Re: [RFC PULL] remove arch/h8300

Re: [RFC PULL] remove arch/h8300

[Arnd Bergmann]

On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
> > If there are no other objections, I'll just queue this up for 5.18 in
> > the asm-generic
> > tree along with the nds32 removal.
>
> So it is the last day of te merge window and arch/h8300 is till there.
> And checking nw the removal has also not made it to linux-next.  Looks
> like it is so stale that even the removal gets ignored :(

I was really hoping that someone else would at least comment.
I've queued it up now for 5.19.

Should we garbage-collect some of the other nommu platforms where
we're here? Some of them are just as stale:

1. xtensa nommu has does not compile in mainline and as far as I can
tell never did
   (there was https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.6-esp32,
which
   worked at some point, but I don't think there was enough interest
to get in merged)

2. arch/sh Hitachi/Renesas sh2 (non-j2) support appears to be in a similar state
    to h8300, I don't think anyone would miss it

8<----- This may we where we want to draw the line ----

3. arch/sh j2 support was added in 2016 and doesn't see a lot of
changes, but I think
    Rich still cares about it and wants to add J32 support (with MMU)
in the future

4. m68k Dragonball, Coldfire v2 and Coldfire v3 are just as obsolete as SH2 as
   hardware is concerned, but Greg Ungerer keeps maintaining it, along with the
   newer Coldfire v4 (with MMU)

5. K210 was added in 2020. I assume you still want to keep it.

7. Arm32 has several Cortex-M based platforms that are mainly kept for
    legacy users (in particular stm32) or educational value.


       Arnd

Re: [RFC PULL] remove arch/h8300

[John Paul Adrian Glaubitz]

Hello Arnd!

On 4/4/22 15:07, Arnd Bergmann wrote:
> 2. arch/sh Hitachi/Renesas sh2 (non-j2) support appears to be in a similar state
>     to h8300, I don't think anyone would miss it
> 
> 8<----- This may we where we want to draw the line ----
> 
> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
> changes, but I think
>     Rich still cares about it and wants to add J32 support (with MMU)
> in the future
> 
> 4. m68k Dragonball, Coldfire v2 and Coldfire v3 are just as obsolete as SH2 as
>    hardware is concerned, but Greg Ungerer keeps maintaining it, along with the
>    newer Coldfire v4 (with MMU)

I'm always interested in everything m68k and SH, so if something needs attention,
I'm happy to help. I actually have SH-2 hardware at home although I haven't tried
a recent kernel.

Adrian

-- 
 .''`.  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

Re: [RFC PULL] remove arch/h8300

[Geert Uytterhoeven]

Hi Arnd,

On Mon, Apr 4, 2022 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
> > On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
> > > If there are no other objections, I'll just queue this up for 5.18 in
> > > the asm-generic
> > > tree along with the nds32 removal.
> >
> > So it is the last day of te merge window and arch/h8300 is till there.
> > And checking nw the removal has also not made it to linux-next.  Looks
> > like it is so stale that even the removal gets ignored :(
>
> I was really hoping that someone else would at least comment.

Doh, I hadn't seen this patch before ;-)
Nevertheless, I do not have access to H8/300 hardware.

> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
> changes, but I think
>     Rich still cares about it and wants to add J32 support (with MMU)
> in the future

Yep, when the SH4 patents will have expired.
I believe that's planned for 2016 (Islamic calendar? ;-)

BTW, the unresponsiveness of the SH maintainers is also annoying.
Patches are sent to the list (sometimes multiple people are solving
the same recurring issue), but ignored.

Anyway, I do regular boot tests on SH4.

> 5. K210 was added in 2020. I assume you still want to keep it.

FTR, I do regular boot tests on K210.

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: [RFC PULL] remove arch/h8300

[Damien Le Moal]

On 4/4/22 22:22, Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Mon, Apr 4, 2022 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>>> On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
>>>> If there are no other objections, I'll just queue this up for 5.18 in
>>>> the asm-generic
>>>> tree along with the nds32 removal.
>>>
>>> So it is the last day of te merge window and arch/h8300 is till there.
>>> And checking nw the removal has also not made it to linux-next.  Looks
>>> like it is so stale that even the removal gets ignored :(
>>
>> I was really hoping that someone else would at least comment.
> 
> Doh, I hadn't seen this patch before ;-)
> Nevertheless, I do not have access to H8/300 hardware.
> 
>> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
>> changes, but I think
>>     Rich still cares about it and wants to add J32 support (with MMU)
>> in the future
> 
> Yep, when the SH4 patents will have expired.
> I believe that's planned for 2016 (Islamic calendar? ;-)
> 
> BTW, the unresponsiveness of the SH maintainers is also annoying.
> Patches are sent to the list (sometimes multiple people are solving
> the same recurring issue), but ignored.
> 
> Anyway, I do regular boot tests on SH4.
> 
>> 5. K210 was added in 2020. I assume you still want to keep it.
> 
> FTR, I do regular boot tests on K210.

FYI, we identified the problem that makes userspace execution unreliable.
Working on a fix.


-- 
Damien Le Moal
Western Digital Research

Re: [RFC PULL] remove arch/h8300

[Rob Landley]

On 4/4/22 08:22, Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Mon, Apr 4, 2022 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>> > On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
>> > > If there are no other objections, I'll just queue this up for 5.18 in
>> > > the asm-generic
>> > > tree along with the nds32 removal.
>> >
>> > So it is the last day of te merge window and arch/h8300 is till there.
>> > And checking nw the removal has also not made it to linux-next.  Looks
>> > like it is so stale that even the removal gets ignored :(
>>
>> I was really hoping that someone else would at least comment.
> 
> Doh, I hadn't seen this patch before ;-)
> Nevertheless, I do not have access to H8/300 hardware.

The 8300 never got qemu support but I had lunch with the maintainer in Tokyo a
few years back and he showed me how to use gdb to simulate it, which included
booting Linux under the gdb simulation (built-in initramfs talking to serial
console). Here's somebody else using gdb simulation for h8/300:

https://www4.cs.fau.de/~felser/RCXSimulator/

I'm interested in H8300 because it's a tiny architecture (under 6k lines total,
in 93 files) and thus a good way to see what a minimal Linux port looks like. If
somebody would like to suggest a different one for that...

>> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
>> changes, but I think
>>     Rich still cares about it and wants to add J32 support (with MMU)
>> in the future
> 
> Yep, when the SH4 patents will have expired.

They've had a working J32 on FPGA for a while now, the problem is porting Linux
to it. The MMU design they went with wasn't compatible with sh3/sh4. (Userspace
is, kernel side needs some tweaking.) And they don't want to finalize the design
until they have proper test loads running on it, and then they went off to do
VPN hardware and such during the pandemic...

> I believe that's planned for 2016 (Islamic calendar? ;-)

The website's kind of archived and needs to be completely redone. (It moved
hosts and I lost access to update it for a while, and I got sucked into other
projects since. The mailing list server is also mothballed. Ask Jeff, I brought
it up every weekly call for 6 months...)

Jeff's team is working on making a J2 asic this year (through sky130), and
everything else is queued up after that. They've been grabbing various I/O
subsystems (like the GPS correlators and crypto engine and such) and doing work
on them to make go/no-go decisions for the asic inclusion. (Lots of activity
goes by on the Signal channel, but I can't even get cut and paste to work in
that thing's Android app, and I don't really have the domain expertise to help
out with that part.)

> BTW, the unresponsiveness of the SH maintainers is also annoying.
> Patches are sent to the list (sometimes multiple people are solving
> the same recurring issue), but ignored.

I mailed four or five turtle boards out to people last year, in hopes of getting
wider testing, but everybody I sent one to seems to have vanished. (The pandemic
chip shortage kinda derailed plans to productize that...)

I tested 5.17 on J2 FPGA when it came out, and it booted with two local patches:

1) Commit 790eb67374 needs to be reverted or the j2 boot just hangs before
producing any console output. Dunno why, it seems COMPLETELY unrelated, and yet.
(Wild guess: disturbs the alignment of some important piece of data? Rich knows
and it's in queue.)

2) This patch from Rich stops the j2 boot messages from being a thousand lines
of IRQ warnings, but he called it a hack when he sent it to me and I have no
clue what a "proper" fix would look like (or why that isn't)?

diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
index 5f47d8ee4ae3..730252cb7b08 100644
--- a/drivers/irqchip/irq-jcore-aic.c
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -68,6 +68,7 @@ static int __init aic_irq_of_init(struct device_node *node,
 	unsigned min_irq = JCORE_AIC2_MIN_HWIRQ;
 	unsigned dom_sz = JCORE_AIC_MAX_HWIRQ+1;
 	struct irq_domain *domain;
+	int rc;

 	pr_info("Initializing J-Core AIC\n");

@@ -100,6 +101,11 @@ static int __init aic_irq_of_init(struct device_node *node,
 	jcore_aic.irq_unmask = noop;
 	jcore_aic.name = "AIC";

+	rc = irq_alloc_descs(min_irq, min_irq, dom_sz - min_irq,
+			     of_node_to_nid(node));
+	if (rc < 0)
+		pr_info("Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+			min_irq);
 	domain = irq_domain_add_legacy(node, dom_sz - min_irq, min_irq, min_irq,
 				       &jcore_aic_irqdomain_ops,
 				       &jcore_aic);

I'm spinning too many plates to reliably reply to stuff, but I try to check in
as often as I can, and at LEAST regression test each new release.

Rob

Re: [RFC PULL] remove arch/h8300

[Arnd Bergmann]

On Wed, Apr 6, 2022 at 11:25 PM Rob Landley <rob@landley.net> wrote:

> I'm interested in H8300 because it's a tiny architecture (under 6k lines total,
> in 93 files) and thus a good way to see what a minimal Linux port looks like. If
> somebody would like to suggest a different one for that...

Anything that is maintained is usually a better example, and it helps when the
code is not old enough to have accumulated a lot of historic baggage.

The arch/riscv/ code is generally a good example base for others to copy.
It's not nearly as small, but that is mostly because it implements optional
features that could be left out. csky is a smaller example that is also
fairly clean and new, but less featureful.

         Arnd

Re: [RFC PULL] remove arch/h8300

[John Paul Adrian Glaubitz]

On 4/7/22 09:17, Arnd Bergmann wrote:
> On Wed, Apr 6, 2022 at 11:25 PM Rob Landley <rob@landley.net> wrote:
> 
>> I'm interested in H8300 because it's a tiny architecture (under 6k lines total,
>> in 93 files) and thus a good way to see what a minimal Linux port looks like. If
>> somebody would like to suggest a different one for that...
> 
> Anything that is maintained is usually a better example, and it helps when the
> code is not old enough to have accumulated a lot of historic baggage.

But if it's not a lot of code, would it really accumulate a lot of cruft?

If the code just works as is and doesn't need much attention to keep it working
why not keep it? As long as the code doesn't break anything else what's the
problem with keeping it?

FWIW, the H8 backend in GCC was just recently modernized and improved and converted
to MODE_CC.

Adrian

-- 
 .''`.  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

Re: [RFC PULL] remove arch/h8300

[Christoph Hellwig]

On Thu, Apr 07, 2022 at 09:47:04AM +0200, John Paul Adrian Glaubitz wrote:
> But if it's not a lot of code, would it really accumulate a lot of cruft?
> 
> If the code just works as is and doesn't need much attention to keep it working

Because no one gives it even that little bit of attention.

Re: [RFC PULL] remove arch/h8300

[Finn Thain]

On Thu, 7 Apr 2022, John Paul Adrian Glaubitz wrote:

> On 4/7/22 09:17, Arnd Bergmann wrote:
> > On Wed, Apr 6, 2022 at 11:25 PM Rob Landley wrote:
> > 
> >> I'm interested in H8300 because it's a tiny architecture (under 6k 
> >> lines total, in 93 files) and thus a good way to see what a minimal 
> >> Linux port looks like. If somebody would like to suggest a different 
> >> one for that...
> > 
> > Anything that is maintained is usually a better example, and it helps 
> > when the code is not old enough to have accumulated a lot of historic 
> > baggage.
> 
> But if it's not a lot of code, would it really accumulate a lot of 
> cruft?
> 

Where you see "TODO" in Documentation/features/*/*/arch-support.txt it may 
mean that an architecture is preventing the removal of an old API.

You're quite right, though, it is incorrect to call this an "accumulation" 
of baggage. It is actually the failure to remove cruft. (OTOH, shiny new 
things can be said to "accumulate". That's how cruft gets made.)

Re: [RFC PULL] remove arch/h8300

[Greg Ungerer]

Hi Arnd,

On 4/4/22 23:07, Arnd Bergmann wrote:
> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
>>> If there are no other objections, I'll just queue this up for 5.18 in
>>> the asm-generic
>>> tree along with the nds32 removal.
>>
>> So it is the last day of te merge window and arch/h8300 is till there.
>> And checking nw the removal has also not made it to linux-next.  Looks
>> like it is so stale that even the removal gets ignored :(
> 
> I was really hoping that someone else would at least comment.
> I've queued it up now for 5.19.
> 
> Should we garbage-collect some of the other nommu platforms where
> we're here? Some of them are just as stale:
> 
> 1. xtensa nommu has does not compile in mainline and as far as I can
> tell never did
>     (there was https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.6-esp32,
> which
>     worked at some point, but I don't think there was enough interest
> to get in merged)
> 
> 2. arch/sh Hitachi/Renesas sh2 (non-j2) support appears to be in a similar state
>      to h8300, I don't think anyone would miss it
> 
> 8<----- This may we where we want to draw the line ----
> 
> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
> changes, but I think
>      Rich still cares about it and wants to add J32 support (with MMU)
> in the future
> 
> 4. m68k Dragonball, Coldfire v2 and Coldfire v3 are just as obsolete as SH2 as
>     hardware is concerned, but Greg Ungerer keeps maintaining it, along with the
>     newer Coldfire v4 (with MMU)

I have no plans to stop maintaining ColdFire v2 and v3 (and v4), FWIW.

But we could consider the Dragonball support for removal. I keep it compiling,
but I don't use it and can't test that it actually works. Not sure that it
has been used for a very long time now. And I didn't even realize but its
serial driver (68328serial.c) was removed in 2015. No one seems too have
noticed and complained.

Regards
Greg
  


> 5. K210 was added in 2020. I assume you still want to keep it.
> 
> 7. Arm32 has several Cortex-M based platforms that are mainly kept for
>      legacy users (in particular stm32) or educational value.
> 
> 
>         Arnd

Re: [RFC PULL] remove arch/h8300

[Daniel Palmer]

Hi Greg,

On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
> But we could consider the Dragonball support for removal. I keep it compiling,
> but I don't use it and can't test that it actually works. Not sure that it
> has been used for a very long time now. And I didn't even realize but its
> serial driver (68328serial.c) was removed in 2015. No one seems too have
> noticed and complained.

I noticed this and I am working on fixing it up for a new Dragonball
homebrew machine.
I'm trying to add a 68000 machine to QEMU to make the development
easier because I'm currently waiting an hour or more for a kernel to
load over serial.
It might be a few months.

It looked like 68328serial.c was removed because someone tried to
clean it up and it was decided that no one was using it and it was
best to delete it.
My plan was to at some point send a series to fix up the issues with
the Dragonball support, revert removing the serial driver and adding
the patch that cleaned it up.

Cheers,

Daniel

Re: [RFC PULL] remove arch/h8300

[Greg Ungerer]

Hi Daniel,

On 5/4/22 13:23, Daniel Palmer wrote:
> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
>> But we could consider the Dragonball support for removal. I keep it compiling,
>> but I don't use it and can't test that it actually works. Not sure that it
>> has been used for a very long time now. And I didn't even realize but its
>> serial driver (68328serial.c) was removed in 2015. No one seems too have
>> noticed and complained.
> 
> I noticed this and I am working on fixing it up for a new Dragonball
> homebrew machine.
> I'm trying to add a 68000 machine to QEMU to make the development
> easier because I'm currently waiting an hour or more for a kernel to
> load over serial.
> It might be a few months.
> 
> It looked like 68328serial.c was removed because someone tried to
> clean it up and it was decided that no one was using it and it was
> best to delete it.
> My plan was to at some point send a series to fix up the issues with
> the Dragonball support, revert removing the serial driver and adding
> the patch that cleaned it up.

Nice. I will leave all the 68000/68328 code alone for now then.

Regards
Greg

Re: [RFC PULL] remove arch/h8300

[Rob Landley]

On 4/5/22 08:07, Greg Ungerer wrote:
> Hi Daniel,
> 
> On 5/4/22 13:23, Daniel Palmer wrote:
>> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
>>> But we could consider the Dragonball support for removal. I keep it compiling,
>>> but I don't use it and can't test that it actually works. Not sure that it
>>> has been used for a very long time now. And I didn't even realize but its
>>> serial driver (68328serial.c) was removed in 2015. No one seems too have
>>> noticed and complained.
>> 
>> I noticed this and I am working on fixing it up for a new Dragonball
>> homebrew machine.
>> I'm trying to add a 68000 machine to QEMU to make the development
>> easier because I'm currently waiting an hour or more for a kernel to
>> load over serial.
>> It might be a few months.

I've been booting Linux on qemu-system-m68k -M q800 for a couple years now? (The
CROSS=m68k target of mkroot in toybox?)

# cat /proc/cpuinfo
CPU:		68040
MMU:		68040
FPU:		68040
Clocking:	1261.9MHz
BogoMips:	841.31
Calibration:	4206592 loops

It certainly THINKS it's got m68000...

$ qemu-system-m68k -cpu ?
cfv4e
m5206
m5208
m68000
m68010
m68020
m68030
m68040
m68060
any

(I'd love to get an m68k nommu system working but never sat down and worked out
a kernel .config qemu agreed to run, plus compiler and libc. Musl added m68k
support but I dunno if that includes coldfire?)

>> It looked like 68328serial.c was removed because someone tried to
>> clean it up and it was decided that no one was using it and it was
>> best to delete it.
>> My plan was to at some point send a series to fix up the issues with
>> the Dragonball support, revert removing the serial driver and adding
>> the patch that cleaned it up.
> 
> Nice. I will leave all the 68000/68328 code alone for now then.

The q800 config uses CONFIG_SERIAL_PMACZILOG. Seems to work fine?

> Regards
> Greg

Rob

Re: [RFC PULL] remove arch/h8300

[Finn Thain]

On Fri, 8 Apr 2022, Rob Landley wrote:

> On 4/5/22 08:07, Greg Ungerer wrote:
> > On 5/4/22 13:23, Daniel Palmer wrote:
> >> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
> >>> But we could consider the Dragonball support for removal. I keep it 
> >>> compiling, but I don't use it and can't test that it actually works. 
> >>> Not sure that it has been used for a very long time now. And I 
> >>> didn't even realize but its serial driver (68328serial.c) was 
> >>> removed in 2015. No one seems too have noticed and complained.
> >> 
> >> I noticed this and I am working on fixing it up for a new Dragonball 
> >> homebrew machine. I'm trying to add a 68000 machine to QEMU to make 
> >> the development easier because I'm currently waiting an hour or more 
> >> for a kernel to load over serial. It might be a few months.
> 
> I've been booting Linux on qemu-system-m68k -M q800 for a couple years 
> now? (The CROSS=m68k target of mkroot in toybox?)
> 
> # cat /proc/cpuinfo
> CPU:		68040
> MMU:		68040
> FPU:		68040
> Clocking:	1261.9MHz
> BogoMips:	841.31
> Calibration:	4206592 loops
> 
> It certainly THINKS it's got m68000...
> 

Most 68040 processor variants have a built-in MMU and the m68k "nommu" 
Linux port doesn't support them. The nommu port covers processors like 
68000, Dragonball etc. whereas the m68k "mmu" port covers 680x0 where x is 
one of 2,3,4,6 with MMU.

> $ qemu-system-m68k -cpu ?
> cfv4e
> m5206
> m5208
> m68000
> m68010
> m68020
> m68030
> m68040
> m68060
> any
> 
> (I'd love to get an m68k nommu system working but never sat down and 
> worked out a kernel .config qemu agreed to run, plus compiler and libc. 
> Musl added m68k support but I dunno if that includes coldfire?)
> 

I could never figure out how to boot a coldfire machine in qemu either. 
There was no documentation about that back when I attempted it but maybe 
things have improved since.

> >> It looked like 68328serial.c was removed because someone tried to 
> >> clean it up and it was decided that no one was using it and it was 
> >> best to delete it. My plan was to at some point send a series to fix 
> >> up the issues with the Dragonball support, revert removing the serial 
> >> driver and adding the patch that cleaned it up.
> > 
> > Nice. I will leave all the 68000/68328 code alone for now then.
> 
> The q800 config uses CONFIG_SERIAL_PMACZILOG. Seems to work fine?
> 

That driver would work on certain 68000 systems e.g. early Macs. (And IIRC 
someone did once boot a customized Linux kernel on a Mac SE...)

Re: [RFC PULL] remove arch/h8300

[Greg Ungerer]

On 9/4/22 11:59, Finn Thain wrote:
> On Fri, 8 Apr 2022, Rob Landley wrote:
> 
>> On 4/5/22 08:07, Greg Ungerer wrote:
>>> On 5/4/22 13:23, Daniel Palmer wrote:
>>>> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
>>>>> But we could consider the Dragonball support for removal. I keep it
>>>>> compiling, but I don't use it and can't test that it actually works.
>>>>> Not sure that it has been used for a very long time now. And I
>>>>> didn't even realize but its serial driver (68328serial.c) was
>>>>> removed in 2015. No one seems too have noticed and complained.
>>>>
>>>> I noticed this and I am working on fixing it up for a new Dragonball
>>>> homebrew machine. I'm trying to add a 68000 machine to QEMU to make
>>>> the development easier because I'm currently waiting an hour or more
>>>> for a kernel to load over serial. It might be a few months.
>>
>> I've been booting Linux on qemu-system-m68k -M q800 for a couple years
>> now? (The CROSS=m68k target of mkroot in toybox?)
>>
>> # cat /proc/cpuinfo
>> CPU:		68040
>> MMU:		68040
>> FPU:		68040
>> Clocking:	1261.9MHz
>> BogoMips:	841.31
>> Calibration:	4206592 loops
>>
>> It certainly THINKS it's got m68000...
>>
> 
> Most 68040 processor variants have a built-in MMU and the m68k "nommu"
> Linux port doesn't support them. The nommu port covers processors like
> 68000, Dragonball etc. whereas the m68k "mmu" port covers 680x0 where x is
> one of 2,3,4,6 with MMU.
> 
>> $ qemu-system-m68k -cpu ?
>> cfv4e
>> m5206
>> m5208
>> m68000
>> m68010
>> m68020
>> m68030
>> m68040
>> m68060
>> any
>>
>> (I'd love to get an m68k nommu system working but never sat down and
>> worked out a kernel .config qemu agreed to run, plus compiler and libc.
>> Musl added m68k support but I dunno if that includes coldfire?)
>>
> 
> I could never figure out how to boot a coldfire machine in qemu either.
> There was no documentation about that back when I attempted it but maybe
> things have improved since.

FWIW this will do it:

     qemu-system-m68k -nographic -machine mcf5208evb -kernel vmlinux

That will boot an m5208evb_defconfig generated vmlinux.
But you will need a user space to get a full boot to login/shell.

Regards
Greg

Re: [RFC PULL] remove arch/h8300

[Rob Landley]

On 4/8/22 23:18, Greg Ungerer wrote:
> 
> On 9/4/22 11:59, Finn Thain wrote:
>> On Fri, 8 Apr 2022, Rob Landley wrote:
>> 
>>> On 4/5/22 08:07, Greg Ungerer wrote:
>>>> On 5/4/22 13:23, Daniel Palmer wrote:
>>>>> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
>>>>>> But we could consider the Dragonball support for removal. I keep it
>>>>>> compiling, but I don't use it and can't test that it actually works.
>>>>>> Not sure that it has been used for a very long time now. And I
>>>>>> didn't even realize but its serial driver (68328serial.c) was
>>>>>> removed in 2015. No one seems too have noticed and complained.
>>>>>
>>>>> I noticed this and I am working on fixing it up for a new Dragonball
>>>>> homebrew machine. I'm trying to add a 68000 machine to QEMU to make
>>>>> the development easier because I'm currently waiting an hour or more
>>>>> for a kernel to load over serial. It might be a few months.
>>>
>>> I've been booting Linux on qemu-system-m68k -M q800 for a couple years
>>> now? (The CROSS=m68k target of mkroot in toybox?)
>>>
>>> # cat /proc/cpuinfo
>>> CPU:		68040
>>> MMU:		68040
>>> FPU:		68040
>>> Clocking:	1261.9MHz
>>> BogoMips:	841.31
>>> Calibration:	4206592 loops
>>>
>>> It certainly THINKS it's got m68000...
>>>
>> 
>> Most 68040 processor variants have a built-in MMU and the m68k "nommu"
>> Linux port doesn't support them. The nommu port covers processors like
>> 68000, Dragonball etc. whereas the m68k "mmu" port covers 680x0 where x is
>> one of 2,3,4,6 with MMU.

In theory you can switch the MMU off. (Or at least give it a NOP page table that
maps all the physical memory into one big contiguous block 1:1 with the physical
address and leave it there.)

Doesn't mean anybody's bothered to implement and add a config option to stub
that out in the kernel yet. But presumably you could have a bootloader shim do it...

>>> (I'd love to get an m68k nommu system working but never sat down and
>>> worked out a kernel .config qemu agreed to run, plus compiler and libc.
>>> Musl added m68k support but I dunno if that includes coldfire?)
>>>
>> 
>> I could never figure out how to boot a coldfire machine in qemu either.
>> There was no documentation about that back when I attempted it but maybe
>> things have improved since.
> 
> FWIW this will do it:
> 
>      qemu-system-m68k -nographic -machine mcf5208evb -kernel vmlinux
> 
> That will boot an m5208evb_defconfig generated vmlinux.
> But you will need a user space to get a full boot to login/shell.

No FDPIC support. :(

I had a binflt toolchain working with uClibc in 2015 or so, but I end of lifed
https://landley.net/aboriginal in 2017 (five years ago now). Multiple reasons,
but one was the old "last GPLv2 release" toolchain was getting painful to force
the kernel to build with.

These days there's articles on lwn.net about yanking a.out support, which fdpic
is a buggy variant of that didn't actually have a maintained elf2flt repository
when I was assembling my toolchain. (I vaguely recall I poked enough people that
somebody picked it up and stuck a repository on github, but Jeff Dionne
explained some fundamental design flaw that had been introduced having to do
with register offsets being calculated in the wrong framework or something?

I don't remember, I lost interest because it's _conceptually_ obsolete. FDPIC is
ELF with a little extra header info, it's clean and potentially even useful on
with-MMU systems as extra ASLR. BINFLT is a.out run through a postprocessing
tool that nominally converts ELF files into the new format but actually needs .o
files from earlier in the process and is kind of an alternate linker except it
doesn't replace the linker... It's layers of ugly.

> Regards
> Greg

Rob

Re: [RFC PULL] remove arch/h8300

[Rob Landley]

On 4/10/22 02:26, Rob Landley wrote:
>> FWIW this will do it:
>> 
>>      qemu-system-m68k -nographic -machine mcf5208evb -kernel vmlinux
>> 
>> That will boot an m5208evb_defconfig generated vmlinux.
>> But you will need a user space to get a full boot to login/shell.
> 
> No FDPIC support. :(

First stab at switching on CONFIG_BINFMT_FDPIC in the coldfire config and adding
enough stuff to shut up the compiler. Maybe it'll let me load a PIE binary?
Dunno yet, but it compiled a vmlinux that booted to the same panic as the
previous one because I haven't fed it an initramfs yet...

I also had to disable CONFIG_ELF_CORE or else the link died with:

m68k-linux-musl-ld: fs/binfmt_elf_fdpic.o: in function `elf_dump_thread_status':
binfmt_elf_fdpic.c:(.text+0x18): undefined reference to `task_user_regset_view'
make: *** [Makefile:1155: vmlinux] Error 1

But when I did THAT it compiled. :)

diff --git a/arch/m68k/include/asm/elf.h b/arch/m68k/include/asm/elf.h
index 3d387ceaea3f..bcb072396640 100644
--- a/arch/m68k/include/asm/elf.h
+++ b/arch/m68k/include/asm/elf.h
@@ -114,4 +114,6 @@ typedef struct user_m68kfp_struct elf_fpregset_t;

 #define ELF_PLATFORM  (NULL)

+#define ELF_FDPIC_CORE_EFLAGS 0
+
 #endif
diff --git a/arch/m68k/include/asm/mmu.h b/arch/m68k/include/asm/mmu.h
index 5c15aacb1370..6f6d83b731ed 100644
--- a/arch/m68k/include/asm/mmu.h
+++ b/arch/m68k/include/asm/mmu.h
@@ -8,6 +8,10 @@ typedef unsigned long mm_context_t;
 #else
 typedef struct {
 	unsigned long		end_brk;
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+        unsigned long           exec_fdpic_loadmap;
+        unsigned long           interp_fdpic_loadmap;
+#endif
 } mm_context_t;
 #endif

diff --git a/arch/m68k/include/uapi/asm/ptrace.h
b/arch/m68k/include/uapi/asm/ptrace.h
index 19a1b9d0d858..869601381f30 100644
--- a/arch/m68k/include/uapi/asm/ptrace.h
+++ b/arch/m68k/include/uapi/asm/ptrace.h
@@ -71,6 +71,10 @@ struct switch_stack {
 #define PTRACE_SETREGS            13
 #define PTRACE_GETFPREGS          14
 #define PTRACE_SETFPREGS          15
+#define PTRACE_GETFDPIC           31
+
+#define PTRACE_GETFDPIC_EXEC      0
+#define PTRACE_GETFDPIC_INTERP    1

 #define PTRACE_GET_THREAD_AREA    25

diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index 4d5ae61580aa..073360aa982c 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -45,7 +45,7 @@ config ARCH_USE_GNU_PROPERTY
 config BINFMT_ELF_FDPIC
 	bool "Kernel support for FDPIC ELF binaries"
 	default y if !BINFMT_ELF
-	depends on (ARM || (SUPERH && !MMU))
+	depends on (ARM || (SUPERH && !MMU) || M68K)
 	select ELFCORE
 	help
 	  ELF FDPIC binaries are based on ELF, but allow the individual load



Rob

Re: [RFC PULL] remove arch/h8300

[Greg Ungerer]

On 10/4/22 17:26, Rob Landley wrote:
> 
> 
> On 4/8/22 23:18, Greg Ungerer wrote:
>>
>> On 9/4/22 11:59, Finn Thain wrote:
>>> On Fri, 8 Apr 2022, Rob Landley wrote:
>>>
>>>> On 4/5/22 08:07, Greg Ungerer wrote:
>>>>> On 5/4/22 13:23, Daniel Palmer wrote:
>>>>>> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
>>>>>>> But we could consider the Dragonball support for removal. I keep it
>>>>>>> compiling, but I don't use it and can't test that it actually works.
>>>>>>> Not sure that it has been used for a very long time now. And I
>>>>>>> didn't even realize but its serial driver (68328serial.c) was
>>>>>>> removed in 2015. No one seems too have noticed and complained.
>>>>>>
>>>>>> I noticed this and I am working on fixing it up for a new Dragonball
>>>>>> homebrew machine. I'm trying to add a 68000 machine to QEMU to make
>>>>>> the development easier because I'm currently waiting an hour or more
>>>>>> for a kernel to load over serial. It might be a few months.
>>>>
>>>> I've been booting Linux on qemu-system-m68k -M q800 for a couple years
>>>> now? (The CROSS=m68k target of mkroot in toybox?)
>>>>
>>>> # cat /proc/cpuinfo
>>>> CPU:		68040
>>>> MMU:		68040
>>>> FPU:		68040
>>>> Clocking:	1261.9MHz
>>>> BogoMips:	841.31
>>>> Calibration:	4206592 loops
>>>>
>>>> It certainly THINKS it's got m68000...
>>>>
>>>
>>> Most 68040 processor variants have a built-in MMU and the m68k "nommu"
>>> Linux port doesn't support them. The nommu port covers processors like
>>> 68000, Dragonball etc. whereas the m68k "mmu" port covers 680x0 where x is
>>> one of 2,3,4,6 with MMU.
> 
> In theory you can switch the MMU off. (Or at least give it a NOP page table that
> maps all the physical memory into one big contiguous block 1:1 with the physical
> address and leave it there.)
> 
> Doesn't mean anybody's bothered to implement and add a config option to stub
> that out in the kernel yet. But presumably you could have a bootloader shim do it...
> 
>>>> (I'd love to get an m68k nommu system working but never sat down and
>>>> worked out a kernel .config qemu agreed to run, plus compiler and libc.
>>>> Musl added m68k support but I dunno if that includes coldfire?)
>>>>
>>>
>>> I could never figure out how to boot a coldfire machine in qemu either.
>>> There was no documentation about that back when I attempted it but maybe
>>> things have improved since.
>>
>> FWIW this will do it:
>>
>>       qemu-system-m68k -nographic -machine mcf5208evb -kernel vmlinux
>>
>> That will boot an m5208evb_defconfig generated vmlinux.
>> But you will need a user space to get a full boot to login/shell.
> 
> No FDPIC support. :(
> 
> I had a binflt toolchain working with uClibc in 2015 or so, but I end of lifed
> https://landley.net/aboriginal in 2017 (five years ago now). Multiple reasons,
> but one was the old "last GPLv2 release" toolchain was getting painful to force
> the kernel to build with.
> 
> These days there's articles on lwn.net about yanking a.out support, which fdpic
> is a buggy variant of that didn't actually have a maintained elf2flt repository
> when I was assembling my toolchain. (I vaguely recall I poked enough people that
> somebody picked it up and stuck a repository on github, but Jeff Dionne
> explained some fundamental design flaw that had been introduced having to do
> with register offsets being calculated in the wrong framework or something?
> 
> I don't remember, I lost interest because it's _conceptually_ obsolete. FDPIC is
> ELF with a little extra header info, it's clean and potentially even useful on
> with-MMU systems as extra ASLR. BINFLT is a.out run through a postprocessing
> tool that nominally converts ELF files into the new format but actually needs .o
> files from earlier in the process and is kind of an alternate linker except it
> doesn't replace the linker... It's layers of ugly.

FLAT format has nothing to do with a.out.
Removing a.out support from the kernel will have no impact on binfmt_flat.

Regards
Greg

Re: [RFC PULL] remove arch/h8300

[Daniel Palmer]

Hi Rob,

On Sat, 9 Apr 2022 at 09:20, Rob Landley <rob@landley.net> wrote:

> I've been booting Linux on qemu-system-m68k -M q800 for a couple years now? (The
> CROSS=m68k target of mkroot in toybox?)
>
> # cat /proc/cpuinfo
> CPU:            68040
> MMU:            68040
> FPU:            68040
> Clocking:       1261.9MHz
> BogoMips:       841.31
> Calibration:    4206592 loops
>
> It certainly THINKS it's got m68000...

I couldn't work out how to define a mc68000 machine on the command line alone.
There might be a way but it didn't seem like it.

> (I'd love to get an m68k nommu system working but never sat down and worked out
> a kernel .config qemu agreed to run, plus compiler and libc. Musl added m68k
> support but I dunno if that includes coldfire?)

Once I get QEMU to emulate a simple mc68000 system my plan is to get
u-boot going (I managed to get it to build for plain mc68000 but I
didn't get far enough with the QEMU bit to try booting it yet) then
put together the buildroot configs to build qemu, u-boot, a kernel and
rootfs that just work. Then I can hook it into CI and have it build
and boot test automatically and it won't bit rot anymore.

> >> It looked like 68328serial.c was removed because someone tried to
> >> clean it up and it was decided that no one was using it and it was
> >> best to delete it.
> >> My plan was to at some point send a series to fix up the issues with
> >> the Dragonball support, revert removing the serial driver and adding
> >> the patch that cleaned it up.
> >
> > Nice. I will leave all the 68000/68328 code alone for now then.
>
> The q800 config uses CONFIG_SERIAL_PMACZILOG. Seems to work fine?

Dragonball uses a weird UART that doesn't seem to be compatible with
any of the common ones so it needs its own driver.

Cheers,

Daniel

Re: [RFC PULL] remove arch/h8300

[Rob Landley]

On 4/8/22 22:37, Daniel Palmer wrote:
> Hi Rob,
> 
> On Sat, 9 Apr 2022 at 09:20, Rob Landley <rob@landley.net> wrote:
> 
>> I've been booting Linux on qemu-system-m68k -M q800 for a couple years now? (The
>> CROSS=m68k target of mkroot in toybox?)
>>
>> # cat /proc/cpuinfo
>> CPU:            68040
>> MMU:            68040
>> FPU:            68040
>> Clocking:       1261.9MHz
>> BogoMips:       841.31
>> Calibration:    4206592 loops
>>
>> It certainly THINKS it's got m68000...
> 
> I couldn't work out how to define a mc68000 machine on the command line alone.
> There might be a way but it didn't seem like it.

By adding "-cpu m68000" to the qemu command line?

The problem is you need a working _system_. If you wget
http://landley.net/toybox/downloads/binaries/mkroot/latest/m68k.tgz and extract
it and run
./qemu-m68k.sh it boots to a shell prompt. If you "./qemu-m68k.sh -cpu m68000"
it doesn't boot because the kernel is built for 68040.

>> (I'd love to get an m68k nommu system working but never sat down and worked out
>> a kernel .config qemu agreed to run, plus compiler and libc. Musl added m68k
>> support but I dunno if that includes coldfire?)
> 
> Once I get QEMU to emulate a simple mc68000 system my plan is to get
> u-boot going (I managed to get it to build for plain mc68000 but I
> didn't get far enough with the QEMU bit to try booting it yet) then
> put together the buildroot configs to build qemu, u-boot, a kernel and
> rootfs that just work. Then I can hook it into CI and have it build
> and boot test automatically and it won't bit rot anymore.

I don't bother with buildroot much, I wrote a 300 line bash script that builds a
bootable Linux system instead:

  https://github.com/landley/toybox/blob/master/scripts/mkroot.sh

As for adding coldfire support, let's see... google for "qemu coldfire" first
hit is https://qemu.readthedocs.io/en/latest/system/target-m68k.html which says
the default board in qemu-system-m68k is coldfire and has run uclinux. There's a
defconfig for it (arch/m68k/configs/m5208evb_defconfig) so:

$ make ARCH=m68k m5208evb_defconfig
...
$ CROSS_COMPILE=m68k-linux-musl- make ARCH-m68k
...
$ qemu-system-m68k -nographic -kernel vmlinux

Hey, console output on serial using my existing m68k toolchain. Good sign. Ok,
let's see, can I get a userspace...

No, I can't. The coldfire kernel only supports BINFLT, which is an a.out
derivative. All the nommu targets I'm supporting are either FDPIC or (where gcc
hasn't merged fdpic support yet) I'm building static pie and using the FDPIC
loader in the kernel, which can load normal ELF: FDPIC makes the 4
bss/data/text/rodata sections independently relocatable and static PIE has those
4 glued together into one contiguous lump but at least that lump is relocatable,
so it's a lot worse about fragmentation but does at least RUN...

If I can't wire up the fdpic loader for coldfire, I can't build ELF format
binaries for it, and I just don't mess with a.out anymore.

>> >> It looked like 68328serial.c was removed because someone tried to
>> >> clean it up and it was decided that no one was using it and it was
>> >> best to delete it.
>> >> My plan was to at some point send a series to fix up the issues with
>> >> the Dragonball support, revert removing the serial driver and adding
>> >> the patch that cleaned it up.
>> >
>> > Nice. I will leave all the 68000/68328 code alone for now then.
>>
>> The q800 config uses CONFIG_SERIAL_PMACZILOG. Seems to work fine?
> 
> Dragonball uses a weird UART that doesn't seem to be compatible with
> any of the common ones so it needs its own driver.

Indeed.

That said, the 5208 is using CONFIG_SERIAL_MCF and I got serial output from the
kernel I just built. Pity it hasn't got FDPIC support...

> Cheers,
> 
> Daniel

Rob

Re: [RFC PULL] remove arch/h8300

[Greg Ungerer]

On 9/4/22 10:24, Rob Landley wrote:
> On 4/5/22 08:07, Greg Ungerer wrote:
>> On 5/4/22 13:23, Daniel Palmer wrote:
>>> On Mon, 4 Apr 2022 at 22:42, Greg Ungerer <gerg@linux-m68k.org> wrote:
>>>> But we could consider the Dragonball support for removal. I keep it compiling,
>>>> but I don't use it and can't test that it actually works. Not sure that it
>>>> has been used for a very long time now. And I didn't even realize but its
>>>> serial driver (68328serial.c) was removed in 2015. No one seems too have
>>>> noticed and complained.
>>>
>>> I noticed this and I am working on fixing it up for a new Dragonball
>>> homebrew machine.
>>> I'm trying to add a 68000 machine to QEMU to make the development
>>> easier because I'm currently waiting an hour or more for a kernel to
>>> load over serial.
>>> It might be a few months.
> 
> I've been booting Linux on qemu-system-m68k -M q800 for a couple years now? (The
> CROSS=m68k target of mkroot in toybox?)
> 
> # cat /proc/cpuinfo
> CPU:		68040
> MMU:		68040
> FPU:		68040
> Clocking:	1261.9MHz
> BogoMips:	841.31
> Calibration:	4206592 loops
> 
> It certainly THINKS it's got m68000...
> 
> $ qemu-system-m68k -cpu ?
> cfv4e
> m5206
> m5208
> m68000
> m68010
> m68020
> m68030
> m68040
> m68060
> any
> 
> (I'd love to get an m68k nommu system working but never sat down and worked out
> a kernel .config qemu agreed to run, plus compiler and libc. Musl added m68k
> support but I dunno if that includes coldfire?)

I run and test all development rc and release kernels on the qemu m5208 target
(that is a ColdFire v2 nommu core, the "-machine mcf5208evb" qemu target).
Of course I test real hardware as well :-)

The kernel's m5208evb_defconfig works for qemu. Though you will need to sort
out a user space to get to a login/shell. I mostly use the last uClibc for
that.



>>> It looked like 68328serial.c was removed because someone tried to
>>> clean it up and it was decided that no one was using it and it was
>>> best to delete it.
>>> My plan was to at some point send a series to fix up the issues with
>>> the Dragonball support, revert removing the serial driver and adding
>>> the patch that cleaned it up.
>>
>> Nice. I will leave all the 68000/68328 code alone for now then.
> 
> The q800 config uses CONFIG_SERIAL_PMACZILOG. Seems to work fine?

Sure, but the Dragonball are a 68328 SoC family. Its serial hardware block
is different, needs a different driver. At least all the ColdFire parts
use the same internal hardware serial block.

Regards
Greg

Re: [RFC PULL] remove arch/h8300

[Max Filippov]

Hi Arnd,

On Mon, Apr 4, 2022 at 6:07 AM Arnd Bergmann <arnd@arndb.de> wrote:
> 1. xtensa nommu has does not compile in mainline and as far as I can
> tell never did

I have a different picture here. If you look at the logs at
  https://kerneltests.org/builders/qemu-xtensa-master/

there's a line for noMMU config in every one of them:
  Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running
............ passed

Please let me know if you observe any specific build/runtime issues.

-- 
Thanks.
-- Max

Re: [RFC PULL] remove arch/h8300

[Arnd Bergmann]

On Mon, Apr 4, 2022 at 7:57 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
>
> Hi Arnd,
>
> On Mon, Apr 4, 2022 at 6:07 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > 1. xtensa nommu has does not compile in mainline and as far as I can
> > tell never did
>
> I have a different picture here. If you look at the logs at
>   https://kerneltests.org/builders/qemu-xtensa-master/
>
> there's a line for noMMU config in every one of them:
>   Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running
> ............ passed
>
> Please let me know if you observe any specific build/runtime issues.

This is what I get:

$ make ARCH=xtensa O=build/xtensa nommu_kc705_defconfig vmlinux V=1
....
xtensa-linux-gcc-11.1.0 -DKCONFIG_SEED=
-Wp,-MMD,arch/xtensa/kernel/.head.o.d -nostdinc
-I/git/arm-soc/arch/xtensa/include -I./arch/xtensa/include/generated
-I/git/arm-soc/include -I./include
-I/git/arm-soc/arch/xtensa/include/uapi
-I./arch/xtensa/include/generated/uapi -I/git/arm-soc/include/uapi
-I./include/generated/uapi -include
/git/arm-soc/include/linux/compiler-version.h -include
/git/arm-soc/include/linux/kconfig.h -D__KERNEL__
-I/git/arm-soc/arch/xtensa/variants/de212/include
-I/git/arm-soc/arch/xtensa/platforms/xtfpga/include
-fmacro-prefix-map=/git/arm-soc/= -D__ASSEMBLY__ -fno-PIE -mlongcalls
-mtext-section-literals -Wa,--fatal-warnings -I
/git/arm-soc/arch/xtensa/kernel -I ./arch/xtensa/kernel    -c -o
arch/xtensa/kernel/head.o /git/arm-soc/arch/xtensa/kernel/head.S
/git/arm-soc/arch/xtensa/kernel/head.S: Assembler messages:
/git/arm-soc/arch/xtensa/kernel/head.S:87: Error: invalid register
'atomctl' for 'wsr' instruction

I think there were other errors in the past, but every time I tried
it, the build failed for me.

        Arnd

Re: [RFC PULL] remove arch/h8300

[Max Filippov]

On Mon, Apr 4, 2022 at 12:01 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Apr 4, 2022 at 7:57 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> > Please let me know if you observe any specific build/runtime issues.
>
> This is what I get:
>
> $ make ARCH=xtensa O=build/xtensa nommu_kc705_defconfig vmlinux V=1
> ....
> xtensa-linux-gcc-11.1.0 -DKCONFIG_SEED=
...
> /git/arm-soc/arch/xtensa/kernel/head.S: Assembler messages:
> /git/arm-soc/arch/xtensa/kernel/head.S:87: Error: invalid register
> 'atomctl' for 'wsr' instruction

Sure, one cannot use an arbitrary xtensa compiler for the kernel
build, the compiler configuration must match the core variant selected
in the linux configuration. Specifically, for the nommu_kc705_defconfig
the following compiler can be used:

https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-de212-elf.tar.gz

If you build the toolchain yourself using crosstool-ng or buildroot they
accept the 'configuration overlay' parameter that does the compiler
customization.

Perhaps the documentation for this part is what needs to be improved.

> I think there were other errors in the past, but every time I tried
> it, the build failed for me.

-- 
Thanks.
-- Max

Re: [RFC PULL] remove arch/h8300

[Arnd Bergmann]

On Mon, Apr 4, 2022 at 9:14 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Mon, Apr 4, 2022 at 12:01 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Mon, Apr 4, 2022 at 7:57 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> > > Please let me know if you observe any specific build/runtime issues.
> > xtensa-linux-gcc-11.1.0 -DKCONFIG_SEED=
> ...
> > /git/arm-soc/arch/xtensa/kernel/head.S: Assembler messages:
> > /git/arm-soc/arch/xtensa/kernel/head.S:87: Error: invalid register
> > 'atomctl' for 'wsr' instruction
>
> Sure, one cannot use an arbitrary xtensa compiler for the kernel
> build, the compiler configuration must match the core variant selected
> in the linux configuration. Specifically, for the nommu_kc705_defconfig
> the following compiler can be used:
>
> https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-de212-elf.tar.gz
>
> If you build the toolchain yourself using crosstool-ng or buildroot they
> accept the 'configuration overlay' parameter that does the compiler
> customization.
>
> Perhaps the documentation for this part is what needs to be improved.

It sounds like a bug in the kernel Makefile. On all other architectures,
you can generally just pick any (recent) compiler and build any kernel,
as the compiler arguments set the exact target machine type based
on the kernel config. You can't normally rely on the compiler defaults
for kernel builds.

         Arnd

Re: [RFC PULL] remove arch/h8300

[Arnd Bergmann]

On Mon, Apr 4, 2022 at 9:35 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Apr 4, 2022 at 9:14 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> > On Mon, Apr 4, 2022 at 12:01 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Mon, Apr 4, 2022 at 7:57 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> > > > Please let me know if you observe any specific build/runtime issues.
> > > xtensa-linux-gcc-11.1.0 -DKCONFIG_SEED=
> > ...
> > > /git/arm-soc/arch/xtensa/kernel/head.S: Assembler messages:
> > > /git/arm-soc/arch/xtensa/kernel/head.S:87: Error: invalid register
> > > 'atomctl' for 'wsr' instruction
> >
> > Sure, one cannot use an arbitrary xtensa compiler for the kernel
> > build, the compiler configuration must match the core variant selected
> > in the linux configuration. Specifically, for the nommu_kc705_defconfig
> > the following compiler can be used:
> >
> > https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-de212-elf.tar.gz
> >
> > If you build the toolchain yourself using crosstool-ng or buildroot they
> > accept the 'configuration overlay' parameter that does the compiler
> > customization.
> >
> > Perhaps the documentation for this part is what needs to be improved.
>
> It sounds like a bug in the kernel Makefile. On all other architectures,
> you can generally just pick any (recent) compiler and build any kernel,
> as the compiler arguments set the exact target machine type based
> on the kernel config. You can't normally rely on the compiler defaults
> for kernel builds.

FWIW, the compiler I used is the one I built for kernel.org [1] using unmodified
upstream sources The config I used for this is

${SRCTREE}/configure ../log-gcc-configure /home/arnd/git/gcc/configure
--target=xtensa-linux --enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-11.1.0-nolibc/xtensa-linux
--enable-languages=c --without-headers --disable-bootstrap
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --disable-libatomic --disable-libcc1
--disable-libmpx --enable-checking=release

Let me know if I need to enable additional options to get a compiler
that works for all xtensa targets. Usually the --enable-targets=all
is meant to be sufficient.

        Arnd

[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/

Re: [RFC PULL] remove arch/h8300

[Max Filippov]

On Mon, Apr 4, 2022 at 12:44 PM Arnd Bergmann <arnd@arndb.de> wrote:
> Let me know if I need to enable additional options to get a compiler
> that works for all xtensa targets. Usually the --enable-targets=all
> is meant to be sufficient.

This is not possible with the current design of the xtensa toolchain port.
There's an effort to make switching between the core configurations easy
(without the whole toolchain rebuild:
 https://github.com/jcmvbkbc/xtensa-dynconfig
 https://github.com/jcmvbkbc/gcc-xtensa/tree/xtensa-dynconfig
 https://github.com/jcmvbkbc/binutils-gdb-xtensa/tree/xtensa-plugin-env ),
but it still involves building plugins for the parts of the toolchain
for each new xtensa core.

-- 
Thanks.
-- Max

Re: [RFC PULL] remove arch/h8300

[Max Filippov]

On Mon, Apr 4, 2022 at 12:36 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Apr 4, 2022 at 9:14 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> > On Mon, Apr 4, 2022 at 12:01 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Mon, Apr 4, 2022 at 7:57 PM Max Filippov <jcmvbkbc@gmail.com> wrote:
> > > > Please let me know if you observe any specific build/runtime issues.
> > > xtensa-linux-gcc-11.1.0 -DKCONFIG_SEED=
> > ...
> > > /git/arm-soc/arch/xtensa/kernel/head.S: Assembler messages:
> > > /git/arm-soc/arch/xtensa/kernel/head.S:87: Error: invalid register
> > > 'atomctl' for 'wsr' instruction
> >
> > Sure, one cannot use an arbitrary xtensa compiler for the kernel
> > build, the compiler configuration must match the core variant selected
> > in the linux configuration. Specifically, for the nommu_kc705_defconfig
> > the following compiler can be used:
> >
> > https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-de212-elf.tar.gz
> >
> > If you build the toolchain yourself using crosstool-ng or buildroot they
> > accept the 'configuration overlay' parameter that does the compiler
> > customization.
> >
> > Perhaps the documentation for this part is what needs to be improved.
>
> It sounds like a bug in the kernel Makefile. On all other architectures,
> you can generally just pick any (recent) compiler and build any kernel,
> as the compiler arguments set the exact target machine type based
> on the kernel config. You can't normally rely on the compiler defaults
> for kernel builds.

It's not just the defaults. The binary instruction encoding is configurable
on the xtensa architecture, configuration overlay replaces parts of
the toolchain that do that.
The additional CPU state is configurable and the kernel gets customized
with the code that loads and stores this state when someone builds it for
a specific xtensa core.
These customizations are done by the users of the xtensa architecture and
there are hundreds of configurations in existence. The toolchain has never
been supposed to support all of them at once.

-- 
Thanks.
-- Max

Re: [RFC PULL] remove arch/h8300

[Damien Le Moal]

On 4/4/22 22:07, Arnd Bergmann wrote:
> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
>>> If there are no other objections, I'll just queue this up for 5.18 in
>>> the asm-generic
>>> tree along with the nds32 removal.
>>
>> So it is the last day of te merge window and arch/h8300 is till there.
>> And checking nw the removal has also not made it to linux-next.  Looks
>> like it is so stale that even the removal gets ignored :(
> 
> I was really hoping that someone else would at least comment.
> I've queued it up now for 5.19.
> 
> Should we garbage-collect some of the other nommu platforms where
> we're here? Some of them are just as stale:
> 
> 1. xtensa nommu has does not compile in mainline and as far as I can
> tell never did
>    (there was https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.6-esp32,
> which
>    worked at some point, but I don't think there was enough interest
> to get in merged)
> 
> 2. arch/sh Hitachi/Renesas sh2 (non-j2) support appears to be in a similar state
>     to h8300, I don't think anyone would miss it
> 
> 8<----- This may we where we want to draw the line ----
> 
> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
> changes, but I think
>     Rich still cares about it and wants to add J32 support (with MMU)
> in the future
> 
> 4. m68k Dragonball, Coldfire v2 and Coldfire v3 are just as obsolete as SH2 as
>    hardware is concerned, but Greg Ungerer keeps maintaining it, along with the
>    newer Coldfire v4 (with MMU)
> 
> 5. K210 was added in 2020. I assume you still want to keep it.

Still working on this one, I would like to keep it.

> 
> 7. Arm32 has several Cortex-M based platforms that are mainly kept for
>     legacy users (in particular stm32) or educational value.
> 
> 
>        Arnd
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


-- 
Damien Le Moal
Western Digital Research

Re: [RFC PULL] remove arch/h8300

[Guenter Roeck]

On Mon, Apr 04, 2022 at 03:07:06PM +0200, Arnd Bergmann wrote:
> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Mar 08, 2022 at 09:19:16AM +0100, Arnd Bergmann wrote:
> > > If there are no other objections, I'll just queue this up for 5.18 in
> > > the asm-generic
> > > tree along with the nds32 removal.
> >
> > So it is the last day of te merge window and arch/h8300 is till there.
> > And checking nw the removal has also not made it to linux-next.  Looks
> > like it is so stale that even the removal gets ignored :(
> 
> I was really hoping that someone else would at least comment.
> I've queued it up now for 5.19.
> 
> Should we garbage-collect some of the other nommu platforms where
> we're here? Some of them are just as stale:
> 
> 1. xtensa nommu has does not compile in mainline and as far as I can
> tell never did
>    (there was https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.6-esp32,
> which
>    worked at some point, but I don't think there was enough interest
> to get in merged)

Hmm, I build and test nommu_kc705_defconfig in my test system.

> 
> 2. arch/sh Hitachi/Renesas sh2 (non-j2) support appears to be in a similar state
>     to h8300, I don't think anyone would miss it
> 
> 8<----- This may we where we want to draw the line ----
> 
> 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
> changes, but I think
>     Rich still cares about it and wants to add J32 support (with MMU)
> in the future
> 
> 4. m68k Dragonball, Coldfire v2 and Coldfire v3 are just as obsolete as SH2 as
>    hardware is concerned, but Greg Ungerer keeps maintaining it, along with the
>    newer Coldfire v4 (with MMU)
> 
> 5. K210 was added in 2020. I assume you still want to keep it.
> 
> 7. Arm32 has several Cortex-M based platforms that are mainly kept for
>     legacy users (in particular stm32) or educational value.
> 
I do build and test mps2_defconfig with qemu's mps2-an385 emulation.

I am not saying that those are actively used, and I don't mind dropping
them, but they do still work.

Guenter

Re: [RFC PULL] remove arch/h8300

[Arnd Bergmann]

On Tue, Apr 5, 2022 at 11:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Apr 04, 2022 at 03:07:06PM +0200, Arnd Bergmann wrote:
> >
> > Should we garbage-collect some of the other nommu platforms where
> > we're here? Some of them are just as stale:
> >
> > 1. xtensa nommu has does not compile in mainline and as far as I can
> > tell never did
> >    (there was https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.6-esp32,
> > which
> >    worked at some point, but I don't think there was enough interest
> > to get in merged)
>
> Hmm, I build and test nommu_kc705_defconfig in my test system.

What toolchain do you use for this? Max already pointed out my mistake
regarding xtensa, which I thought does not build at all, but just needs
a toolchain specific to the cpu.

> > 2. arch/sh Hitachi/Renesas sh2 (non-j2) support appears to be in a similar state
> >     to h8300, I don't think anyone would miss it
> >
> > 8<----- This may we where we want to draw the line ----
> >
> > 3. arch/sh j2 support was added in 2016 and doesn't see a lot of
> > changes, but I think
> >     Rich still cares about it and wants to add J32 support (with MMU)
> > in the future
> >
> > 4. m68k Dragonball, Coldfire v2 and Coldfire v3 are just as obsolete as SH2 as
> >    hardware is concerned, but Greg Ungerer keeps maintaining it, along with the
> >    newer Coldfire v4 (with MMU)
> >
> > 5. K210 was added in 2020. I assume you still want to keep it.
> >
> > 7. Arm32 has several Cortex-M based platforms that are mainly kept for
> >     legacy users (in particular stm32) or educational value.
> >
> I do build and test mps2_defconfig with qemu's mps2-an385 emulation.
>
> I am not saying that those are actively used, and I don't mind dropping
> them, but they do still work.

To clarify, the list was sorted based on what I expected to be the least to
most actively maintained ones, with the stm32 clearly being in use,
and above it in the the list somewhat less.

         Arnd

Re: [RFC PULL] remove arch/h8300

[Guenter Roeck]

On 4/5/22 15:01, Arnd Bergmann wrote:
> On Tue, Apr 5, 2022 at 11:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On Mon, Apr 04, 2022 at 03:07:06PM +0200, Arnd Bergmann wrote:
>>>
>>> Should we garbage-collect some of the other nommu platforms where
>>> we're here? Some of them are just as stale:
>>>
>>> 1. xtensa nommu has does not compile in mainline and as far as I can
>>> tell never did
>>>     (there was https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-5.6-esp32,
>>> which
>>>     worked at some point, but I don't think there was enough interest
>>> to get in merged)
>>
>> Hmm, I build and test nommu_kc705_defconfig in my test system.
> 
> What toolchain do you use for this? Max already pointed out my mistake
> regarding xtensa, which I thought does not build at all, but just needs
> a toolchain specific to the cpu.
> 

Home-built using buildroot. I have three different xtensa toolchains
(de212, dc232b, and dc233c). The toolchain for kc705_nommu needs the
de212 overlay; I think Max pointed to to the information needed
to build the compiler. Buildroot has the "XTENSA_OVERLAY_FILE"
option to specify the compiler overlay file for the target.

Guenter