On 02/22/2017 03:08 AM, Ard Biesheuvel wrote:
On 22 February 2017 at 09:01, zhufuwengang zhufuwengang@hisilicon.com wrote:
On 2017/2/22 16:42, Ard Biesheuvel wrote:
On 22 February 2017 at 08:40, zhufuwengang zhufuwengang@hisilicon.com wrote:
On 2017/2/22 15:46, Ard Biesheuvel wrote:
On 20 February 2017 at 11:21, zhufuwengang zhufuwengang@hisilicon.com wrote:
Hi ,all Lately I've been having a problem when I tried to boot kernel from EMMC.
GUID Partition Table is the basic essentials for UEFI and must be stored on the device before power on;It has two header structures:the primary and the backup.The primary GPT Header must be located in LBA 1 (i.e., the second logical block of EMMC), which is also the storage place of Bootloader, and the backup GPT Header must be located in the last LBA of the device. Therefore,there is a conflict between GPT and Bootloader in the storage. The boot architecture on Poplar board can be described as follows: BootRom-->Bootloader-->ATF-->UEFI-->Kernel. The Bootloader can be viewed as the BL1 stage of the ATF image;So it's a basic essential either. In some date manual we can get that the EMMC device is composed of five parts:BOOT Area Partition 1,BOOT Area Partition 2,RPMB,User Data Area and Vender private area.Hikey did not flash its fastboot into User Data Area where Poplar flased. I have asked our BootRom engineers but got a negative result:BootRom only can recognize the Bootloader in the start address of User Data Area on Poplar board where GPT must be placed to. Therefor, how to solve the conflicts between GPT and Bootloader is really a thorny problem.
I have asked several people for help,and got two methods as follows: #1.Use the backup GPT Header. In the GPT chapter of the UEFI Spec2.6 I read some useful information.Firstly,the backup GPT Partition Entry Array must be located after the Last Usable LBA and end before the backup GPT Header.Secondly,if the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. If it points to a valid GPT Partition Entry Array, then software should restore the primary GPT if allowed by platform policy settings.If the primary GPT is invalid, the backup GPT is used instead and it is located on the last logical block on the disk. On the base of the above,I only flashed the backup GPT to the thirty-three block from the end. But the UEFI can't recognize the backup GPT.So I don't know if the place where I store the backup GPT is wrong?
#2.Add an offset when read or write block . This method will reserve a 1M space for Bootloader at the start address of EMMC. And the primary GPT will be placed in a start address of 1M. We should add a 1M offset when we use the BlockIO functions to read or write block devices.This method maybe need to modify the EDKII core code;Honestly, I have not try this method.
How to solve the conflicts between GPT and Bootloader is really a thorny problem for me.Can you give me some advises about this problem?
Doesn't eMMC support separate boot regions? I think the boot ROM should use the boot region, and switch the eMMC to normal mode before handing over to UEFI. This way, it can put the partition table wherever it likes to.
No,it doesn't support separate boot regions in Poplar board. The boot ROM only can recognize the bootloader at the start address of user data region. Therefor, the first and most important thing is to solve the conflicts between GPT and Bootloader. Now,I am reading the GPT driver source code in EDKII core,and trying to find the reason why UEFI can't recognized the backup GPT Header which was located in the last LBA of the EMMC device. Don't we have other ways to make UEFI recognize the GPT in other place? Can you give me some advises about this problem?
The backup GPT header is for recovery only. We should not rely on it for normal operation.
But,maybe this is the only way to solve the GPT issue on Poplar board. Is there any methods to overcome this difficulty?
I don't think it is mandatory to use a GPT partition table. Did you try using MS-DOS format instead?
Unless I'm reading the spec wrong, I think you're right. It says that firmware adhering to the spec must support GPT partitioning (description of section 5 in table 1 in section 1.2). But later (section 12.3.2) it describes handling of media when there is *no* GPT header found. In that case, the contents of the MBR is consulted for partition information. http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf So it's OK for media to not use GPT, though UEFI firmware must be able to read GPT format media if it's used.
Section 5.2.3 defines a protective MBR, which is used if a legacy MBR is not used at offset 0. It could *maybe* be abused by using a non-standard value in the StartingLBA field (table 17 says it shall contain value 0x00000001). I don't want us to pretend to follow the spec but then not follow it exactly.
I have only just scanned through the GPT spec to collect this information. My feeling now is that we should plan to use a legacy (MS-DOS) MBR for the Poplar eMMC media.
-Alex