October 2004 - U-Boot

[U-Boot-Users] CFI driver
by York Sun 20 Oct '04

20 Oct '04

I am debugging flash driver for MPC8555CDS board. The driver is drivers/cfi_flash.c. I have two boards. One is rev 1.0, with AM29LV641D. The other is rev 1.1, with AM29LV641M. The problem is polling DQ6 after programming. The current driver in U-boot 1.1.2 works well for AM29LV641M. As for AM29LV641D, the programming hangs after writing about 13KB. I track it down to "flash_is_busy()" function. When the problem occurs, the DQ6 keeps toggling. If I change the algorithm to polling DQ7, no problem occurs. Shawn has a similar problem http://lists.infradead.org/pipermail/linux-mtd/2004-March/009402.html. Maybe we should use DQ7 rather than DQ6. Another issue is the CFI driver might not work for all CFI compatible flash. For example, Micro MT28F640J3. Micro uses status register instead of DQ# polling. Somehow, we still need board specific driver. -- Best regards, York Sun, Ph.D Metrowerks Freescale Semiconductor Inc. Phone: (512) 996-5252 Email: yorksun(a)freescale.com This email, and any associated attachments have been classified as: [x] Freescale Semiconductor General Business [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary

2 4

RE: [U-Boot-Users] BDI2000 flashing problem
by VanBaren, Gerald (AGRE) 20 Oct '04

20 Oct '04

> -----Original Message----- > From: Santoso, Yusdi [mailto:Yusdi_Santoso@adaptec.com] > Sent: Tuesday, October 19, 2004 8:33 PM > To: VanBaren, Gerald (AGRE); u-boot-users(a)lists.sourceforge.net > Subject: RE: [U-Boot-Users] BDI2000 flashing problem > > Hi gvb, > > Thanks for the reply. What you said make sense but somehow I > managed to get it work after tinkering with the BDI config > file. I removed the "WORKSPACE" option in the [FLASH] section > and the "prog" command worked well albeit much slower. > Not sure why it is so...anybody can explain why? > > My RAM is working properly because I can read/write to the > address space perfectly, although I have not done a checker > pattern test. > > Thanks, > > > Yusdi The "workspace" command tells the BDI2000 to load a helper program into RAM. The BDI2000 can then load the to-be-programmed data into a RAM buffer (which is fast) and run the helper program to program the RAM buffer data into flash. This obviously is the faster method, but requires more things to be operational on the board and with the processor. Without the "workspace" command, the BDI2000 programs the data into flash directly which is considerably slower since bit-shifting the commands to do the write and poll for completion, etc. are much less efficient than the workspace method. This is slow but sure and only requires CPU and flash functionality to work. You apparently have a problem with the RAM set up in your config file or a hardware problem with your RAM (in that order of likelyhood). I forgot which processor you have, but most or all of the 8xx/8xxx processors have dual port RAM that you can also use for a workspace. Using this is much less complicated than getting SDRAM configured properly in the BDI2000 config file. Trivia: WD recommends (wisely!) that you do _not_ do the SDRAM initialization in the BDI2000 config file. The problem people have with initializing SDRAM in the config file is that they will do the bulk of their development with the BDI2000 attached and never realize their program's SDRAM initialization is stuffed... then at time (ship_date - 1), they unplug the BDI2000 and find their board is dead without a heart-lung machine and they are in a world of hurt. 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

[U-Boot-Users] RE: Another RTL8139 problem
by Santoso, Yusdi 20 Oct '04

20 Oct '04

Nevermind....fixed it myself... Apparently another one of those infamous PPC endianness problem. Just need to swap the MAC address read from EEPROM before storing it to MAC0 register. Thanks, Yusdi

1 0

[U-Boot-Users] Another RTL8139 problem
by Santoso, Yusdi 20 Oct '04

20 Oct '04

Hi all, I have a strange problem with RTL8139 driver on my dev board (hidden dragon-MPC 8241). Some of you might remember my question regarding setting _IO_BASE for the RTL8139. I have that one solved by setting it to (believe it or not) 0x00000000. Seems like the dev->iobase is set correctly to the device memory space without needing extra _IO_BASE. I verified this by doing memory dump with BDI2000 at the iobase address. To test my settings, I enabled the PING command. The network module was able to detect the presence of the link and to send packet out (I used ethereal on the other end to sniff the packets). My development machine also replied with the appropriate packet as reported by ethereal. Now the problem is that the RTL8139 did not recieve any packet (ChipCmd & RxEmptyBuf != 0) at any time. What could be the problem? Is anybody else using RTL8139 in u-boot? What is your experience? Thanks, Yusdi

1 0

AW: [U-Boot-Users] u-boot 1.1.1 and USB mass storage devices
by Martin Krause 20 Oct '04

20 Oct '04

Hi Shannon, Shannon Holland wrotes on Mittwoch, 20. Oktober 2004 00:25: > On Oct 19, 2004, at 2:38 PM, Wolfgang Denk wrote: > > > There are many, many USB devices out there which are out of spec, > > or where controller/firmware problems get fixed in the windows > > drivers provided by the vendor (either directly or through M$). > > Does anyone have recommendations as to devices that are known > to work? We had similar Problems on a Samsung S3C2400 CPU. The following Sticks are working with our board. - Transcend JetFlash TS32MJFLASH OT; Vendor=0ea0 ProdID=6803 Rev= 1.00 - Transcend JetFlash TS32MJF2B; Vendor=0ea0 ProdID=2168 Rev= 2.00 - Sharkoon 64 MB; Vendor=0d7d ProdID=110e Rev= 2.00 - USB007 BIU32MB; Vendor=0ea0 ProdID=6803 Rev= 1.00 - Sharkoon USB 2.0 FLEXI-DRIVE 64 MB; Vendor=0ea0 ProdID=2168 Rev= 2.00 - Belkin F5U026ea16MB; Vendor=0ea0 ProdID=6803 Rev= 1.00 - Yakumo Quicksave 2.0; Vendor=0ea0 ProdID=2168 Rev= 2.00 But be warned. Many USB-Stick manufacturers often change the internally used usb controller - without changing the name of the stick or even the order number. This happens two times for us. In both cases the new usb controller did not work, so we had to search for another usb stick. USB007 seems to provide some manufacturers of embedded devices with huge unit numbers. So this is perhaps a good address to start searching for sticks with a long availability. Regards, Martin

1 0

RE: [U-Boot-Users] BDI2000 flashing problem
by Santoso, Yusdi 20 Oct '04

20 Oct '04

Hi gvb, Thanks for the reply. What you said make sense but somehow I managed to get it work after tinkering with the BDI config file. I removed the "WORKSPACE" option in the [FLASH] section and the "prog" command worked well albeit much slower. Not sure why it is so...anybody can explain why? My RAM is working properly because I can read/write to the address space perfectly, although I have not done a checker pattern test. Thanks, Yusdi

1 0

[U-Boot-Users] U-Boot, hush and pipes
by Robin Gilks 20 Oct '04

20 Oct '04

Greetings I've been digging into the hush parser and finding, what appear to be, odd things. Obviously masses of the hush functionality has been removed using the __U_BOOT__ #define but some bits that are left seem to be not relevant to the bootloader environment. I'm particularly confused by the pipe operators '&' and '|' and how they are used in u-boot. Is this just a mistake? or am I (as usual) missing something... A quick pass with gcc -E -D__U_BOOT__ is most revealing :-)) -- Robin Gilks Senior Design Engineer Phone: (+64)(3) 357 1569 Tait Electronics Fax : (+64)(3) 359 4632 PO Box 1645 Christchurch Email : robin.gilks(a)tait.co.nz New Zealand ======================================================================= This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. =======================================================================

1 0

[U-Boot-Users] Query: Flash remapping
by Charles J Gillan 19 Oct '04

19 Oct '04

Folks, While reading through the source code for the TQM860L board, I have found some comment cards (and related functional details) that are puzzling me. I can't find anything about this in the archive, so I am raising it here as a question. >From TQM860L.h: lines 323to 328 (u-boot-1.1.1 source) /* used to re-map FLASH both when starting from SRAM or FLASH: * restrict access enough to keep SRAM working (if any) * but not too much to meddle with FLASH accesses */ #define CFG_REMAP_OR_AM 0x80000000 /* OR addr mask */ #define CFG_PRELIM_OR_AM 0xE0000000 /* OR addr mask */ I can see the above hash-defines being used in file ./cpu/mpc8xx/cpu_init.c as follows (lines 176 to 178). /* now restrict to preliminary range */ memctl->memc_br0 = CFG_BR0_PRELIM; memctl->memc_or0 = CFG_OR0_PRELIM; where CFG_PRELIM_OR_AM is used in the definition of CFG_OR0_PRELIM, also in TQML860L.h (line 337). I read Table 15.4 of the Motorola MPC860 Family Users Manual which explains the format of the OR registers. If I understand it correctly, the definition of CFG_PRELIM_OR_AM limits the size of the Flash address range by masking out bits 0,1 and 2. Why are only three bits removed ? Also, what puzzles me is the comment: restrict access enough to keep SRAM working (if any) but not too much to meddle with FLASH accesses Why do we have to restrict access to keep SRAM working ? Any explanations would be appreciated. Thanks, Charles. Dr Charles J Gillan The Institute of Electronics, Communications and Information Technology (ECIT), Queen's University Belfast, Titanic Quarter Queens Road, Queens Island, Belfast, BT3 9DT Northern Ireland, UK Tel: +44 (0) 2890 971847

2 1

[U-Boot-Users] U-Boot not working on TQM860L
by Rami Segal 19 Oct '04

19 Oct '04

Hi, I'm am trying to bring up U-Boot on my TQM860L (8M flash), and have some difficulties. The instructions are simple and straight forward (I compile with the TQM860_config parameter). The burning of the u-boot.bin file is successful (address 0x40000000). However, when turning on the power, the system does not respond! The terminal is dead. I know that the system is functional, because other bootstrap programs, such as the TQC monitor, work fine. Are there any configurations that should be changed in the TQM860L.h configuration file? Any other ideas that might help? Thanks, Rami.

2 1

[U-Boot-Users] Re: U-Boot-Users -- confirmation of subscription -- request 357367
by Paul Wujek 19 Oct '04

19 Oct '04

> U-Boot-Users -- confirmation of subscription -- request 357367 > > We have received a request from 216.8.140.170 for subscription of your > email address, <pwujek(a)xp2telecom.com>, to the > u-boot-users(a)lists.sourceforge.net mailing list. To confirm the > request, please send a message to > u-boot-users-request(a)lists.sourceforge.net, and either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 357367 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to > u-boot-users-admin(a)lists.sourceforge.net. > > -- Paul Wujek, Director Network Software, Xp2 Telecom Inc.

1 0