[Qemu-devel] QEMU ARM PXA on FreeBSD issues

[Qemu-devel] QEMU ARM PXA on FreeBSD issues

[Mark Tinguely]

There are a couple qemu-system-arm issues on the PXA under the OS FreeBSD.
I told the freebsd-arm mailling list that I would bring these issues to
the qemu developers attention.

1) The uart is not discovered (I seen this on qemu 0.9.x and on 0.10.0).

  FreeBSD uses the UART Unit Enable bit on the Interrupt Enable Register
  in the UART probe to determine if a UART is active. Unlike hardware, qemu
  does not raise this bit, and the Full Function UART at 0x40100000 is not
  being enabled. It appears that NetBSD and Linux do not check the status
  of the UUE to active a UART.

  It would be nice for FreeBSD, if the UART Unit Enable (UUE) bit is
  raised on the UARTs that qemu activate.

2) qemu 0.10.0 on FreeBSD 8.0-current passes the wrong value of "offset" to the 
   qemu routine smc91c111_readb() in hw/smc91c111.c. This routine works fine
   under FreeBSD 6.4.

    The FreeBSD 8-current error message is:

 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.

This routine worked fine under qemu 0.9.x compiled under FreeBSD 8-current.
I thought this was caused by FreeBSD 8-current gcc version 4.2.1 20070719
compiler, but this also happens on FreeBSD 8-current when compiling the
code with gcc version 3.6.4 and gcc version 3.4.1.

A temporary solution is to run qemu under FreeBSD 6.4, or FreeBSD 8-current
users can mask the offset before use:

static uint32_t smc91c111_readb(void *opaque, target_phys_addr_t offset)
{
    smc91c111_state *s = (smc91c111_state *)opaque;

+    offset = offset & 0xff;
    if (offset == 14) {
        return s->bank;
    }
    if (offset == 15)
        return 0x33;
    switch (s->bank) {

Thank-you.

--Mark Tinguely

Re: [Qemu-devel] QEMU ARM PXA on FreeBSD issues

[Thorsten Zitterell]

Mark Tinguely wrote:
> 2) qemu 0.10.0 on FreeBSD 8.0-current passes the wrong value of "offset" to the 
>    qemu routine smc91c111_readb() in hw/smc91c111.c. This routine works fine
>    under FreeBSD 6.4.
> 
>     The FreeBSD 8-current error message is:
> 
>  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.
> 
> This routine worked fine under qemu 0.9.x compiled under FreeBSD 8-current.
> I thought this was caused by FreeBSD 8-current gcc version 4.2.1 20070719
> compiler, but this also happens on FreeBSD 8-current when compiling the
> code with gcc version 3.6.4 and gcc version 3.4.1.

Hi. I can reproduce this problem when accessing the NIC from a Gumstix connex 
(pxa255) system with disabled MMU.

0xa3f07fdc:  strh       r5, [r4, #14]
0xa3f07fe0:  bl 0xa3f00f5c

qemu: fatal: smc91c111_write: Bad reg 0:30e

R00=a3ee01f0 R01=a3edefb8 R02=00000001 R03=00008000
R04=04000300 R05=00000000 R06=a3edefb8 R07=a3edefb8
R08=a3edefdc R09=a3ee0230 R10=a3ee01f0 R11=00000000
R12=a3f27488 R13=a3edec34 R14=a3f04148 R15=a3f07fac
PSR=600001d3 -ZC- A svc32

The NIC is registered at 0x04000300.

hw/gumstix.c:74:

     smc91c111_init(&nd_table[0], 0x04000300,
                     pxa2xx_gpio_in_get(cpu->gpio)[99]);

Then, the IO memory is initialized by the following lines

hw/smc91c111.c:709:

     s = (smc91c111_state *)qemu_mallocz(sizeof(smc91c111_state));
     s->mmio_index = cpu_register_io_memory(0, smc91c111_readfn,
                                            smc91c111_writefn, s);
     cpu_register_physical_memory(base, 16, s->mmio_index);

Could this problem be related cpu_register_physical_memory_offset(...) as 
addresses are rounded down to page boundaries?

exec.c:2325:

/* register physical memory. 'size' must be a multiple of the target
    page size. If (phys_offset & ~TARGET_PAGE_MASK) != 0, then it is an
    io memory page.  The address used when calling the IO function is
    the offset from the start of the region, plus region_offset.  Both
    start_addr and region_offset are rounded down to a page boundary
    before calculating this offset.  This should not be a problem unless
    the low bits of start_addr and region_offset differ.  */

Or could this be fixed by another driver initialization?

Thorsten