[J-core] Port Idea: Little Kernel

[Rob Landley]

On 11/04/2017 06:20 AM, John Paul Adrian Glaubitz wrote:
> On 11/04/2017 11:51 AM, D. Jeff Dionne wrote:
>> The tool chain meanwhile is very mature, and actively maintained. Please use the
>> musl cross make (last check in: Wednesday) https://github.com/richfelker/musl-cross-make
>> to build it.  Any regressions or build breaks for the J-Core target can be posted here,
>> or direct to the maintainer, who is also the arch kernel maintainer...
> 
> This is also using gcc which is effectively unmaintained for SH at the moment,

Rich pushed gcc patches upstream to add proper fdpic support and has his
own patch collection in musl-cross-make for newer versions.

https://github.com/richfelker/musl-cross-make/tree/master/patches

Keep in mind the current release of j2 is nommu, because current
products for current customers are doing hard realtime signal
processing. We asked about a debian nommu port to j-core a while back
and the answer was "not without an mmu".

> so I don't know how this is going to help with upstream gcc bugs.

We haven't upgraded to new gcc versions (even gcc 7.2 in mcm is a
selectable option we haven't selected in our local toolchains yet), so
we're not seeing regressions they may have introduced.

Longer-term we vaguely plan to move to llvm the same way Apple and
Android have.

> The bugs are
> there, they remain unfixed for months as both Oleg and Kaz don't seem to be
> interested anymore.

First I've heard of these bugs, and you still haven't said what they
are. Maybe Rich knows?

>> I think it likely that the J-Core / SH kernel maintainers may have missed
>> your patches on the kernel list.
> 
> The official kernel maintainers are both Rich Felker and Yoshinori Sato, both
> haven't reviewed any patches sent to linux-sh for several months.

Yes, I poked Rich about that on a phone call two weeks ago, he said he'd
try to clear some time to catch up when the new merge window opened.
(He's never quite caught back up since his house fire, he and his family
were living in a hotel for several weeks and have been catching back up
with everything since. He _just_ got a musl-libc release out on October
19th, the last one before that was December 2016.)

The last time I posted to the linux-sh list was last week:

  http://www.spinics.net/lists/linux-sh/msg51709.html

I haven't seen sato-san since last November, but I follow him on twitter
and since I'm in Tokyo this month I'm trying to arrange a lunch with him
to say hi:

  https://twitter.com/ysat0/status/927505336704974848

> I have briefly
> talked to Yoshinori and he would only answer me when I wrote him in Japanese,
> he said would return to kernel development in summer which didn't happen.

His English is better than my Japanese, but I bring coworkers who speak
japanese along to the lunches. Easier for both of us. :)

>> Please post them here... Rich, Rob and Jeff read this list, at least most of the time.
>> (To reiterate, we develop this stuff and on thus stuff every day at our day jobs).
> 
> Work on gcc and the kernel should happen on the appropriate lists, not somewhere
> hidden in the dark.

It's not hidden in the dark to us. I have a local kernel patch (to fix
the qemu serial stuff on sh4) I've posted more than once, but it's not
_how_ they wanted to fix it. My toybox project doesn't use threads and
thus futexes (design decision); it's blocking me getting "make" running
on the board for native toolchains but incomplete qemu support's the
real issue there for me.

We post gcc work when we do gcc work, we just haven't needed to for
j-core recently. (Rich proposed an update to the fdpic format last
month, but hasn't formally written it up yet.) The version we have works
for the packages we build on it, and this is the first I've heard of the
issues you're raising.

> Other kernel developers expect their patches for SuperH
> to be reviewed on the linux-sh LKML, not here.

Have you seen a kernel patch reviewed here in the past year? The
archive's open, point me at a link please.

> Again, lots of patches are sent and remain without review.

I know, I dinged Rich about it a couple weeks ago.

> If this happens too often, I'm afraid the
> kernel developers will mark the SuperH port as unmaintained again
> with the risk of it getting eventually removed from the kernel.

More or less what I said to Rich on the phone, yes.

That said, I tested the current git snapshot du jour on my Turtle board
back in Austin (circa -rc4 I think) and it ran. My own lkml engagement
has been things more like the CONFIG_DEVTMPFS_AUTOMOUNT thing (which
triggered a debian bug), I need to reopen that can of worms next merge
window:
http://lkml.iu.edu/hypermail/linux/kernel/1709.2/02400.html

And the stupid exclusion logic on the new ping api (blah, thunderbird
crashed a few days ago and I lost the reply window, I should continue
this thread):
http://lkml.iu.edu/hypermail/linux/kernel/1710.3/04715.html

And a long thread this week in which Linus participated about another
toybox issue:
http://lkml.iu.edu/hypermail/linux/kernel/1711.0/00942.html

We haven't exactly been idle...

> To reiterate from my side: Both upstream gcc and kernel for SH are currently
> effectively unmaintained. And if it wasn't for me maintaining Debian's sh4
> port, the whole Linux SuperH port would have probably been dead long ago.

You are railing at i386 developers about the sad state of x86-64. I
sympathize. We plan to enter that space, but we're not there yet.

This list is about an open source _hardware_ project, written in VHDL.
The hardware we've already released runs Linux, but not Debian.

One of the topics for this trip to Japan is getting the mmu development
funded, staffed, and scheduled. We're also talking about asic, turtle,
and gps stuff we've been distracted from by some other work that finally
wrapped up in October.

As with Rich's house fire or my house flooding before that we mostly
haven't talked about that stuff here because it's not relevant to the
open source project, except for its impact on the amount of time we have
to put into it.

> If anyone on this list wants J-Core to be maintained on Linux, you should start
> helping with my efforts both in Debian and upstream.

Debian is a glibc distro, j-core hasn't got a glibc port yet because
glibc has historically had zero interest in nommu. Last I checked,
Debian doesn't have a musl-libc version for any target yet. (We also
used to run uClibc before that project died, but debian hasn't got one
of those either, and that was using even older gcc/binutils versions.)

I would love to help with a Debian port to j-core. I think the first
step would be a musl-libc version on an existing target, like x86 (or
sh4, but qemu really needs a board emulation that can support more than
64 megs ram there. We added device tree support to sh4 _for_ j-core, but
the existing sh4 boards haven't been migrated over (Rich had sh4 test
hardware before the fire, not sure about now), and then qemu would need
to be made aware of it to benefit...)

> Adrian

Rob