November 2004 - U-Boot

[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] support for CF/IDE on PCMCIA for PXA25X
by Christian Pell 13 Aug '05

13 Aug '05

Hi, I tried this with some different CFs with FAT file-systems on them. There is a README in the patch itself that goes in documentation directory. Bye, -- Christian Pellegrin <chri(a)ascensit.com>, <c.pellegrin(a)eurotech.it>, <chri(a)infis.univ.ts.it>, <c.pellegrin(a)exadron.com>

4 8

[U-Boot-Users] u-boot 1.1.1 and USB mass storage devices
by Shannon Holland 03 Aug '05

03 Aug '05

Hello, We are using u-boot on a Samsung S3C2410 based board and have USB mostly working using the arm920t USB driver. I say mostly working as some mass storage devices work fine, but most do not. Typically the behavior we see when they don't work is a "usb reset" reports the correct number of devices, a "usb tree" will return the correct device tree but "usb scan" will typically return a lot of CLI:TIMEOUT errors and seemingly never return. Sometimes it is able to find the storage device, but reading from it (it has a FAT16 filesystem) will return similar errors. I'm curious if these are known problems or likely to be something in the way we have (or have not) set up usb? Might anyone have some recommendations as to where to start looking? Thanks for any help! Shannon

5 8

[U-Boot-Users] Loading FPGA from an mkimage created image?
by Steven Scholz 10 Jun '05

10 Jun '05

Hi there, I know that fpga load [device number] [image address] [image size] can be used to init an FPGA. Now I want to compress and wrap the FPGA data with mkimage. Is there a way to pass the address of an Image to "fpga load". Or do I have to umcompress it first using "bootm" or something and then pass the address and size to "fpga load"? Thanks! -- Steven Scholz

2 7

[U-Boot-Users] mkimage for DOS
by Dave Westwood 10 Jun '05

10 Jun '05

long shot really, but does anyone have a working executable mkimage for DOS or a dos window in windows (don't flame me for using windows !!)

2 1

Re: [U-Boot-Users] Support for Samsung 1Giga bit NAND device
by Laurent Mohin 01 Jun '05

01 Jun '05

Andy, U-boot 1.1.0 doesn't provide support for NAND flash with a page size of 2K-byte instead of 512 byte (and you're right, theses devices require special handling). Pantelis Antoniou submitted a patch on 2004-04-30 which seems to manage these new chips, but I don't think it has been added to the latest CVS tree. By the way, Samsung also offer 1 Giga bit devices with a 512 byte page size (K9K1G08UOM - Manufacturer ID : 0xEC, Chip ID: 0x79). Hope this helps, Laurent Andy Hawkins <a.hawkins(a)cabletime.com> Sent by: u-boot-users-admin(a)lists.sourceforge.net 14/06/04 13:40 To: u-boot-users(a)lists.sourceforge.net cc: Subject: [U-Boot-Users] Support for Samsung 1Giga bit NAND device Hi, Can anyone tell me if U-Boot has support for the Samsung 1 Giga Bit NAND devices (Manufacturer ID: 0xec, Chip ID: 0xf1)? I understand these devices have an unusually large block size, that needs special handling. Is this correct? Thanks. Andy ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

4 8

RE: [U-Boot-Users] Re: [PATCH] !CFG_MEMTEST_SCRATCH - do not dereference NULL ptr
by VanBaren, Gerald (AGRE) 30 May '05

30 May '05

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > Of Ladislav Michl > Sent: Thursday, November 25, 2004 6:22 AM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] Re: [PATCH] !CFG_MEMTEST_SCRATCH - do > not dereference NULL ptr > > On Mon, Nov 22, 2004 at 12:07:18PM +0100, Wolfgang Denk wrote: > > There is no explanation what it does or which problem it is > supposed > > to fix. > > When CFG_MEMTEST_SCRATCH is undefined alternate memory test > in do_mem_mtest (with CFG_ALT_MEMTEST defined) dereferences > null pointer. It defines: > vu_long *dummy = NULL; > and later does: > *dummy = ~val; > > > There is also no CHANGELOG entry. > > CHANGELOG > * Patch by Ladislav Michl, 22 November 2004 > - Fix NULL pointer dereference in alternate memory test > (CFG_ALT_MEMTEST) > when if no CFG_MEMTEST_SCRATCH area defined > > Index: common/cmd_mem.c > =================================================================== > RCS file: /cvsroot/u-boot/u-boot/common/cmd_mem.c,v > retrieving revision 1.19 > diff -p -u -r1.19 cmd_mem.c > --- common/cmd_mem.c 10 Oct 2004 23:27:33 -0000 1.19 > +++ common/cmd_mem.c 22 Nov 2004 11:21:43 -0000 > @@ -646,8 +646,9 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int > vu_long num_words; > #if defined(CFG_MEMTEST_SCRATCH) > vu_long *dummy = (vu_long*)CFG_MEMTEST_SCRATCH; > +#define write_dummy(val) do { *dummy = ~val; } while (0) > #else > - vu_long *dummy = NULL; > +#define write_dummy(val) do { } while (0) > #endif > int j; > int iterations = 1; > @@ -723,7 +724,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int > val = bitpattern[j]; > for(; val != 0; val <<= 1) { > *addr = val; > - *dummy = ~val; /* clear the test data > off of the bus */ > + write_dummy(~val); /* clear the test > data off of the bus */ > readback = *addr; > if(readback != val) { > printf ("FAILURE (data line): " > @@ -731,11 +732,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int > val, readback); > } > *addr = ~val; > - *dummy = val; > + write_dummy(val); > readback = *addr; > if(readback != ~val) { > printf ("FAILURE (data line): " > - "Is %08lx, should be %08lx\n", > + "is %08lx, should be %08lx\n", > readback, ~val); > } > } Ladislav: You are fixing the problem in the wrong way. You should point "dummy" at a location in RAM that is writable rather than "fixing" the code by suppressing the dummy write. Being pedantic here, dummy isn't NULL, it is a pointer to the RAM location 0x00000000 (which just happens to be the same as NULL ;-). Strictly speaking, the assignment should have been written "vu_long *dummy = 0x00000000;". The problem here is that the code assumes 0x00000000 is writable and apparently this isn't the case on your board. It obviously is a good assumption on the other boards supported by u-boot (at least the ones that use this POST code :-). The proper fix is, for your board, change the assignment "vu_long *dummy = 0x00000000;" to point to writable RAM on your board. Suppressing the write to 0x00000000 will make the memory test ineffective on all boards (bad, really bad). The purpose of the "*dummy = ~val" statement is to discharge the data bus lines. The problem this is addressing is when the previous line "*addr = val" is executed, the data bus has on it the value "val". Since there is inherent capacitance on the bus lines, that value will persist (float) on the bus for a finite time, longer than it takes for a processor to do the "readback = *addr". The result is that, if the memory doesn't respond and the bus drivers remain tristated, you will think the memory responded properly because you read the residual charge on the bus. The write of "~val" to dummy is a throw-away operation whose purpose is to put something other than "val" on the bus so that a read of the target location won't give a false positive if the memory isn't working properly. Where "dummy" points is immaterial as long as "~val" gets out on the data bus. Normally you would point it in your RAM space, but you actually could point it anywhere that causes a valid write cycle on the data bus. Regards, 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. ******************************************

4 4

[U-Boot-Users] Patch for ADSVIX single board computer with PXA27x processor
by Robert Whaley 08 Apr '05

08 Apr '05

This patch adds support for the ADSVIX SBC with PXA27x processor.

2 3

[U-Boot-Users] Patch to update pxa-regs.h for PXA27x chips
by Robert Whaley 06 Apr '05

06 Apr '05

This patch updates the pxa-regs.h file for PXA27x chips

2 1

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)
by llandre 06 Apr '05

06 Apr '05

I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c). I tested it with the following configurations: Configuration #1: 32 MB (2 chips), SDRAM clk = 133 MHz Configuration #2: 32 MB (2 chips), SDRAM clk = 111 MHz and everything worked fine. Then I tried the following: Configuration #3: 64 MB (2 chips), SDRAM clk = 111 MHz and the SDRAM does not work. U-Boot executes fine until it jumps to SDRAM after relocation. In this case, two chips K4S561632E-TI75 have been used. In my understanding the default value (0x07f00000) for the RTR register is wrong because these chips have a 64 ms/8k cycle refresh. Thus this register should be 0x03780000. I tried to change it but SDRAM did not work anyway. I suspect it is necessary to fix the TR register too or that the value for RTR is wrong. Any suggestions/remarks? TIA and best regards, llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2(a)dave-tech.it

5 11