Help with sandpoint (PPC 8245) BSP

John_Kiernan1 · August 5, 2004, 6:57pm

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board, but
booting only got to where the kernel starts. (no messages from kernel)

So we decided to just work on our custom board. We’ve changed the BSP
with a few minor changes (Address of COM port, etc…), and we get the
same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and nothing
happens. (We have added the verbosity options (many vvv’s) on both the
startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

Header size=0x0000009c, Total Size=0x00000610, #Cpu=1, Type=1
Section:system_private offset:0x000001c0 size:0x00000068
syspage ptr user:0000c000 kernel:0000c000
cpupage ptr user:0000d000 kernel:0000d000 spacing:4096
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:001ff000 start addr:00221964
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000158 size:0x00000048
boot:00000000 CPS:00000000017d7840 rate/scale:4/-8 intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c8a8 power:00000000
timer_load:0000c914 reload:0000c930 value:0000c97c
0) display:0000c98c poll:0000c9d4 break:0000ca28

display:0000ca70 poll:0000cab8 break:0000cb0c
Section:cpuinfo offset:0x000001a0 size:0x00000020
cpu:80811014 flags:c0000110 speed:0000012c cache i/d:1/0 name:51
Section:cacheattr offset:0x000005d0 size:0x00000040
flags:22 size:0020 #lines:0200 control:0000c618 next:255
flags:01 size:0020 #lines:0200 control:0000c668 next:255
Section:meminfo offset:0x00000610 size:0x00000000
Section:asinfo offset:0x00000390 size:0x00000180
0000000000000000-00000000ffffffff o:ffff a:0010 p:100
c:00000000 n:21
0000000080000000-00000000febfffff o:0000 a:0013 p:100
c:00000000 n:28
0000000080000000-00000000febfffff o:0020 a:0003 p:100
c:00000000 n:35
00000000ff800000-00000000ffffffff o:0000 a:0005 p:100
c:00000000 n:38
0000000000000000-0000000007ffffff o:0000 a:0017 p:100
c:00000000 n:42
00a0) 0000000030000000-000000003003ffff o:0000 a:0003 p:100
c:00000000 n:46
00c0) 00000000001fe108-0000000000305aaf o:0000 a:0005 p:100
c:00000000 n:105
00e0) 00000000001f0000-00000000001fe107 o:0000 a:0007 p:100
c:00000000 n:113
00000000001fe108-0000000000305aaf o:0000 a:0007 p:100
c:00000000 n:121
0000000000003000-000000000000afff o:0080 a:0007 p:100
c:00000000 n:129
000000000000e000-00000000001fe107 o:0080 a:0007 p:100
c:00000000 n:129
0000000000305ab0-0000000007ffffff o:0080 a:0007 p:100
c:00000000 n:129
Section:hwinfo offset:0x000002d8 size:0x000000b8
size:3 tag:3 isize:3, iname:0, owner:65535, kids:2
size:3 tag:17 isize:3, iname:9, owner:0, kids:1
size:3 tag:17 isize:3, iname:56, owner:0, kids:1
size:4 tag:60 isize:11, iname:51, owner:24, kids:0
00 00 00 00
size:1 tag:67
size:6 tag:71
00 01 00 00 00 00 00 00 fe ff 00 00 00 00 ff ff 00 00 00 00
size:3 tag:3 isize:3, iname:80, owner:12, kids:1
size:4 tag:60 isize:15, iname:87, owner:80, kids:0
00 00 00 00
size:3 tag:92
01 7d 78 40 00 00 00 10
size:2 tag:101
00 00 00 0d
size:6 tag:71
00 00 00 08 00 00 00 00 fc 00 45 00 00 00 00 40 00 00 00 00
Section:typed_strings offset:0x00000228 size:0x00000020
off:0 type:5 string:‘RTMIO’
off:12 type:2 string:‘localhost’
Section:strings offset:0x00000248 size:0x00000090
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘device’
[35]‘io’
[38]‘rom’ [42]‘ram’ [46]‘immr’ [51]‘8245’ [56]‘pci’ [60]‘Device’
[67]‘pad’
[71]‘location’ [80]‘serial’ [87]‘8250’ [92]‘inputclk’ [101]‘irq’
[105]‘imagefs’ [113]‘startup’ [121]‘bootram’ [129]‘sysram’
Section:intrinfo offset:0x00000510 size:0x000000c0
vector_base:00000000, #vectors:16, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0400, size:0020, rtn:0000c694
eoi => flags:0400, size:0014, rtn:0000c6b4
mask:0000c6c8, unmask:0000c7a4, config:00000000
vector_base:80000000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000240, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0004, rtn:0000c880
eoi => flags:0000, size:0000, rtn:0000c884
mask:0000c884, unmask:0000c88c, config:00000000
vector_base:80001000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:000003c0, cpu_intr_stride:0, flags:0002
id => flags:0000, size:0004, rtn:0000c894
eoi => flags:0000, size:0000, rtn:0000c898
mask:0000c898, unmask:0000c8a0, config:00000000
Section:smp offset:0x00000610 size:0x00000000
Section:pminfo offset:0x00000610 size:0x00000000
Section:mdriver offset:0x00000610 size:0x00000000
Section:boxinfo offset:0x00000610 size:0x00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000, asid_bits:00000000
Section:smpinfo offset:0x00000610 size:0x00000000
Section:tlbinfo offset:0x00000610 size:0x00000000
qnx-rtmio-startup completed, ready to start kernel.

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964

Jay_Greig1 · August 5, 2004, 7:39pm

Hi John.

Could you please post:

build file
OS version

and are you booting from the IPL or from another loader (ie. DINK)?

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board, but
booting only got to where the kernel starts. (no messages from kernel)

So we decided to just work on our custom board. We’ve changed the BSP
with a few minor changes (Address of COM port, etc…), and we get the
same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and nothing
happens. (We have added the verbosity options (many vvv’s) on both the
startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

Header size=0x0000009c, Total Size=0x00000610, #Cpu=1, Type=1
Section:system_private offset:0x000001c0 size:0x00000068
syspage ptr user:0000c000 kernel:0000c000
cpupage ptr user:0000d000 kernel:0000d000 spacing:4096
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:001ff000 start addr:00221964
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000158 size:0x00000048
boot:00000000 CPS:00000000017d7840 rate/scale:4/-8 intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c8a8 power:00000000
timer_load:0000c914 reload:0000c930 value:0000c97c
0) display:0000c98c poll:0000c9d4 break:0000ca28

display:0000ca70 poll:0000cab8 break:0000cb0c
Section:cpuinfo offset:0x000001a0 size:0x00000020

cpu:80811014 flags:c0000110 speed:0000012c cache i/d:1/0 name:51
Section:cacheattr offset:0x000005d0 size:0x00000040

flags:22 size:0020 #lines:0200 control:0000c618 next:255

flags:01 size:0020 #lines:0200 control:0000c668 next:255
Section:meminfo offset:0x00000610 size:0x00000000
Section:asinfo offset:0x00000390 size:0x00000180

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

0000000080000000-00000000febfffff o:0000 a:0013 p:100 c:00000000
n:28

0000000080000000-00000000febfffff o:0020 a:0003 p:100 c:00000000
n:35

00000000ff800000-00000000ffffffff o:0000 a:0005 p:100 c:00000000
n:38

0000000000000000-0000000007ffffff o:0000 a:0017 p:100 c:00000000
n:42
00a0) 0000000030000000-000000003003ffff o:0000 a:0003 p:100 c:00000000
n:46
00c0) 00000000001fe108-0000000000305aaf o:0000 a:0005 p:100 c:00000000
n:105
00e0) 00000000001f0000-00000000001fe107 o:0000 a:0007 p:100 c:00000000
n:113

00000000001fe108-0000000000305aaf o:0000 a:0007 p:100 c:00000000
n:121

0000000000003000-000000000000afff o:0080 a:0007 p:100 c:00000000
n:129

000000000000e000-00000000001fe107 o:0080 a:0007 p:100 c:00000000
n:129

0000000000305ab0-0000000007ffffff o:0080 a:0007 p:100 c:00000000
n:129
Section:hwinfo offset:0x000002d8 size:0x000000b8

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

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

size:3 tag:17 isize:3, iname:56, owner:0, kids:1

size:4 tag:60 isize:11, iname:51, owner:24, kids:0
00 00 00 00

size:1 tag:67

size:6 tag:71
00 01 00 00 00 00 00 00 fe ff 00 00 00 00 ff ff 00 00 00 00

size:3 tag:3 isize:3, iname:80, owner:12, kids:1

size:4 tag:60 isize:15, iname:87, owner:80, kids:0
00 00 00 00

size:3 tag:92
01 7d 78 40 00 00 00 10

size:2 tag:101
00 00 00 0d

size:6 tag:71
00 00 00 08 00 00 00 00 fc 00 45 00 00 00 00 40 00 00 00 00
Section:typed_strings offset:0x00000228 size:0x00000020
off:0 type:5 string:‘RTMIO’
off:12 type:2 string:‘localhost’
Section:strings offset:0x00000248 size:0x00000090
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘device’
[35]‘io’
[38]‘rom’ [42]‘ram’ [46]‘immr’ [51]‘8245’ [56]‘pci’ [60]‘Device’
[67]‘pad’
[71]‘location’ [80]‘serial’ [87]‘8250’ [92]‘inputclk’ [101]‘irq’
[105]‘imagefs’ [113]‘startup’ [121]‘bootram’ [129]‘sysram’
Section:intrinfo offset:0x00000510 size:0x000000c0

vector_base:00000000, #vectors:16, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0400, size:0020, rtn:0000c694
eoi => flags:0400, size:0014, rtn:0000c6b4
mask:0000c6c8, unmask:0000c7a4, config:00000000

vector_base:80000000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000240, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0004, rtn:0000c880
eoi => flags:0000, size:0000, rtn:0000c884
mask:0000c884, unmask:0000c88c, config:00000000

vector_base:80001000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:000003c0, cpu_intr_stride:0, flags:0002
id => flags:0000, size:0004, rtn:0000c894
eoi => flags:0000, size:0000, rtn:0000c898
mask:0000c898, unmask:0000c8a0, config:00000000
Section:smp offset:0x00000610 size:0x00000000
Section:pminfo offset:0x00000610 size:0x00000000
Section:mdriver offset:0x00000610 size:0x00000000
Section:boxinfo offset:0x00000610 size:0x00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000, asid_bits:00000000
Section:smpinfo offset:0x00000610 size:0x00000000
Section:tlbinfo offset:0x00000610 size:0x00000000
qnx-rtmio-startup completed, ready to start kernel.

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964

John_Kiernan1 · August 5, 2004, 7:45pm

Jay Greig wrote:

Hi John.

Could you please post:

build file
Yeah, I’m using the IDE, so I attached the project.bld file.

OS version
6.3

and are you booting from the IPL or from another loader (ie. DINK)?
With the Sandpoint we were using DINK, with our board we have a similar

type custom loader. We’re porting from VxWorks, and our loader and
hardware work fine with VxWorks.

Thanks

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board, but
booting only got to where the kernel starts. (no messages from kernel)

So we decided to just work on our custom board. We’ve changed the BSP
with a few minor changes (Address of COM port, etc…), and we get the
same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and
nothing happens. (We have added the verbosity options (many vvv’s) on
both the startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

Header size=0x0000009c, Total Size=0x00000610, #Cpu=1, Type=1
Section:system_private offset:0x000001c0 size:0x00000068
syspage ptr user:0000c000 kernel:0000c000
cpupage ptr user:0000d000 kernel:0000d000 spacing:4096
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:001ff000 start addr:00221964
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000158 size:0x00000048
boot:00000000 CPS:00000000017d7840 rate/scale:4/-8 intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c8a8 power:00000000
timer_load:0000c914 reload:0000c930 value:0000c97c
0) display:0000c98c poll:0000c9d4 break:0000ca28

display:0000ca70 poll:0000cab8 break:0000cb0c
Section:cpuinfo offset:0x000001a0 size:0x00000020

cpu:80811014 flags:c0000110 speed:0000012c cache i/d:1/0 name:51
Section:cacheattr offset:0x000005d0 size:0x00000040

flags:22 size:0020 #lines:0200 control:0000c618 next:255

flags:01 size:0020 #lines:0200 control:0000c668 next:255
Section:meminfo offset:0x00000610 size:0x00000000
Section:asinfo offset:0x00000390 size:0x00000180

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

0000000080000000-00000000febfffff o:0000 a:0013 p:100
c:00000000 n:28

0000000080000000-00000000febfffff o:0020 a:0003 p:100
c:00000000 n:35

00000000ff800000-00000000ffffffff o:0000 a:0005 p:100
c:00000000 n:38

0000000000000000-0000000007ffffff o:0000 a:0017 p:100
c:00000000 n:42
00a0) 0000000030000000-000000003003ffff o:0000 a:0003 p:100
c:00000000 n:46
00c0) 00000000001fe108-0000000000305aaf o:0000 a:0005 p:100
c:00000000 n:105
00e0) 00000000001f0000-00000000001fe107 o:0000 a:0007 p:100
c:00000000 n:113

00000000001fe108-0000000000305aaf o:0000 a:0007 p:100
c:00000000 n:121

0000000000003000-000000000000afff o:0080 a:0007 p:100
c:00000000 n:129

000000000000e000-00000000001fe107 o:0080 a:0007 p:100
c:00000000 n:129

0000000000305ab0-0000000007ffffff o:0080 a:0007 p:100
c:00000000 n:129
Section:hwinfo offset:0x000002d8 size:0x000000b8

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

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

size:3 tag:17 isize:3, iname:56, owner:0, kids:1

size:4 tag:60 isize:11, iname:51, owner:24, kids:0
00 00 00 00

size:1 tag:67

size:6 tag:71
00 01 00 00 00 00 00 00 fe ff 00 00 00 00 ff ff 00 00 00 00

size:3 tag:3 isize:3, iname:80, owner:12, kids:1

size:4 tag:60 isize:15, iname:87, owner:80, kids:0
00 00 00 00

size:3 tag:92
01 7d 78 40 00 00 00 10

size:2 tag:101
00 00 00 0d

size:6 tag:71
00 00 00 08 00 00 00 00 fc 00 45 00 00 00 00 40 00 00 00 00
Section:typed_strings offset:0x00000228 size:0x00000020
off:0 type:5 string:‘RTMIO’
off:12 type:2 string:‘localhost’
Section:strings offset:0x00000248 size:0x00000090
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘device’
[35]‘io’
[38]‘rom’ [42]‘ram’ [46]‘immr’ [51]‘8245’ [56]‘pci’ [60]‘Device’
[67]‘pad’
[71]‘location’ [80]‘serial’ [87]‘8250’ [92]‘inputclk’ [101]‘irq’
[105]‘imagefs’ [113]‘startup’ [121]‘bootram’ [129]‘sysram’
Section:intrinfo offset:0x00000510 size:0x000000c0

vector_base:00000000, #vectors:16, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0400, size:0020, rtn:0000c694
eoi => flags:0400, size:0014, rtn:0000c6b4
mask:0000c6c8, unmask:0000c7a4, config:00000000

vector_base:80000000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000240, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0004, rtn:0000c880
eoi => flags:0000, size:0000, rtn:0000c884
mask:0000c884, unmask:0000c88c, config:00000000

vector_base:80001000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:000003c0, cpu_intr_stride:0, flags:0002
id => flags:0000, size:0004, rtn:0000c894
eoi => flags:0000, size:0000, rtn:0000c898
mask:0000c898, unmask:0000c8a0, config:00000000
Section:smp offset:0x00000610 size:0x00000000
Section:pminfo offset:0x00000610 size:0x00000000
Section:mdriver offset:0x00000610 size:0x00000000
Section:boxinfo offset:0x00000610 size:0x00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000, asid_bits:00000000
Section:smpinfo offset:0x00000610 size:0x00000000
Section:tlbinfo offset:0x00000610 size:0x00000000
qnx-rtmio-startup completed, ready to start kernel.

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964

Jay_Greig1 · August 5, 2004, 8:24pm

Ok, that looks fine. In your .bsh file, do you have a ‘display_msg’
before the serial driver starts? If so, and you’re not seeing it, means
that your debug callouts are not working on the board. Or, if you don’t
have a ‘display_msg’ line before the serial driver, try adding one
similar to:

display_msg debug callouts working

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Hi John.

Could you please post:

build file

Yeah, I’m using the IDE, so I attached the project.bld file.

OS version

6.3

and are you booting from the IPL or from another loader (ie. DINK)?

With the Sandpoint we were using DINK, with our board we have a similar
type custom loader. We’re porting from VxWorks, and our loader and
hardware work fine with VxWorks.

Thanks

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board, but
booting only got to where the kernel starts. (no messages from kernel)

So we decided to just work on our custom board. We’ve changed the
BSP with a few minor changes (Address of COM port, etc…), and we get
the same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and
nothing happens. (We have added the verbosity options (many vvv’s)
on both the startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

Header size=0x0000009c, Total Size=0x00000610, #Cpu=1, Type=1
Section:system_private offset:0x000001c0 size:0x00000068
syspage ptr user:0000c000 kernel:0000c000
cpupage ptr user:0000d000 kernel:0000d000 spacing:4096
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:001ff000 start addr:00221964
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000158 size:0x00000048
boot:00000000 CPS:00000000017d7840 rate/scale:4/-8 intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c8a8 power:00000000
timer_load:0000c914 reload:0000c930 value:0000c97c
0) display:0000c98c poll:0000c9d4 break:0000ca28

display:0000ca70 poll:0000cab8 break:0000cb0c
Section:cpuinfo offset:0x000001a0 size:0x00000020

cpu:80811014 flags:c0000110 speed:0000012c cache i/d:1/0 name:51
Section:cacheattr offset:0x000005d0 size:0x00000040

flags:22 size:0020 #lines:0200 control:0000c618 next:255

flags:01 size:0020 #lines:0200 control:0000c668 next:255
Section:meminfo offset:0x00000610 size:0x00000000
Section:asinfo offset:0x00000390 size:0x00000180

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

0000000080000000-00000000febfffff o:0000 a:0013 p:100
c:00000000 n:28

0000000080000000-00000000febfffff o:0020 a:0003 p:100
c:00000000 n:35

00000000ff800000-00000000ffffffff o:0000 a:0005 p:100
c:00000000 n:38

0000000000000000-0000000007ffffff o:0000 a:0017 p:100
c:00000000 n:42
00a0) 0000000030000000-000000003003ffff o:0000 a:0003 p:100
c:00000000 n:46
00c0) 00000000001fe108-0000000000305aaf o:0000 a:0005 p:100
c:00000000 n:105
00e0) 00000000001f0000-00000000001fe107 o:0000 a:0007 p:100
c:00000000 n:113

00000000001fe108-0000000000305aaf o:0000 a:0007 p:100
c:00000000 n:121

0000000000003000-000000000000afff o:0080 a:0007 p:100
c:00000000 n:129

000000000000e000-00000000001fe107 o:0080 a:0007 p:100
c:00000000 n:129

0000000000305ab0-0000000007ffffff o:0080 a:0007 p:100
c:00000000 n:129
Section:hwinfo offset:0x000002d8 size:0x000000b8

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

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

size:3 tag:17 isize:3, iname:56, owner:0, kids:1

size:4 tag:60 isize:11, iname:51, owner:24, kids:0
00 00 00 00

size:1 tag:67

size:6 tag:71
00 01 00 00 00 00 00 00 fe ff 00 00 00 00 ff ff 00 00 00 00

size:3 tag:3 isize:3, iname:80, owner:12, kids:1

size:4 tag:60 isize:15, iname:87, owner:80, kids:0
00 00 00 00

size:3 tag:92
01 7d 78 40 00 00 00 10

size:2 tag:101
00 00 00 0d

size:6 tag:71
00 00 00 08 00 00 00 00 fc 00 45 00 00 00 00 40 00 00 00 00
Section:typed_strings offset:0x00000228 size:0x00000020
off:0 type:5 string:‘RTMIO’
off:12 type:2 string:‘localhost’
Section:strings offset:0x00000248 size:0x00000090
[0]‘hw’ [3]‘Group’ [9]‘unknown’ [17]‘Bus’ [21]‘memory’ [28]‘device’
[35]‘io’
[38]‘rom’ [42]‘ram’ [46]‘immr’ [51]‘8245’ [56]‘pci’ [60]‘Device’
[67]‘pad’
[71]‘location’ [80]‘serial’ [87]‘8250’ [92]‘inputclk’ [101]‘irq’
[105]‘imagefs’ [113]‘startup’ [121]‘bootram’ [129]‘sysram’
Section:intrinfo offset:0x00000510 size:0x000000c0

vector_base:00000000, #vectors:16, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0400, size:0020, rtn:0000c694
eoi => flags:0400, size:0014, rtn:0000c6b4
mask:0000c6c8, unmask:0000c7a4, config:00000000

vector_base:80000000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000240, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0004, rtn:0000c880
eoi => flags:0000, size:0000, rtn:0000c884
mask:0000c884, unmask:0000c88c, config:00000000

vector_base:80001000, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:000003c0, cpu_intr_stride:0, flags:0002
id => flags:0000, size:0004, rtn:0000c894
eoi => flags:0000, size:0000, rtn:0000c898
mask:0000c898, unmask:0000c8a0, config:00000000
Section:smp offset:0x00000610 size:0x00000000
Section:pminfo offset:0x00000610 size:0x00000000
Section:mdriver offset:0x00000610 size:0x00000000
Section:boxinfo offset:0x00000610 size:0x00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000, asid_bits:00000000
Section:smpinfo offset:0x00000610 size:0x00000000
Section:tlbinfo offset:0x00000610 size:0x00000000
qnx-rtmio-startup completed, ready to start kernel.

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964

\

?xml version=“1.0” encoding=“UTF-8”?

!-- QNX System Builder –

buildfile major=“1” minor=“0” micro=“0”
images
image
addr=“0x1f0000”
keepLinked=“false”
autoLink=“true”
name=“bsp-qnx-rtmio” type=“ifs” subType="" pageAligned=“false” compressed=“false” enabled=“true” stripTimeStamps=“false” cpu=“ppcbe” dirPerms=“0777” dirGID=“0” dirUID=“0”
boot name=“binary”
type=“virtual”
/boot
startup name=“WORKSPACE/qnx-rtmio_startup-sandpoint/sandpoint/ppc/be/startup-sandpoint”
args="-D0xfc004500^0.115200.100000000.16 -K0xfc004500^0.115200.100000000.16 -vvvvvvvvvvvv"
/startup
proc name=“procnto-600”
args="-vvvvvvvvvvvvvvv -h"
path=":/proc/boot:/bin:/usr/bin"
ldpath=":/proc/boot:/lib:/usr/lib:/lib/dll"
/proc
bootscript type=“mkifs” inline=“false”
bsp-qnx-rtmio.bsh </bootscript
/image
/images

items
item type=“symlink”
name=“sh”
image=“bsp-qnx-rtmio”
location="/bin"
link="/proc/boot/esh"
/item
item type=“symlink”
name=“console”
image=“bsp-qnx-rtmio”
location="/dev"
link="/dev/ser1"
/item
item type=“symlink”
name=“tmp”
image=“bsp-qnx-rtmio”
location="/"
link="/dev/shmem"
/item
item type=“shlib”
name=“libc.so”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“true”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“devc-ser8250”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=“WORKSPACE/qnx-rtmio_devc-ser8250/ser8250/ppc/be/devc-ser8250”
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“pci-sandpoint”
enabled=“false”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=“WORKSPACE/qnx-rtmio_pci-sandpoint/sandpoint/ppc/be/pci-sandpoint”
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“pci”
enabled=“false”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“ls”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“esh”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“pipe”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“pidin”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“uname”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“slogger”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“sloginfo”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
item type=“binary”
name=“slay”
enabled=“true”
image=“bsp-qnx-rtmio”
location="/proc/boot"
buildpath=""
data_uip=“false”
code_uip=“true”
uid=“0”
gid=“0”
optional=“true”
perms=“0777”
raw=“false”/
/items

/buildfile

John_Kiernan1 · August 5, 2004, 8:25pm

Jay Greig wrote:

Ok, that looks fine. In your .bsh file, do you have a ‘display_msg’
before the serial driver starts? If so, and you’re not seeing it, means
that your debug callouts are not working on the board. Or, if you don’t
have a ‘display_msg’ line before the serial driver, try adding one
similar to:

display_msg debug callouts working

I do have a display_msg in the .bsh file…and I commented out the

serial stuff to see if that was causing a problem. Should the kernel
display any other messages before the point of the shell script?
Is there a way to determine what is not working?

BSH file below:

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

display_msg Welcome to QNX Neutrino 6.3 on the RTMIO

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

SERIAL driver

#######################################################################
#devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,104 0xfe0002f8,103
#waitfor /dev/ser1
#reopen /dev/ser1

slogger
pipe

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

PCI server

#######################################################################
#display_msg Starting PCI server…

#pci-sandpoint
#waitfor /dev/pci 4

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

These env variables are inherited by all the programs which follow

#######################################################################
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib

[+session] esh &

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Hi John.

Could you please post:

build file

Yeah, I’m using the IDE, so I attached the project.bld file.

OS version

6.3

and are you booting from the IPL or from another loader (ie. DINK)?

With the Sandpoint we were using DINK, with our board we have a
similar type custom loader. We’re porting from VxWorks, and our
loader and hardware work fine with VxWorks.

Thanks

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board,
but booting only got to where the kernel starts. (no messages from
kernel)

So we decided to just work on our custom board. We’ve changed the
BSP with a few minor changes (Address of COM port, etc…), and we
get the same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and
nothing happens. (We have added the verbosity options (many vvv’s)
on both the startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:
snip

Jay_Greig1 · August 6, 2004, 2:48pm

John,

Stepping back a bit to the Sandpoint problems you mentioned (since
that’s the hardware we have here), I downloaded an image via DINK to the
board equipped with a 8240 CPU and I had no problems. What revision of
Sandpoint do you have? The one I tested on was a PPCEVAL_SP3 Rev X3.
We currently do not support the PPCEVAL_SP3 Rev X3B.

But as for where to start looking for code to modify, have a look at:

src/hardware/startup/lib/ppc/callout_debug_8250.s

This file defines how the debug callouts work for the 8250 UART.

Hope this helps,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Ok, that looks fine. In your .bsh file, do you have a ‘display_msg’
before the serial driver starts? If so, and you’re not seeing it,
means that your debug callouts are not working on the board. Or, if
you don’t have a ‘display_msg’ line before the serial driver, try
adding one similar to:

display_msg debug callouts working

I do have a display_msg in the .bsh file…and I commented out the
serial stuff to see if that was causing a problem. Should the kernel
display any other messages before the point of the shell script?
Is there a way to determine what is not working?

BSH file below:

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

display_msg Welcome to QNX Neutrino 6.3 on the RTMIO

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

SERIAL driver

#######################################################################
#devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,104 0xfe0002f8,103
#waitfor /dev/ser1
#reopen /dev/ser1

slogger
pipe

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

PCI server

#######################################################################
#display_msg Starting PCI server…

#pci-sandpoint
#waitfor /dev/pci 4

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

These env variables are inherited by all the programs which follow

#######################################################################
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib

[+session] esh &

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Hi John.

Could you please post:

build file

Yeah, I’m using the IDE, so I attached the project.bld file.

OS version

6.3

and are you booting from the IPL or from another loader (ie. DINK)?

With the Sandpoint we were using DINK, with our board we have a
similar type custom loader. We’re porting from VxWorks, and our
loader and hardware work fine with VxWorks.

Thanks

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board,
but booting only got to where the kernel starts. (no messages from
kernel)

So we decided to just work on our custom board. We’ve changed the
BSP with a few minor changes (Address of COM port, etc…), and we
get the same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and
nothing happens. (We have added the verbosity options (many vvv’s)
on both the startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

snip

John_Kiernan1 · August 6, 2004, 5:00pm

Jay Greig wrote:

John,

Stepping back a bit to the Sandpoint problems you mentioned (since
that’s the hardware we have here), I downloaded an image via DINK to the
board equipped with a 8240 CPU and I had no problems. What revision of
Sandpoint do you have? The one I tested on was a PPCEVAL_SP3 Rev X3. We
currently do not support the PPCEVAL_SP3 Rev X3B.
The motherboard is a M98SP_X2 Rev G, and the proc board is a

8240 PMC Unity X4 Rev A1
We kind of gave up debugging the problem here because if we’re going to
debug the problem, we might as well debug it on our board.

But as for where to start looking for code to modify, have a look at:

src/hardware/startup/lib/ppc/callout_debug_8250.s

This is where we are looking now.

As a debugging step, we changed the display_char_8250 function to just
write a single char to the UART address (0xfc004500) and stop. (turning
off address translation first)

Nothing prints, implying that the callout never gets called!?

i.e.

li %r3,0
mtmsr %r3
isync

li %r3,0x0c00
mtspr 1008,%r3
isync

li %r4,‘C’
lis %r3,0xfc00
stb %r4,0x4500(%r3)

b $

This file defines how the debug callouts work for the 8250 UART.

Hope this helps,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Ok, that looks fine. In your .bsh file, do you have a ‘display_msg’
before the serial driver starts? If so, and you’re not seeing it,
means that your debug callouts are not working on the board. Or, if
you don’t have a ‘display_msg’ line before the serial driver, try
adding one similar to:

display_msg debug callouts working

I do have a display_msg in the .bsh file…and I commented out the
serial stuff to see if that was causing a problem. Should the kernel
display any other messages before the point of the shell script?
Is there a way to determine what is not working?

BSH file below:

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

display_msg Welcome to QNX Neutrino 6.3 on the RTMIO

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

SERIAL driver

#######################################################################
#devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,104 0xfe0002f8,103
#waitfor /dev/ser1
#reopen /dev/ser1

slogger
pipe

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

PCI server

#######################################################################
#display_msg Starting PCI server…

#pci-sandpoint
#waitfor /dev/pci 4

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

These env variables are inherited by all the programs which follow

#######################################################################
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib

[+session] esh &

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Hi John.

Could you please post:

build file

Yeah, I’m using the IDE, so I attached the project.bld file.

OS version

6.3

and are you booting from the IPL or from another loader (ie. DINK)?

With the Sandpoint we were using DINK, with our board we have a
similar type custom loader. We’re porting from VxWorks, and our
loader and hardware work fine with VxWorks.

Thanks

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board,
but booting only got to where the kernel starts. (no messages from
kernel)

So we decided to just work on our custom board. We’ve changed the
BSP with a few minor changes (Address of COM port, etc…), and we
get the same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and
nothing happens. (We have added the verbosity options (many
vvv’s) on both the startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

snip

Jay_Greig1 · August 6, 2004, 6:49pm

John,

Chances are that the callout is being called (unless you explicitly
removed it from the callout list), but there may be something extra you
need to do in your callout.

Have a look in the “Building Embedded Systems” book in the help
documentation, chapter 5 “Customizing Image Startup Programs”, section
“Writing your own kernel callout”. There is a sub-section called
‘“Patching” the callout code’ which may be what you’re looking for.

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

John,

Stepping back a bit to the Sandpoint problems you mentioned (since
that’s the hardware we have here), I downloaded an image via DINK to
the board equipped with a 8240 CPU and I had no problems. What
revision of Sandpoint do you have? The one I tested on was a
PPCEVAL_SP3 Rev X3. We currently do not support the PPCEVAL_SP3 Rev X3B.

The motherboard is a M98SP_X2 Rev G, and the proc board is a
8240 PMC Unity X4 Rev A1
We kind of gave up debugging the problem here because if we’re going to
debug the problem, we might as well debug it on our board. >

But as for where to start looking for code to modify, have a look at:

src/hardware/startup/lib/ppc/callout_debug_8250.s

This is where we are looking now.
As a debugging step, we changed the display_char_8250 function to just
write a single char to the UART address (0xfc004500) and stop. (turning
off address translation first)

Nothing prints, implying that the callout never gets called!?

i.e.

li %r3,0
mtmsr %r3
isync

li %r3,0x0c00
mtspr 1008,%r3
isync

li %r4,‘C’
lis %r3,0xfc00
stb %r4,0x4500(%r3)

b $

This file defines how the debug callouts work for the 8250 UART.

Hope this helps,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Ok, that looks fine. In your .bsh file, do you have a ‘display_msg’
before the serial driver starts? If so, and you’re not seeing it,
means that your debug callouts are not working on the board. Or, if
you don’t have a ‘display_msg’ line before the serial driver, try
adding one similar to:

display_msg debug callouts working

I do have a display_msg in the .bsh file…and I commented out the
serial stuff to see if that was causing a problem. Should the kernel
display any other messages before the point of the shell script?
Is there a way to determine what is not working?

BSH file below:

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

display_msg Welcome to QNX Neutrino 6.3 on the RTMIO

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

SERIAL driver

#######################################################################
#devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,104 0xfe0002f8,103
#waitfor /dev/ser1
#reopen /dev/ser1

slogger
pipe

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

PCI server

#######################################################################
#display_msg Starting PCI server…

#pci-sandpoint
#waitfor /dev/pci 4

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

These env variables are inherited by all the programs which follow

#######################################################################
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib

[+session] esh &

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

Hi John.

Could you please post:

build file

Yeah, I’m using the IDE, so I attached the project.bld file.

OS version

6.3

and are you booting from the IPL or from another loader (ie. DINK)?

With the Sandpoint we were using DINK, with our board we have a
similar type custom loader. We’re porting from VxWorks, and our
loader and hardware work fine with VxWorks.

Thanks

Thanks,
-Jay.

John Kiernan wrote:

Hi,
We have a custom board that uses an PPC 8245. We also have a
“sandpoint” development platform that uses a PPC 8240.

We’ve first tried the “Sandpoint BSP” on the Sandpoint dev board,
but booting only got to where the kernel starts. (no messages
from kernel)

So we decided to just work on our custom board. We’ve changed
the BSP with a few minor changes (Address of COM port, etc…),
and we get the same results…

The start-up code executes to completion and prints out lots of
debugging information… Then the kernel attempts to start and
nothing happens. (We have added the verbosity options (many
vvv’s) on both the startup and kernel.)

Is there anyway to determine whats going wrong?
The output is below:

snip

Dave_Green1 · August 6, 2004, 7:12pm

Jay Greig <greig@qnx.com> wrote:

John Kiernan wrote:

Jay Greig wrote:

John,

Chances are that the callout is being called (unless you explicitly
removed it from the callout list), but there may be something extra
you need to do in your callout.

Have a look in the “Building Embedded Systems” book in the help
documentation, chapter 5 “Customizing Image Startup Programs”, section
“Writing your own kernel callout”. There is a sub-section called
‘“Patching” the callout code’ which may be what you’re looking for.

Thanks,
-Jay.

I did read the section your referring to, I’m really not writing my own
callout though, I don’t think that should be necessary. The standard
write_char_8250 should work on our board with out any problems…
That’s is the one I’m trying to use anyway. I’m assuming that the
standard callout works , so I’m thinking that I have something else
not set up properly.

Not necessarily true - one of our developers is struggling through the
debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d offer
more suggestions once he figured it out.

The existing callout does work, on all the boards that we’ve tested it on…

I’ve figured my issue out, for the most part. The following code in the
callout checks whether data translation should be on while accessing
the devices:

lhz %r9,SYSPAGE_PPC_KERINFO(%r3)
add %r9,%r9,%r3
lwz %r9,KERINFO_TS_CLEAR(%r9)

The bit that’s being checked (PPC_MSR_DR) is turned on by default in the startup
library, for all CPU’s, and then, in the ppcv_cpuinfo_** entries, it’s
cleared again, for those CPU families that can leave translation on.
For the CPU family I’m working with (PPC 700), the bit wasn’t being cleared,
so translation was being turned off, and the callout wasn’t working. I added
an entry to a local copy of ppcv_cpuconfig_700 to clear the bit, rebuilt
my startup, and now everything is working.

That said, if you’re using an 8240, I see that in ppcv_cpuconfig_8200.c
in the startup library, this bit is already being cleared… as a quick
test to see if this is your problem (or if you have the opposite problem),
you could copy the ppcv_cpuconfig_8200.c file from the startup library into
your local startup directory, comment out the following line:

lsp.cpu.ppc_kerinfo.p->callout_ts_clear &= ~PPC_MSR_DS;

and then re-build your startup (with the stock callout_debug_8250.s, not
the one you’ve modified).

If this still doesn’t resolve the problem, then I’d second Jay’s suggestion,
of going back to the Sandpoint board first, and figure out why that’s not
working… our Sandpoint BSP on a Sandpoint board should just work, so if
it’s not, the problem might be something more fundamental.

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

John,

Stepping back a bit to the Sandpoint problems you mentioned (since
that’s the hardware we have here), I downloaded an image via DINK to
the board equipped with a 8240 CPU and I had no problems. What
revision of Sandpoint do you have? The one I tested on was a
PPCEVAL_SP3 Rev X3. We currently do not support the PPCEVAL_SP3 Rev
X3B.

The motherboard is a M98SP_X2 Rev G, and the proc board is a
8240 PMC Unity X4 Rev A1
We kind of gave up debugging the problem here because if we’re going
to debug the problem, we might as well debug it on our board. >

But as for where to start looking for code to modify, have a look at:

src/hardware/startup/lib/ppc/callout_debug_8250.s

This is where we are looking now.
As a debugging step, we changed the display_char_8250 function to
just write a single char to the UART address (0xfc004500) and stop.
(turning off address translation first)

Nothing prints, implying that the callout never gets called!?

i.e.

li %r3,0
mtmsr %r3
isync

li %r3,0x0c00
mtspr 1008,%r3
isync

li %r4,‘C’
lis %r3,0xfc00
stb %r4,0x4500(%r3)

b $

snip

–

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

Dave_Green1 · August 6, 2004, 7:15pm

John Kiernan <jkiernan@birinc.com> wrote:

You know, I hate when things like this happen…Like I said it the
callout should work…I’ve changed back some of the stuff we added
for debugging…, and now I get:

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964
Welcome to QNX Neutrino 6.3 on the RTMIO

Good stuff…

HOWEVER, I can’t input anything…(I’m very happy to see the prompt
though > > )

Any ideas of why input doesn’t work? Maybe interrupt related?

possibly… you might also try turning off hardware flow control
on your host’s terminal session.

John Kiernan wrote:

Jay Greig wrote:
Not necessarily true - one of our developers is struggling through the

debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d
offer more suggestions once he figured it out.

Thanks,
-Jay.

We’ll I hope he figures it out! > > Because we’re starting to scratch
our heads here, because it does look like the callout should work.

Thanks,
John

–

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

John_Kiernan1 · August 6, 2004, 7:22pm

Jay Greig wrote:

John,

Chances are that the callout is being called (unless you explicitly
removed it from the callout list), but there may be something extra you
need to do in your callout.

Have a look in the “Building Embedded Systems” book in the help
documentation, chapter 5 “Customizing Image Startup Programs”, section
“Writing your own kernel callout”. There is a sub-section called
‘“Patching” the callout code’ which may be what you’re looking for.

Thanks,
-Jay.

I did read the section your referring to, I’m really not writing my own
callout though, I don’t think that should be necessary. The standard
write_char_8250 should work on our board with out any problems…
That’s is the one I’m trying to use anyway. I’m assuming that the
standard callout works , so I’m thinking that I have something else
not set up properly.

John Kiernan wrote:

Jay Greig wrote:

John,

Stepping back a bit to the Sandpoint problems you mentioned (since
that’s the hardware we have here), I downloaded an image via DINK to
the board equipped with a 8240 CPU and I had no problems. What
revision of Sandpoint do you have? The one I tested on was a
PPCEVAL_SP3 Rev X3. We currently do not support the PPCEVAL_SP3 Rev X3B.

The motherboard is a M98SP_X2 Rev G, and the proc board is a
8240 PMC Unity X4 Rev A1
We kind of gave up debugging the problem here because if we’re going
to debug the problem, we might as well debug it on our board. >

But as for where to start looking for code to modify, have a look at:

src/hardware/startup/lib/ppc/callout_debug_8250.s

This is where we are looking now.
As a debugging step, we changed the display_char_8250 function to just
write a single char to the UART address (0xfc004500) and stop.
(turning off address translation first)

Nothing prints, implying that the callout never gets called!?

i.e.

li %r3,0
mtmsr %r3
isync

li %r3,0x0c00
mtspr 1008,%r3
isync

li %r4,‘C’
lis %r3,0xfc00
stb %r4,0x4500(%r3)

b $

snip

Jay_Greig1 · August 6, 2004, 7:34pm

John Kiernan wrote:

Jay Greig wrote:

John,

Chances are that the callout is being called (unless you explicitly
removed it from the callout list), but there may be something extra
you need to do in your callout.

Have a look in the “Building Embedded Systems” book in the help
documentation, chapter 5 “Customizing Image Startup Programs”, section
“Writing your own kernel callout”. There is a sub-section called
‘“Patching” the callout code’ which may be what you’re looking for.

Thanks,
-Jay.

I did read the section your referring to, I’m really not writing my own
callout though, I don’t think that should be necessary. The standard
write_char_8250 should work on our board with out any problems…
That’s is the one I’m trying to use anyway. I’m assuming that the
standard callout works , so I’m thinking that I have something else
not set up properly.

Not necessarily true - one of our developers is struggling through the
debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d offer
more suggestions once he figured it out.

Thanks,
-Jay.

John Kiernan wrote:

Jay Greig wrote:

John,

Stepping back a bit to the Sandpoint problems you mentioned (since
that’s the hardware we have here), I downloaded an image via DINK to
the board equipped with a 8240 CPU and I had no problems. What
revision of Sandpoint do you have? The one I tested on was a
PPCEVAL_SP3 Rev X3. We currently do not support the PPCEVAL_SP3 Rev
X3B.

The motherboard is a M98SP_X2 Rev G, and the proc board is a
8240 PMC Unity X4 Rev A1
We kind of gave up debugging the problem here because if we’re going
to debug the problem, we might as well debug it on our board. >

But as for where to start looking for code to modify, have a look at:

src/hardware/startup/lib/ppc/callout_debug_8250.s

This is where we are looking now.
As a debugging step, we changed the display_char_8250 function to
just write a single char to the UART address (0xfc004500) and stop.
(turning off address translation first)

Nothing prints, implying that the callout never gets called!?

i.e.

li %r3,0
mtmsr %r3
isync

li %r3,0x0c00
mtspr 1008,%r3
isync

li %r4,‘C’
lis %r3,0xfc00
stb %r4,0x4500(%r3)

b $

snip

John_Kiernan1 · August 6, 2004, 7:40pm

Jay Greig wrote:

Not necessarily true - one of our developers is struggling through the
debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d offer
more suggestions once he figured it out.

Thanks,
-Jay.

We’ll I hope he figures it out! Because we’re starting to scratch
our heads here, because it does look like the callout should work.

Thanks,
John

John_Kiernan1 · August 6, 2004, 7:51pm

You know, I hate when things like this happen…Like I said it the
callout should work…I’ve changed back some of the stuff we added
for debugging…, and now I get:

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964
Welcome to QNX Neutrino 6.3 on the RTMIO

HOWEVER, I can’t input anything…(I’m very happy to see the prompt
though )

Any ideas of why input doesn’t work? Maybe interrupt related?

John Kiernan wrote:

Jay Greig wrote:
Not necessarily true - one of our developers is struggling through the

debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d
offer more suggestions once he figured it out.

Thanks,
-Jay.

We’ll I hope he figures it out! > > Because we’re starting to scratch
our heads here, because it does look like the callout should work.

Thanks,
John

Jay_Greig1 · August 6, 2004, 8:00pm

Excellent! Did you uncomment your serial driver in your build file? If
not, unfortunately it looks as though your debug callouts are still not
working. But if you did add the serial port back into the image, it
looks as though you have an interrupt problem.

-Jay.

John Kiernan wrote:

You know, I hate when things like this happen…Like I said it the
callout should work…I’ve changed back some of the stuff we added
for debugging…, and now I get:

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964
Welcome to QNX Neutrino 6.3 on the RTMIO

HOWEVER, I can’t input anything…(I’m very happy to see the prompt
though > > )

Any ideas of why input doesn’t work? Maybe interrupt related?

John Kiernan wrote:

Jay Greig wrote:
Not necessarily true - one of our developers is struggling through the

debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d
offer more suggestions once he figured it out.

Thanks,
-Jay.

We’ll I hope he figures it out! > > Because we’re starting to scratch
our heads here, because it does look like the callout should work.

Thanks,
John

John_Kiernan1 · August 6, 2004, 9:50pm

Jay Greig wrote:

Excellent! Did you uncomment your serial driver in your build file? If
not, unfortunately it looks as though your debug callouts are still not
working. But if you did add the serial port back into the image, it
looks as though you have an interrupt problem.

I did add the serial driver back… and also added a display_msg after
it. The message after prints out really slow, so I’m guessing interrupt
problem. Our board doesn’t use any other interrupt controllers other
than the standard PPC epic; So I’m using the config_epic call from the
library.

My int_intrinfo.c looks like this:

#include “startup.h”
#include <ppc/603cpu.h>
#include “epic.h”

const static struct startup_intrinfo rtmio_intrs[] = {
EPIC_INTRS(_NTO_INTR_CLASS_EXTERNAL)
{ PPC_INTR_CLASS_DEC, 1, _NTO_INTR_SPARE,
PPC_EXC_DECREMENTER, 0, 0,
{0, 0, &interrupt_id_dec},
{0, 0, &interrupt_eoi_dec},
&interrupt_mask_dec, &interrupt_unmask_dec, 0, 0,
},
};

void init_intrinfo()
{
rtmio_epic_base = 0xfc040000;
add_interrupt_array(rtmio_intrs, sizeof(rtmio_intrs));

config_epic(rtmio_epic_base);
}

Am I not setting this up properly?

John Kiernan wrote:

You know, I hate when things like this happen…Like I said it the
callout should work…I’ve changed back some of the stuff we added
for debugging…, and now I get:

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964
Welcome to QNX Neutrino 6.3 on the RTMIO

HOWEVER, I can’t input anything…(I’m very happy to see the prompt
though > > )

Any ideas of why input doesn’t work? Maybe interrupt related?

John Kiernan wrote:

Jay Greig wrote:
Not necessarily true - one of our developers is struggling through
the

debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d
offer more suggestions once he figured it out.

Thanks,
-Jay.

We’ll I hope he figures it out! > > Because we’re starting to
scratch our heads here, because it does look like the callout
should work.

Thanks,
John

John_Kiernan1 · August 6, 2004, 10:06pm

Dave Green wrote:

We are hoping that your problems are one of the same and that he’d offer
more suggestions once he figured it out.

The existing callout does work, on all the boards that we’ve tested it on… >

I’ve figured my issue out, for the most part. The following code in the
callout checks whether data translation should be on while accessing
the devices:

lhz %r9,SYSPAGE_PPC_KERINFO(%r3)
add %r9,%r9,%r3
lwz %r9,KERINFO_TS_CLEAR(%r9)

The bit that’s being checked (PPC_MSR_DR) is turned on by default in the startup
library, for all CPU’s, and then, in the ppcv_cpuinfo_** entries, it’s
cleared again, for those CPU families that can leave translation on.
For the CPU family I’m working with (PPC 700), the bit wasn’t being cleared,
so translation was being turned off, and the callout wasn’t working. I added
an entry to a local copy of ppcv_cpuconfig_700 to clear the bit, rebuilt
my startup, and now everything is working.

That said, if you’re using an 8240, I see that in ppcv_cpuconfig_8200.c
in the startup library, this bit is already being cleared… as a quick
test to see if this is your problem (or if you have the opposite problem),
you could copy the ppcv_cpuconfig_8200.c file from the startup library into
your local startup directory, comment out the following line:

lsp.cpu.ppc_kerinfo.p->callout_ts_clear &= ~PPC_MSR_DS;

and then re-build your startup (with the stock callout_debug_8250.s, not
the one you’ve modified).

If this still doesn’t resolve the problem, then I’d second Jay’s suggestion,
of going back to the Sandpoint board first, and figure out why that’s not
working… our Sandpoint BSP on a Sandpoint board should just work, so if
it’s not, the problem might be something more fundamental.

As suggested I commented out the line, and doesn’t seem to make any
difference. ?

Justin_Moon1 · August 9, 2004, 12:16pm

Is the serial port using the same interrupt as spec’d in the buildfile? You
may have to change the interrupt value based on which interrupt your serial
port is connected to.

cheers,
Justin
“John Kiernan” <jkiernan@birinc.com> wrote in message
news:cf0s2b$dqf$1@inn.qnx.com…

Jay Greig wrote:
Excellent! Did you uncomment your serial driver in your build file? If
not, unfortunately it looks as though your debug callouts are still not
working. But if you did add the serial port back into the image, it
looks as though you have an interrupt problem.

I did add the serial driver back… and also added a display_msg after
it. The message after prints out really slow, so I’m guessing interrupt
problem. Our board doesn’t use any other interrupt controllers other
than the standard PPC epic; So I’m using the config_epic call from the
library.

My int_intrinfo.c looks like this:

#include “startup.h”
#include <ppc/603cpu.h
#include “epic.h”

const static struct startup_intrinfo rtmio_intrs[] = {
EPIC_INTRS(_NTO_INTR_CLASS_EXTERNAL)
{ PPC_INTR_CLASS_DEC, 1, _NTO_INTR_SPARE,
PPC_EXC_DECREMENTER, 0, 0,
{0, 0, &interrupt_id_dec},
{0, 0, &interrupt_eoi_dec},
&interrupt_mask_dec, &interrupt_unmask_dec, 0, 0,
},
};

void init_intrinfo()
{
rtmio_epic_base = 0xfc040000;
add_interrupt_array(rtmio_intrs, sizeof(rtmio_intrs));

config_epic(rtmio_epic_base);
}

Am I not setting this up properly?

John Kiernan wrote:

You know, I hate when things like this happen…Like I said it the
callout should work…I’ve changed back some of the stuff we added
for debugging…, and now I get:

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964
Welcome to QNX Neutrino 6.3 on the RTMIO

HOWEVER, I can’t input anything…(I’m very happy to see the prompt
though > > )

Any ideas of why input doesn’t work? Maybe interrupt related?

John Kiernan wrote:

Jay Greig wrote:
Not necessarily true - one of our developers is struggling through
the

debug callouts/patcher for a similar board - on paper it should have
used the stock callouts, but it has proved otherwise!

We are hoping that your problems are one of the same and that he’d
offer more suggestions once he figured it out.

Thanks,
-Jay.

We’ll I hope he figures it out! > > Because we’re starting to
scratch our heads here, because it does look like the callout
should work.

Thanks,
John

John_Kiernan1 · August 9, 2004, 5:55pm

Thanks Jay, Dave & Justin,

Success! I have a prompt and can input too!
(It was a few different problems with the interrupts)

Thanks for all your help!

John

Help with sandpoint (PPC 8245) BSP

System page at phys:0000c000 user:0000c000 kern:0000c000 Starting next program at v00221964 \

BSH file below:

SERIAL driver

PCI server

These env variables are inherited by all the programs which follow

BSH file below:

SERIAL driver

PCI server

These env variables are inherited by all the programs which follow

BSH file below:

SERIAL driver

PCI server

These env variables are inherited by all the programs which follow

BSH file below:

SERIAL driver

PCI server

These env variables are inherited by all the programs which follow

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v00221964

\