Relationship between Cape eprom and Device tree?

I’m trying to get a new cape design up and running. I’m at the point where I’m about to fill in the cape’s eprom info.
Filling it in is the easy part, understanding what the info will cause to happen is a bit harder…
I suspect I don’t yet understand the intended relationship between the cape eprom and device trees in a BB system using capes.

Please bear with me while I attempt to outline what’s puzzling me
(this feel like a case of “if I could frame the question crisply, I would not need to ask”. ;-( )

Here is what I think I know:
Cape Eprom: Has various info, including a map of what pins the cape uses.
The cape eprom is read during the BBB boot steps and something is done with the info read from the cape.
Exactly What is done, and When, with the cape pin info and How that interacts with DT processing seems to be what I’m missing…

Intuitively, I’d expect that the reason the eprom is read, is to get the pin config info, and that then “things” (like Am335x pin mux states & needed OS drivers) would then be set up to match the eprom’s pin config info.

Puzzle 1: If this were happening, the BBB + Cape system configuration would only depend on Eprom info.
That would be nice (from a hardware design perspective) , but appears to not be the case.
If eprom info were all that was needed, the folks that built capes for BBWs would find they worked on BBBs - but they don’t… and those folks are working on device tree support to get older capes to work on BBBs.
This sort of implies that on a BBB running 3.8 the eprom info does NOT result in Am335x pin muxes being set to math the eprom info?

Note: I’m not asking about 3.2 vs 3.8 differences - I believe I get the reasons device trees came into existence. For BBBs (which ship with 3.8), I just take the need for Device tree as a given. My understanding is that the device tree blobs are the “Static boot time” hdw config info. Device tree overlays are a way to modify the loaded device tree config post boot time.

What I am puzzled by is how the cape eprom info relates to device trees. Eprom info and DT info seem to have a large overlap.

I (naively?) think there would have been two scenarios here:

Case 1: Eprom drives system config
I.e. boot process reads eprom pin config info and either
a) modifies device tree to match prior to boot (i.e. changes DT info before DT is used during boot).
I think a ) is not what happens given that DTs are compiled - thus the DT info is set way before boot time (at design time).

b) a compiled DT is loaded at boot time, and a DT overlay is used (later in the boot sequence) to modify the existing, already loaded, DT.
This would make sense if the BBB master DT would be loaded at boot time, and at cape read/init time a dynamically generated DT overlay would be applied. This assumes the Eprom is read after the compiled DT blob is loaded. I’n not sure of the order of things during boot.

Case 2: DT drives system config.
Here system config would only be dependent ONLY on DT info.
This is what I’d expect from a linux only perspective (as not all hardware platforms have something like a cape eprom to provide conig info from the hardware components). If the BBB with 3.8 is using only DT info, then why fill in the cape Eprom at all?

Yet, it seems that a BB (BBW or BBB) cape on a BB running 3.8, needs both Eprom info and DT support files…
Why is that?

Any explanation (or a pointer to one) that would help me understand this would be appreciated.


Have you looked at this document?


Hi Gerald,
Yep, I’ve read it. But you question prompted me to double check something stated in it.
In that doc there is this text:

“The information stored on the EEPROM of each cape are a user readable name, serial number, part number, revision information and others. The only information that the cape manager uses to work are the part-number and the revision.” (color highlight added by me)

The blue “and others” is the source of some uncertainty. The “other category” includes the complete pin usage map.
However, the magenta part of the quote may mostly answer my question…

It says that of all the info speced for the eprom (BBB R5.2 SRM page 87) only two things are used by the 3.8 cape manager (part-number and the revision).
OK I had not latched the implication of that in my head when I first read it. This means that other than the eprom bytes for Part-number and revision, the rest of the eprom can literally be blank… and there will be no difference in system initialization or operation… is that correct?

If this is correct, then I’d leave out most (if not all) of the other info that the SRM specifies. One of my musings was “what happens if the Eprom info and DT info are in conflict?”. If the eprom info is not used, then not filling in the eprom avoids the conflict situation, and it eliminates one more thing to update as design changes occur.

That thinking leads me to two more questions:

  1. Should the cape eprom info be filled in anyhow for some reason I don’t know (are there any not yet implemented plans to use the info in the future)?

  2. Does a BBW and/or any system runnign 3.2 use more of the info from the eprom (than a BBB running 3.8)?
    If so, maybe the emprom should be filled in so that the cape “works” when plugged into a BBW?


I do not know for sure what the SW people do. It looks to me like they indeed do not do anything with the other data in the EEPROM.

I want the EEPROM filed as per the table. Hopefully someday a SW person will use it.

As to 3.2 vs. 3.8 using that data, I cannot say. Right now the 3.8 kernel supports very fe kernels due to the Devcie Tree issue. They have not gotten all of them ported over to the new DT format. It is being worked on, but it will take some time to get them all under control.


You have my sympathies re wanting the eprom filled in “just in case”… it’s frustrating (at least to me as a system designer) when the hdw and sftw aspects of a system are not playing nice together.

Just for grins, you may want to point your software side colleges to the rest of this email -

I’m going to go a bit out on a limb here - and say that it seems that the current BBB/DT situation could be improved. (Please understand that I’m not trying to criticize anyone!)

What I do want to do is offer up the perspective of someone that is trying to figure this all out for the first time. I’ve found over the years that first time usage observations like this are often not obvious to guys entrenched in the implementation work (fish in water syndrome).

It seems unfortunate that the DT situation for BB capes apparently ignores BB system info that is already present. That feels to me like a OS software only perspective solution - not a system perspective. I’ll choose to view that as an opportunity for improvement…

A BB system has the nice feature of a cape hardware info device that gives all the info that is needed for pin usage. I think I read that the same is true of the BB(W/B) themselves (the bones have an eprom with similar info -incl default pin mux settings etc for BB without a cape - right?).
It appears that the eprom info is the same hdw config info needed to create a device tree overlay.
Let’s leverage the existing information in cape eproms.

Instead of everyone writing separate device tree overlays, and having to deal with what happens when the cape eprom and DT overly source are in conflict, let’s go back to a basic information system principal: Keep key information in one place.

I’d like to see the single source for all Cape pin use info be ONLY the info in the cape eprom.
Then for 3.8, modify the current system / cape manager boot logic to be:

  1. load the BB base DT blob (or derive it from the Bone eprom instead)
  2. check for cape eproms.
  3. for each eprom found, read the eprom pin config info; dynamically build the DT overlay (or just do the equivalent hdw configuration that loading a DT overlay results in )and load it.
  4. warn after boot about any load of an overlay that attempts to change the pins used by a cape found at boot time
    (I say warn so as to allow for DT overlay that are dealing with capes that can dynamically configure pins).

This would seem to have the following advantages over my understanding of the current approach:
A) Existing capes (with valid eprom data) designed and run under 3.2 would just work under 3.8 - without anyone needing to make 3.8/BBB specific device tree overlays.

B) There would be far fewer DT files to mess with and Cape distribution would not require sync with the DT overlay file distribution in a BBB release. All the recent patches for “added DT for XYZ, tested only on BBW” would have been unnecessary.

C) The boot process would have all the pin info in one place, at one time, and could check for conflicts. How smart the reaction to detected conflict is could evolve over time.

D) Most users (and programmers) could be blissfully unaware of the entire DT topic.
User land programmers could just use hardware that was found at boot time - it comes up configured and ready to go. No need for “but I want subsystem X” for my app so I need to understand and load a DT overlay to turn it on".

OK, perhaps this is just the random delusions of a newbie - but hey, hopefully it’s worth at least what the reader had to pay for these thoughts… :wink:



Hopefully the SW people will read this but, unless you have influence with Linus Torvalds, we are likely to just continue down the path with the PC Linux folks and work to coexist. There are a lot of different platforms working to be compatible with Linux. Rarely does every one win.

You might want to take a look at the Cape Manager, which was rejected by the Linux higher ups, and see how that works.


I’m suggesting that the cape manager can be enhanced w/o a need for Linux kernel changes.

Currently the cape manager gets it’s input from a DTO (file that has to be written and then compiled). The mere use of the DTO file causes two things:

  1. a source file has to be written and compiled (so the compiled version will be around at boot time).
  2. the DT source info is set at DT compile time.
    All that seems to be a waste of effort as it forces developers to recreate info (pin settings) that already exists.

Right now, during boot, a cape is discovered and the eprom is read from - just not very much of the emprom is read - the software only reads just enough to find a product name to use to find a DTO file.
The DTO file itself has no inherent value; it only exists because the cape manager expects it to exist as the only place the cape manager knows to look for pin info.

If the cape manager were to read more of the eprom (I.e. the pin info) and feed that (identical) info into the same internal Cape manager logic that is already there, we would be providing the cape manager logic with the same info it gets from a DTO file. The cape manager can then do the same actions it does today - whether the info came in from a disk file read or an eprom read should not matter.

This would mean we would no longer need the DTO source or compiled version files. All info could come from the eprom.
Suddenly, no one has to write DT files for capes anymore.
And since the info is taken from the eproms - this works for existing capes also - they would not need DT files to run on BBB and 3.8.
The cape manager would just use the info already in the existing cape’s eproms.
Thus, this would remove the need to create DT files for existing capes just to get them to run on 3.8.

Perhaps I just don’t understand something - but it seems to me that a significant amount of man-power is being wasted in creating DT files for old capes.
(To say nothing of the support costs of distributing the DT files and ansering question about “why won’t cape XYZ run on a BBB?”)


OK. From a Hardware standpoint, I see no issue. To move this forward, the best place to be is on the IRC channel and work it out there.


Pinmux settings are just a small portion of the information which goes
into the overlay, which is sufficient only for pins which act as
GPIOs. Much more important part of the overlay is the configuration of
peripherial drivers. This may be timings for LCD screens,
pin-to-function assignments and all kinds of configurable options.
With 3.2 kernels, where all the configuration had to be done in the
kernel code, setting pinmuxes was the only operation that had to be
done after system boot. Introduction of devicetree in 3.8 kernels
moved most of the peripherial configuration to the .dtb* files. In
this situation i see no use for the legacy pinmuxing information in
the cape memory. Even if the kernel will configure the pins, the
device drivers will still have to be configured.


I have been struggling with this too. I spent a day mapping out the EEPROM and creating the json file, only to realize that DT doesn’t use it. Then I had to spend another day creating the dts file.

The A0/A1 EEPROM data does not contain enough information to create a dts file, so why not put the dts file in the EEPROM? My cape file is fairly large, but is only 6kB. The largest dts file in /lib/firmware folder is “cape-bone-tester-00A0.dts”, which is just under 16kB. So they should fit in the extra space available in the EEPROM (~31.5 kB).

Could we define a rev A2 to the EEPROM data format and basically store a dts (or dtbo) file after the rev A0/A1 memory locations. For A2, the A0/A1 locations would only contain the human readable parameters, no bit mapping. The kernel could then auto load it from EEPROM and compile a dtbo, if necessary.


I just found the discussion on this thread…