Fw: 16-bit bootloader support?

Fw: 16-bit bootloader support?

[Bogdan]

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.

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
>


      

Re: Fw: 16-bit bootloader support?

[Seth Goldberg]

Quoting Bogdan, who wrote the following on Thu, 8 Oct 2009:

> 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.
>
> It's not legacy code I'm talking about.


   Do you seriously have an OS you want to boot that starts in 16-bit 
protected mode?  Or is this just an academic question? You're free to add 
support for such a system, but IMHO, its usefulness is dubious, at best.

  --S

Re: Fw: 16-bit bootloader support?

[Vladimir 'phcoder' Serbinenko]

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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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

Re: Fw: 16-bit bootloader support?

[Bogdan]

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 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 (and the spec)?

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
> Grub-devel@gnu.org
> 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
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



      

Re: Fw: 16-bit bootloader support?

[Vladimir 'phcoder' Serbinenko]

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
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>  
>>     
>
>
>   


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

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 <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
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
>> Grub-devel@gnu.org
>> 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
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



      

Re: Fw: 16-bit bootloader support?

[Robert Millan]

On Fri, Oct 09, 2009 at 02:21:06AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> 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)

I have very limited interest in this.  But if there's real demand (i.e. not
just a toy) and it doesn't mean more work for us, we could accept it.

Is there a proof-of-concept patch?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Fw: 16-bit bootloader support?

[Bogdan]

Again, sorry for the top-down mail. There will be a patch just as soon as I get a bit of spare time (this weekend might be a good opportunity). All I have now is a hack that will work for my system under well-known conditions.

Cheers,
Bogdan


----- Original Message ----
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Sent: Fri, October 9, 2009 8:55:02 PM
Subject: Re: Fw: 16-bit bootloader support?

On Fri, Oct 09, 2009 at 02:21:06AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> 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)

I have very limited interest in this.  But if there's real demand (i.e. not
just a toy) and it doesn't mean more work for us, we could accept it.

Is there a proof-of-concept patch?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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