Re: Supermicro R12SPD Ampere Altra - No valid device tree blob found

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