[J-core] Is a small Linux distribution available for J2 on Numato Mimas?
dalias at libc.org
Wed Aug 10 20:46:50 EDT 2016
On Wed, Aug 10, 2016 at 06:35:13PM -0500, Rob Landley wrote:
> On 08/07/2016 09:06 PM, Rich Felker wrote:
> > On Sun, Aug 07, 2016 at 03:16:45PM +0200, txt.file wrote:
> >> It's probably easier to get involved in debian instead of starting a
> >> complete new port on another distribution. At least debian already has
> >> an SH4 port and there is already the plan to support J-Core.
> >> Running Ubuntu on a 50 MHz single core cpu sounds awful to me.
> >> Gentoo also has an SH4 port.
> > To be able to use Debian SH4 directly on J3/J4, several things would
> > have to happen:
> > - Either we'd need to add a little-endian build option for J-Core (I
> > think this would be a good idea to work on soon if it's not too
> > hard) or everything would have to be rebuilt for a big-endian
> > variant.
> There's debian for ppc, so big endian support is already there, and
> rebuilding for j-core isn't a big deal. (MMU and nommu have never run
> the same binaries. I know you think they should, but you're alone in this.)
It's not that Debian can't be built for big-endian targets, just that
there is no existing sh4be target with binaries, so if you stick with
big endian you'd be bootstrapping a new target from scratch rather
than using an existing one.
> > - To support SMP, glibc would need to add runtime atomics selection
> > with support for cas.l rather than hard-coding gusa, which is
> > fundamentally UP-only. Having the kernel provide a vdso function for
> > atomics might be a good idea since SH has so many variants.
> No, the logical thing to do is have a musl version of debian. Long ago
> there was a uClibc version of debian, it can be done.
This can be done, and in fact there are people working on it, but it's
a big project in itself and might end up being a bottleneck.
> (I note that my post about doing so has been open half-finished for a
> week, and was sent before I saw this. :)
> > Also, while Debian is a great resource in terms of its extensive
> > package coverage, it also tends to have very large install-size and
> > runtime memory needs, and so it may not be ideal for much of the early
> > hardware people will be using for J3/J4.
> Indeed. My main worry would be the 64 megabyte memory limit for lpddr.
> (A 128 meg part exists, but I don't believe even turtle is using it. was
> that a cost thing or compatibility with the dram controller?)
The turtle_1v0/board.dts file reports 128M and my board is working
fine with 128M dtb, so I'm pretty sure it actually has 128M. Still I
think that would be hard to run Debian on. Of course you could add
swap with J3/J4, but you'd need some sort of high-speed storage; the
SD card is not going to work well for that.
> The other immediately interesting j2 target is buildroot, which in
> theory can already use an external toolchain ala musl-cross-make.
Yes. I've gotten it to work several times with minor hackery/patching,
but the main obstacles to having a lot of packages working seem to be
(1) Buildroot's incomplete support for musl-based targets, and (2)
IIRC, hard-coded assumptions that you can't use lots of packages on
nommu even if they might actually work. These should be fairly easy to
fix, and I believe the Buildroot maintainers/community are working on
improving musl support considerably.
More information about the J-core