Re: Fw: 16-bit bootloader support?

[Bogdan]

I will need to look into any problems related with 16-bit code. ELF itself is 
not a problem - for instance binutils can work with 16-bit ELFs even if the 
standard doesn't actually define them. The Multiboot specification also lets 
people use other formats (e.g., a.out or plain binaries) so that souldn't be 
much of an issue anyway. If I run into any major problems that might create any 
maintainability issues in the future I will be sure to let you guys know before 
I commit any patches. However if I find an elegant solution I will come back to 
you soon.

Cheers,
Bogdan


----- Original Message ----
From: Vladimir 'phcoder' Serbinenko <address@hidden>
To: The development of GRUB 2 <address@hidden>
Sent: Fri, October 9, 2009 3:21:06 AM
Subject: Re: Fw: 16-bit bootloader support?

Bogdan wrote:
> The difference is basically that you have no paging, the linear address is 
> the same as the physical address, no virtual 8086 mode, no way of going back 
> to real mode, the segment address inside the descriptor table is 24 bits wide 
> and the limit is 16 bits wide.
>
> In response to Seth - there are still business and apparently research 
> machines out there that still use the 80286. It's arguable whether one would 
> actually need to be able to boot several OSes on such machines 
For multi-OS on pre-386 use mbrldr (mbrldr.sf.net)
> but I am an example of someone who is personally interested in this. If I 
> write support for this can it be merged into GRUB 
Rule of a thumb is "if you do it in a way it doesn't create a
maintenance burden then it can be merged". Due to limited usefullness
the amount of maintenance burden I'm ok to tolerate is small. I would
define 286 as a separate architecture with perhaps some BIOS-related and
realmode code reusage. This way it minimises the amount of it getting in
the way
Due to 16-bit pointers it's still likely to get in the way of a lot of
code. Also even before you start you have to ensure grub2 can work with
less than 1 MiB of memory.
In whole I would say that maintaining 16-bit compatible code is a burden
and probably not worth if only PC 286 is considered. Additionally
without being able to load any kernel natively grub's usefulness
decreases. Many other modules become useless too because newer standards
aren't supported on 286 hardware. In whole I feel like multi-OS on 286
and 8086 niche is well filled by mbrldr.
(but I'm not maintainer)

> (and the spec)?
>
>  
multiboot spec is meant for 32-bit mode and relies on e.g. ELF standard.
It's also not meant for any other arcitecture than i386. multiboot2 may
be more appropriate because it's done with portability in mind.
The issue is different however if we take into account that some embeded
systems are 16-bit and some are even 8086 or 80286. Then we also have
some free kernels we may want to support like uClinux. In this case
maintenance issues are somewhat offset by greater usefullness.
Do we want grub2 to go in embedded systems?
Do we want grub2 to go in 16-bit embedded systems?
Do we want grub2 to go in 8-bit and less embedded systems?
> Cheers,
> Bogdan
>
>
> Bogdan wrote:
>  
>> I'm sorry for the top-down mail but Yahoo! Mail is gay. No, I don't mean 
>> virtual 8086 mode, I mean the 16-bit protected mode - which is 16-bit and 
>> not 32-bit. Protected mode was introduced on the Intel 80286 which was still 
>> a 16-bit CPU. Protected mode was later extended for 32-bit allowing of 
>> course for backward compatibility. Windows 3.1 is a good example of an OS 
>> capable of handling 16-bit pmode.
>>
>>  
>>    
> What is the difference between 16-bit and 32-bit protected mode? Is
> 16-bit protected mode like 32-bit protected mode, not paged mode but
> with upper 16-bits ignored?
> What are the benefits of supporting it?
>  
>> It's not legacy code I'm talking about.
>>
>> Cheers,
>> Bogdan
>>
>>
>> Bogdan wrote:
>>  
>>    
>>> Most probably the developers of GRUB will say that this is useless but
>>> did anyone think of adding 16-bit protected mode support to the
>>> Multiboot specification and to GRUB?
>>>    
>>>      
>> Which mode do you mean?
>> protected mode=32-bit mode
>> You may mean vm8086 mode but it's meant only for compatibility purposes.
>> As such it's an OS responsibility to set it up when executing legacy code
>>  
>>    
>>> Cheers,
>>> Bogdan
>>>
>>>    
>>>      
>>      
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>  
>>    
>
>
>  


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 



_______________________________________________
Grub-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/grub-devel