[OpenBIOS] Latest SPARC64 & Milax update

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Sun Jan 3 15:57:44 CET 2010


Igor Kovalenko wrote:

>> Looking at SILO and Linux usage, It looks like OF entry point needs to
>> be in %o4 and %o0 must be zero.
>>
>> http://fxr.watson.org/fxr/source/arch/sparc64/kernel/head.S?v=linux-2.4.22
>> http://git.kernel.org/?p=linux/kernel/git/bcollins/silo.git;a=blob;f=first/ultra.S;h=b285e1d66009e3490c47e4369d541a65529e27b5;hb=a55764ceef83086d00b5f7b8b3027b517fc4ca23
>> http://fxr.watson.org/fxr/source/arch/sparc/kernel/head.S?v=linux-2.4.22
>>
>> But start_client_image() already handles this, except for zero %o0.
> 
> We may want to rework implementation so go() uses start_client_image()
> with saved context, and boot word uses client state reset, load, init-program
> and go words. load would fetch image, init-program would prepare saved
> context. This would match a hint in of1275 document about difference
> between boot and load words.

Yeah I think you're right here - by using an intermediate client state 
then it would be possible to share the majority of code between the two 
implementations.

Another interesting thing I noticed from this document was that the 
alarm word is implemented using a timer interrupt. Hence this would be a 
good test of general timer functionality (as well as given a twirly 
baton during the first loading stage!). Does anyone know if the qemu 
SPARC64 model currently supports a timer interrupt?

>>> Igor has suggested a C version in his previous email, although again I don't
>>> really know enough about SPARC to know if this is valid or not.
>> Looks OK, though I don't again see any difference.

> You need to skip return for failed ofmem_claim() in elf-loader to see
> any difference.

I wonder if we should just ignore the return from ofmem_claim() or maybe 
emit a warning? I guess the clash occurs because of the addresses being 
hard-coded in various parts of the Fcode loader, and so this won't 
change with real hardware.

Or then again maybe resetting the client state (as we believe should now 
happen in init-program) removes some of the old MMU mappings before 
executing the boot-archive ramdisk and so they wouldn't exist anymore?


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs



More information about the OpenBIOS mailing list