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

Wolfgang Denk
2005-05-24T09:00:46Z

Dear Greg,

in message <4292CCC5.2050104@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