fiano
fiano copied to clipboard
linuxboot
Workaround for an error: conflicting erase polarities, was 0x00, requested 0xFF
Hello!
I'm parsing firmwares to analyze corruptions. But there is a non-corrupted firmware (provided by our ODM), which is non-parsible by fiano, it returns an error:
conflicting erase polarities, was 0x00, requested 0xFF
Also I read multiple firmwares in a concurrent way (within concurrent routines), so switching the Attributes.ErasePolarity value is not a very good option. So I'm wondering: is it possible to workaround this problem?
I vaguely remember that there's supposed to be some header which tells you what the polarity is, I think it might be in the firmware volume header. We should read that and automatically apply it, however it raises the question of what happens if we see conflicting volumes. The erase polarity should really be stored in a global header of some sort instead of the fvheader I think.
OK, thanks for the response.
Since I do not modify firmwares: is it safe to just ignore this error (just patch the local copy of fiano to avoid this check)?
yes it should be safe. If it becomes a pain, we can work that into some kind of warning that doesn't terminate the parsing
yes it should be safe. If it becomes a pain, we can work that into some kind of warning that doesn't terminate the parsing
It has now become a bit of a pain, since we're wanting to try and get back to vanilla upstream rather than relying on our fork. Would it be possible to see about having a warning rather than a hard error?
@GanShun Following up on this again, should we just make a PR for what we have to bypass this, and continue work there? It'd be grand to be back on upstream and not have to deal with forks
Do not want to annoy, but I'm curious if I can help to move forward with this problem somehow :)
I've just created a PR out of the code I patched our internal fork/derivative with in 2021. Feel free to reject it, just sharing :)