[LinuxBIOS] Help Debugging Windows VISTA - GSoC

[Augusto Pedroza]

<#>Hi guys,
  I have tried in the last few days to debug windows VISTA installation
process in different ways. All my tests have been doing using qemu.

At first I tried to debug windows vista using WinGdb, but it seems to work
only when windows is already installed since it requires some modifications
in the boot.ini file. So was unable to connect wingdb to qemu through a
pipe.

My second option was to try to use windows debug mode when pressing F8
during the beginning of the installation process but the only info I found
was this:

Debugging Mode: This option turns on debug mode in Windows. Debugging
information can be sent across a serial cable to another computer that is
running a debugger. This mode is configured to use COM2.

Does anyone knows how to capture COM2 output when using qemu? Maybe using a
real hardware makes it easier since I can use a different computer connected
to the guest through a NULL cable.

Since I have gotten some random results when using qemu with its original
bios, I have been unable to install windows vista on  a hard disk image.
Yesterday i almost got it but i created a image file too small, Vista
requires at least 6Gb. I guess if I get that i'll be able to use wingdb more
easily.

Thanks,

[Carl-Daniel Hailfinger]

On 08.08.2007 15:02, Augusto Pedroza wrote:
> Since I have gotten some random results when using qemu with its original
> bios, I have been unable to install windows vista on  a hard disk image.
> Yesterday i almost got it but i created a image file too small, Vista
> requires at least 6Gb. I guess if I get that i'll be able to use wingdb more
> easily.

Does that mean you can't even get Vista to install without problems in
normal Qemu?

Regards,
Carl-Daniel

[Augusto Pedroza]

Exactly!!

I think I can find out why using the qemu option -serial /dev/ttyS1  and
enabling debugging mode during windows start up. I just wonder if i can
connect another computer to the one running qemu and still get the output
send by qemu to emulated /dev/ttyS1. I'll test that tonight.

Regrads,
  Augusto Pedroza

On 8/8/07, Carl-Daniel Hailfinger  wrote:
> On 08.08.2007 15:02, Augusto Pedroza wrote:
> > Since I have gotten some random results when using qemu with its
>
> original
> > bios, I have been unable to install windows vista on  a hard disk image.
> > Yesterday i almost got it but i created a image file too small, Vista
> > requires at least 6Gb. I guess if I get that i'll be able to use wingdb
>
> more
> > easily.
>
> Does that mean you can't even get Vista to install without problems in
> normal Qemu?
>
> Regards,
> Carl-Daniel

[LinuxBIOS] Generic RAM detection routine

[popkonserve]

Hi,
i'll have a generic ram detection routine ready by the end of the week 
that it able to detect any size of EDO/FPM (and maybe SDRAM too) just by 
reading/writing data. it doesn't need to access any smbus. i'll use this 
routine to support DRAM initialization on almost any socket 7 
chipset..just have a little patience. the routine will not be able to 
determine any memory latencies by itself, so it may require user 
interactity or it will just set default values.
the chipsets that will be supported:
ALi Aladdin III/IV/IV/V
AMD 640
Intel 430FX/HX/VX/TX
SiS 5501,5502,5503/5120/5571/5581,5582/5591,5592/5597,5598/530
VIA 570M/580VP(VP1)/580VPX(VPX)/595(VP2)/597(VP3)/598(MVP3)
before you ask: yes, i'll write a separate raminit.c for all those 
chipsets..so it may take a while. anyway, the all use the same ram 
detection routine that, as said before, will be finished by the end of 
the week. any help is appreciated.
if the ram detection works for sdram as well (i didn't took a closer 
look but i guess it works just like the edo/fpm detection) i'll write 
routines for various Slot1 chipsets, too. Intel LX/BX first i guess.
btw. if you happen to live in germany and you want to donate some of the 
above listed hardware for testing purpose: drop me a line :)
Holger

[LinuxBIOS] Generic RAM detection routine

[Joseph Smith]

Quoting popkonserve :
> Hi,
> i'll have a generic ram detection routine ready by the end of the week
> that it able to detect any size of EDO/FPM (and maybe SDRAM too) just by
> reading/writing data. it doesn't need to access any smbus. i'll use this
> routine to support DRAM initialization on almost any socket 7
> chipset..just have a little patience. the routine will not be able to
> determine any memory latencies by itself, so it may require user
> interactity or it will just set default values.
> the chipsets that will be supported:
> ALi Aladdin III/IV/IV/V
> AMD 640
> Intel 430FX/HX/VX/TX
> SiS 5501,5502,5503/5120/5571/5581,5582/5591,5592/5597,5598/530
> VIA 570M/580VP(VP1)/580VPX(VPX)/595(VP2)/597(VP3)/598(MVP3)
> before you ask: yes, i'll write a separate raminit.c for all those
> chipsets..so it may take a while. anyway, the all use the same ram
> detection routine that, as said before, will be finished by the end of
> the week. any help is appreciated.
> if the ram detection works for sdram as well (i didn't took a closer
> look but i guess it works just like the edo/fpm detection) i'll write
> routines for various Slot1 chipsets, too. Intel LX/BX first i guess.
> btw. if you happen to live in germany and you want to donate some of the
> above listed hardware for testing purpose: drop me a line :)
> Holger

Interesting. How will this work without reading SPD data without the  
smbus? Will it just be able to detect if memory is populated? Size?  
Other important info to set northbridge registers? Do tell....

Thanks - Joe

[LinuxBIOS] Generic RAM detection routine

[popkonserve]

> Interesting. How will this work without reading SPD data without the  
> smbus? Will it just be able to detect if memory is populated? Size?  
> Other important info to set northbridge registers? Do tell....

since EDO/FPM don't have a SPD eeprom there's no need trying to get any 
data out of it :)
size and internal organisation detection is done by a simple algorithm. 
i hope i'll have a sample of it ready later. it'll feature the ram init 
and detection of the Intel 430FX chipset and will have lots of comments 
:) the rest should be a bit of datasheet surfing and register adapting 
(more or less).
Holger

[LinuxBIOS] Generic RAM detection routine

[Joseph Smith]

Quoting popkonserve :
> > Interesting. How will this work without reading SPD data without the
> > smbus? Will it just be able to detect if memory is populated? Size?
> > Other important info to set northbridge registers? Do tell....
>
> since EDO/FPM don't have a SPD eeprom there's no need trying to get any
> data out of it :)
> size and internal organisation detection is done by a simple algorithm.
> i hope i'll have a sample of it ready later. it'll feature the ram init
> and detection of the Intel 430FX chipset and will have lots of comments
> :) the rest should be a bit of datasheet surfing and register adapting
> (more or less).
> Holger

Cool for simms, but not sure how this would work out for SDRAM, DDR,  
DDR2, etc. There is alot of data that comes from the SPD eeprom that  
the nothbridge needs to set up its registers, and check for  
compatability, etc. That's where the SMBUS needs to come in....

Still, I am very interested. Can you elaborate on what kind of data  
the "simple algorithm" will be able to produce?

Thanks - Joe

[LinuxBIOS] Generic RAM detection routine

[Peter Stuge]

On Thu, Aug 09, 2007 at 11:03:09AM -0400, Joseph Smith wrote:
> > since EDO/FPM don't have a SPD eeprom
>
> Cool for simms,

Which I think is the scope of the code.
> but not sure how this would work out for SDRAM, DDR, DDR2, etc.

I don't think it's a good idea to try to cover all types of RAM with
one piece of code. The different memory types need different init so
it will be more like a library.
> There is alot of data that comes from the SPD eeprom that
> the nothbridge needs to set up its registers, and check for
> compatability, etc. That's where the SMBUS needs to come in....

Yep. There's been some work to unify SPD already, but I think most of
the improvements here will be in v3.

//Peter

[Carl-Daniel Hailfinger]

On 08.08.2007 20:22, Augusto Pedroza wrote:
> On 8/8/07, Carl-Daniel Hailfinger  wrote:
> > Does that mean you can't even get Vista to install without problems in
> > normal Qemu?
>
> Exactly!!

As it turns out, current Bochs can run Vista and since we depend on the
Bochs BIOS for ADLO, updating the codebase could result in a working
Vista. See http://marc.info/?l=bochs-dev&m=118650789913052&w=2 for the
success message.

Regards,
Carl-Daniel

[Augusto Pedroza]

> As it turns out, current Bochs can run Vista and since we depend on the
> Bochs BIOS for ADLO, updating the codebase could result in a working
> Vista. See http://marc.info/?l=bochs-dev&m=118650789913052&w=2 for the
> success message.

We are using one of the newest versions of bochs bios and it does work ...
sometimes. For some reason it works 1 out of 10 times. Most of the times It
shows a blue screen related to ACPI or PAGE_FAULT.
Yesterday I almost  finished installing vista on a disk image but it
displayed a message saying it couldn't set my locale and canceled the
installation, can you believe that?
  I'm trying very hard to connect the virtual serial COM2 port of qemu to my
real COM2/ttyS1 port so we can get some messages when turning on debugging
mode. I have tried different settings but no sucess up to now.
  I'll email Stanislav to fins out if he faced the same problems.

Thanks a lot,

[Carl-Daniel Hailfinger]

On 09.08.2007 14:43, Augusto Pedroza wrote:
> > As it turns out, current Bochs can run Vista and since we depend on the
> > Bochs BIOS for ADLO, updating the codebase could result in a working
> > Vista. See http://marc.info/?l=bochs-dev&m=118650789913052&w=2 for the
> > success message.
>
> We are using one of the newest versions of bochs bios and it does work ...

The 16bit or the 32bit version of the BIOS? Can you check if the current
Bochs code still works with W2k/WXP?
If the current code still works, please send a patch updating the code
to the list and commit after an Ack.
> sometimes. For some reason it works 1 out of 10 times. Most of the times It
> shows a blue screen related to ACPI or PAGE_FAULT.
> Yesterday I almost  finished installing vista on a disk image but it
> displayed a message saying it couldn't set my locale and canceled the
> installation, can you believe that?

Heh. That is pure excellence by Microsoft...
> I'll email Stanislav to fins out if he faced the same problems.

AFAIK Stanislas ran Vista on Bochs, not on Qemu with a Bochs BIOS.

Regards,
Carl-Daniel