From nobody Tue Jan 21 21:26:43 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yd0ds3JWFz5lcRv for ; Tue, 21 Jan 2025 21:26:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yd0ds0Fj7z3tmr for ; Tue, 21 Jan 2025 21:26:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-216401de828so105700265ad.3 for ; Tue, 21 Jan 2025 13:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1737494815; x=1738099615; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5qnU1hjrec8sth/S78y3XmffA+4I85EmGcvFzWiKNiI=; b=POHJlNlDfjNS2MhtzguCCIXjOlWob0OTHFd+7vPj6Li6FNR3wJQ4SeV23eAEHAB5Ln 2nmmHqQHVs4FmoHJdghA7grTrSTI/S8Jhp9mGDjVGsZT9onDRh8Ctq7cXVpEBlJ7p4t4 o51x9DB4qdYyV88Lqvk2QP6KAPqlnRFpCziFx6B7haq9763MxiMb8IOndtOZMBJlGIAC xgDYl4XWoH+QKvVXxGMw+Cp3qyZpqWZMhbxRItsMUoICDMIPtvTPhN2YFygZhhFq44pY C9okaZNKUs4BS97BeFTXNfRKbbWYN3Q48TDBDUETyiKgrdHzKnR55kS7Nos9zeTEFOox 3xXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737494815; x=1738099615; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5qnU1hjrec8sth/S78y3XmffA+4I85EmGcvFzWiKNiI=; b=qzh3ePrv8gQHEIwNl2b685kZrtZLxk/mpK/Pc8nCL8pC5+gms3yRmlJ1JW6EONrN2Z ISCGUgjPHv3PfUJSejXkMd3I4GROYwDo8BebkostciATNoVeyYnf460XGmzvoR+/YJU5 PrWelwvRwDYJGvwxcR3a0OFE2aoKmKrP6o7vALzheG2maXnCgmtWk/Fj+f/XvlfynsjX S0qRLq2Pb3ZmwELNuyFtIAKanJ7P6Mwof3bXEyWR5njsqQm4rKmL91651gIDbq+6vGjg sVH5WNmKpqFTHSbpL5zwr2D+ybvbYeH4yg1SipfURWl4Q+jDA9O9jExnTKK8Ho6vyvnb V9ng== X-Forwarded-Encrypted: i=1; AJvYcCW2Lnz71bPQ3y1VzEOhtwlo+E9ft+UbJfMYokxOEaqYbA+k+yuvIQuNp/GR51HG5fvMllBlhy/eYN2vbA==@freebsd.org X-Gm-Message-State: AOJu0YwGDrDCi9u1QR1KJNKRE87tXhmhu44FWdU5dCnU9MKnLzPr8K+8 fIo3KrFSJsJyPW4naKgyYM26vHUbUdMgzgzEtBW1KwD0S4cQltTiw2HW7pt8sMoVIDGv9TEW4Ni 8GSs6BgNfhoN+G8SFCGawcQCfhbNb0JUR8vMZfIWnEJDE7wsl/X6rvw== X-Gm-Gg: ASbGnctoBMibblcXn3Tk/52zZ5Q/8M8uNFVqfK26pMYqNvEaSlfzYLsGtsDzYyYJoW9 4MdY934V5SaNuyLfgWF6BEEA2LY+U6B7m4yai8A75wdeuORMRUtg= X-Google-Smtp-Source: AGHT+IE+yeOjF2yQcfLGra557bEZVGwM/GAuOvL79OPvCR6r9DKPiuPhcZ5807NRZy9zu77afkHndLMOdOIaRa675xg= X-Received: by 2002:a05:6a20:9f4f:b0:1eb:48e2:2c2e with SMTP id adf61e73a8af0-1eb48e22cf9mr13178418637.32.1737494815147; Tue, 21 Jan 2025 13:26:55 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 References: <087C4A9F-288B-40EA-BE1B-ACFD32C86DF2@yahoo.com> <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> In-Reply-To: <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> From: Warner Losh Date: Tue, 21 Jan 2025 14:26:43 -0700 X-Gm-Features: AbW1kvaBx9FAFofjzbTje561WPbrFPM1nHgvtGYiKP8iVv8SnU2oNzC4PDV_LdI Message-ID: Subject: Re: Radxa Orion O6 To: Mark Millard Cc: FUKAUMI Naoki , freebsd-arm@freebsd.org, Andrew Turner Content-Type: multipart/alternative; boundary="00000000000041a4f4062c3e0911" X-Rspamd-Queue-Id: 4Yd0ds0Fj7z3tmr X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --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 wr= ote: > On Jan 21, 2025, at 12:10, FUKAUMI Naoki 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 wrote: > >>> Hello FUKAUMI, > >>> > >>> On Jan 21, 2025, at 04:27, FUKAUMI Naoki 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


On Tue, Jan 21,= 2025 at 1:33=E2=80=AFPM 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 fo= r someone that
>>>>>>> knows what they are doing for ACPI contexts. >>>>>>
>>>>>> Changing FreeBSD boot options causes a kernel pani= c on the serial console as shown below ("DeviceTree" mode):
>>>>> The early part of the ACPI boot likely gives relevant<= br> >>>>> information for ACPI, even if there is a later
>>>>> panic/boot-failure. This presumes being able to captur= e
>>>>> 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= =3Dsharing
>>>> https://drive.google.com/file/d/1NrZCdBiaVDsNjw1gbNvt5qDMpG0YDrC_/view?usp= =3Dsharing
>>>> https://drive.google.com/file/d/1Pt3JqOGD8mYU76ld0l7cD3_sljAnBCi8/view?usp= =3Dsharing
>>>> https://drive.google.com/file/d/1uCMljSjxDDpfPFatJ3ji0gyFhD4Bi844/view?usp= =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 000= 0A0000000
>>> (not included).
>>>
>>> But its later "Physical memory chunk(s)" list does n= ot include such a
>>> range. Nor does "Excluded memory regions" list anyth= ing in that range.
>> WARNING: I seem to have misinterpreted the picture: it looks like<= br> >> the "missing" Physical memory chunk(s) line is because o= f 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 c= hunk(s)
>> lines.
>
> Sorry for incomplete screenshots. Does running memmap on the loader no= t 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"<= br> 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 Tu= rner
has a review to add additional pl011 types that are common b= ut were missed
by my initial parsing. Maybe all we need is https://reviews.freebsd.org/D48526=
to get to the next level.

Warner
=C2=A0
> https://lists.freebsd.or= g/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" starti= ng at 0000A0000000 for
>>> 00008000 pages . So: 0000A0000000 up to 0000A8000000 (not incl= uded),
>>> which is immediately after the above.
>>>
>>> Also: That Reseserved is, in turn immediately following by mor= e
>>> ConventionalMemory, so there is a hole in the middle, in a sen= se.
>>> This end: 0000A8000000 up to 0000FFFC0000 (not included).
>>>
>>> There is also at the end a Reserved starting at 000084800000 w= ith
>>> 00000800 pages. So: 000084800000 up to 000085000000 (not inclu= ded)
>>>
>>> That means the sequence is really:
>>>
>>> Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0000084800000 = up to 000085000000 (not included)
>>> ConventionalMemory 000085000000 up to 0000A0000000 (not includ= ed)
>>> Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00000A0000000 = up to 0000A8000000 (not included)
>>> ConventionalMemory 0000A8000000 up to 0000FFFC0000 (not includ= ed)
>>>
>>>> https://drive.google.com/file/d/1ynr6-bfWg0zs6sbe76QE6XsPstgegbEu/view?usp= =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--