The complete software stack on the beaglebone (including bootloaders and kernel) needs to be able to autoconfigure the expansionheaders based on the capes that are plugged in.
Hardware approach:
Add an EEPROM to every cape, with jumpers/dipswitches for stackable capes to avoid address collisions
EEPROM format:
Add a vendor and product ID to the EEPROM a config version flag as well as information on which pins it needs and what mux they need to be in. E.g.:
With the experiences from beagleboard expansion boards in mind we need to pay attention to the following:
* glitch avoidance: only set pinmux if it needs changing, don't setup a default mux and then remux, especially in the kernel
* document clearly what the standard is and how VID/PID allocation works (if we go with numerical IDs)
* have a social contract that encourages cape designers to arrange patches for software support where appropriate.
* Have a webpage that lists the "registered" capes and status of the software support.
* Have clear examples on how to add software support for the devices.
* have uboot and linux utils to (re)flash the EEPROM easily "cape-eeprom-write -v Beagleboardtoys.com -p "DVI cape" -m pins.txt"
So taking the DVI cape as an example: U-boot support works out of the box since pinmux is being read from the EEPROM. Kernel support is harder since we don't support EEPROM readout of capes yet, so we hardcoded the device(s).
In ideal world devicetree would work in mainline, beaglebone would work in mainline and uboot would support devicetree fragments. In that world we could store a complete fragment in EEPROM and the kernel would "just work". This isn't the case at the moment.
Matt, could you please share your proposed EEPROM format so we can have a look at it? If we have a solid, future proof format software support will be a lot easier.
The complete software stack on the beaglebone (including bootloaders and
kernel) needs to be able to autoconfigure the expansionheaders based on
the capes that are plugged in.
Hardware approach:
Add an EEPROM to every cape, with jumpers/dipswitches for stackable
capes
to avoid address collisions
EEPROM format:
Add a vendor and product ID to the EEPROM a config version flag as well
as
information on which pins it needs and what mux they need to be in. E.g.:
With the experiences from beagleboard expansion boards in mind we need to
pay attention to the following:
* glitch avoidance: only set pinmux if it needs changing, don't setup a
default mux and then remux, especially in the kernel * document clearly
what the standard is and how VID/PID allocation works (if we go with
numerical IDs) * have a social contract that encourages cape designers to
arrange patches for software support where appropriate. * Have a webpage
that lists the "registered" capes and status of the software support. *
Have clear examples on how to add software support for the devices. * have
uboot and linux utils to (re)flash the EEPROM easily "cape-eeprom-write -v
Beagleboardtoys.com -p "DVI cape" -m pins.txt"
So taking the DVI cape as an example: U-boot support works out of the box
since pinmux is being read from the EEPROM. Kernel support is harder since
we don't support EEPROM readout of capes yet, so we hardcoded the
device(s).
With the kernel support it would also be nice to have integration between
the pinmux support and udev (maybe indirectly) so that only devices that
are active are ever enabled. For instance the second Ethernet port, there
is no point in creating eth1 if it is not enabled at the pinmux level. Its
presence when inactive just cluters things up.
I do not know if devicetree has the concept of a device which might or might
not be enabled, but it is sufficiently new that adding it now if it does
not have the capability might be a good idea.
From a kernel point of view pinmux has nothing to do with devices. In the specific case you mentioned, eth1 isn't visible or active on beagleboard no matter what the pinmux is set to.
Reading your message again, you propably mean the reverse situation: A device that is always enabled in the kernel (e.g. the DVI cape), but a cape that uses the RGB pins as GPIO gets plugged in. In that case the framebuffer needs to get disabled somehow.
In the devicetree world that would just consist of not passing in the framebuffer entry, but in the current situation...
>> [..]
>> So taking the DVI cape as an example: U-boot support works out of the
>> box since pinmux is being read from the EEPROM. Kernel support is
>> harder since we don't support EEPROM readout of capes yet, so we
>> hardcoded the device(s).
>
> With the kernel support it would also be nice to have integration between
> the pinmux support and udev (maybe indirectly) so that only devices that
> are active are ever enabled. For instance the second Ethernet port,
> there is no point in creating eth1 if it is not enabled at the pinmux
> level. Its presence when inactive just cluters things up.
From a kernel point of view pinmux has nothing to do with devices. In the
specific case you mentioned, eth1 isn't visible or active on beagleboard
no matter what the pinmux is set to.
I was refering to BeagleBone, not BeagleBoard. And if I read the SRM
correctly all the pins for eth1 on the Bone are available with the right
pinmux settings.
>> [..]
>> So taking the DVI cape as an example: U-boot support works out of the
>> box since pinmux is being read from the EEPROM. Kernel support is
>> harder since we don't support EEPROM readout of capes yet, so we
>> hardcoded the device(s).
>
> With the kernel support it would also be nice to have integration between
> the pinmux support and udev (maybe indirectly) so that only devices that
> are active are ever enabled. For instance the second Ethernet port,
> there is no point in creating eth1 if it is not enabled at the pinmux
> level. Its presence when inactive just cluters things up.
From a kernel point of view pinmux has nothing to do with devices. In the
I would argue that it does, or should. If the pinmux is set up in such a
way that the device is not connected to the outside world there is no point
in loading a driver for it and making it available to the rest of the kernel
and userspace. This may not be the way it is now, but surely part of the
change that happened when udev was introduced was to make sure that only
devices that were usable were created. Thus even GPIO pins that are not
enabled as GPIO (because they are being used as something else) should not
be created.
>> Op 28 nov. 2011, om 12:53 heeft David Goodenough het volgende
geschreven:
>>>> [..]
>>>> So taking the DVI cape as an example: U-boot support works out of the
>>>> box since pinmux is being read from the EEPROM. Kernel support is
>>>> harder since we don't support EEPROM readout of capes yet, so we
>>>> hardcoded the device(s).
>>>
>>> With the kernel support it would also be nice to have integration
>>> between the pinmux support and udev (maybe indirectly) so that only
>>> devices that are active are ever enabled. For instance the second
>>> Ethernet port, there is no point in creating eth1 if it is not enabled
>>> at the pinmux level. Its presence when inactive just cluters things
>>> up.
>>
>> From a kernel point of view pinmux has nothing to do with devices. In
>> the
>
> I would argue that it does, or should. If the pinmux is set up in such a
> way that the device is not connected to the outside world there is no
> point in loading a driver for it and making it available to the rest of
> the kernel and userspace. This may not be the way it is now, but surely
> part of the change that happened when udev was introduced was to make
> sure that only devices that were usable were created. Thus even GPIO
> pins that are not enabled as GPIO (because they are being used as
> something else) should not be created.
I do not understand what you mean with your udev comment, could you please
explain that some more?
One of the major reasons for the introduction of udev was a move from
a static, and enormous, /dev directory of all possible devices, to a
smaller list of list the ones that actually exist. So if a device exists
in /dev, or in the ip/ifconfig list or in the relevant bit of /proc or /sys
is should be a real useable device, not a place holder.
Applied to pinmux this says that if a device is not connected to the outside
world then it should not appear in /dev or wherever.
Op 28 nov. 2011, om 12:53 heeft David Goodenough het volgende
geschreven:
[..]
So taking the DVI cape as an example: U-boot support works out of the
box since pinmux is being read from the EEPROM. Kernel support is
harder since we don't support EEPROM readout of capes yet, so we
hardcoded the device(s).
With the kernel support it would also be nice to have integration
between the pinmux support and udev (maybe indirectly) so that only
devices that are active are ever enabled. For instance the second
Ethernet port, there is no point in creating eth1 if it is not enabled
at the pinmux level. Its presence when inactive just cluters things
up.
From a kernel point of view pinmux has nothing to do with devices. In
the
I would argue that it does, or should. If the pinmux is set up in such a
way that the device is not connected to the outside world there is no
point in loading a driver for it and making it available to the rest of
the kernel and userspace. This may not be the way it is now, but surely
part of the change that happened when udev was introduced was to make
sure that only devices that were usable were created. Thus even GPIO
pins that are not enabled as GPIO (because they are being used as
something else) should not be created.
I do not understand what you mean with your udev comment, could you please
explain that some more?
One of the major reasons for the introduction of udev was a move from
a static, and enormous, /dev directory of all possible devices, to a
smaller list of list the ones that actually exist.
Udev doesn't create those device, the kernel does.
So if a device exists
in /dev, or in the ip/ifconfig list or in the relevant bit of /proc or /sys
is should be a real useable device, not a place holder.
Applied to pinmux this says that if a device is not connected to the outside
world then it should not appear in /dev or wherever.
Boot up a beagleone and you'll only see one ethernet device.
>>> [..]
>>> So taking the DVI cape as an example: U-boot support works out of the
>>> box since pinmux is being read from the EEPROM. Kernel support is
>>> harder since we don't support EEPROM readout of capes yet, so we
>>> hardcoded the device(s).
>>
>> With the kernel support it would also be nice to have integration
>> between the pinmux support and udev (maybe indirectly) so that only
>> devices that are active are ever enabled. For instance the second
>> Ethernet port, there is no point in creating eth1 if it is not enabled
>> at the pinmux level. Its presence when inactive just cluters things
>> up.
>
> From a kernel point of view pinmux has nothing to do with devices. In the
> specific case you mentioned, eth1 isn't visible or active on beagleboard
> no matter what the pinmux is set to.
Reading your message again, you propably mean the reverse situation: A
device that is always enabled in the kernel (e.g. the DVI cape), but a
cape that uses the RGB pins as GPIO gets plugged in. In that case the
framebuffer needs to get disabled somehow. In the devicetree world that
would just consist of not passing in the framebuffer entry, but in the
current situation...
I was not assuming this would happen on the fly, only at power up. I rather
assumed that capes could not be plugged in when the box is powered up.
So no, I mean that when the kernel starts, if the RBG pins are not enabled
then the framebuffer should never even get initialised.
>> Op 28 nov. 2011, om 16:21 heeft David Goodenough het volgende
geschreven:
>>>> Op 28 nov. 2011, om 12:53 heeft David Goodenough het volgende
>
> geschreven:
>>>>>> [..]
>>>>>> So taking the DVI cape as an example: U-boot support works out of
>>>>>> the box since pinmux is being read from the EEPROM. Kernel support
>>>>>> is harder since we don't support EEPROM readout of capes yet, so we
>>>>>> hardcoded the device(s).
>>>>>
>>>>> With the kernel support it would also be nice to have integration
>>>>> between the pinmux support and udev (maybe indirectly) so that only
>>>>> devices that are active are ever enabled. For instance the second
>>>>> Ethernet port, there is no point in creating eth1 if it is not
>>>>> enabled at the pinmux level. Its presence when inactive just
>>>>> cluters things up.
>>>>
>>>> From a kernel point of view pinmux has nothing to do with devices. In
>>>> the
>>>
>>> I would argue that it does, or should. If the pinmux is set up in such
>>> a way that the device is not connected to the outside world there is
>>> no point in loading a driver for it and making it available to the
>>> rest of the kernel and userspace. This may not be the way it is now,
>>> but surely part of the change that happened when udev was introduced
>>> was to make sure that only devices that were usable were created.
>>> Thus even GPIO pins that are not enabled as GPIO (because they are
>>> being used as something else) should not be created.
>>
>> I do not understand what you mean with your udev comment, could you
>> please explain that some more?
>
> One of the major reasons for the introduction of udev was a move from
> a static, and enormous, /dev directory of all possible devices, to a
> smaller list of list the ones that actually exist.
Udev doesn't create those device, the kernel does.
> So if a device exists
>
> in /dev, or in the ip/ifconfig list or in the relevant bit of /proc or
> /sys is should be a real useable device, not a place holder.
>
> Applied to pinmux this says that if a device is not connected to the
> outside world then it should not appear in /dev or wherever.
Boot up a beagleone and you'll only see one ethernet device.
I will have to wait until I get a Bone to chew on.
Thanks for starting this topic. Do we have a sense of when the device
tree will be integrated into the mainline? From the u-boot side,
having all the muxing performed at that level makes sense to me. On
the Linux side, in the absence of device trees,I see some form of
matching process going on after each of the four cape address eeprom's
are probed. If the header matches, do a string compare on the VID/PID
or capename against a list of registered boards with support. Then
run what ever cape specific irq/i2c/spi/uart initialization function
that has been provided by the cape producer. Hopefully any pin
conflicts will be exposed during the u-boot process. This isn't all
that elegant... it will quickly lead to a hacked up board file... and
it forces the cape designers to be pretty versed in the early boot
processes... but it might be the best way?
I think that the rest of the points you made are great. I have one
addition that I think would be really beneficial. A web utility that
takes the pin usage statistics from each of the "registered" capes and
shows any overlap etc. I know that this quickly gets complicated due
to the multitude of pin muxing options. But something as easy as,
"Pin 22 on Port 8" is used on both Cape A and Cape B. I think this
would help cape designers as well as users.
As I have mentioned before, (sadly) I don't have a lot of time to help
architect how all the pieces fit together, but i'm here to help.
The complete software stack on the beaglebone \(including bootloaders and kernel\) needs to be able to autoconfigure the expansionheaders based on the capes that are plugged in\.
[..]
So taking the DVI cape as an example: U-boot support works out of the box since pinmux is being read from the EEPROM. Kernel support is harder since we don't support EEPROM readout of capes yet, so we hardcoded the device(s).
[Joel] So what is the short term plan to get capes working with the
right configuration (wrt kernel)?
For ex DVI user LED is already conflicting with the backlight control
pins of the LCD cape for example, so we need a short term solution
soon (which I'm guessing is reading the cape name and hardcoding mux
mode and other initialization in the kernel).
We need a short term solution that is agnostic to the EEPROM format
such as by reading the cape name from an agreed upon fixed location
till the EEPROM format is finalized and the kernel code that does the
auto configuration of mux mode from EEPROM is complete. This will help
keep the capes alive till then.
So taking the DVI cape as an example: U-boot support works out of the box since pinmux is being read from the EEPROM. Kernel support is harder since we don't support EEPROM readout of capes yet, so we hardcoded the device(s).
[Joel]
Actually pinmux is not being read from EEPROM in U-boot, its just the
version field in the EEPROM that is read [1]. The actual pinmux is
hardcoded in code [2]. So U-boot works for capes would be required if
the capes are to be used at this stage (which I don't think is way up
in the priority list anyway..)
Matt, could you please share your proposed EEPROM format so we can have a look at it? If we have a solid, future proof format software support will be a lot easier.
[Joel]
From this post, it sounded like the EEPROM format in the BeagleBone
SRM is not final. If this is the case, when can we expect a final
format to be proposed? A time estimate will also help developers,
and/or starting a thread discussing any revisions to the format
already in the SRM.