[J-core] Did anybody do anything with those turtle boards?

[Rob Landley]

On 6/7/21 6:25 PM, Patrick Oppenlander wrote:
> On Mon, Jun 7, 2021 at 9:53 PM Rob Landley <rob at landley.net> wrote:
>>
>> I mailed out a half-dozen turtle boards to various people, each of whom had
>> plans to do things with them, and am told the boards all arrived successfully
>> but haven't heard back since.
>>
>> I haven't exactly followed up either (we got buried by work again) but... Ping?
>> How's it going?
> 
> I powered mine on with the SD card you sent in it. It booted to a kernel panic.

Sorry for the delay replying, an unexpected laptop reboot (and "might as well
upgrade devuan ascii->beowulf since I lost all my open windows anyway") took out
my reply window.

I mentioned I didn't mean to send an sd card in it (I'd misplaced my little
baggie of spare sd cards and the places within walking distance that sold them
closed in the pandemic). That one was left in by mistake and full of random
debug files.

That said, what you DO need is a vmlinux image reproduction sequence you can use
to put a file on there, and I thought I'd point you at mine but realized that
the current one had a regression, which I'm trying to fix. (I broke the nommu
subshell support, and the WAY I broke it was by exposing a bug that was being
silently ignored before and boils down to "I need to implement the declare
command".)

That's the other half of the delay. Doing that. :)

> I built a toolchain, convinced the bootloader to build with a current
> version of gcc (can send a patch if you like, I never got around to
> testing it, reviewing it and cleaning it up),

Sure. We've had an argument here that I say the bootloader should build with the
fdpic toolchain and Jeff insists it needs to build with the ELF toolchain, and
they have some slight syntax differences (presence or absence of the . prefix at
the start, which is _ on most other targets but when the Hitachi developers back
in the 90's implemented the ELF spec they were using a version translated into
japanese and the code page switch substituted "." for "_" which they dutifully
copied, and we are now stuck with ala hysterical raisins.)

Anyway: yes please, send me the patch. It will annoy Jeff.

> managed to get the
> Xilinx tools running and built the jcore-soc project for the
> turtle_1v1 target.

Cool! (There are some very stale docs on the website, which I need to rewrite to
remove at least half the sarcasm from. And the download URL changed although
it's relatively easy to google...)

We really really really want to use the ghdl toolchain for everything instead of
relying on proprietary ones (it builds fine for lattice and we can SIMULATE the
whole big SOC using it), but the xilinx support in nextpnr is an external fork
(https://github.com/gatecat/nextpnr-xilinx I think) but they switched to having
their own build so my old yogh script is out of date and I haven't updated it
yet, so can't even test the out of tree nextpnr-xilinx against current stuff.

And thus webice remains...

> At that point I was derailed by other things. I still need to build a
> kernel, some userspace and actually load something.

On the bare metal side, https://j-core.org/docs/hello.html ... exists.

Lemme get you a kernel and userspace. (Kernel's fine, I broke the toybox shell,
fixing it. Rich is still using busybox in his systems...)

> Right now my plans for this have been put on hold due to factors
> mostly out of my control. I don't know when I'll get back to it.
> 
> Sorry for the lack of progress.

Eh, this is at least half my fault, probably more...

> Patrick

Rob

P.S. The problem is when the nommu shell forks a subshell it has to marshall
data into the child process, and especially when I implemented functions I had a
lot more context to keep track of, so instead of having the child inherit global
variables through environ[] and sending it local variable as NAME=VALUE
assignments through the pipe, I sent all the variables through the pipe in
"declare -xi NAME=$'val'" format. Which DOES let me maintain all the state...
except for the part I hadn't implemented the "declare" command yet so on the
receiving end they all bounced as errors, and then didn't reliably run the
command at the end, and this made the "init" shell in the vmlinux fail to run
the plumbing that would mount /dev and redirect stdin/out/err to /dev/console
since the initramfs.cpio.gz was built without root on the host and thus didn't
include a static /dev/console node that the kernel tries to open before
launching init, and my patch to make the config symbol that's supposed to
auto-mount devtmpfs actuallly DO that for initramfs got ignored,
https://lkml.org/lkml/2017/9/13/651...)

Anyway, not hard to fix, just time consuming and I keep getting interrupted.
Working on it. Sorry for the delay answering.