From nobody Sun Dec 25 04:14:57 2022 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 4NfndJ1XWtz1J7Pb for ; Sun, 25 Dec 2022 04:15:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4NfndH0Lqgz43KN for ; Sun, 25 Dec 2022 04:15:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qrjLbKr1; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 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=1671941712; bh=cnuXyIKry6xsDPTIF6+oVzjtVld3LFbL2E4lnkU+iu8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=qrjLbKr1RbTmKrzB3F5YvDg7YH7vQVLYBdc/6C0TIyYBCpWZOlwzxZqbFzmtTWOvambbwTN9teNNRVZtDtxa5OEQHyKs+dNhXNff2El44mRnOtST/HwlWoav5iagnp9P48yKlHkzvdS8krZjMrG2n3MxbGK2aUsH0PlENL6k3lUlKxpPdj4qObyk6PX/tXAyj/q7nq8D81BhVKlWrJncoBkArPs3RW3BsNJhQaU+J2AwLxiai/EAE8PlENt27dE79BGXGAWjjXtwTAFXty/2Iv+vxWZitUPbMxuEhJQSX2j4PfegONGj8w/2nzyrpigJ1dgeJT4xAF8H5US1daLymA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671941712; bh=ma8Bq8qpTyser0NriqPuJvnxEsztYypyGgL5hLZls3r=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=CTBqQKFpLPmj6laeMa6QdRmn9lH3u/JmKuAs9n7MQpwDd/CZr+mPLONhrufw4ZxVYYLfulAmrHixHkGRbciFpykd2k0VKTJlxrQjryNp/gNDKVcA6hNXl1OSgGDQjEf/sbPn9KbK3YvEjW3AcOa4wNRq9STbSIm/QyQkwGKZFB9hHofHG+pBNamYU5nZTz1PAI0dCK1HP7psaq0mb4SNkj5uLs3XrzInXX7yaNVkmAwKea4vBC++p42Anks5vlUhS7GUrhPbW0L/wCPGco/H9UxTKaAWDzgeLL43+Ta6QpUqFcOrADd7cKZFRVmMKa2bNEeJ/0uI7e7GCdQW3VrDwg== X-YMail-OSG: r0VnUpAVM1mASvevjjQj4cWc4Um386zx3vvfLAKtme2hxsJIorojOTg77iPLCC4 5QcDGlXw_68iY6h99AnKyMve80tS.yIAJF9nz9iATINlxQXkiLnbBTjWWpHNHA3_PodOo5aFJ8HT QjYWvhytW2653Vw5EitKl09PrZbsnQP2Kom83i9JmfTYLwllJmN.SVV3ObFPhRL1lCf5Y_a.bKky zynFdYscbQ2.q1Hg3bBGme75xrw_Prg0YmOjMI_DIo0rTckiam9ombdENu9Ku95by9f6Z19Q3Uag .6wovNXLxMXQb6SP6TzYhOSzRFZgFzIOyaRq7iQpIu4uQUOi2Pk8RSAB0vNGHO9Qw5QzF5iMxPB8 DeegT8KSYsEwEZb.snCM6LijJ7jGfxVB17oA1we05F1nqnyfVLNRTHDqi6R7Xiay_9_Vfe.C5vFP oiHEcbXi1f0.GkeFRk8Yi4GBWsCzxBqDeEU987mQNAIkxsQccTg8N1V_vd9zLScQZt.jSHdKRKsD mlRWwV63ZoAs7d_MHxi1VJN22T81KmO6yV13HmWAA17L6swNaiXkmCapbNvUS2VnhOkQycVT3NwV eIoLKCFA5itrlLVG1xiTjLmLFqP0r4r5rattI0fO0NO7a2DZ9MYI3rt5QT4rdCsxynq6TSl6846G 482UQXFUM2Ecw_6MoScbDVfLGWYuswAV6gTMmxaS07BjfbC0TWGyTL8W4WGFHqQwlFkIHrB0Xak1 9hoWJqfsfqGrqDGi.u_7XOFLRSpIO.WKJu6ThNQ4Ht._txP8dgT4PQ1spgH0t8Cddzl8rXbvjywW E9tquJQg2aiV9eWazklNVoSUsBy0BUzZfnnUH7x4BjegGoZo6DZcxpqqhWcTTUpcgiBEVQHcimKy R_pKYTFgtzezL_WPT7HRJnH0WakckEWJRVLPnANEUr20pvp2LxaTsgpjQq8vwimBEd42KhSA1uTK vF7R6.pfBGNlylwZ1xG9RGB6J9.S2iOzXmvWL_K_R659QmF1E9Ll_qHAjWoMI88sUxF.sWt1jgzG cms8yD0rh58bG8KZwjsFqNyDJRMdXy9wS4RrD2wMsgRNKACyIlTmmUiZ6UDWTOIKS.YEZno2NGcV ifkmPzwe_KEJldZ8AAfpAhVhoitPNrurl1lPM1TxK__CqlUJpe4FhwJb0EwdWe5cfnF2pp2pwutG 4xroeQC3skqj8orFwBtQXwAVgrrdhMqPGaSH6Yw_VwxCGhwNsaOsYIBeOd4Yw4s0D_NNpvMgjbMb Qklq7TDiYi6S4VinDzRFscBxDoiGqvS1x0COnJrWXLRiVQBwGN.dTOUaxyYqb98xyj4zUwq19Wke sppxOgqOLHL5.T0VgJp4l90j1RvoWXDafJqrqliVSKDOBNWFnte3I8blYCp5VRLO3M7dYGgkF0Sa 9yxvwS9FbvaFz_grP7qIAvhda8dCcm1j01fQTwCdOgBFfPG672EwMd.7l38AYo3pJkSQPfsUdQku 179k3UUXMXT.V.8xKY8j5uTORV.LylWCvjBbGulxnetkDBkY6WMNPtjibNglliKOjsh8Cpwo8JOc sbtz_YMYAmNtwTQmvm21Ne3vki1Cj8SoVM06Z.UE5e7JyaCJzAKhrT.xYfeTklZQKQ8OV3fQpkg3 5ANuoybw5XYHpYV03nWNjfBs4_hmFiXcp63ThuUNjhci.zVi99nsgO09rsa14pz53E8OfUO0llpo ZTkRjLSoxsc_CXDzM_LMzEP8cDHcmJC9I46NK90gtXc..iRNJeJoVVeadOq9cKZOAxqxj2H0kKAK k_qATO7WFELi1mAzcajTkjq2P8n.EsWmmawg2gfyqCr7mQoqxTRkJ1wn6DBzJFOprN6z7vsvNB_. LGiIZ.7A4KT03Qg3hmhQ43Q8z7r8wfSPsX5rnaDEkpBVaZ9VFOrW9lln.RWnMEPep0bZdnaf3UVC cVrXLiZjvRUNZH1NF7k6FGbiBbwQ.ZCJzCvZ2XyIioT6YpjqEsYEMT2MhWHDpOzh4M1KN_mna.Hi _VdZmnsFoc7iGwFTB4R7qlawMlyOmueDlNtHQmzx82Rxh9cO3F4GfqqNYyIH4mWZdep8QXv_Sq2n 6HOZbfkJpnTeRjFtMkja25WyrgXXPp8aIlxUzvDFZ7u3abiq7imhQ.rciq.638013AqQ5jLJ2o4_ 1UFbUK4UxZwLPm6iVZN2m8YGG5AqR1uF8ZVyTqvvaX7AKhTwykTTPapafg9RRIusyxMUtBsnbkHU zj3DSD2DOCZu8UOxuW2dzc2SEyJ4PVmVNeeV5cdttE5dFhYIDlHXdQoL3JpSX X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Dec 2022 04:15:12 +0000 Received: by hermes--production-ne1-7b69748c4d-xhmc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 10683588f6f521ac42872efcd0c24e05; Sun, 25 Dec 2022 04:15:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3731.300.101.1.3\)) Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware Date: Sat, 24 Dec 2022 20:14:57 -0800 References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> To: freebsd-arm In-Reply-To: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> Message-Id: <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.96)[-0.957]; MV_CASE(0.50)[]; 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]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from] X-Rspamd-Queue-Id: 4NfndH0Lqgz43KN X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Dec 24, 2022, at 19:15, Mark Millard wrote: > I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE, > BUS_PASS_ORDER_MIDDLE and the like and they allow being > sure that the brcm,bcm2835-dma related setup has been done > before any use of it is made, despite the order in the > Device Tree: use an earlier pass for brcm,bcm2835-dma > related attach. This avoids the kernel crashing during > boot. >=20 > The example context used below has: serial console with > USB3 SSD boot media (not requiring a usb_pgood_delay > setting), booting a stable/13. The RPI4B is a C0T one (no > 3 GiByte limitation, for example: the PCIe wrapper logic > has been corrected). >=20 > stable/13's source code changes ( similarly for > releng/13.1 ): >=20 > diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c = b/sys/arm/broadcom/bcm2835/bcm2835_dma.c > index cab8639bb607..d8b49acfe332 100644 > --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c > +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c > @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D { >=20 > static devclass_t bcm_dma_devclass; >=20 > -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, = 0, 0); > +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, = bcm_dma_devclass, > + 0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE); > MODULE_VERSION(bcm_dma, 1); >=20 >=20 > For reference, a 13S snapshot with my kernel build replacing > the snapshot's kernel, was booted with: >=20 > # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 11:09:05 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Oct 26 2022 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee (clean) >=20 > There are new things present that FreeBSD reports > but ignores, producing messages like: >=20 > clk_fixed4: disabled on ofwbus0 > clk_fixed4: Cannot FDT parameters. > device_attach: clk_fixed4 attach returned 6 >=20 > over and over during part of the boot. It seems to > retry as it goes and thus produce so many messages. >=20 > There was also: >=20 > fb0: on simplebus0 > fb0: changing fb bpp from 0 to 24 > mbox0: mbox response error > fb0: bcm2835_mbox_fb_init failed, err=3D5 > device_attach: fb0 attach returned 6 >=20 > genet0 is working. >=20 > I've not checked if the microsd card slot can be used. >=20 > I used the normal FreeBSD U-Boot since I was not booting > the NVM3 media that requires extra time (usb_pgood_delay > would be assigned in my own U-Boot builds). >=20 > For reference, I used my typical sort of config.txt : >=20 > # more /boot/msdos/config.txt > [all] > arm_64bit=3D1 > dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > dtoverlay=3Dmmc > dtoverlay=3Ddisable-bt > device_tree_address=3D0x4000 > kernel=3Du-boot.bin >=20 > [pi4] > hdmi_safe=3D1 > armstub=3Darmstub8-gic.bin >=20 > # > [all] > # > # Local addition that avoids USB3 SSD boot failures that look like: > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port ? > initial_turbo=3D60 > # U-Boot that has, for example, a built-in usb_pgood_delay assignment > # for a media specific issue added: > #kernel=3Du-boot.bin.2022.10.arm64 > # > # Local additions: > enable_uart=3D1 > uart_2ndstage=3D1 > dtdebug=3D1 > disable_commandline_tags=3D1 > disable_overscan=3D1 > #gpu_mem_1024=3D32 > # > #program_usb_boot_mode=3D1 > #program_usb_boot_timeout=3D1 >=20 > # Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like. > # That would make the below inappropriate for such contexts. > [pi4] > # Locally avoid hdmi_safe's dislay scaling: > hdmi_safe=3D0 > # > armstub=3Darmstub8-gic.bin > # > # Local additions: > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > force_turbo=3D1 > # > #total_mem=3D1024 > #total_mem=3D991 > [all] >=20 > [pi3]=20 > armstub=3Darmstub8.bin > dtoverlay=3Dpwm > audio_pwm_mode=3D0 > [all] >=20 >=20 > As for main [so: 14], the devclass_t use is gone, thus > the source code changes are: >=20 > diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c = b/sys/arm/broadcom/bcm2835/bcm2835_dma.c > index 5f9ecb0b7981..83c4c493a66b 100644 > --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c > +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c > @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D { > sizeof(struct bcm_dma_softc), > }; >=20 > -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0); > +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0, > + BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE); > MODULE_VERSION(bcm_dma, 1); >=20 >=20 I should note that the above is not likely to be the most appropriate in detail. The boot reports: # dmesg -a | grep bcm_dma0 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 31,32,33,34,35,36,37,38,39,40,41 on simplebus0 bcm_dma0: cannot allocate interrupt device_attach: bcm_dma0 attach returned 6 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 31,32,33,34,35,36,37,38,39,40,41 on simplebus0 bcm_dma0: cannot allocate interrupt device_attach: bcm_dma0 attach returned 6 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 31,32,33,34,35,36,37,38,39,40,41 on simplebus0 bcm_dma0: cannot allocate interrupt device_attach: bcm_dma0 attach returned 6 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 31,32,33,34,35,36,37,38,39,40,41 on simplebus0 bcm_dma0: cannot allocate interrupt device_attach: bcm_dma0 attach returned 6 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 31,32,33,34,35,36,37,38,39,40,41 on simplebus0 where that last (working) one has the message context: gic0: mem = 0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460= 00-0x40047fff irq 30 on simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256 bcm_dma0: mem 0x7e007000-0x7e007aff irq = 31,32,33,34,35,36,37,38,39,40,41 on simplebus0 So something involving BUS_PASS_INTERRUPT or later (but before, say, BUS_PASS_SUPPORTDEV) may be more appropriate. Possibly: BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE (so after gic0). =3D=3D=3D Mark Millard marklmi at yahoo.com