The SeaBIOS git repo can now be accessed via:
git clone git://git.seabios.org/seabios.git
This is a separate repo from the one located on the linuxtogo.org
site. I will maintain the two repos for the next couple of months,
but will eventually stop updating the linuxtogo one.
The new repo should be faster and much more responsive.
This new site (along with the wiki and mail list) is hosted by
Coresystems GmbH. Many thanks!
After some fortune I found out that also Turbo Debugger 286 doesn't work
under plain DOS 6.22 (without any memory mananger just pressing F5) or
with some memory mananagers (HIMEM.SYS, EMM386, QEMM386).
Error message is:
Error 266 loading D:\DIR\TD286.EXE into extended memory.
So it looks like that there is a major issue with extended memory. Any
ideas how to fix or how to find the problem and fix it?
Version is latest seabios and QEMU from git as of now (own builds).
I'm pretty sure that it is the same reason that the 286 DOS Extender
application doesn't work.
For full reference of the previously discussed have a look here:
On Wed, 14 Apr 2010, Jan Kiszka wrote:
> Jamie Lokier wrote:
>> Gerhard Wiesinger wrote:
>>> It is a non public, proprietary application which uses the Ergo Computing
>>> 286 DOS Extender. I guess some other application which use the same DOS
>>> extender have the same problem. So best thing is to find another
>>> application which uses the Ergo Computing 286 DOS Extender, too.
>> The 286 was obsolete 20 years ago, although code depending on it
>> persisted for some years after.
>> I'm fairly sure the number of people using (or trying to use) Qemu
>> with 286-specific code is very small indeed, so unfortunately for a
>> 286 problem, you will need to help reproduce it as much as you can for
>> it to be fixed.
> In some scenarios, we use QEMU in emulation mode for such a legacy guest
> (16-bit protected mode), but we mostly run it in KVM mode these days. It
> works fairly well under QEMU, but also we did not explore all corner cases.
>> Note that Qemu doesn't emulate segments properly even for 32-bit x86
>> code, and 16-bit (286) code depends on that all the more. That may be
>> the problem.
> More precisely: QEMU does not check for segment limits. This can be a
> problem with buggy or pedantic guests, but usually one tried to avoid
> triggering this anyway. I once wrote a crude patch to add this, but it
> had significant performance impact and did not properly make use of the
> TCG to optimize the checks. You'll find it in the archives (but I guess
> it no longer applies).
>> Or it may be the "reset using keyboard controller and BIOS" method
>> used to switch from protected mode to real mode on a 286 is not
>> implemented properly, or is not supported by the BIOS properly.
>> Or it may simply be a bug in 16-bit task segment switching or
>> something like that, which is quite complex and so rarely used that it
>> might never have been properly tested.
> Task switching looks fairly stable in QEMU (in contrast to KVM where we
> just ran into some more corner cases).
>> Did you try running the application under Bochs, which has a more
>> accurate emulation of very old x86 CPUs?
>> -- Jamie
> That said, having some test case to reproduce the issue is essential.
> I'm willing to have a look if you can provide such thing (publicly or
> privately). Before that, you could already try building QEMU with
> --enable-debug and run it with "-d exec,int". The generated
> /tmp/qemu.log may point out where things go wrong (usually where faults
> starts to occur).
I am working on QEMU to pass-through a graphics device. I noticed few
problems with PCI enumeration hence I compiled SeaBIOS with more debug
The PCI enumeration problem seems to be related to BUILS_PCIMEM_SIZE. I keep
on getting the error 'increase BUILD_PCIMEM_SIZE and recompile'. This
happens when BIOS tries to allocate 128MB for one of the BAR. The code seems
to be printing the correct error as, the 128MB naturally aligned memory
request can not be satisfied. No problem with this.
As I notice on my host machine the same case happens, but host BIOS seems to
be allocating 128MB memory from some other region (c0000000-c7ffffff)
02:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B64 [FireGL
V3100 (PCIE)] (rev 80) (prog-if 00 [VGA controller])
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at a000 [size=256]
Region 2: Memory at f9cf0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at f9cc0000 [disabled] [size=128K]
prasad@prasad-kvm:~$ grep '0000:02' /proc/iomem
c0000000-c7ffffff : PCI Bus 0000:02
c0000000-c7ffffff : 0000:02:00.0
f9c00000-f9cfffff : PCI Bus 0000:02
f9cc0000-f9cdffff : 0000:02:00.0
f9ce0000-f9ceffff : 0000:02:00.1
f9cf0000-f9cfffff : 0000:02:00.0
Can SeaBIOS do the same thing? or to put in other words Can SeaBIOS allocate
memory from some other region instead of fixed f0000000 to (0xfec00000-1)?
Thanks and Regards,
I'm Initializing the Local and IO APIC for a propeitary operating
system running in Virtualized Environment .
Im facing some problem with qemu-kvm but the code runs fine with qemu.
when i run my kernel image with qemu-kvm it gives emulation error failure
trying to execute the code outside ROM or RAM at fec00000(IO APIC base address)
but the same code runs fine with qemu. can anyone please point me
where might be the problem or how to find out this one?