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
Author: Glauber Costa <glom...@redhat.com>
Date: Thu Apr 23 15:20:55 2009 -0400
suport device driver initialization model
According to PnP specification, Appendix B, Option ROMs
that support DDIM (device driver initialization model) should
have their memory space writeable.
KVM deviates from us here, by removing the IO_MEM_ROM flag,
to allow for PCI option ROMs (they require DDIM). However,
there's absolutely no reason we can't do the same.
Signed-off-by: Glauber Costa <glom...@redhat.com>
Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>
:040000 040000 5186361da34236c2680af6ed568b5f5bdb2915ac
c968308168e23ffa2678011ed2ff010389b528bd M hw
diff --git a/hw/pc.c b/hw/pc.c
index 61f6e7b..340b313 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -920,7 +920,8 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
option_rom_offset = qemu_ram_alloc(0x20000);
oprom_area_size = 0;
- cpu_register_physical_memory(0xc0000, 0x20000, option_rom_offset);
+ cpu_register_physical_memory(0xc0000, 0x20000,
+ option_rom_offset | IO_MEM_ROM);
if (using_vga) {
/* VGA BIOS load */
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.
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)...
Alain
________________________________
On Tue, May 08, 2012 at 09:47:56AM -0700, Alain Ribière wrote:
> Thanks for your answer.
>
> Here is the debug log in attachement.
> I disabled the debug on the screen shot I sent because I noticed I could get
> a bit more memory without it.
> With the debug on, I got :
> Banked Window 416K at 3800:0 segment
> and a free memory of 15680K
>
> I'll try to find what confuses C-DOS. It reacts a bit strangely...
> When I add or remove options from the SeaBIOS, the memory avalaible
> change and the size of banked window changes too. So I hoped there was a way
> to have enough memory to run my application...
The options don't impact SeaBIOS' memory usage, so this reafirms my
guess that what you are seeing is a secondary effect. As a guess,
this could be stack usage - some old program call the bios with very
small stacks and if the stack overflows silent corruption can occur.
The fact that you're seeing different memory layouts with random
changes to config options could be due to different options causing
the compiler to layout the stack slightly differently and thus causing
slightly different corruption - just a guess.
The other thing I noticed with your C-DOS image is that it doesn't
know about the EBDA and uses that memory for its own purposes. Thus,
the seabios runtime usage of the ebda along with c-dos could cause
conflicts. I don't think this is the cause of your current issue
though as some moving the ebda in some quick tests I ran doesn't seem
to impact the output of "stop".
> Otherwise, I will have to stuck with Qemu 0.11 and PC-BIOS.
>
> Do you know if there is any DOS utility to get the memory map ?
I'm not familiar with DOS utilities. You could ask on the freedos
mailing list.
-Kevin_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
