[J-core] working on SH-2 emulator.

[Rob Landley]

On 09/06/2016 03:40 AM, BGB wrote:
> On 9/6/2016 2:26 AM, D. Jeff Dionne wrote:
>> The driver does exist...  here is a print of my boot just a few min ago:
>>
>> Open vmlinux OK
>> Use bootloader's DTB
>> RUN program
>> Linux version 4.6.0-00044-g127f81a-dirty (jeff at VirtualSuSE) (gcc
>> version 5.3.0 (GCC) ) #2 SMP Sun Sep 4 07:28:34 EDT 2016
>> Boot params:
>> ... MOUNT_ROOT_RDONLY - 00000001
>> ... RAMDISK_FLAGS     - 00000000
>> ... ORIG_ROOT_DEV     - 00000200
>> ... LOADER_TYPE       - 00000001
>> ... INITRD_START      - 00000000
>> ... INITRD_SIZE       - 00000000
>> earlycon: uartlite_a0 at MMIO 0xabcd0100 (options '')
>> bootconsole [uartlite_a0] enabled
>> Booting machvec: devicetree
>>
>> The relevant lines in .config are:
>>
>> #
>> # Serial drivers
>> #
>> CONFIG_SERIAL_EARLYCON=y
>> # CONFIG_SERIAL_8250 is not set
>>
>> #
>> # Non-8250 serial port support
>> #
>> # CONFIG_SERIAL_MAX3100 is not set
>> # CONFIG_SERIAL_MAX310X is not set
>> CONFIG_SERIAL_UARTLITE=y
>> CONFIG_SERIAL_UARTLITE_CONSOLE=y
>> # CONFIG_SERIAL_SH_SCI is not set
>> CONFIG_SERIAL_CORE=y
>> CONFIG_SERIAL_CORE_CONSOLE=y
> 
> good to know. I am working on getting the kernel rebuilt (ex: trying to
> use Aboriginal).

Aboriginal Linux is currently in pieces while I swap it to use Rich's
https://github.com/richfelker/musl-cross-make toolchain.

(When gcc went gplv3 I stayed with the last gplv2 release of gcc and
binutils, but those are now 9 years old and very creaky, and since the
4.3 kernel four different architectures stopped building for four
different _reasons_, and I never got around to fixing it all.)

Also, the toolchain support I added was binflt (using  elf2flt), and
"flat files" are much less flexible/powerful than fdpic. (See
http://nommu.org for the difference between fdpic and elf2flt and why
nommu systems can't just use normal ELF files.) Rich's toolchain uses fdpic.

In theory you can grab the current linux-git from kernel.org, add Rich's
patch to fill in the remaining bits stuck in various maintainer trees
while they bikeshed trivial details (patch attached), build Rich's
toolchain like so (sorry for the line wrap):

cd ~/musl-cross-make
make TARGET=sh2eb-linux-muslfdpic GCC_CONFIG="--with-cpu-mj2
--disable-nls --disable-libquadmath  --disable-decimal-float" install

And then build the kernel (with attached patch) ala:

  make ARCH=sh j2_defconfig
  make ARCH=sh \
    CROSS_COMPILE=~/musl-cross-make/output/bin/sh2eb-linux-muslfdpic-

And then the resulting "vmlinux" file at the top ofthe tree should be
what our bootloader expects to parse. (It's got its own tiny ELF loader
in it. yes we can use ELF in this context where we need FDPIC in other
contexts because we're never launching two instances of the kernel at
once so relocating it to arbitrary memory locations doesn't come up.)

Lemme know if I typoed any of that. (You can inflict -j8 or similar on
most of the make invocations above, if you want the build to use SMP.)

> this is pretty slow and it didn't work the first attempt, so trying again.
> if it doesn't work, I might try "sh2elf" rather than "sh2eb".

Another advantage of Rich's toolchain is that distinction went away. :)

Seriously, I have a half-finished update of the website but I was
waiting for the rest of the patch to go upstream so I could say "use
vanilla linux, it just works!" Alas, merging code into a modern linux
kernel has way more politics and territoriality than that these days.
Maybe next release the rest will get in. Or the one after that...

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcore-4.8-drivers.diff.gz
Type: application/gzip
Size: 7560 bytes
Desc: not available
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160906/2bf97266/attachment-0001.bin>