Hi Patrick,
On 1/19/25 23:28, Patrick Wildt wrote:
On Sun, Jan 19, 2025 at 12:35:59PM +0900, FUKAUMI Naoki wrote:
Hi,
I'm trying to boot OpenBSD/arm64 on a Radxa Orion O6.
UEFI has a "O/S Hardware Description Selection" menu where I can choose
"Device Tree" or "ACPI". "ACPI" allows me to boot a mainline Linux kernel.
With "ACPI" I can use the serial console with efiboot, but the kernel output
only shows up on the display after the kernel is loaded.
Here is a screenshot on the display:
https://drive.google.com/file/d/1EIrQO3qxl9F6AQO5y5mzeTleTbDauRqm/view?usp=sharing
Using "Device Tree" I was able to see the kernel panic occur using the
serial console (please see below).
Could you please give me some advice?
Hi there!
This is a pretty cool board, I should try and get one.
Before I start talking about what exactly I can discover through the
pictures/log, is there a way you can share either the sources for the
UEFI build and/or a device tree source/dump for this board? And maybe
also for the ACPI tables? That would help immensely.
The Linux kernel source including DT and the UEFI (EDK2) source will be
released. It's just the beginning...
DT:
https://gist.github.com/RadxaNaoki/c24be91f920bf4fdb23c4ac478c03479
DSDT.dsl:
https://drive.google.com/file/d/1_Uln7YyhukFBBIOHl9VAo8FEeIf9fpjM/view?usp=drive_link
APIC.dsl:
https://drive.google.com/file/d/1NQyEy_t4fVvcXbsVwQbDq1LNi05Jo3CO/view?usp=drive_link
Obviously both modes should boot up, but don't. I can see you're
booting GENERIC. Does that mean you installed using a miniroot and
are now trying to boot after installation? I assume that the RAMDISK
one from the miniroot has failed and you were trying your luck with
GENERIC?
In preparation for compiling the kernel, I installed OpenBSD-curent on
the USB-SSD of the RK3588 board, and am using it as is on the Orion O6.
(Btw GENERIC.MP is very unstable and the processes are killed frequently)
Device Tree Boot:
The failing code is when iterating over all redistributors. It's likely
that the device tree contains an incorrect size for the redistributor
range, or that the stride is set incorrectly. In the UEFI boot you can
see that it does pass agintc attach, which means that our efiboot(8)
code which translates the ACPI information into DT information does
work, but apparently produces different results than what is in the DT.
ACPI Boot:
It's unclear to me where it hangs, it might be the next device driver
that is attaching. It could also be the PCI bus trying to attach. We
could probably get some more information with the ACPI tables. What is
odd to me is that there are multiple MCFG for the same base address,
but maybe it's normal. Does that look alright, kettenis@?
On 1/19/25 23:30, Patrick Wildt wrote:
> Oh, what you could try in ACPI mode is to do "boot -c"; If the console
> input works in the boot config, try something like
>
> disable acpimcfg*
> disable acpipci*
> quit
For now it is not possible to use (serial) console and ukc in ACPI mode,
so I compiled a new kernel without them.
https://drive.google.com/file/d/11TyxkrAeJN8BtTYkMd02ZWPM1sVf-A88/view?usp=sharing
https://drive.google.com/file/d/16yNp0dWgVzUsEZYQGdWoLNEUZIVdF8yR/view?usp=sharing
https://drive.google.com/file/d/1BlQABXliVtQyIA6YMjhAa-mS22GKGL_X/view?usp=sharing
https://drive.google.com/file/d/1DOMgLmOwOJYTwV4tbMmoebTVYDPat7ia/view?usp=sharing
https://drive.google.com/file/d/1RiarF03wVUBMDR_DXywWBf5tFD5AmLUb/view?usp=sharing
https://drive.google.com/file/d/1eb34ofkxlxhIQdbkt5cxMUclkR6UU7Ci/view?usp=sharing
https://drive.google.com/file/d/1fUl_r0-LJ_c8y4Ds-vVEfscIQWQwjkPV/view?usp=sharing
https://drive.google.com/file/d/1pRlTTNw3kLy6fGz8CdMdYoxQ1slwgrDS/view?usp=sharing
(I forgot to take the next (last) screenshot...)
After that I was able to see it hang after acpiiort so I don't think
acpimcfg is the issue, it just seems to hang randomly.
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
