Flashing an Iyonix after replacing the Flash ROM
Jon Abbott (1421) 2599 posts |
Well, its no wonder I’ve stuffed both my Iyonix trying to flash the ROM… The programmer turned up yesteday, so I dropped in the first Iyonix’s flash chip (having already unsoldered it from the motherboard) and reflashed it, it failed on the second word. This confirmed my initial thought that the flash chip was faulty. No problem, grab the new one I’d already purchased and flash that…fails around half way through with the same bit always inverted within a particular word. Either I’m just really unlucky, or 4MB AMD flash chips are not particularly reliable. Before attempting to reflash the first Iyonix’s chip, I read it to see what the RISC OS reflash tool had done. The whole chip was FFFF, with a few random words having bitrot, so it looks like it had performed a complete erase before attempting to program it and subsequently failed on the very first word. Reading the second Iyonix’s flash, it visually looked okay to me and I’m loathed to attempt to flash it, in fear of it also being bad part way through. If I can find the ROM build that was originally flashed on it (5.20 I think, it doesn’t look like the RISC OS reflash did anything), I’ll do a comparison to see if it also suffers bitrot. Assuming it’s good, then the second Iyonix has probably developed a motherboard fault and is likely failing during POST, before initialising the GPU. Next step, attempt to return/replace the new chip and purchase spares, pre-empting the inevitable failures, frustration and disappointment. |
Jeffrey Lee (213) 6046 posts |
Dropping an email to ROOL might be your best bet, if you don’t have a copy locally. I was expecting some casual URL editing to reveal that the old ROMs are still available from the download folder, but that doesn’t seem to be the case. |
David Pitt (3386) 1248 posts |
I have a copy of Tungsten-Flash/5/20/zip if that would help. A peek inside ’trom’’ shows RISC OS 5.20 (10 Jun 2013). A temporary upload is at http://pittdj.co.uk/temp/Tungsten-Flash520.zip |
Jon Abbott (1421) 2599 posts |
Thanks David, I’ve grabbed the file if you wish to remove it. I’ve now ordered a job lot of AM29LV320DB90EI’s from China at £2.50 each, fingers cross at least one of them works when they arrive. |
Jon Abbott (1421) 2599 posts |
A question regarding the softload ROM, can that be used to write the flash? There’s no difference with the flashable download? Second question, is the date wrong in the RISC OS build environment because last night’s ZIP’s ROM filestamp is 11-11-17 EDIT: I’ve compared the contents of the flash in the second Iyonix with 5.20, it’s almost identical, with the following differences:
I conclude from that, that its developed a hardware fault and my attempted flash the other week just happened to be at the exact same time! |
David Pitt (3386) 1248 posts |
I have just flashed OS5.23 (19-Nov-17), Iyonix still working five minutes later.
Nvidia card patching, I noticed that reported during the flash.
It’s showing the 19th here, now. |
Jon Abbott (1421) 2599 posts |
I can’t just program the ROM into the flash and then solder it onto the board then, I’ll need to possibly modify it first for the GPU to work? How do I know what to alter for the first Iyonix, where I don’t have the original flash contents?
The ZIP is the 19th, but the ROM inside is dated the 11th – unless it’s changed since I downloaded 20 mins ago. I’ve not looked at the ROM itself to see if it’s internally dated the 19th. I’d probably need to flash it to find that out anyhow. |
Doug Webb (190) 1130 posts |
Well the Iyonx softload I used yesterday is the 19th Nov 17 and also I’ve just downloaded again and the ROM date from the download is 19th Nov 17. |
Jeffrey Lee (213) 6046 posts |
As David mentions, that looks a lot like it’ll be the NVidia card patching. This is performed by both the softload tool and the flash programmer. (and now that I think about it, it isn’t performed by the built-in recovery code)
It’s used to cater for cards which "get ‘confused’ at startup and report wrong configuration information". It looks like it’s used to override the contents of the NV32_NVSTRAPINFO2 register. If left at default the register won’t be overridden, so whether it works or not will depend entirely on whether the card is sensible or not. Since you’ve got two Iyonices, if you program the flash and find that it doesn’t work you can always try swapping the graphics cards. Or, since the flash from your second Iyonix looks like it’s correct (just the strap data + ROM checksum which differ from the 5.20 image), you could use that ROM image + graphics card in the Iyonix which had the dead flash, and use that to interrogate the other card to determine the right strap data.
I’ve just downloaded today’s ROM, and it’s the same zipfile as yesterday, containing a ROM file with a timestamp of 1:31 on the 19th. (Maybe some weird browser/proxy caching going on?) Also while looking through the Tungsten HAL, I’ve spotted this doc which gives some clues on how to flash an Iyonix via JTAG. I’m not sure where raminit.log is (which is probably the most important part!), but I’d guess that FlashProg,ffd is the assembled version of this code, and TROM will be the ROM image. |
Jeffrey Lee (213) 6046 posts |
Since Iyonix ROMs should always have valid checksums, if in doubt you can save the ROM from your working flash chip, grab a rompress binary and use the |
Jon Abbott (1421) 2599 posts |
Just downloaded it again, the ROM file is timestamped 11-11-17 and the version @ &40914 within the ROM image says 12 November 2017. Must be something up with the download link, which for me shows as: https://www.riscosopen.org/zipfiles/platform/iyonix/TungstenDev.5.23.zip?1511080573
I suspect raminit.log is generated, FlashProg,ffd is the important bit. The missing information is which JTAG adapter/software this works with and where the JTAG header is on the motherboard.
I’ll do that, thanks for the advice. Assuming the 5.20 image validates, I’ll program the replacement flash with it, get it booting, then reflash within RISCOS with the nightly. |
Doug Webb (190) 1130 posts |
That is the same link that I get by hovering over it so suspect it may be a caching issue somewhere? I can send you the zip file if required. |
Jeffrey Lee (213) 6046 posts |
That’s the same link I’m seeing. Try using curl -v https://www.riscosopen.org/zipfiles/platform/iyonix/TungstenDev.5.23.zip?1511080573 > /dev/null Note that the output is redirected to null to avoid flooding the console with the zip file contents (the headers will still be printed OK). The RISC OS port of curl will also work for this, although you may need to specify I get the following response headers: < HTTP/1.1 200 OK < Server: nginx < Date: Mon, 20 Nov 2017 14:51:04 GMT < Content-Type: application/zip < Content-Length: 2426987 < Last-Modified: Sun, 19 Nov 2017 08:36:13 GMT < Connection: keep-alive < ETag: "5a11427d-25086b" < Strict-Transport-Security: max-age=63072000; includeSubdomains; preload < X-Frame-Options: DENY < X-Content-Type-Options: nosniff < Accept-Ranges: bytes Last-Modified and ETag are likely to be the most important, since they’re used by HTTP caches to decide if you have an up-to-date copy of the file. nginx ETags are just the timestamp & size of the file, so aren’t infallible, but in this case it’s probably good enough (and appears to be correct). (Note that the ?1511080573 URL query parameter is also the unix timestamp of the file – I have a feeling that adding the timestamp to the URL is an attempt to prevent caches from returning old copies of the file, however in your case it doesn’t seem to be working) If you’re seeing the wrong headers returned (or the correct headers but wrong content) then there must be some kind of dodgy cache upstream from your machine which is interfering with things (although since the site is on HTTPS, I’m not sure exactly how that would work). If you’re seeing the correct headers + content when using curl, then it must be your browser being dodgy (or ROOL are running a buggy version of nginx which is generating incorrect responses to conditional GET requests from your browser) |
Jon Abbott (1421) 2599 posts |
curl returns the same response you see, it’s a strange one – never had an issue previously although from a quick look at a few ROMS I’ve downloaded the contents datestamps don’t match the internal rom build date, so it’s possibly been affecting me for a while. I’ll wait for the next build, hopefully it will catch up. |
David Pitt (3386) 1248 posts |
It, for some reason, depends on where the unzipping is done. RISC OS is fine but a download and unzip via Ubuntu 17.10 shows a ROM datestamp of 11-11-17 when viewed on RISC OS after a LanMan98 transfer. I think this has come before, either here or csa. |
Will Ling (519) 98 posts |
Surely the first part of the original flashing would have created the !Restore5xx app*, so you could pull that, assuming you have some other machine you can connect the hdd to. This would have the original rom including the required nVidia patch. |
Jeffrey Lee (213) 6046 posts |
Good point – I’d forgotten about that. (and yes, it does still create the !Restore5xx app) |
Steve Pampling (1551) 7931 posts |
It was here, I recall the ‘conversation’ which covered something I’d noted. If Jon hasn’t noticed it before then it’s probably because he never looked into the zip archive on a PeeCee before. |
Jeffrey Lee (213) 6046 posts |
Confirmed! I’m seeing the same thing with the ROMPatch zip I just created, so this smells of a bug in the RISC OS version of Zip which is being used (RISC OS metadata stored correctly, but native zip timestamp stored incorrectly). I’m also seeing identical things with the zip version available from riscos.info (which is probably where the copy of Zip in CVS came from), so I expect some (more) patches need to be sent in that direction (and I guess the official info-zip website, on the offchance they actually release Zip 3.1, which seems to have been stuck in purgatory for the past 9 years) |
Jon Abbott (1421) 2599 posts |
I’m not going mad then…that’s a relief! |
Jon Abbott (1421) 2599 posts |
I’ve finally got around to putting the new flash chips on the two Iyonix boards, unsurprisingly neither boot. Iyonix 1 I flashed with 5.24 and Iyonix 2 I reflashed with a previously working 5.20. If the nVidia changes aren’t made to the ROM before its flashed, will the Iyonix still boot? Or, will it fail when it attempts to initialise the GPU or even fail with a checksum error?
The rompress download appears to be corrupt so I couldn’t check the images. It has “rcc 5.12” at the end of the file, but the rest is not an Absolute. |
Jeffrey Lee (213) 6046 posts |
Ideally it’ll boot just fine. But if the graphics card you’re using is one of the troublesome ones which needs the patching to work correctly, then it’s hard to say what will happen without the patching being present. Possibly you’ll get no video output, or worst-case it’ll hang completely during ROM init.
Try again – looks like I forgot to flag it as binary within CVS. |
Jon Abbott (1421) 2599 posts |
Thanks, rompress doesn’t report any errors on either ROM image so I can assume they’re okay. I guess the next step is to figure out if the ARM is actually reading the Flash and attempting to boot. |
Tristan M. (2946) 1036 posts |
I’m curious about the hardware side of this. How are the ROMs packaged? The desolder / flash / resolder cycle can’t be good. I can at least assume your equipment is way better than mine. …and in one brief moment I remembered the SPI flash chips I bought for my project and discovered they were missing. That’s life I guess. How’s this resolving? |
Jon Abbott (1421) 2599 posts |
A 48 pin Flash chip, I don’t have the part number to hand but the replacements are manufactured by AMD.
The original Flash chip was bad, so thrown, resoldering wasn’t difficult with liquid solder as it just needs a heat gun. Liquid solder pretty much does away with the issue of shorts due to bad soldering, provided it’s either put on with a mask or thin enough if a mask isn’t viable.
Probably not, I tried a proper solder reflow station but the heat gun was too big for me to see what I was doing. In the end I just used a small gas soldering iron with a heat gun bit on it.
It’s not, it’s an on going saga that started 5 years ago when I attempted to flash my first Iyonix via software upgrade. You can reflash them via JTAG, but the method has been lost to time, so there’s little option but desolder and reflash externally. |