Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Jan 2025 15:38:25 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        FUKAUMI Naoki <naoki@radxa.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Radxa Orion O6
Message-ID:  <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com>
In-Reply-To: <C7599FF0E0B3381D%2Be0606559-357c-435c-8534-7353a2055749@radxa.com>
References:  <EDDF572D3560B2F6%2Bc4a27a6d-9a19-40df-9eef-42bbb4e9aa39@radxa.com> <087C4A9F-288B-40EA-BE1B-ACFD32C86DF2@yahoo.com> <C7599FF0E0B3381D%2Be0606559-357c-435c-8534-7353a2055749@radxa.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello FUKAUMI,

On Jan 20, 2025, at 13:06, FUKAUMI Naoki <naoki@radxa.com> wrote:

> On 1/21/25 02:01, Mark Millard wrote:
>>> . . .
>>> /-------- Welcome to FreeBSD ----------\  ```                        =
`
>>> |                                      | s` `.....---.......--.```   =
-/
>>> |  1. Boot Installer [Enter]           | +o   .--`         /y:`      =
+.
>>> |  2. Boot Single user                 |  yo`:.            :o      =
`+-
>>> |  3. Escape to loader prompt          |   y/               -/`   =
-o/
>>> |  4. Reboot                           |  .-                  =
::/sy+:.
>>> |  5. Cons: Serial                     |  /                     `--  =
/
>> Does there a UART based serial console? Or is there
>> a video console? Or are both possible?
>=20
> As I wrote, in "ACPI" mode the video console is only visible after the =
kernel has started.

That does not tell me if there is also a UART serial console
(no non-video) potentially available.

I've seen contexts were one provided messages in the early
kernel time frame and the other did not until something
was reconfigured so that both would. I've also seen examples
of both not doing so until things were reconfigured so
that both would.

But, now it seems my question is not relevant.

>>> . . .
>>> Using the "Device Tree" I was able to use both the serial console =
and the display and boot the installer. Please see dmesg below.

The above reads to me like the dmesg was supposedly for a
Device Tree boot, not for UEFI/ACPI. This explains my note
below, even though I got it wrong.

>> That later output indicates an UEFI/ACPI boot instead of Device Tree.
>> For example:
>> . . .
>> ACPI: IORT: Dropping unhandled type 6
>> . . .
>> acpi0: <CIXTEK SKY1EDK2>
>> acpi0: Power Button (fixed)
>> acpi0: Sleep Button (fixed)
>> acpi0: Could not update all GPEs: AE_NOT_CONFIGURED
>> . . .
>> and there are lots more examples of "acpi" references in the output,
>> 30+ references counting the ones quoted above.
>=20
> Yes, I understand that. But as I wrote, things work differently in =
"ACPI" and "Device Tree".
>=20
>>> But all pcib are not configured.
>> Looks like it always reported:
>> pcib0: could not allocate memory.
>> A verbose boot output would likely be handy for someone that
>> knows what they are doing for ACPI contexts.
>=20
> Changing FreeBSD boot options causes a kernel panic on the serial =
console as shown below ("DeviceTree" mode):

The early part of the ACPI boot likely gives relevant
information for ACPI, even if there is a later
panic/boot-failure. This presumes being able to capture
and report the output that does occur, however.

> . . .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9B90ADE3-9E1E-448A-B592-509B0E61B197>