I am running ubuntu 18.04, kernel 4.19.94-ti-r36, on a a beaglebone black. I am connected to ssh, and am trying to adjust the boot configuration of the GPIO pins. After boot, I am able to change and query individual GPIO configurations with the "config-pin" command, which is useful for experimentation. But I would like to change all the default GPIO configuration on boot, which this tool does not appear to do.
I found this tutorial on using a device overlay to achieve this here:
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
but I am missing the "bone_capemgr.8" directory. I googled this issue and was directed to this page, which says that device tree overlays are now deprecated, and to use u-boot overlays instead:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays.2C_which_got_loaded
I read through the article, and googled around, but I haven't found anything on how to actually use a u-boot overlay to change the configuration of the GPIO pins on boot.
Does anyone know how to do this, or know where I might find a good resource to this effect?
Thanks!
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
sudo apt install bb-cape-overlays
create a .dts file with the correct configuration
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
something to do with boot images (?)
Questions:
what does searching "in the kernel" mean? how would I do this?
for the actual .dts file, I looked around and found this as a starting point:
https://github.com/derekmolloy/boneDeviceTree/blob/master/overlay/DM-GPIO-Test.dts My plan is to modify/extend lines 29-33 to change the boot configuration of all relevant pins. The second hex number is the pin mode I'm trying to change; that makes sense. The first hex number looks like it somehow corresponds to pin number, but I'm not sure how? for example, 0x078-->P9.12,0x184-->P9.24, etc.
when/where does making an image come into play? what about making two different partitions? I didn't follow that part
to use the uboot-overlays, which is a given for most concepts with GPIO pins on the BBB, one would have to install bb.org-overlays which are found here, https://github.com/beagleboard/bb.org-overlays, and to understand Device-Tree Specifications.
https://github.com/beagleboard/BeagleBoard-DeviceTrees will help you, too.
The Device Tree specification can be found here: https://www.devicetree.org/
In the kernel, you can search the docs. and kernel for specific, already-made device tree ideas and files.
Also, it is as simple as creating your dts file, compiling it, and putting it in the correct space on the BeagleBone Black in /boot/uEnv.txt.
For instance, if I had a specific .dtbo that I compiled from my .dts file(s), I would simply put it in the /boot/uEnv.txt file under this heading...
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays should explain the ideas I am listing.
Oh! Also, when creating your image, one would have to create the two partitions, one for booting and the other for the actual OS/filesystem.
Once this is completed, one would have to install the file uEnv.txt in the /boot dir. by simply making the file in a text editor, saving it, and placing it in the system before compilation via make menuconfig or whatever you are using to install the boot partition and OS partition.
If you need exact placements of the files in the kernel to search under for the .dts, .dtb, and .dtbo files, ask away. I have had complications with this before and lacking understanding, I have been a drift. Luckily, there is a long list of ideas but one needs to make them accessible in the correct order.
Also: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black are some ideas on how to start the image factory of making things available for the BeagleBone Black.
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
git clone https://github.com/beagleboard/bb.org-overlays
create a .dts file with the correct configuration
Your configuration of the .dts file works too...(supposedly as I have not seen it).
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
Not this idea. Although, compiling using the device-tree-compiler is an option, I say use their build script w/ their Makefile.
So, try ./install.sh
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/your_newly_added_file.dtbo
...
Also and excuse me if this does not work, you can try with the BeagleBoard-DeviceTrees link I provided.
In that one, you would simply place the correct file, your .dts file, in the /src/arm/ directory, and go back to the BeagleBoard-DeviceTrees/ dir. to perform the make command.
It will perform all the necessary .dts to .dtb to .dtbo file operations.
This is the /boot/uEnv.txt file I have currently...
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.19.94-ti-r59
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
See where the file states #dtb=? That is section where the .dtb needs to be located and uncommented by removing the hash symbol.
Also, under that particular section of the file, there are u_boot-overlay sections. You can now add your .dtbo files in those particular slots.
Related
I feel like I have done my level best to search for an answer for this but, admittedly, maybe I am not using the correct search keys.
I am building a Linux kernel using Yocto and I can see that adding lines IMAGE_INSTALL_append to local.conf, followed my the additional images that you want to include is the way that you include things like connman, dropbear, etc. That's fine.
What I want to do is include an image of the application that I have written. Let's call it HelloWorld.exe and I would like it to be tucked into it's own directory (MyHello) along with a sub-directory and the sub-directory also contains some files that are necessary for the operation of HelloWorld.
I'm sure that there are different ways of doing this but I just need one. I need to know:
Where do I position my HelloWorld.exe and its attendant files and subdirectories on my Ubuntu system where they will be picked up during the build and included in the image?
How do I alter local.conf to ensure that the final image will include my application and its support files and directories where I need it to be on the target?
Thank you. Mark
I believe it gets a bit complicated in Yocto:
You need to create your own layer. Let's say meta-hello. This folder needs to in the same place as all your other meta layers and also where your poky directory is.
You need to enable that layer in your bblayers.conf file. For that you can use bitbake-layers add-layer /path/to/meta-hello
Now within your meta-hello create a recipe in a folder recipes-hello/hello
your hello.bb file is within the above mentioned folder and your can decide to use either automake, makefile or compile it accordingly using the Dev Manual Here
Once that is done, in your BUILD dir perform bitbake hello and this will compile and provide errors if any. Resolve them and once it compiles successfully, add IMAGE_INSTALL_append = " hello" in the local.conf file.
This is one way of doing it. Another one is a bit complex using the ADT Yocto Workflow
Sorry to say there is no easier way around this as Yocto does have a steep learning and development curve.
Practical Example
You can look at this blog post by Boundary Devices which creates a simple daemonize automake example. You can find it on GitHub too.
devtools workflow
Youtube Video by Tim Orling from Intel on devtools workflow
packing external binaries
For this case use Binaries Installation in Mega Manual
How can I implement hello world Makefile & Kconfig?
I know how to write Makefile, but how can we write Makefile and Kconfig similar to Linux Kernel.
I want to write small program for which I can open menuconfig similar to Linux Kernel?
I don't want it for Linux Kernel module compilation, I know that part, I want to learn to make any application to convert into such a configurable app.
Any sample pointers where should I start from?
If I understand your question properly then you must be asking about in tree build of your loadable module with kernels build process.
Kconfig is responsible for the respective value/loadable module to be visible in menuconfig(I use menuconfig for kernel configuration).
To keep things simple let's follow below:
Create dir on ~/drivers directory nammed mymod.
In ~/drivers/mymod create Kconfig and Makefile files and keep your helloKernelmod.c
In Kconfig keep below content
menu "Menu Name of Your Driver"
config HELLO_MODULE
tristate "Inside Menu Name"
help
This is help/informational content for your module
endmenu
In makefile keep below content
obj-$(CONFIG_HELLO_MODULE) +=helloKernelmod.o
these updates will do the trick and your module will be built.
Add tabs for indentation
For more information go to https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
I'm trying to follow the walkthrough/tutorial found here.
I'm running kernel version 4.1.1-ti-r2, which doesn't appear to have any header files in the rcn-ee.net/deb/trusty-armhf folder. This means that I can't make it past the first step. If I had the linux header files for my kernel, I could skip this step and move forward.
I can't just skip this step, since I don't have a /lib/modules/4.1.1-ti-r2/build directory.
So my question is this. How can I generate the linux header files that I need? I'm relatively inexperienced with Linux/Ubuntu, so baby steps are appreciated.
If you are trying to write drivers for BBB then this is the best resource:
http://derekmolloy.ie/writing-a-linux-kernel-module-part-1-introduction/
Here you will find the steps required for the header installation.
I used SARDU for multi-bootable live DVD. first I made live usb which made perfectly in which I can modified. then i try to made dvd in which i can't modify isolinx.cfg but in usb i can modify syslinux.cfg. How can i modify isolinux.cfg then how to boot cd?
A DVD is a write-once media. When the file isolinux.cfg has been "burned" to the DVD disk, there is no way to change it (well, you could scratch it away with a tiny pin ...)
You could use an overlay filesystem but that won't help because the boot loader doesn't support it (the file system needs the kernel, so the boot loader would need to start the kernel first to read its own config file).
[EDIT] One solution is to create copy the files from the DVD somewhere, make the changes and create a new DVD image (iso file) from that.
Next, make sure that the changes made it into the image (mount -o loop file.iso /mnt and then look at the files under /mnt. Don't forget to replace file.iso with the correct name of the ISO/DVD image file on your hard disk!!)
If that is OK, create a bootable USB stick with the DVD image. This way, you can test that the image actually boots without wasting DVDs.
When everything works, burn a DVD.
In my boot options of my installed CentOS on VBox, I have the followings that really mess me up to figure out how to eliminate those that doesn't work anymore, e.g the first one which is reported as unavailability of kernel root to boot. I can only choose the last one to boot the system.
> CentOS(2.6.32-200.17.1.e16.x86_64)
> CentOS(2.6.32-200.17.1.e16.x86_64.debug)
> CentOS(2.6.32-200.4.2.e16.x86_64.debug)
> CentOS(2.6.32-200.4.2.e16.x86_64)
> CentOS(2.6.32-200.4.1.e16.x86_64)
> CentOS(2.6.32-200.e16.x86_64)
Where are these stored once I boot the system with the last option ? What if I would like to delete (completely) one of them ? I don't know what the xxx.debug's are there for ?
Thank you for any help
On most distros today the boot manager is GRUB. The configuration of boot menu is usually stored in /boot/grub in a file called menu.lst or grub.cfg depending on GRUB version and distro. In that file, you can comment out sets of lines corresponding to the OS you don't want in the menu - syntax should be pretty intuitive.
On some distros the file is generated by a set of scripts, in this case a comment at the top say you shouldn't edit that file directly. For example in Debian, the scripts which generate the configuration reside in /etc/grub.d/ and they do all sorts of auto-probing for available OS's. In this case one needs to either modify the script or to remove the OS images which are automatically appended to the menu. The exact way to do this cleanly may vary depending on your setup - perhaps some of these boot images can be removed using a package manager which would be more elegant than just removing files manually.
Either way, be careful, since removing the wrong file related to booting may make it impossible to boot your OS or even to start GRUB at all if you're extremely unlucky.