On November 16, 2018 at 7:42:51 PM, Sean Brogan via edk2-devel
(edk2-devel@lists.01.org(mailto:edk2-devel@lists.01.org)) wrote:
> I really can't get behind the Phabricator tool suite as it just has too many
> downsides (self-hosted or pay, lack of integrations, lack of support and
> limited se
Mike,
I like the github teams option for discussion as it is just there, free, and
easy. It integrates nicely with all other parts of github. Notifications are
supported for those that want email. Is there any reason this path doesn't
get used now as a test since tianocore is already in git
On 11/16/2018 4:37 PM, Rebecca Cran wrote:
On Friday, 16 November 2018 17:34:09 MST stephano wrote:
Rebecca Cran also brought up that Phabricator allows discussions to be
interacted with via email. A quick search for Phabricator and
"Configuring Inbound Email" it seems that one can both receive
On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel wrote:
>
> NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
> that are not based on the device tree received from QEMU.
>
> For ArmVirtQemu, this does not really matter, given that the NOR
> flash banks are always the same: the PEI cod
The ArmPlatformPkg NOR flash driver has been updated to use device paths
consisting of a fixed GUID and a numeric index rather than a separate GUID
for each flash bank on a given system. This means all explicit device path
references to NOR flash banks have to be brought up to date as well.
Contri
Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
has its own VendorHw GUID, and instances of NorFlashPlatformLib
describe each bank to the driver, along with the GUID for each.
This works ok for bare metal platforms, but it would be useful for
virtual platforms if we could obtai
This series fixes an issue reported by Hongbo and Philippe, where
ArmVirtQemuKernel will crash on an attempt to access flash bank #0,
which is secure-only when running QEMU with support for EL3.
So let's switch to discovering the NOR flash banks from the device tree
instead. This requires some pre
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
that are not based on the device tree received from QEMU.
For ArmVirtQemu, this does not really matter, given that the NOR
flash banks are always the same: the PEI code is linked to execute
in place from flash bank #0, and the fixe
On 11/16/2018 2:14 PM, Philippe Mathieu-Daudé wrote> For people on the
move, having bad internet (3rd world countries), email
system is very powerful, you can download once and work offline,
reading/answering. You can also download the list archive and refers to
it offline. You also have access
On Friday, 16 November 2018 17:34:09 MST stephano wrote:
> Rebecca Cran also brought up that Phabricator allows discussions to be
> interacted with via email. A quick search for Phabricator and
> "Configuring Inbound Email" it seems that one can both receive and send
> discussion messages if confi
On 11/16/2018 1:51 PM, Rebecca Cran wrote> Conversations can followed
via email, so that's one way of 'exporting' them.
But otherwise, I suspect you'd need to either query the database directly or
use "./bin/storage dump":
Perfect. As long as we have a way to store history of conversations I
t
When setting up the stack in the startup code and jumping into C code
for the first time, ensure that the frame pointer register is cleared
so that backtraces terminate correctly. Otherwise, output like the
below is shown when encountering an exception on a DEBUG build:
Synchronous Exception at
When setting up the stack in the startup code and jumping into C code
for the first time, ensure that the frame pointer register is cleared
so that backtraces terminate correctly. Otherwise, output like the
below is shown when encountering an exception on a DEBUG build:
Synchronous Exception at
The backtrace code on AARCH64 does not sanitize the frame pointer values
it pulls of the stack when attempting to do a backtrace, and so junk left
in the frame pointer register may result in a recursive exception and a
truncated backtrace.
Ard Biesheuvel (2):
ArmPlatformPkg: clear frame pointer
On 16/11/18 21:46, stephano wrote:
This looks great.
I'm going to dig in a bit and see if we can export discussions for
logging purposes or if they are locked into Github.
For people on the move, having bad internet (3rd world countries), email
system is very powerful, you can download once
On Friday, 16 November 2018 14:42:44 MST stephano wrote:
> This is a great suggestion, thanks! Two questions:
> 1. Does it allow you to export your conversations in some way?
Conversations can followed via email, so that's one way of 'exporting' them.
But otherwise, I suspect you'd need to eith
On 11/16/2018 12:52 PM, Rebecca Cran wrote:
I'm in several Slack teams: it seems to be the go-to solution for persistent
chat nowadays. None of those pay (i.e. they're on the free tier), so are
subject to its 10,000 message history limit.
I have found the same situation in other open source com
This looks great.
I'm going to dig in a bit and see if we can export discussions for
logging purposes or if they are locked into Github.
git clone git://tianocore.discussion ? :)
On 11/16/2018 11:55 AM, Kinney, Michael D wrote:
Hi Stephano,
GitHub supports discussions for teams.
If we adde
On Friday, 16 November 2018 12:13:37 MST stephano wrote:
> The only reason I didn't include Slack is that it will only log so much
> information before things start falling off into the ether.
>
> Does anyone in the community currently use Slack and know of an easy way
> of archiving conversations
Hi Stephano,
GitHub supports discussions for teams.
If we added a new team to the GitHub TianoCore
organization for all developers that want to be
involved in community topics and design discussions
(which should closely match the current members of
edk2-devel) then that may be a simple option th
The only reason I didn't include Slack is that it will only log so much
information before things start falling off into the ether.
Does anyone in the community currently use Slack and know of an easy way
of archiving conversations publicly?
On 11/16/2018 9:56 AM, Zimmer, Vincent wrote:
htt
https://slack.com/
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kevin D
Davis
Sent: Friday, November 16, 2018 9:35 AM
To: stephano ; edk2-devel@lists.01.org
Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software
If we get to vote, I’d vote against Google Groups. Their interface is
very geared toward their internal work flow and seems to change on a whim.
Thanks,Kevin
On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano"
wrote:
We are looking to augment o
We are looking to augment our current communication methods (mailing
list / IRC) with a modern solution for group collaboration. The goal is
to allow folks to communicate effectively without interrupting the
current patch review system, as well as enabling any future systems with
more robust op
Liming,
Adding a new Python3 directory will increase the maintenance and testing of the
python-based BaseTools.
It would be better if we could have one version of the python sources that work
with both Python2 and Python3.
We should use the edk2-staging branch to work towards this goal.
Pleas
Move the Identification file.
This file is only ever imported into the Eot tool.
Cc: Yonghong Zhu
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/{Common => Eot}/Identification.py | 0
BaseTools/Source/Python/Eot/In
add a variable for the string '*' and then use it instead of lots of '*'
Cc: Yonghong Zhu
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 54
++--
BaseTools/Source/P
1) remove an identical function and import it from Common.LongFilePathSupport
2) remove an import that is not needed/used.
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/AutoGen/UniClassObject.py |
Hi, all
https://pythonclock.org/ say Python 2.7 will not be maintained past 2020. One
BZ https://bugzilla.tianocore.org/show_bug.cgi?id=55 also requests this
migration. And, Python37 does good performance optimization. In EDK2 build,
Python37 can improve 20% performance than Python27 in Build
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Friday, November 09, 2018 2:58 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: Add V4 64bit
> ADMA2 support.
Add cpu on/off feature to support SBSA-PE test. This patch
also fix bug 3996:
https://bugs.linaro.org/show_bug.cgi?id=3996
Build commit information:
TrustedFirmware:5888a78d43c
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang
---
Platform/Hisilicon/D06/bl1.bin |
As SBSA uefi tool can't configuare interrupt following
WatchdogTimerFlags in GTDT, and watchdog interrupt in Hi1620
is edge-trigger, so modify watchdog interrupt type for SBSA
test case 42.
Build commit informations:
edk2:53caffc33b6
edk2-platforms:d4d7e39886a
HwPkg:bf0bdef14d5
TrustedFirmware:588
PE test case 15 flow:
Primary core(cacheable shareable) and slave cores(non-cacheable)
access the same memory area for communication.
For each slave core{
1 Turn on slave core;
2 run the payload function;
3 Write result in memory to notify primary core and follow
Main Change since v1:
1 Modify comments;
Code can also be found in github:
https://github.com/hisilicon/OpenPlatformPkg.git
branch: d06-acs-non-osi-v2
Ming Huang (4):
Hisilicon/D06: Add cpu on/off feature in TrustedFirmware
Hisilicon/D06: Fix SBSA test case 42 failed issues
Hisilicon/D06:
The default link timeout value of USB 3.0 controller is a bit
short for some USB devices, and may cause it timeout in some
cases. We have modify the registers in IoInitDxe,but a bug let
the modifying not successful.
Build commit informations:
edk2:53caffc33b6
edk2-platforms:d4d7e39886a
HwPkg:2a7ee
SdReadWrite can be called with a NULL Token for synchronous operations.
Add guard for DEBUG print to only print event pointer with Token is not
NULL.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen
---
MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 5 +++--
1 file cha
36 matches
Mail list logo
