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?
Best regards, Wengang
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.
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? Best regards, Wengang
.
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.
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?
.
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?
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
On 22 February 2017 at 18:59, Alex Elder elder@linaro.org wrote:
On 02/22/2017 03:08 AM, Ard Biesheuvel wrote:
[...]
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.
If we simply put an MBR in sector 0 that does not cover sector 1 at all (or any subsequent sectors that are part of the primary boot image), I don't think we need to bother at all with GPTs or protective MBRs or anything else that is specific to UEFI. Let's just start the first partition at the next eraseblock boundary, and make it around 128 MB in size, so we can use it as the EFI System Partition (ESP).
On 02/22/2017 01:06 PM, Ard Biesheuvel wrote:
If we simply put an MBR in sector 0 that does not cover sector 1 at all (or any subsequent sectors that are part of the primary boot image), I don't think we need to bother at all with GPTs or protective MBRs or anything else that is specific to UEFI. Let's just start the first partition at the next eraseblock boundary, and make it around 128 MB in size, so we can use it as the EFI System Partition (ESP).
Agreed. -Alex
On 02/22/2017 01:06 PM, Ard Biesheuvel wrote:
If we simply put an MBR in sector 0 that does not cover sector 1 at all (or any subsequent sectors that are part of the primary boot image), I don't think we need to bother at all with GPTs or protective MBRs or anything else that is specific to UEFI. Let's just start the first partition at the next eraseblock boundary, and make it around 128 MB in size, so we can use it as the EFI System Partition (ESP).
Is there any reason, other than the read-modify-write cost of writes smaller than the erase block size that you suggest the first partition lies at the next erase block boundary?
The MBR at offset 0 and the boot loader at offset 1 LBA will (most likely) have to be in the same erase block. I do realize that we don't want to be rewriting these blocks with writes to the front of the first partition.
I just want to be sure I'm not missing some other constraint. Thanks.
-Alex
On 22 February 2017 at 20:23, Alex Elder elder@linaro.org wrote:
On 02/22/2017 01:06 PM, Ard Biesheuvel wrote:
If we simply put an MBR in sector 0 that does not cover sector 1 at all (or any subsequent sectors that are part of the primary boot image), I don't think we need to bother at all with GPTs or protective MBRs or anything else that is specific to UEFI. Let's just start the first partition at the next eraseblock boundary, and make it around 128 MB in size, so we can use it as the EFI System Partition (ESP).
Is there any reason, other than the read-modify-write cost of writes smaller than the erase block size that you suggest the first partition lies at the next erase block boundary?
The idea is that file system blocks should not cover more than one erase block, because hitting such blocks will double the rate the flash blocks are worn out. Since the FS block size is an a priori unknown, the best way to achieve this is simply to align partitions on erase block boundaries. Note that MBR secondary partitions use the first sector for themselves, so those should start 1 sector /before/ an eraseblock boundary.
The MBR at offset 0 and the boot loader at offset 1 LBA will (most likely) have to be in the same erase block. I do realize that we don't want to be rewriting these blocks with writes to the front of the first partition.
Indeed. Usually, eMMC is optimized for FAT, so the region that is usually covered by the FAT tables is wear-leveled in a different way, and so hitting eraseblock 0 often should not result in any problems. But given risk of bricking the board when the boot image is corrupted, I think it makes sense to reserve it for the boot image and MBR partition table.
I just want to be sure I'm not missing some other constraint.
I don't think so, no
On 02/23/2017 05:06 AM, Ard Biesheuvel wrote:
Note that MBR secondary partitions use the first sector for themselves, so those should start 1 sector /before/ an eraseblock boundary.
So just to be completely clear... Because a secondary partition starts with an EBR sector, we'd want to place that just *prior* to the erase block boundary, so that the start of the real partition data is aligned.
I hadn't thought about that and I appreciate you pointing it out.
The rest of the stuff I was pretty aware of. And you confirmed there were no other special constraints.
Thanks.
-Alex
On 2017/2/23 3:06, Ard Biesheuvel wrote:
On 22 February 2017 at 18:59, Alex Elder elder@linaro.org wrote:
On 02/22/2017 03:08 AM, Ard Biesheuvel wrote:
[...]
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.
If we simply put an MBR in sector 0 that does not cover sector 1 at all (or any subsequent sectors that are part of the primary boot image), I don't think we need to bother at all with GPTs or protective MBRs or anything else that is specific to UEFI. Let's just start the first partition at the next eraseblock boundary, and make it around 128 MB in size, so we can use it as the EFI System Partition (ESP).
I read some specs about MBR and GPT today. And I have a doubt about the number of partitions that MBR can support. The MBR only can support four primary partitions which maybe not enough for AOSP platform. So I don't know if it is a problem in Aspen project?
On 02/22/2017 02:42 AM, Ard Biesheuvel wrote:
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.
I haven't really with eMMC, but I wondered what the purpose of the boot regions was. If it's this, we should use it.
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.
That's a good idea.
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.
I agree with this completely.
-Alex
On 2017/2/23 2:29, Alex Elder wrote:
On 02/22/2017 02:42 AM, Ard Biesheuvel wrote:
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.
I haven't really with eMMC, but I wondered what the purpose of the boot regions was. If it's this, we should use it.
We should have used the boot regions,but the boot Rom was fixed to read the fastboot at the start address of User data region in Poplar board for some reasons.
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.
That's a good idea.
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.
I agree with this completely.
I also agree with this,but to be honest, I have no idea with MS-DOS.
-Alex.
On 23 February 2017 at 05:29, Alex Elder elder@linaro.org wrote:
On 02/22/2017 02:42 AM, Ard Biesheuvel wrote:
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.
I haven't really with eMMC, but I wondered what the purpose of the boot regions was. If it's this, we should use it.
Did we get an answer on this?
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.
That's a good idea.
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.
I agree with this completely.
-Alex
On 02/27/2017 05:28 PM, Bin Chen wrote:
I haven't really with eMMC, but I wondered what the purpose of the boot regions was. If it's this, we should use it.Did we get an answer on this?
The answer was something like "yes, they probably should have been used." But the fact remains that the Hi3798cv200 boot ROM loads the image it expects to find at offset 0 of the user area of eMMC. So even if we could get access to the boot region, the ROM wouldn't be using it.
-Alex
On 02/20/2017 05:21 AM, zhufuwengang wrote:
Hi ,all Lately I've been having a problem when I tried to boot kernel from EMMC.
I'll respond in another e-mail shortly. This is just part one...
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
. . .
I have asked several people for help,and got two methods as follows:
. . .
#2.Add an offset when read or write block .
No, this is a bad idea. There is no standard way to communicate to Linux that the device needs to accessed using an offset like this. I don't know for sure but I suspect GPT tools on Linux would not work properly if we tried to do this.
-Alex
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?
Best regards, Wengang
On 02/20/2017 05:21 AM, zhufuwengang wrote:
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?
According to the spec, the backup GPT header resides on the last logical block of the media (not 33 from the end). The backup GPT partition array should go before that block; that would probably be 33 LBAs from the end of the medium.
But I will repeat that we shouldn't be relying on the backup GPT header and partition array this way (i.e., assuming the primary will be bad).
-Alex
-
Alex Elder -
Ard Biesheuvel -
Bin Chen -
zhufuwengang