What's new

Unsolved Hardware Revisions and Kernel Versions

SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Hey everyone,

After looking into XeBuild patches a while back and getting older dashes to run on consoles with newer hack methods like RGH, I've noticed/heard that kernel versions only work on certain hardware revisions of consoles.

For example, a few weeks back, I managed to get 9199 to run on a Trinity console I had with next to no changes, as 12611 didn't come out until several months after the Slims were released. However, when trying it on a later Corona revision, the console would successfully glitch (stop pulsing) but never boot (I checked the POST code at the time, I think it was a generic panic code).

The same applies with Falcons and Jaspers - I could get Falcons to run very early Blade dashes, but couldn't get Jaspers to anything below the 5xxx and 6xxx kernels.

That brings up an interesting question - what specifically stops the later hardware revisions from running certain kernels? My theory would be that the kernel has certain implementations/functionality within it to account for and to work correctly with the newer hardware. For example, only Xenons (possibly Zephyrs?) could in theory run 2241. I tried and couldn't get Falcons or Jaspers to boot with a kernel that old. That makes sense, as Falcons and Jaspers didn't exist back in 2006.

It's a pretty pointless exercise from a practical use point of view but a fun thing to look into from a technical standpoint. So, does anyone have any specific details as to what stops the consoles from booting? And would it be possible to use XeBuild patches to patch the older kernels to run successfully on the newer hardware?
 
G

godofwrath

Newbie
Messages
21
Reaction score
1
Points
45
Hey everyone,

After looking into XeBuild patches a while back and getting older dashes to run on consoles with newer hack methods like RGH, I've noticed/heard that kernel versions only work on certain hardware revisions of consoles.

For example, a few weeks back, I managed to get 9199 to run on a Trinity console I had with next to no changes, as 12611 didn't come out until several months after the Slims were released. However, when trying it on a later Corona revision, the console would successfully glitch (stop pulsing) but never boot (I checked the POST code at the time, I think it was a generic panic code).

The same applies with Falcons and Jaspers - I could get Falcons to run very early Blade dashes, but couldn't get Jaspers to anything below the 5xxx and 6xxx kernels.

That brings up an interesting question - what specifically stops the later hardware revisions from running certain kernels? My theory would be that the kernel has certain implementations/functionality within it to account for and to work correctly with the newer hardware. For example, only Xenons (possibly Zephyrs?) could in theory run 2241. I tried and couldn't get Falcons or Jaspers to boot with a kernel that old. That makes sense, as Falcons and Jaspers didn't exist back in 2006.

It's a pretty pointless exercise from a practical use point of view but a fun thing to look into from a technical standpoint. So, does anyone have any specific details as to what stops the consoles from booting? And would it be possible to use XeBuild patches to patch the older kernels to run successfully on the newer hardware?


Well you can't just look into the difference between patches, you'll need to find the exact point at which the dash loads on a previous board revision but not on the next, then compare parts (preferably one that seemingly only has minor changes otherwise) since the only difference must be some hardware component that identifies itself differently. Even if it were just as simple as microsoft deciding to create an array of accepted board revisions "xenon", "zephyr", "falcon" etc (oversimplified) and simply added to that array in a particular dash revision, though I wouldn't bet on it being exactly that, and it's likely more interwoven a little bit more than that, but I wouldn't even begin to know where to look for identifying information like that - though you could try ask Martin C on TX forums for information, since he claimed to figure it out and documenting as much of this as possible is always good.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Well you can't just look into the difference between patches, you'll need to find the exact point at which the dash loads on a previous board revision but not on the next, then compare parts (preferably one that seemingly only has minor changes otherwise) since the only difference must be some hardware component that identifies itself differently. Even if it were just as simple as microsoft deciding to create an array of accepted board revisions "xenon", "zephyr", "falcon" etc (oversimplified) and simply added to that array in a particular dash revision, though I wouldn't bet on it being exactly that, and it's likely more interwoven a little bit more than that, but I wouldn't even begin to know where to look for identifying information like that - though you could try ask Martin C on TX forums for information, since he claimed to figure it out and documenting as much of this as possible is always good.

Yeah, it would be very nice if it was as simple as an array of board revisions but I HIGHLY doubt that'll be the case. I think the best bet will be to try one of the dashes that have a small amount of changes like you said then monitor the POST bus to see where it fails and go from there.
 

Similar threads

Top Bottom
Login
Register