From nobody Tue Jan 21 20:33:28 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 4YczSV2FWlz5lYxb for ; Tue, 21 Jan 2025 20:33:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4YczST3LcTz3ky7 for ; Tue, 21 Jan 2025 20:33:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1737491622; bh=T/Yow3bWugL1zTvqg+C4xvppN/uMWNX5W+LARehF3ws=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Spr/zVyHhb/+zsEpivrkE1p1daHlgr7iBcllmDftUzlsuR9f1mvpaaaegO/fkcv0A1g06eeXOMS9QE7ci0rrwm3yJTL72XWk9pPYucejC1hpcrrTl+/42GeTFnD4uRuXI00tMryoxAnYinbUhDFRR1ERbX/rOUce4APuXvFZc8/0pfUYSbRgW8adyDnKUS1yNRRti8OcXQAhNDixmK6qpc520nUIOfH3B585/cxAzuI8KW5dR9ujbtjGkJ/Dylki1luAviHYHrY4HHeeqwu2JKUhNiAYIuijZYqvJOboqjVp8i6xKih3K9DE9HQWauirsmp9H5tiGmPrOrFKAcCpAA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1737491622; bh=m0ErACctmQh3qUWx9tKM2oHKXrmAooZp+jxo0UQwclQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YULvWOaS6xiAOJAG8tU+op+gIr30MV29FALDc2TLvhZdJw+2xl3DBl6DLBdCIY3pL9CD1NonDp/uWEzjeLpvPi4A9r2ojZVoAWegHGvBL06v/OUspQIYynApGGMnO/8UVEJDw6HES/IEDHNSin40XjRqxV5o4itJ0m/AMyGckW6owpXWgbv9TNL5c6dbzf9/3oGuAToAkXETwiCdnPk2/5YkncxCjboLOk3A89VA1mr+9IWzl+1IQzKtzGid8E1ojJPiII2HeZwc+ef0tMvIxBthH2wP0piL74huWUUH2xDsytIoztr2rjRdhh1JJrFBYwP2UYRp8lJatFpOGYXFdQ== X-YMail-OSG: 0vlD7dEVM1ml.4w9uN2P_MmILEtAMOmxJko2keIenNuYR8eYi8JUwHbuaKIz94t itLvhMex1QiKBhD_biffT0BEL.taXgotT0J7Jge4ynZWPvyfR2uSUnR85AMLnLGOF4raH_ZZBemr PFMx4O78DZv2mwQFucx9FSVTmYSNS.9xTyQZ9oma8wsm59oEZSV6IMLVTTwzS.4GB4d0Mckp0Z.2 R9fSwyWd2JIIprE4OzMseQHTBBFShXCu2uW9UpLBDhm8kA3BpCt6kCsXO5X2Zu78JSco5gJ1kJEg G7UBZZpG125dDvYWfqZPGJsY8FxSyofi0KjBHsXIHsljHCOCToBrRbug.wpPdw0baT5kwqk_RqYu Rk__E5Pyh_tB79HzrMJ0.cZOHNDjyOlBasGjLR7Ql8g9oJO5fjPSuuspuOtmV1fbvHsN8KJ4erRd f_XHTxarBSJGCngUs5_2xbpW_fbpB.HwgG1ccjSn54thPIMGXsN62I2henSO_N0ZTKEGgf.M1Zt_ fLUF4kgVqpt7JUE0QRemGsdchSUa5bqCeSQpt0TxXXOKMSAXPpjd6jHpofIx8hY1P.iIXsDexFvU .PgIaSjc3eEFHvwX0RkIG9jjCLtesTsS.pG7cDs9_5cj7IB9te0Wwwd8hb9c3GW4IMTAypl11bLt hThlNk5y40VrO.O525Zvg7E4gpQViQV3N4.B2QXg8Iqc38ZLSRE2aVNLlSyqTYZ1YGWjQP4LG2_k REeg_MaeYSRxqA2PmzZOQBiqN.wf8Ip_fWMzeLWF5fNP1DWKUuLFJNam7V0ImymgTsSaw_.sm741 AnBDXACvcG2zFmFK6044t5R71dYG6MTupUjq5moWFHDS5l5YqalHNYOY0U_nLLM2vMzzf.4wz3rX FmeosxQzq9.TCoMjijAuoZeymvJNoLAa5336hVAC2.qfoR1QJocTuGvXtzM09ilwK7QtaBPa58nK mAa5ARUJFcgZ2CyUZZ1UqSdHsUo.oT9.L9Dg44bIbIcqGJIH9yrz6lLY_UHcQJG3Gvl6U_QL_bf6 MylMTsNkIWAskQqOPHf9WA7SzxbUMS6LaTHhmd2Lh4igzqfft6Rz9BkeLmMZD52.bDwFx79vqzmn s5.amCt8.KzsYozuZ9NpRDzqbQPCG26FKFq2jV2E82zVy046j90HPMz81n09doV_rMfjuqN5XYSC L.5Tq9NXAQkX7drc9.OQHD.pe.nZWOctkSqwMRSru7gAN.UJMJfDBM8k5jCT7wbt_145ouuMR7cU qGh2QBCeEG4QcOtLHz.yFIUxBTo31rIgoLfZk6NQf2PqMgUQkPFrqLGmz4jT5GSwoU02R2yshO9S 79Lzq4P2BMbiohbTKwotHGnhMDekXzfrODPu3.rMG_Mk.gMYnIZmQEuRAGt2RwbBaFOcgvPqL8oF NzcOaSPRUNxrz_h1O_PnCVFlRSanaduJBkDnMavDylEpgD0dTBz.WlYc176oCsm8YIMFlagNTsVV 3Bsg89evUhgZVZhCWjhhovDpJVCR0WaheyhIzonC4MGyt6.fHKepjtRfM9ZvRrcS6f3Bg5.dbHiU ANDIsqngVJyZ5gTGhMQPtTR4tNFh8NsmFRzHB3z1wHyAlij44goWlkqxjbEl6spCcfQdTUiHntz0 uFbX6VY7Nt1UzLsMYfWrbG2ELEd0zUmZjlkiFGnkwvbIct31.D.5OFLdrONitj30rKZYBlUI7rLe OkPdBHzCTgcXU4xnNRcvtHjZ0COK4U.CMxXmTVUL5srcjbSFiLtM0i_zMOnd9ZmgQvlFsXPQwp_O rTSqncrmTywGpYtcFxBitEAXozl0i9NyqaWEiOYM2Of4b56A1vy_h9KZfM73T5OBwp0NoZn1LwSE qGhCnAllE6.SHbFWNzy5HQlmhwb_ZNddD4FNi9zLWuIzLr332YrX5TvI1If7ieTUCGW0STbkhXmV 6EkNTW_1HTuJWJdc8DcgDh4xLByy98jR3bL0XIsYySbZBJ3n1mDH5jcFsAIbi7naeBlRmNS1GebE sSgJUSn5nn6f8EceOEBkbXPAnxtanuQLWtZ0c8O9yNfQUXuKg_80tG.EF_xjX.jQ8x32ZssM45vw x0TixS.wVGg19oF.44L6J8yOPJdix5vBVD3gPTX7PPxFC90LK3sMLmg81RaByix4gq3duTuOC80a zM2hi7qF3lyZfEpodtbuqcAUwBhiuW0xkY8gVau5qVU3bMOJEb3EiOcrm.9w4kOFTEU.z22zGBFC zjH0YMt1KuSriehEVveBLOfns6jG7de5tTk7ld8TY8IZ4H2AkNPkvv8U.4ogyIQGoCLZ6yMwYEiE wSRiMy9NHy7iVVTA- X-Sonic-MF: X-Sonic-ID: fe793628-ccdc-4eeb-b743-e1887c6bc2fc Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Jan 2025 20:33:42 +0000 Received: by hermes--production-gq1-5dd4b47f46-9j75b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cc5c6802c90177daf2e72a0cddb1eb66; Tue, 21 Jan 2025 20:33:40 +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: <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> Date: Tue, 21 Jan 2025 12:33:28 -0800 Cc: freebsd-arm@freebsd.org, Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> 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> To: FUKAUMI Naoki X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Queue-Id: 4YczST3LcTz3ky7 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:36647, ipnet:98.137.64.0/20, country:US] On Jan 21, 2025, at 12:10, FUKAUMI Naoki wrote: > Hi Mark, Hello FUKAUMI. > thank you very much for your help. >=20 > 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, >>>=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. >=20 > 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. > = https://lists.freebsd.org/archives/freebsd-arm/2025-January/004464.html >=20 > Btw I'm thinking SPCR is really needed... >=20 > Best regards, >=20 > -- > FUKAUMI Naoki > Radxa Computer (Shenzhen) Co., Ltd. >=20 >>> 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