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

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

[Greg Ungerer]

Hi All,

Attached is a patch that adds support to u-boot for the OpenGear
CM4008 8 port console manager board. It is built around the
KS8695P CPU, with 8 serial ports, 16MB RAM, and 8MB NOR flash.

This patch was originally generated against u-boot 1.1.1.

Regards
Greg




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot.cm4008.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050517/58058d10/attachment.txt 

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

[Wolfgang Denk]

In message <4289F766.5040208@moreton.com.au> you wrote:
>
> Attached is a patch that adds support to u-boot for the OpenGear
> CM4008 8 port console manager board. It is built around the
> KS8695P CPU, with 8 serial ports, 16MB RAM, and 8MB NOR flash.
> 
> This patch was originally generated against u-boot 1.1.1.

Sorry, but 1.1.1 is just too old  as  reference  for  any  new  work.
Please  update  your  source  base  and  resubmit. Please pay special
attention to the fact that CONFIG_INIT_CRITICAL has been depracted!

Also, it seems that this board support  references  a  CPU  directory
which is missing and has not been submitted yet.

Finally, please  include  the  required  entries  to  the  CHANGELOG,
CREDITS and MAINTAINERS files.

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
"All God's children are not beautiful. Most of God's children are, in
fact, barely presentable."                            - Fran Lebowitz

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

[Greg Ungerer]

Hi All,

Revised patch against CVS source, adds support for the OpenGear
CM4008 board (based on support for the ks8695 CPU).

Regards
Greg

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot.cm4008.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050520/2d69464e/attachment.txt 

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

[Wolfgang Denk]

In message <428CA2EE.2090405@moreton.com.au> you wrote:
>
> Revised patch against CVS source, adds support for the OpenGear
> CM4008 board (based on support for the ks8695 CPU).

Added, thanks.

Please don't add trailing white space
(board/cm4008/cm4008.c).

Note that your code references a non-existing U-Boot command "gofsk"!

Note that there are compiler warnings generated from your code:

ks8695eth.c: In function `eth_send':
ks8695eth.c:217: warning: passing arg 2 of `memcpy' discards qualifiers from pointer target type
ks8695eth.c:220: warning: passing arg 1 of `memset' makes pointer from integer without a cast


Please submit a (new, incremental) patch for this one!

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's no future in time travel.

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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> Note that there are compiler warnings generated from your code:
> 
> ks8695eth.c: In function `eth_send':
> ks8695eth.c:217: warning: passing arg 2 of `memcpy' discards qualifiers from pointer target type
> ks8695eth.c:220: warning: passing arg 1 of `memset' makes pointer from integer without a cast
> 
> 
> Please submit a (new, incremental) patch for this one!

Ok, attached.

Thanks
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot.ks8695eth.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050521/18436d77/attachment.txt 

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

[Wolfgang Denk]

In message <428DEF7E.9080703@moreton.com.au> you wrote:
>
> > ks8695eth.c:217: warning: passing arg 2 of `memcpy' discards qualifiers from pointer target type
> > ks8695eth.c:220: warning: passing arg 1 of `memset' makes pointer from integer without a cast
> > 
> > 
> > Please submit a (new, incremental) patch for this one!
> 
> Ok, attached.

Applied. But please provide a CHANGELO entry next time!

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
People seldom know what they want until you give them what  they  ask
for.

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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> Note that your code references a non-existing U-Boot command "gofsk"!

Indeed it does :-)

I have a couple of more patches, things a little more contentious
than simple cpu or board add.

The gofsk command is something I added to support loading
snapgear/uClinux-dist style raw filesystem+kernel images.

The image itself is a simple concatenation of a root filesystem
and a kernel. Typically it is used with a CRAMfs root filesystem.
The primary motivator for not having any header on this image is
that it can be dumped directly into an MTD flash partition, and
it can be directly mounted as the root filesystem. For known
filesystem types (like CRAMfs and ROMfs) the loader simply looks
over the filesystem to get to the kernel for boot time starting.

Patch attached is my current implementation of this.

Is this something that you would allow into the main tree?

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot.gofsk.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050521/f678dd7e/attachment.txt 

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

[Wolfgang Denk]

Dear Greg,

in message <428DF0F8.5090404@moreton.com.au> you wrote:
> 
> The gofsk command is something I added to support loading
> snapgear/uClinux-dist style raw filesystem+kernel images.

I don't understand why a separate command is  needed  for  that;  you
need  to store the start address of the image anyway, so you can also
store it's size and use this to compute any other  offset;  or  store
the kernel address, too.

> The image itself is a simple concatenation of a root filesystem
> and a kernel. Typically it is used with a CRAMfs root filesystem.
> The primary motivator for not having any header on this image is
> that it can be dumped directly into an MTD flash partition, and
> it can be directly mounted as the root filesystem. For known

This is normal. We don't have headers for standard filesystem  images
like cramfs, ext2 or jffs2 for exactly this reason.

> filesystem types (like CRAMfs and ROMfs) the loader simply looks
> over the filesystem to get to the kernel for boot time starting.

Why do you need a separate command for this?

> Patch attached is my current implementation of this.
> 
> Is this something that you would allow into the main tree?

No, I don't think so. I don't see what it gives you what  you  cannot
get  with the existing commands and clever usage of a few environment
variables. Also, in general I find it is not a good idea  to  combine
filesystem  and  OS  kernel  into  ane  image.  Usually  you buy more
restrictions than advantages this way. If you feel you  must  do  it,
you  could extend the capabilities of mutli-file images to match your
needs.

But the main question is: what can you do with this setup that cannot
be done with the existing code, too?

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
Proboscis: The rudimentary organ of an elephant which serves  him  in
place of the knife-and-fork that Evolution has as yet denied him. For
purposes of humor it is popularly called a trunk.    - Ambrose Bierce

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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> Dear Greg,
> 
> in message <428DF0F8.5090404@moreton.com.au> you wrote:
> 
>>The gofsk command is something I added to support loading
>>snapgear/uClinux-dist style raw filesystem+kernel images. 
> 
> I don't understand why a separate command is  needed  for  that;  you
> need  to store the start address of the image anyway, so you can also
> store it's size and use this to compute any other  offset;  or  store
> the kernel address, too.

Not quite. The start address is fixed (as in fixed position in flash
normally). Size is completely dependant on the image - so you need
to compute that at run time. You don't want to store the length
independantly.


>>The image itself is a simple concatenation of a root filesystem
>>and a kernel. Typically it is used with a CRAMfs root filesystem.
>>The primary motivator for not having any header on this image is
>>that it can be dumped directly into an MTD flash partition, and
>>it can be directly mounted as the root filesystem. For known
> 
> 
> This is normal. We don't have headers for standard filesystem  images
> like cramfs, ext2 or jffs2 for exactly this reason.

Yes, but that is not the point here. The is a complete system image
with no heads (system being kernel and root filesystem).


>>filesystem types (like CRAMfs and ROMfs) the loader simply looks
>>over the filesystem to get to the kernel for boot time starting.
> 
> Why do you need a separate command for this?

The other possibility seemed to be for a complicated sequence
of commands to extract the size - though I didn't try to actually
do this.

But I still wanted to construct the armtags for boot. I couldn't
see that this was currently possible if not used a strictly tagged
ARM u-boot image.


>>Patch attached is my current implementation of this.
>>
>>Is this something that you would allow into the main tree?
> 
> No, I don't think so. I don't see what it gives you what  you  cannot
> get  with the existing commands and clever usage of a few environment
> variables. Also, in general I find it is not a good idea  to  combine
> filesystem  and  OS  kernel  into  ane  image.

As a general rule I have always found the exact opposite. Although
conveient for debugging I find sepearate kernel and filesystems a
limitation in real field setups. A single flash partition with no
additional layout restrictions is a much more flexible arrangment.
Doesn't limit one or the others size or location.


>  Usually  you buy more
> restrictions than advantages this way. If you feel you  must  do  it,
> you  could extend the capabilities of mutli-file images to match your
> needs.
> 
> But the main question is: what can you do with this setup that cannot
> be done with the existing code, too?

I couldn't see how to load a raw image (no header) and still get the
ARM tags setup for booting. ofcousre this was with 1.1.1 when I 
originally did this. Is it possible now?

Regards
Greg

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

[Wolfgang Denk]

In message <42913295.6080308@moreton.com.au> you wrote:
>
> > I don't understand why a separate command is  needed  for  that;  you
> > need  to store the start address of the image anyway, so you can also
> > store it's size and use this to compute any other  offset;  or  store
> > the kernel address, too.
> 
> Not quite. The start address is fixed (as in fixed position in flash
> normally). Size is completely dependant on the image - so you need
> to compute that at run time. You don't want to store the length
> independantly.

You can "compute" the image size at download time - actually it comes
for free in $filesize.

> Yes, but that is not the point here. The is a complete system image
> with no heads (system being kernel and root filesystem).

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.

> >>filesystem types (like CRAMfs and ROMfs) the loader simply looks
> >>over the filesystem to get to the kernel for boot time starting.
> > 
> > Why do you need a separate command for this?
> 
> The other possibility seemed to be for a complicated sequence
> of commands to extract the size - though I didn't try to actually
> do this.

"tftp ..." followed by using $filesize seems not too  complicated  to
me.

> But I still wanted to construct the armtags for boot. I couldn't
> see that this was currently possible if not used a strictly tagged
> ARM u-boot image.

One more reason to use headers for the kernel image.

> > But the main question is: what can you do with this setup that cannot
> > be done with the existing code, too?
> 
> I couldn't see how to load a raw image (no header) and still get the
> ARM tags setup for booting. ofcousre this was with 1.1.1 when I 
> originally did this. Is it possible now?

You cannot. And I will not tolerate duplication of the standard Linux
boot command code into other "private" commands. Let's keep the  code
clean and implemented only once.

But this was NOT your requirement. You wanted to store a kernel image
in flash immediately following a cramfs (or other file system) image.

The file system image is usually header-less (only exception: ramdisk
images); the kernel image should have proper U-Boot headers so it can
be nooted by the standard bootm command.

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.

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.

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
They weren't that important. They were merely at the top. The  people
who  really  run organizations are usually found several levels down,
where it's still possible to get things done.
                                      - Terry Pratchett, _Small Gods_

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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> In message <42913295.6080308@moreton.com.au> you wrote:
>>>I don't understand why a separate command is  needed  for  that;  you
>>>need  to store the start address of the image anyway, so you can also
>>>store it's size and use this to compute any other  offset;  or  store
>>>the kernel address, too.
>>
>>Not quite. The start address is fixed (as in fixed position in flash
>>normally). Size is completely dependant on the image - so you need
>>to compute that at run time. You don't want to store the length
>>independantly.
> 
> 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
filesystem that is the first part of the combined image. You
need to know that so you can find the the start of the kernel
image (the zImage part) that is after the filesystem.

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.

So single file image is:


   +----------------------------------------+---------------------+
   |       filesystem                       |  kernel             |
   +----------------------------------------+---------------------+
                                            ^
                                            |

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
fixed filesystem) then the size is stored in the the header.

The start offset of the kernel in this file will change whenever you
change the filesystem (normally it is a readonly type, so the only
change is at compile time when you generate it).

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


>>Yes, but that is not the point here. The is a complete system image
>>with no heads (system being kernel and root filesystem).
> 
> 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.


>>>>filesystem types (like CRAMfs and ROMfs) the loader simply looks
>>>>over the filesystem to get to the kernel for boot time starting.
>>>
>>>Why do you need a separate command for this?
>>
>>The other possibility seemed to be for a complicated sequence
>>of commands to extract the size - though I didn't try to actually
>>do this.
> 
> 
> "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.


>>But I still wanted to construct the armtags for boot. I couldn't
>>see that this was currently possible if not used a strictly tagged
>>ARM u-boot image.
> 
> 
> One more reason to use headers for the kernel image.

Well, thats not quite the way I looked at it. I saw it as
a limitation of u-boot, something that it could not do.

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).


>>>But the main question is: what can you do with this setup that cannot
>>>be done with the existing code, too?
>>
>>I couldn't see how to load a raw image (no header) and still get the
>>ARM tags setup for booting. ofcousre this was with 1.1.1 when I 
>>originally did this. Is it possible now?
> 
> 
> You cannot. And I will not tolerate duplication of the standard Linux
> boot command code into other "private" commands. Let's keep the  code
> clean and implemented only once.

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.


> But this was NOT your requirement. You wanted to store a kernel image
> in flash immediately following a cramfs (or other file system) image.

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.

So there is a couple of problems that fall out of this:

1. the image cannot have a header - otherwise it would not be
    directly mountable as a filesystem on an mtd device
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
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

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

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.

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
automating the size calculation here). But with no ARM tags in
memory it is not a correct boot.

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

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


> The file system image is usually header-less (only exception: ramdisk
> images); the kernel image should have proper U-Boot headers so it can
> be nooted by the standard bootm command.
> 
> 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.

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.


> 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?
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
guys have spec'ed to much flash on the board :-)

Regards
Greg

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

[Wolfgang Denk]

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

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

[Greg Ungerer]

Hi Wolfgang,

I guess we have a mismatch here somewhere, lets try and straiten this out.


Wolfgang Denk wrote:
>>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?

Yes, I read it. I don't currently see how it solves the problem.


>>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
> :-)

I geuss I disagree. We see a different problem. I see u-boot doesn't
support an established image format. You see that it does (well I think
that is what you are saying?).

I don't want to neccessarily turn this into a discussion about the
merits of the format. I want this to be a discussion about how to go
about best supporting it.


>>>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.

The size of the header is not important.


>>>"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 :-)

Hmm, ok, you didn't say that earlier. Seems like an awful
kludge to have to load it twice - don't you think?


>>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.

This isn't about reading documentation. And I suspect this method
predates u-boot anyway. When you say standard you really mean
u-boots own methods don't you?  Does any other boot loader support
the same format headers?  (I actually don't know the answer to
this, thus I am genuinely asking the question).


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

Yes, illustrates my point really...
For one, u-boot has no mechanism for generating arm boot tags for
anything other than its own defined kernel format.


> 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.

Certainly. I have no issue with that. Never have.


> 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.

That makes no sense, I want to use u-boot with an existing format.
No point asking years later what would be a good load format.


>>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.

Ok, this is where I guess I don't understand your argument.

How can I take a multi-part image, and in Linux do

     erase /dev/mtd1
     cat imagefile > /dev/mtd1
     mount /dev/mtdblock1 /mnt

If there is any header then that is not directly mountable as
a filesystem.

You would need additional tool support to do this, and this
either goes in Linux or u-boot.


[snip a lot of stuff that all goes back to the above question]
>>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.

Sorry, just don't agree. Unadept design. It works very well
for its intended purpose. Just not with u-boot as it is.

Regards
Greg

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

[Wolfgang Denk]

Dear Greg,

in message <429300A9.9050202@moreton.com.au> you wrote:
> 
> > I understand this problem., It results from an unadept choice of your
> > image layout - put the kernel first, and the problems  just  go  away
> > :-)
> 
> I geuss I disagree. We see a different problem. I see u-boot doesn't
> support an established image format. You see that it does (well I think
> that is what you are saying?).

Please don't call your proprietary  solution  an  "established  image
format".  It  is  not, and never has been, at least not in the U-Boot
context. U-Boot uses multifile images  for  such  a  purpose.  Please
don't blame me if you ignored the existing solutions and came up with
somthing different which causes problems (no working boot support).

> I don't want to neccessarily turn this into a discussion about the
> merits of the format. I want this to be a discussion about how to go
> about best supporting it.

Me too.

> The size of the header is not important.

OK. Then what exactly prevents you from using a multifile image  with
header?

> > 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 :-)
> 
> Hmm, ok, you didn't say that earlier. Seems like an awful
> kludge to have to load it twice - don't you think?

I don't load anything twice - I load two separate  images:  one  with
the  kernel,  and one with the file system. I always found this to be
much more flexible as you can change one component while leaving  the
other  in place - this is MUCH easier to debug as you change one part
of the system only, while keeping all the rest of the  system  (which
is probably known to be working) unchanged.

I understand that you don't want to have separate images. OK, this is
your decision. In this case U-Boot uses multifile images.

> This isn't about reading documentation. And I suspect this method
> predates u-boot anyway. When you say standard you really mean
> u-boots own methods don't you?  Does any other boot loader support

U-Boot, ARMBoot, PPCBoot, Linux in general. Just  emember  how  Linux
wraps  a  kernel image and an initial ramdisk image into one loadable
file.

> the same format headers?  (I actually don't know the answer to
> this, thus I am genuinely asking the question).

Not with exactly the  same  header  format.  But  the  idea  was  not
completely new when I implemented it.

> For one, u-boot has no mechanism for generating arm boot tags for
> anything other than its own defined kernel format.

Right. This is intentional.

My intention my be wrong, or too limited, in which  case  I  will  be
happy  to  discuss  beter solutions. But for your application I don't
see the need to change anything.

> > 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.
> 
> That makes no sense, I want to use u-boot with an existing format.

What exactly is your problem with using a different format  which  is
supported by U-Boot?

> How can I take a multi-part image, and in Linux do
> 
>      erase /dev/mtd1
>      cat imagefile > /dev/mtd1
>      mount /dev/mtdblock1 /mnt
> 
> If there is any header then that is not directly mountable as
> a filesystem.

Create _THREE_ partitions in flash: one representing  the  area  used
for  the Linux kernel (plus image headers), a second one for the root
file system, and a third one which covers both areas. 

For example:

	Partition	Offset	Size	Usage
	/dev/mtd0	   0	 256 kB	U-Boot
	/dev/mtd1	 256 kB	 768 kB	Linux Kernel (with header(s))
	/dev/mtd2	1024 kB 3072 kB Root Filesystem
	/dev/mtd3	 256 kB 3840 kB Combined Image

Then run:

	erase /dev/mtd3
	cat imagefile >/dev/mtd3
	mount /dev/mtd2 /mnt


> You would need additional tool support to do this, and this
> either goes in Linux or u-boot.

No. I don't need any new tools.

> Sorry, just don't agree. Unadept design. It works very well
> for its intended purpose. Just not with u-boot as it is.

It does not work with U-Boot  because  it  does  not  adhere  to  the
U-Boot's  design  principles.  One  needs  to  be changed. I would be
unwise to try to support the plethora of proprietary image formats in
U-Boot. Instead, we try to provide interfaces that allow to  get  (at
least)  the same functionality. You can use these features, or ignore
them.


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
A supercomputer is a machine that runs an endless loop in 2 seconds.

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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> in message <429300A9.9050202@moreton.com.au> you wrote:
>>>I understand this problem., It results from an unadept choice of your
>>>image layout - put the kernel first, and the problems  just  go  away
>>>:-)
>>
>>I geuss I disagree. We see a different problem. I see u-boot doesn't
>>support an established image format. You see that it does (well I think
>>that is what you are saying?).
> 
> 
> Please don't call your proprietary  solution  an  "established  image
> format".  

When I say established I mean that it is in current use, this isn't
a new format just created recently. And it is hardly proprietary, it
is freely available to use - it is just a concatentation of 2 files
how can you possibly make that proprietary.

And it is not my solution, I am just trying to work with it.


>It  is  not, and never has been, at least not in the U-Boot
> context. 

Well, yes, otherwise we wouldn't be having this discussion.


>U-Boot uses multifile images  for  such  a  purpose.  Please
> don't blame me if you ignored the existing solutions and came up with
> somthing different which causes problems (no working boot support).

This makes no sense, nobody ignored an exitsing u-boot solution,
it did not exist yet!


>>>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 :-)
>>
>>Hmm, ok, you didn't say that earlier. Seems like an awful
>>kludge to have to load it twice - don't you think?
> 
> 
> I don't load anything twice - I load two separate  images:  one  with
> the  kernel,  and one with the file system. I always found this to be
> much more flexible as you can change one component while leaving  the
> other  in place - this is MUCH easier to debug as you change one part
> of the system only, while keeping all the rest of the  system  (which
> is probably known to be working) unchanged.

It can be somewhat useful for debug. But the majority of use for
real products in my experience it is not.


>>This isn't about reading documentation. And I suspect this method
>>predates u-boot anyway. When you say standard you really mean
>>u-boots own methods don't you?  Does any other boot loader support
> 
> 
> U-Boot, ARMBoot, PPCBoot, Linux in general. Just  emember  how  Linux
> wraps  a  kernel image and an initial ramdisk image into one loadable
> file.

I don't understand this. This has nothing to do with init ramdisk on
Linux. The Linux ramdisk setup doesn't at all care how the ramdisk
data got in memory (or flash). That is why there is TAGs and
command line options - so the kernel can tell where it is without
being tied to any boot loader machanism.

The header (or no header) is completely specific to u-boot/armboot/
ppcboot.


>>the same format headers?  (I actually don't know the answer to
>>this, thus I am genuinely asking the question).
> 
> Not with exactly the  same  header  format.  But  the  idea  was  not
> completely new when I implemented it.
> 
> 
>>For one, u-boot has no mechanism for generating arm boot tags for
>>anything other than its own defined kernel format.
> 
> 
> Right. This is intentional.
> 
> My intention my be wrong, or too limited, in which  case  I  will  be
> happy  to  discuss  beter solutions.

Isn't that what we are doing?


> But for your application I don't
> see the need to change anything.

I still don't see a solution to using this existing format. You have
argued it is a bad format, you have argued if you re-organize it
it could be made to work. That doesn't make u-boot work with this
simple existing format as it is.

Changing the format opens lots of options for layout, but that
is not what this discussion is about. Lets start another thread if
anyone wants to talk about that.


>>>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.
>>
>>That makes no sense, I want to use u-boot with an existing format.
> 
> 
> What exactly is your problem with using a different format  which  is
> supported by U-Boot?

U-boot is not the only loader that is used, will be used, or has
been used on this hardware in the past. Existing devices that rely
on the old format (for their tftp loading of images) won't have their
boot loaders changed. So changing to a different format is not
really an option here.


>>How can I take a multi-part image, and in Linux do
>>
>>     erase /dev/mtd1
>>     cat imagefile > /dev/mtd1
>>     mount /dev/mtdblock1 /mnt
>>
>>If there is any header then that is not directly mountable as
>>a filesystem.
> 
> 
> Create _THREE_ partitions in flash: one representing  the  area  used
> for  the Linux kernel (plus image headers), a second one for the root
> file system, and a third one which covers both areas. 
> 
> For example:
> 
> 	Partition	Offset	Size	Usage
> 	/dev/mtd0	   0	 256 kB	U-Boot
> 	/dev/mtd1	 256 kB	 768 kB	Linux Kernel (with header(s))
> 	/dev/mtd2	1024 kB 3072 kB Root Filesystem
> 	/dev/mtd3	 256 kB 3840 kB Combined Image

You have changed the format now, so that is not a solution to
the problem.

(The reason I would hesitate to use this is that you have now
set an arbitrary limit on the kernel size, and you are potentially
wasting up to 256k of flash in this example. Ofcourse you could
come up with a clever mtd map that let you have any size kernel, but
you are still wasting some flash).


>>Sorry, just don't agree. Unadept design. It works very well
>>for its intended purpose. Just not with u-boot as it is.
> 
> 
> It does not work with U-Boot  because  it  does  not  adhere  to  the
> U-Boot's  design  principles.  One  needs  to  be changed. I would be
> unwise to try to support the plethora of proprietary image formats in
> U-Boot. Instead, we try to provide interfaces that allow to  get  (at
> least)  the same functionality. You can use these features, or ignore
> them.

None of this discussion has been about changing the way u-boot works,
or what are the ways it has defined as being good image file formats.
It is merely about some mechanism to support an additional format -
that is all.

It doesn't at all bother me if you don't want this in the main
u-boot source - it never has. I can and will quite happily carry
it along in the versions of u-boot that are built for the hardware
that I put it on that needs it. That is the great thing about
the GPL.

I am simply make these changes available to the community, and if
they are useful to others, then great. Otherwise it just doesn't matter.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

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

[Wolfgang Denk]

In message <42932848.7010704@moreton.com.au> you wrote:
> 
> >U-Boot uses multifile images  for  such  a  purpose.  Please
> > don't blame me if you ignored the existing solutions and came up with
> > somthing different which causes problems (no working boot support).
> 
> This makes no sense, nobody ignored an exitsing u-boot solution,
> it did not exist yet!

Multifile images were added (to PPCBoot) in October 2000.


> > I don't load anything twice - I load two separate  images:  one  with
> > the  kernel,  and one with the file system. I always found this to be
> > much more flexible as you can change one component while leaving  the
...
> It can be somewhat useful for debug. But the majority of use for
> real products in my experience it is not.

You're just working in a different area of the market.

> I don't understand this. This has nothing to do with init ramdisk on
> Linux. The Linux ramdisk setup doesn't at all care how the ramdisk

Did you check what happens when you run  "make  zImage.initrd"  in  a
PowerPC Linux tree? Yes, this has a lot to do with these things. 

> The header (or no header) is completely specific to u-boot/armboot/
> ppcboot.

As mentioned before the U-Boot header is just one way. If you  prefer
to  have  sections  in  an  ELF  file  please look around - there are
several examples that use such a technology.

Please try to get a bit a wider view on this topic than just from the
point of view of your product and just ARM systems.

> > But for your application I don't
> > see the need to change anything.
> 
> I still don't see a solution to using this existing format. You have

So let's get this straight:

I will NOT add support for your  private  "existing  format"  because
with  the  same  right  support for a zilion of other private formats
would have to be added, too.

I will not discuss this  decision  unless  (1)  you  prove  that  the
existing  code  (i.e.  multifile  images) cannot be used for the same
purpose and (2) it turns out that adapting the multifile support code
creates a bigger mess than adding  support  for  your  private  image
format.

> argued it is a bad format, you have argued if you re-organize it
> it could be made to work. That doesn't make u-boot work with this
> simple existing format as it is.

No. But it solves your problem.

> Changing the format opens lots of options for layout, but that
> is not what this discussion is about. Lets start another thread if
> anyone wants to talk about that.

OK. Feel free to start such a new thread  (or  actually  to  continue
this one).

The other part of the discussion is complete. I will reject  code  to
support  your  private  image  format,  even  if  you  submit  it  as
board-specific code.

Sorry for not being clear about this, but this is what  I  wanted  to
tell you right from the beginning.

> U-boot is not the only loader that is used, will be used, or has
> been used on this hardware in the past. Existing devices that rely
> on the old format (for their tftp loading of images) won't have their
> boot loaders changed. So changing to a different format is not
> really an option here.

Then provide two images depending on which boot  loade  ris  used.  I
understand that your bootloader is capable of checking if an image is
valid for this hardware or not?

> You have changed the format now, so that is not a solution to
> the problem.

OK. OK. OK.

You don't want to change your image, I don't want to change U-Boot.

I offered you a compromise (and actually  a  more  powerful  solution
than what you have now), you don't accept it. It's your decision.

> (The reason I would hesitate to use this is that you have now
> set an arbitrary limit on the kernel size, and you are potentially
> wasting up to 256k of flash in this example. Ofcourse you could

Ther eis no such limit. This was an EXAMPLE only. Feel free to adjust
sizes as needed - and oviously limited by sector boundaries  of  your
flash memory. SInce the kernel has the partition map embedded the map
can be adjusted with each new kernel version transparently.

> come up with a clever mtd map that let you have any size kernel, but
> you are still wasting some flash).

Yes, of course we're wasting flash - we have to round up to the  next
sector  boundary  -  but this is exactly the same amount of flash you
lose in your configuratio - in your case it's just "free" (=  unused)
space after the combined image. There is not a single byte difference
(assuming uniform flash sectors).

> It is merely about some mechanism to support an additional format -
> that is all.

And I tell you again that I will not add support  for  any  arbitrary
defined new image format.

> I am simply make these changes available to the community, and if
> they are useful to others, then great. Otherwise it just doesn't matter.

Then we've reached a point. You don't  want  to  change  anything.  I
cannot  allow arbitray code bloat. Anybody looking for a solution for
the problem itself will be able to implement  this  in  the  existing
U-Boot  framework,  without  need for special code or new commands or
boot image formats.

End of this discussion.

Best regards,

Wolfgang Denk

-- 
You can love it, change it, or leave it.    There is NO other option.
But do not complain - it is your own choice...                  -- wd

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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> In message <42932848.7010704@moreton.com.au> you wrote:
> 
>>>U-Boot uses multifile images  for  such  a  purpose.  Please
>>>don't blame me if you ignored the existing solutions and came up with
>>>somthing different which causes problems (no working boot support).
>>
>>This makes no sense, nobody ignored an exitsing u-boot solution,
>>it did not exist yet!
> 
> Multifile images were added (to PPCBoot) in October 2000.

As far as I know the concat format was first used in 1999.


>>I don't understand this. This has nothing to do with init ramdisk on
>>Linux. The Linux ramdisk setup doesn't at all care how the ramdisk
> 
> 
> Did you check what happens when you run  "make  zImage.initrd"  in  a
> PowerPC Linux tree? Yes, this has a lot to do with these things. 
 >
>>The header (or no header) is completely specific to u-boot/armboot/
>>ppcboot.
> 
> 
> As mentioned before the U-Boot header is just one way. If you  prefer
> to  have  sections  in  an  ELF  file  please look around - there are
> several examples that use such a technology.
> 
> Please try to get a bit a wider view on this topic than just from the
> point of view of your product and just ARM systems.

So powerpc does it. I have used on plenty of other architectures
(x86, ARM, SuperH, Sparc, ColdFire, etc) I have never come across
"make zImage.initrd".

I have used ELF sections before, suffers from the similar problems
(and them some extra ones too).


>>>But for your application I don't
>>>see the need to change anything.
>>
>>I still don't see a solution to using this existing format. You have
> 
> 
> So let's get this straight:
> 
> I will NOT add support for your  private  "existing  format"  because
> with  the  same  right  support for a zilion of other private formats
> would have to be added, too.

Please. I have already stated - not my format, and not private.
I could argue that the u-boot multi-file format is provate to
u-boot.


> I will not discuss this  decision  unless  (1)  you  prove  that  the
> existing  code  (i.e.  multifile  images) cannot be used for the same
> purpose and (2) it turns out that adapting the multifile support code
> creates a bigger mess than adding  support  for  your  private  image
> format.
> 
> 
>>argued it is a bad format, you have argued if you re-organize it
>>it could be made to work. That doesn't make u-boot work with this
>>simple existing format as it is.
> 
> 
> No. But it solves your problem.

No it doesn't. Sorry, the whole world is not u-boot.


>>come up with a clever mtd map that let you have any size kernel, but
>>you are still wasting some flash).
> 
> 
> Yes, of course we're wasting flash - we have to round up to the  next
> sector  boundary  -  but this is exactly the same amount of flash you
> lose in your configuratio - in your case it's just "free" (=  unused)
> space after the combined image. There is not a single byte difference
> (assuming uniform flash sectors).

Wrong, there is a difference. You have some wasted space between the
kernel and filesystem. The concat image doesn't. This will make a
difference if you are cramped for flash space.

Example scenario, your layout:

   FLASH SIZE       2MB (64k uniform flash segments)

   u-boot size      85k  -->  128k rounded  -->   2 flash segments
   kernel zImage   722k  -->  768k rounded  -->  12 flash segments
   cramfs size    1180k  --> 1216k rounded  -->  19 flasg semgmets

This does not fit in the 32 flash segments available.

With concat (size = 722k + 1180k = 1902k):

   u-boot size      85k  -->  128k rounded  -->   2 flash segments
   concat size    1902k  --> 1920k rounded  -->  30 flash segments

Fits in 32 flash segments.

Size is NOT the same. These sizes are real u-boot binary, kernel
zImage and CRAMfs filesystem


> Then we've reached a point. You don't  want  to  change  anything.

I am willing to change how this is done in u-boot, but I am not willing
to change the file format. And I sure don't want to be tied to one
header format supported by one boot loader.


>  I
> cannot  allow arbitray code bloat. Anybody looking for a solution for
> the problem itself will be able to implement  this  in  the  existing
> U-Boot  framework,  without  need for special code or new commands or
> boot image formats.
> 
> End of this discussion.

Yes.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com