Preliminary B+ HAT (Hardware Attached on Top) docs/specs

[James Adams]

Preliminary docs are here on Github: https://github.com/raspberrypi/hats

The docs are still changing. We want to lock down the spec by the end of the week. Sensible comments welcome

Note we are now working on the software to create and flash the HAT EEPROM, hopefully complete by the end of the week also.

[EDIT - update subject to be more descriptive]

[gordon@drogon.net]

Looks good so-far, but am I right in thinking that if I plug a "legacy" (26-pin board, or any board without an ID eeprom) on the Pi then the behaviour of the pins will be as before - I'm mostly thinking about the serial pins here..

Ta,

-Gordon

[Gswg]

Thanks James, this is very useful.

Is there recommendation on the part numbers to use for "stackable" connectors please?

It would also be useful to have any defined PCB face2face distances etc. I am assuming (maybe incorrectly) that any PCB which contains components > 11mm in height will, by default, be non-stackable?

Gordon, I plugged in our 26way Pi-DAC card into the B+ and the serial lines worked as expected.

Best regards,

Gordon@iqaudio.com

[James Adams]

The current firmware hasn't moved to the 'new world' yet - but it is very nearly there.

Basically we're moving to doing things 'the right way' using device tree: http://www.devicetree.org/ and a thing a bit like it called gpioman which sets up GPIOs that are used exclusively used by the GPU (e.g. power LED, but also clocks).

So on a B+ you will need to enable hardware using this method (on HATs with EEPROM the EEPROM contains a device tree fragment for the hardware on the board and so Linux will set it all up & load drivers). Otherwise prviding a DT blob to drop onto the /boot partition will do the same job.

For legacy 26 pin GPIO support there will be a config.txt parameter (and raspiconfig menu entry) that will force a default device tree that sets things up in legacy mode (UART and I2C support). HOWEVER on a B+ the EEPROM will still be probed if this legacy option is set, and if detected it will fall back to a safe mode (all pins inputs with pulls) to stop users accidentally setting this option but having a B+ HAT attached.

[PeterO]

A couple of comments from a first read through..

I think it would be a good idea for there to be a statement early on that "input" and "output" refer to the view from the PI and that view then needs to be used consistently. Currently there are places where both views are used.

The case of a non-stackable board on top of a stackable board does not seem to be covered. Is it allowed ? If so then the non-stacking board's assumptions on having the default pin states may be wrong.

PeterO

[James Adams]

TBH we've been on the fence over whether the whole stacking boards thing is a good idea due to the added complexity - and as PeterO and Gswg have pointed out there are still holes in the spec (non-stacker on stacker, and we'll need to spec connectors and board spacing).

So after some more internal discussion we've decided to drop this as a supported feature (also we're not sure how often it would actually get used, and if, given the complexity, it would actually be implemented correctly all the time even if we could resolve the remaining issues).

Nothing stops people 'manually' configuring and using unused pins if they know what they are doing.

[PeterO]

So after some more internal discussion we've decided to drop this as a supported feature (also we're not sure how often it would actually get used, and if, given the complexity, it would actually be implemented correctly all the time even if we could resolve the remaining issues).

That is disappointing to hear. It shouldn't be impossible, after all there are examples of self configuring busses in other machine architectures... Hands up who can remember the last time they had to set IO addressed and Interrupt lines on a PC card ?

Nothing stops people 'manually' configuring and using unused pins if they know what they are doing.

I suppose the issue is to find the correct(ish) balance between flexibility and complexity of implementation. Maybe by imposing some constraints on flexibility the implementation could be made manageable ?

It may only be the hard-core interface builders that would want to stack boards, but with the availability of the extra GPIO pins there may be more use cases which put a new 40 pin board on first and an older 26 pin board stacked on top, who knows ????

PeterO

[James Adams]

Yes it is a little disappointing - but it was getting complex (we were already thiking this but decided to throw it out there initially anyway). Yes in the past people had to set jumpers for ISA IRQs and whatnot on older hardware, but it was always a source of confusion for the not-too-technical.

It is exactly those people we're trying to make life easier for - so complicating the spec for a feature that may not be often used (and may make implementation more difficult to get right) in the end felt like a bad idea.

Stacking a 26W board on a 40W one would not have worked in our ideal world anyway as there was no way for the B+ to 'see' the 26W board (no EEPROM) so you would still have to set it up manually and know what you were doing.

Nothing stopping people stacking boards on top it is just not officially supported (by officially I mean you need to know what you are doing - and do it at your own risk - which is basically the deal for Pi A and B anyway so nothing has been 'lost').

[mikronauts]

C'est la vie.

A bit disappointed, but it won't stop me from making '+' boards

I tried to view the mechanical spec pdf from the link in the first post of this thread, but it was corrupted. Could it be posted to this thread?

[James Adams]

I tried to view the mechanical spec pdf from the link in the first post of this thread, but it was corrupted. Could it be posted to this thread?

Did you clone the Git repository? I don't think you can view directly via Github.

[hippy]

So after some more internal discussion we've decided to drop this as a supported feature ...

It feel it would be worth delaying that decision until after a more public discussion on the issue.

If people are going to produce stackable boards there is little which can be done to prevent that, so IMO better to accept that and at leas thave some de facto standard to comply with rather than the mess which is likely to arise if everyone goes their own way.

[James Adams]

It feel it would be worth delaying that decision until after a more public discussion on the issue.

If we wanted to keep the stacking we would have to mandate an ID EEPROM for all B+ HATs, and then still have to spread the word that you could not stack 26W boards on top - so there would still be a 'manual setup' setp. It is easier to spread the message that stacking boards is not (officially) supported and if you do you do it at your own risk.

And again, it complicates the spec for a minority use case.

So currently stackable is still out (but we reserve the right to change our minds in the nex day or so...!).

[mikronauts]

Time for a Homer moment.... "DUH!"

That worked, thanks.

Now I'll go and get more coffee, as I obviously need it..

I tried to view the mechanical spec pdf from the link in the first post of this thread, but it was corrupted. Could it be posted to this thread?

Did you clone the Git repository? I don't think you can view directly via Github.

[bbodin]

Mandating an ID EEPROM on all stackable boards doesn't resolve the issue where more than one board use the same pin for output to the B+. It would also require all boards to use output drivers with current limiting and indefinite short-circuit protection.

The GPIO port has no physical layer for protection against conflicts. Until there is a well thought-out architecture for using the GPIO port as a bus for stackable boards, dropping the official support for these boards is probably a good idea. It potentially avoids finger-pointing and legal issues down the line.

[rotwang]

Just recap for me, is device tree support (which would be a god-send for the compute module) coming, coming real-soon-now(tm), or dead in the water.

[gordon@drogon.net]

Just recap for me, is device tree support (which would be a god-send for the compute module) coming, coming real-soon-now(tm), or dead in the water.

As I see it, the CM isn't "general purpose" - it will be built into specific applications with a specific set of drivers compiled into the kernel for that application (and no more - or at least that's the way it would be were I designing it into something). I don't see that having an ID system for the CM would give it anything... But I could be wrong!

-Gordon

[ShiftPlusOne]

Just recap for me, is device tree support (which would be a god-send for the compute module) coming, coming real-soon-now(tm), or dead in the water.

To some extent, it's already in the firmware. https://github.com/raspberrypi/firmware ... 9e1b1a1eb6
Dom uploaded this dt-blob.bin in another thread:
https://dl.dropboxusercontent.com/u/366 ... t-blob.bin
You can convert it to a dts file, modify it, convert it back to a dtb file and save it under /boot/dt-blob.bin and it will be used to configure the pins automatically, for example.

[mikronauts]

If the i2c bus was scanned for all eight eeprom addresses, up to eight add-ons could be supported at once - each board would need to be able to strap its eeprom's address.

If there was a need for multi-function boards, each eeprom address could allow for say eight 2k blocks in each eeprom, which would then support 8 boards with up to 8 devices each - which I'd suggest is more than plenty.

[simplesi]

How much do we think this board identity eprom circuitry is going to cost to add in?

Simon

[gsh]

Just to be clear...

gpioman support and the introduction of the ability at add a dt-blob.bin is not the same as the kernel device tree implementation...

We've recently added gpioman support into the firmware, this takes a dt-blob.bin file from the first partition (/boot) and uses it to configure the initial pin settings (the alternate settings) and the pin configuration.

This way if you are creating a new compute module board you can use this file to move the camera gpio pins around or the LAN_RESET pin or the 25MHz clock output (or to output a special second GPCLK output and configure the clocks for it). Although this file is a dtb file it is not a full device tree implementation for the linux kernel.

The full implementation is coming and we are working on it (mostly by rewriting significant numbers of drivers to enable us to upstream our drivers!) We hope to get this working in the long term but it's still some months away

Gordon

[jackokring]

The title is vague, at least from the new posts click link, and the content is/was not apparent. But having read, I see. For most simple people stacking is out, which is good. Being able to override the EEPROM with a stacked user choice is essential although rare, otherwise why buy some boards? Or maybe the EEPROM should be socketed or "power/data offable..."

Input and output have always been defined from the board doing the local or mastering of the IO not the one connected to it. This includes the pi as a slave to the hat master. I think this is a good one on the fizz bang not effect.

If the ID wires are considered for just ID use, then maybe a mini 2 by 6 aux IO for small boards will arise. How many 26-way boards will cover the ID pins?

EDIT: http://skpang.co.uk/blog/archives/575 and do the older boards now have a need to not use I2C address 0, on the bus before the switch around? And there is the obvious omission of a 3V3 within the new pins.

[James Adams]

EDIT: http://skpang.co.uk/blog/archives/575 and do the older boards now have a need to not use I2C address 0, on the bus before the switch around? And there is the obvious omission of a 3V3 within the new pins.

Not quite sure I understand the question. I2C0 (for rev2 B and now B+, it was I2C1 on rev1 B) is the I2C reserved for GPU use. It has never been recommended or supported to use the GPU's I2C on older models. B+ HATs should not use I2C0. Future things attached to the GPU may make even more use of it (for instance camera already does, new display does too for both control and for touch interface).

We can't stop people using it if they really want to, but we would actively recommend people avoid using boards that did this as they don't follow the spec.

[summers]

This is sounding very like the beaglebone and beaglebone black set up with capes.

How things are evolving with the beaglebone is maybe instructive, especially as capes have been part of the landscape for so long.

Now in the past, the beagle bone has used a cape manager, that has handled bringing up the capes. However with the evolution of the device tree, the approach for how to configure the hardware has changed. The problem that you have is that the add on board (capes in beagle bone) are hardware - and effecitvly end up being defined as part of the whole hardware system. In device tree land this is a bit of a mare - it pushes towards havig a different device tree blob for each configuration, e.g. when you change an add on board, you need to change the device tree blob. This is a big hassle.

Now the way the kernel developers see things going, is a device tree with many add ons defined in the tree - but not enabled as default. Now the beagle bone boots via u-boot; and u-boot has the ability to modify the device tree after loading, but before boot. So what is imagined is enabling add on boards in u-boot, before booting to linux.

All this area is currently very active at the moment - its an area of both u-boot and the kernel, that is rapidly evolving. The cape manager approach is having a harder time getting into the mainline kernel - its a less happy fit.

Now fast forward to the RPi B+, it doesn't boot via u-boot, but via a GPU blob. Now if it goes the same way as having add on boards defined in the device tree - how will that be managed? E.g. will you be able to modify the device tree before booting into linux? Does the GPU blob have that functionality? Or is the RPi going in the cpae manager direction, which means a certain amount of forking from the mainline kernel?

[James Adams]

On BCM2835 (Pi SoC) the GPU boots first, then brings up the ARM and boots the Linux kernel so you kind of have a boot manager right there...

The ID EEPROM (read by the GPU) contains a device tree 'fragment' which is merged (by the GPU) into the main board device tree before being handed to the Linux kernel when it is loaded and control passed to the ARM.

[FLYFISH TECHNOLOGIES]

Hi,

I haven't noticed information about the ID I2C bus speed (alias the speed this ID EEPROM must support).

Recommended CAT24C32 supports 100k, 400k and 1M Hz, but I'm wondering if another EEPROM supporting only slower bus can also be used.

Additionally, information if clock stretching is supported would also be valuable.


Thanks & Best wishes, Ivan Zilic.