Re: Radxa Orion O6

On Tue, Jan 21, 2025 at 1:33 PM Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 21, 2025, at 12:10, FUKAUMI Naoki <naoki@radxa.com> wrote:
>
> > Hi Mark,
>
> Hello FUKAUMI.
>
> > 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?
>
> 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.
>

I think there is... The loader thinks the console is only serial. Andy
Turner
has a review to add additional pl011 types that are common but were missed
by my initial parsing. Maybe all we need is
https://reviews.freebsd.org/D48526
to get to the next level.

Warner


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