1.6 with 128MB RAM unable to boot.

[Andr-Zero]

I've noticed since using the 1.4 release, the 1.6 boards that I've been upgrading to 128MB RAM are unable to boot. When powering on the console, the LED on the OpenXenium will start it's cycle and stop on solid blue. The front LEDs on the console will be flashing green until powered off.

Long story short, I ended up testing various different chips (Aladdin, Authentic Xenium, X3, X2, & CheapMod). They all seemed to work okay booting the console. I had another OpenXenium on the 1.3 release and decided to test to find out that it loaded XeniumOS just fine.

To verify that it was indeed the 1.4 release causing the issue. I decided to do something sketchy (Don't recommend) of connecting the CS lines while xBlast 0.60 was booting. This showed the RAM install works after getting past the OpenXenium boot process. Then I took the same chip that had 1.4, reflashed to 1.3, and now the console boots reliably.

I'm not sure if this is the case for all 1.6s with RAM upgrades, as I don't remember running into this issues until this week. Maybe I finally ran through my stash of 1.3s, possibly only select 1.6s, or some tolerance thing with the RAM upgrade?

[Andr-Zero]

Update

I have three 1.6s now that simply wont work with 1.4, I have several that do work... I would suspect the install, but they are stable on the 1.3 release.

No idea what the differences are. Even tried swapping the RAM from between the ones that have issues and others that don't. No change, the board that had issues still does and the ones that didn't still don't have issues.

[Ryzee119]

Which flash chips are you using?

[Andr-Zero]

Samsung. I've tried both "New" and ones harvested from other boards.

[Ryzee119]

Sorry I mean flash chips on the xenium chip

[Andr-Zero]

OH! You did say flash! Sorry about that. I have some with the Spansion chips, two with the spec'd AMD, and several with MX brand. Spansion and MX I can reproduce, I can test the AMD chip later this week. (Have those installed in another console in storage).

Thinking the flash access being too slow?

[gaasedelen]

Just as a datapoint, I tried this on the one 128mb 1.6 I keep on the shelf for testing / edgecases like this and could not reproduce the issue.

I tested with both a 70ns Spansion (per the repo) running OX 2.3.1 and the official 1.4 SVF. I also tested with one of my 55ns Spansion OX running with lower wait states and OX 2.3.5.

When powering on the console, the LED on the OpenXenium will start it's cycle and stop on solid blue. The front LEDs on the console will be flashing green until powered off.

No video, or hanging without frag (OX or not) on bootup almost always means the CPU faulted (bad data/instructions) mid boot. This is either bad data from the chip or an issue with RAM regions used later in boot / system runtime.

It's almost never an LPC soldering issue because the system would not even get past RAM or SMC challenges (FRAG) if it was not communicating well with the chip. People also seldom flash images with a mostly working bootchain but a borked kernel.

If your OX with the 1.4 SVF is working fine in other systems or boards, then the flash access on the chip is probably fine. That more or less leaves us with this being a RAM issue... It'd be interesting to see how that board performs under more memory intensive operations.

[gaasedelen]

Also, part of the reason odd boot hangs are more common on 1.6 upgrades is because the power-on memory test of the lower / retail 64mb is woefully inadequate. It's not at all uncommon for people to cause issues to the retail banks which can slip past the red/orange RAM frag claiming "but the 128mb test passes in XBlast!" (which only checks the upper banks) while getting confused when an MS kernel hangs.

It's not to say this couldn't be a software-ish issue. XOS for example does not do RAM training like MS bootchains, but people also do not update any other passives for these 128mb 1.6 upgrades so you're already playing a dangerous game :-P

If there's not an outright soldering issue (continuity != integrity @ 200mhz) I think this is probably another piece of evidence showing how the mod may be pushing these 1.6 boards out of spec, which is why I generally don't recommend doing it.

[Andr-Zero]

Personally I'm not a fan of stacking RAM chips. However if I'm asked to do so for someone... I don't mind.

I've also learned not to trust xBlast's RAM test. I usually test with a patched version of Halo2, N64 Emulation, and HalfLife 128MB version. Probably better options to test with, these are just the ones I picked and it seems okay? Open to better suggestions for testing. These three consoles that I'm having issues 1.4, have been able to play for hours without problems with 1.3 or any other chip. I've upgraded about 15 or so 1.6 consoles, there are the only three that's given me issues. So a very small sample size. I'm not ruling out a installation issue, or some component out of tolerance. Just mentioned something here since it seems stable with any other combo other than the OX with 1.4.

When I do these upgrades, I do try to cut the CS line to match clock sync in comparison to the stock chips. Not sure if it matters, but it does calm my OCD. I've also been wanting to try to fix the impedance mismatch caused by the stacked chips. That's a bit off topic though...

[gaasedelen]

To be clear, I'm not calling this a user error. I do think it's an interesting case, so thanks for opening the issue! Obviously OX breaking on certain configurations is not good.

From what I can tell, the CPLD itself is operating correctly. But what is happening is that the faster LPC reads is exposing the corners that were cut in XOS (and its age) or a hardware deficiency on the motherboard.

It's hard to diagnose it much further than that remotely, will have to keep an eye out and see how common this is.

[Ryzee119]

Unless your spansion chips are particularly slow ones, they are 70ns access time. On openxenium even with the "faster" speeds its still 4 LPC clocks (~120ns) (TAR1, TAR2 + 2 wait states) which I think from memory is how many the genuine xenium had.

The other change in v1.4 is to do with releasing the bus when its an unknown command. This allows other devices to work in parallel. I'd maybe need to bisect here and isolate which commit specifically is causing it.

Although its particularly weird that the RAM changes make it happen specifically. This doesnt make any sense to me.

[Ryzee119]

Could you try this? Ive just removed the speed change commit but kept the SuperIO compatibility stuff - to help isolate specifically which commit might be causing it openxenium_ddff195.zip

[gaasedelen]

Could you try this? Ive just removed the speed change commit but kept the SuperIO compatibility stuff - to help isolate specifically which commit might be causing it openxenium_ddff195.zip

FWIW I had my 128mb 1.6 setup with an OX and superio for over a year and it has been fine.

@Andr-Zero What RAM chips are you using using on the boards that do not work? Are they M, D, F, or Hynix? If you are using chips that differ in die revision, that can also be an important contributing factor.

There is non-negligible differences in the current requirements of M-chips versus the more refined F-die chips for example. This paired with the complete lack of RAM training by XOS could explain the issue.

The RAM I have stacked on my working 1.6 matches the board, F-dies.

[Andr-Zero]

@Ryzee119 Just tested the diff 195 and it does the same thing as the 1.4 release. Solid blue on OX and flashing green power LED on console.

@gaasedelen I think you might be on something there. I am installing the M variant. I did not check what was preinstalled before I stacked, Very possibly F. I do have some F that I can install the next time I run into this issue. (Not really wanting to undo one that works fine on 1.3 release). I'm also about to build a SuperIO as well, just waiting on the PCBs.

[gaasedelen]

Honestly, I would be very surprised and confused if the breakage you're experiencing are reproducing with only the changes to support SuperIO and not the speed changes. It might be worth double checking you flashed the right SVF, or possibly @Ryzee119 uploaded the wrong SVF?

I have never experienced anything like this, and I've been actively using those SuperIO changes on a lot of boxes since they were committed two years ago.

[Ryzee119]

Definitely the right file :) imo the lpc bus changes could be conflicting with xyclops on a 1.6 - which still doesnt explain why the RAM upgrades changes anything.

One thing you could try is to ground LFRAME on the console and see if that changes anything? This will with certaintly stop xyclops talking on the LPC bus

[HoRnEyDvL]

Just as a FYI. I'm also experiencing the same same thing. 1.6 Xbox 128mb ram Samsung they are all M series. 1.4GHZ CPU upgrade.

Just frags the the console. Tried same chip on other Xbox works fine. using Aladdin mod-chip console boots and functions with no problem.

Xblast all ram passes the checks.

[HoRnEyDvL]

@gaasedelen @Ryzee119

I think the issue is with Xenium-OS instead of the 1.4 update.

Flashing an older version of Xenium-OS v2.3.1 & the console booted no problem at all. Yes we have the graphical issues with 1.6 encoder but yeah.

Any of the newer updates from MM & the console will not boot.

@Andr-Zero , can you give that a shot to prove if it also works for you ?

[gaasedelen]

Just as a datapoint, I tried flashing 2.3.5 to the OX in my 128mb superio 1.6 to test this today and I didn't have any issues/hangs/crashes across a dozen or so boots.

I don't really have any other suggestions on the OX side besides re-testing with a VHD built with only superio, and again with a separate build that only has the speed changes. Alternatively, removing the M chips and replacing them with matching F chips is also something I would recommend testing.

[Andr-Zero]

@HoRnEyDvL I can test XOS v2.3.1 here in the next few days and report back. I find it interesting that yours is FRAGing, mine would just freeze mid boot.

[Andr-Zero]

@HoRnEyDvL

Confirm. 2.3.1 does indeed boot fine with the 1.4 CPLD firmware. I also swapped all M chips over the F series and the result is the same.

I also have someone who I sold a chip to having the same issue with a non-1.6, stock ram configuration board. I'm waiting on more info from the buyer before I want to say it's 100% the same issue. Not sure how it would be, though I'm not sure how it is with 1.6s either...

[Andr-Zero]

Here's the last bit of testing I've done. Really just rehashing what was said on Discord here for continuity on this issue here on Github.

Setup: 1.6 Xbox with 128MB RAM, OpenXenium w/ CPLD firmware 1.4

First test: Booting XOS 2.3.5 with a Xbox2HDMI, Pound cable, Official Component cables, DIY Component cables, and just setting the HD mode on the AVIP connector. All yields the issue described above. OpenXenium LED stuck blue, Power LEDs flashing. XOS version 2.3.1 boots, just has expected graphical glitches, any newer version do not.

Second Test: Same as first test, EXCEPT using a standard AV cable. XOS 2.3.5 boots.

Third Test: Same as the first test, EXCEPT in another Xbox I set the OpenXenium to instant boot a BIOS. Then moved the OpenXenium to the problematic Xbox. Pressing eject to boot into XOS 2.3.5 fails, solid blue on OpenXenium, flashing Power LEDs. Pressing Power to instant boot BIOS, WORKS! It boots as expected directly into the BIOS.

Fourth Test: Removed 64MB of RAM going back to stock configuration on problematic board, CPLD 1.4 firmware, XOS 2.3.5, and using HDMI adapters or Component cables. XOS does not boot. Instant boot does work, same as test 3. Standard AV does boot just as test 2 does.

I now say this is not related to 128MB of RAM on a 1.6. I don't feel this is an OpenXenium issue anymore. Something with CPLD 1.4 Firmware just highlighted some odd quirk with XOS 2.3.2+.

Shall we close this?

[HoRnEyDvL]

@Andr-Zero I wouldn't close it as it still a pending issue that requires a fix. Appreciate all the tests you ran I can confirm the same results. I was unable to twat removal of ram but don't wee it having any difference.

[Ryzee119]

I'd personally close this but raise another place holder 'for information issue that is a summary of the symptoms and causes for visibility for other people. This issue is good but has a lot of noise from troubleshooting. The placeholder issue will be similar to the other issues I have for XeniumOS.

The issue seems to point to community patches which are out of the scope of this project; you may be able to raise an issue on that git page.