April 2004 - U-Boot

RE: [U-Boot-Users] [RFC] NAND Flash
by Dave Ellis 27 Apr '04

27 Apr '04

Pantelis Antoniou wrote: > The big problem with the code as it is its its tendancy not to > account properly for errors which are not only probable but > certain during the life of the device. > > For example the current code cannot boot reliably from NAND > and the read and write routines are also unreliable. > > It's basic assumption made that you can read/write from the NAND > at any position is false. This is impossible because of > the bad blocks that may force you to skip a bad sector. The nand boot looks broken to me. The .jffs2 commands work well for me for booting from a jffs2 partition. > I'm currently in the process of rewritting to actually make it > work reliably. > > I can keep backwards compatibility with the old code but > you can only use it at your own risk. It definitely could use a rewrite. It looks like it was ported from a very old version of mtd. Please let's keep the .jffs2 options for jffs2, so we can add optimizations such as skipping to the end of an empty erase block without breaking other uses. > I'm asking for any people currently working with NAND to comment > on the following points: > > 1. Do you read and write the NAND at arbitrary offsets? > That means not in page boundaries. No. I read an entire JFFS2 partition, or write a JFFS2 image, but only on page boundaries. > 2. Do you use the NAND boot command? It can be replaced by a copy and > bootm sequence. No. > 3. Do you use it as a raw device without employing ECC? Do you > understand the implications? No, use ECC and JFFS2. > 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB > placement of ECC and status bits? JFFS2 > 5. What kind of bad block management options would you like? I'm thinking > of implementing a bad block detection mechanism which would erase and > test the whole chip for any bad blocks. > Another command could also utilise ECC to detect borderline working > pages and relocate them to avoid a permanent failure. If the factory or linux/jffs2/mtd have marked a block bad it shouldn't be erased. There is no reliable way to find them again without factory tests, and I think the manufacturers say that erasing a factory marked bad block can make the good blocks unreliable. I want jffs2 to handle any new bad blocks. Dave Ellis ~~~~~~~~~~~~~~~~~~~~~~~~~~ SIXNET - "Leading the Industrial Ethernet Revolution" 331 Ushers Road, P.O. Box 767, Clifton Park, NY 12065 USA Tel +1 (518) 877-5173 Fax +1 (518) 877-8346 Email me at: dge(a)sixnetio.com Detailed product info: www.sixnetio.com ~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: [U-Boot-Users] [RFC] NAND Flash
by Woodruff, Richard 27 Apr '04

27 Apr '04

> I hope you don't solder your chips on the board, cause bad blocks can be > present in pristine chips fresh from the factory. > This will NOT work, since a bad block anywhere in the range that you use > means that you must replace the chip. > Bad blocks can in practice be a bit harder to get then one might think. In say ... 500 different samples which passed my desk in the last three years none of them actually had bad blocks. They could have of coarse. We simulated bad blocks. It is a real problem. Regards, Richard W.

2 1

RE: [U-Boot-Users] [RFC] NAND Flash
by VanBaren, Gerald (AGRE) 27 Apr '04

27 Apr '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Pantelis > Antoniou > Sent: Tuesday, April 27, 2004 3:45 AM > To: Peter Billek (VI/SEA) > Cc: U-Boot Users > Subject: Re: [U-Boot-Users] [RFC] NAND Flash > > > Peter Billek (VI/SEA) wrote: > > >We are in the progress of starting to implement u-boot and > will need NAND support as well. [snip] > >AS or the bad block cheeking, I would rather go for the > relocation implementation rather than the erasing the complete chip. > > > > > Me too, but it's kinda tricky... The Toshiba NAND flash we use comes from the factory with the bad blocks already marked (they may grow more bad blocks, but the initial ones are identified during manufacturing testing). If you erase the chip without saving the information first, you lose that valuable information. You should check with your supplier to see how they handle it. gvb ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

RE: [U-Boot-Users] [RFC] NAND Flash
by Peter Billek (VI/SEA) 27 Apr '04

27 Apr '04

We are in the progress of starting to implement u-boot and will need NAND support as well. As it looks at the moment we will access the NAND flash not in page boundaries, but rather with arbitrary offsets. At the moment we are using something similar to the boot command with is still a adaptation from former armboot. We don't use ECC and also no FS, rather fixed addresses. However this has to change in the future, but for the moment we are just prototyping. AS or the bad block cheeking, I would rather go for the relocation implementation rather than the erasing the complete chip. I am looking forward to see how your work progresses and might commit to it in the future as well if I can. greetings Peter Billek Board Level Design, Realtime SW Local Design Center VIE Ericsson Enterprise GmbH mailto:peter.billek@ericsson.com -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Pantelis Antoniou Sent: Dienstag, 27. April 2004 09:08 To: Wolfgang Denk; U-Boot Users Subject: [U-Boot-Users] [RFC] NAND Flash Hello there. As you remember earlier I have sent a small patch for the NAND portion of u-boot. This forced me to really take a hard look at the code and really evaluate it. The big problem with the code as it is its its tendancy not to account properly for errors which are not only probable but certain during the life of the device. For example the current code cannot boot reliably from NAND and the read and write routines are also unreliable. It's basic assumption made that you can read/write from the NAND at any position is false. This is impossible because of the bad blocks that may force you to skip a bad sector. I'm currently in the process of rewritting to actually make it work reliably. I can keep backwards compatibility with the old code but you can only use it at your own risk. I'm asking for any people currently working with NAND to comment on the following points: 1. Do you read and write the NAND at arbitrary offsets? That means not in page boundaries. 2. Do you use the NAND boot command? It can be replaced by a copy and bootm sequence. 3. Do you use it as a raw device without employing ECC? Do you understand the implications? 4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB placement of ECC and status bits? 5. What kind of bad block management options would you like? I'm thinking of implementing a bad block detection mechanism which would erase and test the whole chip for any bad blocks. Another command could also utilise ECC to detect borderline working pages and relocate them to avoid a permanent failure. Awaiting your input... Regards Pantelis ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
by Kumar Gala 26 Apr '04

26 Apr '04

I was wondering if there where an examples in the current u-boot source tree in which CONFIG_SYS_CLK_FREQ was determined dynamically. I have a system in which I can read a config register on the board to let me know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz. I was hoping to have the 16550 uart (and anything else) that needed CONFIG_SYS_CLK_FREQ grab it from a variable instead. This is on an MPC85xx platform system. thanks - Kumar

4 16

[U-Boot-Users] Memory problems with u-boot in EP852T board (Embedded Planet)
by Moshe Menachem 26 Apr '04

26 Apr '04

Hi All, I'm porting u-boot to support the EP852T board of Embedded Planet(BUS @ 50MHz) . I saw that there is no reference for using this specific kind of board , but only u-boot for RPXLite board . I encountered a problem to configure the u-boot correctly to support memory operation for this board . The EP 852T board uses a 8MB flash on CS0 (two chips of AMD - AM29LV320B, each is 4MB) and Micron SDRAM(MT48LC4M32B2) of 16MB on CS1 . 1. Does CFG_MAX_FLASH_SECT 71(the num of sectors in one AMD chip) includes both chips ? Which means does the u-boot/cpu see a 1 big flash of 8MB 32 bits bus with doubled size sector? instead of a 64KB size sectors(in a single AMD chip), a 128KB size sectors? 2. According to the EP852T board user manual, the 8MB flash base address starts at 0xff800000 (=CFG_FLASH_BASE) . I configured: CFG_FLASH_BASE 0xff800000 CFG_MONITOR_BASE CFG_FLASH_BASE CFG_BR0_PRELIM 0xff800001 (in order to support base address 0xff800000 for 8MB Flash size) CFG_OR0_PRELIM 0xff800140 (OR Address mask of 0xff8000 for 8MB flash @50MHz) 3. The SDRAM configuration : SDRAM_BASE_PRELIM 0x00000000 /* SDRAM base */ SDRAM_MAX_SIZE 0x01000000 /* max 16 MB */ CFG_PRELIM_OR_AM 0xfc000000 CFG_OR_TIMING_SDRAM 0x00000E00 CFG_OR1_PRELIM ( CFG_PRELIM_OR_AM | CFG_OR_TIMING_SDRAM ) CFG_BR1_PRELIM ((SDRAM_BASE_PRELIM & BR_BA_MSK) | BR_MS_UPMA | BR_V ) (=0x00000081) The problems i encountered : 1. Although the flash prelim and mask are conifgured as defined in the EP board manual, when running the u-boot flash_get_size() it fails on reading Manufacturer ID. When i bypass the flash_get_size and choose manually, in the code, the AM29LV320B flash and its sectors(71) and size(8MB), later, in the u-boot monitor i cannot erase the flash (none of the u-boot erase options work), but i can only read its sectors content . i also see that most of its sectors are detected as protected :(using the "flinfo" command) Bank # 1: AMD AM29LV320B (32 Mbit, bottom boot sect) Size: 8 MB in 71 Sectors Sector Start Addresses: FF800000 FF804000 FF808000 FF80C000 FF810000 FF814000 FF818000 FF81C000 FF820000 FF840000 (RO) FF860000 (RO) FF880000 (RO) FF8A0000 (RO) FF8C0000 (RO) FF8E0000 (RO) FF900000 (RO) FF920000 (RO) FF940000 (RO) FF960000 (RO) FF980000 (RO) FF9A0000 (RO) FF9C0000 (RO) FF9E0000 (RO) FFA00000 (RO) FFA20000 (RO) FFA40000 (RO) FFA60000 (RO) FFA80000 (RO) FFAA0000 (RO) FFAC0000 (RO) FFAE0000 (RO) FFB00000 (RO) FFB20000 (RO) FFB40000 (RO) FFB60000 (RO) FFB80000 (RO) FFBA0000 (RO) FFBC0000 (RO) FFBE0000 (RO) FFC00000 (RO) FFC20000 (RO) FFC40000 (RO) FFC60000 (RO) FFC80000 (RO) FFCA0000 (RO) FFCC0000 (RO) FFCE0000 (RO) FFD00000 (RO) FFD20000 (RO) FFD40000 (RO) FFD60000 (RO) FFD80000 (RO) FFDA0000 (RO) FFDC0000 (RO) FFDE0000 (RO) FFE00000 (RO) FFE20000 (RO) FFE40000 (RO) FFE60000 (RO) FFE80000 (RO) FFEA0000 (RO) FFEC0000 (RO) FFEE0000 (RO) 01010101 (RO) 01010101 (RO) 01F40000 (RO) FFF60000 (RO) FFF80000 (RO) FFFA0000 (RO) FFFC0000 (RO) FFFE0000 (RO) 2. The second problem i have is with the SDRAM operation . The SDRAM seems to work(read and write are possible) only when i use CFG_PRELIM_OR_AM 0xfc000000, although CFG_PRELIM_OR_AM should be configured to 0xff000000 , for 16MB SDRAM OR mask . Thanks in advance, Moshiko

2 1

RE: [U-Boot-Users] v1.1.0, omap boards and udelay()
by Gupta, Kshitij 26 Apr '04

26 Apr '04

Hi Nishant, The timers are working properly for both 1510 and 1610 innovator. Only thing is that #if loop has to be removed with hardcoded spin. warm regards -kshitij -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Kamat, Nishant Sent: Tuesday, April 20, 2004 10:00 PM To: Dave Peverley; u-boot-users(a)lists.sourceforge.net Subject: RE: [U-Boot-Users] v1.1.0, omap boards and udelay() Dave, In versions prior 1.1.0, there was a small bug in the omap1610 port, in that the timer was not enabled. Obviously the udelay wouldn't function normally and so there was this busy loop to make for it. In 1.1.0 this is fixed by enabling the MPU timers, and there is no need for the loop. See board/omap1610inn/platform.S where MPU Timer 1 is now enabled. You might be missing similar code in the 730's port. That said, the same bug in 1510 is not yet fixed, and it still uses the busy loop (in cpu/arm925t/interrupts.c). I'll send a little patch to fix that soon. Regards, Nishant -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Dave Peverley Sent: Monday, April 19, 2004 7:00 AM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] v1.1.0, omap boards and udelay() Hi all, I'm just merging my omap730p2 port into the 1.1.0 codebase, and have hit a snag that I would have thought would affect the omap1510 and 1610 code as well ; can anyone confirm this? The problem is as follows : in boards/omapXXXX/omapXXXX.c, the function ether__init() uses the udelay() call. Prior to version 1.1.0, this was implemented using : #if defined(CONFIG_INNOVATOROMAP1610) || defined(CONFIG_P2OMAP730) #define LOOPS_PER_MSEC 100 /* tuned on omap1610 */ volatile int i, time_remaining = LOOPS_PER_MSEC * usec; for (i = time_remaining; i > 0; i--) { } #else so that the omap's wouldn't use the MPU timer, as this does not work (at least at that point in the startup) This means that u-boot hangs on my board during ether__init() now as the timer never gets incremented. Can anyone tell me why this code was removed? Looking at it, I can't see a reason why it shouldn't break the 1510/1610 omap support as well. I've tested moving the code back as it was (using the 1.1.0 CONFIG_OMAP instead) and this fixes the problem once more. Best Wishes, Dave Peverley ------------------------------------------------------------------------ --- Dave Peverley, Software Engineer, MPC Data Limited. Phone : [+44] (0) 1225 868 228 Web : http://www.mpc-data.co.uk ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

3 5

[U-Boot-Users] Memory problems with u-boot in EP852T board (Embedded Planet)
by Moshe Menachem 26 Apr '04

26 Apr '04

> Hi All, > > I'm porting u-boot to support the EP852T board of Embedded Planet(BUS @ 50MHz) . > I saw that there is no reference for using this specific kind of board , but only u-boot for RPXLite board . > > I encountered a problem to configure the u-boot correctly to support memory operation for this board . > The EP 852T board uses a 8MB flash on CS0 (two chips of AMD - AM29LV320B, each is 4MB) and Micron SDRAM(MT48LC4M32B2) of 16MB on CS1 . > > 1. Does CFG_MAX_FLASH_SECT 71(the num of sectors in one AMD chip) includes both chips ? > Which means does the u-boot/cpu see a 1 big flash of 8MB 32 bits bus with doubled size sector? instead of a 64KB size sectors(in a single AMD chip), a 128KB size > sectors? > > 2. According to the EP852T board user manual, the 8MB flash base address starts at 0xff800000 (=CFG_FLASH_BASE) . > I configured: > CFG_FLASH_BASE 0xff800000 > CFG_MONITOR_BASE CFG_FLASH_BASE > CFG_BR0_PRELIM 0xff800001 (in order to support base address 0xff800000 for 8MB Flash size) > CFG_OR0_PRELIM 0xff800140 (OR Address mask of 0xff8000 for 8MB flash @50MHz) > > 3. The SDRAM configuration : > SDRAM_BASE_PRELIM 0x00000000 /* SDRAM base */ > SDRAM_MAX_SIZE 0x01000000 /* max 16 MB */ > CFG_PRELIM_OR_AM 0xfc000000 > CFG_OR_TIMING_SDRAM 0x00000E00 > CFG_OR1_PRELIM ( CFG_PRELIM_OR_AM | CFG_OR_TIMING_SDRAM ) > CFG_BR1_PRELIM ((SDRAM_BASE_PRELIM & BR_BA_MSK) | BR_MS_UPMA | BR_V ) (=0x00000081) > > > The problems i encountered : > > 1. Although the flash prelim and mask are conifgured as defined in the EP board manual, when running the u-boot flash_get_size() > it fails on reading Manufacturer ID. > When i bypass the flash_get_size and choose manually, in the code, the AM29LV320B flash and its sectors(71) and size(8MB), > later, in the u-boot monitor i cannot erase the flash (none of the u-boot erase options work), but i can only read its sectors content . > i also see that most of its sectors are detected as protected :(using the "flinfo" command) > > Bank # 1: AMD AM29LV320B (32 Mbit, bottom boot sect) > Size: 8 MB in 71 Sectors > Sector Start Addresses: > FF800000 FF804000 FF808000 FF80C000 FF810000 > FF814000 FF818000 FF81C000 FF820000 FF840000 (RO) > FF860000 (RO) FF880000 (RO) FF8A0000 (RO) FF8C0000 (RO) FF8E0000 (RO) > FF900000 (RO) FF920000 (RO) FF940000 (RO) FF960000 (RO) FF980000 (RO) > FF9A0000 (RO) FF9C0000 (RO) FF9E0000 (RO) FFA00000 (RO) FFA20000 (RO) > FFA40000 (RO) FFA60000 (RO) FFA80000 (RO) FFAA0000 (RO) FFAC0000 (RO) > FFAE0000 (RO) FFB00000 (RO) FFB20000 (RO) FFB40000 (RO) FFB60000 (RO) > FFB80000 (RO) FFBA0000 (RO) FFBC0000 (RO) FFBE0000 (RO) FFC00000 (RO) > FFC20000 (RO) FFC40000 (RO) FFC60000 (RO) FFC80000 (RO) FFCA0000 (RO) > FFCC0000 (RO) FFCE0000 (RO) FFD00000 (RO) FFD20000 (RO) FFD40000 (RO) > FFD60000 (RO) FFD80000 (RO) FFDA0000 (RO) FFDC0000 (RO) FFDE0000 (RO) > FFE00000 (RO) FFE20000 (RO) FFE40000 (RO) FFE60000 (RO) FFE80000 (RO) > FFEA0000 (RO) FFEC0000 (RO) FFEE0000 (RO) 01010101 (RO) 01010101 (RO) > 01F40000 (RO) FFF60000 (RO) FFF80000 (RO) FFFA0000 (RO) FFFC0000 (RO) > FFFE0000 (RO) > > 2. The second problem i have is with the SDRAM operation . > The SDRAM seems to work(read and write are possible) only when i use CFG_PRELIM_OR_AM 0xfc000000, > although CFG_PRELIM_OR_AM should be configured to 0xff000000 , for 16MB SDRAM OR mask . > > Thanks in advance, > Moshiko > > > > > > >

1 0

[U-Boot-Users] Anyone had problems with the SMC lan91c96.c driver?
by Dave Peverley 26 Apr '04

26 Apr '04

A quick poll ; We've experienced stalls doing TFTP with this driver every so often on the P2 board (utilises the LAN91C96 chip) - I wasn't sure if it was our board port or something else, but recently I've been using another (omap) board with this LAN chip and u-boot and it appears to behave the same way. So it seems reasonable to suspect the driver may be at fault. Can anyone else confirm or deny whether they've seen this before on any boards using this controller? As an interesting aside, I heard from someone that they'd had problems with performance / stability in Linux 2.4 with the smc9194 driver thats credited as being one of the sources for lan91c96.c. Apparently though the newer smc91x.c driver fixed this and also supports a greater number of SMC controllers as an added bonus, so I've been idly wondering if this is related, and if porting the more ubiquitous smc91x.c may be of value at some point? Best Wishes, Dave Peverley --------------------------------------------------------------------------- Dave Peverley, Software Engineer, MPC Data Limited. Phone : [+44] (0) 1225 868 228 Web : http://www.mpc-data.co.uk

1 0

[U-Boot-Users] u-boot for OMAP730
by Sammy_Yang＠compal.com 26 Apr '04

26 Apr '04

Dear Sir: Does some use u-boot on OMAP730 platform, cause I would like use OMAP1610 configuration to OMAP730, but it's not work.:( Best Regards, Sammy

2 1

[U-Boot-Users] initrd problem...
by Michael Frey 26 Apr '04

26 Apr '04

I am trying to use the initrd function of u-boot and I think I am almost there. However it does not seem that u-boot is re-locating the initrd into ram from flash. Is it supposed to do this? U-Boot is passing the address of the initrd in flash. How can I make it re-locate into ram first then pass the address to the kernel. Here is the output. pepper-> bootm 0x00080000 0x00200000 ## Booting image at 00080000 ... Image Name: Linux-2.4.20_mvl31-dbpxa2xx Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 795324 Bytes = 776.7 kB Load Address: a0008000 Entry Point: a0008000 Verifying Checksum ... OK OK ## Loading Ramdisk Image at 00200000 ... Image Name: BootSplash initrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 38 Bytes = 0 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Turning off MMC clock Starting kernel ... Uncompressing Linux........................................................ done, booting the kernel. Linux version 2.4.20_mvl31-dbpxa2xx (michael.frey(a)chawa.lex.pepper.com) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-14 CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE) CPU: D undefined 5 cache CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets Machine: PepperPad PXA Reference Board initrd (0x00200040 - 0x00200066) extends beyond physical memory - disabling initrd Memory clock: 99.53MHz (*27) Run Mode clock: 199.07MHz (*2) Turbo Mode clock: 398.13MHz (*2.0, inactive) Thanks, Michael Frey

3 4

[U-Boot-Users] JFFS2 speed enhancement patch
by Christian Hohnstaedt 25 Apr '04

25 Apr '04

Hi, for the sake of speed I repaired the header CRC calculation in the jffs2_1pass.c. I also added the eraseblock size to the partition information to skip empty eraseblocks if we find more then 4k of free space. The JFFS2 scanner is now fast enough to remove the spinning wheel so I #ifdef-ed it out. I added watchdog calls in the long running loops. The speed increasement was x10 on my board. I tested this for some days now and it works good for me. regards Christian -- Christian Hohnstaedt Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3308 http://www.innominate.com

2 2

[U-Boot-Users] Patch: Vitesse VSC8201/Cicada CIS8201 errata
by Travis Sawyer 25 Apr '04

25 Apr '04

Greetings: I've been alerted to an interoperability issue with the cicada cis8201 (now the vitesse vsc8201) gigabit ethernet phy and the Intel 82547EI. Apparently the Intel part has a 'slightly delayed response' in making the scrambler mode detection. This patch lengthens the timer setting for the '8201. I have had a report or two of problems with link on the Ocotea (IBM440GX reference design) which uses the '8201. CHANGELOG Entry: * Patch by Travis Sawyer, 23 Apr 2004: Fix VSC/CIS 8201 phy descrambler interoperability timing due to errata from Vitesse Semiconductor. Patch is attached. Best Regards, Travis Sawyer

2 1

[U-Boot-Users] Versatile bootargs
by Philippe Robin 25 Apr '04

25 Apr '04

Greetings, I attached the following patch to set the correct default ethernet address setting for CONFIG_BOOTARGS in versatile.h. Regards, Philippe ------------ * Patch by Philippe Robin, 22 Apr 2004: correct CONFIG_BOOTARGS for versatile board. Index: versatile.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/versatile.h,v retrieving revision 1.2 diff -u -r1.2 versatile.h --- versatile.h 14 Mar 2004 22:26:06 -0000 1.2 +++ versatile.h 22 Apr 2004 13:58:26 -0000 @@ -103,7 +103,7 @@ #include <cmd_confdefs.h> #define CONFIG_BOOTDELAY 2 -#define CONFIG_BOOTARGS "root=/dev/nfs mem=128M ip=dhcp netdev=27,0,0xfc800000,0xfc800010,eth0" +#define CONFIG_BOOTARGS "root=/dev/nfs mem=128M ip=dhcp netdev=25,0,0xf1010000,0xf1010010,eth0" /*#define CONFIG_BOOTCOMMAND "bootp ; bootm" */ /*

2 1

[U-Boot-Users] cramfs byte order
by gleb＠nbase.co.il 25 Apr '04

25 Apr '04

Hello all, It seems there is a problem with cramfs support in u-boot. u-boot implementation of cramfs do swap bytes on big endian machines (ppc) and linux never swap bytes and expects the file system to be in the machine byte order. This is from linuxsrc/Documentation/filesystems/cramfs.txt: Currently, cramfs must be written and read with architectures of the same endianness. The result is the file system can be read or from linux or from u-boot but not from both of them. The other problem is when I am trying to load a file from cramfs (fsload filename) I am getting the following error: ### CRAMFS LOAD ERROR<ffffffff> for vmlinuz! What can it be? Thank you. -- Gleb.

2 1

[U-Boot-Users] Bug in AT91RM9200 ethernet
by Steven Scholz 25 Apr '04

25 Apr '04

Hi there, I found a bug in AT91RM9200 ethernet driver: The PHY is accessed (and often not detected) _before_ the MII interface is actually initialized. Please consider the attached patch. * Patch by Steven Scholz, 24 Feb 2004: - Fix a bug in AT91RM9200 ethernet driver: The MII interface is now initialized before accessing the PHY. Thanks. -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland Index: cpu/at91rm9200/at91rm9200_ether.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/cpu/at91rm9200/at91rm9200_ether.c,v retrieving revision 1.4 diff -p -u -r1.4 at91rm9200_ether.c --- cpu/at91rm9200/at91rm9200_ether.c 24 Feb 2004 00:16:43 -0000 1.4 +++ cpu/at91rm9200/at91rm9200_ether.c 24 Feb 2004 14:42:25 -0000 @@ -378,14 +378,21 @@ int eth_init (bd_t * bd) p_mac = AT91C_BASE_EMAC; - *AT91C_PIOA_PDR = AT91C_PA16_EMDIO | AT91C_PA15_EMDC | AT91C_PA14_ERXER | AT91C_PA13_ERX1 | AT91C_PA12_ERX0 | AT91C_PA11_ECRS_ECRSDV | AT91C_PA10_ETX1 | AT91C_PA9_ETX0 | AT91C_PA8_ETXEN | AT91C_PA7_ETXCK_EREFCK; /* PIO Disable Register */ + /* PIO Disable Register */ + *AT91C_PIOA_PDR = AT91C_PA16_EMDIO | AT91C_PA15_EMDC | AT91C_PA14_ERXER | + AT91C_PA13_ERX1 | AT91C_PA12_ERX0 | AT91C_PA11_ECRS_ECRSDV | + AT91C_PA10_ETX1 | AT91C_PA9_ETX0 | AT91C_PA8_ETXEN | + AT91C_PA7_ETXCK_EREFCK; *AT91C_PIOB_PDR = AT91C_PB25_EF100 | - AT91C_PB19_ERXCK | AT91C_PB18_ECOL | AT91C_PB17_ERXDV | - AT91C_PB16_ERX3 | AT91C_PB15_ERX2 | AT91C_PB14_ETXER | - AT91C_PB13_ETX3 | AT91C_PB12_ETX2; - - *AT91C_PIOB_BSR = AT91C_PB25_EF100 | AT91C_PB19_ERXCK | AT91C_PB18_ECOL | AT91C_PB17_ERXDV | AT91C_PB16_ERX3 | AT91C_PB15_ERX2 | AT91C_PB14_ETXER | AT91C_PB13_ETX3 | AT91C_PB12_ETX2; /* Select B Register */ + AT91C_PB19_ERXCK | AT91C_PB18_ECOL | AT91C_PB17_ERXDV | + AT91C_PB16_ERX3 | AT91C_PB15_ERX2 | AT91C_PB14_ETXER | + AT91C_PB13_ETX3 | AT91C_PB12_ETX2; + + /* Select B Register */ + *AT91C_PIOB_BSR = AT91C_PB25_EF100 | AT91C_PB19_ERXCK | AT91C_PB18_ECOL | + AT91C_PB17_ERXDV | AT91C_PB16_ERX3 | AT91C_PB15_ERX2 | + AT91C_PB14_ETXER | AT91C_PB13_ETX3 | AT91C_PB12_ETX2; *AT91C_PMC_PCER = 1 << AT91C_ID_EMAC; /* Peripheral Clock Enable Register */ @@ -400,6 +407,22 @@ int eth_init (bd_t * bd) rbfdt[RBF_FRAMEMAX - 1].addr |= RBF_WRAP; rbfp = &rbfdt[0]; + p_mac->EMAC_SA2L = (bd->bi_enetaddr[3] << 24) | (bd->bi_enetaddr[2] << 16) + | (bd->bi_enetaddr[1] << 8) | (bd->bi_enetaddr[0]); + p_mac->EMAC_SA2H = (bd->bi_enetaddr[5] << 8) | (bd->bi_enetaddr[4]); + + p_mac->EMAC_RBQP = (long) (&rbfdt[0]); + p_mac->EMAC_RSR &= ~(AT91C_EMAC_RSR_OVR | AT91C_EMAC_REC | AT91C_EMAC_BNA); + + p_mac->EMAC_CFG = (p_mac->EMAC_CFG | AT91C_EMAC_CAF | AT91C_EMAC_NBC) + & ~AT91C_EMAC_CLK; + +#ifdef CONFIG_AT91C_USE_RMII + p_mac->EMAC_CFG |= AT91C_EMAC_RMII; +#endif + + p_mac->EMAC_CTL |= AT91C_EMAC_TE | AT91C_EMAC_RE; + at91rm92000_GetPhyInterface (); if (!pPhyOps->IsPhyConnected (p_mac)) @@ -415,22 +438,6 @@ int eth_init (bd_t * bd) printf ("No link\n\r"); return 0; } - - p_mac->EMAC_SA2L = (bd->bi_enetaddr[3] << 24) | (bd->bi_enetaddr[2] << 16) - | (bd->bi_enetaddr[1] << 8) | (bd->bi_enetaddr[0]); - p_mac->EMAC_SA2H = (bd->bi_enetaddr[5] << 8) | (bd->bi_enetaddr[4]); - - p_mac->EMAC_RBQP = (long) (&rbfdt[0]); - p_mac->EMAC_RSR &= ~(AT91C_EMAC_RSR_OVR | AT91C_EMAC_REC | AT91C_EMAC_BNA); - - p_mac->EMAC_CFG = (p_mac->EMAC_CFG | AT91C_EMAC_CAF | AT91C_EMAC_NBC) - & ~AT91C_EMAC_CLK; - -#ifdef CONFIG_AT91C_USE_RMII - p_mac->EMAC_CFG |= AT91C_EMAC_RMII; -#endif - - p_mac->EMAC_CTL |= AT91C_EMAC_TE | AT91C_EMAC_RE; return 0; }

2 2

RE: [U-Boot-Users] Patch for mii read range and mii dump
by Kerl, John 25 Apr '04

25 Apr '04

* Patch by John Kerl, 19 Apr 2004: Use U-boot's miiphy.h for PHY register names, rather than introducing a new header file. Fixes a bungle in the previous patch. -----Original Message----- From: wd(a)denx.de [mailto:wd@denx.de] Sent: Sunday, April 18, 2004 4:21 PM To: Kerl, John; U-Boot-Users (E-mail) Subject: Re: [U-Boot-Users] Patch for mii read range and mii dump In message <20040418225817.DC01DC109F(a)atlas.denx.de> I wrote: > > > > Please find included a minor enhancement to the mii command. > > This is my first u-boot patch submission so it is almost certain > > that I've screwed something up. Please forgive! > > For a first-timer this was semi-perfect. Except that the new code is referencing a file miivals.h which was not included!! Please submit a new patch to add this file! Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de Too many people are ready to carry the stool when the piano needs to be moved.

2 1

[U-Boot-Users] Patch to fix VLAN for little endian architecture
by Masami Komiya 25 Apr '04

25 Apr '04

I found out the problem of the command ping/tftpboot/nfs. It is caused by new VLAN function on little endian architecture without VLAN environment. Here is the patch to fix, although I have not confirm all in VLAN environment. Best regards. Masami Komiya @ Tokyo.JP

3 2

Re: [U-Boot-Users] Setting up environment variables under linux
by Juergen Oberhofer 24 Apr '04

24 Apr '04

> What EXACTLY did you configure? > > Did you keep the setting of HAVE_REDUND? And is does your system > really use redundand flash sectors? > > Did you keep the definition of CONFIG_FILE? and what does your config > file contain? > No, I uncommented the HAVE_REDUND definition. But I kept the definition of CONFIG_FILE. However, my config file contains, I think, the right informations: # MTD device name Device offset Env. size Flash sector size /dev/mtd2 0x0000 0x4000 0x4000 > Misconfiguration. I think you left the "#define HAVE_REDUND" in the > header file but use only a simple (non-redundand) flash sector; or > you forgot to remove the CONFIG_FILE or to adapt your config file. > > > Best regards, > > Wolfgang Denk > -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info

2 1

[U-Boot-Users] Setting up environment variables under linux
by Juergen Oberhofer 24 Apr '04

24 Apr '04

Hi, I mapped the environment 'partition' to /dev/mtd2. Using cat /dev/mtd2, I am able to read all the environment variables. Now, I tried to use the fw_printenv tool to get a specific variable, but this led to a crc-error (Warning: Bad CRC, using default environment) My mtd2 partition is on 0x8000 - 0xc000, so I configured fw_env.h: DEVICE1_OFFSET 0x0000 DEVICE1_ESIZE 0x4000 ENV1_SIZE 0x4000 Does anybody know where the problem could be? Regards Juergen -- NEU : GMX Internet.FreeDSL Ab sofort DSL-Tarif ohne Grundgeb�hr: http://www.gmx.net/dsl

2 1

[U-Boot-Users] soft_i2c
by Christian Hohnstaedt 23 Apr '04

23 Apr '04

Hi, a small patch for soft I2C to make it more readable and more general - should not break anything. best regards Christian -- Christian Hohnstaedt Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3308 http://www.innominate.com

2 3

RE: [U-Boot-Users] 512-Bytes EEPROM
by VanBaren, Gerald (AGRE) 23 Apr '04

23 Apr '04

Hi Bruno, If you look in .../common/soft_i2c.c you will find the following: #ifdef CFG_I2C_EEPROM_ADDR_OVERFLOW /* * EEPROM chips that implement "address overflow" are ones * like Catalyst 24WC04/08/16 which has 9/10/11 bits of * address and the extra bits end up in the "chip address" * bit slots. This makes a 24WC08 (1Kbyte) chip look like * four 256 byte chips. * * Note that we consider the length of the address field to * still be one byte because the extra address bits are * hidden in the chip address. */ chip |= ((addr >> (alen * 8)) & CFG_I2C_EEPROM_ADDR_OVERFLOW); PRINTD("i2c_read: fix addr_overflow: chip %02X addr %02X\n", chip, addr); #endif The EEPROM you are using apparently uses the "overflow" method of addressing beyond the first 256 bytes. gvb > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Bruno > Sent: Friday, April 23, 2004 9:51 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] 512-Bytes EEPROM > > > > Hello, > > I'm porting U-Boot 1.1.0 to a board which has a > 512-Bytes EEPROM. So, I set the define > CFG_I2C_EEPROM_ADDR_LEN to 2, to support the 16-bit > addresses. But the EEPROM doesn't worked fine, I can't > even read or write it. If I set this define to 1, the > EEPROM works properly (but only the first 256 bytes). > > So, my question is: it's necessary set another > define/flag to user EEPROMs larger than 256 bytes? > > Thanks in advance, > > Bruno > > > ______________________________________________________________________ > > Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora: > http://br.yahoo.com/info/mail.html > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] MPC885
by Kerl, John 23 Apr '04

23 Apr '04

Oops, I immediately apologize for having neglected to include the subject line last time. My bad! -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] Sent: Friday, April 16, 2004 2:30 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] (no subject) Is anyone starting work on 885 support? We have an 885 board coming up very soon, so I will be happy to help out. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

4 3

RE: [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
by VanBaren, Gerald (AGRE) 22 Apr '04

22 Apr '04

The simplest way for shortcutting... #define CONFIG_SYS_CLK_FREQ get_clock_freq() (writing of an acceptable get_clock_freq()is left as an exercize for the reader) gvb > -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang > Denk > Sent: Thursday, April 22, 2004 1:15 PM > To: Kumar Gala > Cc: U-Boot mailing list > Subject: Re: [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ > > > In message > <66FC73FC-9476-11D8-A48D-000393DBC2E8(a)motorola.com> you wrote: > > I was wondering if there where an examples in the current > u-boot source > > tree in which CONFIG_SYS_CLK_FREQ was determined > dynamically. I have a > > Not exactly for CONFIG_SYS_CLK_FREQ - but the TQM8xxL boards contain > code to measure the input clock against the (known) 32kHz clock. > > > system in which I can read a config register on the board to let me > > know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz. I was hoping to > > have the 16550 uart (and anything else) that needed > CONFIG_SYS_CLK_FREQ > > grab it from a variable instead. > > If you provide a suitable init fuction which sets the value in the > global data section eraly enough, you can probably shortcut the use > of CONFIG_SYS_CLK_FREQ. > > > This is on an MPC85xx platform system. > > ...or any other. > > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de > "There are three principal ways to lose money: wine, women, and engi- > neers. While the first two are more pleasant, the third is by far the > more certain." - Baron Rothschild, ca. 1800 > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

1 0

[U-Boot-Users] dataflash card and boot linux (at91rm9200)
by CG 22 Apr '04

22 Apr '04

Hello, Anybody has already boot linux from a dataflash card? I have the at91rm9200dk and it has a dataflash card socket that I can use. Do I have to write a function in u-boot in order to copy kernel and ramdisk data from the smartcard to the sdram memory? And also a function to copy kernel and ramdisk data into the dataflash card. Best regards Christian

2 2