Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1572735 > unrolled thread

regression for m68k/coldfire

Back to article view | Back to linux.kernel

Contents

  regression for m68k/coldfire Waldemar Brodkorb <wbx@openadk.org> - 2017-02-02 21:30 +0100
    Re: regression for m68k/coldfire Greg Ungerer <gerg@uclinux.org> - 2017-02-03 01:30 +0100
      Re: regression for m68k/coldfire John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-02-03 01:40 +0100
        Re: regression for m68k/coldfire Laurent Vivier <laurent@vivier.eu> - 2017-02-03 09:20 +0100
          Re: regression for m68k/coldfire Waldemar Brodkorb <wbx@openadk.org> - 2017-02-03 16:20 +0100
            Re: regression for m68k/coldfire Laurent Vivier <laurent@vivier.eu> - 2017-02-03 16:30 +0100
              Re: regression for m68k/coldfire Greg Ungerer <gerg@uclinux.org> - 2017-02-04 03:10 +0100
                Re: regression for m68k/coldfire Laurent Vivier <laurent@vivier.eu> - 2017-02-04 11:00 +0100
                  Re: regression for m68k/coldfire Greg Ungerer <gerg@uclinux.org> - 2017-02-06 12:50 +0100

#1572735 — regression for m68k/coldfire

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

[toc] | [next] | [standalone]

#1572829

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

[toc] | [prev] | [next] | [standalone]

#1572830

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

[toc] | [prev] | [next] | [standalone]

#1572938

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

[toc] | [prev] | [next] | [standalone]

#1573145

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

[toc] | [prev] | [next] | [standalone]

#1573174

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

[toc] | [prev] | [next] | [standalone]

#1573574

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

[toc] | [prev] | [next] | [standalone]

#1573632

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

[toc] | [prev] | [next] | [standalone]

#1574582

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web