[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <89754ce3-1f76-9af1-f3b0-252c1eba94d9@uclinux.org>
Date: Fri, 3 Feb 2017 10:10:44 +1000
From: Greg Ungerer <gerg@...inux.org>
To: Waldemar Brodkorb <wbx@...nadk.org>,
Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc: linux-kernel@...r.kernel.org, linux-m68k@...r.kernel.org,
uclinux-dev@...inux.org, geert@...ux-m68k.org
Subject: Re: regression for m68k/coldfire
Hi Waldemar,
On 03/02/17 06:15, Waldemar Brodkorb wrote:
> your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
> booting in qemu-system-m68k:
>
> qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel qemu-m68k-mcf5208-initramfspiggyback-kernel
[snip]
> [ 3.460000] ColdFire internal UART serial driver
> [ 3.470000] mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90,
> base_baud = 2083333) is a ColdFire UART
> [ 3.500000] console [ttyS0] enabled
> [ 3.500000] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91,
> base_baud = 2083333) is a ColdFire UART
> [ 3.510000] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92,
> base_baud = 2083333) is a ColdFire UART
> qemu: hardware error: mcf_fec_read: Bad address 0x200
>
> CPU #0:
> D0 = 00000200 A0 = 4780fdec F0 = 0000000000000000 ( 0)
> D1 = 4780ff94 A1 = 401703de F1 = 0000000000000000 ( 0)
> D2 = 46dbb000 A2 = 4780f800 F2 = 0000000000000000 ( 0)
> D3 = 4019d612 A3 = fc030200 F3 = 0000000000000000 ( 0)
> D4 = 00000000 A4 = 4019d608 F4 = 0000000000000000 ( 0)
> D5 = 40043f7a A5 = 400222a0 F5 = 0000000000000000 ( 0)
> D6 = 400df204 A6 = 4783de78 F6 = 0000000000000000 ( 0)
> D7 = 401701c0 A7 = 4783de28 F7 = 0000000000000000 ( 0)
> PC = 400e5ff2 SR = 2009 -N--C FPRESULT = 0
> Aborted
> wbx@...enadk:~/m68k/openadk$
> wbx@...enadk:~/m68k/openadk$ qemu-system-m68k --version
> QEMU emulator version 2.8.0
> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
> developers
>
> Any ideas how to fix it?
This is a limitation in the FEC support in QEMU.
This works on real ColdFire hardware (which do support the
FEC MIB stats registers from offset 0x200 - so not 5272).
I sent this patch to the qemu dev list a couple of weeks
back which fixes qemu:
http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg01781.html
I do not believe it has been picked up by QEMU mainline yet
(I will probably have to resend and push a little to get that done).
Regards
Greg
Powered by blists - more mailing lists