Why is the IPL combined with the IFS in the pxa270 BSP when the IFS cannot
be used? The IPL waits for either an IFS to be downloaded, or it will scan
for one in flash. But flash scans seem to start at an address much higher
than where the IFS is located in the combined image so they don’t work. And
if you’re going download it serially what’s the point in having it in the
bin file? The net effect seems to be it takes longer to program the flash
with no benefit.
What am I missing?
While I’m asking questions, it took awhile to figure out how to uncombine
the IPL from the IFS. I couldn’t figure how to do this in the IDE. After
digging through the BSP package I found a “mkflashimage” script that shows
how to use a utility called ntoarm-objcopy and mkrec to create an IPL that
is divorced from the IFS. I couldn’t find “ntoarm-objcopy” documented in
utilities. It would really help in the embedding QNX documentation if some
discussion was given to actually compiling/linking/locating the IPL image.
Ken Schumm <kwschumm@qsolv.com> wrote:
Why is the IPL combined with the IFS in the pxa270 BSP when the IFS cannot
be used? The IPL waits for either an IFS to be downloaded, or it will scan
for one in flash. But flash scans seem to start at an address much higher
than where the IFS is located in the combined image so they don’t work.
This has been fixed internally, and will appear in the next release of the BSP.
In the meantime, you can simply change:
#define FLASH_ADDR 0x40000
to
#define FLASH_ADDR 0x1000
in main.c of the IPL source code, and then re-build the IPL.
And if you’re going download it serially what’s the point in having it in the
bin file? The net effect seems to be it takes longer to program the flash
with no benefit.
The serial download option is provided for flexibility. If you happen to program
a non-working image into flash, you will still have the ability to serially download
a working image, so that the flash can be erased / re-programmed, without having
to revert to the JTAG tools. The source to the IPL can be modified however you
like; for example, it can be made to only boot from flash, or only boot serially,
or only prompt for a serial boot if no valid image is found in flash. Likewise,
the script in the BSP which combines the binary IPL with the OS image may also
be modified, so that the final step (combining the binary IPL with the OS image)
is not performed.
What am I missing?
While I’m asking questions, it took awhile to figure out how to uncombine
the IPL from the IFS. I couldn’t figure how to do this in the IDE. After
digging through the BSP package I found a “mkflashimage” script that shows
how to use a utility called ntoarm-objcopy and mkrec to create an IPL that
is divorced from the IFS. I couldn’t find “ntoarm-objcopy” documented in
utilities. It would really help in the embedding QNX documentation if some
discussion was given to actually compiling/linking/locating the IPL image.
I’ll leave the IDE questions to someone else; ntoarm-objcopy does not have
its own entry in the documentation, but it is referred to in the documentation
for objcopy. It is also referred to in “Burning an OS image to Flash” in the
BSP documentation (note - the BSP documentation will also be fixed to match
the fix to the IPL FLASH_ADDR parameter).
\
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com
“Dave Green” <dgreen@qnx.com> wrote in message
news:dt0161$p79$1@inn.qnx.com…
Ken Schumm <> kwschumm@qsolv.com> > wrote:
Why is the IPL combined with the IFS in the pxa270 BSP when the IFS
cannot
be used? The IPL waits for either an IFS to be downloaded, or it will
scan
for one in flash. But flash scans seem to start at an address much
higher
than where the IFS is located in the combined image so they don’t work.
This has been fixed internally, and will appear in the next release of the
BSP.
In the meantime, you can simply change:
#define FLASH_ADDR 0x40000
to
#define FLASH_ADDR 0x1000
in main.c of the IPL source code, and then re-build the IPL.
Makes sense, I couldn’t see why it was at 0x40000 but figured I was missing
something.
[…]
I’ll leave the IDE questions to someone else; ntoarm-objcopy does not have
its own entry in the documentation, but it is referred to in the
documentation
for objcopy. It is also referred to in “Burning an OS image to Flash” in
the
BSP documentation (note - the BSP documentation will also be fixed to
match
the fix to the IPL FLASH_ADDR parameter).
Yes, sorry, you’re correct, I missed that section of the BSP documentation.
Once the BSP was installed and working I started relying on the “Embedding
QNX” section of the online docs.
Thanks for the quick response!