RE: Loading Linux from already running code..

[Sumesh Kaana <sumeshkkn@hotmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]


Hi Philipp and Carlos,

Thanks for the reply.

When simpleImage.elf is loaded by a debugger, the debugger reads the elf image header and places various sections of image into right place in the RAM. But when I do it from already_running_code, I should manually unpack the elf and place the sections in the memory, then jump to the start address, Am I right?

Also,
Is it possible to load a simpleImage.bin file and jump to the start address using a function pointer, Hence I can avoid unpack_elf_image()...? - Will this work?


Thanks,
Sumesh.



> Date: Mon, 26 Sep 2011 20:13:24 +0200
> Subject: Re: Loading Linux from already running code..
> From: p.ittershagen@googlemail.com
> To: cmunoz@sablenetworks.com
> CC: linuxppc-dev@lists.ozlabs.org; sumeshkkn@hotmail.com
> 
> On Mon, Sep 26, 2011 at 7:26 PM, Carlos Munoz <cmunoz@sablenetworks.com> wrote:
> > You could build a tarball containing the root files system, dtb, Linux,
> > plus a header indicating where the different pieces need to be loaded.
> > Then your initial code loads the different parts at the right memory
> > locations, sets up the Linux arguments, and jumps to Linux.
> 
> That is exactly what the firmware-independent simpleImage.initrd.*
> targets already do. The resulting elf file include the dtb and initrd
> as well as a prompt-like boot arg cli.
> I think it will be possible to just place the simpleImage.initrd.*
> into you memory and let the existing code jump to the start adress of
> the elf image. I managed to start a ppc core using JTAG and the
> simpleImage.initrd elf files and I think the procedure is very much
> the same but instead of the JTAG debugger setting the PC to the start
> address, your startup code has to do it.
> 
> 
> Philipp
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]