Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
On Wed, 21 Apr 2010, Kevin O'Connor wrote: On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote: On Mon, 19 Apr 2010, Kevin O'Connor wrote: SeaBIOS will lock parts of ram from 0xc-0xf so that the option roms aren't writable. I wonder if that is confusing qemm when it tries to locate the ebda into that area. From your initial log, it looks like QEMM tried to relocate the ebda to CEB5h-D035h. However, the seabios log shows the last rom (genroms/vapic.bin) at 0xce800-0xd0a00. So, SeaBIOS would have locked that ram. Can you see if the patch below shows a different result for you? Ok, log file was until boot process only (as we discussed SCSI EBDA area). Therefore no QEMM is involved at all. Can send complete log file today evening for both cases (QEMM with/wo NOXBDA parameter). Is the area from 0xc-0xf only read only when an option ROM is installed at some part of the memory area (e.g. option ROM at 0xD to 0xD only 0xD to 0xD is made read only) or the comple area is made read only? SeaBIOS will lock only those areas it deployed option roms into. However, the chipset only allows locking of 16K chunks - so SeaBIOS will round up the option rom storage to the nearest 16K block. For example, should the last rom end at 0xd0a00, then SeaBIOS would lock up to 0xd4000. OK, clear. Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote:
> On Mon, 19 Apr 2010, Kevin O'Connor wrote:
> >SeaBIOS will lock parts of ram from 0xc-0xf so that the option
> >roms aren't writable. I wonder if that is confusing qemm when it
> >tries to locate the ebda into that area.
>From your initial log, it looks like QEMM tried to relocate the ebda
to CEB5h-D035h. However, the seabios log shows the last rom
(genroms/vapic.bin) at 0xce800-0xd0a00. So, SeaBIOS would have locked
that ram. Can you see if the patch below shows a different result for
you?
> Is the area from 0xc-0xf only read only when an option ROM
> is installed at some part of the memory area (e.g. option ROM at
> 0xD to 0xD only 0xD to 0xD is made read only) or the
> comple area is made read only?
SeaBIOS will lock only those areas it deployed option roms into.
However, the chipset only allows locking of 16K chunks - so SeaBIOS
will round up the option rom storage to the nearest 16K block. For
example, should the last rom end at 0xd0a00, then SeaBIOS would lock
up to 0xd4000.
-Kevin
--- a/src/shadow.c
+++ b/src/shadow.c
@@ -104,6 +104,8 @@ make_bios_readonly(void)
// Flush any pending writes before locking memory.
wbinvd();
+dprintf(1, "RomEnd=%x\n", RomEnd);
+#if 0
// Write protect roms from 0xc-0xf
int i;
for (i=0; i<6; i++) {
@@ -115,6 +117,7 @@ make_bios_readonly(void)
}
pci_config_writeb(bdf, 0x5a + i, 0x11);
}
+#endif
// Write protect 0xf-0x10
pci_config_writeb(bdf, 0x59, 0x10);
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
On Mon, 19 Apr 2010, Kevin O'Connor wrote: On Mon, Apr 19, 2010 at 08:19:55AM +0200, Gerhard Wiesinger wrote: Kevin O'Connor wrote: The SeaBIOS log would really help. This can be done by adding: -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios to the qemu command line. OK, I made some research on the topic. Problem is that QEMM pushes the Extended BIOS data area to High RAM on some machines (QEMU, P733). Therefore 640k low memory is available and checkit reports 640kB + 6kB=646kB EBIOS DATA AREA. Whats strange that on a physical Pentium 733 machine this works correctly (details see below and attached files), maybe someone can try to find the problem with QEMM+Checkit 3.0 (maybe there is still some other BIOS function incorrectly implemented). QEMM parameter NOXBDA avoids moving the XBDA up to HI RAM and therefore checkit reports 640kB well. SeaBIOS seems to be correct (see below and attached patch files and description below). Total Memory: 256MB (262144kB), Base RAM: 637kB Extended BIOS Data Area size: 3 kB, segment=9f40 SCSI option ROM: After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB Extended BIOS Data Area size: 6 kB, segment=9e80 Which scsi option rom? Can you forward the log using the command line above? Another thing that may help is increasing the debug level in seabios (set CONFIG_DEBUG_LEVEL to 8 in src/config.h and recompile). SeaBIOS will lock parts of ram from 0xc-0xf so that the option roms aren't writable. I wonder if that is confusing qemm when it tries to locate the ebda into that area. SCSI option ROM, LSI 53C895A (BTW: Is there another SCSI emulation available?): http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip Log file can be downloaded at: http://www.wiesinger.com/tmp/seabios.log command line option: -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios CONFIG_DEBUG_LEVEL to 8 in src/config.h Is the area from 0xc-0xf only read only when an option ROM is installed at some part of the memory area (e.g. option ROM at 0xD to 0xD only 0xD to 0xD is made read only) or the comple area is made read only? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
On Mon, Apr 19, 2010 at 08:19:55AM +0200, Gerhard Wiesinger wrote: > Kevin O'Connor wrote: > >The SeaBIOS log would really help. This can be done by adding: > > > >-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios > > > >to the qemu command line. > OK, I made some research on the topic. Problem is that QEMM pushes > the Extended BIOS data area to High RAM on some machines (QEMU, > P733). Therefore 640k low memory is available and checkit reports > 640kB + 6kB=646kB EBIOS DATA AREA. Whats strange that on a physical > Pentium 733 machine this works correctly (details see below and > attached files), maybe someone can try to find the problem with > QEMM+Checkit 3.0 (maybe there is still some other BIOS function > incorrectly implemented). QEMM parameter NOXBDA avoids moving the > XBDA up to HI RAM and therefore checkit reports 640kB well. > > SeaBIOS seems to be correct (see below and attached patch files and > description below). > Total Memory: 256MB (262144kB), Base RAM: 637kB > Extended BIOS Data Area size: 3 kB, segment=9f40 > > SCSI option ROM: > After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB > Extended BIOS Data Area size: 6 kB, segment=9e80 Which scsi option rom? Can you forward the log using the command line above? Another thing that may help is increasing the debug level in seabios (set CONFIG_DEBUG_LEVEL to 8 in src/config.h and recompile). SeaBIOS will lock parts of ram from 0xc-0xf so that the option roms aren't writable. I wonder if that is confusing qemm when it tries to locate the ebda into that area. -Kevin
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
Kevin O'Connor wrote: On Tue, Apr 13, 2010 at 02:26:10PM +0800, Roy Tam wrote: 2010/4/12 Gerhard Wiesinger : 3.) There is also a problem with the reported base memory under QEMM386 (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. Therefore base memory test fails. I guess that reporting memory CMOS tables/interrupt functions are not implemented correctly. - The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1) will just freeze after QEMU counted RAM.(Tested with ScriptPC and Bochs). The SeaBIOS log would really help. This can be done by adding: -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios to the qemu command line. The memory can be obtained in several places (int 12, int 1588, int 15e801, int 15e820, and mem 40:13). All look fine to me from looking at the code. OK, I made some research on the topic. Problem is that QEMM pushes the Extended BIOS data area to High RAM on some machines (QEMU, P733). Therefore 640k low memory is available and checkit reports 640kB + 6kB=646kB EBIOS DATA AREA. Whats strange that on a physical Pentium 733 machine this works correctly (details see below and attached files), maybe someone can try to find the problem with QEMM+Checkit 3.0 (maybe there is still some other BIOS function incorrectly implemented). QEMM parameter NOXBDA avoids moving the XBDA up to HI RAM and therefore checkit reports 640kB well. SeaBIOS seems to be correct (see below and attached patch files and description below). Total Memory: 256MB (262144kB), Base RAM: 637kB Extended BIOS Data Area size: 3 kB, segment=9f40 SCSI option ROM: After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB Extended BIOS Data Area size: 6 kB, segment=9e80 *MS-DOS 6.22, QEMM 8.03* *QEMU* *Testcase* *BDA* *40h:13h* *INT* *12h* *INT 15h,* *AX=E820h* *EBIOS* *DATAAREA* *Checkit* *3.0* Plain DOS, after Boot 634kB 634kB 634kB 9E80h-A000h (6k) 640kB HIMEM.SYS+EMM386.EXE 634kB 634kB 634kB 9E80h-A000h (6k) 640kB QEMM 640kB 640kB 634kB CEB5h-D035h (6k) 646kB QEMURAMD + QEMM 628kB 628kB 634kB 9E80h-A000h (6k) 634k *VMWare* *Testcase* *BDA* *40h:13h* *INT* *12h* *INT 15h,* *AX=E820h* *EBIOS* *DATAAREA* *Checkit 3.0* Plain DOS, after Boot 638kB 638kB 638kB 9F80h-A000h (2k) 640kB HIMEM.SYS+EMM386.EXE 638kB 638kB 638kB 9F80h-A000h (2k) 640kB QEMM 638kB 638kB 638kB 9F80h-A000h (2k) 640kB QEMURAMD + QEMM 632kB 632kB 632kB 9F80h-A000h (2k) 634kB *Pentium 733* *Testcase* *BDA* *40h:13h* *INT* *12h* *INT 15h,* *AX=E820h* *EBIOS* *DATAAREA* *Checkit 3.0* Plain DOS, after Boot 639kB 639kB 639kB 9FC0h-A000h (1k) 640kB QEMM 640B 640kB 639kB D1B5h- (1k) 640kB Attached documents: MEQEMU.TXT QEMU, no CONFIG.SYS/AUTOEXEC.BAT MEQEMUH.TXT QEMU, HIMEM.SYS, EMM386.EXE MEQEMUQ1.TXT QEMU, QEMM386.EXE, NOXBDA parameter MEQEMUQ2.TXT QEMU, QEMM386.EXE MEVMW.TXT VMWare, no CONFIG.SYS/AUTOEXEC.BAT MEVMWH.TXT VMWare, HIMEM.SYS, EMM386.EXE MEVMWQ.TXT QEMU, QEMM386.EXE (XBDA not moved to HMA!?!) P733.TXT, Pentium 733, no CONFIG.SYS/AUTOEXEC.BAT P733Q.TXT Pentium 733, QEMM386.EXE Code and Patches can be found at (released under GPL V2): http://www.wiesinger.com/opensource/seabios/meminfoa.asm http://www.wiesinger.com/opensource/seabios/meminfo.c http://www.wiesinger.com/opensource/seabios/meminfo.exe http://www.wiesinger.com/opensource/seabios/seabios-0.6.0-gw-V01.patch QEMURAMD: DOS Device driver, which modifies BDA reported memory by -6kB, released later. Build script will be released under my DOS-Tools soon (some cleanup necessary). Ciao, Gerhard Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger BIOS area 40h:13h=640, 640kB INT 12h: AX=640, 640kB INT 15h, AH=88h AX=0, number of continuous kB starting at absolute address 10h: 0kB INT 15h, AX=E801h AX=15360, extended memory between 1M and 16M: 15360kB BX=3840, extended memory above 16M, in 64K blocks: 245760kB CX=15360, configured memory between 1M and 16M: 15360kB DX=3840, configured memory above 16M, in 64K blocks: 245760kB INT 15h, AX=E820h structure len=20 base address 0h (0) length in bytes 9E800h (649216), 634kB type of address range: memory type=1 type of addres
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
On Tue, Apr 13, 2010 at 02:26:10PM +0800, Roy Tam wrote: > 2010/4/12 Gerhard Wiesinger : > > 3.) There is also a problem with the reported base memory under QEMM386 > > (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. > > Therefore base memory test fails. I guess that reporting memory CMOS > > tables/interrupt functions are not implemented correctly. > > - The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs > BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1) > will just freeze after QEMU counted RAM.(Tested with ScriptPC and > Bochs). The SeaBIOS log would really help. This can be done by adding: -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios to the qemu command line. The memory can be obtained in several places (int 12, int 1588, int 15e801, int 15e820, and mem 40:13). All look fine to me from looking at the code. -Kevin
Re: [Qemu-devel] QEMU regression problems
2010/4/12 Gerhard Wiesinger : > Hello, > > Checkit reports some problems under DOS: > 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. > Seems to be a problem of the instruction set. > 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the > KVM problem, see my previous post). Seems to be that real-time clock is not > working correct. > 3.) There is also a problem with the reported base memory under QEMM386 > (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. > Therefore base memory test fails. I guess that reporting memory CMOS > tables/interrupt functions are not implemented correctly. > > Details are listed below. > > All issues are NOT present under VMWare Server 2.0 and with real hardware. > > QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II > Quad Core, x86_64-softmmu. > > Any comments? > Tested with Checkit 3.0 and QEMM 9.0. - The NPU error is confirmed and it seems to be a floating point rounding error in QEMU. This should be a 0.12 regression as it works in 0.11.1 and 0.10.6. - The RTC Alarm failure is confirmed too. Is it unimplemented in QEMU? - The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1) will just freeze after QEMU counted RAM.(Tested with ScriptPC and Bochs). > Thnx. > > Ciao, > Gerhard > > -- > http://www.wiesinger.com/ > > Details: > 1.) >NPU Trigonometric Functions.FAILED *** >Step 1, Expected0.42926, received0.42926 > > Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h). > Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h). > Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h). > > 2.) > Compare Current TimePassed >DOS: 16:24:39.89Real-Time Clock: 16:24:39.00 (.89 apart) > > Compare Current DatePassed >DOS: 04/11/2010 Real-Time Clock: 04/11/2010. > > Real-Time Clock Alarm...FAILED *** > > Compare Elapsed TimePassed >DOS: 11.97 Seconds Real-Time Clock: 12.00 Seconds (.03 apart) > > 3.) Known Memory: >Base646K From 0K to646K (000h to 00A17FFh) >Base Memory.FAILED *** >ERROR at Address 0Ah, Bits FEDCBA9876543210 >ERROR at Address 0A0004h, Bits FEDCBA9876543210 >ERROR at Address 0A0006h, Bits FEDCBA9876543210 >ERROR at Address 0A0008h, Bits FEDCBA9876543210 >ERROR at Address 0A000Ah, Bits FEDCBA9876543210 >ERROR at Address 0A000Ch, Bits FEDCBA9876543210 >ERROR at Address 0A000Eh, Bits FEDCBA9876543210 >ERROR at Address 0A0010h, Bits FEDCBA9876543210 >ERROR at Address 0A0012h, Bits FEDCBA9876543210 >ERROR at Address 0A0014h, Bits FEDCBA9876543210 >ERROR at Address 0A0016h, Bits FEDCBA9876543210 >ERROR at Address 0A0018h, Bits FEDCBA9876543210 >ERROR at Address 0A001Ah, Bits FEDCBA9876543210 >ERROR at Address 0A001Ch, Bits FEDCBA9876543210 >ERROR at Address 0A001Eh, Bits FEDCBA9876543210 >ERROR at Address 0A0020h, Bits FEDCBA9876543210 >ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE. > > >
[Qemu-devel] QEMU regression problems
Hello, Checkit reports some problems under DOS: 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. Seems to be a problem of the instruction set. 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the KVM problem, see my previous post). Seems to be that real-time clock is not working correct. 3.) There is also a problem with the reported base memory under QEMM386 (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. Therefore base memory test fails. I guess that reporting memory CMOS tables/interrupt functions are not implemented correctly. Details are listed below. All issues are NOT present under VMWare Server 2.0 and with real hardware. QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II Quad Core, x86_64-softmmu. Any comments? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/ Details: 1.) NPU Trigonometric Functions.FAILED *** Step 1, Expected0.42926, received0.42926 Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h). Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h). Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h). 2.) Compare Current TimePassed DOS: 16:24:39.89Real-Time Clock: 16:24:39.00 (.89 apart) Compare Current DatePassed DOS: 04/11/2010 Real-Time Clock: 04/11/2010. Real-Time Clock Alarm...FAILED *** Compare Elapsed TimePassed DOS: 11.97 Seconds Real-Time Clock: 12.00 Seconds (.03 apart) 3.) Known Memory: Base646K From 0K to646K (000h to 00A17FFh) Base Memory.FAILED *** ERROR at Address 0Ah, Bits FEDCBA9876543210 ERROR at Address 0A0004h, Bits FEDCBA9876543210 ERROR at Address 0A0006h, Bits FEDCBA9876543210 ERROR at Address 0A0008h, Bits FEDCBA9876543210 ERROR at Address 0A000Ah, Bits FEDCBA9876543210 ERROR at Address 0A000Ch, Bits FEDCBA9876543210 ERROR at Address 0A000Eh, Bits FEDCBA9876543210 ERROR at Address 0A0010h, Bits FEDCBA9876543210 ERROR at Address 0A0012h, Bits FEDCBA9876543210 ERROR at Address 0A0014h, Bits FEDCBA9876543210 ERROR at Address 0A0016h, Bits FEDCBA9876543210 ERROR at Address 0A0018h, Bits FEDCBA9876543210 ERROR at Address 0A001Ah, Bits FEDCBA9876543210 ERROR at Address 0A001Ch, Bits FEDCBA9876543210 ERROR at Address 0A001Eh, Bits FEDCBA9876543210 ERROR at Address 0A0020h, Bits FEDCBA9876543210 ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.
