[gPXE] int 10h problem
Deal all,
I just tested int 0x10 BIOS interrupt to draw some pictures.
However, when I coded the follow to enter 640X480 video mode, it seems that the
actual video mode is 640X100,
I draw a rectangle with range(0,0, 640, 480) to verify, and it resulted in
range(0,0, 640,100), about a quarter square of a rectangle.
And I noticed that 320X200 video mode is OK, and 320X200 == 640X100, is that
mean my machine can hand only 64000 pixels?
Can anyone tell me why?
///
void setvga()
{
__asm__ __volatile__ ( REAL_CODE ( movw $0x4f02, %%ax\n\t //ax=0x0012 here
seem stay in the text mode
movw $0x0101, %%bx\n\t
int $0x10\n\t )::);
}
void putpixel(int x,int y,int c)
{
if(vediobuf == NULL)
{
vediobuf = (unsigned char*)phys_to_user(0xa); //physic address of
graphic mode
}
*(vediobuf+x+640*y)=c;
}
/
yours,
soforth___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
[gPXE] Windows 2008 install directly to iscsi target boot problem
Hi, I am trying to install Windows 2008 directly to iscsi disk using gPXE. I've tried almost everything and I am still (now for 2 months) stuck on this. I have DHCP set according to guidelines bellow and as iscsi target I use Openfiler 2.3 (I have also tried CCBoot with the same result). Booting computer has MB Gigabyte GA-8I915PL-G. There is local HDD in computer. I have followed http://etherboot.org...8_iscsi_install . At first I have used NIC Marvell Yukon 88E8001 and chainloaded gPXE via PXE, using this I have during installation to iscsi target seen iscsi disk (when was prompted where to instal to), but i got message Windows cannot be installed to this disk. This computer's hardware may not support booting to this disk. Ensure that the disk's controller is enabled in the computer's BIOS menu. At this point installation ended, because despite all guidelines I couldn't proceed any further. Then I got NIC Intel pro 1000 gt and flashed gPXE1.0.0 rom onto it. Using this, when I am in selection where to install windows, I select iscsi drive and I got the same message Windows cannot be installed to this disk. This computer's ..., but when I click Next, installation starts and it goes to point where it needs to restart computer. The problem is, it copy windows files to iscsi disk, but bootloader writes to local HDD in PC. So after restart, there is no bootloader gPXE (embedded in NIC) could load. I have also tried CCBoot to install Windows 7 to and it's the same problem (without Intel card with flashed gPXE I cannot install to the disk at all, with that card I could proceed to the point where setup restarts computer and I find 7 GB written on CCBoot server but loader is written on local HDD). When I physically detach local HDD, I couldn't install windows either, it ends at the point when I select disk to install windows to with Windows cannot be installed I have tested this on 2 other computers and got the same results. In all cases, gPXE + linux server + Openfiler has exactly the same results as CCBoot. I will be grateful for all insights where could the problem be and how to solve it. Thank you, TomasK ___ gPXE mailing list gPXE@etherboot.org http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] Windows 2008 install directly to iscsi target boot problem
Hello Tomas, The infamous error that you are getting, Windows cannot be installed to this disk, is, as I found out[1], an issue that's caused by a combination of Windows' inability to resolve ARC paths for some system BIOSes in the presence of BIOS INT 13h hooks like the one gPXE uses to attach its SAN target. Some of the troubleshooting steps, like attaching an internal hard drive, allow you to trick (for lack of a better word) Windows into resolving these ARC paths correctly and proceeding with the iSCSI installation. The problem is that it's hit or miss as to whether or not that will work for your BIOS. In your case, adding a drive presented Windows with two installation sources, but the ARC path for your iSCSI disk still wasn't available to the Windows installer. As a result, it only considered your local disk to be bootable, and wrote the BCD and copied BOOTMGR to *it* while placing everything else on the SAN. The SAN disk will get its MBR written, so it'll *try* to boot, but since there's no actual boot loader on it, it can't boot without the other [local] drive being available for that data. You *could* try manually hacking your BCD onto the SAN disk after the first installation step... it *may* be as simple as a drag/drop from a workstation that has both disks attached, but you'll more than likely need to use BCDEdit to get things working right, but that's *definitely* the most complicated way to get things working. A BIOS update couldn't hurt, but I doubt it would fix your problem. The simplest thing you can do is to install to the local disk and image over to your SAN. Obviously, it's also the most time consuming way to do it, and completely kills the cool factor ;) The unfortunate thing is that I couldn't find any method to get Windows to just perform all the installation steps anyway. It really, really seems to think that if *it* doesn't know for sure whether a disk is bootable, that you couldn't know either. Sigh :P Cheers, Andrew Bobulsky [1]: http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/cea6177e-9cb2-420e-bbc0-0cac487e51e2 On Fri, Apr 1, 2011 at 11:26 AM, Tomas K tksoft2...@gmail.com wrote: Hi, I am trying to install Windows 2008 directly to iscsi disk using gPXE. I've tried almost everything and I am still (now for 2 months) stuck on this. I have DHCP set according to guidelines bellow and as iscsi target I use Openfiler 2.3 (I have also tried CCBoot with the same result). Booting computer has MB Gigabyte GA-8I915PL-G. There is local HDD in computer. I have followed http://etherboot.org...8_iscsi_install . At first I have used NIC Marvell Yukon 88E8001 and chainloaded gPXE via PXE, using this I have during installation to iscsi target seen iscsi disk (when was prompted where to instal to), but i got message Windows cannot be installed to this disk. This computer's hardware may not support booting to this disk. Ensure that the disk's controller is enabled in the computer's BIOS menu. At this point installation ended, because despite all guidelines I couldn't proceed any further. Then I got NIC Intel pro 1000 gt and flashed gPXE1.0.0 rom onto it. Using this, when I am in selection where to install windows, I select iscsi drive and I got the same message Windows cannot be installed to this disk. This computer's ..., but when I click Next, installation starts and it goes to point where it needs to restart computer. The problem is, it copy windows files to iscsi disk, but bootloader writes to local HDD in PC. So after restart, there is no bootloader gPXE (embedded in NIC) could load. I have also tried CCBoot to install Windows 7 to and it's the same problem (without Intel card with flashed gPXE I cannot install to the disk at all, with that card I could proceed to the point where setup restarts computer and I find 7 GB written on CCBoot server but loader is written on local HDD). When I physically detach local HDD, I couldn't install windows either, it ends at the point when I select disk to install windows to with Windows cannot be installed I have tested this on 2 other computers and got the same results. In all cases, gPXE + linux server + Openfiler has exactly the same results as CCBoot. I will be grateful for all insights where could the problem be and how to solve it. Thank you, TomasK ___ gPXE mailing list gPXE@etherboot.org http://etherboot.org/mailman/listinfo/gpxe ___ gPXE mailing list gPXE@etherboot.org http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] int 10h problem
2011/4/1 何闯 justhechu...@163.com:
Deal all,
I just tested int 0x10 BIOS interrupt to draw some pictures.
However, when I coded the follow to enter 640X480 video mode, it seems that
the actual video mode is 640X100,
I draw a rectangle with range(0,0, 640, 480) to verify, and it resulted in
range(0,0, 640,100), about a quarter square of a rectangle.
And I noticed that 320X200 video mode is OK, and 320X200 == 640X100, is that
mean my machine can hand only 64000 pixels?
Can anyone tell me why?
///
void setvga()
{
__asm__ __volatile__ ( REAL_CODE ( movw $0x4f02, %%ax\n\t //ax=0x0012
here seem stay in the text mode
movw $0x0101, %%bx\n\t
int $0x10\n\t )::);
}
void putpixel(int x,int y,int c)
{
if(vediobuf == NULL)
{
vediobuf = (unsigned char*)phys_to_user(0xa); //physic address of
graphic mode
}
*(vediobuf+x+640*y)=c;
}
/
yours,
soforth
I'd suggest looking at other boot loaders and how they write to the
screen (including Syslinux's vesamenu.c32 and gfxboot.c32). 64,000
sounds like the 16-bit limit of 65,536 per segment.
--
-Gene
___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] int 10h problem
I'd suggest you find out how many bytes there are per pixel. I guess
you have 4 (not 1 you are using) and the resolution you think you see
is actually 640x120. You may also have limited video memory that makes
different resolutions use different pixel sizes
In Reply to:
2011/4/1 何闯 justhechu...@163.com:
Deal all,
I just tested int 0x10 BIOS interrupt to draw some pictures.
However, when I coded the follow to enter 640X480 video mode, it seems
that
the actual video mode is 640X100,
I draw a rectangle with range(0,0, 640, 480) to verify, and it resulted in
range(0,0, 640,100), about a quarter square of a rectangle.
And I noticed that 320X200 video mode is OK, and 320X200 == 640X100, is
that
mean my machine can hand only 64000 pixels?
Can anyone tell me why?
///
void setvga()
{
__asm__ __volatile__ ( REAL_CODE ( movw $0x4f02, %%ax\n\t //ax=0x0012
here seem stay in the text mode
movw $0x0101, %%bx\n\t
int $0x10\n\t )::);
}
void putpixel(int x,int y,int c)
{
if(vediobuf == NULL)
{
vediobuf = (unsigned char*)phys_to_user(0xa); //physic address of
graphic mode
}
*(vediobuf+x+640*y)=c;
}
/
yours,
soforth
I'd suggest looking at other boot loaders and how they write to the
screen (including Syslinux's vesamenu.c32 and gfxboot.c32). 64,000
sounds like the 16-bit limit of 65,536 per segment.
___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] int 10h problem
On Fri, Apr 1, 2011 at 15:15, Vaza gpxe vaza.g...@gmail.com wrote:
I'd suggest you find out how many bytes there are per pixel. I guess
you have 4 (not 1 you are using) and the resolution you think you see
is actually 640x120. You may also have limited video memory that makes
different resolutions use different pixel sizes
I believe there should be only 4 bits at that video mode.
Soforth, I'd suggest examining http://www.ctyme.com/intr/int-10.htm
for starters. I believe INT 10h AX 4F00h is the start of VESA related
info that Syslinux uses for vesamenu.c32 (and possibly gfxboot.c32)
--
-Gene
In Reply to:
2011/4/1 何闯 justhechu...@163.com:
Deal all,
I just tested int 0x10 BIOS interrupt to draw some pictures.
However, when I coded the follow to enter 640X480 video mode, it seems
that
the actual video mode is 640X100,
I draw a rectangle with range(0,0, 640, 480) to verify, and it resulted in
range(0,0, 640,100), about a quarter square of a rectangle.
And I noticed that 320X200 video mode is OK, and 320X200 == 640X100, is
that
mean my machine can hand only 64000 pixels?
Can anyone tell me why?
///
void setvga()
{
__asm__ __volatile__ ( REAL_CODE ( movw $0x4f02, %%ax\n\t //ax=0x0012
here seem stay in the text mode
movw $0x0101, %%bx\n\t
int $0x10\n\t )::);
}
void putpixel(int x,int y,int c)
{
if(vediobuf == NULL)
{
vediobuf = (unsigned char*)phys_to_user(0xa); //physic address of
graphic mode
}
*(vediobuf+x+640*y)=c;
}
/
yours,
soforth
I'd suggest looking at other boot loaders and how they write to the
screen (including Syslinux's vesamenu.c32 and gfxboot.c32). 64,000
sounds like the 16-bit limit of 65,536 per segment.
___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] int 10h problem
Thanks for the clue, I will check the code in vesamenu.c32 and find why. ：）
At 2011-04-02，Gene Cumm gene.c...@gmail.com wrote:
On Fri, Apr 1, 2011 at 15:15, Vaza gpxe vaza.g...@gmail.com wrote:
I'd suggest you find out how many bytes there are per pixel. I guess
you have 4 (not 1 you are using) and the resolution you think you see
is actually 640x120. You may also have limited video memory that makes
different resolutions use different pixel sizes
I believe there should be only 4 bits at that video mode.
Soforth, I'd suggest examining http://www.ctyme.com/intr/int-10.htm
for starters. I believe INT 10h AX 4F00h is the start of VESA related
info that Syslinux uses for vesamenu.c32 (and possibly gfxboot.c32)
--
-Gene
In Reply to:
2011/4/1 何闯 justhechu...@163.com:
Deal all,
I just tested int 0x10 BIOS interrupt to draw some pictures.
However, when I coded the follow to enter 640X480 video mode, it seems
that
the actual video mode is 640X100,
I draw a rectangle with range(0,0, 640, 480) to verify, and it resulted in
range(0,0, 640,100), about a quarter square of a rectangle.
And I noticed that 320X200 video mode is OK, and 320X200 == 640X100, is
that
mean my machine can hand only 64000 pixels?
Can anyone tell me why?
///
void setvga()
{
__asm__ __volatile__ ( REAL_CODE ( movw $0x4f02, %%ax\n\t //ax=0x0012
here seem stay in the text mode
movw $0x0101, %%bx\n\t
int $0x10\n\t )::);
}
void putpixel(int x,int y,int c)
{
if(vediobuf == NULL)
{
vediobuf = (unsigned char*)phys_to_user(0xa); //physic address of
graphic mode
}
*(vediobuf+x+640*y)=c;
}
/
yours,
soforth
I'd suggest looking at other boot loaders and how they write to the
screen (including Syslinux's vesamenu.c32 and gfxboot.c32). 64,000
sounds like the 16-bit limit of 65,536 per segment.
___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
