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