Cape EEPROM Pinmux settings

Hi,

What is supposed to read the pinmux settings from a beaglebone cape
and set the pinmux? Is that part of u-boot, the kernel, or something
in userspace? Does said software already exist?

--Chris

Hi,

What is supposed to read the pinmux settings from a beaglebone cape
and set the pinmux? Is that part of u-boot, the kernel, or something
in userspace? Does said software already exist?

Ultimately, all of the above. Each should respect the settings in the EEPROMs.

You can read the values of the EEPROMs using the latest bonescript[1].

For example:
root@beaglebone:/var/lib/cloud9# node bonescript/eeprom.js
Reading EEPROM at /sys/bus/i2c/drivers/at24/1-0050/eeprom
Reading EEPROM at /sys/bus/i2c/drivers/at24/1-0051/eeprom
Unable to open EEPROM at /sys/bus/i2c/drivers/at24/1-0051/eeprom:
Error: ETIMEDOUT, Connection timed out
Reading EEPROM at /sys/bus/i2c/drivers/at24/3-0054/eeprom
Unknown EEPROM format: ffffffff
Reading EEPROM at /sys/bus/i2c/drivers/at24/3-0055/eeprom
Unable to open EEPROM at /sys/bus/i2c/drivers/at24/3-0055/eeprom:
Error: ETIMEDOUT, Connection timed out
Reading EEPROM at /sys/bus/i2c/drivers/at24/3-0056/eeprom
Unable to open EEPROM at /sys/bus/i2c/drivers/at24/3-0056/eeprom:
Error: ETIMEDOUT, Connection timed out
Reading EEPROM at /sys/bus/i2c/drivers/at24/3-0057/eeprom
Unable to open EEPROM at /sys/bus/i2c/drivers/at24/3-0057/eeprom:
Error: ETIMEDOUT, Connection timed out
Reading EEPROM at test-bone.eeprom
Unable to open EEPROM at test-bone.eeprom: Error: EBADF, Bad file
descriptor 'test-bone.eeprom'
Reading EEPROM at test-cape.eeprom
Unable to open EEPROM at test-cape.eeprom: Error: EBADF, Bad file
descriptor 'test-cape.eeprom'
{
  "/sys/bus/i2c/drivers/at24/1-0050/eeprom": {
    "header": "aa5533ee",
    "boardName": "A335BONE",
    "version": "00A3",
    "serialNumber": "4511BB000093",
    "configOption":
"0000000000000000000000000000000000000000000000000000000000000000",
    "type": "bone"
  }
}

If I had a cape with valid EEPROM contents, it would show the mux
values. schmux.js has examples on setting the mux values. Anyway,
this isn't all complete yet, but the idea is that bonescript will set
muxes.

There is also places where it is set in the kernel [2], thanks to [3].
Here is Koen's example output (with 2 capes with valid EEPROM
contents written using the above eeprom.js tools):
root@beagleboneA3-0457:~# dmesg | grep -i cape
[ 0.370327] BeagleBone cape EEPROM: found eeprom at address 0x54
[ 0.370348] BeagleBone cape: Beagleboardtoys BeagleBone DVI-D CAPE
[ 0.370364] BeagleBone cape partnumber: BB-BONE-DVID-01
[ 0.370377] BeagleBone cape: initializing DVI cape
[ 0.509767] BeagleBone cape EEPROM: found eeprom at address 0x55
[ 0.509788] BeagleBone cape: Towertech Towertech CAN Cape
[ 0.509803] BeagleBone cape partnumber: TT3201
[ 0.509815] BeagleBone cape: initializing CAN cape
[ 0.509826] TowerTech TT3201 CAN Cape

[1] https://github.com/jadonk/bonescript
[2] https://plus.google.com/100242854243155306943/posts/WSeQuaq9xeS
[3] http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-ti33x-psp-3.2/0004-beaglebone-rebase-everything-onto-3.2-WARNING-MEGAPA.patch

I don't think any work as started in u-boot for it yet, but my
expectation is that we'd respect the settings even there. U-boot
support would give us the opportunity to turn some things on during
boot if there was another Ethernet controller or SPI EEPROM or other
such things.

Hmm so something in the kernel is recognizing the EEPROM and parsing
it (at least partially). But is that actually setting pinmux there
(or intended to)?

I can see why you'd want U-Boot and the kernel to both respect the
settings. What I'm not following is why both kernel and userspace.
It gives me an idea, though, that I can support it in the short term
with scripts like you demonstrated. That's cool.

The other possibility that came to mind is drivers ... is there
infrastructure for a kernel module, on that module's _init perhaps, to
set whatever pins it needs however it needs?

Too many choices..... :slight_smile:

--Chris

root@beagleboneA3-0457:~# dmesg | grep -i cape
[ 0.370327] BeagleBone cape EEPROM: found eeprom at address 0x54
[ 0.370348] BeagleBone cape: Beagleboardtoys BeagleBone DVI-D CAPE
[ 0.370364] BeagleBone cape partnumber: BB-BONE-DVID-01
[ 0.370377] BeagleBone cape: initializing DVI cape
[ 0.509767] BeagleBone cape EEPROM: found eeprom at address 0x55
[ 0.509788] BeagleBone cape: Towertech Towertech CAN Cape
[ 0.509803] BeagleBone cape partnumber: TT3201
[ 0.509815] BeagleBone cape: initializing CAN cape
[ 0.509826] TowerTech TT3201 CAN Cape

Hmm so something in the kernel is recognizing the EEPROM and parsing
it (at least partially). But is that actually setting pinmux there
(or intended to)?

Right now it will call the init functions of those subsystems, which sets the pinmux and inits the clocks, etc. It does not use the mux settings from the EEPROM at all. As you might have guessed, this is not what we want to be using in the near future. On the TODO (anyone should feel free to tackle these items and send patches):

* Seperate mux setting and subsystem init - a good example is PWM, people don't want to see the linefetch errors when trying to use PWM and they don't want all PWM pins to be muxed as pwm. So init pwm, leave muxing to EEPROM or userspace.
* Write uboot code to parse eeprom and set mux
* Write kernel code to parse eeprom and set mux
* convert it all to device tree

I can see why you'd want U-Boot and the kernel to both respect the
settings.

To clarify: testing things in uboot or some RTOS should be supported, so uboot should have an option to read eeprom and set mux.

What I'm not following is why both kernel and userspace.

If we have a userspace app you can 'dry' test eeproms without having the actual cape attached. I don't think it should be used beyond that.

It gives me an idea, though, that I can support it in the short term
with scripts like you demonstrated. That's cool.

The other possibility that came to mind is drivers ... is there
infrastructure for a kernel module, on that module's _init perhaps, to
set whatever pins it needs however it needs?

Yes, but drivers get that info from the board file in most cases. But writing a custom module to tweaks things is an option.

regards,

Koen

I've been following this thread with some interest but it's partially over my head.. I have questions that are somewhat related to this.

If it's the EEPROM settings that configure the Pinmux,:
A. How does the cape/Bone know where it (the cape) is in the stack?
B. What happens when you get a cape without an EEPROM? (or will all capes be required to have one?)
C. If an EEPROM is required, then we'd have to have one on the breadboard when prototyping a new cape, yes? where can I find more info about this EEPROM and how to program it for the Bone.

anyone happen to have a whitepaper or a tutorial on how all this works?

I've been following this thread with some interest but it's partially over my head.. I have questions that are somewhat related to this.

If it's the EEPROM settings that configure the Pinmux,:
A. How does the cape/Bone know where it (the cape) is in the stack?

It doesn't. Well, you can play with the i2c address to run the inits in the "right" order when there are conflicts.

B. What happens when you get a cape without an EEPROM? (or will all capes be required to have one?)

The beagleboard people would very much like every cape to have an EEPROM. Ideally the breadboard type capes would have an eeprom as well, but I can understand why adafruit and circuitco didn't add one.

C. If an EEPROM is required, then we'd have to have one on the breadboard when prototyping a new cape, yes? where can I find more info about this EEPROM and how to program it for the Bone.

Bonescript now has support for writing eeproms, the info on the format should be in the SRM for the bone.

regards,

Koen

Would it be smart to incorporate jumpers on the capes so the user could configure at which level in the stack the cape resides? That should resolve some conflicts but there might be a better idea out there..

That is what the specification says. Dipswitch or jumpers to set the address of the EERPOM. The idea is that the SW will read each of the four addresses starting at 0x54, then 0X55, 0x56, and 0x57. The order is set by the user in the what order they put each board on and how they set the dipswitch or jumper for each board.

Gerald

Gotcha! So I’m not as dumb as I thought… :wink:

Thanks guys! I’m getting there…

The only stupid question is the one that should have been asked, but wasn’t!

Gerald

I feel like being an archaeologist, but I've just noticed the thread
when digging through mail archive.
FlyingBone can be equipped with an eeprom and can be assigned an
address in the stack. It is an open source design and all the files
can be downloaded from its github repository:
https://github.com/piranha32/FlyingBone
Here are a few pictures of the board in action:
https://picasaweb.google.com/108970122327518506150/FlyingBone?authkey=Gv1sRgCJTLj86WrPW2tgE

Regards,
j.