cm/cm3 boot-time configuration

[yaheath]

What are the chances that the cm/cm3 boot loader could be modified to be able to use a Hat-style eeprom to load configuration and/or dtoverlays? Wouldn't it be useful to have a standard mechanism for a carrier board to identify itself to the cm[3] and configure IOs?

I tried connecting an eeprom to gpio 0/1 with a hat configuration on it, hoping maybe the hat support stuff might be active, but there is zero i2c activity on those pins when my cm3 boots.

[W. H. Heydt]

The CM boards expose all interfaces. Of course, if you want to use some of them, they have to be enabled in the kernel. Look to your /boot/config.txt to see if !2C is enabled.

[gregeric]

The eeprom is polled by the GPU firmware & very early in the boot process: before the rainbow splash screen is rendered, you can see a train of pulses lasting ~3.5ms, even without an eeprom on your expansion board. Enabling kernel/arm i2c use does not enact it.

You can just as well configure your hardware in config.txt. Is there anything to be gained by eeprom configuration, other than if your carrier board replicates the 40-pin header?

[6by9]

If you really want to read a HAT EEPROM on a CM, then you can add "force_eeprom_read=1" to config.txt, and define ID_SDA and ID_SCL in your dt-blob.bin.

[yaheath]

If you really want to read a HAT EEPROM on a CM, then you can add "force_eeprom_read=1" to config.txt, and define ID_SDA and ID_SCL in your dt-blob.bin.

Thanks! This is exactly what I was looking for.

[yaheath]

You can just as well configure your hardware in config.txt. Is there anything to be gained by eeprom configuration, other than if your carrier board replicates the 40-pin header?

I anticipate having more than one type of carrier boards with different hardware on them. I also want to have a single OS image that can properly configure itself to whichever of my carrier boards it runs on (so that I don't have to maintain separate OS images that are mostly identical).

If overloading the Hat functionality doesn't work out, my fallback will be to do the hardware configuration post-bootloader early in the startup via a custom systemd service or something.

[MKa]

Hi,
I have very similar needs as you do - with cm3+ module. Did you find solution reading the HAT EEPROM and get details loaded into /proc/device-tree/hat at boot?

[PhilE]

Did you find solution reading the HAT EEPROM and get details loaded into /proc/device-tree/hat at boot?

If you really want to read a HAT EEPROM on a CM, then you can add "force_eeprom_read=1" to config.txt, and define ID_SDA and ID_SCL in your dt-blob.bin.

[MKa]

In fact I also asked this in HAT forum
https://www.raspberrypi.org/forums/view ... 5&t=250765
were I described what I have done. So I already tried defining SDA and SCL in dt-blob.dts and added that "force_eeprom_read=1" in the /boot/config.txt

They did not get SDA0/SCL0 living at boot.