Date: Sat, 24 Dec 2022 20:14:57 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware Message-ID: <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com> In-Reply-To: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 24, 2022, at 19:15, Mark Millard <marklmi@yahoo.com> 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: <Fixed clock> 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: <BCM2835 VT framebuffer driver> 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: <BCM2835 DMA Controller> 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: <BCM2835 DMA Controller> 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: <BCM2835 DMA Controller> 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: <BCM2835 DMA Controller> 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: <BCM2835 DMA Controller> 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: <ARM Generic Interrupt Controller> 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: <BCM2835 DMA Controller> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?374EC3E5-4CB4-4336-A8B9-7A9CF6151691>