Re: Supermicro R12SPD Ampere Altra - No valid device tree blob found
- In reply to: John : "Re: Supermicro R12SPD Ampere Altra - No valid device tree blob found"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 17 Jul 2023 20:39:33 UTC
On Jul 17, 2023, at 12:34, John <jwd@FreeBSD.org> wrote: > ----- Warner Losh's Original Message ----- >> On Mon, Jul 17, 2023 at 11:15 AM Mark Millard <marklmi@yahoo.com> wrote: >> >>> On Jul 17, 2023, at 09:37, John <jwd@FreeBSD.org> wrote: >>> >>>> Hi Folks, >>>> >>>> I have a new Supermicro system: >>>> >>>> Supermicro R12SPD BIOS Date:04/26/2023 Rev:1.1a >>>> CPU : Ampere(R) Altra(R) Max Processor >>>> >>>> Booting from the latest media (spot checking older >>>> media makes no difference): >>>> >>>> Boot Media: >>> FreeBSD-14.0-CURRENT-arm64-aarch64-20230713-510fd8313800-264135-disc1.iso >>>> >>>> Fails here: >>>> >>>> Loading kernel... >>>> /boot/kernel/kernel text=0x2a8 text=0x8ff810 text=0x29b324 data=0x153cc8 >>> data=0x0+0x2c3000 0x8+0x155628+0x8+0x17e504| >>>> Loading configured modules... >>>> can't find '/etc/hostid' >>>> can't find '/boot/entropy' >>>> No valid device tree blob found! >>>> WARNING! Trying to fire up the kernel, but no device tree blob found! >>>> EFI framebuffer information: >>>> addr, size 0x10000000, 0x300000 >>>> dimensions 1024 x 768 >>>> stride 1024 >>>> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 >>>> >>>> >>>> If I break into the loader, the fdt command shows the >>>> same error message. >>>> >>>> OK fdt ls >>>> No device tree blob found! >>>> >>>> OK >>>> >>>> A verbose boot shows no additional information. >>>> >>>> I've poked around in the source and don't see an obvious >>>> fix for this. Web searches have also not provided any >>>> obvious solutions. >>>> >>>> Any ideas? Thoughts? >>> >>> UEFI/ACPI booting does not have a "device tree blob" to find but >>> FreeBSD's UEFI laoder still puts out the "No valid device tree >>> blob found!". I see this on all the UEFI/ACPI booting systems that >>> I have access to --and they all boot fine, aarch64 system and the >>> amd64 system. >>> >>> I expect that your boot context is UEFI/ACPI and that the message >>> has mislead you about what to look for relative to booting. >>> >>> But I could be wrong and the system could be trying to boot via >>> fdt. That is one of the problems with the way this messaging is >>> handled. >>> >>> On the HoneyComb (16 Cortex-A72's), for example, there >>> is the FreeBSD loader's configuration command: >>> >>> OK configuration >>> NumberOfTableEntries=12 >>> 76b6bdfa-2acd-4462-9e3f-cb58c969d937 at 0xfad05b18 >>> fc1bcdb0-7d31-49aa-936a-a4600d9dd083 at 0xfaabfd98 >>> DXE Table at 0xfacea6b0 >>> HOB List Table at 0xfaabd018 >>> MemoryTypeInformation at 0xfacea338 >>> Debug Image Info Table at 0xfad038d8 >>> a4ee0728-e5d7-4ac5-b21e-658ed857e834 at 0xfaccea98 >>> ACPI 2.0 Table at 0xef890018 >>> SMBIOS3 Table at 0xfacb0000 >>> dcfa911d-26eb-469f-a220-38b7dc461220 at 0xee5cb018 >>> HII database at 0xee550018 >>> HII config routing at 0xee530018 >>> >>> For this context, it indicates a UEFI/ACPI boot: note the >>> "ACPI 2.0 Table at". FDT booting would refer to such instead. >>> >>> So you likely can check if you are UEFI/ACPI booting vs. >>> FDT booting. >>> >>> It is technically possible to have an environment that could >>> list both. I've no experience with booting such a system or >>> other knowledge of how FreeBSD handles such. >>> >> >> It's supposed to use FDT if it is present, and ACPI if not. >> If you have both (which kboot does for $REASONS), then >> you'll need to set >> kern.cfg.order="acpi,fdt" >> in /boot/loader.conf which I do for kboot booted mount jade systems. >> >> Warner > > OK set boot_verbose > OK set kern.cfg.order="acpi,fdt" > OK configuration > NumberOfTableEntries=12 > 76b6bdfa-2acd-4462-9e3f-cb58c969d937 at 0xffe88718 > DXE Table at 0xffe84188 > HOB List Table at 0xffc40018 > MemoryTypeInformation at 0xffe865b8 > Debug Image Info Table at 0xffe87380 > 00781ca1-5de3-405f-abb8-379c3c076984 at 0xffd0db98 > ACPI 2.0 Table at 0xffc80000 > a4ee0728-e5d7-4ac5-b21e-658ed857e834 at 0xffd07d18 > SMBIOS3 Table at 0xf8b1ff98 > dcfa911d-26eb-469f-a220-38b7dc461220 at 0xf0c78018 > b122a263-3661-4f68-9929-78f8b0d62180 at 0xfa76bd98 > d742672e-1918-4a66-a1aa-fda807542d81 at 0xf0be0018 So no FDT, just "ACPI 2.0 Table at". That likely implies that set kern.cfg.order="acpi,fdt" makes no difference for the actual context: Always UEFI/ACPI. > OK lsdev > disk devices: > disk0: 1792780 X 512 blocks (removable) > disk0: ISO9660 > disk1: 7501476528 X 512 blocks > disk2: 7501476528 X 512 blocks > disk3: 7501476528 X 512 blocks > disk4: 7501476528 X 512 blocks > http: (unknown) > net devices: > net0: > net1: > net2: > OK boot > Loading kernel... > /boot/kernel/kernel text=0x2a8 text=0x8ff810 text=0x29b324 data=0x153cc8 data=0x0+0x2c3000 0x8+0x155628+0x8+0x17e504| > Loading configured modules... > can't find '/etc/hostid' > can't find '/boot/entropy' Does the media that has the /boot/kernel/kernel that is used above also have a world? I actually have a context in which the used /boot/kernel/ is on separate media than used for the world. (The FreeBSD kernel was the earliest stage that could actually deal with the USB3 port that I wanted to use for the world.) I had to also deal with having/managing /etc/hostid and /boot/entropy on the media used for the /boot/kernel/ . /boot/loader.conf too. Keeping loadable modules uniformly matching the used kernel was also part of managing this odd context. For this context the /boot/loader.conf for the media for the used /boot/kernel/ has: vfs.root.mountfrom="ufs:/dev/gpt/Rock64root" kern.cam.boot_delay=10000 vfs.root_mount_always_wait=1 The vfs.root.mountfrom redirects the world's root to load from the USB3 drive's partition holding the world. I'm not claiming such notes are your overall solution. But those "can't find" messages may be a clue if they are unexepected. > No valid device tree blob found! > WARNING! Trying to fire up the kernel, but no device tree blob found! > EFI framebuffer information: > addr, size 0x10000000, 0x300000 > dimensions 1024 x 768 > stride 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 Serial console possible? Only a video console? There likely are various ways that a video console fails to work, making it not obvious that the boot has actually progressed. Serial console's might have similar issues. Is there some independent evidence that the boot has actually failed vs. its status just not being presented via some form of console? > Any suggestions to track this down? Things must be going > bad pretty quickly. > > Thank, > John > > > It still fails to boot, no output. > === Mark Millard marklmi at yahoo.com