diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.LED_display | 1 | ||||
| -rw-r--r-- | doc/README.POST | 19 | ||||
| -rw-r--r-- | doc/README.arm-relocation | 238 | ||||
| -rw-r--r-- | doc/README.fsl-ddr | 14 | ||||
| -rw-r--r-- | doc/README.scrapyard | 30 | ||||
| -rw-r--r-- | doc/README.ubi | 144 | ||||
| -rw-r--r-- | doc/feature-removal-schedule.txt | 27 |
7 files changed, 245 insertions, 228 deletions
diff --git a/doc/README.LED_display b/doc/README.LED_display index 521746e12..19977ea7e 100644 --- a/doc/README.LED_display +++ b/doc/README.LED_display @@ -14,7 +14,6 @@ This function should control the state of the LED display. Argument is an ORed combination of the following values: DISPLAY_CLEAR -- clear the display DISPLAY_HOME -- set the position to the beginning of display - DISPLAY_MARK -- enable mark (decimal point), if implemented int display_putc(char c); diff --git a/doc/README.POST b/doc/README.POST index eeb218d39..6815d491c 100644 --- a/doc/README.POST +++ b/doc/README.POST @@ -659,12 +659,19 @@ not need any modifications for porting them to another board/CPU. 2.2.2.1. I2C test For verifying the I2C bus, a full I2C bus scanning will be performed -using the i2c_probe() routine. If any I2C device is found, the test -will be considered as passed, otherwise failed. This particular way -will be used because it provides the most common method of testing. -For example, using the internal loopback mode of the CPM I2C -controller for testing would not work on boards where the software -I2C driver (also known as bit-banged driver) is used. +using the i2c_probe() routine. If a board defines +CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices +listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional +devices are detected. If CONFIG_SYS_POST_I2C_ADDRS is not defined +the test will pass if any I2C device is found. + +The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C +devices which may or may not be present when using +CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless +if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not. +This is useful in cases when I2C devices are optional (eg on a +daughtercard that may or may not be present) or not critical +to board operation. 2.2.2.2. Watchdog timer test diff --git a/doc/README.arm-relocation b/doc/README.arm-relocation index 4ab3c7c0b..c0957c210 100644 --- a/doc/README.arm-relocation +++ b/doc/README.arm-relocation @@ -1,49 +1,46 @@ To make relocation on arm working, the following changes are done: -Add new compilerflag: +At arch level: add linker flag -pie --fPIC + This causes the linker to generate fixup tables .rel.dyn and .dynsym, + which must be applied to the relocated image before transferring + control to it. - -> compiler generates position independent code + These fixups are described in the ARM ELF documentation as type 23 + (program-base-relative) and 2 (symbol-relative) -changes in board code: +At cpu level: modify linker file and add a relocation and fixup loop -- dram_init: - - bd pointer is now at this point not accessible, so only - detect the real dramsize, and store it in gd->ram_size. - best detected with get_ram_size(); - ToDo: move there also the dram initialization on boards where - it is possible. - - setup the bd_t dram bank info in the new function - dram_init_banksize(). + the linker file must be modified to include the .rel.dyn and .dynsym + tables in the binary image, and to provide symbols for the relocation + code to access these tables -- board.c code is adapted from ppc code + The relocation and fixup loop must be executed after executing + board_init_f at initial location and before executing board_init_r + at final location. -- undef CONFIG_RELOC_FIXUP_WORKS +At board level: - -> cmdtabl, and subcommand table must be handled from "hand" - collected in section "__datarellocal_start". + dram_init(): bd pointer is now at this point not accessible, so only + detect the real dramsize, and store it in gd->ram_size. Bst detected + with get_ram_size(). - - How To fixup the sections: +TODO: move also dram initialization there on boards where it is possible. - __datarel_start, __datarelrolocal_start, __datarellocal_start and - __datarelro_start + Setup of the the bd_t dram bank info is done in the new function + dram_init_banksize() called after bd is accessible. - automatically? Then it should be possible to define again - CONFIG_RELOC_FIXUP_WORKS +At lib level: -- irq stack setup is now not longer on a fix position, instead it is - calculated in board_init_f, and stored in gd->irq_sp + Board.c code is adapted from ppc code -------------------------------------------------------------------------------------- +* WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING * -To compile a board without relocation, define CONFIG_SYS_ARM_WITHOUT_RELOC -This possibility will removed!! So please fix your board to compile without -CONFIG_SYS_ARM_WITHOUT_RELOC defined!!! +Boards which are not fixed to support relocation will be REMOVED! -------------------------------------------------------------------------------------- +----------------------------------------------------------------------------- -For boards which boot from nand_spl, it is possible to save a copy +For boards which boot from nand_spl, it is possible to save one copy if CONFIG_SYS_TEXT_BASE == relocation address! This prevents that uboot code is copied again in relocate_code(). @@ -64,9 +61,9 @@ f) u-boot code steps through board_init_f() and calculates If CONFIG_SYS_TEXT_BASE == relocation address, the copying of u-boot in f) could be saved. -------------------------------------------------------------------------------------- +----------------------------------------------------------------------------- -ToDo: +TODO - fill in bd_t infos (check) - adapt all boards @@ -80,7 +77,7 @@ ToDo: - new function dram_init_banksize() is actual board specific. Maybe we make a weak default function in arch/arm/lib/board.c ? -------------------------------------------------------------------------------------- +----------------------------------------------------------------------------- Relocation with NAND_SPL (example for the tx25): @@ -88,168 +85,21 @@ Relocation with NAND_SPL (example for the tx25): and start with code execution on this address. - The First page contains u-boot code from u-boot:nand_spl/nand_boot_fsl_nfc.c - which inits the dram, cpu registers, reloacte itself to CONFIG_SYS_TEXT_BASE and loads + which inits the dram, cpu registers, reloacte itself to CONFIG_SYS_TEXT_BASE and loads the "real" u-boot to CONFIG_SYS_NAND_U_BOOT_DST and starts execution @CONFIG_SYS_NAND_U_BOOT_START -- This u-boot does no ram int, nor cpu register setup. Just looks - where it have to relocate and relocate itself to this address. - If relocate address = CONFIG_SYS_TEXT_BASE(not the same, as the TEXT_BASE - from the nand_spl code), no need to copy, just go on with bss clear - and jump to board_init_r. - -------------------------------------------------------------------------------------- - -Relocation: -How to translate flash addresses in GOT to ram addresses. -This is automagically done from code, but this example -shows, how this magic code works ;-) -(example on the qong board) - -Find a variable: - -a) search it in System.map -(for example flash_info) - -a005b4c0 B BootpID -a005b4c4 B BootpTry -a005b4c8 b slave -a005b4cc B flash_info -^^^^^^^^ -a005c908 b saved_sector.4002 -a005c910 b cfi_mtd_info -a005c9c0 b cfi_mtd_names -a005c9d0 B mtd_table - ---------------------------------------- - -b) create hexdump from u-boot code: - -hexdump -C u-boot > gnlmpfhex - ---------------------------------------- - -c) search the variables address in the hexdump - - -* -0005fc80 00 00 00 00 00 00 00 00 2c 06 01 a0 18 cd 05 a0 |........,.......| -0005fc90 9c d4 05 a0 bc b4 05 a0 1c 7f 05 a0 f0 05 01 a0 |................| -0005fca0 08 5a 04 a0 1c ab 05 a0 ec a4 05 a0 98 c3 01 a0 |.Z..............| -0005fcb0 a0 d6 05 a0 04 71 05 a0 c0 f9 00 a0 3c cd 05 a0 |.....q......<...| -0005fcc0 cc b4 05 a0 f0 fa 00 a0 f0 d6 05 a0 10 86 05 a0 |................| - ^^^^^^^^^^^ -0005fcd0 a4 16 06 a0 dc 64 05 a0 18 86 05 a0 52 48 05 a0 |.....d......RH..| -0005fce0 c0 86 05 a0 24 6e 02 a0 b4 6c 05 a0 b0 94 01 a0 |....$n...l......| -0005fcf0 1c 86 05 a0 50 85 05 a0 d4 0c 06 a0 bc 0b 06 a0 |....P...........| - - --> 0005fcc0 - ----------------------------------------- - -d) know we calculate this address in RAM - - - 8ff08000 (new address of code in RAM *1) - -+ 0005fcc0 - -- 00008000 (offset of text *2) - ----------- - - 8ff5fcc0 -> Addr GOT in RAM - -*1: -activate debug and look for the line: -Now running in RAM - U-Boot at: 8ff08000 - ^^^^^^^^ - new address of u-boot code in RAM - -*2: -Section Headers: - [Nr] Name Type Addr Off Size ES Flg Lk Inf Al - [ 0] NULL 00000000 000000 000000 00 0 0 0 - [ 1] .text PROGBITS a0000000 008000 04599c 00 AX 0 0 32 - ^^^^^^ - Offset of text - ----------------------------------------- +- This u-boot does no RAM init, nor CPU register setup. Just look + where it has to copy and relocate itself to this address. If + relocate address = CONFIG_SYS_TEXT_BASE (not the same, as the + CONFIG_SYS_TEXT_BASE from the nand_spl code), then there is no need + to copy, just go on with bss clear and jump to board_init_r. -e) now we look in 8ff5fcc0 (RAM) +----------------------------------------------------------------------------- +How ELF relocations 23 and 2 work. -QongEVB>md 0x8ff5fcc0 -8ff5fcc0 : a005b4cc a000faf0 a005d6f0 a0058610 ................ - ^^^^^^^^ - Bingo, here we have the old flash address (when relocation - is working, here is the fixed ram address. see @ f, how - it gets calculated) - - ----------------------------------------- - -f) now translate it in the new RAM address - - a005b4cc - -- a0000000 TextBase - -+ 8ff08000 new address of u-boot in ram ----------- - 8ff634cc - -QongEVB>mm 0x8ff5fcc0 0x8ff634cc 1 -QongEVB>md 0x8ff5fcc0 -8ff5fcc0 : 8ff634cc a000faf0 a005d6f0 a0058610 .4.............. -8ff5fcd0 : a00616a4 a00564dc a0058618 a0054852 .....d......RH.. - -As this must be done for all address in the GOT, the u-boot -code did this automagically ... :-) - ----------------------------------------------- - -g) check if the new address is really in the bss section: - -bss start: -8ff6054c (8ff08000 + 0005854C monitorlen) - -bss end: -8ff698ac (8ff08000 + 618AC) - -8ff634cc is in bss :-) - ----------------------------------------------- - -h) u-boot prints: - -important addresses: - -U-Boot code: A0000000 -> A005854C BSS: -> A00618AC TextBase 0xa0000000 -Now running in RAM - U-Boot at: 8ff08000 relocBase 0x8ff08000 - - ---------- - -U-Boot 2010.06-rc2-00002-gf8fbb25-dirty (Jun 18 2010 - 17:07:19) - -U-Boot code: A0000000 -> A005854C BSS: -> A00618AC -CPU: Freescale i.MX31 at 398 MHz -Board: DAVE/DENX Qong -mon: FFFFFFFF gd->monLen: 000618AC -Top of RAM usable for U-Boot at: 90000000 -LCD panel info: 640 x 480, 16 bit/pix -Reserving 600k for LCD Framebuffer at: 8ff6a000 -Reserving 390k for U-Boot at: 8ff08000 -Reserving 1280k for malloc() at: 8fdc8000 -Reserving 28 Bytes for Board Info at: 8fdc7fe4 -Reserving 48 Bytes for Global Data at: 8fdc7fb4 -New Stack Pointer is: 8fdc7fb0 -RAM Configuration: -Bank #0: 80000000 256 MiB -mon: 0005854C gd->monLen: 000618AC -Now running in RAM - U-Boot at: 8ff08000 +TBC ------------------------------------------------------------------------------------- @@ -304,7 +154,7 @@ e) load new symbol table: (gdb) add-symbol-file u-boot 0x8ff08000 add symbol table from file "u-boot" at - .text_addr = 0x8ff08000 + .text_addr = 0x8ff08000 (y or n) y Reading symbols from /home/hs/celf/u-boot/u-boot...done. (gdb) c @@ -312,12 +162,12 @@ Continuing. ^C Program received signal SIGSTOP, Stopped (signal). 0x8ff17f18 in serial_getc () at serial_mxc.c:192 -192 while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY); +192 while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY); (gdb) add-symbol-file u-boot 0x8ff08000 - ^^^^^^^^^^ - get this address from u-boot debug printfs + ^^^^^^^^^^ + get this address from u-boot debug printfs U-Boot 2010.06-rc2-00009-gf77b8b8-dirty (Jun 22 2010 - 09:43:46) @@ -329,7 +179,7 @@ Top of RAM usable for U-Boot at: 90000000 LCD panel info: 640 x 480, 16 bit/pix Reserving 600k for LCD Framebuffer at: 8ff6a000 Reserving 391k for U-Boot at: 8ff08000 - ^^^^^^^^ + ^^^^^^^^ Reserving 1280k for malloc() at: 8fdc8000 Reserving 24 Bytes for Board Info at: 8fdc7fe8 Reserving 52 Bytes for Global Data at: 8fdc7fb4 @@ -339,6 +189,6 @@ Bank #0: 80000000 256 MiB relocation Offset is: eff08000 mon: 00058BAC gd->monLen: 00061F10 Now running in RAM - U-Boot at: 8ff08000 - ^^^^^^^^ + ^^^^^^^^ Now you can use gdb as usual :-) diff --git a/doc/README.fsl-ddr b/doc/README.fsl-ddr index e108a0d50..1657ef617 100644 --- a/doc/README.fsl-ddr +++ b/doc/README.fsl-ddr @@ -78,6 +78,20 @@ If the DDR controller supports address hashing, it can be enabled by hwconfig. Syntax is: hwconfig=fsl_ddr:addr_hash=true + +Memory testing options for mpc85xx +================================== +1. Memory test can be done once U-boot prompt comes up using mtest, or +2. Memory test can be done with Power-On-Self-Test function, activated at + compile time. + + In order to enable the POST memory test, CONFIG_POST needs to be + defined in board configuraiton header file. By default, POST memory test + performs a fast test. A slow test can be enabled by changing the flag at + compiling time. To test memory bigger than 2GB, 36BIT support is needed. + Memory is tested within a 2GB window. TLBs are used to map the virtual 2GB + window to physical address so that all physical memory can be tested. + Combination of hwconfig ======================= Hwconfig can be combined with multiple parameters, for example, on a supported diff --git a/doc/README.scrapyard b/doc/README.scrapyard new file mode 100644 index 000000000..42865593b --- /dev/null +++ b/doc/README.scrapyard @@ -0,0 +1,30 @@ +Over time, support for more and more boards gets added to U-Boot - +while other board support code dies a silent death caused by +negligence in combination with ordinary bitrot. Sometimes this goes +by unnoticed, but often build errors will result. If nobody cares any +more to resolve such problems, then the code is really dead and will +be removed from the U-Boot source tree. The remainders rest in piece +in the imperishable depths of the git history. This document tries to +maintain a list of such former fellows, so archeologists can check +easily if here is something they might want to dig for... + + +Board Arch CPU removed Commit last known maintainer/contact +============================================================================= +VoVPN-GW_100MHz powerpc MPC8260 - 2010-10-24 Juergen Selent <j.selent@elmeg.de> +NC650 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de> +CP850 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de> +logodl ARM PXA2xx 059e778 2010-10-18 August Hoeraendl <august.hoerandl@gmx.at> +CCM powerpc MPC860 dff07e1 2010-10-06 Wolfgang Grandegger <wg@denx.de> +PCU_E powerpc MPC860T 544d97e 2010-10-06 Wolfgang Denk <wd@denx.de> +spieval powerpc MPC5200 69434e4 2010-09-19 +smmaco4 powerpc MPC5200 9ddc3af 2010-09-19 +HMI10 powerpc MPC823 77efe35 2010-09-19 Wolfgang Denk <wd@denx.de> +GTH powerpc MPC860 0fe247b 2010-07-17 Thomas Lange <thomas@corelatus.se> +AmigaOneG3SE 953b7e6 2010-06-23 +suzaku microblaze 4f18060 2009-10-03 Yasushi Shoji <yashi@atmark-techno.com> +XUPV2P microblaze 8fab49e 2008-12-10 Michal Simek <monstr@monstr.eu> +MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwarz <andre.schwarz@matrix-vision.de> +adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi@eurotech.com> +R5200 ColdFire 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau@labxtechnologies.com> +CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs@esd-electronics.com> diff --git a/doc/README.ubi b/doc/README.ubi new file mode 100644 index 000000000..da2dfac50 --- /dev/null +++ b/doc/README.ubi @@ -0,0 +1,144 @@ +------------------- +UBI usage in U-Boot +------------------- + +Here the list of the currently implemented UBI commands: + +=> help ubi +ubi - ubi commands + +Usage: +ubi part [part] [offset] + - Show or set current partition (with optional VID header offset) +ubi info [l[ayout]] - Display volume and ubi layout information +ubi create[vol] volume [size] [type] - create volume name with size +ubi write[vol] address volume size - Write volume from address with size +ubi read[vol] address volume [size] - Read volume to address with size +ubi remove[vol] volume - Remove volume +[Legends] + volume: character name + size: specified in bytes + type: s[tatic] or d[ynamic] (default=dynamic) + + +The first command that is needed to be issues is "ubi part" to connect +one mtd partition to the UBI subsystem. This command will either create +a new UBI device on the requested MTD partition. Or it will attach a +previously created UBI device. The other UBI commands will only work +when such a UBI device is attached (via "ubi part"). Here an example: + +=> mtdparts + +device nor0 <1fc000000.nor_flash>, # parts = 6 + #: name size offset mask_flags + 0: kernel 0x00200000 0x00000000 0 + 1: dtb 0x00040000 0x00200000 0 + 2: root 0x00200000 0x00240000 0 + 3: user 0x01ac0000 0x00440000 0 + 4: env 0x00080000 0x01f00000 0 + 5: u-boot 0x00080000 0x01f80000 0 + +active partition: nor0,0 - (kernel) 0x00200000 @ 0x00000000 + +defaults: +mtdids : nor0=1fc000000.nor_flash +mtdparts: mtdparts=1fc000000.nor_flash:2m(kernel),256k(dtb),2m(root),27392k(user),512k(env),512k(u-boot) + +=> ubi part root +Creating 1 MTD partitions on "nor0": +0x000000240000-0x000000440000 : "mtd=2" +UBI: attaching mtd1 to ubi0 +UBI: physical eraseblock size: 262144 bytes (256 KiB) +UBI: logical eraseblock size: 262016 bytes +UBI: smallest flash I/O unit: 1 +UBI: VID header offset: 64 (aligned 64) +UBI: data offset: 128 +UBI: attached mtd1 to ubi0 +UBI: MTD device name: "mtd=2" +UBI: MTD device size: 2 MiB +UBI: number of good PEBs: 8 +UBI: number of bad PEBs: 0 +UBI: max. allowed volumes: 128 +UBI: wear-leveling threshold: 4096 +UBI: number of internal volumes: 1 +UBI: number of user volumes: 1 +UBI: available PEBs: 0 +UBI: total number of reserved PEBs: 8 +UBI: number of PEBs reserved for bad PEB handling: 0 +UBI: max/mean erase counter: 2/1 + + +Now that the UBI device is attached, this device can be modified +using the following commands: + +ubi info Display volume and ubi layout information +ubi createvol Create UBI volume on UBI device +ubi removevol Remove UBI volume from UBI device +ubi read Read data from UBI volume to memory +ubi write Write data from memory to UBI volume + + +Here a few examples on the usage: + +=> ubi create testvol +Creating dynamic volume testvol of size 1048064 + +=> ubi info l +UBI: volume information dump: +UBI: vol_id 0 +UBI: reserved_pebs 4 +UBI: alignment 1 +UBI: data_pad 0 +UBI: vol_type 3 +UBI: name_len 7 +UBI: usable_leb_size 262016 +UBI: used_ebs 4 +UBI: used_bytes 1048064 +UBI: last_eb_bytes 262016 +UBI: corrupted 0 +UBI: upd_marker 0 +UBI: name testvol + +UBI: volume information dump: +UBI: vol_id 2147479551 +UBI: reserved_pebs 2 +UBI: alignment 1 +UBI: data_pad 0 +UBI: vol_type 3 +UBI: name_len 13 +UBI: usable_leb_size 262016 +UBI: used_ebs 2 +UBI: used_bytes 524032 +UBI: last_eb_bytes 2 +UBI: corrupted 0 +UBI: upd_marker 0 +UBI: name layout volume + +=> ubi info +UBI: MTD device name: "mtd=2" +UBI: MTD device size: 2 MiB +UBI: physical eraseblock size: 262144 bytes (256 KiB) +UBI: logical eraseblock size: 262016 bytes +UBI: number of good PEBs: 8 +UBI: number of bad PEBs: 0 +UBI: smallest flash I/O unit: 1 +UBI: VID header offset: 64 (aligned 64) +UBI: data offset: 128 +UBI: max. allowed volumes: 128 +UBI: wear-leveling threshold: 4096 +UBI: number of internal volumes: 1 +UBI: number of user volumes: 1 +UBI: available PEBs: 0 +UBI: total number of reserved PEBs: 8 +UBI: number of PEBs reserved for bad PEB handling: 0 +UBI: max/mean erase counter: 4/1 + +=> ubi write 800000 testvol 80000 +Volume "testvol" found at volume id 0 + +=> ubi read 900000 testvol 80000 +Volume testvol found at volume id 0 +read 524288 bytes from volume 0 to 900000(buf address) + +=> cmp.b 800000 900000 80000 +Total of 524288 bytes were the same diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index ffe261513..180ead5d8 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -6,33 +6,6 @@ from U-Boot, its corresponding entry should also be removed from this file. --------------------------- -What: CONFIG_SYS_ARM_WITHOUT_RELOC option -When: After Release 2011.03 - -Why: The implementation of U-Boot for the ARM architecture has - been reworked to support relocation. This allows to - efficiently use the same U-Boot binary image on systems with - different RAM sizes, and brings the implementation much more - in line with the code used for example on Power Architecture - systems (eventually allowing to merge into common code). This - seems especailly interesting now that ARM is getting Device - Tree support as well. - - All ARM boards need to be adapted to this new code, which - requires testing on the actual hardware, so this is a task - for the respective board maintainers or other users. - - Please see the commit message of commit f1d2b31 for details: - - http://git.denx.de/?p=u-boot.git;a=commit;h=f1d2b31 - - Support for CONFIG_SYS_ARM_WITHOUT_RELOC will be removed - after release v2011.03; all boards that have not been - converted by then, i. e. that are still broken then, are - considered unmaintained and without interest for the - community and will be removed as well. - ---------------------------- What: CONFIG_NET_MULTI option When: Release 2009-11 |