Probably. If you switch 28/29 to inputs and switch 0/1 to ALT0 the bus reappears on 0/1.usul27 wrote:This might be the same problem discussed here:
http://www.raspberrypi.org/forums/viewt ... 00&t=82772
I2C0 is used by Videocore and by default is enabled on GPIO28/29. It will be the VC bootloader that temporarily swaps the alt settings around and probes the GPIO0/GPIO1 I2C0 bus for the EEPROM prior to booting the ARM. There should be no need to probe the EEPROM from Linux in a fully functioning system, but for development or test purposes the hack in the linked thread can let you talk to the EEPROM in Linux.Boeeerb wrote:Thanks usul27, running them 4 lines worked this time, it did refuse to set the direction first time though, kept telling me the file is busy... Odd...
Hopefully see this fixed before the first launch of HATs arrive.
Now to work on how the Pi will auto install drivers when that is ready
Interesting... does that mean that there's no method to read "manufacturer custom data" https://github.com/raspberrypi/hats/blo ... atom-types and it's merely there as some kind of placeholder?jdb wrote:There should be no need to probe the EEPROM from Linux in a fully functioning system, but for development or test purposes the hack in the linked thread can let you talk to the EEPROM in Linux.
Hello,James Adams wrote:Plan is for the Pi to read the EEPROM data once at boot and cache it, then provide the cached data via a sysfs interface (or similar). Obviously software doesn't do this yet but we're working on it.
Code: Select all
dtparam=i2c_vc=off is the default anyway. I thought the same was true for i2c_arm.joan wrote:I'm not sure i2s is relevant.
6by9 says to add force_eeprom_read=0.
In addition perhaps dtparam=i2c_vc=off