[U-Boot] Can physical flash initramfs cpio address be given to bootm?

[U-Boot] Can physical flash initramfs cpio address be given to bootm?

[Brian Hutchinson]

Can I use the physical flash address of a initramfs with the u-boot
bootm command?  The kernel doesn't appear to like it .... see below.

I'm not sure if the problem I've having is a kernel or u-boot issue.
I posted on the ARM linux list too so forgive me if you are on both
lists.

I need a initial ram filesystem and don't want it built into the
kernel so I've built an external initramfs cpio.gz.

I'm currently loading my cpio initramfs into u-boot via tftp and then
providing the initrd= bootarg which works.

I've tried to wrap the cpio with mkimage both with -a 0x0 -e 0x0 and a
RAM address such as -a 0x4000000 -e 0x4000000 (the location I tftp the
initramfs to)

With boths types if mkimage's mentioned above, when I do a bootm
0x20080000 (physical flash location of kernel)
0x20280000 (mkimage of cpio.gz made with -T ramdisk) the cpio is
loaded into ram but the physical
flash address of the initramfs gets passed to kernel via ATAGS and the
kernel doesn't like it:

INITRD: 0x20280040+0x00c8bdb6 extends beyond physical memory - disabling initrd

I thought I saw a patch that allowed initramfs to come from physical
media (flash) but it looks like I currently have to copy the initramfs
to ram right now and provide the initrd= which I would like to get
away from since I don't want to have to touch u-boot env vars every
time the cpio changes.

I don't know if I'm heading in the weeds but my thought were to either
modify kernel to allow initramfs to come from outside external ram
(the patch I mentioned) which would be my NOR flash, or modify my
u-boot so the ATAGS passed to the kernel would include the -a or -e
address from the mkimage header.

How do you all load a initramfs from flash???

I'm using 2.6.28 kernel and u-boot 1.1.6.

Regards,

Brian

[U-Boot] Can physical flash initramfs cpio address be given to bootm?

[Wolfgang Denk]

Dear Brian Hutchinson,

In message <3d1967ab1003171233g5dc9cc20me150066bf64f5db2@mail.gmail.com> you wrote:
> Can I use the physical flash address of a initramfs with the u-boot
> bootm command?  The kernel doesn't appear to like it .... see below.

As far as U-Boot is concerned: yes, you can.

In my understanding any sane kernel implementation shoul dbe able to
deal with this.

> I'm not sure if the problem I've having is a kernel or u-boot issue.
> I posted on the ARM linux list too so forgive me if you are on both
> lists.

Indeed ARM is one architecture which is well-known for NOT supporting
such a boot mode - for reasons I still fail to understand.

Patches to fix this have been posted several times on the ARM kernel
list - and been rejected because such a feature is "not needed".

> I need a initial ram filesystem and don't want it built into the
> kernel so I've built an external initramfs cpio.gz.

I understand your situation. You have basicly 3 options:

- accept the additional, useless copy of the file system image to RAM
- convince the ARM maintainers that this is a useful feature
- live with out-of-tree patches like this one:
  http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=4f112fe89c1ca9ad7853304bd93d39aeedbb06f9

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.

[U-Boot] Can physical flash initramfs cpio address be given to bootm?

[Brian Hutchinson]

On Wed, Mar 17, 2010 at 4:48 PM, Wolfgang Denk <wd@denx.de> wrote:
> As far as U-Boot is concerned: yes, you can.
>
> In my understanding any sane kernel implementation shoul dbe able to
> deal with this.

Thanks Wolfgang!  I sure do thank the Lord for your diligence over the
past 10+ years!

> Indeed ARM is one architecture which is well-known for NOT supporting
> such a boot mode - for reasons I still fail to understand.
>
> Patches to fix this have been posted several times on the ARM kernel
> list - and been rejected because such a feature is "not needed".

Yes sir, I've seen those posts and the discussion around them; patch
in question being rejected which I didn't understand the grounds for.
You have two options for initramfs, built into the kernel and loaded
external.  This method replaces the old way of doing it with a ext2
filesystem and a fake block device so if you need a ramdisk ...
initramfs is the more efficient way to do it (thanks to Linus) ....
but then I was puzzled as to why I couldn't get this to work and
consulted the ARM kernel archives which left me even more confused
about this "not being needed".

>> I need a initial ram filesystem and don't want it built into the
>> kernel so I've built an external initramfs cpio.gz.
>
> I understand your situation. You have basicly 3 options:
>
> - accept the additional, useless copy of the file system image to RAM
can't, will not, it just doesn't make sense (at least to me).

> - convince the ARM maintainers that this is a useful feature
I don't think I'm worthy of being able to do that.  Russell did save
my bacon recently ... I couldn't load my initramfs due to using
discontig mem model and he suggested I switch to sparse mem which
fixed my problem so props to him.

> - live with out-of-tree patches like this one:
> ?http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=4f112fe89c1ca9ad7853304bd93d39aeedbb06f9

Thanks again for checking my sanity (again) and now that I know I'm
not crazy (well mostly) I'll look for a patch that will not make the
kernel balk at locations outside of physical ram.

On a different topic, may I ask what happened to mini_fo in the git
repository?  Doesn't look like it has been touched in a long time.  I
needed a squashfs + union so I ended up finding patches for a 2.6.30+
kernel on the OpenWRT site and back ported them to my 2.6.28 kernel to
get around iget etc. being removed.

Is there a golden repository of this anymore?

Regards,

Brian

[U-Boot] Can physical flash initramfs cpio address be given to bootm?

[Brian Hutchinson]

Hi Wolfgang,

I applied Ilya's ARM initramfs outside physical RAM patch and it
appears to work.  It still displays the warning of disabling the
initrd due to the image being outside physical RAM (I can fix that :)
).

I took the cpio.gz I had and did the following mkimage to it:

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n
uInitramfs_busybox -d /home/hutch/initramfs_data.cpio.gz
uInitramfs_busybox

Flashed this image to the filesystem mtd and edited u-boot vars to:

bootm <physical flash location of kernel> <physical flash location of
initramfs.cpio.gz>

This loads the ARM kernel, loads the initramfs image and then starts
the kernel.  There is a pretty long pause but it worked.

Is this still the right way to go about loading the newer initramfs
type images from flash?  I know it is how things were done with the
older ext2 way of doing ramdisks.

Will the initramfs be loaded to address 0 in RAM (the -a and -e
addresses) and then the kernel relocate it yet again?

Regards,

Brian