diff mbox

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

Message ID 20120510004445.GA19059@morn.localdomain
State New
Headers show

Commit Message

Kevin O'Connor May 10, 2012, 12:44 a.m. UTC 
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:


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

Comments

Kevin O'Connor May 10, 2012, 1:19 a.m. UTC | #1 
On Wed, May 09, 2012 at 08:44:45PM -0400, Kevin O'Connor wrote:
> On Wed, May 09, 2012 at 08:57:53AM -0700, Alain Ribière wrote:
> > 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
[...]

Just for kicks, I tried a simple hack to try and reserve more memory
in the c/d/e-segments, and it seems to work for the image you posted.
Run:

python -c 'import sys; sys.stdout.write("\x55\xaa\xc8\xcb\x6e" + "\x00"*(100*1024 - 5))' > dummy.rom

and then add "-option-rom dummy.rom" to your qemu command line.  (The
idea is to build a 100K dummy option rom that seabios will load and
mark as read-only memory.)

-Kevin
Alain Ribière May 10, 2012, 1:56 p.m. UTC | #2 
Both solutions work for my application !
Thanks a lot. I think I will use one of them, even if I know it's not really "clean".

Thanks again,

Alain
diff mbox

Patch

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;