Le vendredi 20 novembre 2009 à 20:09 +0100, svn@openbios.org a écrit :
Author: stepan Date: 2009-11-20 20:09:04 +0100 (Fri, 20 Nov 2009) New Revision: 624
Modified: trunk/openbios-devel/forth/system/ciface.fs Log: In the IEEE 1275-1994 specification the parameters for Client Interface calls are not in forth stack order but in reversed (heh!) order. Our implementation confused this.
This might / will need some more work, but get this in so more people can test easily.
This breaks PPC boot. All my ISO disk images (Fedora 10, 11, debian 5.0.0, 4.0r6, openSUSE 11.1, openbsd 4.6, freebsd 7.2 ...) hang. They are yaboot based.
My etch HD disk image hangs with this message (it is quik based):
call-method AG�@: exception 5401f50
Regards, Laurent
On 11/20/09 11:40 PM, Laurent Vivier wrote:
Le vendredi 20 novembre 2009 à 20:09 +0100, svn@openbios.org a écrit :
Author: stepan Date: 2009-11-20 20:09:04 +0100 (Fri, 20 Nov 2009) New Revision: 624
Modified: trunk/openbios-devel/forth/system/ciface.fs Log: In the IEEE 1275-1994 specification the parameters for Client Interface calls are not in forth stack order but in reversed (heh!) order. Our implementation confused this.
This might / will need some more work, but get this in so more people can test easily.
This breaks PPC boot. All my ISO disk images (Fedora 10, 11, debian 5.0.0, 4.0r6, openSUSE 11.1, openbsd 4.6, freebsd 7.2 ...) hang. They are yaboot based.
My etch HD disk image hangs with this message (it is quik based):
call-method AG�@: exception 5401f50
I am very sorry! Can you please try whether the problem goes away by just undoing the changes to call-method itself?
In that case we should back them out. Otherwise we should back out the whole patch...
Stefan
On Sat, Nov 21, 2009 at 1:13 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 11/20/09 11:40 PM, Laurent Vivier wrote:
Le vendredi 20 novembre 2009 à 20:09 +0100, svn@openbios.org a écrit :
Author: stepan Date: 2009-11-20 20:09:04 +0100 (Fri, 20 Nov 2009) New Revision: 624
Modified: trunk/openbios-devel/forth/system/ciface.fs Log: In the IEEE 1275-1994 specification the parameters for Client Interface calls are not in forth stack order but in reversed (heh!) order. Our implementation confused this.
This might / will need some more work, but get this in so more people can test easily.
This breaks PPC boot. All my ISO disk images (Fedora 10, 11, debian 5.0.0, 4.0r6, openSUSE 11.1, openbsd 4.6, freebsd 7.2 ...) hang. They are yaboot based.
My etch HD disk image hangs with this message (it is quik based):
call-method AG�@: exception 5401f50
I am very sorry! Can you please try whether the problem goes away by just undoing the changes to call-method itself?
In that case we should back them out. Otherwise we should back out the whole patch...
It also breaks Sparc64. Undoing just the call-method part does not help for either PPC or Sparc64, reverting fixes both.
But, if I check our rev 623, I'm back to the seek failed error :-).
-Nick
On 2009/11/21 at 03:29, Blue Swirl blauwirbel@gmail.com wrote:
On Sat, Nov 21, 2009 at 1:13 AM, Stefan Reinauer
stepan@coresystems.de wrote:
On 11/20/09 11:40 PM, Laurent Vivier wrote:
Le vendredi 20 novembre 2009 à 20:09 +0100, svn@openbios.org a
écrit :
Author: stepan Date: 2009-11-20 20:09:04 +0100 (Fri, 20 Nov 2009) New Revision: 624
Modified: trunk/openbios-devel/forth/system/ciface.fs Log: In the IEEE 1275-1994 specification the parameters for Client
Interface
calls
are not in forth stack order but in reversed (heh!) order. Our
implementation
confused this.
This might / will need some more work, but get this in so more
people can
test
easily.
This breaks PPC boot. All my ISO disk images (Fedora 10, 11,
debian
5.0.0, 4.0r6, openSUSE 11.1, openbsd 4.6, freebsd 7.2 ...) hang.
They
are yaboot based.
My etch HD disk image hangs with this message (it is quik based):
call-method AG@: exception 5401f50
I am very sorry! Can you please try whether the problem goes away
by
just undoing the changes to call-method itself?
In that case we should back them out. Otherwise we should back out
the
whole patch...
It also breaks Sparc64. Undoing just the call-method part does not help for either PPC or Sparc64, reverting fixes both.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-------- 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:
But, if I check our rev 623, I'm back to the seek failed error :-).
There seems to be some confusion between call-method and $call-method.
Call-method is defined as a client interface service in section 6.3.2.2 of IEEE 1275, with an argument list (cstyle): IN: [ string] method, ihandle, arg1, arg2... in other words, ( ... , arg2, arg1, ihandle, adr, len --)
$call-method is a base 1275 method defined in section 5.3.4.2 with an argument list of ( ..., adr, len, ihandle -- ??? )
Looking back at edit 624, it looks like the changes were being made to call-method, which were not correct.
It looks like the changes to read/write/seek were correct, but the change to call-method was mistaken.
On Sat, Nov 21, 2009 at 7:00 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Nick Couchman wrote:
But, if I check our rev 623, I'm back to the seek failed error :-).
There seems to be some confusion between call-method and $call-method.
Call-method is defined as a client interface service in section 6.3.2.2 of IEEE 1275, with an argument list (cstyle): IN: [ string] method, ihandle, arg1, arg2... in other words, ( ... , arg2, arg1, ihandle, adr, len --)
$call-method is a base 1275 method defined in section 5.3.4.2 with an argument list of ( ..., adr, len, ihandle -- ??? )
Looking back at edit 624, it looks like the changes were being made to call-method, which were not correct.
It looks like the changes to read/write/seek were correct, but the change to call-method was mistaken.
But if I revert just the call-method part, PPC and Sparc64 are still broken.
[sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... switching to new context: entry point 0x4000 stack 0x00000000ffe02a71 call-method : exception -21 call-method : exception -21 call-method : exception -21 EXIT 12 >
Tarl Neustaedter wrote:
Looking back at edit 624, it looks like the changes were being made to call-method, which were not correct.
It looks like the changes to read/write/seek were correct, but the change to call-method was mistaken.
Hi guys,
Sorry for the late reply - I've been away this weekend. Tarl, thanks for the advice - I didn't realise that call-method was actually part of the client services API rather than just an internal word, otherwise I wouldn't have changed it :(
I now have attached another version against SVN trunk that will again correctly read/seek from the qemu cdrom on my SPARC64 image which doesn't alter call-method. Blue Swirl/Laurent - please could you check this on your setups to see if it still breaks things for you?
Many thanks,
Mark.
Le dimanche 22 novembre 2009 à 11:44 +0000, Mark Cave-Ayland a écrit :
Tarl Neustaedter wrote:
Looking back at edit 624, it looks like the changes were being made to call-method, which were not correct.
It looks like the changes to read/write/seek were correct, but the change to call-method was mistaken.
Hi guys,
Sorry for the late reply - I've been away this weekend. Tarl, thanks for the advice - I didn't realise that call-method was actually part of the client services API rather than just an internal word, otherwise I wouldn't have changed it :(
I now have attached another version against SVN trunk that will again correctly read/seek from the qemu cdrom on my SPARC64 image which doesn't alter call-method. Blue Swirl/Laurent - please could you check this on your setups to see if it still breaks things for you?
Same result as previous one: yaboot hangs, but quik exits with: "call-method seek: exception -21"
Regards, Laurent
Laurent Vivier wrote:
Same result as previous one: yaboot hangs, but quik exits with: "call-method seek: exception -21"
Regards, Laurent
Thanks Laurent. Now I get it: the conversion routine in modules/client.c mistakenly put the CIF arguments into Forth the wrong way around using this piece of code:
for( i=pb->nargs-1; i>=0; i-- ) PUSH( pb->args[i] );
So, in other words: in order to fix this, we need to reverse the above loop so that the arguments are simply pushed onto the Forth stack in forward order, and then alter the Forth client interface words to take the new ordering into account. Then the CIF words can be called correctly from both Fcode and the C interface, and both our cases should work.
ATB,
Mark.
On 11/22/09 2:44 PM, Mark Cave-Ayland wrote:
Thanks Laurent. Now I get it: the conversion routine in modules/client.c mistakenly put the CIF arguments into Forth the wrong way around using this piece of code:
for( i=pb->nargs-1; i>=0; i-- ) PUSH( pb->args[i] );So, in other words: in order to fix this, we need to reverse the above loop so that the arguments are simply pushed onto the Forth stack in forward order, and then alter the Forth client interface words to take the new ordering into account. Then the CIF words can be called correctly from both Fcode and the C interface, and both our cases should work.
Nice finding... so our own work around to our own code made things break. Wonderful :-)
Stefan
Le dimanche 22 novembre 2009 à 13:44 +0000, Mark Cave-Ayland a écrit :
Laurent Vivier wrote:
Same result as previous one: yaboot hangs, but quik exits with: "call-method seek: exception -21"
Regards, Laurent
Thanks Laurent. Now I get it: the conversion routine in modules/client.c mistakenly put the CIF arguments into Forth the wrong way around using this piece of code:
for( i=pb->nargs-1; i>=0; i-- ) PUSH( pb->args[i] );So, in other words: in order to fix this, we need to reverse the above loop so that the arguments are simply pushed onto the Forth stack in forward order, and then alter the Forth client interface words to take the new ordering into account. Then the CIF words can be called correctly from both Fcode and the C interface, and both our cases should work.
I agree with that.
Regards, Laurent
On Sun, Nov 22, 2009 at 3:44 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Laurent Vivier wrote:
Same result as previous one: yaboot hangs, but quik exits with: "call-method seek: exception -21"
Regards, Laurent
Thanks Laurent. Now I get it: the conversion routine in modules/client.c mistakenly put the CIF arguments into Forth the wrong way around using this piece of code:
for( i=pb->nargs-1; i>=0; i-- ) PUSH( pb->args[i] );
So, in other words: in order to fix this, we need to reverse the above loop so that the arguments are simply pushed onto the Forth stack in forward order, and then alter the Forth client interface words to take the new ordering into account. Then the CIF words can be called correctly from both Fcode and the C interface, and both our cases should work.
But this patch also does not work: [sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... switching to new context: entry point 0x4000 stack 0x00000000ffe02a71 call-method : exception -21 call-method : exception -21 call-method : exception -21 EXIT
diff --git a/forth/system/ciface.fs b/forth/system/ciface.fs index eefb1b7..77ea3be 100644 --- a/forth/system/ciface.fs +++ b/forth/system/ciface.fs @@ -212,21 +212,16 @@ external close-dev ;
-: read ( ihandle addr len -- actual ) - rot dup ihandle>phandle " read" rot find-method - if swap call-package else 3drop -1 then +: read ( len addr ihandle -- actual ) + rot swap " read" call-method ;
-: write ( ihandle addr len -- actual ) - rot dup ihandle>phandle " write" rot find-method - if swap call-package else 3drop -1 then +: write ( len addr ihandle -- actual ) + rot swap " write" call-method ;
-: seek ( ihandle pos_hi pos_lo -- status ) - \ package methods uses ( pos_lo pos_hi -- status ) - swap - rot dup ihandle>phandle " seek" rot find-method - if swap call-package else 3drop -1 then +: seek ( pos_lo pos_hi ihandle -- status ) + " seek" call-method ;
diff --git a/modules/client.c b/modules/client.c index cf47692..d5d92a3 100644 --- a/modules/client.c +++ b/modules/client.c @@ -239,7 +239,7 @@ handle_calls( prom_args_t *pb ) pb->nargs, pb->nret); #endif
- for( i=pb->nargs-1; i>=0; i-- ) + for (i = 0; i < pb->nargs - 1; i++) PUSH( pb->args[i] );
push_str( pb->service );
Blue Swirl wrote:
[...] But this patch also does not work [...]
It looks like you're missing the patch Mark Cave-Ayland proposed, with a str2cstr conversion. He noticed that call-method requires a c-string (pointer only), rather than a traditional forth string (pointer, len). The problem is that " seek" is a forth-format string, and the first thing call-method is doing is converting from cstring to forth string - which doesn't work if you are already supplying a forth string.
On Sun, Nov 22, 2009 at 10:39 PM, Tarl Neustaedter Tarl.Neustaedter@sun.com wrote:
Blue Swirl wrote:
[...] But this patch also does not work [...]
It looks like you're missing the patch Mark Cave-Ayland proposed, with a str2cstr conversion. He noticed that call-method requires a c-string (pointer only), rather than a traditional forth string (pointer, len). The problem is that " seek" is a forth-format string, and the first thing call-method is doing is converting from cstring to forth string - which doesn't work if you are already supplying a forth string.
Right, I missed that. But this version (fixing also the loop check noticed by Stefan) does not work either. [sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... switching to new context: entry point 0x4000 stack 0x00000000ffe02a71 Unhandled Exception 0x0000000000000034 PC = 0x00000000ffd0fc78 NPC = 0x00000000ffd0fc7c Stopping execution
However, something interesting happens with MilaX: [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 7392 bytes entry point is 0x4000 Evaluating FCode... Unhandled Exception 0x9000170000000000 PC = 0x00000000ffd0e2c4 NPC = 0x00000000ffd0e2c8 Stopping execution
Maybe the FCode gets something loaded and starts to execute?
diff --git a/forth/lib/string.fs b/forth/lib/string.fs index eb64749..6d7a229 100644 --- a/forth/lib/string.fs +++ b/forth/lib/string.fs @@ -49,6 +49,19 @@ then ;
+\ convert string to cstr +: str2cstr ( addr len -- cstr) + dup if + \ like strdup but with len + 1 for NULL + dup >r + dup 1+ alloc-mem dup >r swap move + \ add null + r> dup r> + 0 swap c! + else + 2drop 0 0 + then +; + : dict-strdup ( str len -- dict-addr len ) dup here swap allot null-align swap 2dup >r >r move r> r> diff --git a/forth/system/ciface.fs b/forth/system/ciface.fs index eefb1b7..8b2ec6b 100644 --- a/forth/system/ciface.fs +++ b/forth/system/ciface.fs @@ -212,21 +212,16 @@ external close-dev ;
-: read ( ihandle addr len -- actual ) - rot dup ihandle>phandle " read" rot find-method - if swap call-package else 3drop -1 then +: read ( len addr ihandle -- actual ) + rot swap " read" str2cstr call-method drop ;
-: write ( ihandle addr len -- actual ) - rot dup ihandle>phandle " write" rot find-method - if swap call-package else 3drop -1 then +: write ( len addr ihandle -- actual ) + rot swap " write" str2cstr call-method drop ;
-: seek ( ihandle pos_hi pos_lo -- status ) - \ package methods uses ( pos_lo pos_hi -- status ) - swap - rot dup ihandle>phandle " seek" rot find-method - if swap call-package else 3drop -1 then +: seek ( pos_lo pos_hi ihandle -- status ) + " seek" str2cstr call-method drop ;
diff --git a/modules/client.c b/modules/client.c index cf47692..dfb092c 100644 --- a/modules/client.c +++ b/modules/client.c @@ -239,7 +239,7 @@ handle_calls( prom_args_t *pb ) pb->nargs, pb->nret); #endif
- for( i=pb->nargs-1; i>=0; i-- ) + for (i = 0; i < pb->nargs; i++) PUSH( pb->args[i] );
push_str( pb->service );
Blue Swirl wrote:
However, something interesting happens with MilaX: [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 7392 bytes entry point is 0x4000 Evaluating FCode... Unhandled Exception 0x9000170000000000 PC = 0x00000000ffd0e2c4 NPC = 0x00000000ffd0e2c8 Stopping execution
Maybe the FCode gets something loaded and starts to execute?
Not quite, but we're close. According to the debugger here, we're actually hitting load-file within the boot process on Milax :) However, we need to finish reworking all of the client interface Forth words to take into account the new reverse ordering. I've made a start on this, but it will take me a bit of time because its in Forth - I'll post a patch as I complete it, although any offers of help are gratefully accepted.
ATB,
Mark.
Blue Swirl schrieb:
diff --git a/modules/client.c b/modules/client.c index cf47692..d5d92a3 100644 --- a/modules/client.c +++ b/modules/client.c @@ -239,7 +239,7 @@ handle_calls( prom_args_t *pb ) pb->nargs, pb->nret); #endif
for( i=pb->nargs-1; i>=0; i-- )
for (i = 0; i < pb->nargs - 1; i++)
Shouldn't this be i = 0; i < pb->nargs; i++
Stefan
On 2009/11/22 at 13:41, Stefan Reinauer stepan@coresystems.de wrote:
Blue Swirl schrieb:
diff --git a/modules/client.c b/modules/client.c index cf47692..d5d92a3 100644 --- a/modules/client.c +++ b/modules/client.c @@ -239,7 +239,7 @@ handle_calls( prom_args_t *pb ) pb->nargs, pb->nret); #endif
for( i=pb->nargs-1; i>=0; i-- )
for (i = 0; i < pb->nargs - 1; i++)Shouldn't this be i = 0; i < pb->nargs; i++
Stefan
So, I assume these changes haven't been made/committed to the SVN repo, yet? I've updated to r633 and am still getting the "seek failed" error message...
-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:
So, I assume these changes haven't been made/committed to the SVN repo, yet? I've updated to r633 and am still getting the "seek failed" error message...
-Nick
Yeah, that's correct as if we don't go through and update all of the CIF Forth words at once then different things will be broken for different people :(
I'll hopefully be able to get a preliminary version finished later this evening.
ATB,
M-D.
Yeah, that's correct as if we don't go through and update all of the CIF Forth words at once then different things will be broken for different people :(
Understand completely - not trying to bug anyone, just trying to verify that I'm seeing the behavior I ought to be seeing with the latest version of the code.
I'll hopefully be able to get a preliminary version finished later this evening.
Awesome - I'll be waiting to test it! Thanks!
-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 11/22/09 1:44 PM, Laurent Vivier wrote:
Sorry for the late reply - I've been away this weekend. Tarl, thanks for the advice - I didn't realise that call-method was actually part of the client services API rather than just an internal word, otherwise I wouldn't have changed it :(
I now have attached another version against SVN trunk that will again correctly read/seek from the qemu cdrom on my SPARC64 image which doesn't alter call-method. Blue Swirl/Laurent - please could you check this on your setups to see if it still breaks things for you?
Same result as previous one: yaboot hangs, but quik exits with: "call-method seek: exception -21"
Odd... does that mean yaboot relies on a non IEEE conformant version of seek and read in the CI?
Stefan
-
Blue Swirl -
Laurent Vivier -
Mark Cave-Ayland -
Nick Couchman -
Stefan Reinauer -
Tarl Neustaedter