Re: [PATCH] Fix J-core aic warning spam

On 5/3/23 03:32, John Paul Adrian Glaubitz wrote:
> Hi Rob!
> 
> On Sat, 2023-04-29 at 22:45 -0500, Rob Landley wrote:
>> On 4/29/23 15:07, John Paul Adrian Glaubitz wrote:
>> > Hi Rob!
>> > 
>> > On Wed, 2023-04-19 at 20:24 -0500, Rob Landley wrote:
>> > > J-core binary toolchain tarball:
>> > > 
>> > > https://landley.net/toybox/downloads/binaries/toolchains/latest/sh2eb-linux-muslfdpic-cross.tar.xz
>> > 
>> > OK, I can actually build a J2 kernel with that. Are there instructions somewhere which explain
>> > how to boot such a kernel on a Turtle board? Then I can give it a try on my personal one.
>> 
>> Just copy the vmlinux file to "vmlinux" on the sd card. (It needs an initramfs,
>> or in theory a built-in kernel command line from kconfig doing the root= thing,
>> but either way you should get serial output on the usb with something like "sudo
>> busybox microcom -s 115200 /dev/ttyACM0".)
> 
> Thanks. I found my J2 board in the meantime.

Woo!

>> I built 6.3 with toybox's mkroot.sh and booted it on the board, although that
>> was with a 10 patch stack in my tree. Only four of which are j-core related: one
>> is the boot warning spam, of them adds the ugly ethernet driver, one makes uio
>> work on nommu, and one adds support for a variable clock base because we plugged
>> in some peripheral hardware that wasn't clocked in base 10 back in
>> https://landley.net/notes-2020.html#04-11-2020 and... here, lemme just fling it
>> all up github:
>> 
>>   https://github.com/landley/linux/commits/turtle-v6.3
> 
> We should get as many of these patches upstreamed as possible.

I'm all for it, and am very happy to hand patches off to people who can deal
with them, but I'm not personally very good at navigating the process of what
linux-kernel has become:

  https://landley.net/notes-2023.html#22-02-2023

I still feel guilty about not having replied to Andrew yet, but I dunno what to
_say_:

  https://landley.net/notes-2023.html#24-02-2023

Oh, that ncp cleanup patch should also remove SMB_SUPER_MAGIC which went away in
commit 939cbe5af5fb and USBDEVICE_SUPER_MAGIC which went away in commit
fb28d58b72aa. Those symbols _also_ went away more than 10 years ago. Whole lot
of dusty corners in this codebase nobody's bothered to clean them out in forever
because touching linux-kernel actively unpleasant, so people who might otherwise
speak up about the references to 2.1 and 2.2 kernel versions being maybe a bit
stale in
https://github.com/torvalds/linux/blob/v6.3/Documentation/filesystems/proc.rst#:~:text=may%20change%20slightly
don't think engaging with linux-kernel is worth it. (That whole "with enough
eyeballs all bugs are shallow" thing assumes you have participation from people
outside the core group. Which stops working when your community actively drives
them away...)

*shrug* I can respin the patch if you think it's worth trying? Last time I did
something similar I had to argue with people whose entire argument was "change
bad, accumulting cruft endlessly has no downsides":

  https://www.mail-archive.com/[email protected]/msg1102436.html

Which is odd because as the linux-kernel community ages and shrinks it's been
throwing multiple entire drivers overboard:

  http://www.phoronix.com/news/Linux-Disabling-RNDIS-Drivers
  https://fosstodon.org/@kernellogger/109697090093536263

But "change from outsider, bad!" and "we've driven too many developers away to
maintain the existing code" only conflict if you think that a shrinking clique
circling the wagons is a problem I guess. (I admit to bias on this one...)

> I will also continue reviewing old patches from the mailing list, I already
> assembled a list of older patches many of which have not been applied.

Cool, thanks. Some of the branches in Rich's repository have more, and I can dig
through my linux junk drawer here if your backlog runs low. :)

> If possible, the original author of the various J2 patches should post them
> for review.

I believe all the j2-specific kernel patches that weren't authored by me, Rich,
or Jeff have already gone in. Kernel patches from other people in our stacks
were generally saved from this list or lkml in the first place.

In my 6.3 patch stack, 1-6 are from me, 7 was from rich, 8 was Jeff and Rich, 9
is disgusting and shouldn't go in yet (only about 1/3 of that ethernet driver is
relevant), and 10 is a one line yank of an unnecessary config constraint with
explanation (done by Rich I think, we use uio on a nommu board to talk to
bespoke USB 2.0 hardware, among other things; I dunno what the unsupported
mmap() he mentioned would try to do on nommu but assuming it doesn't panic the
kernel we're fine because only a subset of the possible mmap options are _ever_
available on nommu (you can MAP_SHARED but not MAP_PRIVATE on files, anonymous
could theoretically MA_PRIVATE with range registers but I don't think any linux
port supports them?), so mmap not working for this isn't unusual in that context.)

>> > Do you know who authored these patches?
>> 
>> I think some came from Sato-san and the rest from Rich, but I'm not 100% sure?
>> Rich has been the one maintaining them, and Jeff before that.
>> 
>> https://github.com/richfelker/musl-cross-make/commits/master/patches/gcc-5.3.0/0004-j2.diff
>> implies that the patch came from Patrick Oppenlander, who sounds familiar?
>> https://github.com/pattop
> 
> Doesn't ring a bell at the moment.

He's around. He's contributed to toybox and musl and gcc on and off for years:

http://lists.landley.net/pipermail/toybox-landley.net/2017-September/017217.html
https://git.musl-libc.org/cgit/musl/commit/?id=a0d64dccbc8d
https://gcc.gnu.org/legacy-ml/gcc-help/2011-04/msg00067.html

And here's him offering a kernel signed-off-by:

https://lore.kernel.org/all/[email protected]/T/

>> > We should get these merged upstream which should be
>> > easier these days since the FSF has lowered the barriers regarding the copyright assignment.
>> 
>> I'm all for it. Jeff had some more pending todo fixes for the toolchain that he
>> might want to sweep up into such a push.
> 
> Jeff, your turn, please ;-).
> 
>> Me, I want to switch over to llvm but Jeff thinks its optimizer is still
>> terrible for embedded systems. But then I've heard it had some pretty bad
>> regressions 12.0 to, so...
> 
> While SuperH/J2 is not an official LLVM target, there is actually an LLVM toolchain
> for J2, see:
> 
>> https://github.com/francisvm/j2-llvm

Yeah, I know. Alas, work on it stopped when the developer was hired by Apple:

  https://www.linkedin.com/in/francisvm/

That's actually the _second_ superh LLVM port I'm aware of, but we couldn't
convince Renesas to release theirs and it was kinda stale by that point anyway...

There's been some version skew since, but it doesn't look _that_ hard. Just... a
can of worms we've all been to busy with the other plates we're spinning to open.

>> I'm still using 9.4 because when I tried to build 11.2 back in February it went:
>> 
>> sh2eb-linux-muslfdpic/src_gcc/libstdc++-v3/../libgcc/unwind-pe.h:270:25: error:
>> '_Unwind_gnu_Find_got' was not declared in this scope
>>   270 |               result += _Unwind_gnu_Find_got ((_Unwind_Ptr) u);
>> 
>> And I haven't circled around to try to dig up why yet. (I want to bisect the gcc
>> repo to see what commit broke it, but that involves getting the horrific
>> autoconf dependency stack working which went REALLY WEIRD since the last time I
>> looked at it, possibly version skew with debian oldstable package versions. The
>> tarball versions ship cooked ./configure scripts that don't need the full
>> gnu/aaaaaaaaah environment install with automake and everything...)
> 
> GCC for SH itself works fine for me, so I assume an issue with your build environment.

I'm guessing you didn't build libstdc++? Without which you can't build a native
compiler because gcc is now written in C++. (GCC for _sh4_ works fine, including
native compiler. The sh2eb musl config builds the first pass but not the second,
some configuration that's not lining up, probably to do with fdpic given where
it broke. I need to bisect it to find out what the change was...)

> Adrian

Thanks,

Rob