[J-core] Is a small Linux distribution available for J2 on Numato Mimas?

[Geoff Salmon]

On 16-08-07 11:56 PM, Robert Ou wrote:
> It is pretty straightforward to make J2 little endian in a hard-coded
> and non-configurable way. An example of doing so is on my GitHub
> (https://github.com/rqou/myhdl-vhdl-verilog-test/commit/ed8be57aafd712a4b6b653bb076bdbcc228e3741).

Hi Robert

I've been mulling this patch over and how its division of changes 
between the cpu (datapath.vhm) and the memory (top.py) would work for 
other peripherals. My first instinct for supporting little-endian was to 
flip the write-enable and data byte-order of the data bus ports of the 
cpu, but I think your way is more clever and requires fewer changes to 
peripherals.

Do I have the following right?

Your patch does 2 things to the cpu:
1. flip the order of the write-enable bits
2. change which byte or which 2 bytes are placed on the w-bus from the 
32 bits returned during 8 and 16 bit reads

And 4 things to the simulated memories in top.py:
1. flip the 2 bytes in each 16 bit instruction read
2. flip the 4 bytes in each 32 bit data read
3. flip the 4 bytes when writing to simulated ram
4. look at the flipped write-enable for writes to the simulated debug 
port and avr reset peripherals (although the avr reset is always written 
with mov.l so that doesn't matter)

For other peripherals, if we define the various memory-mapped status and 
control registers to be 32-bit values in native byte order, then your 
changes to datapath.vhm require no changes in the peripheral. 32-bit 
reads and writes work as before, and 8 and 16 bit reads/writes would 
access the bytes one expects on a little-endian cpu.

Some peripherals would still need changes though. It's not in the 
existing release, but the ethernet mac has rx and tx memory buffers. A 
mov.b to or from address 0 in the buffers should be accessing the first 
byte in a packet. With this datapath.vhm change, does every peripheral 
exposing arrays of values that support being read or written 
byte-by-byte need to internally flip the byte order for reads and writes 
to those address ranges?

I'm also wondering what affect this will have on the dma. The dmac 
(again, not in the released vhdl yet) accesses peripherals through the 
same data bus ports. The dmac may need similar changes to the 
datapath.vhm so that the byte order of its reads matches the cpus and 
the peripherals expectations.

- Geoff