May 2003 - U-Boot

RE: [U-Boot-Users] MMU setup in u-boot
by john ashfield 12 May '03

12 May '03

Hi, Our processor is MPC7450. We have only one BAT left to setup SDRAM. The other three BAT are used for L3, flash and PCI, and we have 1G memory. I am thinking about using Page Address Translation method using hashing functions as described in the Motorola green book. This method is quite complicated and I dont know where to start with. Any of your feed back is appreciated. Thanks. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

[U-Boot-Users] ARM & Ethernet PHY ???
by Steven Scholz 12 May '03

12 May '03

Hi there, is there support for the LXT971 Ethernet PHY on ATM920T based boards ??? How about arm-linux? Thanks a million, Steven

2 1

[U-Boot-Users] Re: what means this symbol "@"?
by Wells, Charles 12 May '03

12 May '03

>I've never figured out why someone would want to use addi instead of ori in >the second instruction of the load sequence. > >gvb Jerry, The only authoritative explanation I've seen comes from IBM's _The_PowerPC_Compiler_Writer's_Guide_; Steve Hoxey, et.al., 1/1996. Section 3.2.3.1 (p. 48-49) is entitled Loading a Constant into a Register. After discussing the different techniques, they say: "The add instructions are preferred to logical instructions because future PowerPC implementations may have a three-input adder, which permits executing the preceding two instructions (and other forms of add-feeding-add) in parallel, even though they are not independent." If your hand-crafted assembly language is being used to optimize an inner loop, then it may make a difference. If it's used in some one-time initialization code, it doesn't matter. BTW, the CWG is a wonderfully entertaining resource for folks that want to better understand the PowerPC architecture. It's available at: <http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF77852 56996007558C6> Regards, Charlie

1 0

RE: [U-Boot-Users] strataflash.c
by Tom Guilliams 12 May '03

12 May '03

Frank, I can tell you I've had some problems with a x16 in x8 mode in strataflash.c. Basically, the flash_detect_cfi() routine detects my E28F128J3A chip as portwidth 2 (x16) and chipwidth 1 (x8). All the CFI info is read correctly. However, any write accesses to chip (programming or erasing) fail upon the calculated offset (it's incorrectly doubled because of portwidth being 2). I had to manually force the portwidth to 1 (x8) after the flash_get_size() routine to make everything behave for any flash operations. I don't think the "detect" logic is correct in terms of port and chip width for "some" devices. However, the author - Brad Kemp - has said he's had success on numerous other flash width devices. Your problem sounds exactly like mine. For a hack fix, set info->portwidth = 1; for the last thing flash_get_size() does before returning the size. Tom -----Original Message----- From: Frank Smith [mailto:smith@amirix.com] Sent: Friday, May 09, 2003 1:00 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] strataflash.c Hello, I have a board with a couple of Intel RC28F320J3A Strataflash devices. One device is wired to x16 mode, the other to x8 mode. I'm trying to use the strataflash.c driver with these flash chips. The driver detects the flash that's in x16 mode, but not the one in x8 mode. So I'm digging through the code to try to figure out what's up. I've been successful in avoiding dealing with flash programming code up until now in my life..... If anyone knows anything about whether strataflash.c was designed to work with x16 devices in x8 mode, I'd love to hear from you! From what I've seen so far, I'm tending to think that it doesn't. Thanks, Frank. ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ 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] newbie's error on build u-boot
by Zhao Hongda 11 May '03

11 May '03

I'm trying to build u-boot with arm-linux-gcc(gcc 3.2.1, binutils 2.13.90.16, glic 2.3.1), but got the following error: cpu/xscale/start.S:Assembler messages: cpu/xscale/start.S:145 Error: internal_relocation(type: OFFSET_IMM) not fixed up <somethig like above> what should I do to solve this? Hongda Zhao by the way: it can be builded right under arm-linux-gcc 2.95.3.

1 0

[U-Boot-Users] linux doesn't boot when CS for initial cache disabled
by Thomas Schäfer 10 May '03

10 May '03

Hi all, I want to port u-boot to a custom board based on the walnut board where CS0-CS7 are in use by separate chips. I tried to program CS4, which is used for temporary stack and data before relocation, with the settings for a chip after the relocation has been done. u-boot seems to work fine with this setting, global data structure and board info structure are located in RAM and contain the correct values. Loading a kernel via tftp works without problems. As soon as I'm trying to boot the kernel, the system hangs after the kernel has been uncompressed. Trying to debug the kernel boot sequence, I found that the function reloc_offset seems to hang in an endless loop. My question is: why is that CS for the temporary stack of u-boot important for the start sequence of the linux kernel? The Readme says that this stack and data area is only used before relocation of u-boot. Any comments would be appreciated Best regards, Thomas Schäfer ____________________________________ GIGA STREAM - UMTS Technologies GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

3 2

[U-Boot-Users] Change file location
by Rune Torgersen 10 May '03

10 May '03

Hi I am in the process of celaning up a patch to get PCI support to work on a MPC8266ADS board from Motorla. (Patch written by Andy Lowe from MontaVista) There is currently a huge cludge, because the /cpu/mpc8260/pci.c is different for different boards based on the 826x cpu's. The better solution would be to move this file into the board specific directories. If not, I would have to do #ifdef around the whole file. Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

2 1

Re: [U-Boot-Users] [u-boot 3.0 porting to mpc8260 board]
by Wolfgang Denk 10 May '03

10 May '03

In message <001301bf88dd$03fdd520$240110ac@jsbae> you wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_0010_01BF8928.73BCE680 > Content-Type: text/plain; > charset="ks_c_5601-1987" > Content-Transfer-Encoding: base64 > > SGVsbG8gYWxsLA0KSSd2ZSBnb3QgYSBwcm9ibGVtIHdpdGggcG9ydGluZyB1LWJvb3QgMy4wIG9u > IGFuIGVtYmVkZGVkIHN5c3RlbShtcGM4MjUwKQ0KaSB3YW5uYSBpbml0aWFsaXplIHBjaSBidXQg > LCAgaSBjYW4ndCBmaW5kIHBjaV9pbml0X2JvYXJkKCkgLi4uLnRoaXMgZnVuY3Rpb24gY2FsbGVk > IGJ5IHBjaV9pbml0KCkuDQphbmQgd2hlbiBpIGNhbGwgcGNpX21wYzgyNTBfaW5pdCgpPz8gaW4g > Y3B1L21wYzgyNjAvcGNpLmMNCg0KVGhhbmsgeW91Li4uLi4NCioqKioqKioqKioqKioqKioqKioq > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq > KioqKioqDQoguejA5b3EICjb0SDt/iDj1SkNCiAowdYpSU1DxdfFqSC/rLG4sLO537rOILCzud8y > xsANCiDA/MitOjA0Mi04MjItMzQ4NiANCiDG0b26OjA0Mi04MjItMzQ4MyANCiDI3rTrwPzIrTog > MDE5LTQzNC0yOTc1DQogDQogSmFuZy1TaWsgQmFlIA0KIFImRCBEZXZlbG9wbWVudCBUZWFtIDIN > CiBJTUMgVGVjaCBDby4sTHRkLiBLb3JlYQ0KIFRlbDorODItNDItODIyLTM0ODYgDQogRkFYOis4 > Mi00Mi04MjItMzQ4MyANCiBNb2JpbGU6KzgyLTE5LTQzNC0yOTc1DQogDQogRS1tYWlsICA6IGpz > YmFlQGltY3RlY2guY28ua3INCiBNU04gSUQgOiBGZWJfT3ZlcnNldEBob3RtYWlsLmNvbQ0KDQoq > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq > KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo= Please do not post base64 encoded messages to the list. Post plain text only. > ------=_NextPart_000_0010_01BF8928.73BCE680 > Content-Type: text/html; > charset="ks_c_5601-1987" > Content-Transfer-Encoding: base64 > > PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv > L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu > dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T ... Please do not post base64 encoded messages to the list. Please do not post HTML to the list. Post plain text only. Message unreadable, ignored. 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 GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 371140df@csnews

1 0

Re: [U-Boot-Users] CodeWarrior U-Boot debug
by Jerry Van Baren 10 May '03

10 May '03

Sorry, no direct help on CodeWarrior but... stuck in the FP exception would tend to indicate a memory, probably a SDRAM, problem. This is a classic problem: SDRAM appears to work, but is misconfigured and cache burst reading doesn't work properly. This causes a lot of 0xFFs in the instruction stream and these map into FP instructions, causing the FP exception. Reading and writing RAM using your CodeWarrior is NOT a good test of SDRAM. Most often you need to do a burst read for it to fail. Burst reads occur (at this point in the game) only when doing an instruction fetch with the instruction cache enabled. Try running with instruction cache turned off. If it runs slowly but steady :-), you are in the 99% probability it is a SDRAM initialization issue. gvb At 02:25 PM 5/1/2003 -0400, RL(a)prodrive.nl wrote: >Hello, > >Has anyone of you ever used MetroWerks CodeWarrior to debug U-Boot? > >After I've succesfuly compiled the u-boot ELF and binairy I've programmed my >flash with the binairy. > >Next, I've made a CodeWarrior project using the ELF file output of the GNU >Compiler. > >I can connect to the PPC and I can view memory, but when I break the running >process, the cpu is always stuck at address 0x800 (floating point >exception). > >Also I cannot view the code in CodeWarrior?? > >Can someone help me? > >Thx Roel > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >U-Boot-Users mailing list >U-Boot-Users(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/u-boot-users ********************************************************************** This e-mail and any files transmitted with it may be confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster(a)smiths-aerospace.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. Smiths addresses are changing! The new addresses are of the form firstname.lastname(a)smiths-aerospace.com. Please update your address books! Please begin using the new form immediately. ***********************************************************************

2 1

[U-Boot-Users] strataflash.c
by Frank Smith 09 May '03

09 May '03

Hello, I have a board with a couple of Intel RC28F320J3A Strataflash devices. One device is wired to x16 mode, the other to x8 mode. I'm trying to use the strataflash.c driver with these flash chips. The driver detects the flash that's in x16 mode, but not the one in x8 mode. So I'm digging through the code to try to figure out what's up. I've been successful in avoiding dealing with flash programming code up until now in my life..... If anyone knows anything about whether strataflash.c was designed to work with x16 devices in x8 mode, I'd love to hear from you! >From what I've seen so far, I'm tending to think that it doesn't. Thanks, Frank.

1 0