Date: Tue, 21 Jan 2025 12:33:28 -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: <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> In-Reply-To: <9581F4025795F7C5%2B10590950-836c-4d9c-9c05-43b25b880e08@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> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5%2B10590950-836c-4d9c-9c05-43b25b880e08@radxa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 21, 2025, at 12:10, FUKAUMI Naoki <naoki@radxa.com> wrote:
> Hi Mark,
Hello FUKAUMI.
> thank you very much for your help.
>=20
> On 1/22/25 04:56, Mark Millard wrote:
>> [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.
>=20
> Sorry for incomplete screenshots. Does running memmap on the loader =
not help?
The "Physical memory chunks(s)" has output reporting what the
kernel did with such information.
The same sort of status is true of the "Excluded memory regions"
output: extra information that the loader cannot report as it
is from the kernel's operation.
It looks like both of those ended up with screen update activity
during the picture that make the image incomplete for that part
of the output. It would probably take pictures from 2 or more
attempts to be sure everything ends up displayed when all the
tries are examined overall, even if no one picture is complete.
Too bad there does not seem to be a UART (or such) based serial
console as well, not dependent on video.
> =
https://lists.freebsd.org/archives/freebsd-arm/2025-January/004464.html
>=20
> Btw I'm thinking SPCR is really needed...
>=20
> Best regards,
>=20
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
>=20
>>> 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?9EDB5AF9-B11B-474E-8541-6C10098574CE>