Re: Radxa Orion O6

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 <[email protected]> wrote:
> 
>> Hello FUKAUMI,
>>
>> On Jan 21, 2025, at 04:27, FUKAUMI Naoki <[email protected]> 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
> 
> 
>