- arm925t Files specific to ARM 925 CPUs
- arm926ejs Files specific to ARM 926 CPUs
- arm1136 Files specific to ARM 1136 CPUs
+ - at32ap Files specific to Atmel AVR32 AP CPUs
- i386 Files specific to i386 CPUs
- ixp Files specific to Intel XScale IXP CPUs
- mcf52x2 Files specific to Freescale ColdFire MCF52x2 CPUs
- examples Example code for standalone applications, etc.
- include Header Files
- lib_arm Files generic to ARM architecture
+- lib_avr32 Files generic to AVR32 architecture
- lib_generic Files generic to all architectures
- lib_i386 Files generic to i386 architecture
- lib_m68k Files generic to m68k architecture
----------------------
CONFIG_NIOS2
+ AVR32 based CPUs:
+ ----------------------
+ CONFIG_AT32AP
- Board Type: Define exactly one of
CONFIG_PCI5441 CONFIG_PK1C20
CONFIG_EP1C20 CONFIG_EP1S10 CONFIG_EP1S40
+ AVR32 based boards:
+ -------------------
+
+ CONFIG_ATSTK1000
+
+- CPU Daughterboard Type: (if CONFIG_ATSTK1000 is defined)
+ Define exactly one of
+ CONFIG_ATSTK1002
+
- CPU Module Type: (if CONFIG_COGENT is defined)
Define exactly one of
Board code has addition modification that it wants to make
to the flat device tree before handing it off to the kernel
+ CONFIG_OF_BOOT_CPU
+
+ This define fills in the correct boot cpu in the boot
+ param header, the default value is zero if undefined.
+
- Serial Ports:
CFG_PL010_SERIAL
for differential drivers: 0x00001000
for single ended drivers: 0x00005000
+- USB Device:
+ Define the below if you wish to use the USB console.
+ Once firmware is rebuilt from a serial console issue the
+ command "setenv stdin usbtty; setenv stdout usbtty" and
+ attach your usb cable. The Unix command "dmesg" should print
+ it has found a new device. The environment variable usbtty
+ can be set to gserial or cdc_acm to enable your device to
+ appear to a USB host as a Linux gserial device or a
+ Common Device Class Abstract Control Model serial device.
+ If you select usbtty = gserial you should be able to enumerate
+ a Linux host by
+ # modprobe usbserial vendor=0xVendorID product=0xProductID
+ else if using cdc_acm, simply setting the environment
+ variable usbtty to be cdc_acm should suffice. The following
+ might be defined in YourBoardName.h
+
+ CONFIG_USB_DEVICE
+ Define this to build a UDC device
+
+ CONFIG_USB_TTY
+ Define this to have a tty type of device available to
+ talk to the UDC device
+
+ CFG_CONSOLE_IS_IN_ENV
+ Define this if you want stdin, stdout &/or stderr to
+ be set to usbtty.
+
+ mpc8xx:
+ CFG_USB_EXTC_CLK 0xBLAH
+ Derive USB clock from external clock "blah"
+ - CFG_USB_EXTC_CLK 0x02
+
+ CFG_USB_BRG_CLK 0xBLAH
+ Derive USB clock from brgclk
+ - CFG_USB_BRG_CLK 0x04
+
+ If you have a USB-IF assigned VendorID then you may wish to
+ define your own vendor specific values either in BoardName.h
+ or directly in usbd_vendor_info.h. If you don't define
+ CONFIG_USBD_MANUFACTURER, CONFIG_USBD_PRODUCT_NAME,
+ CONFIG_USBD_VENDORID and CONFIG_USBD_PRODUCTID, then U-Boot
+ should pretend to be a Linux device to it's target host.
+
+ CONFIG_USBD_MANUFACTURER
+ Define this string as the name of your company for
+ - CONFIG_USBD_MANUFACTURER "my company"
+
+ CONFIG_USBD_PRODUCT_NAME
+ Define this string as the name of your product
+ - CONFIG_USBD_PRODUCT_NAME "acme usb device"
+
+ CONFIG_USBD_VENDORID
+ Define this as your assigned Vendor ID from the USB
+ Implementors Forum. This *must* be a genuine Vendor ID
+ to avoid polluting the USB namespace.
+ - CONFIG_USBD_VENDORID 0xFFFF
+
+ CONFIG_USBD_PRODUCTID
+ Define this as the unique Product ID
+ for your device
+ - CONFIG_USBD_PRODUCTID 0xFFFF
+
- MMC Support:
The MMC controller on the Intel PXA is supported. To
default value of 5 is used.
- Command Interpreter:
- CFG_AUTO_COMPLETE
+ CONFIG_AUTO_COMPLETE
Enable auto completion of commands using TAB.
+ Note that this feature has NOT been implemented yet
+ for the "hush" shell.
+
+
CFG_HUSH_PARSER
Define this variable to enable the "hush" shell (from
- "u-boot" is an image in ELF binary format
- "u-boot.srec" is in Motorola S-Record format
+By default the build is performed locally and the objects are saved
+in the source directory. One of the two methods can be used to change
+this behavior and build U-Boot to some external directory:
+
+1. Add O= to the make command line invocations:
+
+ make O=/tmp/build distclean
+ make O=/tmp/build NAME_config
+ make O=/tmp/build all
+
+2. Set environment variable BUILD_DIR to point to the desired location:
+
+ export BUILD_DIR=/tmp/build
+ make distclean
+ make NAME_config
+ make all
+
+Note that the command line "O=" setting overrides the BUILD_DIR environment
+variable.
+
Please be aware that the Makefiles assume you are using GNU make, so
for instance on NetBSD you might need to use "gmake" instead of
CROSS_COMPILE=' ' MAKEALL
+When using the MAKEALL script, the default behaviour is to build U-Boot
+in the source directory. This location can be changed by setting the
+BUILD_DIR environment variable. Also, for each target built, the MAKEALL
+script saves two log files (<target>.ERR and <target>.MAKEALL) in the
+<source dir>/LOG directory. This default location can be changed by
+setting the MAKEALL_LOGDIR environment variable. For example:
+
+ export BUILD_DIR=/tmp/build
+ export MAKEALL_LOGDIR=/tmp/log
+ CROSS_COMPILE=ppc_8xx- MAKEALL
+
+With the above settings build objects are saved in the /tmp/build, log
+files are saved in the /tmp/log and the source tree remains clean during
+the whole build process.
+
+
See also "U-Boot Porting Guide" below.
4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
LynxOS, pSOS, QNX, RTEMS, ARTOS;
Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS).
-* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86,
+* Target CPU Architecture (Provisions for Alpha, ARM, AVR32, Intel x86,
IA64, MIPS, NIOS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
- Currently supported: ARM, Intel x86, MIPS, NIOS, PowerPC).
+ Currently supported: ARM, AVR32, Intel x86, MIPS, NIOS, PowerPC).
* Compression Type (uncompressed, gzip, bzip2)
* Load Address
* Entry Point
bash#
+Boot Linux and pass a flat device tree:
+-----------
+
+First, U-Boot must be compiled with the appropriate defines. See the section
+titled "Linux Kernel Interface" above for a more in depth explanation. The
+following is an example of how to start a kernel and pass an updated
+flat device tree:
+
+=> print oftaddr
+oftaddr=0x300000
+=> print oft
+oft=oftrees/mpc8540ads.dtb
+=> tftp $oftaddr $oft
+Speed: 1000, full duplex
+Using TSEC0 device
+TFTP from server 192.168.1.1; our IP address is 192.168.1.101
+Filename 'oftrees/mpc8540ads.dtb'.
+Load address: 0x300000
+Loading: #
+done
+Bytes transferred = 4106 (100a hex)
+=> tftp $loadaddr $bootfile
+Speed: 1000, full duplex
+Using TSEC0 device
+TFTP from server 192.168.1.1; our IP address is 192.168.1.2
+Filename 'uImage'.
+Load address: 0x200000
+Loading:############
+done
+Bytes transferred = 1029407 (fb51f hex)
+=> print loadaddr
+loadaddr=200000
+=> print oftaddr
+oftaddr=0x300000
+=> bootm $loadaddr - $oftaddr
+## Booting image at 00200000 ...
+ Image Name: Linux-2.6.17-dirty
+ Image Type: PowerPC Linux Kernel Image (gzip compressed)
+ Data Size: 1029343 Bytes = 1005.2 kB
+ Load Address: 00000000
+ Entry Point: 00000000
+ Verifying Checksum ... OK
+ Uncompressing Kernel Image ... OK
+Booting using flat device tree at 0x300000
+Using MPC85xx ADS machine description
+Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
+[snip]
+
+
More About U-Boot Image Types:
------------------------------
-----------------
All contributions to U-Boot should conform to the Linux kernel
-coding style; see the file "Documentation/CodingStyle" in your Linux
-kernel source directory.
-
-Please note that U-Boot is implemented in C (and to some small parts
-in Assembler); no C++ is used, so please do not use C++ style
-comments (//) in your code.
+coding style; see the file "Documentation/CodingStyle" and the script
+"scripts/Lindent" in your Linux kernel source directory. In sources
+originating from U-Boot a style corresponding to "Lindent -pcs" (adding
+spaces before parameters to function calls) is actually used.
+
+Source files originating from a different project (for example the
+MTD subsystem) are generally exempt from these guidelines and are not
+reformated to ease subsequent migration to newer versions of those
+sources.
+
+Please note that U-Boot is implemented in C (and to some small parts in
+Assembler); no C++ is used, so please do not use C++ style comments (//)
+in your code.
Please also stick to the following formatting rules:
- remove any trailing white space
projects / oweals / u-boot.git / blobdiff