October 2004 - U-Boot

[U-Boot-Users] cfi_flash.c
by Tolunay Orkun 04 Oct '04

04 Oct '04

We are using this driver with CSB272 and CSB472 (both PPC405 based boards). The driver works OK on CSB272 where flash is setup as 2 side-by- side chips each x16 and accessed via a 32 bit CS. However, on CSB472 we have some apparently minor issue somewhere. The flash is setup as 1 chip of x16 and accessed via a 16 bit chip select. The protect on/off, erase commands work well. cp command also work OK but after the flash write is completed it leaves the flash array in command mode instead of returning to read mode. The workaround for now is to reset the board after programming or issue a protect on/off command. The flash chip is an Intel 28F640 and I've sync to U-Boot CVS last monday. Has anyone seen this problem, made a patch? I've posted about this before a few months ago but there was more pressing issues to deal with. If someone has solved this problem and a patch is in pipeline, I would like to try it otherwise I need to get my hands dirty to find out why the array is left in command mode. Best regards, Tolunay

1 0

[U-Boot-Users] Usb support
by swamy 04 Oct '04

04 Oct '04

Hi, I am interested in knowing any development on bootloader (Uboot) to download kernel using usb port( PXA255) instead of serial or Ethernet? Thanks swamy

1 0

AW: [U-Boot-Users] problem with cfi_flash.c & AT91RM9200DK
by Martin Krause 04 Oct '04

04 Oct '04

Hi Morten, Morten wrotes on Montag, 4. Oktober 2004 12:40: > Hello ! > > I have exchanged the flash on my AT91RM9200DK with a > AT49BV320C cfi flash, > and done all needed mods to the config file, every thing > seems ok except > that it get the size of the flash > incorectly. > > It sayes that it is a 16x16 4m, 71 sector cfi complient > flash, when it > should be a 2097 x 16, 32m, 71 sector flash ? Why should it be 2097 x 16, 32m? The datasheet says the flash is organized 2M x 16. This means 2M (= 2^21 = 2.097.152) Addresses each 16 Bit (= word) wide. And this is a size of 4 MByte. > size_ratio 1 port 16 bits chip 16 bits ... > Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 71 Sectors This means U-Boot has detected a flash that is connected to a 16 bit port (bus) and the flash chip itself has also a 16 bit wide interface. The dirver seems working correctly to me. Regards, Martin

1 0

RE: [U-Boot-Users] Relocate code
by Holger L. Bille 04 Oct '04

04 Oct '04

Hi Raju Sending HTML to this list is inconsiderate. Please don't! > <A target="_blank" HREF="http://clients.rediff.com/signature/track_sig.asp"><IMG SRC="http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbo…" BORDER=0 VSPACE=0 HSPACE=0></a> Sending tracking HTLM is downright rude! Don't do that! Not to this list - don't do it at all! Holger Bille -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net on behalf of raju rediff Sent: Mon 2004-10-04 8:26 To: u-boot-users(a)lists.sourceforge.net Cc: Subject: [U-Boot-Users] Relocate code Hi, Can any of you tell what exactly "relocate_code" function does when a. u-boot code is fused into the prom b. u-boot code is loaded into RAM using emulator It will be grateful if you can tell taking sbc board as reference. With Best Regards, Raju

1 0

[U-Boot-Users] Relocate code
by raju rediff 04 Oct '04

04 Oct '04

Hi, Can any of you tell what exactly "relocate_code" function does when a. u-boot code is fused into the prom b. u-boot code is loaded into RAM using emulator It will be grateful if you can tell taking sbc board as reference. With Best Regards, Raju

1 0

[U-Boot-Users] pagetable / BDI2000 question
by Stuart Yoder 04 Oct '04

04 Oct '04

This is not specifically a u-boot question, but involves some things that knowledgeable u-boot person may have insight into. We are debugging a Linux kernel that has been booted via U-boot on our own custom PowerPC board-- 750GX processor. Early in the Linux kernel initialization our system bridge chip (Marvell 64360 / DiscoveryII) is remapped to a new virtual address (via the ioremap() kernel call). At that point the new virtual address returns bad data. Physical address is: 0xF1000000 Original virtual address: 0xF1000000 Remapped virtual address: 0xEF5F0000 After the remapping occurs the following is true: -programmatic/kernel access to virtual address 0xF1000000 returns good data -programmatic/kernel access to new virtual address 0xEF5F0000 returns bad data -access via the BDI2000 to address 0xF1000000 returns good data -access via the BDI2000 to address 0xEF5F0000 returns _good data_ THIS MAKES NO SENSE. The fact that the BDI2000 can read the data proves that the page table entry is good. Here is the key question: How is it possible that the same location in memory accessed via the BDI2000 and accessed programmatically return DIFFERENT values. This remapped location is not supposed to be cached since it is IO memory. We have the page table / mmu option turned on the BDI config. Also, the Linux kernel has the BDI2000 config option enabled. Stuart

2 1

[U-Boot-Users] [PATCH] Add support for OMAP242x/arm1136 and TI H4 omap242x reference board 2/2.
by Woodruff, Richard 01 Oct '04

01 Oct '04

Hello, This patch adds support for the TI OMAP2420 processor and its reference board the H4. It like other OMAP's it has multiple cores. The ARM core is an ARMv6-ARM1136JF-S. The patch is a bit big, but it mainly is new files, and a couple minor OMAP specific teaks to a few common files. The patch was done against the latest image out on ftp.denx.de (u-boot 1.1.2). I have been using a GCC-3.4.0 tool chain downloadable from Codesourcery to build this. GCC 3.4 is the first version of GCC which has ARMv6 support. Thus this tool chain is required for kernel builds as the v6 kernel makes use of v6 instructions. U-boot could be a bit more flexible, but all my testing so far has been with this version of GCC. The is currently split into two parts. Regards, Richard W.

1 0

[U-Boot-Users] [PATCH] Add support for OMAP242x/arm1136 and TI H4 omap242x reference board 1/2.
by Woodruff, Richard 01 Oct '04

01 Oct '04

Hello, This patch adds support for the TI OMAP2420 processor and its reference board the H4. It like other OMAP's it has multiple cores. The ARM core is an ARMv6-ARM1136JF-S. The patch is a bit big, but it mainly is new files, and a couple minor OMAP specific teaks to a few common files. The patch was done against the latest image out on ftp.denx.de (u-boot 1.1.2). I have been using a GCC-3.4.0 tool chain downloadable from Codesourcery to build this. GCC 3.4 is the first version of GCC which has ARMv6 support. Thus this tool chain is required for kernel builds as the v6 kernel makes use of v6 instructions. U-boot could be a bit more flexible, but all my testing so far has been with this version of GCC. The is currently split into two parts. Regards, Richard W.

1 0

[U-Boot-Users] [PATCH] - fixed missing System ACE CF device
by Sean Chang 01 Oct '04

01 Oct '04

Hi, If there are any problems please let me know and I'll be more than happy to fix it. This patch is applied against the u-boot 1.1.1 release. The CHANGELOG is below. Regards, Sean ======================================================================= CHANGELOG (ace_fat.patch): Patch by Sean Chang, 9 Aug 2004: Fixed missing System ACE CF device during get FAT partition info in fat_register_device function. =======================================================================

3 8

RE: [U-Boot-Users] fishing for ideas
by VanBaren, Gerald (AGRE) 01 Oct '04

01 Oct '04

> -----Original Message----- > From: u-boot-users-admin(a)lists.sourceforge.net > [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Benjamin > Collar > Sent: Friday, October 01, 2004 12:04 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: [U-Boot-Users] fishing for ideas > > > Greetings folks > > Yesterday's problems have been overcome. Mostly I was just > misunderstanding what was going on / what was supposed to be going on. > Thanks for the clues overall. > > But there is a bit more to it. At the end of the day yesterday, I > performed exactly the same 'loads' command, with exactly the > same srec > file, as I had done at the beginning of the day, and it worked. Talk > about frustration! > > Today I was working on it and loaded a linux kernel image. When I > 'loads' it, using the u-boot command line, into ram, the 'md' > command at > the loaded area shows > > 00010000: 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., > 00010010: 7d8c5a14 3940ffff 914c0000 3bffffe0 }.Z.9@...L..;... > 00010020: 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... > 00010030: 00000000 00000000 00000000 00000000 ................ > > while objdump shows > > 00000 27051956 d3232bea 415d1e66 0005ba2c '..V.#+.A].f..., > 00010 00000000 00000000 82847f95 05070201 ................ > 00020 4c696e75 782d322e 342e3138 00000000 Linux-2.4.18.... > > of course, you'll notice immediately that the 5th word is completely > bogus, among others. > > I've spoken with the board developer (who also wrote a bootloader for > the board) and showed him the sdram initialization function, > and he said > it was correct. However, I've got the behavior shown above. Is there > another reason why this sort of corruption would happen? (btw, using > 'cu' to download the image into RAM). > > Thanks for any tips > Ben > > -- > Benjamin Collar > Siemens AG > CT SE 2 > Embedded Linux > 089-636-53711 Just because he said his bootloader works doesn't necessarily mean it really and truly works (I'm a skeptic: my first statement is invariably "show me"). Do you have caching enabled? Did he? Caching enables burst mode which is a well know cause of SDRAM corruption due to what appears to be and is claimed to be working initialization but actually is not correct. Can you create a situation where the same operation works on his bootloader but doesn't work on yours? Can you make his bootloader fail like yours when doing the same or similar operation (not necessarily downloading with cu)? Yours with no answers, just questions... gvb ****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak: ****************************************** 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