October 2008 - U-Boot

[U-Boot] Please pull u-boot-mpc85xx.git
by Andy Fleming 12 Oct '08

12 Oct '08

are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master Haiying Wang (3): Minor fixes for I2C address on MPC8572DS Add ID EEPROM support for MPC8572DS Remove redundant #define for MPC8536DS Jason Jin (1): Fix the incorrect DDR clk freq reporting on 8536DS Kumar Gala (1): 85xx: Remove setting of *cache-line-size in device trees Rafal Czubak (1): FSL: Fix get_cpu_board_revision() return value. Wolfgang Grandegger (1): 85xx: Using proper I2C source clock divider for MPC8544 board/freescale/common/sys_eeprom.c | 2 +- cpu/mpc85xx/cpu.c | 3 ++- cpu/mpc85xx/fdt.c | 3 --- cpu/mpc85xx/speed.c | 7 ++++--- include/asm-ppc/immap_85xx.h | 7 +++++++ include/configs/MPC8536DS.h | 3 +-- include/configs/MPC8572DS.h | 19 +++++++++++++++++-- 7 files changed, 32 insertions(+), 12 deletions(-)

2 1

Re: [U-Boot] [cfi-flash] Please pull git://www.denx.de/git/u-boot-cfi-flash.git
by Wolfgang Denk 12 Oct '08

12 Oct '08

Dear Stefan Roese, In message <200810021035.29824.sr(a)denx.de> you wrote: > The following changes since commit 8fd4166c467a46773f80208bda1ec3b4757747bc: > Stefan Roese (1): > ppc4xx: Canyonlands: Remove unnecessary FDT warning upon DTB fixup > > are available in the git repository at: > > git://www.denx.de/git/u-boot-cfi-flash.git master > > Mike Frysinger (1): > cfi_flash: do not reset flash when probe fails > > drivers/mtd/cfi_flash.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) Done, thanks. And sorry it took so long. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de The human race is faced with a cruel choice: work or daytime tele- vision.

1 0

[U-Boot] Please pull u-boot-mpc83xx fixes for 2008-10 release
by Kim Phillips 12 Oct '08

12 Oct '08

Wolfgang D., Please pull a ddr base address assignment fix, h/w flash protection turned on by default, and a fix to facilitate autobooting: The following changes since commit 8fd4166c467a46773f80208bda1ec3b4757747bc: Stefan Roese (1): ppc4xx: Canyonlands: Remove unnecessary FDT warning upon DTB fixup are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Anton Vorontsov (1): mpc83xx: spd_sdram: fix ddr sdram base address assignment bug Kim Phillips (2): mpc83xx: add h/w flash protection to board configs mpc83xx: don't disable autoboot Nobuhiro Iwamatsu (1): mpc83xx: Fix typo in include/mpc83xx.h board/freescale/mpc8313erdb/sdram.c | 2 +- board/freescale/mpc8315erdb/sdram.c | 2 +- board/freescale/mpc8349emds/mpc8349emds.c | 2 +- board/freescale/mpc8349itx/mpc8349itx.c | 2 +- board/freescale/mpc837xemds/mpc837xemds.c | 2 +- board/freescale/mpc837xerdb/mpc837xerdb.c | 2 +- board/matrix_vision/mvblm7/mvblm7.c | 2 +- board/sbc8349/sbc8349.c | 2 +- cpu/mpc83xx/spd_sdram.c | 2 +- include/configs/MPC8313ERDB.h | 3 ++- include/configs/MPC8315ERDB.h | 1 + include/configs/MPC8323ERDB.h | 3 ++- include/configs/MPC832XEMDS.h | 1 + include/configs/MPC8349EMDS.h | 1 + include/configs/MPC8349ITX.h | 1 + include/configs/MPC8360EMDS.h | 1 + include/configs/MPC837XEMDS.h | 1 + include/configs/MPC837XERDB.h | 3 ++- include/mpc83xx.h | 2 +- 19 files changed, 22 insertions(+), 13 deletions(-) Thanks, Kim

2 1

[U-Boot] resetting environment to default
by Kumar Gala 12 Oct '08

12 Oct '08

In some discussions we were talking about the nicety of having a command to reset the environment back to defaults. The reason for having a command is to deal with know exactly where the environment is stored in various non-volatile memories. Is this something we think would be acceptable -- a 'resetenv' command? - k

2 4

[U-Boot] Help building AT91 u-boot with Buildroot tools
by Otto Caldwell 10 Oct '08

10 Oct '08

Hello, I'm new to this list, so please let me know if this is not the correct list to post this... I am porting Linux to an Atmel at91rm9200-EK board. I've built the cross-compile tool chain using Buildroot, choosing the armeb (arm embedded) option during the build. I downloaded the AT91 custodian branch of u-boot from http://git.denx.de/?p=u-boot/u-boot-at91.git;a=summary When I attempt to compile, I get following type of errors: armeb-linux-ld: failed to merge target specific data of file lib_arm/libarm.a(div0.o) armeb-linux-ld: drivers/mtd/nand_legacy/libnand_legacy.a(nand_legacy.o): compiled for a big endian system and target is little endian It finally stops with Error 1. Any help is much appreciated. Otto Caldwell

2 1

[U-Boot] [AT91] Questions about AT91 architecture in u-boot
by Sergey Lapin 10 Oct '08

10 Oct '08

Hi, all! I have 2 questions about AT91 architecture in u-boot. 1. In file include/dataflash.h there is setting #define NB_DATAFLASH_AREA 5 What is its real meaning? What if I need to change number of DataFlash partitions? Probably it should be made board-specific? 2. What is current state with hardware ECC for NAND on at91 CPUs? And, is there some ideas on how could I make such an image using mtd-tools' mkfs.jffs2? When I flashed normal image and used hardware ECC in kernel I have got lots of ECC errors and kernel not mounting rootfs. BTW, will hardware ECC help me with big NAND (1GB) and lots of system logging to speed-up stuff? Thanks a lot, S.

2 1

[U-Boot] Adding a new board
by Ron Madrid 10 Oct '08

10 Oct '08

I have a quick question about adding a board to the u-boot project. I would like to submit my code for review and subsequent inclusion in the project, however the branch I would like to base my code on is the u-boot-nand-flash. Is it possible/appropriate to add my board to that branch or do I have to wait until the changes in that branch are merged with the main project and then submit? Thanks. Ron Madrid

3 3

[U-Boot] Problem with flash on a MPC5200B board
by Sylvain Lamontagne 10 Oct '08

10 Oct '08

Hi Everyone I'm pretty new to U-Boot and Embedded system globally, but in the last few weeks I have learn a lot and I'm now trying to port correctly U-Boot v 1.3.4 to a custom board based on a Icecube. I'm able to boot a linux kernel with it when I use the RAM with the bootm command. Unfortunately, I must make it work with the FLASH. The chip used for the flash is a S29GL128 or a S29GL256 from Spansion, they are 16bits chips but the bus is only 8bits. By reading the datasheet, these chips are supposed to support the Common Flash Interface so I'm trying to make then work with the CFI driver of U-Boot. Here is what I get when booting with DEBUG activated: U-Boot 1.3.4 (Oct 7 2008 - 16:39:49) > > CPU: MPC5200B v2.2, Core v1.4 at 378 MHz > Bus 84 MHz, IPB 84 MHz, PCI 21 MHz > Board: Icecube Based Board > I2C: 93 kHz, ready > DRAM: 64 MB > Top of RAM usable for U-Boot at: 04000000 > Reserving 551k for U-Boot at: 03f76000 > Reserving 130k for malloc() at: 03f55800 > Reserving 68 Bytes for Board Info at: 03f557bc > Reserving 60 Bytes for Global Data at: 03f55780 > Stack Pointer at: 03f55768 > New Stack Pointer is: 03f55768 > Now running in RAM - U-Boot at: 03f76000 > FLASH: flash detect cfi > fwc addr ff000000 cmd f0 f0 8bit x 8 bit > fwc addr ff000000 cmd f0 f0 8bit x 8 bit > fwc addr ff000055 cmd 98 98 8bit x 8 bit > is= cmd 51(Q) addr ff000010 is= 0 51 > fwc addr ff000555 cmd 98 98 8bit x 8 bit > is= cmd 51(Q) addr ff000010 is= 0 51 > fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit > fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit > fwc addr ff0000aa cmd 98 9898 16bit x 8 bit > is= cmd 51(Q) addr ff000020 is= 5151 5151 > is= cmd 52(R) addr ff000022 is= 5252 5252 > is= cmd 59(Y) addr ff000024 is= 5959 5959 > device interface is 2 > found port 2 chip 1 port 16 bits chip 8 bits > 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 QRY..@.....'6... > 10 : 06 09 13 03 05 03 02 19 02 00 06 00 01 ff 00 00 ................ > 20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 ............... > fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit > fwc addr ff001554 cmd aa aaaa 16bit x 8 bit > fwc addr ff000aaa cmd 55 5555 16bit x 8 bit > fwc addr ff001554 cmd 90 9090 16bit x 8 bit > fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit > fwc addr ff0000aa cmd 98 9898 16bit x 8 bit > manufacturer is 2 > manufacturer id is 0x5 > device id is 0x56 > device id2 is 0x0 > cfi version is 0x3133 > size_ratio 1 port 16 bits chip 8 bits > found 1 erase regions > erase region 0: 0x020000ff > erase_region_count = 256 erase_region_size = 131072 > ERROR: too many flash sectors > fwc addr ff000000 cmd f0 f0 8bit x 8 bit > flash_protect ON: from 0xFFF00000 to 0xFFF43FFF > flash_protect ON: from 0xFFFE0000 to 0xFFFFFFFF > 32 MB > basetask = 0, tasks = 2 > task_org = 0x03fb4c00 > TDT start = 0x00000040, end = 0x000001b8 > PCI: Bus Dev VenId DevId Class Int > PCI Scan: Found Bus 0, Device 24, Function 0 > 00 18 168c 001b 0200 00 > PCI Scan: Found Bus 0, Device 26, Function 0 > 00 1a 1057 5809 0680 00 > In: serial > Out: serial > Err: serial > U-Boot relocated to 03f76000 > Net: mpc5xxx_fec_init_phy... Begin > mpc5xxx_fec_init_phy... Done > FEC ETHERNET > > Type "boot" to boot to Linux (default) > Type "help" for a list of commands So I got an "ERROR: too many flash sectors" and a 32 MB size ... I know for sure that the chip is 16 MB so there is a kind of inconsistency... I'm also a bit confuse about what "#define" I should use to force my board to communicate in 8bit even if it's capable of 16bit. I though that I simply had to "#undef FLASH_CFI_16BIT" but that doesn't seem to do the trick. I'm not sure to understand the debug output I got... fwc addr ff000000 cmd f0 f0 8bit x 8 bit ... fwc addr ff000000 cmd f0 f0f0 16bit x 8 bit Also is the value of erase_region_count = 256 should be the number of sector on the chip ???? Because I know that the ship have a maximum of 128 sectors... If someone could brief me a bit about the debug output posted above I would greatly appreciate. I'm pretty sure I have nearly complete the port except for this FLASH issue... Help/Suggestion/Comments are welcome Thank you Sylvain

3 4

[U-Boot] U-Boot Relocation (all sections, not just .text)
by Graeme Russ 10 Oct '08

10 Oct '08

Hi All, I am trying to fully relocate U-Boot out of the Boot Flash into RAM on my i386 (AMD sc520) board in order to allow the Boot Flash to be flashed from within U-Boot itself (upgrade in place) I have added code to patch the command table so all the code can be relocated. Further investigation revealed that the code has absolute references into the Boot Flash - printf() format strings are a prime example, but I'm sure there are others After a bit of searching around the 'net I discovered gcc's -fpie and ld's -pie flags which generation a Position Independent Executable. This looks like it will do the trick - .text is (practically) identical for varying values of TEXT_BASE and ld produces a .got section as expected. However, ld creates a lot more sections than just .got Before I go down the path of dissecting all this new and wonderful information, I thought I would quickly ask: - Am I looking at the problem the wrong way? - Has anyone here looked into making U-Boot 100% relocatable before? - Is U-Boot already 100% relocatable (not just code) for any other platforms? - Has anyone here used pie before and had to write code to adjust the offset tables? - Does anyone know of a good reference for pie / .got / elf (I have found bits and pieces here and there, but no definitive reference) And lastly - Is it worth the effort, or I should I just set TEXT_BASE to a known memory location and not bother with the relocation at all? tia Graeme

3 2

[U-Boot] Special memory test Question
by Martin Jarman 10 Oct '08

10 Oct '08

I have an Atmel atngw100 development board and a standalone application that crashes within 10 to 30 seconds of starting. I have just discovered that the special memory test described in 5.9.2.10 of DULG also crashes the board after a similar amount of time. With a fresh copy of the Atmel's release of the U-boot binary installed (version 1.1.3-00248-gae9bc0c), I press SPACE to abort autoboot, and then type: loop .b 10400000 (10400000 is an address in SDRAM) Nothing happens for about 20 Seconds, then there is an 'Unhandled exception' and the processor reboots. Assuming I don't have a hardware fault, does the above show that the configuration provided by Atmel does not work properly (or am I missing something)? Note: U-boot will also crash if I did the loop test on an address in the ap7000's internal SRAM, but I assume the actual code for running the loop test is in SDRAM. So, if SDRAM is not being initialized correctly, this may be the reason the loop test crashes. Any comments, help or advice will be greatly appreciated. Martin Jarman

3 5