Date: Tue, 21 Jan 2025 08:56:18 -0800 From: Mark Millard <marklmi@yahoo.com> To: FUKAUMI Naoki <naoki@radxa.com> Cc: freebsd-arm@freebsd.org, Andrew Turner <andrew@fubar.geek.nz> Subject: Re: Radxa Orion O6 Message-ID: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> In-Reply-To: <C7C5CBC3CFEF3079%2B0371ac55-6f32-4017-8916-4e3fbb971ad7@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> <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> <C7C5CBC3CFEF3079%2B0371ac55-6f32-4017-8916-4e3fbb971ad7@radxa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello FUKAUMI,
On Jan 21, 2025, at 04:27, FUKAUMI Naoki <naoki@radxa.com> wrote:
> On 1/21/25 08:38, Mark Millard wrote:
>>>> 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.
>=20
> I captured kernel messages (acpi & verbose) as much as possible.
>=20
> =
https://drive.google.com/file/d/1Ck-T2S6oln5y0XiJcp7rKtUl3xEiaWQG/view?usp=
=3Dsharing
> =
https://drive.google.com/file/d/1NrZCdBiaVDsNjw1gbNvt5qDMpG0YDrC_/view?usp=
=3Dsharing
> =
https://drive.google.com/file/d/1Pt3JqOGD8mYU76ld0l7cD3_sljAnBCi8/view?usp=
=3Dsharing
> =
https://drive.google.com/file/d/1uCMljSjxDDpfPFatJ3ji0gyFhD4Bi844/view?usp=
=3Dsharing
Warning that I'm not an expert in the area.
The one just above shows a ConventionalMemory region starting at =
Physical
000085000000 with #Pages 0001b000 . So: 000085000000 up to 0000A0000000
(not included).
But its later "Physical memory chunk(s)" list does not include such a
range. Nor does "Excluded memory regions" list anything in that range.
I'll also note that there is a "Reserved" starting at 0000A0000000 for
00008000 pages . So: 0000A0000000 up to 0000A8000000 (not included),
which is immediately after the above.
Also: That Reseserved is, in turn immediately following by more
ConventionalMemory, so there is a hole in the middle, in a sense.
This end: 0000A8000000 up to 0000FFFC0000 (not included).
There is also at the end a Reserved starting at 000084800000 with
00000800 pages. So: 000084800000 up to 000085000000 (not included)
That means the sequence is really:
Reserved 000084800000 up to 000085000000 (not included)
ConventionalMemory 000085000000 up to 0000A0000000 (not included)
Reserved 0000A0000000 up to 0000A8000000 (not included)
ConventionalMemory 0000A8000000 up to 0000FFFC0000 (not included)
> =
https://drive.google.com/file/d/1ynr6-bfWg0zs6sbe76QE6XsPstgegbEu/view?usp=
=3Dsharing
The one above reports:
ram0: reserving memory region: 85000000-a0000000
which then gets the panic. (After all: not
listed in Physical memory chunk(s).)
SIDE NOTE:
It is unfortunate that the output conventions
vary for upper bounds. In Physical memory chunk(s)
and Excluded memory regions, that would have been
listed more like:
0x85000000 - 0x9FFFFFFF
instead of:
85000000-a0000000
END SIDE NOTE
It leads me to wonder if an off by one error might have
lead to the omission of 000085000000 up to 0000A0000000
from Physical memory chunk(s)being treated as overlapping
with one of the Reserved regions that are next to it.
Or may be some code that tries to potentially put the 2
ConventionalMemory regions together but rejects the
attempt because of the Reserved in the middle and handles
the rejection by not adding 000085000000 up to 0000A0000000
at all.
I've not looked at the code.
But it looks like the reason for Physical memory chunk(s)
excluding 0x85000000 - 0x9FFFFFFF needs to be discovered
and fixed.
=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?1B4F62E3-A269-4611-B9ED-1A72298FFC85>