[U-Boot-Users] RAM vs. ROM version of PPCBoot

[Chris Hallinan]

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.