Re: update OS on custom device

Hi Paul,
thanks a lot for your very clear answer.
My question was not so clear as my image is running from RAM (not XIP).
Anyway I still have the problem to write raw blocks of flash while system is
running.
How can avoid user processes accessing the flash through PSM driver?
Currently I boost my thread priority during a whole flash block erase/write
operation, but I would like to find something more reliable.
So my question about interrupt disabling.

Best regards,
PaoloC

"Paul G. Tobey [eMVP]" wrote:

Those are *all* device-specific questions. Usually, the bootloader is
responsible for doing flash image upgrades, so it doesn't have to "allocate"
memory; it's the only possible code using the memory so it just says, hey,
I'm going to use the X MB starting at address Y to store the image, so get
used to it! Same goes for the interrupts. The bootloader generally doesn't
enable interrupts at all, so no need to disable them.

You really can't partially write to flash if you're executing XIP. Think
about it. When you are executing code, you're constantly grabbing the next
few instructions from the flash to execute them. When interrupts are
enabled, you might be grabbing some code from application X, then driver Y,
then the kernel, etc., etc. Since writing to a flash region has to be done
a block at a time, you have to be able to assure that *NO CODE WILL BE
EXECUTED FROM FLASH* while that is happening. NONE. You can't do that when
using XIP and running with interrupts enabled.

Paul T.

"PaoloC" <PaoloC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6286C649-FC1B-4B9F-9D27-9ABB46DD715C@xxxxxxxxxxxxxxxx
Good morning,
I have already seen a thread about OS update where the suggested operation
is :
"Easy to do if your OS is running from RAM. In case its XIP, you can
write an app which is loaded completely into RAM. This app should read
the update, turns off interrupts and erases/writes to flash directly."
I have to questions about this approach:
1) How can I allocate in my application enough memory to hold the new
image
(> 27 MB)
2) How can I disable inerrupts from application layer (may be an IOCTl to
a
custom driver ?)
Currently I am loading new image from external flash in chuncks and write
each chunck to the internal flash with interrupt enabled (just high
priority
thread).
Anyway this method is not reliable :-)

Best regards,
PaoloC



.

Relevant Pages

  • Re: What File System supports Application XIP
    ... > You won't gain at runtime by using XIP though. ... I thought that when you XIPed from flash, ... directly back to the flash memory address. ... There shouldn't be a RAM ...
    (Linux-Kernel)
  • XIP vs RAM
    ... Maybe the system can even get away with the next small size RAM ... Does anyone know if/what the premimum of the "K" Strata FLASH is? ... Also what are the steps needed to transition to a XIP OS? ... >>> My bootloader create a BINFS partition and an EXTENDED partition on ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [RFC] Advanced XIP File System
    ... > expensive slow flash instead of cheap fast RAM?" ... If I store libfoo.so as an XIP ... But the JFFS2 version would need ...
    (Linux-Kernel)
  • Re: [RFC] Advanced XIP File System
    ... borrow the compression from Squashfs. ... expensive slow flash instead of cheap fast RAM?" ... If I store libfoo.so as an XIP ... 2MiB of RAM to store that library when used while the XIP system uses ...
    (Linux-Kernel)
  • Re: Flash filesystem
    ... point that the OP is making is that while yes the flash will be corrupted ... when the power is lost, the file system is advertised to manage this and ... >> flash erase block procedure is interrupted with reset? ... >> driver capable of detecting these interrupts and act accordingly. ...
    (microsoft.public.windowsce.platbuilder)