problen this porting QNX on ARM based SBC

Andrey · October 2, 2003, 6:41am

Good Day!
We are curently use QNX Neutrino 6.2.1. I try porting Neutrino RTOS on
embedded SBC(single board computer) based on ARM720T-cpucore. Our MCU this
is EP7312 from Cirrus Logic. We have 2Mb flash memory (AM29LV160), and 2Mb
SRAM memory. All my perephiral device’s(UART,timer’s and etc.) are
integrated in MCU chip. phisycal address if see from CPU

Flash: 0x0000000 - 0x00200000
RAM: 0x3000000 - 0x30200000
MCU_Registers 0x8000000 - 0x80004000
IPL-IFS-ARM.bin burned to flash from address 0x00010000

Because QNX currently not support this MCU, I write ‘ipl’ and ‘startup’
itself. I used BSP for Integrator board, like example project. My system
not work, please see on information that printed by my debuging function’s
and that printed by “print_syspage()”.

( I explain some lines by // and follow description what startup programm
doing)

// begin!

QNX IPL for ARM EP7312 based:

Scan_Flash
Scanning flash from 0x00011000 to 0x00012000
Succes QNX OS Image Found! at address: 0x000110DC // from 0x00010000 -
0x000110DC take space IPL
Signature type: 00FF7EEB
Version MKIFS: 00000001
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 30050000
ram_paddr: 30050000
ram_size: 000E3350
startup_size: 0001C108
stored_size: 000E3350
imagefs_paddr: 00000000
imagefs_size: 000C7248
preboot_size: 00000000
info[1]: 00000000
info[2]: 00000000
info[3]: 00000000
info[4]: 00000000
info[5]: 00000000

AFTER IMAGE_SETUP: // this is after calling function
image_setup(image);
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 30050000
ram_paddr: 30050000
ram_size: 000E3350
startup_size: 0001C108
stored_size: 000E3350
imagefs_paddr: 0002D1E4
imagefs_size: 000C7248
preboot_size: 00000000
info[1]: 00000000
info[2]: 00000000
info[3]: 00000000
info[4]: 00000000
info[5]: 00000000
Found image at 0x000110DC
Jumping to startup at 0x30051900

Startup is STARTED
// this is string printed by “startup” by my functions for debug.

// below string’s printed by init_mmu() function

Cache: 512x16 WT
arm720 rev 2 0MHz

// below string’s printed by print_syspage() function

Header size=0x0000009c, Total Size=0x000004d8, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404858 kernel:fc404858 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:3006d000 start addr:fe01c530
ramsize:00200000 pagesize:00001000
Section:qtime offset:0x00000148 size:0x00000048
boot:00000016 CPS:000000000007d000 rate/scale:1953125000/-15 intr:3
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc404680 power:00000000
timer_load:fc4046b0 reload:fc4046f0 value:fc404708
0) display:fc404728 poll:fc404754 break:fc404780

display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x00000190 size:0x00000020
cpu:41807202 flags:40000000 speed:00000000 cache i/d:0/0 name:46
Section:cacheattr offset:0x000004b8 size:0x00000020
flags:13 size:0010 #lines:0200 control:fc4044f8 next:255
Section:meminfo offset:0x00000240 size:0x00000060
t:1 a:30000000 s:00008000 t:1 a:30013878 s:0003c788 t:2 a:3006c108
s:000c7248
t:3 a:3006c108 s:000c7248 t:1 a:30133350 s:000cccb0
Section:asinfo offset:0x00000338 size:0x00000140
0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000
n:21
0000000000000000-0000000000200000 o:0000 a:0005 p:100 c:00000000
n:28
0000000080000000-0000000080004000 o:0000 a:0013 p:100 c:00000000
n:32
0000000080000000-0000000080004000 o:0040 a:0003 p:100 c:00000000
n:39
0000000030000000-00000000301fffff o:0000 a:0017 p:100 c:00000000
n:42
00a0) 000000003006c108-000000003013334f o:0000 a:0005 p:100 c:00000000
n:53
00c0) 000000003006c108-000000003013334f o:0000 a:0007 p:100 c:00000000
n:61
00e0) 0000000030000000-0000000030007fff o:0080 a:0007 p:100 c:00000000
n:69
0000000030013878-000000003004ffff o:0080 a:0007 p:100 c:00000000
n:69
0000000030133350-00000000301fffff o:0080 a:0007 p:100 c:00000000
n:69
Section:hwinfo offset:0x00000310 size:0x00000028
size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002a0 size:0x00000020
off:0 type:5 string:‘arm’
off:12 type:2 string:‘localhost’
Section:strings offset:0x000002c0 size:0x00000050
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘rom’
[32]‘device’
[39]‘io’ [42]‘ram’ [46]‘arm720’ [53]‘imagefs’ [61]‘bootram’ [69]‘sysram’
Section:intrinfo offset:0x00000478 size:0x00000040
vector_base:00000000, #vectors:4, cascade_vector:7fffffff
cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0060, rtn:fc40450c
eoi => flags:1000, size:005c, rtn:fc40456c
mask:fc4045c8, unmask:fc404624, config:00000000
Section:smp offset:0x000004d8 size:0x00000000
Section:boxinfo offset:0x000001b0 size:0x00000028
hw_flags:00000000
Section:cpu offset:0x00000128 size:0x00000020
page_flush:fc4044d8 page_flush_deferred:fc4044ec
upte_ro:00000aae upte_rw:00000ffe
kpte_ro:0000000e kpte_rw:0000055e
mask_nc:0000000c

System page at phys:30013000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

Shutdown[0,0]
0
0 3310 5 cfe

// That’s all . After this, system not respond\print any message.
// I try write application that print string “Hellow from APPLICATION”
// but I can not see any string on hyperterminal.
//
// Some time i see
// Shutdown[0,0]
0
0 3310 5 50
// instead Shutdown[0,0]
0
0 3310 5 cfe
// or Shutdown[0,0]
0
0 3310 5 fe

and see my build file for this IFS and debug info.

###########################################################################

Neutrino on the ARM board

on EP7312 MCU

boot image

###########################################################################

On-board devices:

----------------

#currently section skiped
###########################################################################

To boot using XIP, uncomment the following two lines:

#[image=0x000110DC]
#[ram=0x30050000]

[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-arm
PATH=/proc/boot procnto -vvvv
}
[+script] .script = {

Programs require the runtime linker (ldqnx.so) to be at a fixed location

procmgr_symlink …/…/proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

Initialise the console

this is my serial port resource manager

devc-my_uart

slogger &

Start some common servers

pipe &

Start the main shell

[+session] sh
}

Redirect console messages

[type=link] /dev/console=/dev/ser1

Shared libaries

libc.so

Executables

[data=c]

devc-my_uart
pipe
ls
cat
slogger
sloginfo

Use the “fat” embedded shell as the default shell

sh=fesh

###########################################################################

Interrupt Assignments

---------------------

vector: 0 (_SOFTINT)

trigger: N/A

device: Software interrupt

vector: 1 (_UART0_TX)

trigger: N/A

device: UART 0

vector: 2 (_UART0_RX)

trigger: N/A

device: UART 0

vector: 3 (_TIMER0)

trigger: N/A

device: Timer

###########################################################################

Can You show me errors in debug information or please send me debug info
that print function “print_syspage()” from Integrator BSP, for compare
with my result’s. This is was non-XIP variant IFS. When I try build XIP
variant by use this build file:

###########################################################################

To boot using XIP, uncomment the following two lines:

[image=0x000110DC]
[ram=0x30050000]

#[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-arm
PATH=/proc/boot procnto -vvvv
}

…
…
…

I receive from target this info:

Scan_Flash
Scanning flash from 0x00011000 to 0x00012000
Succes QNX OS Image Found! at address: 0x000110DC
Signature type: 00FF7EEB
Version MKIFS: 00000001
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 000110DC
ram_paddr: 30050000
ram_size: 0001E728
startup_size: 0001C108
stored_size: 000E4350
imagefs_paddr: 00000000
imagefs_size: 000C8248
preboot_size: 00000000

AFTER IMAGE_SETUP:
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 000110DC
ram_paddr: 30050000
ram_size: 0001E728
startup_size: 0001C108
stored_size: 000E4350
imagefs_paddr: 0002D1E4
imagefs_size: 000C8248
preboot_size: 00000000

Found image at 0x000110DC
Jumping to startup at 0x30051900

Startup say HELLOW

Cache: 512x16 WT
arm720 rev 2 0MHz

Header size=0x0000009c, Total Size=0x000004d8, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404858 kernel:fc404858 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:0002e0dc start addr:fe01c530
ramsize:00200000 pagesize:00001000
Section:qtime offset:0x00000148 size:0x00000048
boot:000001a0 CPS:000000000007d000 rate/scale:1953125000/-15 intr:3
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc404680 power:00000000
timer_load:fc4046b0 reload:fc4046f0 value:fc404708
0) display:fc404728 poll:fc404754 break:fc404780

display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x00000190 size:0x00000020
cpu:41807202 flags:40000000 speed:00000000 cache i/d:0/0 name:46
Section:cacheattr offset:0x000004b8 size:0x00000020
flags:13 size:0010 #lines:0200 control:fc4044f8 next:255
Section:meminfo offset:0x00000240 size:0x00000060
t:2 a:0002d1e4 s:000c8248 t:1 a:30000000 s:00008000 t:1 a:30014878
s:0003b788
t:3 a:3006c108 s:00002620 t:1 a:3006e728 s:001918d8
Section:asinfo offset:0x00000338 size:0x00000140
0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000
n:21
0000000000000000-0000000000200000 o:0000 a:0005 p:100 c:00000000
n:28
0000000080000000-0000000080004000 o:0000 a:0013 p:100 c:00000000
n:32
0000000080000000-0000000080004000 o:0040 a:0003 p:100 c:00000000
n:39
0000000030000000-00000000301fffff o:0000 a:0017 p:100 c:00000000
n:42
00a0) 000000000002d1e4-00000000000f542b o:0000 a:0005 p:100 c:00000000
n:53
00c0) 000000003006c108-000000003006e727 o:0000 a:0007 p:100 c:00000000
n:61
00e0) 0000000030000000-0000000030007fff o:0080 a:0007 p:100 c:00000000
n:69
0000000030014878-000000003004ffff o:0080 a:0007 p:100 c:00000000
n:69
000000003006e728-00000000301fffff o:0080 a:0007 p:100 c:00000000
n:69
Section:hwinfo offset:0x00000310 size:0x00000028
size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
size:3 tag:17 isize:3, iname:9, owner:0, kids:0
size:3 tag:17 isize:3, iname:9, owner:0, kids:0
off:0 type:5 string:‘arm’
off:12 type:2 string:‘localhost’
Section:strings offset:0x000002c0 size:0x00000050
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘rom’
[32]‘device’
[39]‘io’ [42]‘ram’ [46]‘arm720’ [53]‘imagefs’ [61]‘bootram’ [69]‘sysram’
Section:intrinfo offset:0x00000478 size:0x00000040
vector_base:00000000, #vectors:4, cascade_vector:7fffffff
cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0060, rtn:fc40450c
eoi => flags:1000, size:005c, rtn:fc40456c
mask:fc4045c8, unmask:fc404624, config:00000000
Section:smp offset:0x000004d8 size:0x00000000
Section:boxinfo offset:0x000001b0 size:0x00000028
hw_flags:00000000
Section:cpu offset:0x00000128 size:0x00000020
page_flush:fc4044d8 page_flush_deferred:fc4044ec
upte_ro:00000aae upte_rw:00000ffe
kpte_ro:0000000e kpte_rw:0000055e
mask_nc:0000000c

System page at phys:30014000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

// That’s all . After this, system not respond\print any message.

Please see on debug info and correct me.
If your need more info I can send source code for you.

Best Regards.!
Andrey.

Dmitri_Poustovalov1 · October 2, 2003, 10:38am

Dave Green wrote:
[skip]

-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O …

Could you please elaborate on how exactly it works? Does ksh detect
/dev/ser# presence and if there is no such device then ksh utilizes
kernel callouts?

Dave_Green1 · October 2, 2003, 1:05pm

Hello Andrey,

The shutdown message you are getting is not too informative; perhaps
putting more -vvv’s after procnto, and also putting some after startup-arm
in your build file might display some more information.

Typical causes of crashes at this point are misconfigured memory (ex. telling
the kernel you have more memory then you really do, or telling it the
wrong address of memory). Misconfigured interrupt callouts can also cause
problems.

I’d suggest the following:

-make sure your init_raminfo() function is specifying RAM correctly; based
on what you’ve said, it should be something like:

add_ram(0x30000000,0x200000);

-make sure you have masked all interrupts in your init_intrinfo() routine,
prior to starting the kernel

-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O - if this works,
it might indicate an interrupt problem…

put some display_msg calls into your build file

Andrey <n_molodov@from.ru> wrote:

Good Day!
We are curently use QNX Neutrino 6.2.1. I try porting Neutrino RTOS on
embedded SBC(single board computer) based on ARM720T-cpucore. Our MCU this
is EP7312 from Cirrus Logic. We have 2Mb flash memory (AM29LV160), and 2Mb
SRAM memory. All my perephiral device’s(UART,timer’s and etc.) are
integrated in MCU chip. phisycal address if see from CPU

Flash: 0x0000000 - 0x00200000
RAM: 0x3000000 - 0x30200000
^^^^^^^^^

this is a typo, right? It’s really 0x30000000 ?

MCU_Registers 0x8000000 - 0x80004000
IPL-IFS-ARM.bin burned to flash from address 0x00010000

Because QNX currently not support this MCU, I write ‘ipl’ and ‘startup’
itself. I used BSP for Integrator board, like example project. My system
not work, please see on information that printed by my debuging function’s
and that printed by “print_syspage()”.

( I explain some lines by // and follow description what startup programm
doing)

// begin!

QNX IPL for ARM EP7312 based:

Scan_Flash
Scanning flash from 0x00011000 to 0x00012000
Succes QNX OS Image Found! at address: 0x000110DC // from 0x00010000 -
0x000110DC take space IPL
Signature type: 00FF7EEB
Version MKIFS: 00000001
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 30050000
ram_paddr: 30050000
ram_size: 000E3350
startup_size: 0001C108
stored_size: 000E3350
imagefs_paddr: 00000000
imagefs_size: 000C7248
preboot_size: 00000000
info[1]: 00000000
info[2]: 00000000
info[3]: 00000000
info[4]: 00000000
info[5]: 00000000

AFTER IMAGE_SETUP: // this is after calling function
image_setup(image);
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 30050000
ram_paddr: 30050000
ram_size: 000E3350
startup_size: 0001C108
stored_size: 000E3350
imagefs_paddr: 0002D1E4
imagefs_size: 000C7248
preboot_size: 00000000
info[1]: 00000000
info[2]: 00000000
info[3]: 00000000
info[4]: 00000000
info[5]: 00000000
Found image at 0x000110DC
Jumping to startup at 0x30051900

Startup is STARTED
// this is string printed by “startup” by my functions for debug.

// below string’s printed by init_mmu() function

Cache: 512x16 WT
arm720 rev 2 0MHz

// below string’s printed by print_syspage() function

Header size=0x0000009c, Total Size=0x000004d8, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404858 kernel:fc404858 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:3006d000 start addr:fe01c530
ramsize:00200000 pagesize:00001000
Section:qtime offset:0x00000148 size:0x00000048
boot:00000016 CPS:000000000007d000 rate/scale:1953125000/-15 intr:3
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc404680 power:00000000
timer_load:fc4046b0 reload:fc4046f0 value:fc404708
0) display:fc404728 poll:fc404754 break:fc404780

display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x00000190 size:0x00000020

cpu:41807202 flags:40000000 speed:00000000 cache i/d:0/0 name:46
Section:cacheattr offset:0x000004b8 size:0x00000020

flags:13 size:0010 #lines:0200 control:fc4044f8 next:255
Section:meminfo offset:0x00000240 size:0x00000060
t:1 a:30000000 s:00008000 t:1 a:30013878 s:0003c788 t:2 a:3006c108
s:000c7248
t:3 a:3006c108 s:000c7248 t:1 a:30133350 s:000cccb0
Section:asinfo offset:0x00000338 size:0x00000140

0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000
n:21

0000000000000000-0000000000200000 o:0000 a:0005 p:100 c:00000000
n:28

0000000080000000-0000000080004000 o:0000 a:0013 p:100 c:00000000
n:32

0000000080000000-0000000080004000 o:0040 a:0003 p:100 c:00000000
n:39

0000000030000000-00000000301fffff o:0000 a:0017 p:100 c:00000000
n:42
00a0) 000000003006c108-000000003013334f o:0000 a:0005 p:100 c:00000000
n:53
00c0) 000000003006c108-000000003013334f o:0000 a:0007 p:100 c:00000000
n:61
00e0) 0000000030000000-0000000030007fff o:0080 a:0007 p:100 c:00000000
n:69

0000000030013878-000000003004ffff o:0080 a:0007 p:100 c:00000000
n:69

0000000030133350-00000000301fffff o:0080 a:0007 p:100 c:00000000
n:69
Section:hwinfo offset:0x00000310 size:0x00000028

size:3 tag:3 isize:3, iname:0, owner:65535, kids:1

size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002a0 size:0x00000020
off:0 type:5 string:‘arm’
off:12 type:2 string:‘localhost’
Section:strings offset:0x000002c0 size:0x00000050
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘rom’
[32]‘device’
[39]‘io’ [42]‘ram’ [46]‘arm720’ [53]‘imagefs’ [61]‘bootram’ [69]‘sysram’
Section:intrinfo offset:0x00000478 size:0x00000040

vector_base:00000000, #vectors:4, cascade_vector:7fffffff
cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0060, rtn:fc40450c
eoi => flags:1000, size:005c, rtn:fc40456c
mask:fc4045c8, unmask:fc404624, config:00000000
Section:smp offset:0x000004d8 size:0x00000000
Section:boxinfo offset:0x000001b0 size:0x00000028
hw_flags:00000000
Section:cpu offset:0x00000128 size:0x00000020
page_flush:fc4044d8 page_flush_deferred:fc4044ec
upte_ro:00000aae upte_rw:00000ffe
kpte_ro:0000000e kpte_rw:0000055e
mask_nc:0000000c

System page at phys:30013000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

Shutdown[0,0]
0
0 3310 5 cfe

// That’s all . After this, system not respond\print any message.
// I try write application that print string “Hellow from APPLICATION”
// but I can not see any string on hyperterminal.
//
// Some time i see
// Shutdown[0,0]
0
0 3310 5 50
// instead Shutdown[0,0]
0
0 3310 5 cfe
// or Shutdown[0,0]
0
0 3310 5 fe

and see my build file for this IFS and debug info.

###########################################################################

Neutrino on the ARM board

on EP7312 MCU

boot image

###########################################################################

On-board devices:

----------------

#currently section skiped
###########################################################################

To boot using XIP, uncomment the following two lines:

#[image=0x000110DC]
#[ram=0x30050000]

[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-arm
PATH=/proc/boot procnto -vvvv
}
[+script] .script = {

Programs require the runtime linker (ldqnx.so) to be at a fixed location

procmgr_symlink …/…/proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

Initialise the console

this is my serial port resource manager

devc-my_uart

slogger &

Start some common servers

pipe &

Start the main shell

[+session] sh
}

Redirect console messages

[type=link] /dev/console=/dev/ser1

Shared libaries

libc.so

Executables

[data=c]

devc-my_uart
pipe
ls
cat
slogger
sloginfo

Use the “fat” embedded shell as the default shell

sh=fesh

###########################################################################

Interrupt Assignments

---------------------

vector: 0 (_SOFTINT)

trigger: N/A

device: Software interrupt

vector: 1 (_UART0_TX)

trigger: N/A

device: UART 0

vector: 2 (_UART0_RX)

trigger: N/A

device: UART 0

vector: 3 (_TIMER0)

trigger: N/A

device: Timer

###########################################################################

Can You show me errors in debug information or please send me debug info
that print function “print_syspage()” from Integrator BSP, for compare
with my result’s. This is was non-XIP variant IFS. When I try build XIP
variant by use this build file:

###########################################################################

To boot using XIP, uncomment the following two lines:

[image=0x000110DC]
[ram=0x30050000]

#[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-arm
PATH=/proc/boot procnto -vvvv
}

…
…
…

I receive from target this info:

Scan_Flash
Scanning flash from 0x00011000 to 0x00012000
Succes QNX OS Image Found! at address: 0x000110DC
Signature type: 00FF7EEB
Version MKIFS: 00000001
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 000110DC
ram_paddr: 30050000
ram_size: 0001E728
startup_size: 0001C108
stored_size: 000E4350
imagefs_paddr: 00000000
imagefs_size: 000C8248
preboot_size: 00000000

AFTER IMAGE_SETUP:
flag1: 00000001
flag2: 00000000
header_size: 00000100
Mashine type: 00000028
startup_vaddr: 30051900
paddr_bias: 00000000
image_paddr: 000110DC
ram_paddr: 30050000
ram_size: 0001E728
startup_size: 0001C108
stored_size: 000E4350
imagefs_paddr: 0002D1E4
imagefs_size: 000C8248
preboot_size: 00000000

Found image at 0x000110DC
Jumping to startup at 0x30051900

Startup say HELLOW

Cache: 512x16 WT
arm720 rev 2 0MHz

Header size=0x0000009c, Total Size=0x000004d8, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404858 kernel:fc404858 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:0002e0dc start addr:fe01c530
ramsize:00200000 pagesize:00001000
Section:qtime offset:0x00000148 size:0x00000048
boot:000001a0 CPS:000000000007d000 rate/scale:1953125000/-15 intr:3
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc404680 power:00000000
timer_load:fc4046b0 reload:fc4046f0 value:fc404708
0) display:fc404728 poll:fc404754 break:fc404780

display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x00000190 size:0x00000020

cpu:41807202 flags:40000000 speed:00000000 cache i/d:0/0 name:46
Section:cacheattr offset:0x000004b8 size:0x00000020

flags:13 size:0010 #lines:0200 control:fc4044f8 next:255
Section:meminfo offset:0x00000240 size:0x00000060
t:2 a:0002d1e4 s:000c8248 t:1 a:30000000 s:00008000 t:1 a:30014878
s:0003b788
t:3 a:3006c108 s:00002620 t:1 a:3006e728 s:001918d8
Section:asinfo offset:0x00000338 size:0x00000140

0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000
n:21

0000000000000000-0000000000200000 o:0000 a:0005 p:100 c:00000000
n:28

0000000080000000-0000000080004000 o:0000 a:0013 p:100 c:00000000
n:32

0000000080000000-0000000080004000 o:0040 a:0003 p:100 c:00000000
n:39

0000000030000000-00000000301fffff o:0000 a:0017 p:100 c:00000000
n:42
00a0) 000000000002d1e4-00000000000f542b o:0000 a:0005 p:100 c:00000000
n:53
00c0) 000000003006c108-000000003006e727 o:0000 a:0007 p:100 c:00000000
n:61
00e0) 0000000030000000-0000000030007fff o:0080 a:0007 p:100 c:00000000
n:69

0000000030014878-000000003004ffff o:0080 a:0007 p:100 c:00000000
n:69

000000003006e728-00000000301fffff o:0080 a:0007 p:100 c:00000000
n:69
Section:hwinfo offset:0x00000310 size:0x00000028

size:3 tag:3 isize:3, iname:0, owner:65535, kids:1

size:3 tag:17 isize:3, iname:9, owner:0, kids:0

size:3 tag:17 isize:3, iname:9, owner:0, kids:0
off:0 type:5 string:‘arm’
off:12 type:2 string:‘localhost’
Section:strings offset:0x000002c0 size:0x00000050
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘rom’
[32]‘device’
[39]‘io’ [42]‘ram’ [46]‘arm720’ [53]‘imagefs’ [61]‘bootram’ [69]‘sysram’
Section:intrinfo offset:0x00000478 size:0x00000040

vector_base:00000000, #vectors:4, cascade_vector:7fffffff
cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0060, rtn:fc40450c
eoi => flags:1000, size:005c, rtn:fc40456c
mask:fc4045c8, unmask:fc404624, config:00000000
Section:smp offset:0x000004d8 size:0x00000000
Section:boxinfo offset:0x000001b0 size:0x00000028
hw_flags:00000000
Section:cpu offset:0x00000128 size:0x00000020
page_flush:fc4044d8 page_flush_deferred:fc4044ec
upte_ro:00000aae upte_rw:00000ffe
kpte_ro:0000000e kpte_rw:0000055e
mask_nc:0000000c

System page at phys:30014000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

// That’s all . After this, system not respond\print any message.

Please see on debug info and correct me.
If your need more info I can send source code for you.

Best Regards.!
Andrey.

\

–

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

Andrey · October 2, 2003, 2:39pm

Thank You very much for answer. This is very helpful for me, now I know
direction for find errors.
Currently I do rechecking\rewriting my ‘stratup’. In future, I say here
about my results.

Typical causes of crashes at this point are misconfigured memory (ex. telling
the kernel you have more memory then you really do, or telling it the
wrong address of memory). Misconfigured interrupt callouts can also cause
problems.

In asinfo section

0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000
n:21

^^^^ Is this correct? Why 00000000ffffffff ?

I’d suggest the following:

-make sure your init_raminfo() function is specifying RAM correctly; based
on what you’ve said, it should be something like:

add_ram(0x30000000,0x200000);

Yes, in init_raminfo() I write this is.

-make sure you have masked all interrupts in your init_intrinfo() routine,
prior to starting the kernel

-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O - if this works,
it might indicate an interrupt problem…

put some display_msg calls into your build file

display_msg use debug callouts ? Or they use ksh which use my debug
callouts ?

MCU_Registers 0x8000000 - 0x80004000
RAM: 0x3000000 - 0x30200000
^^^^^^^^^
this is a typo, right? It’s really
0x30000000 ?

Yes this is typo.

One more thank’s
Andrey.

Dmitri_Poustovalov1 · October 3, 2003, 11:45am

You have to call mmap_device_io() before out32():

#include <hw/inout.h>
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <sys/iofunc.h>
#include <sys/dispatch.h>
#include <errno.h>
#include <sys/neutrino.h>

#define LF_REG_SIZE 32// an assumption
int
main( int argc, char **argv )
{
unsigned phaddr = 0x800022C0; // Led flasher control register
uinotr_t mylf;

ThreadCtl( _NTO_TCTL_IO, NULL );
mylf = mmap_device_io( LF_REG_SIZE, phaddr);
out32(mylf,0x0);
return 0;
}

Andrey wrote:

About My results :
after checking\working on my callout’s code, message about Shutdown is
disappear. But then I try build my RTOS image with my simle application
programm, I can not see result.
Explain:
I have on MCU chip dedicated “LED Flasher” that program by IPL to flashing.
I wont in my applicatin programm turn off this LED flasher by writing
special data(0x00000000) on LED flasher register(0x800022C0).
This is look like this:

#include <hw/inout.h
#include <stdio.h
#include <stdlib.h
#include <stddef.h
#include <sys/iofunc.h
#include <sys/dispatch.h
#include <errno.h
#include <sys/neutrino.h

int
main( int argc, char **argv )
{
int reg = 0x800022C0; // Led flasher control register
ThreadCtl( _NTO_TCTL_IO, NULL );
out32(reg,0x0);
return 0;
}

This programm (Her name led_flasher_off)
I place in RTOS image by this build file:

#################################

Neutrino on the ARM board

on EP7312 MCU

boot image, suitable for copying to flash.

################################

[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-armlcd
PATH=/proc/boot procnto -vvvvvvvvv
}
[+script] .script = {

Programs require the runtime linker (ldqnx.so) to be at a fixed location

procmgr_symlink …/…/proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

led_flasher_off
}

\

Shared libaries

libc.so

Executables

[data=c]
led_flasher_off

###############################

Question about function callout_io_map(); If I do for example

callout_io_map(0x00004000,0x80000000); // all my internal registers

in ‘interrupt_patcher’ (for example), can I neglect

callout_io_map(0x0000100,0x80000200) in ‘timer_patcher’ ?

Or this is bring in error’s for system?

Best Regards! and Thank You for answer’s.

Andrey.

\

Dmitri_Poustovalov1 · October 3, 2003, 12:00pm

Thanks to both of you, guys! Sounds like a very usefull feature for
serial port debugging. It is a pity it is not documented.

QSS should hire RK for writing a follow-up of his “The QNX cookbook”:
something like “How to fix your meal: debugging under QNX.”

bstecher@qnx.com wrote:

Dave Green <> dgreen@qnx.com> > wrote:

Dmitri Poustovalov <> pdmitri@bigfoot.com> > wrote:

Dave Green wrote:
[skip]

-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O …

Could you please elaborate on how exactly it works? Does ksh detect
/dev/ser# presence and if there is no such device then ksh utilizes
kernel callouts?

I don’t know the precise workings of ksh; I do know that any shell
will display characters to the serial port in the absence of a serial
device driver, provided that the display_char kernel callout is
configured correctly. I also know that the ksh, in addition to
displaying characters, will also receive characters from the
serial port, provided the poll_key callout is configured correctly.

There is a “/dev/text” device that when written to, uses the display_char
kernel call to output the data and when read from, uses the poll_key
callout. When the system first boots up, before any “reopen” is
done in the startup script, the standard in/out/error file descriptors
are connected to the “/dev/text” device. That means that ksh (or any other
program) that reads from standard in or writes to standard out will
end up eventually invoking the callout routines. After a “reopen” is
done, the std in/out/err file descriptors are connected to something
else and the callouts won’t be used. You can get input/output via the
callouts at any time by by forcing the issue:

sh </dev/text >/dev/text 2>&1

Dave_Green1 · October 3, 2003, 3:00pm

Dmitri Poustovalov <pdmitri@bigfoot.com> wrote:

Dave Green wrote:
[skip]
-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O …

Could you please elaborate on how exactly it works? Does ksh detect
/dev/ser# presence and if there is no such device then ksh utilizes
kernel callouts?

I don’t know the precise workings of ksh; I do know that any shell
will display characters to the serial port in the absence of a serial
device driver, provided that the display_char kernel callout is
configured correctly. I also know that the ksh, in addition to
displaying characters, will also receive characters from the
serial port, provided the poll_key callout is configured correctly.

\

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

Dave_Green1 · October 3, 2003, 3:12pm

Andrey <n_molodov@fromru.com> wrote:

Thank You very much for answer. This is very helpful for me, now I know
direction for find errors.
Currently I do rechecking\rewriting my ‘stratup’. In future, I say here
about my results.

Typical causes of crashes at this point are misconfigured memory (ex. telling
the kernel you have more memory then you really do, or telling it the
wrong address of memory). Misconfigured interrupt callouts can also cause
problems.

In asinfo section

0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000
n:21

^^^^ Is this correct? Why 00000000ffffffff ?

This is correct. Startup makes a default as_add() call as follows:

unsigned
as_default()
{
return as_add(0, 0xffffffff, AS_ATTR_NONE, “memory”, AS_NULL_OFF);
}

Please refer to the asinfo section of the Building Embedded Systems
documentation for a description of the fields;

http://www.qnx.com/developer/docs/momentics621_docs/neutrino/building/startup.html

I’d suggest the following:

-make sure your init_raminfo() function is specifying RAM correctly; based
on what you’ve said, it should be something like:

add_ram(0x30000000,0x200000);

Yes, in init_raminfo() I write this is.

-make sure you have masked all interrupts in your init_intrinfo() routine,
prior to starting the kernel

-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O - if this works,
it might indicate an interrupt problem…

put some display_msg calls into your build file

display_msg use debug callouts ? Or they use ksh which use my debug
callouts ?

display_msg uses the debug callouts directly, and may be used in the
startup script prior to a shell or serial driver being loaded.

MCU_Registers 0x8000000 - 0x80004000
RAM: 0x3000000 - 0x30200000
^^^^^^^^^
this is a typo, right? It’s really
0x30000000 ?
Yes this is typo.

One more thank’s
Andrey.

–

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

system · October 3, 2003, 3:14pm

Dave Green <dgreen@qnx.com> wrote:

Dmitri Poustovalov <> pdmitri@bigfoot.com> > wrote:
Dave Green wrote:
[skip]
-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O …

Could you please elaborate on how exactly it works? Does ksh detect
/dev/ser# presence and if there is no such device then ksh utilizes
kernel callouts?

I don’t know the precise workings of ksh; I do know that any shell
will display characters to the serial port in the absence of a serial
device driver, provided that the display_char kernel callout is
configured correctly. I also know that the ksh, in addition to
displaying characters, will also receive characters from the
serial port, provided the poll_key callout is configured correctly.

There is a “/dev/text” device that when written to, uses the display_char
kernel call to output the data and when read from, uses the poll_key
callout. When the system first boots up, before any “reopen” is
done in the startup script, the standard in/out/error file descriptors
are connected to the “/dev/text” device. That means that ksh (or any other
program) that reads from standard in or writes to standard out will
end up eventually invoking the callout routines. After a “reopen” is
done, the std in/out/err file descriptors are connected to something
else and the callouts won’t be used. You can get input/output via the
callouts at any time by by forcing the issue:

sh </dev/text >/dev/text 2>&1

–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

Andrey · October 3, 2003, 3:28pm

About My results :
after checking\working on my callout’s code, message about Shutdown is
disappear. But then I try build my RTOS image with my simle application
programm, I can not see result.
Explain:
I have on MCU chip dedicated “LED Flasher” that program by IPL to flashing.
I wont in my applicatin programm turn off this LED flasher by writing
special data(0x00000000) on LED flasher register(0x800022C0).
This is look like this:

#include <hw/inout.h>
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <sys/iofunc.h>
#include <sys/dispatch.h>
#include <errno.h>
#include <sys/neutrino.h>

int
main( int argc, char **argv )
{
int reg = 0x800022C0; // Led flasher control register
ThreadCtl( _NTO_TCTL_IO, NULL );
out32(reg,0x0);
return 0;
}

This programm (Her name led_flasher_off)
I place in RTOS image by this build file:

#################################

Neutrino on the ARM board

on EP7312 MCU

boot image, suitable for copying to flash.

################################

[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-armlcd
PATH=/proc/boot procnto -vvvvvvvvv
}
[+script] .script = {

Programs require the runtime linker (ldqnx.so) to be at a fixed location

procmgr_symlink …/…/proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

led_flasher_off
}

\

Shared libaries

libc.so

Executables

[data=c]
led_flasher_off

###############################

Question about function callout_io_map(); If I do for example

callout_io_map(0x00004000,0x80000000); // all my internal registers

in ‘interrupt_patcher’ (for example), can I neglect

callout_io_map(0x0000100,0x80000200) in ‘timer_patcher’ ?

Or this is bring in error’s for system?

Best Regards! and Thank You for answer’s.

Andrey.

Robert_Krten1 · October 3, 2003, 4:01pm

Dmitri Poustovalov <pdmitri@bigfoot.com> wrote:

Thanks to both of you, guys! Sounds like a very usefull feature for
serial port debugging. It is a pity it is not documented.

QSS should hire RK for writing a follow-up of his “The QNX cookbook”:
something like “How to fix your meal: debugging under QNX.” >

Nah, he’d just say “I use the printf() debugger, good luck with that”
Let me get one book done first before adding more work to my “lunch plate”

Cheers,
-RK

bstecher@qnx.com > wrote:
Dave Green <> dgreen@qnx.com> > wrote:

Dmitri Poustovalov <> pdmitri@bigfoot.com> > wrote:

Dave Green wrote:
[skip]

-don’t start the serial driver yet; instead, use ksh, which will use your
display_char and poll_key debug callouts for console I/O …

Could you please elaborate on how exactly it works? Does ksh detect
/dev/ser# presence and if there is no such device then ksh utilizes
kernel callouts?

I don’t know the precise workings of ksh; I do know that any shell
will display characters to the serial port in the absence of a serial
device driver, provided that the display_char kernel callout is
configured correctly. I also know that the ksh, in addition to
displaying characters, will also receive characters from the
serial port, provided the poll_key callout is configured correctly.

There is a “/dev/text” device that when written to, uses the display_char
kernel call to output the data and when read from, uses the poll_key
callout. When the system first boots up, before any “reopen” is
done in the startup script, the standard in/out/error file descriptors
are connected to the “/dev/text” device. That means that ksh (or any other
program) that reads from standard in or writes to standard out will
end up eventually invoking the callout routines. After a “reopen” is
done, the std in/out/err file descriptors are connected to something
else and the callouts won’t be used. You can get input/output via the
callouts at any time by by forcing the issue:

sh </dev/text >/dev/text 2>&1

–
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/

Andrey · October 3, 2003, 4:12pm

Yes this is very useful for me too! Biggest thank you for info.

Andrey.

Sunil_Kittur1 · October 3, 2003, 5:32pm

Andrey wrote:

Question about function callout_io_map(); If I do for example

callout_io_map(0x00004000,0x80000000); // all my internal registers

in ‘interrupt_patcher’ (for example), can I neglect

callout_io_map(0x0000100,0x80000200) in ‘timer_patcher’ ?

Or this is bring in error’s for system?

Do you mean the assembly patch routines in the callout code?
If so, you need to patch each callout function to supply it
with a usable virtual address for the IO.
You could do this either:

by callout_io_map for each callout. This will allocate a
new virtual address to map the physical address you specify
by keeping track of the virtual address you got from the
first callout_io_map of all your registers, then using that
virtual address to patch all subsequent callouts

If you don’t supply a valid virtual address for the callout
to use you will crash the kernel because your callout code
will cause a fault when it is invoked.

Sunil.

Dave_Green1 · October 3, 2003, 6:49pm

Andrey <n_molodov@fromru.com> wrote:

About My results :
after checking\working on my callout’s code, message about Shutdown is
disappear. But then I try build my RTOS image with my simle application
programm, I can not see result.
Explain:
I have on MCU chip dedicated “LED Flasher” that program by IPL to flashing.
I wont in my applicatin programm turn off this LED flasher by writing
special data(0x00000000) on LED flasher register(0x800022C0).
This is look like this:

#include <hw/inout.h
#include <stdio.h
#include <stdlib.h
#include <stddef.h
#include <sys/iofunc.h
#include <sys/dispatch.h
#include <errno.h
#include <sys/neutrino.h

int
main( int argc, char **argv )
{
int reg = 0x800022C0; // Led flasher control register
ThreadCtl( _NTO_TCTL_IO, NULL );
out32(reg,0x0);
return 0;
}

You need to use mmap_device_io() to get access to this port:

int
main( int argc, char **argv )
{
uintptr_t reg; // Led flasher control register
ThreadCtl( _NTO_TCTL_IO, NULL );

reg = mmap_device_io(4,0x800022c0);
out32(reg,0x0);
return 0;
}

This programm (Her name led_flasher_off)
I place in RTOS image by this build file:

#################################

Neutrino on the ARM board

on EP7312 MCU

boot image, suitable for copying to flash.

################################

[image=0x30050000]
[virtual=armle,srec] .bootstrap = {
startup-armlcd
PATH=/proc/boot procnto -vvvvvvvvv
}
[+script] .script = {

Programs require the runtime linker (ldqnx.so) to be at a fixed location

procmgr_symlink …/…/proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

led_flasher_off
}

Shared libaries

libc.so

Executables

[data=c]
led_flasher_off

###############################

Question about function callout_io_map(); If I do for example

callout_io_map(0x00004000,0x80000000); // all my internal registers

in ‘interrupt_patcher’ (for example), can I neglect

callout_io_map(0x0000100,0x80000200) in ‘timer_patcher’ ?

Or this is bring in error’s for system?

Best Regards! and Thank You for answer’s.

Andrey.

–

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

Andrey · October 6, 2003, 10:46am

Sunil Kittur wrote:

Do you mean the assembly patch routines in the callout code?

Yes I talk about it.

If so, you need to patch each callout function to supply it
with a usable virtual address for the IO.
You could do this either:

by callout_io_map for each callout. This will allocate a
new virtual address to map the physical address you specify

by keeping track of the virtual address you got from the
first callout_io_map of all your registers, then using that
virtual address to patch all subsequent callouts

If you don’t supply a valid virtual address for the callout
to use you will crash the kernel because your callout code
will cause a fault when it is invoked.

Sunil.

But why then we call assembler patcher routine we do ‘callout_io_map’
for all subprogram’s.
Explain on little example based on BSP from Integrador board:

#include “callout.ah”
#include “sbc.h”

/*

Routine to patch callout code
On entry:
r0 - physical address of syspage
r1 - virtual address of syspage
r2 - offset from start of syspage to start of the callout routine
r3 - offset from start of syspage to read/write data used by callout

*/
interrupt_patch:
stmdb sp!,{r4,lr}
add r4, r0, r2 // address of callout routine

/*

Map interrupt controller registers
*/
ldr r0, ARM_INT_REGISTER_SIZE_
// size of interrupt registers
ldr r1, ARM_INT_REGISTER_BASE_
bl callout_io_map

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
// Here I send r0 to terminal by use my debug function
// ‘send_r0’
//
//******************************************
send_r0
//******************************************

/*

Patch the callout routine
*/
CALLOUT_PATCH r4, r0, r1, r2, ip
ldmia sp!,{r4,pc}

ARM_INT_REGISTER_BASE_: .word 0x80000000
ARM_INT_REGISTER_SIZE_: .word 0x00004000

/*

Identify interrupt source.
Returns interrupt number in r4

/
CALLOUT_START(interrupt_id_arm, 0, interrupt_patch)
/

Get the interrupt controller base address (patched)
*/
mov r0, #0x000000ff
orr r0, r0, #0x0000ff00
orr r0, r0, #0x00ff0000
orr r0, r0, #0xff000000

// Here code for take interrupt ID
//
//

CALLOUT_END(interrupt_id_arm)

CALLOUT_START(interrupt_eoi_arm, 0, interrupt_patch)
/*

Get the interrupt controller base address (patched)
*/
mov r0, #0x000000ff
orr r0, r0, #0x0000ff00
orr r0, r0, #0x00ff0000
orr r0, r0, #0xff000000
// Here code for
//
//

CALLOUT_END(interrupt_eoi_arm)

/*

Mask specified interrupt
On entry:
r0 - syspage_ptr
r1 - interrupt number
Returns:
r0 - error status

/
CALLOUT_START(interrupt_mask_arm, 0, interrupt_patch)
/

Get the interrupt controller base address (patched)
*/
mov r0, #0x000000ff
orr r0, r0, #0x0000ff00
orr r0, r0, #0x00ff0000
orr r0, r0, #0xff000000

// Here code
//
//

CALLOUT_END(interrupt_mask_arm)

and so on … all subprogram that must be.

////////////////////////////////////////////
What strange for me, this is that then I see value of r0. r0 was
incremented every time by 0x4000 (i.e. by ARM_INT_REGISTER_SIZE_ =
0x00004000)
look like:
first call for patcher routine (by interrupt_id_arm) :
r0 = 0xFC405000
second call (by interrupt_eoi_arm):
r0 = 0xFC409000
and etc.
This is value then patched to subprogram. What we have:
in first subprogramm:
mov r0, #0x0000000
orr r0, r0, #0x0005000
orr r0, r0, #0x0400000
orr r0, r0, #0xFC00000
in second:
mov r0, #0x0000000
orr r0, r0, #0x0009000
orr r0, r0, #0x0400000
orr r0, r0, #0xFC00000

Why we must every time do new map physycal address(registers) to virtual
address?
I try do only one callout_io_map for ALL internal register’s, how You
advise for me. After receive base virtual address I write it by hand in
all my subprogramm (interrupt, timers, reboot, debug).

Andrey · October 6, 2003, 11:03am

After remake callouts subprogram I have next message from kernel:

#############################################

System page at phys:30013000 user:fc404000 kern:fc404000
Starting next program at vfe01c530

III /// <--------------------- This is my debug info printed in

/// interrupt_unmask callout, this is show where programm
now

Shutdown[0,0] S/C/F=11/1/11 C/D=fe005d7c/fe048500 state(c0)= now lock
[0]PID-TID=1-1? P/T FL=00019001/09000000
armle context[ff7f5f54]:
0000: 00000000 00000000 00000049 00000000 00000100 ff7fdbb0 00000000
ff7f4030
0020: 00000000 fe020eec 00000000 ff7f5fa8 00000000 ff7f5f98 fe023878
fe023878
0040: 600000d3
instruction[fe023878]:
be 30 d4 e1 01 30 43 e2 be 30 c4 e1 be 00 d4 e1 1c 30 9f e5 d0 30 d3 e1 00
00
stack[ff7f5f98]:
0000: ff7fb448 ff7f5fd8 ff7f5fac fe023500 fe0237fc 00000000 00000000
fe0480c4
0020: 00000001 ff7fdbb0 00000000 00000000 00000000 ff7f5fec ff7f5fdc
fe0216b4
0040: fe0233dc ff7fdbb0 ff7f5ffc ff7f5ff0 fe03158c fe021664 ff7f3f6c
ff7f6000
0060: fe01f500 fe031574 ff7fdbb0 00001000 ff7f8038 00000ff8 db89f4de
8e390e31
bbb /// <--------------------- This is my debug info printed in

/// timer_value callout, this is show where programm now

#############################################

After that I think kernel is stopped.
I leave only one interrupt - timer interrupt = 0.
Please help for understand where error’s.

Andrey · October 6, 2003, 11:57am

Some imperfect data in previous my post:

not correct

bbb /// <--------------------- This is my debug info printed in
/// timer_value callout, this is show where programm now

Must Be
bbb /// <--------------------- This is my debug info printed in
/// reboot callout, this is show where programm now

#############################################

This is means that kernel is down.
I think this abnormal operation maybe happen beacose interrupt not work’s
propertly. I nave only one timer interrupt. I can not understand how RTOS
assign my hardware interrupt’s with logical interrupt number. In ARM cpu
architecture when take place exception (for example IRQ), in programm
counter loaded value stored at 0x00000018 physycal address, this is
usually address of subprogramm for determination of source of IRQ.
I think QNX kernel remap this physical address for appropriate virtual
address where stored address of subprogramm for determination source of
IRQ(timer in my case).
That QNX doing than timer IRQ happend? Only call timer reload subprogram?
I can not see my debug info that I send to terminal in this sobprogramm.
This is means that we shutdown early.

Best Regards and Thank You for answer’s.

Andrey

Sunil_Kittur1 · October 6, 2003, 1:50pm

Andrey wrote:

What strange for me, this is that then I see value of r0. r0 was
incremented every time by 0x4000 (i.e. by ARM_INT_REGISTER_SIZE_ =
0x00004000)
look like:
first call for patcher routine (by interrupt_id_arm) :
r0 = 0xFC405000
second call (by interrupt_eoi_arm):
r0 = 0xFC409000
and etc.
This is value then patched to subprogram. What we have:
in first subprogramm:
mov r0, #0x0000000
orr r0, r0, #0x0005000
orr r0, r0, #0x0400000
orr r0, r0, #0xFC00000
in second:
mov r0, #0x0000000
orr r0, r0, #0x0009000
orr r0, r0, #0x0400000
orr r0, r0, #0xFC00000

Why we must every time do new map physycal address(registers) to virtual
address?

The current callout_map_io() implementation doesn’t
keep track of the virtual to physical mappings it has
already given out.

I try do only one callout_io_map for ALL internal register’s, how You
advise for me. After receive base virtual address I write it by hand in
all my subprogramm (interrupt, timers, reboot, debug).

You just have to be careful to not be dependent on any
particular ordering of the generation of the callout
code in the syspage. eg. if you allocate the mapping
before any of the callouts are generated, then just
pass that virtual address to all your patcher routines
(by global variable etc.) you should be OK I think.

Sunil.

Andrey · October 6, 2003, 2:21pm

Sunil Kittur wrote:

You just have to be careful to not be dependent on any
particular ordering of the generation of the callout
code in the syspage. eg. if you allocate the mapping
before any of the callouts are generated, then just
pass that virtual address to all your patcher routines
(by global variable etc.) you should be OK I think.

Yes, for determinate sequence how kernel call patcher routine, I
transmit char to terminal; interrupt_patcher I transmit char ‘I’, in
timer_patcer I transmit char ‘T’.
This is my result about callout patcher sequence:
first kernel call ‘interrupt_patcher’
second ‘reboot_patcher’
then ‘timer_patcher’
then ‘debug_patcher’.
I save my received virtual address after interrupt_patcher in global
variable, and then read this global variable for all others patch’s.

Andrey.

Andrey · October 10, 2003, 7:43am

Every People Who help me - Big Thank You!
I can starting with QNX, I run ksh .

My advise for novice:

Check You callout code more and more!
You must save value of processor’s register’s that come to you in
callouts!
kernel do not save itself this registers, kernel use it for itself and
then you try use this registers in callout and then do not restore they
value - kernel is shutdown.! About in not writing in help documentation.
For patching in arm callouts use ONLY like:
mov r0, #0x000000FF
orr r0,r0, #0x0000FF00
orr r0, r0, #0x00FF0000
orr r0, r0, #0xFF000000

like
mov r0, #0x00000000
orr r0,r0, #0x00005000
orr r0, r0, #0x00400000
orr r0, r0, #0xFC000000
and then this patched don’t work propertly!
4. Use BSP for example, and use USER Manual on it developer’s board for
know about hardware.

One more Big Thank You All .

Andrey.