RE: [U-Boot-Users] RAM vs. ROM version of PPCBoot
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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Ken Chou 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.
<snip>
I see there are a few board use "CFG_RAMBOOT" flag. My guess is that someone did the same thing as I did.
I use this method, and it is trivial. Here are the steps I use to convert my build from FLASH code to RAM code:
My board/myboard/config.mk file looks like this: TEXT_BASE = 0x00400000 #TEXT_BASE = 0xFFF00000
PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE) -DDEBUG -DCONFIG_DNA -DCFG_RAMBOOT #PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE) -DCONFIG_DNA -DDEBUG
I simply flip-flop the commented out lines for RAM or FLASH. Then I rebuild all objects (after make clobber) and I have the binary for either FLASH or RAM. (There are a dozen other ways this could be done, but I subscribe to the "Don't Fix It If It Ain't Broke" school.
I use the flag "CFG_RAMBOOT" to comment out the cpu-specific stuff like SDRAM init, etc., that breaks when running from RAM. My current version for 824x comments out exactly 2 lines in start.S like this: #ifndef CFG_RAMBOOT bl early_init_f /* Must be ASM: no stack yet! */ #endif ... #ifndef CFG_RAMBOOT bl cpu_init_f /* run low-level CPU init code (from Flash) */ #endif
I then load the resulting (RAM-based) image at TEXT_BASE and type 'go 400100'.
I can't say it's perfect, but I can say this: it has worked for me without problems for several different projects.
-Chris Hallinan DS4.COM, Inc.
In message NEBBKJPFOLJNBMFNKBIIKENKDCAA.clh@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 can't say it's perfect, but I can say this: it has worked for me without problems for several different projects.
Good for you. I always start with code running from flash, and it has worked for me without problems for several different projects, too - so what? :-)
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message NEBBKJPFOLJNBMFNKBIIKENKDCAA.clh@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.
participants (3)
-
Chris Hallinan -
Ken Chou -
Wolfgang Denk