* Ronald G Minnich <[EMAIL PROTECTED]> [020417 00:33]:
> yes, just get rid of that call to the X86EMU_trace_on(); before the Exec.
ah. cool, thanks.
> No int1x support yet. I can use the help. Help Stefan!
i stripped down inthandler.c so testbios branches into the
specific intXX_handler function. This works fine, but leads
to the next problem, which has already been discussed on this list.
Which is the way to be approached for accessing PCI registers
from intXX functions?
* In Linux user space I'd probably do it via ioctl()s.
* When linking it right into LinuxBIOS payload, we save the need
for a running kernel and we're able to use vgabios in a very early
stage. Drawback: currently about 180k is not really what you want
in your lowlevel machine setup. Advantage: We can use LinuxBIOS'
PCI functions.
* When using vgabios as an elf payload 'plugin' we have this nice
and seperated, which seems like a good approach to keep the
LinuxBIOS code itself less bloated. But we have to use another set
of PCI access functions there.
Has anyone played with loading several elf payloads in a row?
a small library of functions, thus printf, string functions plus
pci functions might be interesting because "highlevel" mainboard
fixup like enabling/disabling devices could be packed into a seperate
payload as well. Several motherboards using the same chipset could
boot using the same lowlevel code but having their device init
seperated. Does this sound stupid?
Best regards,
Stefan Reinauer
--
Ok hex 4666 dup negate do i 4000 dup 2* negate do " *" 0 dup 2dup 1e 0 do
2swap * e >>a 2* 5 pick + -rot - j + dup dup * e >>a rot dup dup * e >>a
rot swap 2dup + 10000 > if 3drop 3drop " " 0 dup 2dup leave then loop
2drop 2drop type 268 +loop cr drop 5de +loop
