Some issues with VBE support.

Some issues with VBE support.

[Vesa Jääskeläinen]

Hi,

I have been working (slowly) on new module for GRUB2 to add support for 
VBE. I have run to some addressing problems so I though I could ask here 
if someone can give an advice.

Running under DPMI host I could use it's services to map frame buffer's 
physical memory address. (using DPMI function 0x800)

So how could this be done in grub?

Otherwise I have already implemented all needed real mode stubs to call 
VBE. I implemented these to kern/i386/pc/startup.S as there were 
existing helpers for VGA.

Can GRUB_MEMORY_MACHINE_SCRATCH_ADDR be used freely on this context? I 
need to some low memory addresses to get information from VBE. For now I 
have used this and it seems to work correctly, but there could be some 
issues that I don't see now?

Thanks,
Vesa Jääskeläinen

Re: Some issues with VBE support.

[Yoshinori K. Okuji]

On Wednesday 06 July 2005 16:30, Vesa Jääskeläinen wrote:
> Otherwise I have already implemented all needed real mode stubs to call
> VBE. I implemented these to kern/i386/pc/startup.S as there were
> existing helpers for VGA.

That's good.

> Can GRUB_MEMORY_MACHINE_SCRATCH_ADDR be used freely on this context? I
> need to some low memory addresses to get information from VBE. For now I
> have used this and it seems to work correctly, but there could be some
> issues that I don't see now?

The scratch memory is meant to be used for any temporary region which must 
reside at lower memory, in particular by BI0S calls. So, if you don't need to 
make the information persistent, it is the right way to use the scratch 
memory for this.

Okuji

Re: Some issues with VBE support.

[Vesa Jääskeläinen]

Vesa Jääskeläinen wrote:
> Running under DPMI host I could use it's services to map frame buffer's 
> physical memory address. (using DPMI function 0x800)
> 
> So how could this be done in grub?

Looking at GDT it looks like that all physical memory is mapped to 
linear space and it should work correctly... Then I tested it on real 
computer to make sure it is not vmware problem and I got visual test 
image what I assumed...

Does anyone know better solution than making floppies and booting on 
other computer?

Thanks,
Vesa Jääskeläinen

Re: Some issues with VBE support.

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

> Does anyone know better solution than making floppies and booting on
> other computer?

Booting using PXE?  I think this is supported already.  The other
solution would be using bochs or qemu, perhaps one of those work
correctly.

--
Marco

Re: Some issues with VBE support.

[Vesa Jääskeläinen]

Vesa Jääskeläinen wrote:
> Looking at GDT it looks like that all physical memory is mapped to 
> linear space and it should work correctly... Then I tested it on real 
> computer to make sure it is not vmware problem and I got visual test 
> image what I assumed...

Hmm... I switched from indexed color mode (0x101) to RGB mode (0x111) 
and now I seem to get picture from vmware too. It could be that in 
vmware, color index table is all black or something like that. I will 
diagnose that problem more later on...

I'll probably publish a test version of it soon, but now I have to do 
other tasks.

Thanks,
Vesa Jääskeläinen

Re: Some issues with VBE support.

[Vesa Jääskeläinen]

Vesa Jääskeläinen wrote:

> Hmm... I switched from indexed color mode (0x101) to RGB mode (0x111) 
> and now I seem to get picture from vmware too. It could be that in 
> vmware, color index table is all black or something like that. I will 
> diagnose that problem more later on...

After a while, also 0x101 started to work, until I stopped virtual 
machine for a while and started it :|, need to diagnose why this 
happened... but not now.

> I'll probably publish a test version of it soon, but now I have to do 
> other tasks.

I have made simple modification from vga terminal to vesafb terminal. It 
is far from being good or complete implementation. It is only provided 
to receive some feedback how it works and for other comments. Formatting 
of source code is probably not following grub 2 coding conventions.

Complete source for grub2 and my modifications can found from here:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-20050710-vesafb.tar.gz

I have modified (at least) following files:
grub2/conf/i386-pc.rmk
grub2/kern/i386/startup.S
grub2/include/grub/machine/vbe.h
grub2/term/i386/pc/vesafb.c

To test it, run normal process of compiling grub2 (configure ; make ; ...)

After booting up:
insmod terminal
insmod vesafb
vbe_list_modes
(pick one listed mode)
set vbe_mode=<picked mode>
terminal vesafb

On startup.S there are also some VBE calls that are not yet implemented, 
so if you are going to play with it, check those from there first.

After I have some time to implement those, I could see what needs to be 
done elsewhere to really start using graphical modes and then start 
discussion on it.

Thanks,
Vesa Jääskeläinen