UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable
5,827 Views

initramfs with powerpc

Jump to solution

Has anyone successfully used initramfs with the Xilinx powerpc? I'm seeing a problem where, when the .elf image with initramfs included gets "large" (somewhere around 2MB), the kernel doesn't come up at all - meaning no console output whatsoever. If I then remove some features from the kernel or the root file system, making the .elf smaller, the kernel starts working again.. I'm currently using a snapshot of the xiling git tree from kernel version 2.6.27. 

 

Thanks,

Terry

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Anonymous
Not applicable
6,780 Views

Re: initramfs with powerpc

Jump to solution

Thanks Robert - At the moment, I'm using xmd to download simpleImage.virtex440-ml507.elf.  So last night I found another post mentioning something similar. I modified arch/powerpc/boot/wrapper, changing the "link_address" parameter to 0x800000 for the simpleboot-virtext440- entry. This works, and (I assume) I now have 8MB to work with..

 

So now have two more questions:

 

1) Is there a way to do this with a config option like you mentioned, or at least something cleaner than modifying "wrapper"

2) are there any adverse affects of doing this (or going even larger), assuming I have the memory available?

 

 

Thanks,

Terry

 

Message Edited by toneal on 05-28-2009 09:24 AM
0 Kudos
3 Replies
Visitor so_robert
Visitor
5,807 Views
Registered: ‎04-08-2009

Re: initramfs with powerpc

Jump to solution

Hi Terry!

 

I asume you use the bootstrap loader (included in the zImage).

It seems like the bootstraploader overwrites the original zImage.

This situation is discribed in Chapter 4 "Booting and Debugging" on slide 152 of the Xilinx Linux training. You should be able to get this presentations within Xilinx.

The solution is to change the "initial-load-address" of the zImage. The default download address is 0x400000. During startup the bootstraploader uncompresses the zImage to 0x00000000. This means your uncompressed kernel+initramfs is not allowed to be bigger then 4MByte. If it is bigger, its overwrites itself. In the past it was possible to change this address with the configuration option CONFIG_BOOT_LOAD_BOOL. I tried to find this option in the actual version and couln't find it anymore. Keep us up-to-date if you find the actual way to handle this.

A workaround would be to use a bootloader like uboot.

Regards,

Robert

Highlighted
Anonymous
Not applicable
6,781 Views

Re: initramfs with powerpc

Jump to solution

Thanks Robert - At the moment, I'm using xmd to download simpleImage.virtex440-ml507.elf.  So last night I found another post mentioning something similar. I modified arch/powerpc/boot/wrapper, changing the "link_address" parameter to 0x800000 for the simpleboot-virtext440- entry. This works, and (I assume) I now have 8MB to work with..

 

So now have two more questions:

 

1) Is there a way to do this with a config option like you mentioned, or at least something cleaner than modifying "wrapper"

2) are there any adverse affects of doing this (or going even larger), assuming I have the memory available?

 

 

Thanks,

Terry

 

Message Edited by toneal on 05-28-2009 09:24 AM
0 Kudos
Xilinx Employee
Xilinx Employee
5,781 Views
Registered: ‎09-10-2008

Re: initramfs with powerpc

Jump to solution

I've seen this topic out in linuxppc-dev mailing list when people have added a lot of drivers and stuff in the kernel statically such that the size of the kernel got too big. 

 

I have only seen the recommendation to hack it like you talked. If we thought this was a change that we should keep we could make it in the Xilinx tree even though it wouldn't get into the mainline kernel.  I'm not sure if there's a reason not to change it in the mainline kernel or not.

 

-- John

0 Kudos