July 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] [PATCH] HEAD cmd_falsh.c for m68k tool chain
by Jens Scharsig 31 Jul '06

31 Jul '06

CHANGELOG entry: * Patch by Jens Scharsig, 28 July 2005 - fix some compiler/parser error, if using m68k tool chain - optical fix for protect on/off all messages, if using more then one bank Best regards, Jens Scharsig Index: common/cmd_flash.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/common/cmd_flash.c,v retrieving revision 1.13 diff -p -u -r1.13 cmd_flash.c --- common/cmd_flash.c 15 Jul 2005 22:47:24 -0000 1.13 +++ common/cmd_flash.c 28 Jul 2005 12:32:00 -0000 @@ -117,11 +117,15 @@ static int addr_spec(char *arg1, char *arg2, ulong *addr_first, ulong *addr_last) { char *ep; + char len_used; /* indicates if the "start +length" form used */ + char found; + ulong bank; + *addr_first = simple_strtoul(arg1, &ep, 16); if (ep == arg1 || *ep != '\0') - return -1; - - char len_used = 0; /* indicates if the "start +length" form used */ + return -1; + + len_used = 0; /* indicates if the "start +length" form used */ if (arg2 && *arg2 == '+'){ len_used = 1; ++arg2; @@ -146,8 +150,7 @@ addr_spec(char *arg1, char *arg2, ulong */ /* find the end addr of the sector where the *addr_last is */ - char found = 0; - ulong bank; + found = 0; for (bank = 0; bank < CFG_MAX_FLASH_BANKS && !found; ++bank){ int i; flash_info_t *info = &flash_info[bank]; @@ -453,12 +456,10 @@ int do_protect (cmd_tbl_t *cmdtp, int fl info->protect[i] = p; #endif /* CFG_FLASH_PROTECTION */ } - } - #if defined(CFG_FLASH_PROTECTION) - if (!rcode) puts (" done\n"); + if (!rcode) puts (" done\n"); #endif /* CFG_FLASH_PROTECTION */ - + } return rcode; }

2 2

[U-Boot-Users] MIPS: AMD Alchemy au1x00 ethernet problems
by geoff cleary 23 Jul '06

23 Jul '06

Hi I am seeing a problem with network support on the AMD dbau1550 eval board (and our own board based on Au1550). It seems that after one network command, no further packets can be sent. The minimal case that shows the problem is to include the ping command. The first ping will succeed; any other network commands time out. I have successfully loaded large files using tftpboot command and confirmed the image loaded correctly. Trying the command again fails with TX timeout. Has anyone seen this problem or have any suggestions as to what is going on? We are building little endian. I have tried Joseph Chiu's buffer 0 patch. Thanks Geoff __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

[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] [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