RattusRattus
Posts: 60
Joined: Sat Sep 29, 2018 11:27 am

HAT design - Vendor info atom

Sat Sep 29, 2018 12:10 pm

HI there,

So I am in the process of creating my first HAT, for a product that will provide multiple hardware accelerated 1-Wire interfaces to overcome the limitations of the existing 1-Wire drivers and their accocated hardware shortcommings.

The documentation for HATs tells me that I need an CAT24C32 SPI EEPROM (or somthing compatible with / emulating such a device) to store information pertaining to my HAT so that the host can correctly configure itself and so that drivers and applications can identify what hardware is available.

As part of the Vendor Info Atom:
Note that the UUID is mandatory and must be filled in correctly according to RFC 4122 (every HAT can then be uniquely identified). It protects against the case where a user accidentally stacks 2 identical HATs on top of each other - this error case is only detectable if the EEPROM data in each is different. The UUID is also useful for manufacturers as a per-board 'serial number'.
I am faily convinced that HATs are explicitly NONE-STACKABLE so this doesn't appear to make sence.
Additionly the EEPROM should be at address 0xA0 (the most significant nibble comming from the CAT24C32, whilst the least Significant 3 bits comming from the the 3 Address lines which should all be tied to ground) so even if I did "accidentally stacks 2 identical HATs on top of each other" the EEPROM address colision would prevent the Pi from correctly reading data from the EEPROMs anyway.

(1) Have I missed somthing or is this a hangover from an initial design concept for HATs that would have made sence if HATs were stackable, but the idea being abandoned because making All hats stackable is just to complex?

(2) Is there a register for the PID & VSTR fields or is this a free for all and hope that we don't have conflicts? I am assuming that PID is supposed to be unique for each HAT 'product' and this is the field that is parsed by the boot loader / HAT bring up process so a centeral register makes sence. If this is the case how does one go apout registering a PID?
As an asside I would have expected to see a Vendor ID field here as well - but I do understand that many differant vendors may make what is effectivly the same HAT. Without this field though is 16k worth of product IDs enough?!? (/me inserts 'magic 'PID 0xffff to point to extended PID structure in new atom as yet to be defined)

/Andy

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5876
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: HAT design - Vendor info atom

Mon Oct 01, 2018 10:37 am

RattusRattus wrote: is this a hangover from an initial design concept for HATs that would have made sence if HATs were stackable, but the idea being abandoned because making All hats stackable is just to complex
That's exactly it, but you should still use unique UUIDs. If a customer reports a problem, having a unique identifier can help identify issues on the production line, for example.
RattusRattus wrote: Is there a register for the PID & VSTR fields or is this a free for all and hope that we don't have conflicts?
It's free for all and clashes don't matter too much. Each product from a specific vendor should have a different PID, but different vendors will have the same product IDs as each other.

RattusRattus
Posts: 60
Joined: Sat Sep 29, 2018 11:27 am

Re: HAT design - Vendor info atom

Wed Oct 03, 2018 7:25 pm

Thanks for the response

I am beginning to think that the whole HAT concept is unfortunately flawed.
Given that the identification of a HAT is not possible by looking at structured content of the EEPROM why even bother with the EEPROM in the first place? I mean if there is no control over PID then I can't use that to match software to the available hardware; result everyone either ignores the EEPROM entirely or each vendor goes down the route of their own special sauce to confirm that the hardware really is what they think it should be.... Ultimately nothing has changed. The best I can do is put a VID / PID field in the vendor specific atoms and run my own register scheme, then either cryptographically sign this data or hope that nobody else uses the same atom structure I pick.

As HATs are not considered stackable then there is no point on trying to determine what hardware resources you have available and software needn’t look because *ALL* of the resources must be available (guaranteed by the rule there shalt be one HAT and one HAT only). The result will be that software just assumes that it has the available hardware resource and doesn't bother checking. Failing to get the desired resource simply means that the application (or driver) can simply return an error code or crash out depending on how generous the software author is feeling.

It's a shame.

I note also that the PoE HAT breaks the rules for HATs already (I2C address) - a special case for this 'stackable' HAT. But then other people will argue that their HAT is a special case too and the concept of HATs dies with it.

/Andy

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5876
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: HAT design - Vendor info atom

Wed Oct 03, 2018 7:46 pm

RattusRattus wrote: Given that the identification of a HAT is not possible by looking at structured content of the EEPROM why even bother with the EEPROM in the first place?
What do you mean it's not possible? I don't see how you could look at the vendor string and product ID and not be able to tell what the product is. If you put something silly in there sure, but... don't do that. The main strength of the EEPROM is that you can put a device tree blob in there and have the drivers you need loaded automatically by the firmware. Being able to configure pins is nice too, if your HAT needs it.

There are vendors who put an EEPROM on their board to be able to call their hardware a HAT, although it doesn't need the EEPROM. If your device doesn't need kernel drivers loaded or anything else stored in the EEPROM, then I'd say your product doesn't need to be a HAT.
RattusRattus wrote: hope that nobody else uses the same atom structure I pick
Why would somebody intentionally release a product pretending to be another vendor? Why would people buy it? Sure, it's possible that somebody just clones your board, but the HAT spec isn't intended to protect you from that. You can put a cryptoauthentication chip on your board if that's a concern.
RattusRattus wrote: As HATs are not considered stackable then there is no point on trying to determine what hardware resources you have available and software needn’t look because *ALL* of the resources must be available (guaranteed by the rule there shalt be one HAT and one HAT only).
It's not about hardware resources availability, it's about automatically configuring the things so that the user doens't have to do it manually.
RattusRattus wrote: I note also that the PoE HAT breaks the rules for HATs already (I2C address) - a special case for this 'stackable' HAT. But then other people will argue that their HAT is a special case too and the concept of HATs dies with it.
They can argue it all they want, but that won't change the behaviour of the firmware. The spec would need to be updated before this second address is made available to others. That's something that could happen, but they'd need to make a good case. For PoE HAT, this was allowed because it doesn't use any other pins, so it's guaranteed to be stackable. If somebody else has a HAT that doesn't use any pins, then how would it benefit from the EEPROM?

RattusRattus
Posts: 60
Joined: Sat Sep 29, 2018 11:27 am

Re: HAT design - Vendor info atom

Wed Oct 03, 2018 9:21 pm

Hi again

I guess I see the use case differantly to you <shrug>

I agree having the device tree blob stored on the HAT is fundamental for kernel driver use, it is the rest I am struggling with.

WRT the EEPROM content I get and uncderstand the headder and atom3, I still struggle to 'see' the obvious for the rest

The Vendor info atom is what I had assumed that I should be (indirectly) looking at from within user space aplications to confirm I have the resources that the application is expecting. With a 16 bit PID field and a free-for all then collisions are inevitable, making the use of the PID pointless - hence my (flipant remarks) about using atom 4 to control this instead. Sure I can (and will) look at the vstr instead.
Why would somebody intentionally release a product pretending to be another vendor? Why would people buy it? Sure, it's possible that somebody just clones your board, but the HAT spec isn't intended to protect you from that.
Unfortunatly the world is full of clone-alike IO boards. They tend to be cheeper (in that they often miss out some protection, race hazard preventions, EMC imission control etc) in the race to the minimum possible solution for 80% of the use case. People purchase the lower cost item before they find that out. I was hoping to find parts of the HAT spec that would help here. As you said - not intended for this use.

It's not about hardware resources availability, it's about automatically configuring the things so that the user doens't have to do it manually.
Where 'things' to be configured are resources, but yes given no stacking they will always be available on the HAT.
I agree entirly having software do the right thing so the user doesn't have to jump through setup hoops is the way to go.


Having fixed addressing for an EEPROM to store that blob rarther than a discoverable system is a flaw in my opinion (perhaps searching for multiple EEPROMS at differant addrsses and simple user selectable address' on the HAT or having the EEPROM on the a 1-wire bus where discoverability is part of the protocol). Without this I struggle to see how stackable HATs *could* eventually be achived, even if stackable HATs had been shelved for now. It was somthing I really wanted to see, I have several use cases for them, and this is where most of my disapointment stems from.


WRT PoE - I was trying to say how easy it is for standards to collapse once 'special snowflakes' are introduced. I wasn't trying to pick a fight - sorry if that is how I came across.

/Andy

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5876
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: HAT design - Vendor info atom

Wed Oct 03, 2018 11:00 pm

RattusRattus wrote: I wasn't trying to pick a fight - sorry if that is how I came across.
Hey, I'll address that first to get it out of the way. I didn't pick up any sort of aggressive tone at all and hope I didn't give any off either. I get where you're coming from and was just trying to address the points raised.
RattusRattus wrote: The Vendor info atom is what I had assumed that I should be (indirectly) looking at from within user space aplications to confirm I have the resources that the application is expecting. With a 16 bit PID field and a free-for all then collisions are inevitable, making the use of the PID pointless - hence my (flipant remarks) about using atom 4 to control this instead. Sure I can (and will) look at the vstr instead.
The idea is that you'd use both. You look up the vendor to figure out who makes it and use the product ID to figure which of the vendor's products it is.

Return to “HATs and other add-ons”