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

[D. Jeff Dionne]

On Sep 6, 2016, at 2:46 PM, BGB <cr88192 at gmail.com> wrote:

Oh, excellent.  This means you have passed all the CPU tests, and dropped into a GDB stub.  Did you implement and test the J2 CAS instruction, or patch it out?

If you connect this to GDB as a 'remote', you can load code using gdb, run and (mostly) debug.

Great.

J.

> On 9/5/2016 1:29 AM, BGB wrote:
> 
>> but, seems to pass the "testbra" test at least.
>> appears to currently be dying in "testmov".
>> 
>> so, will probably go beat on it some more...
>> 
> 
> so, a general status update on this:
>  all the boot tests now pass, after a fair bit of debugging.
> 
> for some of the tests, it seemed like the solution to PC-relative loads in the delay-slot was to recalculate the loads with an offset value of 6 rather than 4 (can't say for certain that this is correct, but it does seem to pass the tests).
> 
> 
> then I get this stuff (linebreaks inserted):
> $T1e00:00000000;01:abcd0200;02:00000000;03:00000007;04:00000000;05:0000ff8f;06:10000000;
> 07:00005e7c;08:00000000;09:00001434;0a:00000000;0b:000014a0;0c:0000000c;0d:0000000d;
> 0e:00000000;0f:0000ff8c;10:00001120;11:00001116;12:00000000;13:00000000;14:ffff8000;
> 15:00000000;16:00000001;#3b
> 
> seems to be GDB related, probably not immediately relevant to my use-case.
> that last number seems to vary between runs.
> 
> it seems to be in a loop where it reads characters, and I can give characters to it.
> not sure how to do much with this.
> doesn't really seem to be a human-usable interface.
> 
> 
> trying to boot the "vmlinux" image still doesn't work, as it still seems to go into an infinite loop without it reading any input or producing any output (albeit it appears to be going into an infinite loop in a different place from before).
> 
> possible:
>    there are bugs the tests didn't test for (which prevent Linux from booting);
>    the Linux kernel expects something else in order to start up?...
>    there is some mechanism needed to inform the kernel to direct any output to the "uartlite" interface?...
>        (ex: magic data at magic addresses?...).
>        monitoring 0xABCD0000, don't see any activity
>            nor does it seem to be trying to access any other address ranges
>        don't see anything obvious for this in the boot code (like stuff for passing kernel parameters/...).
> 
> I actually have no idea what the code is doing here.
> I guess if I had a linker map for this kernel I could reverse-lookup, and try to figure out where in the kernel it is looping. I may need to build the kernel from source to get the map though (but don't really know the kernel config).
> 
> decided to leave out a disassembly and register dump.
> 
> 
> but, yeah, at least in a basic sense the emulator seems to be working...
> 
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core