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

[Thorsten Zitterell <the.real.hik@gmx.net>]

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