- boot-architecture - lists.linaro.org

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, 3 months

1
0
0 0

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, 4 months

1
0
0 0

Fast Model for testing

by Steven Kinney

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

13 years, 4 months

2
2
0 0

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, 4 months

1
0
0 0

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, 4 months

1
0
0 0

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, 5 months

2
3
0 0

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, 5 months

1
0
0 0

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, 6 months

2
1
0 0

[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, 6 months

4
7
0 0

lists.linaro.org maintenance completed

by IT Services

This is to let you know that the migration of lists.linaro.org has been successfully completed. As per the email I sent on Wednesday, it may take some time for the new address of the server to be seen by your computer. You can check this by trying to connect to the web site: http://lists.linaro.org/ If you are able to connect and you do not get an error, this means you are connecting to the new server and you can send email to the lists. If you experience any problems after the weekend and you find that you still cannot connect to the server, please reply to this email to let us know. Regards Philip IT Services Manager Linaro

13 years, 6 months

1
0
0 0

OMAP4 PandaBoard 4430 vs PandaBoardES 4460

by Péter Ujfalusi

Hi, First of all I'm not sure if this is the right list to post this, but I thought boot-architecture might be the best list to post. Currently we have one hwpack for PandaBoard4430 and PandaBoardES 4460 which means that when we install the hwpack on PandaBoardES the kernel thinks it is running on PandaBoard 4430. However there is a HW difference between the two boards: Audio routing is different (for capture path). Also the hdmi pin muxing need to be different (according to the DTS files). I can see two ways of dealing with the different versions: 1. create separate hwpacks for the revisions where only the included DTB file is different: PandaBoard 4430: omap4-panda.dtb PandaBoardES: omap4-panda-es.dtb 2. Or to have single hwpack for Panda: With the included patch in u-boot Include both omap4-panda.dtb and omap4-panda-es.dtb files to the boot partition. Modify the boot.txt to load different dtb based on the board: if is_pandaES; then setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1 0x81600000 uInitrd; fatload mmc 0:1 0x815f0000 omap4-panda-es.dtb; bootm 0x80200000 0x81600000 0x815f0000"; else setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1 0x81600000 uInitrd; fatload mmc 0:1 0x815f0000 omap4-panda.dtb; bootm 0x80200000 0x81600000 0x815f0000"; fi; For audio we need to tell the difference between the two revision and this is done via different DTB blob. Thank you, Péter

13 years, 6 months

1
0
0 0

Planned maintenance - lists.linaro.org

by IT Services

Hello You are receiving this email because you are subscribed to one or more mailing lists provided by the lists.linaro.org server. IT Services are announcing planned maintenance for this server scheduled for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work is to move the service to another server. There will be some disruption during this maintenance. In order to ensure that you do not accidentally try to use the service while it is being moved, the current server will be shut down at 2pm. A further email will be sent on Friday afternoon to confirm that the migration of the service is completed. However, due to the way servers are found, it may take a while before your computer is able to connect to the relocated service. After the old server has been shut down, email sent to any of the lists will be queued, but it is possible that the sending server will still trying to deliver the email to the old server rather than the new one when it is started. It is therefore *strongly* recommended that you do not send any email to an @lists.linaro.org email address until you can connect to the new service, which you will be able to test by trying to use a web browser to connect to http://lists.linaro.org after you receive the email confirming that the migration has been completed. Since the old service will be shut down, if you are able to connect, you can be sure you have connected to the new service. If by Monday you are still unable to connect to the service or you are not able to send email to an @lists.linaro.org email address, please send an email to its(a)linaro.org. Thank you. Regards Philip IT Services Manager Linaro

13 years, 6 months

1
0
0 0

[PATCH] 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 a545e80..519b7f8 100755 --- a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc +++ b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc @@ -68,6 +68,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.1.1

13 years, 7 months

1
0
0 0

[PATCH] Samsung/Arndale: Auto boot feature

by Shivamurthy Shastri

The patch been modified as per the new changes in ArmPlatformPkg/Bds/BootOption.c Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> Signed-off-by: Rony Nandy <rony.nandy(a)linaro.org> --- ...-created-to-incorporate-auto-boot-feature.patch | 197 +++++++++++---------- 1 file changed, 105 insertions(+), 92 deletions(-) diff --git a/SamsungPlatformPkg/patches/0001-The-patch-created-to-incorporate-auto-boot-feature.patch b/SamsungPlatformPkg/patches/0001-The-patch-created-to-incorporate-auto-boot-feature.patch index 91aea96..136e7b0 100644 --- a/SamsungPlatformPkg/patches/0001-The-patch-created-to-incorporate-auto-boot-feature.patch +++ b/SamsungPlatformPkg/patches/0001-The-patch-created-to-incorporate-auto-boot-feature.patch @@ -1,63 +1,62 @@ -From 011bc2be4b3f2a5a5413511d7380b6fe3632d0f5 Mon Sep 17 00:00:00 2001 +From 3c9dabb0f20f41c37e1e18c7fcc9a39ce8bfc51d Mon Sep 17 00:00:00 2001 From: Shivamurthy Shastri <shiva.murthy(a)samsung.com> -Date: Wed, 5 Dec 2012 14:44:57 +0530 +Date: Fri, 22 Feb 2013 14:33:57 +0530 Subject: [PATCH] The patch created to incorporate auto boot feature for arndale board. Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> --- - ArmPlatformPkg/Bds/BootOption.c | 71 ++++++++++++++++++++++++++++++++++++++--- - 1 file changed, 67 insertions(+), 4 deletions(-) + ArmPlatformPkg/Bds/BootOption.c | 85 ++++++++++++++++++++++++++++++++++++----- + 1 file changed, 75 insertions(+), 10 deletions(-) diff --git a/ArmPlatformPkg/Bds/BootOption.c b/ArmPlatformPkg/Bds/BootOption.c -index 289d36a..468050d 100644 +index 78a4230..f35d039 100644 --- a/ArmPlatformPkg/Bds/BootOption.c +++ b/ArmPlatformPkg/Bds/BootOption.c -@@ -14,6 +14,11 @@ - - #include "BdsInternal.h" - +@@ -13,6 +13,10 @@ + **/ + + #include "BdsInternal.h" +#include <Library/DxeServicesTableLib.h> +#include <Protocol/BlockIo.h> +#include <Guid/DebugImageInfoTable.h> +#include <Protocol/DevicePathToText.h> -+ - extern EFI_HANDLE mImageHandle; - - EFI_STATUS -@@ -22,26 +27,61 @@ BootOptionStart ( - ) - { - EFI_STATUS Status; -- EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL* EfiDevicePathFromTextProtocol; -+ //EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL* EfiDevicePathFromTextProtocol; - UINT32 LoaderType; - ARM_BDS_LOADER_OPTIONAL_DATA* OptionalData; - ARM_BDS_LINUX_ARGUMENTS* LinuxArguments; - EFI_DEVICE_PATH_PROTOCOL* FdtDevicePath; -- EFI_DEVICE_PATH_PROTOCOL* DefaultFdtDevicePath; -- UINTN FdtDevicePathSize; -+ //EFI_DEVICE_PATH_PROTOCOL* DefaultFdtDevicePath; -+ //UINTN FdtDevicePathSize; - UINTN CmdLineSize; - UINTN InitrdSize; - EFI_DEVICE_PATH* Initrd; - UINT16 LoadOptionIndexSize; - -+ UINTN HandleCount; -+ EFI_HANDLE *HandleBuffer; -+ UINTN Index; -+ //CHAR16* String; -+ //EFI_DEVICE_PATH_PROTOCOL* DevicePathProtocol; -+ EFI_DEVICE_PATH_TO_TEXT_PROTOCOL* DevicePathToTextProtocol; -+ EFI_DEVICE_PATH_PROTOCOL *LoadImageDevicePath; -+ EFI_DEVICE_PATH_PROTOCOL *FileSystemDevicePath; -+ - if (IS_ARM_BDS_BOOTENTRY (BootOption)) { - Status = EFI_UNSUPPORTED; - OptionalData = BootOption->OptionalData; - LoaderType = ReadUnaligned32 ((CONST UINT32*)&OptionalData->Header.LoaderType); - + + extern EFI_HANDLE mImageHandle; + +@@ -22,48 +26,91 @@ BootOptionStart ( + ) + { + EFI_STATUS Status; +- EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL* EfiDevicePathFromTextProtocol; ++ //EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL* EfiDevicePathFromTextProtocol; + UINT32 LoaderType; + ARM_BDS_LOADER_OPTIONAL_DATA* OptionalData; + ARM_BDS_LINUX_ARGUMENTS* LinuxArguments; + EFI_DEVICE_PATH_PROTOCOL* FdtDevicePath; +- EFI_DEVICE_PATH_PROTOCOL* DefaultFdtDevicePath; +- UINTN FdtDevicePathSize; +- UINTN CmdLineSize; ++ //EFI_DEVICE_PATH_PROTOCOL* DefaultFdtDevicePath; ++ //UINTN FdtDevicePathSize; ++ //UINTN CmdLineSize; + UINTN InitrdSize; + EFI_DEVICE_PATH* Initrd; +- UINTN FdtLocalSize; ++ //UINTN FdtLocalSize; + UINT16 LoadOptionIndexSize; ++ UINTN HandleCount; ++ EFI_HANDLE* HandleBuffer; ++ UINTN Index; ++ EFI_DEVICE_PATH_TO_TEXT_PROTOCOL* DevicePathToTextProtocol; ++ EFI_DEVICE_PATH_PROTOCOL* LoadImageDevicePath; ++ EFI_DEVICE_PATH_PROTOCOL* FileSystemDevicePath; + + if (IS_ARM_BDS_BOOTENTRY (BootOption)) { + Status = EFI_UNSUPPORTED; + OptionalData = BootOption->OptionalData; + LoaderType = ReadUnaligned32 ((CONST UINT32*)&OptionalData->Header.LoaderType); + + BdsConnectAllDrivers(); + + Status = gBS->LocateProtocol(&gEfiDevicePathToTextProtocolGuid, NULL, (VOID **)&DevicePathToTextProtocol); @@ -72,12 +71,6 @@ index 289d36a..468050d 100644 + return Status; + } + -+ /*for (Index = 0; Index < HandleCount; Index++) { -+ Status = gBS->HandleProtocol (HandleBuffer[Index], &gEfiDevicePathProtocolGuid, (VOID **)&DevicePathProtocol); -+ String = DevicePathToTextProtocol->ConvertDevicePathToText(DevicePathProtocol,TRUE,TRUE); -+ Print (L"[0x%X] %s\n",(UINT32)HandleBuffer[Index], String); -+ }*/ -+ + for (Index = 0; Index < HandleCount; Index++) { + //Get the device path + FileSystemDevicePath = DevicePathFromHandle(HandleBuffer[Index]); @@ -85,66 +78,86 @@ index 289d36a..468050d 100644 + continue; + } + - if (LoaderType == BDS_LOADER_EFI_APPLICATION) { - // Need to connect every drivers to ensure no dependencies are missing for the application -- BdsConnectAllDrivers(); - - Status = BdsStartEfiApplication (mImageHandle, BootOption->FilePathList, 0, NULL); - } else if (LoaderType == BDS_LOADER_KERNEL_LINUX_ATAG) { -@@ -55,9 +95,18 @@ BootOptionStart ( - Initrd = NULL; - } - + if (LoaderType == BDS_LOADER_EFI_APPLICATION) { + // Need to connect every drivers to ensure no dependencies are missing for the application +- BdsConnectAllDrivers(); + + Status = BdsStartEfiApplication (mImageHandle, BootOption->FilePathList, 0, NULL); + } else if (LoaderType == BDS_LOADER_KERNEL_LINUX_ATAG) { + LinuxArguments = &(OptionalData->Arguments.LinuxArguments); +- CmdLineSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->CmdLineSize); ++ //CmdLineSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->CmdLineSize); + InitrdSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->InitrdSize); + ++#if 0 + if (InitrdSize > 0) { + Initrd = GetAlignedDevicePath ((EFI_DEVICE_PATH*)((UINTN)(LinuxArguments + 1) + CmdLineSize)); + } else { + Initrd = NULL; + } +- ++#endif ++ + //Check if zImage file on SD-MMC. + LoadImageDevicePath = FileDevicePath(HandleBuffer[Index], L"uImage"); ++ if (InitrdSize > 0) { ++ Initrd = FileDevicePath(HandleBuffer[Index], L"uInitrd"); ++ } else { ++ Initrd = NULL; ++ } + Status = BdsBootLinuxAtag (LoadImageDevicePath, Initrd, (CHAR8*)(LinuxArguments + 1)); + if (EFI_ERROR(Status)) { -+ continue; ++ continue; + } + +#if 0 - Status = BdsBootLinuxAtag (BootOption->FilePathList, - Initrd, // Initrd - (CHAR8*)(LinuxArguments + 1)); // CmdLine + Status = BdsBootLinuxAtag (BootOption->FilePathList, + Initrd, // Initrd + (CHAR8*)(LinuxArguments + 1)); // CmdLine +#endif - } else if (LoaderType == BDS_LOADER_KERNEL_LINUX_FDT) { - LinuxArguments = &(OptionalData->Arguments.LinuxArguments); - CmdLineSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->CmdLineSize); -@@ -69,6 +118,7 @@ BootOptionStart ( - Initrd = NULL; - } - + } else if ((LoaderType == BDS_LOADER_KERNEL_LINUX_GLOBAL_FDT) || (LoaderType == BDS_LOADER_KERNEL_LINUX_LOCAL_FDT)) { + LinuxArguments = &(OptionalData->Arguments.LinuxArguments); +- CmdLineSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->CmdLineSize); ++ //CmdLineSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->CmdLineSize); + InitrdSize = ReadUnaligned16 ((CONST UINT16*)&LinuxArguments->InitrdSize); + +#if 0 - // Get the default FDT device path - Status = gBS->LocateProtocol (&gEfiDevicePathFromTextProtocolGuid, NULL, (VOID **)&EfiDevicePathFromTextProtocol); - ASSERT_EFI_ERROR(Status); -@@ -78,13 +128,26 @@ BootOptionStart ( - FdtDevicePathSize = GetDevicePathSize (DefaultFdtDevicePath); - Status = GetEnvironmentVariable ((CHAR16 *)L"Fdt", DefaultFdtDevicePath, &FdtDevicePathSize, (VOID **)&FdtDevicePath); - ASSERT_EFI_ERROR(Status); + if (InitrdSize > 0) { + Initrd = GetAlignedDevicePath ((EFI_DEVICE_PATH*)((UINTN)(LinuxArguments + 1) + CmdLineSize)); + } else { +@@ -89,13 +136,31 @@ BootOptionStart ( + Status = GetEnvironmentVariable ((CHAR16 *)L"Fdt", DefaultFdtDevicePath, &FdtDevicePathSize, (VOID **)&FdtDevicePath); + ASSERT_EFI_ERROR(Status); + } +- +#endif + + //Check if zImage file on SD-MMC. + LoadImageDevicePath = FileDevicePath(HandleBuffer[Index], L"uImage"); -+ FdtDevicePath = FileDevicePath(HandleBuffer[Index], L"exynos5250-arndale.dtb"); ++ FdtDevicePath = FileDevicePath(HandleBuffer[Index], L"board.dtb"); ++ if (InitrdSize > 0) { ++ Initrd = FileDevicePath(HandleBuffer[Index], L"uInitrd"); ++ } else { ++ Initrd = NULL; ++ } + Status = BdsBootLinuxFdt (LoadImageDevicePath, Initrd, (CHAR8*)(LinuxArguments + 1), FdtDevicePath); + FreePool (FdtDevicePath); + if (EFI_ERROR(Status)) { + continue; + } + } - ++ +#if 0 - Status = BdsBootLinuxFdt (BootOption->FilePathList, - Initrd, // Initrd - (CHAR8*)(LinuxArguments + 1), - FdtDevicePath); - - FreePool (FdtDevicePath); + Status = BdsBootLinuxFdt (BootOption->FilePathList, + Initrd, // Initrd + (CHAR8*)(LinuxArguments + 1), + FdtDevicePath); + + FreePool (FdtDevicePath); +#endif - } - } else { - // Set BootCurrent variable + } + } else { + // Set BootCurrent variable -- -1.8.0 +1.8.1.1 -- 1.8.1.1

13 years, 7 months

1
0
0 0

[PATCH] MdeModulePkg/PartitionDxe: hack MBR unique signature to zero

by Ryan Harkin

This is a hack and is not intended to go upstream, but will be useful for Linaro's short term goals. Linaro's development boards use SD cards, currently we have a problem where each unique SD card has a different UUID when created with linaro-media-create / linaro-android-media create. This means that no one Boot Device configuration can boot Linaro images without some manual intervention from the user. This hack will zero the signature (UUID) read from the card meaning that all SD cards will appear to be the same card. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c index 4c64663..ef16396 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c @@ -155,6 +155,15 @@ PartitionInstallMbrChildHandles ( BlockSize, Mbr ); + + // RMH - hack - Linaro's development boards use SD cards, currently we have + // a problem where each unique SD card has a different UUID when created + // with linaro-media-create / linaro-android-media create. + // This means that no one Boot Device configuration can boot Linaro images + // without some manual intervention from the user. + // This hack will zero the signature (UUID) read from the card. + ZeroMem(&(Mbr->UniqueMbrSignature[0]), sizeof (Mbr->UniqueMbrSignature)); + if (EFI_ERROR (Status)) { Found = Status; goto Done; -- 1.7.9.5

13 years, 7 months

3
4
0 0

Flashing method for booting from eMMC for Arndale.

by Rony Nandy

Hi, The flashing method for booting from eMMC for arndale is available in https://wiki.linaro.org/Boards/Arndale/Setup/EnterpriseUbuntuServer?action=… This should be done after applying the patch http://lists.linaro.org/pipermail/boot-architecture/2013-February/000220.ht… on http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=shortlog;h=refs/hea… The document is also attached. Regards Rony

13 years, 7 months

1
0
0 0

[PATCH] Samsung/Arndale: use Linaro default config

by Ryan Harkin

The attached patch will change the default config for the Arndale board so that it boots into a Linaro SD card image. Problem is that a bug [1] prevents the Arndale board booting from a linaro-media-create'd image, so this patch can only sensibly applied after that bug is fixed. [1] https://bugs.launchpad.net/arndale/+bug/1124178

13 years, 7 months

2
1
0 0

[PATCH 1/2] Samsung/Arndale: Booting UEFI and linux from eMMC

by Rony Nandy

1. OM register comparison value changed as per the board switch configuration. 2. Removed eMMC boot partition enable code, to access user area. Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> Signed-off-by: Rony Nandy <rony.nandy(a)linaro.org> --- SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c | 1 - SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h | 2 +- SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c index d166f66..87f9379 100755 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.c @@ -840,7 +840,6 @@ DetectCard ( gSDMMCMedia.MediaId++; UpdateMSHCClkFrequency(MSHC_CLK_50M); - MSHC_EMMC_Boot_Open(); //do not close boot partition DEBUG ((EFI_D_INFO, "SD Card Media Change on Handle 0x%08x\n", gImageHandle)); return Status; diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h index 9bbf13a..e410d66 100755 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/eMMCDxe/eMMCDxe.h @@ -65,7 +65,7 @@ NV data for general purpose : 3400 #define BLEN_512BYTES (0x200) #define BLKSIZE_1 (0x1) -#define OM_EMMC 0x28 +#define OM_EMMC 0x8 #define MAX_RETRY_COUNT (100000) #define MMC_REFERENCE_CLK (96000000) diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S index a10eae1..08a893c 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S @@ -198,7 +198,7 @@ _CopyFirmware: ldr r1, [r0,#0x0] bic r2, r1, #0xffffffc1 - cmp r2, #0x28 + cmp r2, #0x8 beq _CopyFirmwareEMMC /* SD/MMC BOOT */ -- 1.8.1.1

13 years, 7 months

2
3
0 0

Re: [PATCH] Samsung/Arndale: fix RELEASE build with ARMLINUXGCC

by Reece R. Pollack

On 02/13/2013 10:44 AM, Olivier Martin wrote: > Instead of using: > #if !defined(MDEPKG_NDEBUG) > (...) > #endif > > It would be better to use: > DEBUG_CODE_BEGIN(); > (...) > DEBUG_CODE_END(); > > The reason is you can be in debug build and disable debug code (and/or > disable other things such as ASSERT). See definition of PcdDebugPropertyMask > for the full list of debug properties. These macros insert code which would place the variable definition inside an "if" statement. This usage violates the Coding Standard on page 30: "The data declarations must be the first code in a module." "Data declarations appearing anywhere but at the beginning of the module are illegal." > The EDK2 coding convention > (http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II > %20C%20Coding%20Standards%20Specification.pdf/download) says we should not > write this kind of variable declaration: > EFI_STATUS Status = EFI_INVALID_PARAMETER; > > See page 30: "Initializing a variable as part of its declaration is > illegal." This restriction is violated in almost every case in the files I patched. I merely coded my changes to blend in with the surrounding code, as any good maintenance programmer would do. The coding standard's requirement is, in this case, contrary to commonly accepted coding practice in the industry for the last decade. It really should be removed from the DRAFT standard. The mandatory space between the function name and the opening paren of its argument list needs to go away too: the vast majority of the programmers I've spoken with read that as missing a binary operator between a variable and a parenthized expression. They have to re-read the code several times before it becomes apparent that this is a function call and not a coding error. The existence of documented exceptions (macro definitions, etc.) support the argument that it's a bad practice. Feel free to change the patch as you see fit. I never expected to publish these changes; they were intended only to help me figure out why I couldn't build a standard target in my development environment. Ryan asked for copies so I provided them. -Reece

13 years, 7 months

1
0
0 0

[PATCH] Samsung/Arndale: fix RELEASE build with ARMLINUXGCC

by Ryan Harkin

The attached patch from Reece has already been applied to uefi-next as part of 13.02-rc5. But it's still open for review...

13 years, 7 months

2
1
0 0

[PATCH] panda: build.sh: change RELEASE/DEBUG param handling

by Ryan Harkin

The attached patch changes the PandaBoardPkg/build.sh script RELEASE or DEBUG parameter handling. Before this patch, build.sh can be called thus: ./build.sh ./build.sh -b DEBUG ./build.sh RELEASE This patch simplifies the way you pass the debug/release parameter into build.sh so that build scripts can simply pass DEBUG or RELEASE, without having to create a special case to add the "-b". Eg. ./build.sh ./build.sh DEBUG ./build.sh RELEASE

13 years, 7 months

3
4
0 0

UEFI: linaro-tracking-2013.02 is now open for patches

by Ryan Harkin

I've just created the linaro-tracking-2013.02 branch [1] and created the release candidate. You can find a snapshot build of 2013.02-rc2 on snapshots.linaro.org [2]. The branch is now open for submissions. The next freeze date is 21st February 2013. [1] http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=shortlog;h=refs/hea… [2] https://snapshots.linaro.org/components/kernel/uefi-next/115

13 years, 8 months

1
0
0 0

Linaro UEFI 2013.01 released

by Ryan Harkin

Hello all, This month's Linaro UEFI release is special: it's the first release from the new tree, using the new process. The whole thing is documented here; including submission guidelines, release dates, tree locations, build instructions, ...: https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/ The tree can be found here: http://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary The main points about the new tree: - The "master" branch is "long lived", it never gets rebased. - it contains the latest edk2 code from Tianocore - this is taken directly from the Tianocore GIT, so the SHAs match - it contains the latest FatDriver2 from Tianocore - Tianocore does not run a GIT repo for this project - this is taken from the Linaro GIT mirror of the Tianocore SVN - it contains the latest BaseTools from Tianocore - ie. not the version in the edk2 repo but the latest devel code - this is taken directly from the Tianocore GIT, so the SHAs match - branches exist for each sub-tree: - "tianocore-edk2" - "tianocore-edk2-fatdriver2" - "tianocore-edk2-basetools" - The "linaro-tracking" branch is "long lived", it never gets rebased. - it contains the all latest development work from Linaro - currently linaro-uefi-2013.01 - The "linaro-release" branch is "long lived", it never gets rebased. - it contains the latest release from Linaro - currently linaro-uefi-2013.01 - Monthly tracking branches are created - At the start of each month, I will update the master branch from the Tianocore upstreams - It gets tagged as "linaro-base-YYYY.MM" - I will then take a branch from this: the monthly tracking branch - The monthly tracking branch is "long lived", it never gets rebased. - "linaro-tracking-2013.01" is the most recent branch - it is now frozen and the release has been cut - I am about to create the "linaro-tracking-2013.02" branch - Topic branches are rebased each month - All branches for specific topics, e.g., Arndale BSP, get rebased to the monthly tracking branch - Any upstreamed patches are dropped - The patch set is tidied up; any "fix" patches are squashed, etc. - The branch is then merged to the monthly tracking branch - Release Candidates - Once all the topic branches are merged to the monthly tracking branch, tracking gets tagged as a release candidate - "linaro-tracking" is updated to each RC - Patches are accepted via the Boot Architecture mailing list - During the cycle, patches are merged into the relevant topics - When a complete series of patches is merged, a new RC is created. - This is currently ad-hoc and not on a time-table - Each time the tree is updated, a snapshot build is triggered in Linaro's Continuous Integration system, Jenkins. - Builds can be found on snapshots.linaro.org [1] - Release - At the end of the cycle, the monthly tracking branch is frozen - Dated follow linux-linaro - Freeze is the 2nd last Thursday of the month, eg. 21st Feb 2013 - Only urgent fixes can be accepted - Release Candidate builds are made on the following Monday, eg. 25th Feb 2013 - The release happens the last Thursday of the month, eg, 28th Feb 2013 - Release binaries are copied to releases.linaro.org [2] - The released code is copied to the uefi.git tree [3] - some users may find a problem using a tree where some branches are rebased - uefi.git has only 1 branch and is never rebased - the SHA ids do not match uefi-next.git I see this process as "in progress" and open to suggestions and change. Regards, Ryan. [1] https://snapshots.linaro.org/components/kernel/uefi-next [2] http://releases.linaro.org/13.01/components/kernel/uefi-linaro [3] http://git.linaro.org/gitweb?p=arm/uefi/uefi.git;a=summary

13 years, 8 months

1
0
0 0

Hello, Question about SctPkg.

by Steven Kinney

I am porting the UEFI ARM SctPkg into the core UEFI and I am running into a problem; Linux Host. The BuildSct.sh is trying to copy a utility called GenBin_lin{64, 32}, in my case GenBin_lin_64, that should be populated within ~/SctPkg/Tools/Bin/. My compilation executes fine, but I am unable to generate a binary because of the lacking GenBin for Linux; there is a GenBin.exe populated for a Windows Host. Anyone have any advise. Much appreciated, Steve

13 years, 8 months

2
1
0 0

RETURNED MAIL: DATA FORMAT ERROR

by drakelist＠zerobeat.net

The original message was received at Mon, 28 Jan 2013 19:13:53 +0530 from 140.49.106.138 ----- The following addresses had permanent fatal errors ----- boot-architecture(a)lists.linaro.org

13 years, 8 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture