Auto-Identify expansion boards

It seems we get more and more expansion boards connected to Beagle's expansion connector. Different expansion boards might need different pin mux and other configuration changes in SW, e.g. in U-Boot and/or Linux kernel.

From the discussion at this list and at IRC we learned that especially the pin mux configuration is confusing again and again. It would be nice if we could avoid that each expansion board needs its own U-Boot and Kernel (<= recompilation, x binaries). So best would be to autodetect if and which expansion board is connected to Beagle and then configure it automatically by SW. Example is OMAP Linux kernel multi boot feature based on machine ID or Beagle rev Bx/rev C detection based on GPIO states.

But for this we need a way to make SW able to detect which expansion board is connected.

Idea was now to have something like an I2C EEPROM on *each* expansion board which can be read by SW to get an explicit ID from each board. This could use Beagle's i2c2 on the expansion connector (Overo could use i2c3, btw).

What do you think?

If you like this, what do we have to standardize to make this work?

Best regards

Dirk

I think this is a good idea. I will work to come up with a standard on this from a HW perspective. It will be an I2C based EEPROM of the lowest cost I can find. Once I come up with that and the addressing, I will let everyone know.

We will need someone in the community to own the data format and how we format the data in the EEPROM.

Gerald

Are there common, easy to source 1.8V I2C EEPROMs in reasonable packages
(SOT-23 or something leaded with a pitch >= 0.5mm)? I would hate have to
put level converters on a board just for the id ROMs. Otherwise, prehaps
a SPI EEPROM as level conversion for SPI is a lot simplier, but does burn
an additional pin. 1wire would be the fewest pins but that puts us back
into less then trivial level conversions.

Using the SPI is out of the question as that would rule out using those signals for their other functions.

A 1 wire interface is not brought out to the expansion header so that rules that out.

So, the solution that does not burn any pins is the I2C. As you say they are easy to source and I will keep them at 1.8V. This does not preclude others from level shifting the downstream I2C, but it also does not force the addition of level shifters for the EEPROM.

Gerald

Gerald Coley wrote:

I think this is a good idea. I will work to come up with a standard on this
from a HW perspective. It will be an I2C based EEPROM of the lowest cost I
can find. Once I come up with that and the addressing, I will let everyone
know.

We will need someone in the community to own the data format and how we
format the data in the EEPROM.

Do we need a "Beagle ready" logo for expansion boards which comply
with this standard, then? :wink:

Dirk

Instead of making some new approach, why not just use the Bug Labs approach?

Well, that may not be an bad idea, but I don’t know if I can handle that. I just used up my last of 8 arms doing the EEPROM piece. Octo Man is all booked up!

Gerald

Which is?

Gerald

How will this work with multiple (stacked) cards? Or is that off
limits?

I hate throwing this out there, as I have to leave, and I won't be
able to participate again until much later.

I think it is a good idea, and I have built two expansion cards, so I
have an interest in what is chosen.

-Preston

Nice way to keep the conversation going! I would like to be able to handle this. The rub here is the addressing. Let me think on ths and see how we can manage it. I know a way, but I need to see how it flows in a practical implementation. Can we set a limit of two stacks?

Gerald

I have a suggestion. We come up with 8 classes of boards, one for each address. Such as LCD, communications, IO, etc. Each class will have its own address. The restriction would be that only one board form each class of board could be plugged in at any one time, but all classes could have at least one plugged in at a time. I honestly don’t see us having eight boards at a time.

Inside the EEPROM will be kept the resources each board needs. That way we know how to configure the expansion pins on the processor. We could, if we wanted to go this far, also have in there, the functions the board provides, such as serial ports, LCD size, SD/MMC. WLAN, etc.

Gerald

FYI - we did something like this with SDP (from SDP2430 onwards) to
identify the various component boards (yes, it has EEPROM and yes it
has a standard too) -> it is a nightmare trying to maintain them after
a while. if we go with an EEPROM plan, then:
a) maintain a website where one can request for a ID -> this could be
done with some scripting on beagleboard.org
b) the generated file needs to imported to kernel/u-boot on a regular basis.
c) this also should be able to generate eeprom data ==> we need to
provide someway to program these eeproms in u-boot or kernel at it
should be doable at a production floor.
d) having info on type of LCD, timing, SD/MMC WLAN etc will go pretty
fast out of scope fast. my recommendation (with the inspiration of the
KISS rule) is just to have the following info in the:
info in Eeprom:
   i) board ID (a defined offset - say 0x0 for 4 bytes)
   ii) board revision ( a defined offset say 0x4 for 2 bytes)
   iii) manufacturer specific details -> offset 6 onwards.. allows
folks to use 128byte eeproms or 256 byte eeproms etc.. also allows to
store calibration data if required (e.g. a camera)..
info generated from website:
   map of ID to device capabilities - this can change over time, and
formats can be discussed and tweaked -> it is easier to do this
compared to deploying new data structures to boards out in the field.

IMHO, great idea -> but maintenance is more important than the data structures..

Regards,
Nishanth Menon

Yes, I know. That is exactly why I did not volunteer to keep up with it. But, nonetheless, I think we can limit this a lot more than the SDP did. Where the SDP had 3 or 4 boards, we just have the Beagle. So, this is limited to I/O boards.

Another way to do this, is to have each board contain the settings for the Expansion header. The UBoot reads it and sets the pins as required. It does not care about what is on the expansion board or what it is doing. With a common document, anyone can program their EEPROM as needed to work with the common UBoot. If someone wants to use two or three cards, it is up to them to set the information as needed into the EEPROM. This could then remove the need for keeping track of everything. We just have a function in UBoot that allows the user to program the EEPROM. We could then also include as well, the functions on the boards for the higher level OS functions, such as the driver loading.

The more flexible you make it, the complicated it gets.

Gerald

It is essentially:
http://svn.buglabs.net/svn/!source/8867/bug/trunk/bug-linux-2.6.27.2/drivers/bmi/bmi-device.c

The problem is that BugLabs has a dedicated I2C per slot. We only have one I2C port. Plus, the BugLabs bus is not configurable. The pinout of the Beagle bus calls for the functions of the pins to change complete functions based on the muxing options needed. It might be possible to use the BugLabs interface, but I would think the contents and the way we use that information would need to change. .

Gerald

Gerald Coley wrote:

Yes, I know. That is exactly why I did not volunteer to keep up with it.
But, nonetheless, I think we can limit this a lot more than the SDP did.
Where the SDP had 3 or 4 boards, we just have the Beagle. So, this is
limited to I/O boards.

Another way to do this, is to have each board contain the settings for the
Expansion header. The UBoot reads it and sets the pins as required. It does
not care about what is on the expansion board or what it is doing. With a
common document, anyone can program their EEPROM as needed to work with the
common UBoot. If someone wants to use two or three cards, it is up to them
to set the information as needed into the EEPROM. This could then remove the
need for keeping track of everything. We just have a function in UBoot that
allows the user to program the EEPROM. We could then also include as well,
the functions on the boards for the higher level OS functions, such as the
driver loading.

The more flexible you make it, the complicated it gets.

I vote for Nishanth's KISS rule. Just an ID, everything else can be
done in SW (e.g. tables indexed by this ID). Even the board revision
proposed by Nishanth I would omit. New board revision which needs an
other configuration? -> New ID.

But I would add a magic to be sure that the device is identified
correctly.

Proposal:

1) Bytes 0 - 3: Magic (e.g. 'BEAG' or 'EXID')
2) Bytes 4 - 8: ID
3) Bytes 9 - ..: Vendor specific

Best regards

Dirk

I like this variation, but I am not the one that will keep track of
the IDs. Probably obvious, but setting aside a small set of IDs for
testing/private use would be nice.

I also like the I2C address per board class to solve the multiple card
situation.

-Preston