Skip to main content.
Navigation:
DENX
>
DULG
>
UBootCmdGroupExec
Translations:
Edit
|
Attach
|
Raw
|
Ref-By
|
Printable
|
More
DULG
Sections of this site:
DENX Home
|
DULG
|
ELDK-5
|
Know
|
Training
|
U-Boot
|
U-Bootdoc
Topics
DULG Home
BoardSelect
Manual
FAQ
Application Notes
Changes
Index
List of pages in DULG
Search
%SECTION0{name=UBootCmdGroupExec}% Execution Control Commands %SECTION1{name=UBootCmdSource}% source - run script from memory %INCLUDE{DULGData_%BOARD%.UBootSourceHelp}% With the =source= command you can run "shell" scripts under U-Boot: You create a U-Boot script image by simply writing the commands you want to run into a text file; then you will have to use the =mkimage= tool to convert this text file into a U-Boot image (using the image type =script=). This image can be loaded like any other image file, and with =source= you can run the commands in such an image. For instance, the following text file: %INCLUDE{DULGData_%BOARD%.UBootSourceScript}% can be converted into a U-Boot script image using the =mkimage= command like this: %INCLUDE{DULGData_%BOARD%.UBootSourceMkimage}% Now you can load and execute this script image in U-Boot: %INCLUDE{DULGData_%BOARD%.UBootSource}% %SECTION1{name=UBootCmdBootm}% bootm - boot application image from memory %INCLUDE{DULGData_%BOARD%.UBootBootmHelp}% The =bootm= command is used to start operating system images. From the image header it gets information about the type of the operating system, the file compression method used (if any), the load and entry point addresses, etc. The command will then load the image to the required memory address, uncompressing it on the fly if necessary. Depending on the OS it will pass the required boot arguments and start the OS at it's entry point. The first argument to =bootm= is the memory address (in RAM, ROM or flash memory) where the image is stored, followed by optional arguments that depend on the OS. %IF0{ "%ARCH%" eq "powerpc" }% =Linux= requires the flattened device tree blob to be passed at boot time, and =bootm= expects its third argument to be the address of the blob in memory. Second argument to =bootm= depends on whether an =initrd= initial ramdisk image is to be used. If the kernel should be booted without the initial ramdisk, the second argument should be given as "-", otherwise it is interpreted as the start address of =initrd= (in RAM, ROM or flash memory). %ELSE0% For =Linux=, exactly one optional argument can be passed. If it is present, it is interpreted as the start address of a =initrd= ramdisk image (in RAM, ROM or flash memory). In this case the =bootm= command consists of three steps: first the Linux kernel image is uncompressed and copied into RAM, then the ramdisk image is loaded to RAM, and finally control is passed to the Linux kernel, passing information about the location and size of the ramdisk image. %ENDIF0% To boot a Linux kernel image without a =initrd= ramdisk image, the following command can be used: %IF0{ "%ARCH%" eq "powerpc" }% <pre> %UBOOT_PROMPT% bootm ${kernel_addr} - ${fdt_addr} </pre> %ELSE0% <pre> %UBOOT_PROMPT% bootm ${kernel_addr} </pre> %ENDIF0% If a ramdisk image shall be used, you can type: %IF0{ "%ARCH%" eq "powerpc" }% <pre> %UBOOT_PROMPT% bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr} </pre> %ELSE0% <pre> %UBOOT_PROMPT% bootm ${kernel_addr} ${ramdisk_addr} </pre> %ENDIF0% Both examples of course imply that the variables used are set to correct addresses for a kernel %IF{ "%ARCH%" eq "powerpc"}%, fdt blob%ENDIF% and a =initrd= ramdisk image. %X% When booting images that have been loaded to RAM (for instance using TFTP download) you have to be careful that the locations where the (compressed) images were stored do not overlap with the memory needed to load the uncompressed kernel. For instance, if you load a ramdisk image at a location in low memory, it may be overwritten when the Linux kernel gets loaded. This will cause undefined system crashes. %SECTION1{name=UBootCmdGo}% go - start application at address 'addr' %INCLUDE{DULGData_%BOARD%.UBootGoHelp}% U-Boot has support for so-called _standalone applications_. These are programs that do not require the complex environment of an operating system to run. Instead they can be loaded and executed by U-Boot directly, utilizing U-Boot's service functions like console I/O or _malloc()_ and _free()_. This can be used to dynamically load and run special extensions to U-Boot like special hardware test routines or bootstrap code to load an OS image from some filesystem. The =go= command is used to start such standalone applications. The optional arguments are passed to the application without modification. For more information see %REF{type=Section, topic=UBootStandalone, name=UBootStandalone}%.
5.9.3. Flash Memory Commands
1. Abstract
5.9.5. Download Commands
Prev
Home
Next