summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* efi_loader: set revision in loaded image protocolHeinrich Schuchardt2018-07-252-0/+3
| | | | | | | | | | The revision number has to be set in the loaded image protocol. The problem was detected by running the SCT in Protocol/LoadedImage/BlackBoxTest/LoadedImageBBTestMain.c:890 Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_driver: set DM_FLAG_NAME_ALLOCED flagHeinrich Schuchardt2018-07-251-0/+2
| | | | | | | | Set the DM_FLAG_NAME_ALLOCED flag to avoid a memory leak when the block device is removed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_selftest: test writing to fileHeinrich Schuchardt2018-07-251-0/+70
| | | | | | | | Provide a unit test for writing to a FAT file system. Add some additional comments in block device unit test. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* fs: fat: cannot write to subdirectoriesHeinrich Schuchardt2018-07-251-1/+15
| | | | | | | | | | | | | | | | fs_fat_write() is not able to write to subdirectories. Currently if a filepath with a leading slash is passed, the slash is treated as part of the filename to be created in the root directory. Strip leading (back-)slashes. Check that the remaining filename does not contain any illegal characters (<>:"/\|?*). This way we will throw an error when trying to write to a subdirectory. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: check map_key in ExitBootServicesHeinrich Schuchardt2018-07-253-1/+14
| | | | | | | | The UEFI spec requires that the memory map key is checked in ExitBootServices(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: check parameters of GetMemoryMapHeinrich Schuchardt2018-07-251-10/+15
| | | | | | | | Check the parameters of boottime service GetMemoryMap(). Return EFI_INVALID_PARAMETER where required by the UEFI spec. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: check parameters in memory allocationHeinrich Schuchardt2018-07-251-0/+6
| | | | | | | If no pointer is provided throw an error. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: check parameters of CreateEventHeinrich Schuchardt2018-07-251-3/+32
| | | | | | | Rigorously check the TPL level and the event type. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* x86: Add efi_loader bits to x86_64 linker scriptAlexander Graf2018-07-251-1/+33
| | | | | | The x86_64 linker script was missing efi runtime information. Add it. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Rename sections to allow for implicit dataAlexander Graf2018-07-2516-100/+162
| | | | | | | | | | | | | | | | | | | | | | | Some times gcc may generate data that is then used within code that may be part of an efi runtime section. That data could be jump tables, constants or strings. In order to make sure we catch these, we need to ensure that gcc emits them into a section that we can relocate together with all the other efi runtime bits. This only works if the -ffunction-sections and -fdata-sections flags are passed and the efi runtime functions are in a section that starts with ".text". Up to now we had all efi runtime bits in sections that did not interfere with the normal section naming scheme, but this forces us to do so. Hence we need to move the efi_loader text/data/rodata sections before the global *(.text*) catch-all section. With this patch in place, we should hopefully have an easier time to extend the efi runtime functionality in the future. Signed-off-by: Alexander Graf <agraf@suse.de> [agraf: Fix x86_64 breakage]
* efi: Drop error return in efi_carve_out_dt_rsv()Simon Glass2018-07-251-10/+14
| | | | | | | | | | | | | This function currently returns an error code, but never uses it. There is no function comment so it is not obvious why. Presuambly the error is not important. Update the function to explain its purpose and why it ignores the error. Drop the useful error return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi: Tidy up device-tree-size calculation in copy_fdt()Simon Glass2018-07-251-2/+6
| | | | | | | | | | This is a bit confusing at present since it adds 4KB to the pointer, then rounds it up. It looks like a bug, but is not. Move the 4KB addition into a separate statement and expand the comment. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_selftest: Clean up a few comments and messagesSimon Glass2018-07-251-8/+6
| | | | | | | | Fix the 'amp' typo, expand on what 'steps' is and fix a few other minor things. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* vsprintf: Handle NULL with %pUSimon Glass2018-07-251-1/+4
| | | | | | | | | | | At present a NULL pointer passed to printf for a %pU argument will cause U-Boot to access memory at 0. Fix this by adding a check, and print "(null)" instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de> [agraf: s/(null)/<NULL>/] Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Expose U-Boot addresses in memory map for sandboxAlexander Graf2018-07-251-6/+7
| | | | | | | | | | | | | | | | | | | We currently expose host addresses in the EFI memory map. That can be bad if we ever want to use sandbox to boot strap a real kernel, because then the kernel would fetch its memory table from our host virtual address map. But to make that use case work, we would need to have full control over the address space the EFI application sees. So let's expose only U-Boot addresses to the guest until we get to the point of allocation. EFI's allocation functions are fun - they can take U-Boot addresses as input values for hints and return host addresses as allocation results through the same uint64_t * parameter. So we need to be extra careful on what to pass in when. With this patch I am successfully able to run the efi selftest suite as well as grub.efi on aarch64. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi: sandbox: Adjust memory usage for sandboxSimon Glass2018-07-251-3/+10
| | | | | | | | | | With sandbox the U-Boot code is not mapped into the sandbox memory range so does not need to be excluded when allocating EFI memory. Update the EFI memory init code to take account of that. Signed-off-by: Simon Glass <sjg@chromium.org> [agraf: Remove map_sysmem() call and header reference] Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Use common elf.h reloc definesAlexander Graf2018-07-251-4/+3
| | | | | | | | Now that elf.h contains relocation defines for all architectures we care about, let's just include it unconditionally and refer to the defines. Signed-off-by: Alexander Graf <agraf@suse.de>
* elf: Move x86 reloc defines to common elf.hAlexander Graf2018-07-254-47/+35
| | | | | | | | | | We need to know about x86 relocation definitions even in cases where we don't officially build against the x86 target, such as with sandbox. So let's move the x86 definitions into the common elf header, where all other architectures already have them. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Move to compiler based target architecture determinationAlexander Graf2018-07-251-6/+8
| | | | | | | | | | Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us what CPU architecture we're running on. The compiler however does know that, so let's just move the ifdefs over to compiler based defines rather than kconfig based options. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Introduce ms abi vararg helpersAlexander Graf2018-07-252-18/+26
| | | | | | | | | | | | | | Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms abi though, so we also need to make sure we use x86_64 varargs helpers. This patch introduces generic efi vararg helpers that adhere to the respective EFI ABI. That way we can deal with them properly from efi loader code and properly interpret variable arguments. This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests on x86_64 for me. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Disable miniapps on sandboxAlexander Graf2018-07-251-1/+1
| | | | | | | | | | In the sandbox environment we can not easily build efi stub binaries right now, so let's disable the respective test cases for the efi selftest suite. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: efi_allocate_pages is too restrictiveHeinrich Schuchardt2018-07-251-1/+1
| | | | | | | | | | | | | When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory. There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [agraf: use -1ULL instead] Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Allow SMBIOS tables in highmemAlexander Graf2018-07-251-2/+9
| | | | | | | | | | | | | We try hard to make sure that SMBIOS tables live in the lower 32bit. However, when we can not find any space at all there, we should not error out but instead just fall back to map them in the full address space instead. This can for example happen on systems that do not have any RAM mapped in the lower 32bits of address space. In that case having any SMBIOS tables at all is better than having none. Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Use map_sysmem() in bootefi commandAlexander Graf2018-07-251-5/+8
| | | | | | | | | | The bootefi command gets a few addresses as values passed in. In sandbox, these values are in U-Boot address space, so we need to make sure we explicitly call map_sysmem() on them to be able to access them. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: Use compiler constants for image loaderAlexander Graf2018-07-251-6/+6
| | | | | | | | | | | | | The EFI image loader tries to determine which target architecture we're working with to only load PE binaries that match. So far this has worked based on CONFIG defines, because the target CPU was always indicated by a config define. With sandbox however, this is not longer true as all sandbox targets only encompass a single CONFIG option and so we need to use compiler defines to determine the CPU architecture. Signed-off-by: Alexander Graf <agraf@suse.de>
* Revert "efi_loader: no support for ARMV7_NONSEC=y"Mark Kettenis2018-07-252-4/+0
| | | | | | | | | This reverts commit c524997acb3d322e1bbd36c06ad02ef589705e7c. Booting ARMv7 in non-secure mode using bootefi works now. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supportedMark Kettenis2018-07-251-1/+1
| | | | | | | | | | ARMV7_LPAE is required in order to enable the MMU in HYP mode. And we really want to enable the MMU in HYP mode such that we can enable the the caches. Otherwise U-Boot code (such as the EFI implementation) that runs in HYP mode will run at a snils pace. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: ARM: don't attempt to enter non-secure mode twiceMark Kettenis2018-07-251-1/+5
| | | | | | | | | Multiple EFI binaries may be executed in sequence. So if we already are in non-secure mode after running the first one we should skip the switching code since it no longer works once we're non-secure. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_loader: ARM: run EFI payloads non-secureMark Kettenis2018-07-251-0/+33
| | | | | | | | | | | | | If desired (and possible) switch into HYP mode or non-secure SVC mode before calling the entry point of an EFI application. This allows U-Boot to provide a usable PSCI implementation and makes it possible to boot kernels into hypervisor mode using an EFI bootloader. Based on diffs from Heinrich Schuchardt and Alexander Graf. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> [agraf: Fix indentation] Signed-off-by: Alexander Graf <agraf@suse.de>
* ARM: HYP/non-sec: migrate stackMark Kettenis2018-07-251-0/+2
| | | | | | | | | | | The current code that switches into HYP mode doesn't bother to set up a stack for HYP mode. This doesn't work for EFI applications as they expect a usable stack. Fix this by migrating the stack pointer from SP_svc to SP_hyp while in Monitor mode. This restores the stack pointer when we drop into HYP mode. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* efi_selftest: update .gitignoreHeinrich Schuchardt2018-07-251-1/+3
| | | | | | | | | | | | The following generated files should be ignored by git: efi_miniapp_file_image_exit.h efi_miniapp_file_image_return.h *.so files are normally deleted during the build but should be ignored too. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
* mtd: nand: add new enum for storing ECC algorithmRafał Miłecki2018-07-231-0/+8
| | | | | | | | | | | | | | | | | | Our nand_ecc_modes_t is already a bit abused by value NAND_ECC_SOFT_BCH. This enum should store ECC mode only and putting algorithm details there is a bad idea. It would result in too many values impossible to support in a sane way. To solve this problem let's add a new enum. We'll have to modify all drivers to set it properly but once it's done it'll be possible to drop NAND_ECC_SOFT_BCH. That will result in a cleaner design and more possibilities like setting ECC algorithm for hardware ECC mode. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> [Linux commit: b0fcd8ab7b3c89b5da7fff5224d06ed73e7a33cc] [Philippe Reynes: adapt code to u-boot] Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
* ARM: configs: omap3_logic: remove Legacy OMAP3 USB driverAdam Ford2018-07-231-1/+0
| | | | | | | | Only the MUSB driver is currently supported on the omap3_logic boards. The driver is using the new-musb and not the legacy version, so this patch removes the dead code references. Signed-off-by: Adam Ford <aford173@gmail.com>
* Convert CONFIG_DA8XX_GPIO to KconfigAdam Ford2018-07-2312-5/+11
| | | | | | | This converts the following to Kconfig: CONFIG_DA8XX_GPIO Signed-off-by: Adam Ford <aford173@gmail.com>
* ARM: DTS: am3517-evm-u-boot: Mark MMC1 with cd-invertedAdam Ford2018-07-231-0/+4
| | | | | | | | | In order to use the device tree for MMC, the card-detect pin needs to be inverted. This patch places this into the am3517-evm-u-boot.dtsi file to keep the main DTS and DTSI files clean and in-sync with Linux Signed-off-by: Adam Ford <aford173@gmail.com>
* ARM: dts: am3517-evm-uboot: Add reg-shift for UARTAdam Ford2018-07-231-0/+12
| | | | | | | | | With the resync of the omap3.dtsi file, the reg-shift was removed so it breaks the UART. Adding the reg-shift into the am3517-evm-u-boot.dtsi keeps the reg-shift for U-Boot, but keeps the dts/dtsi files clean from Linux. Signed-off-by: Adam Ford <aford173@gmail.com>
* doc: Replace DocBook with sphinx-based docsMario Six2018-07-2326-2404/+4375
| | | | | | | | | | | | | | | | | | The Linux kernel moved to sphinx-based documentation and got rid of the DocBook based documentation quite a while ago. Hence, the DocBook documentation for U-Boot should be converted as well. To achieve this, import the necessary files from Linux v4.17, and convert the current DocBook documentation (three files altogether) to sphinx/reStructuredText. For now, all old DocBook documentation was merged into a single handbook, tentatively named "U-Boot Hacker Manual". For some source files, the documentation style was changed to comply with kernel-doc; no functional changes were applied. Signed-off-by: Mario Six <mario.six@gdsys.cc>
* ARM: DTS: Resync Logic PD SOM-LV 37xx devkit with Linux 4.18-RC4Adam Ford2018-07-233-255/+323
| | | | | | | There have been some significant changes to the DM37 SOM-LV device tree. This patch re-syncs it with Linux. Signed-off-by: Adam Ford <aford173@gmail.com>
* ARM: DTS: Resync LogicPD-Torpedo-37xx-devkit with Linux 4.18-RC4Adam Ford2018-07-233-426/+475
| | | | | | | There have been some refactoring of the DTS files for the Logic PD DM37 Torpedo. This patch re-sync's the DTS files with Linux Signed-off-by: Adam Ford <aford173@gmail.com>
* ARM: dts: Resync OMAP3 and omap36xx with Linux 4.18-RC4Adam Ford2018-07-233-18/+71
| | | | | | | | There have been several minor changes to the OMAP3.dtsi, so this patch re-syncs it with Linux. An addition include/dt-binding was also brought with it. Signed-off-by: Adam Ford <aford173@gmail.com>
* ARM: DTS: Resync am3517-evm.dts with Linux 4.18-rc4Adam Ford2018-07-233-2/+377
| | | | | | | | Several changes have been made to the AM3517-evm and the underlying am3517.dtsi file. This patch re-sync's the DTS and DTSI files with Linux. Signed-off-by: Adam Ford <aford173@gmail.com>
* m68k: m5253evbe: Remove this boardTom Rini2018-07-238-441/+0
| | | | | | | The m5253evbe board has been marked as orphan since June of 2014 and should have been dropped a while ago. Do so now. Signed-off-by: Tom Rini <trini@konsulko.com>
* spi: stm32_qspi: rework mode managementChristophe Kerello2018-07-231-14/+14
| | | | | | | This patch solves quad read issue with Macronix/Micron spi nor. Signed-off-by: Christophe Kerello <christophe.kerello@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
* spi: stm32_qspi: assign functional operation mode in _stm32_qspi_gen_ccrChristophe Kerello2018-07-231-9/+8
| | | | | | | | This patch assigns the functional operation mode in _stm32_qspi_gen_ccr function. Signed-off-by: Christophe Kerello <christophe.kerello@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
* bios_emulator: remove assignment without effectHeinrich Schuchardt2018-07-231-1/+0
| | | | | | | Assigning a parameter which is not used afterwards has not effect. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* Merge branch 'master' of git://git.denx.de/u-boot-imxTom Rini2018-07-2350-508/+2514
|\ | | | | | | | | | | | | trini: Update colibri-imx6ull to use Kconfig for mtdparts related options. Signed-off-by: Tom Rini <trini@konsulko.com>
| * configs: imx6q_logic: Cleanup ramdiskaddr and fdtaddrAdam Ford2018-07-231-11/+9
| | | | | | | | | | | | | | | | | | There are already definitions for ramdisk_addr_r and fdt_addr_r, so having a duplicate copy called ramdiskaddr and fdtaddr is confusing. This patch converts any references to ramdisk_addr_r and fdt_addr_r and removes the duplicates. Signed-off-by: Adam Ford <aford173@gmail.com>
| * mx25: fix the offset between the USB ports' registersMartin Kaiser2018-07-231-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USBOH module on imx25 chips contains two USB controllers which are called USB OTG Controller and USB Host Controller. Each one has its EHCI root hub. The OTG Controller's EHCI registers start at offset 0, the Host Controller's registers start at offset 0x400. We set CONFIG_MXC_USB_PORT=0 to select the OTG Controller and 1 for the Host Controller. Therefore, IMX_USB_PORT_OFFSET must be 0x400. Using this setting, the Host Controller starts working on my imx25 board. Please note that the imx25 reference manual claims that the Host Controller's registers start at 0x200. This is not correct. The Linux Kernel uses the correct offset 0x400 in imx25.dtsi. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
| * tools/imximage: get HAB information from headerHolger Dengler2018-07-231-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signing parts of a u-boot imximage for image verification in High Assurance Boot (HAB) in a post-build process, requires some information from the imximage header. Currently, this information is only provided during the image build, which makes the transfer of this information to the post-build process harder than necessary. The i.MX HAB information (start and length) can be calculated either by using information from the image-configuration file, or from the information in the flash header of the imximage. The advantage of using information from flash header is, that they are not only available during image creation, but also available if existing images are processed. Example: $ tools/mkimage -l u-boot.imx Image Type: Freescale IMX Boot Image Image Ver: 2 (i.MX53/6/7 compatible) Mode: DCD Data Size: 483328 Bytes = 472.00 KiB = 0.46 MiB Load Address: 877ff420 Entry Point: 87800000 HAB Blocks: 0x877ff400 0x00000000 0x00071c00 DCD Blocks: 0x00910000 0x0000002c 0x00000208 Signed-off-by: Holger Dengler <dengler@linutronix.de> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
| * ARM: dh_imx6: enable GigaDevice, Macronix, and Winbond SPI Flash support in ↵Ludwig Zenz2018-07-231-0/+3
| | | | | | | | | | | | | | | | Kconfig In preparation for delivery bottlenecks, enable support for GigaDevice, Macronix, and Winbond nor flash chips. Signed-off-by: Ludwig Zenz <lzenz@dh-electronics.de>
View Lorry Controller Status