From nobody Tue Jan 21 20:10:49 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 4YcyyJ0VKxz5lXKG for ; Tue, 21 Jan 2025 20:11:04 +0000 (UTC) (envelope-from naoki@radxa.com) Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YcyyG6g7Fz3hWw for ; Tue, 21 Jan 2025 20:11:02 +0000 (UTC) (envelope-from naoki@radxa.com) Authentication-Results: mx1.freebsd.org; none X-QQ-mid: bizesmtpip2t1737490252tn28r8v X-QQ-Originating-IP: ZI5xaKAy/FXxPcE7pLNDWhJNMNYetQ+48Gr+tTMRmgY= Received: from [IPV6:240f:10b:7440:1:5772:e21: ( [localhost]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 22 Jan 2025 04:10:50 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 8302001430723767994 Message-ID: <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> Date: Wed, 22 Jan 2025 05:10:49 +0900 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 User-Agent: Mozilla Thunderbird Subject: Re: Radxa Orion O6 To: Mark Millard Cc: freebsd-arm@freebsd.org, Andrew Turner 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> Content-Language: en-US From: FUKAUMI Naoki In-Reply-To: <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpip:radxa.com:qybglogicsvrgz:qybglogicsvrgz8a-1 X-QQ-XMAILINFO: OQNQM5UP8StMUAwx2bq31ZmLsS910S+44Bqq2/DFcrZpuGdMCO3gcfuZ n4bSJR9CRqMr0JlA6W0VbH8DT8gfS2ioBJQio+NfZqfkDDWvXxWSpRhJGLIhPWq/RE0HpB3 gwSmz5BCVVkHxZyXCG1z5tsegRNTmuAX7iqnR3UOldfJ+3z+W4aY0CeBVQwol61yGMuoag0 uOltDZ0Bgw/M7q2mBOJkOyGYD5DoHeeNN+pl7GO1Jp3vAEDJUPtAhEC8np+QT4ugtUqoW2z O5z56O8jc4r2gCLw6l6Y+wy9yCdCs8NKUpdEjmKP+9amMNMAU7TTLp3PyKmtwuXnGPg7f7N shbie72DxU/qg+xNCWrZxS3qYs5/syY6tCRYIkTJngNxQfS3wGaD6BiH/bqBgh5iJOouPhg w7WRUs/7vekWNYe/eJQ3xRfbcfBaj9P3nIr2SP+XYxooayXAd0YMnEUYmF6FcFZIqGsfuXD hpxx3jv6Pc4nEugoNKXxIvcKbEPMWYDobFxxFFUN/vDZ0DMNj7uJ0u5fyxwV18vYv+X7XlX RB/Lq22wv4pSb5ONaJ1woDdoiqy1uXaCIkStv9HWYOxuBPvodTPAeGqSetqEaxh39C2M/v4 TV7dcRaoNS2q+L29L/SUYOawk3mRzEXGwXBxBgAJ8WTrst6FEEE9STcrsQFRBNmxRoU9sSX GE3ArIZD10txDGCLn6aXEXikiIQKJqQT41x9jcrl73uXDVzkurmoZsGfIfQGJOarI50R4Qo +LMjqCXuolZW+7x2kexAJk5ItMmAToX5Wsmiufor2sZanu3yjUn58ew7zFmR04Jgo6UyyZG 2yePlaI4qlKEA9IrbnyGn/uagbJ1OTao+WT1ZPiAk6ApHVy6iIivySdvvSE3TTk9bCPpgZS dXMWpR52O1zGqxm2aCdjJU7i94we/JK8mzTFqtIWDts= X-QQ-XMRINFO: MPJ6Tf5t3I/ycC2BItcBVIA= X-QQ-RECHKSPAM: 0 X-Rspamd-Queue-Id: 4YcyyG6g7Fz3hWw 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:16509, ipnet:54.206.0.0/17, country:US] 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 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?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 > > >