From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9D17F2034D8C3 for ; Thu, 22 Feb 2018 02:50:26 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96E488425B; Thu, 22 Feb 2018 10:56:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-138.rdu2.redhat.com [10.10.120.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8EE3FAB599; Thu, 22 Feb 2018 10:56:23 +0000 (UTC) To: "haojian.zhuang@linaro.org" Cc: "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "ard.biesheuvel@linaro.org" , "linaro-uefi@lists.linaro.org" References: <1518707649-16912-1-git-send-email-haojian.zhuang@linaro.org> <1518707649-16912-2-git-send-email-haojian.zhuang@linaro.org> <51cc9548-3c02-09c6-30a4-5846b03a1374@redhat.com> From: Laszlo Ersek Message-ID: <61c94cc9-1b5c-95a7-fdd9-812609c68561@redhat.com> Date: Thu, 22 Feb 2018 11:56:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 22 Feb 2018 10:56:24 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 22 Feb 2018 10:56:24 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 1/2] Platform/Hisilicon/HiKey960: add boot options X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:50:27 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/22/18 09:57, Haojian Zhuang wrote: > 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 >>> --- >>> 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. Sorry, I don't understand how this follows. Again: why is it only a temporary solution to implement a PlatformBootManagerLib instance for HiKey? The library class says "Platform" in the name. Platforms are supposed to provide it, one way or another. If you want to minimize code duplication between ArmPkg and HiKey, it should be possible to factor out another library class from ArmPkg's PlatformBootManagerLib instance. It could be a function that returns the list of platform-specific boot options -- as an array of EFI_BOOT_MANAGER_LOAD_OPTION elements -- that should always exist. Then ArmPkg's PlatformBootManagerLib would perform the iteration that I described above. Platforms different from HiKey would return an empty array, while HiKey could return the four options it needs. Another benefit is that these four boot options would be restored on every boot, even if the user deleted them. This seems independent of whether the HiKey platform has functional non-volatile storage or not. > 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. I think option #2 is far superior. You don't have to duplicate all code from ArmPkg's PlatformBootManagerLib for that, you can extract another utility library class / callback function just for providing the options you always want. Or perhaps you *don't* want them always, just until NVRAM support arrives to HiKey? And, in that case, it will be alright for the user to delete these options permanently? ... I still think extracting a new lib class for these default boot options would be better. If at some point you'd like to drop the default boot options, it's easy to switch the new callback to returning zero elements. The lib class can remain useful to other development platforms. Thanks Laszlo