linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* regression for m68k/coldfire
@ 2017-02-02 20:15 Waldemar Brodkorb
  2017-02-02 20:21 ` Nikita Yushchenko
  2017-02-03  0:10 ` Greg Ungerer
  0 siblings, 2 replies; 10+ messages in thread
From: Waldemar Brodkorb @ 2017-02-02 20:15 UTC (permalink / raw)
  To: Nikita Yushchenko; +Cc: linux-kernel, gerg, linux-m68k, uclinux-dev, geert

Hi,

your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
booting in qemu-system-m68k:

qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel qemu-m68k-mcf5208-initramfspiggyback-kernel

[    0.000000] Linux version 4.9.6-1 (wbx@vopenadk) (gcc version
5.4.0 (GCC) ) #2 Thu Feb 2 21:08:59 CET 2017
[    0.000000] uClinux with CPU COLDFIRE(m520x)
[    0.000000] COLDFIRE port done by Greg Ungerer, gerg@snapgear.com
[    0.000000] Flat model support (C) 1998,1999 Kenneth Albanowski,
D. Jeff Dionne
[    0.000000] Built 1 zonelists in Zone order, mobility grouping
on.  Total pages: 16320
[    0.000000] Kernel command line: console=ttyS0,115200 ro
rootfstype=tmpfs
[    0.000000] PID hash table entries: 512 (order: -2, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 3,
65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 2, 32768
bytes)
[    0.000000] Memory: 127920K/131072K available (1292K kernel code,
96K rwdata, 216K rodata, 560K init, 179K bss, 3152K reserved, 0K
cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0x40000000 - 0x40000400   (   1 KiB)
[    0.000000]     kmap    : 0x00000000 - 0xffffffff   (4095 MiB)
[    0.000000]     vmalloc : 0x00000000 - 0xffffffff   (4095 MiB)
[    0.000000]     lowmem  : 0x40000000 - 0x48000000   ( 128 MiB)
[    0.000000]       .init : 0x401b2000 - 0x4023e000   ( 560 KiB)
[    0.000000]       .text : 0x40020000 - 0x40163350   (1293 KiB)
[    0.000000]       .data : 0x40163350 - 0x401b1640   ( 313 KiB)
[    0.000000]       .bss  : 0x4023e000 - 0x4026af04   ( 180 KiB)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1,
Nodes=8
[    0.000000] NR_IRQS:256
[    0.000000] clocksource: pit: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 3669622406313 ns
[    0.020000] Calibrating delay loop... 238.38 BogoMIPS
(lpj=1191936)
[    0.080000] pid_max: default: 4096 minimum: 301
[    0.080000] Mount-cache hash table entries: 2048 (order: 0, 8192
bytes)
[    0.080000] Mountpoint-cache hash table entries: 2048 (order: 0,
8192 bytes)
[    0.160000] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.170000] NET: Registered protocol family 16
[    0.200000] pps_core: LinuxPPS API ver. 1 registered
[    0.200000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[    0.200000] PTP clock support registered
[    0.220000] clocksource: Switched to clocksource pit
[    0.230000] NET: Registered protocol family 2
[    0.240000] TCP established hash table entries: 2048 (order: 0,
8192 bytes)
[    0.240000] TCP bind hash table entries: 2048 (order: 0, 8192
bytes)
[    0.240000] TCP: Hash tables configured (established 2048 bind
2048)
[    0.240000] UDP hash table entries: 512 (order: 0, 8192 bytes)
[    0.240000] UDP-Lite hash table entries: 512 (order: 0, 8192
bytes)
[    0.250000] NET: Registered protocol family 1
[    2.560000] random: fast init done
[    3.400000] futex hash table entries: 16 (order: -6, 192 bytes)
[    3.400000] workingset: timestamp_bits=27 max_order=14
bucket_order=0
[    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@vopenadk:~/m68k/openadk$     
wbx@vopenadk:~/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?

best regards
 Waldemar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-02 20:15 regression for m68k/coldfire Waldemar Brodkorb
@ 2017-02-02 20:21 ` Nikita Yushchenko
  2017-02-03  0:10 ` Greg Ungerer
  1 sibling, 0 replies; 10+ messages in thread
From: Nikita Yushchenko @ 2017-02-02 20:21 UTC (permalink / raw)
  To: Waldemar Brodkorb; +Cc: linux-kernel, gerg, linux-m68k, uclinux-dev, geert

> Hi,
> 
> your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux
> booting in qemu-system-m68k:

Hi.

Do you compile with CONFIG_M5272?

Is f85de6666347c974cdf97b1026180995d912d7d0 also in your tree?

Nikita

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-02 20:15 regression for m68k/coldfire Waldemar Brodkorb
  2017-02-02 20:21 ` Nikita Yushchenko
@ 2017-02-03  0:10 ` Greg Ungerer
  2017-02-03  0:35   ` John Paul Adrian Glaubitz
  1 sibling, 1 reply; 10+ messages in thread
From: Greg Ungerer @ 2017-02-03  0:10 UTC (permalink / raw)
  To: Waldemar Brodkorb, Nikita Yushchenko
  Cc: linux-kernel, linux-m68k, uclinux-dev, geert

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@vopenadk:~/m68k/openadk$     
> wbx@vopenadk:~/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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-03  0:10 ` Greg Ungerer
@ 2017-02-03  0:35   ` John Paul Adrian Glaubitz
  2017-02-03  8:18     ` Laurent Vivier
  0 siblings, 1 reply; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-02-03  0:35 UTC (permalink / raw)
  To: Greg Ungerer, Waldemar Brodkorb, Nikita Yushchenko
  Cc: linux-kernel, linux-m68k, uclinux-dev, geert, Laurent Vivier

On 02/03/2017 01:10 AM, Greg Ungerer wrote:
> 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).

QEMU upstream can sometimes take a while before they are merging patches,
but usually it helps containing the maintainer of this part of the
source tree directly.

Unfortunately, mcf5208 is currently unmaintained [1]:

mcf5208
S: Orphan
F: hw/m68k/mcf5208.c
F: hw/m68k/mcf_intc.c
F: hw/char/mcf_uart.c
F: hw/net/mcf_fec.c

But you can try getting into touch with Laurent Vivier who is the
new maintainer of the m68k target. I have CC'ed him.

Adrian

> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=MAINTAINERS

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-03  0:35   ` John Paul Adrian Glaubitz
@ 2017-02-03  8:18     ` Laurent Vivier
  2017-02-03 15:17       ` Waldemar Brodkorb
  0 siblings, 1 reply; 10+ messages in thread
From: Laurent Vivier @ 2017-02-03  8:18 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz, Greg Ungerer, Waldemar Brodkorb,
	Nikita Yushchenko
  Cc: linux-kernel, linux-m68k, uclinux-dev, geert

Le 03/02/2017 à 01:35, John Paul Adrian Glaubitz a écrit :
> On 02/03/2017 01:10 AM, Greg Ungerer wrote:
>> 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).
> 
> QEMU upstream can sometimes take a while before they are merging patches,
> but usually it helps containing the maintainer of this part of the
> source tree directly.
> 
> Unfortunately, mcf5208 is currently unmaintained [1]:
> 
> mcf5208
> S: Orphan
> F: hw/m68k/mcf5208.c
> F: hw/m68k/mcf_intc.c
> F: hw/char/mcf_uart.c
> F: hw/net/mcf_fec.c
> 
> But you can try getting into touch with Laurent Vivier who is the
> new maintainer of the m68k target. I have CC'ed him.
> 
> Adrian
> 
>> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=MAINTAINERS
> 

Use scripts/get_maintainer.pl on your patch to find the people.

This patch is on the network part, so you should cc:
Jason Wang <jasowang@redhat.com> (odd fixer:Network devices)

If you cc me, you add more chances to have a review ;)

Thanks,
Laurent

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-03  8:18     ` Laurent Vivier
@ 2017-02-03 15:17       ` Waldemar Brodkorb
  2017-02-03 15:22         ` Laurent Vivier
  0 siblings, 1 reply; 10+ messages in thread
From: Waldemar Brodkorb @ 2017-02-03 15:17 UTC (permalink / raw)
  To: Laurent Vivier
  Cc: John Paul Adrian Glaubitz, Greg Ungerer, Waldemar Brodkorb,
	Nikita Yushchenko, linux-kernel, linux-m68k, uclinux-dev, geert

Hi,
Laurent Vivier wrote,

> Le 03/02/2017 à 01:35, John Paul Adrian Glaubitz a écrit :
> > On 02/03/2017 01:10 AM, Greg Ungerer wrote:
> >> 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).
> > 
> > QEMU upstream can sometimes take a while before they are merging patches,
> > but usually it helps containing the maintainer of this part of the
> > source tree directly.
> > 
> > Unfortunately, mcf5208 is currently unmaintained [1]:
> > 
> > mcf5208
> > S: Orphan
> > F: hw/m68k/mcf5208.c
> > F: hw/m68k/mcf_intc.c
> > F: hw/char/mcf_uart.c
> > F: hw/net/mcf_fec.c
> > 
> > But you can try getting into touch with Laurent Vivier who is the
> > new maintainer of the m68k target. I have CC'ed him.
> > 
> > Adrian
> > 
> >> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=MAINTAINERS
> > 
> 
> Use scripts/get_maintainer.pl on your patch to find the people.
> 
> This patch is on the network part, so you should cc:
> Jason Wang <jasowang@redhat.com> (odd fixer:Network devices)
> 
> If you cc me, you add more chances to have a review ;)

I tried the patch on top of 2.8.0 qemu release and it works for me
with Linux Kernel 4.9.
Thanks for the hint and patch!
I hope Greg's patch get included in the next qemu release.

Btw: Laurent, are you m68k with mmu support are going to be included
upstream? I always carry an old binary for any m68k with mmu testing.

best regards
 Waldemar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-03 15:17       ` Waldemar Brodkorb
@ 2017-02-03 15:22         ` Laurent Vivier
  2017-02-04  2:03           ` Greg Ungerer
  0 siblings, 1 reply; 10+ messages in thread
From: Laurent Vivier @ 2017-02-03 15:22 UTC (permalink / raw)
  To: Waldemar Brodkorb
  Cc: John Paul Adrian Glaubitz, Greg Ungerer, Nikita Yushchenko,
	linux-kernel, linux-m68k, uclinux-dev, geert

Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :
> Hi,
> Laurent Vivier wrote,
> 
>> Le 03/02/2017 à 01:35, John Paul Adrian Glaubitz a écrit :
>>> On 02/03/2017 01:10 AM, Greg Ungerer wrote:
>>>> 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).
>>>
>>> QEMU upstream can sometimes take a while before they are merging patches,
>>> but usually it helps containing the maintainer of this part of the
>>> source tree directly.
>>>
>>> Unfortunately, mcf5208 is currently unmaintained [1]:
>>>
>>> mcf5208
>>> S: Orphan
>>> F: hw/m68k/mcf5208.c
>>> F: hw/m68k/mcf_intc.c
>>> F: hw/char/mcf_uart.c
>>> F: hw/net/mcf_fec.c
>>>
>>> But you can try getting into touch with Laurent Vivier who is the
>>> new maintainer of the m68k target. I have CC'ed him.
>>>
>>> Adrian
>>>
>>>> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=MAINTAINERS
>>>
>>
>> Use scripts/get_maintainer.pl on your patch to find the people.
>>
>> This patch is on the network part, so you should cc:
>> Jason Wang <jasowang@redhat.com> (odd fixer:Network devices)
>>
>> If you cc me, you add more chances to have a review ;)
> 
> I tried the patch on top of 2.8.0 qemu release and it works for me
> with Linux Kernel 4.9.

If you can send a "Tested-by:" to the mailing list, it would be great.

> Thanks for the hint and patch!
> I hope Greg's patch get included in the next qemu release.
> 
> Btw: Laurent, are you m68k with mmu support are going to be included
> upstream? I always carry an old binary for any m68k with mmu testing.

I'm working to have the FPU included for now, that will allow to have
the linux-user qemu enabled for 680x0 upstream.

I have a 68040 MMU implementation that I will send after this step.
I didn't have a look to the ColdFire MMU (is there one?), but as 68040
is not the same as the 68030 one, I don't expect it works with coldfire.

Laurent

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-03 15:22         ` Laurent Vivier
@ 2017-02-04  2:03           ` Greg Ungerer
  2017-02-04  9:49             ` Laurent Vivier
  0 siblings, 1 reply; 10+ messages in thread
From: Greg Ungerer @ 2017-02-04  2:03 UTC (permalink / raw)
  To: Laurent Vivier
  Cc: Waldemar Brodkorb, John Paul Adrian Glaubitz, Nikita Yushchenko,
	linux-kernel, linux-m68k, uclinux-dev, geert

Hi Laurent,

On 04/02/17 01:22, Laurent Vivier wrote:
> Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :
[snip]
>> Btw: Laurent, are you m68k with mmu support are going to be included
>> upstream? I always carry an old binary for any m68k with mmu testing.
>
> I'm working to have the FPU included for now, that will allow to have
> the linux-user qemu enabled for 680x0 upstream.
>
> I have a 68040 MMU implementation that I will send after this step.
> I didn't have a look to the ColdFire MMU (is there one?), but as 68040
> is not the same as the 68030 one, I don't expect it works with coldfire.

There is a ColdFire MMU in some v4 ColdFire parts, for example
the 547x, 548x, 5441x and 5445x families. It is not compatible with
the older 68020/86030/68040 MMU. It is supported in mainline Linux -
at least for the 547x and 548x parts.

It would be really nice to have support for ColdFire MMU in QEMU :-)

Regards
Greg

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-04  2:03           ` Greg Ungerer
@ 2017-02-04  9:49             ` Laurent Vivier
  2017-02-06 11:40               ` Greg Ungerer
  0 siblings, 1 reply; 10+ messages in thread
From: Laurent Vivier @ 2017-02-04  9:49 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Waldemar Brodkorb, John Paul Adrian Glaubitz, Nikita Yushchenko,
	linux-kernel, linux-m68k, uclinux-dev, geert

Le 04/02/2017 à 03:03, Greg Ungerer a écrit :
> Hi Laurent,
> 
> On 04/02/17 01:22, Laurent Vivier wrote:
>> Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :
> [snip]
>>> Btw: Laurent, are you m68k with mmu support are going to be included
>>> upstream? I always carry an old binary for any m68k with mmu testing.
>>
>> I'm working to have the FPU included for now, that will allow to have
>> the linux-user qemu enabled for 680x0 upstream.
>>
>> I have a 68040 MMU implementation that I will send after this step.
>> I didn't have a look to the ColdFire MMU (is there one?), but as 68040
>> is not the same as the 68030 one, I don't expect it works with coldfire.
> 
> There is a ColdFire MMU in some v4 ColdFire parts, for example
> the 547x, 548x, 5441x and 5445x families. It is not compatible with
> the older 68020/86030/68040 MMU. It is supported in mainline Linux -
> at least for the 547x and 548x parts.
> 
> It would be really nice to have support for ColdFire MMU in QEMU :-)

I can work on this. Do you have a Coldfire distro I can install?

Thanks,
Laurent

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: regression for m68k/coldfire
  2017-02-04  9:49             ` Laurent Vivier
@ 2017-02-06 11:40               ` Greg Ungerer
  0 siblings, 0 replies; 10+ messages in thread
From: Greg Ungerer @ 2017-02-06 11:40 UTC (permalink / raw)
  To: Laurent Vivier
  Cc: Waldemar Brodkorb, John Paul Adrian Glaubitz, Nikita Yushchenko,
	linux-kernel, linux-m68k, uclinux-dev, geert

Hi Laurent,

On 04/02/17 19:49, Laurent Vivier wrote:
> Le 04/02/2017 à 03:03, Greg Ungerer a écrit :
>> Hi Laurent,
>>
>> On 04/02/17 01:22, Laurent Vivier wrote:
>>> Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit :
>> [snip]
>>>> Btw: Laurent, are you m68k with mmu support are going to be included
>>>> upstream? I always carry an old binary for any m68k with mmu testing.
>>>
>>> I'm working to have the FPU included for now, that will allow to have
>>> the linux-user qemu enabled for 680x0 upstream.
>>>
>>> I have a 68040 MMU implementation that I will send after this step.
>>> I didn't have a look to the ColdFire MMU (is there one?), but as 68040
>>> is not the same as the 68030 one, I don't expect it works with coldfire.
>>
>> There is a ColdFire MMU in some v4 ColdFire parts, for example
>> the 547x, 548x, 5441x and 5445x families. It is not compatible with
>> the older 68020/86030/68040 MMU. It is supported in mainline Linux -
>> at least for the 547x and 548x parts.
>>
>> It would be really nice to have support for ColdFire MMU in QEMU :-)
>
> I can work on this. Do you have a Coldfire distro I can install?

This is the one I use:

   http://www.uclinux.org/pub/uClinux/dist/

(toolchains for it at http://www.uclinux.org/pub/uClinux/m68k-elf-tools/)

Or if you don't want to compile it there is a ready to
run binary for the m5475evb at:

   http://www.uclinux.org/ports/coldfire/binary.html

Regards
Greg

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-02-06 11:41 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-02 20:15 regression for m68k/coldfire Waldemar Brodkorb
2017-02-02 20:21 ` Nikita Yushchenko
2017-02-03  0:10 ` Greg Ungerer
2017-02-03  0:35   ` John Paul Adrian Glaubitz
2017-02-03  8:18     ` Laurent Vivier
2017-02-03 15:17       ` Waldemar Brodkorb
2017-02-03 15:22         ` Laurent Vivier
2017-02-04  2:03           ` Greg Ungerer
2017-02-04  9:49             ` Laurent Vivier
2017-02-06 11:40               ` Greg Ungerer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).