public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Haojian Zhuang <haojian.zhuang@outlook.com>
To: "lersek@redhat.com" <lersek@redhat.com>,
	Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"linaro-uefi@lists.linaro.org" <linaro-uefi@lists.linaro.org>
Subject: Re: [PATCH 1/2] Platform/Hisilicon/HiKey960: add boot options
Date: Thu, 22 Feb 2018 08:57:04 +0000	[thread overview]
Message-ID: <ca8e02f6-60f5-bc3b-6a72-5d53baf80619@outlook.com> (raw)
In-Reply-To: <51cc9548-3c02-09c6-30a4-5846b03a1374@redhat.com>

On 02/20/2018 11:54 PM, Laszlo Ersek wrote:
> Hi,
> 
> On 02/15/18 16:14, Haojian Zhuang wrote:
>> Add four boot options in emu variable region. They are
>> "Boot on SD", "Grub", "Android Boot" and "Android Fastboot".
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
>> ---
>>   Platform/Hisilicon/HiKey960/HiKey960.dsc |   3 +
>>   Platform/Hisilicon/HiKey960/HiKey960.fdf | 241 ++++++++++++++++++++++++++++++-
>>   2 files changed, 242 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/HiKey960/HiKey960.dsc b/Platform/Hisilicon/HiKey960/HiKey960.dsc
>> index 98289c0..a6864c1 100644
>> --- a/Platform/Hisilicon/HiKey960/HiKey960.dsc
>> +++ b/Platform/Hisilicon/HiKey960/HiKey960.dsc
>> @@ -78,6 +78,9 @@
>>     gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|FALSE
>>   
>>   [PcdsFixedAtBuild.common]
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0x1AD88048
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x7FB8
>> +
>>     gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
>>   
>>     gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Alpha"
>> diff --git a/Platform/Hisilicon/HiKey960/HiKey960.fdf b/Platform/Hisilicon/HiKey960/HiKey960.fdf
>> index 655032a..af10430 100644
>> --- a/Platform/Hisilicon/HiKey960/HiKey960.fdf
>> +++ b/Platform/Hisilicon/HiKey960/HiKey960.fdf
>> @@ -26,12 +26,12 @@
>>   
>>   [FD.BL33_AP_UEFI]
>>   BaseAddress   = 0x1AC98000|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base address of the Firmware in NOR Flash.
>> -Size          = 0x000F0000|gArmTokenSpaceGuid.PcdFdSize         # The size in bytes of the FLASH Device
>> +Size          = 0x00100000|gArmTokenSpaceGuid.PcdFdSize         # The size in bytes of the FLASH Device
>>   ErasePolarity = 1
>>   
>>   # This one is tricky, it must be: BlockSize * NumBlocks = Size
>>   BlockSize     = 0x00001000
>> -NumBlocks     = 0xF0
>> +NumBlocks     = 0x100
>>   
>>   ################################################################################
>>   #
>> @@ -53,6 +53,243 @@ NumBlocks     = 0xF0
>>   gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>>   FV = FVMAIN_COMPACT
>>   
>> +0x000F0000|0x00008000
>> +gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>> +DATA = {
>> +  ## This is the EFI_FIRMWARE_VOLUME_HEADER
>> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> +  # FileSystemGuid: gEfiSystemNvDataFvGuid         =
>> +  0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
>> +  0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
>> +  # FvLength: 0x8000
>> +  0x00, 0x80, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00,
>> +  #Signature "_FVH"       #Attributes
>> +  0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
>> +  #HeaderLength #CheckSum #ExtHeaderOffset #Reserved #Revision
>> +  0x48, 0x00, 0x36, 0x09, 0x00, 0x00, 0x00, 0x02,
>> +  #Blockmap[0]: 8 Blocks * 0x1000 Bytes / Block
>> +  0x08, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
>> +  #Blockmap[1]: End
>> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> +  ## end of EFI_FIRMWARE_VOLUME_HEADER.
>> +
>> +  ### Offset (0x48) ###
>> +  ## This is the VARIABLE_STORE_HEADER gEfiVariableGuid
>> +  0x16, 0x36, 0xcf, 0xdd, 0x75, 0x32, 0x64, 0x41,
>> +  0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d,
>> +  #Size: 0x8000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) - 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x7FB8
>> +  0xB8, 0x7F, 0x00, 0x00,
>> +  #FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
>> +  0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> +
>> +  ### Offset (0x64) ###
>> +  ## This is the VARIABLE_HEADER
>> +  #StartId: VARIABLE_DATA #State: VAR_ADDED #Reserved
>> +  0xAA, 0x55, 0x3F, 0x00,
>> +  #Attributes: EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS
>> +  0x03, 0x00, 0x00, 0x00,
>> +  #NameSize:
>> +  0x14, 0x00, 0x00, 0x00,
>> +  #DataSize:
>> +  0x18, 0x00, 0x00, 0x00,
>> +  #VariableGuid: gEfiGlobalVariableGuid
>> +  0x61, 0xDF, 0xE4, 0x8B, 0xCA, 0x93, 0xD2, 0x11,
>> +  0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B, 0x8C,
>> +  ## End of VARIABLE_HEADER. Offset (0x84)
>> +  #VariableName: BootOrder
>> +  0x42, 0x00, 0x6F, 0x00, 0x6F, 0x00, 0x74, 0x00,
>> +  0x4F, 0x00, 0x72, 0x00, 0x64, 0x00, 0x65, 0x00,
>> +  0x72, 0x00, 0x00, 0x00,
>> +  #Data
>> +  0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03, 0x00,
>> +  0x04, 0x00, 0x05, 0x00, 0x06, 0x00, 0x07, 0x00,
>> +  0x08, 0x00, 0x09, 0x00, 0x0a, 0x00, 0x0b, 0x00,
>> +  ### End of BootOrder.
>> +
>> +  ### Offset (0xB0) ###
>> +  ## This is the VARIABLE_HEADER
>> +  #StartId: VARIABLE_DATA #State: VAR_ADDED #Reserved
>> +  0xAA, 0x55, 0x3F, 0x00,
>> +  #Attributes: EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS
>> +  0x03, 0x00, 0x00, 0x00,
>> +  #NameSize:
>> +  0x12, 0x00, 0x00, 0x00,
>> +  #DataSize:
>> +  0x42, 0x00, 0x00, 0x00,
>> +  #VariableGuid: gEfiGlobalVariableGuid
>> +  0x61, 0xDF, 0xE4, 0x8B, 0xCA, 0x93, 0xD2, 0x11,
>> +  0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B, 0x8C,
>> +  #VariableName: Boot0000
>> +  0x42, 0x00, 0x6F, 0x00, 0x6F, 0x00, 0x74, 0x00,
>> +  0x30, 0x00, 0x30, 0x00, 0x30, 0x00, 0x30, 0x00,
>> +  0x00, 0x00,
>> +  ###  Offset (0xE2), Size(0x32) ###
>> +  #Data:
>> +  #Attributes: LOAD_OPTION_ACTIVE
>> +  0x01, 0x00, 0x00, 0x00,
>> +  #FilePathListLength
>> +  0x26, 0x00,
>> +  #Description: "Boot on SD"
>> +  0x42, 0x00, 0x6F, 0x00, 0x6F, 0x00, 0x74, 0x00,      #Boot
>> +  0x20, 0x00, 0x6F, 0x00, 0x6E, 0x00, 0x20, 0x00,      # on
>> +  0x53, 0x00, 0x44, 0x00, 0x00, 0x00,                  #SD
>> +  #FilePathList (0x26)
>> +  0x01, 0x04, 0x1D, 0x00, 0x5B, 0x90, 0x51, 0x0D,
>> +  0x7E, 0xB7, 0x2A, 0x45, 0xA2, 0xC0, 0xEC, 0xA0,
>> +  0xCC, 0x8D, 0x51, 0x4A, 0x00, 0xF0, 0x37, 0xFF,
>> +  0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x1A, 0x05,
>> +  0x00, 0x00, 0x7F, 0xFF, 0x04, 0x00,
>> +  ### Offset (0x124), Size (0x42) ###
>> +  ### End of Boot0000
>> +
>>
> 
> While in both ArmVirtPkg and OvmfPkg we use a similar DATA definition
> for *formatting* the pristine variable store (just setting the
> absolutely necessary headers via a hexdump), I think that adding
> "business content" like this is a bad idea. For one, if the defaults
> have to be updated ever again, the patches for the DATA definitions will
> look terrible. It's hard to review and maintain hexdump like these; we
> should keep such DATA definitions to the absolute minimum.
> 
> Such "default" boot options should be set by the platform's
> PlatformBootManagerLib instance. PlatformBootManagerLib is responsible
> for generating boot options. In doing that, PlatformBootManagerLib can
> call helper functions from UefiBootManagerLib, so everything need not be
> done manually.
> 
> For example, EfiBootManagerGetLoadOptions() can be used to retrieve the
> current boot options. Then, you can iterate over the four boot options
> that you want to ensure exist -- for each:
> 
> - create a EFI_BOOT_MANAGER_LOAD_OPTION object with
> EfiBootManagerInitializeLoadOption(),
> - check if the option already exists, with EfiBootManagerFindLoadOption(),
> - if the option doesn't exist yet, add it with
> EfiBootManagerAddLoadOptionVariable(),
> - free the EFI_BOOT_MANAGER_LOAD_OPTION object with
> EfiBootManagerFreeLoadOption()
> 
> Finally, free the originally retrieved set of boot options with
> EfiBootManagerFreeLoadOptions().
> 
> You can find example code in
> "ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c".
> 
> Thanks,
> Laszlo
> 

Hi Laszlo,

Yes, it's a bit hard to review and maintain. Actually, I implemented a 
PlatformBootManagerLib in this link 
(https://github.com/96boards-hikey/OpenPlatformPkg/blob/testing/hikey960_v1.3.4/Platforms/Hisilicon/Library/PlatformBootManagerLib/PlatformBm.c).

I format it with hard code since I want to re-use 
PlatformBootManagerLib in ArmPkg. Because these boot options only exist 
on HiKey/HiKey960 platforms, and most of them are same of the one in 
ArmPkg. If I append them into ArmPkg, it's not common enough. At last, I 
hope to implement a non-volatile region on flash devices in the future. 
It means that implementing a HiKey specific PlatformBootManagerLib is 
only a temporary solution.

It seems that I have two options to go ahead.
1. Move those hard code boot options into a FV file, and put the FV file
in edk2-non-osi repository.

2. Implement a HiKey related PlatformBootManagerLib.

Which one do you prefer?

Best Regards
Haojian


  reply	other threads:[~2018-02-22  8:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15 15:14 [PATCH 0/2] add boot options in HiKey Haojian Zhuang
2018-02-15 15:14 ` [PATCH 1/2] Platform/Hisilicon/HiKey960: add boot options Haojian Zhuang
2018-02-20 15:54   ` Laszlo Ersek
2018-02-22  8:57     ` Haojian Zhuang [this message]
2018-02-22 10:56       ` Laszlo Ersek
2018-02-22 11:32         ` Leif Lindholm
2018-02-22 11:49         ` Haojian Zhuang
2018-02-15 15:14 ` [PATCH 2/2] Platform/Hisilicon/HiKey: " Haojian Zhuang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca8e02f6-60f5-bc3b-6a72-5d53baf80619@outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox