qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re : Re : [SeaBIOS] : Memory problem with Qemu/SeaBIOS


From: Kevin O'Connor
Subject: Re: [Qemu-devel] Re : Re : [SeaBIOS] : Memory problem with Qemu/SeaBIOS
Date: Wed, 9 May 2012 20:44:45 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, May 09, 2012 at 08:57:53AM -0700, Alain Ribière wrote:
> Tanks for your answer.
> 
> 
> I have to apologize, I made a mistake. I rechecked my application and used 
> git bisect.
> So I found that this is not a SeaBIOS issue (actually it's more a C-DOS 
> issues...). My problem comes from this Qemu commit :
> 
> 49669fc551e0ccd2310a9584a9b7343a0bcae477 is the first bad commit
> commit 49669fc551e0ccd2310a9584a9b7343a0bcae477
[...]
> 
> Also I found the theorical memory map of the C-DOS in the documentation of my 
> legacy application :
> start         end
> 
> 000000    9FFFF    Program area
> 
> 0A0000    0BFFFF    Video memory
> 
> 0C00000    0C7FFF    BIOS graphic card
> 0C8000    0CBFFF    BIOS cache controller
> 0CC000    0CFFFF    BIOS removable disk
> 0D0000    0D3FFF    BIOS network adapter
> 0D4000    0EFFFF    CDOS system
> 0F0000    0FFFFF    ROM BIOS
> 
> I wonder what is the CDOS system at 0D4000... It seems a bit strange.

Very odd.  This is still controlled by seabios.  Indeed, if I apply
this (clearly incorrect) patch to seabios:

diff --git a/src/shadow.c b/src/shadow.c
index c0c8cc2..73c0670 100644
--- a/src/shadow.c
+++ b/src/shadow.c
@@ -83,7 +83,7 @@ make_bios_readonly_intel(u16 bdf, u32 pam0)
     for (i=0; i<6; i++) {
         u32 mem = BUILD_ROM_START + i * 32*1024;
         u32 pam = pam0 + 1 + i;
-        if (RomEnd <= mem + 16*1024) {
+        if (0 && RomEnd <= mem + 16*1024) {
             if (RomEnd > mem)
                 pci_config_writeb(bdf, pam, 0x31);
             break;

Then the C-DOS image you posted seems happier.  Basically, if C-DOS is
allowed to write to the e-segment then it seems to do weird things.

> 
> I do not understand why this commit affects the C-DOS memory allocation.
> But you're probably right, C-DOS is using memory addresses he shouldn't for 
> it's own purpose causing conflicts...
> 
> If you have any idea.
> 
> 
> Thanks, and sorry again for the wrong issue (I will remove the SeaBIOS 
> mailing list in the future mails)...
> 

This is still in the SeaBIOS realm.  (Though I'm thinking it's really
a C-DOS bug.)

-Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]