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