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

[txt.file]

Yes. Reason is that I want to be able to run aptitude which needs much
more ram compared to the services.

> txt at is:~$ free -m
>               total        used        free      shared  buff/cache   available
> Mem:            120          25          21           0          73          89
> Swap:           121           8         113
> txt at is:~$ 

--
This message is signed.

On 08/11/2016 02:05 PM, D. Jeff Dionne wrote:
> 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

-------------- 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/bd8bf0c0/attachment.sig>