[U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support)

[Prafulla Wadaskar]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de] 
> Sent: Thursday, July 16, 2009 4:55 PM
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] [PATCH][repost] mkimage support ( 
> bin_dep.sh Support)
> 
> Dear Prafulla Wadaskar,
> 
> In message 
> <73173D32E9439E4ABB5151606C3E19E202DDF26EFD at SC-VEXCH1.marvell.
> com> you wrote:
> > 
> > > > The code really needs to be rewritten in a clean fashion  using 
> > > > common programming metaphors, style and library functions (i.e. 
> > > > use getopt(3), etc.).
> >
> > During restructuring activity for this utility, I found 
> that most of 
> > the code and algorithm is common between mkimage and 
> kwimage (old name doimage).
> 
> I'm not really surprised.
> 
> > I have studied mkimage code.
> > kwimage requirements can be well supported by adding one 
> more type support to the mkimage (i.e. "bootrom").
> 
> "bootrom" is a way to generic name. You have a specific data 
> format in mind, so please use a more specific name.

Kirkwood Specs call it as "boot image" which is a post processed binary bundled with BootRom header and optional header extension so that Kirkwood's internal bootRom loads it from specific media to DRAM and starts execution.
Ref: (Section 24.2.4) http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf

So I will name this as "kwbimage" and target will be u-boot.kwb

Further boot image could be different for "boot from SF/NANDF/UART/SATA" etc...
This information will be abstracted form board specific config.mk.

> 
> > The bootrom image file generation generic abstraction can 
> be provided with new file ./common/bootrom.c internally 
> supported by Arch specific macros/code.
> 
> Hm... I guess this would make it even more complicated to 
> separate the mkimage tool from the rest of the U-Boot code. 
> There have been repeated requests to make it more independent 
> or even integrate in into the Linux kernel code tree. We 
> should keep this in mind.
So I will limit my self not to disturb current mkimage architecture.
I will add additional kwbimage type support the related code will be abstracted to ./tools/kwbimage.c
 
> 
> Note that this is not an argument against your proposal - 
> just a note that we should keep this aspect in mind when 
> implementing and reviewing the new code.
Thanks...If this find useful for others we can think of expanding it latter.
For ex. Type = <SOC>bimage and abstraction in <SOC>bimage.c/h

> 
> > With this-
> > 1. mkimage can be reused for kwimage generation.
> 
> Sounds good to me.
> 
> > 2. Kwimage generation can be supported in a generic way under 
> > "bootrom" image type
> 
> This doesn't sound such a  good  idea  to  me.  As  mentioned 
>  above, "bootrom"  is  a very generic name which can be 
> anything - but if you assign this name to a specific format, 
> it  should  be  exactly  _one_ speific format.
Cool. In sync... Type renamed "kwbimage", abstraction in ./tools/kwbimage.c/h
 
> 
> > 3. In future the same interface can be used by other 
> Marvell and non Marvell socs for similar kind of requirements.
> >
> > Shall I go ahead with this approach?
> > or I should not disturb mkimage at all?
> > What is your opinion?
> 
> I think this is a pretty good plan. Please go ahead.
Thanks a lot.... :-D

Regards..
Prafulla . .

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: 
> wd at denx.de After a heated argument on some trivial matter 
> Nancy [Astor]  .  .  .
> shouted,  ``If  I were your wife I would put poison in your coffee!''
> Whereupon Winston Churchill with equal heat and  sincerity  
> answered, ``And if I were your husband I would drink it.''
>