This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org --- MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr ); + + // RMH - hack - Linaro's development boards use SD cards, currently we have + // a problem where each unique SD card has a different UUID when created + // with linaro-media-create / linaro-android-media create. + // This means that no one Boot Device configuration can boot Linaro images + // without some manual intervention from the user. + // This hack will zero the signature (UUID) read from the card. + ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof (Mbr->UniqueMbrSignature)); + if (EFI_ERROR (Status)) { Found = Status; goto Done;
Ryan, I'm uncomfortable with this hack and its side effects -- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere? Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org --- MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr ); + + // RMH - hack - Linaro's development boards use SD cards, currently + we have // a problem where each unique SD card has a different UUID + when created // with linaro-media-create / linaro-android-media create. + // This means that no one Boot Device configuration can boot Linaro + images // without some manual intervention from the user. + // This hack will zero the signature (UUID) read from the card. + ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof + (Mbr->UniqueMbrSignature)); + if (EFI_ERROR (Status)) { Found = Status; goto Done; -- 1.7.9.5
_______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
Hello Eugene,
all patches being discussed in this thread would come from Linaro engineers from their @linaro.org email addresses. At Linaro we have signed the contributor agreement at Corporate level, see http://www.uefi.org/join/list
Let me know if this clarifies the legal side, while I let Ryan comment on your good and constructive feedback with your proposed flag.
Many thanks,
Andrea -- Andrea Gallo Director, Linaro Enterprise Group email: andrea.gallo@linaro.org IRC: agallo@#linaro on irc.linaro.org Skype: agallo70
On 19 February 2013 16:47, Cohen, Eugene eugene@hp.com wrote:
Ryan, I'm uncomfortable with this hack and its side effects -- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere? Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr );
- // RMH - hack - Linaro's development boards use SD cards, currently
- we have // a problem where each unique SD card has a different UUID
- when created // with linaro-media-create / linaro-android-media create.
- // This means that no one Boot Device configuration can boot Linaro
- images // without some manual intervention from the user.
- // This hack will zero the signature (UUID) read from the card.
- ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof
- (Mbr->UniqueMbrSignature));
- if (EFI_ERROR (Status)) { Found = Status; goto Done;
-- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
linaro-enterprise mailing list linaro-enterprise@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-enterprise
On 19 February 2013 16:47, Cohen, Eugene eugene@hp.com wrote:
Ryan, I'm uncomfortable with this hack and its side effects -- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere? Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr );
- // RMH - hack - Linaro's development boards use SD cards, currently
- we have // a problem where each unique SD card has a different UUID
- when created // with linaro-media-create / linaro-android-media create.
- // This means that no one Boot Device configuration can boot Linaro
- images // without some manual intervention from the user.
- // This hack will zero the signature (UUID) read from the card.
- ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof
- (Mbr->UniqueMbrSignature));
- if (EFI_ERROR (Status)) { Found = Status; goto Done;
-- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
linaro-enterprise mailing list linaro-enterprise@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-enterprise
-- Andrea Gallo Director, Linaro Enterprise Group email: andrea.gallo@linaro.org mobile: +39 338 4075993 IRC: agallo@#linaro on irc.linaro.org Skype: agallo70
On 19 February 2013 16:28, Andrea Gallo andrea.gallo@linaro.org wrote:
Hello Eugene,
all patches being discussed in this thread would come from Linaro engineers from their @linaro.org email addresses. At Linaro we have signed the contributor agreement at Corporate level, see http://www.uefi.org/join/list
Thanks Andrea for that clarification.
In addition, Eugene, I've also requested that all patches submitted to Linaro follow the Tianocore guidelines:
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/developers#Linaro_UEFI_P...
Let me know if this clarifies the legal side, while I let Ryan comment on your good and constructive feedback with your proposed flag.
Many thanks,
Andrea
Andrea Gallo Director, Linaro Enterprise Group email: andrea.gallo@linaro.org IRC: agallo@#linaro on irc.linaro.org Skype: agallo70
On 19 February 2013 16:47, Cohen, Eugene eugene@hp.com wrote:
Ryan, I'm uncomfortable with this hack and its side effects
The side effects could be bad on boards that had multiple devices of the same type, eg, multiple HDDs on one controller. But the boards that we support are currently only booting from either an SD card or from PXE in future to get into GRUB2.
So I don't see it causing much of a problem in the short term. I considered makeing a compile time flag. But you have mentioned making a better change and making it a plaform policy, which would be a neater solution.
-- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Whilst that's a good idea, it's not clear to me how to do that. Please feel free so submit a patch if you know how to do it.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere?
There is no documentation for this at all.
Currently, we aren't really hosting anything destined upstream except my "local FDT" patch, so it's not really a major issue.
Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr );
- // RMH - hack - Linaro's development boards use SD cards, currently
- we have // a problem where each unique SD card has a different UUID
- when created // with linaro-media-create / linaro-android-media create.
- // This means that no one Boot Device configuration can boot Linaro
- images // without some manual intervention from the user.
- // This hack will zero the signature (UUID) read from the card.
- ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof
- (Mbr->UniqueMbrSignature));
- if (EFI_ERROR (Status)) { Found = Status; goto Done;
-- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
linaro-enterprise mailing list linaro-enterprise@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-enterprise
On 19 February 2013 16:47, Cohen, Eugene eugene@hp.com wrote:
Ryan, I'm uncomfortable with this hack and its side effects -- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere? Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr );
- // RMH - hack - Linaro's development boards use SD cards, currently
- we have // a problem where each unique SD card has a different UUID
- when created // with linaro-media-create / linaro-android-media create.
- // This means that no one Boot Device configuration can boot Linaro
- images // without some manual intervention from the user.
- // This hack will zero the signature (UUID) read from the card.
- ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof
- (Mbr->UniqueMbrSignature));
- if (EFI_ERROR (Status)) { Found = Status; goto Done;
-- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
linaro-enterprise mailing list linaro-enterprise@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-enterprise
-- Andrea Gallo Director, Linaro Enterprise Group email: andrea.gallo@linaro.org mobile: +39 338 4075993 IRC: agallo@#linaro on irc.linaro.org Skype: agallo70
Thanks Andrea and Ryan for your responses.
Whilst that's a good idea, it's not clear to me how to do that. Please feel free so submit a patch if you know how to do it.
If you're already using EFI removable boot entry variables (EFI\BOOT\BOOTARM.EFI) as opposed to hardcoded device paths to the loader application, then the change may be as simple as making the signature check in BdsGetDeviceHd optional based on a PCD value. Look for the CompareGuid call in that function (it uses CompareGuid even though the MBR signature would be four bytes and the rest would be zeros per the UEFI spec (see Media Device Path).
Thanks,
Eugene
-----Original Message----- From: Ryan Harkin [mailto:ryan.harkin@linaro.org] Sent: Tuesday, February 19, 2013 9:41 AM To: Andrea Gallo Cc: Cohen, Eugene; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: Re: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
On 19 February 2013 16:28, Andrea Gallo andrea.gallo@linaro.org wrote:
Hello Eugene,
all patches being discussed in this thread would come from Linaro engineers from their @linaro.org email addresses. At Linaro we have signed the contributor agreement at Corporate level, see http://www.uefi.org/join/list
Thanks Andrea for that clarification.
In addition, Eugene, I've also requested that all patches submitted to Linaro follow the Tianocore guidelines:
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/developers#Linaro_UEFI_P...
Let me know if this clarifies the legal side, while I let Ryan comment on your good and constructive feedback with your proposed flag.
Many thanks,
Andrea
Andrea Gallo Director, Linaro Enterprise Group email: andrea.gallo@linaro.org IRC: agallo@#linaro on irc.linaro.org Skype: agallo70
On 19 February 2013 16:47, Cohen, Eugene eugene@hp.com wrote:
Ryan, I'm uncomfortable with this hack and its side effects
The side effects could be bad on boards that had multiple devices of the same type, eg, multiple HDDs on one controller. But the boards that we support are currently only booting from either an SD card or from PXE in future to get into GRUB2.
So I don't see it causing much of a problem in the short term. I considered makeing a compile time flag. But you have mentioned making a better change and making it a plaform policy, which would be a neater solution.
-- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Whilst that's a good idea, it's not clear to me how to do that. Please feel free so submit a patch if you know how to do it.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere?
There is no documentation for this at all.
Currently, we aren't really hosting anything destined upstream except my "local FDT" patch, so it's not really a major issue.
Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr );
- // RMH - hack - Linaro's development boards use SD cards,
- currently we have // a problem where each unique SD card has a
- different UUID when created // with linaro-media-create / linaro-android-media create.
- // This means that no one Boot Device configuration can boot
- Linaro images // without some manual intervention from the user.
- // This hack will zero the signature (UUID) read from the card.
- ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof
- (Mbr->UniqueMbrSignature));
- if (EFI_ERROR (Status)) { Found = Status; goto Done;
-- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
linaro-enterprise mailing list linaro-enterprise@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-enterprise
On 19 February 2013 16:47, Cohen, Eugene eugene@hp.com wrote:
Ryan, I'm uncomfortable with this hack and its side effects -- if you want to ensure that the boot process will boot any device path regardless of the MBR signature this can be handled as a modification to the device path matching logic in BDS. This could be a platform policy PCD boolean like 'BootIgnoreMbrSignature' or something.
Also you mentioned about changes going upstream -- are the details of the upstreaming process from uefi.next to edk2 svn documented somewhere? Are you ensuring that all upstreamed patches come from parties that have signed the Contributor's Agreement?
Thanks,
Eugene
-----Original Message----- From: boot-architecture-bounces@lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Ryan Harkin Sent: Tuesday, February 19, 2013 5:09 AM To: ryan.harkin@linaro.org; boot-architecture@lists.linaro.org; patches@linaro.org; linaro-enterprise@lists.linaro.org; olivier.martin@arm.com Subject: [PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero
This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals.
Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create.
This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user.
This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin ryan.harkin@linaro.org
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr );
- // RMH - hack - Linaro's development boards use SD cards,
- currently we have // a problem where each unique SD card has a
- different UUID when created // with linaro-media-create / linaro-android-media create.
- // This means that no one Boot Device configuration can boot
- Linaro images // without some manual intervention from the user.
- // This hack will zero the signature (UUID) read from the card.
- ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof
- (Mbr->UniqueMbrSignature));
- if (EFI_ERROR (Status)) { Found = Status; goto Done;
-- 1.7.9.5
boot-architecture mailing list boot-architecture@lists.linaro.org http://lists.linaro.org/mailman/listinfo/boot-architecture
linaro-enterprise mailing list linaro-enterprise@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-enterprise
-- Andrea Gallo Director, Linaro Enterprise Group email: andrea.gallo@linaro.org mobile: +39 338 4075993 IRC: agallo@#linaro on irc.linaro.org Skype: agallo70
boot-architecture@lists.linaro.org
-
Andrea Gallo -
Cohen, Eugene -
Ryan Harkin