IFS in FLASH - What if I erase it?

Hiya. I was just pondering the composition of the universe among other things,
and it struck me that I may have created a problem for myself in the future.
In my embedded thingie, I patch the startup header with the address of the IFS
as it sits in FLASH up at the top of the 4G memory range. This works
wonderfully. But what happens at some time down the road, when I decided to
update the FLASH contents in the field? It would start with a bulk erase of
the FLASH and therefore the IFS, possibly creating a window in which any
reference to the IFS could cause heartburn for Proc, no? Even if I did manage
to pull off the reprogramming before anybody looked at /proc/boot, how would
the kernel feel about having the IFS updated right out from underneath it?
Since I can’t really guarantee what will be going on at the time the update
happens am I better off wasting space by copying the IFS to RAM along with the
startup code? This would at least alleviate the dependency on the FLASH always
being consistent, and the new IFS would be loaded along with the new kernel and
whatnot at the next system reset. Comments, anyone?

-Warren “iceberg off the port bow!” Peece

Warren Peece <warren@nospam.com> wrote:
: Hiya. I was just pondering the composition of the universe among other things,
: and it struck me that I may have created a problem for myself in the future.
: In my embedded thingie, I patch the startup header with the address of the IFS
: as it sits in FLASH up at the top of the 4G memory range. This works
: wonderfully. But what happens at some time down the road, when I decided to
: update the FLASH contents in the field? It would start with a bulk erase of
: the FLASH and therefore the IFS, possibly creating a window in which any
: reference to the IFS could cause heartburn for Proc, no? Even if I did manage
: to pull off the reprogramming before anybody looked at /proc/boot, how would
: the kernel feel about having the IFS updated right out from underneath it?
: Since I can’t really guarantee what will be going on at the time the update
: happens am I better off wasting space by copying the IFS to RAM along with the
: startup code? This would at least alleviate the dependency on the FLASH always
: being consistent, and the new IFS would be loaded along with the new kernel and
: whatnot at the next system reset. Comments, anyone?

: -Warren “iceberg off the port bow!” Peece

Not to worry “Warren” … If I read you correctly you are referring to the
‘imagefs_paddr’ structure member of the startup header. This is only used to
allow startup to copy the IFS from its flash location to its final destination
in RAM. This only takes place at boot up.


Now, XIP would be a different kettle of fish …


John

“John Wall” <jwall@qnx.com> wrote in message news:90j8lq$8dq$1@nntp.qnx.com
|
| Not to worry “Warren” … If I read you correctly you are referring to the
| ‘imagefs_paddr’ structure member of the startup header. This is only used to
| allow startup to copy the IFS from its flash location to its final
destination
| in RAM. This only takes place at boot up.
|
|
| Now, XIP would be a different kettle of fish …

John

Mmmmm… Fish stew… :stuck_out_tongue:

You read me correctly. I’m only stuffing the imagefs_paddr, so if you copy it
to RAM already, then I’m safe. Just out of curiosity, “John” :wink:, what would I
have to do different in order to mark the IFS as XIP? Not that I’m-a-gonna,
just didn’t see abything definitive in the docs.

-Warren “there is no spoon” Peece

Warren Peece <warren@nospam.com> wrote:
: “John Wall” <jwall@qnx.com> wrote in message news:90j8lq$8dq$1@nntp.qnx.com
: |
: | Not to worry “Warren” … If I read you correctly you are referring to the
: | ‘imagefs_paddr’ structure member of the startup header. This is only used to
: | allow startup to copy the IFS from its flash location to its final
: destination
: | in RAM. This only takes place at boot up.
: |
: |
: | Now, XIP would be a different kettle of fish …
: |
: | –
: | John

: Mmmmm… Fish stew… :stuck_out_tongue:

: You read me correctly. I’m only stuffing the imagefs_paddr, so if you copy it
: to RAM already, then I’m safe. Just out of curiosity, “John” :wink:, what would I
: have to do different in order to mark the IFS as XIP? Not that I’m-a-gonna,
: just didn’t see abything definitive in the docs.

: -Warren “there is no spoon” Peece


Well “Warren”, not much really. You’d need to change your build file to
include both a “ram=” and image=" parameter, i.e.

image=0xff000000 (location of image in flash)
ram =0x1000 (location of startup and data in ram)

These 2 parameters used together in the build file signal an XIP image.

The IPL would not change one whit. Erasing the whole flash (bulk erase)
certainly would present a problem though …

\

John

Thank you for the info “John”, It doesn’t appear anywhere that I can find
(searched for “xip”) in the documentation. I did read that since the IFS is
compressed, it must be copied to RAM before it can be used. Does this imply
that if I do not compress the IFS that code will be run out of the IFS in FLASH
by default (the docs seem to suggest that this is so, but you say otherwise)?
I feel safe in my implementation, but perhaps a little something could be added
to the docs to make this particular issue clearer (at least not contradictory
to what you said). The apparently conflicting information is in the “XIP vs.
Copy” section of the mkifs documentation in the utilities reference.

Thanks again for the assistance.

-“Warren”


“John Wall” <jwall@qnx.com> wrote in message news:90jdmq$asl$1@nntp.qnx.com
| Warren Peece <warren@nospam.com> wrote:
| : “John Wall” <jwall@qnx.com> wrote in message
news:90j8lq$8dq$1@nntp.qnx.com
| : |
| : | Not to worry “Warren” … If I read you correctly you are referring to
the
| : | ‘imagefs_paddr’ structure member of the startup header. This is only
used to
| : | allow startup to copy the IFS from its flash location to its final
| : destination
| : | in RAM. This only takes place at boot up.
| : |
| : |
| : | Now, XIP would be a different kettle of fish …
| : |
| : | –
| : | John
|
| : Mmmmm… Fish stew… :stuck_out_tongue:
|
| : You read me correctly. I’m only stuffing the imagefs_paddr, so if you copy
it
| : to RAM already, then I’m safe. Just out of curiosity, “John” :wink:, what
would I
| : have to do different in order to mark the IFS as XIP? Not that
I’m-a-gonna,
| : just didn’t see abything definitive in the docs.
|
| : -Warren “there is no spoon” Peece
|
|
| Well “Warren”, not much really. You’d need to change your build file to
| include both a “ram=” and image=" parameter, i.e.
|
| image=0xff000000 (location of image in flash)
| ram =0x1000 (location of startup and data in ram)
|
| These 2 parameters used together in the build file signal an XIP image.
|
| The IPL would not change one whit. Erasing the whole flash (bulk erase)
| certainly would present a problem though …
|

John

Warren Peece <warren@nospam.com> wrote:
: Thank you for the info “John”, It doesn’t appear anywhere that I can find
: (searched for “xip”) in the documentation. I did read that since the IFS is
: compressed, it must be copied to RAM before it can be used. Does this imply
: that if I do not compress the IFS that code will be run out of the IFS in FLASH
: by default (the docs seem to suggest that this is so, but you say otherwise)?
: I feel safe in my implementation, but perhaps a little something could be added
: to the docs to make this particular issue clearer (at least not contradictory
: to what you said). The apparently conflicting information is in the “XIP vs.
: Copy” section of the mkifs documentation in the utilities reference.

I would be very happy if “John” or “someone” would help me make the docs
clearer. That flash stuff (especially XIP) is so much “Greek” to me.


“Steve Reid” stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
“Double quotes are our specialty”

Warren Peece <warren@nospam.com> wrote:
: Thank you for the info “John”, It doesn’t appear anywhere that I can find
: (searched for “xip”) in the documentation. I did read that since the IFS is
: compressed, it must be copied to RAM before it can be used. Does this imply
: that if I do not compress the IFS that code will be run out of the IFS in FLASH
: by default (the docs seem to suggest that this is so, but you say otherwise)?


No, you would need to specify the two ‘mkifs’ parameters in your build file
before the image would be XIP ([image =] and [ram =]). XIP requires that your
flash be linearly mapped and that the image is not compressed.


I think I know what you mean … In your case, the image (IFS) is copied
to ram. The code portions of your executables are used in placed (uip),
i.e. executed from the IFS.
The default is [data=c] (data portions of the executable copied outside
the IFS, code used in place). When I refer to XIP I’m specifically talking
about the code portions of the executable being executed from flash (or ROM,
etc …)

Does that make sense?

: I feel safe in my implementation, but perhaps a little something could be added
: to the docs to make this particular issue clearer (at least not contradictory
: to what you said). The apparently conflicting information is in the “XIP vs.
: Copy” section of the mkifs documentation in the utilities reference.

I think the confusion mainly stems from semantics. My use of XIP and the manuals
may not be exactly the same. I’ll take a look at the manual.


John

“John Wall” <jwall@qnx.com> wrote in message news:90jjev$ea2$1@nntp.qnx.com
| Warren Peece <warren@nospam.com> wrote:
| : Thank you for the info “John”, It doesn’t appear anywhere that I can find
| : (searched for “xip”) in the documentation. I did read that since the IFS
is
| : compressed, it must be copied to RAM before it can be used. Does this
imply
| : that if I do not compress the IFS that code will be run out of the IFS in
FLASH
| : by default (the docs seem to suggest that this is so, but you say
otherwise)?
|
|
| No, you would need to specify the two ‘mkifs’ parameters in your build file
| before the image would be XIP ([image =] and [ram =]). XIP requires that
your
| flash be linearly mapped and that the image is not compressed.
|
|
| I think I know what you mean … In your case, the image (IFS) is copied
| to ram. The code portions of your executables are used in placed (uip),
| i.e. executed from the IFS.
| The default is [data=c] (data portions of the executable copied outside
| the IFS, code used in place). When I refer to XIP I’m specifically talking
| about the code portions of the executable being executed from flash (or ROM,
| etc …)
|
| Does that make sense?

You seem to be reiterating what the doc says, with the assertion that even if
my image is not compressed it will still be copied to RAM by default (which
appears to be the point of distinction here).

My FLASH is linearly mapped, from 0xFFF80000 through 0xFFFFFFFF, with the reset
vector and IPL code in the top 4k, and the boot image (header, startup & IFS)
at the bottom. The doc specifically states that if the IFS is compressed, it
will be un-compressed to RAM. It does not say anything about what happens if
the image is not compressed, and I just assumed it would be left in FLASH
(which is not necessarily a valid assumption according to what you’re saying).
If my assumption were correct, and code was left at the default of UIP, then it
would seem that I had achieved XIP and also a problem if I try to re-program my
FLASH.

IMHO the doc should clearly define what happens to the image in the not
compressed case, and also what needs to be done in order to achieve XIP with
the image and ram parameters to mkifs. Also, someone should teach “Steve” to
read “Greek”. :slight_smile:

| I think the confusion mainly stems from semantics. My use of XIP and the
manuals
| may not be exactly the same. I’ll take a look at the manual.

John

I think it’s just me making bogus assumptions. I guess Dionysos & I have been
spending too much time together lately… (oops, sorry for the “Greek”
reference, “Steve”… Heh)

-yeahyeahyeah

Warren Peece <warren@nospam.com> wrote:
: “John Wall” <jwall@qnx.com> wrote in message news:90jjev$ea2$1@nntp.qnx.com
: | Warren Peece <warren@nospam.com> wrote:
: | : Thank you for the info “John”, It doesn’t appear anywhere that I can find
: | : (searched for “xip”) in the documentation. I did read that since the IFS
: is
: | : compressed, it must be copied to RAM before it can be used. Does this
: imply
: | : that if I do not compress the IFS that code will be run out of the IFS in
: FLASH
: | : by default (the docs seem to suggest that this is so, but you say
: otherwise)?
: |
: |
: | No, you would need to specify the two ‘mkifs’ parameters in your build file
: | before the image would be XIP ([image =] and [ram =]). XIP requires that
: your
: | flash be linearly mapped and that the image is not compressed.
: |
: |
: | I think I know what you mean … In your case, the image (IFS) is copied
: | to ram. The code portions of your executables are used in placed (uip),
: | i.e. executed from the IFS.
: | The default is [data=c] (data portions of the executable copied outside
: | the IFS, code used in place). When I refer to XIP I’m specifically talking
: | about the code portions of the executable being executed from flash (or ROM,
: | etc …)
: |
: | Does that make sense?

: You seem to be reiterating what the doc says, with the assertion that even if
: my image is not compressed it will still be copied to RAM by default (which
: appears to be the point of distinction here).

Whether the image is compressed or not, it IS copied to RAM (with the standard
build files). It will only execute from flash if you include the above 2 mentioned
parameters to your build file.



: My FLASH is linearly mapped, from 0xFFF80000 through 0xFFFFFFFF, with the reset
: vector and IPL code in the top 4k, and the boot image (header, startup & IFS)
: at the bottom. The doc specifically states that if the IFS is compressed, it
: will be un-compressed to RAM. It does not say anything about what happens if
: the image is not compressed, and I just assumed it would be left in FLASH


The [image=xxx] specifies the location of image. Take a look at the verbose
output of ‘mkifs’ when building your images … The output will show you the
address map of the image. Now try adding [image=0xfff80000] and [ram=0x1000],
once again, look at the address map of the image.

: (which is not necessarily a valid assumption according to what you’re saying).
: If my assumption were correct, and code was left at the default of UIP, then it
: would seem that I had achieved XIP and also a problem if I try to re-program my
: FLASH.

Ok, the assumption is not valid :wink:

: IMHO the doc should clearly define what happens to the image in the not
: compressed case, and also what needs to be done in order to achieve XIP with
: the image and ram parameters to mkifs. Also, someone should teach “Steve” to
: read “Greek”. :slight_smile:


A good place to check exactly what happens is _main.c in the startup library.


John