Linaro-uefi

linaro-uefi@lists.linaro.org

811 discussions

Re: [Linaro-uefi] uefi code has included fastboot implementation?

by TigerLiu＠via-alliance.com

Hi, Oliver: Thanks a lot! >ARM Ltd has been working on a UEFI implementation of Android FastBoot. We are >planning to publish this implementation in the next 10 days. It's a good news! Best wishes,

10 years, 10 months

uefi code has included fastboot implementation?

by TigerLiu＠via-alliance.com

Hi, ryan: Does the current uefi code released by linaro include android fastboot implementation? In this websiste : https://wiki.linaro.org/ARM/UEFI/FastBoot It seemed an engineer has implemented it on a PandaBoard. Best wishes,

10 years, 10 months

Removing colour codes

by Ryan Harkin

Hi Fu Wei, Here's the patch for the FVP Base model to remove colour codes. It's very simple. By default, the behaviour isn't changed. But if you build the code with "-D EDK2_SIMPLE_CONSOLE", it will remove the colour code. This patch was based on an old version of our tree, but it should apply. If not, you can see the changed needed and they are very small. Cheers, Ryan.

10 years, 10 months

Re: [Linaro-uefi] draft of blog post - UEFI and ACPI

by Grant Likely

My blog post on ACPI and UEFI has now gone public. Here's the link: http://www.secretlab.ca/archives/27 Jennifer, you can go ahead and publish on the Linaro blog also. g.

10 years, 10 months

UEFI memory type and get_dram_base()

by Roy Franz

Leif and Mark, >From my reading of Table 25 in the UEFI 2.4 spec, I think that the following types should be considered when looking for the base of dram: * EfiLoaderCode: The code portions of a loaded application. (Note that UEFI OS loadersare UEFI applications.) * EfiLoaderData: The data portions of a loaded application and the default data allocation type used by an application to allocate pool memory. * EfiBootServicesCode: The code portions of a loaded Boot Services Driver. * EfiBootServicesData: The data portions of a loaded Boot Serves Driver, and the default data allocation type used by a Boot Services Driver to allocate pool memory. * EfiRuntimeServicesCode: The code portions of a loaded Runtime Services Driver. * EfiRuntimeServicesData: The data portions of a loaded Runtime Services Driver and the default data allocation type used by a Runtime Services Driver to allocate pool memory. * EfiConventionalMemory: Free (unallocated) memory. * EfiACPIReclaimMemory: Memory that holds the ACPI tables. * EfiACPIMemoryNVS: Address space reserved for use by the firmware. and the following should be ignored: * EfiReservedMemoryType: Not used. * EfiUnusableMemory: Memory in which errors have been detected. * EfiMemoryMappedIO: Used by system firmware to request that a memory-mapped IO region be mapped by the OS to a virtual address so it can be accessed by EFI runtime services. * EfiMemoryMappedIOPortSpace: System memory-mapped IO region that is used to translate memory cycles to IO cycles by the processor. * EfiPalCode: Address space reserved by the firmware for code that is part of the processor. Does this seem reasonable? Roy

10 years, 10 months

Fwd: [edk2] edk2/edksetup.sh patch to solve command line parameter

by Leif Lindholm

FYI: this patch, which was committed yesterday, breaks some build instructions (and possibly the uefi-build.sh command). Effectively, they are deprecating the passing of a specific BaseTools directory to edksetup.sh. So it could/should henceforth simply be called as ". edksetup.sh", whereas we've tended to use ". edksetup.sh `pwd`/BaseTools". ---------- Forwarded message ---------- From: Gao, Liming <liming.gao(a)intel.com> Date: 27 January 2014 07:46 Subject: Re: [edk2] edk2/edksetup.sh patch to solve command line parameter To: "Parmeshwr_Prasad(a)Dell.com" <Parmeshwr_Prasad(a)dell.com> Cc: "edk2-commits(a)lists.sourceforge.net" <edk2-commits(a)lists.sourceforge.net>, "edk2-devel(a)lists.sourceforge.net" <edk2-devel(a)lists.sourceforge.net> Parmeshwr: Your patch is good. I will help commit it. Signed-off-by: Gao, Liming <liming.gao(a)intel.com> Thanks Liming *From:* Parmeshwr_Prasad(a)Dell.com [mailto:Parmeshwr_Prasad@Dell.com] *Sent:* Monday, January 27, 2014 3:00 PM *To:* Gao, Liming *Cc:* edk2-commits(a)lists.sourceforge.net *Subject:* RE: edk2/edksetup.sh patch to solve command line parameter Hi Liming, Please find new patch for edksetupp.sh. I have changes according to your comments. It can handle following cases. 1- Handle more than one parameter 2- Handle if first parameter is not "-?, -h, --help or BaseTool". 3- Any other thing to display error message. Please let me know with your comment. Regards Parmeshwr Prasad *From:* Gao, Liming [mailto:liming.gao@intel.com <liming.gao(a)intel.com>] *Sent:* Friday, January 24, 2014 8:01 PM *To:* Prasad, Parmeshwr *Subject:* RE: edk2/edksetup.sh patch to solve command line parameter Yes. If user follows it, it should work. So, I expect the behavior is: 1. No parameter, edksetup.sh will set up environment. 2. BaseTools parameter, edksetup.sh will set up environment. 3. Other parameter, edksetup.sh will print help message. Thanks Liming *From:* Parmeshwr_Prasad(a)Dell.com [mailto:Parmeshwr_Prasad@Dell.com<Parmeshwr_Prasad(a)Dell.com>] *Sent:* Friday, January 24, 2014 7:10 PM *To:* Gao, Liming *Subject:* RE: edk2/edksetup.sh patch to solve command line parameter Hi Liming I got your point. I saw user manual do we give any other parameter except " *BaseTools"* In parameter to edksetup.sh ? If I am not wrong than this is the point you are talking about. *ln -s /home/usr/BaseTools /home/usr/Edk2Workspace/Conf/BaseToolsSource* 4. Run "*. edksetup.sh BaseTools*" under the workspace's directory to set system environment, such as WORKSPACE, EDK_TOOLS_PATH etc. Regards Parmeshwr *From:* Prasad, Parmeshwr *Sent:* Friday, January 24, 2014 4:26 PM *To:* edk2-devel(a)lists.sourceforge.net; liming.gao(a)intel.com *Subject:* Re: [edk2] edk2/edksetup.sh patch to solve command line parameter Hi Liming, See below two example- 1- param@param-opensource:~/Development/edk2$ source edksetup.sh -h- Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh WORKSPACE: /home/param/Development/edk2 EDK_TOOLS_PATH: /home/param/Development/edk2/BaseTools *In above example edksetup.sh is not able to handle "-h-" parameter it mean it can handle only "-?, -h,--help".* *If we give any other parameter except above mentioned. It cannot handle. It mean error handling is required.* *Even the help message is not looking good.* 2- param@param-opensource:~/Development/edk2$ source edksetup.sh -h BaseTools Usage: '. edksetup.sh' Please note: This script must be 'sourced' so the environment can be changed. (Either '. edksetup.sh' or 'source edksetup.sh') This is expected behavior. If this patch is not looking good, suggest me how it can be made better. Regards Parmeshwr *From:* Gao, Liming [mailto:liming.gao@intel.com <liming.gao(a)intel.com>] *Sent:* Friday, January 24, 2014 3:06 PM *To:* Prasad, Parmeshwr *Cc:* edk2-devel(a)lists.sourceforge.net *Subject:* Re: [edk2] edk2/edksetup.sh patch to solve command line parameter Hi, I have two comments. 1. BaseTools parameter is required to be supported for compatibility, because this usage is mentioned in EDKII_UserManual.pdf document. Some users have used it. In fact, ". edksetup.sh BaseTools" is same to ". edksetup.sh". 2. In below script, BaseTools/BuildEnv $* can be cleanup to remove $*, because no parameter is required. if [ -z "$WORKSPACE" ] then . BaseTools/BuildEnv $* else . $WORKSPACE/BaseTools/BuildEnv $* fi Thanks Liming *From:* Parmeshwr_Prasad(a)Dell.com [mailto:Parmeshwr_Prasad@Dell.com<Parmeshwr_Prasad(a)Dell.com>] *Sent:* Thursday, January 23, 2014 4:02 PM *To:* edk2-commits(a)lists.sourceforge.net *Subject:* edk2/edksetup.sh patch to solve command line parameter Hi All, I see there is a problem in "edksetup.sh" file. It accept one parameter "-?, -h, --help" for printing help message. If we give any other parameter to this it goes and set old environment with help message. Expected behavior should be either to print The help message or set environment. It is not able to handle any garbage parameter. I am sending patch for this problem, please review and commit to main stream. Even help message was not clear I changes that also. *Incorrect behavior :* :~/Development/edk2$ source edksetup.sh ---jjdcncn Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh WORKSPACE: /home/param/Development/edk2 EDK_TOOLS_PATH: /home/param/Development/edk2/BaseTools Correct behavior: :~/Development/edk2$ source edksetup.sh -h BaseTools Usage: '. edksetup.sh' Please note: This script must be 'sourced' so the environment can be changed. (Either '. edksetup.sh' or 'source edksetup.sh') Correct behavior: :~/Development/edk2$ source edksetup.sh Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh WORKSPACE: /home/param/Development/edk2 EDK_TOOLS_PATH: /home/param/Development/edk2/BaseTools *Best Regards,* *Parmeshwr Prasad* Tel : +91-9743262018 [image: cid:image002.png@01CE781A.38F61FE0] ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel

10 years, 10 months

Fix vexpress A5 and TC1 BSPs for 14.01 rc1

by Ryan Harkin

Since 14.01 rc1, the Versatile Express A5 and TC1 BSPs no longer build. This is due to PcdSystemMemoryBase changing from a 32 to 64 bit PCD. [PATCH 1/2] TC1: change PcdGet32 to PcdGet64 [PATCH 2/2] VEA5: change PcdGet32 to PcdGet64

10 years, 11 months

Re: [Linaro-uefi] [PATCH V2] Add QEMU support to ARM VExpress builds

by Roy Franz

On Wed, Jan 15, 2014 at 8:28 AM, Olivier Martin <olivier.martin(a)arm.com> wrote: > I believed your suggestion was to update both patches (NorFlash & Ethernet > changes) with the SUPPORT_QEMU flag. I was not expected you will squash both > patch together. > Anyway, I pushed your patch without the Ethernet changes. I cannot accept > the ethernet change at this time as the support is not yet into SVN... > > As I told you in another email, I am waiting for the USWG to take an action > on the Ethernet initialization clarification to push support into Tianocore. > Once, we will have Ethernet support in SVN, I will add the Ethernet part of > your patch. Sorry about that - I misunderstood the state of the network support in Arm. Thanks for taking the flash stuff - we will carry the networking changes in the Linaro tree until all of the networking stuff can be merged. Thanks, Roy > > >> -----Original Message----- >> From: Roy Franz [mailto:roy.franz@linaro.org] >> Sent: 15 January 2014 04:38 >> To: edk2-devel(a)lists.sourceforge.net; linaro-uefi(a)lists.linaro.org; >> Olivier Martin >> Cc: patches(a)linaro.org; ryan.harkin(a)linaro.org; Roy Franz >> Subject: [PATCH V2] Add QEMU support to ARM VExpress builds >> >> This patchset is a combination of my two previous patchsets adding >> QEMU support. Both the networking driver change and the flash >> address for variable storage are now controlled by the >> EDK2_ARMVE_SUPPORT_QEMU build macro. If the macro is not set >> the normal RTSM configuration is built. >> >> With this patchset persistent storage and networking work on the >> A15 VExpress QEMU platform. >> >> >> Changes since v1: >> * Combined both changes into one patch >> * changed flash address selection to be controlled by build macro >> * changed build macro name to be more generic >> >> Roy Franz (1): >> Add build option to support VExpress A15 QEMU emulation >> >> .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 22 >> +++++++++++++++++--- >> .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf | 8 ++++++- >> .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 10 +++++++++ >> 3 files changed, 36 insertions(+), 4 deletions(-) >> >> -- >> 1.7.10.4 >> > > > >

10 years, 11 months

[PATCH V2] Add QEMU support to ARM VExpress builds

by Roy Franz

This patchset is a combination of my two previous patchsets adding QEMU support. Both the networking driver change and the flash address for variable storage are now controlled by the EDK2_ARMVE_SUPPORT_QEMU build macro. If the macro is not set the normal RTSM configuration is built. With this patchset persistent storage and networking work on the A15 VExpress QEMU platform. Changes since v1: * Combined both changes into one patch * changed flash address selection to be controlled by build macro * changed build macro name to be more generic Roy Franz (1): Add build option to support VExpress A15 QEMU emulation .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 22 +++++++++++++++++--- .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf | 8 ++++++- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 10 +++++++++ 3 files changed, 36 insertions(+), 4 deletions(-) -- 1.7.10.4

10 years, 11 months

Re: [Linaro-uefi] [PATCH 0/3]

by Ryan Harkin

On 15 January 2014 16:03, Olivier Martin <olivier.martin(a)arm.com> wrote: > Hi Ryan, > > I forgot to mention you but I pushed your patches in SVN earlier today. > Ah-ha! Thanks Olivier, yes, I see them in the commit log now :-) > > Thanks, > Olivier > > > -----Original Message----- > > From: Ryan Harkin [mailto:ryan.harkin@linaro.org] > > Sent: 14 January 2014 16:06 > > To: ryan.harkin(a)linaro.org; steven.kinney(a)linaro.org; linaro- > > uefi(a)lists.linaro.org; leif.lindholm(a)linaro.org; edk2- > > devel(a)lists.sourceforge.net; Olivier Martin > > Subject: [PATCH 0/3] > > > > Hi Steven, > > > > In the following emails are the three patches that I'd like applied to > > the Linaro EDK2 tree for the 14.01 release: > > > > [PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add virtio to RTSM A15 > > [PATCH 2/3] ArmPlatformPkg/ArmVExpressPkg: add virtio to RTSM A15 > > [PATCH 3/3] ArmPlatformPkg/ArmVExpressPkg: add virtio to RTSM A9 BSP > > > > They all add virtio mmio support to the A9/A15 BSPs. > > > > Olivier, > > > > Please also consider these for inclusion in the Tianocore tree. > > > > Regards, > > Ryan. > > > > >

10 years, 11 months

← Newer
1
...
75
76
77
78
79
80
81
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi