jffs2
We are currently working on the jffs2 code in u-boot. We had the problem that sometimes after overwriting the kernel file in the jffs2 filesystem there have been crc errors.
A colleague has tracked the problem down to the length determination code in jffs2_1pass_read_inode. The code (protected by a brown paper bag statement ;) claims that the file end is determined by an identical isize in 2 following flash inodes which seems to be wrong. He has implemented another variant, based on a sorted list, which seems to be better but takes up to 20 seconds for the first scan. This is unacceptably long but more correct...
I don't want to start a longer discussion here as I'm not deeply in the code myself at the moment, but has anybody seen a similar behaviour or better: has a solution?
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 1 line · In message <[email protected]> you wrote:
We are currently working on the jffs2 code in u-boot. We had the problem
...
Quoted 3 lines
I don't want to start a longer discussion here as I'm not deeply in the code myself at the moment, but has anybody seen a similar behaviour or better: has a solution?
You better ask this on the MTD list where the code in question will find many more active developers.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
<wolfgangmode>
I'm subscribed to the mailing list, you don't have to send me copys of the list mails directly
</wolfgangmode>
;-)
Quoted 2 lines · Wolfgang Denk
You better ask this on the MTD list where the code in question will find many more active developers.
Nope, the jffs2 code in u-boot was significantly striped down; look at the code and notice especially all the brown paper bag warnings.
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 6 lines · In message <[email protected]> Robert Schwebel wrote:
Quoted 3 lines
You better ask this on the MTD list where the code in question will find many more active developers.
Nope, the jffs2 code in u-boot was significantly striped down; look at the code and notice especially all the brown paper bag warnings.
Ummm... I don't think I will dig into this. Nevertheless - if the port of the code was done in a way that both prevents help from the MTD list and updating to newer, less buggy versions of the JFFS2 code, then it was done very badly from the beginning, and should be FIXED NOW.
It makes no sense to go on if you know you are heading down a dead-end road.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space.
Quoted 8 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> Robert Schwebel wrote:
Quoted 3 lines
You better ask this on the MTD list where the code in question will find many more active developers.
Nope, the jffs2 code in u-boot was significantly striped down; look at the code and notice especially all the brown paper bag warnings.
Quoted 8 lines
Ummm... I don't think I will dig into this. Nevertheless - if the port of the code was done in a way that both prevents help from the MTD list and updating to newer, less buggy versions of the JFFS2 code, then it was done very badly from the beginning, and should be FIXED NOW.
It makes no sense to go on if you know you are heading down a dead-end road.
As one of the original "porters" of the brown paper bag code in question, I agree.
However, porting the MTD jffs2 code in a way that will usefully fit into u-boot without SERIOUSLY stripping it down is pretty much impossible; I had started down that path but gave up almost immediately.
Hopefully somebody smarter than I can do it.
Quoted 21 lines
Best regards,
Wolfgang Denk
Signature · 15 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Signature · 5 lines
Nye Liu nliu at mrv.com "Who would be stupid enough to quote a fictitious character?" -- Don Quixote
Quoted 4 lines
isize in 2 following flash inodes which seems to be wrong. He has implemented another variant, based on a sorted list, which seems to be better but takes up to 20 seconds for the first scan. This is unacceptably long but more correct...
The jffs2 code in Linux did a scan and therefore took also quite long (e.g. 20 seconds).
I've heard that in the MTD cvs some things have been improved and now it scans faster or in the background or something like that.
What I would: I would make one JFFS2 /boot parition, with little more than the kernel. And one JFFS2 / parition, with the rest. So the bootloader has only to scan for valid blocks in the little partition, but that's probably ok. And Linux now has some improved scanning/heuristics/whatever that scales better to large partitions.
Not sure if that could be a way for you ...
Greetings, Holger
Quoted 3 lines · In message <[email protected]> you wrote:
What I would: I would make one JFFS2 /boot parition, with little more than the kernel. And one JFFS2 / parition, with the rest. So the bootloader has only
If you do so, you are better off by reading / writing the raw flash WITHOUT any JFFS2 overhead.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The idea of male and female are universal constants. -- Kirk, "Metamorphosis", stardate 3219.8
Quoted 2 lines
If you do so, you are better off by reading / writing the raw flash WITHOUT any JFFS2 overhead.
Depends on your circumstances.
I for example want to be able to update my kernel over WLAN using "ipkg update" "ipkg upgrade". Therefore ipkg must be able to access the zImage via a filesystem --- and the bootloader too.
Maybe you could do run post-install script that copy the zImage to a mtd-character device that points to this partition, in this case you can life without JFFS2 support in the bootloader.
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 2 lines
If you do so, you are better off by reading / writing the raw flash WITHOUT any JFFS2 overhead.
Depends on your circumstances.
I for example want to be able to update my kernel over WLAN using "ipkg update" "ipkg upgrade". Therefore ipkg must be able to access the zImage via a filesystem --- and the bootloader too.
Oops? Where is the problem? Isn't /dev/mtd2 a nice filename?
Quoted 3 lines
Maybe you could do run post-install script that copy the zImage to a mtd-character device that points to this partition, in this case you can life without JFFS2 support in the bootloader.
Either of us must be missing something.
If you dedicate a partition to hold the kernel image, you can of course read and write it direktly, both in Linux and in U-Boot. No fancy tricks needed.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The software required `Windows 95 or better', so I installed Linux.
Quoted 2 lines · Holger Schurig
I've heard that in the MTD cvs some things have been improved and now it scans faster or in the background or something like that.
Wasn't that done with kernel threads? Doesn't work in u-boot.
Quoted 5 lines
What I would: I would make one JFFS2 /boot parition, with little more than the kernel. And one JFFS2 / parition, with the rest. So the bootloader has only to scan for valid blocks in the little partition, but that's probably ok. And Linux now has some improved scanning/heuristics/whatever that scales better to large partitions.
The problem is that we want to have only one image which has to be flashed during a software update, to minimize problems.
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 5 lines · Holger Schurig
Quoted 2 lines
I've heard that in the MTD cvs some things have been improved and now it scans faster or in the background or something like that.
Wasn't that done with kernel threads? Doesn't work in u-boot.
Yes and no, JFFS2 will check the remaning nodes in the background. U-boot don't need to do that. You should talk to David to sort out the details.
Jocke
Quoted 3 lines · In message <[email protected]> Robert Schwebel wrote:
The problem is that we want to have only one image which has to be flashed during a software update, to minimize problems.
The problem is that you chose to use the wrong tool for the job. Use a small dedicated flash partition without a file system, and all your trouble is gone.
Best regards,
Wolfgang Denk
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Quotation, n. The act of repeating erroneously the words of another.
The words erroneously repeated.
- Ambrose Bierce _The Devil's Dictionary_Quoted 3 lines · Wolfgang Denk
The problem is that you chose to use the wrong tool for the job. Use a small dedicated flash partition without a file system, and all your trouble is gone.
I'm not sure if you read my mails from the beginning, so to avoid confusion here's the scenario in more detail: updates are possible in two states: normally the user presses a software update button during normal operation (running Linux), the system fetches a new single image (containing file system, rootfs and kernel) and flashs it to a mtd partition. It's no option to split this up into two pieces, so the kernel definitely must sit inside some real file system, which also must be writable during normal Linux operation.
Is there another way to achieve this, without jffs2?
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 2 lines · In message <[email protected]> Robert Schwebel wrote:
I'm not sure if you read my mails from the beginning, so to avoid
I did.
Quoted 7 lines
confusion here's the scenario in more detail: updates are possible in two states: normally the user presses a software update button during normal operation (running Linux), the system fetches a new single image (containing file system, rootfs and kernel) and flashs it to a mtd partition. It's no option to split this up into two pieces, so the kernel definitely must sit inside some real file system, which also must be writable during normal Linux operation.
Why must it be a filesystem?
Quoted 1 line
Is there another way to achieve this, without jffs2?
I already explained several times, and in the DPLG you will find explicit examples. What's wrong with writing the downloaded image to a raw partition like /dev/mtd2 _without_ any filesystem on it?
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de An Elephant is a mouse with an Operating System. - Knuth
Quoted 8 lines · Wolfgang Denk
Quoted 7 lines
confusion here's the scenario in more detail: updates are possible in two states: normally the user presses a software update button during normal operation (running Linux), the system fetches a new single image (containing file system, rootfs and kernel) and flashs it to a mtd partition. It's no option to split this up into two pieces, so the kernel definitely must sit inside some real file system, which also must be writable during normal Linux operation.
Quoted 7 lines
Why must it be a filesystem?
Quoted 1 line
Is there another way to achieve this, without jffs2?
I already explained several times, and in the DPLG you will find explicit examples. What's wrong with writing the downloaded image to a raw partition like
/dev/mtd2_without_ any filesystem on it?
I have the impression that we don't really understand each other :-)
You download an image, containing a kernel, a root fs which must be writable without having all this in a filesystem? How do you do this? I mean, it's clear that you simply download one _image_ file of the fs which you write to /dev/mtd/*, but what's _inside_ the image? For a raw kernel without rootfs it's clear that you can write it to a partition and be ready. But with rootfs? Being writable? Please excuse me, but I seem to be too stupid to understand your.
And what is DPLG?
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 2 lines · In message <[email protected]> you wrote:
I have the impression that we don't really understand each other :-)
Maybe I should give up and let you stay frustrated about JFFS2 ;-)
Quoted 2 lines
You download an image, containing a kernel, a root fs which must be writable without having all this in a filesystem? How do you do this? I
I don't do it this way. Usually I split filesystem and kernel, as this gives both more flexibility and easier to handle image sizes.
I then write the kernel image to one raw partititon, and the filesystem image to another raw partition.
Quoted 2 lines
mean, it's clear that you simply download one _image_ file of the fs which you write to
/dev/mtd/*, but what's _inside_ the image? For a raw
What is in it? I guess, what you put in? Sorr, I don't understand your problem.
Quoted 3 lines
kernel without rootfs it's clear that you can write it to a partition and be ready. But with rootfs? Being writable? Please excuse me, but I seem to be too stupid to understand your.
It is IMHO a bad idea to have the root filesystem writable in the first place. Usually it means that you don't understand (probably never bothered about it) what's going on in your filesystem. You may end up easily with a system that fails in the field after just a couple of weeks / months because of unintended and unknown write operations.
I always propose a design with a read-only root filesystem, which
contains all the "constant" data like libraries, tools, and
applications, and only a small writable flash filesystem (if any, often it makes no sense at all) for things like configuration data.
But here it goes: if you do it this way - what do you need JFFS2 for? For logfiles? Bad choice. For config data? You can probably use the U-Boot envrionment sectors as well - now that we have implemented redundancy this is a pretty safe method for anything that can be represented as (short) string.
Quoted 1 line
And what is DPLG?
You do read this list, don't you?
See http://www.denx.de/re/DPLG.html
Best regards,
Wolfgang Denk
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Quoted 2 lines · Wolfgang Denk
I don't do it this way. Usually I split filesystem and kernel, as this gives both more flexibility and easier to handle image sizes.
Hmm, but you have to agree with yourself on a maximum kernel partition size first. How do you handle this? Are you sure that even if 2.6 is out there will be enough space?
Quoted 6 lines
It is IMHO a bad idea to have the root filesystem writable in the first place. Usually it means that you don't understand (probably never bothered about it) what's going on in your filesystem. You may end up easily with a system that fails in the field after just a couple of weeks / months because of unintended and unknown write operations.
You may have guessed it - the rootfs is indeed mounted r/o on our system, due to the reason you mentioned. But I in general would like to be able to mount it r/w in case of maintainance or during development. So jffs2 would surely comes close to what I would like to see.
Quoted 4 lines
I always propose a design with a read-only root filesystem, which
contains all the "constant" data like libraries, tools, and
applications, and only a small writable flash filesystem (if any, often it makes no sense at all) for things like configuration data.
That's how it is designed.
Quoted 5 lines
But here it goes: if you do it this way - what do you need JFFS2 for? For logfiles? Bad choice. For config data? You can probably use the U-Boot envrionment sectors as well - now that we have implemented redundancy this is a pretty safe method for anything that can be represented as (short) string.
Well, just to shock you: we have a SQL database which holds our config data :-) But it has it's own jffs2 data partition.
Quoted 3 lines
Quoted 1 line
And what is DPLG?
You do read this list, don't you?
Yes, but I don't print out the archive each and every day and put it under my pillow ;-)
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 4 lines · In message <[email protected]> you wrote:
Hmm, but you have to agree with yourself on a maximum kernel partition size first. How do you handle this? Are you sure that even if 2.6 is out there will be enough space?
I handle it by allowing for partition sizes to change over time.
Quoted 4 lines
You may have guessed it - the rootfs is indeed mounted r/o on our system, due to the reason you mentioned. But I in general would like to be able to mount it r/w in case of maintainance or during development. So jffs2 would surely comes close to what I would like to see.
For a R/O filesystem cramfs or squashfs seem to be much faster.
Quoted 2 lines
Well, just to shock you: we have a SQL database which holds our config data :-) But it has it's own jffs2 data partition.
Great. Which one?
Quoted 2 lines
Yes, but I don't print out the archive each and every day and put it under my pillow ;-)
grep?
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Landing: a controlled mid-air collision with a planet.
Quoted 1 line · Wolfgang Denk
I handle it by allowing for partition sizes to change over time.
Ok, but you still have to change the image _and_ the environment. The jffs2 solution sounds better to me, but that's surely a matter of taste.
Quoted 4 lines
Quoted 2 lines
Well, just to shock you: we have a SQL database which holds our config data :-) But it has it's own jffs2 data partition.
Great. Which one?
SQLite based, integrated into the application.
Quoted 4 lines
Quoted 2 lines
Yes, but I don't print out the archive each and every day and put it under my pillow ;-)
grep?
No, I also don't have the manual of grep under my pillow =8-)
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 3 lines · In message <[email protected]> Robert Schwebel wrote:
Ok, but you still have to change the image _and_ the environment. The jffs2 solution sounds better to me, but that's surely a matter of taste.
Don't you have to change the image and the filename, too?
Quoted 3 lines
Quoted 1 line
grep?
No, I also don't have the manual of grep under my pillow =8-)
You should learn the use of basic Unix toolsm, then ;-)
Wolfgang Denk
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de "Where humor is concerned there are no standards -- no one can say what is good or bad, although you can be sure that everyone will. - John Kenneth Galbraith
Quoted 11 lines
Quoted 6 lines
It is IMHO a bad idea to have the root filesystem writable in the first place. Usually it means that you don't understand (probably never bothered about it) what's going on in your filesystem. You may end up easily with a system that fails in the field after just a couple of weeks / months because of unintended and unknown write operations.
You may have guessed it - the rootfs is indeed mounted r/o on our system, due to the reason you mentioned. But I in general would like to be able to mount it r/w in case of maintainance or during development. So jffs2 would surely comes close to what I would like to see.
You can have jffs2 as rw root fs and still feel safe. JFFS2 can handle sudden power loss w.r.t JFFS2 meta data. But don't expect that a file that you are writing to will be "unharmed" at a sudden power loss. Do your writing in a tmp file and when you are done, rename() it. Works well here.
Jocke
Quoted 3 lines
I already explained several times, and in the DPLG you will find explicit examples. What's wrong with writing the downloaded image to a raw partition like
/dev/mtd2_without_ any filesystem on it?
Could you have overlapping sectors, for example:
partition 0 from sect 0 to 0 for u-boot
partition 1 from sect 1 to 3 for zImage
partition 2 from sect 4 to 63 for rootfs
partition 3 from sect 64 to 255 for fs
partition 4 from sect 1 to 255 for re-flashing Linux, rootfs and fs in one go
Quoted 2 lines · In message <[email protected]> you wrote:
Could you have overlapping sectors, for example:
Yes, of course.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de 1000 pains = 1 Megahertz
Quoted 3 lines
normal operation (running Linux), the system fetches a new single image (containing file system, rootfs and kernel) and flashs it to a mtd partition.
I assume you still know that your system could be interrupted after, say, flashing the first 27 flash blocks?
So, a single image won't give you consistence in all circumstances.
Oh, by the way: you could stay with single image and flash various partitions even without overlapping partition hacks, simple cut the single image into peaces. Your programm could do the equivalent of:
dd if=image of=/dev/mtd1 bs=x count=x skip=0
dd if=image of=/dev/mtd2 bs=x count=y skip=x
dd if=image of=/dev/mtd3 bs=x count=z skip=x+y
Signature · 5 lines
MN-Logistik GmbH http://www.mn-logistik.de Holger Schurig Dieselstr. 18 61191 Rosbach v.d.H?he Tel: 06003/9141-0 Fax: 06003/9141-49
Quoted 4 lines · Holger Schurig
I assume you still know that your system could be interrupted after, say, flashing the first 27 flash blocks?
So, a single image won't give you consistence in all circumstances.
Yes, that's why I have two identical partitions. When flashing goes wrong you can press a button during reset and u-boot boots the old image.
Quoted 7 lines
Oh, by the way: you could stay with single image and flash various partitions even without overlapping partition hacks, simple cut the single image into peaces. Your programm could do the equivalent of:
dd if=image of=/dev/mtd1 bs=x count=x skip=0
dd if=image of=/dev/mtd2 bs=x count=y skip=x
dd if=image of=/dev/mtd3 bs=x count=z skip=x+y
That's an idea; but you have the problem that you have to make the sizes of the partitions fixed in the firmware. When linux-2.6 is out and the minimum compressed kernel size is over 2 MB ;) you will be lost. With Linux sitting in a file system it has more space to grow into...
Robert
Signature · 5 lines
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Braunschweiger Str. 79, 31134 Hildesheim, Germany
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4Quoted 3 lines · In message <[email protected]> you wrote:
That's an idea; but you have the problem that you have to make the sizes of the partitions fixed in the firmware. When linux-2.6 is out and the
If you pass the flash partition sizes to the Linux kernel via the boot arguments (or bi_recs one day) you can adjust as needed in U-Boot or Linux as you like (assuming you can access the U-Boot environment from Linux, too).
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed.
Quoted 6 lines · In message <[email protected]> you wrote:
I assume you still know that your system could be interrupted after, say,
flashing the first 27 flash blocks?
So, a single image won't give you consistence in all circumstances.
Right. For secure updates you will need two alternate images, and a mechanism for automatic fall back to the old version (typically triggered by a watchdog to recover from a hard hang).
Note that this is _far_ more reliable that replacing files one by one in a life filesystem. Just imagine what happens when your update of libc has some problem...
Quoted 5 lines
Oh, by the way: you could stay with single image and flash various partit ions
even without overlapping partition hacks, simple cut the single image int o
peaces. Your programm could do the equivalent of:
I think you got it :-)
Best regards,
Wolfgang Denk
Signature · 5 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
PoB = "Prisoner of Bill" -- those held captive, unwillingly or other-
wise, by the contemptible Microsoft monopoly.
-- Tom Christiansen in <[email protected]>