From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1O0I4e-0007GE-ND for mharc-grub-devel@gnu.org; Fri, 09 Apr 2010 13:32:56 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0I4Z-0007BK-GZ for grub-devel@gnu.org; Fri, 09 Apr 2010 13:32:51 -0400 Received: from [140.186.70.92] (port=39947 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0I4T-0006pv-6W for grub-devel@gnu.org; Fri, 09 Apr 2010 13:32:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0Hut-0001Wo-MI for grub-devel@gnu.org; Fri, 09 Apr 2010 13:22:54 -0400 Received: from mail-fx0-f212.google.com ([209.85.220.212]:43519) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Hut-0001Wj-Dm for grub-devel@gnu.org; Fri, 09 Apr 2010 13:22:51 -0400 Received: by fxm4 with SMTP id 4so3119729fxm.26 for ; Fri, 09 Apr 2010 10:22:50 -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=0t4w9tJUIpWlUHlk0I2VH8HYkkUjjCpsMPSGK0A2QN8=; b=QOt1yIWyNxRSjhr0DGPHfniliJK8HkmmHj2jQhDGWOWung7fnQc/aASvp7JmserQf2 JbUFVwoBIhsrpVYtovip/6ugChfjoUK/K3tji57F3Mg4X41OB60bBgrAwtj/yTL+DHW0 NAkkhBFX9EwTToFH1MpcemYjGrKKlLfoK8PF4= 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=uwYlK22GZL5pesP1Gztipmk9e1F49X5CmBf9Nl86Rxip8uLOSt7tJlT/yRkSzN8aXK wNR+JVKsA5ROqdIpsG2OMaOrA7xMK1gil3zoRvwjmfcrs5D1x++/o5ZeFY0IwXyig+Ed kyBaAE19ZXswO4nnneQKQi8C6PfD0u1LQjHXg= Received: by 10.223.29.135 with SMTP id q7mr367050fac.30.1270833770331; Fri, 09 Apr 2010 10:22:50 -0700 (PDT) Received: from debian.bg45.phnet (125-149.203-62.cust.bluewin.ch [62.203.149.125]) by mx.google.com with ESMTPS id 22sm3322107fkr.29.2010.04.09.10.22.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 10:22:49 -0700 (PDT) Message-ID: <4BBF6261.6070109@gmail.com> Date: Fri, 09 Apr 2010 19:22:41 +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: <4BB73D72.6080806@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD3B46096622F21E2F98BA786" 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: Fri, 09 Apr 2010 17:32:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD3B46096622F21E2F98BA786 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brendan Trotter wrote: > Hi, > =20 >>> the IRQ number (if known/used by the boot loader) and the protocol >>> being used (ASCII, VT100, etc). >>> =20 >> I think it's more useful to supply directly usable strings termcap >> strings rather than an abstract ID >> =20 > > Here's an example termcap string: > > ca|concept100|c100|concept|c104|concept100-4p|HDS Concept-100:\ > :al=3D3*\E^R:am:bl=3D^G:cd=3D16*\E^C:ce=3D16\E^U:cl=3D2*^L= :cm=3D\Ea%+ %+ :\ > :co#80:.cr=3D9^M:db:dc=3D16\E^A:dl=3D3*\E^B:do=3D^J:ei=3D\= E\200:eo:im=3D\E^P:in:\ > :ip=3D16*:is=3D\EU\Ef\E7\E5\E8\El\ENH\EK\E\200\Eo&\200\Eo\= 47\E:k1=3D\E5:\ > :k2=3D\E6:k3=3D\E7:kb=3D^h:kd=3D\E<:ke=3D\Ex:kh=3D\E?:kl=3D= \E>:kr=3D\E=3D:ks=3D\EX:\ > :ku=3D\E;:le=3D^H:li#24:mb=3D\EC:me=3D\EN\200:mh=3D\EE:mi:= mk=3D\EH:mp=3D\EI:\ > :mr=3D\ED:nd=3D\E=3D:pb#9600:rp=3D0.2*\Er%.%+ :se=3D\Ed\Ee= :sf=3D^J:so=3D\EE\ED:\ > :.ta=3D8\t:te=3D\Ev \200\200\200\200\200\200\Ep\r\n:\ > :ti=3D\EU\Ev 8p\Ep\r:ue=3D\Eg:ul:up=3D\E;:us=3D\EG:\ > :vb=3D\Ek\200\200\200\200\200\200\200\200\200\200\200\200\= 200\200\EK:\ > :ve=3D\Ew:vs=3D\EW:vt#8:xn:\ > :bs:cr=3D^M:dC#9:dT#8:nl=3D^J:ta=3D^I:pt: > > Making sense out of arbitrary termcap strings isn't easy - it would > add a large amount of mess to early OS initialisation code (which > typically doesn't even have C library functions to rely on). A single > integer saying "which protocol" is much easier to parse and use, > especially as only a few standard protocols (e.g. VT100) would need to > be supported. > =20 It doesn't need to be termcap string in its normal form. It can be sth li= ke: uint16_t offset_to_gotoxy_string; uint16_t offset_to_cls_string; =2E.. uint16_t offset_to_end_of_last_string; This way if OS wants to e.g. clear screen it should have no trouble retrieving and replaying string. >>> 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. >>> >>> 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= interface is basically the same, just attached differently >> =20 > > An I/O selector (for "8250/6550 compatible") makes sense, and > different tags for "not 8250/6550 compatible" serial ports. > > =20 >> 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= i386 I/O) >> =20 > > For 32-bit MMIO you could use 64-bit MMIO with the high bits of the > "address in I/O space" set to zero. > > =20 Do all platforms zero-expand? Or do some sign-extend? if it depends only on ISA there is no problem in just saying if it's zero or sign-extended depending on platform. Perhaps like 0 =3D you can access even if you're not 64-bit aware 1 =3D you need to be 64-bit aware Another field I forgot which will go instead of 16-bit padding is flags. First flag will be CONSOLE_ACTIVE which will indicate that console was used by bootloader. This way bootloader can inform OS of additional serial ports which it didn't use. > Yes - the console flags tag needs to be expanded... > > =20 It was meant to >>> 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 consol= e >>> 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, o= r >>> 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 >> =20 > > I currently use "PC speaker" as my "critical error notification > method" - it's about 15 instructions that use I/O ports only and > doesn't require memory allocations or anything else. I doubt setting > keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on > anything more than I/O ports. > > In comparison, my video setup code is around 64 KiB of code that > starts with trying to get EDID information from the monitor, filtering > a list of video modes (from VGA and/or VBE), allocating several MiB of > RAM for video buffers and font data, scaling font data, etc. If > there's a problem setting up the memory management it's all useless > and I fall back to the "critical error notification method" so the > user knows the OS failed to initialise something (e.g. couldn't > allocate several MiB of RAM). > =20 If you use frmaebuffer info in mbi you can have basic video much faster. > Alternatively, (for my OS) for headless systems; I use RTS/CTS and the > VT100 "identify" command to detect if anything is listening on the > serial port (and if it's a terminal or something else). When nothing > is listening on the other end the OS can't talk so it uses the PC > speaker as a fallback (but continues monitoring the serial port). > Basically if something goes wrong at any stage, the OS beeps, and the > user can plug a terminal in afterwards to find out what went wrong > (rather than having no idea what caused the problem, then connecting a > terminal and rebooting to see if it happens again while they are > watching). > > =20 I feel like here it's not anymore about present hardware or its state but about user configuration. Generally for this type of parameters command line is better suited. >>> 7) The memory map needs more "area types". Any RAM that is reported b= y >>> 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" >> =20 > > For a server environment, would your OS automatically send an email to > an administrator warning them that an area of memory is marked as > "system"? > > =20 I'll think if this alone is enough reason. Are there any other motivation= ? >>> 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 easie= r >>> 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 easil= y >> trackable now. >> =20 > > Unfortunately a lot of OSs are written by C programmers who do the > absolute minimum to setup paging in a small piece of startup code > written in assembly, before jumping to their "main()". This means they > allocate RAM for page tables, etc before they've parsed or checked > anything; usually by searching the memory map for the first "usable" > area and using the first pages of that area. > > Unfortunately I'm often the person that needs to explain to them that > "usable" doesn't mean usable; and that their code only works by > accident (and their initialisation code could overwrite things needed > by the OS later if it's booted by a different multi-boot compliant > boot loader; including future versions of GRUB and not excluding > non-GRUB boot loaders); and that the only memory they can safely use > before determining what is usable and what isn't is the space in their > ".bss", which usually happens to be linked to a virtual address (e.g. > above 0xC00000000) and not the address it's actually loaded at.The > other alternative is for the initialisation code to copy everything > from the "usable" areas into their ".bss" so that they can assume that > "usable" means usable (but there's no maximum size for the multi-boot > information and no way to know how big "big enough" is, and this won't > work if there's any extra modules). > > Basically, regardless of how the OS handles the problem, the "small > piece of startup code written in assembly" ends up being an ugly mess. > > If multi-boot guaranteed that "usable" actually did mean usable then > the problem goes away. Alternatively you could rename it, so that > "type 1 =3D potentially usable maybe" so that beginners realise they're= > screwed before they write their dodgy code... ;-) > > =20 I added a remark to the spec. > Cheers, > > Brendan > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigD3B46096622F21E2F98BA786 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 iF4EAREKAAYFAku/YmcACgkQNak7dOguQgnnNAD/UFbWGFJj3jVwW2Ot44b+/8SI 5e5dcdDMDXrahLiYiSUA/jlXV+9sGcosR9RB9Se1v4z79FvmYw76+Lva07+BaOwd =/qad -----END PGP SIGNATURE----- --------------enigD3B46096622F21E2F98BA786--