From nobody Mon Jun 8 19:16:32 2026 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 4gZ1xQ6xxzz6gZlh for ; Mon, 08 Jun 2026 19:16:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4gZ1xM1r33z3V3W for ; Mon, 08 Jun 2026 19:16:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jqQuAVg8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1780946194; bh=tQzpj/z+bMAGrrDp1uD07k3YCf+sZGI0TI44Sf6Tlq0=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject:Reply-To; b=jqQuAVg8mpaBSjBJRszn2WBAaEFAdFeV1jqdvLc/j7VqcrhfuSQP5fabmki1kgzp4HUY/ikZP/eXF+ty5s015ZMgVYws8ibo/kJlzwQ+6kqw11n+6WnbWS/blSN0M+SBqyYPgkqGkmwLt/HYRX6iYfavlMkVeX2pk+JUY39J28tLP4WHqcrZiNj/0oFefmAqnYsxdlPlhmOM51tDYH44XHJd1k0GomRVqwXbH6VH3uKOUHx4azrkKkyR01+wLxzUtkBrknR443krwnREJ8+nucuJ+eQjoSwoh+Bygo87R1U732Tcs2VpCqbUKDUUro5X9oEjRxU5x2ChSG8PFEPEGQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1780946194; bh=i5RNy7jqvnV9dfEVOXXx1d9dfxUifk2oqn+wQhunZCc=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=XiYe5coeoSxhQ0YnP64txFhkkP/yA0eskb/dJc4FEF7BoHhGAYNkt6M8FpWfQrxmUoKiW62COKYwp7PFY7hpUSQ/43V2Hs5JAIvWrzfTPasvFArNmLmR/VMpRa5cAfmpMi+pEudhlmOkAs9an6zVSwr/8v6GSUyYSQonz6zP84Ir4gcVg6ncE8RFogdvOMXDb8N6sH+9cUpk+Ra/RHxiZLmMO3pUKNd3fcQJirM9Dfgbl/nVvDtdSgvLOjsLG+nKdOEtgrGWS1Freh+YHaw8rXZeBLbxAHNcLNU5yeDRejfqCyaHXeS4DOrqU1eLLh8O8m99Rn8JlI2E9tjrWdw9kA== X-YMail-OSG: GmHoilcVM1nlsgxoKD5740HF3XHwjyB3deo8Sb1CUoxPpAy3QAJYH9qUu1yjUyO D_P78mXoka9CoKlL5cp35UdMKCJSBu85ivsrdOZm9vMe200qfRIfrGlM7VU2N_bpa1zkhypsNEDP H_BoYjAM8m6pTDPq40MN2680avSiqbsrnEmmXLw1Av.0tq55cFkfA6cpprvymTiw.qbuhAG1KDHI lGimPk6OZcLySmXVQthCgweXXoUAwjunwhJ0.acapCSnzcqFoHJsb6LHiSquxYdE2ZRMVvqGmJbC d15BGGQFU2j7ZelzkzStAlMEF.K0m6kxtod.Y8SYoDRifd1KPY_OeEAoKe8rvx9KnXlxeW_4yW0c 1cqlhKKOaj1KzdBK3z9yTxI.Itm2Syo0nv3swjfzzYzdqG.ZvMMbBsVhdUBxb.cnjzQ._a002ID1 MQ8zKpWHey3jnhQiE2FCoDWeD6qpeiFLwYuCsja9VpKwoxWqmqxQGg7tPcpJWWVwxPyzYGoOsHDC 336TQkcqE8tVB6dcGneHwcB_vc5E4TRoGmiDQP4KWXuxkxlOj5RUaRf0Ejuovz88_guUqK7nLc_c R_V1ivqkUuoU0owJXlxgVn8rXuZJ6LqibHWf5vkAWB3XFpf7_w91wGXWHBKj2aCFrLrvS0f0yK4S TwOudliQE5oaiIIFK1L4ycGXJx3kmgk05J4o6RM5oJB_CYn7kv4QEb0qojaKRebvY9Q6yWpfQLuq Eytc8LWoyVgvnWmd6PCI9268VktUUDq5OgTzEbsPAVz0PfWj44R84ACiIDuPi1McHGhv.scpkFq0 VJWDwaFDpkVlj.erY2J2tJBdWKE88fdteL7bNbfEtuDnzRyDXgLlBuEFeDdpNAcF8XnzC7uofqR6 5ZNXIQ3Aas9UoUzgGZKNofUQ5AcsVPV11LY6mY93djp23EnqhkyOYxDoNtQkDrx5JK3FIdFFEI1m aJZ4DN6Vj7kYHf2JVI4y74ebQKcnkXbawolV9_r_K6S6kUflxE6hdIGeX6WzRU1PX1Wv4bb9HedM z.WHpB4VWs4JLDh.ZgYbyTSHuKY2s5QDZtLJOXRxRU1R05IZUBmsqiFM6XY2Xh1AH_bazrx35hD5 8SIGsaKwHi2iK8xdRp5SwtiTBqBXFqgvIwUL0qP9BnOgGYO.ItW79oWMfDoE7LVPDqB_tYO77Nto xH74Uc2FcfrzVYIp6mrXsnEj.tUu7w.u.s.1qpuuri9AkRbH341J0tA6GmINLbN1Io7daYGY5KuG 5ThW8z3v6C0DqD.sDfMnT2AVlTewg211oPIwAvecseqSM74PGpdF4aAItr1_vHVq.zelsMLudNhh 9iXIacpQfsPpfBSG96wFn_whoJ1iC6bBcEfTEvDT3W9N3cs3NXL6d9dbmEjLsmUVDF.AbJbd0OG6 y.wyERR1_zlt.rv7zKcu_qJNrQ7OGdapSF4r2RiAGTim9TlhSjArz7RwELdsyjL4i1bMVYCAPXn2 HWhsDIaqGmeXyS9s8dEZ6lymQy4mypq1u1aN.7zz0KGq.joYBI7mTTOjs4JgxQ5EUWE63FgdUR5i gAms0A26gug4D.gVBqjO8rIojf5jI7a0HkConOlxeGnkMDaeI.FK8XULyjdBWpOOOtWSYB8S9gtg yU8sorb1xvvK1fBr5ey_if7MohG0kbiuzX.hXOGAe0O6uOKgzr0mWWcCY5JcGbhargjctIAeJLuB EMRMBY_EvUkyFrkDa6nYK868bhqU7VZnctEs05rjsOZeMLDWdfr8JcEAJV_6tysEnfwkPSGpjfBZ vwmvJSYl9uPL5s6XVcaEqev1aHKBAtJXrJG2HW4jW0IcuucdLbOW_gK4vvS0rIvnpeXsPvrq0Oam wtgCxK1Xeq.auNHJuRxEcg0vk5NPAEaluHxXR99pGc_PLcyFnwxpMhvmQ9.8KZ.ITVD6d7PSiISF vfX6ZK.Ks30Oob58gX1ZgtleaBoRD6f_q9ln07Yj2BNvIL4.PnxNIZiDVI6pZ4tstEKutwdo1T60 J.Yjj35tStAvxPVFwWHC93J6I1zLs8lMs8vSb17QL1khq5Rv3LStfRpEi7j7zMjImbvmRM_p_rvq 2hkhaYGv1GdvFQp0ef0f8gF9mPg0hrVGXYZcbac_d0w1oA_JJ4UK5Yn9hffIiWWYnUPslcTrkEsy d34uR6N1Zk92wY6y55gU.Nj.4sdqqAB7i_UQspii_cCMVJ5ocaWgbEhsWIr0o.IH1tXjfYHp98fB 8HFHsaOWRu9nsrMQOSDH846Sby0Arwv1wVetcWddQUgpKjyV8nNZae_qY8zZALMo2wDhS02WqywR FWRTdibPU1DKHKOX1p09csrt42eB8mbeDavayrP1DeOEMa7pF X-Sonic-MF: X-Sonic-ID: f43d9a8a-5a2f-4cfe-927e-9b8cf518a0fe Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 8 Jun 2026 19:16:34 +0000 Received: by hermes--production-gq1-7bb7df5c46-ftcbs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dcc7d70ec07a08bba0385cdbe08e3542; Mon, 08 Jun 2026 19:16:33 +0000 (UTC) Message-ID: Date: Mon, 8 Jun 2026 12:16:32 -0700 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Need testers for ALPHA RPi-5 fan control, GE NIC, WiFi drivers for FreeBSD-CURRENT From: Mark Millard To: Jeremy McMillan , "freebsd-arm@freebsd.org" References: <9YCJYFriU7X2_37aSWQTo5jJSmaf46t827hI4KjmCLaCFNGbgMj4MxRzc4-sUSig2RolfvNOWikCxYuWL3YJfqMgw-5d4FDjG8xtnRGJyMY=@pm.me> <9a96d0ee-29bc-49ae-ba05-c3e6291f6385@yahoo.com> <20ff2ca4-52c1-4070-a4d8-bde3b1df9a2c@yahoo.com> Content-Language: en-US In-Reply-To: <20ff2ca4-52c1-4070-a4d8-bde3b1df9a2c@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25918 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.69)[-0.692]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; 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)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147: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)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gZ1xM1r33z3V3W On 6/5/26 14:22, Mark Millard wrote: > On 6/5/26 12:46, Mark Millard wrote: >> On 6/4/26 20:56, Mark Millard wrote: >>> On 6/4/26 20:12, Mark Millard wrote: >>>> On 6/4/26 19:39, Mark Millard wrote: >>>>> On 5/29/26 17:42, Jeremy McMillan wrote: >>>>>> >>>>>> >>>>>> If anyone has a Raspberry Pi 5 that's not dedicated to anything >>>>>> important, I'd appreciate some help testing this: >>>>>> >>>>>> https://github.com/aphor/FreeBSD15-RPi5-modules >>>>> aphor/FreeBSD15-RPi5-modules> >>>>>> >>>>>> The README.md is up to date, but other docs in there might be stale. >>>>>> >>>>>> IDK if I should try to implement Bluetooth yet. I haven't tried using >>>>>> FreeBSD bluetooth with working known-good drivers on supported hardware, >>>>>> but when this is relatively complete I'm planning to do some bug fixing >>>>>> and performance improvements where necessary in a BETA phase, then a >>>>>> rewrite from scratch for maintainability that can be submitted to >>>>>> FreeBSD-CURRENT. I know the repo says FreeBSD15, but I'm currently >>>>>> building against FreeBSD-16-CURRENT. I've had feedback that the fan >>>>>> control works fine on FreeBSD-15. >>>>>> >>>>>> I also don't know what I should do about GPIO testing. I'd appreciate >>>>>> any pointers if other people work with RPi hardware and have any >>>>>> pointers for testing GPIO stuff. I think there's a few pins that can do >>>>>> DAC and ADC and others that can do PWM (like the ones used for the fan >>>>>> header) when programmed to different modes. I have an oscilloscope, but >>>>>> I'd like to automate testing as much as possible because my spare time >>>>>> is precious. >>>>>> >>>>>> It seems like RPi-5 will be around for a while under the current market >>>>>> conditions for the semiconductor business, and it is my hope that >>>>>> FreeBSD can deserve and get more attention and support from Broadcom and >>>>>> Raspberry Pi. Also, I have my own projects :) >>>>>> >>>>>> Thanks in advance for your attention! >>>>> >>>>> QUOTE >>>>> Add to your FreeBSD device tree (typically at >>>>> /usr/src/sys/arm64/broadcom/bcm2712-rpi-5-b.dts): >>>>> END QUOTE >>>>> >>>>> FreeBSD has never used RPi* device trees based on the ones in the >>>>> FreeBSD /usr/src/sys/ area (copied from linux mainline): only binary >>>>> ones copied directly or indirectly from the RPi* folks (the RPi* >>>>> upstream). (The sources are available.) The same is true for what the >>>>> two RPi5 EDK2's provide: *.dtb files and *.dtbo files from the RPi* >>>>> upstream, both in binary form. >>>>> >>>>> My limited understanding is that they are (were?) not the same in >>>>> various ways --but I do not know the details. >>>>> >>>>> The modern RPi5 *.dtb files include the RPi* folks RP1 description. >>>>> (I have converted the live representation of the time to text in the >>>>> past, not that I remember the details.) >>>>> >>>>> I've no clue what the consequences of mixing such might be or if use of >>>>> a device tree overlay might help avoid such questions. >>>>> >>>>> I'll also note that the RPi* firmware makes some live adjustments to >>>>> what is handed to EDK2 and EDK2 may well make more for what is handed to >>>>> the FreeBSD EFI loader. Some of that is not from overlays. >>>>> >>>>> Anyway, I was surprised at the reference to the copy of the linux >>>>> upstream *.dts . >>>>> >>>> >>>> I do still have the files from 2025-Nov-04. Looking . . . >>>> >>>> / { >>>> . . . >>>> __symbols__ { >>>> . . . >>>> pwm = "/axi/pcie@1000120000/rp1/pwm@98000"; >>>> pwm0 = "/axi/pcie@1000120000/rp1/pwm@98000"; >>>> pwm1 = "/axi/pcie@1000120000/rp1/pwm@9c000"; >>>> . . . >>>> rp1_pwm0 = "/axi/pcie@1000120000/rp1/pwm@98000"; >>>> rp1_pwm1 = "/axi/pcie@1000120000/rp1/pwm@9c000"; >>>> . . . >>>> axi { >>>> . . . >>>> pcie@1000120000 { >>>> rp1 { >>>> . . . >>>> pwm@98000 { >>>> >>>> #pwm-cells = <0x3>; >>>> assigned-clock-rates = <0x2faf080>; >>>> assigned-clocks = <0x2 0x11>; >>>> clocks = <0x2 0x11>; >>>> compatible = "raspberrypi,rp1-pwm"; >>>> phandle = <0xb9>; >>>> reg = <0xc0 0x40098000 0x0 0x100>; >>>> status = "disabled"; >>>> }; >>>> pwm@9c000 { >>>> >>>> #pwm-cells = <0x3>; >>>> assigned-clock-rates = <0x2faf080>; >>>> assigned-clocks = <0x2 0x12>; >>>> clocks = <0x2 0x12>; >>>> compatible = "raspberrypi,rp1-pwm"; >>>> phandle = <0x61>; >>>> pinctrl-0 = <0x39>; >>>> pinctrl-names = "default"; >>>> reg = <0xc0 0x4009c000 0x0 0x100>; >>>> status = "okay"; >>>> }; >>>> . . . >>>> cooling_fan { >>>> compatible = "pwm-fan"; >>>> pwms = <0x61 0x3 0xa25e 0x1>; >>>> }; >>> >>> cooling_fan was from a grep output. More complete: >>> >>> cooling_fan { >>> >>> #cooling-cells = <0x2>; >>> compatible = "pwm-fan"; >>> cooling-levels = <0x0 0x4b 0x7d 0xaf 0xfa>; >>> cooling-max-state = <0x3>; >>> cooling-min-state = <0x0>; >>> phandle = <0x54>; >>> pwms = <0x61 0x3 0xa25e 0x1>; >>> rpm-offset = <0x3c>; >>> rpm-regmap = <0x61>; >>> status = "okay"; >>> }; >>> >>>> . . . >>>> >>>> Now I just have to remember how I generated that file from hw.fdt so I >>>> can see what modern looks like. >>>> >>> >>> And the only differences were (summarized as what had a different value, >>> not what the value was, using indentation for nesting): >>> >>> memreserve >>> choosen >>> bootargs, kaslr-seed, log, rng-seed >>> NEW: rpi-machine-id, rpi-min-boot-ver, rpi-sdram-size-gbit >>> bootloader >>> build-timestamp, count, update-timestamp, version >>> power >>> NEW: sd_overcurrent >>> reserved-memory >>> nvram@0 >>> reg >>> >>> Nothing else was different. >>> >>> >>> The magic command was (given that EDK2 was exporting a DeviceTree as well): >>> >>> # sysctl -b hw.fdt.dtb | dtc -I dtb -s > ~/RPi5B-D0-live-newer.dts > > I switched to the *.dtb's ( and the *.dtbo ) from the RaspiOS64 (my > abbr.) I used to upgrade the EEPROM contents. It shows a lot more > differences to prior ones that I'd looked at. > > I'll note some. The '-' lines are ~/RPi5B-D0-live-newer.dts and the '+' > lines are ~/RPi5B-D0-live-newer2.dts (the most recent). But first, I used: > > # diff -u ~/RPi5B-D0-live-newer*.dts \ > | grep '^[-+]' \ > | grep -v 'phandle = ' > > which removed the lots of changed phandle value lines. > > I did add some blank lines to separate somethings for clarity. I also > added comments of my own, somethings just naming something not detailed. > > The first difference is the overall: > > - #size-cells = <0x1>; > + #size-cells = <0x2>; > > There are now eee, eth_max_speed, and watchdog in: __overrides__ > > There is now a watchdog in: __symbols__ > > - bsc_irq = "/soc@107c000000/intc@7d508380"; > + bsc_irq = "/soc@107c000000/interrupt-controller@7d508380"; > > (So changes in that naming convention.) > > - hdmi0 = "/soc@107c000000/hdmi@7ef00700"; > - hdmi1 = "/soc@107c000000/hdmi@7ef05700"; > + hdmi0 = "/soc@107c000000/hdmi@7c701400"; > + hdmi1 = "/soc@107c000000/hdmi@7c706400"; > > - l2_cache_l0 = "/cpus/cpu@0/l2-cache-l0"; > - l2_cache_l1 = "/cpus/cpu@1/l2-cache-l1"; > - l2_cache_l2 = "/cpus/cpu@2/l2-cache-l2"; > - l2_cache_l3 = "/cpus/cpu@3/l2-cache-l3"; > + l2_cache_l0 = "/cpus/cpu@0/l2-cache"; > + l2_cache_l1 = "/cpus/cpu@1/l2-cache"; > + l2_cache_l2 = "/cpus/cpu@2/l2-cache"; > + l2_cache_l3 = "/cpus/cpu@3/l2-cache"; > > (So: another naming change.) > > - local_intc = > "/soc@107c000000/interrupt-controller@7cd00000"; > > (So something deleted.) > > - main_irq = "/soc@107c000000/intc@7d508400"; > + main_irq = "/soc@107c000000/interrupt-controller@7d508400"; > > + watchdog = "/soc@107c000000/watchdog@7d200000"; > + watchdog = "/soc@107c000000/watchdog@7d200000"; > > The 1st is in: __symbols__ > The 2nd is in: aliases > > + aperture-size = <0x1 0x0>; > > That new thing is in: iommu@5100 > > - snps,axi-max-burst-len = <0x4>; > + snps,axi-max-burst-len = <0x8 > 0x8 0x4 0x4 0x4 0x4 0x4 0x4>; > > + snps,chan-flags = <0x100 0x100 > 0x0 0x0 0x0 0x0 0x0 0x0>; > > - dmas = <0x2b 0x38 0x2b 0x39 0x2b > 0x3a 0x2b 0x3b 0x2b 0x3c 0x2b 0x3d 0x2b 0x3e 0x2b 0x3f>; > + dmas = <0x2b 0x138 0x2b 0x139 > 0x2b 0x13a 0x2b 0x13b 0x2b 0x13c 0x2b 0x13d 0x2b 0x13e 0x2b 0x13f>; > > bootargs has (old then new): > nvme.max_host_mem_size_mb=0 vs. nvme.max_host_mem_size_mb=32 > > - l2-cache-l0 { > + l2-cache { > - l2-cache-l1 { > + l2-cache { > - l2-cache-l2 { > + l2-cache { > - l2-cache-l3 { > + l2-cache { > - reg = <0x10 0x7c580000 0x1a000>; > + reg = <0x10 0x7c580000 0x0 0x1a000>; > - #size-cells = <0x1>; > + #size-cells = <0x2>; > - reg = <0x0 0x0 0x80000>; > + reg = <0x0 0x0 0x0 0x80000>; > - alloc-ranges = <0x0 0x0 0x40000000>; > + alloc-ranges = <0x0 0x0 0x0 0x40000000>; > - size = <0x4000000>; > + size = <0x0 0x4000000>; > - reg = <0x0 0x3fd233a0 0x38>; > + reg = <0x0 0x3fd233a0 0x0 0x38>; > - reg = <0x0 0x0 0x0>; > + reg = <0x0 0x0 0x0 0x0>; > - hdmi@7ef00700 { > + hdmi@7c701400 { > - hdmi@7ef05700 { > + hdmi@7c706400 { > > - intc@7d508380 { > - > - #interrupt-cells = <0x1>; > - compatible = "brcm,bcm7271-l2-intc"; > - interrupt-controller; > - interrupts = <0x0 0xf2 0x4>; > - reg = <0x7d508380 0x10>; > - }; > > - intc@7d508400 { > - > - #interrupt-cells = <0x1>; > - compatible = "brcm,bcm7271-l2-intc"; > - interrupt-controller; > - interrupts = <0x0 0xf4 0x4>; > - reg = <0x7d508400 0x10>; > - }; > > - interrupt-controller@7cd00000 { > + interrupt-controller@7d508380 { > - compatible = "brcm,bcm2836-l1-intc"; > - reg = <0x7cd00000 0x100>; > + #interrupt-cells = <0x1>; > > The below starts inside : interrupt-controller@7d508380 > > + compatible = "brcm,bcm7271-l2-intc"; > + interrupt-controller; > + interrupts = <0x0 0xf2 0x4>; > + reg = <0x7d508380 0x10>; > > + interrupt-controller@7d508400 { > + > + #interrupt-cells = <0x1>; > + compatible = "brcm,bcm7271-l2-intc"; > + interrupt-controller; > + interrupts = <0x0 0xf4 0x4>; > + reg = <0x7d508400 0x10>; > + }; > > + #address-cells = <0x0>; > > The above line was inside: interrupt-controller@7fff9000 > > The below was inside: serial@7d001000 > > - compatible = "arm,pl011", "arm,primecell"; > + compatible = "arm,pl011-axi", "arm,pl011", > "arm,primecell"; Below I contrast the bcm2712-rpi-5-b.dtb file source generated to the live fdt's FreeBSD OS reported source, with the bcm2712-rpi-5-b.dtb source obtained via: # cat /mnt/bcm2712-rpi-5-b.dtb | dtc -I dtb -s > ~/RPi5B-D0-dtb-newer2.dts bcm2712-rpi-5-b.dtb material is "-" and live is "+" below. Note: The memreserve range reference to 0x3fc00000 below later shows up under vc_mem as well. . . . - model = "Raspberry Pi 5"; . . . + memreserve = <0x3fc00000 0x400000>; + model = "Raspberry Pi 5 Model B Rev 1.1"; + serial-number = REDACTED; . . . dma@10600 { #dma-cells = <0x1>; - brcm,dma-channel-mask = <0x7c0>; + brcm,dma-channel-mask = <0xf80>; compatible = "brcm,bcm2712-dma"; + dma-channel-mask = <0xf80>; interrupt-names = "dma6", "dma7", "dma8", "dma9", "dma10", "dma11"; interrupts = <0x0 0x56 0x4 0x0 0x57 0x4 0x0 0x58 0x4 0x0 0x59 0x4 0x0 0x5a 0x4 0x0 0x5b 0x4>; phandle = <0x16>; reg = <0x10 0x10600 0x0 0x600>; }; . . . There are things like local-mac-address that I'll not give details for. Also, later, local-bd-address for bluetooth. . . . pcie@1000110000 { #address-cells = <0x3>; #interrupt-cells = <0x1>; #size-cells = <0x2>; brcm,clkreq-mode = "safe"; brcm,fifo-qos-map = <0x3030303>; compatible = "brcm,bcm2712-pcie"; device_type = "pci"; dma-ranges = <0x3000000 0x10 0x0 0x0 0x0 0x10 0x0 0x3000000 0xff 0xfffff000 0x10 0x131000 0x0 0x1000>; interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0xdb 0x4 0x0 0x0 0x0 0x2 0x1 0x0 0xdc 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0xdd 0x4 0x0 0x0 0x0 0x4 0x1 0x0 0xde 0x4>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-names = "pcie", "msi"; interrupt-parent = <0x1>; interrupts = <0x0 0xdf 0x4 0x0 0xe0 0x4>; linux,pci-domain = <0x1>; max-link-speed = <0x2>; msi-controller; msi-parent = <0x26>; num-lanes = <0x1>; phandle = <0x67>; ranges = <0x2000000 0x0 0x80000000 0x1b 0x80000000 0x0 0x80000000 0x43000000 0x4 0x0 0x18 0x0 0x3 0x80000000>; reg = <0x10 0x110000 0x0 0x9310>; reset-names = "rescal", "bridge"; resets = <0x23 0x24 0x2b>; - status = "disabled"; + status = "okay"; }; . . . pwm@9c000 { #pwm-cells = <0x3>; assigned-clock-rates = <0x2faf080>; assigned-clocks = <0x2 0x12>; clocks = <0x2 0x12>; compatible = "raspberrypi,rp1-pwm"; phandle = <0x61>; pinctrl-0 = <0x39>; pinctrl-names = "default"; reg = <0xc0 0x4009c000 0x0 0x100>; - status = "disabled"; + status = "okay"; }; . . . + vc_mem { + + reg = <0x3fc00000 0x40000000 0xc0000000>; + }; . . . bootargs is different NEW: fixup_applied, kasle-seed, log, os_prefix, overlay_prefix, and a bunch more, including bootloader and power. . . . clk-uart { #clock-cells = <0x0>; - clock-frequency = <0x8ca000>; + clock-frequency = <0x2a30000>; clock-output-names = "uart-clock"; compatible = "fixed-clock"; phandle = <0xe>; }; . . . cooling_fan { #cooling-cells = <0x2>; compatible = "pwm-fan"; cooling-levels = <0x0 0x4b 0x7d 0xaf 0xfa>; cooling-max-state = <0x3>; cooling-min-state = <0x0>; phandle = <0x54>; pwms = <0x61 0x3 0xa25e 0x1>; rpm-offset = <0x3c>; rpm-regmap = <0x61>; - status = "disabled"; + status = "okay"; }; . . . - memory@0 { - - device_type = "memory"; - reg = <0x0 0x0 0x0 0x28000000>; - }; . . . nvram@0 reg and status are different. . . . gpio@7d517c00 { #gpio-cells = <0x2>; - brcm,gpio-bank-widths = <0x11 0x6>; + brcm,gpio-bank-widths = <0xf 0x6>; . . . hdmi@7c701400 { clock-names = "hdmi", "bvb", "audio", "cec"; clocks = <0x17 0xd 0x17 0xe 0x13 0x0 0x18>; compatible = "brcm,bcm2712-hdmi0"; ddc = <0x15>; dma-names = "audio-rx"; - dmas = <0x16 0x41fa000a>; + dmas = <0x16 0x41fa000c>; . . . hdmi@7c706400 { clock-names = "hdmi", "bvb", "audio", "cec"; clocks = <0x17 0xd 0x17 0xe 0x13 0x1 0x18>; compatible = "brcm,bcm2712-hdmi1"; ddc = <0x19>; dma-names = "audio-rx"; - dmas = <0x16 0x41fa0011>; + dmas = <0x16 0x41fa000d>; . . . pinctrl@7d504100 { - compatible = "brcm,bcm2712c0-pinctrl"; + compatible = "brcm,bcm2712d0-pinctrl"; phandle = <0x8f>; - reg = <0x7d504100 0x30>; + reg = <0x7d504100 0x20>; . . . pinctrl@7d510700 { - compatible = "brcm,bcm2712c0-aon-pinctrl"; + compatible = "brcm,bcm2712d0-aon-pinctrl"; phandle = <0x91>; - reg = <0x7d510700 0x20>; + reg = <0x7d510700 0x1c>; . . . serial@7d001000 { arm,primecell-periphid = <0x341011>; clock-names = "uartclk", "apb_pclk"; clocks = <0xe 0xf>; compatible = "arm,pl011-axi", "arm,pl011", "arm,primecell"; - interrupts = <0x0 0x79 0x4>; + interrupts = <0x0 0x78 0x4>; phandle = <0x85>; reg = <0x7d001000 0x200>; status = "okay"; }; . . . spi@7d004000 { #address-cells = <0x1>; #size-cells = <0x0>; clocks = <0xf>; compatible = "brcm,bcm2835-spi"; cs-gpios = <0x1b 0x1 0x1>; dma-names = "tx", "rx"; - dmas = <0x16 0x6 0x16 0x7>; + dmas = <0x16 0x3 0x16 0x4>; . . . + system { + + linux,revision = <0xe04171>; + linux,serial = REDACTED; + }; . . . That was all. The overlay's .dtbo file source generated is probably just easier to list to indicate what is changed by it for C0 stepping to the D0 stepping: # less ~/RPi5B-D0-dtbo-newer2.dts /dts-v1/; / { compatible = "brcm,bcm2712"; __fixups__ { dma40 = "/fragment@5/__overlay__:dmas:0", "/fragment@5/__overlay__:dmas:8", "/fragment@6/__overlay__:dmas:0", "/fragment@7/__overlay__:dmas:0"; gio = "/fragment@0:target:0"; gio_aon = "/fragment@1:target:0"; hdmi0 = "/fragment@6:target:0"; hdmi1 = "/fragment@7:target:0"; pinctrl = "/fragment@2:target:0"; pinctrl_aon = "/fragment@3:target:0"; spi10 = "/fragment@5:target:0"; uart10 = "/fragment@4:target:0"; }; fragment@0 { target = <0xffffffff>; __overlay__ { brcm,gpio-bank-widths = <0x20 0x4>; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { brcm,gpio-bank-widths = <0xf 0x6>; }; }; fragment@2 { target = <0xffffffff>; __overlay__ { compatible = "brcm,bcm2712d0-pinctrl"; reg = <0x7d504100 0x20>; }; }; fragment@3 { target = <0xffffffff>; __overlay__ { compatible = "brcm,bcm2712d0-aon-pinctrl"; reg = <0x7d510700 0x1c>; }; }; fragment@4 { target = <0xffffffff>; __overlay__ { interrupts = <0x0 0x78 0x4>; }; }; fragment@5 { target = <0xffffffff>; __overlay__ { dmas = <0xffffffff 0x3 0xffffffff 0x4>; }; }; fragment@6 { target = <0xffffffff>; __overlay__ { dmas = <0xffffffff 0x41fa000c>; }; }; fragment@7 { target = <0xffffffff>; __overlay__ { dmas = <0xffffffff 0x41fa000d>; }; }; }; > > >>> >>> >> >> I found (from 2026-Mar-20): >> >> >> >> that is explicit about the RPi* folks bcm2712d0-rpi-5-b.dts file that >> they provided (and the matching *.dtb that they provide): >> >> "The discussion in the PR that added bcm2712d0-rpi-5-b.dts >> ( https://github.com/raspberrypi/linux/pull/5847 ) shows that it was >> really only there as an example for the upstream kernel devs. It's not >> been kept in line with the main Pi 5 dts. The upstream D0 support >> doesn't have all the tweaks included in the overlay, but it's been >> enough for them up to now." >> >> There is also this earlier in exchange: >> >> "The downstream kernel uses a modified bcm2712-rpi-5-b.dts for C0, with >> the firmware applying the bcm2712d0 overlay as needed. The upstream >> kernels uses bcm2712-rpi-5-b.dts (unmodified) for C0, and bcm2712-d- >> rpi-5-b.dts for D0." >> >> > > -- === Mark Millard marklmi at yahoo.com From nobody Tue Jun 9 17:20:47 2026 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 4gZbKQ3KsTz6gKJb for ; Tue, 09 Jun 2026 17:20:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.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 4gZbKN42l7z4NQy for ; Tue, 09 Jun 2026 17:20:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AUuroUWo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1781025652; bh=AInpMCofnb5DvBt5JdyclapxjbUiUPOoi1FSb068fAE=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject:Reply-To; b=AUuroUWoz5X2Kkz43ivat50axkuD/BKTUHW3jKFiULSyI7yNlw/UCMh1zw/cME0iVl12PKw7xT7jhoxnP+d2sqK95XpzLyTC0oxB3ijFWb+NEuLMLZKyKwNFi0mIIJHDYdmt6TSD/qvN+fT+26sSWak0tXDIueTZ2wohlV9up3NF1dDMQ2VAmNYDlk9uJdUn1tkBveqxeadrnZkcX9r7SJhwX7ZY3m7h4JtqcsDpzCH2gouoJ3sVIMpV3GBXCkLtFNSbsJlI8WbiO9yxtvYAFhrCxsFFP0BXoI9onpoXB5CnC47ohhuMBdaOQQg+ufOfhdydwxtlK6Gy5PfZE9UE4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1781025652; bh=2sFGd9uIYn6pEnQeFfg8fVLz8s/TYLTfAbEBD9MKhv2=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=fs1F88/b9TTCCRKpqFuQdF8uKbo3YNr4r/XLOik46W3P5KW/2jowxZVo58qXldop0woo1rR1wh46XGA5wHkEHCJhUduYOuyKT4x6aHLeYO1N5yQojjnveRW+OHtYba+dbt1RYmyVM21+P67etzTWC27clrBu19hnEbYZWNyW1pWYSMsmgc/rFyibahSob+9qnKAqlhru1p5CefU89ejFybEg1k8VsGzyglqugVP2NNGUGauoXPZgMUOJ5xfQbUC9jUgnh/Ceh7bK+T0nyo8CUtALXcPmKMNCMWPrQBUnaGmJba1hKdbF5+Iw/2XIJxQsXVd3HWEBqhbZU1bOYDOGqA== X-YMail-OSG: FjnWq0IVM1kGGggsJ5i7duxEtdnAqJt5CMSJVxlys6y_7aclxFtyVlQnphTKaH8 xrrfT5XgpK6Z_xV0HJDTh8YfE96HYdyX.JNpTXlBmi3tKVLQqnHBivrwTq.mZN3IA8nY0AQXJhKX cWgA4qIOf.Ab1GyHpXtDp9AcJYp2xsYR1yra_0rDFZeCoRLrA6m.6nDD7EV5A.O_ElG0AHVQQ.xk xVjQtymriWK6g.wUjckeLFoSaR_w5wu_M0LwVtX5d.MbC2M35K1a3Ac4CKFj_a1YxxfeI2Kao6PB .yo0jxNey8prFHDYThn5MVIGnsaKlxMVG_HuWRZjGOaiCqbWJmAhpwl7UKOSTh.5XlELLTnppIIj ZU2pQ1g59pWMnNh_jB_2RDY.hAIvoN9uVm44bl3W8jcDdtRRBAP6XK_fnY.JUM0hbhV5hbdmky9u AgoMWIrjBmZlkGqhVEScpd2lYPxqkOKMDz_nPj6cp3zdsyKYevtXkEPOWEVi.72ZkIRWcfCwG36O vw4IfvsRO8KOqwlGZPR0e5gidapIDnop7Htu0o4bJiQs6SSBdhs1J5GF0sG9OpnjzZtqc07S8IDM lmTYmM5Bf171f.1UwtLjwm.6_LqOlmHnAeWk5zwX6kK6f9lN3Dr63sMYVckETOBfkRZZdnsiQC7P FevqilOuqd.aSNDHSEe1HVbJwzBq_3yMJZ2O82CzgBtmMXv0428miadCWTMuV7IXQn7SjV9TtnrU Kb3KFUPILDaVDn88iyvWBnXbGbBuQy8yjYY4fcze.lRFhqXasQowx8WBONsr9ZQsjauPzuLAJb2w ptAf51kTRa72PhrWPreAr4Idn3NJ.ZpkLMkUc8nSesxJyB8krqWgpF5r6WSpKNdGTSdBj1NOQhuP KlduUxAP7ByJ6wELSdB0TU4zabWZlkgsYpoS98Ur8lk508mtpxLyzi.CutSMXT0w0kiUeJpxbmMz vDp.4Pt17t2wPitFXKLi17KViLj8eaOrCqVnoyAmp9N2pSHDhptrq3CHf2K2gD3CCeAmAGTTd3Bs xc99FlAqFvwAGvuZQ2quIR7Na6Q1WtFfnEVYDsc1ydU5qfigmy.3dB75XNNxyK2ID00fCnFg8IE. 8DXvh4ts.ivituvcEsOaMyuh90myFhvYpAPWRQ0nMPlDefil2_.ucJPfGWevsBKfJtrxcNFm3J5B NZPE.E5f1VWK4GuO7yuEW12g362s38Rc.ju0BwrnJerjXSdpqQm6UzXugX04X8ZdKaZiNwLbY4mY u6xAdiJ2hl4TWjmVOsQUkInz_dd67458KjjRj2Iko2WO49KtZLbjdGF.lkRqiEUDh84EOlwMHmp_ MK9PEIWUrLqtk_.6lmVucmgd8ZZHhxEk7JupOWP20Bz48tzSTqTt9ayXVqyfZ1jOuEdcDEq0BqQI 9GJK9.cGgn_YLonr_ODkTBepsJC..nE.CvK2wokWw3q1VCddcUeWqsDkO1DQr5AWnVDliJ7K4VOp 39UDCXkiLyN6vgKlk8Ckn.kLhlSMczeP.gnlz.N1IYennCDOlCIOTqxmq1JqLydT3BLOc1.Njc9K O2JChl5uWk0Hymg9zo8GOk9NvkWppc_YwWFY6lGxlLDpzF6U8_IDFpsPw4Oj3Q6xOBv16OOKDfBv I47.vLrv14ABkfbkiZuU0D3zrg4_YfAdes3G6SW16QdyxmMQHAOYOV_OX8Qy49QH.RYk8_7zrHI9 Q8gQ.fYUC067XsTdEY_nUWQUzrxS.WNAjUccIC7QzHyfhUwVX.y6tY4VsvbKVI6cRv4fLyTVbsh8 BfvOX31ksuRLbotsrJKkXehNnkjh154i0Xh8QImp8_SQmpPaCnkWjGGx1_KkfmBuV7DaAlnGpDyf YI9HXSJF2ErI.73.3oin37eFoJZtuTDOwjQByVlAbQhkWI8RYym4mIU6jd2xqiD6H4aWfbtAiCKw ZW.TYi2X7H7rKkMJ8wVLDer7E4sXZpFNEpTYwG0z9.WoVzWaC3Hs5t8cVIEuWMSEBXRvw_az31Ys MndnAmkkM6yMJpkZ7Kq2uyEKLIYudO_0wNQGsj222nKlndBSW2AZz3sqM8Pcux31j.Q5zK2FFsJi S1zR9_pippJH.Jpa20nE7KV8ddL0KklEKlEAo3Y3PFb7vQ_iVFwgQce2VKaTRG8zJsj0Gvf3j.vK n8Cd3lIItaHgWIXDaz24DwTeWjQ5hOZmNgzuyk029TY310rkWz6abJPr0CoUnPBytrHSySjX.of1 FW7MCUOjad1s5Kg6k6Lzqjx6pUxJ7u16wPDW_XdyA69kapwsbyU0sw5p7cr_5QrF9RQZkLQU4vQ9 V9SUHv4mh_QE8L37AtGFIDpD4HywxSBt_JvmOcEhXDlYNkfzYk80- X-Sonic-MF: X-Sonic-ID: f753d426-f1c9-4852-b796-2632c5db4743 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Jun 2026 17:20:52 +0000 Received: by hermes--production-gq1-7bb7df5c46-swc2n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 202bb4f6ea3f5de36e32d297ce502ce0; Tue, 09 Jun 2026 17:20:48 +0000 (UTC) Message-ID: <1bbba34d-0a7f-4cb0-932a-235b5de3ec65@yahoo.com> Date: Tue, 9 Jun 2026 10:20:47 -0700 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: about usb3 <> ethernet adapters for raspberry pi 5 From: Mark Millard To: freebsd-arm@freebsd.org, void References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.25942 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.72 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.72)[-0.718]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_TO(0.00)[freebsd.org,f-m.fm]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; 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)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148: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)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gZbKN42l7z4NQy On 5/22/26 23:33, Mark Millard wrote: > On 5/22/26 10:34, void wrote: >> Hi, >> >> As subject: 1. what works? >>             2. what's the throughput like as measured with iperf/iperf3 ? >> thanks, > > From an 2025-Dec-23 message of mine for systems that were likely running > a official pkgbase GENERIC-NODEBUG kernel (main) and, likely, the > official pkgbase world (which is always debug for official pkgbase > main). The alternate non-debug world would have been via a chroot use. > My use of the debug kernel variant is rare. > > I have access to several of the dongles at the same revision. (See > later.) Also: both systems involved were using this type of dongle. The > other system was an amd64 7950X3D. At the time, as far as I knew, the > FreeBSD OS did not support the built-in ethernet in the 7950X3D system. > > QUOTE > Instead of the built=in Ethernet for the Windows Dev Kit > 2023, use of the dongle on a RPi5: > . . . > > # usbconfig -l -d ugen0.2 > ugen0.2: > at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) > > # iperf3 -c 192.168.1.195 --get-server-output > Connecting to host 192.168.1.195, port 5201 > [ 5] local 192.168.1.161 port 25933 connected to 192.168.1.195 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 112 MBytes 942 Mbits/sec 8 470 KBytes > > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 487 KBytes > > [ 5] 2.00-3.06 sec 119 MBytes 939 Mbits/sec 9 488 KBytes > > [ 5] 3.06-4.06 sec 112 MBytes 940 Mbits/sec 9 486 KBytes > > [ 5] 4.06-5.00 sec 106 MBytes 941 Mbits/sec 0 488 KBytes > > [ 5] 5.00-6.00 sec 112 MBytes 940 Mbits/sec 10 486 KBytes > > [ 5] 6.00-7.04 sec 116 MBytes 938 Mbits/sec 7 486 KBytes > > [ 5] 7.04-8.00 sec 108 MBytes 941 Mbits/sec 0 488 KBytes > > [ 5] 8.00-9.00 sec 112 MBytes 940 Mbits/sec 7 486 KBytes > > [ 5] 9.00-10.03 sec 115 MBytes 941 Mbits/sec 0 486 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec 50 sender > [ 5] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec > receiver > > Server output: > ----------------------------------------------------------- > Server listening on 5201 (test #3) > ----------------------------------------------------------- > Accepted connection from 192.168.1.161, port 49403 > [ 5] local 192.168.1.195 port 5201 connected to 192.168.1.161 port 25933 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.06 sec 119 MBytes 937 Mbits/sec > [ 5] 1.06-2.06 sec 112 MBytes 941 Mbits/sec > [ 5] 2.06-3.06 sec 112 MBytes 939 Mbits/sec > [ 5] 3.06-4.06 sec 112 MBytes 939 Mbits/sec > [ 5] 4.06-5.00 sec 106 MBytes 941 Mbits/sec > [ 5] 5.00-6.06 sec 119 MBytes 938 Mbits/sec > [ 5] 6.06-7.06 sec 112 MBytes 940 Mbits/sec > [ 5] 7.06-8.06 sec 112 MBytes 941 Mbits/sec > [ 5] 8.06-9.05 sec 112 MBytes 939 Mbits/sec > [ 5] 9.05-10.03 sec 110 MBytes 941 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec > receiver > > > iperf Done. > > # iperf3 -R -c 192.168.1.195 --get-server-output > Connecting to host 192.168.1.195, port 5201 > Reverse mode, remote host 192.168.1.195 is sending > [ 5] local 192.168.1.161 port 37464 connected to 192.168.1.195 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.06 sec 119 MBytes 941 Mbits/sec > [ 5] 1.06-2.06 sec 112 MBytes 941 Mbits/sec > [ 5] 2.06-3.03 sec 109 MBytes 942 Mbits/sec > [ 5] 3.03-4.01 sec 109 MBytes 941 Mbits/sec > [ 5] 4.01-5.02 sec 114 MBytes 941 Mbits/sec > [ 5] 5.02-6.00 sec 110 MBytes 941 Mbits/sec > [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec > [ 5] 7.00-8.00 sec 112 MBytes 942 Mbits/sec > [ 5] 8.00-9.00 sec 112 MBytes 942 Mbits/sec > [ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender > [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec > receiver > > Server output: > ----------------------------------------------------------- > Server listening on 5201 (test #4) > ----------------------------------------------------------- > Accepted connection from 192.168.1.161, port 16691 > [ 5] local 192.168.1.195 port 5201 connected to 192.168.1.161 port 37464 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.06 sec 120 MBytes 948 Mbits/sec 0 730 KBytes > > [ 5] 1.06-2.06 sec 112 MBytes 941 Mbits/sec 0 730 KBytes > > [ 5] 2.06-3.06 sec 112 MBytes 941 Mbits/sec 0 732 KBytes > > [ 5] 3.06-4.06 sec 112 MBytes 942 Mbits/sec 0 732 KBytes > > [ 5] 4.06-5.06 sec 112 MBytes 941 Mbits/sec 0 732 KBytes > > [ 5] 5.06-6.03 sec 109 MBytes 941 Mbits/sec 0 732 KBytes > > [ 5] 6.03-7.04 sec 113 MBytes 941 Mbits/sec 0 732 KBytes > > [ 5] 7.04-8.04 sec 112 MBytes 941 Mbits/sec 0 732 KBytes > > [ 5] 8.04-9.06 sec 115 MBytes 942 Mbits/sec 0 732 KBytes > > [ 5] 9.06-10.00 sec 106 MBytes 941 Mbits/sec 0 732 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender > > > iperf Done. > > > I'll note that the RPi5 is booted via a draft EDK2 version > via UEFI/ACPI . The draft does not publish the built-in > Ethernet. > END QUOTE > > cfg=1 was under 24 MBytes/sec one direction and under 12 MBytes/sec in > the other direction. I'll not bother with the detailed results here. > > The tests were for helping with example information for someone else to > make the decision on if the default cfg value should be updated or not. > > It turned out that different revisions behave very differently and the > prior cfg change that had been committed messed up the operation of > the rev I have access to. In the end, the original default cfg (0) was > restored and the other rev 0x31fd got a rev-specific Quirk for Realtek > RTL8153 to use UQ_CFG_INDEX_1 so if_cdce claims rev 0x31fd instead of > if_ure: > > - USB_QUIRK(REALTEK, RTL8153, UQ_CFG_INDEX_1), > + USB_QUIRK_REV(REALTEK, RTL8153, 0x31fd, 0x31fd, UQ_CFG_INDEX_1), > > > The non-0x31fd rev is the type of dongle that I normally use. I do have > at least one other type of dongle around that was historically slower > then the RTL8153 ones I have access to. But, back when the type of my > dongles that I use were speed up (2020-Sep?), I was also a tester for > the effort at that time. > > FYI: the RTL8153's that I have access to have: bcdDevice = 0x3000 An example showing that revision code: # usbconfig -d ugen0.2 dump_device_desc ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0210 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0bda idProduct = 0x8153 bcdDevice = 0x3000 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0006 <000001> bNumConfigurations = 0x0002 The quirk added to sys/dev/usb/quirk/usb_quirk.c to avoid config 0 was for: 0x31fd Another issue is referenced in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165 for some some vintage of RTL8251/RTL8153 that . . . ) is bad used on: Lenovo x1 carbon gen11 but: ) is good used on: x1 carbon gen6 and raspberry pi5 --at least if I interpret the wording correctly. -- === Mark Millard marklmi at yahoo.com From nobody Tue Jun 9 21:15:25 2026 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 4gZhWx2zLdz6gfcn for ; Tue, 09 Jun 2026 21:15:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gZhWx29Kdz46SF for ; Tue, 09 Jun 2026 21:15:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781039725; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=kTF4xk+q1qse0ZBvzNT8a9aXcTJokKZoi1nlopi6Dx0=; b=ebqRYUFtVUcKlFEBA1LDR8TFfAwHsKLy5ULblq4u+RIoQqBWceTOFM85fwjx8se1tVMz3H 2Ep8I9+ywZ2MCejPlLqZQOSQVvHPIFFwivPgH93gzDWmcmO5KqzDrpP/fNORkHZ58YSXD1 /OTlbwKyFXPA8E1sS6iSHo5tUYIxfPko3annCUjWSxop2WvxnFe4+YbVhGuhkOEDGINVTU 9qNctZFWPWvhrkvssawmCywdfpNjVUjglggTXcVQyDgxuuyO6TB8tlVbt8DTJBMjE4hHDn 2Dm180o901Gf5oOXGSkDsnm+HSVngrSV4n1Wl+4zjrFYh0YkcAIRPfJfvYbNgw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1781039725; a=rsa-sha256; cv=none; b=e3Zm2it+2s38xHXAOKI/wi5zgfopUUqX/mo/ueuk4MSPgvZxMeU1b0ZEL63rNQtErRvjfw dRaT/AEL3OPz1MNE7p9Sb6wfxgxknWOm91AW8X9nuQoFoYsWWhU5Tkx3ODgUrPcLE6tOQo VkPLQXD1YniMAV1byYa6OvUyAD80gM6e8GwLB0gzSddQeU73Gyn+2jNSDwtnj16nRUf9gP kesB2wKfzfpm8IhksaZwjVTMAeIX4TIOqVVu5T9p7o++J67XvWQq41UTAj/SjRdzAru9Nr WhmLBanJwdvUMTjVkFFjZIh6fyEPPCN0mUbXlyoXWrdWskKo+9VOpqeXXKlIcQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781039725; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=kTF4xk+q1qse0ZBvzNT8a9aXcTJokKZoi1nlopi6Dx0=; b=qxWLn8QZR0BTVR2oNmO/uAY605BbBi/4TQEAvS+0IO/i3HQJie2h2X75J5t2V0c0QYyEH5 0sfb9mjgUrH0ERe9DQpWtBRXm+YyWxDcq2bgW7FFlBvpcqL6iaQDQ99Xw4sjtZOIqHZCjg rKdTBfVb1hdYSj6uxALzlrlpN7lvZ3vXeeeHtaKehJnIBb3fgZiasplpM6ZorXMr9FyBrT 2/WFSKw6izR24E/6YATW7efVaF30WWAR+7Aa6F+W2R8siW8WR/4lYYmngPMMJswFGw+u/L BcRta3/pUrJOVGVnW/3CvWt4M8Mr43pKkEtEd+2hFLeGyM2t3mTpHd4f0OpfWA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4gZhWx1gpxzrqG for ; Tue, 09 Jun 2026 21:15:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 659LFPjK086748 for ; Tue, 9 Jun 2026 21:15:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 659LFPIO086747 for freebsd-arm@FreeBSD.org; Tue, 9 Jun 2026 21:15:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 295965] wait3(&status, WNOHANG, ...) clobbers status to -65536 when no child exits. Date: Tue, 09 Jun 2026 21:15:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mandree@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform bug_file_loc op_sys bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D295965 Bug ID: 295965 Summary: wait3(&status, WNOHANG, ...) clobbers status to -65536 when no child exits. Product: Base System Version: 15.1-RELEASE Hardware: arm URL: https://github.com/python/cpython/issues/151019#issuec omment-4663777690 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: mandree@FreeBSD.org CC: arrowd@FreeBSD.org, python@FreeBSD.org Created attachment 271653 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D271653&action= =3Dedit test program to demonstrate ARMv7 wait3(WNOHANG) issue Greetings, we've been looking over various self-test failures in Python 3.15.0beta2 (in ports) and on a particular system, and apparently FreeBSD 15.1-RC* clobber = the "status" field that we point wait3(...WNOHANG...) to when it doesn't have an exited child to report the status of. See URL. The issue occurs in an ARM= v7 poudriere jail hosted on Aarch64 on a Neoverse-N1 virtual server, and I can reproduce it on Aarch64 with test code compiled with cc -m32. int status =3D 0; struct rusage ru; // uninit, will be cleared later if pid =3D=3D 0 pid_t pid =3D wait3(&status, WNOHANG, &ru); At this point, pid =3D=3D 0 and status =3D=3D -65536 on ARMv7 or with -m32,= but not Aarch64. The latter is unexpected, and should be status =3D 0. I am attaching a test program. #0: It works on ARM64 and mostly everywhere else: $ cc -std=3Dc11 -o try try-wait3.c -O3 -Wall && ./try pid =3D 0, status =3D 0 =3D 0 That's the expected outcome. wait3() has nothing to report, and leaves stat= us and ru alone. #1: Now add -m32 to the command line: $ cc -std=3Dc11 -m32 -o try try-wait3.c -O3 -Wall && ./try pid =3D 0, status =3D -65536 =3D 0xffff0000 =3D> OOPS. To spice things up - truss "fixes" the status field but spoils the rusage reporting: $ truss ./try fork() =3D 58606 (0xe4ee) freebsd32_wait4(-1,{ EXITED,val=3D0 },WNOHANG,{ u=3D0.000000,s=3D0.000000,in=3D4294958518,out=3D-39440684688344 }) =3D 0 (0= x0) freebsd32_fstat(1,{ mode=3Dcrw--w---- ,inode=3D108,size=3D0,blksize=3D4096 = }) =3D 0 (0x0) freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGN= ED(12),-1,0x0) =3D 537174016 (0x2004a000) [...] freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGN= ED(12),-1,0x0) =3D 537210880 (0x20053000) freebsd32_ioctl(1,TIOCGETA,0xffffcf68) =3D 0 (0x0) pid =3D 0, status =3D 0 =3D 0 write(1,"pid =3D 0, status =3D 0 =3D 0\n",31) =3D 31 (0x1f) kill(58606,SIGTERM) =3D 0 (0x0) _exit(0x0)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 process exit, rval =3D 0 The same happens if I set up an armv7 poudriere jail, enter it, and then compile the test program there (with or without -m32 does not make a differ= ence obviously, the test fails every time unless run under truss). --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 10 11:27:58 2026 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 4gb3Rg3Y2Xz6fwX6 for ; Wed, 10 Jun 2026 11:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gb3Rg0fWWz3swv for ; Wed, 10 Jun 2026 11:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781090879; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ysB5DPtOjUZWYWR9qUEXOMzT3/aWaR3GIyLfeaTKcxw=; b=tCNZ6CpkkClXGO/uytc/tRG5M7M2XmMkNQhYvmgNZBcJnqiT+ib6UXIXvFI1NVGNG5qWFo aJUoDS/8wjS7qrjo6VWoGgFRa+bGCny8Gvc1mTbzpSLC1X77MgKF6Y7+CNABoumboV7XO2 YAh3+gsRaNgxEQ4Z6l+eNO7p2n6TO316Nt//qe8Q3fJdHjIS3vBhNEZ6xwfbQ8mW9Dwm+3 MvpG8RZAgr1aeBBgygioPOFMsX6sno+YrdJTj3zY1HrWLibzezZVOCS8rR7tIAS6xzl0oT 19+oBuqlx7w4Rlmv0RV35rJwsa00KhPTPzdlalwl1tpZr1Cr0FjbrSO2WskqYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1781090879; a=rsa-sha256; cv=none; b=SuU9okuAn1FOx2RxpIC+uOVpcLlASBtMfZLEsu3LuqOpp4qMqbg/2Yl4G02UVSZfsWXobs MZS1sw9OPR9UqnaUQD7kmB2PLDqmMPXoLXlf3FWz1BorseD8HABuZv2ThkP/fWA578t2I8 vOP27mynk33eKzwAmR8AWjMnvoS6u+WnrKXcBtRLTdkS3s9uPSWaLvxU6tU/E58TL4AbJo A0ULSOOpDFeNnv7u5q9UnpO0EvS+TqkVoJJPYeuiKkSM/VZ6NZlJv1UaSOQ8n6dHto7SDm xi4cejLgvAfqmQ1n6aOtACeL6BL+caJgDcNZogMefOXgmLgVe6p72eDF/CeZ5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781090879; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ysB5DPtOjUZWYWR9qUEXOMzT3/aWaR3GIyLfeaTKcxw=; b=wVTpdrfias3a79oNb+IYbbPULvmgBSAdjX1wcSOckPkhF8N43vcyjUr89/rKbvkNA5Bazh 3EFjbWlyt7q3pq9HDloJV8/3QfK2NFAjONxVBQoNIZ6j3iIpSPbTv9Q9xFp01uveb5GcO8 5/ySqAObWXncy2NVog7SBXG78VVrzhGCGEzgtNTc8IBLuXsSjb3ojqyrWFj8bPSN3FD/ai vZgdPIMLasCVB58u+UkK9AYfAFoCWzhIjQcfPWQ/qIs1u7/nDRIaKHWEDZQr45Ey9ERdN+ HFbf/qexnCE6zcolKclsDWjuBSNO2PMmnE6G95w87Qepm+l7URzVh+1bwkEgEQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4gb3Rg03vJz1HVJ for ; Wed, 10 Jun 2026 11:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 65ABRwGh074507 for ; Wed, 10 Jun 2026 11:27:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 65ABRwcV074506 for freebsd-arm@FreeBSD.org; Wed, 10 Jun 2026 11:27:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 271482] Raspberry Compute Module 4 IO does not boot Date: Wed, 10 Jun 2026 11:27:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 16.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ziaee@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271482 Alexander Ziaee changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed CC| |kevans@freebsd.org, | |ziaee@FreeBSD.org Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.=