Hi all,
Following on the previous patch, here is the armv7 UEFI runtime services
support, documented on
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices
(Do note - GRUB boot is currently the only way to actually get the
UEFI system table into the kernel.)
The patches were based off linux-linaro-tracking, and when I tried building
for upstream 3.10-rc6 it failed due to a couple of header file changes.
I will address that during cleanup before upstream submission later this
week. Oh, and there is an accidental remaining edit of an x86 ifdef in
init/main.c. That will be fixed tomorrow.
Again, early reviewing would be appreciated.
/
Leif
Hi all,
This is my first, monolithic, stab at an early_ioremap for ARMv7 - taken
straight from the head of
http://git.linaro.org/gitweb?p=people/leiflindholm/linux-uefi-runtime-servi…
I'll be cleaning up, splitting up, documenting and see if I can get it
working on non-LPAE in time, and then send it upstream later this week.
Early reviewing would be much appreciated.
/
Leif
Hi Oliver,
Sorry for the missing information. I am using version 7.1.63 of the A15
fast model. I'm using the ArmVExpress-RTSM-A15_MPCore.dsc dsc file,and
building against the linaro-tracking-2013.05 branch of the uefi-next
repository. I have been making some changes, mostly debug related.
I had made the following changes to the DSC file:
gArmPlatformTokenSpaceGuid.PcdCoreCount|1
gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|FALSE
This was running fine on a single core until I started removing some debug
prints.
Roy
On 12 June 2013 02:10, Olivier Martin <olivier.martin(a)arm.com> wrote:
> Hello Roy,****
>
> ** **
>
> Which platform are you referring to? Which EDK2 DSC file are you using for
> your UEFI firmware?****
>
> ** **
>
> Thanks,****
>
> Olivier****
>
> ** **
>
> *From:* boot-architecture-bounces(a)lists.linaro.org [mailto:
> boot-architecture-bounces(a)lists.linaro.org] *On Behalf Of *Roy Franz
> *Sent:* 12 June 2013 03:03
> *To:* boot-architecture(a)lists.linaro.org
> *Subject:* Possible race condition in multi-core EDK2****
>
> ** **
>
> ** **
>
> I've been working with the DEBUG build of EDK2, and thought I had changed
> the configuration to be 'proper' for a single core, and it ran fine on a
> single core simulation. As I started removing debug prints, I started
> getting simulator seg faults. I confirmed that the difference between
> running and crashing versions were simply debug prints.****
>
> Changing the simulation to simulator 2 cores resolved the problem. I
> suspect that there may be a race condition or some other multi-core
> detection bug that causes this crash.****
>
> ** **
>
> I don't plan to investigate this further at this point - just wanted to
> report this as I was surprised to find that a debug print being removed
> would cause the simulator to crash.****
>
> ** **
>
> Roy****
>
> ** **
>
> ** **
>
> _______________________________________________
> boot-architecture mailing list
> boot-architecture(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/boot-architecture
>
>
On 12 June 2013 13:07, Olivier Martin <olivier.martin(a)arm.com> wrote:
> Here is a copy of what I sent to Ryan earlier:
>
>
> Unfortunately, I cannot remove the ArmPlatformLib from PL390Gic INF file
> even if it build in most cases.
> The reason is PL390GicSec now uses ArmPlatformIsPrimaryCore() that is
> implemented by ArmPlatformLib library.
> If one day one module uses PL390GicSec but does not depend itself on
> ArmPlatformLib then there is no reason why the engineer should add
> ArmPlatformLib to the INF file of this new module to solve PL390GicSec
> dependency.
>
> A reason why it could fail would be you are using a different ArmPlatformLib
> implementation than the one you are thinking.
> A way to check that is to generate the build report:
> build -A ARM -p ... -t ... -y report.log
> And check which libraries are used by each module.
>
> Actually, I am planning to rename 'PL390GicDxe' into 'ArmGicDxe' that will
> follow the 'ARM Generic Interrupt Controller Architecture Specification'.
>
> Cheers,
> Olivier
>
Thanks Olivier!
I didn't see this before I replied to your email!
This patch will be dropped. We need to find a proper solution for
Arndale. I *guess* it should just involve reworking the platform
DSC/FDF/etc. files in [PATCH 1/2] to include the right things?
>
>
>> -----Original Message-----
>> From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot-
>> architecture-bounces(a)lists.linaro.org] On Behalf Of Ryan Harkin
>> Sent: 12 June 2013 12:03
>> To: ryan.harkin(a)linaro.org; boot-architecture(a)lists.linaro.org
>> Subject: [PATCH 2/2] ArmPkg/PL390Gic: remove ArmPlatformLib from inf
>> file
>>
>> The PL390 GIC driver was including ArmPlatform in PL390GicSecLib.inf.
>>
>> This change is fine as it, however, when the Arndale platfom is fixed
>> to
>> remove its duplicated PL390 GIC driver, it hangs unless this library is
>> removed.
>>
>> Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org>
>> ---
>> ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf
>> b/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf
>> index 205e503..5851bfe 100644
>> --- a/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf
>> +++ b/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf
>> @@ -31,7 +31,6 @@
>>
>> [LibraryClasses]
>> ArmLib
>> - ArmPlatformLib
>> DebugLib
>> IoLib
>> PcdLib
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> boot-architecture mailing list
>> boot-architecture(a)lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/boot-architecture
>
>
>
>
>
> _______________________________________________
> boot-architecture mailing list
> boot-architecture(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/boot-architecture
These two patches will remove the GIC driver from the Arndale BSP, instead using the official GIC driver from the upstream tree:
[PATCH 1/2] Samsung/Arndale: remove GIC400 driver
[PATCH 2/2] ArmPkg/PL390Gic: remove ArmPlatformLib from inf file
I've already sent the second patch to Olivier for review, but as far as I can see, ArmPlatformLib is incuded in the PL390 sec lib, but it isn't needed.
Including it when booting on Arndale hangs the board. I'm guessing there are two issues:
1) if it isn't needed, we can remove it
2) but it shouldn't crash Arndale if it is included, so Arndale is most likely doing something wrong and we should probably work out what that is.
However, the general act of replacing Arndale's clone of the GIC driver seems safe. Arndale appears to have simply cloned an old version of the driver without modification. However, a couple of the bit masks may be different, so perhaps there is an underlying problem that I have not discovered?
Hence, a review by a few other people is really important.
Regards,
Ryan.
In-Reply-To:
I've been working with the DEBUG build of EDK2, and thought I had changed
the configuration to be 'proper' for a single core, and it ran fine on a
single core simulation. As I started removing debug prints, I started
getting simulator seg faults. I confirmed that the difference between
running and crashing versions were simply debug prints.
Changing the simulation to simulator 2 cores resolved the problem. I
suspect that there may be a race condition or some other multi-core
detection bug that causes this crash.
I don't plan to investigate this further at this point - just wanted to
report this as I was surprised to find that a debug print being removed
would cause the simulator to crash.
Roy
Hey all,
After my chat with Leif chat on Thurs, one thing I thought about was
bash completion for uefi-build.sh.
Turns out it's quite easy! I just pushed this commit to
uefi-tools.git [1]. It's quite dumb in that you can autocomplete
"DEBUG" or "RELEASE" even without the "-b" parameter, but hey, it
makes my life easier :-)
Cheers,
Ryan.
commit dc3ba99d46ecb87c529a475d5ff6b840cd2f7c8d
Author: Ryan Harkin <ryan.harkin(a)linaro.org>
Date: Tue Jun 11 13:00:12 2013 +0100
uefi-build: add bash completion script
Copy this script into the bash completion directory to easy entering
parameters:
$ sudo cp uefi-build.sh.bash_completion \
/etc/bash_completion.d/uefi-build.sh
Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org>
diff --git a/uefi-build.sh.bash_completion b/uefi-build.sh.bash_completion
new file mode 100644
index 0000000..f0a5305
--- /dev/null
+++ b/uefi-build.sh.bash_completion
@@ -0,0 +1,24 @@
+# bash completion for uefi-build.sh
+# copy this file to /etc/bash_completion.d/uefi-build.s
+
+have uefi-build.sh &&
+_uefi-build.sh()
+{
+ local cur prev
+
+ COMPREPLY=()
+ _get_comp_words_by_ref -n = cur
+
+ _expand || return 0
+
+ COMPREPLY=( $( compgen -W '--help -b --build RELEASE DEBUG a5 a9
tc1 tc2 panda origen arndale rtsm_a9x4 rtsm_a15x1 rtsm_a15mpcore
rtsm_aarch6
+} &&
+complete -F _uefi-build.sh uefi-build.sh
+
+# Local variables:
+# mode: shell-script
+# sh-basic-offset: 4
+# sh-indent-comment: t
+# indent-tabs-mode: nil
+# End:
+# ex: ts=4 sw=4 et filetype=sh
[1] http://git.linaro.org/gitweb?p=arm/uefi/uefi-tools.git;a=summary
[PATCH 1/2] TC1: Fix TC1 build for latest upstream changes
[PATCH 2/2] VEA5: Fix A5 build for latest upstream changes
The two platforms are relatively simple to fix because they follow the
TC2 and A9 BSPs very closely. Perhaps close enough to some more code
to be moved to common areas ;-)
These examples will show you the simple steps you will need to take to
get your BSP working.
However, your BSP may be using old functionality that my BSPs were not.
The main change to watch out for is the deletion of the macro
IS_PRIMARY_CORE() which has been replaced with a function that the BSP
must provide. The change came about with this commit:
--------------------------------------------------------------------------------
commit bebda7ceec3d3024c76b3c2ed0c9b4e502a13d61
Author: oliviermartin <oliviermartin@6f19259b-4bc3-4df7-8a09-765794883524>
Date: Fri May 10 12:41:27 2013 +0000
ArmPlatformPkg/ArmPlatformLib: Added support for ArmPlatformIsPrimaryCore()
Checking if a core if the primary/boot core used to be done with the macro
IS_PRIMARY_CORE().
Some platforms exposes configuration registers to change the primary core.
Replacing the macro IS_PRIMARY_CORE() by ArmPlatformIsPrimaryCore() allows
some flexibility in the way to check the primary core.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin(a)arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm(a)linaro.org>
Acked-by: Ryan Harkin <ryan.harkin(a)linaro.org>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14344 6f19259b-4bc3-4df7-8a09-765794883524
--------------------------------------------------------------------------------
My examples provide this function in a way that works for them, however,
your platforms may use different mechanisms. I have no specific code
that was using the IS_PRIMARY_CORE() macro, so these patches will not
give an example of how you deal with those changes, but Olivier's
original patch should help a lot there.
Regards,
Ryan.
[1] https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary
Hello UEFI folks,
I spent the day with Leif going through maintainer stuff and together
we produced the 2013.06 iteration of the Linaro UEFI tree [1].
Highlights include:
- A5, TC1, Panda, Origen and Arndale no longer build
(I will be fixing A5 and TC1 as part of -rc2, unless something
else urgent comes in and needs an -rc2)
- The -menu and -local-fdt topics have been merged into one -bds topic
to simplify upstreaming, reviewing and merging
- All topics are rebased to the latest Tianocore upstream code
- Some of our patches have made it upstream - yay! - and thus have
been removed from our topic branches
- There are more patches that we think are ready to go upstream now.
I'll start this after -rc2
Regards,
Ryan.
[1] https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary