[J-core] Is a small Linux distribution available for J2 on Numato Mimas?

[D. Jeff Dionne]

Do you have swap configured on that machine?

Cheers,
J.

> On Aug 11, 2016, at 16:50, txt.file <txt.file at txtfile.eu> wrote:
> 
> regarding memory:
> Running debian on a 128 MB machine is a minor problem. I have a server
> with 128 MB memory and 1 GB HDD and am running debian testing. This
> machine is running my xmpp server (prosody) and my irc bouncer (znc).
> Official memory requirements for debian jessie are 112 MB[0] (90 MB for
> wheezy[1]).
> 
> Compiling on a 128 MB machine might be difficult.
> 
> [0] https://www.debian.org/releases/jessie/amd64/ch02s05.html.en
> [1] https://www.debian.org/releases/wheezy/amd64/ch02s05.html.en
> --
> This message is signed.
> 
>> On 08/11/2016 02:46 AM, Rich Felker wrote:
>>> 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.
>> 
>> Rich
> 
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core