Hi all,
This patch is an attempt at reworking the CIF so that it can be called correctly from both Fcode (Forth) and C. Currently the C arguments are pushed into the stack in reverse order, rather than forward order which is required by Forth words calling the CIF.
In order to fix this, we correct the order in which C arguments are placed on the Forth stack by pushing the parameters in forward order. However, this has the side effect of reversing the order in which the parameters to the CIF Forth words are expected and so these must also be altered to take this into account.
This patch works as expected from Forth Fcode, but I would like to put it out for testing before I commit to the repository. Blue Swirl/Laurent - please can you test on your setups again?
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
ATB,
Mark.
On 2009/11/23 at 15:36, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
wrote:
Hi all,
This patch is an attempt at reworking the CIF so that it can be called correctly from both Fcode (Forth) and C. Currently the C arguments are pushed into the stack in reverse order, rather than forward order which is required by Forth words calling the CIF.
In order to fix this, we correct the order in which C arguments are placed on the Forth stack by pushing the parameters in forward order. However, this has the side effect of reversing the order in which the parameters to the CIF Forth words are expected and so these must also be altered to take this into account.
This patch works as expected from Forth Fcode, but I would like to put it out for testing before I commit to the repository. Blue Swirl/Laurent
- please can you test on your setups again?
Mark, Thanks for the patch - for me this takes care of the seek failed error when booting off the Solaris Nevada DVD, but I'm back to getting this:
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 7120 bytes entry point is 0x4000 Evaluating FCode... Unhandled Exception 0x0000000008000000 PC = 0x00000000ffd10e3c NPC = 0x00000000ffd10e40 Stopping execution
the exception being at the following location: 0xffd10e3c 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 ); }
If you're interested in the full output of "boot cdrom" with "true to ?fcode-verbose", I've put it here: http://openbios.pastebin.com/m1c58f4e5
Maybe there's somewhere else where the stack is in the wrong order - I don't know that I've seen cfetch mentioned before??
-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:
Mark, Thanks for the patch - for me this takes care of the seek failed error when booting off the Solaris Nevada DVD, but I'm back to getting this:
No worries. Looks like it still needs some work on the C interface end though.
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 7120 bytes entry point is 0x4000 Evaluating FCode... Unhandled Exception 0x0000000008000000 PC = 0x00000000ffd10e3c NPC = 0x00000000ffd10e40 Stopping execution
the exception being at the following location: 0xffd10e3c 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 ); }
If you're interested in the full output of "boot cdrom" with "true to ?fcode-verbose", I've put it here: http://openbios.pastebin.com/m1c58f4e5
Maybe there's somewhere else where the stack is in the wrong order - I don't know that I've seen cfetch mentioned before??
-Nick
On my Milax test ISO here, it's actually crashing calling one of the Forth methods to do with getting the platform/architecture name so you probably don't need to go down to C level (yet). However, given that there is a still an issue with the CIF C interface, it would make sense to fix that first before spending more time on this just in case the two problems are related.
ATB,
Mark.
On Tue, Nov 24, 2009 at 12:36 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi all,
This patch is an attempt at reworking the CIF so that it can be called correctly from both Fcode (Forth) and C. Currently the C arguments are pushed into the stack in reverse order, rather than forward order which is required by Forth words calling the CIF.
In order to fix this, we correct the order in which C arguments are placed on the Forth stack by pushing the parameters in forward order. However, this has the side effect of reversing the order in which the parameters to the CIF Forth words are expected and so these must also be altered to take this into account.
This patch works as expected from Forth Fcode, but I would like to put it out for testing before I commit to the repository. Blue Swirl/Laurent - please can you test on your setups again?
It still breaks both Sparc64 and PPC.
Another interesting effect (Aurora 2.0): [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 0x656e746572000000 PC = 0x00000000ffd0fc78 NPC = 0x00000000ffd0fc7c Stopping execution
The exception value 0x656e746572000000 is bogus, it should be less than 0x200 IIRC. But the exception number, when interpreted as a string, yields 'enter'. Strange.
Blue Swirl wrote:
It still breaks both Sparc64 and PPC.
Another interesting effect (Aurora 2.0): [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 0x656e746572000000 PC = 0x00000000ffd0fc78 NPC = 0x00000000ffd0fc7c Stopping execution
The exception value 0x656e746572000000 is bogus, it should be less than 0x200 IIRC. But the exception number, when interpreted as a string, yields 'enter'. Strange.
Hmmm that'll still be broken then :( I've since spent some time yesterday evening setting up a PPC Qemu/OpenBIOS build environment so I can emulate Laurent's yaboot environment. Using this I'll make use of the CIF debugging in order to figure out what is still going wrong...
ATB,
Mark.
On 2009/11/23 at 15:36, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
wrote:
Hi all,
This patch is an attempt at reworking the CIF so that it can be called correctly from both Fcode (Forth) and C. Currently the C arguments are pushed into the stack in reverse order, rather than forward order which is required by Forth words calling the CIF.
In order to fix this, we correct the order in which C arguments are placed on the Forth stack by pushing the parameters in forward order. However, this has the side effect of reversing the order in which the parameters to the CIF Forth words are expected and so these must also be altered to take this into account.
This patch works as expected from Forth Fcode, but I would like to put it out for testing before I commit to the repository. Blue Swirl/Laurent
- please can you test on your setups again?
And, in case it's helpful, here's the output from qemu with the "-d int" flag for the the "Unhandled Exception 0x9000280200000000 PC = 0x00000000ffd0f05c NPC = 0x00000000ffd0f060" error:
Search PC... 4687: Data Access MMU Miss (v=0068) pc=00000000ffd0f05c npc=00000000ffd0f060 SP=00000000fff10cd1 pc: 00000000ffd0f05c npc: 00000000ffd0f060 General Registers: %g0: 0000000000000000 %g1: 9000280200000000 %g2: 00000000ffdac010 %g3: 0000000000000000 %g4: fffffffffffffff8 %g5: 0000000000000030 %g6: 0000000000000000 %g7: 0000000000000000 Current Register Window: %o0: 0000000000000034 %o1: 00000000ffee4d58 %o2: 00000000ffee3000 %o3: 00000000000000e8 %o4: 00000000ffe33878 %o5: 00000000ffe32d68 %o6: 00000000fff10cd1 %o7: 00000000ffd0f068 %l0: 00000000ffee3000 %l1: 0000000000000000 %l2: 00000000ffee3000 %l3: 0000000000000000 %l4: 000000000000001a %l5: 0000000000000000 %l6: 0000000000000000 %l7: 0000000000000000 %i0: 00000000ffe1b720 %i1: 0000000000000200 %i2: 00000000ffe00000 %i3: 0000000000000000 %i4: ffffffffffffffff %i5: 0000000000000018 %i6: 00000000fff10d91 %i7: 00000000ffd12708
Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 0x00000016 ccr: 0x44 asi: 0x00 tl: 0 fprs: 0 cansave: 6 canrestore: 0 otherwin: 0 wstate 0 cleanwin 7 cwp 4 fsr: 0x00000000
-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.
-
Blue Swirl -
Mark Cave-Ayland -
Nick Couchman