|
Main / Uboot
Environment VariablesEditing EV edit command behavior --- Adding new EVs --- Env image compiler --- Traditional NetbootYou can bring a file over the network and load it into a memory location with tftp 0x1000 <filename> tftp ${loadaddr} ${bootfile}; tftp ${rootaddr} ${rootfile}; bootm ${loadaddr} where loadaddr is the kernel address and rootaddr is the root FS address If you add a consoleblank=0 to the bootargs, it will prevent embedded Linux from powering the LCD display off. http://www.stlinux.com/u-boot/modifying Uboot (or perhaps certain PHYs) seem to have trouble with Ethernet auto-negotiation for some switches, like Netgear. Configure the switch port to be 10baseT if possible. What is a BSP?A Board Support Package is a sort of bare metal substitute for a well-endowed boot loader during board bringup. It offers drivers, tools, and tests to help bring the board to life. Booting Linux kernelFor ARM, the kernel image ends up in arch/arm/boot/Image. Use this as the input to the mkimage util, which will output uImage - a format uboot can understand and boot. Here's an example mkimage command: mkimage -A arm -O linux -T kernel -C none -a 0x10008000 -e 0x10008000 -n Linux-version -d arch/arm/boot/Image uImage More on dissecting the uImage: http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/ Boot from USBhttp://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot#USB_Storage You can also load the rootfs from USB, but first you have to use mkimage to create the proper version: mkimage -A arm -O linux -T ramdisk -C none -a 0x12800000 -e 0x12800000 -n Linux-ramdisk -d rootfs.ext2 rootfs.img Sample boot command sets:nandFSboot=usb start ; load usb 0:1 0x10800000 uImage; load usb 0:1 0x12000000 imx6qp-nitrogen6_max.dtb ; load usb 0:1 0x12800000 rootfs.mkfs.img ; setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk0p1 rw rootfstype=ext4 init=/sbin/init ; bootm 10800000 – 12000000 ramboot=usb start ; load usb 0:1 0x10800000 uImage; load usb 0:1 0x12000000 imx6qp-nitrogen6_max.dtb ; load usb 0:1 0x12800000 rootfs.mkfs.img ; setenv bootargs console=ttymxc0,115200 root=/dev/ram0 rw ramdisk_size=33619008 ; bootm 10800000 12800000 12000000 The use of bootm command is: bootm $(kernel_addr) $(ramdisk_addr) $(dtb_addr) Boot from FAT partitionfatload mmc 0 <addr> <filename> What is FIT image?Means Flat Image Tree. Seems to be a style of image that can hold a kernel, an fdt (flattened device tree), FPGA bitstream, for example. Probably an assortment of stuff. Looks like you can use mkimage to generate one. Adding bootelfSimply add a #define CONFIG_CMD_ELF to the include/configs/<board>.h file. Prep for a new board(old way, circa 2013) Add your board to the boards.cfg file. Create a new folder for your board under board/<builder>/<name> and add in critical files such as: Borrow a Makefile from another board's folder and change the name of the .o to match the new board. The macros for the pins are in arch/arm/include/asm/... NOTE: it appears that the new Kconfig system does NOT use boards.cfg, but configs/<board>_defconfig instead.
Previously, all configuration was done by hand, which involved creating symbolic links and editing configuration files manually. More recently, U-Boot has added the Kbuild infrastructure used by the Linux kernel, allowing you to use the "make menuconfig" command to configure your build. If you get this error, check your drive. Will get this for a Win/Lin share for a virtual machine. scripts/kconfig/conf --silentoldconfig Kconfig ln: failed to create symbolic link `arch/arm/include/asm/arch': Read-only file system make[1]: *** [create_symlink] Error 1 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'. Stop. Ethernetdrivers/net/phy/phy.c phy_init function shows which chip manufacturers are supported with init func calls based on CONFIG_PHY_ parameters. SD CardSince card detect is not part of the micro SD standard IF, the mmc driver has a card detect placeholder function board_mmc_getcd which will return -1 unless you overload the function with one of you own in your <board>.c file. For example, your function could check a GPIO pin to which you've connected a card detect circuit. There's an fsl_esdhc module that's also part of this thing, and it has a struct to let you set up some critical things (like clock pin and base address for the correct uSDHC channel)
static struct fsl_esdhc_cfg usdhc_cfg = {
.esdhc_base = USDHC3_BASE_ADDR,
.max_bus_width = 4
};
int board_mmc_init(bd_t *bis)
{
printf("%s:\n", __func__ );
usdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
...
File Systems, ImagesUboot can write and read an ext file system with ext4load and ext4write. For example, if you want to store files on a formatted MMC flash device, you can do: usb start load usb 0:1 0x10800000 uImage load usb 0:1 0x12000000 imx6qp-nitrogen6_max.dtb ext4write mmc 1:1 0x10800000 /boot/uImage <size in HEX> ext4write mmc 1:1 0x12000000 /boot/imx6qp-nitrogen6_max.dtb <size in HEX> A rootfs.ext2 file however is not an archive, and if you want to write to flash it has to be raw. In Linux you can do this with dd or cat. In Uboot you would use mmc write, with block size apparently the same as sector size. Set mmc dev first. With onboard NAND flash I got this working only with partition 0, which seemed strange because the large partition given by parted was 1. The size is the num of image bytes divided the block size (512 in my case). On that partition, the write to 0 worked. When doing it this way, the mmcblk0p1 was blown away I guess and on boot Linux recognized no partitions. However, the FS was there directly on /dev/mmcblk0 instead of /dev/mmcblk0p1. Uboot can list files on a FAT32 USB drive with ls usb 0:1 Building with BuildrootBuildroot can build Uboot for you, and gives similar options to the kernel build. For the 'board name' option, you will select the name of the .cfg file in board/<manuf>/<type> that matches your processor. U-boot Command ToolsLook for the U_BOOT_CMD macro. The function files for these commands are under cmd/. The individual commands can be added/removed in the include/config_cmd_all.h file. USB ProblemsSome instances of Uboot on some boards can have USB stability problems, which results in failures when trying to copy large files from a USB drive to memory. => load usb 0:1 0x12800000 rootfs.big.ext2 reading rootfs.big.ext2 EHCI timed out on TD - token=0x22008d80 EHCI fail timeout STS_ASS reset EHCI timed out on TD - token=0x80008d80 EHCI fail timeout STS_ASS reset EHCI timed out on TD - token=0x80008d80 EHCI fail timeout STS_ASS reset EHCI timed out on TD - token=0x80008d80 EHCI fail timeout STS_ASS reset EHCI timed out on TD - token=0x1f8c80 EHCI fail timeout STS_ASS reset … Error reading cluster ** Unable to read file rootfs.big.ext2 ** => No one seems to have a solution for this, the suggestions I've found haven't worked. There is one theory out there that it has to do with the line traces. PXEA new boot standard. Preboot execution environment (PXE), pronounced pixie, is a set of standards that enables a computer to load an operating system (OS) over a network connection. In your /tftpboot folder, you have a folder called pxelinux.cfg/ and inside is a text file called default which tells the system the names of the files needed for boot, which files reside in /tftpboot. For example LABEL Linux KERNEL Image FDT system.dtb INITRD rootfs.cpio.gz.u-boot Critical Commands
pxe get
-------
syntax: pxe get
follows PXELINUX's rules for retrieving configuration files from a tftp
server, and supports a subset of PXELINUX's config file syntax.
Environment
-----------
'pxe get' requires two environment variables to be set:
pxefile_addr_r - should be set to a location in RAM large enough to hold
pxe files while they're being processed. Up to 16 config files may be
held in memory at once. The exact number and size of the files varies with
how the system is being used. A typical config file is a few hundred bytes
long.
bootfile,serverip - these two are typically set in the DHCP response
handler, and correspond to fields in the DHCP response.
'pxe get' optionally supports these two environment variables being set:
ethaddr - this is the standard MAC address for the ethernet adapter in use.
'pxe get' uses it to look for a configuration file specific to a system's
MAC address.
pxeuuid - this is a UUID in standard form using lower case hexadecimal
digits, for example, 550e8400-e29b-41d4-a716-446655440000. 'pxe get' uses
it to look for a configuration file based on the system's UUID.
File Paths
----------
'pxe get' repeatedly tries to download config files until it either
successfully downloads one or runs out of paths to try. The order and
contents of paths it tries mirrors exactly that of PXELINUX.
pxe boot
--------
syntax: pxe boot [pxefile_addr_r]
Interprets a pxe file stored in memory.
pxefile_addr_r is an optional argument giving the location of the pxe file.
The file must be terminated with a NUL byte.
Environment
-----------
There are some environment variables that may need to be set, depending
on conditions.
pxefile_addr_r - if the optional argument pxefile_addr_r is not supplied,
an environment variable named pxefile_addr_r must be supplied. This is
typically the same value as is used for the 'pxe get' command.
bootfile - typically set in the DHCP response handler based on the
same field in the DHCP respone, this path is used to generate the base
directory that all other paths to files retrieved by 'pxe boot' will use.
If no bootfile is specified, paths used in pxe files will be used as is.
serverip - typically set in the DHCP response handler, this is the IP
address of the tftp server from which other files will be retrieved.
kernel_addr_r, initrd_addr_r - locations in RAM at which 'pxe boot' will
store the kernel(or FIT image) and initrd it retrieves from tftp. These
locations will be passed to the bootm command to boot the kernel. These
environment variables are required to be set.
fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it
retrieves from tftp. The retrieval is possible if 'fdt' label is defined in
pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r'
will be passed to bootm command to boot the kernel.
fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm
command if it is set and 'fdt_addr_r' is not passed to bootm command.
|