Re: j-core vs RISC-V

On 05/10/2017 01:38 AM, Rick Moen wrote:
> Quoting Rob Landley (rob-VoJi6FS/[email protected]):
>> What was his query? 
> 
> He asked:  'Do you think there is any chance to see large deployment of
> Linux on a new architecture?'

Short answer: on this one, yes.

Long answer:

1) it's not a new architecture, it's a variant of an existing
architecture. Running unmodified sh2 code was an explicit goal of the
new hardware design (up to and including booting existing Windows CE
images, for some reason). Up until 2015 or so we were developing against
the last sh2 toolchain released by Code Sourcery in 2010. (Implementing
SMP support required a new cmpxchg instruction the old toolchain
couldn't produce, and moving from binflt->fdpic required toolchain
patches which have since been merged upstream). Which puts us ahead of
cortex-m, which still has its fdpic support out of tree last I checked:

https://www.slideshare.net/linaroorg/sfo15406-arm-fdpic-toolset-kernel-libraries-for-cortexm-cortexr-mmuless-cores

90% of the kernel work we did for linux was implementing device tree and
modern SMP support for an architecture that predated device tree and
modern SMP. If we hadn't cared about making new features like futexes
and thread local storage work we could probably have made an fpga
bitstream compatible with an existing board and not modified the kernel
at all.

B) Yes if for no other reason than se-instruments.com is shipping it to
customers and we intend to ramp up volume, hence the ASICs.

III) Pretty much all the fabs we talked to when reseraching ASIC
manufacturing is interested in offering j-core processors as a library
to their customers, since it's provably royalty-free. (They're
especially interested in the j1 variant, which is a stripped _down_ j2
with a microcoded shift-and-add version version of the multiply
instruction and using sram instead of cache/dram. I.E. arduino country.
We can replace a lot of 8-bit microcontrollers without increasing
transistor count or doing _too_ much damage to memory usage, and that
excites people.)

And finally, we made j-core.org and pushed support upstream into all the
vanilla packages (the kernel has "make ARCH=sh j2_defconfig", superh
fdpic is in current gcc/binutils, etc) so peopole _other_ than use could
use it. We didn't locally need that (works for us just fine already), we
did that because the architect of j-core was previously the founder of
uclinux.org back in the 90's. (That project rolled to a stop when he
moved to Japan in 2003 and went back to hardware development, he handed
uclinux off to other people who didn't maintain it. Jeff Dionne
understands how open source should work and how hardware should work,
and is trying to do a proper open source hardware platform.)

Helping other people use this is something we're spending rather a lot
of time and effort on. The turtle boards only exist because we want
people outside the company to have better development boards; we have
our own in-house EVB boards with lx45 on them and high end analog sensor
equipment and stuff. It's a startup so we're spinning lots of plates and
running from crisis to crisis, but we keep coming back to spin this one up.

Did that answer the question?

Rob

P.S. I think all this information and more was in the ELC talk I linked
to? It's a bit crass advertise on a list like this, and doing too much
pro/con arguing falls into that category if you ask me. But you did ask...