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

[txt.file]

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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160811/5a0fdffd/attachment.sig>