Date: Tue, 21 Jan 2025 14:26:43 -0700 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: FUKAUMI Naoki <naoki@radxa.com>, freebsd-arm@freebsd.org, Andrew Turner <andrew@fubar.geek.nz> Subject: Re: Radxa Orion O6 Message-ID: <CANCZdfobczXAct-C9Vvffe2mmj0Y5kpj-W-ywVbMQg_O5cctNg@mail.gmail.com> In-Reply-To: <9EDB5AF9-B11B-474E-8541-6C10098574CE@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> <9581F4025795F7C5%2B10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000041a4f4062c3e0911
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 21, 2025 at 1:33=E2=80=AFPM Mark Millard <marklmi@yahoo.com> wr=
ote:
> 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?us=
p=3Dsharing
> >>>>
> https://drive.google.com/file/d/1NrZCdBiaVDsNjw1gbNvt5qDMpG0YDrC_/view?us=
p=3Dsharing
> >>>>
> https://drive.google.com/file/d/1Pt3JqOGD8mYU76ld0l7cD3_sljAnBCi8/view?us=
p=3Dsharing
> >>>>
> https://drive.google.com/file/d/1uCMljSjxDDpfPFatJ3ji0gyFhD4Bi844/view?us=
p=3Dsharing
> >>>
> >>> 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 0000A00000=
00
> >>> (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 fo=
r
> >>> 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?us=
p=3Dsharing
> >>>
> >>> 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.
>
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>
>
--00000000000041a4f4062c3e0911
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 21,=
2025 at 1:33=E2=80=AFPM Mark Millard <<a href=3D"mailto:marklmi@yahoo.c=
om">marklmi@yahoo.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">On Jan 21, 2025, at 12:10, FUKAUMI Naoki <<a href=
=3D"mailto:naoki@radxa.com" target=3D"_blank">naoki@radxa.com</a>> wrote=
:<br>
<br>
> Hi Mark,<br>
<br>
Hello FUKAUMI.<br>
<br>
> thank you very much for your help.<br>
> <br>
> On 1/22/25 04:56, Mark Millard wrote:<br>
>> [WARNING: My notes turn out to seem to be significantly based<br>
>> on a misinterpretation of one of the pictures.]<br>
>> On Jan 21, 2025, at 08:56, Mark Millard <<a href=3D"mailto:mark=
lmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
>>> Hello FUKAUMI,<br>
>>> <br>
>>> On Jan 21, 2025, at 04:27, FUKAUMI Naoki <<a href=3D"mailto=
:naoki@radxa.com" target=3D"_blank">naoki@radxa.com</a>> wrote:<br>
>>> <br>
>>>> On 1/21/25 08:38, Mark Millard wrote:<br>
>>>>>>> A verbose boot output would likely be handy fo=
r someone that<br>
>>>>>>> knows what they are doing for ACPI contexts.<b=
r>
>>>>>> <br>
>>>>>> Changing FreeBSD boot options causes a kernel pani=
c on the serial console as shown below ("DeviceTree" mode):<br>
>>>>> The early part of the ACPI boot likely gives relevant<=
br>
>>>>> information for ACPI, even if there is a later<br>
>>>>> panic/boot-failure. This presumes being able to captur=
e<br>
>>>>> and report the output that does occur, however.<br>
>>>> <br>
>>>> I captured kernel messages (acpi & verbose) as much as=
possible.<br>
>>>> <br>
>>>> <a href=3D"https://drive.google.com/file/d/1Ck-T2S6oln5y0X=
iJcp7rKtUl3xEiaWQG/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank"=
>https://drive.google.com/file/d/1Ck-T2S6oln5y0XiJcp7rKtUl3xEiaWQG/view?usp=
=3Dsharing</a><br>
>>>> <a href=3D"https://drive.google.com/file/d/1NrZCdBiaVDsNjw=
1gbNvt5qDMpG0YDrC_/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank"=
>https://drive.google.com/file/d/1NrZCdBiaVDsNjw1gbNvt5qDMpG0YDrC_/view?usp=
=3Dsharing</a><br>
>>>> <a href=3D"https://drive.google.com/file/d/1Pt3JqOGD8mYU76=
ld0l7cD3_sljAnBCi8/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank"=
>https://drive.google.com/file/d/1Pt3JqOGD8mYU76ld0l7cD3_sljAnBCi8/view?usp=
=3Dsharing</a><br>
>>>> <a href=3D"https://drive.google.com/file/d/1uCMljSjxDDpfPF=
atJ3ji0gyFhD4Bi844/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank"=
>https://drive.google.com/file/d/1uCMljSjxDDpfPFatJ3ji0gyFhD4Bi844/view?usp=
=3Dsharing</a><br>
>>> <br>
>>> Warning that I'm not an expert in the area.<br>
>>> <br>
>>> The one just above shows a ConventionalMemory region starting =
at Physical<br>
>>> 000085000000 with #Pages 0001b000 . So: 000085000000 up to 000=
0A0000000<br>
>>> (not included).<br>
>>> <br>
>>> But its later "Physical memory chunk(s)" list does n=
ot include such a<br>
>>> range. Nor does "Excluded memory regions" list anyth=
ing in that range.<br>
>> WARNING: I seem to have misinterpreted the picture: it looks like<=
br>
>> the "missing" Physical memory chunk(s) line is because o=
f the<br>
>> screen being mid-update when the picture was taken, not that it<br=
>
>> was actually missing:<br>
>> Other of the EMails show the "missing" Physical memory c=
hunk(s)<br>
>> lines.<br>
> <br>
> Sorry for incomplete screenshots. Does running memmap on the loader no=
t help?<br>
<br>
The "Physical memory chunks(s)" has output reporting what the<br>
kernel did with such information.<br>
<br>
The same sort of status is true of the "Excluded memory regions"<=
br>
output: extra information that the loader cannot report as it<br>
is from the kernel's operation.<br>
<br>
It looks like both of those ended up with screen update activity<br>
during the picture that make the image incomplete for that part<br>
of the output. It would probably take pictures from 2 or more<br>
attempts to be sure everything ends up displayed when all the<br>
tries are examined overall, even if no one picture is complete.<br>
<br>
Too bad there does not seem to be a UART (or such) based serial<br>
console as well, not dependent on video.<br></blockquote><div><br></div><di=
v>I think there is... The loader thinks the console is only serial. Andy Tu=
rner</div><div>has a review to add additional pl011 types that are common b=
ut were missed</div><div>by my initial parsing. Maybe all we need is <a hre=
f=3D"https://reviews.freebsd.org/D48526">https://reviews.freebsd.org/D48526=
</a></div><div>to get to the next level.</div><div><br></div><div>Warner</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <a href=3D"https://lists.freebsd.org/archives/freebsd-arm/2025-January=
/004464.html" rel=3D"noreferrer" target=3D"_blank">https://lists.freebsd.or=
g/archives/freebsd-arm/2025-January/004464.html</a><br>
> <br>
> Btw I'm thinking SPCR is really needed...<br>
> <br>
> Best regards,<br>
> <br>
> --<br>
> FUKAUMI Naoki<br>
> Radxa Computer (Shenzhen) Co., Ltd.<br>
> <br>
>>> I'll also note that there is a "Reserved" starti=
ng at 0000A0000000 for<br>
>>> 00008000 pages . So: 0000A0000000 up to 0000A8000000 (not incl=
uded),<br>
>>> which is immediately after the above.<br>
>>> <br>
>>> Also: That Reseserved is, in turn immediately following by mor=
e<br>
>>> ConventionalMemory, so there is a hole in the middle, in a sen=
se.<br>
>>> This end: 0000A8000000 up to 0000FFFC0000 (not included).<br>
>>> <br>
>>> There is also at the end a Reserved starting at 000084800000 w=
ith<br>
>>> 00000800 pages. So: 000084800000 up to 000085000000 (not inclu=
ded)<br>
>>> <br>
>>> That means the sequence is really:<br>
>>> <br>
>>> Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0000084800000 =
up to 000085000000 (not included)<br>
>>> ConventionalMemory 000085000000 up to 0000A0000000 (not includ=
ed)<br>
>>> Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00000A0000000 =
up to 0000A8000000 (not included)<br>
>>> ConventionalMemory 0000A8000000 up to 0000FFFC0000 (not includ=
ed)<br>
>>> <br>
>>>> <a href=3D"https://drive.google.com/file/d/1ynr6-bfWg0zs6s=
be76QE6XsPstgegbEu/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank"=
>https://drive.google.com/file/d/1ynr6-bfWg0zs6sbe76QE6XsPstgegbEu/view?usp=
=3Dsharing</a><br>
>>> <br>
>>> The one above reports:<br>
>>> <br>
>>> ram0: reserving memory region: 85000000-a0000000<br>
>>> <br>
>>> which then gets the panic. (After all: not<br>
>>> listed in Physical memory chunk(s).)<br>
>>> <br>
>>> SIDE NOTE:<br>
>>> It is unfortunate that the output conventions<br>
>>> vary for upper bounds. In Physical memory chunk(s)<br>
>>> and Excluded memory regions, that would have been<br>
>>> listed more like:<br>
>>> <br>
>>> 0x85000000 - 0x9FFFFFFF<br>
>>> <br>
>>> instead of:<br>
>>> <br>
>>> 85000000-a0000000<br>
>>> END SIDE NOTE<br>
>>> <br>
>>> It leads me to wonder if an off by one error might have<br>
>>> lead to the omission of 000085000000 up to 0000A0000000<br>
>>> from Physical memory chunk(s)being treated as overlapping<br>
>>> with one of the Reserved regions that are next to it.<br>
>>> <br>
>>> Or may be some code that tries to potentially put the 2<br>
>>> ConventionalMemory regions together but rejects the<br>
>>> attempt because of the Reserved in the middle and handles<br>
>>> the rejection by not adding 000085000000 up to 0000A0000000<br=
>
>>> at all.<br>
>>> <br>
>>> I've not looked at the code.<br>
>>> <br>
>>> But it looks like the reason for Physical memory chunk(s)<br>
>>> excluding 0x85000000 - 0x9FFFFFFF needs to be discovered<br>
>>> and fixed.<br>
<br>
<br>
=3D=3D=3D<br>
Mark Millard<br>
marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank=
">yahoo.com</a><br>
<br>
<br>
</blockquote></div></div>
--00000000000041a4f4062c3e0911--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfobczXAct-C9Vvffe2mmj0Y5kpj-W-ywVbMQg_O5cctNg>