[OpenBIOS] memory corruption with "read" $call-method (sparc32)

[Mark Cave-Ayland]

Artyom Tarasenko wrote:

>> I'd suggest a good starting point for you would be to first switch over to
>> the libopenbios/ofmem_common.c API in arch/sparc32/lib.c using
>> arch/sparc64/lib.c as a reference, and then similarly update
>> arch/sparc32/romvec.c where appropriate.
> 
> If they are so similar, why isn't the code located somewhere in sparc-common?

Probably for two reasons: firstly the ofmem_common.c memory API is quite 
new, and secondly it's only a few lines and so it would probably be 
overkill for the job in hand.

>> I also seem to recall that Blue had
>> a compile time #define in Qemu that would dump the page table contents and
>> so you can use this to verify that the OpenBIOS code is correct. With these
>> two things in place, then you have all the debugging information you need :D
> 
> Within the next months I only have time to test, not to develop/refactor.
> 
> A quick analysis has shown that obp_dumb_memalloc is probably too dumb:
> it maps f00aXXXX to 0104xxxx (which seems to be already mapped to 0104xxxx).
> 
> totmap[0].num_bytes is always initialized with value 2088960. Is it the size
> of already mappED memory? Then why does obp_dumb_memalloc decrease
> this amount? If it is mappABLE, then the value 2088960 seems to be quite small.

I don't think it would be too hard a task with the necessary romvec 
interface documentation (anyone know where you can get this?). All you 
have to do is change the existing romvec functions for simple memory 
alloc/free/map wrapper functions that call the existing routines in 
ofmem_common.c instead which are already known to work with PPC/SPARC64. 
Then the existing code (which from your analysis seems to be broken) can 
just be ripped out.


HTH,

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