PXA255 QEM FYI

[M. Warner Losh]

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);
: +#else
: 	/* 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);
: +#endif
: 
: 	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
: resolved.

Indeed!  Thanks for letting us know.  We should work out the kinks and
create a wiki page with these details...

Warner