From: phcoder <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] badram filtering
Date: Wed, 11 Mar 2009 21:37:22 +0100 [thread overview]
Message-ID: <49B82102.5010109@gmail.com> (raw)
In-Reply-To: <49B6A789.3080600@gmail.com>
Hello. I'm now writing the code to make multiboot and bsd work on EFI
based on my grub_machine_memory_iterate for EFI. MY code will be the
same for all i386 branches. It's quite complete except that I had no
time yet to test it. I'l submit once it works
I was thinking and found another utility for badram: BIOS hooks. They
are actually allocating take some memory and then removing it from mmap.
If bios mmap hook and kernels get their mmap from the same source we can
ensure that bios hooks won't be overwritten by the kernel independently
how it acquired memory map. So I think badram patch should be extended
to allow arbitrary additions to mmap.
P.S. sorry if this e-mail isn't clear enough I've just had a long day of
studies
phcoder wrote:
>> 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
prev parent reply other threads:[~2009-03-11 20:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-27 19:42 [PATCH] badram filtering Robert Millan
2009-03-10 12:56 ` phcoder
2009-03-10 17:46 ` phcoder
2009-03-11 20:37 ` phcoder [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49B82102.5010109@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.