[J-core] Port Idea: Little Kernel

Rob Landley rob at landley.net
Fri Nov 17 09:17:10 EST 2017


On 11/13/2017 10:07 AM, John Paul Adrian Glaubitz wrote:
> On 11/13/2017 04:46 PM, Rob Landley wrote:
>> On 11/12/2017 04:05 AM, John Paul Adrian Glaubitz wrote:
>>> Let me know if you need a new LANDISK device. I still have plenty of
>>> them lying around. I also can tell you how to build your own kernel
>>> for the thing and get it to boot. However, I still have the problem
>>> that I don't know how to make the IDE driver work. I can get the
>>> LANDISK to boot my own, freshly compiled kernel. But it will never
>>> detect any IDE devices. But this might be a problem specific to the
>>> LANDISK USL-5P devices I have. I never tested it with my HDL-U160
>>> device (the same device I had sent to you from Japan).
>>
>> The work Cedric is doing on his qemu fork is quite interesting, if we
>> can convert landisk to device tree and get that tree to cedric for
>> reference, he might be able to get qemu to emulate it.
> 
> I thought Yoshinori already converted LANDISK and R2Dplus to device
> tree:
> 
>> https://lkml.org/lkml/2016/6/29/388
> 
> It seems though the patch was never applied.

Sigh. For toybox I have a directory of unapplied patches so they're not
_lost_, even if I haven't looked at 'em in a while. I assume Rich has
something similar but with the year he's had I should probably try to
track them independently as a fallback.

My understanding is Sato-san basically agreed to act as training wheels
for Rich on arch/sh; Sato-san did the original sh2 port but never poked
at sh4 much that I'm aware of (I should ask), and these days his own
hobby time goes into h8300 (a chip renesas developed in-house instead of
inherited from hitachi).

>> A board with more than 64 megs of ram and a single hard drive would be
>> nice. (And a battery backed up clock.)
>>
>> And, of course, teaching QEMU to emulate the serial buffer the kernel's
>> expected it to have for a year now. :)
> 
> Yes, qemu-sh4-system with 4 GiB RAM or even just 1 GiB RAM would be
> fantastic. I am doing lots of QEMU torture testing on SH4, but that's
> all limited to qemu-user and not qemu-system. I helped fixing lots of
> bugs in QEMU in any case :).

I'm trying to get https://github.com/landley/mkroot to be a proper
replacement for https://landley.net/aboriginal/about.html which means
native toolchains, but Rich has been too busy to host native binaries of
musl-cross-make and I'm not going to touch gplv3 code ever unless
directly ordered to by an employer whose lawyers will stand between me
and that license.

(That's why Aboriginal Linux froze on the last gplv2 releases of all the
gnu packages it still used. Way ack when I'd meant for my qcc fork to
take over that load, but I got married and had a life instead.)

>>> Since the device uses u-boot, it's actually pretty easy to get your
>>> own Linux kernel to boot on this device. And since it's reasonably fast,
>>> it's also more fun to use as compared to the LANDISK device.
>>>
>>> However, there is one huge drawback which is that support for ST40
>>> was completely removed from the kernel, so it would need to be
>>> re-added first:
>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f96691872439ab2071171d4531c4a95b5d493ae5
>>
>> Paul Mundt was not acting in the best interests of the Linux kernel.
> 
> Well, I think these things just happen when code becomes unmaintained.

I say that due to my own interactions with him trying to get sh4 to work
on qemu over the years. Dude could not hold the ideas "interested in
sh4" and "not a renesas customer" in his head at the same time.

> I would have preferred for ST40 support to stay in though.

Presumably we can put it back.

>>> There is an out-of-tree kernel patch for the NextVoD but that is
>>> still based on 2.6.32:
>>>
>>>> https://github.com/dlintw/nextvod-tdt
>>>
>>> If you (or anyone else) is interested on working on this and gettiing
>>> the NextVoD working with a current kernel again, I would them send
>>> such a NextVoD for free immediately. I would be very interested in
>>> getting the NextVoDs supported by a current kernel again as those
>>> NextVoDs devices can be acquired in Taiwan for less than US$10!
>>
>> If Rich doesn't find time by about February, poke me. (I'm in Tokyo this
>> month, then relatives for the holidays, then catching up from all that...)
>>
>> Can these be ordered on amazon, or only bought personally in taiwan?
> 
> They are called "網樂通" in Chinese.

I've got my hands full learning _japanese_. (More than full, so far it's
going about as well as qcc.)

> If you go to Yahoo Auction Taiwan,
> you can find them:
> https://tw.bid.yahoo.com/search/auction/product?kw=%E7%B6%B2%E6%A8%82%E9%80%9A&p=%E7%B6%B2%E6%A8%82%E9%80%9A
> 
> And you can probably use a service like this one to buy them from abroad:
> 
>> http://www.letsgobuy-tw.com/
> 
> I have used Rinkya! for Yahoo Auction Japan before and it works quite
> well. I haven't used the service in Taiwan yet though.

I had a cortex-m board on my desk for 3 months until the company that
loaned it to me asked for it back, and never did port the out-of-tree
patches to current vanilla kernel and send them uptream like I meant to.
Too busy with other things...

> Either way, the NextVoD devices are probably the best SuperH hardware
> you can buy cheap these days and which easily allows to install
> a custom version of Linux.

It sounds highly cool. But it's a question of free time/energy. My
time's only really _free_ these days when I'm too tired to do productive
work. :)

I've forward-ported and backward-ported stuff across several years of
kernel development before, so if I get a board and a working
build-from-source kernel on it, I theoretically _can_ get it working on
a current system. (Modulo big flag day changes like board.c -> device
tree that aren't a port but a rewrite.)

If I can get to a point where I can sit down and do 5 productive minutes
of work at a time, it's easy to work on a project. If I need to clear
hour-long blocks of productive not-dayjob time before you see any
progress, toybox gets those first. (I still _do_ open source
development, I've just _got_ two projects already, toybox and mkroot...)

And $DAYJOB isn't going to do something compatible with this board
because we have our own SOC with its own peripherals and memory layout,
and the MMU we're doing is a different design. (I.E. this isn't _jcore_,
at best running compatible userspace binaries.) So asking work to
officially assign me to this for a few days is a hard sell. (I asked
Jeff about it and he said ST micro isn't manufacturing sh4 chips
anymore, so a currently available st40 product has to be somebody
selling through an existing inventory.)

Might have some weekend time when I get back to Austin. As you can tell
from my email response time, I've been a bit busy in Japan so far. (The
GPS code is much improved, met with ArtAnalog about asic work scheduling, .)

> Adrian

Rob


More information about the J-core mailing list