XeniumOS: v1.0 Xboxes 'frag' when booting Cromwell/Xblast from XeniumOS

[ryzee119]

XeniumOS: v1.0 Xboxes 'frag' when booting Cromwell/Xblast from XeniumOS

[gaasedelen]

I looked at this briefly last spring and I felt pretty confident that the issue was going to stem from when they changed around cromwell's memory layout: XboxDev/cromwell@5702a10

This PR from mike also felt relevant: XboxDev/cromwell#53

It suggests that Cromwell probably took an accidental dependency on some cached CPU state (or MCPX 1.0 artifacts) that get blown away by the fact that OpenXenium always boots into an XOS stub first.

I'm kind of looking back at some XOS stuff for fun, so I'll drop any other related notes here if I think they're useful.

[gaasedelen]

Just to follow up, I did investigate this awhile back (at least for XBlast) and I don't really think there's anything that can be done on the OX side.

The reason XBlast does not boot off an OX on 1.0 consoles is because of how strict the timing threshold was on the SMC challenges for 1.0 hardware. On 1.0 consoles the SMC must receive correct responses to the retail SMC challenges within ~125ms of power on. XBlast booting off OX does not complete them till ~150ms (based on what I traced on a scope).

Maybe the xenium CPLD logic for address translation / fetching from the flash is a 'bit' slower than dumber modchips, slowing down the XBlast boot just enough to fall outside the acceptable threshold to complete the SMC challenges.

Really, I would argue this is more of an XBlast issue than an OX issue. This is because XBlast first copies the entire 'OS' (~140kb) from flash into RAM before bothering to complete the SMC challenges... and this is particularly slow over LPC.

https://github.com/ldotsfan/lpcmod_os/blob/96e6a95912fb236c5d8c263d2e5836645df9c140/boot_rom/2bBootStartup.S#L240-L248

IMO the correct solution is that XBlast should perform the challenges in its bootloader before it copies its OS from flash to RAM. This is what the Microsoft bios' do (prior do decrypt, and decompression of the kernel), and basically every other scene bios.

Maybe it's possible that the Xenium CPLD logic could be 'improved' to speed up the flash addressing or w/e but I'm not totally convinced. But I'm not sure it's worth it tbh. Most people use XBlast only to test RAM upgrades, which would require OX xcodes to also be modified to support booting with mismatched ram chip numbers.

Anyway, just wanted to post this for context. I'm not sure there's a good fix here, besides both updating XBlast and xenium flash xcodes. But that probably falls outside the scope of this repo.

[catogtp]

I can confirm that xblast is now booting on a 1.0 after this update. It previously would fail to boot and reset the console loading XOS again. No hiccups and other bioses now seem to init faster and boot up with less noticeable lag.

[GXTX]

Just a guess but I think Xcalibur stuff is what broke it, between 2.30 and 2.31 that's about all that really changed although there were 40 commits - most being tiny code changes outside init stuff. 2.31: 98cc81d 2.30: a1b92cf and Xcal was added in 3bb29b8.

[GXTX]

Seems there's more too it. Pulling out all the Focus and XCal init stuff from XCodes.h produces the same result. Perhaps they changed more in the xcodes than just xcal init between those revs? I didn't really check too well.

[Ryzee119]

Thank for you taking the time to dig into this. I did some what consider challenge response times in development however as I was never able to repeat this during dev I didnt look into it further.

In the CPLD I used 6 wait states for read and writes. I cantt recall exactly why I chose 6, but the access time of the legacy xenium flash chip is 100ns, so the minimum we could get away with a 4 wait states (4x33Mhz ~ 120ns) atleast on paper. I probably just increased to 6 for a safety factor.

Modern flash chips OX uses have 70ns access time, so we could get away with 3 wait states in this instance, but I would want to remain backward compatible.

With 4 wait states we could save ~60ns per byte. Which could help.

The line is here:

OpenXenium/Firmware/openxenium.vhd

Line 359 in ddff195

COUNT <= 6;

If you or anyone have a setup to synthesize and reprogram without too much effort it could be worth testing, but I would not be able to do this anytime soon. The legacy Xenium used less than 6, I recall it being 3 or 4 wait states and the issue seemed to still be present based on the first post in this issue so hey, maybe not.

But as you say Cromwell probably should not copy the entire OS on boot up and it would still straddle the challenge response time limit.

[gaasedelen]

Neat, good catch.

I actually do have a VM setup to rebuild the VHD from when I was poking at some stuff a few months back. I can dust it off and test both 3 & 4 wait states this weekend.

I'm calculating that this could save ~9-12ms on XBlast, which could be just enough to squeak under the threshold. The spread might have actually been tighter, but I won't hold my breath.

[gaasedelen]

I just want to confirm that dropping wait states to 4 (even 3) keeps the chip functional but does not resolve the issue. XBlast still does not boot on a 1.0.

I haven't actually taken new measurements with a scope, maybe tomorrow if I have the time I'll hook it up and try comparing a 6 wait state chip versus a 3 (maybe even a 2??) to see what the measured timing differences actually are.

haxar pinged me to say that he added an experimental commit to cromwell based on this discussion which will hopefully rectify it on that front: haxar/cromwell@1a258b1

EDIT: As a slight aside, I do feel like it perceptively speeds up boot a bit. In theory it actually should save 50-80ms off of every boot for a system with a Xenium installed.

[Ryzee119]

Should be fixed by v1.4 and requires the CPLD firmware to be upgraded. I am unable to test as I dont have a v1.0 Xbox so hopefully I get some feedback from some users before closing this issue.

RAM upgrade testing will still not work as XeniumOS cannot be started with partial RAM installs.