[J-core] working on SH-2 emulator.
cr88192 at gmail.com
Tue Sep 6 17:31:23 EDT 2016
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_8250 is not set
>>> # Non-8250 serial port support
>>> # CONFIG_SERIAL_MAX3100 is not set
>>> # CONFIG_SERIAL_MAX310X is not set
>>> # CONFIG_SERIAL_SH_SCI is not set
>> 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:
> (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
may deal with it later, for right now managed to get a little burnt out
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
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
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
partly it is a question of whether or not it would be particularly
worthwhile to go down this rabbit hole...
More information about the J-core