PXA255 QEM FYI
M. Warner Losh
imp at bsdimp.com
Thu Mar 19 09:46:46 PDT 2009
In message: <200903191411.n2JEBrCY099265 at casselton.net>
Mark Tinguely <tinguely at casselton.net> writes:
: This is just a FYI for those wanting to use QEMU with the PXA255.
: 1) The uart is not discovered causing a hang after the line:
: warning: no time-of-day clock registered, system time will not be set accurately
: I had this problem in qemu 0.9.1 and 0.10.0_1. This problem was keeping
: the NFS diskless and MD based kernels to even get to single user.
: In FreeBSD, sys/arm/xscale/pxa/uart_bus_pxa.c in uart_pxa_probe(), a
: check is made to make sure the port is enabled. QEM does not enable that
: bit. It appears that Linux does not check for the bit.
: A simple work around in FreeBSD would something like:
: static int
: uart_pxa_probe(device_t dev)
: bus_space_handle_t base;
: struct uart_softc *sc;
: +#ifdef QEMU
: + base = (bus_space_handle_t)pxa_get_base(dev);
: + if (0x40100000 != (unsigned int) base)
: + return (ENXIO);
: /* Check to see if the enable bit's on. */
: if ((bus_space_read_4(obio_tag, base,
: (REG_IER << 2)) & PXA_UART_UUE) == 0)
: return (ENXIO);
: sc = device_get_softc(dev);
: sc->sc_class = &uart_ns8250_class;
: return(uart_bus_probe(dev, 2, PXA2X0_COM_FREQ, 0, 0));
Should the PXA emulation be fixed in qemu?
: 2) the new QEMU (qemu-0.10.0_1) compile under FreeBSD-8.0-current, incorrect
: brings a register value from the ARM enviroment to the QEMU SMC emulation
: evironment and QEMU crashes with a message:
: qemu: fatal: smc91c111_read: Bad reg 0:30e
: R00=00000000 R01=c5e1f300 R02=0000000e R03=c0a778e0
: R04=c0ba8300 R05=c0baab00 R06=00000003 R07=00000001
: R08=00000000 R09=00000000 R10=c0bb4540 R11=c00fbc50
: R12=c00fbc54 R13=c00fbc44 R14=c0403950 R15=c03e8bac
: PSR=a0000113 N-C- A svc32
: Notice register 2 has the correct value of 0x0e.
: Compiled under FreeBSD 6.4, the emulator runs fine. I will mention this
: to the QEMU people; it may be a difference in gcc3 vs gcc4. A temporary
: work around in QEMU might be a mask (0xff) of the offset variable in
: smc91c111_readb (and smc91c111_writeb ?) or removal of the ethernet card
: from the kernel configuration.
Hmmm... That's a good question... I'd talk with them, since stuff
like that shouldn't be needed.
: A big THANK-YOU to Jacques Fourie for holding my hand to get these problems
Indeed! Thanks for letting us know. We should work out the kinks and
create a wiki page with these details...
More information about the freebsd-arm