Re: [OpenBIOS] OpenBios Sparc64

[Tarl Neustaedter]

On 2011-Aug-5 14:23 , Ghitulete Razvan wrote:
> This is a wild
> guess, but is the openboot CIF influenced in any way by the processor
> state register?

Shouldn't be. It's just forth code manipulating the device tree. Doesn't 
do anything exotic with the processor. On the other hand, it does need 
to have the client interface initialized, which happens automatically 
during startup. If you're somehow bypassing that, you'd expect to have 
trouble.
>   Also as a last option, do you know how i could get hold of a
>
> binary for 3.13.1 so i can disassemble it and inspect the code easier
> as i find it pretty difficult using the dis command over and over.

heh. I certainly can't send you one, Oracle is much more retentive on 
exporting code than Sun ever was.

However, if you have hardware, you've got the binary. My recollection is 
that older versions of Solaris (pre Solaris-10) just leave the prom 
mapped in kernel space, starting at 0xf020.0000 . If not, you'll have to 
figure out how to use /dev/physmem to map in the prom so you can dump it 
out.

Another possibility is the version of Openboot that was opensourced by 
Sun several years ago - 4.21, I think. See:

http://openboot.sourceforge.net/

OpenBios Sparc64

[Ghitulete Razvan]

Actually it was a 4.13 the OpenBoot, sorry for the confusion. Anyway
after carefully analysing memory dumps, and so on I found the "bug".
It seems it's not a pretty good idea to try and call the CIF very fast
from C, because of the SILO which relocates the program at 4000000,
and you're assembly code generated by gcc have an offset which doesn't
take into acount the SILO relocation, if one uses global variables(as
I did). So after I wrote the whole code into assembly it seems to run
without a problem. Though I think this is a usecase for the CIF that
should be mentioned, that if it doesn't find a valid string command it
does.... because as i've noticed at the address that I passed as a
parameter 4092 instead of 40004092 it was zero-ed

On Fri, Aug 5, 2011 at 9:36 PM, Tarl Neustaedter  wrote:
> On 2011-Aug-5 14:23 , Ghitulete Razvan wrote:
> > This is a wild
> > guess, but is the openboot CIF influenced in any way by the processor
> > state register?
>
> Shouldn't be. It's just forth code manipulating the device tree. Doesn't do
> anything exotic with the processor. On the other hand, it does need to have
> the client interface initialized, which happens automatically during
> startup. If you're somehow bypassing that, you'd expect to have trouble.
> > Also as a last option, do you know how i could get hold of a
> > binary for 3.13.1 so i can disassemble it and inspect the code easier
> > as i find it pretty difficult using the dis command over and over.
>
> heh. I certainly can't send you one, Oracle is much more retentive on
> exporting code than Sun ever was.
>
> However, if you have hardware, you've got the binary. My recollection is
> that older versions of Solaris (pre Solaris-10) just leave the prom mapped
> in kernel space, starting at 0xf020.0000 . If not, you'll have to figure out
> how to use /dev/physmem to map in the prom so you can dump it out.
>
> Another possibility is the version of Openboot that was opensourced by Sun
> several years ago - 4.21, I think. See:
>
> http://openboot.sourceforge.net/