May 2003 - U-Boot

[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