Date: Wed, 22 Jan 2025 05:10:49 +0900 From: FUKAUMI Naoki <naoki@radxa.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, Andrew Turner <andrew@fubar.geek.nz> Subject: Re: Radxa Orion O6 Message-ID: <9581F4025795F7C5%2B10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> In-Reply-To: <6591E59D-4E91-4325-8A77-46E182303927@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> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark,
thank you very much for your help.
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,
>>
>> 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.
>>>>>
>>>>> 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.
>>>
>>> I captured kernel messages (acpi & verbose) as much as possible.
>>>
>>> https://drive.google.com/file/d/1Ck-T2S6oln5y0XiJcp7rKtUl3xEiaWQG/view?usp=sharing
>>> https://drive.google.com/file/d/1NrZCdBiaVDsNjw1gbNvt5qDMpG0YDrC_/view?usp=sharing
>>> https://drive.google.com/file/d/1Pt3JqOGD8mYU76ld0l7cD3_sljAnBCi8/view?usp=sharing
>>> https://drive.google.com/file/d/1uCMljSjxDDpfPFatJ3ji0gyFhD4Bi844/view?usp=sharing
>>
>> 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.
>
> 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.
Sorry for incomplete screenshots. Does running memmap on the loader not
help?
https://lists.freebsd.org/archives/freebsd-arm/2025-January/004464.html
Btw I'm thinking SPCR is really needed...
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
>> 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=sharing
>>
>> 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.
>
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9581F4025795F7C5%2B10590950-836c-4d9c-9c05-43b25b880e08>