December 2002 - U-Boot

[U-Boot-Users] loading linux in FADS860T board through u-boot-1.0.0
by RamanaYV 17 Mar '04

17 Mar '04

I was trying to load linux-2.4.4 in FADS860T board using u-boot-1.0.0. I have settted environment variables like ipaddr,serverip,ethaddr,bootargs bootfile and saved the environment. Then,i typed tftpboot to download image from server. Then,i typed bootm to start the booting process. System is stucked by showing "Uncompressing Kernel Image ... OK" sequence of these events r given below.can u please suggest, what i need to do to come out from this. Thank you. U-Boot 1.0.0 (Mar 17 2004 - 14:06:16) CPU: XPC86xxxZPnnD4 at 40 MHz: 4 kB I-Cache 4 kB D-Cache FEC present Board: FADS with db MPC821, MPC860 / MPC860SAR / MPC860T rev PILOT DRAM: (4 MB SDRAM) 4M 60ns DRAM: 8 MB FLASH: 2 MB In: serial Out: serial Err: serial Net: FEC ETHERNET =>printenv stdin=serial stdout=serial stderr=serial Environment size: 41/16380 bytes =>setenv ipaddr 192.168.1.115 =>setenv serverip 192.168.1.87 =>setenv ip 192.168.1.115 =>setenv ethaddr 00:30:bf:01:02:d0 =>setenv bootargs "root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192 .168.1.115:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" =>setenv bootfile "pImage_fads_fec" =>saveenv Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors =>printenv stdin=serial stdout=serial stderr=serial ipaddr=192.168.1.115 serverip=192.168.1.87 ip=192.168.1.115 ethaddr=00:30:bf:01:02:d0 bootargs="root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192.168 1.11 5:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" bootfile="pImage_fads_fec" Environment size: 287/16380 bytes =>tftpboot TFTP from server 192.168.1.87; our IP address is 192.168.1.115 Filename 'pImage_fads_fec'. Load address: 0x100000 Loading: T invalid RARP header #####################################################TX timeout ############ ####################### done Bytes transferred = 448321 (6d741 hex) =>bootm ## Booting image at 00100000 . Image Name: Linux-2.4.4 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 448257 Bytes = 437.8 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

3 2

[U-Boot-Users] FADS860T board
by RamanaYV 17 Mar '04

17 Mar '04

I was trying to load linux-2.4.4 in FADS860T board using u-boot-1.0.0. i am getting the followin symptom, can anyone suggest to come out from this problem.. U-Boot 1.0.0 (Mar 17 2004 - 14:06:16) CPU: XPC86xxxZPnnD4 at 40 MHz: 4 kB I-Cache 4 kB D-Cache FEC present Board: FADS with db MPC821, MPC860 / MPC860SAR / MPC860T rev PILOT DRAM: (4 MB SDRAM) 4M 60ns DRAM: 8 MB FLASH: 2 MB In: serial Out: serial Err: serial Net: FEC ETHERNET =>printenv stdin=serial stdout=serial stderr=serial Environment size: 41/16380 bytes =>setenv ipaddr 192.168.1.115 =>setenv serverip 192.168.1.87 =>setenv ip 192.168.1.115 =>setenv ethaddr 00:30:bf:01:02:d0 =>setenv bootargs "root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192 .168.1.115:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" =>setenv bootfile "pImage_fads_fec" =>saveenv Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors =>printenv stdin=serial stdout=serial stderr=serial ipaddr=192.168.1.115 serverip=192.168.1.87 ip=192.168.1.115 ethaddr=00:30:bf:01:02:d0 bootargs="root=/dev/nfs rw nfsroot=192.168.1.87:/opt/eldk/ppc8xx ip=192.168.1.11 5:192.168.1.87:192.168.1.115:255.255.255.0:ppc::off" bootfile="pImage_fads_fec" Environment size: 287/16380 bytes =>tftpboot TFTP from server 192.168.1.87; our IP address is 192.168.1.115 Filename 'pImage_fads_fec'. Load address: 0x100000 Loading: T invalid RARP header #####################################################TX timeout ############ ####################### done Bytes transferred = 448321 (6d741 hex) =>bootm ## Booting image at 00100000 ... Image Name: Linux-2.4.4 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 448257 Bytes = 437.8 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Thanks to all.

2 1

Re: [U-Boot-Users] How To Use gdb w/ u-boot source tree
by Wolfgang Denk 29 Apr '03

29 Apr '03

In message <EGEGIJHKDKJGAJMGIDPNOEKACDAA.jwalden(a)digitalatlantic.com> Jerry Walden wrote: > > Sorry - I did not make myself clear - > Instead of using gdb as a command line debugger, I was hoping to > use an IDE style debugger that can show source (comments etc), so > I can do source level debugging. That does not make any difference, or does it? fro example, use DDD as GUI frontend with GDB - but it's still GDB that will actually perform the debugging, so why shoud it behave differently? [Please, keep the list Cc:ed for the benefit of other readers...] Best regards, and a Happy New Year! 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 Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0

5 43

[U-Boot-Users] Problems with objcopy -O binary
by Bogdan Woldert-Jokisz 10 Apr '03

10 Apr '03

hi When I compile u-boot-0.3.0 then I have the following problem: ppc_405-ld -g -Ttext 0x40000 -o sched -e sched sched.o libsyscall.a ppc_405-objcopy -O srec sched sched.srec ppc_405-objcopy -O binary hello_world.srec hello_world.bin 2>/dev/null make[1]: *** [hello_world.bin] Error 1 make[1]: Leaving directory `/home/bwoldert/bootloader/u-boot-0.3.0/examples' make: *** [subdirs] Error 1 I found out: ppc_405-objcopy -O binary hello_world.srec hello_world.bin ppc_405-objcopy: Warning: Output file cannot represent architecture UNKNOWN! ppc_405-objcopy: hello_world.srec: Bad value When I delete hello_world from the Makefile, then I have the same problem with examples/sched.c. I compile on a i386. What's wrong? regards Bogdan

2 1

[U-Boot-Users] PATCH: Add strtoul in syscall table
by Pierre AUBERT 14 Jan '03

14 Jan '03

Hi everybody, The following patch adds the strtoul entry in the syscall table. This function is very usefull for analyzing the command line arguments in standalone applications. CHANGELOG: * Patch by Pierre Aubert , 09 Dec 2002 Add strtoul in syscall table.

2 2

[U-Boot-Users] Need Help w/ PPC Boot
by Jerry Walden 31 Dec '02

31 Dec '02

Greetings: I apologize in advance if this is a stupid question, or a question with an obvious answer. The fact is that I have place linux on and ARM, and an X86 board, however never on a PPC platform. In fact I have very little experience with the PPC, and RISC processors in general. I am trying to trace my way through the u-boot code - since I do not have access to an in circuit emulator, I am somewhat hindered. However I do have the capability to turn on a LED via a GPIO register. So I am tracing through the code in a "burn an learn" fashion. I have a routine called "led" that turns on an led. The code below is from start.S from the u-boot distro from the cpu/ppc4xx, my processor is a ppc 405GPr. The below code turns the LED on. Note the branch instruction that branches to some code to turn the led on. If I put the branch instruction AFTER the "mtmsr r4" instruction the LED does not turn on. I cannot figure out what is going on. If anyone has any recommendations on documentation to read (I have the 600 page "green book") or if there is something I am obviously missing (i.e. not being familiar enough with how a risc processor works) any advice is welcome. . = EXC_OFF_SYS_RESET .globl _start _start: /* Clear and set up some registers. */ addi r4,r0,0x0000 mtspr sgr,r4 mtspr dcwr,r4 mtesr r4 /* clear Exception Syndrome Reg */ mttcr r4 /* clear Timer Control Reg */ mtxer r4 /* clear Fixed-Point Exception Reg */ mtevpr r4 /* clear Exception Vector Prefix Reg */ addi r4,r0,0x1000 /* set ME bit (Machine Exceptions) */ oris r4,r4,0x0002 /* set CE bit (Critical Exceptions) */ /* the LED will turn on if I branch here */ b LED mtmsr r4 /* change MSR */ /* the LED will NOT turn on if I branch here */ /*b LED */ addi r4,r0,(0xFFFF-0x10000) /* set r4 to 0xFFFFFFFF */ /* dbsr is cleared by setting bits to 1) */ mtdbsr r4 /* clear/reset the dbsr */

2 3

[U-Boot-Users] How to start
by Martin Winistörfer 31 Dec '02

31 Dec '02

Hi, I'm working on a MPC5xx microcontroller and intend to add some features for the MPC5xx to this project. But before I can start I have some questions about the project: - Have there been any effort to implement a MPC5xx port already? I've seen the MPC8xx seems to be well supported. Unfortunatly I don't know this uC well, but it seems that both don't have a lot in common. - I've read the recommended documentation (README, some source...) but what I'm missing is something which discribes the minimal interface between the board and cpu specific part of the code and the actual u-boot code. Something like an API documentation. Is such a document available? The README.console file lists some interface functions. But what's with the other features? What function do I have to provide to get a running system? What I would like to set up is a minimal configuration like this. Essential parts -> A serial interface (for the console) -> r/w memory (memory functions like mm, md...) -> Selecting load adress and go Advanced features -> Download image -> Test, burn, erase flash* -> Test RAM Best regards, Martin * Currently we have a customer board with Flash, RAM and other periphery. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

2 1

[U-Boot-Users] How to make u-boot like BIOS much more?
by mikore 31 Dec '02

31 Dec '02

Hello, I am going to design a GUI for ppcboot to make it have a prety face to user, but, how can I do this work? how much effort? Best Regards Mikore

2 1

[U-Boot-Users] Re: [PPCBoot-users] loads usage on a windows platform
by Holger Schurig 27 Dec '02

27 Dec '02

> Minicom is broken. It cannot be used for s-record download, except by > inserting unacceptable delays. If you have to use something over the serial cable, consider C-Kermit. I compiled for my Linux and it works great. Because it is scriptable (althought in a strange way), I can even automate things. My C-Kermit for example connects to my BDI2000 (over TCP/IP, not serial, it can do both), erases the flash and loads the new bootloader automatically: #!/usr/bin/kermit + .bdihost = bdi .prompt = bdi> .image = /bdi/armboot .image_start = 0x000000 define failquit { input 1 xxxxxxxxxxxxxxx close echo echo \%1 exit 1 } set input echo off set exit on-disconnect on ; Automatic exit on connection loss. set telopt start-tls refuse ; Do not use START_TLS option set telopt authentication refuse ; Do not use AUTH option set telopt encrypt refuse refuse ; Do not use ENCRYPT option echo "Connecting to \m(bdihost) ..." set host \m(bdihost) 23 /telnet ; Force Telnet protocol negotiations if fail exit 1 input 1 \m(prompt) if fail failquit {No prompt from bdi} define erase_flash { xecho "Erasing block \%1 ..." lineout "erase \%1" minput 4 {Erasing flash passed} \# if fail failquit {No answer to 'erase' command.} if ( = \v(minput) 2 ) failquit {Could not erase block \%1.} echo " done!" } erase_flash 0x000000 xecho "Burning image \m(image) ..." lineout "prog \m(image_start) \m(image)" minput 30 {Programming flash passed} \# if fail 1 failquit {No answer to 'prog' command.} if ( = \v(minput) 2 ) failquit {Could not burn image \m(image).} lineout "reset" echo " done!" close quit I'm using similar scripts to update my kernel and my jffs2. Basically I just change the .image, .image_start and the erase_flash lines. VERY different from S-Records ..., I know :-) -- MN-Logistik GmbH http://www.mn-logistik.de Holger Schurig Dieselstr. 18 61191 Rosbach v.d.Höhe Tel: 06003/9141-0 Fax: 06003/9141-49

2 1

[U-Boot-Users] a question about the flash.c in board/fads
by YanMin Qiao 25 Dec '02

25 Dec '02

in board/fads/flash.c in the flash_init(), i see u call flahs_get_size() twice, why?? and does the comment 'MB' mean MByte?? thnx best regard

1 0

[U-Boot-Users] "Standard" Practice for config of SanDisk compact pci memoru
by Jerry Walden 24 Dec '02

24 Dec '02

Greetings: Our hardware guy is tells me that the SanDisk can be placed in one of three modes: 1) PC Card Memory Mode 2) PC Card I/O Mode 3) True IDE Mode The device is going on a custom ppc 405GPr board. He is also asking me how the device will be accessed 1) on bytes 2) on words 3) or both I am not much of a hardware person, so I am not even certain if the question I am asking makes sense. The main goal is to use u-boot to bootstrap and initialize the board, and to load the linux kernel/file system from the compact flash. Does anyone have a reference design for a ppc based SBC with a san-disc like part on it that runs Linux? Kindest Regards, Jerry

1 0

Re: [U-Boot-Users] BDI debugger + u-boot
by Jerry Van Baren 23 Dec '02

23 Dec '02

At 10:16 AM 12/23/2002 -0500, invictus_rm(a)hotmail.com wrote: >Hi, > I am looking for a hardware debugger to help me in broad bringup and >kernel >debugging . Searching through google , i could find BDI2000 . It claims to >support firmware debugging as well as linux kernel with MMU enabled ........ > Has anyone on the list tried out the BDI2000......... > Will it be useful enough ?? YES >Is there something better ?? NO Sorry for shouting, but if you check the email archives of the ppc-boot (predecessor to u-boot), almost every discussion on hardware debugging has in it a recommendation to buy a BDI2000. If the poor unfortunate had already bought something else, condolences were expressed and they were advised to give away the "something else" and buy a BDI2000. It is possible to debug with "something else", but the bulk of the engineers here use the BDI2000 so you will get a lot more help here. The reason for this is because Abatron is a very enlightened company, very responsive (last week I got an update overnight to support a new flash memory), supports linux very well (including kernel debug with MMU support), etc. >regards >rm gvb ********************************************************************** This e-mail and any files transmitted with it are 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)si.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. ***********************************************************************

1 0

[U-Boot-Users] BDI debugger + u-boot
by invictus rm 23 Dec '02

23 Dec '02

Hi, I am looking for a hardware debugger to help me in broad bringup and kernel debugging . Searching through google , i could find BDI2000 . It claims to support firmware debugging as well as linux kernel with MMU enabled ........ Has anyone on the list tried out the BDI2000......... Will it be useful enough ??Is there something better ?? regards rm _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 3 months FREE*. http://join.msn.com/?page=features/featuredemail&xAPID=42&PS=47575&PI=7324&… http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_addphotos_…

2 1

[U-Boot-Users] hello
by Mikore 21 Dec '02

21 Dec '02

1 0

[U-Boot-Users] U-Boot-0.2.0 released
by Wolfgang Denk 17 Dec '02

17 Dec '02

The first version of U-Boot has been released. It is named U-Boot-0.2.0 and tagged as "U-Boot-0_2_0" on the CVS server. A tarball is available at ftp://ftp.denx.de/pub/u-boot/u-boot-0.2.0.tar.bz2 [In case anybody asks if there was a version 0.1.0: yes, there is such a version. It is identical with PPCBoot-2.0.0.] Major news: - Support for AmigaOne board - Support for x86 architecture ====================================================================== Changes for U-Boot 0.2.0: ====================================================================== * Use 1-byte-read instead of -write for iprobe() function Add i2c commands to PM826 config * extend I2C POST code: check for list on known addresses * Improve log buffer code; use "loglevel" to decide which messages to log on the console, too (like in Linux); get rid of "logstart" * Add command line tool to access the U-Boot's environment (board-specific for TRAB now, to be fixed later) * Patch by Hans-Joerg Frieden, 06 Dec 2002 Fix misc problems with AmigaOne support * Patch by Chris Hallinan, 3 Dec 2002: minor cleanup to the MPC8245 EPIC driver * Patch by Pierre Aubert , 28 Nov 2002 Add support for external (SIU) interrupts on MPC8xx * Patch by Pierre Aubert , 28 Nov 2002 Fix nested syscalls bug in standalone applications * Patch by David Müller, 27 Nov 2002: fix output of "pciinfo" command for CardBus bridge devices. * Fix bug in TQM8260 board detection - boards got stuck when board ID was not readable * Add LED indication for IDE activity on KUP4K board * Fix startup problems with VFD display on TRAB * Patch by Pierre Aubert, 20 Nov 2002 Add driver for Epson SED13806 graphic controller. Add support for BMP logos in cfb_console driver. * Added support for both PCMCIA slots (at the same time!) on MPC8xx * Patch by Rod Boyce, 21 Nov 2002: fix PCMCIA on MBX8xx board * Patch by Pierre Aubert , 21 Nov 2002 Add CFG_CPM_POST_WORD_ADDR to make the offset of the bootmode word in DPRAM configurable * Patch by Daniel Engström, 18 Nov 2002: Fixes for x86 port (mostly strings issues) * Patch by Ken Chou, 18 Nov 2002: Fix for natsemi NIC cards (DP83815) * Patch by Pierre Aubert, 19 Nov 2002: fix a bug for the MII configuration, and some warnings * Patch by Thomas Frieden, 13 Nov 2002: Add code for AmigaOne board (preliminary merge to U-Boot, still WIP) * Patch by Jon Diekema, 12 Nov 2002: - Adding URL for IEEE OUI lookup - Making the autoboot #defines dependent on CONFIG_AUTOBOOT_KEYED being defined. - In the CONFIG_EXTRA_ENV_SETTINGS #define, the root-on-initrd and root-on-nfs macros are designed to switch how the default boot method gets defined. * Patch by Daniel Engström, 13 Nov 2002: Add support for i386 architecture and AMD SC520 board * Patch by Pierre Aubert, 12 Nov 2002: Add support for DOS filesystem and booting from DOS floppy disk * Patch by Jim Sandoz, 07 Nov 2002: Increase number of network RX buffers (PKTBUFSRX in "include/net.h") for EEPRO100 based boards (especially SP8240) which showed "Receiver is not ready" errors when U-Boot was processing the receive buffers slower than the network controller was filling them. * Patch by Andreas Oberritter, 09 Nov 2002: Change behaviour of NetLoop(): return -1 for errors, filesize otherwise; return code 0 is valid an means no file loaded - in this case the environment still gets updated! * Patches by Jon Diekema, 9 Nov 2002: - improve ADC/DAC clocking on the SACSng board to align the failing edges of LRCLK and SCLK - sbc8260 configuration tweaks - add status LED support for 82xx systems - wire sspi/sspo commands into command handler; improved error handlering - add timestamp support and alternate memory test to the SACSng configuration * Patch by Vince Husovsky, 7 Nov 2002: Add "-n" to linker options to get rid of "Not enough room for program headers" problem * Patch by David Müller, 05 Nov 2002 Rename CONFIG_PLL_INPUT_FREQ to CONFIG_SYS_CLK_FREQ so we can use an already existing name * Patch by Pierre Aubert, 05 Nov 2002 Hardware relatied improvments in FDC boot code * Patch by Holger Schurig, 5 Nov 2002: Make the PXA really change it's frequency * Patch by Pierre Aubert, 05 Nov 2002 Add support for slave serial Spartan 2 FPGAs * Fix uninitialized memory (MAC address) in 8xx SCC/FEC ethernet drivers * Add support for log buffer which can be passed to Linux kernel's syslog mechanism; used especially for POST results. * Patch by Klaus Heydeck, 31 Oct 2002: Add initial support for kup4k board * Patch by Robert Schwebel, 04 Nov 2002: - use watchdog to reset PXA250 systems - added progress callbacks to (some of the) ARM code - update for Cogent CSB226 board * Add support for FPS860 board * Patch by Guillaume Alexandre,, 04 Nov 2002: Improve PCI access on 32-bits Compact PCI bus * Fix mdelay() on TRAB - this was still the debugging version with seconds instead of ms. * Patch by Robert Schwebel, 1 Nov 2002: XScale related cleanup (affects all ARM boards) * Cleanup of names and README. ====================================================================== Notes for U-Boot 0.1.0: ====================================================================== This is the initial version of "Das U-Boot", the Universal Boot Loader. It is based on version 2.0.0 (the "Halloween Release") of PPCBoot. For information about the history of the project please see the PPCBoot project page at http://sourceforge.net/projects/ppcboot ====================================================================== 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 "Though a program be but three lines long, someday it will have to be maintained." - The Tao of Programming

1 0

Re: [U-Boot-Users] booting linux from u-boot - help!
by Murray Jensen 17 Dec '02

17 Dec '02

On Tue, 17 Dec 2002 19:04:41 +1100, My-Hong Vuong <My-Hong.Vuong(a)au.thalesgroup.com> writes: >with the cache, i've disabled MSR_DR in head_8xx.S You mustn't do this - virtual memory will not work if you do this. >which then seems to >get to start_here fine. This is giving you false hope - you must leave the virtual memory on. >but inserting the same code just before >early_init doesn't seem to work... One problem that you need to look out for is that you only have 0x100 bytes available to you at that point. This is executing the reset exception handler at 0x...100 and the next exception handler must start at 0x...200. Don't insert too much code (you should get an error from the assembler - saying that you are trying to set the location backwards or something like that). >the assembly I'm using is : >lis r25, 0xaaaa >ori r25, r25, 0xaaaa >lis r26, 0x8100 >ori r26,r26,0x0000 >stw r25, 0(r26) > >where r25 is the pattern I want to write into address 0x81000000. I've >used r25 and r26 because I can't see them being used anywhere in the >code... r25 and r26 (and others) are used to save the arguments passed to kernel from the boot loader (in r3, r4, ..., r7) - it's like the first few instructions ever executed by Linux - you mustn't clobber these registers. Besides this, if you leave virtual memory on, this will not do what you think it will - you must first set up a temporary translation in the TLB before you can access that physical location, as is done for the Internal Memory Mapped Registers (IMMR) area. Of course, the appropriate BRx/ORx for the LEDs must have been set up by the boot loader so that the physical address 0x81000000 really does access the LED hardware (I assume this is the case - since you say this code works elsewhere). >I'm not sure how do do it otherwise (i.e. restoring the original >register values) Use some other registers (if you're careful) - e.g. r3, r4, r5 - these will be restored later when required (see call to identify_machine - or some name like that). >any other ideas would be muchly appreciated, I just got my BDI2000 - it's great. Other than that - pull out all code you have inserted and go back to the original Linux code - after carefully examining all the config options. If your hardware is correct and your linux config matches it properly, it should "just work" :-) Good luck. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

1 0

Re: [U-Boot-Users] booting linux from u-boot - help!
by My-Hong Vuong 17 Dec '02

17 Dec '02

I used smc1 because i was unable to get ppcboot running with smc2. our smc1 is at 9600. with the cache, i've disabled MSR_DR in head_8xx.S which then seems to get to start_here fine. but inserting the same code just before early_init doesn't seem to work... the assembly I'm using is : lis r25, 0xaaaa ori r25, r25, 0xaaaa lis r26, 0x8100 ori r26,r26,0x0000 stw r25, 0(r26) where r25 is the pattern I want to write into address 0x81000000. I've used r25 and r26 because I can't see them being used anywhere in the code... I'm not sure how do do it otherwise (i.e. restoring the original register values) any other ideas would be muchly appreciated, My Hong Vuong >>> Murray Jensen <Murray.Jensen(a)csiro.au> 12/17/02 04:24pm >>> On Tue, 17 Dec 2002 14:17:50 +1100, My-Hong Vuong <My-Hong.Vuong(a)au.thalesgroup.com> writes: >Thanks for the prompt response. My pleasure. >The board I'm working with does not utilise SDRAM, rather SRAM - Samsung >K1S321615M, which does not utilise burst access - our ORx has Burst >Inhibit turned on - it does not support burst accesses. This shouldn't >pose a problem then, should it? No you are correct, you simply won't do burst transfers on the bus which means it can't be the problem. >We have CPU6 turned off as we're using an MPC860T Rev.D.4. OK >Switching >the Copyback on and off seem to have no effect. OK >also, for the console, we have it set at SMC1, standard/generic >serial... SMC1 - therefore no modem control (this was going to be my next guess). By the way, don't try to set the baud rate too high - it won't work on and SMC. A nice easy 9600 is good to use. >i'm unclear as to what you mean by: >you must have a virtual memory mapping set up once the mmu is turned on >- the head.S file sets one up for the IMMR and the first 8M of RAM until >the kernel takes over. > >Do you mean that BRx and ORx need to be set up again? (btw, i'm a newbie >at this stuff) No, a virtual memory mapping in the MMU. Linux takes care of this stuff, but if you are going to be poking values into a hardware device, you need to set up a virtual to physical address mapping and use the virtual address when the MMU is turned on, and the physical address when it is turned off. The mapping also needs to be non-cached. For example, something like: volatile phys_addr_t phys_addr = (phys_addr_t)0xXXXXXXXX; volatile void *virt_addr; volatile led_struct *led_ptr; virt_addr = ioremap(phys_addr, size); /* if MMU is off */ led_ptr = (led_struct *)phys_addr; led_ptr->... /* if MMU is on */ led_ptr = (led_struct *)virt_addr; led_ptr->... Don't take this literally - its just quick notes to give you an idea. Note the BRx/ORx stuff sets the "physical" address of devices, while the MMU mappings set the "virtual" address (you don't need a mapping to access the IMMRs - this is done for you). Also, most places in Linux have the MMU on, except for certain routines in the startup, and the exception handlers (in assembly). Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 1

Fwd: Re: [U-Boot-Users] booting linux from u-boot - help!
by My-Hong Vuong 17 Dec '02

17 Dec '02

1 0

[U-Boot-Users] booting linux from u-boot - help!
by My-Hong Vuong 17 Dec '02

17 Dec '02

Hi, I've finally resolved my ethernet reset problem - we just happened to be moving things arount on our development area, and found that upon removal of the mpcbdm cable, our board no longer sporadically reset and our ethernet worked just fine. Can anyone shed some light on this? I'm open to suggestions and I'm sure users developing for custom boards would also find this information useful. Anyway, I'm now up to the stage of booting linux. i've tftp'd a pImage, loaded it into flash and have tried to boot it using: setenv bootargs root=/dev/hda1 bootm 04880000 ## Booting image at 04880000 ... Image Name: Linux-2.4.19-pre7 Created: 2002-12-16 8:04:21 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 599083 Bytes = 585 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK At this point, it hangs. I've double-checked linux/include/asm-ppc/ppcboot.h with u-boot/include/asm-ppc/ppcboot.h and the only difference is the following line: mon_fnc_t *bi_mon_fnc; /* Pointer to monitor functions */ which is required(?) I've also tried it with the clocks_in_mhz turned on and off with no avail. I modified linux/arch/ppc/kernel/head_8xx.S to flash some LEDs on the board at _start and that works, suggesting to me that at least the memory map parsed to linux is ok. however, trying to flash our leds to try and find out where our system hangs, it fails when i get to start_here. it appears that the system crashes after the "rfi", which enables our mmu. to "prove" this, we replaced the turn_on_mmu block with a simple "b start_here". what could possibly be the problem here?? in desperate need of help... and thanks in advance, My Hong Vuong

1 0

[U-Boot-Users] Automatic boot of Linux from flash (Big ppcboot image the sequel)
by "Callebaut, Benoît" 16 Dec '02

16 Dec '02

Hi, I tried another approach to boot directly Linux ,from flash from an image loaded in flash in one block. Instead of compiling ppcboot with an image of the linux kernel in a big array ( makes linking problem) I placed the kernel image direcltly after the ppcboot image with the (linux) command cat image >> ppcboot.bin. With the offset of the kernel and its length hardcoded no problem everything start. But when I use the function get_endaddr() (before relocation of course) It give me back an address approximatively 30 kBytes after the real end of ppcboot. Second problem, How can I find back or make ppcboot find the end of the Kernel image without anything hardcoded ? ---------------------------------------------------------------------------- ------ Benoit Callebaut Software Development Engineer Barco | Control Rooms Noordlaan 5, 8520 Kuurne, Belgium Tel +32(0)56 36 84 28 Fax +32(0)56 36 86 05 mailto:benoit.callebaut@barco.com http://www.barcocontrolrooms.com

2 1

Re: [U-Boot-Users] PPC 405 _start code - Clarification
by Wolfgang Denk 14 Dec '02

14 Dec '02

Dear Jerry, in message <EGEGIJHKDKJGAJMGIDPNCEHJCCAA.jwalden(a)digitalatlantic.com> you wrote: > Thanks for the clarification! You are welcome. > I am used to the x86 world, and when I disassemble something, I > am used to seeing a one for one mapping from instruction to op-code. This is the same with PowerPC. But there may be several equivalent mnemonics to encode the same instruction. The green book ("The Programming Environments") says: "To simplify assembly language programming, a set of simplified mnemonics (referred to as extended mnemonics in the architecture specification) and symbols is provided ..." > It is obvious that I need to become more proficient in PPC assembly, > how could you tell that the instruction we "equivalent" - did you > use a tool, or is it that you are simply that familiar with the PPC > assembly code. In this case I didn't need a book; but you can actually look it up. For example your first statement: > addi r4,r0,0x0000 The green book lists for "addi": addi rD,rA,SIMM and the simplified mnemonics: li rD,value equivalent to addi rD,0,value la rD,disp(rA) equivalent to addi rD,rA,disp subi rD,rA,value equivalent to addi rD,rA,-value The listing you got from the disassembler: > fff80100: 38 80 00 00 li r4,0 obviously matches rule 1 (well, it's only obvious if you now about the special role or R0 in such cases :-). 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 Where people stand is not as important as which way they face. - Terry Pratchett & Stephen Briggs, _The Discworld Companion_

1 0

[U-Boot-Users] PPC 405 _start code
by Jerry Walden 14 Dec '02

14 Dec '02

Greetings: I just build a version of u-boot for the PPC 405GP. If I disassemble the code that is generated I see the following: fff80100 <_start>: fff80100: 38 80 00 00 li r4,0 fff80104: 7c 99 eb a6 mtsgr r4 fff80108: 7c 9a eb a6 mtdcwr r4 fff8010c: 7c 94 f3 a6 mtesr r4 fff80110: 7c 9a f3 a6 mttcr r4 fff80114: 7c 81 03 a6 mtxer r4 fff80118: 7c 96 f3 a6 mtevpr r4 fff8011c: 38 80 10 00 li r4,4096 So to develop a deeper understanding of how all the pieces fit together I went to the start.S module under the cpu subdirecory. There I see the _start vector - however the code I see in start.S does not correspond to the code that I disassembled. What am I missing? Kindest Regards, Jerry

2 2

[U-Boot-Users] Big ppcboot image
by "Callebaut, Benoît" 13 Dec '02

13 Dec '02

Hello, I am using ppcboot 2.0.0 and I placed the linux kernel in the ppcboot image ( included in an header file). Note that I use automatic boot (ie I don't use the main loop) The idea is that instead of loading the image from an esternal source (nfs,...) I use only bootm to boot the image directly from memory. THe problem is that the ppcboot image is now around 720 kBytes instead of 120 kBytes. And something goes wrong at the end of the board_init_f just before the realocation (realocate_code) or in it. PPCBoot give me the following message "PPCBoot size -292044 > reserved (786432)" Some tips on what is going wrong. ---------------------------------------------------------------------------- ------ Benoit Callebaut Software Development Engineer Barco | Control Rooms Noordlaan 5, 8520 Kuurne, Belgium Tel +32(0)56 36 84 28 Fax +32(0)56 36 86 05 mailto:benoit.callebaut@barco.com http://www.barcocontrolrooms.com

4 3

[U-Boot-Users] Patch for multiple standalone images for bootm
by Rod Boyce 12 Dec '02

12 Dec '02

<<cmd_bootm.tar.gz>> All, Here is a patch to load multiple images from bootm command when the first image is a standalone image. There is a readme file inside the patch file. The patch is against the CVS version of U-Boot on 2002-12-11 Regards, Rod Boyce

1 0

[U-Boot-Users] Setting SIUMCR FYI
by Jim Mesenbrink 12 Dec '02

12 Dec '02

We are using u-boot for our custom board based on the MPC8260. For this board the chip select 10 pin is configured as BCTL1. u-boot would hang after SIUMCR was set in cpu_init_f() in the file cpu/mpc8260/cpu_init.c. The problem is that out of reset OR0[BCTLD] defaults to 0 ("BCTLx is asserted upon access to the current memory bank" 10-18). My next access to FLASH hung the system. I moved the assignment of SIUMCR after the memory controller ORx/BRx registers are setup, where ORx[BCTLD] is set they way we need, and u-boot ran fine. As the title suggests this is a FYI. I hope it is helpful. -- Jim Mesenbrink FlightSafety International mesenb(a)vss.fsi.com Visual Simulation Systems Phone: 314-551-8422 5695 Campus Parkway FAX: 314-551-8444 St. Louis, MO 63042-2338

1 0

[U-Boot-Users] Looking for ARM9E u-boot/linux platform - recommendations?
by Nye Liu 11 Dec '02

11 Dec '02

Greetings: I am working on an embedded linux ARM9E based project and i'm looking for a good eval board to get my feet wet... any suggestions? My primary concerns are (in order of importance): 1) MMU/cache/SDRAM support/stability (most important) 2) availability (preferably US mfg'r) 3) linux/u-boot stability 4) cost 5) performance (least important) PS: Hi Wolfgang! Moving to another project name will not get rid of me so easily, muahahaha ;) -- Nye Liu nliu(a)mrv.com "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

2 1

[U-Boot-Users] uncompressing two gziped images
by Rod Boyce 11 Dec '02

11 Dec '02

All, We are using U-Boot to start a new PPC platform. One of the things we need to do is to load hardware debug software and start it. U-Boot does this very well but we also need to load a data pack. This data pack is big for our flash but we can compress it. My question is how can I uncompress two stand alone images before starting one of them (the first one)? Before I start changing the code to do this for us I though I'd ask incase there is a way I have not been able to figure out yet. I have tried using mkimage and setting one to a Linux kernel image and the other one to a RAM disk but the RAM disk is not decompressed before being relocated. Regards, Rod Boyce

2 1

[U-Boot-Users] 82559( eepro100.c) & interrupt handling
by "Callebaut, Benoît" 09 Dec '02

09 Dec '02

Hello, I am trying use the MAC/PHY 82559 (rev C I think) on an interrupt base manner. The interrupt line of the chip is connected directly to the PPC (INT0), so I use the EPIC in direct mode. When the IVPR0[P] is active low configured and IVPR[S] is level sensitive configured I receive continuously an interrupt which is normal (I think the IRQ line of the chip is configured active high) When it is another configuration I receive nothing. I think, it is a problem with the configuration of the chip since with Linux the chip send well interrupts (every ms) but with Linux, the problem is the EPIC config. Does someone have an idea to solve this or better documentation than the one of Intel ? ---------------------------------------------------------------------------- ------ Benoit Callebaut Software Development Engineer Barco | Control Rooms Noordlaan 5, 8520 Kuurne, Belgium Tel +32(0)56 36 84 28 Fax +32(0)56 36 86 05 mailto:benoit.callebaut@barco.com http://www.barcocontrolrooms.com

2 1

[U-Boot-Users] Re: Boot Loader
by Marius Groeger 09 Dec '02

09 Dec '02

On Mon, 9 Dec 2002, Wolfgang Denk wrote: > > Until the U-Boot surfaces, would this be a good way to go, when faced > > with a custom board? > > No. You should not spend time on a project which has been > discontinued. Just download the latest (top of tree) version from the > U-Boot CVS server. Please note that not everyone can access SF's Anon-CVS because of their corporate firewalls. Are the nightly CVS snapshots available to everyone? Regards, Marius ----------------------------------------------------------------------------- Marius Groeger SYSGO Real-Time Solutions AG mgroeger(a)sysgo.de Software Engineering Embedded and Real-Time Software www.sysgo.de Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com

2 1

[U-Boot-Users] Patch: MPC8xx interrupt
by Pierre AUBERT 06 Dec '02

06 Dec '02

Dear Wolfgang, Currently, for the MPC8xx cpu, the irq_install_handler/irq_free_handler works only for the CPM interrupt. The attached patch allows to use irq_install_handler and irq_free_handler for external interrupts _and_ CPM interrupts. Best regards CHANGELOG: * Patch by Pierre Aubert , 28 Nov 2002 Add support for external interrupts on MPC8xx

2 1

[U-Boot-Users] PPC: problem with syscalls
by Pierre AUBERT 06 Dec '02

06 Dec '02

Hello everybody, I've a problem with examples/timer.c. I've tried to launch it on my mpc860t board, if I start the timer and if I press a key after one or more interrupts occured, the u-boot crashes. The problem is that an interrupt handler uses a system call (mon_printf) while the main loop is inside a system call (mon_getc). During a system call, the LR and SRRx are saved at a fixed location (0xcf4, 0xcf8 and 0xcfc) then the return address of the mon_printf in the main loop is overridden by the return address of the mon_getc in the interrupt handler. To avoid this problem, I think that we need to use a stack to store the return addresses (and the SRRx) of the system calls. What's your opinion ? Best regards

2 3

Re: [U-Boot-Users] I2C address above 0x7f
by Wolfgang Denk 04 Dec '02

04 Dec '02

In message <0212041401260G.06014(a)pcj86.jena.mazet.de> you wrote: > > > > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes > > > valid slave address, isn't it ? > > > > No, what makes you think so? It's the value that gets programmed into > > the MPC8xx I2C controller's I2ADD register. See the Users Manual for > > details. > > > > The subject suggests you ntended to ask something different? > > Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C brick > connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two different > addresses both above 0x7F, 0xAE for write access and 0xAF for read access. No. The FRAM has just one address: 0x57. The first octet sent on the I2C bus contains the 7 address bits plus a read/write bit. The I2C interface as used in U-Boot does NOT consider the read/write bit a part of the address - we use the plain 7 bit device address. > The FRAM is similar to E2PROM bricks like AT24C64. Yes, I know. You can find a configuration featuring a FM24CL64 FRAM in the LWMON config file ("include/configs/lwmon.h"). > My question: Is there an read/write abstraction layer inside of the I2C stuff > of PPCBoot ? I don't know if I should use the bit shifted address 0x57 You mean something like i2c_read() and i2c_write()? Of course there is. And there is also extensive command line support for I2C. Use "help". > instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've > tried both addresses without success. You probably got the address length wrong. See the LWMON board for a working example. > Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can > anybody give me an generic command line dump with iprobe in action? I've ran > iprobe but without any success. The only thing I see is: > > => iprobe > Valid chip addresses: Be careful. "iprobe" with the HW I2C code may take _very_ long to complete. If you don't need very fast bulk data transfers (100 kHz clock or more) you will find it probably much simpler to use SW (bitbanging) I2C instead. Here is what I get on a LWMON board: U-Boot 0.1.1 (Dec 4 2002 - 14:19:27) CPU: PPC823EZTnnB2 at 66 MHz: 16 kB I-Cache 8 kB D-Cache Board: Litronic Monitor IV Watchdog enabled I2C: ready DRAM: 64 MB POST spr PASSED FLASH: 16 MB KEYBD: Version 1.2 Net: SCC ETHERNET POST cache PASSED POST i2c PASSED POST cpu PASSED POST ethernet PASSED POST spi PASSED POST usb PASSED PCMCIA: No Card found Hit any key to stop autoboot: 0 => iprobe Valid chip addresses: 2E 51 52 53 55 56 => > I think iprobe has not found any valid chip. Is it so ? Seems so. 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 Many Myths are based on truth -- Spock, "The Way to Eden", stardate 5832.3

3 3

Re: [U-Boot-Users] I2C address above 0x7f
by diekema_jon 04 Dec '02

04 Dec '02

> But now I've another problem (sorry :-). Is there a more extensive syntax > description of all the I2C commands than the quick help messages. I don't > understand the meanings of "dotted address numbers" [.0, .1, .2] and "numbers > of objects" [# of objects]. What is happen if I leave out this fields or in > which case I have to use it ? >From Jerry Van Baren <vanbaren_gerald(a)si.com> on Wed, 23 Jan 2002: Note that I added a ".1" (default) or ".2" modifier to the chip internal address (offset). This allows you to use one byte addresses or two byte addresses in the same system and without the _X mess. ---------- Examples: Dumping 256 bytes from the SPD on a DIMM: => imd 57 0 100 0000: 12 00 00 00 00 00 00 00 00 00 00 11 00 00 00 22 ..............." 0010: 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 ................ 0020: 00 00 00 09 00 00 00 00 00 00 00 01 00 00 00 02 ................ 0030: 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00 06 ................ 0040: 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 00 ................ 0050: 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 ................ 0060: 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 ................ 0070: 00 00 00 09 00 00 00 00 ff ff ff ff 00 00 00 01 ................ 0080: 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 ................ 0090: 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 ................ 00a0: 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 03 ................ 00b0: 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 ................ 00c0: 00 00 00 08 00 00 00 09 00 00 00 00 00 00 00 01 ................ 00d0: 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 ................ 00e0: 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 ................ 00f0: 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 03 ................ Changing a few bytes... => imm 80 Usage: imm - i2c memory modify (auto-incrementing) => imm 50 80 00000080: ff ? 12 00000081: ff ? 34 00000082: ff ? 56 00000083: ff ? 78 00000084: ff ? . Dumping byte data: imd.b e 81 e imd.b f 81 e imd.b 11 81 5 Old emails that might help... To: ppcboot-users(a)lists.sourceforge.net From: Jerry Van Baren <vanbaren_gerald(a)si.com> Date: Wed, 23 Jan 2002 07:07:50 -0500 Good morning everybody, This message is being sent in two parts to (hopefully) squeeze it under the 40K limit of the list server. I sent it yesterday in one part: the moderator (Wolfgang?) has not released the oversize message. Wolfgang is out of town and I'm impatient :-/. ---------------------------------------------------------------- Attached are some I2C patches that I've been working on. This set of patches does two things: 1) Rationalize the i2c interface for the 8260, 8xx, and 4xx CPUs: all of them get the same interface, eliminating the horrible #ifdef cancer that was growing. 2) Create a generic soft_i2c.c in the /common directory that is configured by changing #defines in the board configuration file. This replaces the soft_i2c.c in the cpu/8xx and cpu/8260 subdirectories. 3) Creates a new set of commands that imitate the regular memory peek/poke commands: imd for I2C memory display, imm for I2C mem mod, imw, etc. IMHO this alone is worth the price of admission. The syntax of the commands is: imd {i2c_chip} {addr}{.1, .2} {len} imw {i2c_chip} {addr}{.1, .2} {data} [{count}] icrc32 {i2c_chip} {addr}{.1, .2} {count} imm {i2c_chip} {addr}{.1, .2} inm {i2c_chip} {addr}{.1, .2} iloop {i2c_chip} {addr}{.1, .2} [{length}] [{delay}] Note that I added a ".1" (default) or ".2" modifier to the chip internal address (offset). This allows you to use one byte addresses or two byte addresses in the same system and without the _X mess. 4) New I2C commands: iprobe {addr} - goes through all chip addresses, prints all chips that respond isdram {i2c_chip} - Dumps the SDRAM SPD memory in human readable form 5) Improved the hardware 8260 I2C driver, especially with respect to timeouts. The hardware 8xx I2C driver could probably benefit from this as well, but I don't have a 8xx system to test on. 6) The imd & friends really obsolete cmd_eeprom.c, but I patched it over for backwards compatibility. I thought about putting a pester printf in it for the I2C branch ("This command is obsolete, please use imd/imm/imw, etc.\n") but didn't. Discussion and advice on how to handle command obsolescence would be welcome. -------- This should be a clean patch against the latest PPCBoot, although I did not test that. What I need help with is: 1) Testing the 8xx code (should be OK, but it is untested) 2) Testing the 4xx code (a little shakier, I'm less familiar with the 4xx) 3) Figure out what to do with the ICU862 with its Xicor X40430 I2C EEPROM: I downloaded the X40430 spec sheet but had problems reconciling the spec sheet to the code and ended up not doing anything with the memory lock/unlock code. This is currently BROKEN. Notes: ------ Attachment: ppcboot/common/soft_i2c.c.gz - new file. Part 2 attachment: patch.gz - patches against latest PPCBoot. * The "soft_i2c.c" routines under the 8xx and 8260 cpu subdirectories are made obsolete by the new one in common. The new one is generic, configured by #defines in the board configuration. gvb To: Wolfgang Denk <wd(a)denx.de>, andrew may <acmay(a)acmay.homeip.net> From: Jerry Van Baren <vanbaren_gerald(a)si.com> Date: Wed, 30 Jan 2002 07:38:11 -0500 Attached are my latest i2c patches. I added in some of Andrews suggestions, primarily the [.bwl] attribute on the imm and inm commands. I also removed the gratuitous calls to i2c_init() in some of the i2c read (transfer) routines. Hopefully start up routines call i2c_init() properly before trying to read i2c -- if they don't, I would consider that to be a bug and should be fixed. I did _not_ include Andrew's patch reading the environment variable to determine the I2C speed. In the tarball, I included common/soft_i2c.c which is new and a clean copy of common/cmd_i2c.c which is totally different from the original (current PPCBoot version), making the patch file for it pretty tough to read :-). gvb ********************************************************************** This e-mail and any files transmitted with it are 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)si.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. ***********************************************************************

1 0

[U-Boot-Users] I2C address above 0x7f
by Stephan Linz 04 Dec '02

04 Dec '02

Hi all, currently I play with the I2C facility of PPCBoot 2.0.0 (I know, it's deprecated). At my TQ850L I'm using the I2C hardware machine (CONFIG_HARD_I2C) with needed configuration: * CFG_I2C_SPEED=400000 * CFG_I2C_SLAVE=0x7f Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the highes valid slave address, isn't it ? Best regards, Stephan Linz -- ====================================================================== Stephan Linz Software Engineer MAZeT GmbH Email: mailto:linz@mazet.de Branche office Jena Phone: +49-3641-2809-55 Göschwitzer Straße 32 Fax : +49-3641-2809-12 D-07745 JENA Germany Visit our web-pages: http://www.MAZeT.de ======================================================================

3 3

[U-Boot-Users] Ethernet ARP problem
by My-Hong Vuong 03 Dec '02

03 Dec '02

Hi, I'm developing for an MPC860T using ppcboot2.0 on a custom board. I'm in the stages of getting tftp up and running. I am using an AM79C874, which is identified correctly by ppcboot and I have intialised it to have all capabilities - tech[0:2] = 0x111. After several attempts to tftp failed, i ended up using Etherpeek to capture the packets. What I got in my packets was not an ARP request, but a XNS packet.... the protocol id had somehow changed from 0x806 to 0x807!!!! Experimenting, I changed it to 0x807 to see what i got, and i still got 0x807. trying 0x805 got me 0x805 but trying 0x804 got me 0x805.... it seems that the last bit is being set high somewhere. Doing a dump at location 0x1ff3420 (pointer to the bufaddr), i do get 0x0806 (all the correct values as a matter of fact), but etherpeek continues to receive it as an 0x807. Additionally, I changed the pointer to a location up a byte and doing a memory dump throught ppcboot is the same but using etherpeek, it still captures it as an 0x807 setting it to loopback : fecp->fec_r_cntrl = 0x00000001; gets me: Receive from protocol 0x0807 from the ppcboot console. what's going on here?? is there something that I'm not setting or perhaps setting incorrectly? Has anyone encountered this kind of problem before?? Thanks in advance, My Hong Vuong ------------------------------------------------------------------ Acoustic Mine Imaging Thales Underwater Systems 274 Victoria Road Rydalmere NSW 2116 +61 2 9848 3627 +61404 483 823 My-Hong.Vuong(a)au.thalesgroup.com ------------------------------------------------------------------

1 0

[U-Boot-Users] PATCH: MPC824x EPIC Driver cleanup
by Chris Hallinan 03 Dec '02

03 Dec '02

The following patch is a minor cleanup to the MPC8245 EPIC driver found in the MPC824x files. It is against this morning's CVS snapshot. It has been tested on a custom MPC8245 board that I derived from the Sandpoint configuration. Comments welcome. -Chris Hallinan DS4.COM, Inc.

1 0

RE: [U-Boot-Users] RAM vs. ROM version of PPCBoot My $0.02 worth
by Rod Boyce 03 Dec '02

03 Dec '02

At the risk of prolonging a dieing thread I'm going to add my two cents work as I think I have a slightly different perspective. For the record I now 100% agree with Wolfgang it makes no sense to create a new version of U-Boot linked at a different address. BUT... When I first started down this path I would have fought tooth and nail for the other approach. I come from an embedded 8/16-bit world where your code runs from ROM of some description and RAM is a very limited commodity. (For instance some of the projects I worked on have only 64-bytes of RAM including register space and stack.) My first though when I started working on PowerPC micro-controllers with a BDM was to use the BDM to initialise the system and then load the code into RAM and debug from there. What a luxury having any kind of debugger that let you step through your code. I created a couple of test applications this way some of which are still used today in our factory to debug the hardware. I even created a RAM only version of PPCBoot that would let me debug PPCBoot it became apparent very quickly that this was causing me a great deal of grief while trying to get PPCBoot working. I created a ROM version of PPCBoot and all of a sudden everything started to work. There are a great many things you are going to have to take out of PPCBoot to get it to work correctly in a RAM only mode. Being able to use RAM to debug from the outset looks like a good idea until you get past taking your first baby steps with PowerPCs but having a minimal BDI script and letting U-Boot do all the rest is a very good idea you will discover this for yourself. I strongly suggest you listen to guys like Wolfgang he has been there and done it more times than most of the rest of us I suspect. Like me I suspect by the time you have your board working correctly you are going to owe Wolfgang a beer or to good luck. Regards, Rod Boyce -----Original Message----- From: Chris Hallinan [mailto:clh@net1plus.com] Sent: Tuesday, December 03, 2002 1:32 PM To: wd(a)denx.de Cc: u-boot-users(a)sourceforge.net Subject: RE: [U-Boot-Users] RAM vs. ROM version of PPCBoot Wolfgang Denk wrote: > > In message > <NEBBKJPFOLJNBMFNKBIIKENKDCAA.clh(a)net1plus.com> you wrote: > > > > > Why RAM version? > > > Mostly, the convenience is the main reason. > > > > I can't imaging debugging PPCBoot (or most other flash-resident) > > code any other way. > > Oops? To me it makes absolutely no difference if the code > is runing > from RAM or ROM. Debugging is exactly the same (OK, > you might be > limited regarding thenumber of breakpoints when running > from ROM, but > usually this is no real handicap). I agree with your comments. The main reason I use RAM version is for load speed. OK, OK, I just timed it. To erase/program flash using BDI-2000, it takes erase: 3 seconds prog: 6 seconds (with WORKSPACE enabled) and to load into RAM: load: 2 seconds (with dcache disabled) So, you're right, the difference isn't really that much! :) -Chris Hallinan DS4.COM, Inc. ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ 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] RAM vs. ROM version of PPCBoot
by Ken Chou 03 Dec '02

03 Dec '02

Hi, Not everyone has BDI-2000 and FLASH! The measurement will have bigger delta in the case of neither bdi-2000 nor FLASH. It depends on the code size also. It is just added convenience (which the engineering is about: to make life a little easier ;-) It is not absolutely needed to be in CVS since it is trivial. Yet, I see it is beneficial for some to have it in CVS. Ken Chou > -----Original Message----- > From: Chris Hallinan [mailto:clh@net1plus.com] > Sent: Tuesday, December 03, 2002 1:32 PM > To: wd(a)denx.de > Cc: u-boot-users(a)sourceforge.net > Subject: RE: [U-Boot-Users] RAM vs. ROM version of PPCBoot > > Wolfgang Denk wrote: > > > > In message > > <NEBBKJPFOLJNBMFNKBIIKENKDCAA.clh(a)net1plus.com> you wrote: > > > > > > > Why RAM version? > > > > Mostly, the convenience is the main reason. > > > > > > I can't imaging debugging PPCBoot (or most other flash-resident) > > > code any other way. > > > > Oops? To me it makes absolutely no difference if the code > > is runing > > from RAM or ROM. Debugging is exactly the same (OK, > > you might be > > limited regarding thenumber of breakpoints when running > > from ROM, but > > usually this is no real handicap). > > I agree with your comments. The main reason I use RAM version is > for load speed. > > OK, OK, I just timed it. To erase/program flash using BDI-2000, it > takes > erase: 3 seconds > prog: 6 seconds (with WORKSPACE enabled) > > and to load into RAM: > load: 2 seconds (with dcache disabled) > > So, you're right, the difference isn't really that much! :) > > -Chris Hallinan > DS4.COM, Inc. > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Microsoft Visual Studio.NET > comprehensive development tool, built to increase your > productivity. Try a free online hosted session at: > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en > _______________________________________________ > 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] RAM vs. ROM version of PPCBoot
by Ken Chou 03 Dec '02

03 Dec '02

Hi, Why RAM version? Mostly, the convenience is the main reason. We use COP/BDM debugger during the development. It is quicker and easier to use RAM version instead of burning the flash in every turn of the firmware change. (Just think that you don't have FLASH and have only one-time PROM. This might not be the limitation for most of us today. Yet, it might be true in some cases.) It is natural to have RAM version during the development phase since the final code is moved out of FLASH and runs fro DRAM. The DRAM controller and the other initialization steps are done by debugger. There is no reason to hung up on the reset vector and always start from 0xfff00100. The PC can be changed by the debugger. I used this method when I just started learning PPCBoot in the 1.1.6 time. It is pretty useful since I did not have Ethernet and flash routine working at that time yet. Whether the RAM version should be checked into the CVS? It is up to the maintainer to decide. It might help some that just started U-Boot and without a good way to program FLASH in the beginning. I see there are a few board use "CFG_RAMBOOT" flag. My guess is that someone did the same thing as I did. Cut an intermediate RAM version in the beginning and move on to the FLASH version when the code is stabilized on the custom board. Ken Chou > -----Original Message----- > From: Wolfgang Denk [mailto:wd@denx.de] > Sent: Tuesday, December 03, 2002 4:55 AM > To: Stephan Linz > Cc: Mailing list U-Boot > Subject: Re: [U-Boot-Users] RAM vs. ROM version of ppcboot > > In message <02120313135706.06014(a)pcj86.jena.mazet.de> you wrote: > > > > > > I hope it's right to post questions about PPCBoot at U-Boot mailing > list. I'm > > Given the fact that PPCBoot has been laid to rest, yes. > > > new at PPCBoot, but know about internals of ARMBoot. So I know the ROM > and > > RAM versions of ARMBoot have to differ. > > Ummm... you don;t need a "RAM version" at all. > > > Now, I plan to download PPCBoot into the RAM of a TQM850L via gdb and > run > > from there. Gdb init the target processor inclusive address decoder. Can > I > > load a ppcboot binary builded from plain tarball into the RAM or schould > I > > swap some configs in include/configs/TQM850L.h ? > > Why would you want to do this? U-Boot (and PPCBoot) is running > perfectly fine from flash on all TQ boards. Why would you want to > create a "RAM version"? It makes no sense to me. > > As the CPU starts executing code from the boot device (CS0 = > typically flash) this is the most natural mode to run PPCBoot, too. > It was written to expect a CPU coming up from reset, so don't force > it into any other environment without a good reason and a very good > understanding of what you do, and why. > > Since you ask this question, I think you should NOT try doing this. > > > 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 > Even historians fail to learn from history -- they repeat the same > mistakes. > -- John Gill, "Patterns of Force", stardate 2534.7 > > > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T > handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users

3 3

[U-Boot-Users] RAM vs. ROM version of ppcboot
by Stephan Linz 03 Dec '02

03 Dec '02

Hi all, I hope it's right to post questions about PPCBoot at U-Boot mailing list. I'm new at PPCBoot, but know about internals of ARMBoot. So I know the ROM and RAM versions of ARMBoot have to differ. Now, I plan to download PPCBoot into the RAM of a TQM850L via gdb and run from there. Gdb init the target processor inclusive address decoder. Can I load a ppcboot binary builded from plain tarball into the RAM or schould I swap some configs in include/configs/TQM850L.h ? thanks, Stephan -- ====================================================================== Stephan Linz Software Engineer MAZeT GmbH Email: mailto:linz@mazet.de Branche office Jena Phone: +49-3641-2809-55 Göschwitzer Straße 32 Fax : +49-3641-2809-12 D-07745 JENA Germany Visit our web-pages: http://www.MAZeT.de ======================================================================

2 2

[U-Boot-Users] FAT32 for Compact Flash
by Ken Chou 02 Dec '02

02 Dec '02

Hi, Has anyone tried the FAT file system on the compact flash? Ken

1 0

[U-Boot-Users] autoscript?
by Steven Scholz 02 Dec '02

02 Dec '02

Hi there, how can a make an u-boot image that contains a kernel _and_ a script? How is the syntax within the script? Thanks, Steven

3 7