From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ny34F-00070I-Pe for mharc-grub-devel@gnu.org; Sat, 03 Apr 2010 09:07:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ny34D-0006yC-CW for grub-devel@gnu.org; Sat, 03 Apr 2010 09:07:13 -0400 Received: from [140.186.70.92] (port=60618 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ny34B-0006w2-Gg for grub-devel@gnu.org; Sat, 03 Apr 2010 09:07:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ny349-0006fz-ER for grub-devel@gnu.org; Sat, 03 Apr 2010 09:07:11 -0400 Received: from mail-bw0-f220.google.com ([209.85.218.220]:64947) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ny349-0006fo-69 for grub-devel@gnu.org; Sat, 03 Apr 2010 09:07:09 -0400 Received: by bwz20 with SMTP id 20so2988354bwz.32 for ; Sat, 03 Apr 2010 06:07:08 -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 :x-enigmail-version:content-type; bh=vmV06V3HbZxu7rZWdngAfecJKHQ/ClIZnj+wfOdR2Ng=; b=SDxj/uHqgzA0j+yFmvnymtw7uL0FTWEMuGcqcPBf6+LwRXgIlTj7EW5juNJGhm3rWc FHIisT1tziTtxRz0WRbg1YxOo0wa5FL2jre6xFHxEx7wIz6+5DrLnk9Esc8GtetSvTPI EObe2kBfog5bIQOANl8s4hMX7tNCS23AkGeig= 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:x-enigmail-version:content-type; b=JpRsAQTPARnTSeX8KKe/2j5M6V+xrVyaRI/RDNPSdnUJtmp12KX1bSXf5GpuUE/dwy DE2Jz+uBzT3VN8TvcWhz4imNXCMFd/sK04B0UBWezbWsUn9pOAs6wjvJq6j9Nron/Spu TvWaGfuxYDQAT6wWsvzka+tEZniWkBI18fZxg= Received: by 10.204.15.1 with SMTP id i1mr828565bka.207.1270300027964; Sat, 03 Apr 2010 06:07:07 -0700 (PDT) Received: from debian.bg45.phnet (57.92.63.81.cust.bluewin.ch [81.63.92.57]) by mx.google.com with ESMTPS id 15sm5176116bwz.4.2010.04.03.06.07.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Apr 2010 06:07:06 -0700 (PDT) Message-ID: <4BB73D72.6080806@gmail.com> Date: Sat, 03 Apr 2010 15:06:58 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig30DF95477BC80208F11E68A5" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Multiboot2 Suggestions X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 13:07:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30DF95477BC80208F11E68A5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brendan Trotter wrote: > Hi, > > 2010/3/28 Vladimir '=CF=86-coder/phcoder' Serbinenko : > =20 >> Also I'm aware that at least some people want more tags. Feel free to >> propose new ones. >> In short all ammendment ideas are welcome. >> =20 > > Here's my list.. :-) > > 1) If GRUB was using a serial port as a console device (e.g. on a > headless system) it'd be nice if the OS could continue using the same > serial port with the same configuration instead of resetting the > serial port, etc. A new tag (for 80x86, "8250/6550 compatible" serial > ports) would include base I/O port, the serial line configuration > (e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600), > =20 The kernel can read data bits, stop bits, parity and divisor from registers itself. I think it's more useful to supply a base frequency since there are a lot of "almost compatible" cards which differ only in base frequency. > the IRQ number (if known/used by the boot loader) and the protocol > being used (ASCII, VT100, etc). I think it's more useful to supply directly usable strings termcap strings rather than an abstract ID > If the boot loader doesn't know which > IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ > number to 0xFFFFFFFF.=20 > =20 > Where the serial port has a different interface > (e.g. if the serial port uses MMIO or if it's not "8250/6550 > compatible") a different tag with different fields are used to > describe it.=20 I think it's more useful to have an I/O selector since yeeloong serial in= terface is basically the same, just attached differently I think we need following fields: 1) I/O space selector (e.g. 0 =3D 32-bit MMIO, 1 =3D 64-bit MMIO, 2 =3D i= 386 I/O) 2) IRQ type selector (0 =3D None, 1 =3D standard platform interrupt) 3) 16-bit padding 4) address in I/O space (up to 64-bits) 5) Base frequency in Hz (32-bit) 6) IRQ (32-bit or even 64-bit since it's not excluded some platforms woul= d use 64-bit IRQ ids, though I'm not aware of such). > "telnet+ethernet" It would need network tag first > 2) The "OS image format" information should be expanded, so that the > OS can tell the boot loader if it supports "8250/6550 compatible" > serial ports (and which protocols), and any other console devices (for > the same reason the "OS image format" already has flags, etc for > video). > =20 Console flags tag is for this > 3) There should be an (optional?) "critical error notification method" > tag that tells the OS which method/s it can/should use to tell the > user it encountered a problem before it was able to setup it's console > output. For example, can/should the OS return to the boot loader, or > use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or > something else. > =20 Processing such a selector may prove as difficult as setting up a console based on console tags. So I doubt its usefullness > 4) The section on "Machine State" is missing lots of information, and > needs to indicate the state of *all* hardware on all architectures > (regardles of firmware type). For example; for 80x86/PC it should say > that PCI devices are left in an undefined state (so that the boot > loader is not responsible for configuring PCI devices if the firmware > didn't for any reason), except for any PCI device that is indirectly > mentioned in the multi-boot information (e.g. if there's a serial port > tag then the OS can assume that serial port is configured, if there's > a video information tag then the OS can assume the video cards is > configured, etc). > =20 Everything not said explicitly is undefined. However I would like to add a sentence that some basic PCI initialisation OS usually expects and which is done by firmware to be present. > 5) The boot loader should always provide a "memory map". If the boot > loader is unable to get a memory map from the firmware then the boot > loader constructs a fake memory map from any/all information it can > find, including known areas that aren't RAM. For e.g. on "80x86 BIOS" > if "int 0x15, eax=3D0xE820" isn't supported, then other BIOS functions > are used to find usable RAM and the boot loader creates an entry that > marks the area from 0x000A0000 to 0x000FFFFF as "system" or "unknown". > =20 Where bootloader gets memory map from isn't part of specification and I see no reason to change that > The "mem_upper/mem_lower" tag should removed from the specification. > > =20 If more people speak against this tag then yes. > 7) The memory map needs more "area types". Any RAM that is reported by > firmware as faulty should use "area type 5" so that the OS can know > that some RAM is faulty, and (for e.g.) could tell a system > administrator about it. Also, "area type 0xFFFFFFFF" should be used > for "unknown", as this allows the OS to determine the difference > between "boot loader doesn't know what the area is" and "boot loader > does know what the area is but the area type is defined in a newer > version of the multi-boot specification". > =20 What's the difference between type 2 and "type 5" > 8) Any RAM that is not immediately usable by the OS should not be > reported as "usable RAM" in the memory map. An example of this is the > "ACPI reclaimable" area (which is RAM that isn't usable until the OS > has finished using the ACPI tables). RAM used to store the multi-boot > information, RAM used to store the "kernel" and RAM used to store any > modules should be treated in the same way. I suggest using "area type > 0xFFFFFFFE =3D RAM used for multi-boot information" and "area type > 0xFFFFFFFD =3D RAM used for kernel/modules". This makes it much easier > to write a kernel's early initialisation code, because it can use RAM > without worrying about trashing data that is needed by the kernel/OS > later. > =20 kernel should know itself what it asked bootloader to do. MBI now is a single chunk. Further than that there are only elf section tag and module tags which refer to external memory. I think it should be easily trackable now. > 9) The "boot device" tag needs to be revised. If the firmware was not > "PC BIOS" it doesn't make any sense; and even if the firmware was "PC > BIOS" the OS is unlikely to care (and there's cases where the BIOS > device number still doesn't make sense if the OS does care - e.g. "El > Torito" boot CD emulating a floppy disk or hard disk). The "boot > device" tag should be removed, and (potentially) replaced by one or > more new tags that describes how the boot device is accessed - e.g. > one tag for "PCI_bus/device/function then controller_device_number and > partition", another tag for "PCI_bus/device/function then > protocol/IP_address/port", etc. > > =20 I agree that current tag is quite useless but I'm not sure how to do a new one cleanly > 10) The word used for "kernel" should be changed. There is currently > no reason why the boot loader couldn't be used to load an extra (OS > specific) stage which in turn starts (one of) the OSs real kernel/s; > and no reason why the real kernel/s couldn't be loaded by the boot > loader as a module. Unfortunately, because the specification uses the > word "kernel" people who are new to OS development and/or multi-boot > make the mistake of assuming that "kernel" must be the OS's kernel. I > propose the world "kernel" should be changed to "initial module" (or > something else) to avoid confusion. > =20 I added a remark to Terminology section but I think that "Initial module" will be more confusing. > 11) The multi-boot specification should say which tags are required > (e.g. "boot loader name", "memory map"); which tags must be present > under certain circumstances (e.g. "serial port" must be present *if* > the boot loader used a serial port as a console device); and which > tags are optional (and may be included or omitted by the boot loader). > For the current draft this is unclear. > > =20 Only the ones OS image explicitly declared as required. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig30DF95477BC80208F11E68A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAku3PXcACgkQNak7dOguQgnu5gD8DQYKim7h97LzxCnq810sd+fu VD7ksCW+8InEA2/jtGoA/2ofyxUCW8Ceq82g4FFgCHmgfuSpBcZ7WEuf+8YLd5v9 =EW2f -----END PGP SIGNATURE----- --------------enig30DF95477BC80208F11E68A5--