From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lq8jY-0006sk-LW for mharc-grub-devel@gnu.org; Sat, 04 Apr 2009 12:28:40 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lq8jW-0006sV-GD for grub-devel@gnu.org; Sat, 04 Apr 2009 12:28:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lq8jS-0006qE-Mz for grub-devel@gnu.org; Sat, 04 Apr 2009 12:28:38 -0400 Received: from [199.232.76.173] (port=60634 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lq8jS-0006pv-GN for grub-devel@gnu.org; Sat, 04 Apr 2009 12:28:34 -0400 Received: from mail-fx0-f166.google.com ([209.85.220.166]:47780) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lq8jR-0005fS-Tg for grub-devel@gnu.org; Sat, 04 Apr 2009 12:28:34 -0400 Received: by fxm10 with SMTP id 10so1415002fxm.42 for ; Sat, 04 Apr 2009 09:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=nrH8tXsTC9O5LxCf6XwIGo5xMAVWpM6FxVPtLbUfBMs=; b=QVUxzqo1DGfd8bm1cYT/ROLJOhogkHhYm/ZpULaONAfv4lw7WLDzmPpPZ3mpKl5YqU bKif01oMKm/LbAQ5JGM7/IA9O52N5pMjz9Lfit7a/Yh9X1ooE4dHoEHxZOThRWXAm2g4 fykRNa5nJuo7sDadw8AxpuCrGSubk6dszMBiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=VtdNZ7nn8zeCqjCEh7vdWpI0QyW7NRSunwovvxGZdZt3KQUhB/NpLpumnGNfU4yWvE FmovD79hBPISLsdT0hg7TDXdmjGhRLPq18kMIPFzYwkdCIoqNmWqkW/LbsQK2CObxlAb YRUYkYfl/7pBgQzEj6iuDxfCn7pLJZNhFQMo0= Received: by 10.86.80.17 with SMTP id d17mr1805811fgb.49.1238862512050; Sat, 04 Apr 2009 09:28:32 -0700 (PDT) Received: from ?192.168.1.2? (5-181.3-85.cust.bluewin.ch [85.3.181.5]) by mx.google.com with ESMTPS id e20sm10202735fga.14.2009.04.04.09.28.31 (version=SSLv3 cipher=RC4-MD5); Sat, 04 Apr 2009 09:28:31 -0700 (PDT) Message-ID: <49D78AB0.3040803@gmail.com> Date: Sat, 04 Apr 2009 18:28:32 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49C780C3.4010403@gmail.com> <20090328131306.GB8493@thorin> <49CEA5CC.1000301@gmail.com> In-Reply-To: <49CEA5CC.1000301@gmail.com> Content-Type: multipart/mixed; boundary="------------010602070400020006040308" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: multiboot on EFI X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:28:38 -0000 This is a multi-part message in MIME format. --------------010602070400020006040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For those interested in testing: here is a rediff and some updates. Soon I'll split it into components phcoder wrote: > Robert Millan wrote: >> Would it be hard to split the patch and make it more granular? I see it >> implements base mmap / lsmmap support on efi, then ports the *BSD loaders >> and the Multiboot loader too, and the uppermem facility. > The only reason why it's not splitted is that it's totally "preview". > When it'll be more ready I'll split it >> If everybody's fine with it, I'd like to suggest adding stuff to >> pkglib_MODULES >> in the same place as its corresponding variables. I've done this >> already a few >> times, and I think it makes the build system a bit more maintainable. >> What do >> you all think about this? > > I also agree with this but I temporarily kept this in > architecture-specific file because of some minor problems with > multiboot2. I'll fix this too > >> >>> diff --git a/include/grub/i386/pc/memory.h >>> b/include/grub/i386/pc/memory.h >>> index 08e92a9..e69ff77 100644 >>> --- a/include/grub/i386/pc/memory.h >>> +++ b/include/grub/i386/pc/memory.h >>> @@ -92,6 +92,8 @@ struct grub_machine_mmap_entry >>> grub_uint64_t len; >>> #define GRUB_MACHINE_MEMORY_AVAILABLE 1 >>> #define GRUB_MACHINE_MEMORY_RESERVED 2 >>> +#define GRUB_MACHINE_MEMORY_ACPI 3 >>> +#define GRUB_MACHINE_MEMORY_NVS 4 >>> grub_uint32_t type; >>> } __attribute__((packed)); >> >> Do we need specific knowledge of these two on i386-pc ? >> > This one is because some loaders just copy e820 map types and I don't > want to modify what OS gets on i386-pc >>> /* The minimum and maximum heap size for GRUB itself. */ >>> #define MIN_HEAP_SIZE 0x100000 >>> -#define MAX_HEAP_SIZE (16 * 0x100000) >>> +#define MAX_HEAP_SIZE (1600 * 0x100000) >> >> Is 1600 MB what we want, or to remove the limit? >> > I would suggest to remove the limit altogether >>> + /* Bubble-sort the memory map */ >>> + while (done) >>> + { >>> + done = 0; >>> + for (i = 0; i < count - 1; i++) >>> + if (regions[i].start > regions[i + 1].start) >>> + { >>> + done = 1; >>> + t = regions[i]; >>> + regions[i] = regions[i + 1]; >>> + regions[i + 1] = t; >>> + } >>> + } >> >> Do we need the memory map to be sorted? AFAIK loadees can cope with >> unsorted >> maps fine; is there an exception? >> > I prefer to sort. Even as just a precaution. Actually even sorted EFI > map may break a lot of OS because it usually has more entries (the > runtime code isn't guaranteed to be contiguous and if it isn't it > results in mmap having a lot of entries) and sometimes the first N > kilobytes are defined as unusable (it's the case with qemu-tianocore) > which under current definition means that low_memory=0 >>> +#ifdef GRUB_MACHINE_PCBIOS >>> + grub_stop_floppy (); >>> +#endif >> >> grub_stop_floppy() doesn't do any BIOS-specific stuff. Wouldn't __i386__ >> be more appropiate? >> > I've already moved it to machine_fini just because my computer died I > couldn't send the new patch > -- Regards Vladimir 'phcoder' Serbinenko --------------010602070400020006040308 Content-Type: text/x-diff; name="efiboot.all.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="efiboot.all.diff" --------------010602070400020006040308--