Various typo in ArmVirtPkg.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Coeur
---
ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c| 2 +-
Various typo in ArmPkg.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Coeur
---
.../Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c | 2 +-
ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c | 2 +-
ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 2 +-
Various typo in ArmPlatformPkg.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Coeur
---
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 4 ++--
ArmPlatformPkg/Include/Library/ArmPlatformLib.h| 2 +-
ArmPlatformPkg/Include/Library/PL011UartLib.h | 2 +-
Various typo in AppPkg, ignoring Python folder.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Coeur
---
AppPkg/Applications/Enquire/Enquire.c | 2 +-
AppPkg/Applications/Sockets/DataSource/DataSource.c | 4 ++--
I'm trying to fetch a file over HTTP in a boot loader, but gBS-
>LocateHandleBuffer doesn't find either of the EFI_TCP4_SERVICE_BINDING_PROTCOL
or EFI_HTTP_SERVICE_BINDING_PROTOCOL.
I'm running a build of OVMF from git master from a few weeks ago.
Should they exist and be usable, or does OVMF
Replace the dummy C implementation of SpeculationBarrier() with
implementations consisting of the recommended DSB SY + ISB sequence,
as recommended by ARM in the whitepaper "Cache Speculation Side-channels"
version 2.4, dated October 2018.
Contributed-under: TianoCore Contribution Agreement 1.1
Laszlo,
not sure which Andrew you wanted, but he didn’t get added so far as I can tell.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, February 05, 2019 4:05 AM
> To: Leif Lindholm
> Cc:
Hi Brad:
One other possible path you might be able to consider. Have you looked at
Component Firmware Update as a way to manage in-device firmware?? While that
originates with Microsoft, it's open source and OS neutral and might be an
easier overall.
Thank you Mike! This is kind of what I thought, but wasn't sure if I was
missing something. I will let you know if I come across any standard.
-Brad
On Tue, Feb 5, 2019 at 2:58 PM Kinney, Michael D
wrote:
> Hi Brad,
>
> In order to update a FW storage device in UEFI, a UEFI driver
> that
Hi Brad,
In order to update a FW storage device in UEFI, a UEFI driver
that produces the Firmware Management Protocol is required.
There are some protocols to access I2C devices, so the
implementation of the Firmware Management Protocol for
an I2C device can use the I2C protocols to perform the
Hi Pete,
On 2/4/19 1:47 PM, Pete Batard wrote:
> This is designed to be used on platforms where a a real RTC is not
> available and relies on an RtcEpochSeconds variable having been set or,
> if that is not the case, falls back to using the epoch embedded at
> compilation time.
>
> Note that, in
I would really appreciate a small pointer on this - yes/no on if is a
standard peripheral fw delivery buit-in, and maybe a pointer to a doc or
source code directory to take a look at?
Thank you,
Brad
On Tue, Jan 29, 2019 at 4:54 PM Brad Bozarth wrote:
> Hi!
>
> I am implementing firmware for a
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Kubacki, Michael A
> Sent: Monday, February 4, 2019 5:57 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ;
> Desimone, Nathaniel L ;
> Sinha, Ankit ; Chiu, Chasel
> ; Oram, Isaac W
> ; Gao, Liming
>
> Subject:
Reviewed-by: Nate DeSimone
On 2/4/19, 5:57 PM, "Kubacki, Michael A" wrote:
Adds details on the EDK II Minimum Platform design for Intel
platforms.
* Overview of Minimum Platform
* Board package purpose and conventions
* Stage boot concept and control
* Minimum
Documentation is split between general plaform data and OS testing
and installation details.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/Readme.md | 167
Platform/RaspberryPi/RPi3/Systems.md | 65
Laszlo,
Thanks a lot for the prompt fix. Works now.
Tested-by: Vladimir Olovyannikov
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, February 5, 2019 3:22 AM
To: edk2-devel@lists.01.org
Cc: Bob Feng; Liming Gao; Vladimir Olovyannikov; Yonghong Zhu
Adds the .dec/.dsc/.fdf needed to build the platform firmware.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/RPi3.dec | 58 ++
Platform/RaspberryPi/RPi3/RPi3.dsc | 629
Platform/RaspberryPi/RPi3/RPi3.fdf |
>From https://github.com/raspberrypi/firmware/tree/master/boot
The .dtb's were decompiled to .dts, and then edited to fix USB
keyboard support as well as CPU enabling through PSCI.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
These ATF binaries were built from the ATF source (commit c3859557)
with the custom RPi3 platform options detailed in the readme, and with
no modification to the official source whatsoever.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
The Raspberry Pi 3 uses a dedicated Synopsys DesignWare USB Host driver
to interface with various USB peripherals, including the onboard NIC.
This driver, which is based on the Android OpenPlatformPkg implementation,
provides support for that.
Contributed-under: TianoCore Contribution Agreement
The libraries decide and set the boot order between UEFI Shell, SD media
and/or USB media and allow for user configuration and override. Stale
boot options (non present media) are automatically removed on boot.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
The BCM283x family includes two SD card controllers, the second one
being the "internal" SD HOST controller. This driver implements support
for this one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
The BCM283x family includes two SD card controllers, one being an Arasan
SDHCI compliant controller. This driver implements support for this one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
This implements the MMC Host protocol, which is used by the two
concurrent SD interface drivers that the Raspberry Pi 3 supports.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/Drivers/MmcDxe/ComponentName.c | 163
This driver serves the device tree that is either embedded
in the firmware volume or was provided through config.txt.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 364
Since the Raspberry Pi doesn't have a NVRAM, this driver is used to store
non-volatile user configuration settings into the firmware volume itself.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Implements the graphic console (extended text output) needed
for user interaction.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/Drivers/GraphicsConsoleDxe/ComponentName.c
| 183 ++
Implements the EFI_GRAPHICS_OUTPUT_PROTOCOL for the Raspberry
Pi platform, through framebuffer, including resolution querying
and screenshot support.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Static SMBIOS Table for the ARM platform, derived from EmulatorPkg.
Implements SMBIOS 2.7.1 required structures.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c |
903
Provides the user-visible configuration options for the
firmware UI.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/Drivers/ConfigDxe/ConfigDxe.c| 351
Implements the base driver that is used to provide or set platform
specific configuration data.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
Reviewed-by: Ard Biesheuvel
---
Platform/RaspberryPi/RPi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 1084
A platform helper library, relying on low level Mailbox messaging
between the CPU and VideoCore to obtain current platform information,
that is used by various services and drivers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
These ACPI tables were mostly derived or copied from the MS-IoT ones.
This means that they are targetting Windows OSes, rather than Linux ones,
and aren't ACPI compliant, especially when it comes to their descriptors.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete
The memory init library ensures that relevant memory regions are
reserved on boot.
The reset library supports the ResetSystem runtime call using PSCI
and signals the gRaspberryPiEventResetGuid event group on reset,
which we need to save modified configuration vars to NVRAM.
Note that we tried to
This library is meant to be used by Bcm283x-based platforms, such
as the Raspberry Pi, to control the GPIO port pins on said platform.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
---
Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h | 49
This currently only implements support for the architected timer
interrupts on the per-CPU interrupt controllers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard
Reviewed-by: Ard Biesheuvel
---
Silicon/Broadcom/Bcm283x/Bcm283x.dec |
Changes for v5:
* Raspberry/Pi3 -> RaspberryPi/RPi3
* Remove VirtualRealTimeClockLib as well as BUILD_EPOCH macro (use the upcoming
EmbeddedPkg Virtual RTC from EDK2 instead)
* Use $(PLATFORM_NAME) where possible in .dsc and .fdf
* Update Readme to remove build instructions, describe ACPI
On 02/05/19 13:02, Philippe Mathieu-Daudé wrote:
> On 2/5/19 10:03 AM, Laszlo Ersek wrote:
>> On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
>>> Since 9c2d68c0a299 the build tools default to the python version
>>> provided by the ${PYTHON} environment variable.
>>> However the Python3 transition
(+Mike, +Andrew)
On 02/05/19 12:47, Leif Lindholm wrote:
> On Tue, Feb 05, 2019 at 10:03:21AM +0100, Laszlo Ersek wrote:
>> On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
>>> Since 9c2d68c0a299 the build tools default to the python version
>>> provided by the ${PYTHON} environment variable.
>>>
On 2/5/19 10:03 AM, Laszlo Ersek wrote:
> On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
>> Since 9c2d68c0a299 the build tools default to the python version
>> provided by the ${PYTHON} environment variable.
>> However the Python3 transition is not effective before d943b0c339fe.
>
> (1) Do you
On Tue, Feb 05, 2019 at 10:03:21AM +0100, Laszlo Ersek wrote:
> On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
> > Since 9c2d68c0a299 the build tools default to the python version
> > provided by the ${PYTHON} environment variable.
> > However the Python3 transition is not effective before
On 02/05/19 12:08, Leif Lindholm wrote:
> On Mon, Feb 04, 2019 at 08:02:55PM +0100, Laszlo Ersek wrote:
>> AIUI, "-a IA32 -a X64" it means "build the Components.* sections
>> (plural) as dictated by the '-a' flags, and then organize the full
>> (multi-arch) set of modules into the flash
The goal of commit 97c8f5b9e7d3 ("BaseTools:StructurePCD value display
incorrect in "Not used" section.", 2019-02-02) was to display the full
contents of such structure PCDs in the build report that were set in the
platform DSC or the FDF, but not used in any module INFs. The listings
would appear
On Mon, Feb 04, 2019 at 08:02:55PM +0100, Laszlo Ersek wrote:
> > Now, the Ia32X64 target is very much of a special case, which I don't
> > necessarily see as usefully supported by the current .dsc
> > specification. But I believe we need to do one of
> > - banning (simultaneous)
On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
> Since 9c2d68c0a299 the build tools default to the python version
> provided by the ${PYTHON} environment variable.
> However the Python3 transition is not effective before d943b0c339fe.
(1) Do you mean "functional" rather than "effective"?
(2)
Update TF-A to upstream v2.0 release (Commit: dbc8d9496ead). Also update
OP-TEE to upstream v3.4.0 release (Commit: 406c609bbf08).
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sumit Garg
---
Following is reference repo to pull this patch:
46 matches
Mail list logo