Using Redboot firmware as QNX bootloader

QNX Newsgroups (Archives) qnx.bsp
1

Hello,

My goal is very simple I need to boot QNX OS from Redboot “level”.

First please note that we have developed IPL and startup code for
the target board. Everything works perfect, but due to some
requirements we must use Redboot in the new project.

So, we have a proper startup code and now it’s time for IFS image
generation, downloading it to target write into flash and finally boot up.

My buildfile is as follows:

[image=0xa0200000]
[virtual=armle,raw] .bootstrap = {
startup-viper -vvvvv
PATH=/proc/boot:/bin LD_LIBRARY_PATH=/usr/lib:/proc/boot procnto -vvvvv
}
[+script] .script = {

display_msg .
display_msg Welcome to QNX Neutrino 6.3.

devc-serpxa250 -e 0x40100000,22 0x40200000,21 0x40700000,20 &
reopen

pipe &

[+session] sh &
}

[perms=0777 uid=0 gid=0]
[type=link] /dev/console = /dev/ser1
[type=link] /bin/sh = /bin/fesh
[type=link] /usr/lib/libc.so.2 = /usr/lib/libc.so
[type=link] /usr/lib/ldqnx.so.2 = /usr/lib/libc.so

[perms=0777 uid=0 gid=0 data=uip code=uip]
/usr/lib/libc.so = libc.so
/bin/pipe = pipe
/bin/pidin = pidin
/bin/fesh = fesh
/bin/devc-ser8250 = devc-ser8250
/bin/devc-serpxa250 = devc-serpxa250

I generate IFS in raw format:
mkifs -v QNX-Redboot.build qnx.img

Offset Size Entry Ramoff Target=Host
a0200000 8 0 —
C:/QNX630/target/qnx6/armle/boot/sys/raw.boot
a0200008 100 ---- — Startup-header
a0200108 b010 a0201c00 — .\s3g4.3
a020b110 5c ---- — Image-header
a020b16c 288 ---- — Image-directory
---- — ---- — usr/lib/ldqnx.so.2=/usr/lib/libc.so
---- — ---- — usr/lib/libc.so.2=/usr/lib/libc.so
---- — ---- — bin/sh=/bin/fesh
---- — ---- — dev/console=/dev/ser1
a020b3f4 e8 ---- — proc/boot/.script=.\s3g4.2
a020c000 51000 fe0203a4 — proc/boot/procnto=.\s3g4.4
a025d000 67000 37ec4 —
usr/lib/libc.so=C:/QNX630/target/qnx6/armle/lib/libc.so
a02c4000 a841 10189c —
bin/devc-serpxa250=C:/QNX630/target/qnx6/armle/sbin/devc-serpxa250
a02cf000 4be0 1013b4 —
bin/pipe=C:/QNX630/target/qnx6/armle/sbin/pipe
a02d4000 d381 101210 —
bin/pidin=C:/QNX630/target/qnx6/armle/bin/pidin
a02e2000 59c2 101354 —
bin/fesh=C:/QNX630/target/qnx6/armle/bin/fesh
a02e8000 ca4e 101c50 —
bin/devc-ser8250=C:/QNX630/target/qnx6/armle/sbin/devc-ser8250
a02f4a50 4 ---- — Image-trailer

Here is a part of Redboot session:

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000
qnx 0x00020000 0x00020000 0x00100000 0x00201C00

RedBoot> load -r -b 0x200000 -m tftp qnx.img

Redboot> fis create qnx
…
…

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000
qnx 0x00020000 0x00200000 0x00100000 0x00200000

Finally I start QNX image in this way:

RedBoot> fis load qnx

RedBoot> exec
Using base address 0x00200000 and length 0x000fc2e0

Dcache: 1024x32 WB
Icache: 1024x32
pxa255 rev 6 399MHz
Header size=0x0000009c, Total Size=0x000005c0, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404a18 kernel:fc404a18 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:a020c000 start addr:fe0203a4
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000170 size:0x00000048
boot:00000000 CPS:0000000000384000 rate/scale:271267361/-15 intr:26
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc4048ac power:fc4048d8
timer_load:fc4048f0 reload:fc404928 value:fc404970
0) display:00000000 poll:00000000 break:00000000

  1. display:00000000 poll:00000000 break:00000000
    Section:cpuinfo offset:0x000001b8 size:0x00000020
  2. cpu:69052d06 flags:40000001 speed:000000c7 cache i/d:1/0 name:62
    Section:cacheattr offset:0x00000580 size:0x00000040
  3. flags:32 size:0020 #lines:0400 control:fc404624 next:255
  4. flags:11 size:0020 #lines:0400 control:fc404670 next:255
    Section:meminfo offset:0x000005c0 size:0x00000000
    Section:asinfo offset:0x00000360 size:0x000001a0
  5. 000000000000ffff-00000000ffffffff o:ffff a:0010 p:100 c:00000000
    n:21
  6. 0000000000000000-0000000000100000 o:0000 a:0005 p:100 c:00000000
    n:28
  7. 0000000004000000-0000000006000000 o:0000 a:0005 p:100 c:00000000
    n:28
  8. 0000000014800000-0000000000040000 o:0000 a:0005 p:100 c:00000000
    n:28
  9. 0000000040000000-0000000008000044 o:0000 a:0013 p:100 c:00000000
    n:32
    00a0) 0000000040000000-0000000008000044 o:0080 a:0003 p:100 c:00000000
    n:39
    00c0) 00000000a0000000-00000000a3ffffff o:0000 a:0017 p:100 c:00000000
    n:42
    00e0) 00000000a020b110-00000000a02fc2df o:0000 a:0005 p:100 c:00000000
    n:69
  10. 00000000a0200008-00000000a020b10f o:0000 a:0007 p:100 c:00000000
    n:77
  11. 00000000a020b110-00000000a02fc2df o:0000 a:0007 p:100 c:00000000
    n:85
  12. 00000000a0000000-00000000a0007fff o:00c0 a:0007 p:100 c:00000000
    n:93
  13. 00000000a0014a38-00000000a0200007 o:00c0 a:0007 p:100 c:00000000
    n:93
  14. 00000000a02fc2e0-00000000a3ffffff o:00c0 a:0007 p:100 c:00000000
    n:93
    Section:hwinfo offset:0x00000308 size:0x00000058
    Section:typed_strings offset:0x00000240 size:0x00000060
    off:0 type:7 string:‘01281021619224’
    off:20 type:2 string:‘localhost’
    Section:strings offset:0x000002a0 size:0x00000068
    [0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘rom’
    [32]‘device’
    [39]‘io’ [42]‘ram’ [46]‘rtc’ [50]‘NONE’ [55]‘Device’ [62]‘pxa255’
    [69]‘imagefs’ [77]‘startup’ [85]‘bootram’ [93]‘sysram’
    Section:intrinfo offset:0x00000500 size:0x00000080
  15. vector_base:00000000, #vectors:32, cascade_vector:7fffffff
    cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
    id => flags:8000, size:0058, rtn:fc404698
    eoi => flags:9000, size:0028, rtn:fc4046f0
    mask:fc404718, unmask:fc404740, config:00000000
  16. vector_base:00000080, #vectors:79, cascade_vector:0000000a
    cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
    id => flags:8000, size:0094, rtn:fc4047a8
    eoi => flags:9000, size:0000, rtn:fc40483c
    mask:fc40483c, unmask:fc404844, config:00000000
    Section:smp offset:0x000005c0 size:0x00000000
    Section:pminfo offset:0x000005c0 size:0x00000000
    Section:mdriver offset:0x000005c0 size:0x00000000
    Section:boxinfo offset:0x00000148 size:0x00000028
    hw_flags:00000000
    Section:cpu offset:0x00000128 size:0x00000020
    page_flush:fc4045e0 page_flush_deferred:fc404620
    upte_ro:0000002f upte_rw:0000007f
    kpte_ro:0000000f kpte_rw:0000005f
    mask_nc:0000004c

System page at phys:a0014000 user:fc404000 kern:fc404000
Starting next program at vfe0203a4

As we see startup code prints contents of the whole system page
and tranfers control to microkernel:

“Starting next program at vfe0203a4”
(the fe0203a4 is entry point to procnto: fe0203a4 —
proc/boot/procnto=.\s3g4.4)

and that’s all. I don’t have an idea why microkernel fails.

Has anybody ever tried to boot QNX from Redboot?
Am I doing something wrong?

Regards,
Jacek

2

Hello,

A few things to check…

-before programming your QNX image into flash, have you verified that the
image works after doing a straight tftp transfer directly to memory? i.e.

redboot> load -r -b 0xa0200000 -m tftp qnx.img
redboot> go 0xa0200000

-when you create your image in flash, you are passing a -e option, which
appears to be the offset of startup_vaddr within the OS image; however,
since you are using a ‘raw’ format image, this shouldn’t be necessary;
if anything, you should pass -e 0x200000 as the entry point; the ‘raw’
header which sits at that offset has a jump instruction to startup_vaddr

-what are you expecting the ‘fis load qnx’ command to do? It should be
copying the OS image from flash (at 0x200000), to DRAM (at 0xa0200000),
and then jumping to the entry point in DRAM, at 0xa0200000. The redboot
docs indicate that there is a -r option to the ‘fis create’ command,
which specifies where the address should be relocated to by the load
command.

Maybe you should be doing something like:

load -r -b 0xa0200000 -m tftp qnx.img

fis create -b 0xa0200000 -f 0x200000 -r 0xa0200000 -n qnx

fis load qnx

go

You’ll need to experiment with the different redboot options, until
you get a sequence that copies the image from flash at 0x200000, to
DRAM at 0xa0200000, and then jumps to the entry point at 0xa0200000.


Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:

Hello,

My goal is very simple I need to boot QNX OS from Redboot “level”.

First please note that we have developed IPL and startup code for
the target board. Everything works perfect, but due to some
requirements we must use Redboot in the new project.

So, we have a proper startup code and now it’s time for IFS image
generation, downloading it to target write into flash and finally boot up.

My buildfile is as follows:

[image=0xa0200000]
[virtual=armle,raw] .bootstrap = {
startup-viper -vvvvv
PATH=/proc/boot:/bin LD_LIBRARY_PATH=/usr/lib:/proc/boot procnto -vvvvv
}
[+script] .script = {

display_msg .
display_msg Welcome to QNX Neutrino 6.3.

devc-serpxa250 -e 0x40100000,22 0x40200000,21 0x40700000,20 &
reopen

pipe &

[+session] sh &
}

[perms=0777 uid=0 gid=0]
[type=link] /dev/console = /dev/ser1
[type=link] /bin/sh = /bin/fesh
[type=link] /usr/lib/libc.so.2 = /usr/lib/libc.so
[type=link] /usr/lib/ldqnx.so.2 = /usr/lib/libc.so

[perms=0777 uid=0 gid=0 data=uip code=uip]
/usr/lib/libc.so = libc.so
/bin/pipe = pipe
/bin/pidin = pidin
/bin/fesh = fesh
/bin/devc-ser8250 = devc-ser8250
/bin/devc-serpxa250 = devc-serpxa250

I generate IFS in raw format:
mkifs -v QNX-Redboot.build qnx.img

Offset Size Entry Ramoff Target=Host
a0200000 8 0 —
C:/QNX630/target/qnx6/armle/boot/sys/raw.boot
a0200008 100 ---- — Startup-header
a0200108 b010 a0201c00 — .\s3g4.3
a020b110 5c ---- — Image-header
a020b16c 288 ---- — Image-directory
---- — ---- — usr/lib/ldqnx.so.2=/usr/lib/libc.so
---- — ---- — usr/lib/libc.so.2=/usr/lib/libc.so
---- — ---- — bin/sh=/bin/fesh
---- — ---- — dev/console=/dev/ser1
a020b3f4 e8 ---- — proc/boot/.script=.\s3g4.2
a020c000 51000 fe0203a4 — proc/boot/procnto=.\s3g4.4
a025d000 67000 37ec4 —
usr/lib/libc.so=C:/QNX630/target/qnx6/armle/lib/libc.so
a02c4000 a841 10189c —
bin/devc-serpxa250=C:/QNX630/target/qnx6/armle/sbin/devc-serpxa250
a02cf000 4be0 1013b4 —
bin/pipe=C:/QNX630/target/qnx6/armle/sbin/pipe
a02d4000 d381 101210 —
bin/pidin=C:/QNX630/target/qnx6/armle/bin/pidin
a02e2000 59c2 101354 —
bin/fesh=C:/QNX630/target/qnx6/armle/bin/fesh
a02e8000 ca4e 101c50 —
bin/devc-ser8250=C:/QNX630/target/qnx6/armle/sbin/devc-ser8250
a02f4a50 4 ---- — Image-trailer

Here is a part of Redboot session:

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000
qnx 0x00020000 0x00020000 0x00100000 0x00201C00

RedBoot> load -r -b 0x200000 -m tftp qnx.img

Redboot> fis create qnx
…
…

RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000
qnx 0x00020000 0x00200000 0x00100000 0x00200000

Finally I start QNX image in this way:

RedBoot> fis load qnx

RedBoot> exec
Using base address 0x00200000 and length 0x000fc2e0

Dcache: 1024x32 WB
Icache: 1024x32
pxa255 rev 6 399MHz
Header size=0x0000009c, Total Size=0x000005c0, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404a18 kernel:fc404a18 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:a020c000 start addr:fe0203a4
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000170 size:0x00000048
boot:00000000 CPS:0000000000384000 rate/scale:271267361/-15 intr:26
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc4048ac power:fc4048d8
timer_load:fc4048f0 reload:fc404928 value:fc404970
0) display:00000000 poll:00000000 break:00000000

  1. display:00000000 poll:00000000 break:00000000
    Section:cpuinfo offset:0x000001b8 size:0x00000020
  2. cpu:69052d06 flags:40000001 speed:000000c7 cache i/d:1/0 name:62
    Section:cacheattr offset:0x00000580 size:0x00000040
  3. flags:32 size:0020 #lines:0400 control:fc404624 next:255
  4. flags:11 size:0020 #lines:0400 control:fc404670 next:255
    Section:meminfo offset:0x000005c0 size:0x00000000
    Section:asinfo offset:0x00000360 size:0x000001a0
  5. 000000000000ffff-00000000ffffffff o:ffff a:0010 p:100 c:00000000
    n:21
  6. 0000000000000000-0000000000100000 o:0000 a:0005 p:100 c:00000000
    n:28
  7. 0000000004000000-0000000006000000 o:0000 a:0005 p:100 c:00000000
    n:28
  8. 0000000014800000-0000000000040000 o:0000 a:0005 p:100 c:00000000
    n:28
  9. 0000000040000000-0000000008000044 o:0000 a:0013 p:100 c:00000000
    n:32
    00a0) 0000000040000000-0000000008000044 o:0080 a:0003 p:100 c:00000000
    n:39
    00c0) 00000000a0000000-00000000a3ffffff o:0000 a:0017 p:100 c:00000000
    n:42
    00e0) 00000000a020b110-00000000a02fc2df o:0000 a:0005 p:100 c:00000000
    n:69
  10. 00000000a0200008-00000000a020b10f o:0000 a:0007 p:100 c:00000000
    n:77
  11. 00000000a020b110-00000000a02fc2df o:0000 a:0007 p:100 c:00000000
    n:85
  12. 00000000a0000000-00000000a0007fff o:00c0 a:0007 p:100 c:00000000
    n:93
  13. 00000000a0014a38-00000000a0200007 o:00c0 a:0007 p:100 c:00000000
    n:93
  14. 00000000a02fc2e0-00000000a3ffffff o:00c0 a:0007 p:100 c:00000000
    n:93
    Section:hwinfo offset:0x00000308 size:0x00000058
    Section:typed_strings offset:0x00000240 size:0x00000060
    off:0 type:7 string:‘01281021619224’
    off:20 type:2 string:‘localhost’
    Section:strings offset:0x000002a0 size:0x00000068
    [0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘rom’
    [32]‘device’
    [39]‘io’ [42]‘ram’ [46]‘rtc’ [50]‘NONE’ [55]‘Device’ [62]‘pxa255’
    [69]‘imagefs’ [77]‘startup’ [85]‘bootram’ [93]‘sysram’
    Section:intrinfo offset:0x00000500 size:0x00000080
  15. vector_base:00000000, #vectors:32, cascade_vector:7fffffff
    cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
    id => flags:8000, size:0058, rtn:fc404698
    eoi => flags:9000, size:0028, rtn:fc4046f0
    mask:fc404718, unmask:fc404740, config:00000000
  16. vector_base:00000080, #vectors:79, cascade_vector:0000000a
    cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
    id => flags:8000, size:0094, rtn:fc4047a8
    eoi => flags:9000, size:0000, rtn:fc40483c
    mask:fc40483c, unmask:fc404844, config:00000000
    Section:smp offset:0x000005c0 size:0x00000000
    Section:pminfo offset:0x000005c0 size:0x00000000
    Section:mdriver offset:0x000005c0 size:0x00000000
    Section:boxinfo offset:0x00000148 size:0x00000028
    hw_flags:00000000
    Section:cpu offset:0x00000128 size:0x00000020
    page_flush:fc4045e0 page_flush_deferred:fc404620
    upte_ro:0000002f upte_rw:0000007f
    kpte_ro:0000000f kpte_rw:0000005f
    mask_nc:0000004c

System page at phys:a0014000 user:fc404000 kern:fc404000
Starting next program at vfe0203a4

As we see startup code prints contents of the whole system page
and tranfers control to microkernel:

“Starting next program at vfe0203a4”
(the fe0203a4 is entry point to procnto: fe0203a4 —
proc/boot/procnto=.\s3g4.4)

and that’s all. I don’t have an idea why microkernel fails.

Has anybody ever tried to boot QNX from Redboot?
Am I doing something wrong?

Regards,
Jacek



–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

3

Dave,

I forgot to tell that Redboot does own memory mappings:

RAM: 0x00000000-0x04000000, [0x000179e8-0x03fd1000] available
FLASH: base 0x60000000, size 0x01000000, 128 blocks of 0x00020000 bytes
each.

So, transfering image to 0x200000 address means that I’m sending it to
physical
memory 0xa0200000. I checked that with hardware debugger and this works ok.

Loading directly to 0xa0200000 ends with Redboot error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? n

-before programming your QNX image into flash, have you verified that the
image works after doing a straight tftp transfer directly to memory? i.e.

redboot> load -r -b 0xa0200000 -m tftp qnx.img
redboot> go 0xa0200000

I tried in this way:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000

RedBoot> go 0x200000
$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b

But unfortunately no luck.

Also the following methods fails:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000
RedBoot> exec 0x200000
Using base address 0x0020+
…
<automatic hardware reset/restart>
…

RedBoot>

-when you create your image in flash, you are passing a -e option, which
appears to be the offset of startup_vaddr within the OS image; however,
since you are using a ‘raw’ format image, this shouldn’t be necessary;
if anything, you should pass -e 0x200000 as the entry point; the ‘raw’
header which sits at that offset has a jump instruction to startup_vaddr

Yes, you are right the raw.boot does this jump for me.

So, the

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx
or
RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x200000 -n qnx

command doesn’t change anything in booting scenario.

-what are you expecting the ‘fis load qnx’ command to do? It should be
copying the OS image from flash (at 0x200000), to DRAM (at 0xa0200000),
and then jumping to the entry point in DRAM, at 0xa0200000. The redboot
docs indicate that there is a -r option to the ‘fis create’ command,
which specifies where the address should be relocated to by the load
command.

Maybe you should be doing something like:

load -r -b 0xa0200000 -m tftp qnx.img

fis create -b 0xa0200000 -f 0x200000 -r 0xa0200000 -n qnx

The fis create -b 0x200000 -f 0x20000 -r 0x200000 -n qnx

does the same as the following sequence:

fis create -f 0x20000 -b 0x200000 -n qnx
load …
fis create qnx


reset

fis load qnx

go

You’ll need to experiment with the different redboot options, until
you get a sequence that copies the image from flash at 0x200000, to
DRAM at 0xa0200000, and then jumps to the entry point at 0xa0200000.

All these steps necessary for proper procnto booting are done.
Also I don’t see any mistakes in my redboot session.

The problem is that QNX microkernel fails at early execution stage.
It even doesn’t crash and prints some dump messages.

There must be something missing in configuration, but I don’t know what.
Very interesting is that QNX boots fine with our IPL.

Redboot is just a “bigger version” of IPL, so OS should boots without
any problems too.

Regards,
Jacek

4

Try “run 0x200000”.


Jacek Rudnicki wrote:

Dave,

I forgot to tell that Redboot does own memory mappings:

RAM: 0x00000000-0x04000000, [0x000179e8-0x03fd1000] available
FLASH: base 0x60000000, size 0x01000000, 128 blocks of 0x00020000 bytes
each.

So, transfering image to 0x200000 address means that I’m sending it to
physical
memory 0xa0200000. I checked that with hardware debugger and this works ok.

Loading directly to 0xa0200000 ends with Redboot error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? n

-before programming your QNX image into flash, have you verified that the
image works after doing a straight tftp transfer directly to memory? i.e.

redboot> load -r -b 0xa0200000 -m tftp qnx.img
redboot> go 0xa0200000

I tried in this way:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000

RedBoot> go 0x200000
$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b

But unfortunately no luck.

Also the following methods fails:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000
RedBoot> exec 0x200000
Using base address 0x0020+
…
automatic hardware reset/restart
…

RedBoot

-when you create your image in flash, you are passing a -e option, which
appears to be the offset of startup_vaddr within the OS image; however,
since you are using a ‘raw’ format image, this shouldn’t be necessary;
if anything, you should pass -e 0x200000 as the entry point; the ‘raw’
header which sits at that offset has a jump instruction to startup_vaddr

Yes, you are right the raw.boot does this jump for me.

So, the

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx
or
RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x200000 -n qnx

command doesn’t change anything in booting scenario.

-what are you expecting the ‘fis load qnx’ command to do? It should be
copying the OS image from flash (at 0x200000), to DRAM (at 0xa0200000),
and then jumping to the entry point in DRAM, at 0xa0200000. The redboot
docs indicate that there is a -r option to the ‘fis create’ command,
which specifies where the address should be relocated to by the load
command.

Maybe you should be doing something like:

load -r -b 0xa0200000 -m tftp qnx.img

fis create -b 0xa0200000 -f 0x200000 -r 0xa0200000 -n qnx

The fis create -b 0x200000 -f 0x20000 -r 0x200000 -n qnx

does the same as the following sequence:

fis create -f 0x20000 -b 0x200000 -n qnx
load …
fis create qnx


reset

fis load qnx

go

You’ll need to experiment with the different redboot options, until
you get a sequence that copies the image from flash at 0x200000, to
DRAM at 0xa0200000, and then jumps to the entry point at 0xa0200000.

All these steps necessary for proper procnto booting are done.
Also I don’t see any mistakes in my redboot session.

The problem is that QNX microkernel fails at early execution stage.
It even doesn’t crash and prints some dump messages.

There must be something missing in configuration, but I don’t know what.
Very interesting is that QNX boots fine with our IPL.

Redboot is just a “bigger version” of IPL, so OS should boots without
any problems too.

Regards,
Jacek

5

My Redboot doesn’t have “run” command.
It was probably disabled by vendor.

Jacek


Try “run 0x200000”.


Jacek Rudnicki wrote:
Dave,

I forgot to tell that Redboot does own memory mappings:

RAM: 0x00000000-0x04000000, [0x000179e8-0x03fd1000] available
FLASH: base 0x60000000, size 0x01000000, 128 blocks of 0x00020000 bytes
each.

So, transfering image to 0x200000 address means that I’m sending it to
physical
memory 0xa0200000. I checked that with hardware debugger and this works
ok.

Loading directly to 0xa0200000 ends with Redboot error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? n

-before programming your QNX image into flash, have you verified that
the
image works after doing a straight tftp transfer directly to memory?
i.e.

redboot> load -r -b 0xa0200000 -m tftp qnx.img
redboot> go 0xa0200000

I tried in this way:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000

RedBoot> go 0x200000
$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b

But unfortunately no luck.

Also the following methods fails:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000
RedBoot> exec 0x200000
Using base address 0x0020+
…
automatic hardware reset/restart
…

RedBoot

-when you create your image in flash, you are passing a -e option, which
appears to be the offset of startup_vaddr within the OS image; however,
since you are using a ‘raw’ format image, this shouldn’t be necessary;
if anything, you should pass -e 0x200000 as the entry point; the ‘raw’
header which sits at that offset has a jump instruction to startup_vaddr

Yes, you are right the raw.boot does this jump for me.

So, the

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx
or
RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x200000 -n qnx

command doesn’t change anything in booting scenario.

-what are you expecting the ‘fis load qnx’ command to do? It should be
copying the OS image from flash (at 0x200000), to DRAM (at 0xa0200000),
and then jumping to the entry point in DRAM, at 0xa0200000. The redboot
docs indicate that there is a -r option to the ‘fis create’ command,
which specifies where the address should be relocated to by the load
command.

Maybe you should be doing something like:

load -r -b 0xa0200000 -m tftp qnx.img

fis create -b 0xa0200000 -f 0x200000 -r 0xa0200000 -n qnx

The fis create -b 0x200000 -f 0x20000 -r 0x200000 -n qnx

does the same as the following sequence:

fis create -f 0x20000 -b 0x200000 -n qnx
load …
fis create qnx


reset

fis load qnx

go

You’ll need to experiment with the different redboot options, until
you get a sequence that copies the image from flash at 0x200000, to
DRAM at 0xa0200000, and then jumps to the entry point at 0xa0200000.

All these steps necessary for proper procnto booting are done.
Also I don’t see any mistakes in my redboot session.

The problem is that QNX microkernel fails at early execution stage.
It even doesn’t crash and prints some dump messages.

There must be something missing in configuration, but I don’t know what.
Very interesting is that QNX boots fine with our IPL.

Redboot is just a “bigger version” of IPL, so OS should boots without
any problems too.

Regards,
Jacek

6

Then use “help” to see which command is to run program with
MMU disabled. Our startup expects the MMU is disabled, or 1-1
mapping if MMU is enabled.

Jacek Rudnicki wrote:

My Redboot doesn’t have “run” command.
It was probably disabled by vendor.

Jacek


Try “run 0x200000”.


Jacek Rudnicki wrote:
Dave,

I forgot to tell that Redboot does own memory mappings:

RAM: 0x00000000-0x04000000, [0x000179e8-0x03fd1000] available
FLASH: base 0x60000000, size 0x01000000, 128 blocks of 0x00020000 bytes
each.

So, transfering image to 0x200000 address means that I’m sending it to
physical
memory 0xa0200000. I checked that with hardware debugger and this works
ok.

Loading directly to 0xa0200000 ends with Redboot error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? n

-before programming your QNX image into flash, have you verified that
the
image works after doing a straight tftp transfer directly to memory?
i.e.

redboot> load -r -b 0xa0200000 -m tftp qnx.img
redboot> go 0xa0200000
I tried in this way:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000

RedBoot> go 0x200000
$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b

But unfortunately no luck.

Also the following methods fails:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000
RedBoot> exec 0x200000
Using base address 0x0020+
…
automatic hardware reset/restart
…

RedBoot

-when you create your image in flash, you are passing a -e option, which
appears to be the offset of startup_vaddr within the OS image; however,
since you are using a ‘raw’ format image, this shouldn’t be necessary;
if anything, you should pass -e 0x200000 as the entry point; the ‘raw’
header which sits at that offset has a jump instruction to startup_vaddr
Yes, you are right the raw.boot does this jump for me.

So, the

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx
or
RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x200000 -n qnx

command doesn’t change anything in booting scenario.

-what are you expecting the ‘fis load qnx’ command to do? It should be
copying the OS image from flash (at 0x200000), to DRAM (at 0xa0200000),
and then jumping to the entry point in DRAM, at 0xa0200000. The redboot
docs indicate that there is a -r option to the ‘fis create’ command,
which specifies where the address should be relocated to by the load
command.

Maybe you should be doing something like:

load -r -b 0xa0200000 -m tftp qnx.img

fis create -b 0xa0200000 -f 0x200000 -r 0xa0200000 -n qnx
The fis create -b 0x200000 -f 0x20000 -r 0x200000 -n qnx

does the same as the following sequence:

fis create -f 0x20000 -b 0x200000 -n qnx
load …
fis create qnx


reset

fis load qnx

go

You’ll need to experiment with the different redboot options, until
you get a sequence that copies the image from flash at 0x200000, to
DRAM at 0xa0200000, and then jumps to the entry point at 0xa0200000.
All these steps necessary for proper procnto booting are done.
Also I don’t see any mistakes in my redboot session.

The problem is that QNX microkernel fails at early execution stage.
It even doesn’t crash and prints some dump messages.

There must be something missing in configuration, but I don’t know what.
Very interesting is that QNX boots fine with our IPL.

Redboot is just a “bigger version” of IPL, so OS should boots without
any problems too.

Regards,
Jacek

7

Jacek Rudnicki <jacek.rudnicki@quantum.com.pl> wrote:

Dave,

I forgot to tell that Redboot does own memory mappings:

RAM: 0x00000000-0x04000000, [0x000179e8-0x03fd1000] available
FLASH: base 0x60000000, size 0x01000000, 128 blocks of 0x00020000 bytes
each.

If this is the case, then all of the ‘fis create’ commands that you have
been issuing are to RAM addresses, not flash addresses; if you want to
put the image in flash, you should be passing addresses to the -f options
which are in the range of the flash, i.e. -f 0x60000000.

Is there any way to turn off this remapping in redboot, and deal with
flash and DRAM at their actual physical addresses? Re-mapping things
seems unnecessary. At what point does this re-mapping “go away”? Or does
it remain even after redboot transfers control to the next program? If this
is the case, then you’ll need to change your build file (actually, your entire
BSP) to suit the redboot memory map.

We have used redboot to successfully load raw QNX images on several different
platforms, and nothing special needed to be done to the OS image to make it
work with redboot. Mind you, I’ve never encountered a version of redboot that
re-maps things in this fashion…

I’d forget about loading an image from flash for the time being, and
concentrate on simply doing a tftp image transfer directly to DRAM, and
getting the image to run. But first, I’d see if the Redboot re-mapping can
be turned off…

So, transfering image to 0x200000 address means that I’m sending it to
physical
memory 0xa0200000. I checked that with hardware debugger and this works ok.

Loading directly to 0xa0200000 ends with Redboot error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? n

What happens if you override, and enter ‘y’ ?

-before programming your QNX image into flash, have you verified that the
image works after doing a straight tftp transfer directly to memory? i.e.

redboot> load -r -b 0xa0200000 -m tftp qnx.img
redboot> go 0xa0200000

I tried in this way:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000

RedBoot> go 0x200000
$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b$T0a0f:001c20a0;0d:ec0ffd03;#6b

But unfortunately no luck.

Also the following methods fails:

RedBoot> load -r -b 0x200000 -m tftp qnx.img
Raw file loaded 0x00200000-0x002f4a53, assumed entry at 0x00200000
RedBoot> exec 0x200000
Using base address 0x0020+
…
automatic hardware reset/restart
…

RedBoot

-when you create your image in flash, you are passing a -e option, which
appears to be the offset of startup_vaddr within the OS image; however,
since you are using a ‘raw’ format image, this shouldn’t be necessary;
if anything, you should pass -e 0x200000 as the entry point; the ‘raw’
header which sits at that offset has a jump instruction to startup_vaddr

Yes, you are right the raw.boot does this jump for me.

So, the

RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x201c00 -n qnx
or
RedBoot> fis create -f 0x20000 -l 0xfffff - b 0x200000 -e 0x200000 -n qnx

command doesn’t change anything in booting scenario.

-what are you expecting the ‘fis load qnx’ command to do? It should be
copying the OS image from flash (at 0x200000), to DRAM (at 0xa0200000),
and then jumping to the entry point in DRAM, at 0xa0200000. The redboot
docs indicate that there is a -r option to the ‘fis create’ command,
which specifies where the address should be relocated to by the load
command.

Maybe you should be doing something like:

load -r -b 0xa0200000 -m tftp qnx.img

fis create -b 0xa0200000 -f 0x200000 -r 0xa0200000 -n qnx

The fis create -b 0x200000 -f 0x20000 -r 0x200000 -n qnx

does the same as the following sequence:

fis create -f 0x20000 -b 0x200000 -n qnx
load …
fis create qnx



reset

fis load qnx

go

You’ll need to experiment with the different redboot options, until
you get a sequence that copies the image from flash at 0x200000, to
DRAM at 0xa0200000, and then jumps to the entry point at 0xa0200000.

All these steps necessary for proper procnto booting are done.
Also I don’t see any mistakes in my redboot session.

The problem is that QNX microkernel fails at early execution stage.
It even doesn’t crash and prints some dump messages.

There must be something missing in configuration, but I don’t know what.
Very interesting is that QNX boots fine with our IPL.

Redboot is just a “bigger version” of IPL, so OS should boots without
any problems too.

Regards,
Jacek

–

David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com

8

Dave,

If this is the case, then all of the ‘fis create’ commands that you have
been issuing are to RAM addresses, not flash addresses; if you want to

Not exactly. Flash memory is managed by Flash Image System (FIS) created
in user flash area by redboot.

Here is a list of FIS partitions:

RedBoot> fis list
Name FLASH addr Mem addr Length Entry
point
FIS directory 0x00000000 0x00000000 0x0001F000 0x00000000
RedBoot config 0x0001F000 0x0001F000 0x00001000 0x00000000
qnx 0x00020000 0x00200000 0x00100000 0x00200000

and rest free space of the16MB flash device:

RedBoot> fis free
0x00120000 … 0x01000000

put the image in flash, you should be passing addresses to the -f options
which are in the range of the flash, i.e. -f 0x60000000.

A correct address for -f option should be situated inside 0x0 – 0x1000000
offset.
Otherwise redboot will print the following error message:

RedBoot> load …
RedBoot> fis create -f 0x60000000 -b 0x200000 -r 0x200000 -e 0x200000 -l
0xfffff -n qnx
Invalid FLASH offset 0x60000000: Invalid FLASH address
maximum offset is 0x01000000
RedBoot>

I checked contents of the user flash and
fis create -f 0x20000 -b 0x200000 -r 0x200000 -e 0x200000 -l 0xfffff -n qnx
command really writes QNX image into it.

Assuming I have QNX image in flash, then I load it to DRAM (fis load qnx)
and run (exec).

Am I doing something wrong ? The starup code is executed fine, so why
kernel fails?

Is there any way to turn off this remapping in redboot, and deal with
flash and DRAM at their actual physical addresses? Re-mapping things
seems unnecessary. At what point does this re-mapping “go away”? Or does
it remain even after redboot transfers control to the next program? If
this
is the case, then you’ll need to change your build file (actually, your
entire
BSP) to suit the redboot memory map.

We have used redboot to successfully load raw QNX images on several
different
platforms, and nothing special needed to be done to the OS image to make
it
work with redboot. Mind you, I’ve never encountered a version of redboot
that
re-maps things in this fashion…

I’d forget about loading an image from flash for the time being, and
concentrate on simply doing a tftp image transfer directly to DRAM, and
getting the image to run. But first,

Unfortunately just after image transfer to DRAM both redboot commands:
‘go’ and ‘exec’ crash.

I’d see if the Redboot re-mapping can be turned off…

I’m not sure. Probably we will have to work with the Redboot as it is.

Loading directly to 0xa0200000 ends with Redboot error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? n

What happens if you override, and enter ‘y’ ?

Nothing special, redboot prints another error message:

RedBoot> load -r -b 0xa0200000 -m tftp qnx.img
Specified address (0xa0200000) is not believed to be in RAM - continue
(y/n)? y
** command abort - illegal memory access?
RedBoot>

Jacek