Re: Radxa Orion O6

[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.

> 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