How Do We Replace Our OS Image in Flash?

QNX Newsgroups (Archives) qdn.public.qnxrtp.powerpc
1

How Do We Replace Our OS Image in Flash?

We have a Motorola 8260ADS Pilot rev 00 development board
which, after receiving our copy of the Embedding Kit, we
have finally been able to get to run QNX. Currently we are
stuck using some software called “OCD Commander” together
with a Macraigor “Raven” pod to burn the QNX flash image to
the board’s flash memory via the JTAG port. Even though the
Raven pod has a parallel port interface on the PC side it is
UNGODLY slow! It takes just over 4 hours to transfer an 8MB
flash image!

From reading the QNX “Making an OS Image” document, I get
the impression that once QNX is on the board, we should be
able to update the OS boot image by writing the image to the
raw flash partition that corresponds to the build image area
on the flash. I’ve had a go at this but I must have done
something wrong. The system wouldn’t boot after I was
through and I was forced to use the Raven pod to get it
going again (I end up doing at least one, 4-hour download a
day it seems – it’s getting old fast! :slight_smile:). Here are some
details.


The image I build and download through the JTAG port is laid
out as follows. This images encompasses the entire 8MB
flash memory (except for the first 256k, which is not used
and not written to the flash).

0xff800000 - Starting address of flash. The first 256k
(i.e. the first flash sector) are left
unused because the OCD Commander software
refuses to write to it claiming it can’t be
written to on an 8260ADS board. I’m
skeptical however because I’ve been able to
modify at least the first couple of
kilobytes in this area. Also the board
support package for the 8260ADS expects to
be able to write in the first flash sector.

0xff840000 - Beginning of the second flash sector. This is where
the OS image generated from the 8260ads.build script
goes. The image is padded to 2MB - 256kB.

0xffa00000 - Beginning of the QNX flash file system area (5MB)

0xfff00100 - Reset code and IPL padded to 1MB


I download this image to the dev board via the JTAG
connector (starting at the second flash sector for reasons
described above), hit the reset button and got a QNX system
with a serial console, mounted flash file system and
Ethernet enabled and hosting tcp/ip on our office LAN.
Perfect! Then I FTPed over ‘df’, ‘du’ and a few other
utilities to the flash partition (/fs0p1). When I run ‘df
-kP’ I see the following report for the various
/dev/… flash partitions.

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/fs 1024 1024 0 100% /dev/fs0p2
/dev/fs0p1 4864 28 4835 1% /fs0p1
/dev/fs0 2048 2048 0 100% /dev/fs0p0
/dev/fs0 8192 8192 0 100%

Based on the partition sizes I assumed /dev/fs0p0
corresponded to the area in flash that contains the 256k of
unused memory plus the OS image and /dev/fs0p2 corresponded
to the area holding the IPL. With this in mind I made some
changes to the 8260ads.build file and tried to build just
that portion of the image that goes into the first 2MB of
the flash. As follows…

mkrec -s2M -o256k -ffull -r 8260ads.bin > boot_img

Then I FTPed ‘boot_img’ over to the flash file system on the
dev board and used ‘cp’ to write it onto /dev/fs0p0. The
image copy appeared to work ok and the board and software
continued to run fine until I got crazy and hit the reset
button to test the new image. This turned the dev board into
a brick and I had to rewrite the full 8M flash image with
the JTAG programmer to get it to boot up again. I’m really
not too surprised by my failure because I don’t really
understand what I’m doing. However, given that the FTP /
copy cycle takes about 15 seconds and the JTAG method takes
a bit over 4 hours, I would REALLY like to know how to
update the boot image without having to re-burn the entire
flash via the JTAG port! If possible, I would prefer just
to replace the OS image and not overwrite items stored in
the flash file system. Can that be done? If so, how? What
am I doing wrong? All comments are welcome!



Charlie Hubbard
charlieh@innovsys.com

2

Charlie Hubbard <chubbard@owt.com> wrote:

How Do We Replace Our OS Image in Flash?

We have a Motorola 8260ADS Pilot rev 00 development board
which, after receiving our copy of the Embedding Kit, we
have finally been able to get to run QNX. Currently we are
stuck using some software called “OCD Commander” together
with a Macraigor “Raven” pod to burn the QNX flash image to
the board’s flash memory via the JTAG port. Even though the
Raven pod has a parallel port interface on the PC side it is
UNGODLY slow! It takes just over 4 hours to transfer an 8MB
flash image!

From reading the QNX “Making an OS Image” document, I get
the impression that once QNX is on the board, we should be
able to update the OS boot image by writing the image to the
raw flash partition that corresponds to the build image area
on the flash. I’ve had a go at this but I must have done
something wrong. The system wouldn’t boot after I was
through and I was forced to use the Raven pod to get it
going again (I end up doing at least one, 4-hour download a
day it seems – it’s getting old fast! > :slight_smile:> ). Here are some
details.



The image I build and download through the JTAG port is laid
out as follows. This images encompasses the entire 8MB
flash memory (except for the first 256k, which is not used
and not written to the flash).

0xff800000 - Starting address of flash. The first 256k
(i.e. the first flash sector) are left
unused because the OCD Commander software
refuses to write to it claiming it can’t be
written to on an 8260ADS board. I’m
skeptical however because I’ve been able to
modify at least the first couple of
kilobytes in this area. Also the board
support package for the 8260ADS expects to
be able to write in the first flash sector.

0xff840000 - Beginning of the second flash sector. This is where
the OS image generated from the 8260ads.build script
goes. The image is padded to 2MB - 256kB.

0xffa00000 - Beginning of the QNX flash file system area (5MB)

0xfff00100 - Reset code and IPL padded to 1MB



I download this image to the dev board via the JTAG
connector (starting at the second flash sector for reasons
described above), hit the reset button and got a QNX system
with a serial console, mounted flash file system and
Ethernet enabled and hosting tcp/ip on our office LAN.
Perfect! Then I FTPed over ‘df’, ‘du’ and a few other
utilities to the flash partition (/fs0p1). When I run ‘df
-kP’ I see the following report for the various
/dev/… flash partitions.

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/fs 1024 1024 0 100% /dev/fs0p2
/dev/fs0p1 4864 28 4835 1% /fs0p1
/dev/fs0 2048 2048 0 100% /dev/fs0p0
/dev/fs0 8192 8192 0 100%

Based on the partition sizes I assumed /dev/fs0p0
corresponded to the area in flash that contains the 256k of
unused memory plus the OS image and /dev/fs0p2 corresponded
to the area holding the IPL. With this in mind I made some
changes to the 8260ads.build file and tried to build just
that portion of the image that goes into the first 2MB of
the flash. As follows…

mkrec -s2M -o256k -ffull -r 8260ads.bin > boot_img

Then I FTPed ‘boot_img’ over to the flash file system on the
dev board and used ‘cp’ to write it onto /dev/fs0p0. The
image copy appeared to work ok and the board and software
continued to run fine until I got crazy and hit the reset
button to test the new image. This turned the dev board into
a brick and I had to rewrite the full 8M flash image with
the JTAG programmer to get it to boot up again. I’m really
not too surprised by my failure because I don’t really
understand what I’m doing. However, given that the FTP /
copy cycle takes about 15 seconds and the JTAG method takes
a bit over 4 hours, I would REALLY like to know how to
update the boot image without having to re-burn the entire
flash via the JTAG port! If possible, I would prefer just
to replace the OS image and not overwrite items stored in
the flash file system. Can that be done? If so, how? What
am I doing wrong? All comments are welcome!

Hi Charlie,

I think the problem is that you built your image to be 2M in
size, then over-wrote the 256k at the beginning of the flash
(the part which the Commander software won’t overwrite). By
using the mkrec command as you did, you generated a 2M image,
but the OS image is offset to 256k into the image.
The problem is that the devf driver doesn’t recognize that the
first 2M consists of some unknown 256k chunk, then the OS image;
it just sees a 2M partition. What you need to do when you want
to copy in a new OS image is to use the flashctl command to
erase the old OS image. Then you need to somehow copy the new
one in at the proper offset, for which I would recommend the dd
command. So:

to erase the old OS image:

flashctl -p/dev/fs0 -o256k -l1792k -e

this will erase the raw device, starting at offset 256k, up to
a limit of 2M - 256k (1792k), and leave the first 256k alone.

now, ftp the original, un-padded boot image over, and use dd to
copy it to the desired 256k offset;

dd if=8260ads.bin of=/dev/fs0 bs=1k seek=256k


Hope this helps,

Dave Green (dgreen@qnx.com)

QNX Software Systems Ltd.
http://www.qnx.com

3

On 25 Feb 2002 13:49:52 GMT, Dave Green <dgreen@qnx.com> wrote:

Hi Charlie,

I think the problem is that you built your image to be 2M in
size, then over-wrote the 256k at the beginning of the flash
(the part which the Commander software won’t overwrite). By
using the mkrec command as you did, you generated a 2M image,
but the OS image is offset to 256k into the image.
The problem is that the devf driver doesn’t recognize that the
first 2M consists of some unknown 256k chunk, then the OS image;
it just sees a 2M partition. What you need to do when you want
to copy in a new OS image is to use the flashctl command to
erase the old OS image. Then you need to somehow copy the new
one in at the proper offset, for which I would recommend the dd
command. So:

to erase the old OS image:

flashctl -p/dev/fs0 -o256k -l1792k -e

this will erase the raw device, starting at offset 256k, up to
a limit of 2M - 256k (1792k), and leave the first 256k alone.

now, ftp the original, un-padded boot image over, and use dd to
copy it to the desired 256k offset;

dd if=8260ads.bin of=/dev/fs0 bs=1k seek=256k

Dave,

Thanks for the quick response on this. I’ve tried your suggestions
but the result is the same. Once the new OS image is on the flash and
the board is rebooted, the board is more or less dead. “More or less”
I say because stuff does come out on serial port 1 but it’s just
gibberish. This same kind of thing happens when we first boot a board
that’s been loaded with the OCD Commander softare. There is a few
lines of garbage followed by the ‘Welcome…’ message from the build
script followed by a shell prompt. When we try to load the board
using ‘flashctl’ and ‘dd’ we get the few lines of garbage after a
reboot but we don’t get the welcome message or the shell prompt. The
garbage repeats itself over and over every few seconds. My theory has
been the board is rebooting every few seconds and spraying a fresh
round of garbage.

Anyway, I’m not sure I’m loading the new image into the right
place. Below I’ve included copies of our build script as well as the
shell script that builds the 8MB ‘flash_img’ file we push down with
OCD Commander. Maybe you’ll be able to spot something that I’m
missing that indicates I’m using the wrong offsets or something.

======================================================================
8260ads.build file

[image=0x10000]
[virtual=ppcbe,binary] .bootstrap = {
startup-8260ads
PATH=/proc/boot procnto-600
}

[+script] startup.script = {
devf-8260ads &

devc-serppc8260 -e -b57600 -c16625000 scc1 scc2 &
reopen /dev/ser1
display_msg .
display_msg **********************************
display_msg Welcome to Neutrino on the 8260ADS
display_msg **********************************

io-net -dppc8260-ads channel=2 -pttcpip
if=en0:172.23.11.207:255.255.248.0 &

These env variables inherited by all the programs which

follow
SYSNAME=nto
TERM=qansi

run startup.bat out of the flash filesystem

/fs0p1/startup.bat

[+session] PATH=:/proc/boot:/fs0p1:/fs0p1/bin esh

[+session] login -p

}

[type=link] /dev/console=/dev/ser1
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so
[type=link] /tmp=/dev/shmem

libc.so

The networking shared libraries

devn-ppc8260-ads.so
libsocket.so
npm-ttcpip.so

[data=c]

Generic components

devc-serppc8260
esh
pidin
ls
cat
pdebug
uname
cp
chmod
mkdir
rm
echo
sin
dd

io-net and networking utilities

io-net
ping
ftp
fs-nfs2

Flash filesystem driver

devf-8260ads
flashctl


\

make_flash_img shell script

if [ x"$1" = x ]
then
echo “You must specify a name of a Neutrino image”
exit 1
fi

Start with the boot image. The boot image is specified as

an argument to the script (max size 1792k)

mkrec -s1792k -ffull -r $1 > flash_img

Create an empty 5MB flash partition and append it to our image

mkefs …/src/hardware/ipl/boards/8260ads/8260ads.ffs flash.tmp
cat flash.tmp >>flash_img

Generate a binary image of the IPL code

objcopy --input-format=elf32-powerpc --output-format=binary -R.data
…/src/hardware/ipl/boards/8260ads/ppc/be/ipl-8260ads ipl-8260ads.bin
mkrec -s1M -ffull -r ipl-8260ads.bin >> flash_img
rm ipl-8260ads.bin
rm flash.tmp

create s-record version of flash image

objcopy --input-format=binary --output-format=srec
–adjust-vma=0xff840000 flash_img flash_img.s19

======================================================================

The final line in the shell script generates the file ‘flash_img.s19’.
It is this image that I download to the development board through the
JTAG pod. The JTAG software reads the file and sees that it spans
from 0xff840000 to 0xffffffff (8M - 256k). I write this image starting
at 0xff840000, which is the start of the second flash sector.


Now here is something interesting. When I do a ‘df -kP’ on a working
development board I get the following report…

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/fs 1024 1024 0 100% /dev/fs0p2
/dev/fs0p1 4864 28 4835 1% /fs0p1
/dev/fs0 2048 2048 0 100% /dev/fs0p0
/dev/fs0 8192 8192 0 100%

Because /dev/fs0p0 is 2M in size, I assumed it was into this area that
the OS boot image was being written. I assumed it was 256k of unused
area (the first flash sector) followed by the boot image in the
remaining 1792k. That would make 2M total for the partition and
mirror what I thought I wrote through the JTAG programmer. So, out of
curiosity I used FTP to copy /dev/fs0p0 to a windows machine so I
could have a look. Here is a snippet of what I found…


00008740: 0a4c 6f61 6469 6e67 2051 4e58 362e 2e2e .Loading QNX6…
00008750: 2e0a 0a00 6b65 726e 656c 5f64 6576 6963 …kernel_devic
00008760: 6500 0000 726f 6d00 0000 0000 0000 0040 e…rom…@
00008770: 7fff ffff 0000 0140 0000 0000 0000 0000 …@…
00008780: 0001 0ba4 1000 0000 0001 0c60 0001 0dfc …`…
00008790: 0001 0d48 0000 0000 8000 0000 0000 0001 …H…
000087a0: 7fff ffff 0000 0240 0000 0000 0000 0000 …@…
000087b0: 0001 0eb0 0000 0000 0001 0ec0 0001 0ee0 …
000087c0: 0001 0ecc 0000 0000 0000 0000 0001 0ef4 …
000087d0: 0001 8828 0001 880c 0001 87f0 0001 3504 …(…5.
000087e0: 0001 3c0c 0001 0a28 0001 0aa4 0001 0b28 …<…(…(
000087f0: 7363 6332 5e31 2e35 3736 3030 2e31 3636 scc2^1.57600.166
00008800: 3235 3030 302e 3136 0000 0000 7363 6331 25000.16…scc1
00008810: 5e31 2e35 3736 3030 2e31 3636 3235 3030 ^1.57600.1662500
00008820: 302e 3136 0000 0000 3832 3630 0000 0000 0.16…8260…
00008830: 4144 3a66 3a4b 3a4d 3a4e 3a50 3a52 3a53 AD:f:K:M:N:P:R:S
00008840: 3a76 0000 3832 3630 4144 5300 1820 2428 :v…8260ADS… $(
00008850: 2c00 0000 696f 0000 0000 0000 0000 0000 ,…io…
00008860: ffff 8a8c ffff 8a9c ffff 8a9c ffff 8a78 …x

The scc1, scc2, 57600, etc., appears to be serial port setup stuff
taken from my build script. Anyway, what surprises me is here is
recognizable QNX stuff at address 0x00008740! I really didn’t expect
to see any QNX stuff until after 0x00040000 (256k). Clearly I don’t
understand how /dev/fs0p0 maps onto the physical memory. But I’m
curious, if it doesn’t include the first 256k, why does it span 2MB?


Anyway, I took the new boot image I wanted to load and padded it to 2M
with no starting offset and looked at its hex dump to see how they
compared…

00008670: 2c00 0000 4082 fff8 7c69 1850 4e80 0020 ,…@…|i.PN…
00008680: 0000 0000 0000 0000 0000 0000 0000 0000 …
00008690: 6b65 726e 656c 5f64 6576 6963 6500 0000 kernel_device…
000086a0: 726f 6d00 0000 0000 0000 0040 7fff ffff rom…@…
000086b0: 0000 0140 0000 0000 0000 0000 0001 0afc …@…
000086c0: 1000 0000 0001 0bb8 0001 0d54 0001 0ca0 …T…
000086d0: 0000 0000 8000 0000 0000 0001 7fff ffff …
000086e0: 0000 0240 0000 0000 0000 0000 0001 0e08 …@…
000086f0: 0000 0000 0001 0e18 0001 0e38 0001 0e24 …8…$
00008700: 0000 0000 0000 0000 0001 0e4c 0001 8764 …L…d
00008710: 0001 8748 0001 872c 0001 345c 0001 3b64 …H…,…4…;d
00008720: 0001 0980 0001 09fc 0001 0a80 7363 6332 …scc2
00008730: 5e31 2e35 3736 3030 2e31 3636 3235 3030 ^1.57600.1662500
00008740: 302e 3136 0000 0000 7363 6331 5e31 2e35 0.16…scc1^1.5
00008750: 3736 3030 2e31 3636 3235 3030 302e 3136 7600.16625000.16
00008760: 0000 0000 3832 3630 0000 0000 4144 3a66 …8260…AD:f
00008770: 3a4b 3a4d 3a4e 3a50 3a52 3a53 3a76 0000 :K:M:N:P:R:S:v…
00008780: 3832 3630 4144 5300 1820 2428 2c00 0000 8260ADS… $(,…
00008790: 696f 0000 0000 0000 0000 0000 0000 0000 io…
000087a0: ffff 8aa4 ffff 8ab4 ffff 8ab4 ffff 8a90 …


As you can see, things are not exactly the same but they seem pretty
close both in address and content so I thought maybe I could take my
new image and write it over the top of /dev/fs0p0. I FTPed the image
to the dev board and used ‘cp boot_img /dev/fs0p0’ to copy it to
flash. I didn’t use ‘flashctl’ to erase the partition first. Was
this my problem? At any rate the end result was much the same as
before. Once rebooted, the dev board would spew a couple lines of
garbage characters out the serial port every few seconds but that was
all.

I’m sure there is some key piece or pieces of how this all works that
I’m just not understanding correctly. What am I missing?



Charlie Hubbard
charlieh@innovsys.com

4

On Tue, 26 Feb 2002 11:45:33 -0600, Charlie Hubbard <chubbard@owt.com>
wrote:

Dave,

Thanks for the quick response on this. I’ve tried your suggestions
but the result is the same. Once the new OS image is on the flash and
the board is rebooted, the board is more or less dead…

Nevermind, we finally got this problem figured out! I guess the
original idea of just copying a new OS image over the top of
/dev/fs0p0 didn’t work because I didn’t bother to erase the partition
beforehand. Most recently we’ve been able to do…

flashctl -p/dev/fs0p0 -e

to erase that partition and then use FTP to directly copy a new OS
image on top of /dev/fs0p0. That seems to work just fine! I don’t
know why I couldn’t see the necessity in erasing the partition first
when I tried this last Friday. Oh well, I’m just happy it’s working.
Hopefully the 4 hour JTAG downloads will become a rarity!


Charlie Hubbard
charlieh@innovsys.com

5

Charlie Hubbard <chubbard@owt.com> wrote:

On 25 Feb 2002 13:49:52 GMT, Dave Green <> dgreen@qnx.com> > wrote:

[snip]

Dave,

Thanks for the quick response on this. I’ve tried your suggestions
but the result is the same. Once the new OS image is on the flash and
the board is rebooted, the board is more or less dead. “More or less”
I say because stuff does come out on serial port 1 but it’s just
gibberish. This same kind of thing happens when we first boot a board
that’s been loaded with the OCD Commander softare. There is a few
lines of garbage followed by the ‘Welcome…’ message from the build
script followed by a shell prompt. When we try to load the board
using ‘flashctl’ and ‘dd’ we get the few lines of garbage after a
reboot but we don’t get the welcome message or the shell prompt. The
garbage repeats itself over and over every few seconds. My theory has
been the board is rebooting every few seconds and spraying a fresh
round of garbage.

Charlie,

First of all, when performing this sort of operation, I prefer to work
with the raw flash device (/dev/fs0) as opposed to any partitions which
exist on the device (/dev/fs0p0, /dev/fs0p1, etc.). Also, instead of
using the df command, using “ls -ls /dev/fs*” gives more useful information
about what’s on the flash. In your case, after loading the full image
with the JTAG software, I’d expect to see:

/dev/fs0 == 8M (the raw device)
/dev/fs0p0 == 2M (the 256k of mystery code, plus your OS image)
/dev/fs0p1 == 5M (your flash filesystem partition)
/dev/fs0p2 == 1M (everything after the ffs, namely, the IPL)

note that the flash driver doesn’t recognize exactly where the
OS image begins; it does know exactly where the flash filesystem
begins and ends, as well as the size of the entire device, and it
defines the partition sizes based on that information.

later on in your response, you say:

I FTPed the image
to the dev board and used ‘cp boot_img /dev/fs0p0’ to copy it to
flash. I didn’t use ‘flashctl’ to erase the partition first. Was
this my problem?

Yes, I believe that this is your problem. After ftp’ing your boot image
over, you must use flashctl to erase the existing boot image before
writing the new one. Secondly, you want to write it to /dev/fs0 at a
particular offset, not to /dev/fs0p0. So again, I’d suggest you use
flashctl and dd to place the OS image, and make sure you’re specifying
the raw device (/dev/fs0), not a partition, when you issue these commands:

flashctl -p/dev/fs0 -o256k -l1792k -e

dd if=boot_img of=/dev/fs0 bs=1k seek=256k


Anyway, I’m not sure I’m loading the new image into the right
place. Below I’ve included copies of our build script as well as the
shell script that builds the 8MB ‘flash_img’ file we push down with
OCD Commander. Maybe you’ll be able to spot something that I’m
missing that indicates I’m using the wrong offsets or something.

======================================================================
8260ads.build file

[image=0x10000]
[virtual=ppcbe,binary] .bootstrap = {
startup-8260ads
PATH=/proc/boot procnto-600
}

[+script] startup.script = {
devf-8260ads &

devc-serppc8260 -e -b57600 -c16625000 scc1 scc2 &
reopen /dev/ser1
display_msg .
display_msg **********************************
display_msg Welcome to Neutrino on the 8260ADS
display_msg **********************************

io-net -dppc8260-ads channel=2 -pttcpip
if=en0:172.23.11.207:255.255.248.0 &

These env variables inherited by all the programs which

follow
SYSNAME=nto
TERM=qansi

run startup.bat out of the flash filesystem

/fs0p1/startup.bat

[+session] PATH=:/proc/boot:/fs0p1:/fs0p1/bin esh

[+session] login -p

}

[type=link] /dev/console=/dev/ser1
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so
[type=link] /tmp=/dev/shmem

libc.so

The networking shared libraries

devn-ppc8260-ads.so
libsocket.so
npm-ttcpip.so

[data=c]

Generic components

devc-serppc8260
esh
pidin
ls
cat
pdebug
uname
cp
chmod
mkdir
rm
echo
sin
dd

io-net and networking utilities

io-net
ping
ftp
fs-nfs2

Flash filesystem driver

devf-8260ads
flashctl


make_flash_img shell script

if [ x"$1" = x ]
then
echo “You must specify a name of a Neutrino image”
exit 1
fi

Start with the boot image. The boot image is specified as

an argument to the script (max size 1792k)

mkrec -s1792k -ffull -r $1 > flash_img

Create an empty 5MB flash partition and append it to our image

mkefs …/src/hardware/ipl/boards/8260ads/8260ads.ffs flash.tmp
cat flash.tmp >>flash_img

Generate a binary image of the IPL code

objcopy --input-format=elf32-powerpc --output-format=binary -R.data
…/src/hardware/ipl/boards/8260ads/ppc/be/ipl-8260ads ipl-8260ads.bin
mkrec -s1M -ffull -r ipl-8260ads.bin >> flash_img
rm ipl-8260ads.bin
rm flash.tmp

create s-record version of flash image

objcopy --input-format=binary --output-format=srec
–adjust-vma=0xff840000 flash_img flash_img.s19

======================================================================

The final line in the shell script generates the file ‘flash_img.s19’.
It is this image that I download to the development board through the
JTAG pod. The JTAG software reads the file and sees that it spans
from 0xff840000 to 0xffffffff (8M - 256k). I write this image starting
at 0xff840000, which is the start of the second flash sector.



Now here is something interesting. When I do a ‘df -kP’ on a working
development board I get the following report…

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/fs 1024 1024 0 100% /dev/fs0p2
/dev/fs0p1 4864 28 4835 1% /fs0p1
/dev/fs0 2048 2048 0 100% /dev/fs0p0
/dev/fs0 8192 8192 0 100%

Because /dev/fs0p0 is 2M in size, I assumed it was into this area that
the OS boot image was being written. I assumed it was 256k of unused
area (the first flash sector) followed by the boot image in the
remaining 1792k. That would make 2M total for the partition and
mirror what I thought I wrote through the JTAG programmer. So, out of
curiosity I used FTP to copy /dev/fs0p0 to a windows machine so I
could have a look. Here is a snippet of what I found…



00008740: 0a4c 6f61 6469 6e67 2051 4e58 362e 2e2e .Loading QNX6…
00008750: 2e0a 0a00 6b65 726e 656c 5f64 6576 6963 …kernel_devic
00008760: 6500 0000 726f 6d00 0000 0000 0000 0040 e…rom…@
00008770: 7fff ffff 0000 0140 0000 0000 0000 0000 …@…
00008780: 0001 0ba4 1000 0000 0001 0c60 0001 0dfc …`…
00008790: 0001 0d48 0000 0000 8000 0000 0000 0001 …H…
000087a0: 7fff ffff 0000 0240 0000 0000 0000 0000 …@…
000087b0: 0001 0eb0 0000 0000 0001 0ec0 0001 0ee0 …
000087c0: 0001 0ecc 0000 0000 0000 0000 0001 0ef4 …
000087d0: 0001 8828 0001 880c 0001 87f0 0001 3504 …(…5.
000087e0: 0001 3c0c 0001 0a28 0001 0aa4 0001 0b28 …<…(…(
000087f0: 7363 6332 5e31 2e35 3736 3030 2e31 3636 scc2^1.57600.166
00008800: 3235 3030 302e 3136 0000 0000 7363 6331 25000.16…scc1
00008810: 5e31 2e35 3736 3030 2e31 3636 3235 3030 ^1.57600.1662500
00008820: 302e 3136 0000 0000 3832 3630 0000 0000 0.16…8260…
00008830: 4144 3a66 3a4b 3a4d 3a4e 3a50 3a52 3a53 AD:f:K:M:N:P:R:S
00008840: 3a76 0000 3832 3630 4144 5300 1820 2428 :v…8260ADS… $(
00008850: 2c00 0000 696f 0000 0000 0000 0000 0000 ,…io…
00008860: ffff 8a8c ffff 8a9c ffff 8a9c ffff 8a78 …x

The scc1, scc2, 57600, etc., appears to be serial port setup stuff
taken from my build script. Anyway, what surprises me is here is
recognizable QNX stuff at address 0x00008740! I really didn’t expect
to see any QNX stuff until after 0x00040000 (256k). Clearly I don’t
understand how /dev/fs0p0 maps onto the physical memory. But I’m
curious, if it doesn’t include the first 256k, why does it span 2MB?



Anyway, I took the new boot image I wanted to load and padded it to 2M
with no starting offset and looked at its hex dump to see how they
compared…

00008670: 2c00 0000 4082 fff8 7c69 1850 4e80 0020 ,…@…|i.PN…
00008680: 0000 0000 0000 0000 0000 0000 0000 0000 …
00008690: 6b65 726e 656c 5f64 6576 6963 6500 0000 kernel_device…
000086a0: 726f 6d00 0000 0000 0000 0040 7fff ffff rom…@…
000086b0: 0000 0140 0000 0000 0000 0000 0001 0afc …@…
000086c0: 1000 0000 0001 0bb8 0001 0d54 0001 0ca0 …T…
000086d0: 0000 0000 8000 0000 0000 0001 7fff ffff …
000086e0: 0000 0240 0000 0000 0000 0000 0001 0e08 …@…
000086f0: 0000 0000 0001 0e18 0001 0e38 0001 0e24 …8…$
00008700: 0000 0000 0000 0000 0001 0e4c 0001 8764 …L…d
00008710: 0001 8748 0001 872c 0001 345c 0001 3b64 …H…,…4…;d
00008720: 0001 0980 0001 09fc 0001 0a80 7363 6332 …scc2
00008730: 5e31 2e35 3736 3030 2e31 3636 3235 3030 ^1.57600.1662500
00008740: 302e 3136 0000 0000 7363 6331 5e31 2e35 0.16…scc1^1.5
00008750: 3736 3030 2e31 3636 3235 3030 302e 3136 7600.16625000.16
00008760: 0000 0000 3832 3630 0000 0000 4144 3a66 …8260…AD:f
00008770: 3a4b 3a4d 3a4e 3a50 3a52 3a53 3a76 0000 :K:M:N:P:R:S:v…
00008780: 3832 3630 4144 5300 1820 2428 2c00 0000 8260ADS… $(,…
00008790: 696f 0000 0000 0000 0000 0000 0000 0000 io…
000087a0: ffff 8aa4 ffff 8ab4 ffff 8ab4 ffff 8a90 …



As you can see, things are not exactly the same but they seem pretty
close both in address and content so I thought maybe I could take my
new image and write it over the top of /dev/fs0p0. I FTPed the image
to the dev board and used ‘cp boot_img /dev/fs0p0’ to copy it to
flash. I didn’t use ‘flashctl’ to erase the partition first. Was
this my problem? At any rate the end result was much the same as
before. Once rebooted, the dev board would spew a couple lines of
garbage characters out the serial port every few seconds but that was
all.

I’m sure there is some key piece or pieces of how this all works that
I’m just not understanding correctly. What am I missing?



Charlie Hubbard
charlieh@innovsys.com

–

Dave Green (dgreen@qnx.com)

QNX Software Systems Ltd.
http://www.qnx.com