- boot-architecture - lists.linaro.org

[MailServer Notification]Security Notification

by Administrator＠allwinnertech.com

WORM_MYDOOM.GEN has been detected,and Clean fail, quarantine entire message has been taken on 2011-12-5 14:11:47.

13 years, 7 months

1
0
0 0

Returned mail: see transcript for details

by joba320＠topflight-china.com

The original message was included as attachment

13 years, 7 months

1
0
0 0

[ACTIVITY] Meeting minutes from 20 October 2011

by Ilias Biris

https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-20 Please take note on the following: - there could be no call this week. Grant will confirm (as many are on ELCE this week) - Jean Christophe was to send to the list a proposal on what could be the reference platforms for the work related to server - in the meeting Jean Christophe mentioned ST and Marvel, but it would be best to have specific reference to any boards - Other actions are in the link: https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-20#action-poin… Best regards -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 8 months

3
2
0 0

Minutes from ELC-E/LinuxCon Europe meeting

by Loïc Minier

Hey These are the minutes for the meeting we had today at ELC-Europe/LinuxCon Europe. Please fix/amend as you see fit! Cheers, == Attendees == * Sascha Hauer * Olof Johansson * Grant Likely * Jean-Christophe * Deepak Saxena * Nicolas Pitre * Loïc Minier * Michael Frysinger == Random topics/agenda == * Barebox * Support in Linaro tools * Runtime configuration via DeviceTree * Boot menu * U-Boot * zload on ARM * runtime configuration via DeviceTree * UEFI * Tianocore * Support in Linaro tools * PXE implementation * Intel builds * pxelinux compatibility app * U-Boot (Barebox?) UEFI compatibility app * grub-efi porting * ACPI * Intel opensource implementation * ARM support in linux * Compiler * Specs * entry point protocol (Jean-Christophe) * kernel image format (Jean-Christophe) * secure boot (Grant) == Minutes == * Recent decision to focus on server rather than doing boot architecture at large * Constraints of supporting older OS on newer hardware * Calxeda focusing entirely on server, with A9 * Apple and Windows 8 expecting the same boot interface on all supported hardware * Apple not interesting case because vertically integrated * Short-term + long-term approach * Short-term: U-Boot * Long-term: Tianocore * Short-term pain points * uImage solved: use -1 as load address to use the default address * userspace should have nothing board specific, but should pass: * kernel * initrd * dtb -- actually that's board specific :-/ * ship all device trees * install one as the firmware during install * if we need to update the dt, install the one corresponding to the currently used device-tree compatible property (from /proc) * Replacing the DTB in the firmware might break the signature * Eventually want NOT to load DTB from userspace but only rely on the firmware one; DTB updates are provided via firmware upgrades * Can't demonstrate this easily with boards without flash in Linaro, but that's ok * u-boot would gain an eliloboot command which reads an elilo config file and runs it * Could have a GRUB backend for U-Boot before we get the EFI one * Should we target a single config file format for all bootloaders? * Too hard and so many concrete short-terms problems to solve * Can boot with GPT/EFI conventions on things which look like disks (e.g. SD/MMC) * Doesn't support MTD * GRUB ARM port * Direct port or on top of U-Boot * Need block access and console access * Probably larger work to port GRUB to U-Boot/Barebox than parsing grub.cfg from U-Boot * But would miss LVM/RAID/filesystems from grub * Why isn't GRUB logic in a library? * Wouldn't help anyway as U-Boot is GPLv2 only and GRUB is v3+ * U-Boot ABI is stable, Barebox has a POSIX ABI * Plan: * Add grubcfg command to parse grub.cfg * Port GRUB to Barebox or U-Boot * Move to grub-efi * ACPI * Is it going to open up? * How does Tianocore support ACPI today? What would it take to support on ARM * Enabling as many ACPI related pieces on ARM: ACPI BIOS, compiler, linux implementation -- Loïc Minier

13 years, 8 months

1
0
0 0

Boot architecture meeting at ELC-E

by Grant Likely

Hi all, For those of you attending ELC-E, I've got the "Quadrant" room booked from 1:30-5:00pm on Thursday Oct 27, 2011 for a face to face boot architecture meeting. g.

13 years, 8 months

1
1
0 0

[ACTIVITY] Meeting minutes from 20 October 2011

by Gerald BAEZA

Hello Two questions to rebound on last meeting minutes and "Working with ACPI and UEFI on ARM" message from Grant: - Since both ACPI and UEFI topics are joined in those recent discussions, does that mean that you don't want to consider one of them (UEFI) without the other one (ACPI) now ? There was some begin of discussion earlier this year and recent activities on UEFI so I am wondering if this will go on as this or be necessarily combined with ACPI. - About UEFI implementation: Tianocore (http://sourceforge.net/projects/tianocore/) seems to be the de facto open source UEFI implementation, as far as I understand. This one is delivered under BSD license (2-clause version, right ?) that would make many OEM happy, compare to the GPL license (U-Boot / Barebox) that they usually don't like for their bootloader. Can you confirm this and/or make it clear in the list started by Grant above ? Best regards, Gérald

13 years, 8 months

2
1
0 0

[ACTIVITY] Meeting minutes from 13Oct2011

by Ilias Biris

Hi folks https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-13 has the meeting minutes from yesterday's discussion. I have summarised below the highlights and Actions recorded in the etherpad. ----- = Highlights = We discussed the short term pain points, which should be possible to address via some engineering work - priorities were discussed here is where the discussion was left at the end of the meeting RANKING - Rob's top two: 1) zImage support in u-boot. 2) How does the OS change which kernel gets booted. - Olivier: 1) Get grub working with u-boot - get booting from a GPT partition 2) zImage update process 3) GPT support - Jean-Christophe: 1) Investigate and begin using FIT image format 2) multiplatform kernel images 3) signed images - kernel, initrd, dtb - Grant: 1) grub or grub config file on u-boot 2) Start using GPT support ----- = Actions from the meeting = - [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership - INPROGRESS - [CARRIEDOVER] Grant: Interact with Microsoft on ARM boot interface - there is some discussion more to say say by around mid October - [CARRIEDOVER] Grant to draft a position on secure boot, from the Linaro perspective, which can be reviewed by Linaro TSC: TODO - [CARRIEDOVER] Grant: Draft DTB recommended practices and getting the recommended practices document out and merged into a public tree by Linaro Connect (actually means the week before - as there are other events before the Connect) INPROGRESS, - [CARRIEDOVER] Grant: Select date & time for the next f2f meeting (Next F2F in ELCE in Prague (OCT 27) ?) - 1/2 day in the afternoon. TODO: send out public announcement. + Option 1: half-day meeting during ELCE, some folks won't make it - this is the plan to go for Final confirmation - [CARRIEDOVER] Will: Define SMP boot requirements - spin tables? Target Linaro Connect. No updates. - [CARRIEDOVER] Jean-Christophe to send a RFC to the list regarding the kernel image format and entry protocol: INPROGRESS - target this weekend. + Related to these previous APs: o [CARRIEDOVER] Jean Christophe: Investigate entry point protocol - related to multi-image support. Proposal needed. o [CARRIEDOVER] Jean-Christophe: Investigate kernel image format - Target Linaro Connect. The proposal here is similar to the one handling the previous action point (entry point protocol). - [CARRIEDOVER] Jean-Christophe to send some more details the list regarding the question : is it possible to put the initrd in the DT directly (similar to putting some firmware in the DT)? Proposal (JC) is to have 2 device trees, one very minimal with the boot arguments and another with the HW description. Issue: it is a requirement to be able to sign images passed in to the kernel; including the device tree. That makes it forbidden to modify the boot loader. - must support static DT. - TODO: sent proposal for how to sign device tree images. - [ACTION] Jean-Christophe to put an example of the boot sequence to the mailing list - Under review - waiting for approval to release. - [ACTION] Grant to post request for feedback for ACPI and UEFI - wants to have this checked from ACPI pov Best regards, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 9 months

5
11
0 0

Working with ACPI and UEFI on ARM

by Grant Likely

Hi everyone, We Linux developers seem to have a bit of a love-hate relationship with ACPI. On the plus side it provides the "standard platform" that we rely on to support the huge amount of hardware in the x86 ecosystem It is also the source of much pain due to firmware and DSDT tables that are either buggy or perform poorly. In the embedded space we've avoided ACPI entirely by standardizing on the Flattened Device Tree for hardware discovery. However there are some market segments and use cases where FDT doesn't solve the problems faced by OEMs, particularly when the hardware needs to support existing, unmodified OS images. Some OEMs are looking to implement ACPI on ARM since it is a solution they are already familiar with. It's becoming clear to me that in the near future, independent of whether or not we as the Linux community like it, we are going to start seeing ARM systems that are based on UEFI and ACPI. But, to quote h2g2, "Don't Panic." While there are many reasons as to why ACPI has been the source of pain, at least one of those factors is under our control. Historically, we as the Linux community have not been very good at participating or providing leadership as to what the future of the commodity hardware industry should look like, and the result is decisions that don't reflect our best interest, sheerly by omission. (There is an argument that standards setting hasn't been inclusive either, but I have reason to hope that is neither permanent nor insurmountable). So, given that we know that ARM ACPI machines will exist, and given that we still want to support Linux on these machines, I think it is absolutely appropriate to start getting involved with both the ACPI and UEFI standardization processes. I (on behalf of Linaro) will soon be joining the UEFI ARM Binding Sub Team (ABST), and we already have representatives from Canonical and Red Hat involved there. I'm also investigating the possibility of getting involved when the post-ACPI 5 process begins, probably sometime early next year. In the mean time, I want to start getting prepared by collecting feedback about the state of ACPI and UEFI now, and what changes we need to have for ACPI and UEFI to meet our needs in the Linux ecosystem. Reply to this email with your comments, and I'll start collating a list that I can discuss with the ACPI and UEFI folks. For your reference, the current versions of the ACPI and UEFI specs can be found here[1][2]. The ACPI spec is freely downloadable, but the UEFI spec requires a click-through license to read. [1] http://www.acpi.info/DOWNLOADS/ACPIspec40a.pdf [2] http://www.uefi.org/specs/ I'll kick things off with a few items from my personal list. This list will grow as I collect feedback and input from all of you. 1) Open Process - Currently the ACPI definition process is entirely confidential between the 5 APCI member companies (Microsoft, Intel, Toshiba, HP and Phoenix Technologies), and it remains so until the Final Draft is proposed to "Contributing Adopters" which is very late in the process. The current version of the spec is v4.0a[1]. ACPI 5 is currently under final review and will be released sometime late 2011, early 2012. For us to participate in the ACPI definition, we need to have an open processes so that open source Linux engineers can participate. 2) Improvements to compliance testing - Several Linux developers have been doing good work on BIOS/UEFI/ACPI testing and are able to identify many common bugs in firmware. This is of course valueable to the Linux ecosystem, but since it is discovering firmware bugs, it is most likely of high value to all HW and OS vendors. I would like to see much of the test work that we're currently doing to start filtering back into the tools that are routinely used by HW vendors as part of QA testing. Maybe even pushing for an industry wide suite of compliance tests. 3) Better rules (and testing) on SMM interrupts (or the ARM equivalent). HW vendors are using SMM to work around hardware bugs or perform system management tasks independently and transparently from the operating system. However, poorly implemented firmware will take the processor away from the OS for unbounded periods of time which is a deal breaker for any kind of real-time response in the OS. For ARM systems I would like to see an alternative to compete interruption of the OS when firmware needs to perform system management tasks. Cheers, g.

13 years, 9 months

2
1
0 0

GPT support in U-Boot

by Loïc Minier

Hi Just to confirm what Jean-Christophe said on today's meeting: U-Boot has disk/part_efi.c added in September 2008: Add support for CONFIG_EFI_PARTITION (GUID Partition Table) so it's indeed GPT support. It's currently being turned on for two NVIDIA Tegra2 boards: Harmony and Seaboard. (I didn't try it out.) One open question we had from last week's meeting is whether we can have backwards-compatible entries for e.g. boot ROMs in current SoCs as to use GPT for UEFI compatibility but with the relevant "PC" partitions entries as to allow booting. Cheers, -- Loïc Minier

13 years, 9 months

2
1
0 0

[ACTIVITY] Meeting minutes from 20111006 (this week's meeting)

by Ilias Biris

Meeting minutes are in: https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06 In particular note - the decision for the focus in a two-pronged approach for short and long term goals ( see https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06#Minutes for details, below is just a summary) + SHORT TERM pain points are summarized below - the list needs priorization and to be shown to the TSC so that suitable resources are assigned to do the work - support for Uboot - kernel update process/method - making every uboot behave the same way - how does uboot decide what kernel to load - does not have to be uboot specific fix, could be a script for uboot - single zImage able to boot on multiple SOCs - support for grub on uboot. - Port tianocore as a uboot app - uboot should understand which is the active partition - or should have a mechanism to tell the user which is the active partition + LONG TERM goals (strategic and design issues): there is a vendors' interest in standards process - which the Linux community has not been extremely involved with in the past. So we should work with the standards - get familiar with the existing standards For next week - ALL should download and get familiar with ACPI/UEFI specs (and open firmware ones - if not already familiar with those). Let me know if there is something missing or wrong in the minutes, I can update as indicated. Best regards, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 9 months

2
1
0 0

[wiki-uefi] How to port EDK2 to a new ARM Platform

by Olivier Martin

Hi all, I drafted a quick wikipage to explain how to port EDK2 (UEFI Open Source implementation) on a new ARM Platform : http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformP kg I am aware this wikipage could require some EDK2 knowledge but I will try to fill these gaps in the future by creating or referring to wikipages that explains some of the key EDK2 concepts. Feel free to directly send me an email if you want more explanations about a specific concept. That would help to define priorities. Olivier

13 years, 9 months

1
0
0 0

Boot architecture - Meeting minutes from 29 Oct 2011

by Ilias Biris

https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-09-29 Please note the wiki page for the next meeting is set : https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-10-06 Summary of the action points: - [CARRIEDOVER] Grant to followup the status of Linaro UEFI membership - [CARRIEDOVER] David Rusling: - Linaro UEFI membership - target Linaro Connect - [CARRIEDOVER] Grant to draft a position on secure boot, from the Linaro perspective, which can be reviewed by Linaro TSC - [CARRIEDOVER] <tba> Interact with Microsoft on ARM boot interface - there is some discussion more to say say by around mid October - [CARRIEDOVER] Grant: Draft DTB recommended practices and getting the recommended practices document out and merged into a public tree by Linaro Connect (actually means the week before - as there are other events before the Connect) INPROGRESS, - [CARRIEDOVER] Grant: Select date & time for the next f2f meeting (Next F2F in ELCE in Prague (OCT 26-28) ?) Option 1: half-day meeting during ELCE, some folks won't make it - this is the plan to go for Final confirmation - [CARRIEDOVER] Will: Define SMP boot requirements - spin tables? Target Linaro Connect. No updates. - [ACTION] Olivier to send the wiki link with the documentation on how to port UEFI to new platforms - [ACTION] Jean-Christophe to send a RFC to the list regarding the kernel image format and entry protocol - [ACTION] Jean-Christophe to send some more details the list regarding the question : is it possible to put the initrd in the DT directly (similar to putting some firmware in the DT)? Proposal (JC) is to have 2 device trees, one very minimal with the boot arguments and another with the HW description. - [ACTION] Jean-Christophe to put an example of the boot sequence to the mailing list Best, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 9 months

3
3
0 0

Meeting today - AP list on etherpad

by Ilias Biris

Hi folks Etherpad: http://etherpad.osuosl.org/arm-boot-architecture-meeting-notes I have updated this etherpad with the action points and agenda for today. Grant, since you will be unable to join, I hope you could give an update for the actions under your name, I have grouped the action points under your name at the top of the AP list. Agenda for today: * Action items review * Status updates on DT and UEFI work * Implementation on other bootloader than the ARM one * HW platform status * Android + UEFI status Anything else to add? (PLEASE NOTE: As usual, I will be using the etherpad to update the wiki meeting minutes which is your best reference location to check what was discussed during any of the meetings.) Cheers! -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

13 years, 9 months

1
0
0 0

UEFI Runtime Service Support?

by Cohen, Eugene

Is there already support for UEFI Runtime Services in the kernel? If not is this already planned for Linaro? UEFI Runtime Services are necessary for exchanging NVRAM values with the UEFI environment. These NVRAM values provide the foundation for UEFI spec'ed functionality ranging from boot entry management to key management for secure boot. Thanks, Eugene

13 years, 9 months

2
1
0 0

[ACTIVITY] Meeting minutes from 22 Sep 2011

by Ilias Biris

https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-09-22 Please note the new action points at the bottom of the page. Send your status updates to the list regarding: - DT and UEFI work - Implementation on other bootloader than the ARM one - HW platform status In addition there was no time to discuss during the last meeting the Android + UEFI status. Could someone summarize the status there for the rest of the list? Thanks, ************************************* Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris *************************************

13 years, 9 months

1
0
0 0

EDK2 git mirror(s)

by Loïc Minier

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.git git://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

13 years, 9 months

2
4
0 0

Next Face to Face meeting

by Grant Likely

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.

13 years, 9 months

4
4
0 0

Device Tree Resources

by Cohen, Eugene

[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

13 years, 9 months

2
2
0 0

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

13 years, 10 months

4
6
0 0

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

13 years, 10 months

9
34
0 0

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

13 years, 10 months

1
0
0 0

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.

13 years, 10 months

1
0
0 0

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.

13 years, 11 months

2
1
0 0

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.

13 years, 11 months

3
4
0 0

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.

13 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture