Execute-in-Place (XIP)

Execute-in-Place (XIP)

[Chris Boot]

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

Hi all,

Due to the puny amounts of RAM (2MB) on my board, I'm going to have  
to use XIP so that RAM isn't being taken up by kernel code. I was  
looking around for MIPS XIP patches and all I could find was in the  
linux-vr tree which seems, well, dead. Does anyone know of any more  
recent patches or should I undertake the work of porting the patch to  
a more recent 2.4 kernel?

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2359 bytes --]

Re: Execute-in-Place (XIP)

[Ralf Baechle]

On Thu, Oct 27, 2005 at 10:02:40AM +0100, Chris Boot wrote:

> Due to the puny amounts of RAM (2MB) on my board, I'm going to have  
> to use XIP so that RAM isn't being taken up by kernel code. I was  
> looking around for MIPS XIP patches and all I could find was in the  
> linux-vr tree which seems, well, dead.

The linux-vr tree is kept online for people to dig out the goodies which
may be left in there :-)

> Does anyone know of any more  
> recent patches or should I undertake the work of porting the patch to  
> a more recent 2.4 kernel?

I guess you'll have to do that.  The alternative would be to port the
2.6 ARM XIP_KERNEL implementation.

  Ralf

Re: Execute-in-Place (XIP)

[Chris Boot]

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

On 27 Oct 2005, at 11:29, Ralf Baechle wrote:

> On Thu, Oct 27, 2005 at 10:02:40AM +0100, Chris Boot wrote:
>
>
>> Due to the puny amounts of RAM (2MB) on my board, I'm going to have
>> to use XIP so that RAM isn't being taken up by kernel code. I was
>> looking around for MIPS XIP patches and all I could find was in the
>> linux-vr tree which seems, well, dead.
>>
>
> The linux-vr tree is kept online for people to dig out the goodies  
> which
> may be left in there :-)
>
>
>> Does anyone know of any more
>> recent patches or should I undertake the work of porting the patch to
>> a more recent 2.4 kernel?
>>
>
> I guess you'll have to do that.  The alternative would be to port the
> 2.6 ARM XIP_KERNEL implementation.
>
>   Ralf

Looks like I'm getting somewhere! I still don't have a JTAG or any  
way to test the kernels I've built, but readelf provides good looking  
results and my flat binary image looks like it will do the right thing.

Basically what I've done is ported over the XIP code from the linux- 
vr tree but renamed config symbols to be more similar to the ARM XIP  
code in 2.6, so then I can port the 2.6 MTD code into my 2.4 tree (if  
possible) that little bit more easily.

The only remaining question now is: the kernel_entry symbol seems to  
be placed pretty randomly in my kernel image, and the way I'm finding  
it now is by getting the entry point address from readelf. Is there a  
way I can either move this to be at the start of the image or insert  
the entry point address at the start of my image? Surely I can't be  
expected to hand-edit an entry point address in my bootloader and  
flash the lot to run my kernel, can I?

Many thanks,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2359 bytes --]

Re: Execute-in-Place (XIP)

[Chris Boot]

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

On 28 Oct 2005, at 23:20, Chris Boot wrote:

> On 27 Oct 2005, at 11:29, Ralf Baechle wrote:
>
>
>> On Thu, Oct 27, 2005 at 10:02:40AM +0100, Chris Boot wrote:
>>
>>
>>
>>> Due to the puny amounts of RAM (2MB) on my board, I'm going to have
>>> to use XIP so that RAM isn't being taken up by kernel code. I was
>>> looking around for MIPS XIP patches and all I could find was in the
>>> linux-vr tree which seems, well, dead.
>>>
>>>
>>
>> The linux-vr tree is kept online for people to dig out the goodies  
>> which
>> may be left in there :-)
>>
>>
>>
>>> Does anyone know of any more
>>> recent patches or should I undertake the work of porting the  
>>> patch to
>>> a more recent 2.4 kernel?
>>>
>>>
>>
>> I guess you'll have to do that.  The alternative would be to port the
>> 2.6 ARM XIP_KERNEL implementation.
>>
>>   Ralf
>>
>
> Looks like I'm getting somewhere! I still don't have a JTAG or any  
> way to test the kernels I've built, but readelf provides good  
> looking results and my flat binary image looks like it will do the  
> right thing.
>
> Basically what I've done is ported over the XIP code from the linux- 
> vr tree but renamed config symbols to be more similar to the ARM  
> XIP code in 2.6, so then I can port the 2.6 MTD code into my 2.4  
> tree (if possible) that little bit more easily.
>
> The only remaining question now is: the kernel_entry symbol seems  
> to be placed pretty randomly in my kernel image, and the way I'm  
> finding it now is by getting the entry point address from readelf.  
> Is there a way I can either move this to be at the start of the  
> image or insert the entry point address at the start of my image?  
> Surely I can't be expected to hand-edit an entry point address in  
> my bootloader and flash the lot to run my kernel, can I?

Gaah! Just as I sent this I whacked a 'j kernel_entry' at the top of  
head.S and it does what I want. Now, time to get the hardware side of  
things done, and a bootloader written! ;-)

Now, who knows how much initialisation a bootloader is expected to  
perform? Does the vrboot loader do the necessary operations, in which  
case I can just work on that instead of writing my own?

Cheers,
Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2359 bytes --]

Re: Execute-in-Place (XIP)

[David Daney]

Chris Boot wrote:
> 
> Now, who knows how much initialisation a bootloader is expected to  
> perform? Does the vrboot loader do the necessary operations, in which  
> case I can just work on that instead of writing my own?
> 
It depends.

Depending on the hardware:

Initialize clocks (things like PLL divisors and such).

Initialize serial port so it can report on its progress.

Initialize memory controller (so that RAM functions).

(optionally) copy bootmonitor to ram so that it can run out of cached 
memory.

(optionally) copy kernel image to ram (possibley uncompressing it) and 
transfersing control to the kernel.

If you are doing XIP, the last two steps are probably skipped.


I have no idea what the vrboot loader does, but that is what the Xilleon 
boot loaders do.

David Daney