The DENX U-Boot and Linux Guide (DULG) for m28 Table of contents: • 1. Abstract • 2. Introduction ♦ 2.1. Copyright ♦ 2.2. Disclaimer ♦ 2.3. Availability ♦ 2.4. Credits ♦ 2.5. Translations ♦ 2.6. Feedback ♦ 2.7. Conventions • 3. Embedded Linux Development Kit ♦ 3.1. ELDK Availability ♦ 3.2. ELDK Getting Help ♦ 3.3. Supported Host Systems ♦ 3.4. Supported Target Architectures ♦ 3.5. Installation ◊ 3.5.1. Product Packaging ◊ 3.5.2. Downloading the ELDK ◊ 3.5.3. Initial Installation ◊ 3.5.4.
♦ 5.4. Installation ◊ 5.4.1. Before You Begin ⋅ 5.4.1.1. Installation Requirements ⋅ 5.4.1.2. Board Identification Data ◊ 5.4.2. Installation Using a BDM/JTAG Debugger ◊ 5.4.3. Installation using U-Boot ♦ 5.5. Tool Installation ♦ 5.6. Initialization ♦ 5.7. Initial Steps ♦ 5.8. The First Power-On ♦ 5.9. U-Boot Command Line Interface ◊ 5.9.1. Information Commands ⋅ 5.9.1.1. bdinfo - print Board Info structure ⋅ 5.9.1.2. coninfo - print console devices and informations ⋅ 5.9.1.3.
⋅ 5.9.7.3. fdt print - recursive print ⋅ 5.9.7.4. fdt mknode - create new nodes ⋅ 5.9.7.5. fdt set - set node properties ⋅ 5.9.7.6. fdt rm - remove nodes or properties ⋅ 5.9.7.7. fdt move - move FDT blob to new address ⋅ 5.9.7.8. fdt chosen - fixup dynamic info ◊ 5.9.8. Special Commands ⋅ 5.9.8.1. i2c - I2C sub-system ◊ 5.9.9. Storage devices ⋅ 5.9.9.1. MMC devices ⋅ 5.9.9.2. NAND devices • 5.9.9.2.1. nand bad - show bad block information • 5.9.9.2.2. nand erase - erase region • 5.9.9.2.3.
• 9.1.5.3.1. Determining the Parameters of the used Flash Types: • 9.1.5.3.2. Create some Test File System Hierarchy • 9.1.5.3.3. Installing UBIFS images into existing UBI Volume: • 9.1.5.3.4. Installing UBI images (if no UBI Volumes exist): ♦ 9.2. The TMPFS Virtual Memory Filesystem ◊ 9.2.1. Mount Parameters ◊ 9.2.2. Kernel Support for tmpfs ◊ 9.2.3. Usage of tmpfs in Embedded Systems ♦ 9.3. Using MultiMediaCards in Linux" ♦ 9.4. Splash Screen Support in Linux ♦ 9.5.
♦ 13.1. Flat Device Tree ♦ 13.2. BDI2000 Configuration file • 14. FAQ - Frequently Asked Questions ♦ 14.1. ELDK ◊ 14.1.1. ELDK Installation under FreeBSD ◊ 14.1.2. ELDK Installation Hangs ◊ 14.1.3. .gvfs: Permission Denied ◊ 14.1.4. Installation on Local Harddisk ◊ 14.1.5. System Include Files Missing ◊ 14.1.6. patch: command not found ◊ 14.1.7. ELDK Include Files Missing ◊ 14.1.8. Using the ELDK on a 64 bit platform ◊ 14.1.9. How can I check if Floating Point support is working? ◊ 14.1.10. ELDK 2.
◊ 14.3.12. Loopback interface does not work ◊ 14.3.13. Linux kernel messages are not printed on the console ◊ 14.3.14. Linux ignores input when using the framebuffer driver ◊ 14.3.15. How to switch off the screen saver and the blinking cursor? ◊ 14.3.16. BogoMIPS Value too low ◊ 14.3.17. Linux Kernel crashes when using a ramdisk image ◊ 14.3.18. Ramdisk Greater than 4 MB Causes Problems ◊ 14.3.19. Combining a Kernel and a Ramdisk into a Multi-File Image ◊ 14.3.20.
• 2. Introduction ♦ 2.1. Copyright ♦ 2.2. Disclaimer ♦ 2.3. Availability ♦ 2.4. Credits ♦ 2.5. Translations ♦ 2.6. Feedback ♦ 2.7. Conventions 2. Introduction This document describes how to use the firmware U-Boot and the operating system Linux in Embedded Power Architecture®, ARM and MIPS Systems. There are many steps along the way, and it is nearly impossible to cover them all in depth, but we will try to provide all necessary information to get an embedded system running from scratch.
• Send your derivative work (in the most suitable format such as sgml) to the author. • License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used. • Give due credit to previous authors and major contributors. It is requested that corrections and/or comments be forwarded to the author. If you are considering to create a derived work other than a translation, it is requested that you discuss your plans with the author. 2.2.
Directory Names Commands to be typed Applications Names Prompt of users command under bash shell Prompt of root users command under bash shell Prompt of users command under tcsh shell Environment Variables Emphasized word Code Example directory a command another application bash$ bash# tcsh$ VARIABLE word ls -l • 3. Embedded Linux Development Kit ♦ 3.1. ELDK Availability ♦ 3.2. ELDK Getting Help ♦ 3.3. Supported Host Systems ♦ 3.4. Supported Target Architectures ♦ 3.5. Installation ◊ 3.5.1.
3.1. ELDK Availability The ELDK is available • on DVD-ROM from DENX Computer Systems • for download on the following server: FTP HTTP ftp://ftp.denx.de/pub/eldk/ http://www.denx.de/ftp/pub/eldk/ • for download on the following mirrors: FTP HTTP ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/eldk/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/eldk/ ftp://mirror.switch.ch/mirror/eldk/ http://mirror.switch.ch/ftp/mirror/eldk/ not available http://mira.sunsite.utk.edu/eldk/ ftp://ftp.sunet.
3.4. Supported Target Architectures The ELDK for ARM systems supports processors complying with the ARM architecture version 2 to 6. This includes ARM7, ARM9, XScale, AT91RM9200, i.MX31, S3C6400 and other ARM based systems. The version of 4.2 and higher of ELDK has two ARM targets in distribution - one with the soft-float math support, and another one with the Vector Floating Point math support. Both targets comply with ARM Embedded Application Binary Interface (EABI).
You can either download the ready-to-burn ISO-images from one of the mirror sites (see 3.1. ELDK Availability), or you can download the individual files of the ELDK from the development directory tree and either use these directly for installation or create an ISO image that can be burned on DVD-ROM. Change to a directory with sufficient free disk space; for the ARM version of the ELDK you need about 510 MiB, or twice as much (1.1 GiB) if you also want to create an ISO image in this directory.
The initial installation is performed using the install utility located in the root of the ELDK ISO image directory tree. The install utility has the following syntax: $ ./install [-d
] [] [] ... -d Specifies the root directory of the ELDK being installed. If omitted, the ELDK goes into the current directory. Specifies the target CPU family the user desires to install.To install a package, use the following command: bash$ ${CROSS_COMPILE}rpm -i To update a package, use the following command: bash$ ${CROSS_COMPILE}rpm -U For the above commands to work correctly, it is crucial that the correct rpm binary gets invoked. In case of multiple ELDK installations and RedHat-based host system, there may well be several rpm tools installed on the host system.
• The trailing '-' character in the CROSS_COMPILE variable value is optional and has no effect on the cross tools behavior. However, it is required when building Linux kernel and U-Boot images. • Add the directories /opt/eldk/usr/bin and /opt/eldk/bin to PATH: bash$ PATH=$PATH:/opt/eldk/usr/bin:/opt/eldk/bin • Compile a file: bash$ ${CROSS_COMPILE}gcc -o hello_world hello_world.
/opt/eldk/arm Before the NFS-mounted root file system can work, you must create necessary device nodes in the //dev directory. This process requires superuser privileges and thus cannot be done by the installation procedure (which typically runs as non-root). To facilitate creation of the device nodes, the ELDK provides a script named ELDK_MAKEDEV, which is located in the root of the ELDK distribution ISO image.
After an ELDK source RPM is installed using the above command, its spec file and sources can be found in the subdirectories of the /usr/src/denx subdirectory. The sections that follow provide detailed instructions on rebuilding ELDT and target components of the ELDK. 3.8.2. Rebuilding Target Packages All the target packages can be rebuilt from the provided source RPM packages. At first you have to install the Source RPM itself: bash$ ${CROSS_COMPILE}rpm -iv .src.
3.9. ELDK Packages 3.9.1. List of ELDT Packages Package Name Package Version autoconf 2.61-8 automake 1.10-5 bison 2.3-3 crosstool-devel 0.43-3 dtc 20070802-1 elocaledef 1-1 ftdump 20070802-1 gdb 6.7-2 genext2fs 1.4.1-1 info 4.8-15 ldd 0.1-1 libtool 1.5.22-11 make 3.81-6 mkcramfs 1.1-1 mkimage 1.3.1-1 mtd-utils 1.0.1-2 rpm 4.4.2-46_2 rpm-build 4.4.2-46_2 sed 4.1.4-1 texinfo 4.8-15 Note: The crosstool 0.43 ELDT package provides the following packages: gcc 4.2.
bash 3.2-9 bc 1.06-26 bind 9.4.1-8.P1 binutils 2.17.90-1 binutils-devel 2.17.90-1 boa 0.94.14-0.5.rc21 busybox 1.7.1-2 byacc 1.9.20050813-1 bzip2 1.0.4-10 bzip2-devel 1.0.4-10 bzip2-libs 1.0.4-10 ccid 1.2.1-10 chkconfig 1.3.34-1 coreutils 6.9-3 cpio 2.6-27 cpp 4.2.2-2 cracklib 2.8.9-11 cracklib-dicts 2.8.9-11 crosstool-targetcomponents 0.43-3 curl 7.16.2-1 cyrus-sasl 2.1.22-6 cyrus-sasl-devel 2.1.22-6 cyrus-sasl-lib 2.1.22-6 db4 4.5.20-5_2 db4-devel 4.5.
dropbear 0.50-1 dtc 20070802-1 duma 2.5.8-2 e2fsprogs 1.39-11 e2fsprogs-devel 1.39-11 e2fsprogs-libs 1.39-11 ethtool 5-1 expat 1.95.8-9 expat-devel 1.95.8-9 file 4.21-1 file-libs 4.21-1 findutils 4.2.29-2 flex 2.5.33-9 freetype 2.3.4-3 freetype-devel 2.3.4-3 ftdump 20070802-1 ftp 0.17-40 gawk 3.1.5-15 gcc 4.2.2-2 gcc-c++ 4.2.2-2 gcc-java 4.2.2-2 gdb 6.7-1 glib 1.2.10-26 glib2 2.12.13-1 glib2-devel 2.12.13-1 glib-devel 1.2.10-26 gmp 4.1.4-12.3 grep 2.5.
initscripts 8.54.1-1 iproute 2.6.20-2 iptables 1.3.8-2 iputils 20070202-3 iscsitarget 0.4.15-1 kbd 1.12-22 kernel-headers 2.6.24-1 kernel-source 2.6.24-1 krb5-devel 1.6.1-2.1 krb5-libs 1.6.1-2.1 less 394-9 libattr 2.4.32-2 libattr-devel 2.4.32-2 libcap 1.10-29 libcap-devel 1.10-29 libpng 1.2.16-1 libpng-devel 1.2.16-1 libsysfs 2.1.0-1 libsysfs-devel 2.1.0-1 libtermcap 2.0.8-46.1 libtermcap-devel 2.0.8-46.1 libtirpc 0.1.7-7_2 libtirpc-devel 0.1.7-7_2 libtool 1.
ltp 20080131-eldk2 lvm2 2.02.24-1 m4 1.4.8-2 mailcap 2.1.23-1 make 3.81-6 MAKEDEV 3.23-1.2 man 1.6e-3 mdadm 2.6.2-4 microwindows 0.91-2 microwindows-fonts 0.91-1 mingetty 1.07-5.2.2 mktemp 1.5-25 module-init-tools 3.3-0.pre11.1.0 mtd-utils 1.0.1-2 ncompress 4.2.4-49 ncurses 5.6-17 ncurses-devel 5.6-17 net-snmp 5.4-14 net-snmp-devel 5.4-14 net-snmp-libs 5.4-14 net-snmp-utils 5.4-14 net-tools 1.60-82 newt 0.52.6-30 newt-devel 0.52.6-30 nfs-utils 1.1.
passwd 0.74-3 patch 2.5.4-29.2.2 pciutils 2.2.4-3_2 pciutils-devel 2.2.4-3_2 pcmciautils 014-9_2 pcre 7.0-2 pcsc-lite 1.3.3-1.0 pcsc-lite-devel 1.3.3-1.0 pcsc-lite-libs 1.3.3-1.0 perl 5.8.8-18_2 perl-libs 5.8.8-18_2 popt 1.12-1 portmap 4.0-65_2 postgresql 8.2.4-1_2 postgresql-devel 8.2.4-1_2 postgresql-libs 8.2.4-1_2 ppp 2.4.4-7 procps 3.2.7-14 psmisc 22.3-2 python 2.5.1-1 rdate 1.4-6 readline 5.2-4 readline-devel 5.2-4 routed 0.17-12_1 rpcbind 0.1.
setup 2.6.4-1_2 shadow-utils 4.0.18.1-15 slang 2.0.7-17 slang-devel 2.0.7-17 smartmontools 5.38-2 strace 4.5.15-1 sysfsutils 2.1.0-1 sysklogd 1.4.2-9 sysvinit 2.86-17 tar 1.15.1-26 tcp_wrappers 7.6-48 tcp_wrappers-devel 7.6-48 tcp_wrappers-libs 7.6-48 telnet 0.17-38 telnet-server 0.17-38 termcap 5.5-1.20060701.1 tftp 0.42-4 tftp-server 0.42-4 thttpd 2.25b-13 time 1.7-29 u-boot 1.3.1-1 udev 106-4.1 unixODBC 2.2.12-2 unzip 5.52-4 util-linux 2.13-0.
xenomai 2.4.2-1 xinetd 2.3.14-12 zip 2.31-3 zlib 1.2.3-10 zlib-devel 1.2.3-10 Note 1: Not all packages will be installed automatically; for example the boa and thttpd web servers are mutually exclusive - you will have to remove one package before you can (manually) install the other one. Note 2: The crosstool 0.43 target package provides the following packages: glibc 2.6, glibc-common 2.6, glibc-devel 2.6, libstdc++ 4.2.2, libgcj 4.2.2, libgcj-devel 4.2.2 and libstdc++-devel 4.2.2.
SRPMS Fedora 7 sources Then you may switch to a specific release of the ELDK using the "git-checkout" command; for example, to get the files for ELDK release 4.1, please do the following from the module directory: git-checkout ELDK_4_2 It must be noted that some of the packages which are included in the ELDK are not included in Fedora. Examples of such packages are appWeb, microwindows, and wu-ftpd. For these packages tarballs are provided in the DENX GIT repository.
/ build/cross_rpms//SPECS/... SOURCES/... target_rpms//SPECS/... SOURCES/... install/install.c Makefile misc/ELDK_MAKEDEV ELDK_FIXOWNER README.html cpkgs.lst tpkgs.lst build.sh ELDK_BUILD SRPMS.lst tarballs.lst tarballs/.... SRPMS/.... SRPMS-updates/.... In subdirectories of the cross_rpms and target_rpms directories, the sources and RPM spec files of, respectively, the ELDT and target packages are stored.
3.10.2. Setting Up ELDK Build Environment For your convenience, the ELDK build environment CD-ROM provides full ELDK build environment. All you need to do is copy the contents of the CD-ROM to an empty directory on your host system. Assuming the ELDK build environment CD-ROM is mounted at /mnt/cdrom, and the empty directory where you want to create the build environment is named /opt/eldk, use the following commands to create the build environment: bash$ cd /opt/eldk bash$ cp -r /mnt/cdrom/* .
files (see below for details). You may specify which sub-steps of the build step are to be performed. The formal syntax for the usage of build.sh is as follows: bash$ ./build.sh [-a ] [-n ] [-p ] [-r ] \ [-w ] [] -a target architecture: "ppc", "ppc64", "arm" or "mips", defaults to "ppc". -n an identification string for the build. It is used as a name for some directories created during the build.
3.10.4. Format of the cpkgs.lst and tpkgs.lst Files Each line of these files has the following format: \ The ELDK source CD-ROM contains the cpkgs.lst and tpkgs.lst files used to build this version of the ELDK distribution. Use them as reference if you want to include any additional packages into the ELDK, or remove unneeded packages. To add a package to the ELDK you must add a line to either the cpkgs.
4.2. Configuring the "cu" command The cu command is part of the UUCP package and can be used to act as a dial-in terminal. It can also do simple file transfers, which can be used in U-Boot for image download. On RedHat systems you can check if the UUCP package is installed as follows: $ rpm -q uucp If necessary, install the UUCP package from your distribution media.
• ~/.kermrc: set line /dev/ttyS0 set speed 115200 set carrier-watch off set handshake none set flow-control none robust set file type bin set file name lit set rec pack 1000 set send pack 1000 set window 5 This example assumes that you use the first serial port of your host system (/dev/ttyS0) at a baudrate of 115200 to connect to the target's serial console port. You can then connect to the serial line: $ kermit -c Connecting to /dev/ttyS0, speed 115200.
4.6. Configuration of a TFTP Server The fastest way to use U-Boot to load a Linux kernel or an application image is file transfer over Ethernet. For this purpose, U-Boot implements the TFTP protocol (see the tftpboot command in U-Boot). To enable TFTP support on your host system you must make sure that the TFTP daemon program /usr/sbin/in.tftpd is installed. On RedHat systems you can verify this by running: $ rpm -q tftp-server If necessary, install the TFTP daemon program from your distribution media.
option domain-name-servers ns.local.net; host trgt { hardware ethernet fixed-address option root-path option host-name next-server filename 00:30:BF:01:02:D0; 192.168.20.38; "/opt/eldk-5.2/armv5te/rootfs"; "m28"; 192.168.1.1; "/tftpboot/duts/m28/uImage"; } } With this configuration, the DHCP server will reply to a request from the target with the ethernet address 00:30:BF:01:02:D0 with the following information: • The target is located in the subnet 192.168.0.0 which uses the netmask 255.255.0.0.
◊ 5.4.2. Installation Using a BDM/JTAG Debugger ◊ 5.4.3. Installation using U-Boot ♦ 5.5. Tool Installation ♦ 5.6. Initialization ♦ 5.7. Initial Steps ♦ 5.8. The First Power-On ♦ 5.9. U-Boot Command Line Interface ◊ 5.9.1. Information Commands ⋅ 5.9.1.1. bdinfo - print Board Info structure ⋅ 5.9.1.2. coninfo - print console devices and informations ⋅ 5.9.1.3. flinfo - print FLASH memory information ⋅ 5.9.1.4. iminfo - print header information for application image ⋅ 5.9.1.5. help - print online help ◊ 5.9.
⋅ 5.9.7.7. fdt move - move FDT blob to new address ⋅ 5.9.7.8. fdt chosen - fixup dynamic info ◊ 5.9.8. Special Commands ⋅ 5.9.8.1. i2c - I2C sub-system ◊ 5.9.9. Storage devices ⋅ 5.9.9.1. MMC devices ⋅ 5.9.9.2. NAND devices • 5.9.9.2.1. nand bad - show bad block information • 5.9.9.2.2. nand erase - erase region • 5.9.9.2.3. nand write - write to NAND device • 5.9.9.2.4. nand read - read from NAND device ◊ 5.9.10. Miscellaneous Commands ⋅ 5.9.10.1. date - get/set/reset date & time ⋅ 5.9.10.2.
5.2. Unpacking the Source Code If you use GIT to get a copy of the U-Boot sources, here an example how you get the sources with git: Note: Included topic DULGData_m28.UBootGetSource does not exist yet If you used GIT to get a copy of the U-Boot sources, then you can skip this next step since you already have an unpacked directory tree. If you downloaded a compressed tarball from the DENX FTP server, you can unpack it as follows: $ $ $ $ $ $ cd /opt/eldk/usr/src wget ftp://ftp.denx.de/pub/u-boot/2012.07.
5.4. Installation 5.4.1. Before You Begin 5.4.1.1. Installation Requirements The following section assumes that flash memory is used as the storage device for the firmware on your board. If this is not the case, the following instructions will not work - you will probably have to replace the storage device (probably ROM or EPROM) on such systems to install or update U-Boot. 5.4.1.2. Board Identification Data All m28 boards use a serial number for identification purposes.
update=echo done => setenv u-boot /tftpboot/duts/m28/u-boot.bin => run load update if mmc rescan ; then if tftp ${update_sd_firmware_filename} ; then setexpr fw_sz ${filesize} / 0x Using FEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.20.33 Filename 'duts/m28/u-boot.mx28.sd'. Load address: 0x42000000 Loading: ############################### done Bytes transferred = 446080 (6ce80 hex) MMC write: dev # 0, block # 2048, count 872 ... 872 blocks write: OK done => reset resetting ...
The default configuration of the console port on the m28 board uses a baudrate of 115200/8N1 (115200 bps, 8 Bit per character, no parity, 1 stop bit, no handshake). If you are running Linux on your host system we recommend either kermit or cu as terminal emulation programs. Do not use minicom, since this has caused problems for many users, especially for software download over the serial port. For the configuration of your terminal program see section 4.1.
- print values of all environment variables printenv name ... - print value of environment variable 'name' tftpboot - boot image via network using TFTP protocol Usage: tftpboot [loadAddress] [[hostIPaddr:]bootfilename] => 5.8. The First Power-On Note: If you bought your m28 board with U-Boot already installed, you can skip this section since the manufacturer probably has already performed these steps.
=> printenv serial# ethaddr serial#=DUTS ethaddr=C0:E5:4E:02:00:00 => Please double check that the printed values are correct! You will not be able to correct any errors later! If there is something wrong, reset the board and restart from the beginning; otherwise you can store the parameters permanently using the saveenv command: => saveenv Saving Environment to NAND... Erasing NAND... Erasing at 0x300000 -- 25% complete.Erasing at 0x320000 -Writing to NAND... done => 50% complete.
-> size ethaddr ip_addr baudrate TLB addr relocaddr reloc off irq_sp sp start FB base => = = = = = = = = = = 0x10000000 C0:E5:4E:02:00:00 192.168.20.33 115200 bps 0x4FFF0000 0x4FF48000 0x0FF47F00 0x4FB43F68 0x4FB43F58 0x00000000 5.9.1.2. coninfo - print console devices and informations => help conin coninfo - print console devices and information Usage: coninfo => The coninfo command (short: conin) displays information about the available console I/O devices.
iminfo (short: imi) is used to print the header information for images like Linux kernels or ramdisks. It prints (among other information) the image name, type and size and verifies that the CRC32 checksums stored within the image are OK. => tftp ${ram_ws} ${bootfile} Using FEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.20.33 Filename '/tftpboot/duts/m28/uImage'.
=> You can use the base command (short: ba) to print or set a "base address" that is used as address offset for all memory commands; the default value of the base address is 0, so all addresses you enter are used unmodified.
43000010: 00800040 00800040 9de1110f 00020205 43000020: 756e694c 2e332d78 2d302e36 7478656e => @...@........... Linux-3.6.0-next Like most memory commands the cmp can access the memory in different sizes: as 32 bit (long word), 16 bit (word) or 8 bit (byte) data. If invoked just as cmp the default size (32 bit or long words) is used; the same can be selected explicitely by typing cmp.l instead. If you want to access memory as 16 bit or word data, you can use the variant cmp.
42000020: => 42000030: 42000040: 42000050: => 756e694c 2e332d78 2d302e36 7478656e Linux-3.6.0-next 3130322d 30303132 30302d31 2d343130 e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 e1a00000 -20121001-00014................ ................ This command, too, can be used with the type extensions .l, .w and .b : => => md.w 0x42000000 42000000: 0527 5619 7c80 8daa 6a50 dcea 2100 606e 42000010: 0040 0080 0040 0080 @...@... => d.b 0x4200000 '..V.|..Pj...
42000010: 00800040 00800040 9de1110f 00020205 42000020: 756e694c 2e332d78 2d302e36 7478656e 42000030: 3130322d 30303132 30302d31 2d343130 => => => mm.b 0x42000000 42000000: 01 ? 0x48 42000001: 01 ? 0x65 42000002: 02 ? 0x6c 42000003: 02 ? 0x6c 42000004: 21 ? 0x6f 42000005: 43 ? 0x20 42000006: 65 ? 0x20 42000007: 87 ? 0x20 42000008: 67 ? .
42000010: ffffffea ffffffe9 42000020: ffffffe6 ffffffe5 42000030: ffffffe2 ffffffe1 => mw 0x42000000 0xaabbccdd => md 0x42000000 0x10 42000000: aabbccdd ffffffed 42000010: ffffffea ffffffe9 42000020: ffffffe6 ffffffe5 42000030: ffffffe2 ffffffe1 => mw 0x42000000 0 6 => md 0x42000000 0x10 42000000: 00000000 00000000 42000010: 00000000 00000000 42000020: ffffffe6 ffffffe5 42000030: ffffffe2 ffffffe1 => ffffffe8 ffffffe7 ffffffe4 ffffffe3 ffffffe0 ffffffdf ................ ................ ................
5.9.2.10. loop - infinite loop on address range => help loop loop - infinite loop on address range Usage: loop [.b, .w, .l] address number_of_objects => The loop command reads in a tight loop from a range of memory. This is intended as a special form of a memory test, since this command tries to read the memory as fast as possible. This command will never terminate. There is no way to stop it but to reset the board! => loop 100000 8 5.9.3. Flash Memory Commands 5.9.3.1.
5.9.3.3. erase - erase FLASH memory Note: Included topic DULGData_m28.UBootEraseHelp does not exist yet The erase command (short: era) is used to erase the contents of one or more sectors of the flash memory. It is one of the more complex commands; the help output shows this. Probably the most frequent usage of this command is to pass the start and end addresses of the area to be erased: Note: Included topic DULGData_m28.
The protect command is another complex one. It is used to set certain parts of the flash memory to read-only mode or to make them writable again. Flash memory that is "protected" (= read-only) cannot be written (with the cp command) or erased (with the erase command). Protected areas are marked as (RO) (for "read-only") in the output of the flinfo command: Note: Included topic DULGData_m28.
this command uses three environment variables: 'partition' - keeps current partition identifier partition := := ,part_num 'mtdids' - linux kernel mtd device id <-> u-boot device id mapping mtdids=[,,...] := := := := = 'nand'|'nor'|'onenand' mtd device number, 0... unique device tag used by linux kernel to find mtd device (mtd->name) 'mtdparts' - partition list mtdparts=mtdparts=[;...
=> mtdparts device nand0 , # parts = 3 #: name size 0: bootloader 0x00300000 1: environment 0x00080000 2: redundant-environment0x00080000 offset 0x00000000 0x00300000 0x00380000 mask_flags 1 0 0 active partition: nand0,0 - (bootloader) 0x00300000 @ 0x00000000 defaults: mtdids : nand0=gpmi-nand mtdparts: mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(ke => ...
device nand0 , # parts = 5 #: name size 0: bootloader 0x00300000 1: environment 0x00080000 2: redundant-environment0x00080000 3: kernel 0x00400000 4: filesystem 0x0f800000 offset 0x00000000 0x00300000 0x00380000 0x00400000 0x00800000 mask_flags 1 0 0 0 0 active partition: nand0,0 - (bootloader) 0x00300000 @ 0x00000000 defaults: mtdids : nand0=gpmi-nand mtdparts: mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(ke => U-Boot provides the following command li
UBI: UBI: UBI: UBI: => available PEBs: 1961 total number of reserved PEBs: 23 number of PEBs reserved for bad PEB handling: 19 max/mean erase counter: 1/0 Now that the UBI device is attached, this device can be accessed using the following commands: ubi ubi ubi ubi ubi info createvol removevol read write Display volume and ubi layout information Create UBI volume on UBI device Remove UBI volume from UBI device Read data from UBI volume to memory Write data from memory to UBI volume For example display
42000020: 00000800 0001f000 0000000e 000007c0 ................ 42000030: 00800000 00000000 00000005 00000002 ................ 42000040: 00000001 00000001 00000008 00000100 ................ 42000050: 00000004 00000001 00000000 00000000 ................ 42000060: 00000000 00000000 3b9aca00 71b3e5e9 ...........;...q 42000070: fa46cc48 aabe65a2 32ec78f1 00000000 H.F..e...x.2.... 42000080: 00000000 00000000 00000000 00000000 ................ 42000090: 00000000 00000000 00000000 00000000 ................
UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 1984 UBI: number of PEBs reserved for bad PEB handling: 19 UBI: max/mean erase counter: 4/1 => ubifsmount filesystem UBIFS: mounted UBI device 0, volume 0, name "filesystem" UBIFS: mounted read-only UBIFS: file system size: 247603200 bytes (241800 KiB, 236 MiB, 1950 LEBs) UBIFS: journal size: 9023488 bytes (8812 KiB, 8 MiB, 72 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS:
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.
5.9.4.2. bootm - boot application image from memory => help bootm bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. To boot that kernel without an initrd image, use a '-' for the second argument.
5.9.4.3. go - start application at address 'addr' => help go go - start application at address 'addr' Usage: go addr [arg ...] - start application at address 'addr' passing 'arg' as arguments => 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().
=> loadb 100000 ## Ready for binary (kermit) download ... Ctrl-\c (Back at denx.denx.de) ---------------------------------------------------C-Kermit 7.0.197, 8 Feb 2000, for Linux Copyright (C) 1985, 2000, Trustees of Columbia University in the City of New York. Type ? or HELP for help. Kermit> send /bin /tftpboot/pImage ... Kermit> connect Connecting to /dev/ttyS0, speed 115200.
- print values of all environment variables printenv name ... - print value of environment variable 'name' => The printenv command prints one, several or all variables of the U-Boot environment. When arguments are given, these are interpreted as the names of environment variables which will be printed with their values: => printenv ipaddr hostname netmask ipaddr=192.168.20.33 hostname=m28 netmask=255.255.0.
net_nfs=run fdt_netload kernel_netload nfsargs addip addcons addmtd addmisc;bootm ${kernel_addr_r net_nfs_nodt=run kernel_netload nfsargs addip addcons addmtd addmisc;bootm ${kernel_addr_r} netdev=eth0 netmask=255.255.0.0 nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath},v3,tcp partition=nand0,0 rootdev=/dev/mmcblk0p3 rootpath=/opt/eldk-5.2.1/armv5te/rootfs-qte-sdk serverip=192.168.1.
To modify the U-Boot environment you have to use the setenv command. When called with exactly one argument, it will delete any variable of that name from U-Boot's environment, if such a variable exists. Any storage occupied for such a variable will be automatically reclaimed: => setenv foo This is an example value. => printenv foo foo=This is an example value.
run var [...] - run the commands in the environment variable(s) 'var' => You can use U-Boot environment variables to store commands and even sequences of commands. To execute such a command, you use the run command: => setenv test echo This is a test\;printenv ipaddr\;echo Done. => printenv test test=echo This is a test;printenv ipaddr;echo Done. => run test This is a test ipaddr=192.168.20.33 Done.
fdt fdt fdt fdt fdt fdt fdt fdt fdt fdt fdt fdt fdt fdt fdt addr [] move resize print [] list [] set [] mknode rm [] header bootcpu memory rsvmem print rsvmem add rsvmem delete chosen [ ] - Set the fdt location to Copy the fdt to and make it active Resize fdt to size + padding to 4k addr Recursive print starting at Print
=> fdt print /cpus cpus { cpu@0 { compatible = "arm,arm926ejs"; }; }; => 5.9.7.4. fdt mknode - create new nodes fdt mknode can be used to attach a new node to the tree.
testnode { }; => 5.9.7.5. fdt set - set node properties Now, let's create a property at the newly created node; again we'll use fdt list for verification: => fdt set /testnode testprop testvalue => fdt list /testnode testnode { testprop = "testvalue"; }; => 5.9.7.6. fdt rm - remove nodes or properties The fdt rm command is used to remove nodes and properties.
interrupt-parent = <0x1>; model = "DENX M28EVK"; compatible = "denx,m28evk", "fsl,imx28"; chosen { }; aliases { }; memory { }; cpus { }; apb@80000000 { }; ahb@80080000 { }; regulators { }; sound { }; }; => fdt mknod / foobar => fdt list / / { #address-cells = <0x1>; #size-cells = <0x1>; interrupt-parent = <0x1>; model = "DENX M28EVK"; compatible = "denx,m28evk", "fsl,imx28"; foobar { }; chosen { }; aliases { }; memory { }; cpus { }; apb@80000000 { }; ahb@80080000 { }; regulators { }; sound { }; }; => fdt ad
regulators { }; sound { }; }; => 5.9.7.8. fdt chosen - fixup dynamic info One of the modifications made by U-Boot to the blob before passing it to the kernel is the addition of the /chosen node. Linux 2.6 Documentation/powerpc/booting-without-of.txt says that this node is used to store "some variable environment information, like the arguments, or the default input/output devices." To force U-Boot to add the /chosen node to the current blob, fdt chosen command can be used.
=> fdt list /chosen chosen { }; => Note: fdt boardsetup performs board-specific blob updates, most commonly setting clock frequencies, etc. Discovering its operation is left as an excercise for the reader. 5.9.8. Special Commands 5.9.8.1. i2c - I2C sub-system => help i2c i2c - I2C sub-system Usage: i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device i2c md chip address[.0, .1, .
MXS MMC: 0 => With the mmc rescan command you can rescan the actual mmc device. => mmc rescan => The mmcinfo command displays the information about the actual mmc device => mmcinfo Device: MXS MMC Manufacturer ID: 1b OEM: 534d Name: 00000 Tran Speed: 50000000 Rd Block Len: 512 SD version 2.0 High Capacity: No Capacity: 1.9 GiB Bus Width: 4-bit => The mmc part command displays the available partitions on the actual mmc device.
=> md 0x43000000 43000000: 00000000 00000000 43000010: 00000000 00000000 43000020: 00000000 00000000 43000030: 00000000 00000000 43000040: 00000000 00000000 43000050: 00000000 00000000 43000060: 00000000 00000000 43000070: 00000000 00000000 43000080: 00000000 00000000 43000090: 00000000 00000000 430000a0: 00000000 00000000 430000b0: 00000000 00000000 430000c0: 00000000 00000000 430000d0: 00000000 00000000 430000e0: 00000000 00000000 430000f0: 00000000 00000000 => mw 0x42000000 0xdeadface => md 0x42000000 42
MMC write: dev # 0, block # 583, count 16 ... 16 blocks write: OK => mmc read 0x42000000 247 10 MMC read: dev # 0, => md 0x42000000 42000000: 00000000 42000010: 00000000 42000020: 00000000 42000030: 00000000 42000040: 00000000 42000050: 00000000 42000060: 00000000 42000070: 00000000 42000080: 00000000 42000090: 00000000 420000a0: 00000000 420000b0: 00000000 420000c0: 00000000 420000d0: 00000000 420000e0: 00000000 420000f0: 00000000 => block # 583, count 16 ...
420000c0: 420000d0: 420000e0: 420000f0: => 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................ ................ ................ ................ 5.9.9.2. NAND devices U-Boot allows us to directly work with NAND devices attached directly or through a NAND controller.
NAND erase: device 0 offset 0x400000, size 0x10000 Erasing at 0x400000 -- 100% complete. OK => 5.9.9.2.3. nand write - write to NAND device Let's create a testpattern in memory and write that to the previously erased NAND area: => mw 0x42000000 0x55aa55aa 0x4000 => nand write 0x42000000 0x00400000 0x10000 NAND write: device 0 offset 0x400000, size 0x10000 65536 bytes written: OK => 5.9.9.2.4.
5.9.10.2. echo - echo args to console => help echo echo - echo args to console Usage: echo [args..] - echo args to console; \c suppresses newline => The echo command echoes the arguments to the console: => echo The quick brown fox jumped over the lazy dog. The quick brown fox jumped over the lazy dog. => 5.9.10.3. reset - Perform RESET of the CPU => help reset reset - Perform RESET of the CPU Usage: reset => The reset command reboots the system. => => reset resetting ... U-Boot 2012.
5.9.10.5. version - print monitor version => help version version - print monitor, compiler and linker version Usage: version => You can print the version and build date of the U-Boot image running on your system using the version command (short: vers): => version U-Boot 2012.07-00471-ge8925d7-dirty (Oct 01 2012 - 18:20:02) arm-linux-gnueabi-gcc (Debian 4.7.2-2) 4.7.2 GNU ld (GNU Binutils for Debian) 2.22 => 5.9.10.6.
• bootdelay: After reset, U-Boot will wait this number of seconds before it executes the contents of the bootcmd variable. During this time a countdown is printed, which can be interrupted by pressing any key. Set this variable to 0 boot without delay. Be careful: depending on the contents of your bootcmd variable, this can prevent you from entering interactive commands again forever! Set this variable to -1 to disable autoboot.
U-Boot. Define this variable to hold the number of kB you want to reserve for pRAM. Note that the board info structure will still show the full amount of RAM.
echo ===== Linux Kernel settings ===== setenv bootfile /tftpboot/TQM860L/uImage setenv kernel_addr 40040000 setenv load_kernel 'tftp ${loadaddr} ${bootfile};' setenv install_kernel 'era ${kernel_addr} +${filesize};cp.
=> Hint: maximum flexibility can be achieved if you are using the Hush shell as command interpreter in U-Boot; see section 14.2.17. How the Command Line Parsing Works 5.12. U-Boot Standalone Applications U-Boot supports "standalone" applications, which are loaded dynamically; these applications can have access to the U-Boot console I/O functions, memory allocation and interrupt services. A couple of simple examples are included with the U-Boot source code: 5.12.1. "Hello World" Demo examples/hello_world.
## Application terminated, rc = 0x0 5.12.2. Timer Demo This example is only available on MPC8xx CPUs. 5.13. U-Boot Image Formats U-Boot operates on "image" files which can be basically anything, preceeded by a special header; see the definitions in include/image.h for details; basically, the header defines the following image properties: • Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.
This variable will be automatically created if it does not exist, and it will be updated at each reset of the processor. After a power-on reset, it will be initialized with 1, and each reboot will increment the value by 1. bootlimit: If this variable exists, its contents are taken as the maximum number of reboot cycles allowed.
The following command selects a standard configuration for the m28 board that has been extensively tested. It is recommended to use this as a starting point for other, customized configurations: bash$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- m28_defconfig [marex@pollux]$ Note: The name of this default configuration file is arch/arm/configs/XXX . By (recursively) listing the contents of the arch/arm/configs/ directory you can easily find out which other default configurations are available.
◊ 7.5.1. Bootlog of tftp'd Linux kernel with Root Filesystem over NFS ♦ 7.6. Boot from NAND Flash Memory ♦ 7.7. Standalone Operation with Ramdisk Image 7. Booting Embedded Linux 7.1. Introduction In principle, if you have a Linux kernel image and the flattened device tree blob somewhere in system memory (RAM, ROM, flash...), then all you need to boot the system is the bootm command.
device tree source file structure, etc.). 7.3. Passing Kernel Arguments In nearly all cases, you will want to pass additional information to the Linux kernel; for instance, information about the root device or network configuration. In U-Boot, this is supported using the bootargs environment variable. Its contents are automatically passed to the Linux kernel as boot arguments (or "command line" arguments). This allows the use of the same Linux kernel image in a wide range of configurations.
The advantage of this mechanism is that you don't have to spend precious system memory (RAM and flash) for network configuration tools like ifconfig or route - especially in Embedded Systems where you seldom have to change the network configuration while the system is running. We can use U-Boot environment variables to store all necessary configuration parameters: => => => => => => setenv ipaddr 192.168.20.38 setenv serverip 192.168.1.1 setenv netmask 255.255.0.
sections about the respective U-Boot commands. 7.5. Networked Operation with Root Filesystem over NFS This section will show how to boot the target into Linux with no more than U-Boot residing on it. For this we will use the tftp command of U-Boot to transfer a Linux kernel and boot it with the NFS rootfilesystem provided by the ELDK. For this to work, we rely on some U-Boot environment variables to be set up correctly, i.e.
Image Name: Linux-3.6.0-next-20121001-00014Created: 2012-10-02 13:23:40 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2190944 Bytes = 2.1 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 41000000 Booting using the fdt blob at 0x41000000 Loading Kernel Image ... OK OK Loading Device Tree to 4fb3c000, end 4fb430a2 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [ 0.
[ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ 0.230000] 0.240000] 0.240000] 0.250000] 0.250000] 0.260000] 0.260000] 0.270000] 0.290000] 0.300000] 0.300000] 0.310000] 0.320000] 0.320000] 0.330000] 0.330000] 0.340000] 0.340000] 0.350000] 0.350000] 0.360000] 0.400000] 0.400000] 0.410000] 0.410000] 0.420000] 0.420000] 0.440000] 0.460000] 0.630000] 0.640000] 0.650000] 0.670000] 0.680000] 0.680000] 0.690000] 0.700000] 0.
[ 1.350000] hub 2-0:1.0: 1 port detected [ 1.350000] mousedev: PS/2 mouse device common for all mice [ 1.360000] stmp3xxx-rtc 80056000.rtc: rtc core: registered 80056000.rtc as rtc0 [ 1.370000] i2c /dev entries driver [ 1.410000] mxs-mmc 80010000.ssp: initialized [ 1.410000] usbcore: registered new interface driver usbhid [ 1.420000] usbhid: USB HID core driver [ 1.440000] sgtl5000 0-000a: Failed to get supply 'VDDD': -517 [ 1.450000] 0-000a: 1200 mV normal [ 1.
Starting Distributed Compiler Daemon: distcc. creating NFS state directory: done starting 8 nfsd kernel threads: rpc.nfsd: Unable to access /proc/fs/nfsd errno 2 (No such file or Please try, as root, 'mount -t nfsd nfsd /proc/fs/nfsd' and then restart rpc.nfsd to correct the done starting mountd: done starting statd: done Starting system log daemon...0 Starting kernel log daemon...0 Starting internet superserver: xinetd. Starting Lighttpd Web Server: lighttpd. Unknown HZ value! (90) Assume 100.
Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK => nand write ${kernel_addr_r} ${nand_off} ${filesize} NAND write: device 0 offset 0x400000, size 0x216ea0 2191008 bytes written: OK => setenv nand_off => saveenv Saving Environment to NAND... Erasing redundant NAND... Erasing at 0x380000 -- 25% complete.Erasing at 0x3a0000 -Writing to redundant NAND... done => 50% complete.
stdout=serial stderr=serial bootcmd=bootm 42000000 - 41000000 bootargs=root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-5.2/armv5te/rootfs ip=192.168.20.38:192.168.1.1:192.168.1.1:255.255.0.0:m28::off .... => saveenv To test booting from flash you can now reset the board (either by power-cycling it, or using the U-Boot command reset), or you can manually call the boot command which will run the commands in the bootcmd variable: Note: Included topic DULGData_m28.
♦ 9.2. The TMPFS Virtual Memory Filesystem ◊ 9.2.1. Mount Parameters ◊ 9.2.2. Kernel Support for tmpfs ◊ 9.2.3. Usage of tmpfs in Embedded Systems ♦ 9.3. Using MultiMediaCards in Linux" ♦ 9.4. Splash Screen Support in Linux ♦ 9.5. Root File System: Design and Building ◊ 9.5.1. Root File System on a Ramdisk ◊ 9.5.2. Root File System on a JFFS2 File System ◊ 9.5.3. Root File System on a cramfs File System ◊ 9.5.4. Root File System on a Read-Only ext2 File System ◊ 9.5.5. Root File System on a Flash Card ◊ 9.
Now we can run some basic tests to verify that the flash driver routines and the partitioning works as expected: root@generic-armv5te:~# root@generic-armv5te:~# hexdump -C /dev/mtd4 | head In the hex-dumps of the MTD devices you can identify some strings that verify that we indeed see an U-Boot environment, a Linux kernel, a ramdisk image and an empty partition to play wih. The last output shows the partition to be empty.
If the flash device is erased, we can simply mount it, and the creation of the JFFS filesystem is performed automagically. Note: For simple accesses like direct read or write operations or erasing you use the character device interface (/dev/mtd*) of the MTD layer, while for filesystem operations like mounting we must use the block device interface (/dev/mtdblock*). # eraseall /dev/mtd2 Erased 4096 Kibyte @ 0 -- 100% complete.
# >file bash: file: No space left on device # mv file foo mv: cannot create regular file `foo': No space left on device You will have to use rm to actually delete a file in this situation.
Everything: 24 kilobytes $ ls -l test.cramfs.img -rw-r--r-1 wd users 24576 Nov 10 23:44 test.cramfs.img As you can see, the CramFs image test.cramfs.img takes just 24 kB, while the input directory contained 64 kB of data. Savings of some 60% like in this case are typical CramFs. Now we write the CramFs image to a partition in flash and test it: # cp test.cramfs.img /dev/mtd3 # mount -t cramfs /dev/mtdblock3 /mnt # mount /dev/root on / type nfs (rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=10.0.0.
9.1.5.2. Using UBI on NAND Flash: Erase the flash partition: root@generic-armv5te:~# flash_erase -q /dev/mtd4 0 0 root@generic-armv5te:~# and attach it to UBI: root@generic-armv5te:~# ubiattach /dev/ubi_ctrl -m 4 -O 2048 [ 115.210000] UBI: attaching mtd4 to ubi0 [ 116.580000] UBI: scanning is finished [ 116.590000] UBI: empty MTD device detected [ 116.630000] UBI: attached mtd4 (name "filesystem", size 248 MiB) to ubi0 [ 116.630000] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes [ 116.
Present UBI devices: ubi0 ubi0 Volumes count: Logical eraseblock size: Total amount of logical eraseblocks: Amount of available logical eraseblocks: Maximum count of volumes Count of bad physical eraseblocks: Count of reserved physical eraseblocks: Current maximum erase counter value: Minimum input/output unit size: Character device major/minor: Present volumes: 1 126976 bytes, 124.0 KiB 1984 (251920384 bytes, 240.
Sub-page size: OOB size: Character device major/minor: Bad blocks are allowed: Device is writable: Default UBI VID header offset: Default UBI data offset: Default UBI LEB size: Maximum UBI volumes count: 2048 bytes 64 bytes 90:8 true true 2048 4096 126976 bytes, 124.
[ 161.550000] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 [ 161.550000] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096 [ 161.560000] UBI: good PEBs: 1984, bad PEBs: 0, corrupted PEBs: 0 [ 161.580000] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128 [ 161.580000] UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 19519 [ 161.600000] UBI: available PEBs: 0, total reserved PEBs: 1984, PEBs reserved for bad PEB handl [ 161.
[marex@pollux]$ Note that for the NAND device we must pass the "-s 2048" option to ubinize; if we don't, an attempt to attach the created UBI device will result in error messages like these: root@generic-armv5te:~# ubiattach /dev/ubi_ctrl -m 4 [ 196.320000] UBI: attaching mtd4 to ubi0 [ 199.060000] UBI: scanning is finished [ 199.090000] UBI: attached mtd4 (name "filesystem", size 248 MiB) to ubi0 [ 199.090000] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes [ 199.110000] UBI: min./max.
Everything in tmpfs is temporary in the sense that no files will be created on any device. If you unmount a tmpfs instance, everything stored therein is lost. tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap unneeded pages out to swap space. It has maximum size limits which can be adjusted on the fly via 'mount -o remount ...
read-only ramdisk: #!/bin/sh ... # Won't work on read-only root: mkdir /tmpfs mount -t tmpfs tmpfs /tmpfs mkdir /tmpfs/tmp /tmpfs/var # Won't work on read-only root: ln -sf /tmpfs/tmp /tmpfs/var / ... The commented out sections will of course fail on a read-only root filesystem, so you have to create the /tmpfs mount-point and the symbolic links in your root filesystem beforehand in order to successfully use this setup. 9.3.
root@generic-armv5te:/tmp/duts# mount -t vfat /dev/mmcblk0p2 /tmp/duts/mmc root@generic-armv5te:/tmp/duts# mount rootfs on / type rootfs (rw) 192.168.1.1:/opt/eldk-5.2.
-rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 1152054 Feb 8 2012 -rwxr-xr-x 1 root root 2340744 Apr 18 07:07 root@generic-armv5te:/tmp/duts# slide-2.bmp slide-3.bmp slide-4.bmp slide-5.bmp slide-6.bmp slide-7.bmp slide-8.
We recommend to store settings of brightness and contrast in U-Boot environment variables that can be shared between U-Boot and Linux. This way it is possible (assuming adequate driver support) to adjust the display settings correctly already in U-Boot and thus to avoid any flicker of the display when Linux takes over control. 9.5. Root File System: Design and Building It is not an easy task to design the root file system for an embedded system. There are three major problems to be solved: 1.
4. Instead, we create a separate tarball which contains only the device entries so we can use them when necessary (with cramfs): bash# tar -zcf /tmp/devices.tar.gz dev/ bash# cd /tmp 5. Unmount ramdisk image: bash# umount /mnt/tmp We will use the /tmp/rootfs.tar.gz tarball as master file in all following experiments. 9.5.1. Root File System on a Ramdisk Ram disks are used very often to hold the root file system of embedded systems.
/dev/hda /dev/kmem /dev/mem /dev/mtd /dev/mtdblock /dev/mtdr /dev/nftla /dev/nftla /dev/nftlb /dev/nftlb /dev/null /dev/ptyp /dev/ptypa /dev/ptypb /dev/ptypc /dev/ptypd /dev/ptype /dev/ptypf /dev/ram /dev/ram /dev/rtc /dev/tty /dev/tty /dev/ttyS /dev/ttyp /dev/ttypa /dev/ttypb /dev/ttypc /dev/ttypd /dev/ttype /dev/ttypf /dev/zero b c c c b c b b b b c c c c c c c c b b c c c c c c c c c c c c 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 640 64
We now have a root file system image uRamdisk that can be used with U-Boot. 9.5.2. Root File System on a JFFS2 File System JFFS2 (Journalling Flash File System version 2) was specifically designed for use on flash memory devices in embedded systems.
When booting the Linux kernel prints the following messages showing the default partition map which is used for the flash memory on the TQM8xxL boards: TQM flash bank 0: Using static image partition definition Creating 7 MTD partitions on "TQM8xxL0": 0x00000000-0x00040000 : "u-boot" 0x00040000-0x00100000 : "kernel" 0x00100000-0x00200000 : "user" 0x00200000-0x00400000 : "initrd" 0x00400000-0x00600000 : "cramfs" 0x00600000-0x00800000 : "jffs" 0x00400000-0x00800000 : "big_fs" We use U-Boot to load and store t
Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.4.25 (wd@xpert) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)) #1 Sun Jun 12 On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/mtdblock6 rw rootfstype=jffs2 ip=192.168.3.80:192.168.3.1::2 Decrementer Frequency = 187500000/60 Calibrating delay loop... 49.86 BogoMIPS ... NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Many tools require some storage place in a filesystem, so we must provide at least one (small) writable filesystem. For all data which may be lost when the system goes down, a "tmpfs" filesystem is the optimal choice. To create such a writable tmpfs filesystem we add the following lines to the /etc/rc.
3. a 10 b 11 c 12 d 13 e 14 f 15 __EOD__ chmod 0666 /tmpfs/dev/* 4. We can now create a cramfs file system image using the mkcramfs tool: $ ROOTFS_DIR=rootfs $ ROOTFS_ENDIAN="-r" $ ROOTFS_IMAGE=cramfs.img # directory with root file system content # target system has reversed (big) endianess # generated file system image PATH=/opt/eldk/usr/bin:$PATH mkcramfs ${ROOTFS_ENDIAN} ${DEVICES} ${ROOTFS_DIR} ${ROOTFS_IMAGE} Swapping filesystem endian-ness bin dev etc ... -48.78% (-86348 bytes) in.ftpd -46.
$ mkdir rootfs $ cd rootfs $ tar -zxf /tmp/rootfs.tar.gz 2. Like with the cramfs root file system, we use "tmpfs" for cases where a writable file system is needed and add the following lines to the /etc/rc.
d 13 e 14 f 15 __EOD__ chmod 0666 /tmpfs/dev/* 3. Like we did for the ramdisk, we now create an ext2 file system image using the genext2fs tool: $ $ $ $ $ $ ROOTFS_DIR=rootfs ROOTFS_SIZE=3700 ROOTFS_FREE=100 ROOTFS_INODES=380 ROOTFS_DEVICES=rootfs_devices.tab ROOTFS_IMAGE=ext2.
################################################################# ################################################################# ################################################################# ################################################################# ########################## done Bytes transferred = 3788800 (39d000 hex) => ide part Partition Map for IDE device 0 Partition Start Sector 1 32 => ide write 100000 20 1ce8 -- Partition Type: DOS Num Sectors 500704 Type 6 IDE write: device 0 bl
Here is one possible solution: Your software distribution consistes of two files: The first file is the Linux kernel with a minimal ramdisk image attached (using the multi-file image format for U-Boot); U-Boot can load and boot such files from a FAT or VFAT file system. The second file is your root file system. For convenience and speed we use again an image of an ext2 file system. When Linux boots, it will initially use the attached ramdisk as root file system.
$ genext2fs -U \ -d ${INITRD_DIR} \ -D ${INITRD_DEVICES} \ -b ${INITRD_SIZE} \ -r ${INITRD_FREE} \ -i ${INITRD_INODES} \ ${INITRD_IMAGE} $ gzip -v9 ${INITRD_IMAGE} The result is a really small (233 kB) compressed ramdisk image. 5. Assuming you already have your Linux kernel image, you can now use mkimage to build an U-Boot multi-file image that combines the Linux kernel and the initial ramdisk: $ LINUX_KERNEL=linuxppc_2_4_devel/arch/ppc/boot/images/vmlinux.
• The first line says that it's a script file for the /bin/nash interpreter. Note: even if this file looks like a shell script it is NOT interpreted by a shell, but by the nash interpreter. For a complete list of available nash commands and their syntax please refer to the manual page, nash(8). • The first action is to mount the /proc pseudo file system which is needed to find out some required information.
Board: TQM860LDB0A3-T50.202 DRAM: 16 MB FLASH: 8 MB In: serial Out: serial Err: serial Net: SCC ETHERNET, FEC ETHERNET [PRIME] PCMCIA: 3.3V card found: Transcend 256M Fixed Disk Card IDE interface [silicon] [unique] [single] [sleep] [standby] [idle] [low power] Bus 0: OK Device 0: Model: Transcend 256M Firm: 1.1 Ser#: SSSC256M04Z27A25906T Type: Removable Hard Disk Capacity: 244.5 MB = 0.2 GB (500736 x 512) Type "run flash_nfs" to mount root filesystem over NFS Hit any key to stop autoboot: reading linux.
9.6. Root File System Selection Now we know several options for file systems we can use, and know how to create the corresponding images. But how can we decide which one to chose? For practical purposes in embedded systems the following criteria are often essential: • boot time (i. e. time needed from power on until application code is running) • flash memory footprint • RAM memory footprint • effects on software updates The following data was measured for the different configurations.
What it is good for? In embedded systems the main use of mini_fo is to overlay the root file system. This means it is mounted on top of the regular root file system, thereby allowing applications or users to transparently make modifications to it but redirecting these to a different location. Some examples of why this is usefull are explained in the following sections. Making a read-only root filesystem writeable Root file systems stored in flash are often read only, such as cramfs or read only ext2.
This is easy. Let's assume "/" is the read-only root file system and /dev/mtdblock5 contains a small JFFS2 flash partition that shall be used to store modifications made by application "/usr/bin/autoPilot": # # # # # mount -t jffs2 /dev/mtdblock5 /tmp/sto insmod mini_fo.o mount -t mini_fo -o base=/,sto=/tmp/sto/ / /mnt/mini_fo/ cd /mnt/mini_fo/ chroot . /usr/bin/autoPilot The mini_fo file system is mounted with "/" as base directory, "/tmp/sto/" as storage directory to the mount point "/mnt/mini_fo".
2. Reading from files, creating new files, modifying already modified files These operations are passed directly through to the lower native layer, and only impose an overhead of 1-2%. Further information This section discusses how the mini_fo overlay file system can be used in embedded systems. More general information is available at the mini_fo project page: http://www.denx.de/wiki/Know/MiniFOHome. 9.8.
• 10. Debugging ♦ 10.1. Debugging of U-Boot ◊ 10.1.1. Debugging of U-Boot Before Relocation ◊ 10.1.2. Debugging of U-Boot After Relocation ♦ 10.2. Linux Kernel Debugging ◊ 10.2.1. Linux Kernel and Statically Linked Device Drivers ◊ 10.2.2. Dynamically Loaded Device Drivers (Modules) ◊ 10.2.3. GDB Macros to Simplify Module Loading ♦ 10.3. GDB Startup File and Utility Scripts ♦ 10.4. Tips and Tricks ♦ 10.5. Application Debugging ◊ 10.5.1. Local Debugging ◊ 10.5.2. Remote Debugging ♦ 10.6.
136 (gdb) s 137 (gdb) 138 (gdb) asm volatile(" bl 0f" ::: "lr"); asm volatile("0: mflr asm volatile(" 4, 0, 14" addi 3" ::: "r3"); ::: "r4"); cpu_init_f is the first C function called from the code in start.C. 10.1.2. Debugging of U-Boot After Relocation For debugging U-Boot after relocation we need to know the address to which U-Boot relocates itself to. When no exotic features like PRAM are used, this address usually is - CONFIG_SYS_MONITOR_LEN.
10.2.1. Linux Kernel and Statically Linked Device Drivers 10.2.2. Dynamically Loaded Device Drivers (Modules) First start GDB in the root directory of your Linux kernel, using the vmlinux kernel image as file to debug: bash$ cd bash$ ${CROSS_COMPILE}gdb vmlinux GNU gdb 5.1.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.
Now you can list the source code of the module, set break points or inspect variables as usual: (gdb) l fun 61 static RT_TASK *thread; 62 63 static int cpu_used[NR_RT_CPUS]; 64 65 static void fun(int t) 66 { 67 unsigned int loops = LOOPS; 68 while(loops--) { 69 cpu_used[hard_cpu_id()]++; 70 rt_leds_set_mask(1,t); (gdb) (gdb) b ex_sw.c:69 Breakpoint 1 at 0xcf03007c: file ex_sw.c, line 69. (gdb) c Continuing. Breakpoint 1, fun (t=1) at ex_sw.
(gdb) c Continuing. Breakpoint 1, fun (t=0x1) at ex_sw.c:69 69 cpu_used[hard_cpu_id()]++; (gdb) p/d loops $2 = 999986939 (gdb) p t $3 = 0x1 (gdb) d b Delete all breakpoints? (y or n) y (gdb) c Continuing. 10.3.
`add_sect `add_sect `add_sect `add_sect .data`\ .sdata`\ .bss`\ .sbss`\ " echo "add-symbol-file $1 $ARGS" > ~/add-symbol-file.gdb 10.4. Tips and Tricks • To prevent GDB from jumping around in the code when trying to single step, i. e. when it seems as if the code is not executing line by line, you can recompile your code with the following additional compiler options: -fno-schedule-insns -fno-schedule-insns2 • On some systems (like the MPC8xx or MPC8260) you can only define one hardware breakpoint.
10.5.2. Remote Debugging gdbserver allows you to connect your program with a remote GDB using the "target remote" command. On the target machine, you need to have a copy of the program you want to debug. gdbserver does not need your program's symbol table, so you can strip the program if necessary to save space. GDB on the host system does all the symbol handling. Here is an example: bash$ ${CROSS_COMPILE}gcc -Wall -g -o hello hello.
It is convenient to use DDD, a Graphical User Interface to GDB, for debugging as it allows to define and execute frequently used commands via buttons. You can start DDD with the command: bash$ ddd --debugger ${CROSS_COMPILE}gdb & If DDD is not already installed on your Linux system, have a look at your distribution media. 11. Simple Embedded Linux Framework 12. Books, Mailing Lists, Links, etc. This section provides references on where to find more information Contents: • 12.
12.2.2. Linux kernel Books • Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum: "Building Embedded Linux Systems 2nd edition", Paperback: 462 pages, O'Reilly & Associates; (August 2008); ISBN 10: 0-596-52968-6; ISBN 13: 9780596529680 ISBN 059600222X - IMHO the best book about Embedded Linux so far. An absolute must have.
• David R. Butenhof: "Programming with POSIX Threads", Addision Wesley, ISBN 0-201-63392-2. • Bradford Nichols, Dick Buttlar and Jacqueline Proulx Farrell: "Pthreads Programming", O'Reilly & Associates • "Git Community Book" See http://book.git-scm.com/ or download the PDF version. Articles • The GNU C Library: http://www.linuxselfhelp.com/gnu/glibc/html_chapter/libc_toc.html General Linux Programming: http://www.linuxselfhelp.com/cats/programming.
• Gary R. Wright, W. Richard Stevens: "TCP/IP Illustrated, Volume 2 - The Implementation", Addision Wesley, ISBN 0-201-63354-X • W. Richard Stevens: "TCP/IP Illustrated, Volume 3 - TCP for Transactions", Addision Wesley, ISBN 0-201-63495-3 • W. Richard Stevens: "UNIX Network Programming, Volume 1 - Networking APIs: Sockets and XTI", 2nd ed., Prentice Hall, ISBN-0-13-490012-X • W. Richard Stevens: "UNIX Network Programming, Volume 2 - Interprocess Communication", 2nd ed.
12.2.9. Power Architecture® Programming Books • Programming Environments Manual for 32-Bit Implementations of the PowerPC architecture: http://www.freescale.com/files/product/doc/MPCFPE32B.pdf • IBM PDF file (600+ page book) on PowerPC assembly language: http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600719DF2 • Power.org™ Standard for Embedded Power Architecture™ Platform Requirements (ePAPR): https://www.power.
12.3. Mailing Lists These are some mailing lists of interest. If you are new to mailing lists then please take the time to read at least RFC 1855. • linux-arm-kernel - Communications among developers and users of Linux on arm boards • linuxppc-embedded - Communications among developers and users of Linux on embedded Power Architecture® boards This mailing list has been merged into the linuxppc-dev mailing list below and thus does not exist anymore.
Miscalleneous or unsorted material: • BDI2000 List of supported Flash Memories: This document not only lists the currently supported flash chips, but also the required settings in the BDI config file. • BDI2000 configuration files: ftp://78.31.64.234/bdigdb/config/ 12.5. Tools • http://lxr.linux.no/source/ - Cross-Referencing the Linux Kernel - using a versatile hypertext cross-referencing tool for the Linux Kernel source tree (the Linux Cross-Reference project) • ftp://ftp.denx.
label = "bootloader"; reg = <0x00000000 0x00300000>; read-only; }; partition@1 { label = "environment"; reg = <0x00300000 0x00080000>; }; partition@2 { label = "redundant-environment"; reg = <0x00380000 0x00080000>; }; partition@3 { label = "kernel"; reg = <0x00400000 0x00400000>; }; partition@4 { label = "filesystem"; reg = <0x00800000 0x0f800000>; }; }; ssp0: ssp@80010000 { compatible = "fsl,imx28-mmc"; pinctrl-names = "default"; pinctrl-0 = <&mmc0_8bit_pins_a &mmc0_cd_cfg &mmc0_sck_cfg>; bus-width = <8>;
0x30d3 /* MX28_PAD_AUART3_TX__GPIO_3_13 */ >; fsl,drive-strength = <0>; fsl,voltage = <1>; fsl,pull-up = <0>; }; lcdif_pins_m28: lcdif-m28@0 { reg = <0>; fsl,pinmux-ids = < 0x11e0 /* MX28_PAD_LCD_DOTCLK__LCD_DOTCLK */ 0x11f0 /* MX28_PAD_LCD_ENABLE__LCD_ENABLE */ >; fsl,drive-strength = <0>; fsl,voltage = <1>; fsl,pull-up = <0>; }; }; lcdif@80030000 { pinctrl-names = "default"; pinctrl-0 = <&lcdif_24bit_pins_a &lcdif_pins_m28>; status = "okay"; }; can0: can@80032000 { pinctrl-names = "default"; pinctrl-0 = <
eeprom: eeprom@51 { compatible = "atmel,24c128"; reg = <0x51>; pagesize = <32>; }; rtc: rtc@68 { compatible = "stm,mt41t62"; reg = <0x68>; }; }; lradc@80050000 { status = "okay"; }; duart: serial@80074000 { pinctrl-names = "default"; pinctrl-0 = <&duart_pins_a>; status = "okay"; }; usbphy0: usbphy@8007c000 { status = "okay"; }; usbphy1: usbphy@8007e000 { status = "okay"; }; auart0: serial@8006a000 { pinctrl-names = "default"; pinctrl-0 = <&auart0_2pins_a>; status = "okay"; }; }; }; ahb@80080000 { usb0: usb@
regulators { compatible = "simple-bus"; reg_3p3v: 3p3v { compatible = "regulator-fixed"; regulator-name = "3P3V"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-always-on; }; reg_vddio_sd0: vddio-sd0 { compatible = "regulator-fixed"; regulator-name = "vddio-sd0"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&gpio3 28 0>; }; reg_usb0_vbus: usb0_vbus { compatible = "regulator-fixed"; regulator-name = "usb0_vbus"; regulator-min-microvolt
BREAKMODE SCANSUCC STARTUP ;BDIMODE [HOST] IP PROMPT HARD 0 0 RESET ;SOFT or HARD, ARM / Thumb break code ; 1 4 when the ETMBUF after the ARM926 core is enabled via TESTMO ; the ARM 926 core is stop after reset LOADONLY 192.168.1.1 M28> [FLASH] ; only nand and this is not supported directly from the bdi [REGS] FILE BDI2000/reg926e.def • 14. FAQ - Frequently Asked Questions ♦ 14.1. ELDK ◊ 14.1.1. ELDK Installation under FreeBSD ◊ 14.1.2. ELDK Installation Hangs ◊ 14.1.3. .gvfs: Permission Denied ◊ 14.
♦ 14.3. Linux ◊ 14.3.1. Linux crashes randomly ◊ 14.3.2. Linux crashes when uncompressing the kernel ◊ 14.3.3. Linux Post Mortem Analysis ◊ 14.3.4. Linux kernel register usage ◊ 14.3.5. Linux Kernel Ignores my bootargs ◊ 14.3.6. Cannot configure Root Filesystem over NFS ◊ 14.3.7. Linux Kernel Panics because "init" process dies ◊ 14.3.8. Unable to open an initial console ◊ 14.3.9. System hangs when entering User Space (ARM) ◊ 14.3.10. Mounting a Filesystem over NFS hangs forever ◊ 14.3.11.
14. FAQ - Frequently Asked Questions This is a collection of questions which came up repeatedly. Give me more feedback and I will add more stuff here. The items are categorized whether they concern U-Boot itself, the Linux kernel or the SELF framework. 14.1. ELDK 14.1.1. ELDK Installation under FreeBSD Question: How can I install ELDK on a FreeBSD system? Answer: [Thanks to Rafal Jaworowski for these detailed instructions.] This is a short tutorial how to host ELDK on FreeBSD 5.x and 6.x.
# cd # brandelf -t Linux ./install Note: The following workaround might be a good alternative for the tedious copying of the installation CDROM to a writable location and manual branding: you can set a fallback branding in FreeBSD - when the loader cannot recognise the ELF brand it will switch to the last resort defined. # sysctl -w kern.elf32.fallback_brand=3 kern.elf32.fallback_brand: -1 -> 3 With this setting, the normal ELDK CDROM images should work. 3.
I try to install the ELDK on a Linux PC, and the installation hangs. It starts fine, but then it freezes like this: ... Preparing... 1:db4-devel-ppc_4xx Preparing... 1:db4-utils-ppc_4xx Preparing... 1:glib2-ppc_4xx Preparing... 1:glib2-devel-ppc_4xx Preparing...
$ df -h /home/wd/.gvfs Filesystem Size Used Avail Use% Mounted on gvfs-fuse-daemon 0 0 0 - /home/wd/.gvfs $ sudo df -h /home/wd/.gvfs df: `/home/wd/.gvfs': Permission denied df: no file systems processed 14.1.4. Installation on Local Harddisk Question: I have a local harddisk drive connected to my target board. Can I install the ELDK on it and run it like a standard Linux distribution? Answer: Yes, this is possible. It requires only minor adjustments.
-#[ "$state" != "rw" -a "$READONLY" != "yes" ] && \ -# action $"Remounting root filesystem in read-write mode: " mount -n -o remount,rw +state=`LC_ALL=C awk '/ \/ / && ($3 !~ /rootfs/) { print $4 }' /proc/mounts` +[ "$state" != "rw" -a "$READONLY" != "yes" ] && \ + action $"Remounting root filesystem in read-write mode: " mount -n -o remount,rw # Clean up SELinux labels if [ -n "$SELINUX" ]; then 8. Unmount disk: bash-3.00# umount /mnt 9.
14.1.7. ELDK Include Files Missing Question: After configuring and compiling a Linux kernel in the kernel source tree that comes with the ELDK, I cannot compile user space programs any more - I get error messages because many #include file like etc. are missing. This is with ELDK 4.0 or 4.1. Answer: This problem is caused by the way how the ELDK is packaged.
SPE, but there are no special FP registers available as on a normal FPU, so General Purpose Registers must be used for passing of FP operands. While this is still much faster than pure soft-float emulation, it is missing the advantages and the speed of a full-blown, separate standard FPU with a full FP register set. Also, your tool chain needs to be aware of this feature, and must contain support for it. Eventually special compiler options are needed - check your documentation.
.globl foo .type foo, @function foo: stwu 1,-48(1) mflr 0 stw 24,16(1) stw 25,20(1) stw 26,24(1) stw 27,28(1) stw 28,32(1) stw 29,36(1) stw 0,52(1) mr 28,3 mr 29,4 mr 26,5 mr 27,6 bl __adddf3 mr 24,3 mr 25,4 mr 3,28 mr 4,29 mr 5,26 mr 6,27 bl __muldf3 mr 5,3 mr 6,4 mr 3,24 mr 4,25 bl __divdf3 lwz 0,52(1) mtlr 0 lwz 24,16(1) lwz 25,20(1) lwz 26,24(1) lwz 27,28(1) lwz 28,32(1) lwz 29,36(1) addi 1,1,48 blr .size foo, .-foo .ident "GCC: (GNU) 4.2.2" .section .note.
evmergelo 9,5,6 efdadd 11,0,9 efdmul 0,0,9 efddiv 11,11,0 evstdd 11,24(1) evmergehi 9,11,11 mr 10,11 stw 9,32(1) stw 10,36(1) mr 3,9 mr 4,10 addi 1,1,48 blr .size foo, .-foo .ident "GCC: (GNU) 4.2.2" .section .note.GNU-stack,"",@progbits Here we can see moderate use of General Purpos Registers combined with the use of SPE machine instructions (evmergelo, efdadd, efdmul, efddiv, evstdd, evmergehi) which proves that the compiler really generates code that supports the SPE. 14.1.10. ELDK 2.
# dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key Will output 1024 bit rsa secret key to '/etc/dropbear/dropbear_rsa_host_key' Generating key, this may take a while... Public key portion is: ssh-rsa ... Fingerprint: md5 ... # dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key Will output 1024 bit dss secret key to '/etc/dropbear/dropbear_dss_host_key' Generating key, this may take a while... Public key portion is: ssh-dss ... Fingerprint: md5 ...
99% or more of all errors are located when you port U-Boot to a new hardware. In the result, your RAM image may work, but in the end you will need a full image to program the flash memory with it, and then you will have to enable all this highly critical and completely untested code. You see? You cannot use a RAM version of U-Boot to avoid testing a flash version, so you can save all this effort and just burn your image to flash.
Alternatively, the tool chain could provide a separate version of libgcc.a built with old ABI. This could be done using the multilib approach. The advantage here is that no U-boot changes will be required. 14.2.4. U-Boot crashes after relocation to RAM Question: I have ported U-Boot to a custom board. It starts OK, but crashes or hangs after relocating itself to RAM. Why? Answer: Your SDRAM initialization is bad, and the system crashes when it tries to fetch instructions from RAM.
Why? Answer: Most probably everything is OK. The message is printed because the flash sector or ERPROM containing the environment variables has never been initialized yet. The message will go away as soon as you save the envrionment variables using the saveenv command. 14.2.6. Net: No ethernet found Question: I have ported U-Boot to a custom board. It seems to boot OK, but it prints: Net: No ethernet found.
"add-symbol-file u-boot _offset_" for code after relocation. 14.2.8. Decoding U-Boot Crash Dumps When you are porting U-Boot to new hardware, or implementing extensions, you might run into situations where U-Boot crashes and prints a register dump and a stack trace, for example like this: Bus Fault @ 0x00f8d70c, fixup 0x00000000 Machine check in kernel mode.
14.2.9. Porting Problem: cannot move location counter backwards Question: I'm trying to port U-Boot to a new board and the linker throws an error message like this: board//u-boot.lds:75 cannot move location counter backwards (from 00000000b0008 Answer: Check your linker script board/your_board/u-boot.lds which controls how the object files are linked together to build the U-Boot image. It looks as if your board uses an "embedded" environment, i. e.
Where can the image size be altered from? Answer: Some processors have a fixed reset vector address at 0xFFFFFFFC, so the U-Boot image has to include that address, i. e. it covers the full range from the start address to the end of the 32 bit address space. In such a case, the start address must be changed - check the setting of TEXT_BASE in your board//config.mk file. 14.2.12. Erasing Flash Fails Question: I tried to erase the flash memory like erase 40050000 40050100 It fails.
variables, too. Question: I have configured a MAC address of 01:02:03:04:05:06, and I can see that an ARP packet is sent by U-Boot, and that an ARP reply is sent by the server, but U-Boot never receives any packets. What's wrong? Answer: You have chosen a MAC address which, according to the ANSI/IEEE 802-1990 standard, has the multicast bit set. Under normal conditions a network interface discards such packets, and this is what U-Boot is doing. This is not a bug, but correct behaviour.
14.2.15. Why do I get TFTP timeouts? Question 1:: When trying to download a file from the TFTP server I always get timeouts like these: ... Loading: #######T ##################################T###################T ####T ##T # ###T #T #########T ########T #############T ##T #############T ########T #############T #####T ###T ######T #######T #######T #############T ##T ##############T ########### ########### done If the target is connected directly to the host PC (i. e.
If this doesn't work, fix your TFTP server configuration and make sure it is running. (2) If your TFTP server is working, run ethereal (or equivalent ethernet sniffing) to see what ethernet packets are being sent by your development board. It usually works best to run ethereal on your TFTP server (if you run it on a different machine and you use an ethernet switch, the third machine likely won't see the tftp packets). 14.2.16.
the autonegotiation <-> fixed configuration case because the odds of it working properly are poor anyway. Rule: Always try to set up your PHY for autonegotiation. If you must use some fixed setting, then set it to half duplex mode. If you really must use a fixed full-duplex setting, then you absolutley must make sure that the link partner is configured exactly the same. See also: Wikipedia: Autonegotiation and Wikipedia: Duplex mismatch 14.2.17.
setenv bootcmd bootm \$address setenv addip 'setenv bootargs $bootargs ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostnam 14.2.17.3.
14.2.17.4. General rules 1. If a command line (or an environment variable executed by a run command) contains several commands separated by semicolons, and one of these commands fails, the remaining commands will still be executed. 2. If you execute several variables with one call to run (i. e. calling run with a list of variables as arguments), any failing command will cause run to terminate, i. e. the remaining variables are not executed. 14.2.18.
This installs a lot of kernel modules in "./lib/modules/" and a kernel ELF file in "./boot" : $ ls -l boot total 8792 -rw-r--r-- 1 root root 1226119 Oct 17 17:31 System.map-2.6.30.9-90.fc11.ppc -rw-r--r-- 1 root root 96224 Oct 17 17:31 config-2.6.30.9-90.fc11.ppc -rwxr-xr-x 1 root root 7673768 Oct 17 18:20 vmlinuz-2.6.30.9-90.fc11.ppc Now convert the ELF kernel image into an uImage file: $ ppc_4xxFP-objcopy -O binary boot/vmlinuz-2.6.30.9-90.fc11.ppc /tmp/vmlinux.bin $ gzip -v9 /tmp/vmlinux.
Question: I am using U-Boot with a Linux kernel version Y (Y < 2.4.5-pre5), but the last message I see is Uncompressing Kernel Image ... OK Then the system hangs. Answer: Most probably you pass bad parameters to the Linux kernel. There are several possible reasons: ◊ Bad device tree; for example, check that the memory map set up by the boot loader (like mapping of IMMR, PCI addresses etc.) is consistent with what is encoded in your device tree specification.
Answer: This depends mainly on how you intend to distribute your software updates, and which physical interfaces are present (or usable for this purpose) on your device. Typically you will either distribute the software over the network, or you can use soMe type of storage device like USB mass storage device (memory stick etc.), SD cards etc. U-Boot already supports such a feature on several boards.
Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1003065 Bytes = 979.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... Error: inflate() returned -3 GUNZIP ERROR - must RESET board to recover Answer: Your kernel image is quite big - nearly 1 MB compressed; when it gets uncompressed it will need 2.5 ... 3 MB, starting at address 0x0000.
14.3.4. Linux kernel register usage For the Power Architecture® architecture, the Linux kernel uses the following registers: R1: stack pointer R2: pointer to task_struct for the current task R3-R4: parameter passing and return values R5-R10: parameter passing R13: small data area pointer R30: GOT pointer R31: frame pointer A function can use r0 and r3 - r12 without saving and restoring them. r13 - r31 have to be preserved so they must be saved and restored when you want to use them.
MACHINE_END The machine descriptor macros for your machine will be located in a similar file in your kernel source tree. Having located your machine descriptor macros, the next step is to find out where U-Boot puts the kernel boot tags in memory for your architecture. On the Lubbock, this address turns out to be the start of physical RAM plus 0x100, or 0xa0000100.
Normally, the file "etc/ld.so.cache" contains a compiled list of system libraries. This file is used by the dynamic linker/loader ld.so to cache library information. If it does not exist, rebuilt automatically. For some reason, a corrupted or partial file was written to your root file system. This corrupt file then confused the dynamic linker so that it crashed when trying to start the init process.
We use the SELF ramdisk image that comes with the ELDK. When we try to mount a filesystem over NFS from the server, for example: # mount -t nfs 192.168.1.1:/target/home /home the command waits nearly 5 minutes in uninterruptable sleep. Then the mount finally succeeds. What's wrong? Answer: The default configuration of the SELF was not designed to mount additional filesystems with file locking over NFS, so no portmap deamon is running, which is causing your problems.
• parse the U-Boot environment directly • pass it via the command line If your device driver does not support one of these sources directly, then do it yourself: • add an init board hook • program it from user space (`ifconfig hw ...`) • for people who need to do NFS root or similar, then use initramfs -- this is what it was designed for ! 14.3.12.
... console=tty0 console=ttyS0,${baudrate} ... This will ensure that the boot messages are displayed on both the framebuffer (/dev/tty0) and the serial console (/dev/ttyS0); the last device named in a console= option will be the one that takes input, too, so with the settings above you can use the serial console to enter commands etc. For a more detailed description see http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/configure-kernel.html 14.3.15.
boot. " - Benjamin Herrenschmidt 14.3.17. Linux Kernel crashes when using a ramdisk image Question: I have a Power Architecture® board with 1 GiB of RAM (or more). It works fine with root file system over NFS, but it will crash when I try to use a ramdisk. Answer: Check where your ramdisk image gets loaded to. In the standard configuration, the Linux kernel can access only 768 MiB of RAM, so your ramdisk image must be loaded below this limit. Check your boot messages.
CONFIG_BLK_DEV_RAM_SIZE parameter so that it contains a number equal or larger than your ramdisk (in kB). (In the 2.4 kernel series, you'll find this setting under the "Block devices" menu choice while, in the 2.6 series, it will be under "Device drivers" -> "Block devices".) 14.3.19. Combining a Kernel and a Ramdisk into a Multi-File Image Question: I used to build a zImage.initrd file which combined the Linux kernel with a ramdisk image.
The following kernel configuration options are required to support miscellaneous PCMCIA card types with Linux and the PCMCIA CS package: ◊ PCMCIA IDE cards (CF and true-IDE) To support the IDE CardService client, the kernel has to be configured with general ATA IDE support. The MPC8xx IDE support (CONFIG_BLK_DEV_MPC8XX_IDE flag) must be turned off. ◊ PCMCIA modem cards The kernel has to be configured with standard serial port support (CONFIG_SERIAL flag).
For "disk" type PC Cards (FlashDisks, CompactFlash, Hard Disk Adapters - basically anything that looks like an ordinary IDE drive), an alternative solution is available: direct support within the Linux kernel. This has the big advantage of minimal memory footprint, but of course it comes with a couple of disadvantages, too: • It works only with "disk" type PC Cards - no support for modems, network cards, etc; for these you still need the PCMCIA Card Services package. • There is no support for "hot plug", i.
systems around. To format your "disk" drive with a MacOS partition table you can use the pdisk command: We start printing the help menu, re-initializing the partition table and then printing the new, empty partition table so that we know the block numbers when we want to create new partitions: # pdisk /dev/hda Edit /dev/hda Command (? for help): ? Notes: Base and length fields are blocks, which vary in size between media. The base field can be p; i.e. use the base of the nth partition.
First block: 4160 Length in blocks: 4096 Name of partition: boot1 Type of partition: PPCBoot Command (? for help): p Partition map (with 512 byte blocks) on '/dev/hda' #: type name length base ( size ) 1: Apple_partition_map Apple 63 @ 1 2: PPCBoot boot0 4096 @ 64 ( 2.0M) 3: PPCBoot boot1 4096 @ 4160 ( 2.0M) 4: Apple_Free Extra 1579344 @ 8256 (771.2M) Device block size=512, Number of Blocks=1587600 (775.
# mke2fs /dev/hda5 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 90624 inodes, 181034 blocks 9051 blocks (5.00%) reserved for the super user First data block=0 6 block groups 32768 blocks per group, 32768 fragments per group 15104 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840 Writing inode tables: done Writing superblocks and filesystem accounting information: done 14.3.23.2.
Last cylinder or +size or +sizeM or +sizeK (1-1575, default 1575): +2M Command (m for help): p Disk /dev/hda: 16 heads, 63 sectors, 1575 cylinders Units = cylinders of 1008 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 1 5 2488+ 83 Linux Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2 First cylinder (6-1575, default 6): Using default value 6 Last cylinder or +size or +sizeM or +sizeK (6-1575, default 1575): +2M Command (m for help): p Di
The partition table has been altered! Calling ioctl() to re-read partition table. hda: hda1 hda2 hda3 hda4 hda: hda1 hda2 hda3 hda4 WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. Syncing disks. Now we are ready to initialize the partitions: # mkswap /dev/hda3 Setting up swapspace version 1, size = 67604480 bytes # mke2fs /dev/hda4 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.
14.3.25. Use NTP to synchronize system time against RTC If a system has a real-time clock (RTC) this is often used only to initialize the system time when the system boots. From then, the system time is running independently. The RTC will probably only be used again at shutdown to save the current system time. Such a configuration is used in many workstation configurations.
CONFIG_XIP_PHYS_ADDR = FLASH-base-address + offset-in-FLASH CONFIG_XIP_VIRT_ADDR = 0xc0000000 + DRAM-size + offset-in-FLASH The default configuration parameters shown above are for a system with 16MB of DRAM and the XIP kernel image located at the physical address 0x40100000 in flash memory. Note that the FLASH and MTD driver must be disabled. You can then build the "uImage", copy it to CONFIG_XIP_PHYS_ADDR in flash memory and boot it from CONFIG_XIP_PHYS_ADDR as usual. 14.3.26.2.
Be aware that cramfs is a read-only filesystem. 14.3.26.3. Hints and Notes • XIP conserves RAM at the expense of flash. This might be useful if you have a big flash memory and little RAM. • Flash memory used for XIP must be readable all the time e.g. this excludes installation and usage the character device or MTD flash drivers, because they do device probing, sector erase etc. • The XIP extension is currently only available for PowerQUICC™I 8xx but can easily be extended to other architectures.
I am using a SCC port of a MPC8xx / MPC82xx as UART; for the Linux UART driver I have configured support for hardware handshake. Then I used a null-modem cable to connect the port to the serial port of my PC. But this does not work. What am I doing wrong? Answer: There is absolutely no way to connect a MPC8xx / MPC82xx SCC port to any DTE and use RS-232 standard hardware flow control.
For building against older versions of the MTD headers (meaning before v2.6.8-rc1) it is required to pass the argument "MTD_VERSION=old" to make: make MTD_VERSION=old env The resulting binary is called fw_printenv, but actually includes support for setting environment variables too. To achieve this, the binary behaves according to the name it is invoked as, so you will have to create a link called fw_setenv to fw_printenv. These tools work exactly like the U-Boot commands printenv resp.
# rm -f random # ln -s urandom random Solution: The correct solution for the problem is of course to feed sufficient entropy into /dev/random.
bash-2.05b# free total used Mem: 14556 14260 -/+ buffers/cache: 4372 Swap: 0 0 bash-2.05b# swapon swapfile bash-2.05b# free total used Mem: 14556 14172 -/+ buffers/cache: 4368 Swap: 63480 0 bash-2.05b# free 296 10184 0 shared 0 buffers 772 cached 9116 free 384 10188 63480 shared 0 buffers 784 cached 9020 Because the ELDK right now has no device nodes for the loopback driver we create them along the way. It goes without saying that the loop driver has to be included in the kernel configuration.
14.3.33. Telnet / SSH (dropbear) server not working Question: The telnet server is running on the target but when I try to login I get this error message: $ telnet 192.168.20.12 telnet 192.168.20.12 Trying 192.168.20.12... Connected to 192.168.20.12. Escape character is '^]'. telnetd: All network ports in use. Connection closed by foreign host. The dropbear ssh server fails in a similar fashion: $ ssh root@192.168.20.12 root@192.168.20.
1. Extract compressed ramdisk image (ramdisk.gz) bash$ dd if=uRamdisk bs=64 skip=1 of=ramdisk.gz 21876+1 records in 21876+1 records out 2. Uncompress ramdisk image (if it was a compressed one) bash$ gunzip -v ramdisk.gz ramdisk.gz: 66.6% -- replaced with ramdisk 3. Mount ramdisk image bash# mount -o loop ramdisk /mnt/tmp Now you can add, remove, or modify files in the /mnt/tmp directory. If you are done, you can re-pack the ramdisk into a U-Boot image: 1. Unmount ramdisk image: bash# umount /mnt/tmp 2.
2. Uncompress ramdisk image bash$ gunzip -v ramdisk.gz ramdisk.gz: 66.6% -- replaced with ramdisk 3. Mount ramdisk image As root: bash# mkdir -p /mnt/tmp bash# mount -o loop ramdisk /mnt/tmp 4. Create new ramdisk image, say 8 MB big: bash$ dd if=/dev/zero of=new_ramdisk bs=1024k count=8 bash$ /sbin/mke2fs -F -m0 new_ramdisk bash$ /sbin/tune2fs -c 0 -i 0 new_ramdisk As root: bash# mkdir -p /mnt/new bash# mount -o loop new_ramdisk /mnt/new 5.
When I try to compile my LInux kernel after applying the RTAI patch, I get a strange "asm-specifier for variable `__sc_3' conflicts with asm clobber list" error message. What does that mean? Answer: You are using an old version of the Linux kernel / RTAI patch in combination with a more recent version of the cross compiler. Please use a recent kernel tree (and the corresponding RTAI patch), or apply the attached patch to fix this problem. See: http://www.denx.
Conclusion: You cannot debug Linux exception entry and exit code. Because of speed, DataStoreTLBMiss does not even make use of EXCEPTION_PROLOG, and SRR0/SRR1 are never saved. Therefore you cannot debug DataStoreTLBMiss unless you change it's code (save SRR0/SRR1, set MSR[RI]. 14.6.3. How to single step through "RFI" instruction Question: I am trying to debug Linux on an IBM 405GP processor. Linux boots fine and I can step through the code until the "rfi" instruction in head_4xx.
14.6.5. Remote 'g' packet reply is too long Question: I'm trying to debug U-Boot for a PPC4xx processor, but I get the following error: (gdb) target remote xx.xx.xx.xx:2001 Remote debugging using xx.xx.xx.xx:2001 Remote 'g' packet reply is too long:... I believe this error is caused by GDB being configured to the wrong architecture. So I did the following: $ ppc_4xx-gdb u-boot ...
14.7.1. LITE5200 Installation Howto A nice "Application Note: Installing Embedded Linux on the Motorola MPC5200 Lite Evaluation Board" which covers the installation of U-Boot and Linux can be found at: http://emsys.denayer.wenk.be/emcam/Linux_on_MPC5200_(UK).pdf 14.7.2. USB does not work on Lite5200 board Question: USB does not work on my Lite5200 board. Also, the green LED behind the USB connector remains always off. Why? Answer: This is a hardware problem.
BDM - Background Debug Mode An on-chip debug interface supported by a special hardware port on some processors. It allows to take full control over the CPU with minimal external hardware, in many cases eliminationg the need for expensive tools like In-Circuit-Emulators.
DHCP - Dynamic Host Configuration Protocol A network protocol which can be used to inquire a server about information for the intended system configuration (like IP address, host name, netmask, name server, routing, name of a boot image, address of NFS server, etc.). Sucessor of BOOTP DMA - Direct Memory Access A form a data transfer directly between memory and a peripheral or between memory and memory, without normal program intervention.
GPL / LGPL - GNU General Public License/Lesser General Public License The full license text can be found at http://www.gnu.org/copyleft/gpl.html. The licenses under which the Linux kernel and much of the utility and library code necessary to build a complete system may be copied, distributed and modified. Each portion of the software is copyright by its respected copyright holder, and you must comply with the terms of the license in order to legally copy (and hence use) it.
MII - Media Independent Interface The IEEE Ethernet standard control interface used to communicate between the Ethernet controller (MAC) and the external PHY. MMU - Memory Management Unit CPU component which maps kernel- and user-space virtual addresses to physical addresses, and is an integral part of Linux kernel operation.
RTOS - Real-Time Operating System SCC - Serial Communications Controller The high performance module(s) within the CPM which implement the lowest layer of various serial protocols, such as Asynchronous serial (UART), 10 Mbps Ethernet, HDLC etc. SDMA - Serial DMA DMA used to transfer data to and from the SCCs. SELF - Simple Embedded Linux Framework A simple default configuration for Embedded Linux systems that is suitable as starting point for building your own systems.
Motorola S-records are an industry-standard format for transmitting binary files to target systems and PROM programmers. See also: http://pmon.groupbsd.org/Info/srec.htm Target The computer system which will be used later in you application environment, for instance an Embedded System. In many cases it has a different architecture and much more limited resoucres than a typical Host system, so it is often not possible to develop the software directly (native) on this system.
