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
Hi Ryan,
Thanks for the patch system and I will follow the
same methodology.
BR,
Steve
On 4 June 2013 10:50, Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> Hi Steve,
>
> Further to our phone call, I pushed out my patch system git repo:
>
> ssh://
> linaro-private.git.linaro.org/srv/linaro-private.git.linaro.org/uefi/patche…
>
> Hope it helps!
>
> Cheers,
> Ryan.
>
> On 3 June 2013 16:23, Steven Kinney <steven.kinney(a)linaro.org> wrote:
> > Hi Ryan,
> >
> > I am focusing on maintainer tasks today and tomorrow;
> > before I start on 64-bit SCT integration. I talked to Grant on my
> one-on-one
> > Friday and he suggested applying the patches within a local repository,
> > maybe within my git.linaro.org folder, and working with you regarding
> > merging and other GIT tasks. Of course, if you have ant suggestions to
> > start getting me up so that I can be more of use to you, please let me
> know.
> > Also, Grant wanted me to start giving suggestions regarding the coding,
> and
> > I see some areas that can be commented on, but I would like to make sure
> we
> > are in sync before I start yammering on commented out code blocks and
> such.
> >
> > Anyway, I look forward to learning about this area and
> > will ping you from time to time over the next few days to get some
> specific
> > advice. Thanks for you patience and help!
> >
> > BR,
> >
> > Steve
>
[cc'ing the boot architecture list; this conversation should be in public]
On Wed, May 29, 2013 at 11:19 AM, Leif Lindholm
<leif.lindholm(a)linaro.org> wrote:
> Hi Yi,
>
> On 28 May 2013 15:52, Li Yi <yi.li(a)linaro.org> wrote:
>> just modify linux loader , add SMBIOS address information into fdt. then
>> I will modify the dmidecode to parse the /dev/devicetree to find SMBIOS
>> table pointer. Maybe this way can skip grub and kernel's modification.
>
> Ok, yes, that should work.
>
>> the only problem I care about is the address wrote into fdt ,it is a
>> real physical address, does dmidecode (tool) can read this address ,and do
>> the right thing? it need to be proved.
>
> Yes - UEFI is guaranteed to run with a 1:1 mapping, so the address you see it
> at in the UEFI linux loader is the physical address.
>
>> Grant: if kernel will use the SMBIOS's region memory, can I reserve the
>> 64M memory from the top total ,then kernel will know it's reserved ,will not
>> use the region again ,right?
>
> That should be enough.
Yes, but you shouldn't even need to do that. I just looked at the
LinuxLoader code, in particular the UEFI FDT code, and I've noticed
that the reserved regions should already be set up. Look in
ArmPkg/Library/BdsLib/BdsLinuxFdt.c, about line 420. The function
PrepareFdt() retrieves the UEFI memory map and calls fdt_add_mem_rsv()
for each region.
It does use the function IsLinuxReservedRegion() to filter the
regions, so if SMBIOS uses a different region type then you'll need to
add that type to the list.
So, if I'm correct, it should be sufficient to merely enable SMBIOS
support in UEFI and the kernel will automatically mark the SMBIOS
region as reserved. You can verify this by adding "memblock=debug" to
the kernel command line and looking at the kernel boot output. You'll
see something like this:
memblock_reserve: [0x00000000008400-0x0000000042e98c]
arm_memblock_init+0x4c/0x150
memblock_reserve: [0x00000004000000-0x0000000452f400]
arm_memblock_init+0xcc/0x150
memblock_reserve: [0x00000000004000-0x00000000008000]
arm_memblock_init+0xf0/0x150
memblock_reserve: [0x00000004530000-0x00000004537350]
arm_dt_memblock_reserve+0x30/0xb0
MEMBLOCK configuration:
memory size = 0x8000000 reserved size = 0x960cdc
memory.cnt = 0x1
memory[0x0] [0x00000000000000-0x00000007ffffff], 0x8000000 bytes
reserved.cnt = 0x4
reserved[0x0] [0x00000000004000-0x00000000007fff], 0x4000 bytes
reserved[0x1] [0x00000000008400-0x0000000042e98b], 0x42658c bytes
reserved[0x2] [0x00000004000000-0x0000000452f3ff], 0x52f400 bytes
reserved[0x3] [0x00000004530000-0x0000000453734f], 0x7350 bytes
Memory policy: ECC disabled, Data cache writeback
memblock_reserve: [0x00000007fff000-0x00000008000000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffe000-0x00000007fff000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffdf10-0x00000007ffe000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffc000-0x00000007ffd000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffb000-0x00000007ffc000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffa000-0x00000007ffb000]
memblock_alloc_base_nid+0x68/0x84
Note: this only works with the UEFI LinuxLoader. The GRUB code doesn't
currently add the UEFI reserved regions to the FDT reserved map.
g.
Hi Roy,
Here are some very quick notes on what I found on writing UEFI applications.
I found a library called "gnuefi" which allows building EFI
applications apart from the Tianocore build tree. It looks
interesting, but has not been ported to ARM. I don't yet know if it is
worthwhile pursuing.
http://gnu-efi.sourceforge.net/
As mentioned, the Linux kernel has an EFI stub already. I could tell
you which files to look at, but really just doing a "git grep
EFI_STUB" in the kernel tree will show you all the files that you need
to care about. :-)
You'll need to figure out how to get a UEFI PE-COFF header into the
LInux kernel zImage wrapper. It shouldn't be too hard. You'll need to
look at the startup code in arch/arm/boot/compressed/head.S. The
PE-COFF header will need to go somewhere after the start: label. You
should be able to see the existing LInux kernel "header" (not much of
a header, more of a magic number) about 10 lines down from the start
label.
That's all I can write at the moment. We can talk more tomorrow.
g.
Terse information, more engineering notes than documentation, and
links to sources can be found at:
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices
Contains a few known bugs, and will need some fundamental
discussions/reengineering, but lets us start experimenting.
/
Leif