1# SPDX-License-Identifier: GPL-2.0+ 2# 3# (C) Copyright 2000 - 2013 4# Wolfgang Denk, DENX Software Engineering, wd@denx.de. 5 6Summary: 7======== 8 9This directory contains the source code for U-Boot, a boot loader for 10Embedded boards based on PowerPC, ARM, MIPS and several other 11processors, which can be installed in a boot ROM and used to 12initialize and test the hardware or to download and run application 13code. 14 15The development of U-Boot is closely related to Linux: some parts of 16the source code originate in the Linux source tree, we have some 17header files in common, and special provision has been made to 18support booting of Linux images. 19 20Some attention has been paid to make this software easily 21configurable and extendable. For instance, all monitor commands are 22implemented with the same call interface, so that it's very easy to 23add new commands. Also, instead of permanently adding rarely used 24code (for instance hardware test utilities) to the monitor, you can 25load and run it dynamically. 26 27 28Status: 29======= 30 31In general, all boards for which a configuration option exists in the 32Makefile have been tested to some extent and can be considered 33"working". In fact, many of them are used in production systems. 34 35In case of problems see the CHANGELOG file to find out who contributed 36the specific port. In addition, there are various MAINTAINERS files 37scattered throughout the U-Boot source identifying the people or 38companies responsible for various boards and subsystems. 39 40Note: As of August, 2010, there is no longer a CHANGELOG file in the 41actual U-Boot source tree; however, it can be created dynamically 42from the Git log using: 43 44 make CHANGELOG 45 46 47Where to get help: 48================== 49 50In case you have questions about, problems with or contributions for 51U-Boot, you should send a message to the U-Boot mailing list at 52<u-boot@lists.denx.de>. There is also an archive of previous traffic 53on the mailing list - please search the archive before asking FAQ's. 54Please see https://lists.denx.de/pipermail/u-boot and 55https://marc.info/?l=u-boot 56 57Where to get source code: 58========================= 59 60The U-Boot source code is maintained in the Git repository at 61https://source.denx.de/u-boot/u-boot.git ; you can browse it online at 62https://source.denx.de/u-boot/u-boot 63 64The "Tags" links on this page allow you to download tarballs of 65any version you might be interested in. Official releases are also 66available from the DENX file server through HTTPS or FTP. 67https://ftp.denx.de/pub/u-boot/ 68ftp://ftp.denx.de/pub/u-boot/ 69 70 71Where we come from: 72=================== 73 74- start from 8xxrom sources 75- create PPCBoot project (https://sourceforge.net/projects/ppcboot) 76- clean up code 77- make it easier to add custom boards 78- make it possible to add other [PowerPC] CPUs 79- extend functions, especially: 80 * Provide extended interface to Linux boot loader 81 * S-Record download 82 * network boot 83 * ATA disk / SCSI ... boot 84- create ARMBoot project (https://sourceforge.net/projects/armboot) 85- add other CPU families (starting with ARM) 86- create U-Boot project (https://sourceforge.net/projects/u-boot) 87- current project page: see https://www.denx.de/wiki/U-Boot 88 89 90Names and Spelling: 91=================== 92 93The "official" name of this project is "Das U-Boot". The spelling 94"U-Boot" shall be used in all written text (documentation, comments 95in source files etc.). Example: 96 97 This is the README file for the U-Boot project. 98 99File names etc. shall be based on the string "u-boot". Examples: 100 101 include/asm-ppc/u-boot.h 102 103 #include <asm/u-boot.h> 104 105Variable names, preprocessor constants etc. shall be either based on 106the string "u_boot" or on "U_BOOT". Example: 107 108 U_BOOT_VERSION u_boot_logo 109 IH_OS_U_BOOT u_boot_hush_start 110 111 112Versioning: 113=========== 114 115Starting with the release in October 2008, the names of the releases 116were changed from numerical release numbers without deeper meaning 117into a time stamp based numbering. Regular releases are identified by 118names consisting of the calendar year and month of the release date. 119Additional fields (if present) indicate release candidates or bug fix 120releases in "stable" maintenance trees. 121 122Examples: 123 U-Boot v2009.11 - Release November 2009 124 U-Boot v2009.11.1 - Release 1 in version November 2009 stable tree 125 U-Boot v2010.09-rc1 - Release candidate 1 for September 2010 release 126 127 128Directory Hierarchy: 129==================== 130 131/arch Architecture-specific files 132 /arc Files generic to ARC architecture 133 /arm Files generic to ARM architecture 134 /m68k Files generic to m68k architecture 135 /microblaze Files generic to microblaze architecture 136 /mips Files generic to MIPS architecture 137 /nds32 Files generic to NDS32 architecture 138 /nios2 Files generic to Altera NIOS2 architecture 139 /powerpc Files generic to PowerPC architecture 140 /riscv Files generic to RISC-V architecture 141 /sandbox Files generic to HW-independent "sandbox" 142 /sh Files generic to SH architecture 143 /x86 Files generic to x86 architecture 144 /xtensa Files generic to Xtensa architecture 145/api Machine/arch-independent API for external apps 146/board Board-dependent files 147/cmd U-Boot commands functions 148/common Misc architecture-independent functions 149/configs Board default configuration files 150/disk Code for disk drive partition handling 151/doc Documentation (a mix of ReST and READMEs) 152/drivers Device drivers 153/dts Makefile for building internal U-Boot fdt. 154/env Environment support 155/examples Example code for standalone applications, etc. 156/fs Filesystem code (cramfs, ext2, jffs2, etc.) 157/include Header Files 158/lib Library routines generic to all architectures 159/Licenses Various license files 160/net Networking code 161/post Power On Self Test 162/scripts Various build scripts and Makefiles 163/test Various unit test files 164/tools Tools to build and sign FIT images, etc. 165 166Software Configuration: 167======================= 168 169Configuration is usually done using C preprocessor defines; the 170rationale behind that is to avoid dead code whenever possible. 171 172There are two classes of configuration variables: 173 174* Configuration _OPTIONS_: 175 These are selectable by the user and have names beginning with 176 "CONFIG_". 177 178* Configuration _SETTINGS_: 179 These depend on the hardware etc. and should not be meddled with if 180 you don't know what you're doing; they have names beginning with 181 "CONFIG_SYS_". 182 183Previously, all configuration was done by hand, which involved creating 184symbolic links and editing configuration files manually. More recently, 185U-Boot has added the Kbuild infrastructure used by the Linux kernel, 186allowing you to use the "make menuconfig" command to configure your 187build. 188 189 190Selection of Processor Architecture and Board Type: 191--------------------------------------------------- 192 193For all supported boards there are ready-to-use default 194configurations available; just type "make <board_name>_defconfig". 195 196Example: For a TQM823L module type: 197 198 cd u-boot 199 make TQM823L_defconfig 200 201Note: If you're looking for the default configuration file for a board 202you're sure used to be there but is now missing, check the file 203doc/README.scrapyard for a list of no longer supported boards. 204 205Sandbox Environment: 206-------------------- 207 208U-Boot can be built natively to run on a Linux host using the 'sandbox' 209board. This allows feature development which is not board- or architecture- 210specific to be undertaken on a native platform. The sandbox is also used to 211run some of U-Boot's tests. 212 213See doc/arch/sandbox.rst for more details. 214 215 216Board Initialisation Flow: 217-------------------------- 218 219This is the intended start-up flow for boards. This should apply for both 220SPL and U-Boot proper (i.e. they both follow the same rules). 221 222Note: "SPL" stands for "Secondary Program Loader," which is explained in 223more detail later in this file. 224 225At present, SPL mostly uses a separate code path, but the function names 226and roles of each function are the same. Some boards or architectures 227may not conform to this. At least most ARM boards which use 228CONFIG_SPL_FRAMEWORK conform to this. 229 230Execution typically starts with an architecture-specific (and possibly 231CPU-specific) start.S file, such as: 232 233 - arch/arm/cpu/armv7/start.S 234 - arch/powerpc/cpu/mpc83xx/start.S 235 - arch/mips/cpu/start.S 236 237and so on. From there, three functions are called; the purpose and 238limitations of each of these functions are described below. 239 240lowlevel_init(): 241 - purpose: essential init to permit execution to reach board_init_f() 242 - no global_data or BSS 243 - there is no stack (ARMv7 may have one but it will soon be removed) 244 - must not set up SDRAM or use console 245 - must only do the bare minimum to allow execution to continue to 246 board_init_f() 247 - this is almost never needed 248 - return normally from this function 249 250board_init_f(): 251 - purpose: set up the machine ready for running board_init_r(): 252 i.e. SDRAM and serial UART 253 - global_data is available 254 - stack is in SRAM 255 - BSS is not available, so you cannot use global/static variables, 256 only stack variables and global_data 257 258 Non-SPL-specific notes: 259 - dram_init() is called to set up DRAM. If already done in SPL this 260 can do nothing 261 262 SPL-specific notes: 263 - you can override the entire board_init_f() function with your own 264 version as needed. 265 - preloader_console_init() can be called here in extremis 266 - should set up SDRAM, and anything needed to make the UART work 267 - there is no need to clear BSS, it will be done by crt0.S 268 - for specific scenarios on certain architectures an early BSS *can* 269 be made available (via CONFIG_SPL_EARLY_BSS by moving the clearing 270 of BSS prior to entering board_init_f()) but doing so is discouraged. 271 Instead it is strongly recommended to architect any code changes 272 or additions such to not depend on the availability of BSS during 273 board_init_f() as indicated in other sections of this README to 274 maintain compatibility and consistency across the entire code base. 275 - must return normally from this function (don't call board_init_r() 276 directly) 277 278Here the BSS is cleared. For SPL, if CONFIG_SPL_STACK_R is defined, then at 279this point the stack and global_data are relocated to below 280CONFIG_SPL_STACK_R_ADDR. For non-SPL, U-Boot is relocated to run at the top of 281memory. 282 283board_init_r(): 284 - purpose: main execution, common code 285 - global_data is available 286 - SDRAM is available 287 - BSS is available, all static/global variables can be used 288 - execution eventually continues to main_loop() 289 290 Non-SPL-specific notes: 291 - U-Boot is relocated to the top of memory and is now running from 292 there. 293 294 SPL-specific notes: 295 - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and 296 CONFIG_SPL_STACK_R_ADDR points into SDRAM 297 - preloader_console_init() can be called here - typically this is 298 done by selecting CONFIG_SPL_BOARD_INIT and then supplying a 299 spl_board_init() function containing this call 300 - loads U-Boot or (in falcon mode) Linux 301 302 303Configuration Options: 304---------------------- 305 306Configuration depends on the combination of board and CPU type; all 307such information is kept in a configuration file 308"include/configs/<board_name>.h". 309 310Example: For a TQM823L module, all configuration settings are in 311"include/configs/TQM823L.h". 312 313 314Many of the options are named exactly as the corresponding Linux 315kernel configuration options. The intention is to make it easier to 316build a config tool - later. 317 318- ARM Platform Bus Type(CCI): 319 CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which 320 provides full cache coherency between two clusters of multi-core 321 CPUs and I/O coherency for devices and I/O masters 322 323 CONFIG_SYS_FSL_HAS_CCI400 324 325 Defined For SoC that has cache coherent interconnect 326 CCN-400 327 328 CONFIG_SYS_FSL_HAS_CCN504 329 330 Defined for SoC that has cache coherent interconnect CCN-504 331 332The following options need to be configured: 333 334- CPU Type: Define exactly one, e.g. CONFIG_MPC85XX. 335 336- Board Type: Define exactly one, e.g. CONFIG_MPC8540ADS. 337 338- 85xx CPU Options: 339 CONFIG_SYS_PPC64 340 341 Specifies that the core is a 64-bit PowerPC implementation (implements 342 the "64" category of the Power ISA). This is necessary for ePAPR 343 compliance, among other possible reasons. 344 345 CONFIG_SYS_FSL_TBCLK_DIV 346 347 Defines the core time base clock divider ratio compared to the 348 system clock. On most PQ3 devices this is 8, on newer QorIQ 349 devices it can be 16 or 32. The ratio varies from SoC to Soc. 350 351 CONFIG_SYS_FSL_PCIE_COMPAT 352 353 Defines the string to utilize when trying to match PCIe device 354 tree nodes for the given platform. 355 356 CONFIG_SYS_FSL_ERRATUM_A004510 357 358 Enables a workaround for erratum A004510. If set, 359 then CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV and 360 CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY must be set. 361 362 CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV 363 CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV2 (optional) 364 365 Defines one or two SoC revisions (low 8 bits of SVR) 366 for which the A004510 workaround should be applied. 367 368 The rest of SVR is either not relevant to the decision 369 of whether the erratum is present (e.g. p2040 versus 370 p2041) or is implied by the build target, which controls 371 whether CONFIG_SYS_FSL_ERRATUM_A004510 is set. 372 373 See Freescale App Note 4493 for more information about 374 this erratum. 375 376 CONFIG_A003399_NOR_WORKAROUND 377 Enables a workaround for IFC erratum A003399. It is only 378 required during NOR boot. 379 380 CONFIG_A008044_WORKAROUND 381 Enables a workaround for T1040/T1042 erratum A008044. It is only 382 required during NAND boot and valid for Rev 1.0 SoC revision 383 384 CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 385 386 This is the value to write into CCSR offset 0x18600 387 according to the A004510 workaround. 388 389 CONFIG_SYS_FSL_DSP_DDR_ADDR 390 This value denotes start offset of DDR memory which is 391 connected exclusively to the DSP cores. 392 393 CONFIG_SYS_FSL_DSP_M2_RAM_ADDR 394 This value denotes start offset of M2 memory 395 which is directly connected to the DSP core. 396 397 CONFIG_SYS_FSL_DSP_M3_RAM_ADDR 398 This value denotes start offset of M3 memory which is directly 399 connected to the DSP core. 400 401 CONFIG_SYS_FSL_DSP_CCSRBAR_DEFAULT 402 This value denotes start offset of DSP CCSR space. 403 404 CONFIG_SYS_FSL_SINGLE_SOURCE_CLK 405 Single Source Clock is clocking mode present in some of FSL SoC's. 406 In this mode, a single differential clock is used to supply 407 clocks to the sysclock, ddrclock and usbclock. 408 409 CONFIG_SYS_CPC_REINIT_F 410 This CONFIG is defined when the CPC is configured as SRAM at the 411 time of U-Boot entry and is required to be re-initialized. 412 413 CONFIG_DEEP_SLEEP 414 Indicates this SoC supports deep sleep feature. If deep sleep is 415 supported, core will start to execute uboot when wakes up. 416 417- Generic CPU options: 418 CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN 419 420 Defines the endianess of the CPU. Implementation of those 421 values is arch specific. 422 423 CONFIG_SYS_FSL_DDR 424 Freescale DDR driver in use. This type of DDR controller is 425 found in mpc83xx, mpc85xx as well as some ARM core SoCs. 426 427 CONFIG_SYS_FSL_DDR_ADDR 428 Freescale DDR memory-mapped register base. 429 430 CONFIG_SYS_FSL_DDR_EMU 431 Specify emulator support for DDR. Some DDR features such as 432 deskew training are not available. 433 434 CONFIG_SYS_FSL_DDRC_GEN1 435 Freescale DDR1 controller. 436 437 CONFIG_SYS_FSL_DDRC_GEN2 438 Freescale DDR2 controller. 439 440 CONFIG_SYS_FSL_DDRC_GEN3 441 Freescale DDR3 controller. 442 443 CONFIG_SYS_FSL_DDRC_GEN4 444 Freescale DDR4 controller. 445 446 CONFIG_SYS_FSL_DDRC_ARM_GEN3 447 Freescale DDR3 controller for ARM-based SoCs. 448 449 CONFIG_SYS_FSL_DDR1 450 Board config to use DDR1. It can be enabled for SoCs with 451 Freescale DDR1 or DDR2 controllers, depending on the board 452 implemetation. 453 454 CONFIG_SYS_FSL_DDR2 455 Board config to use DDR2. It can be enabled for SoCs with 456 Freescale DDR2 or DDR3 controllers, depending on the board 457 implementation. 458 459 CONFIG_SYS_FSL_DDR3 460 Board config to use DDR3. It can be enabled for SoCs with 461 Freescale DDR3 or DDR3L controllers. 462 463 CONFIG_SYS_FSL_DDR3L 464 Board config to use DDR3L. It can be enabled for SoCs with 465 DDR3L controllers. 466 467 CONFIG_SYS_FSL_IFC_BE 468 Defines the IFC controller register space as Big Endian 469 470 CONFIG_SYS_FSL_IFC_LE 471 Defines the IFC controller register space as Little Endian 472 473 CONFIG_SYS_FSL_IFC_CLK_DIV 474 Defines divider of platform clock(clock input to IFC controller). 475 476 CONFIG_SYS_FSL_LBC_CLK_DIV 477 Defines divider of platform clock(clock input to eLBC controller). 478 479 CONFIG_SYS_FSL_DDR_BE 480 Defines the DDR controller register space as Big Endian 481 482 CONFIG_SYS_FSL_DDR_LE 483 Defines the DDR controller register space as Little Endian 484 485 CONFIG_SYS_FSL_DDR_SDRAM_BASE_PHY 486 Physical address from the view of DDR controllers. It is the 487 same as CONFIG_SYS_DDR_SDRAM_BASE for all Power SoCs. But 488 it could be different for ARM SoCs. 489 490 CONFIG_SYS_FSL_DDR_INTLV_256B 491 DDR controller interleaving on 256-byte. This is a special 492 interleaving mode, handled by Dickens for Freescale layerscape 493 SoCs with ARM core. 494 495 CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS 496 Number of controllers used as main memory. 497 498 CONFIG_SYS_FSL_OTHER_DDR_NUM_CTRLS 499 Number of controllers used for other than main memory. 500 501 CONFIG_SYS_FSL_HAS_DP_DDR 502 Defines the SoC has DP-DDR used for DPAA. 503 504 CONFIG_SYS_FSL_SEC_BE 505 Defines the SEC controller register space as Big Endian 506 507 CONFIG_SYS_FSL_SEC_LE 508 Defines the SEC controller register space as Little Endian 509 510- MIPS CPU options: 511 CONFIG_SYS_INIT_SP_OFFSET 512 513 Offset relative to CONFIG_SYS_SDRAM_BASE for initial stack 514 pointer. This is needed for the temporary stack before 515 relocation. 516 517 CONFIG_XWAY_SWAP_BYTES 518 519 Enable compilation of tools/xway-swap-bytes needed for Lantiq 520 XWAY SoCs for booting from NOR flash. The U-Boot image needs to 521 be swapped if a flash programmer is used. 522 523- ARM options: 524 CONFIG_SYS_EXCEPTION_VECTORS_HIGH 525 526 Select high exception vectors of the ARM core, e.g., do not 527 clear the V bit of the c1 register of CP15. 528 529 COUNTER_FREQUENCY 530 Generic timer clock source frequency. 531 532 COUNTER_FREQUENCY_REAL 533 Generic timer clock source frequency if the real clock is 534 different from COUNTER_FREQUENCY, and can only be determined 535 at run time. 536 537- Tegra SoC options: 538 CONFIG_TEGRA_SUPPORT_NON_SECURE 539 540 Support executing U-Boot in non-secure (NS) mode. Certain 541 impossible actions will be skipped if the CPU is in NS mode, 542 such as ARM architectural timer initialization. 543 544- Linux Kernel Interface: 545 CONFIG_MEMSIZE_IN_BYTES [relevant for MIPS only] 546 547 When transferring memsize parameter to Linux, some versions 548 expect it to be in bytes, others in MB. 549 Define CONFIG_MEMSIZE_IN_BYTES to make it in bytes. 550 551 CONFIG_OF_LIBFDT 552 553 New kernel versions are expecting firmware settings to be 554 passed using flattened device trees (based on open firmware 555 concepts). 556 557 CONFIG_OF_LIBFDT 558 * New libfdt-based support 559 * Adds the "fdt" command 560 * The bootm command automatically updates the fdt 561 562 OF_TBCLK - The timebase frequency. 563 564 boards with QUICC Engines require OF_QE to set UCC MAC 565 addresses 566 567 CONFIG_OF_BOARD_SETUP 568 569 Board code has addition modification that it wants to make 570 to the flat device tree before handing it off to the kernel 571 572 CONFIG_OF_SYSTEM_SETUP 573 574 Other code has addition modification that it wants to make 575 to the flat device tree before handing it off to the kernel. 576 This causes ft_system_setup() to be called before booting 577 the kernel. 578 579 CONFIG_OF_IDE_FIXUP 580 581 U-Boot can detect if an IDE device is present or not. 582 If not, and this new config option is activated, U-Boot 583 removes the ATA node from the DTS before booting Linux, 584 so the Linux IDE driver does not probe the device and 585 crash. This is needed for buggy hardware (uc101) where 586 no pull down resistor is connected to the signal IDE5V_DD7. 587 588- vxWorks boot parameters: 589 590 bootvx constructs a valid bootline using the following 591 environments variables: bootdev, bootfile, ipaddr, netmask, 592 serverip, gatewayip, hostname, othbootargs. 593 It loads the vxWorks image pointed bootfile. 594 595 Note: If a "bootargs" environment is defined, it will override 596 the defaults discussed just above. 597 598- Cache Configuration: 599 CONFIG_SYS_L2CACHE_OFF- Do not enable L2 cache in U-Boot 600 601- Cache Configuration for ARM: 602 CONFIG_SYS_L2_PL310 - Enable support for ARM PL310 L2 cache 603 controller 604 CONFIG_SYS_PL310_BASE - Physical base address of PL310 605 controller register space 606 607- Serial Ports: 608 CONFIG_PL011_SERIAL 609 610 Define this if you want support for Amba PrimeCell PL011 UARTs. 611 612 CONFIG_PL011_CLOCK 613 614 If you have Amba PrimeCell PL011 UARTs, set this variable to 615 the clock speed of the UARTs. 616 617 CONFIG_PL01x_PORTS 618 619 If you have Amba PrimeCell PL010 or PL011 UARTs on your board, 620 define this to a list of base addresses for each (supported) 621 port. See e.g. include/configs/versatile.h 622 623 CONFIG_SERIAL_HW_FLOW_CONTROL 624 625 Define this variable to enable hw flow control in serial driver. 626 Current user of this option is drivers/serial/nsl16550.c driver 627 628- Autoboot Command: 629 CONFIG_BOOTCOMMAND 630 Only needed when CONFIG_BOOTDELAY is enabled; 631 define a command string that is automatically executed 632 when no character is read on the console interface 633 within "Boot Delay" after reset. 634 635 CONFIG_RAMBOOT and CONFIG_NFSBOOT 636 The value of these goes into the environment as 637 "ramboot" and "nfsboot" respectively, and can be used 638 as a convenience, when switching between booting from 639 RAM and NFS. 640 641- Serial Download Echo Mode: 642 CONFIG_LOADS_ECHO 643 If defined to 1, all characters received during a 644 serial download (using the "loads" command) are 645 echoed back. This might be needed by some terminal 646 emulations (like "cu"), but may as well just take 647 time on others. This setting #define's the initial 648 value of the "loads_echo" environment variable. 649 650- Removal of commands 651 If no commands are needed to boot, you can disable 652 CONFIG_CMDLINE to remove them. In this case, the command line 653 will not be available, and when U-Boot wants to execute the 654 boot command (on start-up) it will call board_run_command() 655 instead. This can reduce image size significantly for very 656 simple boot procedures. 657 658- Regular expression support: 659 CONFIG_REGEX 660 If this variable is defined, U-Boot is linked against 661 the SLRE (Super Light Regular Expression) library, 662 which adds regex support to some commands, as for 663 example "env grep" and "setexpr". 664 665- Device tree: 666 CONFIG_OF_CONTROL 667 If this variable is defined, U-Boot will use a device tree 668 to configure its devices, instead of relying on statically 669 compiled #defines in the board file. This option is 670 experimental and only available on a few boards. The device 671 tree is available in the global data as gd->fdt_blob. 672 673 U-Boot needs to get its device tree from somewhere. This can 674 be done using one of the three options below: 675 676 CONFIG_OF_EMBED 677 If this variable is defined, U-Boot will embed a device tree 678 binary in its image. This device tree file should be in the 679 board directory and called <soc>-<board>.dts. The binary file 680 is then picked up in board_init_f() and made available through 681 the global data structure as gd->fdt_blob. 682 683 CONFIG_OF_SEPARATE 684 If this variable is defined, U-Boot will build a device tree 685 binary. It will be called u-boot.dtb. Architecture-specific 686 code will locate it at run-time. Generally this works by: 687 688 cat u-boot.bin u-boot.dtb >image.bin 689 690 and in fact, U-Boot does this for you, creating a file called 691 u-boot-dtb.bin which is useful in the common case. You can 692 still use the individual files if you need something more 693 exotic. 694 695 CONFIG_OF_BOARD 696 If this variable is defined, U-Boot will use the device tree 697 provided by the board at runtime instead of embedding one with 698 the image. Only boards defining board_fdt_blob_setup() support 699 this option (see include/fdtdec.h file). 700 701- Watchdog: 702 CONFIG_WATCHDOG 703 If this variable is defined, it enables watchdog 704 support for the SoC. There must be support in the SoC 705 specific code for a watchdog. For the 8xx 706 CPUs, the SIU Watchdog feature is enabled in the SYPCR 707 register. When supported for a specific SoC is 708 available, then no further board specific code should 709 be needed to use it. 710 711 CONFIG_HW_WATCHDOG 712 When using a watchdog circuitry external to the used 713 SoC, then define this variable and provide board 714 specific code for the "hw_watchdog_reset" function. 715 716 CONFIG_SYS_WATCHDOG_FREQ 717 Some platforms automatically call WATCHDOG_RESET() 718 from the timer interrupt handler every 719 CONFIG_SYS_WATCHDOG_FREQ interrupts. If not set by the 720 board configuration file, a default of CONFIG_SYS_HZ/2 721 (i.e. 500) is used. Setting CONFIG_SYS_WATCHDOG_FREQ 722 to 0 disables calling WATCHDOG_RESET() from the timer 723 interrupt. 724 725- Real-Time Clock: 726 727 When CONFIG_CMD_DATE is selected, the type of the RTC 728 has to be selected, too. Define exactly one of the 729 following options: 730 731 CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC 732 CONFIG_RTC_MC13XXX - use MC13783 or MC13892 RTC 733 CONFIG_RTC_MC146818 - use MC146818 RTC 734 CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC 735 CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC 736 CONFIG_RTC_DS1338 - use Maxim, Inc. DS1338 RTC 737 CONFIG_RTC_DS1339 - use Maxim, Inc. DS1339 RTC 738 CONFIG_RTC_DS164x - use Dallas DS164x RTC 739 CONFIG_RTC_ISL1208 - use Intersil ISL1208 RTC 740 CONFIG_RTC_MAX6900 - use Maxim, Inc. MAX6900 RTC 741 CONFIG_RTC_DS1337_NOOSC - Turn off the OSC output for DS1337 742 CONFIG_SYS_RV3029_TCR - enable trickle charger on 743 RV3029 RTC. 744 745 Note that if the RTC uses I2C, then the I2C interface 746 must also be configured. See I2C Support, below. 747 748- GPIO Support: 749 CONFIG_PCA953X - use NXP's PCA953X series I2C GPIO 750 751 The CONFIG_SYS_I2C_PCA953X_WIDTH option specifies a list of 752 chip-ngpio pairs that tell the PCA953X driver the number of 753 pins supported by a particular chip. 754 755 Note that if the GPIO device uses I2C, then the I2C interface 756 must also be configured. See I2C Support, below. 757 758- I/O tracing: 759 When CONFIG_IO_TRACE is selected, U-Boot intercepts all I/O 760 accesses and can checksum them or write a list of them out 761 to memory. See the 'iotrace' command for details. This is 762 useful for testing device drivers since it can confirm that 763 the driver behaves the same way before and after a code 764 change. Currently this is supported on sandbox and arm. To 765 add support for your architecture, add '#include <iotrace.h>' 766 to the bottom of arch/<arch>/include/asm/io.h and test. 767 768 Example output from the 'iotrace stats' command is below. 769 Note that if the trace buffer is exhausted, the checksum will 770 still continue to operate. 771 772 iotrace is enabled 773 Start: 10000000 (buffer start address) 774 Size: 00010000 (buffer size) 775 Offset: 00000120 (current buffer offset) 776 Output: 10000120 (start + offset) 777 Count: 00000018 (number of trace records) 778 CRC32: 9526fb66 (CRC32 of all trace records) 779 780- Timestamp Support: 781 782 When CONFIG_TIMESTAMP is selected, the timestamp 783 (date and time) of an image is printed by image 784 commands like bootm or iminfo. This option is 785 automatically enabled when you select CONFIG_CMD_DATE . 786 787- Partition Labels (disklabels) Supported: 788 Zero or more of the following: 789 CONFIG_MAC_PARTITION Apple's MacOS partition table. 790 CONFIG_ISO_PARTITION ISO partition table, used on CDROM etc. 791 CONFIG_EFI_PARTITION GPT partition table, common when EFI is the 792 bootloader. Note 2TB partition limit; see 793 disk/part_efi.c 794 CONFIG_SCSI) you must configure support for at 795 least one non-MTD partition type as well. 796 797- IDE Reset method: 798 CONFIG_IDE_RESET_ROUTINE - this is defined in several 799 board configurations files but used nowhere! 800 801 CONFIG_IDE_RESET - is this is defined, IDE Reset will 802 be performed by calling the function 803 ide_set_reset(int reset) 804 which has to be defined in a board specific file 805 806- ATAPI Support: 807 CONFIG_ATAPI 808 809 Set this to enable ATAPI support. 810 811- LBA48 Support 812 CONFIG_LBA48 813 814 Set this to enable support for disks larger than 137GB 815 Also look at CONFIG_SYS_64BIT_LBA. 816 Whithout these , LBA48 support uses 32bit variables and will 'only' 817 support disks up to 2.1TB. 818 819 CONFIG_SYS_64BIT_LBA: 820 When enabled, makes the IDE subsystem use 64bit sector addresses. 821 Default is 32bit. 822 823- SCSI Support: 824 CONFIG_SYS_SCSI_MAX_LUN [8], CONFIG_SYS_SCSI_MAX_SCSI_ID [7] and 825 CONFIG_SYS_SCSI_MAX_DEVICE [CONFIG_SYS_SCSI_MAX_SCSI_ID * 826 CONFIG_SYS_SCSI_MAX_LUN] can be adjusted to define the 827 maximum numbers of LUNs, SCSI ID's and target 828 devices. 829 830 The environment variable 'scsidevs' is set to the number of 831 SCSI devices found during the last scan. 832 833- NETWORK Support (PCI): 834 CONFIG_E1000 835 Support for Intel 8254x/8257x gigabit chips. 836 837 CONFIG_E1000_SPI 838 Utility code for direct access to the SPI bus on Intel 8257x. 839 This does not do anything useful unless you set at least one 840 of CONFIG_CMD_E1000 or CONFIG_E1000_SPI_GENERIC. 841 842 CONFIG_E1000_SPI_GENERIC 843 Allow generic access to the SPI bus on the Intel 8257x, for 844 example with the "sspi" command. 845 846 CONFIG_NATSEMI 847 Support for National dp83815 chips. 848 849 CONFIG_NS8382X 850 Support for National dp8382[01] gigabit chips. 851 852- NETWORK Support (other): 853 CONFIG_CALXEDA_XGMAC 854 Support for the Calxeda XGMAC device 855 856 CONFIG_LAN91C96 857 Support for SMSC's LAN91C96 chips. 858 859 CONFIG_LAN91C96_USE_32_BIT 860 Define this to enable 32 bit addressing 861 862 CONFIG_SMC91111 863 Support for SMSC's LAN91C111 chip 864 865 CONFIG_SMC91111_BASE 866 Define this to hold the physical address 867 of the device (I/O space) 868 869 CONFIG_SMC_USE_32_BIT 870 Define this if data bus is 32 bits 871 872 CONFIG_SMC_USE_IOFUNCS 873 Define this to use i/o functions instead of macros 874 (some hardware wont work with macros) 875 876 CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT 877 Define this if you have more then 3 PHYs. 878 879 CONFIG_FTGMAC100 880 Support for Faraday's FTGMAC100 Gigabit SoC Ethernet 881 882 CONFIG_FTGMAC100_EGIGA 883 Define this to use GE link update with gigabit PHY. 884 Define this if FTGMAC100 is connected to gigabit PHY. 885 If your system has 10/100 PHY only, it might not occur 886 wrong behavior. Because PHY usually return timeout or 887 useless data when polling gigabit status and gigabit 888 control registers. This behavior won't affect the 889 correctnessof 10/100 link speed update. 890 891 CONFIG_SH_ETHER 892 Support for Renesas on-chip Ethernet controller 893 894 CONFIG_SH_ETHER_USE_PORT 895 Define the number of ports to be used 896 897 CONFIG_SH_ETHER_PHY_ADDR 898 Define the ETH PHY's address 899 900 CONFIG_SH_ETHER_CACHE_WRITEBACK 901 If this option is set, the driver enables cache flush. 902 903- TPM Support: 904 CONFIG_TPM 905 Support TPM devices. 906 907 CONFIG_TPM_TIS_INFINEON 908 Support for Infineon i2c bus TPM devices. Only one device 909 per system is supported at this time. 910 911 CONFIG_TPM_TIS_I2C_BURST_LIMITATION 912 Define the burst count bytes upper limit 913 914 CONFIG_TPM_ST33ZP24 915 Support for STMicroelectronics TPM devices. Requires DM_TPM support. 916 917 CONFIG_TPM_ST33ZP24_I2C 918 Support for STMicroelectronics ST33ZP24 I2C devices. 919 Requires TPM_ST33ZP24 and I2C. 920 921 CONFIG_TPM_ST33ZP24_SPI 922 Support for STMicroelectronics ST33ZP24 SPI devices. 923 Requires TPM_ST33ZP24 and SPI. 924 925 CONFIG_TPM_ATMEL_TWI 926 Support for Atmel TWI TPM device. Requires I2C support. 927 928 CONFIG_TPM_TIS_LPC 929 Support for generic parallel port TPM devices. Only one device 930 per system is supported at this time. 931 932 CONFIG_TPM_TIS_BASE_ADDRESS 933 Base address where the generic TPM device is mapped 934 to. Contemporary x86 systems usually map it at 935 0xfed40000. 936 937 CONFIG_TPM 938 Define this to enable the TPM support library which provides 939 functional interfaces to some TPM commands. 940 Requires support for a TPM device. 941 942 CONFIG_TPM_AUTH_SESSIONS 943 Define this to enable authorized functions in the TPM library. 944 Requires CONFIG_TPM and CONFIG_SHA1. 945 946- USB Support: 947 At the moment only the UHCI host controller is 948 supported (PIP405, MIP405); define 949 CONFIG_USB_UHCI to enable it. 950 define CONFIG_USB_KEYBOARD to enable the USB Keyboard 951 and define CONFIG_USB_STORAGE to enable the USB 952 storage devices. 953 Note: 954 Supported are USB Keyboards and USB Floppy drives 955 (TEAC FD-05PUB). 956 957 CONFIG_USB_EHCI_TXFIFO_THRESH enables setting of the 958 txfilltuning field in the EHCI controller on reset. 959 960 CONFIG_USB_DWC2_REG_ADDR the physical CPU address of the DWC2 961 HW module registers. 962 963- USB Device: 964 Define the below if you wish to use the USB console. 965 Once firmware is rebuilt from a serial console issue the 966 command "setenv stdin usbtty; setenv stdout usbtty" and 967 attach your USB cable. The Unix command "dmesg" should print 968 it has found a new device. The environment variable usbtty 969 can be set to gserial or cdc_acm to enable your device to 970 appear to a USB host as a Linux gserial device or a 971 Common Device Class Abstract Control Model serial device. 972 If you select usbtty = gserial you should be able to enumerate 973 a Linux host by 974 # modprobe usbserial vendor=0xVendorID product=0xProductID 975 else if using cdc_acm, simply setting the environment 976 variable usbtty to be cdc_acm should suffice. The following 977 might be defined in YourBoardName.h 978 979 CONFIG_USB_DEVICE 980 Define this to build a UDC device 981 982 CONFIG_USB_TTY 983 Define this to have a tty type of device available to 984 talk to the UDC device 985 986 CONFIG_USBD_HS 987 Define this to enable the high speed support for usb 988 device and usbtty. If this feature is enabled, a routine 989 int is_usbd_high_speed(void) 990 also needs to be defined by the driver to dynamically poll 991 whether the enumeration has succeded at high speed or full 992 speed. 993 994 CONFIG_SYS_CONSOLE_IS_IN_ENV 995 Define this if you want stdin, stdout &/or stderr to 996 be set to usbtty. 997 998 If you have a USB-IF assigned VendorID then you may wish to 999 define your own vendor specific values either in BoardName.h 1000 or directly in usbd_vendor_info.h. If you don't define 1001 CONFIG_USBD_MANUFACTURER, CONFIG_USBD_PRODUCT_NAME, 1002 CONFIG_USBD_VENDORID and CONFIG_USBD_PRODUCTID, then U-Boot 1003 should pretend to be a Linux device to it's target host. 1004 1005 CONFIG_USBD_MANUFACTURER 1006 Define this string as the name of your company for 1007 - CONFIG_USBD_MANUFACTURER "my company" 1008 1009 CONFIG_USBD_PRODUCT_NAME 1010 Define this string as the name of your product 1011 - CONFIG_USBD_PRODUCT_NAME "acme usb device" 1012 1013 CONFIG_USBD_VENDORID 1014 Define this as your assigned Vendor ID from the USB 1015 Implementors Forum. This *must* be a genuine Vendor ID 1016 to avoid polluting the USB namespace. 1017 - CONFIG_USBD_VENDORID 0xFFFF 1018 1019 CONFIG_USBD_PRODUCTID 1020 Define this as the unique Product ID 1021 for your device 1022 - CONFIG_USBD_PRODUCTID 0xFFFF 1023 1024- ULPI Layer Support: 1025 The ULPI (UTMI Low Pin (count) Interface) PHYs are supported via 1026 the generic ULPI layer. The generic layer accesses the ULPI PHY 1027 via the platform viewport, so you need both the genric layer and 1028 the viewport enabled. Currently only Chipidea/ARC based 1029 viewport is supported. 1030 To enable the ULPI layer support, define CONFIG_USB_ULPI and 1031 CONFIG_USB_ULPI_VIEWPORT in your board configuration file. 1032 If your ULPI phy needs a different reference clock than the 1033 standard 24 MHz then you have to define CONFIG_ULPI_REF_CLK to 1034 the appropriate value in Hz. 1035 1036- MMC Support: 1037 The MMC controller on the Intel PXA is supported. To 1038 enable this define CONFIG_MMC. The MMC can be 1039 accessed from the boot prompt by mapping the device 1040 to physical memory similar to flash. Command line is 1041 enabled with CONFIG_CMD_MMC. The MMC driver also works with 1042 the FAT fs. This is enabled with CONFIG_CMD_FAT. 1043 1044 CONFIG_SH_MMCIF 1045 Support for Renesas on-chip MMCIF controller 1046 1047 CONFIG_SH_MMCIF_ADDR 1048 Define the base address of MMCIF registers 1049 1050 CONFIG_SH_MMCIF_CLK 1051 Define the clock frequency for MMCIF 1052 1053- USB Device Firmware Update (DFU) class support: 1054 CONFIG_DFU_OVER_USB 1055 This enables the USB portion of the DFU USB class 1056 1057 CONFIG_DFU_NAND 1058 This enables support for exposing NAND devices via DFU. 1059 1060 CONFIG_DFU_RAM 1061 This enables support for exposing RAM via DFU. 1062 Note: DFU spec refer to non-volatile memory usage, but 1063 allow usages beyond the scope of spec - here RAM usage, 1064 one that would help mostly the developer. 1065 1066 CONFIG_SYS_DFU_DATA_BUF_SIZE 1067 Dfu transfer uses a buffer before writing data to the 1068 raw storage device. Make the size (in bytes) of this buffer 1069 configurable. The size of this buffer is also configurable 1070 through the "dfu_bufsiz" environment variable. 1071 1072 CONFIG_SYS_DFU_MAX_FILE_SIZE 1073 When updating files rather than the raw storage device, 1074 we use a static buffer to copy the file into and then write 1075 the buffer once we've been given the whole file. Define 1076 this to the maximum filesize (in bytes) for the buffer. 1077 Default is 4 MiB if undefined. 1078 1079 DFU_DEFAULT_POLL_TIMEOUT 1080 Poll timeout [ms], is the timeout a device can send to the 1081 host. The host must wait for this timeout before sending 1082 a subsequent DFU_GET_STATUS request to the device. 1083 1084 DFU_MANIFEST_POLL_TIMEOUT 1085 Poll timeout [ms], which the device sends to the host when 1086 entering dfuMANIFEST state. Host waits this timeout, before 1087 sending again an USB request to the device. 1088 1089- Journaling Flash filesystem support: 1090 CONFIG_JFFS2_NAND 1091 Define these for a default partition on a NAND device 1092 1093 CONFIG_SYS_JFFS2_FIRST_SECTOR, 1094 CONFIG_SYS_JFFS2_FIRST_BANK, CONFIG_SYS_JFFS2_NUM_BANKS 1095 Define these for a default partition on a NOR device 1096 1097- Keyboard Support: 1098 See Kconfig help for available keyboard drivers. 1099 1100 CONFIG_KEYBOARD 1101 1102 Define this to enable a custom keyboard support. 1103 This simply calls drv_keyboard_init() which must be 1104 defined in your board-specific files. This option is deprecated 1105 and is only used by novena. For new boards, use driver model 1106 instead. 1107 1108- Video support: 1109 CONFIG_FSL_DIU_FB 1110 Enable the Freescale DIU video driver. Reference boards for 1111 SOCs that have a DIU should define this macro to enable DIU 1112 support, and should also define these other macros: 1113 1114 CONFIG_SYS_DIU_ADDR 1115 CONFIG_VIDEO 1116 CONFIG_CFB_CONSOLE 1117 CONFIG_VIDEO_SW_CURSOR 1118 CONFIG_VGA_AS_SINGLE_DEVICE 1119 CONFIG_VIDEO_LOGO 1120 CONFIG_VIDEO_BMP_LOGO 1121 1122 The DIU driver will look for the 'video-mode' environment 1123 variable, and if defined, enable the DIU as a console during 1124 boot. See the documentation file doc/README.video for a 1125 description of this variable. 1126 1127- LCD Support: CONFIG_LCD 1128 1129 Define this to enable LCD support (for output to LCD 1130 display); also select one of the supported displays 1131 by defining one of these: 1132 1133 CONFIG_ATMEL_LCD: 1134 1135 HITACHI TX09D70VM1CCA, 3.5", 240x320. 1136 1137 CONFIG_NEC_NL6448AC33: 1138 1139 NEC NL6448AC33-18. Active, color, single scan. 1140 1141 CONFIG_NEC_NL6448BC20 1142 1143 NEC NL6448BC20-08. 6.5", 640x480. 1144 Active, color, single scan. 1145 1146 CONFIG_NEC_NL6448BC33_54 1147 1148 NEC NL6448BC33-54. 10.4", 640x480. 1149 Active, color, single scan. 1150 1151 CONFIG_SHARP_16x9 1152 1153 Sharp 320x240. Active, color, single scan. 1154 It isn't 16x9, and I am not sure what it is. 1155 1156 CONFIG_SHARP_LQ64D341 1157 1158 Sharp LQ64D341 display, 640x480. 1159 Active, color, single scan. 1160 1161 CONFIG_HLD1045 1162 1163 HLD1045 display, 640x480. 1164 Active, color, single scan. 1165 1166 CONFIG_OPTREX_BW 1167 1168 Optrex CBL50840-2 NF-FW 99 22 M5 1169 or 1170 Hitachi LMG6912RPFC-00T 1171 or 1172 Hitachi SP14Q002 1173 1174 320x240. Black & white. 1175 1176 CONFIG_LCD_ALIGNMENT 1177 1178 Normally the LCD is page-aligned (typically 4KB). If this is 1179 defined then the LCD will be aligned to this value instead. 1180 For ARM it is sometimes useful to use MMU_SECTION_SIZE 1181 here, since it is cheaper to change data cache settings on 1182 a per-section basis. 1183 1184 1185 CONFIG_LCD_ROTATION 1186 1187 Sometimes, for example if the display is mounted in portrait 1188 mode or even if it's mounted landscape but rotated by 180degree, 1189 we need to rotate our content of the display relative to the 1190 framebuffer, so that user can read the messages which are 1191 printed out. 1192 Once CONFIG_LCD_ROTATION is defined, the lcd_console will be 1193 initialized with a given rotation from "vl_rot" out of 1194 "vidinfo_t" which is provided by the board specific code. 1195 The value for vl_rot is coded as following (matching to 1196 fbcon=rotate:<n> linux-kernel commandline): 1197 0 = no rotation respectively 0 degree 1198 1 = 90 degree rotation 1199 2 = 180 degree rotation 1200 3 = 270 degree rotation 1201 1202 If CONFIG_LCD_ROTATION is not defined, the console will be 1203 initialized with 0degree rotation. 1204 1205 CONFIG_LCD_BMP_RLE8 1206 1207 Support drawing of RLE8-compressed bitmaps on the LCD. 1208 1209 CONFIG_I2C_EDID 1210 1211 Enables an 'i2c edid' command which can read EDID 1212 information over I2C from an attached LCD display. 1213 1214- MII/PHY support: 1215 CONFIG_PHY_CLOCK_FREQ (ppc4xx) 1216 1217 The clock frequency of the MII bus 1218 1219 CONFIG_PHY_RESET_DELAY 1220 1221 Some PHY like Intel LXT971A need extra delay after 1222 reset before any MII register access is possible. 1223 For such PHY, set this option to the usec delay 1224 required. (minimum 300usec for LXT971A) 1225 1226 CONFIG_PHY_CMD_DELAY (ppc4xx) 1227 1228 Some PHY like Intel LXT971A need extra delay after 1229 command issued before MII status register can be read 1230 1231- IP address: 1232 CONFIG_IPADDR 1233 1234 Define a default value for the IP address to use for 1235 the default Ethernet interface, in case this is not 1236 determined through e.g. bootp. 1237 (Environment variable "ipaddr") 1238 1239- Server IP address: 1240 CONFIG_SERVERIP 1241 1242 Defines a default value for the IP address of a TFTP 1243 server to contact when using the "tftboot" command. 1244 (Environment variable "serverip") 1245 1246 CONFIG_KEEP_SERVERADDR 1247 1248 Keeps the server's MAC address, in the env 'serveraddr' 1249 for passing to bootargs (like Linux's netconsole option) 1250 1251- Gateway IP address: 1252 CONFIG_GATEWAYIP 1253 1254 Defines a default value for the IP address of the 1255 default router where packets to other networks are 1256 sent to. 1257 (Environment variable "gatewayip") 1258 1259- Subnet mask: 1260 CONFIG_NETMASK 1261 1262 Defines a default value for the subnet mask (or 1263 routing prefix) which is used to determine if an IP 1264 address belongs to the local subnet or needs to be 1265 forwarded through a router. 1266 (Environment variable "netmask") 1267 1268- BOOTP Recovery Mode: 1269 CONFIG_BOOTP_RANDOM_DELAY 1270 1271 If you have many targets in a network that try to 1272 boot using BOOTP, you may want to avoid that all 1273 systems send out BOOTP requests at precisely the same 1274 moment (which would happen for instance at recovery 1275 from a power failure, when all systems will try to 1276 boot, thus flooding the BOOTP server. Defining 1277 CONFIG_BOOTP_RANDOM_DELAY causes a random delay to be 1278 inserted before sending out BOOTP requests. The 1279 following delays are inserted then: 1280 1281 1st BOOTP request: delay 0 ... 1 sec 1282 2nd BOOTP request: delay 0 ... 2 sec 1283 3rd BOOTP request: delay 0 ... 4 sec 1284 4th and following 1285 BOOTP requests: delay 0 ... 8 sec 1286 1287 CONFIG_BOOTP_ID_CACHE_SIZE 1288 1289 BOOTP packets are uniquely identified using a 32-bit ID. The 1290 server will copy the ID from client requests to responses and 1291 U-Boot will use this to determine if it is the destination of 1292 an incoming response. Some servers will check that addresses 1293 aren't in use before handing them out (usually using an ARP 1294 ping) and therefore take up to a few hundred milliseconds to 1295 respond. Network congestion may also influence the time it 1296 takes for a response to make it back to the client. If that 1297 time is too long, U-Boot will retransmit requests. In order 1298 to allow earlier responses to still be accepted after these 1299 retransmissions, U-Boot's BOOTP client keeps a small cache of 1300 IDs. The CONFIG_BOOTP_ID_CACHE_SIZE controls the size of this 1301 cache. The default is to keep IDs for up to four outstanding 1302 requests. Increasing this will allow U-Boot to accept offers 1303 from a BOOTP client in networks with unusually high latency. 1304 1305- DHCP Advanced Options: 1306 You can fine tune the DHCP functionality by defining 1307 CONFIG_BOOTP_* symbols: 1308 1309 CONFIG_BOOTP_NISDOMAIN 1310 CONFIG_BOOTP_BOOTFILESIZE 1311 CONFIG_BOOTP_NTPSERVER 1312 CONFIG_BOOTP_TIMEOFFSET 1313 CONFIG_BOOTP_VENDOREX 1314 CONFIG_BOOTP_MAY_FAIL 1315 1316 CONFIG_BOOTP_SERVERIP - TFTP server will be the serverip 1317 environment variable, not the BOOTP server. 1318 1319 CONFIG_BOOTP_MAY_FAIL - If the DHCP server is not found 1320 after the configured retry count, the call will fail 1321 instead of starting over. This can be used to fail over 1322 to Link-local IP address configuration if the DHCP server 1323 is not available. 1324 1325 CONFIG_BOOTP_DHCP_REQUEST_DELAY 1326 1327 A 32bit value in microseconds for a delay between 1328 receiving a "DHCP Offer" and sending the "DHCP Request". 1329 This fixes a problem with certain DHCP servers that don't 1330 respond 100% of the time to a "DHCP request". E.g. On an 1331 AT91RM9200 processor running at 180MHz, this delay needed 1332 to be *at least* 15,000 usec before a Windows Server 2003 1333 DHCP server would reply 100% of the time. I recommend at 1334 least 50,000 usec to be safe. The alternative is to hope 1335 that one of the retries will be successful but note that 1336 the DHCP timeout and retry process takes a longer than 1337 this delay. 1338 1339 - Link-local IP address negotiation: 1340 Negotiate with other link-local clients on the local network 1341 for an address that doesn't require explicit configuration. 1342 This is especially useful if a DHCP server cannot be guaranteed 1343 to exist in all environments that the device must operate. 1344 1345 See doc/README.link-local for more information. 1346 1347 - MAC address from environment variables 1348 1349 FDT_SEQ_MACADDR_FROM_ENV 1350 1351 Fix-up device tree with MAC addresses fetched sequentially from 1352 environment variables. This config work on assumption that 1353 non-usable ethernet node of device-tree are either not present 1354 or their status has been marked as "disabled". 1355 1356 - CDP Options: 1357 CONFIG_CDP_DEVICE_ID 1358 1359 The device id used in CDP trigger frames. 1360 1361 CONFIG_CDP_DEVICE_ID_PREFIX 1362 1363 A two character string which is prefixed to the MAC address 1364 of the device. 1365 1366 CONFIG_CDP_PORT_ID 1367 1368 A printf format string which contains the ascii name of 1369 the port. Normally is set to "eth%d" which sets 1370 eth0 for the first Ethernet, eth1 for the second etc. 1371 1372 CONFIG_CDP_CAPABILITIES 1373 1374 A 32bit integer which indicates the device capabilities; 1375 0x00000010 for a normal host which does not forwards. 1376 1377 CONFIG_CDP_VERSION 1378 1379 An ascii string containing the version of the software. 1380 1381 CONFIG_CDP_PLATFORM 1382 1383 An ascii string containing the name of the platform. 1384 1385 CONFIG_CDP_TRIGGER 1386 1387 A 32bit integer sent on the trigger. 1388 1389 CONFIG_CDP_POWER_CONSUMPTION 1390 1391 A 16bit integer containing the power consumption of the 1392 device in .1 of milliwatts. 1393 1394 CONFIG_CDP_APPLIANCE_VLAN_TYPE 1395 1396 A byte containing the id of the VLAN. 1397 1398- Status LED: CONFIG_LED_STATUS 1399 1400 Several configurations allow to display the current 1401 status using a LED. For instance, the LED will blink 1402 fast while running U-Boot code, stop blinking as 1403 soon as a reply to a BOOTP request was received, and 1404 start blinking slow once the Linux kernel is running 1405 (supported by a status LED driver in the Linux 1406 kernel). Defining CONFIG_LED_STATUS enables this 1407 feature in U-Boot. 1408 1409 Additional options: 1410 1411 CONFIG_LED_STATUS_GPIO 1412 The status LED can be connected to a GPIO pin. 1413 In such cases, the gpio_led driver can be used as a 1414 status LED backend implementation. Define CONFIG_LED_STATUS_GPIO 1415 to include the gpio_led driver in the U-Boot binary. 1416 1417 CONFIG_GPIO_LED_INVERTED_TABLE 1418 Some GPIO connected LEDs may have inverted polarity in which 1419 case the GPIO high value corresponds to LED off state and 1420 GPIO low value corresponds to LED on state. 1421 In such cases CONFIG_GPIO_LED_INVERTED_TABLE may be defined 1422 with a list of GPIO LEDs that have inverted polarity. 1423 1424- I2C Support: 1425 CONFIG_SYS_NUM_I2C_BUSES 1426 Hold the number of i2c buses you want to use. 1427 1428 CONFIG_SYS_I2C_DIRECT_BUS 1429 define this, if you don't use i2c muxes on your hardware. 1430 if CONFIG_SYS_I2C_MAX_HOPS is not defined or == 0 you can 1431 omit this define. 1432 1433 CONFIG_SYS_I2C_MAX_HOPS 1434 define how many muxes are maximal consecutively connected 1435 on one i2c bus. If you not use i2c muxes, omit this 1436 define. 1437 1438 CONFIG_SYS_I2C_BUSES 1439 hold a list of buses you want to use, only used if 1440 CONFIG_SYS_I2C_DIRECT_BUS is not defined, for example 1441 a board with CONFIG_SYS_I2C_MAX_HOPS = 1 and 1442 CONFIG_SYS_NUM_I2C_BUSES = 9: 1443 1444 CONFIG_SYS_I2C_BUSES {{0, {I2C_NULL_HOP}}, \ 1445 {0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \ 1446 {0, {{I2C_MUX_PCA9547, 0x70, 2}}}, \ 1447 {0, {{I2C_MUX_PCA9547, 0x70, 3}}}, \ 1448 {0, {{I2C_MUX_PCA9547, 0x70, 4}}}, \ 1449 {0, {{I2C_MUX_PCA9547, 0x70, 5}}}, \ 1450 {1, {I2C_NULL_HOP}}, \ 1451 {1, {{I2C_MUX_PCA9544, 0x72, 1}}}, \ 1452 {1, {{I2C_MUX_PCA9544, 0x72, 2}}}, \ 1453 } 1454 1455 which defines 1456 bus 0 on adapter 0 without a mux 1457 bus 1 on adapter 0 with a PCA9547 on address 0x70 port 1 1458 bus 2 on adapter 0 with a PCA9547 on address 0x70 port 2 1459 bus 3 on adapter 0 with a PCA9547 on address 0x70 port 3 1460 bus 4 on adapter 0 with a PCA9547 on address 0x70 port 4 1461 bus 5 on adapter 0 with a PCA9547 on address 0x70 port 5 1462 bus 6 on adapter 1 without a mux 1463 bus 7 on adapter 1 with a PCA9544 on address 0x72 port 1 1464 bus 8 on adapter 1 with a PCA9544 on address 0x72 port 2 1465 1466 If you do not have i2c muxes on your board, omit this define. 1467 1468- Legacy I2C Support: 1469 If you use the software i2c interface (CONFIG_SYS_I2C_SOFT) 1470 then the following macros need to be defined (examples are 1471 from include/configs/lwmon.h): 1472 1473 I2C_INIT 1474 1475 (Optional). Any commands necessary to enable the I2C 1476 controller or configure ports. 1477 1478 eg: #define I2C_INIT (immr->im_cpm.cp_pbdir |= PB_SCL) 1479 1480 I2C_ACTIVE 1481 1482 The code necessary to make the I2C data line active 1483 (driven). If the data line is open collector, this 1484 define can be null. 1485 1486 eg: #define I2C_ACTIVE (immr->im_cpm.cp_pbdir |= PB_SDA) 1487 1488 I2C_TRISTATE 1489 1490 The code necessary to make the I2C data line tri-stated 1491 (inactive). If the data line is open collector, this 1492 define can be null. 1493 1494 eg: #define I2C_TRISTATE (immr->im_cpm.cp_pbdir &= ~PB_SDA) 1495 1496 I2C_READ 1497 1498 Code that returns true if the I2C data line is high, 1499 false if it is low. 1500 1501 eg: #define I2C_READ ((immr->im_cpm.cp_pbdat & PB_SDA) != 0) 1502 1503 I2C_SDA(bit) 1504 1505 If <bit> is true, sets the I2C data line high. If it 1506 is false, it clears it (low). 1507 1508 eg: #define I2C_SDA(bit) \ 1509 if(bit) immr->im_cpm.cp_pbdat |= PB_SDA; \ 1510 else immr->im_cpm.cp_pbdat &= ~PB_SDA 1511 1512 I2C_SCL(bit) 1513 1514 If <bit> is true, sets the I2C clock line high. If it 1515 is false, it clears it (low). 1516 1517 eg: #define I2C_SCL(bit) \ 1518 if(bit) immr->im_cpm.cp_pbdat |= PB_SCL; \ 1519 else immr->im_cpm.cp_pbdat &= ~PB_SCL 1520 1521 I2C_DELAY 1522 1523 This delay is invoked four times per clock cycle so this 1524 controls the rate of data transfer. The data rate thus 1525 is 1 / (I2C_DELAY * 4). Often defined to be something 1526 like: 1527 1528 #define I2C_DELAY udelay(2) 1529 1530 CONFIG_SOFT_I2C_GPIO_SCL / CONFIG_SOFT_I2C_GPIO_SDA 1531 1532 If your arch supports the generic GPIO framework (asm/gpio.h), 1533 then you may alternatively define the two GPIOs that are to be 1534 used as SCL / SDA. Any of the previous I2C_xxx macros will 1535 have GPIO-based defaults assigned to them as appropriate. 1536 1537 You should define these to the GPIO value as given directly to 1538 the generic GPIO functions. 1539 1540 CONFIG_SYS_I2C_INIT_BOARD 1541 1542 When a board is reset during an i2c bus transfer 1543 chips might think that the current transfer is still 1544 in progress. On some boards it is possible to access 1545 the i2c SCLK line directly, either by using the 1546 processor pin as a GPIO or by having a second pin 1547 connected to the bus. If this option is defined a 1548 custom i2c_init_board() routine in boards/xxx/board.c 1549 is run early in the boot sequence. 1550 1551 CONFIG_I2C_MULTI_BUS 1552 1553 This option allows the use of multiple I2C buses, each of which 1554 must have a controller. At any point in time, only one bus is 1555 active. To switch to a different bus, use the 'i2c dev' command. 1556 Note that bus numbering is zero-based. 1557 1558 CONFIG_SYS_I2C_NOPROBES 1559 1560 This option specifies a list of I2C devices that will be skipped 1561 when the 'i2c probe' command is issued. If CONFIG_I2C_MULTI_BUS 1562 is set, specify a list of bus-device pairs. Otherwise, specify 1563 a 1D array of device addresses 1564 1565 e.g. 1566 #undef CONFIG_I2C_MULTI_BUS 1567 #define CONFIG_SYS_I2C_NOPROBES {0x50,0x68} 1568 1569 will skip addresses 0x50 and 0x68 on a board with one I2C bus 1570 1571 #define CONFIG_I2C_MULTI_BUS 1572 #define CONFIG_SYS_I2C_NOPROBES {{0,0x50},{0,0x68},{1,0x54}} 1573 1574 will skip addresses 0x50 and 0x68 on bus 0 and address 0x54 on bus 1 1575 1576 CONFIG_SYS_SPD_BUS_NUM 1577 1578 If defined, then this indicates the I2C bus number for DDR SPD. 1579 If not defined, then U-Boot assumes that SPD is on I2C bus 0. 1580 1581 CONFIG_SYS_RTC_BUS_NUM 1582 1583 If defined, then this indicates the I2C bus number for the RTC. 1584 If not defined, then U-Boot assumes that RTC is on I2C bus 0. 1585 1586 CONFIG_SOFT_I2C_READ_REPEATED_START 1587 1588 defining this will force the i2c_read() function in 1589 the soft_i2c driver to perform an I2C repeated start 1590 between writing the address pointer and reading the 1591 data. If this define is omitted the default behaviour 1592 of doing a stop-start sequence will be used. Most I2C 1593 devices can use either method, but some require one or 1594 the other. 1595 1596- SPI Support: CONFIG_SPI 1597 1598 Enables SPI driver (so far only tested with 1599 SPI EEPROM, also an instance works with Crystal A/D and 1600 D/As on the SACSng board) 1601 1602 CONFIG_SOFT_SPI 1603 1604 Enables a software (bit-bang) SPI driver rather than 1605 using hardware support. This is a general purpose 1606 driver that only requires three general I/O port pins 1607 (two outputs, one input) to function. If this is 1608 defined, the board configuration must define several 1609 SPI configuration items (port pins to use, etc). For 1610 an example, see include/configs/sacsng.h. 1611 1612 CONFIG_SYS_SPI_MXC_WAIT 1613 Timeout for waiting until spi transfer completed. 1614 default: (CONFIG_SYS_HZ/100) /* 10 ms */ 1615 1616- FPGA Support: CONFIG_FPGA 1617 1618 Enables FPGA subsystem. 1619 1620 CONFIG_FPGA_<vendor> 1621 1622 Enables support for specific chip vendors. 1623 (ALTERA, XILINX) 1624 1625 CONFIG_FPGA_<family> 1626 1627 Enables support for FPGA family. 1628 (SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX) 1629 1630 CONFIG_FPGA_COUNT 1631 1632 Specify the number of FPGA devices to support. 1633 1634 CONFIG_SYS_FPGA_PROG_FEEDBACK 1635 1636 Enable printing of hash marks during FPGA configuration. 1637 1638 CONFIG_SYS_FPGA_CHECK_BUSY 1639 1640 Enable checks on FPGA configuration interface busy 1641 status by the configuration function. This option 1642 will require a board or device specific function to 1643 be written. 1644 1645 CONFIG_FPGA_DELAY 1646 1647 If defined, a function that provides delays in the FPGA 1648 configuration driver. 1649 1650 CONFIG_SYS_FPGA_CHECK_CTRLC 1651 Allow Control-C to interrupt FPGA configuration 1652 1653 CONFIG_SYS_FPGA_CHECK_ERROR 1654 1655 Check for configuration errors during FPGA bitfile 1656 loading. For example, abort during Virtex II 1657 configuration if the INIT_B line goes low (which 1658 indicated a CRC error). 1659 1660 CONFIG_SYS_FPGA_WAIT_INIT 1661 1662 Maximum time to wait for the INIT_B line to de-assert 1663 after PROB_B has been de-asserted during a Virtex II 1664 FPGA configuration sequence. The default time is 500 1665 ms. 1666 1667 CONFIG_SYS_FPGA_WAIT_BUSY 1668 1669 Maximum time to wait for BUSY to de-assert during 1670 Virtex II FPGA configuration. The default is 5 ms. 1671 1672 CONFIG_SYS_FPGA_WAIT_CONFIG 1673 1674 Time to wait after FPGA configuration. The default is 1675 200 ms. 1676 1677- Configuration Management: 1678 1679 CONFIG_IDENT_STRING 1680 1681 If defined, this string will be added to the U-Boot 1682 version information (U_BOOT_VERSION) 1683 1684- Vendor Parameter Protection: 1685 1686 U-Boot considers the values of the environment 1687 variables "serial#" (Board Serial Number) and 1688 "ethaddr" (Ethernet Address) to be parameters that 1689 are set once by the board vendor / manufacturer, and 1690 protects these variables from casual modification by 1691 the user. Once set, these variables are read-only, 1692 and write or delete attempts are rejected. You can 1693 change this behaviour: 1694 1695 If CONFIG_ENV_OVERWRITE is #defined in your config 1696 file, the write protection for vendor parameters is 1697 completely disabled. Anybody can change or delete 1698 these parameters. 1699 1700 Alternatively, if you define _both_ an ethaddr in the 1701 default env _and_ CONFIG_OVERWRITE_ETHADDR_ONCE, a default 1702 Ethernet address is installed in the environment, 1703 which can be changed exactly ONCE by the user. [The 1704 serial# is unaffected by this, i. e. it remains 1705 read-only.] 1706 1707 The same can be accomplished in a more flexible way 1708 for any variable by configuring the type of access 1709 to allow for those variables in the ".flags" variable 1710 or define CONFIG_ENV_FLAGS_LIST_STATIC. 1711 1712- Protected RAM: 1713 CONFIG_PRAM 1714 1715 Define this variable to enable the reservation of 1716 "protected RAM", i. e. RAM which is not overwritten 1717 by U-Boot. Define CONFIG_PRAM to hold the number of 1718 kB you want to reserve for pRAM. You can overwrite 1719 this default value by defining an environment 1720 variable "pram" to the number of kB you want to 1721 reserve. Note that the board info structure will 1722 still show the full amount of RAM. If pRAM is 1723 reserved, a new environment variable "mem" will 1724 automatically be defined to hold the amount of 1725 remaining RAM in a form that can be passed as boot 1726 argument to Linux, for instance like that: 1727 1728 setenv bootargs ... mem=\${mem} 1729 saveenv 1730 1731 This way you can tell Linux not to use this memory, 1732 either, which results in a memory region that will 1733 not be affected by reboots. 1734 1735 *WARNING* If your board configuration uses automatic 1736 detection of the RAM size, you must make sure that 1737 this memory test is non-destructive. So far, the 1738 following board configurations are known to be 1739 "pRAM-clean": 1740 1741 IVMS8, IVML24, SPD8xx, 1742 HERMES, IP860, RPXlite, LWMON, 1743 FLAGADM 1744 1745- Access to physical memory region (> 4GB) 1746 Some basic support is provided for operations on memory not 1747 normally accessible to U-Boot - e.g. some architectures 1748 support access to more than 4GB of memory on 32-bit 1749 machines using physical address extension or similar. 1750 Define CONFIG_PHYSMEM to access this basic support, which 1751 currently only supports clearing the memory. 1752 1753- Error Recovery: 1754 CONFIG_NET_RETRY_COUNT 1755 1756 This variable defines the number of retries for 1757 network operations like ARP, RARP, TFTP, or BOOTP 1758 before giving up the operation. If not defined, a 1759 default value of 5 is used. 1760 1761 CONFIG_ARP_TIMEOUT 1762 1763 Timeout waiting for an ARP reply in milliseconds. 1764 1765 CONFIG_NFS_TIMEOUT 1766 1767 Timeout in milliseconds used in NFS protocol. 1768 If you encounter "ERROR: Cannot umount" in nfs command, 1769 try longer timeout such as 1770 #define CONFIG_NFS_TIMEOUT 10000UL 1771 1772 Note: 1773 1774 In the current implementation, the local variables 1775 space and global environment variables space are 1776 separated. Local variables are those you define by 1777 simply typing `name=value'. To access a local 1778 variable later on, you have write `$name' or 1779 `${name}'; to execute the contents of a variable 1780 directly type `$name' at the command prompt. 1781 1782 Global environment variables are those you use 1783 setenv/printenv to work with. To run a command stored 1784 in such a variable, you need to use the run command, 1785 and you must not use the '$' sign to access them. 1786 1787 To store commands and special characters in a 1788 variable, please use double quotation marks 1789 surrounding the whole text of the variable, instead 1790 of the backslashes before semicolons and special 1791 symbols. 1792 1793- Command Line Editing and History: 1794 CONFIG_CMDLINE_PS_SUPPORT 1795 1796 Enable support for changing the command prompt string 1797 at run-time. Only static string is supported so far. 1798 The string is obtained from environment variables PS1 1799 and PS2. 1800 1801- Default Environment: 1802 CONFIG_EXTRA_ENV_SETTINGS 1803 1804 Define this to contain any number of null terminated 1805 strings (variable = value pairs) that will be part of 1806 the default environment compiled into the boot image. 1807 1808 For example, place something like this in your 1809 board's config file: 1810 1811 #define CONFIG_EXTRA_ENV_SETTINGS \ 1812 "myvar1=value1\0" \ 1813 "myvar2=value2\0" 1814 1815 Warning: This method is based on knowledge about the 1816 internal format how the environment is stored by the 1817 U-Boot code. This is NOT an official, exported 1818 interface! Although it is unlikely that this format 1819 will change soon, there is no guarantee either. 1820 You better know what you are doing here. 1821 1822 Note: overly (ab)use of the default environment is 1823 discouraged. Make sure to check other ways to preset 1824 the environment like the "source" command or the 1825 boot command first. 1826 1827 CONFIG_DELAY_ENVIRONMENT 1828 1829 Normally the environment is loaded when the board is 1830 initialised so that it is available to U-Boot. This inhibits 1831 that so that the environment is not available until 1832 explicitly loaded later by U-Boot code. With CONFIG_OF_CONTROL 1833 this is instead controlled by the value of 1834 /config/load-environment. 1835 1836- TFTP Fixed UDP Port: 1837 CONFIG_TFTP_PORT 1838 1839 If this is defined, the environment variable tftpsrcp 1840 is used to supply the TFTP UDP source port value. 1841 If tftpsrcp isn't defined, the normal pseudo-random port 1842 number generator is used. 1843 1844 Also, the environment variable tftpdstp is used to supply 1845 the TFTP UDP destination port value. If tftpdstp isn't 1846 defined, the normal port 69 is used. 1847 1848 The purpose for tftpsrcp is to allow a TFTP server to 1849 blindly start the TFTP transfer using the pre-configured 1850 target IP address and UDP port. This has the effect of 1851 "punching through" the (Windows XP) firewall, allowing 1852 the remainder of the TFTP transfer to proceed normally. 1853 A better solution is to properly configure the firewall, 1854 but sometimes that is not allowed. 1855 1856 CONFIG_STANDALONE_LOAD_ADDR 1857 1858 This option defines a board specific value for the 1859 address where standalone program gets loaded, thus 1860 overwriting the architecture dependent default 1861 settings. 1862 1863- Frame Buffer Address: 1864 CONFIG_FB_ADDR 1865 1866 Define CONFIG_FB_ADDR if you want to use specific 1867 address for frame buffer. This is typically the case 1868 when using a graphics controller has separate video 1869 memory. U-Boot will then place the frame buffer at 1870 the given address instead of dynamically reserving it 1871 in system RAM by calling lcd_setmem(), which grabs 1872 the memory for the frame buffer depending on the 1873 configured panel size. 1874 1875 Please see board_init_f function. 1876 1877- Automatic software updates via TFTP server 1878 CONFIG_UPDATE_TFTP 1879 CONFIG_UPDATE_TFTP_CNT_MAX 1880 CONFIG_UPDATE_TFTP_MSEC_MAX 1881 1882 These options enable and control the auto-update feature; 1883 for a more detailed description refer to doc/README.update. 1884 1885- MTD Support (mtdparts command, UBI support) 1886 CONFIG_MTD_UBI_WL_THRESHOLD 1887 This parameter defines the maximum difference between the highest 1888 erase counter value and the lowest erase counter value of eraseblocks 1889 of UBI devices. When this threshold is exceeded, UBI starts performing 1890 wear leveling by means of moving data from eraseblock with low erase 1891 counter to eraseblocks with high erase counter. 1892 1893 The default value should be OK for SLC NAND flashes, NOR flashes and 1894 other flashes which have eraseblock life-cycle 100000 or more. 1895 However, in case of MLC NAND flashes which typically have eraseblock 1896 life-cycle less than 10000, the threshold should be lessened (e.g., 1897 to 128 or 256, although it does not have to be power of 2). 1898 1899 default: 4096 1900 1901 CONFIG_MTD_UBI_BEB_LIMIT 1902 This option specifies the maximum bad physical eraseblocks UBI 1903 expects on the MTD device (per 1024 eraseblocks). If the 1904 underlying flash does not admit of bad eraseblocks (e.g. NOR 1905 flash), this value is ignored. 1906 1907 NAND datasheets often specify the minimum and maximum NVM 1908 (Number of Valid Blocks) for the flashes' endurance lifetime. 1909 The maximum expected bad eraseblocks per 1024 eraseblocks 1910 then can be calculated as "1024 * (1 - MinNVB / MaxNVB)", 1911 which gives 20 for most NANDs (MaxNVB is basically the total 1912 count of eraseblocks on the chip). 1913 1914 To put it differently, if this value is 20, UBI will try to 1915 reserve about 1.9% of physical eraseblocks for bad blocks 1916 handling. And that will be 1.9% of eraseblocks on the entire 1917 NAND chip, not just the MTD partition UBI attaches. This means 1918 that if you have, say, a NAND flash chip admits maximum 40 bad 1919 eraseblocks, and it is split on two MTD partitions of the same 1920 size, UBI will reserve 40 eraseblocks when attaching a 1921 partition. 1922 1923 default: 20 1924 1925 CONFIG_MTD_UBI_FASTMAP 1926 Fastmap is a mechanism which allows attaching an UBI device 1927 in nearly constant time. Instead of scanning the whole MTD device it 1928 only has to locate a checkpoint (called fastmap) on the device. 1929 The on-flash fastmap contains all information needed to attach 1930 the device. Using fastmap makes only sense on large devices where 1931 attaching by scanning takes long. UBI will not automatically install 1932 a fastmap on old images, but you can set the UBI parameter 1933 CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT to 1 if you want so. Please note 1934 that fastmap-enabled images are still usable with UBI implementations 1935 without fastmap support. On typical flash devices the whole fastmap 1936 fits into one PEB. UBI will reserve PEBs to hold two fastmaps. 1937 1938 CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT 1939 Set this parameter to enable fastmap automatically on images 1940 without a fastmap. 1941 default: 0 1942 1943 CONFIG_MTD_UBI_FM_DEBUG 1944 Enable UBI fastmap debug 1945 default: 0 1946 1947- SPL framework 1948 CONFIG_SPL 1949 Enable building of SPL globally. 1950 1951 CONFIG_SPL_LDSCRIPT 1952 LDSCRIPT for linking the SPL binary. 1953 1954 CONFIG_SPL_MAX_FOOTPRINT 1955 Maximum size in memory allocated to the SPL, BSS included. 1956 When defined, the linker checks that the actual memory 1957 used by SPL from _start to __bss_end does not exceed it. 1958 CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE 1959 must not be both defined at the same time. 1960 1961 CONFIG_SPL_MAX_SIZE 1962 Maximum size of the SPL image (text, data, rodata, and 1963 linker lists sections), BSS excluded. 1964 When defined, the linker checks that the actual size does 1965 not exceed it. 1966 1967 CONFIG_SPL_RELOC_TEXT_BASE 1968 Address to relocate to. If unspecified, this is equal to 1969 CONFIG_SPL_TEXT_BASE (i.e. no relocation is done). 1970 1971 CONFIG_SPL_BSS_START_ADDR 1972 Link address for the BSS within the SPL binary. 1973 1974 CONFIG_SPL_BSS_MAX_SIZE 1975 Maximum size in memory allocated to the SPL BSS. 1976 When defined, the linker checks that the actual memory used 1977 by SPL from __bss_start to __bss_end does not exceed it. 1978 CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE 1979 must not be both defined at the same time. 1980 1981 CONFIG_SPL_STACK 1982 Adress of the start of the stack SPL will use 1983 1984 CONFIG_SPL_PANIC_ON_RAW_IMAGE 1985 When defined, SPL will panic() if the image it has 1986 loaded does not have a signature. 1987 Defining this is useful when code which loads images 1988 in SPL cannot guarantee that absolutely all read errors 1989 will be caught. 1990 An example is the LPC32XX MLC NAND driver, which will 1991 consider that a completely unreadable NAND block is bad, 1992 and thus should be skipped silently. 1993 1994 CONFIG_SPL_RELOC_STACK 1995 Adress of the start of the stack SPL will use after 1996 relocation. If unspecified, this is equal to 1997 CONFIG_SPL_STACK. 1998 1999 CONFIG_SYS_SPL_MALLOC_START 2000 Starting address of the malloc pool used in SPL. 2001 When this option is set the full malloc is used in SPL and 2002 it is set up by spl_init() and before that, the simple malloc() 2003 can be used if CONFIG_SYS_MALLOC_F is defined. 2004 2005 CONFIG_SYS_SPL_MALLOC_SIZE 2006 The size of the malloc pool used in SPL. 2007 2008 CONFIG_SPL_OS_BOOT 2009 Enable booting directly to an OS from SPL. 2010 See also: doc/README.falcon 2011 2012 CONFIG_SPL_DISPLAY_PRINT 2013 For ARM, enable an optional function to print more information 2014 about the running system. 2015 2016 CONFIG_SPL_INIT_MINIMAL 2017 Arch init code should be built for a very small image 2018 2019 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 2020 Partition on the MMC to load U-Boot from when the MMC is being 2021 used in raw mode 2022 2023 CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 2024 Sector to load kernel uImage from when MMC is being 2025 used in raw mode (for Falcon mode) 2026 2027 CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, 2028 CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 2029 Sector and number of sectors to load kernel argument 2030 parameters from when MMC is being used in raw mode 2031 (for falcon mode) 2032 2033 CONFIG_SPL_FS_LOAD_PAYLOAD_NAME 2034 Filename to read to load U-Boot when reading from filesystem 2035 2036 CONFIG_SPL_FS_LOAD_KERNEL_NAME 2037 Filename to read to load kernel uImage when reading 2038 from filesystem (for Falcon mode) 2039 2040 CONFIG_SPL_FS_LOAD_ARGS_NAME 2041 Filename to read to load kernel argument parameters 2042 when reading from filesystem (for Falcon mode) 2043 2044 CONFIG_SPL_MPC83XX_WAIT_FOR_NAND 2045 Set this for NAND SPL on PPC mpc83xx targets, so that 2046 start.S waits for the rest of the SPL to load before 2047 continuing (the hardware starts execution after just 2048 loading the first page rather than the full 4K). 2049 2050 CONFIG_SPL_SKIP_RELOCATE 2051 Avoid SPL relocation 2052 2053 CONFIG_SPL_NAND_IDENT 2054 SPL uses the chip ID list to identify the NAND flash. 2055 Requires CONFIG_SPL_NAND_BASE. 2056 2057 CONFIG_SPL_UBI 2058 Support for a lightweight UBI (fastmap) scanner and 2059 loader 2060 2061 CONFIG_SPL_NAND_RAW_ONLY 2062 Support to boot only raw u-boot.bin images. Use this only 2063 if you need to save space. 2064 2065 CONFIG_SPL_COMMON_INIT_DDR 2066 Set for common ddr init with serial presence detect in 2067 SPL binary. 2068 2069 CONFIG_SYS_NAND_5_ADDR_CYCLE, CONFIG_SYS_NAND_PAGE_COUNT, 2070 CONFIG_SYS_NAND_PAGE_SIZE, CONFIG_SYS_NAND_OOBSIZE, 2071 CONFIG_SYS_NAND_BLOCK_SIZE, CONFIG_SYS_NAND_BAD_BLOCK_POS, 2072 CONFIG_SYS_NAND_ECCPOS, CONFIG_SYS_NAND_ECCSIZE, 2073 CONFIG_SYS_NAND_ECCBYTES 2074 Defines the size and behavior of the NAND that SPL uses 2075 to read U-Boot 2076 2077 CONFIG_SYS_NAND_U_BOOT_DST 2078 Location in memory to load U-Boot to 2079 2080 CONFIG_SYS_NAND_U_BOOT_SIZE 2081 Size of image to load 2082 2083 CONFIG_SYS_NAND_U_BOOT_START 2084 Entry point in loaded image to jump to 2085 2086 CONFIG_SYS_NAND_HW_ECC_OOBFIRST 2087 Define this if you need to first read the OOB and then the 2088 data. This is used, for example, on davinci platforms. 2089 2090 CONFIG_SPL_RAM_DEVICE 2091 Support for running image already present in ram, in SPL binary 2092 2093 CONFIG_SPL_PAD_TO 2094 Image offset to which the SPL should be padded before appending 2095 the SPL payload. By default, this is defined as 2096 CONFIG_SPL_MAX_SIZE, or 0 if CONFIG_SPL_MAX_SIZE is undefined. 2097 CONFIG_SPL_PAD_TO must be either 0, meaning to append the SPL 2098 payload without any padding, or >= CONFIG_SPL_MAX_SIZE. 2099 2100 CONFIG_SPL_TARGET 2101 Final target image containing SPL and payload. Some SPLs 2102 use an arch-specific makefile fragment instead, for 2103 example if more than one image needs to be produced. 2104 2105 CONFIG_SPL_FIT_PRINT 2106 Printing information about a FIT image adds quite a bit of 2107 code to SPL. So this is normally disabled in SPL. Use this 2108 option to re-enable it. This will affect the output of the 2109 bootm command when booting a FIT image. 2110 2111- TPL framework 2112 CONFIG_TPL 2113 Enable building of TPL globally. 2114 2115 CONFIG_TPL_PAD_TO 2116 Image offset to which the TPL should be padded before appending 2117 the TPL payload. By default, this is defined as 2118 CONFIG_SPL_MAX_SIZE, or 0 if CONFIG_SPL_MAX_SIZE is undefined. 2119 CONFIG_SPL_PAD_TO must be either 0, meaning to append the SPL 2120 payload without any padding, or >= CONFIG_SPL_MAX_SIZE. 2121 2122- Interrupt support (PPC): 2123 2124 There are common interrupt_init() and timer_interrupt() 2125 for all PPC archs. interrupt_init() calls interrupt_init_cpu() 2126 for CPU specific initialization. interrupt_init_cpu() 2127 should set decrementer_count to appropriate value. If 2128 CPU resets decrementer automatically after interrupt 2129 (ppc4xx) it should set decrementer_count to zero. 2130 timer_interrupt() calls timer_interrupt_cpu() for CPU 2131 specific handling. If board has watchdog / status_led 2132 / other_activity_monitor it works automatically from 2133 general timer_interrupt(). 2134 2135 2136Board initialization settings: 2137------------------------------ 2138 2139During Initialization u-boot calls a number of board specific functions 2140to allow the preparation of board specific prerequisites, e.g. pin setup 2141before drivers are initialized. To enable these callbacks the 2142following configuration macros have to be defined. Currently this is 2143architecture specific, so please check arch/your_architecture/lib/board.c 2144typically in board_init_f() and board_init_r(). 2145 2146- CONFIG_BOARD_EARLY_INIT_F: Call board_early_init_f() 2147- CONFIG_BOARD_EARLY_INIT_R: Call board_early_init_r() 2148- CONFIG_BOARD_LATE_INIT: Call board_late_init() 2149- CONFIG_BOARD_POSTCLK_INIT: Call board_postclk_init() 2150 2151Configuration Settings: 2152----------------------- 2153 2154- MEM_SUPPORT_64BIT_DATA: Defined automatically if compiled as 64-bit. 2155 Optionally it can be defined to support 64-bit memory commands. 2156 2157- CONFIG_SYS_LONGHELP: Defined when you want long help messages included; 2158 undefine this when you're short of memory. 2159 2160- CONFIG_SYS_HELP_CMD_WIDTH: Defined when you want to override the default 2161 width of the commands listed in the 'help' command output. 2162 2163- CONFIG_SYS_PROMPT: This is what U-Boot prints on the console to 2164 prompt for user input. 2165 2166- CONFIG_SYS_CBSIZE: Buffer size for input from the Console 2167 2168- CONFIG_SYS_PBSIZE: Buffer size for Console output 2169 2170- CONFIG_SYS_MAXARGS: max. Number of arguments accepted for monitor commands 2171 2172- CONFIG_SYS_BARGSIZE: Buffer size for Boot Arguments which are passed to 2173 the application (usually a Linux kernel) when it is 2174 booted 2175 2176- CONFIG_SYS_BAUDRATE_TABLE: 2177 List of legal baudrate settings for this board. 2178 2179- CONFIG_SYS_MEM_RESERVE_SECURE 2180 Only implemented for ARMv8 for now. 2181 If defined, the size of CONFIG_SYS_MEM_RESERVE_SECURE memory 2182 is substracted from total RAM and won't be reported to OS. 2183 This memory can be used as secure memory. A variable 2184 gd->arch.secure_ram is used to track the location. In systems 2185 the RAM base is not zero, or RAM is divided into banks, 2186 this variable needs to be recalcuated to get the address. 2187 2188- CONFIG_SYS_MEM_TOP_HIDE: 2189 If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config header, 2190 this specified memory area will get subtracted from the top 2191 (end) of RAM and won't get "touched" at all by U-Boot. By 2192 fixing up gd->ram_size the Linux kernel should gets passed 2193 the now "corrected" memory size and won't touch it either. 2194 This should work for arch/ppc and arch/powerpc. Only Linux 2195 board ports in arch/powerpc with bootwrapper support that 2196 recalculate the memory size from the SDRAM controller setup 2197 will have to get fixed in Linux additionally. 2198 2199 This option can be used as a workaround for the 440EPx/GRx 2200 CHIP 11 errata where the last 256 bytes in SDRAM shouldn't 2201 be touched. 2202 2203 WARNING: Please make sure that this value is a multiple of 2204 the Linux page size (normally 4k). If this is not the case, 2205 then the end address of the Linux memory will be located at a 2206 non page size aligned address and this could cause major 2207 problems. 2208 2209- CONFIG_SYS_LOADS_BAUD_CHANGE: 2210 Enable temporary baudrate change while serial download 2211 2212- CONFIG_SYS_SDRAM_BASE: 2213 Physical start address of SDRAM. _Must_ be 0 here. 2214 2215- CONFIG_SYS_FLASH_BASE: 2216 Physical start address of Flash memory. 2217 2218- CONFIG_SYS_MONITOR_BASE: 2219 Physical start address of boot monitor code (set by 2220 make config files to be same as the text base address 2221 (CONFIG_SYS_TEXT_BASE) used when linking) - same as 2222 CONFIG_SYS_FLASH_BASE when booting from flash. 2223 2224- CONFIG_SYS_MONITOR_LEN: 2225 Size of memory reserved for monitor code, used to 2226 determine _at_compile_time_ (!) if the environment is 2227 embedded within the U-Boot image, or in a separate 2228 flash sector. 2229 2230- CONFIG_SYS_MALLOC_LEN: 2231 Size of DRAM reserved for malloc() use. 2232 2233- CONFIG_SYS_MALLOC_F_LEN 2234 Size of the malloc() pool for use before relocation. If 2235 this is defined, then a very simple malloc() implementation 2236 will become available before relocation. The address is just 2237 below the global data, and the stack is moved down to make 2238 space. 2239 2240 This feature allocates regions with increasing addresses 2241 within the region. calloc() is supported, but realloc() 2242 is not available. free() is supported but does nothing. 2243 The memory will be freed (or in fact just forgotten) when 2244 U-Boot relocates itself. 2245 2246- CONFIG_SYS_MALLOC_SIMPLE 2247 Provides a simple and small malloc() and calloc() for those 2248 boards which do not use the full malloc in SPL (which is 2249 enabled with CONFIG_SYS_SPL_MALLOC_START). 2250 2251- CONFIG_SYS_NONCACHED_MEMORY: 2252 Size of non-cached memory area. This area of memory will be 2253 typically located right below the malloc() area and mapped 2254 uncached in the MMU. This is useful for drivers that would 2255 otherwise require a lot of explicit cache maintenance. For 2256 some drivers it's also impossible to properly maintain the 2257 cache. For example if the regions that need to be flushed 2258 are not a multiple of the cache-line size, *and* padding 2259 cannot be allocated between the regions to align them (i.e. 2260 if the HW requires a contiguous array of regions, and the 2261 size of each region is not cache-aligned), then a flush of 2262 one region may result in overwriting data that hardware has 2263 written to another region in the same cache-line. This can 2264 happen for example in network drivers where descriptors for 2265 buffers are typically smaller than the CPU cache-line (e.g. 2266 16 bytes vs. 32 or 64 bytes). 2267 2268 Non-cached memory is only supported on 32-bit ARM at present. 2269 2270- CONFIG_SYS_BOOTM_LEN: 2271 Normally compressed uImages are limited to an 2272 uncompressed size of 8 MBytes. If this is not enough, 2273 you can define CONFIG_SYS_BOOTM_LEN in your board config file 2274 to adjust this setting to your needs. 2275 2276- CONFIG_SYS_BOOTMAPSZ: 2277 Maximum size of memory mapped by the startup code of 2278 the Linux kernel; all data that must be processed by 2279 the Linux kernel (bd_info, boot arguments, FDT blob if 2280 used) must be put below this limit, unless "bootm_low" 2281 environment variable is defined and non-zero. In such case 2282 all data for the Linux kernel must be between "bootm_low" 2283 and "bootm_low" + CONFIG_SYS_BOOTMAPSZ. The environment 2284 variable "bootm_mapsize" will override the value of 2285 CONFIG_SYS_BOOTMAPSZ. If CONFIG_SYS_BOOTMAPSZ is undefined, 2286 then the value in "bootm_size" will be used instead. 2287 2288- CONFIG_SYS_BOOT_RAMDISK_HIGH: 2289 Enable initrd_high functionality. If defined then the 2290 initrd_high feature is enabled and the bootm ramdisk subcommand 2291 is enabled. 2292 2293- CONFIG_SYS_BOOT_GET_CMDLINE: 2294 Enables allocating and saving kernel cmdline in space between 2295 "bootm_low" and "bootm_low" + BOOTMAPSZ. 2296 2297- CONFIG_SYS_BOOT_GET_KBD: 2298 Enables allocating and saving a kernel copy of the bd_info in 2299 space between "bootm_low" and "bootm_low" + BOOTMAPSZ. 2300 2301- CONFIG_SYS_MAX_FLASH_BANKS: 2302 Max number of Flash memory banks 2303 2304- CONFIG_SYS_MAX_FLASH_SECT: 2305 Max number of sectors on a Flash chip 2306 2307- CONFIG_SYS_FLASH_ERASE_TOUT: 2308 Timeout for Flash erase operations (in ms) 2309 2310- CONFIG_SYS_FLASH_WRITE_TOUT: 2311 Timeout for Flash write operations (in ms) 2312 2313- CONFIG_SYS_FLASH_LOCK_TOUT 2314 Timeout for Flash set sector lock bit operation (in ms) 2315 2316- CONFIG_SYS_FLASH_UNLOCK_TOUT 2317 Timeout for Flash clear lock bits operation (in ms) 2318 2319- CONFIG_SYS_FLASH_PROTECTION 2320 If defined, hardware flash sectors protection is used 2321 instead of U-Boot software protection. 2322 2323- CONFIG_SYS_DIRECT_FLASH_TFTP: 2324 2325 Enable TFTP transfers directly to flash memory; 2326 without this option such a download has to be 2327 performed in two steps: (1) download to RAM, and (2) 2328 copy from RAM to flash. 2329 2330 The two-step approach is usually more reliable, since 2331 you can check if the download worked before you erase 2332 the flash, but in some situations (when system RAM is 2333 too limited to allow for a temporary copy of the 2334 downloaded image) this option may be very useful. 2335 2336- CONFIG_SYS_FLASH_CFI: 2337 Define if the flash driver uses extra elements in the 2338 common flash structure for storing flash geometry. 2339 2340- CONFIG_FLASH_CFI_DRIVER 2341 This option also enables the building of the cfi_flash driver 2342 in the drivers directory 2343 2344- CONFIG_FLASH_CFI_MTD 2345 This option enables the building of the cfi_mtd driver 2346 in the drivers directory. The driver exports CFI flash 2347 to the MTD layer. 2348 2349- CONFIG_SYS_FLASH_USE_BUFFER_WRITE 2350 Use buffered writes to flash. 2351 2352- CONFIG_FLASH_SPANSION_S29WS_N 2353 s29ws-n MirrorBit flash has non-standard addresses for buffered 2354 write commands. 2355 2356- CONFIG_SYS_FLASH_QUIET_TEST 2357 If this option is defined, the common CFI flash doesn't 2358 print it's warning upon not recognized FLASH banks. This 2359 is useful, if some of the configured banks are only 2360 optionally available. 2361 2362- CONFIG_FLASH_SHOW_PROGRESS 2363 If defined (must be an integer), print out countdown 2364 digits and dots. Recommended value: 45 (9..1) for 80 2365 column displays, 15 (3..1) for 40 column displays. 2366 2367- CONFIG_FLASH_VERIFY 2368 If defined, the content of the flash (destination) is compared 2369 against the source after the write operation. An error message 2370 will be printed when the contents are not identical. 2371 Please note that this option is useless in nearly all cases, 2372 since such flash programming errors usually are detected earlier 2373 while unprotecting/erasing/programming. Please only enable 2374 this option if you really know what you are doing. 2375 2376- CONFIG_SYS_RX_ETH_BUFFER: 2377 Defines the number of Ethernet receive buffers. On some 2378 Ethernet controllers it is recommended to set this value 2379 to 8 or even higher (EEPRO100 or 405 EMAC), since all 2380 buffers can be full shortly after enabling the interface 2381 on high Ethernet traffic. 2382 Defaults to 4 if not defined. 2383 2384- CONFIG_ENV_MAX_ENTRIES 2385 2386 Maximum number of entries in the hash table that is used 2387 internally to store the environment settings. The default 2388 setting is supposed to be generous and should work in most 2389 cases. This setting can be used to tune behaviour; see 2390 lib/hashtable.c for details. 2391 2392- CONFIG_ENV_FLAGS_LIST_DEFAULT 2393- CONFIG_ENV_FLAGS_LIST_STATIC 2394 Enable validation of the values given to environment variables when 2395 calling env set. Variables can be restricted to only decimal, 2396 hexadecimal, or boolean. If CONFIG_CMD_NET is also defined, 2397 the variables can also be restricted to IP address or MAC address. 2398 2399 The format of the list is: 2400 type_attribute = [s|d|x|b|i|m] 2401 access_attribute = [a|r|o|c] 2402 attributes = type_attribute[access_attribute] 2403 entry = variable_name[:attributes] 2404 list = entry[,list] 2405 2406 The type attributes are: 2407 s - String (default) 2408 d - Decimal 2409 x - Hexadecimal 2410 b - Boolean ([1yYtT|0nNfF]) 2411 i - IP address 2412 m - MAC address 2413 2414 The access attributes are: 2415 a - Any (default) 2416 r - Read-only 2417 o - Write-once 2418 c - Change-default 2419 2420 - CONFIG_ENV_FLAGS_LIST_DEFAULT 2421 Define this to a list (string) to define the ".flags" 2422 environment variable in the default or embedded environment. 2423 2424 - CONFIG_ENV_FLAGS_LIST_STATIC 2425 Define this to a list (string) to define validation that 2426 should be done if an entry is not found in the ".flags" 2427 environment variable. To override a setting in the static 2428 list, simply add an entry for the same variable name to the 2429 ".flags" variable. 2430 2431 If CONFIG_REGEX is defined, the variable_name above is evaluated as a 2432 regular expression. This allows multiple variables to define the same 2433 flags without explicitly listing them for each variable. 2434 2435The following definitions that deal with the placement and management 2436of environment data (variable area); in general, we support the 2437following configurations: 2438 2439- CONFIG_BUILD_ENVCRC: 2440 2441 Builds up envcrc with the target environment so that external utils 2442 may easily extract it and embed it in final U-Boot images. 2443 2444BE CAREFUL! The first access to the environment happens quite early 2445in U-Boot initialization (when we try to get the setting of for the 2446console baudrate). You *MUST* have mapped your NVRAM area then, or 2447U-Boot will hang. 2448 2449Please note that even with NVRAM we still use a copy of the 2450environment in RAM: we could work on NVRAM directly, but we want to 2451keep settings there always unmodified except somebody uses "saveenv" 2452to save the current settings. 2453 2454BE CAREFUL! For some special cases, the local device can not use 2455"saveenv" command. For example, the local device will get the 2456environment stored in a remote NOR flash by SRIO or PCIE link, 2457but it can not erase, write this NOR flash by SRIO or PCIE interface. 2458 2459- CONFIG_NAND_ENV_DST 2460 2461 Defines address in RAM to which the nand_spl code should copy the 2462 environment. If redundant environment is used, it will be copied to 2463 CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE. 2464 2465Please note that the environment is read-only until the monitor 2466has been relocated to RAM and a RAM copy of the environment has been 2467created; also, when using EEPROM you will have to use env_get_f() 2468until then to read environment variables. 2469 2470The environment is protected by a CRC32 checksum. Before the monitor 2471is relocated into RAM, as a result of a bad CRC you will be working 2472with the compiled-in default environment - *silently*!!! [This is 2473necessary, because the first environment variable we need is the 2474"baudrate" setting for the console - if we have a bad CRC, we don't 2475have any device yet where we could complain.] 2476 2477Note: once the monitor has been relocated, then it will complain if 2478the default environment is used; a new CRC is computed as soon as you 2479use the "saveenv" command to store a valid environment. 2480 2481- CONFIG_SYS_FAULT_ECHO_LINK_DOWN: 2482 Echo the inverted Ethernet link state to the fault LED. 2483 2484 Note: If this option is active, then CONFIG_SYS_FAULT_MII_ADDR 2485 also needs to be defined. 2486 2487- CONFIG_SYS_FAULT_MII_ADDR: 2488 MII address of the PHY to check for the Ethernet link state. 2489 2490- CONFIG_NS16550_MIN_FUNCTIONS: 2491 Define this if you desire to only have use of the NS16550_init 2492 and NS16550_putc functions for the serial driver located at 2493 drivers/serial/ns16550.c. This option is useful for saving 2494 space for already greatly restricted images, including but not 2495 limited to NAND_SPL configurations. 2496 2497- CONFIG_DISPLAY_BOARDINFO 2498 Display information about the board that U-Boot is running on 2499 when U-Boot starts up. The board function checkboard() is called 2500 to do this. 2501 2502- CONFIG_DISPLAY_BOARDINFO_LATE 2503 Similar to the previous option, but display this information 2504 later, once stdio is running and output goes to the LCD, if 2505 present. 2506 2507- CONFIG_BOARD_SIZE_LIMIT: 2508 Maximum size of the U-Boot image. When defined, the 2509 build system checks that the actual size does not 2510 exceed it. 2511 2512Low Level (hardware related) configuration options: 2513--------------------------------------------------- 2514 2515- CONFIG_SYS_CACHELINE_SIZE: 2516 Cache Line Size of the CPU. 2517 2518- CONFIG_SYS_CCSRBAR_DEFAULT: 2519 Default (power-on reset) physical address of CCSR on Freescale 2520 PowerPC SOCs. 2521 2522- CONFIG_SYS_CCSRBAR: 2523 Virtual address of CCSR. On a 32-bit build, this is typically 2524 the same value as CONFIG_SYS_CCSRBAR_DEFAULT. 2525 2526- CONFIG_SYS_CCSRBAR_PHYS: 2527 Physical address of CCSR. CCSR can be relocated to a new 2528 physical address, if desired. In this case, this macro should 2529 be set to that address. Otherwise, it should be set to the 2530 same value as CONFIG_SYS_CCSRBAR_DEFAULT. For example, CCSR 2531 is typically relocated on 36-bit builds. It is recommended 2532 that this macro be defined via the _HIGH and _LOW macros: 2533 2534 #define CONFIG_SYS_CCSRBAR_PHYS ((CONFIG_SYS_CCSRBAR_PHYS_HIGH 2535 * 1ull) << 32 | CONFIG_SYS_CCSRBAR_PHYS_LOW) 2536 2537- CONFIG_SYS_CCSRBAR_PHYS_HIGH: 2538 Bits 33-36 of CONFIG_SYS_CCSRBAR_PHYS. This value is typically 2539 either 0 (32-bit build) or 0xF (36-bit build). This macro is 2540 used in assembly code, so it must not contain typecasts or 2541 integer size suffixes (e.g. "ULL"). 2542 2543- CONFIG_SYS_CCSRBAR_PHYS_LOW: 2544 Lower 32-bits of CONFIG_SYS_CCSRBAR_PHYS. This macro is 2545 used in assembly code, so it must not contain typecasts or 2546 integer size suffixes (e.g. "ULL"). 2547 2548- CONFIG_SYS_CCSR_DO_NOT_RELOCATE: 2549 If this macro is defined, then CONFIG_SYS_CCSRBAR_PHYS will be 2550 forced to a value that ensures that CCSR is not relocated. 2551 2552- CONFIG_IDE_AHB: 2553 Most IDE controllers were designed to be connected with PCI 2554 interface. Only few of them were designed for AHB interface. 2555 When software is doing ATA command and data transfer to 2556 IDE devices through IDE-AHB controller, some additional 2557 registers accessing to these kind of IDE-AHB controller 2558 is required. 2559 2560- CONFIG_SYS_IMMR: Physical address of the Internal Memory. 2561 DO NOT CHANGE unless you know exactly what you're 2562 doing! (11-4) [MPC8xx systems only] 2563 2564- CONFIG_SYS_INIT_RAM_ADDR: 2565 2566 Start address of memory area that can be used for 2567 initial data and stack; please note that this must be 2568 writable memory that is working WITHOUT special 2569 initialization, i. e. you CANNOT use normal RAM which 2570 will become available only after programming the 2571 memory controller and running certain initialization 2572 sequences. 2573 2574 U-Boot uses the following memory types: 2575 - MPC8xx: IMMR (internal memory of the CPU) 2576 2577- CONFIG_SYS_GBL_DATA_OFFSET: 2578 2579 Offset of the initial data structure in the memory 2580 area defined by CONFIG_SYS_INIT_RAM_ADDR. Usually 2581 CONFIG_SYS_GBL_DATA_OFFSET is chosen such that the initial 2582 data is located at the end of the available space 2583 (sometimes written as (CONFIG_SYS_INIT_RAM_SIZE - 2584 GENERATED_GBL_DATA_SIZE), and the initial stack is just 2585 below that area (growing from (CONFIG_SYS_INIT_RAM_ADDR + 2586 CONFIG_SYS_GBL_DATA_OFFSET) downward. 2587 2588 Note: 2589 On the MPC824X (or other systems that use the data 2590 cache for initial memory) the address chosen for 2591 CONFIG_SYS_INIT_RAM_ADDR is basically arbitrary - it must 2592 point to an otherwise UNUSED address space between 2593 the top of RAM and the start of the PCI space. 2594 2595- CONFIG_SYS_SCCR: System Clock and reset Control Register (15-27) 2596 2597- CONFIG_SYS_OR_TIMING_SDRAM: 2598 SDRAM timing 2599 2600- CONFIG_SYS_MAMR_PTA: 2601 periodic timer for refresh 2602 2603- FLASH_BASE0_PRELIM, FLASH_BASE1_PRELIM, CONFIG_SYS_REMAP_OR_AM, 2604 CONFIG_SYS_PRELIM_OR_AM, CONFIG_SYS_OR_TIMING_FLASH, CONFIG_SYS_OR0_REMAP, 2605 CONFIG_SYS_OR0_PRELIM, CONFIG_SYS_BR0_PRELIM, CONFIG_SYS_OR1_REMAP, CONFIG_SYS_OR1_PRELIM, 2606 CONFIG_SYS_BR1_PRELIM: 2607 Memory Controller Definitions: BR0/1 and OR0/1 (FLASH) 2608 2609- SDRAM_BASE2_PRELIM, SDRAM_BASE3_PRELIM, SDRAM_MAX_SIZE, 2610 CONFIG_SYS_OR_TIMING_SDRAM, CONFIG_SYS_OR2_PRELIM, CONFIG_SYS_BR2_PRELIM, 2611 CONFIG_SYS_OR3_PRELIM, CONFIG_SYS_BR3_PRELIM: 2612 Memory Controller Definitions: BR2/3 and OR2/3 (SDRAM) 2613 2614- CONFIG_SYS_SRIO: 2615 Chip has SRIO or not 2616 2617- CONFIG_SRIO1: 2618 Board has SRIO 1 port available 2619 2620- CONFIG_SRIO2: 2621 Board has SRIO 2 port available 2622 2623- CONFIG_SRIO_PCIE_BOOT_MASTER 2624 Board can support master function for Boot from SRIO and PCIE 2625 2626- CONFIG_SYS_SRIOn_MEM_VIRT: 2627 Virtual Address of SRIO port 'n' memory region 2628 2629- CONFIG_SYS_SRIOn_MEM_PHYxS: 2630 Physical Address of SRIO port 'n' memory region 2631 2632- CONFIG_SYS_SRIOn_MEM_SIZE: 2633 Size of SRIO port 'n' memory region 2634 2635- CONFIG_SYS_NAND_BUSWIDTH_16BIT 2636 Defined to tell the NAND controller that the NAND chip is using 2637 a 16 bit bus. 2638 Not all NAND drivers use this symbol. 2639 Example of drivers that use it: 2640 - drivers/mtd/nand/raw/ndfc.c 2641 - drivers/mtd/nand/raw/mxc_nand.c 2642 2643- CONFIG_SYS_NDFC_EBC0_CFG 2644 Sets the EBC0_CFG register for the NDFC. If not defined 2645 a default value will be used. 2646 2647- CONFIG_SPD_EEPROM 2648 Get DDR timing information from an I2C EEPROM. Common 2649 with pluggable memory modules such as SODIMMs 2650 2651 SPD_EEPROM_ADDRESS 2652 I2C address of the SPD EEPROM 2653 2654- CONFIG_SYS_SPD_BUS_NUM 2655 If SPD EEPROM is on an I2C bus other than the first 2656 one, specify here. Note that the value must resolve 2657 to something your driver can deal with. 2658 2659- CONFIG_SYS_DDR_RAW_TIMING 2660 Get DDR timing information from other than SPD. Common with 2661 soldered DDR chips onboard without SPD. DDR raw timing 2662 parameters are extracted from datasheet and hard-coded into 2663 header files or board specific files. 2664 2665- CONFIG_FSL_DDR_INTERACTIVE 2666 Enable interactive DDR debugging. See doc/README.fsl-ddr. 2667 2668- CONFIG_FSL_DDR_SYNC_REFRESH 2669 Enable sync of refresh for multiple controllers. 2670 2671- CONFIG_FSL_DDR_BIST 2672 Enable built-in memory test for Freescale DDR controllers. 2673 2674- CONFIG_SYS_83XX_DDR_USES_CS0 2675 Only for 83xx systems. If specified, then DDR should 2676 be configured using CS0 and CS1 instead of CS2 and CS3. 2677 2678- CONFIG_RMII 2679 Enable RMII mode for all FECs. 2680 Note that this is a global option, we can't 2681 have one FEC in standard MII mode and another in RMII mode. 2682 2683- CONFIG_CRC32_VERIFY 2684 Add a verify option to the crc32 command. 2685 The syntax is: 2686 2687 => crc32 -v <address> <count> <crc32> 2688 2689 Where address/count indicate a memory area 2690 and crc32 is the correct crc32 which the 2691 area should have. 2692 2693- CONFIG_LOOPW 2694 Add the "loopw" memory command. This only takes effect if 2695 the memory commands are activated globally (CONFIG_CMD_MEMORY). 2696 2697- CONFIG_CMD_MX_CYCLIC 2698 Add the "mdc" and "mwc" memory commands. These are cyclic 2699 "md/mw" commands. 2700 Examples: 2701 2702 => mdc.b 10 4 500 2703 This command will print 4 bytes (10,11,12,13) each 500 ms. 2704 2705 => mwc.l 100 12345678 10 2706 This command will write 12345678 to address 100 all 10 ms. 2707 2708 This only takes effect if the memory commands are activated 2709 globally (CONFIG_CMD_MEMORY). 2710 2711- CONFIG_SPL_BUILD 2712 Set when the currently-running compilation is for an artifact 2713 that will end up in the SPL (as opposed to the TPL or U-Boot 2714 proper). Code that needs stage-specific behavior should check 2715 this. 2716 2717- CONFIG_TPL_BUILD 2718 Set when the currently-running compilation is for an artifact 2719 that will end up in the TPL (as opposed to the SPL or U-Boot 2720 proper). Code that needs stage-specific behavior should check 2721 this. 2722 2723- CONFIG_SYS_MPC85XX_NO_RESETVEC 2724 Only for 85xx systems. If this variable is specified, the section 2725 .resetvec is not kept and the section .bootpg is placed in the 2726 previous 4k of the .text section. 2727 2728- CONFIG_ARCH_MAP_SYSMEM 2729 Generally U-Boot (and in particular the md command) uses 2730 effective address. It is therefore not necessary to regard 2731 U-Boot address as virtual addresses that need to be translated 2732 to physical addresses. However, sandbox requires this, since 2733 it maintains its own little RAM buffer which contains all 2734 addressable memory. This option causes some memory accesses 2735 to be mapped through map_sysmem() / unmap_sysmem(). 2736 2737- CONFIG_X86_RESET_VECTOR 2738 If defined, the x86 reset vector code is included. This is not 2739 needed when U-Boot is running from Coreboot. 2740 2741- CONFIG_SYS_NAND_NO_SUBPAGE_WRITE 2742 Option to disable subpage write in NAND driver 2743 driver that uses this: 2744 drivers/mtd/nand/raw/davinci_nand.c 2745 2746Freescale QE/FMAN Firmware Support: 2747----------------------------------- 2748 2749The Freescale QUICCEngine (QE) and Frame Manager (FMAN) both support the 2750loading of "firmware", which is encoded in the QE firmware binary format. 2751This firmware often needs to be loaded during U-Boot booting, so macros 2752are used to identify the storage device (NOR flash, SPI, etc) and the address 2753within that device. 2754 2755- CONFIG_SYS_FMAN_FW_ADDR 2756 The address in the storage device where the FMAN microcode is located. The 2757 meaning of this address depends on which CONFIG_SYS_QE_FMAN_FW_IN_xxx macro 2758 is also specified. 2759 2760- CONFIG_SYS_QE_FW_ADDR 2761 The address in the storage device where the QE microcode is located. The 2762 meaning of this address depends on which CONFIG_SYS_QE_FMAN_FW_IN_xxx macro 2763 is also specified. 2764 2765- CONFIG_SYS_QE_FMAN_FW_LENGTH 2766 The maximum possible size of the firmware. The firmware binary format 2767 has a field that specifies the actual size of the firmware, but it 2768 might not be possible to read any part of the firmware unless some 2769 local storage is allocated to hold the entire firmware first. 2770 2771- CONFIG_SYS_QE_FMAN_FW_IN_NOR 2772 Specifies that QE/FMAN firmware is located in NOR flash, mapped as 2773 normal addressable memory via the LBC. CONFIG_SYS_FMAN_FW_ADDR is the 2774 virtual address in NOR flash. 2775 2776- CONFIG_SYS_QE_FMAN_FW_IN_NAND 2777 Specifies that QE/FMAN firmware is located in NAND flash. 2778 CONFIG_SYS_FMAN_FW_ADDR is the offset within NAND flash. 2779 2780- CONFIG_SYS_QE_FMAN_FW_IN_MMC 2781 Specifies that QE/FMAN firmware is located on the primary SD/MMC 2782 device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device. 2783 2784- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE 2785 Specifies that QE/FMAN firmware is located in the remote (master) 2786 memory space. CONFIG_SYS_FMAN_FW_ADDR is a virtual address which 2787 can be mapped from slave TLB->slave LAW->slave SRIO or PCIE outbound 2788 window->master inbound window->master LAW->the ucode address in 2789 master's memory space. 2790 2791Freescale Layerscape Management Complex Firmware Support: 2792--------------------------------------------------------- 2793The Freescale Layerscape Management Complex (MC) supports the loading of 2794"firmware". 2795This firmware often needs to be loaded during U-Boot booting, so macros 2796are used to identify the storage device (NOR flash, SPI, etc) and the address 2797within that device. 2798 2799- CONFIG_FSL_MC_ENET 2800 Enable the MC driver for Layerscape SoCs. 2801 2802Freescale Layerscape Debug Server Support: 2803------------------------------------------- 2804The Freescale Layerscape Debug Server Support supports the loading of 2805"Debug Server firmware" and triggering SP boot-rom. 2806This firmware often needs to be loaded during U-Boot booting. 2807 2808- CONFIG_SYS_MC_RSV_MEM_ALIGN 2809 Define alignment of reserved memory MC requires 2810 2811Reproducible builds 2812------------------- 2813 2814In order to achieve reproducible builds, timestamps used in the U-Boot build 2815process have to be set to a fixed value. 2816 2817This is done using the SOURCE_DATE_EPOCH environment variable. 2818SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a configuration 2819option for U-Boot or an environment variable in U-Boot. 2820 2821SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC. 2822 2823Building the Software: 2824====================== 2825 2826Building U-Boot has been tested in several native build environments 2827and in many different cross environments. Of course we cannot support 2828all possibly existing versions of cross development tools in all 2829(potentially obsolete) versions. In case of tool chain problems we 2830recommend to use the ELDK (see https://www.denx.de/wiki/DULG/ELDK) 2831which is extensively used to build and test U-Boot. 2832 2833If you are not using a native environment, it is assumed that you 2834have GNU cross compiling tools available in your path. In this case, 2835you must set the environment variable CROSS_COMPILE in your shell. 2836Note that no changes to the Makefile or any other source files are 2837necessary. For example using the ELDK on a 4xx CPU, please enter: 2838 2839 $ CROSS_COMPILE=ppc_4xx- 2840 $ export CROSS_COMPILE 2841 2842U-Boot is intended to be simple to build. After installing the 2843sources you must configure U-Boot for one specific board type. This 2844is done by typing: 2845 2846 make NAME_defconfig 2847 2848where "NAME_defconfig" is the name of one of the existing configu- 2849rations; see configs/*_defconfig for supported names. 2850 2851Note: for some boards special configuration names may exist; check if 2852 additional information is available from the board vendor; for 2853 instance, the TQM823L systems are available without (standard) 2854 or with LCD support. You can select such additional "features" 2855 when choosing the configuration, i. e. 2856 2857 make TQM823L_defconfig 2858 - will configure for a plain TQM823L, i. e. no LCD support 2859 2860 make TQM823L_LCD_defconfig 2861 - will configure for a TQM823L with U-Boot console on LCD 2862 2863 etc. 2864 2865 2866Finally, type "make all", and you should get some working U-Boot 2867images ready for download to / installation on your system: 2868 2869- "u-boot.bin" is a raw binary image 2870- "u-boot" is an image in ELF binary format 2871- "u-boot.srec" is in Motorola S-Record format 2872 2873By default the build is performed locally and the objects are saved 2874in the source directory. One of the two methods can be used to change 2875this behavior and build U-Boot to some external directory: 2876 28771. Add O= to the make command line invocations: 2878 2879 make O=/tmp/build distclean 2880 make O=/tmp/build NAME_defconfig 2881 make O=/tmp/build all 2882 28832. Set environment variable KBUILD_OUTPUT to point to the desired location: 2884 2885 export KBUILD_OUTPUT=/tmp/build 2886 make distclean 2887 make NAME_defconfig 2888 make all 2889 2890Note that the command line "O=" setting overrides the KBUILD_OUTPUT environment 2891variable. 2892 2893User specific CPPFLAGS, AFLAGS and CFLAGS can be passed to the compiler by 2894setting the according environment variables KCPPFLAGS, KAFLAGS and KCFLAGS. 2895For example to treat all compiler warnings as errors: 2896 2897 make KCFLAGS=-Werror 2898 2899Please be aware that the Makefiles assume you are using GNU make, so 2900for instance on NetBSD you might need to use "gmake" instead of 2901native "make". 2902 2903 2904If the system board that you have is not listed, then you will need 2905to port U-Boot to your hardware platform. To do this, follow these 2906steps: 2907 29081. Create a new directory to hold your board specific code. Add any 2909 files you need. In your board directory, you will need at least 2910 the "Makefile" and a "<board>.c". 29112. Create a new configuration file "include/configs/<board>.h" for 2912 your board. 29133. If you're porting U-Boot to a new CPU, then also create a new 2914 directory to hold your CPU specific code. Add any files you need. 29154. Run "make <board>_defconfig" with your new name. 29165. Type "make", and you should get a working "u-boot.srec" file 2917 to be installed on your target system. 29186. Debug and solve any problems that might arise. 2919 [Of course, this last step is much harder than it sounds.] 2920 2921 2922Testing of U-Boot Modifications, Ports to New Hardware, etc.: 2923============================================================== 2924 2925If you have modified U-Boot sources (for instance added a new board 2926or support for new devices, a new CPU, etc.) you are expected to 2927provide feedback to the other developers. The feedback normally takes 2928the form of a "patch", i.e. a context diff against a certain (latest 2929official or latest in the git repository) version of U-Boot sources. 2930 2931But before you submit such a patch, please verify that your modifi- 2932cation did not break existing code. At least make sure that *ALL* of 2933the supported boards compile WITHOUT ANY compiler warnings. To do so, 2934just run the buildman script (tools/buildman/buildman), which will 2935configure and build U-Boot for ALL supported system. Be warned, this 2936will take a while. Please see the buildman README, or run 'buildman -H' 2937for documentation. 2938 2939 2940See also "U-Boot Porting Guide" below. 2941 2942 2943Monitor Commands - Overview: 2944============================ 2945 2946go - start application at address 'addr' 2947run - run commands in an environment variable 2948bootm - boot application image from memory 2949bootp - boot image via network using BootP/TFTP protocol 2950bootz - boot zImage from memory 2951tftpboot- boot image via network using TFTP protocol 2952 and env variables "ipaddr" and "serverip" 2953 (and eventually "gatewayip") 2954tftpput - upload a file via network using TFTP protocol 2955rarpboot- boot image via network using RARP/TFTP protocol 2956diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd' 2957loads - load S-Record file over serial line 2958loadb - load binary file over serial line (kermit mode) 2959md - memory display 2960mm - memory modify (auto-incrementing) 2961nm - memory modify (constant address) 2962mw - memory write (fill) 2963ms - memory search 2964cp - memory copy 2965cmp - memory compare 2966crc32 - checksum calculation 2967i2c - I2C sub-system 2968sspi - SPI utility commands 2969base - print or set address offset 2970printenv- print environment variables 2971pwm - control pwm channels 2972setenv - set environment variables 2973saveenv - save environment variables to persistent storage 2974protect - enable or disable FLASH write protection 2975erase - erase FLASH memory 2976flinfo - print FLASH memory information 2977nand - NAND memory operations (see doc/README.nand) 2978bdinfo - print Board Info structure 2979iminfo - print header information for application image 2980coninfo - print console devices and informations 2981ide - IDE sub-system 2982loop - infinite loop on address range 2983loopw - infinite write loop on address range 2984mtest - simple RAM test 2985icache - enable or disable instruction cache 2986dcache - enable or disable data cache 2987reset - Perform RESET of the CPU 2988echo - echo args to console 2989version - print monitor version 2990help - print online help 2991? - alias for 'help' 2992 2993 2994Monitor Commands - Detailed Description: 2995======================================== 2996 2997TODO. 2998 2999For now: just type "help <command>". 3000 3001 3002Environment Variables: 3003====================== 3004 3005U-Boot supports user configuration using Environment Variables which 3006can be made persistent by saving to Flash memory. 3007 3008Environment Variables are set using "setenv", printed using 3009"printenv", and saved to Flash using "saveenv". Using "setenv" 3010without a value can be used to delete a variable from the 3011environment. As long as you don't save the environment you are 3012working with an in-memory copy. In case the Flash area containing the 3013environment is erased by accident, a default environment is provided. 3014 3015Some configuration options can be set using Environment Variables. 3016 3017List of environment variables (most likely not complete): 3018 3019 baudrate - see CONFIG_BAUDRATE 3020 3021 bootdelay - see CONFIG_BOOTDELAY 3022 3023 bootcmd - see CONFIG_BOOTCOMMAND 3024 3025 bootargs - Boot arguments when booting an RTOS image 3026 3027 bootfile - Name of the image to load with TFTP 3028 3029 bootm_low - Memory range available for image processing in the bootm 3030 command can be restricted. This variable is given as 3031 a hexadecimal number and defines lowest address allowed 3032 for use by the bootm command. See also "bootm_size" 3033 environment variable. Address defined by "bootm_low" is 3034 also the base of the initial memory mapping for the Linux 3035 kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and 3036 bootm_mapsize. 3037 3038 bootm_mapsize - Size of the initial memory mapping for the Linux kernel. 3039 This variable is given as a hexadecimal number and it 3040 defines the size of the memory region starting at base 3041 address bootm_low that is accessible by the Linux kernel 3042 during early boot. If unset, CONFIG_SYS_BOOTMAPSZ is used 3043 as the default value if it is defined, and bootm_size is 3044 used otherwise. 3045 3046 bootm_size - Memory range available for image processing in the bootm 3047 command can be restricted. This variable is given as 3048 a hexadecimal number and defines the size of the region 3049 allowed for use by the bootm command. See also "bootm_low" 3050 environment variable. 3051 3052 bootstopkeysha256, bootdelaykey, bootstopkey - See README.autoboot 3053 3054 updatefile - Location of the software update file on a TFTP server, used 3055 by the automatic software update feature. Please refer to 3056 documentation in doc/README.update for more details. 3057 3058 autoload - if set to "no" (any string beginning with 'n'), 3059 "bootp" will just load perform a lookup of the 3060 configuration from the BOOTP server, but not try to 3061 load any image using TFTP 3062 3063 autostart - if set to "yes", an image loaded using the "bootp", 3064 "rarpboot", "tftpboot" or "diskboot" commands will 3065 be automatically started (by internally calling 3066 "bootm") 3067 3068 If set to "no", a standalone image passed to the 3069 "bootm" command will be copied to the load address 3070 (and eventually uncompressed), but NOT be started. 3071 This can be used to load and uncompress arbitrary 3072 data. 3073 3074 fdt_high - if set this restricts the maximum address that the 3075 flattened device tree will be copied into upon boot. 3076 For example, if you have a system with 1 GB memory 3077 at physical address 0x10000000, while Linux kernel 3078 only recognizes the first 704 MB as low memory, you 3079 may need to set fdt_high as 0x3C000000 to have the 3080 device tree blob be copied to the maximum address 3081 of the 704 MB low memory, so that Linux kernel can 3082 access it during the boot procedure. 3083 3084 If this is set to the special value 0xFFFFFFFF then 3085 the fdt will not be copied at all on boot. For this 3086 to work it must reside in writable memory, have 3087 sufficient padding on the end of it for u-boot to 3088 add the information it needs into it, and the memory 3089 must be accessible by the kernel. 3090 3091 fdtcontroladdr- if set this is the address of the control flattened 3092 device tree used by U-Boot when CONFIG_OF_CONTROL is 3093 defined. 3094 3095 i2cfast - (PPC405GP|PPC405EP only) 3096 if set to 'y' configures Linux I2C driver for fast 3097 mode (400kHZ). This environment variable is used in 3098 initialization code. So, for changes to be effective 3099 it must be saved and board must be reset. 3100 3101 initrd_high - restrict positioning of initrd images: 3102 If this variable is not set, initrd images will be 3103 copied to the highest possible address in RAM; this 3104 is usually what you want since it allows for 3105 maximum initrd size. If for some reason you want to 3106 make sure that the initrd image is loaded below the 3107 CONFIG_SYS_BOOTMAPSZ limit, you can set this environment 3108 variable to a value of "no" or "off" or "0". 3109 Alternatively, you can set it to a maximum upper 3110 address to use (U-Boot will still check that it 3111 does not overwrite the U-Boot stack and data). 3112 3113 For instance, when you have a system with 16 MB 3114 RAM, and want to reserve 4 MB from use by Linux, 3115 you can do this by adding "mem=12M" to the value of 3116 the "bootargs" variable. However, now you must make 3117 sure that the initrd image is placed in the first 3118 12 MB as well - this can be done with 3119 3120 setenv initrd_high 00c00000 3121 3122 If you set initrd_high to 0xFFFFFFFF, this is an 3123 indication to U-Boot that all addresses are legal 3124 for the Linux kernel, including addresses in flash 3125 memory. In this case U-Boot will NOT COPY the 3126 ramdisk at all. This may be useful to reduce the 3127 boot time on your system, but requires that this 3128 feature is supported by your Linux kernel. 3129 3130 ipaddr - IP address; needed for tftpboot command 3131 3132 loadaddr - Default load address for commands like "bootp", 3133 "rarpboot", "tftpboot", "loadb" or "diskboot" 3134 3135 loads_echo - see CONFIG_LOADS_ECHO 3136 3137 serverip - TFTP server IP address; needed for tftpboot command 3138 3139 bootretry - see CONFIG_BOOT_RETRY_TIME 3140 3141 bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR 3142 3143 bootstopkey - see CONFIG_AUTOBOOT_STOP_STR 3144 3145 ethprime - controls which interface is used first. 3146 3147 ethact - controls which interface is currently active. 3148 For example you can do the following 3149 3150 => setenv ethact FEC 3151 => ping 192.168.0.1 # traffic sent on FEC 3152 => setenv ethact SCC 3153 => ping 10.0.0.1 # traffic sent on SCC 3154 3155 ethrotate - When set to "no" U-Boot does not go through all 3156 available network interfaces. 3157 It just stays at the currently selected interface. 3158 3159 netretry - When set to "no" each network operation will 3160 either succeed or fail without retrying. 3161 When set to "once" the network operation will 3162 fail when all the available network interfaces 3163 are tried once without success. 3164 Useful on scripts which control the retry operation 3165 themselves. 3166 3167 npe_ucode - set load address for the NPE microcode 3168 3169 silent_linux - If set then Linux will be told to boot silently, by 3170 changing the console to be empty. If "yes" it will be 3171 made silent. If "no" it will not be made silent. If 3172 unset, then it will be made silent if the U-Boot console 3173 is silent. 3174 3175 tftpsrcp - If this is set, the value is used for TFTP's 3176 UDP source port. 3177 3178 tftpdstp - If this is set, the value is used for TFTP's UDP 3179 destination port instead of the Well Know Port 69. 3180 3181 tftpblocksize - Block size to use for TFTP transfers; if not set, 3182 we use the TFTP server's default block size 3183 3184 tftptimeout - Retransmission timeout for TFTP packets (in milli- 3185 seconds, minimum value is 1000 = 1 second). Defines 3186 when a packet is considered to be lost so it has to 3187 be retransmitted. The default is 5000 = 5 seconds. 3188 Lowering this value may make downloads succeed 3189 faster in networks with high packet loss rates or 3190 with unreliable TFTP servers. 3191 3192 tftptimeoutcountmax - maximum count of TFTP timeouts (no 3193 unit, minimum value = 0). Defines how many timeouts 3194 can happen during a single file transfer before that 3195 transfer is aborted. The default is 10, and 0 means 3196 'no timeouts allowed'. Increasing this value may help 3197 downloads succeed with high packet loss rates, or with 3198 unreliable TFTP servers or client hardware. 3199 3200 tftpwindowsize - if this is set, the value is used for TFTP's 3201 window size as described by RFC 7440. 3202 This means the count of blocks we can receive before 3203 sending ack to server. 3204 3205 vlan - When set to a value < 4095 the traffic over 3206 Ethernet is encapsulated/received over 802.1q 3207 VLAN tagged frames. 3208 3209 bootpretryperiod - Period during which BOOTP/DHCP sends retries. 3210 Unsigned value, in milliseconds. If not set, the period will 3211 be either the default (28000), or a value based on 3212 CONFIG_NET_RETRY_COUNT, if defined. This value has 3213 precedence over the valu based on CONFIG_NET_RETRY_COUNT. 3214 3215 memmatches - Number of matches found by the last 'ms' command, in hex 3216 3217 memaddr - Address of the last match found by the 'ms' command, in hex, 3218 or 0 if none 3219 3220 mempos - Index position of the last match found by the 'ms' command, 3221 in units of the size (.b, .w, .l) of the search 3222 3223 zbootbase - (x86 only) Base address of the bzImage 'setup' block 3224 3225 zbootaddr - (x86 only) Address of the loaded bzImage, typically 3226 BZIMAGE_LOAD_ADDR which is 0x100000 3227 3228The following image location variables contain the location of images 3229used in booting. The "Image" column gives the role of the image and is 3230not an environment variable name. The other columns are environment 3231variable names. "File Name" gives the name of the file on a TFTP 3232server, "RAM Address" gives the location in RAM the image will be 3233loaded to, and "Flash Location" gives the image's address in NOR 3234flash or offset in NAND flash. 3235 3236*Note* - these variables don't have to be defined for all boards, some 3237boards currently use other variables for these purposes, and some 3238boards use these variables for other purposes. 3239 3240Image File Name RAM Address Flash Location 3241----- --------- ----------- -------------- 3242u-boot u-boot u-boot_addr_r u-boot_addr 3243Linux kernel bootfile kernel_addr_r kernel_addr 3244device tree blob fdtfile fdt_addr_r fdt_addr 3245ramdisk ramdiskfile ramdisk_addr_r ramdisk_addr 3246 3247The following environment variables may be used and automatically 3248updated by the network boot commands ("bootp" and "rarpboot"), 3249depending the information provided by your boot server: 3250 3251 bootfile - see above 3252 dnsip - IP address of your Domain Name Server 3253 dnsip2 - IP address of your secondary Domain Name Server 3254 gatewayip - IP address of the Gateway (Router) to use 3255 hostname - Target hostname 3256 ipaddr - see above 3257 netmask - Subnet Mask 3258 rootpath - Pathname of the root filesystem on the NFS server 3259 serverip - see above 3260 3261 3262There are two special Environment Variables: 3263 3264 serial# - contains hardware identification information such 3265 as type string and/or serial number 3266 ethaddr - Ethernet address 3267 3268These variables can be set only once (usually during manufacturing of 3269the board). U-Boot refuses to delete or overwrite these variables 3270once they have been set once. 3271 3272 3273Further special Environment Variables: 3274 3275 ver - Contains the U-Boot version string as printed 3276 with the "version" command. This variable is 3277 readonly (see CONFIG_VERSION_VARIABLE). 3278 3279 3280Please note that changes to some configuration parameters may take 3281only effect after the next boot (yes, that's just like Windoze :-). 3282 3283 3284Callback functions for environment variables: 3285--------------------------------------------- 3286 3287For some environment variables, the behavior of u-boot needs to change 3288when their values are changed. This functionality allows functions to 3289be associated with arbitrary variables. On creation, overwrite, or 3290deletion, the callback will provide the opportunity for some side 3291effect to happen or for the change to be rejected. 3292 3293The callbacks are named and associated with a function using the 3294U_BOOT_ENV_CALLBACK macro in your board or driver code. 3295 3296These callbacks are associated with variables in one of two ways. The 3297static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC 3298in the board configuration to a string that defines a list of 3299associations. The list must be in the following format: 3300 3301 entry = variable_name[:callback_name] 3302 list = entry[,list] 3303 3304If the callback name is not specified, then the callback is deleted. 3305Spaces are also allowed anywhere in the list. 3306 3307Callbacks can also be associated by defining the ".callbacks" variable 3308with the same list format above. Any association in ".callbacks" will 3309override any association in the static list. You can define 3310CONFIG_ENV_CALLBACK_LIST_DEFAULT to a list (string) to define the 3311".callbacks" environment variable in the default or embedded environment. 3312 3313If CONFIG_REGEX is defined, the variable_name above is evaluated as a 3314regular expression. This allows multiple variables to be connected to 3315the same callback without explicitly listing them all out. 3316 3317The signature of the callback functions is: 3318 3319 int callback(const char *name, const char *value, enum env_op op, int flags) 3320 3321* name - changed environment variable 3322* value - new value of the environment variable 3323* op - operation (create, overwrite, or delete) 3324* flags - attributes of the environment variable change, see flags H_* in 3325 include/search.h 3326 3327The return value is 0 if the variable change is accepted and 1 otherwise. 3328 3329 3330Note for Redundant Ethernet Interfaces: 3331======================================= 3332 3333Some boards come with redundant Ethernet interfaces; U-Boot supports 3334such configurations and is capable of automatic selection of a 3335"working" interface when needed. MAC assignment works as follows: 3336 3337Network interfaces are numbered eth0, eth1, eth2, ... Corresponding 3338MAC addresses can be stored in the environment as "ethaddr" (=>eth0), 3339"eth1addr" (=>eth1), "eth2addr", ... 3340 3341If the network interface stores some valid MAC address (for instance 3342in SROM), this is used as default address if there is NO correspon- 3343ding setting in the environment; if the corresponding environment 3344variable is set, this overrides the settings in the card; that means: 3345 3346o If the SROM has a valid MAC address, and there is no address in the 3347 environment, the SROM's address is used. 3348 3349o If there is no valid address in the SROM, and a definition in the 3350 environment exists, then the value from the environment variable is 3351 used. 3352 3353o If both the SROM and the environment contain a MAC address, and 3354 both addresses are the same, this MAC address is used. 3355 3356o If both the SROM and the environment contain a MAC address, and the 3357 addresses differ, the value from the environment is used and a 3358 warning is printed. 3359 3360o If neither SROM nor the environment contain a MAC address, an error 3361 is raised. If CONFIG_NET_RANDOM_ETHADDR is defined, then in this case 3362 a random, locally-assigned MAC is used. 3363 3364If Ethernet drivers implement the 'write_hwaddr' function, valid MAC addresses 3365will be programmed into hardware as part of the initialization process. This 3366may be skipped by setting the appropriate 'ethmacskip' environment variable. 3367The naming convention is as follows: 3368"ethmacskip" (=>eth0), "eth1macskip" (=>eth1) etc. 3369 3370Image Formats: 3371============== 3372 3373U-Boot is capable of booting (and performing other auxiliary operations on) 3374images in two formats: 3375 3376New uImage format (FIT) 3377----------------------- 3378 3379Flexible and powerful format based on Flattened Image Tree -- FIT (similar 3380to Flattened Device Tree). It allows the use of images with multiple 3381components (several kernels, ramdisks, etc.), with contents protected by 3382SHA1, MD5 or CRC32. More details are found in the doc/uImage.FIT directory. 3383 3384 3385Old uImage format 3386----------------- 3387 3388Old image format is based on binary files which can be basically anything, 3389preceded by a special header; see the definitions in include/image.h for 3390details; basically, the header defines the following image properties: 3391 3392* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 3393 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, 3394 LynxOS, pSOS, QNX, RTEMS, INTEGRITY; 3395 Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, LynxOS, 3396 INTEGRITY). 3397* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, 3398 IA64, MIPS, NDS32, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; 3399 Currently supported: ARM, Intel x86, MIPS, NDS32, Nios II, PowerPC). 3400* Compression Type (uncompressed, gzip, bzip2) 3401* Load Address 3402* Entry Point 3403* Image Name 3404* Image Timestamp 3405 3406The header is marked by a special Magic Number, and both the header 3407and the data portions of the image are secured against corruption by 3408CRC32 checksums. 3409 3410 3411Linux Support: 3412============== 3413 3414Although U-Boot should support any OS or standalone application 3415easily, the main focus has always been on Linux during the design of 3416U-Boot. 3417 3418U-Boot includes many features that so far have been part of some 3419special "boot loader" code within the Linux kernel. Also, any 3420"initrd" images to be used are no longer part of one big Linux image; 3421instead, kernel and "initrd" are separate images. This implementation 3422serves several purposes: 3423 3424- the same features can be used for other OS or standalone 3425 applications (for instance: using compressed images to reduce the 3426 Flash memory footprint) 3427 3428- it becomes much easier to port new Linux kernel versions because 3429 lots of low-level, hardware dependent stuff are done by U-Boot 3430 3431- the same Linux kernel image can now be used with different "initrd" 3432 images; of course this also means that different kernel images can 3433 be run with the same "initrd". This makes testing easier (you don't 3434 have to build a new "zImage.initrd" Linux image when you just 3435 change a file in your "initrd"). Also, a field-upgrade of the 3436 software is easier now. 3437 3438 3439Linux HOWTO: 3440============ 3441 3442Porting Linux to U-Boot based systems: 3443--------------------------------------- 3444 3445U-Boot cannot save you from doing all the necessary modifications to 3446configure the Linux device drivers for use with your target hardware 3447(no, we don't intend to provide a full virtual machine interface to 3448Linux :-). 3449 3450But now you can ignore ALL boot loader code (in arch/powerpc/mbxboot). 3451 3452Just make sure your machine specific header file (for instance 3453include/asm-ppc/tqm8xx.h) includes the same definition of the Board 3454Information structure as we define in include/asm-<arch>/u-boot.h, 3455and make sure that your definition of IMAP_ADDR uses the same value 3456as your U-Boot configuration in CONFIG_SYS_IMMR. 3457 3458Note that U-Boot now has a driver model, a unified model for drivers. 3459If you are adding a new driver, plumb it into driver model. If there 3460is no uclass available, you are encouraged to create one. See 3461doc/driver-model. 3462 3463 3464Configuring the Linux kernel: 3465----------------------------- 3466 3467No specific requirements for U-Boot. Make sure you have some root 3468device (initial ramdisk, NFS) for your target system. 3469 3470 3471Building a Linux Image: 3472----------------------- 3473 3474With U-Boot, "normal" build targets like "zImage" or "bzImage" are 3475not used. If you use recent kernel source, a new build target 3476"uImage" will exist which automatically builds an image usable by 3477U-Boot. Most older kernels also have support for a "pImage" target, 3478which was introduced for our predecessor project PPCBoot and uses a 3479100% compatible format. 3480 3481Example: 3482 3483 make TQM850L_defconfig 3484 make oldconfig 3485 make dep 3486 make uImage 3487 3488The "uImage" build target uses a special tool (in 'tools/mkimage') to 3489encapsulate a compressed Linux kernel image with header information, 3490CRC32 checksum etc. for use with U-Boot. This is what we are doing: 3491 3492* build a standard "vmlinux" kernel image (in ELF binary format): 3493 3494* convert the kernel into a raw binary image: 3495 3496 ${CROSS_COMPILE}-objcopy -O binary \ 3497 -R .note -R .comment \ 3498 -S vmlinux linux.bin 3499 3500* compress the binary image: 3501 3502 gzip -9 linux.bin 3503 3504* package compressed binary image for U-Boot: 3505 3506 mkimage -A ppc -O linux -T kernel -C gzip \ 3507 -a 0 -e 0 -n "Linux Kernel Image" \ 3508 -d linux.bin.gz uImage 3509 3510 3511The "mkimage" tool can also be used to create ramdisk images for use 3512with U-Boot, either separated from the Linux kernel image, or 3513combined into one file. "mkimage" encapsulates the images with a 64 3514byte header containing information about target architecture, 3515operating system, image type, compression method, entry points, time 3516stamp, CRC32 checksums, etc. 3517 3518"mkimage" can be called in two ways: to verify existing images and 3519print the header information, or to build new images. 3520 3521In the first form (with "-l" option) mkimage lists the information 3522contained in the header of an existing U-Boot image; this includes 3523checksum verification: 3524 3525 tools/mkimage -l image 3526 -l ==> list image header information 3527 3528The second form (with "-d" option) is used to build a U-Boot image 3529from a "data file" which is used as image payload: 3530 3531 tools/mkimage -A arch -O os -T type -C comp -a addr -e ep \ 3532 -n name -d data_file image 3533 -A ==> set architecture to 'arch' 3534 -O ==> set operating system to 'os' 3535 -T ==> set image type to 'type' 3536 -C ==> set compression type 'comp' 3537 -a ==> set load address to 'addr' (hex) 3538 -e ==> set entry point to 'ep' (hex) 3539 -n ==> set image name to 'name' 3540 -d ==> use image data from 'datafile' 3541 3542Right now, all Linux kernels for PowerPC systems use the same load 3543address (0x00000000), but the entry point address depends on the 3544kernel version: 3545 3546- 2.2.x kernels have the entry point at 0x0000000C, 3547- 2.3.x and later kernels have the entry point at 0x00000000. 3548 3549So a typical call to build a U-Boot image would read: 3550 3551 -> tools/mkimage -n '2.4.4 kernel for TQM850L' \ 3552 > -A ppc -O linux -T kernel -C gzip -a 0 -e 0 \ 3553 > -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux.gz \ 3554 > examples/uImage.TQM850L 3555 Image Name: 2.4.4 kernel for TQM850L 3556 Created: Wed Jul 19 02:34:59 2000 3557 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3558 Data Size: 335725 Bytes = 327.86 kB = 0.32 MB 3559 Load Address: 0x00000000 3560 Entry Point: 0x00000000 3561 3562To verify the contents of the image (or check for corruption): 3563 3564 -> tools/mkimage -l examples/uImage.TQM850L 3565 Image Name: 2.4.4 kernel for TQM850L 3566 Created: Wed Jul 19 02:34:59 2000 3567 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3568 Data Size: 335725 Bytes = 327.86 kB = 0.32 MB 3569 Load Address: 0x00000000 3570 Entry Point: 0x00000000 3571 3572NOTE: for embedded systems where boot time is critical you can trade 3573speed for memory and install an UNCOMPRESSED image instead: this 3574needs more space in Flash, but boots much faster since it does not 3575need to be uncompressed: 3576 3577 -> gunzip /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux.gz 3578 -> tools/mkimage -n '2.4.4 kernel for TQM850L' \ 3579 > -A ppc -O linux -T kernel -C none -a 0 -e 0 \ 3580 > -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux \ 3581 > examples/uImage.TQM850L-uncompressed 3582 Image Name: 2.4.4 kernel for TQM850L 3583 Created: Wed Jul 19 02:34:59 2000 3584 Image Type: PowerPC Linux Kernel Image (uncompressed) 3585 Data Size: 792160 Bytes = 773.59 kB = 0.76 MB 3586 Load Address: 0x00000000 3587 Entry Point: 0x00000000 3588 3589 3590Similar you can build U-Boot images from a 'ramdisk.image.gz' file 3591when your kernel is intended to use an initial ramdisk: 3592 3593 -> tools/mkimage -n 'Simple Ramdisk Image' \ 3594 > -A ppc -O linux -T ramdisk -C gzip \ 3595 > -d /LinuxPPC/images/SIMPLE-ramdisk.image.gz examples/simple-initrd 3596 Image Name: Simple Ramdisk Image 3597 Created: Wed Jan 12 14:01:50 2000 3598 Image Type: PowerPC Linux RAMDisk Image (gzip compressed) 3599 Data Size: 566530 Bytes = 553.25 kB = 0.54 MB 3600 Load Address: 0x00000000 3601 Entry Point: 0x00000000 3602 3603The "dumpimage" tool can be used to disassemble or list the contents of images 3604built by mkimage. See dumpimage's help output (-h) for details. 3605 3606Installing a Linux Image: 3607------------------------- 3608 3609To downloading a U-Boot image over the serial (console) interface, 3610you must convert the image to S-Record format: 3611 3612 objcopy -I binary -O srec examples/image examples/image.srec 3613 3614The 'objcopy' does not understand the information in the U-Boot 3615image header, so the resulting S-Record file will be relative to 3616address 0x00000000. To load it to a given address, you need to 3617specify the target address as 'offset' parameter with the 'loads' 3618command. 3619 3620Example: install the image to address 0x40100000 (which on the 3621TQM8xxL is in the first Flash bank): 3622 3623 => erase 40100000 401FFFFF 3624 3625 .......... done 3626 Erased 8 sectors 3627 3628 => loads 40100000 3629 ## Ready for S-Record download ... 3630 ~>examples/image.srec 3631 1 2 3 4 5 6 7 8 9 10 11 12 13 ... 3632 ... 3633 15989 15990 15991 15992 3634 [file transfer complete] 3635 [connected] 3636 ## Start Addr = 0x00000000 3637 3638 3639You can check the success of the download using the 'iminfo' command; 3640this includes a checksum verification so you can be sure no data 3641corruption happened: 3642 3643 => imi 40100000 3644 3645 ## Checking Image at 40100000 ... 3646 Image Name: 2.2.13 for initrd on TQM850L 3647 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3648 Data Size: 335725 Bytes = 327 kB = 0 MB 3649 Load Address: 00000000 3650 Entry Point: 0000000c 3651 Verifying Checksum ... OK 3652 3653 3654Boot Linux: 3655----------- 3656 3657The "bootm" command is used to boot an application that is stored in 3658memory (RAM or Flash). In case of a Linux kernel image, the contents 3659of the "bootargs" environment variable is passed to the kernel as 3660parameters. You can check and modify this variable using the 3661"printenv" and "setenv" commands: 3662 3663 3664 => printenv bootargs 3665 bootargs=root=/dev/ram 3666 3667 => setenv bootargs root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2 3668 3669 => printenv bootargs 3670 bootargs=root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2 3671 3672 => bootm 40020000 3673 ## Booting Linux kernel at 40020000 ... 3674 Image Name: 2.2.13 for NFS on TQM850L 3675 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3676 Data Size: 381681 Bytes = 372 kB = 0 MB 3677 Load Address: 00000000 3678 Entry Point: 0000000c 3679 Verifying Checksum ... OK 3680 Uncompressing Kernel Image ... OK 3681 Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:35:17 MEST 2000 3682 Boot arguments: root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2 3683 time_init: decrementer frequency = 187500000/60 3684 Calibrating delay loop... 49.77 BogoMIPS 3685 Memory: 15208k available (700k kernel code, 444k data, 32k init) [c0000000,c1000000] 3686 ... 3687 3688If you want to boot a Linux kernel with initial RAM disk, you pass 3689the memory addresses of both the kernel and the initrd image (PPBCOOT 3690format!) to the "bootm" command: 3691 3692 => imi 40100000 40200000 3693 3694 ## Checking Image at 40100000 ... 3695 Image Name: 2.2.13 for initrd on TQM850L 3696 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3697 Data Size: 335725 Bytes = 327 kB = 0 MB 3698 Load Address: 00000000 3699 Entry Point: 0000000c 3700 Verifying Checksum ... OK 3701 3702 ## Checking Image at 40200000 ... 3703 Image Name: Simple Ramdisk Image 3704 Image Type: PowerPC Linux RAMDisk Image (gzip compressed) 3705 Data Size: 566530 Bytes = 553 kB = 0 MB 3706 Load Address: 00000000 3707 Entry Point: 00000000 3708 Verifying Checksum ... OK 3709 3710 => bootm 40100000 40200000 3711 ## Booting Linux kernel at 40100000 ... 3712 Image Name: 2.2.13 for initrd on TQM850L 3713 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3714 Data Size: 335725 Bytes = 327 kB = 0 MB 3715 Load Address: 00000000 3716 Entry Point: 0000000c 3717 Verifying Checksum ... OK 3718 Uncompressing Kernel Image ... OK 3719 ## Loading RAMDisk Image at 40200000 ... 3720 Image Name: Simple Ramdisk Image 3721 Image Type: PowerPC Linux RAMDisk Image (gzip compressed) 3722 Data Size: 566530 Bytes = 553 kB = 0 MB 3723 Load Address: 00000000 3724 Entry Point: 00000000 3725 Verifying Checksum ... OK 3726 Loading Ramdisk ... OK 3727 Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:32:08 MEST 2000 3728 Boot arguments: root=/dev/ram 3729 time_init: decrementer frequency = 187500000/60 3730 Calibrating delay loop... 49.77 BogoMIPS 3731 ... 3732 RAMDISK: Compressed image found at block 0 3733 VFS: Mounted root (ext2 filesystem). 3734 3735 bash# 3736 3737Boot Linux and pass a flat device tree: 3738----------- 3739 3740First, U-Boot must be compiled with the appropriate defines. See the section 3741titled "Linux Kernel Interface" above for a more in depth explanation. The 3742following is an example of how to start a kernel and pass an updated 3743flat device tree: 3744 3745=> print oftaddr 3746oftaddr=0x300000 3747=> print oft 3748oft=oftrees/mpc8540ads.dtb 3749=> tftp $oftaddr $oft 3750Speed: 1000, full duplex 3751Using TSEC0 device 3752TFTP from server 192.168.1.1; our IP address is 192.168.1.101 3753Filename 'oftrees/mpc8540ads.dtb'. 3754Load address: 0x300000 3755Loading: # 3756done 3757Bytes transferred = 4106 (100a hex) 3758=> tftp $loadaddr $bootfile 3759Speed: 1000, full duplex 3760Using TSEC0 device 3761TFTP from server 192.168.1.1; our IP address is 192.168.1.2 3762Filename 'uImage'. 3763Load address: 0x200000 3764Loading:############ 3765done 3766Bytes transferred = 1029407 (fb51f hex) 3767=> print loadaddr 3768loadaddr=200000 3769=> print oftaddr 3770oftaddr=0x300000 3771=> bootm $loadaddr - $oftaddr 3772## Booting image at 00200000 ... 3773 Image Name: Linux-2.6.17-dirty 3774 Image Type: PowerPC Linux Kernel Image (gzip compressed) 3775 Data Size: 1029343 Bytes = 1005.2 kB 3776 Load Address: 00000000 3777 Entry Point: 00000000 3778 Verifying Checksum ... OK 3779 Uncompressing Kernel Image ... OK 3780Booting using flat device tree at 0x300000 3781Using MPC85xx ADS machine description 3782Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb 3783[snip] 3784 3785 3786More About U-Boot Image Types: 3787------------------------------ 3788 3789U-Boot supports the following image types: 3790 3791 "Standalone Programs" are directly runnable in the environment 3792 provided by U-Boot; it is expected that (if they behave 3793 well) you can continue to work in U-Boot after return from 3794 the Standalone Program. 3795 "OS Kernel Images" are usually images of some Embedded OS which 3796 will take over control completely. Usually these programs 3797 will install their own set of exception handlers, device 3798 drivers, set up the MMU, etc. - this means, that you cannot 3799 expect to re-enter U-Boot except by resetting the CPU. 3800 "RAMDisk Images" are more or less just data blocks, and their 3801 parameters (address, size) are passed to an OS kernel that is 3802 being started. 3803 "Multi-File Images" contain several images, typically an OS 3804 (Linux) kernel image and one or more data images like 3805 RAMDisks. This construct is useful for instance when you want 3806 to boot over the network using BOOTP etc., where the boot 3807 server provides just a single image file, but you want to get 3808 for instance an OS kernel and a RAMDisk image. 3809 3810 "Multi-File Images" start with a list of image sizes, each 3811 image size (in bytes) specified by an "uint32_t" in network 3812 byte order. This list is terminated by an "(uint32_t)0". 3813 Immediately after the terminating 0 follow the images, one by 3814 one, all aligned on "uint32_t" boundaries (size rounded up to 3815 a multiple of 4 bytes). 3816 3817 "Firmware Images" are binary images containing firmware (like 3818 U-Boot or FPGA images) which usually will be programmed to 3819 flash memory. 3820 3821 "Script files" are command sequences that will be executed by 3822 U-Boot's command interpreter; this feature is especially 3823 useful when you configure U-Boot to use a real shell (hush) 3824 as command interpreter. 3825 3826Booting the Linux zImage: 3827------------------------- 3828 3829On some platforms, it's possible to boot Linux zImage. This is done 3830using the "bootz" command. The syntax of "bootz" command is the same 3831as the syntax of "bootm" command. 3832 3833Note, defining the CONFIG_SUPPORT_RAW_INITRD allows user to supply 3834kernel with raw initrd images. The syntax is slightly different, the 3835address of the initrd must be augmented by it's size, in the following 3836format: "<initrd addres>:<initrd size>". 3837 3838 3839Standalone HOWTO: 3840================= 3841 3842One of the features of U-Boot is that you can dynamically load and 3843run "standalone" applications, which can use some resources of 3844U-Boot like console I/O functions or interrupt services. 3845 3846Two simple examples are included with the sources: 3847 3848"Hello World" Demo: 3849------------------- 3850 3851'examples/hello_world.c' contains a small "Hello World" Demo 3852application; it is automatically compiled when you build U-Boot. 3853It's configured to run at address 0x00040004, so you can play with it 3854like that: 3855 3856 => loads 3857 ## Ready for S-Record download ... 3858 ~>examples/hello_world.srec 3859 1 2 3 4 5 6 7 8 9 10 11 ... 3860 [file transfer complete] 3861 [connected] 3862 ## Start Addr = 0x00040004 3863 3864 => go 40004 Hello World! This is a test. 3865 ## Starting application at 0x00040004 ... 3866 Hello World 3867 argc = 7 3868 argv[0] = "40004" 3869 argv[1] = "Hello" 3870 argv[2] = "World!" 3871 argv[3] = "This" 3872 argv[4] = "is" 3873 argv[5] = "a" 3874 argv[6] = "test." 3875 argv[7] = "<NULL>" 3876 Hit any key to exit ... 3877 3878 ## Application terminated, rc = 0x0 3879 3880Another example, which demonstrates how to register a CPM interrupt 3881handler with the U-Boot code, can be found in 'examples/timer.c'. 3882Here, a CPM timer is set up to generate an interrupt every second. 3883The interrupt service routine is trivial, just printing a '.' 3884character, but this is just a demo program. The application can be 3885controlled by the following keys: 3886 3887 ? - print current values og the CPM Timer registers 3888 b - enable interrupts and start timer 3889 e - stop timer and disable interrupts 3890 q - quit application 3891 3892 => loads 3893 ## Ready for S-Record download ... 3894 ~>examples/timer.srec 3895 1 2 3 4 5 6 7 8 9 10 11 ... 3896 [file transfer complete] 3897 [connected] 3898 ## Start Addr = 0x00040004 3899 3900 => go 40004 3901 ## Starting application at 0x00040004 ... 3902 TIMERS=0xfff00980 3903 Using timer 1 3904 tgcr @ 0xfff00980, tmr @ 0xfff00990, trr @ 0xfff00994, tcr @ 0xfff00998, tcn @ 0xfff0099c, ter @ 0xfff009b0 3905 3906Hit 'b': 3907 [q, b, e, ?] Set interval 1000000 us 3908 Enabling timer 3909Hit '?': 3910 [q, b, e, ?] ........ 3911 tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0xef6, ter=0x0 3912Hit '?': 3913 [q, b, e, ?] . 3914 tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x2ad4, ter=0x0 3915Hit '?': 3916 [q, b, e, ?] . 3917 tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x1efc, ter=0x0 3918Hit '?': 3919 [q, b, e, ?] . 3920 tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x169d, ter=0x0 3921Hit 'e': 3922 [q, b, e, ?] ...Stopping timer 3923Hit 'q': 3924 [q, b, e, ?] ## Application terminated, rc = 0x0 3925 3926 3927Minicom warning: 3928================ 3929 3930Over time, many people have reported problems when trying to use the 3931"minicom" terminal emulation program for serial download. I (wd) 3932consider minicom to be broken, and recommend not to use it. Under 3933Unix, I recommend to use C-Kermit for general purpose use (and 3934especially for kermit binary protocol download ("loadb" command), and 3935use "cu" for S-Record download ("loads" command). See 3936https://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3. 3937for help with kermit. 3938 3939 3940Nevertheless, if you absolutely want to use it try adding this 3941configuration to your "File transfer protocols" section: 3942 3943 Name Program Name U/D FullScr IO-Red. Multi 3944 X kermit /usr/bin/kermit -i -l %l -s Y U Y N N 3945 Y kermit /usr/bin/kermit -i -l %l -r N D Y N N 3946 3947 3948NetBSD Notes: 3949============= 3950 3951Starting at version 0.9.2, U-Boot supports NetBSD both as host 3952(build U-Boot) and target system (boots NetBSD/mpc8xx). 3953 3954Building requires a cross environment; it is known to work on 3955NetBSD/i386 with the cross-powerpc-netbsd-1.3 package (you will also 3956need gmake since the Makefiles are not compatible with BSD make). 3957Note that the cross-powerpc package does not install include files; 3958attempting to build U-Boot will fail because <machine/ansi.h> is 3959missing. This file has to be installed and patched manually: 3960 3961 # cd /usr/pkg/cross/powerpc-netbsd/include 3962 # mkdir powerpc 3963 # ln -s powerpc machine 3964 # cp /usr/src/sys/arch/powerpc/include/ansi.h powerpc/ansi.h 3965 # ${EDIT} powerpc/ansi.h ## must remove __va_list, _BSD_VA_LIST 3966 3967Native builds *don't* work due to incompatibilities between native 3968and U-Boot include files. 3969 3970Booting assumes that (the first part of) the image booted is a 3971stage-2 loader which in turn loads and then invokes the kernel 3972proper. Loader sources will eventually appear in the NetBSD source 3973tree (probably in sys/arc/mpc8xx/stand/u-boot_stage2/); in the 3974meantime, see ftp://ftp.denx.de/pub/u-boot/ppcboot_stage2.tar.gz 3975 3976 3977Implementation Internals: 3978========================= 3979 3980The following is not intended to be a complete description of every 3981implementation detail. However, it should help to understand the 3982inner workings of U-Boot and make it easier to port it to custom 3983hardware. 3984 3985 3986Initial Stack, Global Data: 3987--------------------------- 3988 3989The implementation of U-Boot is complicated by the fact that U-Boot 3990starts running out of ROM (flash memory), usually without access to 3991system RAM (because the memory controller is not initialized yet). 3992This means that we don't have writable Data or BSS segments, and BSS 3993is not initialized as zero. To be able to get a C environment working 3994at all, we have to allocate at least a minimal stack. Implementation 3995options for this are defined and restricted by the CPU used: Some CPU 3996models provide on-chip memory (like the IMMR area on MPC8xx and 3997MPC826x processors), on others (parts of) the data cache can be 3998locked as (mis-) used as memory, etc. 3999 4000 Chris Hallinan posted a good summary of these issues to the 4001 U-Boot mailing list: 4002 4003 Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)? 4004 From: "Chris Hallinan" <clh@net1plus.com> 4005 Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET) 4006 ... 4007 4008 Correct me if I'm wrong, folks, but the way I understand it 4009 is this: Using DCACHE as initial RAM for Stack, etc, does not 4010 require any physical RAM backing up the cache. The cleverness 4011 is that the cache is being used as a temporary supply of 4012 necessary storage before the SDRAM controller is setup. It's 4013 beyond the scope of this list to explain the details, but you 4014 can see how this works by studying the cache architecture and 4015 operation in the architecture and processor-specific manuals. 4016 4017 OCM is On Chip Memory, which I believe the 405GP has 4K. It 4018 is another option for the system designer to use as an 4019 initial stack/RAM area prior to SDRAM being available. Either 4020 option should work for you. Using CS 4 should be fine if your 4021 board designers haven't used it for something that would 4022 cause you grief during the initial boot! It is frequently not 4023 used. 4024 4025 CONFIG_SYS_INIT_RAM_ADDR should be somewhere that won't interfere 4026 with your processor/board/system design. The default value 4027 you will find in any recent u-boot distribution in 4028 walnut.h should work for you. I'd set it to a value larger 4029 than your SDRAM module. If you have a 64MB SDRAM module, set 4030 it above 400_0000. Just make sure your board has no resources 4031 that are supposed to respond to that address! That code in 4032 start.S has been around a while and should work as is when 4033 you get the config right. 4034 4035 -Chris Hallinan 4036 DS4.COM, Inc. 4037 4038It is essential to remember this, since it has some impact on the C 4039code for the initialization procedures: 4040 4041* Initialized global data (data segment) is read-only. Do not attempt 4042 to write it. 4043 4044* Do not use any uninitialized global data (or implicitly initialized 4045 as zero data - BSS segment) at all - this is undefined, initiali- 4046 zation is performed later (when relocating to RAM). 4047 4048* Stack space is very limited. Avoid big data buffers or things like 4049 that. 4050 4051Having only the stack as writable memory limits means we cannot use 4052normal global data to share information between the code. But it 4053turned out that the implementation of U-Boot can be greatly 4054simplified by making a global data structure (gd_t) available to all 4055functions. We could pass a pointer to this data as argument to _all_ 4056functions, but this would bloat the code. Instead we use a feature of 4057the GCC compiler (Global Register Variables) to share the data: we 4058place a pointer (gd) to the global data into a register which we 4059reserve for this purpose. 4060 4061When choosing a register for such a purpose we are restricted by the 4062relevant (E)ABI specifications for the current architecture, and by 4063GCC's implementation. 4064 4065For PowerPC, the following registers have specific use: 4066 R1: stack pointer 4067 R2: reserved for system use 4068 R3-R4: parameter passing and return values 4069 R5-R10: parameter passing 4070 R13: small data area pointer 4071 R30: GOT pointer 4072 R31: frame pointer 4073 4074 (U-Boot also uses R12 as internal GOT pointer. r12 4075 is a volatile register so r12 needs to be reset when 4076 going back and forth between asm and C) 4077 4078 ==> U-Boot will use R2 to hold a pointer to the global data 4079 4080 Note: on PPC, we could use a static initializer (since the 4081 address of the global data structure is known at compile time), 4082 but it turned out that reserving a register results in somewhat 4083 smaller code - although the code savings are not that big (on 4084 average for all boards 752 bytes for the whole U-Boot image, 4085 624 text + 127 data). 4086 4087On ARM, the following registers are used: 4088 4089 R0: function argument word/integer result 4090 R1-R3: function argument word 4091 R9: platform specific 4092 R10: stack limit (used only if stack checking is enabled) 4093 R11: argument (frame) pointer 4094 R12: temporary workspace 4095 R13: stack pointer 4096 R14: link register 4097 R15: program counter 4098 4099 ==> U-Boot will use R9 to hold a pointer to the global data 4100 4101 Note: on ARM, only R_ARM_RELATIVE relocations are supported. 4102 4103On Nios II, the ABI is documented here: 4104 https://www.altera.com/literature/hb/nios2/n2cpu_nii51016.pdf 4105 4106 ==> U-Boot will use gp to hold a pointer to the global data 4107 4108 Note: on Nios II, we give "-G0" option to gcc and don't use gp 4109 to access small data sections, so gp is free. 4110 4111On NDS32, the following registers are used: 4112 4113 R0-R1: argument/return 4114 R2-R5: argument 4115 R15: temporary register for assembler 4116 R16: trampoline register 4117 R28: frame pointer (FP) 4118 R29: global pointer (GP) 4119 R30: link register (LP) 4120 R31: stack pointer (SP) 4121 PC: program counter (PC) 4122 4123 ==> U-Boot will use R10 to hold a pointer to the global data 4124 4125NOTE: DECLARE_GLOBAL_DATA_PTR must be used with file-global scope, 4126or current versions of GCC may "optimize" the code too much. 4127 4128On RISC-V, the following registers are used: 4129 4130 x0: hard-wired zero (zero) 4131 x1: return address (ra) 4132 x2: stack pointer (sp) 4133 x3: global pointer (gp) 4134 x4: thread pointer (tp) 4135 x5: link register (t0) 4136 x8: frame pointer (fp) 4137 x10-x11: arguments/return values (a0-1) 4138 x12-x17: arguments (a2-7) 4139 x28-31: temporaries (t3-6) 4140 pc: program counter (pc) 4141 4142 ==> U-Boot will use gp to hold a pointer to the global data 4143 4144Memory Management: 4145------------------ 4146 4147U-Boot runs in system state and uses physical addresses, i.e. the 4148MMU is not used either for address mapping nor for memory protection. 4149 4150The available memory is mapped to fixed addresses using the memory 4151controller. In this process, a contiguous block is formed for each 4152memory type (Flash, SDRAM, SRAM), even when it consists of several 4153physical memory banks. 4154 4155U-Boot is installed in the first 128 kB of the first Flash bank (on 4156TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After 4157booting and sizing and initializing DRAM, the code relocates itself 4158to the upper end of DRAM. Immediately below the U-Boot code some 4159memory is reserved for use by malloc() [see CONFIG_SYS_MALLOC_LEN 4160configuration setting]. Below that, a structure with global Board 4161Info data is placed, followed by the stack (growing downward). 4162 4163Additionally, some exception handler code is copied to the low 8 kB 4164of DRAM (0x00000000 ... 0x00001FFF). 4165 4166So a typical memory configuration with 16 MB of DRAM could look like 4167this: 4168 4169 0x0000 0000 Exception Vector code 4170 : 4171 0x0000 1FFF 4172 0x0000 2000 Free for Application Use 4173 : 4174 : 4175 4176 : 4177 : 4178 0x00FB FF20 Monitor Stack (Growing downward) 4179 0x00FB FFAC Board Info Data and permanent copy of global data 4180 0x00FC 0000 Malloc Arena 4181 : 4182 0x00FD FFFF 4183 0x00FE 0000 RAM Copy of Monitor Code 4184 ... eventually: LCD or video framebuffer 4185 ... eventually: pRAM (Protected RAM - unchanged by reset) 4186 0x00FF FFFF [End of RAM] 4187 4188 4189System Initialization: 4190---------------------- 4191 4192In the reset configuration, U-Boot starts at the reset entry point 4193(on most PowerPC systems at address 0x00000100). Because of the reset 4194configuration for CS0# this is a mirror of the on board Flash memory. 4195To be able to re-map memory U-Boot then jumps to its link address. 4196To be able to implement the initialization code in C, a (small!) 4197initial stack is set up in the internal Dual Ported RAM (in case CPUs 4198which provide such a feature like), or in a locked part of the data 4199cache. After that, U-Boot initializes the CPU core, the caches and 4200the SIU. 4201 4202Next, all (potentially) available memory banks are mapped using a 4203preliminary mapping. For example, we put them on 512 MB boundaries 4204(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash 4205on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is 4206programmed for SDRAM access. Using the temporary configuration, a 4207simple memory test is run that determines the size of the SDRAM 4208banks. 4209 4210When there is more than one SDRAM bank, and the banks are of 4211different size, the largest is mapped first. For equal size, the first 4212bank (CS2#) is mapped first. The first mapping is always for address 42130x00000000, with any additional banks following immediately to create 4214contiguous memory starting from 0. 4215 4216Then, the monitor installs itself at the upper end of the SDRAM area 4217and allocates memory for use by malloc() and for the global Board 4218Info data; also, the exception vector code is copied to the low RAM 4219pages, and the final stack is set up. 4220 4221Only after this relocation will you have a "normal" C environment; 4222until that you are restricted in several ways, mostly because you are 4223running from ROM, and because the code will have to be relocated to a 4224new address in RAM. 4225 4226 4227U-Boot Porting Guide: 4228---------------------- 4229 4230[Based on messages by Jerry Van Baren in the U-Boot-Users mailing 4231list, October 2002] 4232 4233 4234int main(int argc, char *argv[]) 4235{ 4236 sighandler_t no_more_time; 4237 4238 signal(SIGALRM, no_more_time); 4239 alarm(PROJECT_DEADLINE - toSec (3 * WEEK)); 4240 4241 if (available_money > available_manpower) { 4242 Pay consultant to port U-Boot; 4243 return 0; 4244 } 4245 4246 Download latest U-Boot source; 4247 4248 Subscribe to u-boot mailing list; 4249 4250 if (clueless) 4251 email("Hi, I am new to U-Boot, how do I get started?"); 4252 4253 while (learning) { 4254 Read the README file in the top level directory; 4255 Read https://www.denx.de/wiki/bin/view/DULG/Manual; 4256 Read applicable doc/README.*; 4257 Read the source, Luke; 4258 /* find . -name "*.[chS]" | xargs grep -i <keyword> */ 4259 } 4260 4261 if (available_money > toLocalCurrency ($2500)) 4262 Buy a BDI3000; 4263 else 4264 Add a lot of aggravation and time; 4265 4266 if (a similar board exists) { /* hopefully... */ 4267 cp -a board/<similar> board/<myboard> 4268 cp include/configs/<similar>.h include/configs/<myboard>.h 4269 } else { 4270 Create your own board support subdirectory; 4271 Create your own board include/configs/<myboard>.h file; 4272 } 4273 Edit new board/<myboard> files 4274 Edit new include/configs/<myboard>.h 4275 4276 while (!accepted) { 4277 while (!running) { 4278 do { 4279 Add / modify source code; 4280 } until (compiles); 4281 Debug; 4282 if (clueless) 4283 email("Hi, I am having problems..."); 4284 } 4285 Send patch file to the U-Boot email list; 4286 if (reasonable critiques) 4287 Incorporate improvements from email list code review; 4288 else 4289 Defend code as written; 4290 } 4291 4292 return 0; 4293} 4294 4295void no_more_time (int sig) 4296{ 4297 hire_a_guru(); 4298} 4299 4300 4301Coding Standards: 4302----------------- 4303 4304All contributions to U-Boot should conform to the Linux kernel 4305coding style; see the kernel coding style guide at 4306https://www.kernel.org/doc/html/latest/process/coding-style.html, and the 4307script "scripts/Lindent" in your Linux kernel source directory. 4308 4309Source files originating from a different project (for example the 4310MTD subsystem) are generally exempt from these guidelines and are not 4311reformatted to ease subsequent migration to newer versions of those 4312sources. 4313 4314Please note that U-Boot is implemented in C (and to some small parts in 4315Assembler); no C++ is used, so please do not use C++ style comments (//) 4316in your code. 4317 4318Please also stick to the following formatting rules: 4319- remove any trailing white space 4320- use TAB characters for indentation and vertical alignment, not spaces 4321- make sure NOT to use DOS '\r\n' line feeds 4322- do not add more than 2 consecutive empty lines to source files 4323- do not add trailing empty lines to source files 4324 4325Submissions which do not conform to the standards may be returned 4326with a request to reformat the changes. 4327 4328 4329Submitting Patches: 4330------------------- 4331 4332Since the number of patches for U-Boot is growing, we need to 4333establish some rules. Submissions which do not conform to these rules 4334may be rejected, even when they contain important and valuable stuff. 4335 4336Please see https://www.denx.de/wiki/U-Boot/Patches for details. 4337 4338Patches shall be sent to the u-boot mailing list <u-boot@lists.denx.de>; 4339see https://lists.denx.de/listinfo/u-boot 4340 4341When you send a patch, please include the following information with 4342it: 4343 4344* For bug fixes: a description of the bug and how your patch fixes 4345 this bug. Please try to include a way of demonstrating that the 4346 patch actually fixes something. 4347 4348* For new features: a description of the feature and your 4349 implementation. 4350 4351* For major contributions, add a MAINTAINERS file with your 4352 information and associated file and directory references. 4353 4354* When you add support for a new board, don't forget to add a 4355 maintainer e-mail address to the boards.cfg file, too. 4356 4357* If your patch adds new configuration options, don't forget to 4358 document these in the README file. 4359 4360* The patch itself. If you are using git (which is *strongly* 4361 recommended) you can easily generate the patch using the 4362 "git format-patch". If you then use "git send-email" to send it to 4363 the U-Boot mailing list, you will avoid most of the common problems 4364 with some other mail clients. 4365 4366 If you cannot use git, use "diff -purN OLD NEW". If your version of 4367 diff does not support these options, then get the latest version of 4368 GNU diff. 4369 4370 The current directory when running this command shall be the parent 4371 directory of the U-Boot source tree (i. e. please make sure that 4372 your patch includes sufficient directory information for the 4373 affected files). 4374 4375 We prefer patches as plain text. MIME attachments are discouraged, 4376 and compressed attachments must not be used. 4377 4378* If one logical set of modifications affects or creates several 4379 files, all these changes shall be submitted in a SINGLE patch file. 4380 4381* Changesets that contain different, unrelated modifications shall be 4382 submitted as SEPARATE patches, one patch per changeset. 4383 4384 4385Notes: 4386 4387* Before sending the patch, run the buildman script on your patched 4388 source tree and make sure that no errors or warnings are reported 4389 for any of the boards. 4390 4391* Keep your modifications to the necessary minimum: A patch 4392 containing several unrelated changes or arbitrary reformats will be 4393 returned with a request to re-formatting / split it. 4394 4395* If you modify existing code, make sure that your new code does not 4396 add to the memory footprint of the code ;-) Small is beautiful! 4397 When adding new features, these should compile conditionally only 4398 (using #ifdef), and the resulting code with the new feature 4399 disabled must not need more memory than the old code without your 4400 modification. 4401 4402* Remember that there is a size limit of 100 kB per message on the 4403 u-boot mailing list. Bigger patches will be moderated. If they are 4404 reasonable and not too big, they will be acknowledged. But patches 4405 bigger than the size limit should be avoided. 4406