[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 at 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