Hi everyone,
We Linux developers seem to have a bit of a love-hate relationship
with ACPI. On the plus side it provides the "standard platform" that
we rely on to support the huge amount of hardware in the x86 ecosystem
It is also the source of much pain due to firmware and DSDT tables
that are either buggy or perform poorly. In the embedded space we've
avoided ACPI entirely by standardizing on the Flattened Device Tree
for hardware discovery. However there are some market segments and use
cases where FDT doesn't solve the problems faced by OEMs, particularly
when the hardware needs to support existing, unmodified OS images.
Some OEMs are looking to implement ACPI on ARM since it is a solution
they are already familiar with. It's becoming clear to me that in the
near future, independent of whether or not we as the Linux community
like it, we are going to start seeing ARM systems that are based on
UEFI and ACPI.
But, to quote h2g2, "Don't Panic." While there are many reasons as to
why ACPI has been the source of pain, at least one of those factors is
under our control. Historically, we as the Linux community have not
been very good at participating or providing leadership as to what the
future of the commodity hardware industry should look like, and the
result is decisions that don't reflect our best interest, sheerly by
omission. (There is an argument that standards setting hasn't been
inclusive either, but I have reason to hope that is neither permanent
nor insurmountable).
So, given that we know that ARM ACPI machines will exist, and given
that we still want to support Linux on these machines, I think it is
absolutely appropriate to start getting involved with both the ACPI
and UEFI standardization processes. I (on behalf of Linaro) will soon
be joining the UEFI ARM Binding Sub Team (ABST), and we already have
representatives from Canonical and Red Hat involved there. I'm also
investigating the possibility of getting involved when the post-ACPI 5
process begins, probably sometime early next year.
In the mean time, I want to start getting prepared by collecting
feedback about the state of ACPI and UEFI now, and what changes we
need to have for ACPI and UEFI to meet our needs in the Linux
ecosystem. Reply to this email with your comments, and I'll start
collating a list that I can discuss with the ACPI and UEFI folks.
For your reference, the current versions of the ACPI and UEFI specs
can be found here[1][2]. The ACPI spec is freely downloadable, but
the UEFI spec requires a click-through license to read.
[1] http://www.acpi.info/DOWNLOADS/ACPIspec40a.pdf
[2] http://www.uefi.org/specs/
I'll kick things off with a few items from my personal list. This list
will grow as I collect feedback and input from all of you.
1) Open Process - Currently the ACPI definition process is entirely
confidential between the 5 APCI member companies (Microsoft, Intel,
Toshiba, HP and Phoenix Technologies), and it remains so until the
Final Draft is proposed to "Contributing Adopters" which is very late
in the process. The current version of the spec is v4.0a[1]. ACPI 5
is currently under final review and will be released sometime late
2011, early 2012.
For us to participate in the ACPI definition, we need to have an open
processes so that open source Linux engineers can participate.
2) Improvements to compliance testing - Several Linux developers have
been doing good work on BIOS/UEFI/ACPI testing and are able to
identify many common bugs in firmware. This is of course valueable to
the Linux ecosystem, but since it is discovering firmware bugs, it is
most likely of high value to all HW and OS vendors. I would like to
see much of the test work that we're currently doing to start
filtering back into the tools that are routinely used by HW vendors as
part of QA testing. Maybe even pushing for an industry wide suite of
compliance tests.
3) Better rules (and testing) on SMM interrupts (or the ARM
equivalent). HW vendors are using SMM to work around hardware bugs or
perform system management tasks independently and transparently from
the operating system. However, poorly implemented firmware will take
the processor away from the OS for unbounded periods of time which is
a deal breaker for any kind of real-time response in the OS. For ARM
systems I would like to see an alternative to compete interruption of
the OS when firmware needs to perform system management tasks.
Cheers,
g.
Hi
Just to confirm what Jean-Christophe said on today's meeting: U-Boot
has disk/part_efi.c added in September 2008:
Add support for CONFIG_EFI_PARTITION (GUID Partition Table)
so it's indeed GPT support.
It's currently being turned on for two NVIDIA Tegra2 boards: Harmony
and Seaboard.
(I didn't try it out.)
One open question we had from last week's meeting is whether we can
have backwards-compatible entries for e.g. boot ROMs in current SoCs as
to use GPT for UEFI compatibility but with the relevant "PC" partitions
entries as to allow booting.
Cheers,
--
Loïc Minier
Meeting minutes are in:
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06
In particular note
- the decision for the focus in a two-pronged approach for short and
long term goals ( see
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06#Minutes
for details, below is just a summary)
+ SHORT TERM pain points are summarized below - the list needs
priorization and to be shown to the TSC so that suitable resources are
assigned to do the work
- support for Uboot
- kernel update process/method
- making every uboot behave the same way
- how does uboot decide what kernel to load - does not have to be
uboot specific fix, could be a script for uboot
- single zImage able to boot on multiple SOCs
- support for grub on uboot.
- Port tianocore as a uboot app
- uboot should understand which is the active partition - or should
have a mechanism to tell the user which is the active partition
+ LONG TERM goals (strategic and design issues): there is a vendors'
interest in standards process - which the Linux community has not been
extremely involved with in the past. So we should work with the
standards - get familiar with the existing standards
For next week - ALL should download and get familiar with ACPI/UEFI
specs (and open firmware ones - if not already familiar with those).
Let me know if there is something missing or wrong in the minutes, I can
update as indicated.
Best regards,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi all,
I drafted a quick wikipage to explain how to port EDK2 (UEFI Open Source
implementation) on a new ARM Platform :
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformP
kg
I am aware this wikipage could require some EDK2 knowledge but I will try to
fill these gaps in the future by creating or referring to wikipages that
explains some of the key EDK2 concepts.
Feel free to directly send me an email if you want more explanations about a
specific concept. That would help to define priorities.
Olivier
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-09-29
Please note the wiki page for the next meeting is set :
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06
Summary of the action points:
- [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership
- [CARRIEDOVER] David Rusling: - Linaro UEFI membership - target Linaro
Connect
- [CARRIEDOVER] Grant to draft a position on secure boot, from the
Linaro perspective, which can be reviewed by Linaro TSC
- [CARRIEDOVER] <tba> Interact with Microsoft on ARM boot interface -
there is some discussion more to say say by around mid October
- [CARRIEDOVER] Grant: Draft DTB recommended practices and getting the
recommended practices document out and merged into a public tree by
Linaro Connect (actually means the week before - as there are other
events before the Connect) INPROGRESS,
- [CARRIEDOVER] Grant: Select date & time for the next f2f meeting (Next
F2F in ELCE in Prague (OCT 26-28) ?)
Option 1: half-day meeting during ELCE, some folks won't make it - this
is the plan to go for Final confirmation
- [CARRIEDOVER] Will: Define SMP boot requirements - spin tables? Target
Linaro Connect. No updates.
- [ACTION] Olivier to send the wiki link with the documentation on how
to port UEFI to new platforms
- [ACTION] Jean-Christophe to send a RFC to the list regarding the
kernel image format and entry protocol
- [ACTION] Jean-Christophe to send some more details the list regarding
the question : is it possible to put the initrd in the DT directly
(similar to putting some firmware in the DT)? Proposal (JC) is to have 2
device trees, one very minimal with the boot arguments and another with
the HW description.
- [ACTION] Jean-Christophe to put an example of the boot sequence to the
mailing list
Best,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi folks
Etherpad: http://etherpad.osuosl.org/arm-boot-architecture-meeting-notes
I have updated this etherpad with the action points and agenda for
today. Grant, since you will be unable to join, I hope you could give an
update for the actions under your name, I have grouped the action points
under your name at the top of the AP list.
Agenda for today:
* Action items review
* Status updates on DT and UEFI work
* Implementation on other bootloader than the ARM one
* HW platform status
* Android + UEFI status
Anything else to add?
(PLEASE NOTE: As usual, I will be using the etherpad to update the wiki
meeting minutes which is your best reference location to check what was
discussed during any of the meetings.)
Cheers!
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Is there already support for UEFI Runtime Services in the kernel? If not is this already planned for Linaro?
UEFI Runtime Services are necessary for exchanging NVRAM values with the UEFI environment. These NVRAM values provide the foundation for UEFI spec'ed functionality ranging from boot entry management to key management for secure boot.
Thanks,
Eugene
https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-09-22
Please note the new action points at the bottom of the page. Send your
status updates to the list regarding:
- DT and UEFI work
- Implementation on other bootloader than the ARM one
- HW platform status
In addition there was no time to discuss during the last meeting the
Android + UEFI status. Could someone summarize the status there for
the rest of the list?
Thanks,
*************************************
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
*************************************
Hey
As discussed again in today's call, I've pushed a git mirror of edk2's
and edk2-fatdriver2's SVN modules to git.linaro.org.
This is temporary in that:
* the whole history of edk2-fatdriver2 was imported, but only the last
revision of edk2 was imported (a full import is running, but that
will take a while)
* git.linaro.org lacks git-svn and has outbound traffic firewalled; I'm
working with IS to resolve this
These can be used right now, with the caveats that the branches might
be rebased or might move to another host; I'm happy to assist if you
need help moving your patches around when that happens.
The repos are:
git://git.linaro.org/mirror/edk2/edk2.gitgit://git.linaro.org/mirror/edk2/edk2-fatdriver2.git
These were created with:
git svn clone -s \
https://edk2-fatdriver2.svn.sourceforge.net/svnroot/edk2-fatdriver2
edk2-fatdriver2
git svn clone -r 12354 -s \
https://edk2-fatdriver2.svn.sourceforge.net/svnroot/edk2
edk2
Would you need any other SVN module mirrored, or if you have
suggestions about a different set of git-svn options, please get in
touch with me.
Cheers
--
Loïc Minier
Hi everyone,
I'd like to get the date and time sorted out for the next two boot
architecture face-to-face meetings. For the next one, I propose
scheduling it as a 1/2 day summit during LinuxCon & ELC-E in Prague,
Oct 26-28th, or possibly the day before in parallel with kernel
summit. ELC-E I think is an excellent venue since there will be
representatives from a large number of ARM vendors in attendance, as
well as core Linux developers. I believe we'll be able to get a
larger cross-section of the ecosystem there than will be attending
LInaro Connect the week after in Orlando. Does anybody have any
issues with that date? Is there a specific day that works best? I
haven't talked with the Linux Foundation folks yet or looked at the
schedule, but I'll try to choose a time that doesn't conflict with
related presentations.
For the meeting after that, there are two options; either at Linaro
Connect Q1.12, February 6-10, in San Diego (?), or I *think* ELC the
week after and also in San Diego. I need confirmation from the LF
though about the scheduling. I'm leaning toward ELC for this meeting
also for the same reasons as above, but it might be a good strategy to
alternate between Linaro and non-Linaro gatherings. Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[sorry if this is the wrong list, please direct me to the right one as needed]
I'm trying to get my head wrapped around FDT to understand how UEFI firmware can produce this (and possibly use it internally) and pass it to the OS.
I've been trying to find the authoritative specification describing DT and FDT. My experience searching resulted in a lot of dead links. Is the spec the ePAPR specification? How does this specification get updated to provide compatibility or enhancements that the current spec does not address like ARM architecture additions?
Also is there a central registry, if any, of strings for vendors or compatible hardware? For example if I have a property 'compatible = "hp,widget123";' who determines whether 'hp' standard for Hewlett-Packard or Henry's Pickles? Along the same lines if there is a standard interface like a "gic" where is the spec/document describing what a "gic" is and how is it updated?
Sorry for the newbie DT questions... I guess I've been spoiled by the UEFI spec providing all the information I've needed in the past in once place. :)
Thanks,
Eugene
Dear Grant Likely,
In the boot architecture meeting held in Linaro connect
Q3, we discussed regarding a separate git repository for vendors supporting
the Uefi boot loader.
I am responsible for the supporting Uefi for samsung platform. Can you
please let me know when the git repository will be available to upstream the
UEFI.
Regards
Girish K S
We're looking into porting Xen to the ARM A15 architecture. In this
context, it's necessary to arrange for the Xen hypervisor to be
entered from the boot loader in an appropriate processor mode.
KVM needs to deal with the same problem, of course. And any future
Linux kernel feature which uses the Secure State does too.
We are currently working with ARM's "Fast Model" of the Cortex A15, a
software emulator. We're using it in the mode where you feed it an
ELF and it loads it into simulated RAM and starts executing at the
ELF entrypoint. It does this in the CPU's defined startup mode, which
is Kernel mode in the Secure state.
It seems that this environment is what the nascent KVM-on-A15
developers [1] are using too. There is modified version of the tiny
boot wrapper (the normal version of which just emulates the proper
calling API for the kernel); it sets up a trampoline security monitor.
We need to define a correct calling convention for the kernel which is
compatible with old systems, but which also allows the booted kernel
(Linux, perhaps KVM-enabled, or indeed a hypervisor like Xen) use of
all the available facilities. The correct approach does seem to be to
have Linux set itself up a trivial trampoline which allows the kernel
to later regain the elevated privilege.
There are a couple of things with the existing KVM ARM approach with
the trivial boot wrapper which need to be fixed, though: firstly,
there should be separate trampolines for hypervisor mode and for
secure state. That allows the two features to be used independently.
Secondly, the trivial trampolines should be part of the kernel proper
and their lifetime should not extend across the bootloader interface.
At first I thought that the best thing to do would be to boot the
kernel in any suitable mode, and have the kernel automatically detect
the starting mode. I started writing code in linux's head.S to do
this. However, detecting whether we are in secure state is very
difficult: it involves deliberately risking an undefined instruction
trap. The code for this was getting rather long and involved.
Also, unconditionally starting a kernel in hypervisor mode seems
rather unfriendly. At the moment we unconditionally start it in the
secure state and indeed in the current setup it seems to run entirely
in secure state. It seems to me that the kernel should mostly run in
non-secure state.
So I propose the following approach:
1. The kernel will advertise via ELF notes what modes it may be
started in. The possible modes will be:
(i) secure monitor mode
(ii) non-secure hypervisor mode
(iii) non-secure kernel mode
2. The bootloader will select the first mode from the three listed
above which is supported by both the processor and the kernel to
be loaded, and transition the processor to that mode. If this
involves dropping out of secure or hypervisor mode, it will put
those modes permanently beyond use.
3. The kernel will examine CPSR to determine which of the three
possibilities above has happened, and:
(a) If started in monitor mode:
* Grant access to everything to non-secure state
* Set the non-secure copies of the various CP15 registers
which don't have a sane value on cpu reset
* Install a trivial monitor vector which unconditionally
copies r0 to MVBAR and returns
* Switch to non-secure Hyp mode (if available) and do (b),
or non-secure Kernel mode (if Hyp mode not supported).
(b) If started in Hyp mode:
* Install a trivial hypervisor vector which unconditionally
copies r0 to HVBAR and returns
(c) Rest of startup.
Questions:
1. What do people think ? If this seems plausible I will prepare
an RFC patch for Linux and the boot-wrapper.git.
2. This cpu startup process must happen very early - before paging
is enabled, in any case, so before RAM is really available.
However, it produces two bits of information: 1. does the
kernel own secure state; 2. does the kernel own hyp mode.
Where should this information be stored ?
3. Is Linux allowed to assume that the secondary CPUs have the
same properties as the boot CPU ? If not, where do I store the
availability of the secure/hyp modes for the secondary cpus ?
Perhaps that ought to be in the device tree.
4. I'm not very familiar with the KVM on ARM code. How much would
have to be changed to existing KVM on ARM to make it conform to
the above scheme ? In particular it would have to not use SMC to
adjust the HVBAR; instead, it would have to take control of HVBAR
once per CPU.
Opinions welcome.
Thanks,
Ian.
[1] http://wiki.ncl.cs.columbia.edu/wiki/KVMARM:Guides:Development_Environment
Folks
September will be the time to restart the meetings for Boot
Architecture. The meetings should restart after the Plumbers event, so
wk37 (starting 12 September) looks a good time to restart.
I can create and send out the invitation, please let me know:
1. is the frequency ok - every week? YES/NO (if not then how often
should we meet in your opinion)
2. is the day of the week and time ok? It used to be Thursdays at 14:00
UTC, does that still suit you?
I will gather all the responses and try to meet all your constraints.
Best,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi Olivier:
Thanks, I have also forwarded to the EDK2 mailing list.
Cheers,
Alan C
From: Olivier Martin
Sent: Friday, August 19, 2011 4:42 PM
To: Alan Chuang; boot-architecture(a)lists.linaro.org
Subject: RE: Booting Linux from UEFI on Beagleboard Qemu
Hi Alan,
I tried last night the build I recommended you (rev12160) but it did not work. I did a couple of additional fixes to make it work.
I had the same Linux kernel crash as you are seeing. I will let you of any updates.
It should be better to speak UEFI EDK2 specific issue on the edk2 mailing-list: edk2-devel(a)lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Thanks for the feedback,
Olivier
From: Alan Chuang
Sent: 19 August 2011 09:10
To: Olivier Martin; boot-architecture(a)lists.linaro.org
Subject: RE: Booting Linux from UEFI on Beagleboard Qemu
Hi Olivier:
Thanks for the update. I did a svn update (now at r12175) and tested it again:
1. It now indeed booted in Linux and I got the following error during Linux booting:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.35-1008-linaro-omap (buildd@hawthorn) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #15-Ubuntu Fri Oct 22 11:56:29 UTC 2010 (Ubuntu 2.6.35-1008.15-linaro-omap 2.6.35.7)
[ 0.000000] CPU: ARMv7 Processor [412fc083] revision 3 (ARMv7), cr=10c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Reserving 6291456 bytes SDRAM for VRAM
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] OMAP3430/3530 ES3.1 (iva sgx neon isp )
[ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
[ 0.000000] kernel BUG at /build/buildd/linux-linaro-2.6.35/mm/bootmem.c:419!
2. Trying the build-next.sh path, I am getting a different Linux kernel boot error
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.35-1008-linaro-omap (buildd@hawthorn) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #15-Ubuntu Fri Oct 22 11:56:29 UTC 2010 (Ubuntu 2.6.35-1008.15-linaro-omap 2.6.35.7)
[ 0.000000] CPU: ARMv7 Processor [412fc083] revision 3 (ARMv7), cr=10c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x600000 bytes below 0x0.
[ 0.000000]
[ 0.000000] [<c0055be4>] (unwind_backtrace+0x0/0x100) from [<c050e8f8>] (dump_stack+0x18/0x1c)
[ 0.000000] [<c050e8f8>] (dump_stack+0x18/0x1c) from [<c050e968>] (panic+0x6c/0xe4)
[ 0.000000] [<c050e968>] (panic+0x6c/0xe4) from [<c001d570>] (memblock_alloc_base+0x4c/0x5c)
[ 0.000000] [<c001d570>] (memblock_alloc_base+0x4c/0x5c) from [<c0026914>] (omap_vram_reserve_sdram_memblock+0x14c/0x198)
[ 0.000000] [<c0026914>] (omap_vram_reserve_sdram_memblock+0x14c/0x198) from [<c001521c>] (omap_reserve+0x14/0x18)
[ 0.000000] [<c001521c>] (omap_reserve+0x14/0x18) from [<c000e280>] (arm_memblock_init+0xcc/0xd8)
[ 0.000000] [<c000e280>] (arm_memblock_init+0xcc/0xd8) from [<c000ce98>] (setup_arch+0x230/0x3b8)
[ 0.000000] [<c000ce98>] (setup_arch+0x230/0x3b8) from [<c00087e8>] (start_kernel+0xc0/0x33c)
[ 0.000000] [<c00087e8>] (start_kernel+0xc0/0x33c) from [<80008034>] (0x80008034)
So, the MMC fix is probably in the right direction, but I think there are other fixes that may interfere. There were quite a few files that got changed and I actually have to fix a few typos in order to make it compile. I will try r12160 instead.
Thanks,
Alan
From: Olivier Martin
Sent: Thursday, August 18, 2011 11:16 PM
To: Alan Chuang; boot-architecture(a)lists.linaro.org
Subject: RE: Booting Linux from UEFI on Beagleboard Qemu
Hi Alan,
What you did seem correct. I have not tried to duplicate the issue. But interestingly, I found a bug around the MMC driver using GCC to build the BeagleBoard UEFI firmware (the firmware was crashing when booting Linux).
I fixed the bug in the revision 12160. It could fix the bug you found.
Thanks,
Olivier
From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Alan Chuang
Sent: 12 August 2011 06:19
To: boot-architecture(a)lists.linaro.org
Subject: Booting Linux from UEFI on Beagleboard Qemu
Hi all:
I just started to play around with ARM UEFI stuff and has issue booting into Linux when trying to test the EDK2 software on Qemu. This seems like the right place to ask. I followed the instruction in (http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/BeagleBoardPkg/readm…) including downloading the specific version of binaries / tools. When trying to run UEFI (both in NOR flash method as well as SD card method), UEFI started successfully. However, I kept on getting "Did not find Linux kernel" error when trying to boot Linux. From EBL, I can see the zImage file is present (cd fs1:; dir). The zImage file is basically vmlinuz-2.6.35-1008-linaro-omap from the hwpack. I even tried to extract zImage from uImage, but the result is still the same.
I am wondering if anyone has run into the same issue and can give me a hint on what else to try.
Thanks,
Alan Chuang
---------------- Console Log -------------------
The default boot selection will start in 1 seconds
CMD0 response: 0
MmcStatus: 18000
CMD5 fails. Not an SDIO card.
CMD8 success. CMD8 response: 1CE
Card is SD2.0
CMD55 success. CMD55 response: 120
SD card detected. ACMD41 OCR: C0FFFF00
High capacity card.
CMD2 response: EF006219 1DEADBE 454D5521 AA585951
CMD3 response: RCA 4567
CMD9 response: A400000 FFF7F80 5B590000 400E0032
Card type: 4, BlockSize: 200, NumBlocks: 400000
MaxDataTransferRate: 0x32, Frequency: 25000 KHz, ClockFrequencySelect: 4
SD Memory Card set to 4-bit mode
SD Card Media Change on Handle 0x8792E290
SD Card ReinstallProtocolInterface ()
ERROR: Did not find Linux kernel.
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 2
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- Arguments:
Update entry: 1
File path of the EFI Application or the kernel: zImage
Has FDT support? [y/n] n
Arguments to pass to the binary:
Description for this new Entry: Linux from SD
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 4
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 2
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
add-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
Embedded Boot Loader (EBL) prototype. Built at 09:56:17 on Aug 12 2011
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN 'AS IS' BASIS,
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
Please send feedback to edk2-devel(a)lists.sourceforge.net
BeagleEdk2 >device
Firmware Volume Devices:
fv0: 0x80008000 - 0x80087FFF : 0x00080000
fv1: 0x87C4A000 - 0x87E0751F : 0x001BD520
File System Devices:
fs0: SemihostFs:
fs1: boot:
Block IO Devices:
blk0: Size = 0x10000000
blk1: Removable Size = 0x80000000
blk2: fs1: Removable Partition Size = 0x33F8000
blk3: Removable Partition Size = 0x7CC00000
BeagleEdk2 >devicepaths
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
[0x87A00790] MemoryMapped(0xB,0x80008000,0x80087FFF)
[0x87A00490] MemoryMapped(0xB,0x87C4A000,0x87E0751F)
[0x87975B10] VenHw(6696936D-3637-467C-87CB-14EA8248948C)/Uart(115200,8,N,1)
[0x8796B910] VenHw(4D00EF14-C4E0-426B-81B7-30A00A14AAD6)
[0x8792E290] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)
[0x8792D390] PciRoot(0x0)/Pci(0x0,0x0)
[0x87918890] VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)
[0x8790A890] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)
[0x8790A590] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(2,MBR,0x00000000,0x1A000,0x3E6000)
BeagleEdk2 >exit
remove-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start:
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Olivier:
Thanks for the update. I did a svn update (now at r12175) and tested it again:
1. It now indeed booted in Linux and I got the following error during Linux booting:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.35-1008-linaro-omap (buildd@hawthorn) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #15-Ubuntu Fri Oct 22 11:56:29 UTC 2010 (Ubuntu 2.6.35-1008.15-linaro-omap 2.6.35.7)
[ 0.000000] CPU: ARMv7 Processor [412fc083] revision 3 (ARMv7), cr=10c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Reserving 6291456 bytes SDRAM for VRAM
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] OMAP3430/3530 ES3.1 (iva sgx neon isp )
[ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
[ 0.000000] kernel BUG at /build/buildd/linux-linaro-2.6.35/mm/bootmem.c:419!
2. Trying the build-next.sh path, I am getting a different Linux kernel boot error
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.35-1008-linaro-omap (buildd@hawthorn) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #15-Ubuntu Fri Oct 22 11:56:29 UTC 2010 (Ubuntu 2.6.35-1008.15-linaro-omap 2.6.35.7)
[ 0.000000] CPU: ARMv7 Processor [412fc083] revision 3 (ARMv7), cr=10c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x600000 bytes below 0x0.
[ 0.000000]
[ 0.000000] [<c0055be4>] (unwind_backtrace+0x0/0x100) from [<c050e8f8>] (dump_stack+0x18/0x1c)
[ 0.000000] [<c050e8f8>] (dump_stack+0x18/0x1c) from [<c050e968>] (panic+0x6c/0xe4)
[ 0.000000] [<c050e968>] (panic+0x6c/0xe4) from [<c001d570>] (memblock_alloc_base+0x4c/0x5c)
[ 0.000000] [<c001d570>] (memblock_alloc_base+0x4c/0x5c) from [<c0026914>] (omap_vram_reserve_sdram_memblock+0x14c/0x198)
[ 0.000000] [<c0026914>] (omap_vram_reserve_sdram_memblock+0x14c/0x198) from [<c001521c>] (omap_reserve+0x14/0x18)
[ 0.000000] [<c001521c>] (omap_reserve+0x14/0x18) from [<c000e280>] (arm_memblock_init+0xcc/0xd8)
[ 0.000000] [<c000e280>] (arm_memblock_init+0xcc/0xd8) from [<c000ce98>] (setup_arch+0x230/0x3b8)
[ 0.000000] [<c000ce98>] (setup_arch+0x230/0x3b8) from [<c00087e8>] (start_kernel+0xc0/0x33c)
[ 0.000000] [<c00087e8>] (start_kernel+0xc0/0x33c) from [<80008034>] (0x80008034)
So, the MMC fix is probably in the right direction, but I think there are other fixes that may interfere. There were quite a few files that got changed and I actually have to fix a few typos in order to make it compile. I will try r12160 instead.
Thanks,
Alan
From: Olivier Martin
Sent: Thursday, August 18, 2011 11:16 PM
To: Alan Chuang; boot-architecture(a)lists.linaro.org
Subject: RE: Booting Linux from UEFI on Beagleboard Qemu
Hi Alan,
What you did seem correct. I have not tried to duplicate the issue. But interestingly, I found a bug around the MMC driver using GCC to build the BeagleBoard UEFI firmware (the firmware was crashing when booting Linux).
I fixed the bug in the revision 12160. It could fix the bug you found.
Thanks,
Olivier
From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Alan Chuang
Sent: 12 August 2011 06:19
To: boot-architecture(a)lists.linaro.org
Subject: Booting Linux from UEFI on Beagleboard Qemu
Hi all:
I just started to play around with ARM UEFI stuff and has issue booting into Linux when trying to test the EDK2 software on Qemu. This seems like the right place to ask. I followed the instruction in (http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/BeagleBoardPkg/readm…) including downloading the specific version of binaries / tools. When trying to run UEFI (both in NOR flash method as well as SD card method), UEFI started successfully. However, I kept on getting "Did not find Linux kernel" error when trying to boot Linux. From EBL, I can see the zImage file is present (cd fs1:; dir). The zImage file is basically vmlinuz-2.6.35-1008-linaro-omap from the hwpack. I even tried to extract zImage from uImage, but the result is still the same.
I am wondering if anyone has run into the same issue and can give me a hint on what else to try.
Thanks,
Alan Chuang
---------------- Console Log -------------------
The default boot selection will start in 1 seconds
CMD0 response: 0
MmcStatus: 18000
CMD5 fails. Not an SDIO card.
CMD8 success. CMD8 response: 1CE
Card is SD2.0
CMD55 success. CMD55 response: 120
SD card detected. ACMD41 OCR: C0FFFF00
High capacity card.
CMD2 response: EF006219 1DEADBE 454D5521 AA585951
CMD3 response: RCA 4567
CMD9 response: A400000 FFF7F80 5B590000 400E0032
Card type: 4, BlockSize: 200, NumBlocks: 400000
MaxDataTransferRate: 0x32, Frequency: 25000 KHz, ClockFrequencySelect: 4
SD Memory Card set to 4-bit mode
SD Card Media Change on Handle 0x8792E290
SD Card ReinstallProtocolInterface ()
ERROR: Did not find Linux kernel.
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 2
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- Arguments:
Update entry: 1
File path of the EFI Application or the kernel: zImage
Has FDT support? [y/n] n
Arguments to pass to the binary:
Description for this new Entry: Linux from SD
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 4
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 2
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
add-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
Embedded Boot Loader (EBL) prototype. Built at 09:56:17 on Aug 12 2011
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN 'AS IS' BASIS,
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
Please send feedback to edk2-devel(a)lists.sourceforge.net
BeagleEdk2 >device
Firmware Volume Devices:
fv0: 0x80008000 - 0x80087FFF : 0x00080000
fv1: 0x87C4A000 - 0x87E0751F : 0x001BD520
File System Devices:
fs0: SemihostFs:
fs1: boot:
Block IO Devices:
blk0: Size = 0x10000000
blk1: Removable Size = 0x80000000
blk2: fs1: Removable Partition Size = 0x33F8000
blk3: Removable Partition Size = 0x7CC00000
BeagleEdk2 >devicepaths
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
[0x87A00790] MemoryMapped(0xB,0x80008000,0x80087FFF)
[0x87A00490] MemoryMapped(0xB,0x87C4A000,0x87E0751F)
[0x87975B10] VenHw(6696936D-3637-467C-87CB-14EA8248948C)/Uart(115200,8,N,1)
[0x8796B910] VenHw(4D00EF14-C4E0-426B-81B7-30A00A14AAD6)
[0x8792E290] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)
[0x8792D390] PciRoot(0x0)/Pci(0x0,0x0)
[0x87918890] VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)
[0x8790A890] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)
[0x8790A590] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(2,MBR,0x00000000,0x1A000,0x3E6000)
BeagleEdk2 >exit
remove-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start:
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all:
I just started to play around with ARM UEFI stuff and has issue booting into Linux when trying to test the EDK2 software on Qemu. This seems like the right place to ask. I followed the instruction in (http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/BeagleBoardPkg/readm…) including downloading the specific version of binaries / tools. When trying to run UEFI (both in NOR flash method as well as SD card method), UEFI started successfully. However, I kept on getting "Did not find Linux kernel" error when trying to boot Linux. From EBL, I can see the zImage file is present (cd fs1:; dir). The zImage file is basically vmlinuz-2.6.35-1008-linaro-omap from the hwpack. I even tried to extract zImage from uImage, but the result is still the same.
I am wondering if anyone has run into the same issue and can give me a hint on what else to try.
Thanks,
Alan Chuang
---------------- Console Log -------------------
The default boot selection will start in 1 seconds
CMD0 response: 0
MmcStatus: 18000
CMD5 fails. Not an SDIO card.
CMD8 success. CMD8 response: 1CE
Card is SD2.0
CMD55 success. CMD55 response: 120
SD card detected. ACMD41 OCR: C0FFFF00
High capacity card.
CMD2 response: EF006219 1DEADBE 454D5521 AA585951
CMD3 response: RCA 4567
CMD9 response: A400000 FFF7F80 5B590000 400E0032
Card type: 4, BlockSize: 200, NumBlocks: 400000
MaxDataTransferRate: 0x32, Frequency: 25000 KHz, ClockFrequencySelect: 4
SD Memory Card set to 4-bit mode
SD Card Media Change on Handle 0x8792E290
SD Card ReinstallProtocolInterface ()
ERROR: Did not find Linux kernel.
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 2
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- Arguments:
Update entry: 1
File path of the EFI Application or the kernel: zImage
Has FDT support? [y/n] n
Arguments to pass to the binary:
Description for this new Entry: Linux from SD
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Return to main menu
Choice: 4
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start: 2
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
add-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
Embedded Boot Loader (EBL) prototype. Built at 09:56:17 on Aug 12 2011
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN 'AS IS' BASIS,
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
Please send feedback to edk2-devel(a)lists.sourceforge.net
BeagleEdk2 >device
Firmware Volume Devices:
fv0: 0x80008000 - 0x80087FFF : 0x00080000
fv1: 0x87C4A000 - 0x87E0751F : 0x001BD520
File System Devices:
fs0: SemihostFs:
fs1: boot:
Block IO Devices:
blk0: Size = 0x10000000
blk1: Removable Size = 0x80000000
blk2: fs1: Removable Partition Size = 0x33F8000
blk3: Removable Partition Size = 0x7CC00000
BeagleEdk2 >devicepaths
EhcCreateUsb2Hc: capability length 0
EhcDriverBindingStart: failed to create USB2_HC
[0x87A00790] MemoryMapped(0xB,0x80008000,0x80087FFF)
[0x87A00490] MemoryMapped(0xB,0x87C4A000,0x87E0751F)
[0x87975B10] VenHw(6696936D-3637-467C-87CB-14EA8248948C)/Uart(115200,8,N,1)
[0x8796B910] VenHw(4D00EF14-C4E0-426B-81B7-30A00A14AAD6)
[0x8792E290] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)
[0x8792D390] PciRoot(0x0)/Pci(0x0,0x0)
[0x87918890] VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)
[0x8790A890] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)
[0x8790A590] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(2,MBR,0x00000000,0x1A000,0x3E6000)
BeagleEdk2 >exit
remove-symbol-file /home/alanc/UEFI/src2/edk2/Build/BeagleBoard/DEBUG_ARMGCC/ARM/EmbeddedPkg/Ebl/Ebl/DEBUG/Ebl.dll 0x85BCD240
[1] Linux from SD
- VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage
- LoaderType: 1
- Arguments:
[2] EBL
[3] Boot Manager
Start:
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Thank you to everyone who attended the ARM boot architecture summit at
Linaro Connect Q3.11 a week ago. It was a big help in understanding
what the focus needs to be over the next 6 months, but it also
highlighted just how large the boot architecture work is.
I've put the meeting minutes up on the boot architecture wiki page[1],
and I'll be editing them and sorting out the action items. The
remainder of August is fully booked for me, and I've got the
impression that many others are in the same boat, so I'm deferring the
next conference call until September when most of us will be back into
a normal routine.
The next face to face meeting will be a BoF at Linux Plumbers
conference in Santa Rosa, California. September 7-9. Jon Masters is
organizing it.
The face to face meeting after that will most likely be scheduled in
conjunction with ELC-E/LinuxCon Europe/Kernel Summit in Prague at the
end of October.
[1] https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-08-05
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Wed, Jul 06, 2011, Olivier Martin wrote:
> Anyway, these are the build instructions to build the Tianocore project
> (UEFI Open Source implementation) and to test on qEmu:
> http://edk2.svn.sourceforge.net/viewvc/edk2/trunk/edk2/BeagleBoardPkg/readme
> .txt?revision=11997
I had started following these, but ran into some issues with my setup;
I will try with the alternate build-next.sh approach too, to see
whether I get other issues or not.
The two classes of issues I ran into was:
a) variables being written to, but never read
b) conditions being always true
I indeed had to apply the patch you mention; what's the state of that
patch? Are these things which will get merged soonish? Without the
patch, my toolchain wouldn't be properly picked up (it'd try running
c:/program files/ stuff and calling a CS toolchain) and I had some
error conditions like '-(' in linker invocations due to missing '\'
escapes. These go away with the patch and my toolchain is picked up
and works.
I'm running Ubuntu oneiric (which will become 11.10) and the toolchain
I've used is our packaged Linaro GCC based cross-compiler
(arm-linux-gnueabi-gcc from the gcc-arm-linux-gnueabi package).
a) variables being written to, but never read
This is stuff like:
--- a/edk2/BaseTools/Source/C/EfiLdrImage/EfiLdrImage.c
+++ b/edk2/BaseTools/Source/C/EfiLdrImage/EfiLdrImage.c
@@ -181,7 +181,7 @@ Returns:
CHAR8* OutputFileName = NULL;
CHAR8* InputFileNames[MAX_PE_IMAGES + 1];
UINT8 InputFileCount = 0;
- BOOLEAN QuietFlag = FALSE;
+ //BOOLEAN QuietFlag = FALSE;
UINT64 DebugLevel = 0;
UINT64 VerboseLevel = 0;
EFI_STATUS Status = EFI_SUCCESS;
@@ -220,7 +220,7 @@ Returns:
}
if ((stricmp (argv[0], "-q") == 0) || (stricmp (argv[0], "--quiet") == 0)) {
- QuietFlag = TRUE;
+ //QuietFlag = TRUE;
argc --;
argv ++;
continue;
QuietFlag is never used (read), newer gccs detect this and report it as
a fatal warning by default (not sure where this warning is configured
as a fatal one, whether it's in UEFI or in the toolchain config).
There are many such cases, but some are a bit more worrying, like
variables holding the return values of fread of fwrite not being
checked:
--- a/edk2/BaseTools/Source/C/GenVtf/GenVtf.c
+++ b/edk2/BaseTools/Source/C/GenVtf/GenVtf.c
@@ -1141,7 +1141,7 @@ Returns:
EFI_STATUS Status;
UINT64 CompStartAddress;
UINT64 FileSize;
- UINT64 NumByteRead;
+ //UINT64 NumByteRead;
UINT64 NumAdjustByte;
UINT8 *Buffer;
FILE *Fp;
@@ -1189,7 +1189,7 @@ Returns:
//
// Read first 64 bytes of PAL header and use it to find version info
//
- NumByteRead = fread (Buffer, sizeof (UINT8), SIZE_OF_PAL_HEADER, Fp);
+ /* NumByteRead = */fread (Buffer, sizeof (UINT8), SIZE_OF_PAL_HEADER, Fp);
//
// PAL header contains the version info. Currently, we will use the header
@@ -1200,7 +1200,7 @@ Returns:
}
}
- NumByteRead = fread (Buffer, sizeof (UINT8), (UINTN) FileSize, Fp);
+ /* NumByteRead = */fread (Buffer, sizeof (UINT8), (UINTN) FileSize, Fp);
fclose (Fp);
//
I just quickly hacked the source to get it to build, but we should fix
the code to loop until all bytes have been read or to raise an error.
The last such cases is a conditional piece of code:
--- a/edk2/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
+++ b/edk2/BaseTools/Source/C/LzmaCompress/Sdk/C/LzmaEnc.c
@@ -1919,11 +1919,13 @@ static SRes LzmaEnc_CodeOneBlock(CLzmaEnc *p, Bool useLimits, UInt32 maxPackSize
static SRes LzmaEnc_Alloc(CLzmaEnc *p, UInt32 keepWindowSize, ISzAlloc *alloc, ISzAlloc *allocBig)
{
UInt32 beforeSize = kNumOpts;
+ #ifdef COMPRESS_MF_MT
Bool btMode;
+ #endif
if (!RangeEnc_Alloc(&p->rc, alloc))
return SZ_ERROR_MEM;
- btMode = (p->matchFinderBase.btMode != 0);
#ifdef COMPRESS_MF_MT
+ btMode = (p->matchFinderBase.btMode != 0);
p->mtMode = (p->multiThread && !p->fastMode && btMode);
#endif
b) conditions being always true
A bunch of asserts trigger a warning in newer GCCs, essentially the
ASSERT macros in question are doing multiple things:
- testing whether the object is null
- testing some other condition on the object, like some state being
correct
but the objects are guaranteed to never be null from GCC PoV, so it
raises a fatal warning; as a workaround I just commented the asserts
out, but I guess what we should do is review whether any of the
ASSERT_LOCKED() users has a chance of getting a NULL pointer, and
either drop the NULL check or replace the macro with two.
--- a/edk2/MdeModulePkg/Core/Dxe/Event/Event.c
+++ b/edk2/MdeModulePkg/Core/Dxe/Event/Event.c
@@ -225,7 +225,7 @@ CoreNotifyEvent (
//
// Event database must be locked
//
- ASSERT_LOCKED (&gEventQueueLock);
+ //ASSERT_LOCKED (&gEventQueueLock);
//
// If the event is queued somewhere, remove it
I got this for a bunch of ASSERT_LOCKED(),
ASSERT_PROTOCOL_ALREADY_INSTALLED(), and ASSERT_VOLUME_LOCKED()
These are all issues in edk2, except the ASSERT_VOLUME_LOCKED() macro
issue which is the only issue in FatPkg and only there.
A cleaner workaround would be to make this warnings non-fatal for now
for this toolchain, but the code should also be fixed not to trigger
them. What's the best way to address this? Is there some bug tracker
I should report these issues at?
To try the resulting image, I just did:
qemu-system-arm -mtdblock \
../Build/BeagleBoard/DEBUG_ARMGCC/FV/BeagleBoard_EFI_flashboot.fd \
-nographic -M beagle
which sent this on the serial port:
UART Enabled
Magic delay to disable watchdog timers properly.
ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT /home/lool/git/edk2/edk2/edk2/EmbeddedPkg/Library/PrePiLib/PrePiLib.c(73): !EFI_ERROR (Status)
I didn't actually look into this issue yet.
I tried passing a barebox based SD image I had built earlier (see other
message) with -sd sd.img, but that didn't change the output.
--
Loïc Minier
Okay, minutes from the last meeting are posted to the wiki, and the
next meeting is scheduled for tomorrow, 3 hours earlier to accommodate
Jean in China (0600MDT, 0800EDT, 1200UTC). Email me if you want to
attend and I'll add you to the invite.
g.
On Thu, Jun 23, 2011 at 10:47 PM, Grant Likely
<grant.likely(a)secretlab.ca> wrote:
> Hi all,
>
> here are the notes from today's meeting. Please look over it an make
> sure all of it is okay by you for posting on the public wiki. If
> there is anything sensitive that should not be published, then let me
> know right away so that I can edit it out.
>
> Cheers,
> g.
>
>
>
> Meeting notes from ARM Boot Architecture Meeting, June 23, 2011
>
> https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-06-23
>
> == Attendees ==
>
> Loïc Minier
> Grant Likely
> Olivier Martin
> Jean-Christophe PLAGNIOL-VILLARD
> Jon Masters
> Andrew Pickard
>
>
> == Minutes ==
>
> * Need to think about what do we actually care about and write it down
> * Should be careful to consider non-Linux OSes
> * Want to get to a standard ARM platform
>
> * Time to market also an important consideration
>
>
> Notes on process:
> - We are not a standards body - need to be agile and try to base on
> existing standards
> - We need to be congnisent of other operating systems and other architectures
>
> Other Topics (maybe to put on the backburner):
> * How to we boot multiple CPUs of heterogeneous architectures
> * How does the boot architecture define how to start other CPUs, and
> other scenarii like kexec or virtualization? security / secure boot
> also impact the boot architecture subtly
>
> Licensing: GPL might be a problem for some specific pieces of code,
> e.g. touching CPU initialization
> * Specifications should remain as abstract of the licensing as
> possible though
> * Eveything we discuss should be public and avaiable free of charge
>
> Bootloader consolidation: we agree that there wont be consolidation on
> a single bootloader, instead a variety of bootloaders have to be
> supported
>
> Skeleton of boot architecture plan at
> https://wiki.linaro.org/OfficeofCTO/BootArchitecture/
> * Not clear whether we want to specify UI though
>
> What's the output?
> * Standard?
> * Wiki page? web site?
> * Need to work dynamically in the beginning, then freeze a version 1
> or something of the recommendations
> * Deliverable of some kind at the August Linaro meeting
>
> Dealing with legacy?
> * Could provide old-world boot media chainloading into new-world boot
> architecture media
> * Hard to implement security architecture in this mode
> * Don't care about legacy beyond a point (why care with product lifecycles?)
>
> Another output is one or more reference implementation(s) which can be
> deployed in production (be it UEFI, Barebox or whatever)
>
> Need to make sure we document the things which are NOT covered in our
> outputs/documents
>
> Should add definitions for terms; particuarly in the case of secure
> boot terminology.
>
> Need to handle booting secondary "bootloaders" like GRUB. Need to
> handle bits beyond just kernel, including initramfs, and other data
> images that need to be loaded by the bootloader.
>
>
> Power Management & PM handoff to the kernel.
>
> Plan agenda ahead of calls and assign time slots
>
> Suggest having a whole day/half day to advance (bootstrap!) this effort
>
> Topics raised after meeting:
> Privacy: The goal is to have everything open and public, but anybody
> can request for a conversation on the mailing list to be kept private
> in the interest of open communication.
>
> Minimal "run time" service type of interface for example to allow
> second stage bootloader to retrieve "files". However, this should not
> be massive overkill.
>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Wed, Jul 06, 2011, Olivier Martin wrote:
> UEFI Device Path
> ----------------
> UEFI has the concept of 'Device Path'. Every hardware devices supported by
> the UEFI firmware on the platform have a representation that defined the
> hardware path to access to this device and their properties.
I had a couple of questions on this:
* is the definition ARM specific or across all arches?
* is there a registry of GUID and allowed interfaces?
--
Loïc Minier
Hi,
one of the big issue on the device tree will be to update it at
runtime from the bootloader
As example the same board have 2 version with only one difference the
Main Oscilator. So to support it easly without having 2 DT will want
to update the default DT with the proper Osc value from the
bootlaoder.
But as the bootloader will not be able to be udpate in the futur on
production board, we will have to never change to format of the DT
otherwise the bootloder will not be able to work on never kernel.
This is one of issue that nearly all of the PowerPC kernel dev meet
ofen with the couple u-boot + kernel + DT
To avoid this we may use a script to update the DT and then specify
how we get the information from the bootloader. So in this case, the
script we will manage the dependency of the current format version of
the DT.
Best Regards,
J.
