Cape EEPROM Pinmux settings
Christopher Piggott
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
Jason Kridner
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.
>
> --Chris
>
> --
> To join: http://beagleboard.org/discuss
> To unsubscribe from this group, send email to:
> beagleboard...@googlegroups.com
> Frequently asked questions: http://beagleboard.org/faq
Christopher Piggott
On Feb 11, 12:51 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> 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
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..... :)
--Chris
Koen Kooi
Op 12 feb. 2012, om 00:59 heeft Christopher Piggott het volgende geschreven:
>
> On Feb 11, 12:51 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
>
>> 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
>
> Too many choices..... :)
>
> --Chris
>
Charlie Fullerton
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?
Koen Kooi
Op 12 feb. 2012, om 01:41 heeft Charlie Fullerton het volgende geschreven:
> 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
Charlie Fullerton
>> 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.
>
configure at which level in the stack the cape resides? That should
resolve some conflicts but there might be a better idea out there..
Gerald Coley
Charlie Fullerton
Thanks guys! I'm getting there...
--
To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
Gerald Coley
Jacek Radzikowski
> Op 12 feb. 2012, om 01:41 heeft Charlie Fullerton het volgende geschreven:
>> 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.
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.
--
Given a choice between two theories, take the one which is funnier