This should fix the problem on the next release.
https://github.com/pantoniou/linux-bbxm/commit/738e37102bdfbfd065f4f53814df62b896804d90
It's pretty hard to load a dtbo from a rootfs that's not yet mounted...
Hello Pantelis,
thank you very much for your work!
Indeed, compiling the firmware into the kernel works as expected. My feeling just was that the overlay-extension was added to relief the user of compiling custom kernels.
Now, enabling by partno works (and with your new patch also without recompiling the kernel!). Yet I was not able to let capemgr detect the right firmware based on the capes EEPROM. I added a mapping with part-number=“BB-BONE-IBB” → dtbo=“cape-bone-ibb-00A0.dtbo” to the am335x-bone-common.dtsi but it was not mapped. But this is another issue.
With respect to your fix: How could this be solved for the EEPROM-supported loading of firmware? Again for known capes there could be an additional entry in the mentioned am335x-bone-common.dtsi, but how to allow this for capes purely known by EEPROM-data?
Again, thank you very much for your work.
BTW: As you introduced the “DTify”-patch for the PCA954x: Maybe you aplly this fix as well: https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-capes/EpSgObarwpc
Best regards,
Robert
Hi there,
Hello Pantelis,
thank you very much for your work!
Indeed, compiling the firmware into the kernel works as expected. My feeling just was that the overlay-extension was added to relief the user of compiling custom kernels.
It was; the case of loading a dtbo from a rootfs on a device that's been created via a dtbo is a case of a chicken & egg problem.
If you booted from external sd card where the mmc device is part of the base dtb you wouldn't have this problem.
Now, enabling by partno works (and with your new patch also without recompiling the kernel!). Yet I was not able to let capemgr detect the right firmware based on the capes EEPROM. I added a mapping with part-number="BB-BONE-IBB" -> dtbo="cape-bone-ibb-00A0.dtbo" to the am335x-bone-common.dtsi but it was not mapped. But this is another issue.
You don't have to modify the base dts (am335x-bone-common.dtsi) - for your case just name your dts file for your cape
BB-BONE-IBB-00A0.dts, compile it and put it in /lib/firmware as BB-BONE-IBB-00A0.dtbo.
If the EEPROM is probed correctly and the part-number revision fields are correct (BB-BONE-IBB & 00A0 respectively) it should
just work.
With respect to your fix: How could this be solved for the EEPROM-supported loading of firmware? Again for known capes there could be an additional entry in the mentioned am335x-bone-common.dtsi, but how to allow this for capes purely known by EEPROM-data?
No need to mofidy am335x-bone-common.dtsi at all.
Again, thank you very much for your work.
My pleasure.
BTW: As you introduced the "DTify"-patch for the PCA954x: Maybe you aplly this fix as well: Redirecting to Google Groups
OK, noted; should be in the next release.
Best regards,
Robert
Regards
-- Pantelis
Hi,
Hello Pantelis,
thank you very much for your work!
Indeed, compiling the firmware into the kernel works as expected. My feeling just was that the overlay-extension was added to relief the user of compiling custom kernels.
Now, enabling by partno works (and with your new patch also without recompiling the kernel!). Yet I was not able to let capemgr detect the right firmware based on the capes EEPROM. I added a mapping with part-number="BB-BONE-IBB" -> dtbo="cape-bone-ibb-00A0.dtbo" to the am335x-bone-common.dtsi but it was not mapped. But this is another issue.
With respect to your fix: How could this be solved for the EEPROM-supported loading of firmware? Again for known capes there could be an additional entry in the mentioned am335x-bone-common.dtsi, but how to allow this for capes purely known by EEPROM-data?
Ugh, ok, now I see what you mean... The chicken and egg problem, but now with EEPROMs...
Let me think about it a bit; sigh...
Sorry for keeping on asking:
Now modified the EEPROM to have part-number “cape-bone-ibb” (which is quite long and only is a working-around for the kernel-mapping). The correct cape-bone-ibb-00A0.dtbo is now found/loaded correctly as it is now in my modified kernel.
But still the cape-fw is loaded now in slot 0 (0-3), which is prior to the eMMC (slot 4 by now!). So without compiling the cape-fw in the kernel even with your patch to the “partno”-option AUTOMATIC loading based on the EEPROM won’t work!
One option would be not to refer to the cape-fw when using “partno” but to refer to the eMMC-fw and set it to priority -1 or something to explicitly tell the capemgr to load it prior to all other stuff.
Best regards,
Robert
Or better: there is a check for conflicts anyway - what about loading the stuff that is “onboard” anyway and just advise people with incompatible capes (which fw is rejected then) to DISABLE the emmc-fw. Would suit much more people from the first start.
After thinking about it for a while - really, the onboard-stuff should be loaded first by default and could be disabled by using uEnv.txt on demand. No need for priorities and most users would never notice. Those with conflicting acpes should pay attention anyway.
No that's not enough.
There's a requirement that the images used for booting are the same both for the emmc & the external sd card.
Using your prescribed method would mean that those images should be different.
I'm working on it, hang on please.
Hi Guys,
I’ve been reading your posts and i’m experiencing the same problem. When i try to load my cape from EEPROM it doesn’t work but when i do it manually it loads correctly.
I added to my uEnv.txt file the line “optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN” and according with my log the cape is recognized and correctly read from EEPROM, also my dtbo file is in lib/firmware but i get a message on log saying that “failed to load firmware” and i don’t understand why.
I’m know that you are working on some solutions and i just wanted to leave my case so you know that there are more people suffering from the same problem 
, if you have some ideas of what is happening please let me know.
Thanks.
Duarte
Quinta-feira, 25 de Julho de 2013 15:28:44 UTC+1, Pantelis Antoniou escreveu:
You will be right - but it is not clear to me. If you change the order of overlays in “both” cases, everything should be fine? For me it is also meanningful that “onboard-extensions” are loaded by default prior to capes?
All these will be part of something I will put out tomorrow.
There are many ways to accomplish it.
Hang on a bit ..
-- Pantelis
Hi,
https://github.com/pantoniou/linux-bbxm/commit/66166f29c1cfa5035ba4782266d677b908e81f0e
https://github.com/pantoniou/linux-bbxm/commit/fb99fd668f8baaf4270ce8b2359077dcc9a047aa
This should fix kind of problem when the dtbo is not included in the kernel image.
BTW, if you do have a cape that you submitted to the beagleboard tree, we include it
and from now on it will always be present without those kind of gymnastics.
Regards
-- Pantelis
I have been reading through the threads here and Googling quite a bit, and it seems as though this is the same sort of problem I am having. I don’t have an EEPROM’ed “cape” (custom HW setup) and am instead loading cape firmware via the uEnv.txt file. I see this question is marked as “completed”, but I am unsure how to apply the fix to my issue.
It seems to be simple enough to create your own custom dts file, compile it on the Beaglebone with the dtc command and then make sure the resultant dtbo file is in /lib/firmware. In theory that firmware will be loaded the next time you reboot or via manually loading it to /sys/devices/bone_capemgr*/slots, but that process isn’t working for me. It seems I’m not the only one having this issue, either.
This particular thread looks promising, but I am not sure how the two patches Pantelis posted fit into a solution. Pantelis says “This should fix kind of problem when the dtbo is not included in the kernel image.” which seems to be my issue. Does that mean we still have to recompile the kernel to have our cape firmware changes included? What is the purpose of the /lib/firmware folder in that case? I am pretty new to this and it would be appreciated if Pantelis (or anyone else who’s been successful at this) could share how they got their custom dtbo files loaded and working with more detail. Thanks.
Hi Pantelis,
is there an estimate how long it will take for this patch to be included in “3rd-party”-kernels such as the one from Robert C. Nelson (http://elinux.org/BeagleBoardDebian)? Sure it depends on the actual author, but is there a generell procedure / time schedule when this will find its way in the repos Robert Nelson is using for his kernels?
Best regards,
Robert
Seth - did you ever get an answer to your question? I’m having a similar problem. My custom .dtbo files (located in /lib/firmware and loaded using enable_partno in uEnv.txt) do get loaded eventually, but only after a 60 second timeout. I’m wondering if enable_partno isn’t a good idea for firmware that isn’t compiled into the kernel, and if you should load these files using /sys/devices/bone_capemgr*/slots after boot instead. I see that there’s a config option that allows you to override the 60 second default, but it isn’t clear to me if this can be set without a kernel recompile.
FWIW, this functionality worked without delay prior to a round of patches over the last few months.
Unfortunately I have not found (tried) a solution. I assume that “all I need to do” is to recompile the kernel with the updated dtbo file.
This is one more of those times (many with the beaglebone/linux) where I have two options:
A) Try to fix the problem myself (a relatively inexperienced ‘beginner’) with what usually ends up being days/weeks of struggling on basic things or
B) Wait for the professionals to fix it correctly or wait until someone nice enough who knows what they’re doing answers the question people have been asking.
If I choose (A) but the pros end up fixing it, then I’ve wasted a lot of my time (although hopefully I’ve learned something from it). If I pick (B) but the pros never get around to it, then again I’ve wasted a lot of time and then I’m forced to pick A anyway - but at what point do I switch my choice and try to do things myself?
Fortunately I’m not on a strict schedule that would force me to always pick (A) and this time around I’ve chosen (B). Sorry I can’t be of more help. I haven’t tried the recompilation myself and I haven’t received help from my question yet either. If I do get time to try that process I’ll post back here with my results.
It means that the kernel must be compiled with the two changes Pantelis made in order to work. Depending on how you are keeping your software image up to date will control whether or not you need to recompile. I am using Robert Nelson’s build image scripts and currently am using the 3.8 kernel with his patches up through version bone28. Checking the linux source files I do not see those two patches - and checking his 3.8 kernel branch, https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 I don’t see the patches so I’m assuming they are not there yet.
Ahh i see the issue now.
Those patches are disabled..
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patch.sh#L786
Feel free to enable them and also "tweak" the config, so it doesn't
break loading every cape...
Regards,
Hello, guys. I read all your posts but get really confused. I encounter the same problem. I want to overlay the BB-BONE-LCD7-00A0.dtbo file. But unfortunately I got the error message “-sh: echo: write error: No such file or directory”. So, I wanna know, did all you guys fix the problem. Thanks a lot.
This thread has been open for about 8 months.
I’ve got the experience to understand this, and have spent a week looking at it for 3.12.x.
There are two things I am certain of:
-
if you want to debug a hotplug event, you have to be logging it in detail. firmware loading requests are hotplug events coming from the kernel. If you are not logging during your debug session, you are guessing. I use busybox’s mdev, and recently augmented the load_firmware() infrastructure to do a decent job logging the hotplug events.
-
The first firmware load event coming from 3.12 has the wrong ACTION verb, it has remove rather than add. So tend to indicate a bug in this kernel. Subsequent firmware requests come with the correct action verb, 60 seconds apart.
It is possible that if you only have one firmware DTB to load, that your hotplug script is IGNORING the load request because of the bad ACTION verb. Unless you are logging it all, while troubleshooting, you are guessing.
In my case there are 3 firmware requests, they all fail. The first fails because of the bad verb, and the 2nd two fail because the firmware files are missing. Without logging I would not have known this.
I have two problems to solve now.