[OpenBIOS] [PATCH] sparc64: fix registers dealing with client

[Igor Kovalenko]

On Sat, Jul 11, 2009 at 4:16 PM, Blue Swirl<blauwirbel at gmail.com> wrote:
> On 7/11/09, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
>> On Fri, Jul 10, 2009 at 11:20 PM, Blue Swirl<blauwirbel at gmail.com> wrote:
>>
>> > On 7/6/09, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
>>  >> Hi!
>>  >>
>>  >>  This patch improves previous proposal and adds:
>>  >>
>>  >>  - save/restore global registers across client interface calls.
>>  >>  Since OS kernel generally has it's own idea of what
>>  >>  the ABI is we have to follow this requirement.
>>  >>
>>  >>  - adjust stack to allow using unoptimized openbios
>>  >>  build with linux kernel. Linux provides only 128 bytes
>>  >>  on stack which is not enough to save arguments by
>>  >>  code generated with gcc -O0
>>  >>
>>  >>  - fix switch_to so it actually could be used to switch
>>  >>  to client image. context pointer must be volatile to
>>  >>  prevent gcc optimizing out stores to it.
>>  >>
>>  >>  Signed-off-by: igor.v.kovalenko at gmail.com
>>  >
>>  > Thanks, but with the patch applied, SILO in most of my test images no
>>  > longer boots. For example, HelenOS 0.2.0.5:
>>  > 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 Jul 10 2009 19:12
>>  >  Type 'help' for detailed information
>>  >
>>  > [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 0x00000000ffe51999
>>  > SIUnhandled Exception 0x0000000000000068
>>  > PC = 0x00000000ffd0ff14 NPC = 0x00000000ffd0ff18
>>  > Stopping execution
>>  >
>>
>>
>> I found two issues:
>>
>>  - block reading routines are using significant amount of stack data so
>>  4k is not enough (8k seems OK)
>>  - must flush windows on caller's stack before switching stack pointer,
>>  this causes hard-to-find memory corruption
>>
>>  Here is updated version, now silo seems to be working here.
>
> Works for me too. Thanks, I'll apply this.

Thanks!
Please add arch/sparc64/call-client.S to repository, I suppose that file
missed svn add operation.

-- 
Kind regards,
Igor V. Kovalenko