PCMHammer P04

[antus]

Thanks, gampy!

Ah I thought there was a record of breaks and builds you guys kept.

There are notes about what changed and why in the commits on the branch, but in general we're tracking what works, not what does not.
For example you can see a single commit with some P04 fixes here https://github.com/LegacyNsfw/PcmHacks/ ... 1ea08ab8db
If you go to the network view in gitlab you can mouse over the commits on a branch and see the notes, then click the commit and see what changed in that commit.

[ProfessWRX]

Could the PCM checking the first 740bytes of RAM for a checksum of sorts to see if it's initialized or not possibly cause issues with the kernel? I noticed it seems to do this and also was surprised that it's almost exactly the area of the kernel.

I don't see how, unless in the middle of a process it's still running OEM code and sees that area change could send it to initialize itself again. Could this be the break that happens somehow?

17E2A in 12588500.

I could also be completely wrong about what's happening at all and in that case just ignore me. I've gone down so many rabbit holes I'm not exactly sure what I'm looking at sometimes.


Or maybe it happens because the preloader kernel gets pushed back outside that space when the kernel is large enough. Because the oem code is running while the loader kernel is being inserted right? I don’t know. Pretty tired at this point.

[antus]

The P04 is more of a black box to me. Everything is shutdown properly before loading the kernel on the P01. The early ones may or may not do it a little different. What I do know though is that these are not modern processors, memory access is flat, there is no virtualization. The only way any execution can happen is via interrupt. The first thing the kernel does is disable interrupts. What your saying sounds like a possability, but what makes me think it is not the case is that the results are consistent. The kernel always works or it always doesn't. If something else was affecting ram randomly then we'd expect random results. The other test we have done is modify the kernel to dump itself out of ram straight back on the bus, and we have been able to verify there is no corruption in ram.

If I had to guess I'd think its to do with the DLC chip. There are a number of failure modes that we should be checking for and resetting the DLC and we are not (and neither is any other company kernel), because the kernel code size gets a lot larger to fit in ram. If the early DLC is more picky about something it could crash entirely crashing the PCM, or it could just fail. I've seen both failure modes. One where the kernel is running and there is no watchdog reset but it stops communicating and another where it does outright crash and reset. Both could be caused by the DLC. But, how to proove it and what to do about it? And is it even worth it to anything if we can build a stable kernel?

[ProfessWRX]

Well if it’s spacing then the loader kernel moved outside the FF8740 range could always work and if moved inside could always crash.

[antus]

That cant be it because we are talking only 2 bytes difference, then you add another 2 bytes and it starts working again. And we can dump the kernel from ram so its not like junk code is being pushed in or out of a bad couple of bytes in the middle of the kernel. In fact when reading the kernel back its bigger than without that code, and not useing most of the code thats loaded, so corruption in most places would likely not be a crash. But we'd be able to see it on the readback. And the corruption is not so.

[ProfessWRX]

So the loader kernel always works? It’s the main kernel where all the strange nop/crash issues are?

[antus]

yes, that's right. and it tends to be to do with the hardware IO interactions for the flash chip. EG the read kernel is always OK. The crashes happen when we are putting the flash IC in or out of command mode.

[Gampy]

I guess that all depends on who you are and what you are doing ...

Because that is not how it is for me.

I have far less issues (virtually none) with the loader.

But it may not matter any longer, I 'think' the issue has been resolved, doing some serious testing right now as I type ... So far looking really good, especially for the P04, but need to fix a few things for the others yet!

-Enjoy

[antus]

Yeah loader is fine, its kernel issues. But wow, that's great. Can't wait to hear your findings. Its been nearly a year now trying to get to the bottom of this! So much solved but still this gotcha.

[Gampy]

Excuse me ... I've been fighting it much longer than that.

I started this project a little over three years ago!

But I had never written a word of Assembly at that point either, thus I had to start at ground level.

-Enjoy