Potential replacement for Spansion S29AL016J
Dolnor opened this issue · comments
Hiya,
I think it's not a secret there's a global chip shortage. I had foolishly assumed one could just get any TSOP48 parallel chip, like Macronix MX29LV160DBTI, and build away based on that. Realization came very late - there are constants in xenium tools and elsewhere (e.g. xenium-programmer) that look for 0x01 0xc4 explicitly and thus the hardware is not classed as a xenium device.
Do we have something remotely similar to S29AL016J readily (albeit at a higher cost) available these days? Farnell has Spansion chips on preorder due late March 2022, Digikey barely has any, looking more likey they actually don't.
The chip IDs is the first issue, recent analysis of XeniumOS shows it also reads the full chip CFI (presumably with additional checks beyong the chip IDs), also this chip has some unique bank sizing at the end of the flash area, which might be common, but certainly not as common as fixed bank sizes.
Finding the S29AL series chip which looks like it is identical to the original Xenium flash chip rebadged was very lucky. If you find anything else please let me know.
Other chips would likely need extensive patching of XeniumOS
I see, so even worse than I had imagined.
The aforementioned Macronix (Manufacturer:194, Device:73) does enable the chip boot into XeniumOS, but it's verry intermittent. The OS allow the BIOS banks to be added and removed and set default, the banks can be booted no problem and everything in the dash/kernel works, but unpon first reboot something corrupts in memory and the console just starts fragging, until the power is disconnected and the console is booted again via the eject button. Rinse and repeat ..
Im surprised it gets that far to be honest. Ill check out the datasheet
Sounds a lot like the self-destruct routines in XeniumOS where it wipes the flash when it doesn't detect the proper hardware IDs. LoveMHz has done some work on this, perhaps it's worth attempting to use one of his patched images as a test.
Tampering with a 1.6 console, thats something I came across alright. The prebuilt xbe is unfortunately also checking for valid flash IDs, so booting to it wasn't a problem, getting XeniumOS actually updated before it corrupts was. I don't have toolchain/nxdk setup to pack that check out of it.
I will see if I can figure out how to grab just the bootloader & xeniumos payloads from assets and program them to the chip.
One thing I forgot to mention - it actually physically ejects the drive before XeniumOS is started. The drive tray persists ejected while you navigate around, which I thought was strange behavior.
As for the experiment to see if self-destruct checks (based on chip info?) have been patched out - in short, that resulted in a big fat nothing. Noticed the const patch_xeniumos is not actually used anywhere in the code, but thought I'd replace that bank anyway, whilst also replacing the bootloader payload at 0x180000 with patch_bootloader. The chip comes on, the LED turns blue, then off and nothing happens, no image on screen, nada. Figured, I'll do just the bootloader bank then - same thing. Looking at the LoveMHz code, I don't see any CRC adjustments to the flash contents, just a byte-for-byte write so it's not likely a direct overwrite of the respective payload in the 2Mb file being flashed to the MX chip has a bad checksum somewhere?
After such failure the aforementioned limbo condition still ensues where the console starts fragging, Not sure if there are any other banks in those 2Mb of XeniumOS that also have some form of self-destruct code. But alas, it looks like this is a no-go.
The only chip that seems to be available (at least here) that matches vendor/device IDs of 0x01/0xc4 according to flashrom is S29GL016A90TFIR1, however looking at the datasheet, the sector layout for 016 variant lists 39 sectors opposed to 35 on original hardware, due to bottom sectors all being 8/4 Kbytes, opposed to varying size.
Now delving into the technical side of this, I recon the memory I ended up with, MX29LV160DBTI, is supposed to be a suitable replacement for the legacy AM29LV160MB, which is in fact Bottom Boot .. so far from ideal just from that side of things alone.
According to this, the direct replacement for S29AL016J70TFI01 is MX29LV160DTTI-70G (damnit, my random choice of components was somewhat close but not quite). Hardware wise, it should be identical, however this doesn't rule out the vendor ID woes, as 0x01 becomes 0xC2 with MX chips. It also doesn't help that MX chips seem to be scarce, too.
I've grabbed a few of the aforementioned top boot MX chips (identical sector layout to the original hardware, except it doesn't implement Secured Silicon Sector), these are unfortunately on back order until late January here, so I'll update the issue if anything changes with the way Xenium behaves using the patched boot code. I have a sneaking suspicion it's the actual software on the memory chip getting corrupted because of effectively flipped sector layout to what the firmware was originally intended for.
Sorry that it's taken me so so long to notice this issue.
The current patch on xenium-fw-update only patches out one of the checks. The additional 'post boot' self-destruct check is only patched in the last batch of OpenXenium we made and I haven't had a chance yet to update the repo.
If the sector layout is different then there are going to be problems. (Secured sectors support shouldn't be an issue though since it's not used afaik). The plan for us moving forwards is to identify a compatible part and work on the needed patches. (Open source of course).
Unfortunately, I don't have an answer today, but it's on my to-do list.
Thanks for chining in with the details on the patches!
I actually have the XboxHD+ order sitting at the post office, waiting to be picked up (they have most ridiculous business hours). Although not sure the Xenium it comes with is the "last batch" as it got shipped some time mid December, I will dump the chip 2MB contents and see what is the bank payload like, i.e. stock blue or indeed has the patches in.
Both S92GL (somewhat wrong sector map) Spansion chips and the MX top boot (idrntical sector map) chips are still not in me hands, so no update on that front.
The Open Xenium I had received with my HD+ order turned out to have bog standard blue OS flashed to it (presumably produced early Dec 2021), having bank CRC32 checksums of 0x0A3D160A and 0x1CF10F96, respectively. When I get the MX chips, it'd be grant if @LoveMHz could provide a raw dump from a recent batch of chips, having the checks patched out, to see how it behaves on a non-native hardware.
A little update on S29GL016A90TFIR1 which I'd stumbled across from reading the flashrom source as having compatible hardware IDs. Got the chips yesterday night. Although these have a different sector layout (39 sectors, SA32-SA38 are all uniform 8/4 KB/Kwords opposed to 35 sectors, SA31 = 32/16, SA32-SA33 = 8/4 and SA34 =16/8 ) to the original, they can be flashed with XOS 2.3.1 recovery file and from there on updated to @LoveMHz 2.3.2 using @Ryzee119's XeniumTools. The DVD drive is not being ejected as happed with MX bottom boot chips, nor the firmware corrupts/self destructs after a complete power cycle. FTP, Web server and all the hard disk tools seem to work, have not tried stuffing it with bioses to the brim, but my guess there shouldn't be any problems with it.
As the aforementioned Spansion chips are hard to come by too, they aren't a great alternative. But what it tells us is that the layout of the sectors, as long as there's at least 31 size 64 KB sectors and the chip is top boot, doesn't seem to matter to XOS. Which makes it easier to look for a possible alternative that is readily available...
I'm supposed to be getting MX29LV160DTTI-70G chips some time the following week, so will update on how that goes.
Apologies for disappearing off the face of the earth, had to deal with a loss of a relative.
An update on MX29LV160DTTI-70G as promised earlier (hardware ID 0xC2:0xC4 vs 0x01:0xC4). To cut a long story short - it's exactly the same as the bottom boot MX29LV160DBTI I've stated with. The chips can be programmed ok, the first time you boot via Eject, red light comes on from CPLD, followed by amber, blue, the drive actually ejects physically, followed by LED off (typical is: red, amber, red, off) and XOS comes on as normal. You can add the boot items and boot whatever the BIOS you desire but on the first reboot the contents of the chip get wiped by the self-destruct code. If flashed over with a raw dump from a bog standard OpenXenium that was previously updated to @LoveMHz 2.3.2, the chip ejects the drive but refuses to boot to XOS, period.
Hi Dolnor,
Have you tried the newer MakeMHZ OS releases that has reportedly removed the self destruct code?
https://github.com/MakeMHz/xenium-fw-update/releases
Regards.
I haven't tried the bottom boot chips (I suspect they might work based my original attempt, despite the sector arrangements being completely backwards), I have however tried the top boot MX chips (that are supposed to be direct S29AL016J replacement) and these have worked OK. I have recompiled both the update and xenium-tools to enable the 0xC2 to be recognized as an alternative vendor ID to enable these tests with an otherwise incompatible config chip. From my tests, the entirety of self-destruct code has indeed been removed as of 2.3.4a update by @LoveMHz.
Seeing as DIgikey has a relatively high stock of MX29LV160DTTI-70G, this could well be an ok alternative for the time being, although flashing XOS onto the chips will require some tinkering.
blah I have been trying with the help of a few others to program a bottom boot S29AL016JFI02 chips, and have been unsuccessful.
I have got a batch of Spansion 02 chips myself here (thanks to the usual aliexpress false advertisement). While I have some PCBs around, my soldering equipment is packed at the moment due to house renovation so I'm afraid I won't be of help. I did however try to flash them via xenium-programmer (you seem to be using too) and they were validating correctly. Your best bet would be to get a 01 chip flashed, updated to 2.3.4a (at the very least) and have it dumped via xenium-tools, then flash the bin over via xenium-programmer.
No worries. May well post it here how you get on.
P.S. This was quite a surreal moment having closed the topic and watching someone stumble upon it whilst livestreaming mere minutes later haha
Oh, great stuff Dolnor, well done.
So what's the procedure to program the MX29LV160DTTI-70G then? Update a regular working spansion to Makemhz 2.3.5 and then dump that and use that to program the MX chip?
Thanks again.
Neil.
If you already have access to a working OpenXenium with a config chip proper, that would be a path of least resistance. The only thing you'd then need to do would be either rebuild xenium-programmer to accept the 0xC2 (Macronix) vendor ID or amend the same thing in Xenium-Tools and rebuild that, so that either could treat the MX make chip as valid hardware when programming XOS binary.
Ok, thanks for that.
Any chance of an upload of the Xenium-Tools with the 0xC2 patch ID applied and compiled as I'm on a MAC :o)
Still at work, the project is sat in my WSL at home .. if I don't forget, I'll put it up somewhere. In the meantime, we may ask @Ryzee119 politely to implement the alt mfg id formally, which probably should cause Xenium-Tools to hide the 'Write XeniumOS 2.3.1 Update File' option if it detects a 0xC2 make as it would otherwise allow the user to instantly fubar the chip, if selected.
The crude way I've amended the code is made the (essentially bool) method returning 1 for detected and 0 for not detected return a uint16 instead, which is then passed through a case switch to see which chip is being used, if any that is valid.
Yep, either way it would no doubt be appreciated by all trying to save and fix up some consoles.
Many thanks.
Neil.
As promised, here's the pre-build xbe.
Superb, many thanks for that, it's appreciated.
Oh, getting an error trying to expand that zip for some odd reason.
OSX has problem with certain zip specifications. Try The Unarchiver, from memory it was the only software that was able to remedy that.
On a side note, I've got about a dozen built and programmed Xenium chips after this experiment, which I'm willing to sell/ship across Europe. If interested, drop me an email.
Ah right okay, tried terminal and got another nag "need PK comat v6.3", then tried MacPAR deluxe too.
Downloaded Unarchiver - bingo ! Worked as you said.
I've got some chips, missing the flash, got ripped on alix as usual so was stuck, so hopefully can get a few chips from digikey now tah.
This was more of a PSA rather than a targeted sales pitch haha. Although, I appreciate most people lurking around here are probably interested in building their own hardware rather than purchasing it off of someone else. Just had personal 3 boxes sorted and now left with a pile of chips that could help recoupe the costs of buying random memory chips for this experiment, given the current market prices and lead times..
You'll have no problem shifting some chips right now, and no doubt recoup your outlay and then some! haha
I dunno, this IC shortage malarky is a disaster really for all kinds of projects really.
A shout out to Dustin as well for removing those self destruct routines as well.
Thanks again,
Neil.
Just FYI Digikey had 15 in stock a few days ago and I ordered them all, I went to re-check and now they have 1040 in stock. If you need some, get them now!
https://www.digikey.com/en/products/detail/cypress-semiconductor-corp/S29AL016J70TFI010/3761535
Cheers for the heads up! Makes you wonder how true the "This product is no longer manufactured and will no longer be stocked once stock is depleted" statement actually is...
Here's hoping it's not like cough element14 cough, saying they have thousands of this one SKU in stock and then sending you an email thanking you for the order whilst saying the lead time is gonna be 22/12/12...
Wow that was quick, all 1000 are sold!! Luckily I got a bunch