[OpenBIOS] [commit] r739 - trunk/openbios-devel/libopenbios

[Igor Kovalenko]

On Sat, Apr 10, 2010 at 3:08 PM, repository service <svn at openbios.org> wrote:
> Author: mcayland
> Date: Sat Apr 10 13:08:57 2010
> New Revision: 739
> URL: http://tracker.coreboot.org/trac/openbios/changeset/739
>
> Log:
> Don't try and update the MMU mappings when claiming physical memory. This is probably related to r737 and seems to solve an
> issue whereby Forth starts doing strange things just after attemping a claim on physical memory resource.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>
>
> Modified:
>   trunk/openbios-devel/libopenbios/ofmem_common.c
>
> Modified: trunk/openbios-devel/libopenbios/ofmem_common.c
> ==============================================================================
> --- trunk/openbios-devel/libopenbios/ofmem_common.c     Thu Apr  8 23:31:44 2010        (r738)
> +++ trunk/openbios-devel/libopenbios/ofmem_common.c     Sat Apr 10 13:08:57 2010        (r739)
> @@ -401,8 +401,6 @@
>        }
>        add_entry( phys, size, &ofmem->phys_range );
>
> -       ofmem_update_translations();
> -
>        return phys;
>  }
>

This ofmem_update_translations call is supposed to keep available
physical memory ranges up-to-date. There are no other places where we
do update available phys ranges. Virtual ranges and MMU translations
we update at the same time; since virtual allocations and MMU
translations are not affected at this call site the resulting lists of
virtual ranges and MMU translations are not changed.

The only thing which may change here is actual placement of
"translations" property value, so if you keep pointer to previous
location it may be stale after update call.

What is the issue you are solving here?

-- 
Kind regards,
Igor V. Kovalenko