Message-ID: <568D773F.6000408@landley.net>
Date:	Wed, 6 Jan 2016 14:21:19 -0600
From:	Rob Landley <rob@...dley.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	Rich Felker <dalias@...c.org>, linux-kernel@...r.kernel.org,
	linux-sh@...r.kernel.org, Jeff Dionne <jeff@...inux.org>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb



On 01/06/2016 10:57 AM, Peter Zijlstra wrote:
> On Wed, Jan 06, 2016 at 09:42:35AM -0600, Rob Landley wrote:
>> (I would have thought the presence of working QEMU support would tide us
>> over providing an easy basic regression testing environment, but people
>> keep insisting that's not real and doesn't count. But if we can keep it
>> 99% working until the sh4 patents expire later this year, we can add mmu
>> and have full sh4 in hardware again with BSD VHDL.)
> 
> I didn't know there was a 'working' qemu for SH.

Yes, for several years now?

  https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html

I try to build bootable images with each new kernel, although I'm a few
versions behind at the moment (this is 4.1 I think?):

  wget http://landley.net/aboriginal/bin/system-image-sh4.tar.gz
  tar xvzf system-image-sh4.tar.gz
  cd system-image-sh4
  ./run-emulator.sh

There's an sh2eb one in there too, but you need a $50 FPGA board to run
it (Numato Mimas v2, setup walkthrough is at http://nommu.org/jcore).

I keep meaning to poke at qemu and get their r2d board emulation to give
me more than 64 megs of memory so I can do native compiles. (I have a
native toolchain but building much more than "hello world" requires
setting up a swap file because the board emulation only gives me one
virtual disk. None of the other architectures need that...)

I'd _also_ like to get proper sh2 support into qemu (sh2 code runs under
sh4 but still), but the sh4 patents expire later this year and sometime
after that we want to add an MMU to the VHDL, so...

(We still want the nommu version because hard realtime is actually
easier to verify without page faults, and the big product needs
nanosecond accurate timestamps on stuff...)

> My personal 'complaint' with SH is its lack of maintainer feedback. I do
> full arch sweeps on semi-regular basis, and while I know in very board
> terms how a fair number of archs work its impossible to know everything
> about all 25+ we support.

We (the j-core guys) have wanted to take over arch/sh maintainership for
a while, we've just been trying to get the board we're working on in
position to be upstreamed first. The feedback on my craptacular first
effort to chip off a chunk that other people could at least reproduce
against a then-current kernel was "ew" and "redo it all as device tree".
So we went away again to work on that...

Meanwhile all $DAYJOB's in-house resources (at se-instruments.com) have
been tied up making SMP work for a product. (Yes, sh2 SMP. A NOMMU smp
system. There were some teething troubles, but it's working now. Alas,
not on the above $50 FPGA because that's only got an LX9 FPGA which one
SOC instance uses like 2/3 of the gates in. We're doing the SMP stuff in
LX45 boards, which are crazy expensive.)

I note I just sent a Numato board to the buildroot maintainer so I can
walk him through adding jcore support to buildroot. And I got toybox
working nommu, and Rich added sh2 support to musl-libc... There has been
activity on this arch, just not on this list due to the noise from a
bunch of different Renesas arm systems and whatever "arm/shmobile" is.
("Not superh or jcore compatible", that's all I know...)

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists