Date: Tue, 21 Jan 2025 11:56:21 -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: <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> In-Reply-To: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.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> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[WARNING: My notes turn out to seem to be significantly based
on a misinterpretation of one of the pictures.]
On Jan 21, 2025, at 08:56, Mark Millard <marklmi@yahoo.com> wrote:
> Hello FUKAUMI,
>=20
> On Jan 21, 2025, at 04:27, FUKAUMI Naoki <naoki@radxa.com> wrote:
>=20
>> 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
>=20
> Warning that I'm not an expert in the area.
>=20
> The one just above shows a ConventionalMemory region starting at =
Physical
> 000085000000 with #Pages 0001b000 . So: 000085000000 up to =
0000A0000000
> (not included).
>=20
> But its later "Physical memory chunk(s)" list does not include such a
> range. Nor does "Excluded memory regions" list anything in that range.
WARNING: I seem to have misinterpreted the picture: it looks like
the "missing" Physical memory chunk(s) line is because of the
screen being mid-update when the picture was taken, not that it
was actually missing:
Other of the EMails show the "missing" Physical memory chunk(s)
lines.
> 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.
>=20
> 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).
>=20
> There is also at the end a Reserved starting at 000084800000 with
> 00000800 pages. So: 000084800000 up to 000085000000 (not included)
>=20
> That means the sequence is really:
>=20
> 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)
>=20
>> =
https://drive.google.com/file/d/1ynr6-bfWg0zs6sbe76QE6XsPstgegbEu/view?usp=
=3Dsharing
>=20
> The one above reports:
>=20
> ram0: reserving memory region: 85000000-a0000000
>=20
> which then gets the panic. (After all: not
> listed in Physical memory chunk(s).)
>=20
> 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:
>=20
> 0x85000000 - 0x9FFFFFFF
>=20
> instead of:
>=20
> 85000000-a0000000
> END SIDE NOTE
>=20
> 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.
>=20
> 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.
>=20
> I've not looked at the code.
>=20
> 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?6591E59D-4E91-4325-8A77-46E182303927>