Mainly due to some frustrations around opencv Python support in Angstrom, I am investigating switching to the Debian distribution. I have followed Robert Nelson's excellent tutorials and scripts, but need some guidance in adding my own kernel modules and device trees. I have already successfully built them under Angstrom/bitbake, but cannot determine the preferred or "correct" workflow for Debian. Any help would be greatly appreciated.
Best regards,
Dave.
Hi Dave,
What kernel modules/device tree's do you need enabled?
For the bone, the kernel script can be found here: (it's 99% source
identical to angstrom's 3.8 tree)
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8
Regards,
Mainly due to some frustrations around opencv Python support in Angstrom, I
am investigating switching to the Debian distribution. I have followed
Robert Nelson's excellent tutorials and scripts, but need some guidance in
adding my own kernel modules and device trees. I have already successfully
built them under Angstrom/bitbake, but cannot determine the preferred or
"correct" workflow for Debian. Any help would be greatly appreciated.Hi Dave,
What kernel modules/device tree's do you need enabled?
Thanks for your quick reply.
These are modules/dts that I have written to support a UPS/watchdog cape I am developing. They are building and working fine with the 3.8 Angstrom kernel using the attached bitbake recipe. My question is what are the magical incantations I need to build these outside the kernel tree? I suspect there is a "correct" way to do this under Debian, rather than me re-inventing a wheel.
Regards,
Dave.
argus-ups_1.0.0.bb (1.24 KB)
Well, the best option is to write a patch against:
https://github.com/beagleboard/kernel/tree/3.8
and then i'll merge it into both tree's and push out a new
debian/ubuntu kernel build. .
So everyone get's the patch and
supports your new cape out of the box...
Regards,
Thanks Robert. I must admit I am much more comfortable with that approach, than with bitbake/Angstrom recipes.
Dave.
Well I got my module and dtb to compile and install cleanly, but I am now confused by the uEnv.txt. It appears to be much more complex than the one I used for Angstrom (attached). I would like to disable the HDMI virtual cape and enable mine. Is there a wiki that explains how to do this with Debian?
Regards,
Dave.
uEnv.txt (118 Bytes)
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
Errr, that is as long as the file names have not changed . . .
I also wanted to point out that that technically uEnv.txt and uboot have nothing to do with the OS in particular. However in this case optargs are passed to the kernel when it starts up so . …
I may be barking up the wrong tree here, but I also notice that the uboot partition contains dtbs (see below). Do I need to put my cape's dtb here? Also I am attaching the uEnv.txt from the Debian system. I am particularly confused by the line:
loadfdt=load mmc ${mmcdev}:${mmcpart} 0x815f0000 /dtbs/${fdtfile}
I have been looking for some documentation on this without success.
Best regards,
Dave.
root@debian:~# ls -R /boot/uboot/dtbs/
/boot/uboot/dtbs/:
am335x-boneblack.dtb omap3430-sdp.dtb omap4-panda.dtb
am335x-bone.dtb omap3-beagle.dtb omap4-panda-es.dtb
am335x-evm.dtb omap3-beagle-xm.dtb omap4-sdp.dtb
am335x-evmsk.dtb omap3-devkit8000.dtb omap4-sdp-es23plus.dtb
am335x-tester.dtb omap3-evm.dtb omap4-var-som.dtb
am3517-evm.dtb omap3-igep0020.dtb omap5-evm.dtb
am3517_mt_ventoux.dtb omap3-igep0030.dtb omap5-uevm.dtb
am43x-epos-evm.dtb omap3-tobi.dtb
omap2420-h4.dtb omap4-panda-a4.dtb
uEnv.txt (998 Bytes)
I'm not sure on your confusion. With Angstrom the bootloader/uEnv.txt
matched each other and since they programmed them at the factory they
had a 100% guarantee of what was installed. In my case, I have to
deal with the original factory u-boot/MLO, and i also support a good
dozen more boards. So for my sanity the uEnv.txt has a lot of generic
options that override some of the factory defaults for this board.
So if you compare with a board that has no factory (NAND/eMMC) like
the orignal bone, the uEnv.txt is a lot simpler:
http://eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-uEnv.txtbasedbootscript
So back to the line:
loadfdt=load mmc ${mmcdev}:${mmcpart} 0x815f0000 /dtbs/${fdtfile}
For the bone (this image will boot on board boards):
ftdfile: (set by u-boot.img)
am335x-boneblack.dtb
am335x-bone.dtb
you can also override this with "fdtfile=am335x-mycape.dtb" (all
dtb's are in a single directory in the fat partition)
mmcdev:
0: microSD
1: eMMC
mmcpart:
1: (fat partition..) (i don't use 2, ext4)
In your case, follow William's example and add:
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
To the top of the uEnv.txt..
Regards,
Thanks Robert. This make perfect sense now. Sorry for the dumb question :-[
Regards,
Dave.
Not a problem Dave..
BTW, if you used my kernel build script, the config is already setup
to place the *.dtbo's (firmware) into into the kernel (zImage). So if
your utilizing a new one, you don't actually have to copy the *.dtbo
to the /lib/firmware/ directory..
Regards,
Thanks so much for your help, your scripts really help simplify things a lot!
BTW I am going to change the name of my module to something more appropriate before sending you a patch. I just need to test it first with the "argus-ups" name.
I am getting really close now, but do not seem to be able to automatically load my driver/dt. Manually all works fine, as follows:
root@debian:~# echo argus-ups:00A0 > /sys/devices/bone_capemgr.9/slots
[ 543.266228] bone-capemgr bone_capemgr.9: part_number 'argus-ups', version '00A0'
[ 543.274815] bone-capemgr bone_capemgr.9: slot #8: generic override
[ 543.281388] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
[ 543.289441] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,argus-ups'
[ 543.299325] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'argus-ups-00A0.dtbo
[ 543.309581] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'argus-ups-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 543.328913] bone-capemgr bone_capemgr.9: slot #8: dtbo 'argus-ups-00A0.dtbo' loaded; converting to live tree
[ 543.340358] bone-capemgr bone_capemgr.9: slot #8: #2 overlays
[ 543.352047] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.
root@debian:~# [ 543.368913] Init UPS module - debug=0, shutdown=1
[ 543.375128] Debug parameter read from DT:0
[ 543.379479] Shutdown parameter read from DT:1
root@debian:~# cat /sys/devices/bone_capemgr.9/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
8: ff:P-O-L Override Board Name,00A0,Override Manuf,argus-ups
But if I add:
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN \
capemgr.enable_partno=argus-ups
to the start of uEnv.txt, then I get the following in dmesg:
--snip--
[ 0.000000] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=argus-ups VIDEO_DISPLAY root=/dev/mmcblk0p5 ro rootfstype=ext4 rootwait fixrtc
--snip--
[ 1.382046] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMIN
[ 1.420581] bone-capemgr bone_capemgr.9: slot #0: No cape found
[ 1.457686] bone-capemgr bone_capemgr.9: slot #1: No cape found
[ 1.494794] bone-capemgr bone_capemgr.9: slot #2: No cape found
[ 1.531905] bone-capemgr bone_capemgr.9: slot #3: No cape found
[ 1.538151] bone-capemgr bone_capemgr.9: slot #4: specific override
[ 1.544751] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4
[ 1.552798] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[ 1.562915] bone-capemgr bone_capemgr.9: slot #5: specific override
[ 1.569510] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5
[ 1.577555] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[ 1.587569] bone-capemgr bone_capemgr.9: slot #6: specific override
[ 1.594164] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6
[ 1.602209] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[ 1.612420] bone-capemgr bone_capemgr.9: enabled_partno part_number 'argus-ups', version 'N/A', prio '0'
[ 1.622379] bone-capemgr bone_capemgr.9: slot #7: generic override
[ 1.628873] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 7
[ 1.636917] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,argus-ups'
[ 1.646758] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 1.656356] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN
[ 1.666237] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.675115] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.683911] bone-capemgr bone_capemgr.9: initialized OK.
[ 1.689508] bone-capemgr bone_capemgr.9: loader: before slot-7 argus-ups:00A0 (prio 0)
[ 1.697824] bone-capemgr bone_capemgr.9: loader: check slot-7 argus-ups:00A0 (prio 0)
[ 1.707286] OneNAND driver initializing
[ 1.712253] usbcore: registered new interface driver cdc_ether
[ 1.718459] usbcore: registered new interface driver rndis_host
[ 1.724749] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 1.733537] bone-capemgr bone_capemgr.9: loader: after slot-7 argus-ups:00A0 (prio 0)
[ 1.741835] usbcore: registered new interface driver cdc_ncm
[ 1.747803] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'argus-ups-00A0.dtbo
[ 1.758613] usbcore: registered new interface driver cdc_acm
[ 1.764575] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 1.772976] Initializing USB Mass Storage driver...
[ 1.778120] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'argus-ups-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
--snip--
[ 2.559761] bone-capemgr bone_capemgr.9: failed to load firmware 'argus-ups-00A0.dtbo'
[ 2.568151] bone-capemgr bone_capemgr.9: loader: failed to load slot-7 argus-ups:00A0 (prio 0)
[ 2.577237] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 2.592771] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[ 2.610203] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
[ 2.639467] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
[ 2.661184] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
This works fine on my Angstrom system.
Regards,
Dave.
Very strange... Does it help in any way to dump the argus-ups dtbo to
/lib/firmware/ ?
Regards,
I think that just a space between the disable / enables lines is all you need. There are a couple ways I could read your last message as in text formating etc, but be sure there are no Windows type white spaces or more specifically what Microsoft OSes call a line feed.
To be succinct: If you’re using backslash to esc the line to make your file more readable. Dont. put it all on one line.
I think that just a space between the disable / enables lines is all you need. There are a couple ways I could read your last message as in text formating etc, but be sure there are no Windows type white spaces or more specifically what Microsoft OSes call a line feed.
Thanks for the suggestion William.
I removed the backslash to no avail. The module refuses to autoload. Here is the dmesg dump of the kernel command line:
[ 0.000000] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=argus-ups VIDEO_DISPLAY root=/dev/mmcblk0p5 ro rootfstype=ext4 rootwait fixrtc
To be succinct: If you're using backslash to esc the line to make your file more readable. Dont. put it all on one line.
Regards,
Dave.
I am not sure what you mean by "dump"? The dtbo was put in /lib/firmware by your scripts:
root@debian:~# ls -l /lib/firmware/arg*
-rw-r--r-- 1 dlambert dlambert 1677 Dec 6 13:45 /lib/firmware/argus-ups-00A0.dtbo
Regards,
Dave.
Perhaps the HDMI video and audio are not being disabled quickly enough for your module to load. Another way to load your module would be to write a startup service. Which you can then load at any point in the Debian startup cycle. I have a write up of an example here :http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-init-scripts-default-gatewayand-ntpdate/
Turns out the reason why I wrote this short article was a goof on my part. Also, the reasons why I did this may not seen sane to some. Meaning, there could be a much easier way to do the same things . . . but . . . whatever the case the example is perfectly usable for different situations.
Perhaps the HDMI video and audio are not being disabled quickly enough for your module to load. Another way to load your module would be to write a startup service. Which you can then load at any point in the Debian startup cycle. I have a write up of an example here :http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-init-scripts-default-gatewayand-ntpdate/
I think you may be right William. There may be a race condition here. Sometimes when I boot, I get:
root@debian:~# cat /sys/devices/bone_capemgr.9/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,argus-ups
But the module is not loaded.
Other times I get nothing in slot 7.
I think one difference between my Angstrom system may be that Angstrom uses systemd, and Debian uses System V init???
Anyway, I will try your suggestion.
Thanks,
Dave.
Something like that, Robert would know better than I. I do have years of Debian experience, but much of the low level details I am unfamiliar with. This would be one of those cases.