On Sat, Apr 10, 2010 at 3:08 PM, repository service svn@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@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?