RPI CM4 - I2C BUS and Device Tree

Hi all,
I am currently facing an issue with U-Boot and a raspberry pi CM4. Here is the setup:
1. Yocto Scarthgap
2. U-Boot 2024.01
3. rpi_arm64_defconfig
I am trying to access the i2c bus from U-Boot. I have been trying to modify the device tree which is referenced as “CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b”” in the defconfig without success. I can remove everything, set all nodes to disabled and I see no change in U-Boot (I am using dm commands to check the status of the peripherals).
It seems that with the rpi, U-Boot will only configure itself against the device tree passed by the bootloader of RPI. Could someone confirm this ?
Is there a way to configure / modify U-Boot to use its own devicetree and simply pass the device tree generated by the rpi bootloader to the kernel ?
Because the second issue is that the i2c driver defined in the device tree passed to u-boot is not available in u-boot.
Thanks for your help
Best regards
Romain

Hi,
I am currently facing an issue with U-Boot and a raspberry pi CM4. Here is the setup:
Yocto Scarthgap
U-Boot 2024.01
rpi_arm64_defconfig
I am trying to access the i2c bus from U-Boot. I have been trying to modify the device tree which is referenced as “CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b”” in the defconfig without success. I can remove everything, set all nodes to disabled and I see no change in U-Boot (I am using dm commands to check the status of the peripherals).
What i2c driver are you using in U-Boot?
It seems that with the rpi, U-Boot will only configure itself against the device tree passed by the bootloader of RPI. Could someone confirm this ?
By default, yes that is the case.
Is there a way to configure / modify U-Boot to use its own devicetree and simply pass the device tree generated by the rpi bootloader to the kernel ?
You can do the former, but I believe that DT is then passed to the kernel, you can't specify differing DTs.
Because the second issue is that the i2c driver defined in the device tree passed to u-boot is not available in u-boot.
Well I think that is the main issue, there's not a driver the RPi i2c IP in U-Boot, if there was a driver the DT provided by the prior fimware should then work for what you're trying to do. There's no driver to date likely because no one has needed to access i2c on the rpi in U-Boot so it's not been contributed.
Peter

+Peter Robinson +Matthias Brugger
Hi Romain,
On Sat, 17 Aug 2024 at 07:01, Romain Crausaz crausaz.romain@gmail.com wrote:
Hi all,
I am currently facing an issue with U-Boot and a raspberry pi CM4. Here is the setup:
Yocto Scarthgap
U-Boot 2024.01
rpi_arm64_defconfig
I am trying to access the i2c bus from U-Boot. I have been trying to modify the device tree which is referenced as “CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b”” in the defconfig without success. I can remove everything, set all nodes to disabled and I see no change in U-Boot (I am using dm commands to check the status of the peripherals).
It seems that with the rpi, U-Boot will only configure itself against the device tree passed by the bootloader of RPI. Could someone confirm this ?
Yes. It isn't quite obvious, but this is a clue:
Core: 211 devices, 16 uclasses, devicetree: board
'board' means that the board can do whatever it wants.
Is there a way to configure / modify U-Boot to use its own devicetree and simply pass the device tree generated by the rpi bootloader to the kernel ?
Because the second issue is that the i2c driver defined in the device tree passed to u-boot is not available in u-boot.
Thanks for your help
Since OF_HAS_PRIOR_STAGE is a hidden option, you cannot disable it in the defconfig. The only way I know of is to comment out the 'imply OF_HAS_PRIOR_STAGE' in ARCH_BCM283X in arch/arm/Kconfig
For me, that stops the rpi_4 booting, so perhaps the devicetree is out-of-date or ft_board_setup() is doing something strange, or something else. The in-tree devicetree may have got out-of-date, so perhaps use the Linux one.
Regards, Simon

Hi Simon, Hi Peter,
First of all, thanks a lot for your answers.
1. When I enable the i2c bus in the config.txt (which is parsed by the rpi first stage bootloader), the overlay put this as compatible:"brcm,bcm2835". I checked in the source of U-Boot and the driver is not available. 2. One solution could be to use the i2c-gpio driver instead of the default i2c controller. U-Boot has this driver. 3. Since the device tree passed by the rpi bootloader is stored in the variable fw_dtb_pointer (see the lowlevel_init.S) would I be able to do the following: 3.1 remove the automatic selection for the device tree passed by the rpi bootload 3.2 system starts and use the default device tree where the i2c bus is defined with i2c-gpio, access the device I need and store the information needed 3.3 get the device tree address from fw_dtb_pointer, set fdt address fdt addr with the new device tree and then start the kernel
I have another question, what triggers the DM to check for the device (with dm tree command there is a X under the column probed). Because here we could have a really simple device tree with the minimum configuration for just the i2c and load it from U-Boot, perform the action needed and then boot the kernel by passing the device tree provided by the first stage bootloder.
Regards Romain
Le sam. 17 août 2024 à 17:57, Simon Glass sjg@chromium.org a écrit :
+Peter Robinson +Matthias Brugger
Hi Romain,
On Sat, 17 Aug 2024 at 07:01, Romain Crausaz crausaz.romain@gmail.com wrote:
Hi all,
I am currently facing an issue with U-Boot and a raspberry pi CM4. Here
is
the setup:
Yocto Scarthgap
U-Boot 2024.01
rpi_arm64_defconfig
I am trying to access the i2c bus from U-Boot. I have been trying to
modify
the device tree which is referenced as “CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b”” in the defconfig without success. I can remove everything, set all nodes to disabled and I see no change in U-Boot (I am using dm commands to check the status of the peripherals).
It seems that with the rpi, U-Boot will only configure itself against the device tree passed by the bootloader of RPI. Could someone confirm this ?
Yes. It isn't quite obvious, but this is a clue:
Core: 211 devices, 16 uclasses, devicetree: board
'board' means that the board can do whatever it wants.
Is there a way to configure / modify U-Boot to use its own devicetree and simply pass the device tree generated by the rpi bootloader to the
kernel ?
Because the second issue is that the i2c driver defined in the device
tree
passed to u-boot is not available in u-boot.
Thanks for your help
Since OF_HAS_PRIOR_STAGE is a hidden option, you cannot disable it in the defconfig. The only way I know of is to comment out the 'imply OF_HAS_PRIOR_STAGE' in ARCH_BCM283X in arch/arm/Kconfig
For me, that stops the rpi_4 booting, so perhaps the devicetree is out-of-date or ft_board_setup() is doing something strange, or something else. The in-tree devicetree may have got out-of-date, so perhaps use the Linux one.
Regards, Simon

Hi Romain,
On Mon, 19 Aug 2024 at 01:15, Romain Crausaz crausaz.romain@gmail.com wrote:
Hi Simon, Hi Peter,
First of all, thanks a lot for your answers.
- When I enable the i2c bus in the config.txt (which is parsed by the rpi first stage bootloader), the overlay put this as compatible:"brcm,bcm2835". I checked in the source of U-Boot and the driver is not available.
- One solution could be to use the i2c-gpio driver instead of the default i2c controller. U-Boot has this driver.
- Since the device tree passed by the rpi bootloader is stored in the variable fw_dtb_pointer (see the lowlevel_init.S) would I be able to do the following: 3.1 remove the automatic selection for the device tree passed by the rpi bootload 3.2 system starts and use the default device tree where the i2c bus is defined with i2c-gpio, access the device I need and store the information needed 3.3 get the device tree address from fw_dtb_pointer, set fdt address fdt addr with the new device tree and then start the kernel
I have another question, what triggers the DM to check for the device (with dm tree command there is a X under the column probed). Because here we could have a really simple device tree with the minimum configuration for just the i2c and load it from U-Boot, perform the action needed and then boot the kernel by passing the device tree provided by the first stage bootloder.
Just a little niggle, please avoid top-posting as it messes up the history for later readers.
U-Boot devices are probed when used. So you could use the 'i2c' command to make it be probed.
Regards, Simon
Regards Romain
Le sam. 17 août 2024 à 17:57, Simon Glass sjg@chromium.org a écrit :
+Peter Robinson +Matthias Brugger
Hi Romain,
On Sat, 17 Aug 2024 at 07:01, Romain Crausaz crausaz.romain@gmail.com wrote:
Hi all,
I am currently facing an issue with U-Boot and a raspberry pi CM4. Here is the setup:
Yocto Scarthgap
U-Boot 2024.01
rpi_arm64_defconfig
I am trying to access the i2c bus from U-Boot. I have been trying to modify the device tree which is referenced as “CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b”” in the defconfig without success. I can remove everything, set all nodes to disabled and I see no change in U-Boot (I am using dm commands to check the status of the peripherals).
It seems that with the rpi, U-Boot will only configure itself against the device tree passed by the bootloader of RPI. Could someone confirm this ?
Yes. It isn't quite obvious, but this is a clue:
Core: 211 devices, 16 uclasses, devicetree: board
'board' means that the board can do whatever it wants.
Is there a way to configure / modify U-Boot to use its own devicetree and simply pass the device tree generated by the rpi bootloader to the kernel ?
Because the second issue is that the i2c driver defined in the device tree passed to u-boot is not available in u-boot.
Thanks for your help
Since OF_HAS_PRIOR_STAGE is a hidden option, you cannot disable it in the defconfig. The only way I know of is to comment out the 'imply OF_HAS_PRIOR_STAGE' in ARCH_BCM283X in arch/arm/Kconfig
For me, that stops the rpi_4 booting, so perhaps the devicetree is out-of-date or ft_board_setup() is doing something strange, or something else. The in-tree devicetree may have got out-of-date, so perhaps use the Linux one.
Regards, Simon
participants (3)
-
Peter Robinson
-
Romain Crausaz
-
Simon Glass