Upgrading cramfs root file system

Upgrading cramfs root file system

[Antonio Di Bacco]

Hi,

how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that receives 
the new rootfs from a web interface and then tries to write it in the flash. 
While overwriting the old cramfs, the CGI will continue to work? something 
weird could happen?

Best regards,
Antonio.

Re: Upgrading cramfs root file system

[Wojciech Kromer]

Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
> Hi,
>
> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that receives 
> the new rootfs from a web interface and then tries to write it in the flash. 
> While overwriting the old cramfs, the CGI will continue to work? something 
> weird could happen?
>   

Generally it's not a good idea to override working filesystem ( I've 
tried to do it once).

You can have two separate copies of filesystem, one to work with, and 
another to overwrite, it requires more flash.
Another way is working in initrd, it requires more RAM.
You can also use jffs2 or jffs3 (experimental) to have read-write 
filesystem, and change applications only, not whole filesystem (be 
carefull with changing busybox or libraries!)

Re: Upgrading cramfs root file system

[Antonio Di Bacco]

Yes you are right, it is not a good idea to overwrite working cramfs=20
filesystem. But what happens if I download the new cramfs plus kernel in RA=
M,=20
do a checksum and then, completely in kernel mode, disabling all the=20
interrupts, I write to flash? No process could complain that I am overwriti=
ng=20
because no one is executing.

Bye,
Antonio.

On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> Dnia 2006-04-06 22:38, U=C5=BCytkownik Antonio Di Bacco napisa=C5=82:
> > Hi,
> >
> > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
> > receives the new rootfs from a web interface and then tries to write it
> > in the flash. While overwriting the old cramfs, the CGI will continue to
> > work? something weird could happen?
>
> Generally it's not a good idea to override working filesystem ( I've
> tried to do it once).
>
> You can have two separate copies of filesystem, one to work with, and
> another to overwrite, it requires more flash.
> Another way is working in initrd, it requires more RAM.
> You can also use jffs2 or jffs3 (experimental) to have read-write
> filesystem, and change applications only, not whole filesystem (be
> carefull with changing busybox or libraries!)

Re: Upgrading cramfs root file system

[White]

make it easy: if you start an application which do the flash and after
this a reset.. nothing should happen. I do it that way.
the application resist completly in RAM .. and all important libs are
in RAm or in Filesystem Cache.
It's only important that you pretend any Application from accessing
Datafiles or start of new application ...

Alternativly, you can put it in a reserved RAM Area ( mark it not
usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
after a reset....

But overwrite a cramfs works for me on >100 times without problems.

Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
<antonio.dibacco@aruba.it> :

> Yes you are right, it is not a good idea to overwrite working cramfs 
> filesystem. But what happens if I download the new cramfs plus kernel in RAM, 
> do a checksum and then, completely in kernel mode, disabling all the 
> interrupts, I write to flash? No process could complain that I am overwriting 
> because no one is executing.
> 
> Bye,
> Antonio.
> 
> On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> > Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
> > > Hi,
> > >
> > > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
> > > receives the new rootfs from a web interface and then tries to write it
> > > in the flash. While overwriting the old cramfs, the CGI will continue to
> > > work? something weird could happen?
> >
> > Generally it's not a good idea to override working filesystem ( I've
> > tried to do it once).
> >
> > You can have two separate copies of filesystem, one to work with, and
> > another to overwrite, it requires more flash.
> > Another way is working in initrd, it requires more RAM.
> > You can also use jffs2 or jffs3 (experimental) to have read-write
> > filesystem, and change applications only, not whole filesystem (be
> > carefull with changing busybox or libraries!)
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Antonio Di Bacco]

Yes, I also thought this too. Anything important should stay already in RAM=
=20
but there is a chance that something bad could happen. Probably the best=20
thing is what you suggested as second option but I have not so much ram. My=
=20
CGI writes the downloaded new software in RAM and then I should directly ju=
mp=20
to u-boot without leaving Linux the chance to mix things up and then u-boot=
 =20
should copy the RAM to the flash. It seems a strange procedure but what els=
e=20
could be done with 4MB flash and 16 MB ram?=20

Bye,
Antonio.

On Thursday 20 April 2006 22:18, White wrote:
> make it easy: if you start an application which do the flash and after
> this a reset.. nothing should happen. I do it that way.
> the application resist completly in RAM .. and all important libs are
> in RAm or in Filesystem Cache.
> It's only important that you pretend any Application from accessing
> Datafiles or start of new application ...
>
> Alternativly, you can put it in a reserved RAM Area ( mark it not
> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
> after a reset....
>
> But overwrite a cramfs works for me on >100 times without problems.
>
> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
>
> <antonio.dibacco@aruba.it> :
> > Yes you are right, it is not a good idea to overwrite working cramfs
> > filesystem. But what happens if I download the new cramfs plus kernel in
> > RAM, do a checksum and then, completely in kernel mode, disabling all t=
he
> > interrupts, I write to flash? No process could complain that I am
> > overwriting because no one is executing.
> >
> > Bye,
> > Antonio.
> >
> > On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> > > Dnia 2006-04-06 22:38, U=C5=BCytkownik Antonio Di Bacco napisa=C5=82:
> > > > Hi,
> > > >
> > > > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs th=
at
> > > > receives the new rootfs from a web interface and then tries to write
> > > > it in the flash. While overwriting the old cramfs, the CGI will
> > > > continue to work? something weird could happen?
> > >
> > > Generally it's not a good idea to override working filesystem ( I've
> > > tried to do it once).
> > >
> > > You can have two separate copies of filesystem, one to work with, and
> > > another to overwrite, it requires more flash.
> > > Another way is working in initrd, it requires more RAM.
> > > You can also use jffs2 or jffs3 (experimental) to have read-write
> > > filesystem, and change applications only, not whole filesystem (be
> > > carefull with changing busybox or libraries!)
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Antonio Di Bacco]

How can I mark some RAM unusable by Linux at runtime? I know that it could =
be=20
done before booting but not runtime.

Bye,
Antonio.

On Thursday 20 April 2006 23:03, Antonio Di Bacco wrote:
> Yes, I also thought this too. Anything important should stay already in R=
AM
> but there is a chance that something bad could happen. Probably the best
> thing is what you suggested as second option but I have not so much ram. =
My
> CGI writes the downloaded new software in RAM and then I should directly
> jump to u-boot without leaving Linux the chance to mix things up and then
> u-boot should copy the RAM to the flash. It seems a strange procedure but
> what else could be done with 4MB flash and 16 MB ram?
>
> Bye,
> Antonio.
>
> On Thursday 20 April 2006 22:18, White wrote:
> > make it easy: if you start an application which do the flash and after
> > this a reset.. nothing should happen. I do it that way.
> > the application resist completly in RAM .. and all important libs are
> > in RAm or in Filesystem Cache.
> > It's only important that you pretend any Application from accessing
> > Datafiles or start of new application ...
> >
> > Alternativly, you can put it in a reserved RAM Area ( mark it not
> > usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
> > after a reset....
> >
> > But overwrite a cramfs works for me on >100 times without problems.
> >
> > Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
> >
> > <antonio.dibacco@aruba.it> :
> > > Yes you are right, it is not a good idea to overwrite working cramfs
> > > filesystem. But what happens if I download the new cramfs plus kernel
> > > in RAM, do a checksum and then, completely in kernel mode, disabling
> > > all the interrupts, I write to flash? No process could complain that I
> > > am overwriting because no one is executing.
> > >
> > > Bye,
> > > Antonio.
> > >
> > > On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> > > > Dnia 2006-04-06 22:38, U=C5=BCytkownik Antonio Di Bacco napisa=C5=
=82:
> > > > > Hi,
> > > > >
> > > > > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs
> > > > > that receives the new rootfs from a web interface and then tries =
to
> > > > > write it in the flash. While overwriting the old cramfs, the CGI
> > > > > will continue to work? something weird could happen?
> > > >
> > > > Generally it's not a good idea to override working filesystem ( I've
> > > > tried to do it once).
> > > >
> > > > You can have two separate copies of filesystem, one to work with, a=
nd
> > > > another to overwrite, it requires more flash.
> > > > Another way is working in initrd, it requires more RAM.
> > > > You can also use jffs2 or jffs3 (experimental) to have read-write
> > > > filesystem, and change applications only, not whole filesystem (be
> > > > carefull with changing busybox or libraries!)
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Tolunay Orkun]

If your bootloader is U-Boot and you are using standard bootm command to 
boot, U-Boot decompresses the initrd image to RAM before passing the 
file system to Linux. So, you are not working with flash copy and 
updating the flash copy is not a problem at all. This applies to ext2, 
cramfs or squashfs based initrd.

You can keep working as long as you like until it is time to reboot.

Antonio Di Bacco wrote:
> Yes, I also thought this too. Anything important should stay already in RAM 
> but there is a chance that something bad could happen. Probably the best 
> thing is what you suggested as second option but I have not so much ram. My 
> CGI writes the downloaded new software in RAM and then I should directly jump 
> to u-boot without leaving Linux the chance to mix things up and then u-boot  
> should copy the RAM to the flash. It seems a strange procedure but what else 
> could be done with 4MB flash and 16 MB ram? 
> 
> Bye,
> Antonio.
> 
> On Thursday 20 April 2006 22:18, White wrote:
>> make it easy: if you start an application which do the flash and after
>> this a reset.. nothing should happen. I do it that way.
>> the application resist completly in RAM .. and all important libs are
>> in RAm or in Filesystem Cache.
>> It's only important that you pretend any Application from accessing
>> Datafiles or start of new application ...
>>
>> Alternativly, you can put it in a reserved RAM Area ( mark it not
>> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
>> after a reset....
>>
>> But overwrite a cramfs works for me on >100 times without problems.
>>
>> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
>>
>> <antonio.dibacco@aruba.it> :
>>> Yes you are right, it is not a good idea to overwrite working cramfs
>>> filesystem. But what happens if I download the new cramfs plus kernel in
>>> RAM, do a checksum and then, completely in kernel mode, disabling all the
>>> interrupts, I write to flash? No process could complain that I am
>>> overwriting because no one is executing.
>>>
>>> Bye,
>>> Antonio.
>>>
>>> On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
>>>> Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
>>>>> Hi,
>>>>>
>>>>> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
>>>>> receives the new rootfs from a web interface and then tries to write
>>>>> it in the flash. While overwriting the old cramfs, the CGI will
>>>>> continue to work? something weird could happen?
>>>> Generally it's not a good idea to override working filesystem ( I've
>>>> tried to do it once).
>>>>
>>>> You can have two separate copies of filesystem, one to work with, and
>>>> another to overwrite, it requires more flash.
>>>> Another way is working in initrd, it requires more RAM.
>>>> You can also use jffs2 or jffs3 (experimental) to have read-write
>>>> filesystem, and change applications only, not whole filesystem (be
>>>> carefull with changing busybox or libraries!)
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[antonio.dibacco]

No, I have a cramfs on flash and the kernel uses it directly from flash, 
extracting what it needs to execute. I'm not using initrd then, I have to 
update in situ, while running.

Bye,
Antonio. 

Tolunay Orkun Scrive: 

> If your bootloader is U-Boot and you are using standard bootm command to 
> boot, U-Boot decompresses the initrd image to RAM before passing the file 
> system to Linux. So, you are not working with flash copy and updating the 
> flash copy is not a problem at all. This applies to ext2, cramfs or 
> squashfs based initrd. 
> 
> You can keep working as long as you like until it is time to reboot. 
> 
> Antonio Di Bacco wrote:
>> Yes, I also thought this too. Anything important should stay already in 
>> RAM but there is a chance that something bad could happen. Probably the 
>> best thing is what you suggested as second option but I have not so much 
>> ram. My CGI writes the downloaded new software in RAM and then I should 
>> directly jump to u-boot without leaving Linux the chance to mix things up 
>> and then u-boot  should copy the RAM to the flash. It seems a strange 
>> procedure but what else could be done with 4MB flash and 16 MB ram?  
>> 
>> Bye,
>> Antonio. 
>> 
>> On Thursday 20 April 2006 22:18, White wrote:
>>> make it easy: if you start an application which do the flash and after
>>> this a reset.. nothing should happen. I do it that way.
>>> the application resist completly in RAM .. and all important libs are
>>> in RAm or in Filesystem Cache.
>>> It's only important that you pretend any Application from accessing
>>> Datafiles or start of new application ... 
>>> 
>>> Alternativly, you can put it in a reserved RAM Area ( mark it not
>>> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
>>> after a reset.... 
>>> 
>>> But overwrite a cramfs works for me on >100 times without problems. 
>>> 
>>> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco 
>>> 
>>> <antonio.dibacco@aruba.it> :
>>>> Yes you are right, it is not a good idea to overwrite working cramfs
>>>> filesystem. But what happens if I download the new cramfs plus kernel 
>>>> in
>>>> RAM, do a checksum and then, completely in kernel mode, disabling all 
>>>> the
>>>> interrupts, I write to flash? No process could complain that I am
>>>> overwriting because no one is executing. 
>>>> 
>>>> Bye,
>>>> Antonio. 
>>>> 
>>>> On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
>>>>> Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
>>>>>> Hi, 
>>>>>> 
>>>>>> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
>>>>>> receives the new rootfs from a web interface and then tries to write
>>>>>> it in the flash. While overwriting the old cramfs, the CGI will
>>>>>> continue to work? something weird could happen?
>>>>> Generally it's not a good idea to override working filesystem ( I've
>>>>> tried to do it once). 
>>>>> 
>>>>> You can have two separate copies of filesystem, one to work with, and
>>>>> another to overwrite, it requires more flash.
>>>>> Another way is working in initrd, it requires more RAM.
>>>>> You can also use jffs2 or jffs3 (experimental) to have read-write
>>>>> filesystem, and change applications only, not whole filesystem (be
>>>>> carefull with changing busybox or libraries!)
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
 

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Wolfgang Denk]

In message <20060421055142.11025.qmail@mx1.aruba.it> you wrote:
> No, I have a cramfs on flash and the kernel uses it directly from flash,
> extracting what it needs to execute. I'm not using initrd then, I have to
> update in situ, while running.

This cannot be done reliably. You have to make the file system  idle,
i. e. unmount it.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Change is the essential process of all existence.
	-- Spock, "Let That Be Your Last Battlefield",
	   stardate 5730.2

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Tolunay Orkun]

Wolfgang Denk wrote:
> In message <20060421055142.11025.qmail@mx1.aruba.it> you wrote:
>   
>> No, I have a cramfs on flash and the kernel uses it directly from flash,
>> extracting what it needs to execute. I'm not using initrd then, I have to
>> update in situ, while running.
>>     
>
> This cannot be done reliably. You have to make the file system  idle,
> i. e. unmount it.
>   
I agree, even if you make the executables involved in the update 
statically linked (so library dependencies are removed), kernel can 
choose to reload any running executables page and it would end up with a 
bogus page in memory. This is particularly true if you do not have swap 
which you could try to lock executable in swap. Also, you cannot 
reliably depend on file system cache to contain all the executable code 
you would need to complete update either.

Regards,
Tolunay

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Wolfgang Denk]

In message <44485B3F.8080308@orkun.us> you wrote:
>
> If your bootloader is U-Boot and you are using standard bootm command to 
> boot, U-Boot decompresses the initrd image to RAM before passing the 
> file system to Linux. So, you are not working with flash copy and 
> updating the flash copy is not a problem at all. This applies to ext2, 
> cramfs or squashfs based initrd.

But it makes no sense to use cramfs or squashfs on a ramdisk.
You *want* to run these directly from flash.
But then, of course, you need alternate images (or other tricks)
for full image updates.

[Single file updates can be done using overlay file systems; see  the
DULG for details.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).                   - Bill Joy 6/21/85

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Tolunay Orkun]

Wolfgang Denk wrote:
> In message <44485B3F.8080308@orkun.us> you wrote:
>   
>> If your bootloader is U-Boot and you are using standard bootm command to 
>> boot, U-Boot decompresses the initrd image to RAM before passing the 
>> file system to Linux. So, you are not working with flash copy and 
>> updating the flash copy is not a problem at all. This applies to ext2, 
>> cramfs or squashfs based initrd.
>>     
>
> But it makes no sense to use cramfs or squashfs on a ramdisk.
> You *want* to run these directly from flash.
> But then, of course, you need alternate images (or other tricks)
> for full image updates.
>   
Well, we lose a couple of MB of RAM but squashfs as initrd has been 
reliable, very compact and since the file system is in RAM, it is faster 
and we can tune a bit for smaller cache etc. 

Image updates have been extremely easy as a result, we did not need to 
resort to alternate images and other tricks as a result. If you have 
more flexibility in RAM than in flash, our approach makes sense without 
complicating the matter much. I understand that not everyone might have 
this option.
> [Single file updates can be done using overlay file systems; see  the
> DULG for details.]
I know about the overlay fs. There is also unionfs that works similarly.

Best regards,
Tolunay

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[David Jander]

Hi,

On Thursday 20 April 2006 23:03, Antonio Di Bacco wrote:
> Yes, I also thought this too. Anything important should stay already in RAM
> but there is a chance that something bad could happen. Probably the best

What do you mean with "something bad could happen"?
The only thing I can think of is pulling the power plug while flash is being 
erased or written. What else could go wrong?
We do the following: system running from read-only jffs2 partition. Sometimes 
that partition is remounted read-write and single files are replaced, but in 
some occasions we need to upgrade the whole fs. In that case a CGI lodas the 
image into a ramdisk, and the upgrade process is started. For upgrade, 
'eraseall' and 'dd' (from busybox) are needed. First, all unnecessary 
processes are killed (the webserver stays alive to be able to report the 
status when finished), then "dd" is called for a dummy operation (to have it 
cached). After that the upgrade tool calls "eraseall" on the rootfs 
partition, and then "dd" again to copy the image. At that point no critical 
flash-read access should be requested since dd is already in cache (it's 
busybox, so it's almost always in RAM anyway). When dd is finished, the only 
other thing that's needed is to either be able to send some last html strings 
to the web-server to complete the progress page and tell the user, that it's 
ok to pull the plug, or reset the system, we don't care if the rest of the 
system goes belly-up, since the fs was mounted read-only anyway, and the 
upgrade is finished.

Of course this isn't failsafe, so there should always be a way to recover if 
the rootfs gets trashed, but most of the time it's acceptable that service 
personel is required in that situation. Until now, it has never been required 
though.

> thing is what you suggested as second option but I have not so much ram. My
> CGI writes the downloaded new software in RAM and then I should directly
> jump to u-boot without leaving Linux the chance to mix things up and then
> u-boot should copy the RAM to the flash. It seems a strange procedure but
> what else could be done with 4MB flash and 16 MB ram?

Run from initrd? Maybe an uncomressed filesystem on a ramdisk to be able to do 
XIP (execute in place)?

Greetings,

-- 
David Jander

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Wolfgang Denk]

In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> 
> What do you mean with "something bad could happen"?

System crashes.

> The only thing I can think of is pulling the power plug while flash is being 
> erased or written. What else could go wrong?

The kernel may try to (re-) load some pages of a  running  executable
or  library  which  is  no  longer  available  (at  least  not at the
addresses where they used to be). The kernel will either stumble over
what it believes to be a corrupted file system,  or  load  the  wrong
data -> kaboom.

> We do the following: system running from read-only jffs2 partition. Sometimes 
> that partition is remounted read-write and single files are replaced, but in 
> some occasions we need to upgrade the whole fs. In that case a CGI lodas the 
> image into a ramdisk, and the upgrade process is started. For upgrade, 

You *have* to unmount the old file system here.

> partition, and then "dd" again to copy the image. At that point no critical 
> flash-read access should be requested since dd is already in cache (it's 

The kernel might reload any page of any running executable or library.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Logic and practical information do not seem to apply here."
"You admit that?"
"To deny the facts would be illogical, Doctor"
	-- Spock and McCoy, "A Piece of the Action", stardate unknown

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Antonio Di Bacco]

Little bit off topic:
I decided to adopt a different strategy, the sw download web page will contain 
a java applet that will act as a tftp server, then the board will be rebooted 
and an environment variable will instruct the u-boot to tftp the new software 
from the applet. What do you think? I know that applets cannot read local 
files on the PC, unless they have a valid certificate but the user should 
trust me.

Bye,
Antonio.

On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> > What do you mean with "something bad could happen"?
>
> System crashes.
>
> > The only thing I can think of is pulling the power plug while flash is
> > being erased or written. What else could go wrong?
>
> The kernel may try to (re-) load some pages of a  running  executable
> or  library  which  is  no  longer  available  (at  least  not at the
> addresses where they used to be). The kernel will either stumble over
> what it believes to be a corrupted file system,  or  load  the  wrong
> data -> kaboom.
>
> > We do the following: system running from read-only jffs2 partition.
> > Sometimes that partition is remounted read-write and single files are
> > replaced, but in some occasions we need to upgrade the whole fs. In that
> > case a CGI lodas the image into a ramdisk, and the upgrade process is
> > started. For upgrade,
>
> You *have* to unmount the old file system here.
>
> > partition, and then "dd" again to copy the image. At that point no
> > critical flash-read access should be requested since dd is already in
> > cache (it's
>
> The kernel might reload any page of any running executable or library.
>
> Best regards,
>
> Wolfgang Denk

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Stefan Eletzhofer]

Hi,

Am 21.04.2006 um 23:32 schrieb Antonio Di Bacco:

> Little bit off topic:
> I decided to adopt a different strategy, the sw download web page  
> will contain
> a java applet that will act as a tftp server, then the board will  
> be rebooted
> and an environment variable will instruct the u-boot to tftp the  
> new software
> from the applet. What do you think? I know that applets cannot read  
> local
> files on the PC, unless they have a valid certificate but the user  
> should
> trust me.

nice idea IMHO. Is that applet available somewhere? That would surely  
fit my needs
(and others probably, too).

Cheers,
Stefan.

>
> Bye,
> Antonio.
>
> On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
>> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
>>> What do you mean with "something bad could happen"?
>>
>> System crashes.
>>
>>> The only thing I can think of is pulling the power plug while  
>>> flash is
>>> being erased or written. What else could go wrong?
>>
>> The kernel may try to (re-) load some pages of a  running  executable
>> or  library  which  is  no  longer  available  (at  least  not at the
>> addresses where they used to be). The kernel will either stumble over
>> what it believes to be a corrupted file system,  or  load  the  wrong
>> data -> kaboom.
>>
>>> We do the following: system running from read-only jffs2 partition.
>>> Sometimes that partition is remounted read-write and single files  
>>> are
>>> replaced, but in some occasions we need to upgrade the whole fs.  
>>> In that
>>> case a CGI lodas the image into a ramdisk, and the upgrade  
>>> process is
>>> started. For upgrade,
>>
>> You *have* to unmount the old file system here.
>>
>>> partition, and then "dd" again to copy the image. At that point no
>>> critical flash-read access should be requested since dd is  
>>> already in
>>> cache (it's
>>
>> The kernel might reload any page of any running executable or  
>> library.
>>
>> Best regards,
>>
>> Wolfgang Denk
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)I

[Antonio Di Bacco]

I'm going to develop it if I don't find elsewhere.

Bye.


On Saturday 22 April 2006 13:40, Stefan Eletzhofer wrote:
> Hi,
>
> Am 21.04.2006 um 23:32 schrieb Antonio Di Bacco:
> > Little bit off topic:
> > I decided to adopt a different strategy, the sw download web page
> > will contain
> > a java applet that will act as a tftp server, then the board will
> > be rebooted
> > and an environment variable will instruct the u-boot to tftp the
> > new software
> > from the applet. What do you think? I know that applets cannot read
> > local
> > files on the PC, unless they have a valid certificate but the user
> > should
> > trust me.
>
> nice idea IMHO. Is that applet available somewhere? That would surely
> fit my needs
> (and others probably, too).
>
> Cheers,
> Stefan.
>
> > Bye,
> > Antonio.
> >
> > On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
> >> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> >>> What do you mean with "something bad could happen"?
> >>
> >> System crashes.
> >>
> >>> The only thing I can think of is pulling the power plug while
> >>> flash is
> >>> being erased or written. What else could go wrong?
> >>
> >> The kernel may try to (re-) load some pages of a  running  executable
> >> or  library  which  is  no  longer  available  (at  least  not at the
> >> addresses where they used to be). The kernel will either stumble over
> >> what it believes to be a corrupted file system,  or  load  the  wrong
> >> data -> kaboom.
> >>
> >>> We do the following: system running from read-only jffs2 partition.
> >>> Sometimes that partition is remounted read-write and single files
> >>> are
> >>> replaced, but in some occasions we need to upgrade the whole fs.
> >>> In that
> >>> case a CGI lodas the image into a ramdisk, and the upgrade
> >>> process is
> >>> started. For upgrade,
> >>
> >> You *have* to unmount the old file system here.
> >>
> >>> partition, and then "dd" again to copy the image. At that point no
> >>> critical flash-read access should be requested since dd is
> >>> already in
> >>> cache (it's
> >>
> >> The kernel might reload any page of any running executable or
> >> library.
> >>
> >> Best regards,
> >>
> >> Wolfgang Denk
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Tolunay Orkun]

Antonio Di Bacco wrote:
> Little bit off topic:
> I decided to adopt a different strategy, the sw download web page will contain 
> a java applet that will act as a tftp server, then the board will be rebooted 
> and an environment variable will instruct the u-boot to tftp the new software 
> from the applet. What do you think? I know that applets cannot read local 
> files on the PC, unless they have a valid certificate but the user should 
> trust me.
> 
> Bye,
> Antonio.
> 

If this approach hits a roadblock for some reason (user resistance, 
firewall issues with tftp etc.), think about the following...

During the update you can use a small ram based file system (tempfs) 
holding everything you need, kill all unneeded processes, fill your ram 
based file system. Once this ram file system is filled you will 
pivot_root to it making it new root fs and proceed to update from it. 
Once update is down you can reboot.

I have not done this so it is very likely there are some details that I 
cannot foresee at this very moment.

Best regards,
Tolunay

Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)

[Antonio Di Bacco]

Flashing by myself means that I cannot use the mtd drivers? Then I cannot 
erase the flash as usual but I should reproduce in the application the 
algorithm to erase it, isn't it?

Bye,
Antonio.
P.S: I cannot believe that the author of the best book I've ever read, 
answered my question.

On Thursday 20 April 2006 23:11, Alessandro Rubini wrote:
> > but there is a chance that something bad could happen.
>
> If you mlockall(2) and sched_setscheduler(SCHED_FIFO) you can be
> somewhat confident that nothing bad can happen. However, you should flash
> by yourself (in the application, without resorting to the kernel.
>
> But please remember that Denk is right most of the time.
>
> /alessandro

Re: Upgrading cramfs root file system

[Wojciech Kromer]

Dnia 2006-04-20 22:18, Użytkownik White napisał:
> make it easy: if you start an application which do the flash and after
> this a reset.. nothing should happen. I do it that way.
> the application resist completly in RAM .. and all important libs are
> in RAm or in Filesystem Cache.
> It's only important that you pretend any Application from accessing
> Datafiles or start of new application ...
>
> Alternativly, you can put it in a reserved RAM Area ( mark it not
> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
> after a reset....
>
> But overwrite a cramfs works for me on >100 times without problems.
>
>   

Problems with changing cramfs  and reboot may vary depending on changes 
made to filesystem.
You can't even call reboot, bacause it's not in the prevoius location 
after changing flash.

> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
> <antonio.dibacco@aruba.it> :
>
>   
>> Yes you are right, it is not a good idea to overwrite working cramfs 
>> filesystem. But what happens if I download the new cramfs plus kernel in RAM, 
>> do a checksum and then, completely in kernel mode, disabling all the 
>> interrupts, I write to flash? No process could complain that I am overwriting 
>> because no one is executing.
>>
>>     
Maybe such feature should be added to MTD code.
But disabling interrupts may cause watchdog reset in most embedded 
platforms.