I want to boot a distro with my board where the package manager controls extlinux.conf and ships dtb file for my board but I also have an extension board so I'll need an overlay to enable some features.
Previously I would just write a boot.scr file that applies the overlay and then boots the kernel. But the kernel's and initramfs' filenames change between versions so managing the boot.scr would be tedious.
Luckily it also ships with extlinux.conf that points to the new versions but I'm having a hard time finding a way to apply an fdt overlay that way.
Is that even possible?
The Syslinux syntax used in extlinux.conf files read by U-Boot does not include a keyword to apply fdt overlays, so you're out of luck here.
It is possible to use the localboot keyword to have U-Boot execute a custom command instead of loading the kernel image specified with the kernel keyword. If a label contains the localboot keyword followed by a non-negative number, e.g.:
label mycustomboot
localboot 0
U-Boot when booting the entry executes the commands contained in the localcmd environment variable. So in theory you could put in your localcmd environment variable the series of commands you need to execute at boot (load the kernel, the fdt and the overlay, apply the overlay, and boot the kernel). But I guess this would defeat the purpose of using extlinux.conf in the first place, and wouldn't be much different from how you do things with your boot.scr file...
Related
I have board with arm-proccessor, that uses u-boot to load firmwares. I load firmware as Squashfs, but I want to make sure, that no one would be able to load their own firmwares, so I want to some how sign my squashfs file and check its signature in u-boot.
Are there any standart ways to do it? Does squashfs supports signatures "out-of-box"? Or can I add my signature to the end of squshfs-file?
A solution to this would be to leverage the verified boot functionality of FIT images, and have your squashfs be contained with the FIT image, along with the kernel and device tree files. Then you can ensure they have the signatures that you want before booting, and also disable support for booting unsigned images.
I want to upgrade my systems in the field using the uboot FIT images.
My system is a custom firmware, booted by uboot. So far the FIT filesystem works very good. It provides a shasum verified upload. I am using uboot scripts to update stuff on the target.
One intriguing type defined in uboot docs is type "filesystem". The actual content could be several things, like maybe tar'ed bunch of files, or an actual collection of separate individual files in one chunk in the FIT.
In another FIT question, Tom Rini implied that a filesystem is really just a binary blob. What goes into it is my problem and that uboot could then just mmc write ... or usb write ... to create the new filesystem on some partition. Is this really the case?
How can I build a filesystem (say FAT), on a host build computer for packaging with FIT?
Thanks, Steve
The creation of a filesystem image will depend on the filesystem itself. In many cases, build systems such as OpenEmbedded or buildroot can help you here as they will create the images for you.
I have a custom board running Yocto (Jethro) and would like to run a single u-boot command, preboot. Obviously, breaking the boot sequence with space and running it manually works. How do I get it to run automatically? More specifically, where is the startup command sequence, by default?
Edit: Also, I am aware I can edit the environment at runtime. However, I am trying to build this change into the image so I can distribute it.
When you are in the uboot environment. Enter printenv, it will list the environment variables that uboot uses.
There is a variable name bootcmd. Currently, mine contain a bunch of if else command. Similarly, add your prefer function there for boot.
And after it is finished and tested. Use saveenv to store the edit
Here is a syntax for uboot.
Edit:
U-Boot allows to store commands or command sequences in a plain text file. Using the mkimage tool you can then convert this file into a script image which can be executed using U-Boot's autoscr command. U-boot Scripting Capabilities
Typically, your U-Boot recipe will build U-Boot for a single machine, in that case, I'd normally just patch the compiled in, default, U-Boot environment to do the right thing. This is achieved by
SRC_URI_machine += "file://mydefenv.patch"
Or (even better) use your own git tree. This would also have the additional benefit that your system might be able to boot up and to something useful, even if the environment would be totally corrupted.
Another possibility is to do it like Charles suggested in a comment to another answer, create an environment offline, and have U-Boot load it, see denx.de/wiki/view/DULG/UBootScripts
A third possibility, that I've also used sometimes, is to construct the environment offline (possibly using the same or a similar mechanism as in the link above), and the flash the environment to flash during the normal flash programming process. Though, most of the time I've done this on AT91's, using a tcl script similar to at91 Sam-Ba TCL script
No matter which method you chose, the bootcmd variable in U-Boot should hold your boot script.
The general answer is that bootcmd is run by default, and if there is persistent environment you can change the command and 'saveenv' so that it's kept.
It is easiest to modify the said bootcmd, which is executed anyway.
As an alternative to patching the kernel, it is possible to override the command in u-boot.
Create a file e.g. platform-top.h at the same place where you would place the patch file (it might already exist) and override the CONFIG_BOOTCOMMAND.
The result will look something like this:
/* ... */
/* replace the memory write with any other valid command */
#define CONFIG_BOOTCOMMAND "mw 0x1 0x1 && run default_bootcommand"
Don't forget to make the file known in your bbapend SRC_URI = "file://platform-top.h"
I am trying to interface a 16x2 LCD with Beagleboard xM using GPIO. I have done this by using a shell script and it's working very good. Now I want to achieve the same functionality by writing a kernel module. I know little bit about kernel programming as I'm in the learning phase. Need some guidance. Thanks in advance!
Writing a kernel module is different then shell scripting. You must write your own code in C++, declaring the kernel mode, and then compile it. I found one example, but don't have time to check it, so I am leaving that to you.
Here is one example of writing kernel modules, and here is one tutorial for interfacing 16x02 lcd.
If you have a script you can load it like a module in linux ,
In /etc/rcS.d folder you will find a lot of scripts like S13-some_name.sh . These scripts will be automatically run by the kernel while booting up. So you can just add your scipt here to make it as a module
So one thing have to do is find the last number used in these list of scripts and rename your driver script by prepending the next number to the last in the list
for eg:
if the last script in /etc/rcS.d is S53logger.sh
Rename your scipt as S54-name-.sh (don't forget to change attributes by chmod +x)
If the /etc/rcS.d is not present there might be a file rc.local file you just add the driver script to it
I am working at an OS independent file manager, in C. I managed to copy files, links and directories, but I am not sure how to copy devices. I would appreciate any help.
To create a device file, use the mknod(2) syscall. The struct stat structure will give you the major and minor device numbers for an existing device in st_rdev.
Having said that, there is little value in "copying" a device because a device doesn't contain anything useful. The major and minor numbers are specific to the OS on which they exist.
It's not really a useful feature, IMHO. tar(1) needs to be able to do it as part of backing up a system, and setup programs need to be able to create them for you when setting up your system, but few people need to deal directly with device files these days.
Also, modern Linux systems are going to dynamic device files, created on the fly. You plug in a device and the device files appear; you unplug it and they disappear. There is really no use in being able to copy these dynamic files.
dd is your friend (man dd)
dd if=/dev/sda1 of=/some_file_or_equally_sized_partition bs=8192
if you want to copy the device-file itself, do this:
cp -p device-filename new-filename
e.g.:
cp -p /dev/sda1 /tmp/sda1
those are both equivalent device files, and can be used to access the device.
If you're want to do this from C, use mknod() .. see "man 2 mknod"
This might be useful
cp -dpR devices /destination_directory
cp -dpR console /mnt/dev
You don't. Just filter them out of the view such that it can't be done.
Use the stat function to determine the file type.
Check if you've the udev package, if you do, chances are that devices are generated on the fly, from the package description:
udev - rule-based device node and kernel event manager
udev is a collection of tools and a daemon to manage events received from the
kernel and deal with them in user-space. Primarily this involves creating and
removing device nodes in /dev when hardware is discovered or removed from the
system.
Events are received via kernel netlink messaged and processed according to
rules in /etc/udev/rules.d and /lib/udev/rules.d, altering the name of the
device node, creating additional symlinks or calling other tools and programs
including those to load kernel modules and initialise the device.