From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marian Balakowicz Date: Wed, 19 Dec 2007 15:07:09 +0100 Subject: [U-Boot-Users] RFC: New U-boot image format In-Reply-To: <4767E487.8020103@freescale.com> References: <475EB857.4080104@semihalf.com> <4767E487.8020103@freescale.com> Message-ID: <4769258D.6090709@semihalf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Timur Tabi wrote: > Marian Balakowicz wrote: >> >> New format for U-boot images has been on the list few times already. >> There were different ideas and features discussed but no final >> conclusion has been made. > > I have a request for a new feature. I think we need image-format > plug-ins. That is, we need a way for a plug-in to register itself with > the main format processing code. When the processing code sees a blob > that it doesn't understand, it calls the plug-in to handle it. The hooks idea sounds reasonable but, the problem is that there isn't really any such thing like "main fromat processing code". The 'bootm' command code does a lot of image related manipulation but it's not generic or main format processing code. It is rather a specialized command that handles one thing, starting executables, like kernels or standalone applications. And it's a command, it will not do anything unless directly called. So, having hooks in bootm, you would need to call bootm and then your 'qe fw' command which is sort of wired. There are also other commands that deal with the images, these are other boot commands like scsiboot, usbboot, etc, and also imls, imxtract. And all of them process images directly, finding necessary information on their own. Your command seem to be of the same type, it needs information from the uImage (soon from the New uImage) and it knows best what it needs. IMHO, reasonable is to make it get this information from New uImage directly. Your current syntax is: > qe fw Extended syntax could be: qe fw 200000:fw_image at 1 Where 200000 is the address of New uImage and "fw_image at 1" is a example node name of your blob data. The New uImage API will allow, in simple way (one, two calls), to get other details for a given image, so you would be able to get the blob data start address. More on the New uImage format soon, stay tuned. > This would be a handy way to handle stuff like the QE firmware binary > blob format (see the thread titled "[PATCH] 85xx: add ability to upload > QE firmware"). The format of the QE firmware blob has already been > decided, so all I would need from the multi-image format is: > > 1) A way to package my blob. > 2) A way to pass the address of the blob to the QE code > > For option #2, setting an environment variable would be the easiest. To > do that, the QE code could register a call-back that says, "If you see a > QE firmware blob, call this function and pass the address of the blob". Cheers, Marian