HATs and other add-ons • Re: Why is there no M.2 HAT+ overlay?

Are you calling my a liar?

No. Not sure why you would think that. I'm just implying that there's no point sitting around speculating this or that, or imagining some kind of malfeasance, when it's possible to actually find out what's going on.

read the HAT+ spec as well as the M.2 HAT spec (it's even written on the schematic): the I2C address needs (!) to be 0x51

Ah, so it is. I've seen the schematic, but I guess I forgot.

ID_SC/ID_SA were connected to ic2_arm on the DUT (CM4, used only for reading the EEPROM).

So... you're using a second Pi CM4 - that is, not the Pi 5 the HAT is attached to - to read the EEPROM? I mean, if you want to make your own life more complicated... But whatever works for you, man.

I'm using a custom overlay for I2C access:

You don't need an overlay to use eepflash.sh. It loads (with modprobe) I2C and at24 kernel modules itself. Of course, the downside of this is that it only ever uses the default 1-byte reads/writes, but that's no big deal for occasional use.

Trying to run the script from 'HAT EEPROM tools' fails as it tries to access a device on address a file '1-000x51' which ins't there for sure - correct would be '1-0051'

Oops, my bad. I forgot the address argument should be without "0x".

It doesn't help that the help text from the utility itself wrongly shows the argument values in "0xNN" format.

reading it in a different way

Code:

pi@raspberrypi:~ $ sudo dd if=/sys/class/i2c-dev/i2c-1/device/1-0051/eeprom bs=1 count=4096 | hexdump -C00000000  52 2d 50 69 02 00 01 00  46 00 00 00 01 00 00 00  |R-Pi....F.......|00000010  32 00 00 00 9c 6e 67 e6  4e 3c 6f 8e 79 47 e0 a8  |2....ng.N<o.yG..|00000020  01 d0 3a 83 00 00 03 00  0c 0e 52 61 73 70 62 65  |..:.......Raspbe|00000030  72 72 79 20 50 69 4d 2e  32 20 48 41 54 2b 20 4d  |rry PiM.2 HAT+ M|00000040  20 4b 65 79 90 1a ff ff  ff ff ff ff ff ff ff ff  | Key............|00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|*00000fe0  30 30 30 30 31 31 32 34  30 30 31 30 31 34 31 34  |0000112400101414|00000ff0  00 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|4096+0 records in4096+0 records out4096 bytes (4.1 kB, 4.0 KiB) copied, 2.1727 s, 1.9 kB/s00001000pi@raspberrypi:~ $ sudo dd if=/sys/class/i2c-dev/i2c-1/device/1-0051/eeprom bs=1 count=4096 | hexdump -C > hateeprom.eep4096+0 records in4096+0 records out4096 bytes (4.1 kB, 4.0 KiB) copied, 2.13714 s, 1.9 kB/s

eedump gives me a format signature mismatch

Code:

pi@raspberrypi:~ $ eepdump hateeprom.eep hat_eeprom_dump.txtWARNING: Format signature mismatchUnexpected EOF or error occurred

You made a mistake on the second read. You're still piping through hexdump. So the output of hexdump is what went into the .eep file. Not surprising that eepdump complained of bad data.

Anyway, you initially got a read of the EEPROM data, and it can be trivially decoded by hand from what you've shown. It contains one single atom of type 0x0001 Vendor Info, Product ID is 0x0000, Product Version is 0x0003, Vendor string is "Raspberry Pi", Product string is "M.2 HAT+ M Key". And because that vendor info is the only atom there, there is no Device Tree Overlay atom. My prediction was correct.

I'm not sure what that odd extra data at offset 0x0FE0 is. Perhaps some kind of serial number and/or production date. Whatever it is, it's not part of the HAT ID data and won't ever be read by the Pi (the length of the ID data specified in the header is only 70 bytes, which doesn't include this data all the way at the end of the EEPROM).

Statistics: Posted by HwAoRrDk — Sun May 26, 2024 10:42 pm

---