[PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Daniel Palmer]

68000 has different alignment needs to 68020+.
memcpy() checks if the destination is aligned and does a smaller copy
to fix the alignment and then critically for 68000 it checks if the
source is still unaligned and if it is reverts to smaller copies.

memmove() does not currently do the second part and malfunctions if
one of the pointers is aligned and the other isn't.

This is apparently getting triggered by printk. If I put breakpoints
into the new checks added by this commit the first hit looks like this:

memmove (n=205, src=0x2f3971 <printk_shared_pbufs+205>, dest=0x2f3980 <printk_shared_pbufs+220>) at arch/m68k/lib/memmove.c:82

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---

This is from my "make 68000 work again" backlog.

I have had this fix for years and I think the few other people that
have various 68000 hobby builds must have something similar.

/root # uname -a
uClinux buildroot 6.18.0-12420-gdc1a468a2724 #120 Sat Dec 13 20:42:45 JST 2025 m68k GNU/Linux
/root # cat /proc/cpuinfo
CPU:            68000
MMU:            none
FPU:            none
Clocking:       1179.1MHz
BogoMips:       1758.00
Calibration:    879001600 loops
/root #

 arch/m68k/lib/memmove.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/m68k/lib/memmove.c b/arch/m68k/lib/memmove.c
index 6519f7f349f6..e33f00b02e4c 100644
--- a/arch/m68k/lib/memmove.c
+++ b/arch/m68k/lib/memmove.c
@@ -24,6 +24,15 @@ void *memmove(void *dest, const void *src, size_t n)
 			src = csrc;
 			n--;
 		}
+#if defined(CONFIG_M68000)
+		if ((long)src & 1) {
+			char *cdest = dest;
+			const char *csrc = src;
+			for (; n; n--)
+				*cdest++ = *csrc++;
+			return xdest;
+		}
+#endif
 		if (n > 2 && (long)dest & 2) {
 			short *sdest = dest;
 			const short *ssrc = src;
@@ -66,6 +75,15 @@ void *memmove(void *dest, const void *src, size_t n)
 			src = csrc;
 			n--;
 		}
+#if defined(CONFIG_M68000)
+		if ((long)src & 1) {
+			char *cdest = dest;
+			const char *csrc = src;
+			for (; n; n--)
+				*--cdest = *--csrc;
+			return xdest;
+		}
+#endif
 		if (n > 2 && (long)dest & 2) {
 			short *sdest = dest;
 			const short *ssrc = src;
-- 
2.51.0

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Greg Ungerer]

Hi Daniel,

On 13/12/25 22:04, Daniel Palmer wrote:
> 68000 has different alignment needs to 68020+.
> memcpy() checks if the destination is aligned and does a smaller copy
> to fix the alignment and then critically for 68000 it checks if the
> source is still unaligned and if it is reverts to smaller copies.
> 
> memmove() does not currently do the second part and malfunctions if
> one of the pointers is aligned and the other isn't.

What is the nature of the failure, is it a trap?


> This is apparently getting triggered by printk. If I put breakpoints
> into the new checks added by this commit the first hit looks like this:
> 
> memmove (n=205, src=0x2f3971 <printk_shared_pbufs+205>, dest=0x2f3980 <printk_shared_pbufs+220>) at arch/m68k/lib/memmove.c:82
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>

Seems to make sense from what we have in memcpy.c.

Acked-by: Greg Ungerer <gerg@linux-m68k.org>

Geert: if you are ok with this I can take it via the m68knommu tree?

Regards
Greg



> ---
> 
> This is from my "make 68000 work again" backlog.
> 
> I have had this fix for years and I think the few other people that
> have various 68000 hobby builds must have something similar.
> 
> /root # uname -a
> uClinux buildroot 6.18.0-12420-gdc1a468a2724 #120 Sat Dec 13 20:42:45 JST 2025 m68k GNU/Linux
> /root # cat /proc/cpuinfo
> CPU:            68000
> MMU:            none
> FPU:            none
> Clocking:       1179.1MHz
> BogoMips:       1758.00
> Calibration:    879001600 loops
> /root #
> 
>   arch/m68k/lib/memmove.c | 18 ++++++++++++++++++
>   1 file changed, 18 insertions(+)
> 
> diff --git a/arch/m68k/lib/memmove.c b/arch/m68k/lib/memmove.c
> index 6519f7f349f6..e33f00b02e4c 100644
> --- a/arch/m68k/lib/memmove.c
> +++ b/arch/m68k/lib/memmove.c
> @@ -24,6 +24,15 @@ void *memmove(void *dest, const void *src, size_t n)
>   			src = csrc;
>   			n--;
>   		}
> +#if defined(CONFIG_M68000)
> +		if ((long)src & 1) {
> +			char *cdest = dest;
> +			const char *csrc = src;
> +			for (; n; n--)
> +				*cdest++ = *csrc++;
> +			return xdest;
> +		}
> +#endif
>   		if (n > 2 && (long)dest & 2) {
>   			short *sdest = dest;
>   			const short *ssrc = src;
> @@ -66,6 +75,15 @@ void *memmove(void *dest, const void *src, size_t n)
>   			src = csrc;
>   			n--;
>   		}
> +#if defined(CONFIG_M68000)
> +		if ((long)src & 1) {
> +			char *cdest = dest;
> +			const char *csrc = src;
> +			for (; n; n--)
> +				*--cdest = *--csrc;
> +			return xdest;
> +		}
> +#endif
>   		if (n > 2 && (long)dest & 2) {
>   			short *sdest = dest;
>   			const short *ssrc = src;

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Daniel Palmer]

Hi Greg,

On Fri, 19 Dec 2025 at 20:59, Greg Ungerer <gerg@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On 13/12/25 22:04, Daniel Palmer wrote:
> > 68000 has different alignment needs to 68020+.
> > memcpy() checks if the destination is aligned and does a smaller copy
> > to fix the alignment and then critically for 68000 it checks if the
> > source is still unaligned and if it is reverts to smaller copies.
> >
> > memmove() does not currently do the second part and malfunctions if
> > one of the pointers is aligned and the other isn't.
>
> What is the nature of the failure, is it a trap?

Address error because of the unaligned address. This was actually a
real pain to work out because on QEMU it worked fine (mainline QEMU
allows the unaligned access[0]) and on the real CPU it just locked up.

Thanks!

Daniel

0 - https://gitlab.com/qemu-project/qemu/-/issues/2165

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Eero Tamminen]

Hi Daniel,

On 12/19/25 15:30, Daniel Palmer wrote:
> On Fri, 19 Dec 2025 at 20:59, Greg Ungerer <gerg@linux-m68k.org> wrote:
>> On 13/12/25 22:04, Daniel Palmer wrote:
>>> 68000 has different alignment needs to 68020+.
>>> memcpy() checks if the destination is aligned and does a smaller copy
>>> to fix the alignment and then critically for 68000 it checks if the
>>> source is still unaligned and if it is reverts to smaller copies.
>>>
>>> memmove() does not currently do the second part and malfunctions if
>>> one of the pointers is aligned and the other isn't.
>>
>> What is the nature of the failure, is it a trap?
> 
> Address error because of the unaligned address. This was actually a
> real pain to work out because on QEMU it worked fine (mainline QEMU
> allows the unaligned access[0]) and on the real CPU it just locked up.
Both WinUAE (Amiga) and Hatari (Atari) emulators emulate 680x0 
exceptions just fine, and can run Linux.

(They also emulate 030 cache and it's even semi-cycle-accurate [1].)

Hatari CLI debugger / profiler will give you kernel backtraces even if 
kernel itself could not, see: https://www.hatari-emu.org/doc/m68k-linux.txt


	- Eero

[1] https://www.hatari-emu.org/doc/debugger.html#Profile_data_accuracy

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Daniel Palmer]

Hi Eero,

On Mon, 22 Dec 2025 at 08:54, Eero Tamminen <oak@helsinkinet.fi> wrote:
> Both WinUAE (Amiga) and Hatari (Atari) emulators emulate 680x0
> exceptions just fine, and can run Linux.
>
> (They also emulate 030 cache and it's even semi-cycle-accurate [1].)
>
> Hatari CLI debugger / profiler will give you kernel backtraces even if
> kernel itself could not, see: https://www.hatari-emu.org/doc/m68k-linux.txt

I have been using WinUAE. The driver I sent for the A4000 mediator PCI
bridge I sent a while back was initially tested in WinUAE and then
finished off on my real A4000.
I have to turn off JIT to get it working under wine so it's not very
fast. I didn't know about hatari, so I'll take a look.

I'm using QEMU for 68000 emulation because I have added a machine that
roughly emulates the Dragonball EZ that is "supported"[0] in the
kernel and I can use that to test most things before trying it on the
real hardware. It made getting u-boot and the kernel working properly
a lot easier.

Cheers,

Daniel

0 - GCC currently generates code that will cause unaligned accesses,
some code in entry.S is currently broken.

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Greg Ungerer]

Hi Daniel,

I'll add this to the m68knommu git tree, for-next branch.

Thanks
Greg



On 19/12/25 21:58, Greg Ungerer wrote:
> Hi Daniel,
> 
> On 13/12/25 22:04, Daniel Palmer wrote:
>> 68000 has different alignment needs to 68020+.
>> memcpy() checks if the destination is aligned and does a smaller copy
>> to fix the alignment and then critically for 68000 it checks if the
>> source is still unaligned and if it is reverts to smaller copies.
>>
>> memmove() does not currently do the second part and malfunctions if
>> one of the pointers is aligned and the other isn't.
> 
> What is the nature of the failure, is it a trap?
> 
> 
>> This is apparently getting triggered by printk. If I put breakpoints
>> into the new checks added by this commit the first hit looks like this:
>>
>> memmove (n=205, src=0x2f3971 <printk_shared_pbufs+205>, dest=0x2f3980 <printk_shared_pbufs+220>) at arch/m68k/lib/memmove.c:82
>>
>> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> 
> Seems to make sense from what we have in memcpy.c.
> 
> Acked-by: Greg Ungerer <gerg@linux-m68k.org>
> 
> Geert: if you are ok with this I can take it via the m68knommu tree?
> 
> Regards
> Greg
> 
> 
> 
>> ---
>>
>> This is from my "make 68000 work again" backlog.
>>
>> I have had this fix for years and I think the few other people that
>> have various 68000 hobby builds must have something similar.
>>
>> /root # uname -a
>> uClinux buildroot 6.18.0-12420-gdc1a468a2724 #120 Sat Dec 13 20:42:45 JST 2025 m68k GNU/Linux
>> /root # cat /proc/cpuinfo
>> CPU:            68000
>> MMU:            none
>> FPU:            none
>> Clocking:       1179.1MHz
>> BogoMips:       1758.00
>> Calibration:    879001600 loops
>> /root #
>>
>>   arch/m68k/lib/memmove.c | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/m68k/lib/memmove.c b/arch/m68k/lib/memmove.c
>> index 6519f7f349f6..e33f00b02e4c 100644
>> --- a/arch/m68k/lib/memmove.c
>> +++ b/arch/m68k/lib/memmove.c
>> @@ -24,6 +24,15 @@ void *memmove(void *dest, const void *src, size_t n)
>>               src = csrc;
>>               n--;
>>           }
>> +#if defined(CONFIG_M68000)
>> +        if ((long)src & 1) {
>> +            char *cdest = dest;
>> +            const char *csrc = src;
>> +            for (; n; n--)
>> +                *cdest++ = *csrc++;
>> +            return xdest;
>> +        }
>> +#endif
>>           if (n > 2 && (long)dest & 2) {
>>               short *sdest = dest;
>>               const short *ssrc = src;
>> @@ -66,6 +75,15 @@ void *memmove(void *dest, const void *src, size_t n)
>>               src = csrc;
>>               n--;
>>           }
>> +#if defined(CONFIG_M68000)
>> +        if ((long)src & 1) {
>> +            char *cdest = dest;
>> +            const char *csrc = src;
>> +            for (; n; n--)
>> +                *--cdest = *--csrc;
>> +            return xdest;
>> +        }
>> +#endif
>>           if (n > 2 && (long)dest & 2) {
>>               short *sdest = dest;
>>               const short *ssrc = src;
> 

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Daniel Palmer]

Hi Greg,

On Fri, 16 Jan 2026 at 20:03, Greg Ungerer <gerg@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> I'll add this to the m68knommu git tree, for-next branch.
>
> Thanks
> Greg

Thanks!

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Geert Uytterhoeven]

Hi Daniel,

On Sat, 13 Dec 2025 at 13:04, Daniel Palmer <daniel@thingy.jp> wrote:
> 68000 has different alignment needs to 68020+.
> memcpy() checks if the destination is aligned and does a smaller copy
> to fix the alignment and then critically for 68000 it checks if the
> source is still unaligned and if it is reverts to smaller copies.
>
> memmove() does not currently do the second part and malfunctions if
> one of the pointers is aligned and the other isn't.
>
> This is apparently getting triggered by printk. If I put breakpoints
> into the new checks added by this commit the first hit looks like this:
>
> memmove (n=205, src=0x2f3971 <printk_shared_pbufs+205>, dest=0x2f3980 <printk_shared_pbufs+220>) at arch/m68k/lib/memmove.c:82
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>

Thanks for your patch, which is now commit 590fe2f46c8698bb ("m68k:
nommu: fix memmove() with differently aligned src and dest for
68000") in v7.0-rc1.

> --- a/arch/m68k/lib/memmove.c
> +++ b/arch/m68k/lib/memmove.c
> @@ -24,6 +24,15 @@ void *memmove(void *dest, const void *src, size_t n)
>                         src = csrc;
>                         n--;
>                 }
> +#if defined(CONFIG_M68000)

Ideally, these (and the few existing other checks) should check for
CONFIG_CPU_HAS_NO_UNALIGNED instead.

> +               if ((long)src & 1) {
> +                       char *cdest = dest;
> +                       const char *csrc = src;
> +                       for (; n; n--)
> +                               *cdest++ = *csrc++;
> +                       return xdest;
> +               }
> +#endif
>                 if (n > 2 && (long)dest & 2) {
>                         short *sdest = dest;
>                         const short *ssrc = src;
> @@ -66,6 +75,15 @@ void *memmove(void *dest, const void *src, size_t n)
>                         src = csrc;
>                         n--;
>                 }
> +#if defined(CONFIG_M68000)
> +               if ((long)src & 1) {
> +                       char *cdest = dest;
> +                       const char *csrc = src;
> +                       for (; n; n--)
> +                               *--cdest = *--csrc;
> +                       return xdest;
> +               }
> +#endif
>                 if (n > 2 && (long)dest & 2) {
>                         short *sdest = dest;
>                         const short *ssrc = src;

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] m68k: nommu: fix memmove() with differently aligned src and dest for 68000

[Daniel Palmer]

Hi Geert,

On Tue, 24 Feb 2026 at 19:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Ideally, these (and the few existing other checks) should check for
> CONFIG_CPU_HAS_NO_UNALIGNED instead.

That makes sense. I have a few other bits to make 68000 support work
properly again that I will send eventually.
If I remember I'll send a patch with some of that to
s/CONFIG_M68000/CONFIG_CPU_HAS_NO_UNALIGNED/ for these functions.

Thanks,

Daniel