Re: [PATCH] badram filtering

[phcoder <phcoder@gmail.com>]

I've looked in depth in memory map and have seen that (1) is already 
done so except for EFI systems. And except that memory types are defined 
on per-machine basis. IMO generic memory types should be shared at the 
output of grub_machine_memory_iterate but it's not critical. I will code 
a similar function for EFI and adapt multiboot loader for EFI systems
phcoder wrote:
> Very interesting. I have following suggestions:
> 1) define platform independent way to enumerate memory map. This 
> function wouldn't mark types with GRUB_MACHINE_* but with one of the 
> following types:
> GRUB_MMAP_HOLE - means that at this position there is no RAM at all. 
> Should this be iterated at all?
> GRUB_MMAP_IO - usable only by I/O drivers
> GRUB_MMAP_FREE - usable by ACPI and firmware-unaware OS. But may be 
> unusable by grub itself. memory allocator should be used for requesting 
> memory in grub
> GRUB_MMAP_ACPI - usable by ACPI-aware OS after loading tables
> GRUB_MMAP_PLATFORM_FIRST...GRUB_MMAP_PLATFORM_LAST - platform specific 
> types which can't be used except by firmware-aware code and OS
> 2) when badram variable is set corresponding memory chunks should be 
> removed from memory manager
> 3) add a method to specify badram in init.c so that grub2 itself has no 
> risk of using any of this memory. I propose to embed initial environment 
> in core.img. Then prefix and root can be changed to use this mechanism. 
> It would also be able to override this initial environment through 
> multiboot command line when grub2 is loaded by multiboot loader
> 
> 
> Robert Millan wrote:
>> Hi,
>>
>> This patch implements badram filtering in GRUB.  It's the same idea as in
>> http://rick.vanrein.org/linux/badram/ but applied to GRUB.
>>
>> The badram module sits between loaders (or other users like lsmmap) and
>> filters the mmap entries, but only when user previously set the "badram"
>> variable (whose syntax is the same as the one in badram patch for Linux).
>>
>> NOTE this won't affect loadees that get the memory map from BIOS instead
>> of from GRUB.  This means it currently works for Multiboot and for the
>> new/experimental Linux loader.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko