Anyone working on BSP for PPC (Sandpoint)

bridged with qdn.public.bsp
Chris Hallinan

Anyone working on BSP for PPC (Sandpoint)

Post by Chris Hallinan » Thu Nov 14, 2002 10:05 pm

I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)

I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.

When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.

Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.

Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.


Thanks,

Chris
clh@net1plus.com

Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Fri Nov 15, 2002 1:32 pm

Chris Hallinan <clh@net1plus.com> wrote:
I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)

I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.

When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.

Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.

Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.
Thanks,

Chris
clh@net1plus.com
Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html


--

David Green (dgreen@qnx.com)

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

Chris Hallinan

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Chris Hallinan » Fri Nov 15, 2002 9:53 pm

test

dgreen@qnx.com wrote:
Chris Hallinan <clh@net1plus.com> wrote:

I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html

Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Mon Nov 18, 2002 1:53 pm

Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,

Thanks, David.

I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:

Chris Hallinan <clh@net1plus.com> wrote:
test

dgreen@qnx.com wrote:
Chris Hallinan <clh@net1plus.com> wrote:

I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html

--

David Green (dgreen@qnx.com)

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

Chris Hallinan

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Chris Hallinan » Mon Nov 18, 2002 3:09 pm

Yes, for unknown reasons, the cc: to this group bounced back. Here is
the screen-shot of the output:

Select debug device
init ram
init intrinfo
OpenPIC (1 CPUs and 26 IRQ sources)
openpic: Disabling pass-through
init decrementer
init cacheattr
init cpu_info
CPU Speed: 66
init hwinfo
Replace init_hwinfo() with a board specific version
Printing syspage from main
Header size=0x0000009c, Total Size=0x00000570, #Cpu=1, Type=1
Section:system_private offset:0x00000218 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:0040c000 start addr:0042a03c
ramsize:02000000 pagesize:00001000
Section:qtime offset:0x00000188 size:0x00000048
boot:00000000 CPS:0000000000fbc520 rate/scale:606060606/-16
intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c6f8 power:00000000
timer_load:0000c764 reload:0000c780 value:0000c7cc
0) display:0000c7dc poll:0000c804 break:0000c838
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x000001d0 size:0x00000020
0) cpu:80811014 flags:c0000001 speed:00000042 cache i/d:1/0 name:60
Section:cacheattr offset:0x00000530 size:0x00000040
0) flags:2a size:0020 #lines:0200 control:0000c578 next:255
1) flags:01 size:0020 #lines:0200 control:0000c5c8 next:255
Section:meminfo offset:0x00000280 size:0x00000060
t:1 a:00003000 s:00008000 t:1 a:0000e000 s:003fd108 t:2 a:0040b108
s:000c0f2c
t:3 a:0040b108 s:000c0f2c t:1 a:004cc034 s:01b33fcc
Section:asinfo offset:0x00000390 size:0x00000160
0000) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 80000000-febfffff o:0000 a:0013 p:100 c:00000000 n:28
0040) 80000000-febfffff o:0020 a:0003 p:100 c:00000000 n:35
0060) f8000000-ffffffff o:0000 a:0003 p:100 c:00000000 n:38
0080) ff000000-ffffffff o:0000 a:0005 p:100 c:00000000 n:52
00a0) 00000000-01ffffff o:0000 a:0017 p:100 c:00000000 n:56
00c0) 0040b108-004cc033 o:0000 a:0005 p:100 c:00000000 n:65
00e0) 0040b108-004cc033 o:0000 a:0007 p:100 c:00000000 n:73
0100) 00003000-0000afff o:00a0 a:0007 p:100 c:00000000 n:81
0120) 0000e000-0040b107 o:00a0 a:0007 p:100 c:00000000 n:81
0140) 004cc034-01ffffff o:00a0 a:0007 p:100 c:00000000 n:81
Section:hwinfo offset:0x00000368 size:0x00000028
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002e0 size:0x00000028
off:0 type:5 string:'PowerDNA'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000308 size:0x00000060
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'device'
[35]'io'
[38]'kernel_device' [52]'rom' [56]'ram' [60]'82xx' [65]'imagefs'
[73]'bootram' [81]'sysram'
Section:intrinfo offset:0x000004f0 size:0x00000040
0) vector_base:00000089, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0000, size:004c, rtn:0000c5f4
eoi => flags:1000, size:0018, rtn:0000c640
mask:0000c658, unmask:0000c690, config:00000000
Section:boxinfo offset:0x000001f0 size:0x00000028
hw_flags:00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000
Section:smpinfo offset:0x00000158 size:0x00000030
mpu_start_addr:00000000 ipi_vector:00000000
Calling startnext()

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0042a03c
Unexpected exception vector usage (0x900).
Check startup code for missing interrupt callout definiti
Shutdown[0,0] S/C/F=255/255/255 C/D=00411efc/0045c538 state(d0)= now
lock exit
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
ppcbe context[0045af28]:
0000: 00004000 0045afd8 00461eb0 00460000 00000000 00001032 00009032
000000d0
0020: 6f632f62 00000004 00009ff8 00000000 0000af88 004633e0 07fef000
080d0000
0040: 00001032 34be439e 341d4985 22d22e16 209890be 00000001 23822756
0045c360
0060: 00008000 00000000 0045c66c 0045c6b0 00000001 00000000 00007688
000075c0
0080: 00000000 00000904 00009032 00456de0 44002004 2000000c 00000000
00000001
00a0: 0045afd8
instruction[00456de0]:
80 ad 8f e4 2c 05 00 00 40 82 02 ec 3b 4d 91 60 83 7f 00 84 83 9a 00 00
7c 1b
stack[0045afd8]:
0000: 0045b008 00444794 00000000 00000000 00000000 00000000 00000002
00400040
0020: 00402044 00409081 07fef51c 0045a028 0045b018 00439d98 00000000
0042a03c
0040: 00000000 0042a03c 00000000 00000000 00010202 03030303 04040404
04040404
0060: 05050505 05050505 05050505 05050505 06060606 06060606 06060606
06060606

Regards,

Chris Hallinan


dgreen@qnx.com wrote:
Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,



Thanks, David.


I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:




Chris Hallinan <clh@net1plus.com> wrote:

test


dgreen@qnx.com wrote:

Chris Hallinan <clh@net1plus.com> wrote:


I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html




Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Mon Nov 18, 2002 3:18 pm

Chris,

What value is your EUMBBAR register set to? The Sandpoint startup code
expects it to be 0xfc000000.


Chris Hallinan <clh@net1plus.com> wrote:
Yes, for unknown reasons, the cc: to this group bounced back. Here is
the screen-shot of the output:

Select debug device
init ram
init intrinfo
OpenPIC (1 CPUs and 26 IRQ sources)
openpic: Disabling pass-through
init decrementer
init cacheattr
init cpu_info
CPU Speed: 66
init hwinfo
Replace init_hwinfo() with a board specific version
Printing syspage from main
Header size=0x0000009c, Total Size=0x00000570, #Cpu=1, Type=1
Section:system_private offset:0x00000218 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:0040c000 start addr:0042a03c
ramsize:02000000 pagesize:00001000
Section:qtime offset:0x00000188 size:0x00000048
boot:00000000 CPS:0000000000fbc520 rate/scale:606060606/-16
intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c6f8 power:00000000
timer_load:0000c764 reload:0000c780 value:0000c7cc
0) display:0000c7dc poll:0000c804 break:0000c838
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x000001d0 size:0x00000020
0) cpu:80811014 flags:c0000001 speed:00000042 cache i/d:1/0 name:60
Section:cacheattr offset:0x00000530 size:0x00000040
0) flags:2a size:0020 #lines:0200 control:0000c578 next:255
1) flags:01 size:0020 #lines:0200 control:0000c5c8 next:255
Section:meminfo offset:0x00000280 size:0x00000060
t:1 a:00003000 s:00008000 t:1 a:0000e000 s:003fd108 t:2 a:0040b108
s:000c0f2c
t:3 a:0040b108 s:000c0f2c t:1 a:004cc034 s:01b33fcc
Section:asinfo offset:0x00000390 size:0x00000160
0000) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 80000000-febfffff o:0000 a:0013 p:100 c:00000000 n:28
0040) 80000000-febfffff o:0020 a:0003 p:100 c:00000000 n:35
0060) f8000000-ffffffff o:0000 a:0003 p:100 c:00000000 n:38
0080) ff000000-ffffffff o:0000 a:0005 p:100 c:00000000 n:52
00a0) 00000000-01ffffff o:0000 a:0017 p:100 c:00000000 n:56
00c0) 0040b108-004cc033 o:0000 a:0005 p:100 c:00000000 n:65
00e0) 0040b108-004cc033 o:0000 a:0007 p:100 c:00000000 n:73
0100) 00003000-0000afff o:00a0 a:0007 p:100 c:00000000 n:81
0120) 0000e000-0040b107 o:00a0 a:0007 p:100 c:00000000 n:81
0140) 004cc034-01ffffff o:00a0 a:0007 p:100 c:00000000 n:81
Section:hwinfo offset:0x00000368 size:0x00000028
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002e0 size:0x00000028
off:0 type:5 string:'PowerDNA'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000308 size:0x00000060
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'device'
[35]'io'
[38]'kernel_device' [52]'rom' [56]'ram' [60]'82xx' [65]'imagefs'
[73]'bootram' [81]'sysram'
Section:intrinfo offset:0x000004f0 size:0x00000040
0) vector_base:00000089, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0000, size:004c, rtn:0000c5f4
eoi => flags:1000, size:0018, rtn:0000c640
mask:0000c658, unmask:0000c690, config:00000000
Section:boxinfo offset:0x000001f0 size:0x00000028
hw_flags:00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000
Section:smpinfo offset:0x00000158 size:0x00000030
mpu_start_addr:00000000 ipi_vector:00000000
Calling startnext()

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0042a03c
Unexpected exception vector usage (0x900).
Check startup code for missing interrupt callout definiti
Shutdown[0,0] S/C/F=255/255/255 C/D=00411efc/0045c538 state(d0)= now
lock exit
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
ppcbe context[0045af28]:
0000: 00004000 0045afd8 00461eb0 00460000 00000000 00001032 00009032
000000d0
0020: 6f632f62 00000004 00009ff8 00000000 0000af88 004633e0 07fef000
080d0000
0040: 00001032 34be439e 341d4985 22d22e16 209890be 00000001 23822756
0045c360
0060: 00008000 00000000 0045c66c 0045c6b0 00000001 00000000 00007688
000075c0
0080: 00000000 00000904 00009032 00456de0 44002004 2000000c 00000000
00000001
00a0: 0045afd8
instruction[00456de0]:
80 ad 8f e4 2c 05 00 00 40 82 02 ec 3b 4d 91 60 83 7f 00 84 83 9a 00 00
7c 1b
stack[0045afd8]:
0000: 0045b008 00444794 00000000 00000000 00000000 00000000 00000002
00400040
0020: 00402044 00409081 07fef51c 0045a028 0045b018 00439d98 00000000
0042a03c
0040: 00000000 0042a03c 00000000 00000000 00010202 03030303 04040404
04040404
0060: 05050505 05050505 05050505 05050505 06060606 06060606 06060606
06060606

Regards,

Chris Hallinan
dgreen@qnx.com wrote:
Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,



Thanks, David.


I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:




Chris Hallinan <clh@net1plus.com> wrote:

test


dgreen@qnx.com wrote:

Chris Hallinan <clh@net1plus.com> wrote:


I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html




--

David Green (dgreen@qnx.com)

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

Chris Hallinan

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Chris Hallinan » Mon Nov 18, 2002 4:27 pm

It is set to 0xfc000000 by my bootloader (PPCBoot.!
Can you confirm that the procnto-600 sets it (or more likely maps it) to
0x34000000?

-Chris

dgreen@qnx.com wrote:
Chris,

What value is your EUMBBAR register set to? The Sandpoint startup code
expects it to be 0xfc000000.


Chris Hallinan <clh@net1plus.com> wrote:

Yes, for unknown reasons, the cc: to this group bounced back. Here is
the screen-shot of the output:


Select debug device
init ram
init intrinfo
OpenPIC (1 CPUs and 26 IRQ sources)
openpic: Disabling pass-through
init decrementer
init cacheattr
init cpu_info
CPU Speed: 66
init hwinfo
Replace init_hwinfo() with a board specific version
Printing syspage from main
Header size=0x0000009c, Total Size=0x00000570, #Cpu=1, Type=1
Section:system_private offset:0x00000218 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:0040c000 start addr:0042a03c
ramsize:02000000 pagesize:00001000
Section:qtime offset:0x00000188 size:0x00000048
boot:00000000 CPS:0000000000fbc520 rate/scale:606060606/-16
intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c6f8 power:00000000
timer_load:0000c764 reload:0000c780 value:0000c7cc
0) display:0000c7dc poll:0000c804 break:0000c838
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x000001d0 size:0x00000020
0) cpu:80811014 flags:c0000001 speed:00000042 cache i/d:1/0 name:60
Section:cacheattr offset:0x00000530 size:0x00000040
0) flags:2a size:0020 #lines:0200 control:0000c578 next:255
1) flags:01 size:0020 #lines:0200 control:0000c5c8 next:255
Section:meminfo offset:0x00000280 size:0x00000060
t:1 a:00003000 s:00008000 t:1 a:0000e000 s:003fd108 t:2 a:0040b108
s:000c0f2c
t:3 a:0040b108 s:000c0f2c t:1 a:004cc034 s:01b33fcc
Section:asinfo offset:0x00000390 size:0x00000160
0000) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 80000000-febfffff o:0000 a:0013 p:100 c:00000000 n:28
0040) 80000000-febfffff o:0020 a:0003 p:100 c:00000000 n:35
0060) f8000000-ffffffff o:0000 a:0003 p:100 c:00000000 n:38
0080) ff000000-ffffffff o:0000 a:0005 p:100 c:00000000 n:52
00a0) 00000000-01ffffff o:0000 a:0017 p:100 c:00000000 n:56
00c0) 0040b108-004cc033 o:0000 a:0005 p:100 c:00000000 n:65
00e0) 0040b108-004cc033 o:0000 a:0007 p:100 c:00000000 n:73
0100) 00003000-0000afff o:00a0 a:0007 p:100 c:00000000 n:81
0120) 0000e000-0040b107 o:00a0 a:0007 p:100 c:00000000 n:81
0140) 004cc034-01ffffff o:00a0 a:0007 p:100 c:00000000 n:81
Section:hwinfo offset:0x00000368 size:0x00000028
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002e0 size:0x00000028
off:0 type:5 string:'PowerDNA'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000308 size:0x00000060
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'device'
[35]'io'
[38]'kernel_device' [52]'rom' [56]'ram' [60]'82xx' [65]'imagefs'
[73]'bootram' [81]'sysram'
Section:intrinfo offset:0x000004f0 size:0x00000040
0) vector_base:00000089, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0000, size:004c, rtn:0000c5f4
eoi => flags:1000, size:0018, rtn:0000c640
mask:0000c658, unmask:0000c690, config:00000000
Section:boxinfo offset:0x000001f0 size:0x00000028
hw_flags:00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000
Section:smpinfo offset:0x00000158 size:0x00000030
mpu_start_addr:00000000 ipi_vector:00000000
Calling startnext()


System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0042a03c
Unexpected exception vector usage (0x900).
Check startup code for missing interrupt callout definiti
Shutdown[0,0] S/C/F=255/255/255 C/D=00411efc/0045c538 state(d0)= now
lock exit
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
ppcbe context[0045af28]:
0000: 00004000 0045afd8 00461eb0 00460000 00000000 00001032 00009032
000000d0
0020: 6f632f62 00000004 00009ff8 00000000 0000af88 004633e0 07fef000
080d0000
0040: 00001032 34be439e 341d4985 22d22e16 209890be 00000001 23822756
0045c360
0060: 00008000 00000000 0045c66c 0045c6b0 00000001 00000000 00007688
000075c0
0080: 00000000 00000904 00009032 00456de0 44002004 2000000c 00000000
00000001
00a0: 0045afd8
instruction[00456de0]:
80 ad 8f e4 2c 05 00 00 40 82 02 ec 3b 4d 91 60 83 7f 00 84 83 9a 00 00
7c 1b
stack[0045afd8]:
0000: 0045b008 00444794 00000000 00000000 00000000 00000000 00000002
00400040
0020: 00402044 00409081 07fef51c 0045a028 0045b018 00439d98 00000000
0042a03c
0040: 00000000 0042a03c 00000000 00000000 00010202 03030303 04040404
04040404
0060: 05050505 05050505 05050505 05050505 06060606 06060606 06060606
06060606


Regards,


Chris Hallinan



dgreen@qnx.com wrote:

Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,




Thanks, David.


I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:




Chris Hallinan <clh@net1plus.com> wrote:


test


dgreen@qnx.com wrote:


Chris Hallinan <clh@net1plus.com> wrote:



I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html





Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Mon Nov 18, 2002 5:12 pm

Chris Hallinan <clh@net1plus.com> wrote:
It is set to 0xfc000000 by my bootloader (PPCBoot.!
Can you confirm that the procnto-600 sets it (or more likely maps it) to
0x34000000?
This mapping is done in init_asinfo.c of startup:

as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, "kernel_device", mem);

The BAT range starts at 0xF8000000, which is translated to 0x30000000 by
the kernel, so 0xfc000000 - 0xf8000000 + 0x30000000 = 0x34000000.
Note that this translated address range is only applicable to kernel
code, so you normally wouldn't address it directly, except in
startup's kernel callouts.

OK, so if the EUMBBAR is OK, next I'd suspect something in the
init_intrinfo.c routine of startup is amiss... the intrinfo
section of the syspage printout looks a little suspicious.
I see only one entry, with a vector base of 0x89, and a single
interrupt on the vector, and I also don't see an entry for the
decrementer (0x80000000). Could you post your init_intrinfo.c file?

-Chris

dgreen@qnx.com wrote:
Chris,

What value is your EUMBBAR register set to? The Sandpoint startup code
expects it to be 0xfc000000.


Chris Hallinan <clh@net1plus.com> wrote:

Yes, for unknown reasons, the cc: to this group bounced back. Here is
the screen-shot of the output:


Select debug device
init ram
init intrinfo
OpenPIC (1 CPUs and 26 IRQ sources)
openpic: Disabling pass-through
init decrementer
init cacheattr
init cpu_info
CPU Speed: 66
init hwinfo
Replace init_hwinfo() with a board specific version
Printing syspage from main
Header size=0x0000009c, Total Size=0x00000570, #Cpu=1, Type=1
Section:system_private offset:0x00000218 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:0040c000 start addr:0042a03c
ramsize:02000000 pagesize:00001000
Section:qtime offset:0x00000188 size:0x00000048
boot:00000000 CPS:0000000000fbc520 rate/scale:606060606/-16
intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c6f8 power:00000000
timer_load:0000c764 reload:0000c780 value:0000c7cc
0) display:0000c7dc poll:0000c804 break:0000c838
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x000001d0 size:0x00000020
0) cpu:80811014 flags:c0000001 speed:00000042 cache i/d:1/0 name:60
Section:cacheattr offset:0x00000530 size:0x00000040
0) flags:2a size:0020 #lines:0200 control:0000c578 next:255
1) flags:01 size:0020 #lines:0200 control:0000c5c8 next:255
Section:meminfo offset:0x00000280 size:0x00000060
t:1 a:00003000 s:00008000 t:1 a:0000e000 s:003fd108 t:2 a:0040b108
s:000c0f2c
t:3 a:0040b108 s:000c0f2c t:1 a:004cc034 s:01b33fcc
Section:asinfo offset:0x00000390 size:0x00000160
0000) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 80000000-febfffff o:0000 a:0013 p:100 c:00000000 n:28
0040) 80000000-febfffff o:0020 a:0003 p:100 c:00000000 n:35
0060) f8000000-ffffffff o:0000 a:0003 p:100 c:00000000 n:38
0080) ff000000-ffffffff o:0000 a:0005 p:100 c:00000000 n:52
00a0) 00000000-01ffffff o:0000 a:0017 p:100 c:00000000 n:56
00c0) 0040b108-004cc033 o:0000 a:0005 p:100 c:00000000 n:65
00e0) 0040b108-004cc033 o:0000 a:0007 p:100 c:00000000 n:73
0100) 00003000-0000afff o:00a0 a:0007 p:100 c:00000000 n:81
0120) 0000e000-0040b107 o:00a0 a:0007 p:100 c:00000000 n:81
0140) 004cc034-01ffffff o:00a0 a:0007 p:100 c:00000000 n:81
Section:hwinfo offset:0x00000368 size:0x00000028
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002e0 size:0x00000028
off:0 type:5 string:'PowerDNA'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000308 size:0x00000060
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'device'
[35]'io'
[38]'kernel_device' [52]'rom' [56]'ram' [60]'82xx' [65]'imagefs'
[73]'bootram' [81]'sysram'
Section:intrinfo offset:0x000004f0 size:0x00000040
0) vector_base:00000089, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0000, size:004c, rtn:0000c5f4
eoi => flags:1000, size:0018, rtn:0000c640
mask:0000c658, unmask:0000c690, config:00000000
Section:boxinfo offset:0x000001f0 size:0x00000028
hw_flags:00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000
Section:smpinfo offset:0x00000158 size:0x00000030
mpu_start_addr:00000000 ipi_vector:00000000
Calling startnext()


System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0042a03c
Unexpected exception vector usage (0x900).
Check startup code for missing interrupt callout definiti
Shutdown[0,0] S/C/F=255/255/255 C/D=00411efc/0045c538 state(d0)= now
lock exit
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
ppcbe context[0045af28]:
0000: 00004000 0045afd8 00461eb0 00460000 00000000 00001032 00009032
000000d0
0020: 6f632f62 00000004 00009ff8 00000000 0000af88 004633e0 07fef000
080d0000
0040: 00001032 34be439e 341d4985 22d22e16 209890be 00000001 23822756
0045c360
0060: 00008000 00000000 0045c66c 0045c6b0 00000001 00000000 00007688
000075c0
0080: 00000000 00000904 00009032 00456de0 44002004 2000000c 00000000
00000001
00a0: 0045afd8
instruction[00456de0]:
80 ad 8f e4 2c 05 00 00 40 82 02 ec 3b 4d 91 60 83 7f 00 84 83 9a 00 00
7c 1b
stack[0045afd8]:
0000: 0045b008 00444794 00000000 00000000 00000000 00000000 00000002
00400040
0020: 00402044 00409081 07fef51c 0045a028 0045b018 00439d98 00000000
0042a03c
0040: 00000000 0042a03c 00000000 00000000 00010202 03030303 04040404
04040404
0060: 05050505 05050505 05050505 05050505 06060606 06060606 06060606
06060606


Regards,


Chris Hallinan



dgreen@qnx.com wrote:

Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,




Thanks, David.


I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:




Chris Hallinan <clh@net1plus.com> wrote:


test


dgreen@qnx.com wrote:


Chris Hallinan <clh@net1plus.com> wrote:



I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html





--

David Green (dgreen@qnx.com)

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

Chris Hallinan

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Chris Hallinan » Mon Nov 18, 2002 6:37 pm

Excellent answer. Thank you.

In an effort to keep it simple while debugging, I only defined a single
interrupt in the syspage. It describes the interrupt for the DUART1.
The vector is correct, 0x89 (137) which is the OpenPIC standard
reference for this interrupt on this processor's internal EPIC
controller. If you take the OpenPIC definitions, and apply the vector
number 137 to the starting address of the MPC8245 EPIC register bank
defining the non-timer interrupt sources (0x5_0000), and take into
account the 0x10 spacing between vec/pri and dest registers, you get the
following:

offset_of_duart1_vec_pri = 0x5_0000 + ( VECTOR * 0x20 )
= 0x5_1120 for VECTOR = 137 (DUART1.)

I did it this way because I am a Linux hack, and that's how it's done in
Linux for this and many other processors for the OpenPIC reference
model, and I'm not clever enough to think up a better way :) !

I assume I am free to imlement the low-level h/w interface in this
manner? This mean that I will need to understand the assembly-language
callouts. I'm sure I'll have questions there, too!

Here's my init_intrinfo.c

Thanks much!

Chris Hallinan





dgreen@qnx.com wrote:
Chris Hallinan <clh@net1plus.com> wrote:

It is set to 0xfc000000 by my bootloader (PPCBoot.!
Can you confirm that the procnto-600 sets it (or more likely maps it) to
0x34000000?


This mapping is done in init_asinfo.c of startup:

as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, "kernel_device", mem);

The BAT range starts at 0xF8000000, which is translated to 0x30000000 by
the kernel, so 0xfc000000 - 0xf8000000 + 0x30000000 = 0x34000000.
Note that this translated address range is only applicable to kernel
code, so you normally wouldn't address it directly, except in
startup's kernel callouts.

OK, so if the EUMBBAR is OK, next I'd suspect something in the
init_intrinfo.c routine of startup is amiss... the intrinfo
section of the syspage printout looks a little suspicious.
I see only one entry, with a vector base of 0x89, and a single
interrupt on the vector, and I also don't see an entry for the
decrementer (0x80000000). Could you post your init_intrinfo.c file?



-Chris


dgreen@qnx.com wrote:

Chris,

What value is your EUMBBAR register set to? The Sandpoint startup code
expects it to be 0xfc000000.


Chris Hallinan <clh@net1plus.com> wrote:


Yes, for unknown reasons, the cc: to this group bounced back. Here is
the screen-shot of the output:


Select debug device
init ram
init intrinfo
OpenPIC (1 CPUs and 26 IRQ sources)
openpic: Disabling pass-through
init decrementer
init cacheattr
init cpu_info
CPU Speed: 66
init hwinfo
Replace init_hwinfo() with a board specific version
Printing syspage from main
Header size=0x0000009c, Total Size=0x00000570, #Cpu=1, Type=1
Section:system_private offset:0x00000218 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:0040c000 start addr:0042a03c
ramsize:02000000 pagesize:00001000
Section:qtime offset:0x00000188 size:0x00000048
boot:00000000 CPS:0000000000fbc520 rate/scale:606060606/-16
intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c6f8 power:00000000
timer_load:0000c764 reload:0000c780 value:0000c7cc
0) display:0000c7dc poll:0000c804 break:0000c838
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x000001d0 size:0x00000020
0) cpu:80811014 flags:c0000001 speed:00000042 cache i/d:1/0 name:60
Section:cacheattr offset:0x00000530 size:0x00000040
0) flags:2a size:0020 #lines:0200 control:0000c578 next:255
1) flags:01 size:0020 #lines:0200 control:0000c5c8 next:255
Section:meminfo offset:0x00000280 size:0x00000060
t:1 a:00003000 s:00008000 t:1 a:0000e000 s:003fd108 t:2 a:0040b108
s:000c0f2c
t:3 a:0040b108 s:000c0f2c t:1 a:004cc034 s:01b33fcc
Section:asinfo offset:0x00000390 size:0x00000160
0000) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 80000000-febfffff o:0000 a:0013 p:100 c:00000000 n:28
0040) 80000000-febfffff o:0020 a:0003 p:100 c:00000000 n:35
0060) f8000000-ffffffff o:0000 a:0003 p:100 c:00000000 n:38
0080) ff000000-ffffffff o:0000 a:0005 p:100 c:00000000 n:52
00a0) 00000000-01ffffff o:0000 a:0017 p:100 c:00000000 n:56
00c0) 0040b108-004cc033 o:0000 a:0005 p:100 c:00000000 n:65
00e0) 0040b108-004cc033 o:0000 a:0007 p:100 c:00000000 n:73
0100) 00003000-0000afff o:00a0 a:0007 p:100 c:00000000 n:81
0120) 0000e000-0040b107 o:00a0 a:0007 p:100 c:00000000 n:81
0140) 004cc034-01ffffff o:00a0 a:0007 p:100 c:00000000 n:81
Section:hwinfo offset:0x00000368 size:0x00000028
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002e0 size:0x00000028
off:0 type:5 string:'PowerDNA'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000308 size:0x00000060
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'device'
[35]'io'
[38]'kernel_device' [52]'rom' [56]'ram' [60]'82xx' [65]'imagefs'
[73]'bootram' [81]'sysram'
Section:intrinfo offset:0x000004f0 size:0x00000040
0) vector_base:00000089, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0000, size:004c, rtn:0000c5f4
eoi => flags:1000, size:0018, rtn:0000c640
mask:0000c658, unmask:0000c690, config:00000000
Section:boxinfo offset:0x000001f0 size:0x00000028
hw_flags:00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000
Section:smpinfo offset:0x00000158 size:0x00000030
mpu_start_addr:00000000 ipi_vector:00000000
Calling startnext()


System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0042a03c
Unexpected exception vector usage (0x900).
Check startup code for missing interrupt callout definiti
Shutdown[0,0] S/C/F=255/255/255 C/D=00411efc/0045c538 state(d0)= now
lock exit
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
ppcbe context[0045af28]:
0000: 00004000 0045afd8 00461eb0 00460000 00000000 00001032 00009032
000000d0
0020: 6f632f62 00000004 00009ff8 00000000 0000af88 004633e0 07fef000
080d0000
0040: 00001032 34be439e 341d4985 22d22e16 209890be 00000001 23822756
0045c360
0060: 00008000 00000000 0045c66c 0045c6b0 00000001 00000000 00007688
000075c0
0080: 00000000 00000904 00009032 00456de0 44002004 2000000c 00000000
00000001
00a0: 0045afd8
instruction[00456de0]:
80 ad 8f e4 2c 05 00 00 40 82 02 ec 3b 4d 91 60 83 7f 00 84 83 9a 00 00
7c 1b
stack[0045afd8]:
0000: 0045b008 00444794 00000000 00000000 00000000 00000000 00000002
00400040
0020: 00402044 00409081 07fef51c 0045a028 0045b018 00439d98 00000000
0042a03c
0040: 00000000 0042a03c 00000000 00000000 00010202 03030303 04040404
04040404
0060: 05050505 05050505 05050505 05050505 06060606 06060606 06060606
06060606


Regards,


Chris Hallinan



dgreen@qnx.com wrote:


Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,





Thanks, David.


I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:




Chris Hallinan <clh@net1plus.com> wrote:



test


dgreen@qnx.com wrote:



Chris Hallinan <clh@net1plus.com> wrote:




I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html





Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Mon Nov 18, 2002 7:16 pm

Chris Hallinan <clh@net1plus.com> wrote:
This is a multi-part message in MIME format.
--------------000606070509050600040500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Excellent answer. Thank you.

In an effort to keep it simple while debugging, I only defined a single
interrupt in the syspage. It describes the interrupt for the DUART1.
The vector is correct, 0x89 (137) which is the OpenPIC standard
reference for this interrupt on this processor's internal EPIC
controller. If you take the OpenPIC definitions, and apply the vector
number 137 to the starting address of the MPC8245 EPIC register bank
defining the non-timer interrupt sources (0x5_0000), and take into
account the 0x10 spacing between vec/pri and dest registers, you get the
following:

offset_of_duart1_vec_pri = 0x5_0000 + ( VECTOR * 0x20 )
= 0x5_1120 for VECTOR = 137 (DUART1.)

I did it this way because I am a Linux hack, and that's how it's done in
Linux for this and many other processors for the OpenPIC reference
model, and I'm not clever enough to think up a better way :) !

I assume I am free to imlement the low-level h/w interface in this
manner? This mean that I will need to understand the assembly-language
callouts. I'm sure I'll have questions there, too!

Here's my init_intrinfo.c

Thanks much!

Chris Hallinan
Chris,

This should be OK, as long as DUART1 is the only thing that will
cause the EPIC to interrupt the CPU (i.e. everything else is masked).

However, if you're looking for a way to eliminate interrupt hassles
from the process of developing startup code (until things are "up and
running"), a handy way to do it is to mask _all_ EPIC interrupts, and
attach the serial driver (devc-ser8250) to the decrementer interrupt:

ex.

devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,0x80000000 &

However, for this to work, the decrementer interrupt vector needs to
be set up in the init_intrinfo() routiner. This is also likely why you
were getting the unexpected exception vector problem. You need to add
the following to init_intrinfo.c:

{ 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,
},


dgreen@qnx.com wrote:
Chris Hallinan <clh@net1plus.com> wrote:

It is set to 0xfc000000 by my bootloader (PPCBoot.!
Can you confirm that the procnto-600 sets it (or more likely maps it) to
0x34000000?


This mapping is done in init_asinfo.c of startup:

as_add(0xf8000000, 0xffffffff, AS_ATTR_DEV, "kernel_device", mem);

The BAT range starts at 0xF8000000, which is translated to 0x30000000 by
the kernel, so 0xfc000000 - 0xf8000000 + 0x30000000 = 0x34000000.
Note that this translated address range is only applicable to kernel
code, so you normally wouldn't address it directly, except in
startup's kernel callouts.

OK, so if the EUMBBAR is OK, next I'd suspect something in the
init_intrinfo.c routine of startup is amiss... the intrinfo
section of the syspage printout looks a little suspicious.
I see only one entry, with a vector base of 0x89, and a single
interrupt on the vector, and I also don't see an entry for the
decrementer (0x80000000). Could you post your init_intrinfo.c file?



-Chris


dgreen@qnx.com wrote:

Chris,

What value is your EUMBBAR register set to? The Sandpoint startup code
expects it to be 0xfc000000.


Chris Hallinan <clh@net1plus.com> wrote:


Yes, for unknown reasons, the cc: to this group bounced back. Here is
the screen-shot of the output:


Select debug device
init ram
init intrinfo
OpenPIC (1 CPUs and 26 IRQ sources)
openpic: Disabling pass-through
init decrementer
init cacheattr
init cpu_info
CPU Speed: 66
init hwinfo
Replace init_hwinfo() with a board specific version
Printing syspage from main
Header size=0x0000009c, Total Size=0x00000570, #Cpu=1, Type=1
Section:system_private offset:0x00000218 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:0040c000 start addr:0042a03c
ramsize:02000000 pagesize:00001000
Section:qtime offset:0x00000188 size:0x00000048
boot:00000000 CPS:0000000000fbc520 rate/scale:606060606/-16
intr:2147483648
Section:callout offset:0x000000a0 size:0x00000048
reboot:0000c6f8 power:00000000
timer_load:0000c764 reload:0000c780 value:0000c7cc
0) display:0000c7dc poll:0000c804 break:0000c838
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x000001d0 size:0x00000020
0) cpu:80811014 flags:c0000001 speed:00000042 cache i/d:1/0 name:60
Section:cacheattr offset:0x00000530 size:0x00000040
0) flags:2a size:0020 #lines:0200 control:0000c578 next:255
1) flags:01 size:0020 #lines:0200 control:0000c5c8 next:255
Section:meminfo offset:0x00000280 size:0x00000060
t:1 a:00003000 s:00008000 t:1 a:0000e000 s:003fd108 t:2 a:0040b108
s:000c0f2c
t:3 a:0040b108 s:000c0f2c t:1 a:004cc034 s:01b33fcc
Section:asinfo offset:0x00000390 size:0x00000160
0000) 00000000-ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 80000000-febfffff o:0000 a:0013 p:100 c:00000000 n:28
0040) 80000000-febfffff o:0020 a:0003 p:100 c:00000000 n:35
0060) f8000000-ffffffff o:0000 a:0003 p:100 c:00000000 n:38
0080) ff000000-ffffffff o:0000 a:0005 p:100 c:00000000 n:52
00a0) 00000000-01ffffff o:0000 a:0017 p:100 c:00000000 n:56
00c0) 0040b108-004cc033 o:0000 a:0005 p:100 c:00000000 n:65
00e0) 0040b108-004cc033 o:0000 a:0007 p:100 c:00000000 n:73
0100) 00003000-0000afff o:00a0 a:0007 p:100 c:00000000 n:81
0120) 0000e000-0040b107 o:00a0 a:0007 p:100 c:00000000 n:81
0140) 004cc034-01ffffff o:00a0 a:0007 p:100 c:00000000 n:81
Section:hwinfo offset:0x00000368 size:0x00000028
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:0
Section:typed_strings offset:0x000002e0 size:0x00000028
off:0 type:5 string:'PowerDNA'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000308 size:0x00000060
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'device'
[35]'io'
[38]'kernel_device' [52]'rom' [56]'ram' [60]'82xx' [65]'imagefs'
[73]'bootram' [81]'sysram'
Section:intrinfo offset:0x000004f0 size:0x00000040
0) vector_base:00000089, #vectors:1, cascade_vector:7fffffff
cpu_intr_base:00000140, cpu_intr_stride:0, flags:0000
id => flags:0000, size:004c, rtn:0000c5f4
eoi => flags:1000, size:0018, rtn:0000c640
mask:0000c658, unmask:0000c690, config:00000000
Section:boxinfo offset:0x000001f0 size:0x00000028
hw_flags:00000000
Section:kerinfo offset:0x00000128 size:0x00000030
pretend_cpu:00810101 init_msr:00000000
Section:smpinfo offset:0x00000158 size:0x00000030
mpu_start_addr:00000000 ipi_vector:00000000
Calling startnext()


System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0042a03c
Unexpected exception vector usage (0x900).
Check startup code for missing interrupt callout definiti
Shutdown[0,0] S/C/F=255/255/255 C/D=00411efc/0045c538 state(d0)= now
lock exit
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
ppcbe context[0045af28]:
0000: 00004000 0045afd8 00461eb0 00460000 00000000 00001032 00009032
000000d0
0020: 6f632f62 00000004 00009ff8 00000000 0000af88 004633e0 07fef000
080d0000
0040: 00001032 34be439e 341d4985 22d22e16 209890be 00000001 23822756
0045c360
0060: 00008000 00000000 0045c66c 0045c6b0 00000001 00000000 00007688
000075c0
0080: 00000000 00000904 00009032 00456de0 44002004 2000000c 00000000
00000001
00a0: 0045afd8
instruction[00456de0]:
80 ad 8f e4 2c 05 00 00 40 82 02 ec 3b 4d 91 60 83 7f 00 84 83 9a 00 00
7c 1b
stack[0045afd8]:
0000: 0045b008 00444794 00000000 00000000 00000000 00000000 00000002
00400040
0020: 00402044 00409081 07fef51c 0045a028 0045b018 00439d98 00000000
0042a03c
0040: 00000000 0042a03c 00000000 00000000 00010202 03030303 04040404
04040404
0060: 05050505 05050505 05050505 05050505 06060606 06060606 06060606
06060606


Regards,


Chris Hallinan



dgreen@qnx.com wrote:


Chris,

I received your e-mail, but the output sample that you sent
didn't get attached; I see you also cc'd your mail to this
group, but it didn't get posted here... could you please
re-post the output from startup and procnto here, after
putting a print_syspage() call in main.c of your startup, and
putting some verbosity on startup and procnto in your build
file?

Thanks,





Thanks, David.


I have made some more progress. I understand everything you
explained, and the debug callouts seem to be working fine.
I also added my own very early put_string_raw and put_byte_raw
routines to spit characters directly to my 8250-like MPC8245
DUART prior to the time the debug device is initialized.
All that works fine.

I now have the kernel starting, and complaining about the
use of an unexpected exception vector (0x900) which
happens to be the decrementer. I shouldn't have to touch
anything in code related to that, since it's pretty generic
PowerPC stuff and applies to a wide range or PPC processors.

(By the way, I was pretty happy to get this far: at least the
Neutrino kernel is producing output!)

Here's the output:




Chris Hallinan <clh@net1plus.com> wrote:



test


dgreen@qnx.com wrote:



Chris Hallinan <clh@net1plus.com> wrote:




I am new to QNX (though I'm very experienced with Linux/Unix and
embedded systems in general.)


I'm doing a port of QNX 6.2 to a custom MPC8245-based board. I have
made substantial progress in little time, and I have the startup-*
program running.


When I pass control to procnto-600, I get nothing. No debug, no
exceptions, just stuck in some wierd (low) memory location.


Any ideas for how to debug at this stage? With Linux, I'm used to
having the source and I can go in and put debug printk()'s, etc, etc.
You know the drill. But not with QNX.


Since there have been only a half-dozen posts on this list this year,
I'm just poking around to see if there is anyone in a similar situation.



Thanks,


Chris
clh@net1plus.com


Chris,

You likely need to modify startup's debug callout, which allows the kernel
to display debug information to the serial port, in the absence of a serial
device driver. While startup itself is executing, it uses the put_8250()
routine, found in hw_ser8250.c of the startup library (assuming the serial
hardware on your board is 8250 based). Once control is passed to the
kernel, the kernel relies on the display_char_8250 routine in callout_debug_8250.s
to display characters. This routine may need customization for your board.

For more information on callouts, and modifying startup code in general, check out:

http://www.qnx.com/developer/docs/momen ... artup.html





--------------000606070509050600040500
Content-Type: text/plain;
name="init_intrinfo.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="init_intrinfo.c"

/*
* Copyright 2001, QNX Software Systems Ltd. Unpublished Work All Rights
* Reserved.
*
* This source code contains confidential information of QNX Software Systems
* Ltd. (QSSL). Any use, reproduction, modification, disclosure, distribution
* or transfer of this software, or any software which includes or is based
* upon any of this code, is only permitted under the terms of the QNX
* Confidential Source License version 1.0 (see licensing.qnx.com for details)
* or as otherwise expressly authorized by a written license agreement from
* QSSL. For more information, please email licensing@qnx.com.
*/
#include "startup.h"
#include <ppc/603cpu.h
#include "open_pic.h"

//
// Initialize interrupt controller hardware & intrinfo structure in the
// system page.
// This code is hardware dependant and may have to be changed
// changed by end users.
//

/*
* This file has been basically re-written to support
* the UEI PowerDNA board and EPIC interrupt controller
* C. Hallinan, November 15, 2002
*/
extern struct callout_rtn interrupt_id_pdna_duart1;
extern struct callout_rtn interrupt_eoi_pdna_duart1;
extern struct callout_rtn interrupt_mask_pdna_duart1;
extern struct callout_rtn interrupt_unmask_pdna_duart1;

#define MPC8245_EPIC_BASE 0xfc040000

#define PDNA_DUART1_INTR 137
#define PDNA_INTR_CLASS_PCI _NTO_INTR_CLASS_EXTERNAL /* (0x0000UL << 16) */
#define SANDPOINT_NUM_INTR_PCI 4

const static struct startup_intrinfo intrs_pdna[] = {
{ vector_base: PDNA_DUART1_INTR,
num_vectors: 1,
cascade_vector: _NTO_INTR_SPARE,
cpu_intr_base: PPC_EXC_EXTERNAL_INTR,
cpu_intr_stride: 0,
flags: 0,
/* Struct startup_intrgen id */
{ genflags: 0,
size: 0,
rtn: &interrupt_id_pdna_duart1},
/* Struct startup_intrgen eoi */
{ genflags: INTR_GENFLAG_LOAD_INTRMASK,
size: 0,
rtn: &interrupt_eoi_pdna_duart1},
/* Struct callout_rtn */
mask: &interrupt_mask_pdna_duart1,
/* Struct callout_rtn */
unmask: &interrupt_unmask_pdna_duart1,
/* Struct callout_rtn */
config: NULL,
},

};

void
init_intrinfo() {

/*
* Initialize the OpenPIC controller on the MPC8245
* Pass in offset = 0;
*/
openpic_init((void *)MPC8245_EPIC_BASE, 0, NULL, 0);

add_interrupt_array(intrs_pdna, sizeof(intrs_pdna));
}

--------------000606070509050600040500--
--

David Green (dgreen@qnx.com)

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

Chris Hallinan

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Chris Hallinan » Mon Nov 18, 2002 7:47 pm

..
..
..<snip>
Chris,

This should be OK, as long as DUART1 is the only thing that will
cause the EPIC to interrupt the CPU (i.e. everything else is masked).

However, if you're looking for a way to eliminate interrupt hassles
from the process of developing startup code (until things are "up and
running"), a handy way to do it is to mask _all_ EPIC interrupts, and
attach the serial driver (devc-ser8250) to the decrementer interrupt:

ex.

devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,0x80000000 &

However, for this to work, the decrementer interrupt vector needs to
be set up in the init_intrinfo() routiner. This is also likely why you
were getting the unexpected exception vector problem. You need to add
the following to init_intrinfo.c:

{ 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,
},
snip
Yes, after your last post, I added that entry (copied from the original
sandpoint file) and I actually got a kernel prompt! However, it was
horribly slow and does not accept keyboard input. I remember hitting
this situation with Sandpoint, and it was because the interrupts were
not correctly set up. I am certain that is still the case. I am
working through the callout assembly routine, but I have one question:

Many of your callout-*.s files provide function prototypes so one can
determine what parameters are in the PPC registers on entry. In the
callout_interrupt_sandpoint.s file, there is no function prototype for
the mask/unmask prodedures. What is passed in via R4?? I have to
modify these for my numbering convention, I think.

Can you provide a 'C' function prototype for the sandpoint callout
function:
interrupt_unmask_sandpointmpic
Upon which my unmask is based? Really, the only missing piece of the
puzzle is the value in r4.

Thanks for the help. I'm getting there!!

-Chris Hallinan

Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Mon Nov 18, 2002 8:23 pm

Chris Hallinan <clh@net1plus.com> wrote:
.
.
.<snip
Chris,

This should be OK, as long as DUART1 is the only thing that will
cause the EPIC to interrupt the CPU (i.e. everything else is masked).

However, if you're looking for a way to eliminate interrupt hassles
from the process of developing startup code (until things are "up and
running"), a handy way to do it is to mask _all_ EPIC interrupts, and
attach the serial driver (devc-ser8250) to the decrementer interrupt:

ex.

devc-ser8250 -e -c1846200 -b9600 0xfe0003f8,0x80000000 &

However, for this to work, the decrementer interrupt vector needs to
be set up in the init_intrinfo() routiner. This is also likely why you
were getting the unexpected exception vector problem. You need to add
the following to init_intrinfo.c:

{ 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,
},
snip

Yes, after your last post, I added that entry (copied from the original
sandpoint file) and I actually got a kernel prompt! However, it was
horribly slow and does not accept keyboard input. I remember hitting
this situation with Sandpoint, and it was because the interrupts were
not correctly set up. I am certain that is still the case. I am
working through the callout assembly routine, but I have one question:

Many of your callout-*.s files provide function prototypes so one can
determine what parameters are in the PPC registers on entry. In the
callout_interrupt_sandpoint.s file, there is no function prototype for
the mask/unmask prodedures. What is passed in via R4?? I have to
modify these for my numbering convention, I think.

Can you provide a 'C' function prototype for the sandpoint callout
function:
interrupt_unmask_sandpointmpic
Upon which my unmask is based? Really, the only missing piece of the
puzzle is the value in r4.
The prototype for the callout would be the same as for the other PPC
mask and unmask callouts, i.e. the syspage pointer is passed in r16, and the
interrupt level to be masked or unmasked is passed in r4.

Thanks for the help. I'm getting there!!

-Chris Hallinan
--

David Green (dgreen@qnx.com)

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

Brian Stecher

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Brian Stecher » Mon Nov 18, 2002 8:31 pm

dgreen@qnx.com wrote:
The prototype for the callout would be the same as for the other PPC
mask and unmask callouts, i.e. the syspage pointer is passed in r16, and the
interrupt level to be masked or unmasked is passed in r4.
syspage is passed in r3 for mask/unmask, actually. It's only passed in
r16 for id/eoi if INTR_GENFLAG_LOAD_SYSPAGE is specified for the
callout.

--
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

Guest

Re: Anyone working on BSP for PPC (Sandpoint)

Post by Guest » Mon Nov 18, 2002 8:34 pm

Brian Stecher <bstecher@qnx.com> wrote:
dgreen@qnx.com wrote:
The prototype for the callout would be the same as for the other PPC
mask and unmask callouts, i.e. the syspage pointer is passed in r16, and the
interrupt level to be masked or unmasked is passed in r4.

syspage is passed in r3 for mask/unmask, actually. It's only passed in
r16 for id/eoi if INTR_GENFLAG_LOAD_SYSPAGE is specified for the
callout.
There you go. Thanks Brian.

--
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
--

David Green (dgreen@qnx.com)

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

A K

Re: Anyone working on BSP for PPC (Sandpoint)

Post by A K » Tue Nov 19, 2002 3:49 pm

Is there anywhere in QNX documentation where the specifics of register
allocation for callouts and other BSP specifics are kept?

Post Reply

Return to “qdn.public.bsp”