From nobody Tue Jan 21 19:56:21 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 4Ycydg4Y74z5lWlp for ; Tue, 21 Jan 2025 19:56:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ycydf4Df9z3fGb for ; Tue, 21 Jan 2025 19:56:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=axKy1vhl; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1737489396; bh=AoVBIinc20d2XGHESEN1WtxN6gmB5yCGeao6t4cOwYc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=axKy1vhlqAFW3zyoxP248oltn+BjlndA6+nUhf2rAi70YUA8KDhT8003sJ1EnzHRQK5yEs2ZU9poSr0j3lmxmLIA2n8OK+MaF0gN7rJmhBwmaJPT8rKz99p6jnRyb75sGUi3Jr9IymABRGR9+Ui8zIKcMaay4WlXzFbLElfQyUAwPpopqOQyoEIZLpH/qhiYPHkpaAJyoEb08N2WEKPBQBKKsFVzGz+Lz6mX//Vq24/yZ2DKVzBp6CxIniMONUZEuFo9+RJelWG1LUtTZa+/dv88JUGBa1nofp534o4izrAbvXLBjJn2meGI8IiYhGpPd3ykLQB/WZaUhDEi0vgE/A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1737489396; bh=r5slmkd015aY65rhxRDqkaiHg2LwtenMOT2Pv6Mq2rO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qq9BX90vMy+j0rGNbvQFrvInIPFLuArJMIEKUHKW4Q+2txL8ZJiptnHyWoT7OtOZwktUfxKAhm/wNsBcNZYIAhgOPz5Rs7pA3dFIzHaeJaQiZjkiD7DYZ1Na7zf3Zvnd9jf1lQDpMblACFQtdhBxPg2fmuxLiO8cJKRINdlfySPN6nqEwM5zdC+NmT1mwUN5CTEMesjeEJjICDjHP7La2iIaPiYGu+OaXavJWuvOqhUR7uMI3YrPRvaLuDY4tp3DLJEIEvNFu6cVUvxzj7fXvdcLy00QmOs/2/Fwaw/osyj7XqqT6OLMJLwCFFSWQ7cTPL801twdZrQtaV8cmO/phA== X-YMail-OSG: 9QeCM.sVM1lRUeV0KBKZ1a8mYaOYrbtuycM4UDByQTQ4JSB9poBGNKJ6wl55kHl EzZD53yhXCjnMGRoxBchIK_DSzx0c9GYzJ.StkuU8Qjkp9bkdlZK3oQxkHNL8i6HGjor.ZxKYReI SloziPjPquEacv0zf1dpMyTgjpPSXkn1eiwrbwE97xjuoDCiDjxo8oVpJ3cXi7rv.sPWOuu0y.Uo M8o5xAgC9rGFO29fCaMdYyga_SfGFr4aOJKIWx_WpHGXGXTRL9zIK.n_4DF7MoamfjJ01v5ocRlB VNWlBx.MRVhrulJ8fGMsSNd1wHk0FEAVmciNBIhnEpndCRKrcdb9rf0gqS8.lz.dWgzR1eL3ZXBu tRGU9vsPtd.zT4DuJw4JvSK.GmLMMIK_vne7uxgLGqoXEXqwo.qIzvfVnSXHMMGJakIfqlguyMEB fF0ZeADG6zjWdMQ0lFcPvQLZAISPd3udjatLSfvwElH_zMGa5qpXuX4qsnuGU6pxwpiT6ehbcr7f 4uHT2mMQ.Sv9lYTVLuRhya8kEAa6d.ktCyq0c2NX_fdG16juROjxA.guip00iIlOeloQh5g2KZmE kw99TiCU5T_Wlus3j8pQZXoI7kaI93p_OnxTGekKpUpAugFfGOiqtXxU7MCTGsI4NN6N0IvSDf2f Mlw_rgzwOLMxajko__xIS.ieRlTZaoXelWUs6yZhaUCRVdkgn0DbKiEdvIQi9DG9o2H68.BX0n_E qFgsfheJi_hrr9.ysCgDBM_tDqceBarH1sdHpZpdIHbgm1rPMuPE8_lwVoa7G4Oq7adj029NBrnd LOM4Mv6FrbQeBHTS5oTDl8VcOPXUVgUCPmjzeD5riVz9rKao8fnyrS63zAGcl8qPXztIK0qVIJA2 uYTj67MYmQwsPnpX4.Bl.1P8YX9gtQ5INWX.Bz_mEeNGd859rD9mfG3hTUNTgE7T12zY3AiAha9t d4qqrJcarcy._JvUuqlbmXKdlHR8Hn9xwY1Tzb2rM3cSYwhxGqG0Yw4UAfKzk5gkyO5of5rIo4m. uoGRlo10HNNV7I_EK6Pd3tDrj2ZVqqXM0blaDBVqZCgX3EQYW2GoH0j05IAQyzfsRFZ.VwlIcVa5 7dkjRdcafpOS6VGYEyfsYNn6RkDnsYnIYYSIfCekkziF9I8sfVvSWIJg_RjdLUmuuonzK7aVMnXQ OESuAb.IqrXY5RPFuJ5WSymUP7JODUdTVNYPTL8f1e3heN7G77AwNZM1KBn5ekpiMiapaRKGzYIl DPx1AOBorlQppqWu_kyTi4tE2oGAlWExQYPASO0hDxwF1nw0gaMNTxRxBqGTVod42U3gSja6BSSt C.LSdBRxOrufBVMlW6WjCwXwJ4NY56LiiXuNHCxLhdRh8sPZGzA_aSPKyRC6cEKu99Bw2fSX.2R5 FgP_qERVmsPigfyAWXxKkOhIDe4eBJlLVRa4bDqP5OicM8_00RF.JVZNm9MYyvS6f22GDsgVL5dd mF6NexYN1L5t95OMADvF5pqL36enLtssiPozCLKTBddmMH1ipL3KgFhCKcoEX7UPoNmnL5HHo42I Y1D4bs7xuJGl7hDTsziCPOrLdaDsNUZWKK_2.6dVLTcL2P7XMQ8kIZ7BFMGto4bg3W5ogx8WFKnL tOBT4cOCknSTQDi9ue.G2Em0HaMwE31VIIxLmDYaU4A8t.d2D66u1nE_YuPpDlQtdZISPgYrjuru WDLtWit7f1_uQ8DA4QWFY2w.ZeY29Z2dGkYkczYFH03vdwWjnrSd.JNHoMzTWE2bZ2skrZtJnglF XuX7om7QtY59D9PESfE84Va7SrzrQQUe_6R2y4CF.jKAgZB9llFQN5FJRWHUfjVbKMk2_3C9uMeN OwQUd0oiugTASNfs0LiNPZfiNM.azQRMPJx19nDjdAc7qcq_uRsOdG0TaZ5nwfmThXGgu6d4sblK yg.27NA284_w9KNgRdhvDnKG9ax6tOKKDXWmQFBTo53rTha_3_4I2xeSaHP6NESD.m7OUrxX6Uve JJzoiKbgy6EA2RT2G4H6D1lJ6EVJ3PNLPnThiVkyHahqshpPIn5gHItJCPOTwwXAIz6Mq7Ik6_RI H6qW76dlYDzps29ERG7D4ZY1.Eo9C0X.vR4b_X26SX7pockeosSB6KdMLnp6dv9rhEBSEhT2PhbV B8fAhwBRgjvh4q1jSRFWNOkXSyuj6xW8QGE8QErWWt2O_sOWNio7dttL0d_clhUHJSacFu8qc2Kv Zi89qmDIOi2OQa7QB3WMIhm0lqwl0Kg.27c22Vd8hKT8WJBpcwN4NONVCcr4QHiC._m91Xcu5_io g0yiGKtMTlYvjVw-- X-Sonic-MF: X-Sonic-ID: 06c414c1-1283-45b9-8d0a-3a921128efa0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Jan 2025 19:56:36 +0000 Received: by hermes--production-gq1-5dd4b47f46-wrqn7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2755d293b3f2348f571e144beec47b28; Tue, 21 Jan 2025 19:56:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: Radxa Orion O6 From: Mark Millard In-Reply-To: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> Date: Tue, 21 Jan 2025 11:56:21 -0800 Cc: freebsd-arm@freebsd.org, Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> References: <087C4A9F-288B-40EA-BE1B-ACFD32C86DF2@yahoo.com> <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> To: FUKAUMI Naoki X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Spamd-Result: default: False [-4.50 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.30:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Ycydf4Df9z3fGb [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, >=20 > On Jan 21, 2025, at 04:27, FUKAUMI Naoki wrote: >=20 >> 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. >>>>=20 >>>> 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. >>=20 >> I captured kernel messages (acpi & verbose) as much as possible. >>=20 >> = 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 >=20 > Warning that I'm not an expert in the area. >=20 > The one just above shows a ConventionalMemory region starting at = Physical > 000085000000 with #Pages 0001b000 . So: 000085000000 up to = 0000A0000000 > (not included). >=20 > 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. >=20 > 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). >=20 > There is also at the end a Reserved starting at 000084800000 with > 00000800 pages. So: 000084800000 up to 000085000000 (not included) >=20 > That means the sequence is really: >=20 > 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) >=20 >> = https://drive.google.com/file/d/1ynr6-bfWg0zs6sbe76QE6XsPstgegbEu/view?usp= =3Dsharing >=20 > The one above reports: >=20 > ram0: reserving memory region: 85000000-a0000000 >=20 > which then gets the panic. (After all: not > listed in Physical memory chunk(s).) >=20 > 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: >=20 > 0x85000000 - 0x9FFFFFFF >=20 > instead of: >=20 > 85000000-a0000000 > END SIDE NOTE >=20 > 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. >=20 > 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. >=20 > I've not looked at the code. >=20 > 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