[U-Boot] Extract data file from U-Boot image
Hi list,
I guess I'm not the first one who ever needed to retrieve data files from multifile images, those create by mkimage tool. However, I could just find scripts to do that (specially an old thread answered by Wolfgang about dd).
I made a patch to allow mkimage to extract files from images, which just works for multi-file image. But, the fact that nobody has ever done this means that this feature is not desired in the tool?
IMHO, it is very convenient to have a C code to do that, specially for embedded systems where scripting is noticeably slower than binary code. Besides it requires 'dd' to extract and another tool to parse file's offsets inside the image.
Comments? -- Guilherme Maciel Ferreira Mobile Brazil: +55 48 9904 3728 e +55 48 9134 4651 Site: http://guilhermemacielferreira.com/ Skype: guilherme.maciel.ferreira
Hi Guilherme,
On Thu, 25 Jul 2013 12:31:46 -0300, Guilherme Maciel Ferreira guilherme.maciel.ferreira@gmail.com wrote:
Hi list,
I guess I'm not the first one who ever needed to retrieve data files from multifile images, those create by mkimage tool. However, I could just find scripts to do that (specially an old thread answered by Wolfgang about dd).
I made a patch to allow mkimage to extract files from images, which just works for multi-file image. But, the fact that nobody has ever done this means that this feature is not desired in the tool?
IMHO, it is very convenient to have a C code to do that, specially for embedded systems where scripting is noticeably slower than binary code. Besides it requires 'dd' to extract and another tool to parse file's offsets inside the image.
Comments?
My comment would be that, while U-Boot images /run/ on embedded systems, people do not necessarily /work on/ these images /from within/ said systems; indeed, work on such images, and more generally, development around U-Boot, is performed on development systems, not on target systems.
Besides, in many cases, the image was actually built from files available -- even from files themselves built just before putting them together within the image.
Apart from very specific cases (tweaking the initrd in an existing image comes to mind), I don't see the point in taking images apart when you can simply build them the way you want.
Amicalement,
Dear Guilherme Maciel Ferreira,
In message CAF=5bWftE3UwPrOH+q+JPm-ag0igmAr_G4s=kLzhSObNhN=YyA@mail.gmail.com you wrote:
I made a patch to allow mkimage to extract files from images, which just works for multi-file image. But, the fact that nobody has ever done this means that this feature is not desired in the tool?
Speaking just for myself: I needed such features only in very rare occasions, where it was way faster to use a one-liner on the command line than to write any actual code.
YMMV...
But I fear that mkimage explodes from creaping featurism, so if you go and implement something like this, please do not add it to kmimage, but rather create a separate, new tool, say "dumpimage" or so.
IMHO, it is very convenient to have a C code to do that, specially for embedded systems where scripting is noticeably slower than binary code. Besides it requires 'dd' to extract and another tool to parse file's offsets inside the image.
Well, when I was doing such things, I never did this on the embedded targets, nor did I ever have to care about performance because I always needed it just once or twice.
Could you please be so kind and feed my curiousity a bit: what exactly are you doing that you need such a feature on the target? I can't think of useful applications at the moment...
Best regards,
Wolfgang Denk
Dear Wolfgang,
2013/7/25 Wolfgang Denk wd@denx.de:
Dear Guilherme Maciel Ferreira,
In message CAF=5bWftE3UwPrOH+q+JPm-ag0igmAr_G4s=kLzhSObNhN=YyA@mail.gmail.com you wrote:
I made a patch to allow mkimage to extract files from images, which just works for multi-file image. But, the fact that nobody has ever done this means that this feature is not desired in the tool?
Speaking just for myself: I needed such features only in very rare occasions, where it was way faster to use a one-liner on the command line than to write any actual code.
YMMV...
But I fear that mkimage explodes from creaping featurism, so if you go and implement something like this, please do not add it to kmimage, but rather create a separate, new tool, say "dumpimage" or so.
How does 'unimage' sound to you? =) Following the example of unsquashfs and unubi?
I mean, if people really consider this tool of some use.
IMHO, it is very convenient to have a C code to do that, specially for embedded systems where scripting is noticeably slower than binary code. Besides it requires 'dd' to extract and another tool to parse file's offsets inside the image.
Well, when I was doing such things, I never did this on the embedded targets, nor did I ever have to care about performance because I always needed it just once or twice.
Could you please be so kind and feed my curiousity a bit: what exactly are you doing that you need such a feature on the target? I can't think of useful applications at the moment...
Well, I'm not allowed to say much, but broadly speaking it's intended for a less intrusive firmware upgrade.
Today, in order to upgrade the firmware, the device receives a Multifile image composed by a new kernel and a new root file system and overwrite both of them. Which requires the device to hang for a moment.
However, now we want a selective upgrade, where we can pick a few directories from within the new root file system without the need to write the whole new file system and kernel.
Best regards,
Dear Guilherme Maciel Ferreira,
In message CAF=5bWcMhBhvvWP1933Xyi9Cpv_t3Y306ceWr6pH+TqwoYpi=g@mail.gmail.com you wrote:
But I fear that mkimage explodes from creaping featurism, so if you go and implement something like this, please do not add it to kmimage, but rather create a separate, new tool, say "dumpimage" or so.
How does 'unimage' sound to you? =) Following the example of unsquashfs and unubi?
I dislike such names; they appear not natural to me. "Make an image" => mkimage or "dump the image content" => dumpimage kind of describe what the command does in a natural language. But "unimage" is a word that I cannot put anywhere.
I mean, if people really consider this tool of some use.
The simple rule is: if something is useful for someone, and does not hurt others, it can get added. Just make sure it's a separate make target so it does not get built automatically for each and every build, but only when you ask for it.
However, now we want a selective upgrade, where we can pick a few directories from within the new root file system without the need to write the whole new file system and kernel.
Hm... Repacking images on the target appears not really an efficient approach to me. Also I wonder how this works - are you talking about ramdisk based root file system images?
Best regards,
Wolfgang Denk
Dear Wolfgang,
2013/7/26 Wolfgang Denk wd@denx.de:
Dear Guilherme Maciel Ferreira,
In message CAF=5bWcMhBhvvWP1933Xyi9Cpv_t3Y306ceWr6pH+TqwoYpi=g@mail.gmail.com you wrote:
But I fear that mkimage explodes from creaping featurism, so if you go and implement something like this, please do not add it to kmimage, but rather create a separate, new tool, say "dumpimage" or so.
How does 'unimage' sound to you? =) Following the example of unsquashfs and unubi?
I dislike such names; they appear not natural to me. "Make an image" => mkimage or "dump the image content" => dumpimage kind of describe what the command does in a natural language. But "unimage" is a word that I cannot put anywhere.
dumpimage... That's fine for me.
I mean, if people really consider this tool of some use.
The simple rule is: if something is useful for someone, and does not hurt others, it can get added. Just make sure it's a separate make target so it does not get built automatically for each and every build, but only when you ask for it.
Ok. Just give me some time to rework the patch.
However, now we want a selective upgrade, where we can pick a few directories from within the new root file system without the need to write the whole new file system and kernel.
Hm... Repacking images on the target appears not really an efficient approach to me. Also I wonder how this works - are you talking about ramdisk based root file system images?
Exactly, a ramdisk root file system image, which is received -- by the device -- inside a Multifile image.
Best regards,
participants (3)
-
Albert ARIBAUD -
Guilherme Maciel Ferreira -
Wolfgang Denk