August 2005 - U-Boot

[U-Boot-Users] Kernel XIP
by shivappa.kushtagi＠wipro.com 19 May '06

19 May '06

Hello, I configured for kernel XIP and created xipImage. When I tried to load it through u-boot, it complained about invalid magic number. Later I added a 64 byte header required for u-boot with the following mkimage command: mkimage -A arm -O linux -T kernel -C none -a 0x00080000 -e 0x00080040 -d xipImage XIPImage. Actually some of the document found at CELF wiki specifies that we need to give "-x" option to mkimage. With -x option, mkimage fails with the following error message : mkimage: Bad file: "xipImage" has invalid buffer for XIP. After looking into the mkimage source code, found that it expects 0xFF for the first 64 bytes of xipImage. Which is missing in the xipImage I have built. There must be some in-consistency between the way xipImage is built or mkimage command. Also, I didn't find any significance of the code for "-x" if we specify the "entry point" correctly (load address + 0x40). After the mkimage, I flashed the XIPImage at address 0x00080000. After resetting the board, I got the following boot messages : ## Booting image at 00080000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2009016 Bytes = 1.9 MB Load Address: 00080000 Entry Point: 00080040 Verifying Checksum ... OK XIP Kernel Image ... OK Starting kernel ... And it stops here.... Any idea what is going wrong here ? My configuration: Processor : ARM926EJ-Sid(wb) rev 3 (v5l) Kernel : 2.6.10 Regards Shivappa

3 2

[U-Boot-Users] PATCH: apply SoC concept on arm926 cpus
by Andreas Engel 03 Apr '06

03 Apr '06

CHANGELOG entry: * Patch by Andreas Engel, 20 June 2005 applied the SoC concept to arm926ejs cpus, i.e. moved the SoC specific timer and cpu_reset code from the ./cpu/$(CPU) directory into new ./cpu/$(CPU)/$(SOC) directories

6 8

[U-Boot-Users] [PATCH] fix building of tools/env programs
by Murray.Jensen＠csiro.au 23 Mar '06

23 Mar '06

This patch shows what I had to do to get the programs in the tools/env directory to build (i.e. fw_printenv/fw_setenv). Your mileage may vary. Cheers! Murray... CHANGELOG entry: * Patch by Murray Jensen <Murray.Jensen(a)csiro.au>, July 15, 2005: - fix building of programs in the tools/env directory Copyright: This patch is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 3

[U-Boot-Users] Re: compile u-boot with recent toolchain : symbols problem
by Anton Wöllert 22 Mar '06

22 Mar '06

I've got the same problem with binutils 2.16 and gcc 3.4.4. also binutils 2.16.91.0.1 doesn't work right. > > > > I used to compile U-Boot with ELDK, but I currently need to work with > > newer toolchain : > > - binutils-2.16 > > - gcc-3.4.3 > > This looks line a binutils problem, then. May I ask why you have to > use binutils-2.16 ? May I ask you why it should not be used? How to recover bugs, if people just use older software? > > And which exact board are we talking about? > > > The "__u_boot_cmd_start" symbol value, generated with this new > > toolchain, is wrong (U-Boot crashes when relocating the command > > table). > > Can you please provide exact data, like the differences between the > System.map and the u-boot.map files when using binutils-2.16 and > another, working version of binutils? [Please use the _same_ version > of GCC for this comparison.] > > > There are two new sections between "__u_boot_cmd_start" and > > ".u_boot_cmd" address : > > - .data.rel.local > > - .data.rel > > Can you please show exactly what happens? The above, i couldn't acknowledge, but u-boot definitly hangs _after_ relocating to memory. it will dump 'Now running in RAM at .....'. But then it hangs. After relocating, it tries to manually relocate the command table. But that doesn't work. Don't know why, but with the patch it works. Obviously __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; and __u_boot_cmd_start = ADDR(.u_boot_cmd); .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; should be the same. However, this should be a binutils bug or the linker script voodoo that is done with the first script above isn't really valid. Maybe .u_boot_cmd gets misalligned. Maybe i should try to DEBUG(& __u_boot_cmd_start) in both (the patched and unpatched) versions to see, where it points, or maybe objdump show more. Btw. this happens on the tqm8xx board. Thanks to Vincent for recovering that, that saved me a lot of time... kind regards Anton Wöllert

4 10

[U-Boot-Users] Bug in DTT for temperatures below zero degress !!!
by Steven Scholz 14 Mar '06

14 Mar '06

Hi there, there's a terrible bug in the current U-Boot CVS concerning DDT: For temperature below zero the function dtt_get_temp() (at least for lm75) returns wrong values! ... DTT: 1 is 235 C LCD: Hitachi TX14D11 5,7" 320x240 TFT (235°C) WDT: disabled This is because of the use of an "int" although the lm75 only returns two byte ("signed short"). This trivial fix is needed: Index: u-boot/dtt/lm75.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/dtt/lm75.c,v retrieving revision 1.2 diff -u -r1.2 lm75.c --- u-boot/dtt/lm75.c 27 Jun 2003 21:32:38 -0000 1.2 +++ u-boot/dtt/lm75.c 15 Jun 2005 08:44:21 -0000 @@ -174,7 +170,7 @@ int dtt_get_temp(int sensor) { - return (dtt_read(sensor, DTT_READ_TEMP) / 256); + return ( ((signed short) dtt_read(sensor, DTT_READ_TEMP)) / 256); } /* dtt_get_temp() */ #endif /* CONFIG_DTT_LM75 */ Then the output is correct: ... DTT: 1 is -28 C LCD: Hitachi TX14D11 5,7" 320x240 TFT (-28°C) CCFL: disabled (too cold!) WDT: disabled I am afraid this is an issues on all DTT in U-Boot. Some even only use "uchar". Comments? -- Steven

2 2

[U-Boot-Users] gunzip question about large uImages
by Robin Getz 13 Mar '06

13 Mar '06

Quick Question: It looks to me that the max uncompressed image size is hard coded to 4Meg (0x400000 bytes). Any thoughts why? Long question: We were having some problems booting large uImages (reported here ~ month ago). It seemed as if the were not being decompressed properly. When we had someone (Aubrey Li) dig into it he found/pointed out that in the latest cvs, u-boot/common/cmd_bootm.c the function do_bootm defines what looks to be a uncompressed max length as: uint unc_len = 0x400000; This is passed to gunzip if the image needs to be uncompressed. --snip-- case IH_COMP_GZIP: printf (" Uncompressing %s ... ", name); if (gunzip ((void *)ntohl(hdr->ih_load), unc_len, (uchar *)data, &len) != 0) { puts ("GUNZIP ERROR - must RESET board to recover\n"); SHOW_BOOT_PROGRESS (-6); do_reset (cmdtp, flag, argc, argv); } break; --snip-- gunzip takes this as the second parameter and sets it to dstlen. int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp) This is passed to the inflation routine as s.avail_out = dstlen; where inflate from u-boot/lib_generic/zlib.c uses this to halt decompression if the image size can not fit. -- snip -- from int inflate(z, f) -- if (f == Z_PACKET_FLUSH && z->avail_in == 0 && z->avail_out != 0) r = inflate_packet_flush(z->state->blocks); --snip -- from local int inflate_flush(s, z, r)-- /* compute number of bytes to copy as far as end of window */ n = (uInt)((q <= s->write ? s->write : s->end) - q); if (n > z->avail_out) n = z->avail_out; if (n && r == Z_BUF_ERROR) r = Z_OK; /* update counters */ z->avail_out -= n; z->total_out += n; -- When unc_len is increased - our problem goes away... So: two questions: - what is the best way to manage the size of unc_len? in include/configs/platform.h? Or just make it really_really big? - do you want a patch in u-boot/common/cmd_bootm.c/gunzip to check to see if the image was completely decompressed? OR - do you want a patch in u-boot/lib_generic/zlib.c to return an error if it runs out of room? Thanks -Robin

2 1

[U-Boot-Users] Why exceptions are enabled before exception vector code is copied
by Cedric VINCENT 13 Mar '06

13 Mar '06

Dear Wolfgang. Can I ask you why exceptions are enabled before exception vector code is copied to the low RAM pages ? (I am talking about U-Boot/PPC) On my board, U-Boot crashes before relocation (when debugging) since Xilinx Microprocessor Debugger (XMD) makes a spurious "Machine Check Exception". For other reasons, such an exception could arrived before u-boot starts. Finally, it is a bug or a very strange coding behaviour... Cedric VINCENT.

2 6

[U-Boot-Users] [PATCH] I2C2 support for MPC8548CDS
by Zajac Adam-AAZ004 13 Mar '06

13 Mar '06

The attached patch adds I2C2 support for the MPC8548CDS board. I've performed a limited testing on our MPC8548CDS board and everything seems to be working fine. Since this processor is brand new, I may need to revise the changes when we build our real system based on '8548. Thanks, Adam Zajac <<mpc8548cds_i2c2.patch.gz>>

2 1

[U-Boot-Users] malloc with no return check?
by Andrew Dyer 13 Mar '06

13 Mar '06

I noticed the au1xxx ethernet driver has a malloc where the return value isn't checked. I did some more looking while waiting for a slow flash programmer and at least these files seem to do the same thing: ./drivers/ns8382x.c ./drivers/bcm570x.c ./drivers/rtl8139.c ./drivers/eepro100.c ./drivers/dc2114x.c ./drivers/e1000.c ./drivers/sk98lin/skge.c ./drivers/cfb_console.c ./drivers/natsemi.c ./drivers/inca-ip_sw.c ./drivers/rtl8169.c ./drivers/pcnet.c ./cpu/mips/au1x00_eth.c ./cpu/ppc4xx/serial.c ./cpu/ppc4xx/405gp_enet.c ./cpu/ppc4xx/440gx_enet.c ./cpu/i386/serial.c ./cpu/mpc8xx/scc.c ./common/hush.c ./cpu/mpc8xx/spi.c ?maybe ./cpu/mpc8260/spi.c ?maybe ./cpu/mpc85xx/ether_fcc.c ./cpu/mpc8260/ether_fcc.c ./cpu/mpc5xxx/fec.c ./cpu/mpc8220/fec.c ./tools/easylogo/easylogo.c I didn't look under the board directory or check all varieties of alloc :-) I will submit patches for the mips stuff hopefully next week. -- Hardware, n.: The parts of a computer system that can be kicked.

3 4

[U-Boot-Users] [PATCH] in tftp client, recover from lost ACKs
by Brenda J. Butler 13 Mar '06

13 Mar '06

CHANGELOG entry: * Patch by John McCarthy and Brenda J. Butler, 8 July 2005 When the tftp client sends an ack but it gets lost, the server will resend the block. The client was now expecting the next block and ignored this block, the server never got an ack, and they got stuck. Now the tftp client will ack the block the second (and subsequent) time(s) allowing the tftp session to proceed. This little fix assumes that the server will resend exactly the same contents (same size from same offset). Here is the patch for you to look at; it is also in an attachment where the tabs and lines are preserved better. Apply to top of head checkout with patch -p0 < uboot2.patch Index: net/tftp.c =================================================================== RCS file: /u00/cvs/u-boot3/net/tftp.c,v retrieving revision 1.1 retrieving revision 1.3 diff -u -r1.1 -r1.3 --- net/tftp.c 15 Mar 2005 17:53:28 -0000 1.1 +++ net/tftp.c 5 Jul 2005 19:48:46 -0000 1.3 @@ -246,17 +246,17 @@ } } - if (TftpBlock == TftpLastBlock) { - /* - * Same block again; ignore it. - */ - break; - } - TftpLastBlock = TftpBlock; NetSetTimeout (TIMEOUT * CFG_HZ, TftpTimeout); - store_block (TftpBlock - 1, pkt + 2, len); + if (TftpBlock != TftpLastBlock) { + /* + * Same block again; do everything again + * except store it. Hope the server sent + * exactly the same length/contents. + */ + store_block (TftpBlock - 1, pkt + 2, len); + } /* * Acknoledge the block just received, which will prompt

2 1