[J-core] Linux on J1?

Rich Felker dalias at libc.org
Tue Aug 2 14:06:41 EDT 2016


On Mon, Aug 01, 2016 at 03:51:19PM -0500, Rob Landley wrote:
> What would it take to build a J1 processor running Linux?
> 
> What I mean by that is, presumably starting with:
> 
>   http://lists.j-core.org/pipermail/j-core/2016-June/000204.html
> 
> 1) Take the stripped down "should fit in ice-40 if the toolchain works"
> config and build it for spartan 6 with the existing xilinx toolchain.
> 
> 2) Add the DRAM controller back.
> 
> 3) Audit the instruction set and decide what we want to keep/drop. Do we
> want a microcoded multiplier, or have libgcc.a do it? We talked about
> this a few times:
> 
>   http://lists.j-core.org/pipermail/j-core/2016-May/000166.html
>   http://lists.j-core.org/pipermail/j-core/2016-May/000169.html
>   http://lists.j-core.org/pipermail/j-core/2016-July/000252.html

There would be at least a moderate software support burden for trying
to make Linux & userspace run on something that's not SH-2 ISA
compatible. Both GCC's FDPIC support and the kernel presuppose at
least SH-2. Since the kernel doesn't need FDPIC, one could audit it
for SH-2 assumptions and remove them, then add traps to emulate full
missing instructions for userspace in software; of course that would
be painfully slow. If we wanted GCC to support an ISA-subset J1
directly, either FDPIC support should be added to the existing SH-1
target (not too difficult but upstream would end up with extra mess to
maintain) or J1 could be added as a new ISA level (complexity burden).

If microcoding is practical, I think that makes a lot more sense. It
should both perform better and avoid big software dependencies.

> 4) Tweak gcc/binutils to add a target to produce the right instructions.
> 
> 5) Tweak the kernel assembly.
> 
> 6) Boot Linux on a Numato board with J1.
> 
> Now here's the really funky question: If we just use prefetch instead of
> icache/dcache, could we SMP J1 on Numato? (And/or fit in one instance of
> the DSP?)

Disabling dcache is a huge hit to performance. It might be more
practical to do a shared-dcache implementation for SMP, where both
cores are accessing the same cache (even if subject to stalls when
both access it at the same time) that would allow all the snooping
logic (and half of the cache memory size) to be omitted.

Rich


More information about the J-core mailing list