Beagleboard Cape Integration into the Linux Kernel

Hi Everyone,

I just sent off my prototype Inertial Sensing Cape for fab and I am
starting to look at the board level integration. (I will post gerbers
+ schematics once I have verified functionality. There is no reason
to populate the web with unproven designs) I have pulled the linux
3.0 sources from the meta-ti branch of the https://github.com/beagleboard/linux
tree and have looked through the board-am335xevm.c. I am sensing that
the cape management subsystem hasn't been solidified yet.

I was wondering if anyone could provide insight into:

1.) What is the high level plan for the pin muxing and board
initialization?

        - ( My understanding is that the i2c-2 bus will probe each
eeprom cape address and identify if a board is present. From there,
does the board file read and implement the pin muxing information
stored in the cape's eeprom? Or does the board just do a matching
process on the cape name to run the correct configuration function?
It appears like the DVI cape configuration is being hard coded as a
peripheral at build time.)

2.) Has anyone envisioned a form of conflict resolution if multiple
capes all want the same resources?

Thanks for the guidance. I would prefer to do the integration once
and in a manner that everyone can refer to for further designs.

-Colin

Hi Everyone,

I just sent off my prototype Inertial Sensing Cape for fab and I am
starting to look at the board level integration. (I will post gerbers
+ schematics once I have verified functionality. There is no reason
to populate the web with unproven designs) I have pulled the linux
3.0 sources from the meta-ti branch of the GitHub - beagleboard/linux: The official Read Only BeagleBoard and BeagleBone kernel repository https://git.beagleboard.org/beagleboard/linux
tree and have looked through the board-am335xevm.c. I am sensing that
the cape management subsystem hasn't been solidified yet.

The current code reuses the code for TI EVMs which is utterly broken by design. It depends on people flipping a few dipswitches and hoping there are only 8 combinations.

I was wondering if anyone could provide insight into:

1.) What is the high level plan for the pin muxing and board
initialization?

       - ( My understanding is that the i2c-2 bus will probe each
eeprom cape address and identify if a board is present. From there,
does the board file read and implement the pin muxing information
stored in the cape's eeprom? Or does the board just do a matching
process on the cape name to run the correct configuration function?
It appears like the DVI cape configuration is being hard coded as a
peripheral at build time.)

The current plan we have:

1) Encode name, manufacturer, website in the eeprom
2) encode the pins the cape needs and their mux setting in the eeprom
3) Have uboot read the eeprom and setup the resources accordingly

What happens with the kernel is still up in the air, since there is no bone support in mainline and by the time it will be there devicetree will be there. In the DT world:

3a) have uboot assemble a DT containing all the resources and pass it to linux

Matt Porter has a good proposal for the EEPROM format we need to discuss next week and see if we can get it to work with the DVI cape. For the time being I'd advice using the echo something 0xaddress > new_device for simple I2C devices, for SPI and things like accelerometers with an interupt line hacks to the boardfile.

2.) Has anyone envisioned a form of conflict resolution if multiple
capes all want the same resources?

Yes, it's up to the person plugging those in to fix that. The only sane thing we can do is issues warnings in uboot and linux about it. Documentation for the default config of all the pins is also missing, which is also in the TODO for next week.

So not much helpfull info yet, but we need to get cape designers to weigh in on all this for it to work.

regards,

Koen

Koen,

Thanks for the response. If there is anything that I can do to help
to formalize the structure please tell me.

For the time being, (and the prototypes), I am going to hack together
a hard-coded boardfile to verify driver/hardware functionality.

Thanks and please keep me in the loop as the cape framework
solidifies.

-Colin