From nobody Sun Feb 04 08:09:16 2024 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 4TSMcH4GD8z59HjC for ; Sun, 4 Feb 2024 08:09:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4TSMcG4j3xz3xLS for ; Sun, 4 Feb 2024 08:09:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NyQ41Myp; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707034172; bh=7ShX3SA1OIKcGQTYy3Dvd+zBeu7EQdGa/K9q4NH0/6g=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=NyQ41MypwWLRoVf6zRBNSTckFVqzu7CU11+ZLcl8sX94VigwIUfYrSOLRLO1vrzUxw9q0oVIMUszbmSdozT7b4Q6g5Mh2ihIWxoczYNpqmQI0MQVRn/nTxTpAdoa4y1Vk8WXIdkNPjYKhwhm/7HdTgIOzyWFDfO5qmmWFHJQKzT4wClfUJ2mpt7NORjjxgjoJo/G4jTG+YROonmLrWWQIM1z/6tmlhlEZaKxym956qbY/3+NFjZ/XttTQNXD0EFsku83altSSXTXwjdWgZtsHVfv7BQoyxTsfD0c9A2IIXuobVgfcjau2ytOGD94JWLdvUzC84S8LtsZIKq1mcrwfA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707034172; bh=T0v+rMNdlAWDDWokvNfth7DIsTXcOvB/GCbDPyqLm3S=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=avdulVFeMu72eUUEnwCQtrSWs8cD2oSq4yQzv7IEJO8ugr1kSkqwU/73xpNFR4byWiS68a5l3tgV1e2c87s9H6EJs6mkhX3eiQNWKl2oLMrKQHRGruBXcHS5lKeWAO4h3mZ3/P7W7VizwxJfAYWXRv8BLBOhR2ZWa3kErbnXwEGZ5EJiCQVPp3Kg4evGgk5+Z+MLHFmY0YCe97cNADeeu3JCQ5a7BlBmGdZUpeCEqX+MX2xFP94PWn+WFL8RHdkkOj5fuBPsfo9RiDZuhBJPp5NA2RszS/43qeA0JClM3tmC8wskXNUngDdRz84sByeR2rpGclqQaNi2cMz2z3vIog== X-YMail-OSG: EmlDk_0VM1leZ19nNM6US8NZdRiTLsV8OFmpbc2Am_H6gSrngSrdM3v8IsEYv1F nMtikn7tjy.v.pKaUP7BjDBLB_unJcsDXsZX3kDNKRbwTPE7lGg337g1AoilvXhzMGzhEDqCDYXo DDHW9m3BXAD.xzdMv94GwNshwZPftuTfmgJJPlYJBxb9SupiwtjLWyEoy4vWES6LnTYxH7kr6Mrw AG8oJh8mGrCs6yu4RkcAT.F8qWrLZAkB59Via9u1FGZ8rstwdAa9philnwWO7g8PFxFEahJb8kJr EjWxhIJ0x7n2_bZAe7uX95_TBXm0jj0gbfJf5qICJY1injtHJuRrPGFsWAkDGzxXrEdgXSxKGi5l J6sOPZr2WBwTABg6Y_yy4B3mLnhRBtUFehv9OcTjUw7tCGoEQVDBGdrOmLVpk_.QX2vtdsfVpuy1 xvToJoZ56EYdhIuVrYBqMYtLG_fMNAKKOjFaIrhtJXg0kYPK6fjGEMPioj2hw_00Js_C.NKvB6tV zQpms9thregJLho3tkDq_8_mEjEZsojjO3XI2Dy.UZ.XT1psfpkJy2gW9CqcMsABz7W7Oj6XBeKD q62jPG1V7NfI5592zvxdcDeXDHOZZMjFY2hiMoYgVqSDXL4t_aZrlc7t_ZWAD4vbKs99a8r8eN.H 5MjHgLZ.9kq3b8nbHgb55tcPEbNrTilG6Cw9zkv78VAgI05HhN0w_oNFtMzF8owDK1EKlRBVeQ_6 Ag1_lAUxT6rGyAaLTirVYxC_wxwo.FNeEnaVwO8NM4lp33jLk.eyUT7btyJk959g0dtOsU53zbs6 bJXMNbKdpsIap5FtEV5C1PbbfvzZfpWcbiEUcU8p2Ofg8epBepr4CoAdvkcC1IPKauA_rAa.abN2 aIYfId.24VGoocRV4bET_eOcOCz77VkZrUx38WGmmMvKqJxnarmnxZnO7rHtyRKK_F8WYREeCPac F0CDjBrnwCbfAGlxHRSE5uQBj2YJWIcFCrPDupsdHvVPMqJmmz1uwMAe49FR7AufYMKNRWXDP6aN XwVITOfVOaG6GduRxJWNmaHKXSzj9pNAIQgomkSbHSfAweJOH_UQSd2bZAIl0HbayxIlQvdgZ4.b va.tdWrJqaHbUo65RvVIszkvCzQi1uiqBxGoJnxnrY5XzFHBkd9IQuUUQZILblPKuY17hApEYcsb jNfO2.slf2a5pVfsR4XVvGQdTV_mhz1Z6ni3nBXPkNBshfMPyZHFZWgnB2CRnlYbAYKE675ENsKX cnn1G6WiTNgPiYcMf0WDoA7uDDnRwd.54JSIL1x1Xc70XmoGdngzLTcomGPIKKBLozRgkrJA.DSj vGB73eo2zR1VTIfAULxxQfnGNfMixnh6IK_qkl4AzJHigFgCgfC9j0ncLYRoyV3eb90phXgZ50BB SX4BqYqKC2MDGNgj5cTyICs5gZpcX19hmQu4grSvu2h7B9g0kmJl4Gnpwq95rPsGabbnDbvWfHIj cotOGEtqVQetiYDpq9qtb4q_drKEVq.lJH7S8mEbbXY816pKPSpwxnYwRL8AZGiW3QlM.LA9Sejv WNWGhzbXPn3SuuaJJyaJmT4M595uKAU_VtW_DYQungHfs8efha5YOOBZMBOtMwpDy_Tnrz3DZMeo KAqf5ot0QCbYhi_7zb1w3fNhfVN0RoeN8evsrP27EbfHleR0fKAiz5rweRpvpy0UKrxK6GE.eGIV Vx1ZposGsY7jInTB39k2VBKxTKHQjKl9KntplzuS6C63DOkmDvXrpLD8n.1JZ0wiPcnWDbreeE7x Ust0g8ykZgPqMSbaLYBGR_j2_9CnS_xcBUd1oNGty3D7BXy1P.nXm5p5MG8x9EqMk7g1VY9vCfWd 7wlQl8K70U29bF83v9Krkrsc2a1WlxSUbjBSJqDBNwabCcFczCUSjTk730NTmmsnMPmtgJM8IpuP U0BIyXSyNuXvnp2UhFJMHyTIQ3Y4nTY5M1H11DCdF__QmP2okx_XWqo0OsTleUqA8EzBhFNvCWfl A83LTTDh1xPMwpjvSjoCKd7ZbJfXHqUFwsnGRkmqYVWOHTvgJ.3eLIZbUgs43v.XcgPeo.JoEh62 Bx0IUm3hgFiRqNU27B1lokmfCSt2dtPbNG_eKt5iHF.tl8WtI6LNwyfptxmIEk2Ir3DAx6XJNqDA by3IYtvR8w373ietqOFw_QcdCLqiFN6XnsYSV_B8EeNmDF0S0KULdjKg7QX.h0h.UAKGljn3Qnxf 7GCfl9bOzUied7O.koU3w0hTIy3tjwRzodb.WU6YQDrtDmZ9UwWM9JADAv92nhx0WR7JB0r4fo5A - X-Sonic-MF: X-Sonic-ID: 5def8680-56e0-4c2e-b6a7-2070d25653ce Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 4 Feb 2024 08:09:32 +0000 Received: by hermes--production-gq1-5c57879fdf-wt62k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 878e8b230ee84f819e937d613683d0ef; Sun, 04 Feb 2024 08:09:27 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 \(3774.300.61.1.2\)) Subject: Re: https://github.com/pftf/RPi4 EDK2 RPi4B booting ram_attach crash re-tried via 2024-Jan-11 snapshot, with debug.rman_debug=1 and details about what is wrong Date: Sun, 4 Feb 2024 00:09:16 -0800 References: To: Mike Karels , void , FreeBSD ARM List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; URL_IN_SUBJECT(1.00)[github.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-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)[]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[karels.net,f-m.fm,freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4TSMcG4j3xz3xLS I did some more investigation (EDK2 code and Linux handling) and then got an independent rpi4-uefi-dev "Mario" confirmation of the following about the EDK2 implementation: QUOTE It is indeed a mistake to expose it in _CRS like this, because it does not mean the same thing in the CPU's view of memory. 0x7EXXXXXX is mapped as DRAM in Arm space. END QUOTE So the FreeBSD panic/crash has exposed an error in the RPi4B EDK2 design (lack of address space identification based handling for BCM2844's (a.k.a. \_SB_.GDV0.PWM0 's) [0x7e20c000, 0x7e20c027]). That FreeBSD sees 0x7e20c000..0x7e20c027 as an ARM "Low Peripheral" System RAM address range is what EDK2 is reporting via the _CRS it uses. So the split: QUOTE splitting region in three parts: [0, 0x7e20bfff]; [0x7e20c000, 0x7e20c027]; [0x7e20c028, 0xfd57ffff] END QUOTE is following what EDK2 indicated to do for the range. But FreeBSD later interprets other material as having a range that spans the 0x28 bytes already reserved: ConventionalMemory 000040000000 000000000000 000bc000 WC WT WB which indicates no hole exists in the range. This results in the attempt: QUOTE ram0: reserving memory region: 40000000-fc000000 rman_reserve_resource_bound: request: [0x40000000, 0xfc000000], length 0xbc000000, flags 0, device ram0 . . . s->r_start (0x7e20c028) + count - 1> end (0xfc000000) no unshared regions found panic: ram_attach: resource 5 failed to attach END QUOTE So, likely, the only question is if the handling should be a panic vs. a error report with error handling that would allow continuing. (But there might not be a generally good way to set up for continuing.) It appears that Linux handles it (views it) as (quoting Mario): "Ultimately it shouldn't cause any issues, it's just reserving away a bit of usable RAM." So: no error reports, no warnings, and no rejection happen. (I've no clue if EDK2 will be updated now that the issue is publicly reported/known. But I doubt Linux will start reporting warnings or such.) Linux shows its results for the EDK2 oddity as: /sys/bus/acpi/devices/BCM2844:00/path : \_SB_.GDV0.PWM0 /proc/iomem : . . . 40000000-fbffffff : System RAM 7e20c000-7e20c027 : BCM2844:00 . . . ff20c000-ff20c027 : BCM2844:00 . . . (That last is what the valid ARM "Low Peripheral" address space range actually is for the 0x28 Bytes. The _CRS had that too. The _CRS just is inappropriate for describing addresses in a pair of address spaces with an address offset involved for going back or forth between the spaces.) === Mark Millard marklmi at yahoo.com