New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recover flashing doesn't work when firmware or gateware is flashed #252
Comments
Yes, and we can even get it from libfx2. |
One of the examples? They don't have binaries checked in and we don't want to require sdcc. I also think we should upload special firmware, because if the flashed firmware is completely broken (that is what recover is for), then we really don't want the fx2 to load it. |
No, |
Ok, there are binary wheels now: https://pypi.org/project/fx2/#files |
Specifically, I'm referring to the firmware loaded when you run |
Ok, so the solution for factory would be:
Are the eeprom commands the same between boot-cypress.ihex and Glasgow firmware? |
Yes, intentionally. |
(You can also use fx2tool's EEPROM commands with Glasgow without replacing its firmware with the bootloader, although you can only access the FX2 EEPROM that way, not the FPGA EEPROM. Which is fine.) |
Hmm, let's say you have bad gateware flashed. Once you load the Glasgow firmware into the ram of the fx2, it will start to load this gateware, right? So i think factory should also clear the FPGA EEPROM. Can the boot-cypress.ihex do this or does it just have the commands for the FX2 EEPROM? To me it looks like it just handles the FX2 EEPROM. |
No it won't if the configuration doesn't tell it to do that. |
Ah, ok, I haven't looked at that part yet. So the boot-cypress.ihex is fine then when we clear this config bit. |
Before this commit, some aspects of factory flashing (device enumeration and initial loading of firmware) were handled in the production flow. However, this interacted poorly with the device recovery flow, since uploading a production firmware causes the device to re-enumerate. * Re-enumeration is not very reliable, especially on Windows. (GlasgowEmbedded#252) * If more than one device is connected, re-enumeration could cause the wrong one to be destructively reflashed, since USB has no geographical addressing. In addition, behavior related to `--force` depended on the device EEPROM state, which is not appropriate to either factory flashing or the recovery flows. This commit solves these issues by separating (and simplifying) the production and the factory flashing flows. * The production flow only opens VID_QIHW:PID_GLASGOW devices (factory flashed) and loads only the production firmware. * The factory flashing flow opens VID_CYPRESS:PID_FX2 devices with no options, and VID_QIHW:PID_GLASGOW devices with `--reinitialize`. * The factory flashing flow loads the Cypress bootloader firmware, regardless of VID:PID. It ignores the EEPROM contents and flashes the configured revision and serial, as well as the built-in firmware, and asks the operator to power cycle the device. The notable differences are: * The factory flashing flow is incomparably more reliable. * The factory flashing flow is flashing a firmware in addition to the configuration block, halving the amount of programming steps. * The factory flashing flow no longer attempts to prevent you from flashing an already factory flashed device. This might seem bad at first glance, but: - It was added, IIRC, to handle potential re-enumeration bugs, which are no longer present. - It actively got in the way most of the time. - It's not *that* destructive--you just lose your serial, and even that only if you did not have it on a sticker or written down somewhere. (If you care about the serial it is probably because you have it in a script somewhere, so the problem of backing it up solves itself.) Fixes GlasgowEmbedded#252.
Before this commit, some aspects of factory flashing (device enumeration and initial loading of firmware) were handled in the production flow. However, this interacted poorly with the device recovery flow, since uploading a production firmware causes the device to re-enumerate. * Re-enumeration is not very reliable, especially on Windows. (GlasgowEmbedded#252) * If more than one device is connected, re-enumeration could cause the wrong one to be destructively reflashed, since USB has no geographical addressing. In addition, behavior related to `--force` depended on the device EEPROM state, which is not appropriate to either factory flashing or the recovery flows. This commit solves these issues by separating (and simplifying) the production and the factory flashing flows. * The production flow only opens VID_QIHW:PID_GLASGOW devices (factory flashed) and loads only the production firmware. * The factory flashing flow opens VID_CYPRESS:PID_FX2 devices with no options, and VID_QIHW:PID_GLASGOW devices with `--reinitialize`. * The factory flashing flow loads the Cypress bootloader firmware, regardless of VID:PID. It ignores the EEPROM contents and flashes the configured revision and serial, as well as the built-in firmware, and asks the operator to power cycle the device. The notable differences are: * The factory flashing flow is incomparably more reliable. * The factory flashing flow is flashing a firmware in addition to the configuration block, halving the amount of programming steps. * The factory flashing flow no longer attempts to prevent you from flashing an already factory flashed device. This might seem bad at first glance, but: - It was added, IIRC, to handle potential re-enumeration bugs, which are no longer present. - It actively got in the way most of the time. - It's not *that* destructive--you just lose your serial, and even that only if you did not have it on a sticker or written down somewhere. (If you care about the serial it is probably because you have it in a script somewhere, so the problem of backing it up solves itself.) Fixes GlasgowEmbedded#252.
Before this commit, some aspects of factory flashing (device enumeration and initial loading of firmware) were handled in the production flow. However, this interacted poorly with the device recovery flow, since uploading a production firmware causes the device to re-enumerate. * Re-enumeration is not very reliable, especially on Windows. (#252) * If more than one device is connected, re-enumeration could cause the wrong one to be destructively reflashed, since USB has no geographical addressing. In addition, behavior related to `--force` depended on the device EEPROM state, which is not appropriate to either factory flashing or the recovery flows. This commit solves these issues by separating (and simplifying) the production and the factory flashing flows. * The production flow only opens VID_QIHW:PID_GLASGOW devices (factory flashed) and loads only the production firmware. * The factory flashing flow opens VID_CYPRESS:PID_FX2 devices with no options, and VID_QIHW:PID_GLASGOW devices with `--reinitialize`. * The factory flashing flow loads the Cypress bootloader firmware, regardless of VID:PID. It ignores the EEPROM contents and flashes the configured revision and serial, as well as the built-in firmware, and asks the operator to power cycle the device. The notable differences are: * The factory flashing flow is incomparably more reliable. * The factory flashing flow is flashing a firmware in addition to the configuration block, halving the amount of programming steps. * The factory flashing flow no longer attempts to prevent you from flashing an already factory flashed device. This might seem bad at first glance, but: - It was added, IIRC, to handle potential re-enumeration bugs, which are no longer present. - It actively got in the way most of the time. - It's not *that* destructive--you just lose your serial, and even that only if you did not have it on a sticker or written down somewhere. (If you care about the serial it is probably because you have it in a script somewhere, so the problem of backing it up solves itself.) Fixes #252.
Steps to reproduce
glasgow factory --force --rev C2
Result:
No new serial is flashed. The Glasgow still loads firmware and gateware after a manual reset.
I haven't investigated yet, but at least loading gateware takes longer than factory is waiting for. Could be the same for firmware, but the time difference isn't as obvious.
Maybe we need to upload a special firmware during factory that ignores everything in eeprom?
The text was updated successfully, but these errors were encountered: