[J-core] Fwd: General Questions

[Rob Landley]

On 09/27/2016 11:26 AM, D. Jeff Dionne wrote:
> On Sep 28, 2016, at 12:27 AM, Marina Shishova <thngttr at ya.ru> wrote:
> 
>> Hi!
> 
> Hi :)
> 
>>
>> Hope I write to the right address.
>>
>> I do my very first steps with J2 Soft Core, so there are a lot of questions you may find either obvious or too general or maybe too early to be asked but I hope you can answer at least some of them.
> 
> Very quickly...
> 
>>
>> So, say we do have Aboriginal Linux OS started on Numato Mimas V2 board. What's next?

The Aboriginal Linux instructions are stale. I'm redoing it based on
https://github.com/richfelker/musl-cross-make and
http://github.com/j-core/mkroot but there's some significant redesign
involved that's taking a while.

In the meantime, we wrote up some instructions here:

  http://lists.j-core.org/pipermail/j-core/2016-May/000171.html

>> 1. How to access hardware like ports/pins, memory, buttons, leds, vga, etc.?
> 
> You a, make sure the appropriate IP cores are connected to the appropriate pins and b, write a program or device driver to control said core.
> 
>> 2. How to create executable files? Should I write them through terminal connection? Or put them directly to SD card? What IDE and/or toolchain should I use?
> 
> Did you build from sources or did you use a precompiled binary?
> If you built from source, then you have the compiler installed,

The main thing that went stale in aboriginal linux was the toolchain.
Rich's new toolchain uses fdpic (much nicer binary format) and is gcc
5.x instead of gcc 4.2 from 2007.

> otherwise you need to follow the instructions on the j-core.org page and
> build / install a toolchain (using musl cross make).

I need to update the web page, but I'm trying to get a toybox release
out first. (Hopefully this weekend...)

>> 3. Is it possible to perform project build natively on J2 running on
> Mimas V2? Is there a way to merge neccessary binaries (like gcc) and
> libraries with Linux beforehand?
> 
> Yes, Rich F demonstrated that (on Turtle) but it’s very very slow.

Although part of the problem was the sdcard driver being very slow
(such that loading the gcc binary from it took something like 30
seconds). I think we fixed the sdcard driver so it's faster now, but you
may need a new bitstream for that (and the 62.5 mhz bitstream release
isn't up yet).

What I'd really like is to get our sh2 userspace running on
qemu-system-sh with distcc calling out to the cross compiler, so we can
natively build at x86 host speeds. The fact that "qemu-system-sh4" is
currently the name of that target may be a hint why that's not working
yet. :)

Failing that, one of our eventual blue-sky todo items is to do a run of
actual ASICs via kickstarter.I don't know if that will be 2017 or 2018
or what. (Should we do it after j3? j4? j64?)

If that's done on maybe a 45 nanometer process, it would run several
times the speed of the FPGA version, so there's another (eventual)
native compiling possibility...

In the long run, yes we very much want to support this. In the short
run, there are todo items left. :)

> You want to install the compilers and build on your Linux machine.
> 
>> 4. How to load executable binary (hex or elf or other format) from
>> outside to execute within J2 Linux environment?
>
> On mimas, there is no ethernet.  So you can drop the binary on the
> sdcard and run it from there.  On a platform with Ethernet, you
> can also FTP the file over to the board.

I uuencode encode the binary, fire up notepad, and cut and paste it
across the serial port into uudecode. (Disgusting, but it works for me.)

>> 5. Is there any support for DRAM? As you know, Mimas V2 has 512 Mbits of LPDDR, is that memory accessible for J2 for any purposes in current version?
> 
> Linux, as you show in your boot messages, runs from DDR.

Specifically, lpddr. This was discussed on the list before, see April 28
and April 30 of:

  http://j-core.org/news.html#30-04-2016

Again, I need to:

A) catch up on the news.html summaries/indexes.

2) update the web page with all that information

III) get a new system image out with the current components.

(Next week's linux-kernel merge window should FINALLY merge the rest of
the J2 board support for mimas. Last time they took the basic board
config but NOT the interrupt controller, so it boots halfway and hangs
with no timer interrupt. Bravo. The bikeshedding was epic and prolonged.
Working on it...)

>> 6. We see 511 MB of memory listed during Linux boot

Possibly you mean megabits, not megabytes?

Linux thinks in megabytes, and LPDDR maxes out at 256M but that's newer
chips than the mimas has (only 128M).

In order for us to go beyond that we either need to teach the dram
controller to talk to other kinds of memory (and most of them need WAY
more pins), or else we need a second LPDDR bank (which could bring us up
to 512 megs... at the expense of doubling our pin count and requiring a
second instance of the dram controller and plumbing to mediate between
them...)

It's on the todo list but not _yet_. Probably the j4 or j64 timeframe.

There's a roadmap page on the website that needs updating, the basic
idea is: j3 adds an MMU and more instructions, probably full sh4
instruction set. j4 is about multi-issue, executing 2 instructions per
clock cycle. j64 adds a 64 bit mode to our chip which has NOTHING to do
with the "sh5" path renesas went down. We're following what Hitachi did
then brancing out on our own from there.

All of this still subject to change if we think of a better idea before
implementing it, of course. :)

But before ANY of that, we want to get the VHDL repository up on github
so people can participate in the hardware-side development. (Rich Felker
is currently working on that repository conversion, using a completely
different approach than I was trying. Mine would have produced a history
with as little trace of subrepos as possible, but it turned out to be a
horrible nightmare to implement. His has a lot of
branch/merge/branch/merge in it due to the subrepos, but the data should
be accessable, and once it's converted and we internally migrate to the
new one for our own development, the history should be clearer going
forward.)

Rob