boot-architecture

boot-architecture@lists.linaro.org

1 participants
685 discussions

[PATCH 0/1] How to fix your ARM UEFI BSP to work with the latest upstream Tianocore code

by Ryan Harkin

[PATCH 1/2] TC1: Fix TC1 build for latest upstream changes [PATCH 2/2] VEA5: Fix A5 build for latest upstream changes The two platforms are relatively simple to fix because they follow the TC2 and A9 BSPs very closely. Perhaps close enough to some more code to be moved to common areas ;-) These examples will show you the simple steps you will need to take to get your BSP working. However, your BSP may be using old functionality that my BSPs were not. The main change to watch out for is the deletion of the macro IS_PRIMARY_CORE() which has been replaced with a function that the BSP must provide. The change came about with this commit: -------------------------------------------------------------------------------- commit bebda7ceec3d3024c76b3c2ed0c9b4e502a13d61 Author: oliviermartin <oliviermartin@6f19259b-4bc3-4df7-8a09-765794883524> Date: Fri May 10 12:41:27 2013 +0000 ArmPlatformPkg/ArmPlatformLib: Added support for ArmPlatformIsPrimaryCore() Checking if a core if the primary/boot core used to be done with the macro IS_PRIMARY_CORE(). Some platforms exposes configuration registers to change the primary core. Replacing the macro IS_PRIMARY_CORE() by ArmPlatformIsPrimaryCore() allows some flexibility in the way to check the primary core. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin(a)arm.com> Reviewed-by: Leif Lindholm <leif.lindholm(a)linaro.org> Acked-by: Ryan Harkin <ryan.harkin(a)linaro.org> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14344 6f19259b-4bc3-4df7-8a09-765794883524 -------------------------------------------------------------------------------- My examples provide this function in a way that works for them, however, your platforms may use different mechanisms. I have no specific code that was using the IS_PRIMARY_CORE() macro, so these patches will not give an example of how you deal with those changes, but Olivier's original patch should help a lot there. Regards, Ryan. [1] https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary

13 years

linaro-uefi-2013.06-rc1 is out

by Ryan Harkin

Hello UEFI folks, I spent the day with Leif going through maintainer stuff and together we produced the 2013.06 iteration of the Linaro UEFI tree [1]. Highlights include: - A5, TC1, Panda, Origen and Arndale no longer build (I will be fixing A5 and TC1 as part of -rc2, unless something else urgent comes in and needs an -rc2) - The -menu and -local-fdt topics have been merged into one -bds topic to simplify upstreaming, reviewing and merging - All topics are rebased to the latest Tianocore upstream code - Some of our patches have made it upstream - yay! - and thus have been removed from our topic branches - There are more patches that we think are ready to go upstream now. I'll start this after -rc2 Regards, Ryan. [1] https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary

13 years

Re: Looking at Maintainer Tasks Today And Tomorrow

by Steven Kinney

Hi Ryan, Thanks for the patch system and I will follow the same methodology. BR, Steve On 4 June 2013 10:50, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > Hi Steve, > > Further to our phone call, I pushed out my patch system git repo: > > ssh:// > linaro-private.git.linaro.org/srv/linaro-private.git.linaro.org/uefi/patche… > > Hope it helps! > > Cheers, > Ryan. > > On 3 June 2013 16:23, Steven Kinney <steven.kinney(a)linaro.org> wrote: > > Hi Ryan, > > > > I am focusing on maintainer tasks today and tomorrow; > > before I start on 64-bit SCT integration. I talked to Grant on my > one-on-one > > Friday and he suggested applying the patches within a local repository, > > maybe within my git.linaro.org folder, and working with you regarding > > merging and other GIT tasks. Of course, if you have ant suggestions to > > start getting me up so that I can be more of use to you, please let me > know. > > Also, Grant wanted me to start giving suggestions regarding the coding, > and > > I see some areas that can be commented on, but I would like to make sure > we > > are in sync before I start yammering on commented out code blocks and > such. > > > > Anyway, I look forward to learning about this area and > > will ping you from time to time over the next few days to get some > specific > > advice. Thanks for you patience and help! > > > > BR, > > > > Steve >

13 years

Fast Model for testing

by Steven Kinney

Ryan, Which Fast Model would you recommend for SCT testing and testing in general. -Steve

13 years

Re: Detect SMBIOS table

by Grant Likely

[cc'ing the boot architecture list; this conversation should be in public] On Wed, May 29, 2013 at 11:19 AM, Leif Lindholm <leif.lindholm(a)linaro.org> wrote: > Hi Yi, > > On 28 May 2013 15:52, Li Yi <yi.li(a)linaro.org> wrote: >> just modify linux loader , add SMBIOS address information into fdt. then >> I will modify the dmidecode to parse the /dev/devicetree to find SMBIOS >> table pointer. Maybe this way can skip grub and kernel's modification. > > Ok, yes, that should work. > >> the only problem I care about is the address wrote into fdt ,it is a >> real physical address, does dmidecode (tool) can read this address ,and do >> the right thing? it need to be proved. > > Yes - UEFI is guaranteed to run with a 1:1 mapping, so the address you see it > at in the UEFI linux loader is the physical address. > >> Grant: if kernel will use the SMBIOS's region memory, can I reserve the >> 64M memory from the top total ,then kernel will know it's reserved ,will not >> use the region again ,right? > > That should be enough. Yes, but you shouldn't even need to do that. I just looked at the LinuxLoader code, in particular the UEFI FDT code, and I've noticed that the reserved regions should already be set up. Look in ArmPkg/Library/BdsLib/BdsLinuxFdt.c, about line 420. The function PrepareFdt() retrieves the UEFI memory map and calls fdt_add_mem_rsv() for each region. It does use the function IsLinuxReservedRegion() to filter the regions, so if SMBIOS uses a different region type then you'll need to add that type to the list. So, if I'm correct, it should be sufficient to merely enable SMBIOS support in UEFI and the kernel will automatically mark the SMBIOS region as reserved. You can verify this by adding "memblock=debug" to the kernel command line and looking at the kernel boot output. You'll see something like this: memblock_reserve: [0x00000000008400-0x0000000042e98c] arm_memblock_init+0x4c/0x150 memblock_reserve: [0x00000004000000-0x0000000452f400] arm_memblock_init+0xcc/0x150 memblock_reserve: [0x00000000004000-0x00000000008000] arm_memblock_init+0xf0/0x150 memblock_reserve: [0x00000004530000-0x00000004537350] arm_dt_memblock_reserve+0x30/0xb0 MEMBLOCK configuration: memory size = 0x8000000 reserved size = 0x960cdc memory.cnt = 0x1 memory[0x0] [0x00000000000000-0x00000007ffffff], 0x8000000 bytes reserved.cnt = 0x4 reserved[0x0] [0x00000000004000-0x00000000007fff], 0x4000 bytes reserved[0x1] [0x00000000008400-0x0000000042e98b], 0x42658c bytes reserved[0x2] [0x00000004000000-0x0000000452f3ff], 0x52f400 bytes reserved[0x3] [0x00000004530000-0x0000000453734f], 0x7350 bytes Memory policy: ECC disabled, Data cache writeback memblock_reserve: [0x00000007fff000-0x00000008000000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffe000-0x00000007fff000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffdf10-0x00000007ffe000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffc000-0x00000007ffd000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffb000-0x00000007ffc000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffa000-0x00000007ffb000] memblock_alloc_base_nid+0x68/0x84 Note: this only works with the UEFI LinuxLoader. The GRUB code doesn't currently add the UEFI reserved regions to the FDT reserved map. g.

13 years

EFI_STUB notes

by Grant Likely

Hi Roy, Here are some very quick notes on what I found on writing UEFI applications. I found a library called "gnuefi" which allows building EFI applications apart from the Tianocore build tree. It looks interesting, but has not been ported to ARM. I don't yet know if it is worthwhile pursuing. http://gnu-efi.sourceforge.net/ As mentioned, the Linux kernel has an EFI stub already. I could tell you which files to look at, but really just doing a "git grep EFI_STUB" in the kernel tree will show you all the files that you need to care about. :-) You'll need to figure out how to get a UEFI PE-COFF header into the LInux kernel zImage wrapper. It shouldn't be too hard. You'll need to look at the startup code in arch/arm/boot/compressed/head.S. The PE-COFF header will need to go somewhere after the start: label. You should be able to see the existing LInux kernel "header" (not much of a header, more of a magic number) about 10 lines down from the start label. That's all I can write at the moment. We can talk more tomorrow. g.

13 years, 1 month

ARMv7-A UEFI runtime services support in Linux

by Leif Lindholm

Terse information, more engineering notes than documentation, and links to sources can be found at: https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices Contains a few known bugs, and will need some fundamental discussions/reengineering, but lets us start experimenting. / Leif

13 years, 1 month

PXE for arndale

by Rony Nandy

To boot linux kernel using TFTP in Arndale. Following is the steps: 1. Apply the patches 13.03 branch. (on top of Olivers Ethernet patches,If Olivier's patches doesn't apply, then do it manually) 2. Compile and boot as usual. 3. Wait till USB initialization and then do as shown below: The default boot selection will start in 1 seconds UsbEnumeratePort: Device Connect/Disconnect Normally UsbEnumeratePort: Device Connect/Disconnect Normally UsbEnumeratePort: Device Connect/Disconnect Normally EhcExecTransfer: transfer failed with 8 EhcControlTransfer: error - Device Error, transfer - 8 0x9F6BDA90: Allocate pNicDevice, 792 bytes 0x9F4DCD10: Allocated timer Installed: gEfiCallerIdGuid on 0x9F4DE390 Installed: gEfiSimpleNetworkProtocolGuid on 0x9F4DE390 MnpSyncSendPacket: No network cable detected. MnpSyncSendPacket: No network cable detected. MnpSyncSendPacket: No network cable detected. MnpSyncSendPacket: No network cable detected. ERROR: Did not find Linux kernel. [1] SD-MMC Booting - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage - Arguments: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log - LoaderType: Linux kernel with global FDT ----------------------- Global FDT Config - VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)/exynos5250-arndale.dtb ----------------------- [a] Boot Manager [b] Shell Start: a [1] Add Boot Device Entry [2] Update Boot Device Entry [3] Remove Boot Device Entry [4] Update FDT path [5] Return to main menu Choice: 1 Installed Fat filesystem on 9E63E190 [1] boot (51 MB) - VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000) [2] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00) - VenHw(B615F1F5-5088-43CD-809C-A16E52487D00) [3] PXE on MAC Address: 00:40:5C:26:0A:5B - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0) [4] TFTP on MAC Address: 00:40:5C:26:0A:5B - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0) Select the Boot Device: 4 Get the IP address from DHCP: [y/n] y Get the TFTP server IP address: 192.168.1.1 File path of the EFI Application or the kernel : uImage Is an EFI Application? [y/n] n Boot Type: [a] ATAGS, [g] Global FDT or [l] Local FDT? [a/g/l] g Add an initrd: [y/n] n Arguments to pass to the binary: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log Description for this new Entry: tftp [1] Add Boot Device Entry [2] Update Boot Device Entry [3] Remove Boot Device Entry [4] Update FDT path [5] Return to main menu Choice: 5 [1] SD-MMC Booting - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage - Arguments: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log - LoaderType: Linux kernel with global FDT [2] tftp - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage - Arguments: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log - LoaderType: Linux kernel with global FDT ----------------------- Global FDT Config - VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)/exynos5250-arndale.dtb ----------------------- [a] Boot Manager [b] Shell Start: 2

13 years, 2 months

boot Ubuntu using PXE from U-Boot on the Samsung XE303C12-A01US Chromebook

by Mario

Hello. I'm trying to boot Ubuntu using PXE from U-Boot on the Samsung XE303C12-A01US Chromebook. I would like to understand better the point 5 of the tutorial here : https://wiki.linaro.org/Boards/Arndale/Setup/PXEBoot it says : "At the u-boot prompt, set the environmental variables "serverip" and "ipaddr" as per the board and host PC configuration. Now set the following environmental variables as mentioned..." the problem is that the Samsung XE303C12-A01US does not have a serial port and I can't stop the u-boot booting and set the enviromental variables manually. I would like to know how can I embed them inside u-boot. Also because there is not a configuration file like boot.cmd/boot.scr like there is on the pandaboard that can be used to pass the parameters. Thanks. -- Mario.

13 years, 2 months

[PATCH 1/2] Samsung/Arndale: Enable component name protocol

by Shivamurthy Shastri

Component Name Protocol been enabled to make sure the shell commands like drivers, devtree and devices shows the device name and other features properly. Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> Signed-off-by: Rony Nandy <rony.nandy(a)linaro.org> --- SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc index fe574af..941c6e5 100755 --- a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc +++ b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc @@ -69,6 +69,11 @@ ################################################################################ [PcdsFeatureFlag.common] + gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|FALSE + gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE + gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|FALSE + gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE + !ifdef $(EDK2_SKIP_PEICORE) gArmPlatformTokenSpaceGuid.PcdSystemMemoryInitializeInSec|TRUE gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|TRUE -- 1.8.2

13 years, 2 months

← Newer
1
...
55
56
57
58
59
60
61
...
69
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture