[U-Boot-Users] [PATCH] add OpenGear CM4008 board support

[Wolfgang Denk]

Dear Greg,

in message <4292CCC5.2050104 at moreton.com.au> you wrote:
> 
> > You can "compute" the image size at download time - actually it comes
> > for free in $filesize.
> 
> It is not the filesize that you want. You want the size of the

Yes, it is what *I* want :-) 

> filesystem that is the first part of the combined image. You

This is the catch: I wouldn't use combined images.

> To get the filesystem size you have to look at the first few
> words when you get it in memory. Once you figure out the filesystem
> type (since there is only a couple of interresting types that
> can work here you only need to check for the magic number header)
> you know how to determine its size.

Did you read my proposal of using a multifile image?

> You don't know where the kernel starts until you have a look in the
> header of the filesystem. If it is CRAMfs or ROMfs (or that type of

I understand this problem., It results from an unadept choice of your
image layout - put the kernel first, and the problems  just  go  away
:-)

> Because there is no boot loader header this image is directly mountable
> if I copy it into an mtd flash partition.

You can do the same with a standard multifile image.

> > I think it is not a good idea to use header-less kernel images - most
> > projects I've seen were happy enough to be able to  find  outr  which
> > image is installed in flash and if it's corrupted or not. YMMV.
> 
> Some people want that, some don't. There is a pretty big installed
> base of configurations that don't use headers.

Well, the only disadvantage you  get  from  having  a  header  is  an
additional  64  bytes  (or  68  +  4  * number of images in case of a
multi-image file). More memory is saved by NOT  adding  special  boot
code for headerless images.

> > "tftp ..." followed by using $filesize seems not too  complicated  to
> > me.
> 
> As I pointed out that does not work, it is not filesize you want.

It does work. I use it all the time. You just have to use tftp  twice
- once for the filesystem and a second time for the kernel :-)

> This method is in common use. The snapgear guys have been
> doing it for years. They would have a pretty large installed
> base (though that is not relevant to this discussion).

Well, I cannot prevent anybody from not reading the documentation  or
from  doing  non-standard  things.  I don't consider it my problem if
Snapgear comes up with a solution that ignores the existing  standard
methods and creates their own proprietary solutions or problems.

Quote:

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn


But I will try to enforce some  design  principles  on  the  official
U-Boot tree, and one of these is to avoid duplication of code.

Don't use "a pretty large installed base" as an argument - it doesn't
count. You could have discussed your design here on the mailing  list
BEFORE implementing your own proprietary stuff.

> It is not a question of tolerating anything, it is about
> finding a solution that is acceptable to you for something
> that u-boot cannot currently do.

Did you *read* me previous message? Why do you continue to ignore  my
proposal of using a multifile image instead? I really don't see where
exactly your problem is.

> Yes, the requirement is to be able to store the image in flash and have
> it directly bootable and mountable, and for it to be network loadable
> and to run just the same that way. Ofcourse it has to support the ARM
> boot tags, this is booting an ARM linux kernel.

Yes, I understood this. And ALL of this is available with either  two
separate images or with a combined multifile image.

> 1. the image cannot have a header - otherwise it would not be
>     directly mountable as a filesystem on an mtd device

Wrong. As I explained before, you can use a multifile image with  the
header  "belonging"  to the kernel, which should be the first file in
the image then.

> 2. you need to determine the kernel start address so you can
>     run it (irrespective of whether it is in flash or network
>     loaded into RAM

You created this problem  yourself.  It  results  from  your  unadept
design.

If you use a multifile image with a proper header  the  kernel  start
address is encoded in the header.

> 3. you don't want to copy the filesystem part needlessly (so if it
>     is in flash then don't bother copying it to RAM, and don require
>     any additional copy of filesystem if network loaded into RAM

Agreed. But I don't  see  what  this  has  to  do  with  the  current
discussion.  It's  a  completely  separate  issue,  relevant  only to
ramdisk images and then more of a Linux kernel question (i. e. if  it
can read a [compressed] ramdisk image directly from flash or not).

> You want this setup to support boot tags - since that is the
> ARM defined mechanism for parsing boot information to the kernel.

This is part of the standard boot command. Just use it.

> The fundamental idea is to have a single image that is a single file
> that is capable of all of this. (in other words it can be directly
> dumped into an mtd flash partition - usually within Linux, and it is
> capable of being network loaded and run.

You repeat this again and again. I understood your intentions.

But there is amy ways to implement  this,  and  I  repeat  that  your
method is probably not the best one.

> I can load a one of these combined images into RAM (or from flash)
> using standard command, I can manually determine the size by dumping
> memory and looking at, I can start that image. I can do all of this
> without any extra command support (though I am not sure about

Right. YOu can also save all this effort and  just  use  a  multifile
image.

> automating the size calculation here). But with no ARM tags in
> memory it is not a correct boot.

Right. Which is one of the reasons why this approach  does  not  make
sense.

>  From what you have said so far it seems I was right, you cannot do
> this currently with u-boot?

Wrong. I really ask myself if you are READING my postings????


I try to explain to you that it CAN be done, with  existing  commands
only.

> Is a command tool that allows constructing ARM tags a better solution
> for you?

What for? WE ALREADY HAVE A WORKING IMPLEMENTATION FOR THIS!

> > If I wanted to do this, I would probly  change  the  order:  put  the
> > kernel  image  first,  followed  by  the filesystem image. Then we ar
> > every close to using a standard  multi-file  image.  The  only  thing
> > still  needed  is  to  manually pad the kernel image so that the file
> > system will start on a sector boundary.
> 
> But I cannot copy this "as is" into an mtd flash partition and
> mount it as a filesystem.

Please explain why not?

> Even if you try to pad out to mtd partition boundaries that is at best
> a kludge. You will either waste too much flash space, or you will
> eventually have a kernel that is too large. It will happen.

Ummm... I cannot parse this. Can you please explain how  this  should
be  any problem? I mean, any more of a problem like in your solution?
I understand that your kernel uses a static partition map, right?  So
the kernel knows about the current partitioning?

> > If this is too cumbersome, you could easily patch the mkimage tool to
> > take  a  new  option  ("-b  blocksize"  or  so)  to  do  the  padding
> > automatically for you.
> > 
> > That would be even more flexible as it does not restrict you to  just
> > two images.
> 
> I don't understand, two images?

A multifile image contains one ore more (usually more,  that's  where
the  "multi"  is  coming  from) "files" or "images". You talk allt he
time about two items: the linux kernel and a file system. So we  have
two "files" or "images" to deal with, right?

With the multifile setup you could - for example - have 3 "files"  or
"images"  in  one  combined  image  - say (1) the Linux kernel, (2) a
read-only root file system like a cramfs image, and  (3)  a  writable
JFFS2 image for configuration data etc.

> Virtually all the platfoms I deal with do not have the flash space for
> two images (or even just two kernels). If they did then the hardware

But you are using two images: kernel plus root filesystem - right?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is only one way to console a widow.  But remember the risk.
                                                   -- Robert Heinlein