boot-architecture August 2011

boot-architecture@lists.linaro.org

16 participants
7 discussions

Regarding a git Repository for Vendors supporting Uefi Boot Loader

by Girish K S

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

14 years, 11 months

ARM processor mode, kernel startup, Hyp / secure state

by Ian Jackson

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

14 years, 12 months

Weekly meeting - resetting for September

by Ilias Biris

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

14 years, 12 months

RE: Booting Linux from UEFI on Beagleboard Qemu

by Alan Chuang

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.

15 years

RE: Booting Linux from UEFI on Beagleboard Qemu

by Alan Chuang

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.

15 years

Booting Linux from UEFI on Beagleboard Qemu

by Alan Chuang

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.

15 years

Boot Architecture - the plan from here

by Grant Likely

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.

15 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture August 2011