From nobody Tue Jan 21 16:56:18 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 4Yctdt6ckgz5lKn3 for ; Tue, 21 Jan 2025 16:56:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4Yctdt2jDKz3Nft for ; Tue, 21 Jan 2025 16:56:34 +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=1737478592; bh=vwHwapGytY6cmx1Z87fqlB3bqxNJ7ftyT42yfGWZ4KI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Lg3Dyjyg0OqIq0ZKAcfURO6G0wCgMZNg57aGQYHo0EN/kHnE942xi9wciR0OPo3BMsSni91QBpAS/4Yf8ht16Rly4yPc7kTFImNG838sRpI09+h2a192GxJGL7PCilCGqwuKzarJifRxjDVu1EO8d15Mg1KRYtIVsZAAXx9KtSTmKDZc0WPkF7HSm653WsCuKtQ51AJBiLt/ISrygD3WBcaXiZIzf88H04VHXcsOrI5uuM8FSHspHmF0mJ0VDfrRP5PXgWfQCIX8CIclJViPcryqdb35Qod4F29AagO4lFOVgY7HgaEfI0uZuY7cls9J72H+5jq4codOJX7UYcXynA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1737478592; bh=Ux+McFDZCd6sMQo2V/pKUt9SF1ikcBFeyrlaqqT6sqM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jWXDHmfFfNce5QWckvMW3XekgO6h/QXVbe+jrs16dfq2+DasXhOfnwXhdfMKE2+BR9taU+r2pHNHZFj9ssG0IzE/gHylCyL5kHq2VVrvRZtZ485Cq4ebmxnshTR2p/Z+23ocbUoAmo3kVTSNmqXTBTfepqmOWH8y8kjkOZZ93xiQnwecWOKEX3i5sTfg9lz9GusyrjxM4rJry1z9Fz7LHlP0ALMVd/aTbXRXcBoNpI+SXdTcto/xYjvFJCpFKhuFaV6k5xy8xbO80A6OC+I4bMEAlSOF7tIcXLq7u4nJjFKyo/dwDpn0zpWmDeAISBh4vIiuXrLwiOH1zq104vNMKg== X-YMail-OSG: LRLB6vwVM1mC0DfWQAdPolgNzAN7Hkg.CvL9iG0MvcmuVqS_O99zvRUyJhZnssw Vsc3cYH7U5jGkSiTeqYHyWlGoU.4RyWCJrxmvVsCUwraqTYkd3ADvGhoUcjwQyVFdE1rnWLY1364 __E6cJxcJv8VisKJq.OoexMOdoHe1kv04XjksXGa_AWx0wyv_vPhc3qWQ_BL1eyq3xOrHg1euB73 rv1239usuQ.k2Pn2_y0AAZf5X_MK1JqtLjnkdOmZczChMtT7kH.ZOnmZ1SAgoGmH2.24P17oeRNM T965l4LD4Ct33gIyt9yPH268vzaUt5QgZTMAmNwwxslIA1fAMCdSFUkFTcHHnJ1QgAV.KGvDZM4w tACL7Vuf2n49b6d9jZ5.8.QseZQTQEePimpizQ_XdX7zb_mumjuNWHScUkK480f0U_WGyIkv.dmE AEhTLSmJKoA2PK.LowidQV1hOC40MR2B_6FajWkbpkD7sR1YBje2CK93WIg6NscK_zuV5PstN7k2 g3hJdEsHG8hvg8RvwAwKd8QfqCZWup_A9aEqAEIU0O47EBiCKXME8MjAp9d0CzLblEtcysYb6HHM x5jVUwYKjaUG2BVBpL.dW56sZwhCbvtSqU2NhvQKgT2Ha_wFiJ2uuT1i6PsIiMDZV52tVt6wBZ59 sp2dugOGAVhuSOaw_o5RL7jVPGbT_f1_nHO6gUc_I9rVQegvPilxcIbblxXp404C.8gVmgveSFXo lNkWixqHqz8CFvPF0AICVxaJq0rbRMfIWc1UuJMVymq4H6J9N.jDwsRVzYHjshrAqSjTeRhda7Iv bySt_2Hz3yuhaNsixVIY5Rf7kFQJjoDz.UDiQ1vVQKay_yNli0JqwVbaXmUS8rOa9LN60N1_7ijs FI8aCVB8yRKz_hKhuWIUrT8vxs6JtKyQv1ogChu6iiRaNnNb6Dgzk5.XBzTIF5XHWcL1tCWUMLU3 P_eVfZ0guseGBaNJGdDIi7SFC0rXI6LNLs.G1vgI3N5Yhcb430Juv6ZHCFCC3F7uZDUtJxuUeU02 Ue0UHG3QOj.cVcK.pl9bpO.72bh8XyjbbPyvfkRYwpCnS2OEVwiripdMymH8RzBOC7yB13lTroaG aCDNKuOEqpICVrvT6WBRFDb4F7livxgC7TjcJq5mEBu.rcCmESnOzmpiJwJpwktoz8w38ygLFs9C as4SqlgcBIhnNB2pBDdCl..q2B38YxICrxhTHz5qZ6dH.imU2TfFEiHWmUSwMvkDSbPxLOBh2i08 gxf0BBxsve_wZMndSOMb_vMaGqyxVUFuzkxy2SzhPtHF.Xx1ZpD9Xcdb9oL1z9.7qV4123J0aRz1 8o0RSC3Pe3C7pg6ootjGRAHj5AEG3tFWwYumV6AiXGDslw2FNfmZfVjxNf0SXbn2o13MgJpj7kvx XvuTb7rNQ92lp.5uJ7vNLTTA0UHsueXF7bF13hsqyw.x3bTjx0tcVlDCdLUDE4HGfnsPb4Okce9Q FT3rypjH9hj_LMhLYI45HGQRMdc7GTLdbOqy65zFmzec5wXc9cwyZqJ72M.A0o01n0w1Bj3V1m2i QrAnvCwFDNYZoospeKYCvSHZlECHtrqcXGRDPxHFZM4e7F2UeBLBJaIiswYmcOYw3GSW0h5uToET ctpDG1xVBUj2bpsREonzse9nmR_.88NJEm9hVieZuk6awqzqWjXdu6Av2d.p2yR7kln348ilym3M FoW_WEfqz.qsOQUa6dQqmb58rELWRSg5o.NqWhfZuEEMiMkBXqARKlrxMG7mktIQ_MzUAXtZN3SL 6RVPsfTqsLv4N0KRpE5GOEaEFQChwYCTLVeSYdK0WVBQKcuZSUyMP54cujhZfdppotdKdzoty0XX 16YlvM7WJoX2g86SubHM0GPgEAPpvxEPS2nY0OSl.Yhzk1nIxYIwp.OMV981ZrGAwZVUWbbKON_d XX83bWJifBtyCSc1KfIHL9rHXa3juscE.piiqsS7.9nm4CGQA05Jg49NMWDIY27bV1Y_rpsv0FB7 gt0BA.pb9IO974BhxPXMw7mLTHEFwvfjnb2kNxAIP6sxQXVppcz810UNPj_gtSdYkGsD.wf3kFRo bi9OPaQl_nGTzffQIH6bOPyIQ7UDQEMtyFNUaVsEI77BgKipgONeHzyTpqlwpOkhdy7IvR_6AxQf UaAxwFKKt0aMHKCU68cZPholbQvBz0cByXEjK9wLiRG5Q7nquTtJ__lWeFei3I8kfD6A4mmgMdCY YxJLx9eFZj6x3bGBrrAtmjVE_Vl3QlrZAw86qdlKJC.KnODVz8a2l7lkMQ6pCZ8lxy8h5n0Magir XCzVxDRL93Q-- X-Sonic-MF: X-Sonic-ID: 108e09fd-972f-4112-9e92-b1919ee4ace2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Jan 2025 16:56:32 +0000 Received: by hermes--production-gq1-5dd4b47f46-whghm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ff8b0101a334a1ff5873093e28de20de; Tue, 21 Jan 2025 16:56:30 +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: Date: Tue, 21 Jan 2025 08:56:18 -0800 Cc: freebsd-arm@freebsd.org, Andrew Turner Content-Transfer-Encoding: quoted-printable Message-Id: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> References: <087C4A9F-288B-40EA-BE1B-ACFD32C86DF2@yahoo.com> <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> To: FUKAUMI Naoki X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Queue-Id: 4Yctdt2jDKz3Nft 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] 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. >>>=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 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. 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= =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