December 2002 - U-Boot

[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