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
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