- boot-architecture - lists.linaro.org

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.

14 years, 4 months

1
0
0 0

ARM Boot Architecture Meeting on Thursday, July 28

by Grant Likely

Hi all, Just a reminder, we actually have a boot architecture meeting scheduled for today (I don't have to cancel, yay!). 3:00pm BST, 10:00am EDT, 8:00am MDT. I hope the calendar entries are showing up correctly. The one item I really want to talk about is the agenda for the boot architecture summit at Linaro Connect next week. Here's the link to the meeting minutes page[1] and the draft schedule[2]. [1] https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-07-28 [2] https://wiki.linaro.org/Events/LinaroConnectQ3.11/Magdelene/BootArchitecture g.

14 years, 5 months

3
2
0 0

SMP Boot

by Grant Likely

Hi folks, SMP boot mechanism was a topic in our previous boot architecture meeting[1], and it came up that ePAPR talks about how the problem is solved on PowerPC. You can find it in section 5.5 of the following link[2]: [1] https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-07-07 [2] https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

14 years, 5 months

1
0
0 0

Re: UEFI on BeagleBoard qEmu

by Loïc Minier

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

14 years, 5 months

2
7
0 0

Re: Minutes from Boot Architecture meeting today.

by Grant Likely

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.

14 years, 5 months

4
4
0 0

Re: UEFI Overview

by Loïc Minier

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

14 years, 6 months

3
2
0 0

Fwd: Notes on running barebox under QEMU for OMAP

by Loïc Minier

(Attached) -- Loïc Minier

14 years, 6 months

1
0
0 0

Device Tree Update

by Jean-Christophe PLAGNIOL-VILLARD

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.

14 years, 6 months

1
0
0 0

Barebox Overview

by Jean-Christophe PLAGNIOL-VILLARD

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.

14 years, 6 months

1
0
0 0

RE: UEFI on BeagleBoard qEmu

by Olivier Martin

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.

14 years, 6 months

1
0
0 0

UEFI on BeagleBoard qEmu

by Olivier Martin

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

14 years, 6 months

1
0
0 0

RE: UEFI Overview

by Olivier Martin

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.

14 years, 6 months

1
0
0 0

UEFI Overview

by Olivier Martin

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.

14 years, 6 months

1
0
0 0

Linaro QEMU branch

by Loïc Minier

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=summary git://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

14 years, 6 months

1
0
0 0

Loading a variable number of "modules"

by 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

14 years, 6 months

4
3
0 0

Re: Linux Boot Architecture coordination meeting

by Grant Likely

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.

14 years, 6 months

1
0
0 0

RE: Linux Boot Architecture coordination meeting

by Nicolas Pitre

On Tue, 21 Jun 2011, Olivier Martin wrote: > Thanks Grant for adding me to the list, > To introduce myself, I am part of the UEFI team at ARM Ltd. I am also the > maintainer of the ARM Packages in the Open Source implementation of UEFI > (http://www.tianocore.org/ ). > > Maybe an issue this "ARM Boot Architecture" topic should solve is the > interface between the boot loader and the Linux kernel binary. > > Recently, I was trying to extend our ARM UEFI boot loader to detect the type > of the Linux kernel binary: > - zImage, non-compressed Image, uImage format > - ATAG or FDT support > ... to start any kernel by passing the correct parameters and jump to the > right offset. > > Unfortunately, it was not as easy as it should be. In fact it does not look > to be possible right now. Defining a signature (eg: kernel binary format + > machine type) in the kernel binary would make the task easier. Some of the > formats have a signature (eg: u-boot) but not all the formats. The zImage format has a signature too. I documented it here a _long_ time ago: http://lists.arm.linux.org.uk/lurker/message/20020226.165754.4c7e6539.en.ht… Of course some things have changed since then. For a while now, the zImage is fully position independent. I can be loaded anywhere in memory and branched directly to it as it takes care of relocating itself when needed. Therefore the load address at offset 0x28 is now always zero, except when the zImage is linked to be executed directly from flash memory (but I doubt that case is relevant to UEFI). For that matter, the uImage format is broken. It insists on absolute addresses in its header. This is therefore not a good format if we want to support multiple SoCs with the same kernel binary, as some of them have their physical RAM at different addresses. You may want to support it if you want, but it is likely not to be suitable anymore in the future. Hence having the ability to boot a zImage directly is likely to be the most flexible option. > Actually, if we try to boot a Linux kernel with the wrong settings then the > kernel would crash or raise an error. And it is not be possible to recover > from this state without restarting the platform. What kind of parameters do you have in mind? > Making these information available to the boot loader (u-boot, uefi, etc) > would also make easier the migration from the legacy ATAG to the Flat Device > Tree (FDT) support. How would it make that transition easier? The link between those issues is not obvious to me. With regard to ATAGs, I don't think UEFI should bother with them. If we really want to move to device tree, and it seems we do, then ATAGs should be left behind. We do have a compatibility layer going into zImage to convert ATAGs into DT properties at run time to allow booting a DT kernel on legacy bootloaders. Adding ATAg support to UEFI might impair the move to DT in the kernel by making it a lower priority. Nicolas

14 years, 6 months

3
2
0 0

Re: Linux Boot Architecture coordination meeting

by Jean-Christophe PLAGNIOL-VILLARD

On 18:01 Tue 21 Jun , Olivier Martin wrote: > Thanks Grant for adding me to the list, > To introduce myself, I am part of the UEFI team at ARM Ltd. I am also the > maintainer of the ARM Packages in the Open Source implementation of UEFI > (http://www.tianocore.org/ ). > > Maybe an issue this "ARM Boot Architecture" topic should solve is the > interface between the boot loader and the Linux kernel binary. > > Recently, I was trying to extend our ARM UEFI boot loader to detect the type > of the Linux kernel binary: > - zImage, non-compressed Image, uImage format > - ATAG or FDT support > ... to start any kernel by passing the correct parameters and jump to the > right offset. > > Unfortunately, it was not as easy as it should be. In fact it does not look > to be possible right now. Defining a signature (eg: kernel binary format + > machine type) in the kernel binary would make the task easier. Some of the > formats have a signature (eg: u-boot) but not all the formats. > > Actually, if we try to boot a Linux kernel with the wrong settings then the > kernel would crash or raise an error. And it is not be possible to recover > from this state without restarting the platform. > Making these information available to the boot loader (u-boot, uefi, etc) > would also make easier the migration from the legacy ATAG to the Flat Device > Tree (FDT) support. in Barebox we use the same as u-boot but we can boot a zImage directly > > > BTW, Thursday 15:00UTC is fine for me. 15:00UTC is a bit late for I as I live now in China Shanghai I'd prefer 14:00UTC as if the call take 2h it will be already midnight here Best Regards, J.

14 years, 6 months

1
0
0 0

Linux Boot Architecture coordination meeting

by Grant Likely

Hi all, Following up from the decisions made at UDS last month[1], we need to organize a boot architecture coordination meeting. Currently the proposal is to hold a meeting either as part of the Linaro platform sprint[2] in the week on August 1-5, 2011, or in the weekend between the platform sprint and the ARM Partners Meeting the week after. Personally, my preference is to schedule a full day meeting on Friday, Aug 5 as part of the platform sprint, but I'd like to get some feedback before settling on that date. [1] https://blueprints.launchpad.net/linaro/+spec/linaro-kernel-o-bootarchitect… [2] https://wiki.linaro.org/Events/2011-08-LDS Right now I'm in the process of organizing the information and topics which were discussed during UDS and get them out onto the Linaro wiki. Expect to see some early draft documents showing up late this week or early next week. After that, I'm going to be soliciting feedback and help to make them reflect the priorities and requirements that Linux vendors, users and developers have for the boot architecture. By the time the Linaro platform sprint rolls around, we should have a solid set of documents covering both requirements and a draft boot architecture. At the boot architecture meeting, my goal is to first come to agreement on the general approach and draft design, second to make decisions about how the boot architecture fits in with existing technologies like Fastboot, UEFI and U-Boot, and third to kick off work on implementation and detailed design. In order to be successful, we need to make sure the appropriate people are involved. I've started by sending this email to the people who I know are interested in the topic, but I know I've missed folks. I'm also going to cc: the boot-architecture(a)lists.linaro.org[3] for any boot architecture traffic. Please let me know if there is anybody else that I should be inviting. In addition to the meeting in August, I'm considering a regular boot architecture conference call as part of the document drafting process, so I'd like to put together a list of critical stakeholders by the end of next week. [3] http://lists.linaro.org/mailman/listinfo/boot-architecture -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

14 years, 6 months

3
4
0 0

Re: Linux Boot Architecture coordination meeting

by Grant Likely

On Mon, Jun 13, 2011 at 7:56 AM, Steve McIntyre <steve.mcintyre(a)linaro.org> wrote: > On Mon, Jun 13, 2011 at 07:51:05AM -0600, Grant Likely wrote: >>Hi everyone, >> >>Note: I'm sending this directly to everyone on my 'interested >>individuals' list, but future traffic will only get sent to the >>boot-architecture(a)lists.linaro.org mailing list. If you're not >>already, and would like to stay in the loop, please subscribe to the >>list. >> >>Given the feedback I've received so far, I'm going to tentatively >>schedule the meeting for Friday, July 5, at the end of the Linaro > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^August, surely? Gah! yes. Friday, August 5th. Thanks for catching that. g.

14 years, 6 months

1
0
0 0

Barebox

by Jean-Christophe PLAGNIOL-VILLARD

Hi all, I've like to open the discussion about barebox What is Barebox? Barebox is a fork of U-Boot which was named before the elce 2009 U-Boot-V2 with the target to have a modern internal Implememtation derived from the Linux kernel and user friendly interface The current design of barebox is very near from the kernel as example on AT91 I've update the current API to be as near as possible as the one in the kernel so it's now really easy to port a new board and on contrary of U-Boot we can have the multy instance of the drivers. I'm start to push the SH with the same idea As example have the prompt on all uart at the same time or be able to use them independently. We also support FastBoot, Framebuffer, USB ohci & Ehci, network, nor, nandflash, dfu, usb ethernet (very usefull for soc without net device), Menu Framework, etc... inprogress mmc, spi flash DFU for Device Firmware Upgrade is very use full to update device from usb device from a PC so you will have an generic updater from the bootloader The Menu Framework will help you to create friendly interface to manage the booloader via key specially on device without keyboard as cellphone, STB etc... We have also a true shell support with scripting so it's very easy to create complex command via sheel script and also complex boot sequence We have modules support as the kernel which allow to load code based on the need and speed up the boot but also allow to update the bootloader functionnality in the feature etc... Best Regards, J.

15 years, 4 months

2
3
0 0

Re: ARM Boot Architecture working group idea

by Grant Likely

Follow up to the initial poll for interest on an ARM Boot Architecture working group (You can read the initial posting below for those people I've just added to the to: list). Linaro has graciously offered to host a mailing list and provide a conference bridge for meetings. You can subscribe to the mailing list here: http://lists.linaro.org/mailman/listinfo/boot-architecture I'm ready to kick off the first phase of the working group, which is to start collecting requirements and to define the boot use-cases that the working group will focus on solving (for example, one use-case is supporting a generic ARM distro on netbooks and tablets). There is a start to capturing requirements on the wiki page[1] and some discussion on the associated talk page[2]. [1] http://devicetree.org/Boot_Architecture [2] http://devicetree.org/Talk:Boot_Architecture I propose having a kick-off conference call in about 2 weeks (week of September 13th). Goal of the first call will be settle on a first-draft for the requirements, and to figure out if there are additional people or companies that we should be soliciting feedback from. Then we can begin drafting the interface and recommended practices document. If you're interested in being in on the call, let me know and I'll send you an invite and if you've got a preference on a day of the week. Regardless of the day, It will probably have to be at about 9:00MDT/16:00GMT to handle everyone's timezones. Cheers, g. ---------- Forwarded message ---------- From: Grant Likely <grant.likely(a)secretlab.ca> Date: Wed, Jul 21, 2010 at 1:31 PM Subject: ARM Boot Architecture working group idea Following up on a discussion from UDS-M in Brussels this year, the idea was raised to put together a working group to define a recommended firmware architecture for ARM systems. The goal being to have something usable by both the hardware and operating system vendors (notably Android and Linaro) to reduce the cost associated with board ports, and to have a common method for operating system installation across a wide range of devices. The goal of this working group would be to produce a specification including the following 3 things: 1) A set of requirements that meets the needs of hardware vendors, operating systems vendors, and software engineers 2) A recommended architecture for boot firmware. 3) A reference design implementing the first two items in a form usable by hardware vendors. I'm in the early planning stages now, and I'm looking for volunteers and interested parties to join the working group. To get things rolling, I've set up a wiki page[1] with a very early draft of requirements which captures some of the issues brought up at UDS-M. [1] http://devicetree.org/Boot_Architecture I've not yet set up any kind of charter or procedures for the working group. Nor have I done an exhaustive search for people who should be involved, so if there is anybody you can think of who I should contact, then please let me know. If you (or your company) is interested and would like to be involved, then please let me know. Once we've got a few people to kick things off, I'll set up a mailing list, try to pull together something about how this working group will be organized, and probably make an lwn or linux-embedded announcement. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

15 years, 4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture