PS3 CECH-A BC is crashing before initramfs start

[AKuHAK]

The kernel is crashing just after EARLY_PRINTK is switching into initramfs. Also, the same crash occurs in the pcsx2 in the same place. Don't know if this can be debugged further - seems that there is no way to debug what is happening between the vmode switch. Or maybe we should wait until EE-SIO will be implemented.

Also, some notes. Seems that PS3 supports gcont in both modes nicely. Also, PS3 can handle video modes up to 576i/480p.

wiki:
COK-001 found in CECHA & CECHB models of PS3 includes the combined EE+GS chip and PS2 RAMBUS. COK-002 was included in CECHC & CECHE models. It has a few changes, mainly the EE & RAMBUS removed but the GS remaining, the Samsung NAND chips containing the system firmware have moved, and the southbridge is in a smaller package.

This COK-001 came from a CECHA00 system (00 = Japan), the COK-002 came from a CECHC03 system (03 = UK).

[frno7]

The kernel is crashing just after EARLY_PRINTK is switching into initramfs. Also, the same crash occurs in the pcsx2 in the same place. Don't know if this can be debugged further - seems that there is no way to debug what is happening between the vmode switch. Or maybe we should wait until EE-SIO will be implemented.

Binary search, also known as bisection, is very effective at finding crash points. Identify a known working start point, and a wanted but currently unreachable end point. Now, try to find a third point approximately halfway between those points, and put an indicator there. Something trivial is enough, such as flipping a background colour on the screen via a GS command, beeping in the speaker, or flashing a LED indicator, for instance. Determine whether this occurs or not in a test-run. For each successive iteration, the distance to the crash point is halved.

If there are, say, 1000 steps between the start and end points, it only takes approximately 10 iterations to find the exact crash point. If there are 1 million steps, it only takes 20 iterations. :-)

[AKuHAK]

maybe someone can test where it is crashing on pcsx2, since pcsx2 is available to everyone. It looks like pcsx2 and ps3 are crashing at the same point. I used pcsx2 heavily for debugging stuff and can confirm that 99% pcsx2 crash occurs when there is something wrong in the application.

[frno7]

I agree it'd likely be revealing. The kernel may demand more emulation than a typical application though. :-)

[AKuHAK]

The kernel may demand more emulation

Currently, pcsx2 reaches a very accurate state, so there is a higher chance that the problem is an inside the app, rather than in the program itself. i agree that kernel is a complex app that may require something outside emulation, but as I say it is still will be good to debug this to know what exactly is crashing it.

[frno7]

I've registered issue #83 to deal with the PCSX2.