[RFC] Expansionboards and mainline kernel support

Hi,

With more and more expansionboards seeing the light (I now have 3 different ones on my desk) we need to find some agreement on hardware are software points:

Hardware:
  Ideally every expansionboard has an eeprom that contains some bits that will let the kernel and uboot know which board is attached. If we have a standard we could write a uboot method that sets up the mux accordingly and/or a kernel module that does the same.

Software:
  Adding devices to board-omap3beagle.c file isn't going to scale well and I can foresee conflicts, so we need some form of buildtime and runtime checks that will do the right thing for your expansion board(s).

I'm not a hardware guy nor a kernelhacker, so please point out the (in)sanity of all this if you are one :slight_smile:

regards,

Koen

The EEPROM that is on the Zippy board is the standard for the EEPROM. All boards will have this exact device and configuration on the expansion board. What needs to be determined is the data to be contained in the EEPROM from a Software perspective. Maybe a good format would be one that determineds what the Mux settings are for each pin and the default state. That way we do not require a central database based on Board and Supplier, but instead let the EEPROMM data tell the SW what to do. Obviously we cna also have other date in the EEPROM, like board name, revsion, supplier, etc.

Gerald

The EEPROM that is on the Zippy board is the standard for the EEPROM. All
boards will have this exact device and configuration on the expansion
board. What needs to be determined is the data to be contained in the
EEPROM from a Software perspective. Maybe a good format would be one that
determineds what the Mux settings are for each pin and the default state.
That way we do not require a central database based on Board and Supplier,
but instead let the EEPROMM data tell the SW what to do. Obviously we cna
also have other date in the EEPROM, like board name, revsion, supplier,
etc.

Gerald

From a software prospective, I think a vendor:product is a must. The first
reason is the pinmux is insufficient to tell software what drivers it needs.
And even if it is from the same vendor, the same functionality may be done
with different chips on different vendors. A week or so ago, sakoman and I
talked about this on IRC. I think the conclusion was he would try it out on
the Overo first.

On the kernel side, I agree that patching the board file would get out of
hand. But anything we decide on should also have the approval of our
upstream, the L-O folks. There is no reason to have different approaches for
the different boards. Off hand I can think of at least 2 other boards in a
similar situation - the Logic PD modules, and the Overo. I would like to
propose the following. Depending on the feedback here, I can post it on the
L-O list.

We create a directory in arch/arm/mach-omap2/add-ons to contain expansion
board code. This would be very similar to what is done in the current board
file (register I2C/SPI/etc, grab GPIOs, etc). Each of these files can be
included or excluded based on Kconfig. Keeping in line with the rest of the
tree, the files should not be mutually exclusive if possible.

The board file would then be patched to read the EEPROM and call the add on
board init function to do its thing. This patch would be basically an array
containing the {vendor id, product id, and function pointer to the init.}.
The board file would read the I2C EEPROM and attempt to match it with the
array. The array entries can be included or excluded based on kconfig. This
entire mechanism should be controllable via Kconfig entry. Most of this code
should probally be marked with __init unless we want to allow for hot
plugging.

Thoughts, comments?

Just to be clear. I will not be the person responsible for granting and tracking vendor and product IDs, so you need to figure out how that is handled.

Gerald

Gerald Coley wrote:

Just to be clear. I will not be the person responsible for granting and
tracking vendor and product IDs, so you need to figure out how that is
handled.

Two answers:

- What should be in the eeprom:

I'd like to learn from ARM's machine ID. That is, I think to have
"just a number" in eeprom is enough. If this number is composed by
vendor:product ([31:16] and [15:0] of the first 32bit of that
eeprom?) this is fine. Everything else can be done based on
(U-Boot/Kernel) software. Don't put to much stuff into the eeprom.
Most probably we will end with something like broken ACPI tables, then.

- How to deal with vendor:product IDs:

Again, learn from ARM's machine IDs and coordinate this by a simple
web page. Wouldn't it be sufficient to start with a wiki table?

Best regards

Dirk

A wiki page works for me. I would like to see us keep it as simple as possible.

Gerald

Totally agree with this approach – Keep it as simple as absolutely possible in order for everyone to contribute as easily as possible J

Best regards – Looking forward to this J

Søren

A wiki page works for me. I would like to see us keep it as simple as possible.

Gerald

Gerald Coley wrote:

Just to be clear. I will not be the person responsible for granting and
tracking vendor and product IDs, so you need to figure out how that is
handled.

Two answers:

  • What should be in the eeprom:

I’d like to learn from ARM’s machine ID. That is, I think to have
“just a number” in eeprom is enough. If this number is composed by
vendor:product ([31:16] and [15:0] of the first 32bit of that
eeprom?) this is fine. Everything else can be done based on
(U-Boot/Kernel) software. Don’t put to much stuff into the eeprom.
Most probably we will end with something like broken ACPI tables, then.

  • How to deal with vendor:product IDs:

Again, learn from ARM’s machine IDs and coordinate this by a simple
web page. Wouldn’t it be sufficient to start with a wiki table?

Best regards

Dirk

Gerald Coley wrote:

A wiki page works for me. I would like to see us keep it as simple as
possible.

Just a proposal:

http://elinux.org/BeagleBoardPinMux#Expansion_boards

It's a wiki, change, add or delete what you don't like or what is missing.

Dirk

Content looks good. I prefer that this be a dedicated Wiki page just for this information or at tlest move the boards toward the top. It could also be a way to advertise the boards for those people who are looking for boards. This gives them one spot to come and see what is there.

Gerald

Gerald Coley wrote:

Content looks good. I prefer that this be a dedicated Wiki page just for
this information

Yes, I agree. When we found the final style and content, we can easily
move it to BeagleBoardExpansionBoards.

It's just a quick and dirty start proposal :wink:

Dirk

Works for me!

Gerald

Suggestion,

If you are going to standardise around an EEPROM identifier chip for add
on boards, there should be a simple schematic extract on that wiki
page, or another wiki page for developers, showing the technical details
so all boards are implemented in the same way.

It would be bad to have to probe different EEPROM types/connection
methods/I2C addresses etc.

Strontium

Gerald Coley wrote:

There will be such an item to follow provided. In fact, the standard for this was decided several months ago. It will also be reflected in an updated System Reference Manual.

Gerald

Also, it would be great if some references on to program the EEPROMs would be great.

Thanks,
–Krishna/.

Strontium wrote:

Suggestion,

If you are going to standardise around an EEPROM identifier chip for add
on boards, there should be a simple schematic extract on that wiki
page, or another wiki page for developers, showing the technical details
so all boards are implemented in the same way.

This is what

http://elinux.org/BeagleBoardPinMux#Hardware_2

is intended for.

Anybody already with the schematic for this anywhere? Zippy schematic
is "coming soon".

Best regards

Dirk

Attached. It connects to the I2C pins on the expansion connector.

Gerald

EEPROM_SCHEM.bmp (1.24 MB)

are going to standardise around an EEPROM identifier chip for add on boards, there should be a

Sorry for the stupid question, but please add this FAQ: "why add an eeprom instead of putting the identifier table somewhere in the flash memory? (last sectors, or inside mlo/uboot/etc...)"

Another stupid question to add to the Beagleboard FAQ: "why pinmux config has to be in the uboot or kernel? a root-privileged executable, at /etc/init.d time, could setup mux (it only has to write some data on some precise physical memory address)"

Thank you.
alf

2009/9/1 Alfonso Martone <alfonso.martone@gmail.com>

Another stupid question to add to the Beagleboard FAQ: “why pinmux
config has to be in the uboot or kernel? a root-privileged
executable, at /etc/init.d time, could setup mux (it only has to
write some data on some precise physical memory address)”

There are no stupid questions.

Its ARM kernel policy IIRC. theres nothing stopping you redefining it in a script if you want to…

Alfonso Martone wrote:

are going to standardise around an EEPROM identifier chip for add on boards, there should be a

Sorry for the stupid question, but please add this FAQ: "why add an eeprom instead of putting the identifier table somewhere in the flash memory? (last sectors, or inside mlo/uboot/etc...)"

Which flash? The flash on the BeagleBoard can't know which expansion board is connected. You need the information on the expansion board. And from SW point of view (sorry HW guys :wink: ) an EEPROM is something like 'flash' on expansion board.

Another stupid question to add to the Beagleboard FAQ: "why pinmux config has to be in the uboot or kernel?

Because you need pin mux as early as possible

- to be able to correctly access peripherals by drivers in U-Boot and Kernel
- to make sure that wrong pin mux doesn't break anything

Best regards

Dirk

Is there any facility planned for having more than one expansion board
connected to a Beagle? Or, is there an assumption that any expansion board
added to Beagle would be a combination board offering all necessary added
features? For multiple expansion boards, there would probably need to be a
different I2C address for the EEPROM on different boards.

I ask about this because one might want an LCD expansion board and a Zippy or
similar board, for instance. Other expansion combinations might be possible
also, as more expansion boards are designed and made.

There might be expansion boards oriented towards areas such as robotics and
process control, for instance. It would be great to be able to have a board
like this be able to work along side a Zippy and an LCD board. Other area
specific expansion boards would also be possible.

Something like a TCT Breeder with a larger Atmega processer (Atmega1280 or
Atmega 2560) with nice 3 pin headers for connecting servos and sensors to, I2C
and SPI brought out to headers, and all UARTs on headers, would be nice. The
Atmega could handle all direct interfacing with the outside world (at
selectable 3.3V or 5V for I/Os in groups of 4 or 5 pins or per specific
header), and could be made compatible with the Arduino environment as well as
be programmed in the standard AVR environments. Interfacing with Beagle could
be done through different methods such as serial, I2C, SPI, or whatever is
appropriate for the given application. Basically this could be a super
Arduino (and more) on an expansion board. :slight_smile: Maybe the only level shifting
that would be required would be on the I/Os used for inter processor (Beagle
<-> AVR) communication.

An expansion like this would find uses in robotics as well as general process
control and maybe work along with a Zippy and/or LCD expansion board. There
are many more uses for a board like this, besides just robotics. I mention the
Atmega1280 (128k) and Atmega2560 (256k) because they have lots of program
memory, 16 analog inputs, quite a few PWM outputs, several UARTs, etc. I only
focus on robotics specifically because this is the area I know most about and
am working with. :slight_smile:

Am I just dreaming here? :wink: I'm sure others here can come up with similar
combinations of expansions that would be desirable.

  8-Dale