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

[Patrick Oppenlander]

On Thu, Jun 17, 2021 at 9:17 PM Rob Landley <rob at landley.net> wrote:
>
> 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. :)

Thanks, I'm sure that will be helpful for everyone with boards.

> > 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.)

Wow.

I can't remember if I did this with an fdpic or ELF toolchain. I think
it was ELF after looking at the diffs. I've changed machines since
then.

I agree with you -- it should be buildable with the fdpic toolchain
but I don't think I've tried that yet because the fdpic toolchain
failed to build libstdc++ (something to do with exception unwinding -
haven't looked at that yet either).

I assume you're talking about the prefix on asm symbols generated from
C? "-fleading-underscore" might as well be "-fbreak-everything" as far
as I'm concerned. Didn't realise there was a difference between ELF
and fdpic. That would be painful.

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

Attached.

As I said previously, half baked work in progress.. I'll try to
remember what some of the changes were for:

* libgcc-Os-4-200.a wasn't built with my toolchain, I didn't
investigate why. Maybe because musl toolchains aren't multilib?
* NEED_LIBC? gcc generates extern references to functions like memcpy,
so you pretty much always NEED_LIBC.
* Fixes for references to C symbols which aren't underscore prefixed.
Oh I remember now -- you (obviously?) can't even link against libgcc
if you turn on -fleading-underscore. I think I tried to build a
leading underscore toolchain but the world exploded so I gave up.
* I didn't get around to looking into why ld stopped understanding "elf32-sh".
* Support for overriding CROSS_COMPILE in jcore-soc was missing.

> > 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...)

For the Xilinx installation? I saw that :)

There's a nice clean recipe for installing it here:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=xilinx-ise

And a simple way to get a working license is described here:

https://wiki.archlinux.org/title/Xilinx_ISE_WebPACK#License_Installation

> 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.

Nice, I saw that on the mailing list.

> 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...)

I'm still using busybox in my other projects too. The shell is the
only thing left before I can "rm -rf busybox".

> > 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...

It'll be nice to build an image for the board, but realistically I
won't be able to dedicate real time to it in at the moment.

>
> 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.

I can't wait for toysh. Thanks for all the hard work!

Patrick