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.
HI,
Barebox flow basecly the linux kernel architecture
We use as linux a file system (devfs) to manage the device
such as NOR, NAND, SPI Flash, Memory, phy, SD etc...
As have a pseudo POSIX API to implement command application
such as ls, rm, mount, boot etc...
You can see barebox as "Small Linux like" bootlader
To extend it's fonctionality at runtime we use modules (same as in the
kernel).
We do not support yet ABI Application
With start from anywhere and they relocate our self at the right
addres in DDR after have init the soc and the board. Which include the
DDR.
After we use the initcall to init:
1: the core
Usualy clock and pio
2: console
uart
3: core device
using the device / driver model of the kernel
4: Filesystem
register filesytem
5: device
using the device / driver model of the kernel
as Frambuffer, and other
Then we mount a ramfs and devfs and execute a script /env/bin/init
all the boot sequence is manage by script based on Hush from busybox
we have a default scripting implementation to boot but you are free to
manage it how you want
we an boot from any media and from tftp, nfs with uImage or zImage or
Image
You can manage your boot loader configuration and boot from via a Menu
which can be manage in C or in shell
Over uart and soon over Framebuffer
Best Regards,
J.
I have tried tonight on my personal computer with the latest revision of Tianocore (rev1199).
Actually, there is two versions of the BeagleBoard UFEI upstream. There is the original version.
And the version we are working on which reuses most of the framework we have introduces for our development platform to avoid code duplication and flexibilty.
This is the version I have tested, to build it you must use './build-next.sh' instead of './build.sh'
Unfortunately, there are two patches you will need to apply. These patches are pending and wait to be approved by the maintainers of their respective packages.
One of the patch in the source tree and the other one is attached to this email.
Configuration:
--------------
- ARM GCC CodeSourcery arm-none-eabi-2010q3
- qEmu-linaro:
commit 2d601b5fb663bb2876b85bec255d73bba01e38e6
Author: Peter Maydell <peter.maydell(a)linaro.org>
Date: Wed Jun 15 15:08:48 2011 +0000
- Tianocore EDK2: revision 11999
Build process:
--------------
svn co https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2 edk2 --username guest -r 11999
cd edk2
svn co https://edk2-fatdriver2.svn.sourceforge.net/svnroot/edk2-fatdriver2/trunk/F… FatPkg --username guest
patch -p1 < ArmPlatformPkg/Documentation/patches/BaseTools-Pending-Patches.patch
patch -p1 < 0001-MdeModulePkg-DxeCore-Fix-the-loop-to-find-the-highes.patch
cd BeagleBoardPkg
I add to fix 2 easy warnings to make it build
./build-next.sh RELEASE
To test on qEmu:
----------------
./qemu-system-arm -M beagle -mtdblock ~/dev/edk2/Build/BeagleBoard/RELEASE_ARMGCC/FV/BeagleBoard_EFI_flashboot.fd -serial stdio -sd ~/dev/linaro-image-tools-0.4.8/beagle_sd.img
Log: starting an ATAG kernel from UEFI (after editing its filepath):
------------------------------------------------------------------------------
VNC server running on `127.0.0.1:5900'
The default boot selection will start in 8 seconds
[1] Linux from SD
[2] EBL
[3] Boot Manager
Start: 1
ERROR: Did not find Linux kernel.
[1] Linux from SD
[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
Update entry: 1
File path of the EFI Application or the kernel: zImage-atag
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
[2] EBL
[3] Boot Manager
Start: 1
PEI 160 ms
DXE 622 ms
BDS 22922 ms
BDS 1418980260529 ms
Total Time = 1418980284234 ms
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Linux version 2.6.38.7 (olivier@olivier-laptop) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51) ) #1 Sun Jul 3 15:42:26 BST 2011
[ 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] Reserving 33554432 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: 0x10000
[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[ 0.000000] Reprogramming SDRC clock to 332000000 Hz
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 24320
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 96MB = 96MB total
(...)
Log: Boot from a FDT kernel added to the Boot Menu:
-----------------------------------------------------------------
UEFI firmware built at 23:09:40 on Jul 6 2011
omap_badwidth_read32: 32-bit register 0x00000000
The default boot selection will start in 8 seconds
[1] Linux from SD
[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: 1
[1] SemihostFs (0 MB)
[2] boot (51 MB)
[3] VenHw(4D00EF14-C4E0-426B-81B7-30A00A14AAD6)
Select the Boot Device: 2
File path of the EFI Application or the kernel: zImage-fdt
Has FDT support? [y/n] y
Arguments to pass to the binary:
Description for this new Entry: FDT Kernel 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
[2] FDT Kernel from SD
[3] EBL
[4] Boot Manager
Start: 2
PEI 149 ms
DXE 609 ms
BDS 222 ms
Total Time = 981 ms
omap2_inth_read: Bad register 0x00000020
[ 0.000000] Linux version 2.6.39.1 (cosgor01@cam-vm-424) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51) ) #2 SMP Thu Jun 30 18:55:24 BST 2011
[ 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, model: TI OMAP3 BeagleBoard
[ 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: 0x10000
[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[ 0.000000] Reprogramming SDRC clock to 332000000 Hz
[ 0.000000] PERCPU: Embedded 7 pages/cpu @c0cc7000 s8160 r8192 d12320 u32768
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200n8
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
(...)
-- 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.
To be frank, I spent most of my time since the last meeting to get Tianocore
working on qEmu.
Unfortunately, I have not been able to reproduce a consistent stable
firmware on qEmu.
It seems to work fine on my computer at home. I can boot Linux with ATAG
support or FDT support from UEFI on qEmu.
Booting UEFI from NOR Flash works. I also successfully 'hacked' a SD card
created with the linaro-media-create to replace u-boot by UEFI to get the
following boot stage ROM -> x-loader -> UEFI -> Linux.
I am using ARM GCC with the latest qEmu-linaro tree.
But on my machines at work with the same configuration, qEmu crashes during
the UEFI boot up with a 'Segmentation Fault'. It is the first time I work
with qEmu, I do not know if an 'Exception Fault' could be expected in case
of bug in the emulated binary or a problem in qEmu itself. I have not enough
element yet to report the issue to the qEmu team.
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
Olivier
I forgot to mention but Tianocore and other UEFI Open Source projects have implemented shells for UEFI firmwares.
Some people are even working on porting Python to UEFI.
Feel free to ask questions or clarifications about this overview.
Mainly if you had thoughts about the way UEFI works which does not correspond to the big picture I gave.
Olivier
-----Original Message-----
From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Olivier Martin
Sent: 06 July 2011 20:29
To: boot-architecture(a)lists.linaro.org
Subject: UEFI Overview
This email describes the way UEFI Tianocore implementation works. I limit
the scope to the UEFI drivers and the 'boot manager'. The implementation and
the platform specific bits are skipped.
Boot sequence:
--------------
1) After the platform modules (part of the PI (Platform Initialization)
phase) have finished the bringup initialization, the DXE (Driver Execution
Environment) Core is loaded.
2) The DXE core scans the different firmwares available on the platform and
calls the entrypoint of all the drivers that are expected to start (either
they request to be initialized during this sequence or they have their
dependencies solved).
Following the recommendation of the UEFI specification, the drivers should
do not touch the hardware controllers during this phase. They should only
declares their protocols (UEFI name for 'interfaces') to the DXE core.
3) Once all the drivers are dispatched, the DXE core passes its control to
the driver that exports the Boot Device Selection (BDS) interface.
This BDS driver should implement the 'Boot Manager' of the UEFI firmware
defined by the Chapter 3 of the UEFI spec.
This chapter defines non volatile variables that define among other things:
- The Boot Device entries ('Boot###' variables) (Name, location of the OS
loader, arguments) and their order ('BootOrder' variable)
- The devices responsible for the Console Input/Output
- The 'Timeout' before the BDS starts the default boot selection
- if defined, 'BootNext' defines the OS loader/EFI application to start the
next boot only (the variable is erased at the next boot)
4) Following the non variables values, the BDS will either automatically
starts the boot device (case 'BootNext' is defined or 'TimeOut' reached 0)
or displays the boot menu (with the Boot Device entries defined by
'Boot###' listed in the order defined by 'BootOrder'). Then the user chooses
in this menu which entry he/she wants to start.
5) With our implementation of the Boot Manager, we currently defines 3 types
of boot devices. The boot device can be either an EFI application (eg: an OS
loader) or a ATAG or FDT Linux kernel image. In case the BDS starts a Linux
kernel images, our BDS will automatically fills the required ATAG or loads
the Device Tree blob.
Note: One of our partner has been asking us to provide a reference EFI
Application to boot Linux. It is expecting some platforms will have their
own BDS and will use an EFI application to load the Linux kernel.
Actually, we are waiting the output of the Boot Architecture 'forum' to
provide such 'reference' EFI application.
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.
Some examples:
# Device path for a kernel on PCI SATA Hard Drive:
PciRoot(0)/Pci(0|0)/Pci(0|0)/Pci(5|0)/Pci(0|0)/Sata(0,0,0)/HD(2,MBR,0x000767
30,0x1F21BF,0x1F21BF)\boot\zImage
- PciRoot(0) define the first PCI Root complex.
- PCI(5|0) = PCI controller with Device = 5 and Function = 0
- HD(Partition,Type,Signature,Start, Size) = hard disk partition
- \boot\zImage : filepath on the partition
# Device path for a Linux kernel on the first partition of the SD card:
VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0
)/zImage
- VenHw(guid) is used when the device path node is not defined by the UEFI
specification (generally memory mapped controllers)
The Device Path allows to describe hardware devices or media even if they
have been initialized. When hardware drivers are started they can declare
the device path(s) of the hardware they support.
The advantage is if we do not need some specific hardwares during the UEFI
boot up, we could skip their initialization in UEFI.
This device path complexity can be hidden by the Boot Manager. We have
implemented our own interactive boot menu to help us to define the boot
devices.
_______________________________________________
boot-architecture mailing list
boot-architecture(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/boot-architecture
-- 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.
This email describes the way UEFI Tianocore implementation works. I limit
the scope to the UEFI drivers and the 'boot manager'. The implementation and
the platform specific bits are skipped.
Boot sequence:
--------------
1) After the platform modules (part of the PI (Platform Initialization)
phase) have finished the bringup initialization, the DXE (Driver Execution
Environment) Core is loaded.
2) The DXE core scans the different firmwares available on the platform and
calls the entrypoint of all the drivers that are expected to start (either
they request to be initialized during this sequence or they have their
dependencies solved).
Following the recommendation of the UEFI specification, the drivers should
do not touch the hardware controllers during this phase. They should only
declares their protocols (UEFI name for 'interfaces') to the DXE core.
3) Once all the drivers are dispatched, the DXE core passes its control to
the driver that exports the Boot Device Selection (BDS) interface.
This BDS driver should implement the 'Boot Manager' of the UEFI firmware
defined by the Chapter 3 of the UEFI spec.
This chapter defines non volatile variables that define among other things:
- The Boot Device entries ('Boot###' variables) (Name, location of the OS
loader, arguments) and their order ('BootOrder' variable)
- The devices responsible for the Console Input/Output
- The 'Timeout' before the BDS starts the default boot selection
- if defined, 'BootNext' defines the OS loader/EFI application to start the
next boot only (the variable is erased at the next boot)
4) Following the non variables values, the BDS will either automatically
starts the boot device (case 'BootNext' is defined or 'TimeOut' reached 0)
or displays the boot menu (with the Boot Device entries defined by
'Boot###' listed in the order defined by 'BootOrder'). Then the user chooses
in this menu which entry he/she wants to start.
5) With our implementation of the Boot Manager, we currently defines 3 types
of boot devices. The boot device can be either an EFI application (eg: an OS
loader) or a ATAG or FDT Linux kernel image. In case the BDS starts a Linux
kernel images, our BDS will automatically fills the required ATAG or loads
the Device Tree blob.
Note: One of our partner has been asking us to provide a reference EFI
Application to boot Linux. It is expecting some platforms will have their
own BDS and will use an EFI application to load the Linux kernel.
Actually, we are waiting the output of the Boot Architecture 'forum' to
provide such 'reference' EFI application.
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.
Some examples:
# Device path for a kernel on PCI SATA Hard Drive:
PciRoot(0)/Pci(0|0)/Pci(0|0)/Pci(5|0)/Pci(0|0)/Sata(0,0,0)/HD(2,MBR,0x000767
30,0x1F21BF,0x1F21BF)\boot\zImage
- PciRoot(0) define the first PCI Root complex.
- PCI(5|0) = PCI controller with Device = 5 and Function = 0
- HD(Partition,Type,Signature,Start, Size) = hard disk partition
- \boot\zImage : filepath on the partition
# Device path for a Linux kernel on the first partition of the SD card:
VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0
)/zImage
- VenHw(guid) is used when the device path node is not defined by the UEFI
specification (generally memory mapped controllers)
The Device Path allows to describe hardware devices or media even if they
have been initialized. When hardware drivers are started they can declare
the device path(s) of the hardware they support.
The advantage is if we do not need some specific hardwares during the UEFI
boot up, we could skip their initialization in UEFI.
This device path complexity can be hidden by the Boot Manager. We have
implemented our own interactive boot menu to help us to define the boot
devices.
Hey
QEMU is really handy to try out OMAP and Versatile Express boot stuff;
the Linaro QEMU version has patches (progressively being upstreamed)
for OMAP support and allows emulating vexpress, overo, beaglexm and
beagle boards which is a good collection already. It's based of a
modern QEMU commit and contains plenty of good fixes (all on their way
to mainline).
Get a tarball from:
https://launchpad.net/qemu-linaro
Source code at:
http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=summarygit://git.linaro.org/qemu/qemu-linaro.git
(This is like a regular qemu git tree or tarball; usual QEMU
documentation applies.)
Binaries are available in Ubuntu and backports are in the
linaro-maintainers/tools PPA.
Some QEMU HowTos are hosted on the Linaro wiki, but they are a bit
specific to Linaro images and tools to manipulate them. Basically you
can run a beagle xm SD image with:
qemu-system-arm -M beaglexm -sd your.img
(You might want to throw the serial line output directly on your
terminal or disable graphics or various other things.)
For vexpress, you can only boot by passing a kernel or ELF image to
QEMU:
qemu-system-arm -M vexpress-a9 -kernel u-boot.bin
Cheers,
--
Loïc Minier
Hey
(followup to today's call0
This is an attempt to write down an use case which expresses the
concept of "modules" that the boot architecture would cover. I don't
really like the name modules, if you have better names please propose!
So here's the writeup; this is completely fictional, and is just meant
to illustrate modules.
Here are the steps that could be taken to load a plain linux kernel:
a) your SoC starts up in a SoC-specific way
b) the boot architecture mandates how vmlinuz is loaded and started
c) control is passed to linux
d) profit!1!
in a very dumbed down version of our boot architecture, we could say
for b):
a file named "bootme" is loaded from the first FAT partition of the
SD card; its type is detected and if it's a linux kernel, it's
started with a device tree blob provided by the firmware to the
kernel
Good:
* easy to install or update a kernel by replacing the vmlinuz file
Bad:
* miss way to pass kernel cmdline
* miss way to pass (optional) initrd
* miss way to load/replace the DT
all of the above bad points could be alleviated by pushing this data in
the vmlinuz file, but it's not as practical as the modern linux systems
we know.
Another approach would be to put U-Boot or Barebox in the "bootme"
file, but then U-Boot or Barebox would have to decide how to load the
kernel and implement drivers for the SD card and this wouldn't be a
SoC-agnostic boot image anymore.
So the only possible approach I see in this case is to put a general
purpose ARM bootloader in the "bootme" file which will talk to firmware
to load additional files from the SD card (thanks to non-resident
support from the firmware); this would then go away once linux runs.
Now to "modules": instead of defining b) as just loading a single
"bootme" file, we'd define a config file which lists what to load (e.g.
something like grub.cfg/menu.lst) so that we could pass combinations
such as:
- vmlinuz + initrd + DT
- vmlinuz + DT
- Xen + DT + the OS modules it should load (linux and initrd)
it would also allow setting things like kernel cmdline or other OS
specific things.
Maybe I misunderstood Grant's idea, but it felt like he was mandating a
single payload from being loaded and just deferring to that payload. I
feel that if we go that route, we've specified too little to be able to
construct useful images and have deffered to an implementation specific
architecture (even if it could support multiple SoCs).
So my conclusion is that we should specify:
* either a single payload to start which would be something like a
generic ARM bootloader talking to the firmware to load the other bits
(e.g. via UEFI), but then also how it loads the next things
* or a config file which points at "modules" (by lack of a better name)
to load; these will get loaded by SoC specific code (likely an UEFI
implementation)
the main difference is whether we specify how a generic ARM bootloader
is loaded and then defer to it to decide how to load the OS, or whether
we specify OS-ish bits to load, and leave the loading to the
implementation.
Does that make any sense?
Cheers,
--
Loïc Minier
On Thu, Jun 23, 2011 at 5:25 AM, Olivier Martin <olivier.martin(a)arm.com> wrote:
> Thanks Nicolas for the link. You right the zImage has a signature. I read
> again the code I wrote and it is the signature for the non compressed image
> I have not found.
> My function was able to detect uImage and zImage but I had to assume if it
> is not one of these formats the image was a non-compressed image. Which it
> is ok as far as we have got only 3 formats, but that could cause trouble for
> any additional formats that would have some requirements from the boot
> loader.
>
>
> FYI, our UEFI implementation already supports ATAG (and partially DT). We
> can pass a DT to the kernel but we have not implemented yet the update of
> the tree in the firmware; for example to pass new arguments to the kernel.
> Again same argument as the binary format, if in the future a new format
> incompatible with the DT format is introduced to answer some limitations of
> the Flat Device Tree at this time; should the ARM boot 'standardization' be
> rewriting again and break the legacy mechanism ?
>
>
> I had a look again to this page:
> https://wiki.linaro.org/OfficeofCTO/BootArchitecture
> It seems the current concern is more about the firmware itself than the
> interface between the OS loader and the kernel. I guess this Blue Print has
> been created to solve the issues of the boot fragmentation in the ARM world.
> I suppose the idea is to introduce some requirements for booting ARM
> platforms.
> But should we only limit our view to the requirements of booting Linux 3.0
> (zImage? and Device Tree). Could we also think about defining some
> 'standards' in the interface between the OS Loader and the Linux kernel to
> leave some flexibility for any future technology that involves the boot
> firmware to initialize the platform for the Linux kernel.
I think in general, yes we should constrain our view to 3.0+. That
doesn't preclude firmware from supporting what it already supports.
Indeed it would be crazy to ask firmware projects to remove things
that it currently supports. Rather, I think that the process of
creating a standard implementable by any firmware should be /focused/
on new kernels since we cannot change the stuff that is already
deployed anyway.
> As I suggested in my first email, defining a signature (binary format:zImage
> + machine type:DT) could be a way to define our current requirements and
> leave some place for any future requirements
I've added signature/CRC/identification as a topic to the boot
architecture page.
g.
