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.