I'm opening up this discussion, which was formerly just between the folks actively doing freebios2. We're getting closer to having things working and I am happy to hear any comments.
linuxbios.a now builds for the K8 with the new config tool. Not all of linuxbios, just linuxbios.a, but that's quite a way to working.
Things are stricter now. We've been able to operate before with code like this:
#if SOME_VARIABLE_THAT_WAS_UNDEFINED == 0 stuff #endif
because in the GNU C preprocessor, #if (a == 0) and #ifndef a
are equivalent if a is undefined.
I think that is a very poor way to operate: it can fool people, and in a BIOS you want more checking.
Now that you can use an 'if' operator in the config language, setting up some things is a lot easier:
For example, this: expr ROM_SECTION_SIZE =(USE_FALLBACK_IMAGE*65536)+(USE_NORMAL_IMAGE*(ROM_SIZE - 65536))
expr ROM_SECTION_OFFSET=(USE_FALLBACK_IMAGE*(ROM_SIZE-65536))+(USE_NORMAL_IMAGE *0)
now becomes this: default FALLBACK_SIZE=65536 if USE_FALLBACK_IMAGE option ROM_SECTION_SIZE = FALLBACK_SIZE option ROM_SECTION_OFFSET= (ROM_SIZE - FALLBACK_SIZE) end if USE_NORMAL_IMAGE option ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) option ROM_SECTION_OFFSET= 0 end
Much better. However, if you have not defined USE_FALLBACK_IMAGE or USE_NORMAL_IMAGE, then you're going to get an error, which in the past was not the case.
So we'll have to learn to be a bit more careful about defining things before they are used, and not using things that were never defined. This is all proving to be easy, but people will need to take more care with the Config files (which, in deference to Windows and MacOS, are now named Config.lb).
ron
Anyone have any idea why writing to PCI config space while in the middle of the Bochs BIOS with ADLO is running would cause lockups?
Our board has 2 video chips on the PCI bus and for Xwindows to be able to use the head I have to init it from the bios. X (even 4.3) has issues with our setup because there is only one copy of the video bios for both chips and I haven't been able to make X go look for the bios in the right location. Plus I need the head to come up early for field service reasons.
The way we did this under our old COTS bios kit was
enable IO on head 1 call vga bios disable io on head 1 enable io on head 2 call vga bios disable io on head 2 enable IO on head 1
Then all is well with X.
I found the vido init part of ADLO/Bochs and ported the PCI_[WRITE:READ]_CONFIG_DWORD macro from linuxbios but when I call it the system hangs. Currently I'm down to just re-writing the IO bit in the config register of the already active head and it still hangs.
Perhaps I don't have my device IDs correct? Can someone verify that if I want to read and write to the PCI command register and lspci lists my 2 video heads as 0:12.0 and 0:14.0 that the corresponding values I should load into eax before calling the macros are:
12.0 0x9010 14.0 0xa010
Other than that is there prehaps some freaky 16bit real mode issue thats busting me?
Richard Smith wrote:
Anyone have any idea why writing to PCI config space while in the middle of the Bochs BIOS with ADLO is running would cause lockups?
Ok.. Some new info. Turns out it dosen't have anything to do with PCI config space at all. Its position dependant.
I can duplicate my problem with a macro of all mov instructions.
Depending on how many instructions over 6 I add into the Bochs bios file (in the vga init section) it will either hang or tell me that an NMI has been called when it calls _print_bios_banner.
Any ideas? It seems unlikely that the bochs stuff would be that fragile so I must be missing something.
On Mon, 9 Jun 2003, Richard Smith wrote:
Any ideas? It seems unlikely that the bochs stuff would be that fragile so I must be missing something.
It is :/
turn off some deubgging stuff. it helps keep code smaller.
I suspect it is b/c of those legacy bios entry points embedded into the bios code. they have fixed address. Perhaps it is some problem with BCC.