Closed p2mate closed 1 year ago
Seems like Retro Replay also doesn't work..
Missing: steps to reproduce & binaries.
now I broke it completely by trying to bisect the issue..
binary is binary.zip
any idea how to recover from this?
Hold restore on boot?
sadly that doesn't work :(
I still get
@ 20000000000000000000000000000000000000000000008EEEEEEEEEEEEEEEEEEEEEEEEE20000000000000000000000000000000000000000000002EEEEEEEEEEEEEEEEEEEEEEEDB7 23A
on the serial console and then the machine hangs
Well, unless Gideon has another idea, you have to make a recovery using your PC and an "USB Blaster". Do you happen to have an "USB Blaster"?
Edit: I guess you have hit the broken FPGA Blob while bisecting. It bricked my Ultimate 64 some time ago - according to Gideon it bricked older Ultimate 64s.
You should have asked - bug mentioned in the topic is already known, and obviously already solved - but Github does not contain a fixed FPGA.
Edit: If you really have hit the older FPGA, and your board is one of those which does not work with that FPGA, there is nothing you can do but using the »USB Blaster«. That will work, I already have had this issue.
@GideonZ The Github FPGA is still the one you announced me with: »...it is buggy with carts. Some carts make the firmware crash really hard, and when set to use that cart as startup.. yup.. bad.« on March 6th. So you already know about the original posting issue...
Well, unless Gideon has another idea, you have to make a recovery using your PC and an "USB Blaster". Do you happen to have an "USB Blaster"?
Edit: I guess you have hit the broken FPGA Blob while bisecting. It bricked my Ultimate 64 some time ago - according to Gideon it bricked older Ultimate 64s.
You should have asked - bug mentioned in the topic is already known, and obviously already solved - but Github does not contain a fixed FPGA.
Edit: If you really have hit the older FPGA, and your board is one of those which does not work with that FPGA, there is nothing you can do but using the »USB Blaster«. That will work, I already have had this issue.
no I don't have a USB blaster.. I have a xilinx JTAG dongle but no idea if that helps. anyway, I can try to locate one.
Compared to Xilinx, ALtera/Intel USB Blasters are really cheap, so if you try "random" snapshots from github source code, having one is a better idea.
the official one seems to be pretty expensive (https://www.mouser.fi/ProductDetail/Intel-Altera/PL-USB-BLASTER-RCN?qs=jblrfmjbeiFezz56mIHRCg%3D%3D) 282 Euro, however there seem to be plenty of clones. Do they work as well? The xilinx 'dongle' I have is also a clone and you can easily make one from a RPI0. https://www.fruugo.fi/usb-blaster-altera-cpldfpga-download-cable/p-124421069-261455335?language=en&ac=croud&asc=pmax is one of the clones for example
Well, my very cheap clone works fine... But since the altera / intel tools won't work with a raspberry, you will need to have a clone (or the original), you can't use a raspberry.
The clone you linked looks fine to me.
ok. I will order that one, can you post the instructions on what to flash etc?
If @GideonZ could post updated instructions, that would be fine.
In the past, I was fine using the following two commands from Quartus (command line):
nios2-configure-sof
nios2-download -g
FPGA can be found in the "external/" directory of the repository. Application is build when compiling.
The application is build while compiling:
The application normally running on the U64 is ./target/software/nios2_u64/result/ultimate.elf
It can be used to start any updater you want.
./target/software/nios2_update_u64a4/result/update.elf Is the updater you may also start instead of the main application.
Edit: Note the above commands do not change anything on the flash. But they allow you to start the regular firmware updater again.
Using your instructions, https://github.com/mithro/ixo-usb-jtag and a cypress FX2 development board I had lying around, I managed to get the machine back to life! Thank you! If you're interested, I can post the changes I made to ixo-usb-jtag somewhere.
Congrats.
Note you can use the same commands to test a firmware without flashing it if you have the .sof and the .elf file.
One important information: U64 builds from this repository do not use the contents of the fpga/ subdirectory, but use the supplied "external/u64.sof" fpga.
Thus bisect does not give you a helpfull commit - you will find it's one of the updates of external/u64.sof.
Congrats.
Note you can use the same commands to test a firmware without flashing it if you have the .sof and the .elf file.
Yes indeed. Good reason to buy a USB blaster which I did now.
One important information: U64 builds from this repository do not use the contents of the fpga/ subdirectory, but use the supplied "external/u64.sof" fpga.
Thus bisect does not give you a helpfull commit - you will find it's one of the updates of external/u64.sof.
No indeed.. I did use the external/u64.sof file. I think we can close this issue here.
Tested with commit https://github.com/GideonZ/1541ultimate/commit/a4e063ef4da8d2d1c1f52ab941b2b82d04fc4786 I did not try to bisect which commit causes the problem but I suspect it might be https://github.com/GideonZ/1541ultimate/commit/63775c9547270bf5549c94987d73cf90628c4910 given it is related to the supersnapshot 5 handling. screenlog.txt