u-boot redundant environment support issue about fwup HOT 5 CLOSED

Oh wow, thanks for identifying this and sending the patch!

I hope to review today and assuming all goes well, I'll make an updated release this week.

from fwup.

No worries, regarding the patch, we are integrating 'fwup' using Yocto (Gatesgarth) and the patch compiles fine, however I just noticed today that integrating the patch with an older Petalinux-Xilinx it will fail when using the two 'static const' declarations because their use in a switch statement in 'C' is not allowed, albeit until C99 I guess, so I simply changed to a couple of horrible '#defines', but as I said before feel free to change to whatever you think works best ;-).

Kind regards
Eddy

from fwup.

@RossiSoftLtd Sorry for the delay - something came up in life, but I'm back! I looked at the issue and opted for a slightly different fix. Your patch worked, but caused a different unit test to fail. That one had to do with recovering after U-Boot environment corruption. It probably was nothing - like the unit test being too picky. However, once I saw what you fixed and had a good test to verify the issue, I took a crack at a minimal change.

If you're around and can take a quick look, let me know if you have any concerns. If I don't hear from you, I'll just push this out since I think that I've tested the case sufficiently and anyone using redundant U-Boot environments definitely needs it.

from fwup.

Hi,
hope you're well and your problems solved ;-)

Regarding your changes have you checked accessing the u-boot compatible area via standard user space utilities like fw_printenv/fw_setenv as well? I'm saying that because such utilities which we are using in combination with 'fwup' are particularly strict on the swap buffer edge cases and our patch was carefully catering for that in selecting the right buffer.

from fwup.

Thanks. That's a good suggestion.

The tests update the U-Boot environment 255 times to roll the counter. I just added a call to fw_printenv to verify each iteration to make sure that the expected buffer was read back by the U-Boot tools. It was.

If there's another case that you've tested that's not exercised, please let me know. Other unit tests exercise corruption recover which is, I think, the main thing that's not tested by unit test 200.

from fwup.