[J-core] My trip to Japan

[Rob Landley]

On 12/26/19 3:43 PM, Joh-Tob Schäg wrote:
> Hello J-Core list,
> 
> in the last weeks i made a trip a to Japan. There were two events that
> are relevant for this community.

Sorry for the delay replying, gmail's out of control spam filter ate this and I
just caught it.

> 1. Presentation of progress of porting µT-Kernel 2.0 to J2 at TRONSHOW 2019
> 
> As you might know i am working on porting a small embedded real time
> to J2. I presented my current state at TRONSHOW 2019 on the short
> paper track which has some relation to IEEE.

Offer's still open: If you can get us a copy of the source you're working on, we
can help port it.

> 2. Supper with Jeff
> 
> My girlfriend, me, Geo and Jeff took part in a supper/nomikai(?) on
> the 12th December (names from the left in the attached picture). Geo
> is part of the Picolisp community and build his own lisp machine in
> FPGA using Verilog. He showed interest in J-Core and might even have
> already joined the mailing list.

Sorry for the radio silence, we've been working on GPS bits the past week and
change (porting the correlators to turtle, with a a "hat" GPS receiver). Adding
the correlators took 1282 LUTs, by the way. (And 8402 wires, and 590 S6 registers.)

> I found the conversations very
> interesting. Rob did not make it since he was not in Japan at the
> time.

Same reason I didn't submit a paper to CCC: holidays with the family.

> During the occasion i received a turtle board with some binaries
> . I am free to talk about it, so if you have questions ask me. The

Oh, we have a new bitstream that's doing internal bus termination right. (One of
the things we're cleaning up before release is that Niishi-san added some awk
scripts to postprocess the source in places Geoff's leingen routing tool didn't
do what he wanted, and they were matching board names exactly, which explains
why "turtle_1v1" had different bus termination than turtle_1v0". At first we
thought it was version skew in the bus implementation logic...)

Of course said bus _mostly_ comes into play when talking to USB, which we
haven't got all the VHDL plumbing for done yet, so... :)

> FPGA came flashed with a dual core J32. Jeff also showed me how to
> reflash the FPGA. It has a dedicated flash mode which can be triggered
> at start-up.

Do you have one with the 250k serial speed, or the 19.2k serial speed? (We
switched all ours over, _that_ requires reflashing the atmel chip which involves
shorting a resistor while holding down the restart button, and then running the
tool from atmel's website. It mostly just makes the console feel snappier,
unless of course you're putting ppp over it. :)

(P.S. Jeff _insists_ that slip is still relevant and that ppp isn't what you'd
use to bridge two devices next to each other on a desk. The last time I used
slip was in college, so I couldn't tell you...)

Anyway, it's relevant because the bitstream hardwires the serial port speed
(part of what makes uartlite simple, it works at a fixed speed). The USB side of
things hides this (it gets translated to USB packets and back, speed is
irrelevant) but the other end presents a serial interface to the bootloader and
kernel. If the atmel hasn't got the speed right it can't reflash the kernel, and
if the kernel hasn't got it right you can't see the console. Which means we have
to build kernels for a given console speed, and these days we're building them
for 250k because we upgraded all our boards here already.

All the turtles we ship to crowdsupply should have the 250k speed, but you got
an early one that may need upgrading to use new kernels, and the process is a
bit fiddly because we never thought anybody would have to do it in the field.

P.S. Remind me to poke martin about uploading the change to
https://github.com/j-core/TurtleAtmel/commits/master
It's _probably_ just changing
https://github.com/j-core/TurtleAtmel/blob/master/serialio.h#L11 and then
rebuilding with the arduino toolchain, but I should confirm that?

> In the flash mode the board talks over serial and has an
> assistant for flashing an image form the µSD card.
> The linux build that came with it did not support J32 yet which means
> it crashes when mmap is called. (I understood from Robs explanation
> that this expected behaviour when running a nommu kernel on a device
> with MMU).

It shouldn't crash when mmap() is called, but mmap(MAP_PRIVATE) isn't supported
on files and would return -1. You can mmap(MAP_SHARED) a file, and you can
mmap(MAP_PRIVATE) anonymous memory, but you can't mmap(MAP_SHARED) a file
without copy on write support. (Also, a file backed mmap longer than page size
only works if the pages are already physically contiguous in page cache, which
is anybody's guess...)

That's not j-core specific, that's nommu. :)

> Jeff mentioned that a new run of the turtle board (and there by the
> crowd funding campaign) is delayed because some of the boards came
> back defective and they want to fix this before doing mass production.
> I am not sure if they already diagnosed it.

I'm pretty sure we diagnosed everything. The big problem is the 3.5" jack has
the pins in the wrong order which means ground isn't where you expect it so
don't plug your headphones into that. (We could make an adapter to swap the pins
around, but next run should have them in the right order.)

I think all the other hardware should be working in yours?

> If you want to run some
> J32 binaries on the turtle or have ideas for experiments please poke
> me. I have no J32 source though, so i can't answer questions about
> these.

We've been feeding j32 info to Rich this week, and he's been poking at improving
kernel support. No schedule on that yet, but something like progress is occurring.

Rob