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.