<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Tanks for your answer.<br></span></div><div><br></div><div>I have to apologize, I made a mistake. I rechecked my application and used git bisect.</div><div>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 :</div><div><br></div><div>49669fc551e0ccd2310a9584a9b7343a0bcae477 is the first bad commit<br>commit 49669fc551e0ccd2310a9584a9b7343a0bcae477<br>Author: Glauber Costa <glommer@redhat.com><br>Date: Thu Apr 23 15:20:55 2009 -0400<br><br> suport device driver initialization model<br> <br> According to PnP specification, Appendix B, Option ROMs<br> that support DDIM (device driver initialization model) should<br> have their memory space
writeable.<br> <br> KVM deviates from us here, by removing the IO_MEM_ROM flag,<br> to allow for PCI option ROMs (they require DDIM). However,<br> there's absolutely no reason we can't do the same.<br> <br> Signed-off-by: Glauber Costa <glommer@redhat.com><br> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com><br><br>:040000 040000 5186361da34236c2680af6ed568b5f5bdb2915ac c968308168e23ffa2678011ed2ff010389b528bd M hw</div><div><br></div><div>diff --git a/hw/pc.c b/hw/pc.c<br>index 61f6e7b..340b313 100644<br>--- a/hw/pc.c<br>+++ b/hw/pc.c<br>@@ -920,7 +920,8 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,<br> <br> option_rom_offset = qemu_ram_alloc(0x20000);<br> oprom_area_size = 0;<br>-
cpu_register_physical_memory(0xc0000, 0x20000, option_rom_offset);<br>+ cpu_register_physical_memory(0xc0000, 0x20000,<br>+ option_rom_offset | IO_MEM_ROM);<br> <br> if (using_vga) {<br> /* VGA BIOS load */<br></div><div><br></div><div>Also I found the theorical memory map of the C-DOS in the documentation of my legacy application :</div><div>start<span class="tab"> </span><span class="tab"> </span><span class="tab">end<br></span></div><div>000000<span class="tab"> 9FFFF</span><span class="tab"> Program area<br></span></div><div><span class="tab">0A0000</span><span class="tab">
0BFFFF</span><span class="tab"> Video memory<br></span></div><div><span class="tab">0C00000</span><span class="tab"> 0C7FFF</span><span class="tab"> BIOS graphic card</span></div><div><span class="tab">0C8000</span><span class="tab"> 0CBFFF</span><span class="tab"> BIOS cache controller</span></div><div><span class="tab">0CC000</span><span class="tab"> 0CFFFF</span><span class="tab"> BIOS removable disk</span></div><div><span class="tab">0D0000</span><span class="tab"> 0D3FFF</span><span class="tab"> BIOS network adapter</span></div><div><span class="tab">0D4000</span><span class="tab"> 0EFFFF</span><span class="tab"> CDOS system</span></div><div><span class="tab">0F0000</span><span class="tab"> 0FFFFF</span><span
class="tab"> ROM BIOS</span></div><div><br><span class="tab"></span></div><div><span class="tab">I wonder what is the CDOS system at 0D4000... It seems a bit strange.<br></span></div><div><br></div><div>I do not understand why this commit affects the C-DOS memory allocation.</div><div>But you're probably right, C-DOS is using memory addresses he shouldn't for it's own purpose causing conflicts...<br><span class="tab"></span></div><div><span class="tab">If you have any idea.<br></span></div><div><br><span class="tab"></span></div><div><span class="tab">Thanks, and sorry again for the wrong issue (I will remove the SeaBIOS mailing list in the future mails)...<br></span></div><div><br></div><div>Alain<br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr
size="1"><b><span style="font-weight:bold;"></span></b></font><br></div>On Tue, May 08, 2012 at 09:47:56AM -0700, Alain Ribière wrote:<br>> Thanks for your answer.<br>> <br>> Here is the debug log in attachement.<br>> I disabled the debug on the screen shot I sent because I noticed I could get a bit more memory without it.<br>> With the debug on, I got :<br>> Banked Window 416K at 3800:0 segment<br>> and a free memory of 15680K<br>> <br>> I'll try to find what confuses C-DOS. It reacts a bit strangely... <br>> When I add or remove options from the SeaBIOS, the memory avalaible <br>> change and the size of banked window changes too. So I hoped there was a way to have enough memory to run my application...<br><br>The options don't impact SeaBIOS' memory usage, so this reafirms my<br>guess that what you are seeing is a secondary effect. As a guess,<br>this could be stack usage - some old program call the bios
with very<br>small stacks and if the stack overflows silent corruption can occur.<br>The fact that you're seeing different memory layouts with random<br>changes to config options could be due to different options causing<br>the compiler to layout the stack slightly differently and thus causing<br>slightly different corruption - just a guess.<br><br>The other thing I noticed with your C-DOS image is that it doesn't<br>know about the EBDA and uses that memory for its own purposes. Thus,<br>the seabios runtime usage of the ebda along with c-dos could cause<br>conflicts. I don't think this is the cause of your current issue<br>though as some moving the ebda in some quick tests I ran doesn't seem<br>to impact the output of "stop".<br><br>> Otherwise, I will have to stuck with Qemu 0.11 and PC-BIOS.<br>> <br>> Do you know if there is any DOS utility to get the memory map ?<br><br>I'm not familiar with DOS utilities. You could ask on
the freedos<br>mailing list.<br><br>-Kevin<br><br><br> </div> </div> </div></body></html>