August 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] i386 multi_image.
by David Updegraff 22 Jul '06

22 Jul '06

Hi. I think this is needed to correctly boot multi-part images if you are unfortuanate enough to be working on an i386 platform. -dbu. diff --git a/lib_i386/i386_linux.c b/lib_i386/i386_linux.c --- a/lib_i386/i386_linux.c +++ b/lib_i386/i386_linux.c @@ -150,6 +150,11 @@ void do_bootm_linux(cmd_tbl_t *cmdtp, in initrd_start = 0; initrd_end = 0; } + /* <dave(a)cray.com> : if multi-part img. need to advance base ptr */ + if ((hdr->ih_type==IH_TYPE_MULTI) && (len_ptr[1])) { + int i; + for (i=0, addr+=sizeof(int); len_ptr[i++]; addr+=sizeof(int)); + } base_ptr = load_zimage((void*)addr + sizeof(image_header_t), ntohl(hdr->ih_size), initrd_start, initrd_end-initrd_start, 0);

2 1

[U-Boot-Users] [Patch] KVME080 Support
by Sangmoon Kim 22 Jul '06

22 Jul '06

Hi, This patch adds support for KVME080 board. KVME080 is a VME board with MPC8245 CPU. It also patches drivers/cfi_flash.c. First, it adds CFG_FLASH_PROTECT_CLEAR because for some flash memories(such as 28F320C3) all banks are protected after reset. Second, it makes write_buff not to call flash_write_cfibuffer if buffer_size is1. Because for flash memories with buffer_size 1, buffer write is not supported. Third, it makes 64 bit writes to use FLASH_WRITE64 if FLASH_WRITE64 is defined. Because KVME080 needs it. Fourth, it makes flash_detect_cfi call FLASH_PORTWIDTH when changing portwidth if FLASH_PORTWIDTH is defined. Because on some CPUs (such as MPC8245), port width should be changed. Regards, Sangmoon Kim

2 3

[U-Boot-Users] MIPS LE build problems
by Wolfgang Denk 22 Jul '06

22 Jul '06

Dear Thomas, I always wondered what exactly was the reason why I was not able to build the dbau1x00 targets (especially the little endian dbau1550_el target using the ELDK toolchain). Also, I always wondered about the reference to a non-exitent cpu/mips/little/liblittle.a library. Is ther ea special reason for the current settings of build options for the dbau1x00 targets? Attached below is a patch which makes all dbau1x00 targets build fine with the current ELDK, and I believe these settings are more correct than the previous ones. If you don't protest I would like to merge this patch into the public source tree? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Remember, there's a big difference between kneeling down and bending over. - Frank Zappa

6 31

[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] PATCH: Add PLEB 2 to top-level makefile
by David Snowdon 20 Jun '06

20 Jun '06

Please find attached a patch to the top level Makefile and associated documentation to add support for the PLEB 2 board (which somehow got left out of the last patch). Modifies: Makefile README MAKEALL Regards, Dave.

2 1

[U-Boot-Users] NOTE: New MTD flash partitioning methods
by Wolfgang Denk 20 Jun '06

20 Jun '06

Hello everybody, especially board maintainers! I just comitted a bigger patch that implements a new "mtdparts" command and a common partition scheme that allows U-Boot and Linux to share the same idea about flash partitioning.. Old, obsolete and duplicated code was cleaned up and replaced by the new partitioning method. There are two possible approaches now: The first one is to define a single, static partition: #undef CONFIG_JFFS2_CMDLINE #define CONFIG_JFFS2_DEV "nor0" #define CONFIG_JFFS2_PART_SIZE 0xFFFFFFFF /* use whole device */ #define CONFIG_JFFS2_PART_SIZE 0x00100000 /* use 1MB */ #define CONFIG_JFFS2_PART_OFFSET 0x00000000 The second method is to use the "mtdparts" command line and dynamic partitioning: /* mtdparts command line support */ #define CONFIG_JFFS2_CMDLINE #define MTDIDS_DEFAULT "nor1=zuma-1,nor2=zuma-2" #define MTDPARTS_DEFAULT "mtdparts=zuma-1:-(jffs2),zuma-2:-(user)" Command line of course produces bigger images, and may be inappropriate for some targets, so by default it's off. The code was tested on the following targets: Alaska8220, CPCI4052, NC650, PPChamelion, incaip. Besides the above targets, there were several other targets affected, where necessary changes were made. However, no testing was done for those targets, only compilation was verified (for PPC, MIPS and ARM targets). Due to the lack of tool chain for NICOS and i386 I was not able to compile the following targets: ADNPESC1, DK1C20, DK1S10, sc520_cdp, sc520_spunk. Among the modified and not tested targets there is a group of targets which were implementing their custom multi-partition scheme. This was mostly duplicating jffs2_part_info() routine code. Introducing the new common scheme required removing this duplicated code, so those targets should be especially carefully tested by the board main- tainers. Target list that require special attention: xsengine, voiceblue, mx1fs2, MPC8260ADS, innokom and VoVPN-GW (JFFS2 is by default not compiled in) and especially SXNI855T where the jffs2_part_info() routine was doing some custom NAND read caching. Thanks. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de If there was anything that depressed him more than his own cynicism, it was that quite often it still wasn't as cynical as real life. - Terry Pratchett, _Guards! Guards!_

2 2