Bug 274956 - Kernel panic at mountroot prompt
Summary: Kernel panic at mountroot prompt
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 15.0-CURRENT
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-07 16:44 UTC by Paul Reynolds
Modified: 2023-11-14 10:52 UTC (History)
4 users (show)

See Also:


Attachments
kernel panic output (10.89 KB, text/plain)
2023-11-07 16:45 UTC, Paul Reynolds
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Reynolds 2023-11-07 16:44:07 UTC
I am attempting to boot FreeBSD on an i.MX 8M Plus EVK from NXP (https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/evaluation-kit-for-the-i-mx-8m-plus-applications-processor:8MPLUSLPD4-EVK). The kernel is loading successfully and boots up to the point where it is trying to mount the root filesystem, at which point it panics. I have tried local builds of FreeBSD 13.2, and 14.0-RC2 as well as the 20231026 build of 15-CURRENT all with similar results.

I am attempting to boot a USB installer image with the u-boot install shipped on the board.

u-boot commands:
run loadfdt
usb start
fatload usb 0:1 ${loadaddr} /EFI/BOOT/bootaa64.efi
bootefi ${loadaddr} ${fdt_addr}

I have attached the initial kernel output along with the panic from the attempt using the 20231026 build of 15-CURRENT.

Any hints as to what might be going on here are greatly appreciated.
Comment 1 Paul Reynolds 2023-11-07 16:45:14 UTC
Created attachment 246181 [details]
kernel panic output
Comment 2 Andrew Turner freebsd_committer freebsd_triage 2023-11-07 17:19:21 UTC
Why is the driver returning a failure? It's likely the cause as the panic is in the uart kobj handling, indicating it hasn't been initialized.

uart0: <Freescale i.MX UART> mem 0x30860000-0x3086ffff irq 45 on simplebus3
device_attach: uart0 attach returned 2
Comment 3 John F. Carr 2023-11-07 17:21:46 UTC
I see in your log

uart0: <Freescale i.MX UART> mem 0x30860000-0x3086ffff irq 45 on simplebus3
device_attach: uart0 attach returned 2
uart0: <Freescale i.MX UART> mem 0x30880000-0x3088ffff irq 46 on simplebus3
device_attach: uart0 attach returned 2
uart0: <Freescale i.MX UART> mem 0x30890000-0x3089ffff irq 47 on simplebus3
device_attach: uart0 attach returned 2

The crash in uart_grab may be because there is no uart device to grab.

The faulting source code looks like

 kobjop_t _m;
 kobjop_desc_t _desc = &uart_grab_desc
 kobj_method_t **_cep = &((kobj_t)this)->ops->cache[_desc->id & (256 - 1)]
 kobj_method_t *_ce = *_cep
 if (_ce->desc != _desc) _ce = kobj_lookup_method(((kobj_t)this)->ops->cls, _cep, _desc)
 _m = _ce->func

On my system the PC (uart_grab + 0x30) corresponds to the load of _ce->desc.  If your kernel has the same register assignments the base address of the load holds 0x00656572665f7365 = "es_Free".
Comment 4 Ronald Klop freebsd_committer freebsd_triage 2023-11-07 23:30:38 UTC
Next to the panic which is discussed above. 

Why is your root device configured as a CDROM?
cd9660:/dev/iso9660/15_0_CURRENT_AARCH64_CD%20

You mention you are booting from USB. I see no usb controller recognized by freebsd in the boot messages. So no usb disk also.
Comment 5 Paul Reynolds 2023-11-09 14:22:04 UTC
Thanks everyone for your input! It was probably naïve of me to assume I could boot a kernel on a random embedded arm64 board without writing any drivers. The fact that it got as far as it did using just UEFI support should make doing so easier.

Is there is a way to tell the kernel to continue to use the UEFI interface and not switch to native drivers that aren't present? Either way, I think we can close this as unsupported hardware.

As for the root device showing as a CD-ROM, that is because I used rufus to put an iso on a USB flash stick and was booting from that. I get the same results when attempting to boot an img, except it can't find ufs:/dev/ufs/FreeBSD_Install, likely for the same reason that there is no driver for the device the root filesystem lives on.
Comment 6 Andrew Turner freebsd_committer freebsd_triage 2023-11-13 11:55:33 UTC
There is i.MX 8 support. Depending on how similar the i.MX 8M is it shouldn't be too difficult to also support. Can you point us to the dts you are using?

There is no way to use the UEFI console in the kernel. The console is a boot service, and we need to exit the boot services before executing the kernel.
Comment 7 Paul Reynolds 2023-11-13 13:35:54 UTC
> Can you point us to the dts you are using?

I am using a binary dtb obtained from the hardware manufacturer (NXP), but I believe it to be the same as this one:
https://github.com/Freescale/u-boot-fslc/blob/2023.04%2Bfslc/arch/arm/dts/imx8mp-evk.dts
Comment 8 Andrew Turner freebsd_committer freebsd_triage 2023-11-14 10:52:01 UTC
It looks like it's missing the clock device. You can see the clock node at https://github.com/Freescale/u-boot-fslc/blob/2023.04%2Bfslc/arch/arm/dts/imx8mp.dtsi#L481-L513. It's a fsl,imx8mp-ccm where FreeBSD has support for fsl,imx8mq-ccm. I expect they are similar, however will contain a different selection of clocks and may be at different register offsets.

You will also need to update the usb drivers to get to userspace as, while there is a dwc3 driver, you will need a glue driver to handle things like clocks. You can see sys/dev/usb/controller/xlnx_dwc3.c as an example.