June 2005 - U-Boot

[U-Boot-Users] Ethernet loopback command
by Thomas Schäfer 17 Apr '12

17 Apr '12

Hi, The patch attached provides a command called 'ethloop' which allows to perform loopback testing on the current eth device. To achieve this, a new ethernet packet type (PROT_TEST, 0x0808, AFAIK this is not used otherwise) is introduced in net/net.c. The patch is against SF CVS from 20050307. The functions EthLoopStart, EthLoopSend and EthLoopHandler generate a simple ethernet frame with NetOurEther as destination address and packet type PROT_TEST. The looped back package is compared with the original one and a message is displayed. It is necessary to set the ethernet line into loopback mode either by programming the PHY or using a loopback plug. I've tested this on our PPC405 custom board, but it should also work on all other systems because packet generation is independent of the underlying ethernet hardware. Example usage: => mii w 0 0 7100 <-- sets PHY into loopback mode => ethloop Using ppc_405x_eth0 device Got ethernet loopback frame, len=64 loopback test successfully completed => mii w 0 0 8000 <-- PHY reset after test is completed Maybe this is also useful for others.. Best regards, Thomas Schäfer ____________________________________ Kontron Modular Computers GmbH Konrad-Zuse-Str. 9 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: thomas.schaefer(a)kontron.com

5 5

[U-Boot-Users] New NAND code
by Stefan Roese 10 Aug '06

10 Aug '06

Hi! I was just wondering about state of the NAND code. When I remember correctly a pretty big rewrite was done but not commited yet. Is the last patch sent to this list from Pantelis Antoniou on 5th May still the latest version? Best regards, Stefan

6 8

[U-Boot-Users] parse bug in cmd_mii.c
by Andrew Dyer 22 Jul '06

22 Jul '06

I noticed that in do_mii() the code is dereferencing argv[1] without checking what value argc has. This leads to an exception if a command line like 'mii ' is given where argv[1] is NULL. I have a patch, but my cmd_mii.c is carrying around some other patches (some submitted to the list, some local). Is there a good way to separate out the patches I want to submit by themselves? -- Hardware, n.: The parts of a computer system that can be kicked.

2 4

[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] 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] [PATCH] fix conditional for including ks8695eth driver
by Greg Ungerer 12 Mar '06

12 Mar '06

Move the c-preprocessor conditional check for compiling the ks8695eth driver code to after including the headers. Otherwise it can never be compiled in. Index: drivers/ks8695eth.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/drivers/ks8695eth.c,v retrieving revision 1.2 diff -u -r1.2 ks8695eth.c --- drivers/ks8695eth.c 23 May 2005 10:49:51 -0000 1.2 +++ drivers/ks8695eth.c 3 Jun 2005 14:13:54 -0000 @@ -18,8 +18,6 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_DRIVER_KS8695ETH - /****************************************************************************/ #include <common.h> @@ -28,6 +26,7 @@ #include <asm/io.h> #include <asm/arch/platform.h> +#ifdef CONFIG_DRIVER_KS8695ETH /****************************************************************************/ /*

3 3

[U-Boot-Users] [PATCH] dhcp vendor fields - support opt bootfile, ignore tftp server
by Murray.Jensen＠csiro.au 12 Mar '06

12 Mar '06

This patch adds support for the dhcp vendor optional bootfile (#67). It also ignores the vendor tftp server name option (#66). Both of these are supplied by the DEC Tru64 Unix dhcp server (called "join"), and in the case of the bootfile, it is the only place the boot file name is supplied. There is a perfectly good, 128 byte, field in the main bootp/dhcp packet where the boot file name could have been stored, but it wasn't used - go figure. Cheers! Murray... -- 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 1