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

[BGB]

On 9/6/2016 1:51 PM, Rob Landley wrote:
> 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).
>> 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".
>>
>> as noted, I did add CAS, SHAD, and SHLD, since in this case there wasn't
>> really all that much reason not to.
> Oh, the build kind of expects a root filesystem in initramfs, which
> means you need a cpio archive or directory to point
> CONFIG_INITRAMFS_SOURCE at, which means you might want to look at:
>
>   https://github.com/j-core/mkroot
>
> (Sorry, I really need to write this up properly for the web page. _And_
> I need to get a new aboriginal linux release out using Rich's toolchain
> and an updated kernel version.)

yeah. as-is, I am not having much success getting it rebuilt, and after 
beating on the issue all day and part of yesterday I am feeling a bit 
frustrated.

may deal with it later, for right now managed to get a little burnt out 
on it.


I am left to question if one needs such a large compiler and kernel (ex: 
GCC and Linux) for embedded targets, vs using a smaller/more-specialized 
C compiler and a more minimalist OS kernel (MM, FS, loader, and a few 
drivers).

I could almost try writing a new compiler and kernel for this myself, 
but this would be a considerable investment of time/energy.

my existing stuff primarily targets bytecode ISA's, and ideally one 
would want a direct native compiler, as opposed to one going 
C->bytecode->native (possibly tacking in some extensions to allow inline 
ASM).

though, in a high-level sense, going from C to bytecode and then 
generating native code in the link phase isn't too much different from 
how LLVM works (would mostly need to write a SH backend, maybe make a 
new compiler frontend based mostly on my existing code).

well, and probably also need to write an SH2 assembler and native linker 
for this.

partly it is a question of whether or not it would be particularly 
worthwhile to go down this rabbit hole...