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

Wolfgang Denk wd at denx.de
Tue May 24 13:15:07 CEST 2005


Dear Greg,

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




More information about the U-Boot mailing list