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: 1) 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)? 2) This application does not zero out the variable area?
In order for the flasher to have access to the various PCDs that describe where STYX_EFI.Fv lives in the NOR, it needs to be built as part of the platform, but after STYX_EFI.Fv has been generated, which results in a chicken-and-egg situation. Therefore, the recommended way of generating the flasher is
- delete the Build/<platform> directory entirely
- build the platform
- build the platform again, but with -D DO_FLASHER=TRUE appended
Build with -m .../StyxFlashUefi.inf instead of rebuilding the whole platform?
Yes, that should be sufficient. I will add that.
The flasher application is called 'StyxFlashUefi'
Only style comments below, but one silly question before that: Is there some particular reason why the application embeds the FV instead of reading it from a filesystem? Or just that you figured it's small enough that it doesn't matter?
Two reasons:
- simplicity; the actual code is *very* simply due to the fact that it
can refer to the payload directly, and I am not a seasoned shell application hacker that has a clue how one would go about implementing it using file I/O etc
- a generic flasher needs metadata that describes where the payload
needs to go, and the .Fv file does not contain that, so it would involve a file format or a command line option with all the associated failure modes.
Right, so basically because PcdFvBaseAddress and PcdFdBaseAddress could change? But would such a change not mean that variables would not be preserved after all?
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
Platforms/AMD/Styx/Applications/StyxFlashUefi/Scripts/GccBase.lds | 86 ++++++++++++++++++ Platforms/AMD/Styx/Applications/StyxFlashUefi/StyxFlashImage.S | 25 +++++ Platforms/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.c | 96 ++++++++++++++++++++ Platforms/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf | 53 +++++++++++ Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc | 12 ++- Platforms/AMD/Styx/Overdrive1000Board/Overdrive1000Board.dsc | 8 ++ Platforms/AMD/Styx/OverdriveBoard/OverdriveBoard.dsc | 8 ++ 7 files changed, 286 insertions(+), 2 deletions(-)