September 2003 - U-Boot

[U-Boot-Users] [PATCH] build on Cygwin
by Anders Larsen 18 Sep '03

18 Sep '03

Hi, here's a patch against 0.4.8 that allows U-Boot to be built on a Cygwin- hosted platform. Problems solved: - mkimage.c, img2srec.c and bmp_logo.c wouldn't compile - mkimage converted all 0x0a to 0x0d 0x0a in the binary image CHANGELOG: allow mkimage to build and run on Cygwin-hosted systems Cheers Anders

3 4

[U-Boot-Users] AT91RM2000DK: Location of U-Boot?
by Steven Scholz 18 Sep '03

18 Sep '03

Hi there, where is U-Boot stored on the AT91RM9200DK eval board? At the beginning of the parallel flash? Or in the 128kB two-wire EEPROM? Thanks, Steven

1 0

[U-Boot-Users] 回覆：[U-Boot-Users] Re: Patch s3c2410 nand-boot.
by KevinLiao＠iei.com.tw 18 Sep '03

18 Sep '03

3 2

[U-Boot-Users] bdiGDB configuration for AT91RM9200DK ??
by Steven Scholz 18 Sep '03

18 Sep '03

Hi there, has someone a bdiGDB configuration for Atmel AT91RM9200DK evaluation board? Thanks, Steven

1 0

[U-Boot-Users] [PATCH] MPC8266 default config...
by Rune Torgersen 18 Sep '03

18 Sep '03

A few things had to be changed to get the board to run correctly on using u-boot 0.4.8. CHANGELOG * Changed sdam parameter init so Page Based mode works for standard 16MB DIMM * Changed reset addess (CFG_RESET_ADDRESS) * Added SDRAM init delay for standard 16MB DIMM This is the weird part. On my 8266ADS board, If I don't have a delay between memory init and code relocation, u-boot hangs, but only when using the 16MB DIMM that came with the board. Using any other DIMM works great. Rune Torgersen System Developer Innovative Systems LLC 1000 Innovative Drive Mitchell, SD 57301 Ph: 605-995-6120 www.innovsys.com

2 1

[U-Boot-Users] [PATCH] enable 3.rd UART on PXA
by Anders Larsen 18 Sep '03

18 Sep '03

Hi, here's a patch against 0.4.8 that enables the 3.rd UART (ST-UART) on the PXA(XScale) CPUs. Furthermore, it enables watchdog-support in the same way it's already implemented on numerous other devices. CHANGELOG: Allow the PXA ST-UART to be used as console Cheers Anders

2 1

[U-Boot-Users] [PATCH] allow CFG_ALT_MEMTEST to be used on ARM
by Anders Larsen 18 Sep '03

18 Sep '03

Hi, here's a patch against 0.4.8 that allows CFG_ALT_MEMTEST to be used on systems where writing to address zero crashes the system. On ARM (well, at least on my PXA255) writing to address zero causes a "data abort" (which, IMHO, is a Good Thing(tm)). This patch allows the board-specific config to define an alternative scratch-address (CFG_MEMTEST_SCRATCH) to be used by the extensive memory test. CFG_MEMTEST_SCRATCH does not have to point to physical RAM, it only has to point to a writeable (not necessarily readable) address. CHANGELOG: Allow CFG_ALT_MEMTEST on systems where address zero isn't writeable Cheers Anders

2 1

[U-Boot-Users] [PATCH] fix potential crash-window
by Anders Larsen 18 Sep '03

18 Sep '03

Hi, here's a patch against 0.4.8 that closes a window where any console-I/O would crash U-Boot. Specifically, the setting of GD_FLG_DEVINIT is delayed until the console is completely initialized. CHANGELOG: don't declare "all devices initialized" until they really are... Cheers Anders

2 1

[U-Boot-Users] [PATCH] fix spelling errors
by Anders Larsen 18 Sep '03

18 Sep '03

Hi, here's a patch against 0.4.8 that fixes some spelling mistakes CHANGELOG: fix spelling mistakes Cheers Anders

2 1

[U-Boot-Users] RE: Determining the UPMA. UPMB SDRAM table
by Keith Outwater 17 Sep '03

17 Sep '03

> -----Original Message----- > From: Raghu [mailto:raghu_dk@yahoo.com] > Sent: Tuesday, September 16, 2003 8:30 PM > To: u-boot > Subject: [U-Boot-Users] Determining the UPMA. UPMB SDRAM table > > > Hello, > > Just courious to know how does one determine the SDRAM > table to MPC8xx family of processors ?? > > Warm Regards > Raghu. Raghu - As Robin Gilks pointed out in another post, Motorola has a tool called MCUinit on their web site that also includes a tool called UPM860. UPM860 allows you to graphically edit the SDRAM timing waveforms and then generate a UPM table. Very handy (I used UPM860). I also found Motorola application note AN2066/D very helpful when designing my SDRAM hardware interface and writing the UPM tables and SDRAM init code. Finally, take a look at the SDRAM initializations of 860 based boards in the U-Boot sources. You can get a good head start by doing this and depending on the SDRAM you use, you may be able to copy the UPM tables and initializations. Many SDRAMs from different manufacturers use the same or similar init sequence and timing. Just remember that if you copy the UPM tables from another board, be sure to determine which UPM outputs are connected to which SDRAM pins. The MPC860 provides a lot of flexibility in this area and different hardware designs may use different pin assignments. Read your SDRAM datasheet carefully and implement the required initialization. One final tip: if you copy the UPM tables, feed the tables back into UPM860 and you'll get a graphical representation of the timing. This reverse-engineering step will allow you to see what's going on and make any changes that may be appropriate for your particular hardware. The port I did of U-Boot to my generic MPC860T design (GEN860T) may be a possible starting point. I tried to make the SDRAM init clear and straightforward. Hope this helps, Keith Keith Outwater Sr. Staff Engineer Microvision, Inc. 19910 N. Creek Parkway Bothell, WA 98011

1 0

RE: [U-Boot-Users] MPC8266ADS
by Rune Torgersen 17 Sep '03

17 Sep '03

Make sure you burn the flash image for U-Boot at the very start of flash (no matter where that is). If you program it with the jumper in the default position, start programming at 0xff800000. This will place the image correctly. (New HRCW _must_ be at very start of memory) > I should have said, the latest u-boot-0.4.x. I did a cvs > checkout last night > which shows me the LABEL_2003_09_13_2100 for mpc8266ads.c. > And I confirmed > that mpc8266ads.c does indeed have the PBI turned off. Will verify latest later today.

1 0

[U-Boot-Users] data abort
by Glenson Muthedan 17 Sep '03

17 Sep '03

Hello everybody! First of all thanks to Wolfgang Denk and Robert Schwebel for the helpful instructions to get started with U-Boot and BDI2000. Now, I've a new problem: When U-Boot starts I can see following outsputs through "cu", before the system stops due to a data abort. (My board: PXA250, 32MB SDRAM, 32MB Strataflash, etc.) **************************************************** U-Boot 0.4.0 (Sep 15 2003 - 12:09:08) U-Boot code: A1FE0000 -> A1FF5728 BSS: -> A1FF6BD4 DRAM Configuration: Bank #0: a0000000 32 MB Flash: 32 MB data abort undefined instruction undefined instruction undefined instruction **************************************************** I put some printf-lines(beginning with GM) in the soucecode to see where the execution stops. Here, my debug-output: **************************************************** U-Boot 0.4.0 (Sep 15 2003 - 12:23:05) U-Boot code: A1FE0000 -> A1FF5870 BSS: -> A1FF6D1C DRAM Configuration: Bank #0: a0000000 32 MB Flash: 32 MB GM: lib_arm/board.c; entering devices_init() GM: common/devices.c; entering ListCreate() GM: common/lists.c; after 'list = (list_t) (NewHandle (sizeof (ListStruct)))' GM: common/lists.c; list = 0badc108 GM: common/lists.c; *list = a1ff10a0 data abort prefetch abort prefetch abort prefetch abort prefetch abort **************************************************** If I understand right, this exception occurs due to access to the contents of the created list. For example at the line(lists.c: ListCreate): (*list)->numItems = 0; Why does this happen? I'm quite sure that my Flash and SDRAM are working properly. Can somebody suggest a way to workaround this problem? Thanks. Glenson Muthedan.

4 12

[U-Boot-Users] MPC8266ADS
by Jeff Angielski 17 Sep '03

17 Sep '03

>The current configuration in U-BOOT works, and boots Linux with no problem. >It will, however, not work on a virgin ADS development board. You have to >change one jumper to get the CPU to use the Hardware Configuration word from >Flash, and not from BCSR... (JP3 I think). Can somebody confirm that the latest u-boot-0.4.0 with default settings on all jumpers except for JP3 works correctly. I just downloaded the latest code from CVS and it is not working for me. Incidentally, u-boot-0.3.0 works on the board with the default jumper settings (including JP3 on 2-3 BCSR) and no code changes right out of the box. Also, does anybody have a BDI2000 config file for the MPC8266ADS that matches the new configuration from u-boot-0.4.0? -- ==================================================== Jeff Angielski jeff(a)ThePTRGroup.com ====================================================

3 4

[U-Boot-Users] New board...
by Anders Larsen 17 Sep '03

17 Sep '03

Hi Wolfgang, I'm currently porting U-Boot to a PXA-based industrial device developed by my employer. Since the code I write/modify/adapt is covered by the GPL I'd like to know what to do with it - can I push it to you for inclusion in U-Boot (although we do not sell the naked board) or must I follow the provisions of the GPL (e.g. ship the source code with the device)? Cheers Anders

3 2

[U-Boot-Users] Determining the UPMA. UPMB SDRAM table
by Raghu 17 Sep '03

17 Sep '03

Hello, Just courious to know how does one determine the SDRAM table to MPC8xx family of processors ?? Warm Regards Raghu. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

RE: [U-Boot-Users] data abort
by Woodruff, Richard 16 Sep '03

16 Sep '03

I had similar problems with the 925 when I first enabled devices via devices_init, the arm code does not do selective remapping. Inside devices_init() should be a conditional for ARM only. I suspect your -pxa patch wiped this or other such code out. Regards, Richard W. > -----Original Message----- > From: Glenson Muthedan [mailto:glenson@gmx.de] > Sent: Tuesday, September 16, 2003 1:44 PM > To: u-boot-users(a)lists.sourceforge.net > Subject: Re: [U-Boot-Users] data abort > > > Hello! > > Thank you guys for your kind help. My SDRAM initialization was not > correct. Now, having done some changes, everything seems to work > smoothly except one line in devices_init() in the file > common/devices.c > > The execution stops at the line > gd->flags |= GD_FLG_DEVINIT; /* device initialization done */ > > Then, sometimes a "prefetch abort" occurs, sometimes it just hangs. > > When I comment this line, U-Boot runs up to the bootloader-prompt > without any problem. So I hope, the line above is not a > crucial one if I > only have to do with the serial console. But I'm interested > to know what > you think about this temporary solution; am I running into > problems later? > > Regards. > Glenson. > > > Wolfgang Denk wrote: > > Fix your SDRAM initialization. > > Robert Schwebel wrote: > > Sounds like memory problems. Are you sure you did your RAM > > initialization correct? > > Anders Larsen wrote: > > ...or because ListCreate() can't allocate a (writable) > block of RAM. > ... > > > > > ------------------------------------------------------- > 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 >

1 0

[U-Boot-Users] compile u-boot (error)
by Chien-Lung Wu 16 Sep '03

16 Sep '03

Hi, I am working on a project to bring up MPC 8240/8245. I try to use u-boot. However, I got error when I compile u-boot source code. Since I am working a hardware by our company, I follow the instruction to create related files and then compile u-boot. The error message is: gcc -Wall -pedantic -I ../include -I.. -D TEXT_BASE=0xFFF00000 -DUSE_HOSTCC -O -o img2srec.exe imag2srec.o /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld: cannot find -lcygwin collect2: ld returned 1 exit status. ( I am working on window NT/cygwin platform.) Do anyone have similar experience? Your suggestions and opinion will be great helpful for me. TIA. David,

2 1

[U-Boot-Users] SDRAM Table for K4561633C - RL 75
by Raghu 16 Sep '03

16 Sep '03

Hello All, I have a board that has Samsung K4S561633C - RL75 SDRAM. Two chips of ( 32 Mbit each total of 64MByte ) I want the sdram_table[] parameters, where can I get them ? The same chip is used in wepep250 board for ARM architecture, but I could not locate the SDRAM table. Warm Regards, Raghu. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

[U-Boot-Users] What are the Post codes generated?
by deya privi 16 Sep '03

16 Sep '03

Hi What are the post codes and error codes genereted by u-boot for PXA255? Thanks in advance for any help! Regards, Deya. ________________________________________________________________________ Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com

2 1

[U-Boot-Users] question about standalone application
by Chan Queenie-r54684 16 Sep '03

16 Sep '03

Hi all, I'm new to U-Boot. I'd like to run an application after my custom board is booted up. In the U-Boot readme file, I learned there is a command called "loads" which will download the *.srec from the host to the board through serial line. So I want to download the hello world demo and see how it works. I don't know how I should setup my board and my host. My host run on Windows 2000 and connects to the board using HyperTerminal. With that, I'm able to see the bootup message. When I type "loads", it shows the following: => loads ## Ready for S-Record download ... but the next line "~>examples/hello_world.srec" never comes out. Must I use Linux as the host? I downloaded C-Kermit for Linux and Windows XP, too. But I couldn't set it up correctly. In Linux, I entered the following commands and expected to see the bootup message as in HyperTerminal, but I didn't. set line <my device> set speed 115200 set serial 8N1 set carrier-watch off connect And I couldn't make a connection using Kermit 95 for Windows XP either. What have I done wrong? Please help! Your advice is appreciated. Best Regards, Queenie Chan NCSD Application Engineer

2 1

[U-Boot-Users] Conditional 'hush' script examples anyone?
by Robin Gilks 16 Sep '03

16 Sep '03

Greetings I've RTFM'd and I've FAQ'd but I still can't find a single example of the use of conditionals with the u-boot hush shell command line. I assume its only usable with an autoscript or can environmental variables hold complete conditional blocks. Most interested in this so that I can make sensible decisions about what to do if an image CRC is bad for example (or when to boot a different image after an upgrade). Examples, examples, examples is what I'm looking for rather than a dry explanation about hush (which I can get close to from any book that documents bash!!) Many thanks -- 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

6 14

RE: [U-Boot-Users] hi
by erik.teose＠exgate.tek.com 16 Sep '03

16 Sep '03

OK, Wolfgang, want to take this one? :-) Erik -----Original Message----- From: Dannel_Zhang To: u-boot-users(a)lists.sourceforge.net Sent: 9/15/2003 9:25 PM Subject: [U-Boot-Users] hi

2 1

[U-Boot-Users] [Q] MPC8245 A3000 board
by 배장식 16 Sep '03

16 Sep '03

hi.... i use a A3000 board (mpc8245) i find piece which is strange.. The time flows slowly.. blow factor is a result which it confirms as an date command date command realtime ( my pc time) Artis:~>date Thu Jun 13 20:02:13 KST 2002 Thu Sep 16 12:12:13 1 minute later check result Artis:~>date Thu Jun 13 20:02:28 KST 2002 Thu Sep 16 12:13:13 It probably is like this why, it is anxious Best Regard~~

1 0

[U-Boot-Users] hi
by Dannel_Zhang 16 Sep '03

16 Sep '03

1 0

[U-Boot-Users] U-Boot-CVS mailing list available
by Wolfgang Denk 15 Sep '03

15 Sep '03

As requested, I have created a new U-Boot related mailing list: U-Boot-CVS(a)lists.sourceforge.net You can subscribe at http://lists.sourceforge.net/mailman/listinfo/u-boot-cvs All ckeck-ins to the CVS (change log plus context diffs) will be posted to this list. Hope this helps. Best regards, 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 The software required `Windows 95 or better', so I installed Linux.

1 0

[U-Boot-Users] memory map?
by deya privi 14 Sep '03

14 Sep '03

Hi, As per the U-boot at what locations should the bootloader image and kernel image shall be placed in Flash memory? Thanks in advance. Regards, Deya. ________________________________________________________________________ Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com

2 1

[U-Boot-Users] Porting U-Boot to custom board
by sharad＠buckeye.ece.drexel.edu 14 Sep '03

14 Sep '03

Hi, I am new to this group. I am involved with porting U-boot to a custom board based on PowerPC 7455. Right now, we are at the point where we have just got our bus slave working so U-boot is our next logical step. And ultimately, Linux kernel. Looking at the README and the source code it seems like with the support of this group, we shall be able to do it. One note, just browsing through include/asm-ppc/processor.h ... it seems like the SPR numbers for [DI]BAT4[UL]-[DI]BAT7[UL] have been interchanged i.e upper register gets the SPR number of the lower register and vice-versa. Just thought to bring this to notice. Looking forward to your support, Sharad Gupta

2 1

[U-Boot-Users] Re: Patches for U-Boot
by Wolfgang Denk 13 Sep '03

13 Sep '03

In message <3F62CC58.8060604(a)elsoft.ch> you wrote: > > The attached patch fixes the following issues: > > Makefile: add $(CC) to "-print-libgcc-filename" so compiler gets > correct libgcc file Description and patch disagree. In the patch, you add not "$(CC)" [which is already there - obviously], but "$(CFLAGS)". What makes you think that options like "-Wall" or "-Wstrict-prototypes" would change the behaviour of "-print-libgcc-filename" ?? Rejected. > README: mention VCMA9 board > > board/mpl/vcma9/* various changes to VCMA9 board specific files Added. > common/cmd_nand.c prepare S3C2410 support (more to follow) I think it's a bad idea to ``#include "../board/mpl/vcma9/vcma9.h"'' in a common source file. Either vcma9.h contains definitions valid and necessary for all S3C24xx boards, then those should be moved into to common header file; or they include board specific stuff, and then they should not be needed in common/cmd_nand.c Rejected. > drivers/s3c24x0_i2c.c adjust delay value and some cleanup Please explain why you think that this modification: - i = I2C_TIMEOUT * 1000; + i = I2C_TIMEOUT * 10000; status = i2c->IICCON; while ((i > 0) && !(status & I2CCON_IRPND)) { - udelay(1000); + udelay(100); status = i2c->IICCON; i--; } changes or improves the behaviour. I see no advantages. Rejected for now. I see no advantages. Rejected for now. > rtc/s3c24x0_rtc.c remove unnecessary enable/disable stuff and cleanup Do you think the enable/disable stuff hurts? Left as is, rest applied. Changes will show up on CVS "soon". Best regards, 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 "To IBM, 'open' means there is a modicum of interoperability among some of their equipment." - Harv Masterson

1 0

[U-Boot-Users] need help regarding u-boot for csb226
by renjithgopal 13 Sep '03

13 Sep '03

Hello I am a beginner I was trying to compie u-boot for csb226. but it is giving some compiler error. make[1]: Entering directory `/uboot/lib_generic' arm-linux-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -mshort-load-bytes -msoft-float -D__KERNEL__ -DTEXT_BASE=0xa1fe0000 -I/uboot/include -fno-builtin -ffreestanding -nostdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ -mapcs-32 -march=armv4 -mtune=strongarm1100 -Wall -Wstrict-prototypes -c -o crc32.o crc32.c as: unrecognized option `-marmv4' In file included from /uboot/include/common.h:77, from crc32.c:12: /uboot/include/image.h:148: output pipe has been closed cpp0: output pipe has been closed make[1]: *** [crc32.o] Error 1 make[1]: Leaving directory `/uboot/lib_generic' make: *** [subdirs] Error 1 but when i asked some of my friends they told it should work fine with out any problem.. i am using u-boot 0.4.6 and arm-linux-gcc 2.95.3 i am also attaching the log of compilation ... please tell me what to do? Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets on Air Sahara Flights at Prices Lower Than Before. Just log on to http://airsahara.indiatimes.com and Bid Now!

4 8

[U-Boot-Users] RTC on ebony
by Dhanuka, Anupam 13 Sep '03

13 Sep '03

Hi all I have been using u-boot for the IBM ebony board (it works very well :)). The Ebony board has an RTC. However, in my custom board I am planning not to have the RTC. Will this affect u-boot in any way? Basically what I am trying to ask is that, does u-boot use the RTC? Thanks Anupam S/W Design Engineer Dolby Labs 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.

2 1

RE: [U-Boot-Users] MPC8266ADS patch
by Curtis, Allen 13 Sep '03

13 Sep '03

> > < $(OBJCOPY) -O binary $< $@ 2>/dev/null > > --- > > > $(OBJCOPY) -O ppcboot $< $@ 2>/dev/null > > Please explain why. Does the MontaVista version of the binutils doe > not understand "binary" output format any longer? > > The MontaVista tools will not convert binary to srec. You get an error > message about unknown architecture. However I discovered the ppcboot options > which works fine. Another solution is to use "dd" to strip the 64k header. Well, this is a bug in the MV toolchain then. Complain at MV. We will NOT add this to the Makefile as it breaks all other systems. My suggestion was to add this as a comment to the Makefile. > > Index: board/mpc8266ads/config.mk > > ================================================================== > > RCS file: /cvsroot/u-boot/u-boot/board/mpc8266ads/config.mk,v > > retrieving revision 1.2 > > diff -r1.2 config.mk > > 30c30 > > < TEXT_BASE = 0xfe000000 > > --- > > > TEXT_BASE = 0xfff00000 > > Please explain why you think this is necessary. > > The reset vector for 8260 is 0xfff00100. The easiest way to u-boot to put > code at this location is to change TEXT_BASE. This is the same as the > MPC8260 config.mk file.... There is no relation between the reset vector and TEXT_BASE. You can have the reset vector at 0x100 and TEXT_BASE - say - at 0x40000000. I don't think I want to change this configuration (which seems to be working to several people) without a really good reason. The reset address is either 0x00000100 or 0xfff00100. The current u-boot configuration doesn't locate any code at these locations. The MPC8260 configuration specified TEXT_BASE as 0xfff00000 and it works. The current u-boot configuration does not boot. > FLASH_BASE 0xff800000 - the board ships with a 8MB SIMM. This is the base > address. You can map the flash at any arbitrary address. I don't see why 0xFF800000 would be any better than 0xFE000000 - on contrary - mapping it at 0xFE000000 leaves enough room if there should ever be a board with bigger flash chips. As long as something responds to the 0xfff00xxx address range you are correct. > CFG_BCSR & CFG_PCI_INIT - according to the memory map in the MPC8266ADS > manual, these are the physical addresses. You need to access the BCSR to > enable the serial and Ethernet ports. Physical addresses on a 82xx are programmable. The programming of the memory controller decides where a device shows up in the physiacal memory map. Please ignore the memory map given in the manyal - it is just one example out of many possible, and it is an example which will NOT work with Linux. If the only hardware requirement is chip-select generation, this is correct. It would be better to move these to another location. > Actually I think it is a bug to map the BCSR at a low address like > 0x04500000. Are you really, really sure that this will work with > Linux? > > Virtual address != Physical address > These are correct according to the documentation You are wrong. There are certain address ranges in Linux which are mapped with virtual"physical 1:1. The IMMR and BCSR areas are among them. This is very implementation specific. There have been several discussions about the use of BATs with these architectures. > This works. The current u-boot implementation does not work. Perhaps the > current configuration works with a different board configuration. If that is > true, then there should be a big note somewhere with detailed configuration > notes. I doubt that you have any Linux applications running with your configuration. I see Linux and u-boot as two very different things. In my opinion it is useful to have the BIOS follow the documented configuration. This helps the person who is trying to bring up, and probably learn, a new platform. As they become comfortable with the hardware they can deviate from the standard configuration. The difference is that they made those changes and didn't need to refer to several documents (or source code) to figure out a memory map. When Linux boots, it assumes the BIOS is brain-dead and reconfigures everything. The BCSR and IMMR will be relocated to what makes sense for that operating environment.

2 2

[U-Boot-Users] MPC8266ADS PBI memory patch
by Rune Torgersen 12 Sep '03

12 Sep '03

Changed default memory option on MPC8266ADS to not be Page Based Interleave, since this doesn't work very well with the standard 16MB DIMM > > Only other issue I know about (in u-boot-0.4.5) is that the memory > > controller is set to use Page Based Interleave (PBI), which > I do not > > think works with the standard 16MB DIMM that comes with the eval > > board. There were some discussion about setting the SDAM > field of the > > PSDMR differently to fix this, but I havent gotten that to > work. Fix > > is to use bigger than 16MB DIMM, or turn off PBI (top of > > board/mpc8266ads/mpc8266ads.c) This should probaby be changed... > > If you know for sure, can you please submit a patch?

2 1

Re: [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
by James Bates 12 Sep '03

12 Sep '03

Thanks everyone, Loads of issues were pointed out there for me to solve (Thanks) but the main one was to do with my console baud rate after all. When I changed my terminal emulator to 9600 linux was there up and running all along. The problem was that U-boot was configured to run at 115200 and linux at 9600. The problem I have now is changing my u-boot baud rate to 9600 (which is what the powers that be have decided). I tried changing CONFIG_BAUDRATE to 9600 but it has no effect, it just stays at 115200. Any ideas? Thanks again, James Bates This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error please return the message immediately to the sender and delete the message from your systems. Thank you.

3 3

[U-Boot-Users] PXA (XScale) memory layout
by Anders Larsen 12 Sep '03

12 Sep '03

Hi folks, is there any particular reason why the PXA uses a different memory layout than the other ARMs? It seems to be causing a certain amount of grief (and dirty workarounds, like e.g. in board/wepep250/wepep250.c lines 43..53) that cpu/pxa/start.S places stack (and heap) below the code instead of above. I'd be grateful if somebody could enlighten me on this. cheers Anders

4 8

[U-Boot-Users] Unable to compile the U-boot-0.4.8 version for OMAP1610/1510/smdk2410
by Rahul Shanbhag 12 Sep '03

12 Sep '03

Hi All, I am not able to compile the new u-boot tar ball i.e. u-boot-0.4.8, u-boot-0.4.7 compiles fine . I got the following error message after make omap1610inn_config make command "In file included from /home/rahul/omap1610/0-4-8/u-boot-0.4.8/include/common.h:4 0, from uboot_drv.c:26: /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h:43: parse error before `__gnuc_va_list' /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h:43: warning: data defin ition has no type or storage class /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h:110: parse error before `va_list' " can anybody tell me what is the problem. Thanks Rahul

3 4

Re: [U-Boot-Users] Kernel hangs after decompressing.
by DavidHo＠nanometrics.ca 12 Sep '03

12 Sep '03

Hi Wolfgang, >> I copied the bd_info structure from u-boot.h to rpxclassic.h in the kernel > This is wrong. You should include ppcboot.h in rpxclassic.h. Okay, I originally copied the structure from u-boot.h to ppcboot.h. But seeing that another bd_t structure was declared in rpxclassic.h, I decided to replace the structure in rpxclassic.h. Your approach is definitely more elegant. Made the change to rpxclassic.h. > This cannot work. The powerpc kernel requires load address == entry > point = 0x0000. Correct me if I'm wrong, I thought the kernel can be booted from any location in memory, the startup code in the i386 tree can boot the kernel from low and high memory. I should've been more faithful to the documentation. =) I set the kenrel load address back to 0x0000. I had to move the tftp load address to 0x400000 so that it had enough space to decompress the kernel to low memory. That was the problem I had before because by default tftp loads uImage to 0x100000. But I'm back to the same problem again that as soon as u-boot passes control to the kernel, it hangs without spitting a single meaningful message to the console. I really need someone to tell me what could possibly go wrong here. =) I switched on the debug messages in hope you might spot something interesting there. >> I made the uImage from vmlinux in the top level directory and the >> vmlinux.gz from arch/ppc but they hanged at the same point. > Did you read the README? You should. I used the very first method shown in the README to build the uImage from vmlinux. I converted the it to a binary file, gzipped it and used mkimage to build the final image file. I then used the typical way of building the image that makes use of the vmlinux.gz in arch/ppc/boot/images and run mkimage directly on it. The only thing I haven't tried is building one from an uncompressed image. Regards, David Ho U-Boot 0.4.0 (Sep 11 2003 - 14:44:53) CPU: XPC860xxZPnnD4 at 50 MHz: 16 kB I-Cache 8 kB D-Cache FEC present Board: EP860 I2C: ready DRAM: 16 MB Top of RAM usable for U-Boot at: 01000000 Reserving 130k for U-Boot at: 00fdf000 Reserving 132k for malloc() at: 00fbe000 Reserving 64 Bytes for Board Info at: 00fbdfc0 Reserving 44 Bytes for Global Data at: 00fbdf94 Stack Pointer at: 00fbdf78 New Stack Pointer is: 00fbdf78 Now running in RAM - U-Boot at: 00fdf000 FLASH: 16 MB In: serial Out: serial Err: serial U-Boot relocated to 00fdf000 Net: FEC ETHERNET ### main_loop entered: bootdelay=5 ### main_loop: bootcmd="tftpboot; setenv bootargs root=/dev/nfs rw nfsroot =$(ser verip):$(rootpath) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask): $(hostname): :off; bootm" Hit any key to stop autoboot: 0 => tftp Trying FEC ETHERNET TFTP from server 199.71.138.8; our IP address is 199.71.138.25 Filename 'uImage'. Load address: 0x400000 Loading: ################################################################# ################################################################# ########################################### done Bytes transferred = 883653 (d7bc5 hex) => bootm ## Booting image at 00400000 ... Image Name: Linux Kernel Image Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 883589 Bytes = 862.9 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x00FBDBF0 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF61 bd address = 0x00FBDFC0 memstart = 0x00000000 memsize = 0x01000000 flashstart = 0xFC000000 flashsize = 0x01000000 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFA200000 bootflags = 0x00000001 intfreq = 50 MHz busfreq = 50 MHz ethaddr = 00:10:EC:80:3B:49 IP addr = 199.71.138.25 baudrate = 9600 bps No initrd ## Transferring control to Linux (at address 00000000) ...

2 1

[U-Boot-Users] u-boot on Memec P4/7-FG456 (w/ virtex II pro)?
by jds 12 Sep '03

12 Sep '03

hi, has anyone done any u-boot porting work for the Memec Virtex-II Pro P4/7-FG456 evaluation board? as you can see from the link below this is a development board which has the Virtex-II Pro (w/ single 405GP core) along with SDRAM, NV stroage via compact flash, and so forth. http://www.memec.com/cgi-bin/bvutf8/memec/scripts/local/manuDetailArticle.j… we are considering using this board as an R&D platfrom for an upcoming project. thanks! -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery

2 2

RE: [U-Boot-Users] MPC8266ADS patch
by Rune Torgersen 11 Sep '03

11 Sep '03

> When Linux > boots, it assumes the BIOS is brain-dead and reconfigures > everything. The BCSR and IMMR will be relocated to what makes > sense for that operating environment. This is not enirely true for PPC Linux. It is true for x86. On PPC, Linux assumes that the BIOS or bootloader initalizes all the board or CPU specific hardware. Like the FCCs for ehternet, serial ports (for initial debug output), IO pins used by FCCs, and serial ports.(linux doesn't touch thesse) Some of the meory map (specifically where the IMMR and to a lesser extent BCSR) Linux depends on the bootloader to tell it where they are.

1 0

RE: [U-Boot-Users] MPC8266ADS patch
by Rune Torgersen 11 Sep '03

11 Sep '03

> > This works. The current u-boot implementation does not > work. Perhaps > > the current configuration works with a different board > configuration. > > If that is true, then there should be a big note somewhere with > > detailed configuration notes. > > I doubt that you have any Linux applications running > with your configuration. > > Rune, are you reading this? I don't have a MPC8266ADS > board to actually test this, but you are the board > maintainer. What is your comment? > The current configuration in U-BOOT works, and boots Linux with no problem. It will, however, not work on a virgin ADS development board. You have to change one jumper to get the CPU to use the Hardware Configuration word from Flash, and not from BCSR... (JP3 I think) There is a huge textbox in the start of the MPC8266ADS.h file that explains this. There is absolutely no reason to change the BCSR and PCI_INT addresses. They work fine as they are set now. I don't know how the unified PQ2 port (which should work on all the MPC826xDAS boards and the new PQ2 boards) is set up. Haven't tried it. Only other issue I know about (in u-boot-0.4.5) is that the memory controller is set to use Page Based Interleave (PBI), which I do not think works with the standard 16MB DIMM that comes with the eval board. There were some discussion about setting the SDAM field of the PSDMR differently to fix this, but I havent gotten that to work. Fix is to use bigger than 16MB DIMM, or turn off PBI (top of board/mpc8266ads/mpc8266ads.c) This should probaby be changed...

2 1

[U-Boot-Users] Kernel hangs after decompressing.
by DavidHo＠nanometrics.ca 11 Sep '03

11 Sep '03

Hi, I am trying to bring up an uImage made from a Timesys 4.0 kernel on a EP860 board with u-boot 4.0 as the bootloader. I did a small port to make u-boot run on the EP860, mainly making changes to the SDRAM initialization and Flash configuration code. Once this is done. I went back to the Timesys kernel, which uses the RPXClassic configuration - the kernel runs fine in this configuration on the EP860. I copied the bd_info structure from u-boot.h to rpxclassic.h in the kernel and I had to add a bi_nvram_size field to the structure since the board requires it. I know the IMAP_ADDR is important so I'm absolutely sure this matches CFG_IMMR. When I try autobooting the kernel image from the tftp server, it hangs soon after the kernel is uncompressed. U-Boot 0.4.0 (Sep 11 2003 - 12:37:07) CPU: XPC860xxZPnnD4 at 50 MHz: 16 kB I-Cache 8 kB D-Cache FEC present Board: EP860 I2C: ready DRAM: 16 MB FLASH: 16 MB In: serial Out: serial Err: serial Net: FEC ETHERNET Hit any key to stop autoboot: 0 TFTP from server 199.71.138.8; our IP address is 199.71.138.25 Filename 'uImage'. Load address: 0x100000 Loading: ################################################################# ################################################################# ########################################### done Bytes transferred = 883654 (d7bc6 hex) ## Booting image at 00100000 ... Image Name: Linux Kernel Image Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 883590 Bytes = 862.9 kB Load Address: 00100000 Entry Point: 00100000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK B I had to move the load address up from 0x0 to pass the uncompressing stage. I'm not sure why loading to 0x0 causes problems since the examples in the readme all use 0x0 as the load address. I made the uImage from vmlinux in the top level directory and the vmlinux.gz from arch/ppc but they hanged at the same point. I can boot the zImage (kernel built with its own boot loader) by tftping the zImage to RAM and jumping to the start of the image. So the kernel works smoothly with its boot loader. I would really appreciate any suggestions you can give me to try on the board. I can give you any other information if there's anything I missed here. Thanks in advance, David Ho Nanometrics Inc.

2 1

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
by James Bates 11 Sep '03

11 Sep '03

Hi All, I have now managed to get the image to be read in and kernel image uncompressed etc. I am getting the problem where it hangs after Uncompression though. My previous issue with Bad Magic Number errors was due to the compilation of the mkimage tool. It was producing images with the wrong endianness in the header. Not sure if this may still be my problem tho :) I have tried both settings of clocks_in_mhz and have made sure that I copied u-boot.h from uboot to ppcboot.h in Linux. I have made sure that IMAP_ADDR is correct but I still get the same thing, just hangs after uncompression. I am totally stumped. My board is an adaptation of the MPC8260ADS. I am using BlueCat 4.0 and u-boot 4.8 (tried 4.0 and 4.7) etc and have tried booting both the uImage and kdi files (after turning them into u-boot images with mkimgage). Here is a print out with extra debug info when trying a kdi image called Q319.img: ---------------------------------------------------------------------------- -------------- => tftpboot 100000 Q319.img Trying FCC2 ETHERNET TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'Q319.img'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################################# done Bytes transferred = 3637824 (378240 hex) => bootm common/cmd_bootm.c before attempting to boot an image ## Booting image at 00100000 ... common/cmd_bootm.c Image header has correct magic number common/cmd_bootm.c Image header has correct checksum Image Name: Linux Kernel Image Image Type: PowerPC LynxOS Kernel Image (uncompressed) Data Size: 3637760 Bytes = 3.5 MB Load Address: 00500000 Entry Point: 00507000 Verifying Checksum ... OK common/cmd_bootm.c Image data has correct checksum common/cmd_bootm.c Architecture check OK common/cmd_bootm.c Image Type check OK OK common/cmd_bootm.c Uncompression OK common/cmd_bootm.c Image Type check OK Booting Bluecat KDI ... loaded at: 00507000 005121DC zimage at: 0050D000 0057366C initrd at: 00575000 00878200 relocated to: 00576000 00879200 avail ram: 0087A000 04000000 Linux/PPC load: root=/dev/ram root=/dev/ram rw ramdisk_size=28472 hda=bswap hdb=bswap hdc=bswap hdd=bswap root=101 Uncompressing Linux...done. Now booting the kernel (Hangs here) ---------------------------------------------------------------------------- ---------------- Another example which does not use a kdi image but simply takes a mkimaged zipped vmlinux file as follows. => tftpboot 100000 uImage Trying FCC2 ETHERNET TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'uImage'. Load address: 0x100000 Loading: ################################################################# ################# done Bytes transferred = 419502 (666ae hex) => bootm common/cmd_bootm.c before attempting to boot an image ## Booting image at 00100000 ... common/cmd_bootm.c Image header has correct magic number common/cmd_bootm.c Image header has correct checksum Image Name: Linux Kernel Image Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 419438 Bytes = 409.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK common/cmd_bootm.c Image data has correct checksum common/cmd_bootm.c Architecture check OK common/cmd_bootm.c Image Type check OK Uncompressing Kernel Image ... OK common/cmd_bootm.c Uncompression OK common/cmd_bootm.c Image Type check OK ## Current stack ends at 0x03F6CBD8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF10 bd address = 0x03F6CFB4 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xFE000000 flashsize = 0x7FCFFFF7 flashoffset = 0x0002E000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFA200000 bootflags = 0x00000001 vco = 266.666 MHz sccfreq = 66.666 MHz brgfreq = 66.666 MHz intfreq = 199.999 MHz cpmfreq = 133.333 MHz busfreq = 66.666 MHz ethaddr = 00:00:00:10:18:82 IP addr = 192.168.1.2 baudrate = 115200 bps common/cmd_bootm.c No initial ramdisk, no multifile, continue. No initrd ## Transferring control to Linux (at address 00000000) ... common/cmd_bootm.c All preparation done, transferring control to OS (hangs here) Any ideas anyone? You help is much appreciated. Regards, James Bates PS: Apologies for this signature at the bottom of my posts, it is attached by my employer out of my control. This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error please return the message immediately to the sender and delete the message from your systems. Thank you.

6 7

[U-Boot-Users] Changes to NAND flash handling
by Wolfgang Denk 11 Sep '03

11 Sep '03

Hi, I don't really like the way how NAND flash is handled right now. Ii is inconsistent with the handling of other types of memory. I've changed the behaviour now so that it looks more like what we get for other types of memory (RAM, flash), i. e. for example it now prints: ... Board: PPChameleon EVB SN PPCN 310300 A8 I2C: ready DRAM: 32 MB FLASH: 4 MB NAND: 32 MB Hit any key to stop autoboot: 0 ... I tried to modify all affected boards, but I cannot test it. Will the board maintainers please have a look and complain (and/or send patches) if my changes broke anything? The new stuff is checked in now. Best regards, 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 "If you own a machine, you are in turn owned by it, and spend your time serving it..." - Marion Zimmer Bradley, _The Forbidden Tower_

1 0

Re: [U-Boot-Users] MPC8266ADS patch
by Wolfgang Denk 11 Sep '03

11 Sep '03

Dear Allen, please keep the u-boot-users list Cc:ed. In message <FA06AA2C99BCD511951200005A99441003BE1706@IRVEXCH1> you wrote: > > I am sorry about the format. Between fighting the corporate IT guys and > Windoz I feel lucky that it works at all. It's not usable, though. We need context or unified diff's or any simple change elsewhere in the file (which causes the line numbers to shift) will break it. > > < $(OBJCOPY) -O binary $< $@ 2>/dev/null > > --- > > > $(OBJCOPY) -O ppcboot $< $@ 2>/dev/null > > Please explain why. Does the MontaVista version of the binutils doe > not understand "binary" output format any longer? > > The MontaVista tools will not convert binary to srec. You get an error > message about unknown architecture. However I discovered the ppcboot options > which works fine. Another solution is to use "dd" to strip the 64k header. Well, this is a bug in the MV toolchain then. Complain at MV. We will NOT add this to the Makefile as it breaks all other systems. > > Index: board/mpc8266ads/config.mk > > ================================================================== > > RCS file: /cvsroot/u-boot/u-boot/board/mpc8266ads/config.mk,v > > retrieving revision 1.2 > > diff -r1.2 config.mk > > 30c30 > > < TEXT_BASE = 0xfe000000 > > --- > > > TEXT_BASE = 0xfff00000 > > Please explain why you think this is necessary. > > The reset vector for 8260 is 0xfff00100. The easiest way to u-boot to put > code at this location is to change TEXT_BASE. This is the same as the > MPC8260 config.mk file.... There is no relation between the reset vector and TEXT_BASE. You can have the reset vector at 0x100 and TEXT_BASE - say - at 0x40000000. I don't think I want to change this configuration (which seems to be working to several people) without a really good reason. > > diff -r1.4 MPC8266ADS.h > > 236,237c236,237 > > < #define CFG_FLASH_BASE 0xFE000000 > > < #define FLASH_BASE 0xFE000000 > > --- > > > #define CFG_FLASH_BASE 0xFF800000 > > > #define FLASH_BASE 0xFF800000 > > 252,253c252,253 > > < #define CFG_BCSR 0xF8000000 > > < #define CFG_PCI_INT 0xF8200000 /* PCI interrupt > controller > > */ > > --- > > > #define CFG_BCSR 0x04500000 > > > #define CFG_PCI_INT 0x04730000 /* PCI interrupt > > controller */ > > Please explain why you think this is necessary. > > FLASH_BASE 0xff800000 - the board ships with a 8MB SIMM. This is the base > address. You can map the flash at any arbitrary address. I don't see why 0xFF800000 would be any better than 0xFE000000 - on contrary - mapping it at 0xFE000000 leaves enough room if there should ever be a board with bigger flash chips. > CFG_BCSR & CFG_PCI_INIT - according to the memory map in the MPC8266ADS > manual, these are the physical addresses. You need to access the BCSR to > enable the serial and Ethernet ports. Physical addresses on a 82xx are programmable. The programming of the memory controller decides where a device shows up in the physiacal memory map. Please ignore the memory map given in the manyal - it is just one example out of many possible, and it is an example which will NOT work with Linux. > Actually I think it is a bug to map the BCSR at a low address like > 0x04500000. Are you really, really sure that this will work with > Linux? > > Virtual address != Physical address > These are correct according to the documentation You are wrong. There are certain address ranges in Linux which are mapped with virtual"physical 1:1. The IMMR and BCSR areas are among them. > This works. The current u-boot implementation does not work. Perhaps the > current configuration works with a different board configuration. If that is > true, then there should be a big note somewhere with detailed configuration > notes. I doubt that you have any Linux applications running with your configuration. Rune, are you reading this? I don't have a MPC8266ADS board to actually test this, but you are the board maintainer. What is your comment? Best regards, 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 It is a good thing for an uneducated man to read books of quotations. - Sir Winston Churchill _My Early Life_ ch. 9

1 0

RE: [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
by Rune Torgersen 11 Sep '03

11 Sep '03

> changing CONFIG_BAUDRATE to 9600 but it has no effect, it > just stays at 115200. Any ideas? Note that that CONFIG parameter is ONLY used if there is no baudrate settin on the environment in flash. Change the environment variable, and it should work. (Same thing with CONFIG_CLOCK_IN_MHZ....)

1 0

RE: [U-Boot-Users] Kernel hangs after decompressing.
by Muhammad Sarwar 11 Sep '03

11 Sep '03

Make sure you don't have clock_in_mhz in your environment settings. Regards, Muhammad Sarwar Mangrove Systems Inc. -----Original Message----- From: DavidHo(a)nanometrics.ca [mailto:DavidHo@nanometrics.ca] Sent: Thursday, September 11, 2003 2:10 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] Kernel hangs after decompressing. Hi, I am trying to bring up an uImage made from a Timesys 4.0 kernel on a EP860 board with u-boot 4.0 as the bootloader. I did a small port to make u-boot run on the EP860, mainly making changes to the SDRAM initialization and Flash configuration code. Once this is done. I went back to the Timesys kernel, which uses the RPXClassic configuration - the kernel runs fine in this configuration on the EP860. I copied the bd_info structure from u-boot.h to rpxclassic.h in the kernel and I had to add a bi_nvram_size field to the structure since the board requires it. I know the IMAP_ADDR is important so I'm absolutely sure this matches CFG_IMMR. When I try autobooting the kernel image from the tftp server, it hangs soon after the kernel is uncompressed. U-Boot 0.4.0 (Sep 11 2003 - 12:37:07) CPU: XPC860xxZPnnD4 at 50 MHz: 16 kB I-Cache 8 kB D-Cache FEC present Board: EP860 I2C: ready DRAM: 16 MB FLASH: 16 MB In: serial Out: serial Err: serial Net: FEC ETHERNET Hit any key to stop autoboot: 0 TFTP from server 199.71.138.8; our IP address is 199.71.138.25 Filename 'uImage'. Load address: 0x100000 Loading: ################################################################# ################################################################# ########################################### done Bytes transferred = 883654 (d7bc6 hex) ## Booting image at 00100000 ... Image Name: Linux Kernel Image Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 883590 Bytes = 862.9 kB Load Address: 00100000 Entry Point: 00100000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK B I had to move the load address up from 0x0 to pass the uncompressing stage. I'm not sure why loading to 0x0 causes problems since the examples in the readme all use 0x0 as the load address. I made the uImage from vmlinux in the top level directory and the vmlinux.gz from arch/ppc but they hanged at the same point. I can boot the zImage (kernel built with its own boot loader) by tftping the zImage to RAM and jumping to the start of the image. So the kernel works smoothly with its boot loader. I would really appreciate any suggestions you can give me to try on the board. I can give you any other information if there's anything I missed here. Thanks in advance, David Ho Nanometrics Inc. ------------------------------------------------------- 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

1 0

[U-Boot-Users] Debugging U-Boot with BDI2000
by Glenson Muthedan 11 Sep '03

11 Sep '03

Hello! I'm quite new to U-Boot and trying to get started with the Bootloader-Stuff for some weeks now. My Board is similar to Accelent IDP or CSB226(PXA250 with 32 MB Strataflash and 32 MB SDRAM). U-Boot seems to crash on my board before it can output something through the serial line. So I wanted step through U-Boot right from the very first instruction using BDI2000 while booting. The problem is that the information the bdi user manual gives, is quite confusing. I tried out various configurations for BDI2000, but really don't know what to do with the vector table in the "Mini IC" and the debug handler stuff. The situation now is as following: The target is in debug mode right from the start and the PC is pointing to 0xffff0004. "go" or "ti" doesn't work because of access to an invalid memory address. (My configuration file now contains a blank [INIT] section and no vector table/debug handler stuff in the [TARGET] part) I'd be very thankful if someone could answer my questions: 1) Is it possible to debug U-Boot with BDI2000 (Linux host) at all? (eg. step through the instructions) 2) Do somebody have a working configuration file for BDI2000 (Linux host) to be used with a PXA250-target? Hope, you can give me at least a hint. Regards, Glenson Muthedan.

3 2

[U-Boot-Users] PATCH: USB & FAT fixes
by Denis Peter 11 Sep '03

11 Sep '03

Hello, sorry thath the patch 'usb-bulk-transfer.diff' did not apply. It seems that the sourceforge CVS is not up to date. The usb-bulk-tansfer is already implemented in the current tarball. Here two additionally small patches for USB and FAT: usb_stor_fix.diff: Fixes usb data pointer assignment for bulk only transfer. fat-ls-fix.diff: Prevents to display erased directories. With best regards, Denis

2 1

[U-Boot-Users] MPC8266ADS patch
by Curtis, Allen 11 Sep '03

11 Sep '03

Here is a patch to get a 8266 booting with the default board configuration. Notes: 1. The patch to examples/Makefile should be included as a comment. People with MontaVista 2.0 (possibly other versions too) need this change. 2. This assumes that you have the small flash module. (should work fine with larger modules) 3. I followed some of the messages regarding booting the 8266. None of them appeared to address the address differences for the BCSR and PCI interrupt controller. (include/configs/MPC8266ADS.h) Index: board/mpc8266ads/config.mk ================================================================== RCS file: /cvsroot/u-boot/u-boot/board/mpc8266ads/config.mk,v retrieving revision 1.2 diff -r1.2 config.mk 30c30 < TEXT_BASE = 0xfe000000 --- > TEXT_BASE = 0xfff00000 Index: examples/Makefile ================================================================== RCS file: /cvsroot/u-boot/u-boot/examples/Makefile,v retrieving revision 1.7 diff -r1.7 Makefile 81c81 < $(OBJCOPY) -O binary $< $@ 2>/dev/null --- > $(OBJCOPY) -O ppcboot $< $@ 2>/dev/null Index: include/configs/MPC8266ADS.h ================================================================== RCS file: /cvsroot/u-boot/u-boot/include/configs/MPC8266ADS.h,v retrieving revision 1.4 diff -r1.4 MPC8266ADS.h 236,237c236,237 < #define CFG_FLASH_BASE 0xFE000000 < #define FLASH_BASE 0xFE000000 --- > #define CFG_FLASH_BASE 0xFF800000 > #define FLASH_BASE 0xFF800000 252,253c252,253 < #define CFG_BCSR 0xF8000000 < #define CFG_PCI_INT 0xF8200000 /* PCI interrupt controller */ --- > #define CFG_BCSR 0x04500000 > #define CFG_PCI_INT 0x04730000 /* PCI interrupt controller */

2 1

[U-Boot-Users] Re: PATCH: FAT support for IDE and SCSI
by Wolfgang Denk 10 Sep '03

10 Sep '03

Dear Denis, in message <200309090847.h898llqu005516(a)pip5.mpl.ch> you wrote: > > attached are several patches against the CVS from 03.09.03 (I wasn't able to > check-out the current CVS): > > - pip405-mip405-update.diff: > Some fixes for the boards PIP405 and MIP405 Added. > - DOC-fixes.diff: > Minor fix for Disk On Chip (UnitSizeFactor=0) Added. > - usb-bulk-transfer.diff: > Added bulk-only transfer for USB *** NOT ADDED *** This patch does not apply to current version in CVS. Please review, and re-submit. Sorry. > - fat-support.diff: > Added FAT support for IDE, SCSI and USB interface > This patch changes the behaviour of the fatxx commands, > which are only used for the board lubbock so far. I sent it > to the maintainer of this board and got his Ok. Added. > - fat-fast.diff: > increasing the speed of the FAT access by allowing > to transfer more than one block per read command. > This patch must be applied AFTER the fat-support.diff. Added. Best regards, 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 Bumper sticker: Auntie Em: Hate you, hate Kansas, taking dog. Dorothy

1 0

[U-Boot-Users] [PATCH] POST doesn't compile on MPC824X
by gleb＠nbase.co.il 10 Sep '03

10 Sep '03

Hello, POST compilation fails in post/ether.c and post/uart.c on MPC824X even though I didn't configure CFG_POST_ETHER and CFG_POST_UART Attached patch moves checking of these options before error occurs. -- Gleb.

2 1