boot-architecture

boot-architecture@lists.linaro.org

2 participants
647 discussions

[PATCH 1/2] Samsung/Arndale: Booting UEFI and linux from eMMC

by Rony Nandy

1. OM register comparison value changed as per the board switch configuration. 2. Removed eMMC boot partition enable code, to access user area. Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> Signed-off-by: Rony Nandy <rony.nandy(a)linaro.org> --- SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c | 1 - SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h | 2 +- SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c index d166f66..87f9379 100755 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c @@ -840,7 +840,6 @@ DetectCard ( gSDMMCMedia.MediaId++; UpdateMSHCClkFrequency(MSHC_CLK_50M); - MSHC_EMMC_Boot_Open(); //do not close boot partition DEBUG ((EFI_D_INFO, "SD Card Media Change on Handle 0x%08x\n", gImageHandle)); return Status; diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h index 9bbf13a..e410d66 100755 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h @@ -65,7 +65,7 @@ NV data for general purpose : 3400 #define BLEN_512BYTES (0x200) #define BLKSIZE_1 (0x1) -#define OM_EMMC 0x28 +#define OM_EMMC 0x8 #define MAX_RETRY_COUNT (100000) #define MMC_REFERENCE_CLK (96000000) diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S index a10eae1..08a893c 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S @@ -198,7 +198,7 @@ _CopyFirmware: ldr r1, [r0,#0x0] bic r2, r1, #0xffffffc1 - cmp r2, #0x28 + cmp r2, #0x8 beq _CopyFirmwareEMMC /* SD/MMC BOOT */ -- 1.8.1.1

12 years, 6 months

Re: [PATCH] Samsung/Arndale: fix RELEASE build with ARMLINUXGCC

by Reece R. Pollack

On 02/13/2013 10:44 AM, Olivier Martin wrote: > Instead of using: > #if !defined(MDEPKG_NDEBUG) > (...) > #endif > > It would be better to use: > DEBUG_CODE_BEGIN(); > (...) > DEBUG_CODE_END(); > > The reason is you can be in debug build and disable debug code (and/or > disable other things such as ASSERT). See definition of PcdDebugPropertyMask > for the full list of debug properties. These macros insert code which would place the variable definition inside an "if" statement. This usage violates the Coding Standard on page 30: "The data declarations must be the first code in a module." "Data declarations appearing anywhere but at the beginning of the module are illegal." > The EDK2 coding convention > (http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II > %20C%20Coding%20Standards%20Specification.pdf/download) says we should not > write this kind of variable declaration: > EFI_STATUS Status = EFI_INVALID_PARAMETER; > > See page 30: "Initializing a variable as part of its declaration is > illegal." This restriction is violated in almost every case in the files I patched. I merely coded my changes to blend in with the surrounding code, as any good maintenance programmer would do. The coding standard's requirement is, in this case, contrary to commonly accepted coding practice in the industry for the last decade. It really should be removed from the DRAFT standard. The mandatory space between the function name and the opening paren of its argument list needs to go away too: the vast majority of the programmers I've spoken with read that as missing a binary operator between a variable and a parenthized expression. They have to re-read the code several times before it becomes apparent that this is a function call and not a coding error. The existence of documented exceptions (macro definitions, etc.) support the argument that it's a bad practice. Feel free to change the patch as you see fit. I never expected to publish these changes; they were intended only to help me figure out why I couldn't build a standard target in my development environment. Ryan asked for copies so I provided them. -Reece

12 years, 6 months

[PATCH] Samsung/Arndale: fix RELEASE build with ARMLINUXGCC

by Ryan Harkin

The attached patch from Reece has already been applied to uefi-next as part of 13.02-rc5. But it's still open for review...

12 years, 6 months

[PATCH] panda: build.sh: change RELEASE/DEBUG param handling

by Ryan Harkin

The attached patch changes the PandaBoardPkg/build.sh script RELEASE or DEBUG parameter handling. Before this patch, build.sh can be called thus: ./build.sh ./build.sh -b DEBUG ./build.sh RELEASE This patch simplifies the way you pass the debug/release parameter into build.sh so that build scripts can simply pass DEBUG or RELEASE, without having to create a special case to add the "-b". Eg. ./build.sh ./build.sh DEBUG ./build.sh RELEASE

12 years, 6 months

UEFI: linaro-tracking-2013.02 is now open for patches

by Ryan Harkin

I've just created the linaro-tracking-2013.02 branch [1] and created the release candidate. You can find a snapshot build of 2013.02-rc2 on snapshots.linaro.org [2]. The branch is now open for submissions. The next freeze date is 21st February 2013. [1] http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=shortlog;h=refs/hea… [2] https://snapshots.linaro.org/components/kernel/uefi-next/115

12 years, 6 months

Linaro UEFI 2013.01 released

by Ryan Harkin

Hello all, This month's Linaro UEFI release is special: it's the first release from the new tree, using the new process. The whole thing is documented here; including submission guidelines, release dates, tree locations, build instructions, ...: https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/ The tree can be found here: http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary The main points about the new tree: - The "master" branch is "long lived", it never gets rebased. - it contains the latest edk2 code from Tianocore - this is taken directly from the Tianocore GIT, so the SHAs match - it contains the latest FatDriver2 from Tianocore - Tianocore does not run a GIT repo for this project - this is taken from the Linaro GIT mirror of the Tianocore SVN - it contains the latest BaseTools from Tianocore - ie. not the version in the edk2 repo but the latest devel code - this is taken directly from the Tianocore GIT, so the SHAs match - branches exist for each sub-tree: - "tianocore-edk2" - "tianocore-edk2-fatdriver2" - "tianocore-edk2-basetools" - The "linaro-tracking" branch is "long lived", it never gets rebased. - it contains the all latest development work from Linaro - currently linaro-uefi-2013.01 - The "linaro-release" branch is "long lived", it never gets rebased. - it contains the latest release from Linaro - currently linaro-uefi-2013.01 - Monthly tracking branches are created - At the start of each month, I will update the master branch from the Tianocore upstreams - It gets tagged as "linaro-base-YYYY.MM" - I will then take a branch from this: the monthly tracking branch - The monthly tracking branch is "long lived", it never gets rebased. - "linaro-tracking-2013.01" is the most recent branch - it is now frozen and the release has been cut - I am about to create the "linaro-tracking-2013.02" branch - Topic branches are rebased each month - All branches for specific topics, e.g., Arndale BSP, get rebased to the monthly tracking branch - Any upstreamed patches are dropped - The patch set is tidied up; any "fix" patches are squashed, etc. - The branch is then merged to the monthly tracking branch - Release Candidates - Once all the topic branches are merged to the monthly tracking branch, tracking gets tagged as a release candidate - "linaro-tracking" is updated to each RC - Patches are accepted via the Boot Architecture mailing list - During the cycle, patches are merged into the relevant topics - When a complete series of patches is merged, a new RC is created. - This is currently ad-hoc and not on a time-table - Each time the tree is updated, a snapshot build is triggered in Linaro's Continuous Integration system, Jenkins. - Builds can be found on snapshots.linaro.org [1] - Release - At the end of the cycle, the monthly tracking branch is frozen - Dated follow linux-linaro - Freeze is the 2nd last Thursday of the month, eg. 21st Feb 2013 - Only urgent fixes can be accepted - Release Candidate builds are made on the following Monday, eg. 25th Feb 2013 - The release happens the last Thursday of the month, eg, 28th Feb 2013 - Release binaries are copied to releases.linaro.org [2] - The released code is copied to the uefi.git tree [3] - some users may find a problem using a tree where some branches are rebased - uefi.git has only 1 branch and is never rebased - the SHA ids do not match uefi-next.git I see this process as "in progress" and open to suggestions and change. Regards, Ryan. [1] https://snapshots.linaro.org/components/kernel/uefi-next [2] http://releases.linaro.org/13.01/components/kernel/uefi-linaro [3] http://git.linaro.org/gitweb?p=arm/uefi/uefi.git;a=summary

12 years, 6 months

Hello, Question about SctPkg.

by Steven Kinney

I am porting the UEFI ARM SctPkg into the core UEFI and I am running into a problem; Linux Host. The BuildSct.sh is trying to copy a utility called GenBin_lin{64, 32}, in my case GenBin_lin_64, that should be populated within ~/SctPkg/Tools/Bin/. My compilation executes fine, but I am unable to generate a binary because of the lacking GenBin for Linux; there is a GenBin.exe populated for a Windows Host. Anyone have any advise. Much appreciated, Steve

12 years, 6 months

RETURNED MAIL: DATA FORMAT ERROR

by drakelist＠zerobeat.net

The original message was received at Mon, 28 Jan 2013 19:13:53 +0530 from 140.49.106.138 ----- The following addresses had permanent fatal errors ----- boot-architecture(a)lists.linaro.org

12 years, 6 months

Returned mail: see transcript for details

by umagesh＠apache.org

Your message could not be delivered

12 years, 7 months

Message could not be delivered

by christian.graf＠hk24.de

The original message was received at Wed, 23 Jan 2013 10:41:34 +0700 from 177.7.60.200 ----- The following addresses had permanent fatal errors ----- <boot-architecture(a)lists.linaro.org>

12 years, 7 months

← Newer
1
...
53
54
55
56
57
58
59
...
65
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture