-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Thursday, July 16, 2009 4:55 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support)
Dear Prafulla Wadaskar,
In message <73173D32E9439E4ABB5151606C3E19E202DDF26EFD@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_88F618...
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-
- mkimage can be reused for kwimage generation.
Sounds good to me.
- 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
- 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@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.''