Auto-Identify expansion boards

19 views
Skip to first unread message

Dirk Behme

unread,
Apr 17, 2009, 2:50:50 PM4/17/09
to beagl...@googlegroups.com

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


Gerald Coley

unread,
Apr 17, 2009, 2:56:40 PM4/17/09
to beagl...@googlegroups.com
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

Hunyue Yau

unread,
Apr 17, 2009, 3:12:34 PM4/17/09
to beagl...@googlegroups.com
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.
--
Hunyue Yau
http://www.hy-research.com/

Gerald Coley

unread,
Apr 17, 2009, 3:28:58 PM4/17/09
to beagl...@googlegroups.com
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

Dirk Behme

unread,
Apr 17, 2009, 3:34:25 PM4/17/09
to beagl...@googlegroups.com
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? ;)

Dirk

Jason Kridner

unread,
Apr 17, 2009, 3:34:56 PM4/17/09
to beagl...@googlegroups.com
Instead of making some new approach, why not just use the Bug Labs approach?

Gerald Coley

unread,
Apr 17, 2009, 3:36:58 PM4/17/09
to beagl...@googlegroups.com
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

Gerald Coley

unread,
Apr 17, 2009, 3:38:13 PM4/17/09
to beagl...@googlegroups.com
Which is?
 
Gerald

Preston Wilson

unread,
Apr 17, 2009, 3:40:51 PM4/17/09
to Beagle Board
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

On Apr 17, 3:36 pm, Gerald Coley <ger...@beagleboard.org> wrote:
> 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
>
> On Fri, Apr 17, 2009 at 2:34 PM, Dirk Behme <dirk.be...@googlemail.com>wrote:
>
>
>
> > 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? ;)
>
> > Dirk
>
> > > On Fri, Apr 17, 2009 at 1:50 PM, Dirk Behme <dirk.be...@googlemail.com

Gerald Coley

unread,
Apr 17, 2009, 3:44:05 PM4/17/09
to beagl...@googlegroups.com
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

Gerald Coley

unread,
Apr 17, 2009, 3:57:11 PM4/17/09
to beagl...@googlegroups.com
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
'

On Fri, Apr 17, 2009 at 2:40 PM, Preston Wilson <rpwil...@gmail.com> wrote:

Nishanth Menon

unread,
Apr 17, 2009, 4:33:58 PM4/17/09
to beagl...@googlegroups.com
On Fri, Apr 17, 2009 at 2:57 PM, Gerald Coley <ger...@beagleboard.org> wrote:
> 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.

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

Gerald Coley

unread,
Apr 17, 2009, 4:43:45 PM4/17/09
to beagl...@googlegroups.com
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

Jason Kridner

unread,
Apr 17, 2009, 5:05:48 PM4/17/09
to beagl...@googlegroups.com

Gerald Coley

unread,
Apr 17, 2009, 5:12:23 PM4/17/09
to beagl...@googlegroups.com
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

Dirk Behme

unread,
Apr 18, 2009, 2:39:15 AM4/18/09
to beagl...@googlegroups.com
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

Preston Wilson

unread,
Apr 18, 2009, 8:59:21 AM4/18/09
to Beagle Board
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
Reply all
Reply to author
Forward
0 new messages