On 2009/12/08 at 18:09, svn@openbios.org wrote:
Author: mcayland Date: 2009-12-09 02:09:48 +0100 (Wed, 09 Dec 2009) New Revision: 641
Modified: trunk/openbios-devel/forth/bootstrap/bootstrap.fs trunk/openbios-devel/forth/device/fcode.fs Log: Revert r638, apply previous patch to extend control flow stack items to 2 data stack items, and fix the Fcode evaluator to use this new information to correctly resolve destination (b<mark) references. See the email archives for further discussion on why this is required.
Hopefully this should finally resolve the Fcode backward branch problem; at least all previous incorrect resolutions now appear correct and the Fcode evaluator no longer crashes or gets stuck in a loop while attempting to boot Milax.
Updated and rebuilt OpenBIOS - still getting the same unhandled exception at the same place: (gdb) l *0x00000000ffd10e54 0xffd10e54 is in cfetch (../include/openbios/stack.h:34). 29 typedef ucell phandle_t; 30 31 32 33 34 static inline void PUSH(ucell value) { 35 dstack[++dstackcnt] = (value); 36 } 37 static inline void PUSH_xt( xt_t xt ) { PUSH( (ucell)xt ); } 38 static inline void PUSH_ih( ihandle_t ih ) { PUSH( (ucell)ih ); }
What version of Milax are you using? I downloaded the 0.4 ISO and all I get is "Unsupported Image Format" when I try to boot.
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Nick Couchman wrote:
Updated and rebuilt OpenBIOS - still getting the same unhandled exception at the same place: (gdb) l *0x00000000ffd10e54 0xffd10e54 is in cfetch (../include/openbios/stack.h:34). 29 typedef ucell phandle_t; 30 31 32 33 34 static inline void PUSH(ucell value) { 35 dstack[++dstackcnt] = (value); 36 } 37 static inline void PUSH_xt( xt_t xt ) { PUSH( (ucell)xt ); } 38 static inline void PUSH_ih( ihandle_t ih ) { PUSH( (ucell)ih ); }
Again - any chance you trace this using the Forth debugger instead? Otherwise it's pretty much impossible to find out where you are in the Forth code by catching it at the system level.
What version of Milax are you using? I downloaded the 0.4 ISO and all I get is "Unsupported Image Format" when I try to boot.
I'm using 0.3.2. AFAICT 0.4 is only available for x86 unless you can find a link indicating otherwise :(
ATB,
Mark.
On 2009/12/08 at 18:36, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
wrote:
Again - any chance you trace this using the Forth debugger instead? Otherwise it's pretty much impossible to find out where you are in the Forth code by catching it at the system level.
I'll give it a shot - it's difficult with the Nevada code because it seems to lack some of the debugging ability. I seem to be able to debug everything except the boot process, or I can go to the extreme of getting the verbose fcode output - not much in between.
What version of Milax are you using? I downloaded the 0.4 ISO and all I get
is "Unsupported Image Format" when I try to boot.
I'm using 0.3.2. AFAICT 0.4 is only available for x86 unless you can find a link indicating otherwise :(
Ah - that must be it...I hate it when I make stupid mistakes like that!
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Again - any chance you trace this using the Forth debugger instead? Otherwise it's pretty much impossible to find out where you are in the Forth code by catching it at the system level.
By the way, is the fcode-verbose output useful at all?
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Nick Couchman wrote:
Again - any chance you trace this using the Forth debugger instead? Otherwise it's pretty much impossible to find out where you are in the Forth code by catching it at the system level.
By the way, is the fcode-verbose output useful at all?
yes.
Stefan
On 2009/12/08 at 18:36, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
wrote:
Nick Couchman wrote:
Updated and rebuilt OpenBIOS - still getting the same unhandled exception at
the same place:
(gdb) l *0x00000000ffd10e54 0xffd10e54 is in cfetch (../include/openbios/stack.h:34). 29 typedef ucell phandle_t; 30 31 32 33 34 static inline void PUSH(ucell value) { 35 dstack[++dstackcnt] = (value); 36 } 37 static inline void PUSH_xt( xt_t xt ) { PUSH( (ucell)xt ); } 38 static inline void PUSH_ih( ihandle_t ih ) { PUSH( (ucell)ih ); }
Again - any chance you trace this using the Forth debugger instead? Otherwise it's pretty much impossible to find out where you are in the Forth code by catching it at the system level.
Okay, after some great help from everyone here on getting debugging to work correctly, I've come up with the following output. This indicates that the problem is somewhere at the end of the open-package method - it finishes, then throws the exception. The ?fcode-verbose output is here: http://openbios.pastebin.com/m7807de7c. Here's the debugging output...I'll try to enable a few more things to figure out why it's failing right after open-package.
-Nick
0 > do-boot : do-boot ( Empty ) 00000000ffe386b0: parse-bootargs ( Empty ) 00000000ffe386b8: halt? ( 0 ) 00000000ffe386c0: do?branch ( Empty ) 00000000ffe38710: get-bootdev ( Empty ) 00000000ffe38718: load-pkg ( Empty ) 00000000ffe38720: mount-root : mount-root ( Empty ) 00000000ffe35af0: boot-dev$ ( ffe35570 6 ) 00000000ffe35af8: fs-pkg$ ( ffe35570 6 ffe31588 10 ) 00000000ffe35b00: $open-package : $open-package ( ffe35570 6 ffe31588 10 ) 00000000ffe13dc8: find-package : find-package ( ffe35570 6 ffe31588 10 ) 00000000ffe13be8: (") ( ffe35570 6 ffe31588 10 ffe13bf8 9 ) 00000000ffe13c08: find-dev ( ffe35570 6 ffe31588 10 ffe27920 ffffffffffffffff ) 00000000ffe13c10: 0= ( ffe35570 6 ffe31588 10 ffe27920 0 ) 00000000ffe13c18: do?branch ( ffe35570 6 ffe31588 10 ffe27920 ) 00000000ffe13c40: find-rel-dev ( ffe35570 6 ffe32320 ffffffffffffffff ) 00000000ffe13c48: 0= ( ffe35570 6 ffe32320 0 ) 00000000ffe13c50: do?branch ( ffe35570 6 ffe32320 ) 00000000ffe13c70: true ( ffe35570 6 ffe32320 ffffffffffffffff ) 00000000ffe13c78: (semis) [ Finished find-package ] ( ffe35570 6 ffe32320 ffffffffffffffff ) 00000000ffe13dd0: do?branch ( ffe35570 6 ffe32320 ) 00000000ffe13de0: open-package : open-package ( ffe35570 6 ffe32320 ) 00000000ffe13ca0: create-instance ( ffe35570 6 ffe49330 ) 00000000ffe13ca8: dup ( ffe35570 6 ffe49330 ffe49330 ) 00000000ffe13cb0: 0= ( ffe35570 6 ffe49330 0 ) 00000000ffe13cb8: do?branch ( ffe35570 6 ffe49330 ) 00000000ffe13ce0: >r ( ffe35570 6 ) 00000000ffe13ce8: strdup ( ffe47df8 6 ) 00000000ffe13cf0: r@ ( ffe47df8 6 ffe49330 ) 00000000ffe13cf8: >in.arguments ( ffe47df8 6 ffe49378 ) 00000000ffe13d00: 2! ( Empty ) 00000000ffe13d08: (") ( ffe13d18 4 ) 00000000ffe13d20: r@ ( ffe13d18 4 ffe49330 ) 00000000ffe13d28: (lit) ( ffe13d18 4 ffe49330 ffe13a88 ) 00000000ffe13d38: catch : find-package ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe26fd0 9 ) 00000000ffe13be8: (") ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe26fd0 9 ffe13bf8 9 ) 00000000ffe13c08: find-dev ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe26fd0 9 ffe27920 ffffffffffffffff ) 00000000ffe13c10: 0= ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe26fd0 9 ffe27920 0 ) 00000000ffe13c18: do?branch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe26fd0 9 ffe27920 ) 00000000ffe13c40: find-rel-dev ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe2afa0 ffffffffffffffff ) 00000000ffe13c48: 0= ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe2afa0 0 ) 00000000ffe13c50: do?branch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe2afa0 ) 00000000ffe13c70: true ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe2afa0 ffffffffffffffff ) 00000000ffe13c78: (semis) [ Finished find-package ] : open-package ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe2afa0 ) 00000000ffe13ca0: create-instance ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe4ab98 ) 00000000ffe13ca8: dup ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe4ab98 ffe4ab98 ) 00000000ffe13cb0: 0= ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe4ab98 0 ) 00000000ffe13cb8: do?branch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe4ab98 ) 00000000ffe13ce0: >r ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ) 00000000ffe13ce8: strdup ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ) 00000000ffe13cf0: r@ ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe4ab98 ) 00000000ffe13cf8: >in.arguments ( 1 ffe2fbf0 ffe4a818 ffe4ab88 0 0 ffe4abe0 ) 00000000ffe13d00: 2! ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ) 00000000ffe13d08: (") ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe13d18 4 ) 00000000ffe13d20: r@ ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe13d18 4 ffe4ab98 ) 00000000ffe13d28: (lit) ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe13d18 4 ffe4ab98 ffe13a88 ) 00000000ffe13d38: catch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffffffffffffffff 0 ) 00000000ffe13d40: do?branch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffffffffffffffff ) 00000000ffe13d60: do?branch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ) 00000000ffe13d70: r> ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe4ab98 ) 00000000ffe13d78: dobranch ( 1 ffe2fbf0 ffe4a818 ffe4ab88 ffe4ab98 ) 00000000ffe13da0: (semis) [ Finished open-package ] Unhandled Exception 0x0000000008000000 PC = 0x00000000ffd10e54 NPC = 0x00000000ffd10e58 Stopping execution
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Again - any chance you trace this using the Forth debugger instead? Otherwise it's pretty much impossible to find out where you are in the Forth code by catching it at the system level.
A little more info...I suspect I'll have a few e-mails like this out today :-). Looks like it's failing in read-file - here's the output:
0 > do-boot : do-boot ( Empty ) 00000000ffe386b0: parse-bootargs ( Empty ) 00000000ffe386b8: halt? ( 0 ) 00000000ffe386c0: do?branch ( Empty ) 00000000ffe38710: get-bootdev ( Empty ) 00000000ffe38718: load-pkg ( Empty ) 00000000ffe38720: mount-root : open-package ( ffe35570 7 ffe32320 ) 00000000ffe13ca0: create-instance ( ffe35570 7 ffe49330 ) 00000000ffe13ca8: dup ( ffe35570 7 ffe49330 ffe49330 ) 00000000ffe13cb0: 0= ( ffe35570 7 ffe49330 0 ) 00000000ffe13cb8: do?branch ( ffe35570 7 ffe49330 ) 00000000ffe13ce0: >r ( ffe35570 7 ) 00000000ffe13ce8: strdup ( ffe47df8 7 ) 00000000ffe13cf0: r@ ( ffe47df8 7 ffe49330 ) 00000000ffe13cf8: >in.arguments ( ffe47df8 7 ffe49378 ) 00000000ffe13d00: 2! ( Empty ) 00000000ffe13d08: (") ( ffe13d18 4 ) 00000000ffe13d20: r@ ( ffe13d18 4 ffe49330 ) 00000000ffe13d28: (lit) ( ffe13d18 4 ffe49330 ffe13a88 ) 00000000ffe13d38: catch : open-package ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe2afa0 ) 00000000ffe13ca0: create-instance ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe4ab98 ) 00000000ffe13ca8: dup ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe4ab98 ffe4ab98 ) 00000000ffe13cb0: 0= ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe4ab98 0 ) 00000000ffe13cb8: do?branch ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe4ab98 ) 00000000ffe13ce0: >r ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ) 00000000ffe13ce8: strdup ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ) 00000000ffe13cf0: r@ ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe4ab98 ) 00000000ffe13cf8: >in.arguments ( 1 ffe30530 ffe4a818 ffe4ab88 0 0 ffe4abe0 ) 00000000ffe13d00: 2! ( 1 ffe30530 ffe4a818 ffe4ab88 ) 00000000ffe13d08: (") ( 1 ffe30530 ffe4a818 ffe4ab88 ffe13d18 4 ) 00000000ffe13d20: r@ ( 1 ffe30530 ffe4a818 ffe4ab88 ffe13d18 4 ffe4ab98 ) 00000000ffe13d28: (lit) ( 1 ffe30530 ffe4a818 ffe4ab88 ffe13d18 4 ffe4ab98 ffe13a88 ) 00000000ffe13d38: catch ( 1 ffe30530 ffe4a818 ffe4ab88 ffffffffffffffff 0 ) 00000000ffe13d40: do?branch ( 1 ffe30530 ffe4a818 ffe4ab88 ffffffffffffffff ) 00000000ffe13d60: do?branch ( 1 ffe30530 ffe4a818 ffe4ab88 ) 00000000ffe13d70: r> ( 1 ffe30530 ffe4a818 ffe4ab88 ffe4ab98 ) 00000000ffe13d78: dobranch ( 1 ffe30530 ffe4a818 ffe4ab88 ffe4ab98 ) 00000000ffe13da0: (semis) [ Finished open-package ] ( 1 ffe30530 ffe30530 ffe4a818 ffec3658 1 ffe2bc20 ) 00000000ffe13ca0: create-instance ( 1 ffe30530 ffe30530 ffe4a818 ffec3658 1 ffe4acc0 ) 00000000ffe13ca8: dup ( 1 ffe30530 ffe30530 ffe4a818 ffec3658 1 ffe4acc0 ffe4acc0 ) 00000000ffe13cb0: 0= ( 1 ffe30530 ffe30530 ffe4a818 ffec3658 1 ffe4acc0 0 ) 00000000ffe13cb8: do?branch ( 1 ffe30530 ffe30530 ffe4a818 ffec3658 1 ffe4acc0 ) 00000000ffe13ce0: >r ( 1 ffe30530 ffe30530 ffe4a818 ffec3658 1 ) 00000000ffe13ce8: strdup ( 1 ffe30530 ffe30530 ffe4a818 ffe493a0 1 ) 00000000ffe13cf0: r@ ( 1 ffe30530 ffe30530 ffe4a818 ffe493a0 1 ffe4acc0 ) 00000000ffe13cf8: >in.arguments ( 1 ffe30530 ffe30530 ffe4a818 ffe493a0 1 ffe4ad08 ) 00000000ffe13d00: 2! ( 1 ffe30530 ffe30530 ffe4a818 ) 00000000ffe13d08: (") ( 1 ffe30530 ffe30530 ffe4a818 ffe13d18 4 ) 00000000ffe13d20: r@ ( 1 ffe30530 ffe30530 ffe4a818 ffe13d18 4 ffe4acc0 ) 00000000ffe13d28: (lit) ( 1 ffe30530 ffe30530 ffe4a818 ffe13d18 4 ffe4acc0 ffe13a88 ) 00000000ffe13d38: catch ( 1 ffe30530 ffe30530 ffe4a818 ffffffffffffffff 0 ) 00000000ffe13d40: do?branch ( 1 ffe30530 ffe30530 ffe4a818 ffffffffffffffff ) 00000000ffe13d60: do?branch ( 1 ffe30530 ffe30530 ffe4a818 ) 00000000ffe13d70: r> ( 1 ffe30530 ffe30530 ffe4a818 ffe4acc0 ) 00000000ffe13d78: dobranch ( 1 ffe30530 ffe30530 ffe4a818 ffe4acc0 ) 00000000ffe13da0: (semis) [ Finished open-package ] ( ffffffffffffffff 0 ) 00000000ffe13d40: do?branch ( ffffffffffffffff ) 00000000ffe13d60: do?branch ( Empty ) 00000000ffe13d70: r> ( ffe49330 ) 00000000ffe13d78: dobranch ( ffe49330 ) 00000000ffe13da0: (semis) [ Finished open-package ] ( Empty ) 00000000ffe38728: zflag? ( 0 ) 00000000ffe38730: nested? ( 0 0 ) 00000000ffe38738: invert ( 0 ffffffffffffffff ) 00000000ffe38740: and ( 0 ) 00000000ffe38748: do?branch ( Empty ) 00000000ffe38768: load-file : load-file ( Empty ) 00000000ffe384c0: get-arch ( Empty ) 00000000ffe384c8: get-targ ( ffe36d48 c ) 00000000ffe384d0: open-path : open-path ( ffe36d48 c ) 00000000ffe36ef0: over ( ffe36d48 c ffe36d48 ) 00000000ffe36ef8: c@ ( ffe36d48 c 62 ) 00000000ffe36f00: (lit) ( ffe36d48 c 62 2f ) 00000000ffe36f10: <> ( ffe36d48 c ffffffffffffffff ) 00000000ffe36f18: do?branch ( ffe36d48 c ) 00000000ffe36f28: 2dup ( ffe36d48 c ffe36d48 c ) 00000000ffe36f30: plat-name$ ( ffe36d48 c ffe36d48 c ffe36400 5 ) 00000000ffe36f38: $plat-prepend ( ffe36d48 c ffe366b0 1c ) 00000000ffe36f40: try-file ( ffe36d48 c 0 0 ) 00000000ffe36f48: do?branch ( ffe36d48 c 0 ) 00000000ffe36f90: dobranch ( ffe36d48 c 0 ) 00000000ffe37008: -rot ( 0 ffe36d48 c ) 00000000ffe37010: 2drop ( 0 ) 00000000ffe37018: (semis) [ Finished open-path ] ( 0 ) 00000000ffe384d8: loader-base : loader-base ( 0 ) 00000000ffe356c8: nested? ( 0 0 ) 00000000ffe356d0: do?branch ( 0 ) 00000000ffe35700: (lit) ( 0 51000000 ) 00000000ffe35710: (semis) [ Finished loader-base ] ( 0 51000000 ) 00000000ffe384e0: over primitive words cannot be debugged ( 0 51000000 0 ) 00000000ffe384e8: get-file : get-file ( 0 51000000 0 ) 00000000ffe35ef8: dup ( 0 51000000 0 0 ) 00000000ffe35f00: >r ( 0 51000000 0 ) 00000000ffe35f08: ( 0 51000000 d746c00 ) 00000000ffe35f10: dup ( 0 51000000 d746c00 d746c00 ) 00000000ffe35f18: rot ( 0 d746c00 d746c00 51000000 ) 00000000ffe35f20: vmem-alloc-prop ( 0 d746c00 0 51000000 ) 00000000ffe35f28: rot ( 0 0 51000000 d746c00 ) 00000000ffe35f30: 2dup ( 0 0 51000000 d746c00 51000000 d746c00 ) 00000000ffe35f38: r> ( 0 0 51000000 d746c00 51000000 d746c00 0 ) 00000000ffe35f40: read-file : read-file ( 0 0 51000000 d746c00 51000000 d746c00 0 ) 00000000ffe35da8: >r ( 0 0 51000000 d746c00 51000000 d746c00 ) 00000000ffe35db0: dup ( 0 0 51000000 d746c00 51000000 d746c00 d746c00 ) 00000000ffe35db8: do?branch ( 0 0 51000000 d746c00 51000000 d746c00 ) ( 0 0 51000000 d746c00 51000000 d746c00 ) 00000000ffe35dd0: dup ( 0 0 51000000 d746c00 51000000 d746c00 d746c00 ) 00000000ffe35dd8: ( 0 0 51000000 d746c00 51000000 d746c00 d746c00 400000 ) 00000000ffe35de0: min ( 0 0 51000000 d746c00 51000000 d746c00 400000 ) 00000000ffe35de8: 2 ( 0 0 51000000 d746c00 51000000 d746c00 400000 2 ) 00000000ffe35df0: pick ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 ) 00000000ffe35df8: 2 ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 2 ) 00000000ffe35e00: pick ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 d746c00 ) 00000000ffe35e08: 2 ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 d746c00 2 ) 00000000ffe35e10: pick ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 d746c00 400000 ) 00000000ffe35e18: nip ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 ) 00000000ffe35e20: r@ ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ) 00000000ffe35e28: Unhandled Exception 0x0000000000000032 PC = 0x00000000ffd1bad0 NPC = 0x00000000ffd1baa4 Stopping execution
Curiously the PC location for the error has changed - according to the output above, here's the gdb location:
(gdb) l *0x00000000ffd1bad0 0xffd1bad0 is in ob_ide_insw (./target/include/asm/io.h:165). 160 { 161 uint16_t *b = (uint16_t *) buf; 162 163 while (ns > 0) { 164 *b++ = in_le16(port); 165 ns--; 166 } 167 } 168 169 static inline void _outsw_ns(volatile uint16_t * port, const void *buf,
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Nick Couchman wrote:
[...] 00000000ffe35e20: r@ ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ) 00000000ffe35e28: Unhandled Exception 0x0000000000000032
You've gotten yourself a zero address for your buffer somehow. That r@ is trying to fetch through zero, and faults.
I probably won't be able to answer any more today, I'm flying all day.
Tarl Neustaedter wrote:
Nick Couchman wrote:
[...] 00000000ffe35e20: r@ ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ) 00000000ffe35e28: Unhandled Exception 0x0000000000000032
You've gotten yourself a zero address for your buffer somehow. That r@ is trying to fetch through zero, and faults.
And I'm not fully awake yet, that isn't correct. I was confusing rl@ with r@. The problem is the instruction after the r@, whatever it is.
On 2009/12/09 at 08:14, Tarl Neustaedter Tarl.Neustaedter@Sun.COM wrote:
Tarl Neustaedter wrote:
Nick Couchman wrote:
[...] 00000000ffe35e20: r@ ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ) 00000000ffe35e28: Unhandled Exception 0x0000000000000032
You've gotten yourself a zero address for your buffer somehow. That r@ is trying to fetch through zero, and faults.
And I'm not fully awake yet, that isn't correct. I was confusing rl@ with r@. The problem is the instruction after the r@, whatever it is.
Looks to be in one of the call-package calls:
0 > do-boot : do-boot ( Empty ) 00000000ffe386b0: parse-bootargs ( Empty ) 00000000ffe386b8: halt? ( 0 ) 00000000ffe386c0: do?branch ( Empty ) 00000000ffe38710: get-bootdev ( Empty ) 00000000ffe38718: load-pkg ( Empty ) 00000000ffe38720: mount-root ( Empty ) 00000000ffe38728: zflag? ( 0 ) 00000000ffe38730: nested? ( 0 0 ) 00000000ffe38738: invert ( 0 ffffffffffffffff ) 00000000ffe38740: and ( 0 ) 00000000ffe38748: do?branch ( Empty ) 00000000ffe38768: load-file : read-file ( 0 0 51000000 d746c00 51000000 d746c00 0 ) 00000000ffe35da8: >r ( 0 0 51000000 d746c00 51000000 d746c00 ) 00000000ffe35db0: dup ( 0 0 51000000 d746c00 51000000 d746c00 d746c00 ) 00000000ffe35db8: do?branch ( 0 0 51000000 d746c00 51000000 d746c00 ) ( 0 0 51000000 d746c00 51000000 d746c00 ) 00000000ffe35dd0: dup ( 0 0 51000000 d746c00 51000000 d746c00 d746c00 ) 00000000ffe35dd8: ( 0 0 51000000 d746c00 51000000 d746c00 d746c00 400000 ) 00000000ffe35de0: min ( 0 0 51000000 d746c00 51000000 d746c00 400000 ) 00000000ffe35de8: 2 ( 0 0 51000000 d746c00 51000000 d746c00 400000 2 ) 00000000ffe35df0: pick ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 ) 00000000ffe35df8: 2 ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 2 ) 00000000ffe35e00: pick ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 d746c00 ) 00000000ffe35e08: 2 ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 d746c00 2 ) 00000000ffe35e10: pick ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 d746c00 400000 ) 00000000ffe35e18: nip ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 ) 00000000ffe35e20: r@ ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ) 00000000ffe35e28: : ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ) 00000000ffe35820: (") ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ) 00000000ffe35840: fs-ih ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ffe49330 ) 00000000ffe35848: $call-method : $call-method ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ffe49330 ) 00000000ffe13a90: dup ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ffe49330 ffe49330 ) 00000000ffe13a98: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ffe49330 ) 00000000ffe13aa0: >in.device-node ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ffe49340 ) 00000000ffe13aa8: @ ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe35830 9 ffe32320 ) 00000000ffe13ab0: find-method ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ffffffffffffffff ) 00000000ffe13ab8: do?branch ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ) 00000000ffe13ac8: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ffe49330 ) 00000000ffe13ad0: call-package : call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ffe49330 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ffe49330 0 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ffe49330 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ffe49330 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 51000000 400000 0 ffe34d70 ) 00000000ffe13a40: execute : call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b8d0 ffe4ad48 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b8d0 ffe4ad48 ffe49330 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b8d0 ffe4ad48 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b8d0 ffe4ad48 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b8d0 ) 00000000ffe13a40: execute ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b568 ffe4ac28 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b568 ffe4ac28 ffe4ad48 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b568 ffe4ac28 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b568 ffe4ac28 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b568 ) 00000000ffe13a40: execute ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe30830 ffe4ab28 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe30830 ffe4ab28 ffe4ac28 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe30830 ffe4ab28 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe30830 ffe4ab28 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe30830 ) 00000000ffe13a40: execute : call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b230 ffe4ab98 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b230 ffe4ab98 ffe4ab28 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b230 ffe4ab98 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b230 ffe4ab98 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 c582e000 0 ffe2b230 ) 00000000ffe13a40: execute ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a48: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe4ab28 ) 00000000ffe13a50: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe4ab28 ffe040f8 ) 00000000ffe13a60: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a68: (semis) [ Finished call-package ] ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a48: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe4ac28 ) 00000000ffe13a50: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe4ac28 ffe040f8 ) 00000000ffe13a60: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a68: (semis) [ Finished call-package ] ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a48: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe4ad48 ) 00000000ffe13a50: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe4ad48 ffe040f8 ) 00000000ffe13a60: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a68: (semis) [ Finished call-package ] ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a48: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe49330 ) 00000000ffe13a50: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ffe49330 ffe040f8 ) 00000000ffe13a60: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 51000000 400000 0 ) 00000000ffe13a68: (semis) [ Finished call-package ] : call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b830 ffe4ad48 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b830 ffe4ad48 ffe49330 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b830 ffe4ad48 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b830 ffe4ad48 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b830 ) 00000000ffe13a40: execute ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b4c8 ffe4ac28 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b4c8 ffe4ac28 ffe4ad48 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b4c8 ffe4ac28 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b4c8 ffe4ac28 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b4c8 ) 00000000ffe13a40: execute ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe308c0 ffe4ab28 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe308c0 ffe4ab28 ffe4ac28 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe308c0 ffe4ab28 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe308c0 ffe4ab28 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe308c0 ) 00000000ffe13a40: execute : call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe2b280 ffe4ab98 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe2b280 ffe4ab98 ffe4ab28 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe2b280 ffe4ab98 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe2b280 ffe4ab98 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 ffe2b280 ) 00000000ffe13a40: execute ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ) 00000000ffe13a48: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ffe4ab28 ) 00000000ffe13a50: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ffe4ab28 ffe040f8 ) 00000000ffe13a60: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ) 00000000ffe13a68: (semis) [ Finished call-package ] ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ) 00000000ffe13a48: r> ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ffe4ac28 ) 00000000ffe13a50: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ffe4ac28 ffe040f8 ) 00000000ffe13a60: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 c582e000 0 ) 00000000ffe13a68: (semis) [ Finished call-package ] ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe307e8 ffe4ab28 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe307e8 ffe4ab28 ffe4ac28 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe307e8 ffe4ab28 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe307e8 ffe4ab28 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe307e8 ) 00000000ffe13a40: execute primitive words cannot be debugged
: call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b190 ffe4ab98 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b190 ffe4ab98 ffe4ab28 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b190 ffe4ab98 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b190 ffe4ab98 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 400000 ffe2b190 ) 00000000ffe13a40: execute : call-package ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 18b05c 800 ffe309b0 ffe4ab28 ) 00000000ffe13a18: my-self ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 18b05c 800 ffe309b0 ffe4ab28 ffe4ab98 ) 00000000ffe13a20: >r ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 18b05c 800 ffe309b0 ffe4ab28 ) 00000000ffe13a28: (lit) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 18b05c 800 ffe309b0 ffe4ab28 ffe040f8 ) 00000000ffe13a38: (to) ( 0 0 51000000 d746c00 51000000 d746c00 400000 400000 400000 51000000 18b05c 800 ffe309b0 ) 00000000ffe13a40: execute Unhandled Exception 0x0000000000000032 PC = 0x00000000ffd1bad0 NPC = 0x00000000ffd1baa4 Stopping execution
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Nick Couchman wrote:
Curiously the PC location for the error has changed - according to the output above, here's the gdb location:
(gdb) l *0x00000000ffd1bad0 0xffd1bad0 is in ob_ide_insw (./target/include/asm/io.h:165). 160 { 161 uint16_t *b = (uint16_t *) buf; 162 163 while (ns > 0) { 164 *b++ = in_le16(port); 165 ns--; 166 } 167 } 168 169 static inline void _outsw_ns(volatile uint16_t * port, const void *buf,
-Nick
Okay - I've just committed a "fix" for the missing alarm word since OpenBIOS wasn't removing the parameters from the stack as alarm should. Now I get slightly further with Milax, but I too am seeing a crash in the IDE inteface code trying to load a file. It seems that the crash manages to kill the Qemu instance too.
Here's a Forth debugger trace reading in the first sector of the CDROM from the beginning of the boot process which we know works:
: read ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 800 8000000 ffe6b200 ) 00000000ffe28d28: >r ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 800 8000000 ) 00000000ffe28d30: swap ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ) 00000000ffe28d38: r> ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ) 00000000ffe28d40: dup ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ffe6b200 ) 00000000ffe28d48: ihandle>phandle ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ffe2b600 ) 00000000ffe28d50: (") ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ffe2b600 ffe28d60 4 ) 00000000ffe28d68: rot ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ffe28d60 4 ffe2b600 ) 00000000ffe28d70: find-method ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ffe2b838 ffffffffffffffff ) 00000000ffe28d78: do?branch ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe6b200 ffe2b838 ) 00000000ffe28d88: swap ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 8000000 800 ffe2b838 ffe6b200 ) 00000000ffe28d90: call-package ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 800 ) 00000000ffe28d98: dobranch ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 800 800 ) 00000000ffe28db8: (semis)
And here's a Forth debugger trace trying to read in /platform/sun4u/boot_archive:
: read ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 554c800 51000000 ffe6b200 ) 00000000ffe28d28: >r ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 554c800 51000000 ) 00000000ffe28d30: swap ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ) 00000000ffe28d38: r> ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ) 00000000ffe28d40: dup ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ffe6b200 ) 00000000ffe28d48: ihandle>phandle ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ffe2b600 ) 00000000ffe28d50: (") ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ffe2b600 ffe28d60 4 ) 00000000ffe28d68: rot ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ffe28d60 4 ffe2b600 ) 00000000ffe28d70: find-method ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ffe2b838 ffffffffffffffff ) 00000000ffe28d78: do?branch ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe6b200 ffe2b838 ) 00000000ffe28d88: swap ( ffffffffffffffff 1 0 ffffffffffffffff 0 0 0 ffe0b9e8 0 0 0 0 0 0 0 0 0 51000000 554c800 554c800 554c800 554c800 51000000 554c800 ffe2b838 ffe6b200 ) 00000000ffe28d90: call-package qemu: unsupported keyboard cmd=0x57 sSegmentation fault
In the case of reading the first sector of the Milax CDROM, 0x800 bytes are being read to memory at 0x8000000 which works fine. When trying to read in boot_archive then we see that 0x554c800 bytes are being read into memory at 0x51000000 and this is where the crash happens. I wonder if we're finding some kind of IDE I/O emulation bug for SPARC64 Qemu?
If you switch back to GDB and poke around where the segfault happens, can you see any values that look obviously broken at your end?
ATB,
Mark.
On 2009/12/09 at 11:56, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
wrote:
Nick Couchman wrote:
Curiously the PC location for the error has changed - according to the output
above, here's the gdb location:
(gdb) l *0x00000000ffd1bad0 0xffd1bad0 is in ob_ide_insw (./target/include/asm/io.h:165). 160 { 161 uint16_t *b = (uint16_t *) buf; 162 163 while (ns > 0) { 164 *b++ = in_le16(port); 165 ns--; 166 } 167 } 168 169 static inline void _outsw_ns(volatile uint16_t * port, const void *buf,
-Nick
Okay - I've just committed a "fix" for the missing alarm word since OpenBIOS wasn't removing the parameters from the stack as alarm should. Now I get slightly further with Milax, but I too am seeing a crash in the IDE inteface code trying to load a file. It seems that the crash manages to kill the Qemu instance too.
After an svn up and a rebuild, I'm getting exactly the same Unhandled Exception as before with the Solaris Nevada code - no segfault or anything like that. With Milax I see exactly the error you're seeing, including the segfault.
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On 2009/12/09 at 11:56, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
wrote:
Nick Couchman wrote:
Curiously the PC location for the error has changed - according to the output
above, here's the gdb location:
(gdb) l *0x00000000ffd1bad0 0xffd1bad0 is in ob_ide_insw (./target/include/asm/io.h:165). 160 { 161 uint16_t *b = (uint16_t *) buf; 162 163 while (ns > 0) { 164 *b++ = in_le16(port); 165 ns--; 166 } 167 } 168 169 static inline void _outsw_ns(volatile uint16_t * port, const void *buf,
-Nick
Okay - I've just committed a "fix" for the missing alarm word since OpenBIOS wasn't removing the parameters from the stack as alarm should. Now I get slightly further with Milax, but I too am seeing a crash in the IDE inteface code trying to load a file. It seems that the crash manages to kill the Qemu instance too.
Would any of the Qemu debugging in op_helper.c provide any more information? Seems like most of that debugging is for CPU and memory management, and now for disk or network I/O.
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Okay - I've just committed a "fix" for the missing alarm word since OpenBIOS wasn't removing the parameters from the stack as alarm should. Now I get slightly further with Milax, but I too am seeing a crash in the IDE inteface code trying to load a file. It seems that the crash manages to kill the Qemu instance too.
Here's a Forth debugger trace reading in the first sector of the CDROM from the beginning of the boot process which we know works:
Found IDE debugging in qemu and turned that on...the last couple hundred lines are here: http://openbios.pastebin.com/de428f7c
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Nick Couchman wrote:
Found IDE debugging in qemu and turned that on...the last couple hundred lines are here: http://openbios.pastebin.com/de428f7c
-Nick
For reference, here are the last few lines:
ATAPI limit=0xf800 packet: 28 00 00 01 22 f6 00 00 1f 00 00 00 read pio: LBA=74486 nb_sectors=31 reply: tx_size=63488 elem_tx_size=0 index=2048 byte_count_limit=63488 status=0x58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read addr=0x607 val=58 ide: read addr=0x602 val=02 ide: read addr=0x604 val=00 ide: read addr=0x605 val=f8 reply: tx_size=61440 elem_tx_size=61440 index=2048 reply: tx_size=59392 elem_tx_size=59392 index=2048 reply: tx_size=57344 elem_tx_size=57344 index=2048 reply: tx_size=55296 elem_tx_size=55296 index=2048 reply: tx_size=53248 elem_tx_size=53248 index=2048 reply: tx_size=51200 elem_tx_size=51200 index=2048 reply: tx_size=49152 elem_tx_size=49152 index=2048 reply: tx_size=47104 elem_tx_size=47104 index=2048 reply: tx_size=45056 elem_tx_size=45056 index=2048 reply: tx_size=43008 elem_tx_size=43008 index=2048 reply: tx_size=40960 elem_tx_size=40960 index=2048 reply: tx_size=38912 elem_tx_size=38912 index=2048 reply: tx_size=36864 elem_tx_size=36864 index=2048 reply: tx_size=34816 elem_tx_size=34816 index=2048 reply: tx_size=32768 elem_tx_size=32768 index=2048 reply: tx_size=30720 elem_tx_size=30720 index=2048 reply: tx_size=28672 elem_tx_size=28672 index=2048 reply: tx_size=26624 elem_tx_size=26624 index=2048 reply: tx_size=24576 elem_tx_size=24576 index=2048 reply: tx_size=22528 elem_tx_size=22528 index=2048 reply: tx_size=20480 elem_tx_size=20480 index=2048 reply: tx_size=18432 elem_tx_size=18432 index=2048 reply: tx_size=16384 elem_tx_size=16384 index=2048 sIDE: write addr=0x502 val=0x9a IDE: write addr=0x503 val=0xa9 IDE: write addr=0x504 val=0x06 IDE: write addr=0x505 val=0xed IDE: write addr=0x506 val=0x14 IDE: write addr=0x507 val=0xcd ide: CMD=cd ide: write control addr=0x582 val=97 IDE: write addr=0x602 val=0xba IDE: write addr=0x603 val=0xae IDE: write addr=0x604 val=0xce IDE: write addr=0x605 val=0xb6 IDE: write addr=0x606 val=0x58 IDE: write addr=0x607 val=0x57 ide: CMD=57 ide: write control addr=0x682 val=70 bmdma_cmd_writeb: 0x00000054 bmdma: writeb 0x701 : 0xd7 bmdma: writeb 0x702 : 0x79 bmdma: writeb 0x703 : 0xfe bmdma_addr_writew: 0x0000ddef bmdma_addr_writew: 0x0000b12b bmdma_cmd_writeb: 0x000000da bmdma: writeb 0x709 : 0x95
That's interesting. From the whole output you posted in the pastebin, it looks as if the IDE control register is located at 0x682 and various bits of data are written between 0x600 and 0x607.
However, then something does terribly wrong mid-request and the write addresses change to 0x500-0x507 with a control register at 0x582, then 0x600-0x607 with a control register at 0x582 and then 0x700-0x707 with a control register of 0x682 again.
I'm current leaning towards this being a bug in Qemu...
ATB,
Mark.
That's interesting. From the whole output you posted in the pastebin, it looks as if the IDE control register is located at 0x682 and various bits of data are written between 0x600 and 0x607.
However, then something does terribly wrong mid-request and the write addresses change to 0x500-0x507 with a control register at 0x582, then 0x600-0x607 with a control register at 0x582 and then 0x700-0x707 with a control register of 0x682 again.
I'm current leaning towards this being a bug in Qemu...
So perhaps the 57 that it tries to write as an IDE CMD is getting pulled out of a memory location that the IDE code shouldn't be accessing?
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On Thu, Dec 10, 2009 at 12:11 AM, Nick Couchman Nick.Couchman@seakr.com wrote:
That's interesting. From the whole output you posted in the pastebin, it looks as if the IDE control register is located at 0x682 and various bits of data are written between 0x600 and 0x607.
However, then something does terribly wrong mid-request and the write addresses change to 0x500-0x507 with a control register at 0x582, then 0x600-0x607 with a control register at 0x582 and then 0x700-0x707 with a control register of 0x682 again.
I'm current leaning towards this being a bug in Qemu...
So perhaps the 57 that it tries to write as an IDE CMD is getting pulled out of a memory location that the IDE code shouldn't be accessing?
Well qemu's crash is a bug in qemu for sure. The garbage being written is probably due to device i/o mapping issues (could clash with physical ram mapped low) so is separate issue. Of course we will need to solve both :) Do you see screen garbage before crash?
Well qemu's crash is a bug in qemu for sure. The garbage being written is probably due to device i/o mapping issues (could clash with physical ram mapped low) so is separate issue. Of course we will need to solve both :) Do you see screen garbage before crash?
No, I don't really see any garbage. If I boot without any debugging at all, I see the following:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Dec 9 2009 19:06 Type 'help' for detailed information
0 > boot cdrom [sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Evaluating FCode... qemu: unsupported keyboard cmd=0x57 sSegmentation fault
The only things of interest are 1) that it's referencing a keyboard command with the error really seems to be in the IDE code, and 2) that there's an extra "s" before the segmentation fault. This probably confirms Mark's suspicion that the IDE code is writing to the wrong memory segment - perhaps to the keyboard segment, as Qemu generates a keyboard error and an extra character. I don't know if that's technically considered garbage or not...
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Igor Kovalenko wrote:
Well qemu's crash is a bug in qemu for sure. The garbage being written is probably due to device i/o mapping issues (could clash with physical ram mapped low) so is separate issue. Of course we will need to solve both :) Do you see screen garbage before crash?
Yeah; a keyboard command error and a single letter "s" with -nographic:
qemu: unsupported keyboard cmd=0x57 sSegmentation fault
The segmentation fault is actually the Qemu host process dying. The VNC display looks more interesting; it seems that something is writing all over the screen memory just before the crash happens.
I believe from Nick's email that he can also recreate this using latest OpenBIOS SVN, a recent pull of Qemu and a Milax 0.3.2 ISO image.
HTH,
Mark.
Yeah; a keyboard command error and a single letter "s" with -nographic:
qemu: unsupported keyboard cmd=0x57 sSegmentation fault
The segmentation fault is actually the Qemu host process dying. The VNC display looks more interesting; it seems that something is writing all over the screen memory just before the crash happens.
I believe from Nick's email that he can also recreate this using latest OpenBIOS SVN, a recent pull of Qemu and a Milax 0.3.2 ISO image.
Yep...I can recreate with Qemu pulled from the git repo, OpenBIOS from svn, and both Milax and the Solaris Nevada ISOs.
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On Thu, Dec 10, 2009 at 12:47 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor Kovalenko wrote:
Well qemu's crash is a bug in qemu for sure. The garbage being written is probably due to device i/o mapping issues (could clash with physical ram mapped low) so is separate issue. Of course we will need to solve both :) Do you see screen garbage before crash?
Yeah; a keyboard command error and a single letter "s" with -nographic:
qemu: unsupported keyboard cmd=0x57 sSegmentation fault
Do you run in graphics mode at all? The garbage I see is in qemu screen, due to framebuffer being mapped where data is loaded by milax code.
The segmentation fault is actually the Qemu host process dying. The VNC display looks more interesting; it seems that something is writing all over the screen memory just before the crash happens.
I believe from Nick's email that he can also recreate this using latest OpenBIOS SVN, a recent pull of Qemu and a Milax 0.3.2 ISO image.
To heat things up: found another issue in conditional evaluation handling by qemu-system-sparc64, will try to prepare a patch for qemu but this could take some time. Current experimental record:
On serial: Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Evaluating FCode... OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000000000000 -> 0000000000000000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000008000000 -> 0000000000000000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000000002000 -> 0000000000002000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000008002000 -> 0000000000002000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000000004000 -> 0000000000004000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000008004000 -> 0000000000004000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000000006000 -> 0000000000006000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000008006000 -> 0000000000006000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim phys=ffffffffffffffff size=000000000554e000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000000008000 -> 0000000000008000 000000000554e000 mode 0000000000000032 OFMEM: ofmem_claim_virt virt=0000000051000000 size=000000000554e000 align=0000000000000000 OFMEM: ofmem_map_page_range 0000000051000000 -> 0000000000008000 000000000554e000 mode 0000000000000032 OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000005556000 -> 0000000005556000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000000001 OFMEM: ofmem_map_page_range 0000000008008000 -> 0000000005556000 0000000000002000 mode 0000000000000032 OFMEM: ofmem_release_virt addr=0000000008008000 size=0000000000002000 OFMEM: ofmem_release_virt not implemented
On screen: Welcome to OpenBIOS v1.0 built on Dec 9 2009 19:06 Type 'help' for detailed information
$call-method: instance method not found
Can't open /ramdisk-root
byte-load: exception caught!
On Thu, Dec 10, 2009 at 1:02 AM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Thu, Dec 10, 2009 at 12:47 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor Kovalenko wrote:
Well qemu's crash is a bug in qemu for sure. The garbage being written is probably due to device i/o mapping issues (could clash with physical ram mapped low) so is separate issue. Of course we will need to solve both :) Do you see screen garbage before crash?
Yeah; a keyboard command error and a single letter "s" with -nographic:
qemu: unsupported keyboard cmd=0x57 sSegmentation fault
Do you run in graphics mode at all? The garbage I see is in qemu screen, due to framebuffer being mapped where data is loaded by milax code.
The segmentation fault is actually the Qemu host process dying. The VNC display looks more interesting; it seems that something is writing all over the screen memory just before the crash happens.
I believe from Nick's email that he can also recreate this using latest OpenBIOS SVN, a recent pull of Qemu and a Milax 0.3.2 ISO image.
Please try this patch as well, helps clearing a few subtle memory issues.
openbios-forth-package-prevent-null-dereferences
- Prevent dereferencing page zero and complain about invalid handles
Signed-off-by: igor.v.kovalenko@gmail.com
Please try this patch as well, helps clearing a few subtle memory issues.
openbios-forth-package-prevent-null-dereferences
- Prevent dereferencing page zero and complain about invalid handles
If I understood correctly, this patch was not intended to fix the SPARC64 IDE emulation error, but, just to make sure, I don't see any improved behavior with this patch. I see a couple of call-method outputs to the screen as qemu is starting up (before the 0> prompt), but that's about it.
Also, has anyone thrown this issue up on the qemu-devel list, yet? I didn't see anything out there, yet, but may have missed it and was wondering if someone else was already working on getting it posted over there? If not, I'll be happy to kick off the thread on that list and provide some details to the Qemu developers.
-Nick
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On Thu, Dec 10, 2009 at 7:02 PM, Nick Couchman Nick.Couchman@seakr.com wrote:
Please try this patch as well, helps clearing a few subtle memory issues.
openbios-forth-package-prevent-null-dereferences
- Prevent dereferencing page zero and complain about invalid handles
If I understood correctly, this patch was not intended to fix the SPARC64 IDE emulation error, but, just to make sure, I don't see any improved behavior with this patch. I see a couple of call-method outputs to the screen as qemu is starting up (before the 0> prompt), but that's about it.
That's correct, still there was a remote chance you hit this issue. Fortunately package implementation does only read the value from zero page so loaded data should be not modified if you see some output from call-method.
Also, has anyone thrown this issue up on the qemu-devel list, yet? I didn't see anything out there, yet, but may have missed it and was wondering if someone else was already working on getting it posted over there? If not, I'll be happy to kick off the thread on that list and provide some details to the Qemu developers.
Ide emulation issue is not on qemu list yet. From what I see here it is not really a driver implementation fault because driver callback gets bogus pointer. Probably this is caused by some clash with low memory location where device i/o space is mapped.
Ide emulation issue is not on qemu list yet. From what I see here it is not really a driver implementation fault because driver callback gets bogus pointer. Probably this is caused by some clash with low memory location where device i/o space is mapped.
Pardon my ignorance, but are you saying that Qemu is throwing a bogus pointer back to OpenBIOS, or that there's something wrong with OpenBIOS that's requesting the wrong memory location? So is it worth opening a thread on the qemu-devel list, or is everyone who needs to work the problem already on this list?
-------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On Fri, Dec 11, 2009 at 12:22 AM, Nick Couchman Nick.Couchman@seakr.com wrote:
Ide emulation issue is not on qemu list yet. From what I see here it is not really a driver implementation fault because driver callback gets bogus pointer. Probably this is caused by some clash with low memory location where device i/o space is mapped.
Pardon my ignorance, but are you saying that Qemu is throwing a bogus pointer back to OpenBIOS, or that there's something wrong with OpenBIOS that's requesting the wrong memory location? So is it worth opening a thread on the qemu-devel list, or is everyone who needs to work the problem already on this list?
I think it's both parties, in that openbios calls cause qemu code to crash, which should not happen. Still the crash is in emulation code, and that is to be fixed eventually. What I'm sure about at the moment is that we can work around qemu issues in this area by moving most of pci address space out of 32bit memory. Related change to qemu is already proposed on the qemu-devel list quite a while ago, and most of the required changes are now implemented, like 64bit wide addressing for mapped pci memory space - that is now possible. What's left is the actual remapping change, that would need more time to get into code base, as current proposal may be seen as functional but conceptually wrong workaround. That said I'd be happy to see a fix for this cmd646 crash issue in qemu, and will look into tracing this crash to root cause.
On Fri, Dec 11, 2009 at 12:49 AM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Fri, Dec 11, 2009 at 12:22 AM, Nick Couchman Nick.Couchman@seakr.com wrote:
Ide emulation issue is not on qemu list yet. From what I see here it is not really a driver implementation fault because driver callback gets bogus pointer. Probably this is caused by some clash with low memory location where device i/o space is mapped.
Pardon my ignorance, but are you saying that Qemu is throwing a bogus pointer back to OpenBIOS, or that there's something wrong with OpenBIOS that's requesting the wrong memory location? So is it worth opening a thread on the qemu-devel list, or is everyone who needs to work the problem already on this list?
I think it's both parties, in that openbios calls cause qemu code to crash, which should not happen. Still the crash is in emulation code, and that is to be fixed eventually. What I'm sure about at the moment is that we can work around qemu issues in this area by moving most of pci address space out of 32bit memory. Related change to qemu is already proposed on the qemu-devel list quite a while ago, and most of the required changes are now implemented, like 64bit wide addressing for mapped pci memory space - that is now possible. What's left is the actual remapping change, that would need more time to get into code base, as current proposal may be seen as functional but conceptually wrong workaround. That said I'd be happy to see a fix for this cmd646 crash issue in qemu, and will look into tracing this crash to root cause.
The qemu issue with cmd646 amounts to a bug in reading or writing registers for second dma channel. It appears to be a regression, but withoud cmd646 documentation it is not clear how to fix it. It may be that original cmd646 code is misinterpreting dma channel data. First channel should work though.
How we get to dma channel registers? Those are mapped into low 16mb of memory by openbios startup code, and it turns out that we do not claim that mapped memory so it is still claimable. Milax loader claims that memory for it's own needs, and loading data there does write something to cmd646 dma channel registers.
How do we solve this?
- My original idea was to relocate i/o space so that low physical memory address space does not intersect with i/o space. A few required changes to both qemu and openbios code are in the works.
- Alternatively we can claim mapped address space, so milax loader does not use it on it's own. Please see the patch attached, it allows to skip cmd646 implementation issue since openbios will not access broken part of register space.
I'm positive there are more issues with address mappings done by openbios, both for client program code and for own use as well. If someone could enlighten me on how memory mappings should look like at the time client program receives control, it would be sincerely appreciated.
On Sun, Dec 13, 2009 at 11:53 AM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Fri, Dec 11, 2009 at 12:49 AM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Fri, Dec 11, 2009 at 12:22 AM, Nick Couchman Nick.Couchman@seakr.com wrote:
Ide emulation issue is not on qemu list yet. From what I see here it is not really a driver implementation fault because driver callback gets bogus pointer. Probably this is caused by some clash with low memory location where device i/o space is mapped.
Pardon my ignorance, but are you saying that Qemu is throwing a bogus pointer back to OpenBIOS, or that there's something wrong with OpenBIOS that's requesting the wrong memory location? So is it worth opening a thread on the qemu-devel list, or is everyone who needs to work the problem already on this list?
I think it's both parties, in that openbios calls cause qemu code to crash, which should not happen. Still the crash is in emulation code, and that is to be fixed eventually. What I'm sure about at the moment is that we can work around qemu issues in this area by moving most of pci address space out of 32bit memory. Related change to qemu is already proposed on the qemu-devel list quite a while ago, and most of the required changes are now implemented, like 64bit wide addressing for mapped pci memory space - that is now possible. What's left is the actual remapping change, that would need more time to get into code base, as current proposal may be seen as functional but conceptually wrong workaround. That said I'd be happy to see a fix for this cmd646 crash issue in qemu, and will look into tracing this crash to root cause.
The qemu issue with cmd646 amounts to a bug in reading or writing registers for second dma channel. It appears to be a regression, but withoud cmd646 documentation it is not clear how to fix it. It may be that original cmd646 code is misinterpreting dma channel data. First channel should work though.
I found the data sheet from: http://www.datasheet.org.uk/pdf/Datasheet-03/DSA0038524.pdf
However, it refers to Intel docs for bus master register programming.
How we get to dma channel registers? Those are mapped into low 16mb of memory by openbios startup code, and it turns out that we do not claim that mapped memory so it is still claimable. Milax loader claims that memory for it's own needs, and loading data there does write something to cmd646 dma channel registers.
How do we solve this?
- My original idea was to relocate i/o space so that low physical
memory address space does not intersect with i/o space. A few required changes to both qemu and openbios code are in the works.
I think this would be closest to how real HW operates.
- Alternatively we can claim mapped address space, so milax
loader does not use it on it's own. Please see the patch attached, it allows to skip cmd646 implementation issue since openbios will not access broken part of register space.
I didn't see any improvement in the few tests I tried. I guess the patch does not hurt, though.
On Sun, Dec 13, 2009 at 7:19 PM, Blue Swirl blauwirbel@gmail.com wrote:
On Sun, Dec 13, 2009 at 11:53 AM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Fri, Dec 11, 2009 at 12:49 AM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Fri, Dec 11, 2009 at 12:22 AM, Nick Couchman Nick.Couchman@seakr.com wrote:
Ide emulation issue is not on qemu list yet. From what I see here it is not really a driver implementation fault because driver callback gets bogus pointer. Probably this is caused by some clash with low memory location where device i/o space is mapped.
Pardon my ignorance, but are you saying that Qemu is throwing a bogus pointer back to OpenBIOS, or that there's something wrong with OpenBIOS that's requesting the wrong memory location? So is it worth opening a thread on the qemu-devel list, or is everyone who needs to work the problem already on this list?
I think it's both parties, in that openbios calls cause qemu code to crash, which should not happen. Still the crash is in emulation code, and that is to be fixed eventually. What I'm sure about at the moment is that we can work around qemu issues in this area by moving most of pci address space out of 32bit memory. Related change to qemu is already proposed on the qemu-devel list quite a while ago, and most of the required changes are now implemented, like 64bit wide addressing for mapped pci memory space - that is now possible. What's left is the actual remapping change, that would need more time to get into code base, as current proposal may be seen as functional but conceptually wrong workaround. That said I'd be happy to see a fix for this cmd646 crash issue in qemu, and will look into tracing this crash to root cause.
The qemu issue with cmd646 amounts to a bug in reading or writing registers for second dma channel. It appears to be a regression, but withoud cmd646 documentation it is not clear how to fix it. It may be that original cmd646 code is misinterpreting dma channel data. First channel should work though.
I found the data sheet from: http://www.datasheet.org.uk/pdf/Datasheet-03/DSA0038524.pdf
However, it refers to Intel docs for bus master register programming.
How we get to dma channel registers? Those are mapped into low 16mb of memory by openbios startup code, and it turns out that we do not claim that mapped memory so it is still claimable. Milax loader claims that memory for it's own needs, and loading data there does write something to cmd646 dma channel registers.
How do we solve this?
- My original idea was to relocate i/o space so that low physical
memory address space does not intersect with i/o space. A few required changes to both qemu and openbios code are in the works.
I think this would be closest to how real HW operates.
We also need to find out how memory mappings are laid out preparing to run client code. It is not clear from of1275 docs.
- Alternatively we can claim mapped address space, so milax
loader does not use it on it's own. Please see the patch attached, it allows to skip cmd646 implementation issue since openbios will not access broken part of register space.
I didn't see any improvement in the few tests I tried. I guess the patch does not hurt, though.
It stops writing over 0x700...0x70d range while loading block from device, that range is where bmdma registers are mapped. To see this logged I have to turn on DEBUG_IDE in qemu.
Igor Kovalenko wrote:
[...] We also need to find out how memory mappings are laid out preparing to run client code. It is not clear from of1275 docs.
Generally, OF is placed in high memory, and memory allocations are from low memory.
But there are several address spaces, which it sounds like are being overlapped here:
1) Actual memory 2) PCI memory space 3) PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Note that PCI memory space is further subdivided into DMA address space and BAR memory space. In general on SPARC (with Openboot, at least), we use low addresses in PCI memory space for BARs and high addresses for DMA (backwards from x86 behaviour). We've found a number of devices which refuse to allow us to assign PCI memory space 0 to a BAR - so we've had to reserve the low order page of PCI memory and not assign it to BARs.
On Sun, Dec 13, 2009 at 9:07 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Igor Kovalenko wrote:
[...] We also need to find out how memory mappings are laid out preparing to run client code. It is not clear from of1275 docs.
Generally, OF is placed in high memory, and memory allocations are from low memory.
That is how memory layout looks like now, if we look at 32bits of physical address space. The only difference seems to be with low 16m being used for both pci memory, i/o space and actual memory. It's getting mapped 1:1 into virtual address space used by openbios code.
What is really confusing is how exactly we need to claim and map memory for client program. Some client programs appear to be happy with read-write privileged mapping, some may expect global translation, and docs are basically silent in this regard. Can we do 4M page mappings?
But there are several address spaces, which it sounds like are being overlapped here:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Note that PCI memory space is further subdivided into DMA address space and BAR memory space. In general on SPARC (with Openboot, at least), we use low addresses in PCI memory space for BARs and high addresses for DMA (backwards from x86 behaviour). We've found a number of devices which refuse to allow us to assign PCI memory space 0 to a BAR - so we've had to reserve the low order page of PCI memory and not assign it to BARs.
Thanks for the hint!
Igor Kovalenko wrote:
[...] What is really confusing is how exactly we need to claim and map memory for client program. Some client programs appear to be happy with read-write privileged mapping, some may expect global translation, and docs are basically silent in this regard. Can we do 4M page mappings?
Sure. We tend to do 8K mappings, but 4M shouldn't be any different, as long as you don't run out of virtual address space.
Igor Kovalenko wrote:
Generally, OF is placed in high memory, and memory allocations are from low memory.
That is how memory layout looks like now, if we look at 32bits of physical address space. The only difference seems to be with low 16m being used for both pci memory, i/o space and actual memory. It's getting mapped 1:1 into virtual address space used by openbios code.
Ah this is now starting to make sense. I assumed from reading the OpenBIOS code that PCI devices were just mapped directly to virtual addresses, but I can see that this may not necessary be the case. Does that mean OpenBIOS is missing some kind of PCI controller emulation in order to access PCI memory space?
Though I can also see that this wouldn't just affect the Qemu/SPARC combination so I'm quite surprised that this hasn't been noticed before on other guest/host combinations.
But there are several address spaces, which it sounds like are being overlapped here:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
I've never looked at PCI devices in much detail before, however if there is any C coding I can do to help out, please let me know.
ATB,
Mark.
On Sun, Dec 13, 2009 at 11:39 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor Kovalenko wrote:
Generally, OF is placed in high memory, and memory allocations are from low memory.
That is how memory layout looks like now, if we look at 32bits of physical address space. The only difference seems to be with low 16m being used for both pci memory, i/o space and actual memory. It's getting mapped 1:1 into virtual address space used by openbios code.
Ah this is now starting to make sense. I assumed from reading the OpenBIOS code that PCI devices were just mapped directly to virtual addresses, but I can see that this may not necessary be the case. Does that mean OpenBIOS is missing some kind of PCI controller emulation in order to access PCI memory space?
Though I can also see that this wouldn't just affect the Qemu/SPARC combination so I'm quite surprised that this hasn't been noticed before on other guest/host combinations.
Well, sparc64 is a bit unique.
From what I have seen almost any other openbios platform is either 32bit
or has no pci devices, also every other platform has pci configuration mechanism 1 in place. - sparc64 has no configuration mechanism 1 (which has basically a single port to implement configuration protocol) but directly maps configuration space. So for sparc64 pci is also quite different from the rest, and a few clients know about that mapped configuration space. - PCI support is there and useful, but a few places has bar address mapping hardcoded; - getting ucells right on 64bit sparc was *real* fun :) It turns out that linux kernel started to rely more on prom tree data so that required ofmem supporting allocations and range properties; no other openbios platform seem to require implementing ofmem to such extent
But there are several address spaces, which it sounds like are being overlapped here:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
I've never looked at PCI devices in much detail before, however if there is any C coding I can do to help out, please let me know.
Welcome! But to my mind we need to get qemu part right first, in that we need to remap pci address spaces out of low addresses. If you could invent another workaround it would be a good start, we need get these 3 address spaces right one way or another.
Igor Kovalenko wrote:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Well, sparc64 is a bit unique.
From what I have seen almost any other openbios platform is either 32bit or has no pci devices, also every other platform has pci configuration mechanism 1 in place.
- sparc64 has no configuration mechanism 1 (which has basically a single port
to implement configuration protocol) but directly maps configuration space. So for sparc64 pci is also quite different from the rest, and a few clients know about that mapped configuration space.
- PCI support is there and useful, but a few places has bar address
mapping hardcoded;
- getting ucells right on 64bit sparc was *real* fun :) It turns out that linux
kernel started to rely more on prom tree data so that required ofmem supporting allocations and range properties; no other openbios platform seem to require implementing ofmem to such extent
Right, so is what you're saying is that at a minimum we'd need to implement 2) with a PCI configuration mechanism in place for this to stand any chance of working? Would the configuration mechanism simply be a set of MMIO addresses?
I've never looked at PCI devices in much detail before, however if there is any C coding I can do to help out, please let me know.
Welcome! But to my mind we need to get qemu part right first, in that we need to remap pci address spaces out of low addresses. If you could invent another workaround it would be a good start, we need get these 3 address spaces right one way or another.
Does that mean you've already started working on the Qemu side of this? If so, again let me know if I can help at all. Incidentally if you already have ideas for this, it's probably worth floating any proposals to the qemu-devel list first before doing any coding, just to make sure that they would be happy to accept patches implementing this new functionality.
ATB,
Mark.
On Tue, Dec 15, 2009 at 8:30 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor Kovalenko wrote:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Well, sparc64 is a bit unique.
From what I have seen almost any other openbios platform is either 32bit or has no pci devices, also every other platform has pci configuration mechanism 1 in place.
- sparc64 has no configuration mechanism 1 (which has basically a single
port to implement configuration protocol) but directly maps configuration space. So for sparc64 pci is also quite different from the rest, and a few clients know about that mapped configuration space.
- PCI support is there and useful, but a few places has bar address
mapping hardcoded;
- getting ucells right on 64bit sparc was *real* fun :) It turns out that
linux kernel started to rely more on prom tree data so that required ofmem supporting allocations and range properties; no other openbios platform seem to require implementing ofmem to such extent
Right, so is what you're saying is that at a minimum we'd need to implement 2) with a PCI configuration mechanism in place for this to stand any chance of working? Would the configuration mechanism simply be a set of MMIO addresses?
Bare minimum is to move legacy device registers, pci control registers and pci memory space out of physical ram space. Obvious workaround is to claim out patches of ram space so those cannot be mapped by client, downside is that looking at memory issues is non-trivial with non-uniform mapping. Also physical memory would be at waste.
Second required part is tick timer support. In my local experiments this is only directly visible in linux kernel runs. Others (including helenos and milax) do not really get to using timer yet.
I've never looked at PCI devices in much detail before, however if there is any C coding I can do to help out, please let me know.
Welcome! But to my mind we need to get qemu part right first, in that we need to remap pci address spaces out of low addresses. If you could invent another workaround it would be a good start, we need get these 3 address spaces right one way or another.
Does that mean you've already started working on the Qemu side of this? If so, again let me know if I can help at all. Incidentally if you already have ideas for this, it's probably worth floating any proposals to the qemu-devel list first before doing any coding, just to make sure that they would be happy to accept patches implementing this new functionality.
It was already proposed to allow sparc64 to shift pci memory space by a constant offset (say 0x1fe00000000 as it is on real hardware) so qemu could map device bars into 64bit address space where those belong. Originally that change was quite huge since all pci devices were touched, to support bars mapped above 32bit space. Most of those changes are in qemu code already, so it may be worth doing another patch submission round.
Igor Kovalenko wrote:
Bare minimum is to move legacy device registers, pci control registers and pci memory space out of physical ram space. Obvious workaround is to claim out patches of ram space so those cannot be mapped by client, downside is that looking at memory issues is non-trivial with non-uniform mapping. Also physical memory would be at waste.
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
Second required part is tick timer support. In my local experiments this is only directly visible in linux kernel runs. Others (including helenos and milax) do not really get to using timer yet.
Well the Milax ISO does, because it tries to set an alarm to draw the twirly baton on screen. So if we can find a way of setting an alarm() for x ms then we can make use of it.
Does that mean you've already started working on the Qemu side of this? If so, again let me know if I can help at all. Incidentally if you already have ideas for this, it's probably worth floating any proposals to the qemu-devel list first before doing any coding, just to make sure that they would be happy to accept patches implementing this new functionality.
It was already proposed to allow sparc64 to shift pci memory space by a constant offset (say 0x1fe00000000 as it is on real hardware) so qemu could map device bars into 64bit address space where those belong. Originally that change was quite huge since all pci devices were touched, to support bars mapped above 32bit space. Most of those changes are in qemu code already, so it may be worth doing another patch submission round.
Okay; are you working on this at the moment? I've tried searching for sparc64 pci memory and qemu but don't seem to have found any hits. Can you point me towards the relevant patches?
ATB,
Mark.
On Tue, Dec 22, 2009 at 1:32 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor Kovalenko wrote:
Bare minimum is to move legacy device registers, pci control registers and pci memory space out of physical ram space. Obvious workaround is to claim out patches of ram space so those cannot be mapped by client, downside is that looking at memory issues is non-trivial with non-uniform mapping. Also physical memory would be at waste.
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
Second required part is tick timer support. In my local experiments this is only directly visible in linux kernel runs. Others (including helenos and milax) do not really get to using timer yet.
Well the Milax ISO does, because it tries to set an alarm to draw the twirly baton on screen. So if we can find a way of setting an alarm() for x ms then we can make use of it.
Does that mean you've already started working on the Qemu side of this? If so, again let me know if I can help at all. Incidentally if you already have ideas for this, it's probably worth floating any proposals to the qemu-devel list first before doing any coding, just to make sure that they would be happy to accept patches implementing this new functionality.
It was already proposed to allow sparc64 to shift pci memory space by a constant offset (say 0x1fe00000000 as it is on real hardware) so qemu could map device bars into 64bit address space where those belong. Originally that change was quite huge since all pci devices were touched, to support bars mapped above 32bit space. Most of those changes are in qemu code already, so it may be worth doing another patch submission round.
Okay; are you working on this at the moment? I've tried searching for sparc64 pci memory and qemu but don't seem to have found any hits. Can you point me towards the relevant patches?
Please try these patches.
Blue Swirl wrote:
Okay; are you working on this at the moment? I've tried searching for sparc64 pci memory and qemu but don't seem to have found any hits. Can you point me towards the relevant patches?
Please try these patches.
Sorry for the delay on this; I've just tried applying these patches to my updated qemu and it seems that parts of them have already been applied.
Looking through the changelog I see a partial reversion of these patches listed as commit c71b5b4a9c4ee680bc48eb02386f1dc4311e0fdb. Does that mean that this still needs some work before it can be activated in qemu?
ATB,
Mark.
On Sun, Dec 27, 2009 at 5:45 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Okay; are you working on this at the moment? I've tried searching for sparc64 pci memory and qemu but don't seem to have found any hits. Can you point me towards the relevant patches?
Please try these patches.
Sorry for the delay on this; I've just tried applying these patches to my updated qemu and it seems that parts of them have already been applied.
Looking through the changelog I see a partial reversion of these patches listed as commit c71b5b4a9c4ee680bc48eb02386f1dc4311e0fdb. Does that mean that this still needs some work before it can be activated in qemu?
Yes, the bus address translation (how to add the memory base to all memory BARs) needs some more thought.
[...]
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
PCI spaces are each mapped in separately in physical spaces on SPARC. On a Sun4u system, as I recall, the mappings are something like:
1fe.0000.0000-1fe.00ff.ffff : config-space (where it's bbddff, bus-device-function) 1fe.8000.0000-1fe.ffff.ffff: io space 1ff.0000.0000-1ff.ffff.ffff: 32-bit memory space
I'll get the exact addresses later on today. Also note there will be multiple such mappings, since we usually have multiple PCI roots.
On Tue, Dec 22, 2009 at 5:06 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
[...]
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
PCI spaces are each mapped in separately in physical spaces on SPARC. On a Sun4u system, as I recall, the mappings are something like:
1fe.0000.0000-1fe.00ff.ffff : config-space (where it's bbddff, bus-device-function) 1fe.8000.0000-1fe.ffff.ffff: io space 1ff.0000.0000-1ff.ffff.ffff: 32-bit memory space
I'll get the exact addresses later on today. Also note there will be multiple such mappings, since we usually have multiple PCI roots.
These are documented in "UltraSPARC-IIi User's Manual", 805-0087, Chapter 9.
Some relevant docs can be found in: http://wikis.sun.com/display/FOSSdocs/Home
BTW, the pages have been updated in ages. Nobody wants interesting documents anymore?
Blue Swirl wrote:
Some relevant docs can be found in: http://wikis.sun.com/display/FOSSdocs/Home
BTW, the pages have been updated in ages. Nobody wants interesting documents anymore?
I think the guy that was doing it left right before the big layoff.
I keep asking every once in a while for the documents I requested and I don't even get a reply anymore. I hope this stuff is backed up somewhere because it could go at any time.
On 12/22/09 6:31 PM, Blue Swirl wrote:
Some relevant docs can be found in: http://wikis.sun.com/display/FOSSdocs/Home
BTW, the pages have been updated in ages. Nobody wants interesting documents anymore?
The pages were last updated on September 4th, 2008. Maybe the reason is that Barton George, the open source expert at SUN who maintained the pages, left on September 5th -- the very next day. Unfortunately, good projects often leave with good people. That said, I want to thank Tarl for his support here over many years.
Stefan
Tarl Neustaedter wrote:
[...]
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
PCI spaces are each mapped in separately in physical spaces on SPARC. [...]
On a sun4u system (Tazmo, SUNW,Ultra-4), the first PCI root complex is a Psycho (Sun's first PCI bus chip) and has spaces at:
Config: 000001fe.01000000, length 00800000. IO: 000001fe.02010000 length 00010000. mem32: 000001ff.80000000 length 80000000. mem64: 000001ff.80000000 length 80000000
This can be derived from the "Ranges" property in the PCI node, attached below. Note that Psycho did not implement mem64 separately, so the mem64 space simply points to mem32 space. And it only has 31 bits of addressability - I recall the other half of the mem32 space is used for DMA, so thus not mappable as registers.
The config space is addressed precisely as defined by the PCI bindings "phys.hi" definition. That means it's composed of:
phys.hi: xxxxxxxx bbbbbbbb dddddfff rrrrrrrr
Where xxxx is not part of the addressing in above address space, bbbbbbbb is eight bits of bus number, ddddd is five bits of device number, fff is three bits of function number and rrrrrrrr is eight bits of register offset addressing (sorry I got it wrong on an earlier email, I was thinking of some pci-e stuff).
- - - - - PCI node as shown by Solaris "prtconf -pv":
Node 0xf006ebb8 slot-names: 0000001e.4d6f7468.6572626f.61726400.4d6f7468.6572626f.61726 400.4d6f7468.6572626f.61726400.50434920.736c6f74.20313000 available: 82000000.00000000.00017000.00000000.7ffe9000.81000000.000000 00.00000900.00000000.0000f700 bus-range: 00000000.00000000 version#: 00000004 implementation#: 00000000 address: fffb4000.fffb2000.fffa4000 #upa-interrupt-proxies: 00000002 clock-frequency: 01f78a40 upa-portid: 0000001f interrupts: 000007f1.000007ee.000007ef.000007e5.000007e8.000007f2 ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.00800000. 01000000.00000000.00000000.000001fe.02010000.00000000.00010000.02000000.00000000 .00000000.000001ff.80000000.00000000.80000000.03000000.00000000.00000000.000001f f.80000000.00000000.80000000 reg: 000001fe.00004000.00000000.00002000.000001fe.01000000.00000000.000 00100.000001fe.00000000.00000000.0000d000 no-probe-list: '0' latency-timer: 00000040 model: 'SUNW,psycho' compatible: 'pci108e,8000' + 'pciclass,060000' thermal-interrupt: bus-parity-generated: #size-cells: 00000002 #address-cells: 00000003 device_type: 'pci' name: 'pci'
On Tue, Dec 22, 2009 at 7:20 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Tarl Neustaedter wrote:
[...]
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
PCI spaces are each mapped in separately in physical spaces on SPARC. [...]
On a sun4u system (Tazmo, SUNW,Ultra-4), the first PCI root complex is a Psycho (Sun's first PCI bus chip) and has spaces at:
QEMU is emulating a Sabre/Simba based system.
Config: 000001fe.01000000, length 00800000. IO: 000001fe.02010000 length 00010000. mem32: 000001ff.80000000 length 80000000. mem64: 000001ff.80000000 length 80000000
There the values are (from the US-IIi manual) Config: 000001fe.01000000, length 00800000? IO: 000001fe.02000000 length 00100000 mem32: 000001ff.00000000 length f0000000 (4G - PROM) mem64: 000001ff.80000000 length f0000000 (I think)
This can be derived from the "Ranges" property in the PCI node, attached below. Note that Psycho did not implement mem64 separately, so the mem64 space simply points to mem32 space. And it only has 31 bits of addressability - I recall the other half of the mem32 space is used for DMA, so thus not mappable as registers.
The config space is addressed precisely as defined by the PCI bindings "phys.hi" definition. That means it's composed of:
phys.hi: xxxxxxxx bbbbbbbb dddddfff rrrrrrrr
Where xxxx is not part of the addressing in above address space, bbbbbbbb is eight bits of bus number, ddddd is five bits of device number, fff is three bits of function number and rrrrrrrr is eight bits of register offset addressing (sorry I got it wrong on an earlier email, I was thinking of some pci-e stuff).
Same as Sabre.
PCI node as shown by Solaris "prtconf -pv":
Node 0xf006ebb8 slot-names: 0000001e.4d6f7468.6572626f.61726400.4d6f7468.6572626f.61726 400.4d6f7468.6572626f.61726400.50434920.736c6f74.20313000 available: 82000000.00000000.00017000.00000000.7ffe9000.81000000.000000 00.00000900.00000000.0000f700 bus-range: 00000000.00000000 version#: 00000004 implementation#: 00000000 address: fffb4000.fffb2000.fffa4000 #upa-interrupt-proxies: 00000002 clock-frequency: 01f78a40 upa-portid: 0000001f interrupts: 000007f1.000007ee.000007ef.000007e5.000007e8.000007f2 ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.00800000. 01000000.00000000.00000000.000001fe.02010000.00000000.00010000.02000000.00000000 .00000000.000001ff.80000000.00000000.80000000.03000000.00000000.00000000.000001f f.80000000.00000000.80000000 reg: 000001fe.00004000.00000000.00002000.000001fe.01000000.00000000.000 00100.000001fe.00000000.00000000.0000d000 no-probe-list: '0' latency-timer: 00000040 model: 'SUNW,psycho' compatible: 'pci108e,8000' + 'pciclass,060000' thermal-interrupt: bus-parity-generated: #size-cells: 00000002 #address-cells: 00000003 device_type: 'pci' name: 'pci'
This one is from "SUNW,Ultra-5_10":
Node 0xf005f1e0 bus-range: 00000000.00000002 available: 82000000.00000000.00001000.00000000.fffff000.81000000.000000 00.00000400.00000000.00fffc00.00006176.61696c61 virtual-dma: c0000000.20000000 #virtual-dma-size-cells: 00000001 #virtual-dma-addr-cells: 00000001 latency-timer: address: fffc4000.fffc2000 button-interrupt: no-streaming-cache: clock-frequency: 03ef1480 upa-portid: 0000001f 66mhz-capable: interrupts: 000007f0.000007ee.000007ef.000007e5 ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. 01000000.00000000.00000000.000001fe.02000000.00000000.01000000.02000000.00000000 .00000000.000001ff.00000000.00000001.00000000.03000000.00000000.00000000.000001f f.00000000.00000001.00000000 reg: 000001fe.00000000.00000000.00010000.000001fe.01000000.00000000.000 00100 model: 'SUNW,sabre' compatible: 70636931.3038652c.61303030.00706369 bus-parity-generated: #size-cells: '00000002' #address-cells: '00000003' device_type: 'pci' name: 'pci'
Node 0xf005f9d4 bus-range: 00000001.00000001 scsi-initiator-id: 00000007 compatible: 70636931.3038652c.35303030.00706369 66mhz-capable: fast-back-to-back: devsel-speed: 00000001 class-code: 00060400 revision-id: 00000011 device-id: 00005000 vendor-id: 0000108e interrupt-map: 00010800.00000000.00000000.00000001.f005f1e0.0000002 1.00011000.00000000.00000000.00000001.f005f1e0.0000000f.00011800.00000000.000000 00.00000001.f005f1e0.00000020 interrupt-map-mask: 00fff800.00000000.00000000.00000007 #interrupt-cells: 00000001 slot-names: 00000000 no-probe-list: '0' clock-frequency: 01f78a40 model: 'SUNW,simba' #address-cells: 00000003 #size-cells: 00000002 reg: 00000900.00000000.00000000.00000000.00000000 device_type: 'pci' name: 'pci'
[...]
QEMU is emulating a Sabre/Simba based system.
I'll keep that in mind - I never actually worked on one of those systems.
There the values are (from the US-IIi manual) Config: 000001fe.01000000, length 00800000? IO: 000001fe.02000000 length 00100000 mem32: 000001ff.00000000 length f0000000 (4G - PROM) mem64: 000001ff.80000000 length f0000000 (I think)
The ranges property you showed below comes out with:
00000000.00000000.00000000.000001fe.01000000.00000000.01000000. 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. 03000000.00000000.00000000.000001ff.00000000.00000001.00000000
Config space is twice the size of Psycho's, at 01000000 - so supports 256 buses instead of the 128 psycho did (defect in that chip). IO space supports a full 24-bit address as well (length 01000000). And the memory spaces support the full 32 bits (length 1.00000000), although in practice you have to reserve some address space for DMA.
On Sun, Dec 13, 2009 at 9:29 PM, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Sun, Dec 13, 2009 at 9:07 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Igor Kovalenko wrote:
[...] We also need to find out how memory mappings are laid out preparing to run client code. It is not clear from of1275 docs.
Generally, OF is placed in high memory, and memory allocations are from low memory.
That is how memory layout looks like now, if we look at 32bits of physical address space. The only difference seems to be with low 16m being used for both pci memory, i/o space and actual memory. It's getting mapped 1:1 into virtual address space used by openbios code.
What is really confusing is how exactly we need to claim and map memory for client program. Some client programs appear to be happy with read-write privileged mapping, some may expect global translation, and docs are basically silent in this regard. Can we do 4M page mappings?
But there are several address spaces, which it sounds like are being overlapped here:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Just thought this needs more words to clarify.
From CPU point of view all three of these address spaces are just distinct
regions in single physical address space accessible with simple load/store instructions. What happens now on qemu side is that we have i/o space and pci memory space addresses assigned near start of actual memory address space. Qemu effectively gives actual memory locations less precedence after i/o and pci bars are mapped by initialization routines, so the issue with ide bmdma registers is obvious.
-
Blue Swirl -
Igor Kovalenko -
Mark Cave-Ayland -
Nick Couchman -
Robert Reif -
Stefan Reinauer -
Stefan Reinauer -
Tarl Neustaedter