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

[Greg Ungerer]

Hi Wolfgang,

Wolfgang Denk wrote:
> in message <429300A9.9050202 at 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