Re: Multiboot2 Suggestions

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9671 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]