Brendan Trotter wrote: > Hi, > >>> 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 >> > > Here's an example termcap string: > > ca|concept100|c100|concept|c104|concept100-4p|HDS Concept-100:\ > :al=3*\E^R:am:bl=^G:cd=16*\E^C:ce=16\E^U:cl=2*^L:cm=\Ea%+ %+ :\ > > :co#80:.cr=9^M:db:dc=16\E^A:dl=3*\E^B:do=^J:ei=\E\200:eo:im=\E^P:in:\ > > :ip=16*:is=\EU\Ef\E7\E5\E8\El\ENH\EK\E\200\Eo&\200\Eo\47\E:k1=\E5:\ > :k2=\E6:k3=\E7:kb=^h:kd=\E<:ke=\Ex:kh=\E?:kl=\E>:kr=\E=:ks=\EX:\ > :ku=\E;:le=^H:li#24:mb=\EC:me=\EN\200:mh=\EE:mi:mk=\EH:mp=\EI:\ > :mr=\ED:nd=\E=:pb#9600:rp=0.2*\Er%.%+ > :se=\Ed\Ee:sf=^J:so=\EE\ED:\ > :.ta=8\t:te=\Ev \200\200\200\200\200\200\Ep\r\n:\ > :ti=\EU\Ev 8p\Ep\r:ue=\Eg:ul:up=\E;:us=\EG:\ > > :vb=\Ek\200\200\200\200\200\200\200\200\200\200\200\200\200\200\EK:\ > :ve=\Ew:vs=\EW:vt#8:xn:\ > :bs:cr=^M:dC#9:dT#8:nl=^J:ta=^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. > It doesn't need to be termcap string in its normal form. It can be sth like: uint16_t offset_to_gotoxy_string; uint16_t offset_to_cls_string; ... uint16_t offset_to_end_of_last_string; <strings> 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. >>> >> I think it's more useful to have an I/O selector since yeeloong serial >> interface is basically the same, just attached differently >> > > An I/O selector (for "8250/6550 compatible") makes sense, and > different tags for "not 8250/6550 compatible" serial ports. > > >> I think we need following fields: >> 1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O) >> > > For 32-bit MMIO you could use 64-bit MMIO with the high bits of the > "address in I/O space" set to zero. > > 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 = you can access even if you're not 64-bit aware 1 = 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... > > 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 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. >>> >>> >> Processing such a selector may prove as difficult as setting up a >> console based on console tags. So I doubt its usefullness >> > > 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). > 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). > > 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 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". >>> >>> >> What's the difference between type 2 and "type 5" >> > > 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"? > > 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 = RAM used for multi-boot information" and "area type >>> 0xFFFFFFFD = 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. >>> >>> >> 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. >> > > 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 = potentially usable maybe" so that beginners realise they're > screwed before they write their dodgy code... ;-) > > 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 > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
