You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hope this is also the place for discussions about HAT.
We plan to build a system on top of the CM4. We will have a baseboard
with some specific IOs derived from the GPIOs. Probably there will be
variants for customers. Although it does not look like a HAT I think
the HAT-EEPROM would be a nice way to identify and configure it.
Now comes the question. We also plan for a series of expansion modules
on top of this baseboard (one at a time). So we would need a second
HAT-EEPROM on the expansion module to configure this in case it is
plugged in.
Is anything like this foreseen?
If not, if we add an additional EEROM with say address 0x51 to ID_SD/ID_SC,
will this be any compatiblity break within the Rasperry firmware? Our
backup plan is then to process this when the kernel has been loaded.
The text was updated successfully, but these errors were encountered:
Dear Sirs,
I hope this is also the place for discussions about HAT.
We plan to build a system on top of the CM4. We will have a baseboard
with some specific IOs derived from the GPIOs. Probably there will be
variants for customers. Although it does not look like a HAT I think
the HAT-EEPROM would be a nice way to identify and configure it.
Now comes the question. We also plan for a series of expansion modules
on top of this baseboard (one at a time). So we would need a second
HAT-EEPROM on the expansion module to configure this in case it is
plugged in.
Is anything like this foreseen?
If not, if we add an additional EEROM with say address 0x51 to ID_SD/ID_SC,
will this be any compatiblity break within the Rasperry firmware? Our
backup plan is then to process this when the kernel has been loaded.
The text was updated successfully, but these errors were encountered: