On Tue, Jun 27, 2017 at 05:56:35PM +0000, Ard Biesheuvel wrote:
On 27 June 2017 at 17:48, Leif Lindholm leif.lindholm@linaro.org wrote:
On Tue, Jun 27, 2017 at 05:24:30PM +0000, Ard Biesheuvel wrote:
On 27 June 2017 at 17:00, Leif Lindholm leif.lindholm@linaro.org wrote:
On Tue, Jun 27, 2017 at 04:39:47PM +0000, Ard Biesheuvel wrote:
On 27 June 2017 at 16:33, Leif Lindholm leif.lindholm@linaro.org wrote:
On Tue, Jun 27, 2017 at 01:21:45PM +0000, Ard Biesheuvel wrote: > This implements a UEFI Shell application that updates the EFI NOR
standalone UEFI Shell application
> partition with the contents of STYX_EFI.Fv. Note that this means that > a) EFI variables are preserved, and > b) this updater can only be used on systems that have already been flashed > with a firmware build based on this open source branch (and not on systems > still running AMI firmware)
Request for clarification based on your explanation below: Presumably b) is for one or both of these reasons:
- AMI firmware will not produce all protocols needed for this application to run (just like this firmware will not produce all protocols the AMI updater needs)?
- This application does not zero out the variable area?
The AMI firmware is also based on SeattleFDK, so it does produce the ISCP protocol that exposes the NOR read/write/erase methods. This is what makes it dangerous, given that the flasher will most likely run happily, but will not leave the NOR in a state where a varstore FV header appears in the expected place. This is what will make the firmware crash.
Note that none of these issues are particularly difficult to deal with, but it increases the complexity of this tools, which is not intended as a production quality firmware update distribution method but simply to allow me to distribute firmware updates to people like Lorenzo and Marc, and now some Cello users as well which shouldn't have been shipped boards to begin with.
All I'm really getting at with these questions around a very much welcome new tool is that I have a feeling it isn't necessarily end-user proof at this stage, so I think I would like to see either a few warnings in this commit message (which currently reads more like it's saying more along the lines of "it will only work if" than "you will become a customer of Dediprog if you try") or some attempt to determine whether we are on a platform where it is safe to attempt an upgrade.
Oh, this is absolutely unsuitable for general use. For instance, it does not distinguish between Cello, Overdrive and Overdrive1000, nor does it perform any kind of verification after the flash, all of which are not that difficult to implement, but simply not things that I can be bothered to care about at the moment, given the sorry state of Cello, and the fact that the only three users of this firmware for Overdrive are one floor down from where your desk is.
Yeah, I get it.
So for now, it is either merging this code, with perhaps some discouraging capitalized scary words added to the commit message, or just disregarding the patch for now, in the hope that someone else (Alan perhaps?) can be bothered to pick it up later and polish it up a bit. I honestly don't care either way.
I'm good with some capitalized scary words.
/ Leif