April 2004 - U-Boot

[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