May 2003 - U-Boot

[U-Boot-Users] patch to support intel e1000 family
by Mark Rakes 14 May '03

14 May '03

Wolfgang, etc. this patch adds support for Intel e1000 gig cards. Tested in u-boot with Sandpoint 8245 and the PRO/1000 MT Copper card (82546-based) and in ppcboot against that card, and its 82546 fiber equivalent. ran Lindent :) ran MAKEALL. did a diff against top of CVS. let me know if I need to make any patch modifications. enjoy, -mark rakes CHANGELOG entry: * Patch by Mark Rakes, 14 May 2003: Add e1000 driver

1 0

[U-Boot-Users] adding a command to write to regiters
by Paul,Kunal 14 May '03

14 May '03

hello all, i am workin on a custom board.i want to add commands for writing and reading to/from the CPU n PHY registers... can someone help me by telling me what all is required to be done...also i want to add a command to read and write boot n user flashes.... i need help on both. thnx... regards, kunal

1 0

[U-Boot-Users] using both AMD n Intel sync strata flashes on a board
by Paul,Kunal 14 May '03

14 May '03

hi all, i have a custom board wherein i am using an AMD flash as the bootflash and an INTEL synchronous strata flash(K3 n K18) as the user flash...can anybody help me with hoe to go about porting the u-boot for both... thnx, regards, kunal

1 0

[U-Boot-Users] walnut board
by Iser Flaum 14 May '03

14 May '03

first time user trying to run clone variation of the walnut bd. IBM demo board flash binary image (using PROM burner) runs (although having LAN problems to be debugged), and talks to the serial console ok. when trying to build the IBM provided source and makefile for this target, does not work (at least does not talk to console). already found one needed correction to the makefile.mak file .... the hbranch utility specified a wrong size flash (0x20000) instead of 0x80000 (512kB flash both on walnut demo and my clone). seeking information of other makefile.mak problems which may need correcting. it seems that the reset_entry block is being loaded at 0x2020 instead of 0x62020 (near the top of the flash). are there other alternative boot source/build tools available to get my board working? Iser Flaum (562) 926-6727 x113 iser(a)corelis.com

1 0

Re: [U-Boot-Users] IBM 440GP Ebony board: Gigabit ethernet adapter
by Mark Rakes 14 May '03

14 May '03

I "ported" a polling-based driver from the Etherboot project, which in turn had ported it from the Intel Linux (interrupt-based) driver. I've used it with both the 82546-based Dual Gig Copper adapter (pro/1000 MT) and the 82546-based Dual Gig Fiber adapter (don't know the model # off hand). We don't have a 64 bit environment, and we don't do PCI-X, so I'm not sure what that part will take, but this should be a start, hopefully... good luck, -m On Tuesday, May 13, 2003, at 03:33 PM, Dhanuka, Anupam wrote: > Hi Mark > > Thanks for your response. > > I am not sure what you mean when you say "via Etherboot via Linux Intel > Driver". Could you elaborate? > > Is the e1000 same as the Server Adapter (I want to use 64 bits)? What > would the differences be for PCI-x support? > > I am sorry but I am fairly new to this Boot Loader area. I am not used > to the terminology yet. > > Thanks > > Anupam > > > > -----Original Message----- > From: Mark Rakes [mailto:mrakes@vivato.net] > > I have a working e1000 driver (via Etherboot via Linux Intel driver) > for ppcboot on PCI (not PCI-X). > > I haven't submitted it back to the list as we're still using ppcboot > 2.0 and I hadn't taken the time to do the "port" the driver to u-boot > yet. > > I'll try to do that in today, if I can... > > no promises on pci-x, though... > -Mark > > > On Tuesday, May 13, 2003, at 02:26 PM, Wolfgang Denk wrote: > >> Dear Anupam, >> >> in message <2692A548B75777458914AC89297DD7DA021CCCC6(a)bronze.dolby.net> > >> you wrote: >>> >>> I have the IBM "Ebony' reference board with IBM 440GP processor. I >>> want >>> to use the Intel 1000/MT Gigabit Server Adapter as a network > interface >>> to load the OS image over the network. The adapter is connected to > the >>> PCI-X slot. I was wondering if U-boot has support for such an >> >> No,not yet (AFAIK). >> >>> arrangement. If not then where can I find more help and if I were to >>> develop the driver for this adapter myself, then how feasible would > it >>> be. >> >> It's a routine job for some of the developers on this list, and out >> of reach for others. Sorry, but I don't know your level of >> experience.

1 0

[U-Boot-Users] IBM 440GP Ebony board: Gigabit ethernet adapter
by Dhanuka, Anupam 13 May '03

13 May '03

Hi all I have the IBM "Ebony' reference board with IBM 440GP processor. I want to use the Intel 1000/MT Gigabit Server Adapter as a network interface to load the OS image over the network. The adapter is connected to the PCI-X slot. I was wondering if U-boot has support for such an arrangement. If not then where can I find more help and if I were to develop the driver for this adapter myself, then how feasible would it be. Help will be extremely appreciated. Anupam This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited.

3 2

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

13 May '03

In a x16 device in x8 mode, the portwidth should be 1. However, CFI detection in strataflash.c will not work in this mode. It will look for the CFI QRY at 0x10, 0x11, 0x12 offsets when they're actually at double that offset (portwidth = 2). I agree that the portwidth is not be used correctly in the case of a x16 device in x8 mode. For the meantime, the hack I've made will sustain me until I or someone else can add support for this chipset mode to the driver. Tom -----Original Message----- From: Frank Smith [mailto:smith@amirix.com] Sent: Sunday, May 11, 2003 4:51 PM To: Tom Guilliams; u-boot-users(a)lists.sourceforge.net Cc: Frank Smith Subject: Re: [U-Boot-Users] strataflash.c Hi, The more I look into strataflash.c, the more I'm starting to think that it doesn't support x16 devices in x8 mode. The problem I see is that the 'portwidth' value is used to drive two things -- offset multiplier, and side of data reads/writes to the flash device. On a pure x16 device, the offset multiplier is 2 and the size of the data read/writes is 2. So portwidth is 2. On an x16 device in x8 mode, however, the offset multiplier is 2, but the size of data read/writes is 1. What should portwidth be...? I think the offset multiplier and size of data read/writes should be driven by *different* values. Or am I overlooking something obvious? Thanks, Frank. ----- Original Message ----- From: "Tom Guilliams" <tguilliams(a)sbs.com> To: "'Frank Smith'" <smith(a)amirix.com>; <u-boot-users(a)lists.sourceforge.net> Sent: Friday, May 09, 2003 7:14 PM Subject: RE: [U-Boot-Users] strataflash.c > 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 > > > ------------------------------------------------------- > 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 >

1 0

RE: [U-Boot-Users] StrataFlash on PrPMC800
by Brad Kemp 13 May '03

13 May '03

Try ppmc8260/strataflash.c it autodetects the chip and port width Brad -----Original Message----- From: Mark.Lightfoot(a)sita.aero [mailto:Mark.Lightfoot@sita.aero] Sent: Tue 5/13/2003 2:13 PM To: u-boot-users(a)lists.sourceforge.net Cc: Subject: [U-Boot-Users] StrataFlash on PrPMC800 Hello, I've been working on a port of U-Boot for the Motorola PrPMC800 and I've come up against my first obstacle, CFI detection of the flash. The board implements two Intel 28F128J3 devices which, according to Motorola documentation, are each 8 bits wide residing on a 16 bit wide bus. I take that to mean they are interleaved to form a virtual 16 bit wide device. I've already taken care of mapping the devices into the CPU's address space. I borrowed the source code for flash support from the EVB64260 but it didn't work. It fails because it can determine the manufacture code Do any of the supported boards already support devices in a similar configuration? Could the source code possibly be reused for the PrPMC800? I don't know anything about how CFI works so I'm trying to avoid doing it from scratch. From the looks of it, it shouldn't be necessary to reinvent the wheel. But, if I've to start from scratch, anyone know of a good CFI tutorial. I've got the JEDEC docs but can make much of them yet. Regards, Mark. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Mark Lightfoot - Software Designer - SITA 777 Walker's Line, Burlington, Ontario, Canada, L7N 2G1 905-681-5575 mark.lightfoot(a)sita.aero ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ------------------------------------------------------- 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

1 0

[U-Boot-Users] StrataFlash on PrPMC800
by Mark.Lightfoot＠sita.aero 13 May '03

13 May '03

Hello, I've been working on a port of U-Boot for the Motorola PrPMC800 and I've come up against my first obstacle, CFI detection of the flash. The board implements two Intel 28F128J3 devices which, according to Motorola documentation, are each 8 bits wide residing on a 16 bit wide bus. I take that to mean they are interleaved to form a virtual 16 bit wide device. I've already taken care of mapping the devices into the CPU's address space. I borrowed the source code for flash support from the EVB64260 but it didn't work. It fails because it can determine the manufacture code Do any of the supported boards already support devices in a similar configuration? Could the source code possibly be reused for the PrPMC800? I don't know anything about how CFI works so I'm trying to avoid doing it from scratch. From the looks of it, it shouldn't be necessary to reinvent the wheel. But, if I've to start from scratch, anyone know of a good CFI tutorial. I've got the JEDEC docs but can make much of them yet. Regards, Mark. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Mark Lightfoot - Software Designer - SITA 777 Walker's Line, Burlington, Ontario, Canada, L7N 2G1 905-681-5575 mark.lightfoot(a)sita.aero ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

1 0

[U-Boot-Users] How to debug u-boot?
by huasee 13 May '03

13 May '03

hi, How to debug u-boot?Is it necessarily to use emluator e.g.BDI2000? Can I use some software to debug (just as kgdb?)

1 0

[U-Boot-Users] porting problem on porting to similar FADS860 board
by John 12 May '03

12 May '03

Hello list! I've checked the archives, but have not found anyone using the 860 with my problem. I have a MPC860 board ported from FADS860 board. ( TEXT_BASE is also 0x2800000, but IMMR is 0x2200000). I have vxworks run OK on it. But when I am porting U-Boot on it. I met booting problem on it. For Example as following: (ELDK1.0 + U-boot-0.3.0) ---------------------------------------------------------------------------------------- located in /cpu/mpc8xx/start.S .globl _start .extern testLed _start: lis r3, 0x220 /* my IMMR addr is 0x2200000 */ ori r3, r3, 0x0000 mtspr 638, r3 /*IMMR SPR is 638*/ bl testLed /* this is to light LEDs on board(PA0 - PA3)*/ ---------------------------------------------------------------------------------------- located in /cpu/mpc8xx/cpu_init.c void testLed(void) { int i,k; for(k=0;k<5;k++) { * ( (volatile unsigned short *) (0x2200000 + 0x950) ) = 0xA000; /* light LED */ for (i=0; i<0xFFFF;i++) {;}; * ( (volatile unsigned short *) (0x2200000 + 0x950) ) = 0x0000; /* unlight LED */ for (i=0; i<0xFFFF;i++) {;}; }; }; When I build to *.bin and burn into bootrom flash, after power on, the LEDs of board are not lighting. But, I tested these codes under Vxworks Bootrom code (rominit.S), that's OK. maybe it is linking problem? I 'm confused. Could you like to help me or give me any comments ? Thanks in advance! John

1 0

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

12 May '03

Here is what I did: I'm testing with an IBM Walnut board (PPC405GP) with u-boot 0.3.0 and 2.4.17 kernel from Montavista. After booting u-boot and loading the kernel via tftp, I submit the following commands on the console: => setdcr 12 0012: 00000004 ? 7 0012: 00000007 ? . => setdcr 13 0013: 400da000 ? 0 0013: 00000000 ? . This disables CS7, which is used for the temporary stack in my configuration. The kernel function start_here (arch/ppc/kernel/head_4xx.S) is the place where the MMU is used first. Setting a breakpoint (in my case at 0xc00022d0) and trying to trace from this point with my BDI2000 results in a data machine check interrupt: BDI>bi 0xc00022d0 Breakpoint identification is 0 BDI>go - TARGET: target has entered debug mode BDI>info Target state : debug mode Debug entry cause : instruction breakpoint Current PC : 0xc00022d0 Current CR : 0x24004004 Current MSR : 0x00001030 Current LR : 0x0000001c BDI>ti Target state : debug mode Debug entry cause : JTAG stop request Current PC : 0x00000280 Current CR : 0x28004004 Current MSR : 0x00000000 Current LR : 0xc0002b34 # Step timeout detected BDI> Unfortunately I have no idea why this happens. Looking at the register contents I found that the address of the temporary stack (0x40000000) is still stored in r2, but this should have no effect on booting the kernel??? BDI>rd GPR00: c00022d0 07f9f5e8 40000000 c10003c0 GPR04: c0000000 00000000 007ffc00 007ffc0e GPR08: 07fc9f10 000186a0 00000003 00000002 GPR12: 00000000 c01605b0 07fe5800 00000000 GPR16: 00000001 007ffc0e 007ffc00 ffffffff GPR20: 00000000 07fe2398 07f9fe88 00000002 GPR24: 00000000 00000000 007ffb90 007ffc0e GPR28: 007ffc00 00000000 00000000 007ffb90 CR : 24004004 MSR: 00001030 BDI> Any ideas? Best regards, Thomas Schaefer ____________________________________ 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

1 0

RE: [U-Boot-Users] Change file location
by Rune Torgersen 12 May '03

12 May '03

>> There is currently a huge cludge, because the /cpu/mpc8260/pci.c is >> different for different boards based on the 826x cpu's. > >Oops?? We use the current version of cpu/mpc8260/pci.c omn several >boards already, without #ifdef'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. > >Can you please explain why you think this is a board specific file? Because the PCI Maemory and IO map is defined there, and it does depend a bit on how you want the board set up. I guess it can be used for multiple boards if the memory map should be the same. I know the reason Andy changed the pci.c memory map, was to get a simpler memory layout in linux. Here is his motivation for changing it: * This file is a bit of a problem since the PCI memory map is hardcoded here in code common to all MPC8260 targets, but one memory map may not necessarily be appropriate for all targets. For now I just changed the hardcoded memory map to one that I like better. This probably broke the PM826 u-boot port. The memory map definition could be #ifdef'd for each board, or the memory map definition could be moved to the board configuration header file. My motivation here was to move the PCI I/O space from 0xA0000000 to 0xF4000000. Having all the I/O regions above 0xF0000000 allows Linux to efficiently map them all with one BAT register.

2 1

RE: [U-Boot-Users] MMU setup in u-boot
by Jerry Van Baren 12 May '03

12 May '03

Sorry, you will have to go complex if you want to reach all your memory. gvb At 12:29 PM 5/12/2003 -0400, johny122(a)hotmail.com wrote: >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. ********************************************************************** 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. ***********************************************************************

1 0

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

12 May '03

Hi, u-boot setups MMU for maximum of 256M memory using Block Address Translation. Do you have any idea how to setup MMU for more than 256M (for example 1G of memory)? Thanks _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

4 4

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