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

[Blue Swirl]

On 4/9/10, Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> wrote:
> 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

There is some information in the header file, arch/sparc32/openprom.h
and how Linux uses it (arch/sparc/prom/*).

> 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.

Should be a good idea. There are some hacks now for Solaris/SunOS but
I think this way is cleaner.