For what it's worth, I have enough of the keyboard implemented that I can try either a normal boot (on/off), a system-diagnostic boot (S), or a kernel-print boot (K). The log of kernel prints is here:https://gist.github.com/MooglyGuy/20cb1489552e4730244aff75770e54dd …
-
-
Vastauksena käyttäjille @TheMogMiner ja @KinkTodd
I've also added some instrumentation to MAME's ARM7 core to detect calls into the Windows CE kernel, thanks to running across some random IDA-related utility that lists them all:https://gist.github.com/MooglyGuy/58fde57cbff63e0f4ac0442f68ef388c …
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @TheMogMiner ja @KinkTodd
Isn't StrongARM slightly different from ARM7?
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @happysphere ja @TheMogMiner
That's a very good point. The SA-1110 in the 720 is a direct descendant of the 110 used in the DEC DNARD which ran NetBSD and it has an ARMv4 core. There could be strangeness in ARMv4 that the ROM is counting on, for instance unaligned accesses causing rotated data loads.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
I worked on the DNARD port of NetBSD but that was over 20 years ago now. I just remember that the ISA of that generation of ARM had some really weird quirks.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Ah! It just hit me that
@TheMogMiner said ARM7 not ARMv7, these are quite different. ARM7 refers to chips of the v3/v4/v4T generation so that would be nominally appropriate.1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjille @KinkTodd ja @happysphere
The SA-1110 was ARMv4, but supported unaligned access faults. Notably, I don't have those hooked up - I was hoping CE wouldn't use them - but I guess I should have a look.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Snake-eyes on that one, sadly. I put a few printfs into the 32-bit and 16-bit read and write functions in the event of a misaligned read or write, none are ever printed.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
So far I've worked out that there seems to be some list of tasks that need to be completed in order to bring up the system, which is sensible enough. Once the kernel is brought up, there's a function with a check at 13E2C (virtual) of R3, then at 13E30 it loops back if it's > 0.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
R3 starts at 0x12 on entry to the function and gradually decrements as various bring-up tasks are completed (based on observing kernel calls and reads/writes to hardware registers). R1 increments, but at a strangely different rate. R3==3, R1==0x10 seems to be the failure point.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä
Interestingly, if I set MAME's debugger to break on that condition (R15==0x13E2C, R3==3, R1==0x10), then force R3 to be 0, it continues starting up, though I have to figure it's doing so in an unstable state.
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.