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@xxxxxxxx> wrote:
>> On Sun, Apr 3, 2022 at 2:43 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> 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