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"
Related
I'm building Kernel for my embedded ARM-based system (system is a ARM7 VARISCITE DART6UL).
Since I need to build Kernel appending my local version to it, I read it's possible to edit (using make menuconfig) the right local version I need, writing in General setup->"Local version - append to kernel release".
Commands I execute to edit .config kernel are the following:
make mrproper
make imx6ul-var-dart_defconfig
make menuconfig
My question is: why my kernel release that I appended in the graphical kernel menu config file doesn't still remain saved?
Everytime I enter in menuconfig it disappear: Is there a way to fixed it, avoiding the need to rewrite each time?
Regards
Paolo
You need to copy back the .config file to arch/arm/configs/imx6ul-var-dart_defconfig
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...
I am currently trying to build a new version of a piece of software I developed. The software takes a simple command line argument and appends the argument to the end of a file. My problem is that I want to alter the program so:
Someone can set up a standard location to save the file to.
The program will remember that location.
It will still work for anyone installing the C program on mac, linux or windows.
So basically I am trying to figure out how to create a C executable that comes with persistent memory that it can read and modify. Alternatively I would take any way to create an installer to make this easy for anyone who wants to use my program.
If this were a java program I would just add it to the jar file but I have never seen this documented for the C language.
I would add platform-specific code to store your settings in whatever area users of that particular platform expect. So:
For Linux: store configuration files in the location specified by $XDG_CONFIG_HOME.
For Mac: Use CFPreferences
For Windows: use the registry
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'm writing a 'C' program that makes several calls to system() to execute other programs. When constructing the command string is it better to explicitly give the full path to the program being called, or should I just give the executable name and let the shell resolve its location using the PATH environment variable?
The programs I'm calling are all part of a single package and I have the path to the installation directory from a preprocessor definition. Giving the explicit path would seem to avoid errors that might occur if multiple installed programs share the same name. However it makes building the command strings a little more complicated, and everything will break if the user moves the programs around after installation.
Is there a widely accepted best practice covering this?
[Clarification]
I'm using autoconf/automake to generate the distribuion. The preprocessor definition providing the installation directory is created by the makefile. It reflects the user's choice of the installation directory as specified either on the configure comamnd line or the make command line. I do take the point about using environment variables to specify the location for the binaries though. It seems like an unneeded pain in the butt to make users rebuild just to change the location of the binaries.
Best practice is never to assume that you know your install directory at build time. Let your users decide where to install and work anyway.
This means that you will need to find out where your programs are located using some other mechanism. Consider using environment variables or command line parameters to allow the user to specify the actual path, if your platform does not provide you with the means to find out where the executables are located. You can use your knowledge of where you are normally installed as a fallback option.
For your actual question, in case you can build the absolute path to your program (using another mechanism than preprocessor directives) - use that. Otherwise, fall back to having the system find out for you.
The best practice is to not presume anything about the system you're installing onto. You can have the best of both worlds if you just let the user choose. Make the command you call an application preference or require paths to be defined in the environment:
PATH_TO_TOOL1=foo
PATH_TO_TOOL2=/usr/bin/bar
You can, of course, just fall back to a default of some kind if the variables aren't defined or the preference isn't set. Writing your application to be more flexible is always the best choice!
You should definitely let the user specify the path with an environment variable to the installed binaries. Not all systems are the same and many people will want to put their execs in different places.
the best example I can think of is people doing a local install vs system install. If your program is installed in a home directory that user will have to set and env variable to say where the binaries are copied to.
If you're absolutely sure of the path names, and if they are not "well-known" commands (for example, POSIX shell utilities on Unix are "well-known"), you should specify the pathname, otherwise don't specify the full path, or let the user control it by using an environment variable.
In fact, you may be able to write something like a function such as int my_system(const char *);, which does the prefixing of the path for you. If later you determine that it was a bad idea, it's just a matter of making my_system() identical to system().
I'm not sure if it's a best practice, but what I do in these cases is I write my C code to extend the PATH environment variable to include the installation directory at the end. Then I just use the PATH. That way, if the user's PATH wants to override where I believe the stuff was installed, it can—but if the software was installed in an out-of-the-way place, I can call it without forcing my users to put the directory on $PATH themselves.
Please note that the extended PATH lasts only as long as the C program runs; I'm not proposing changing the persistent PATH.