- Nov 17, 2016
-
-
Alexander Graf authored
Most new systems in U-Boot these days make use of the generic "distro" framework which allows a user to have U-Boot scan for a bootable OS on all available media types. This patch extends the LS2080ARDB board to use that framework if the hard coded NOR flash location does not contain a bootable image. Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Alexander Graf authored
When implementing efi loader support, we can expose runtime services for payloads. One such service is CPU reset. This patch implements RTS CPU reset support for layerscape systems. Signed-off-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
York Sun <york.sun@nxp.com>
-
Alexander Graf authored
The efi loader code has its own memory map, so it needs to be aware where the spin tables are located, to ensure that no code writes into those regions. Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Alexander Graf authored
The DP-DDR shouldn't be exposed as conventional memory to an OS, so let's rather claim it's a reserved region in the EFI memory map Signed-off-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
York Sun <york.sun@nxp.com>
-
Alexander Graf authored
On ls2080 we have a separate network fabric component which we need to shut down before we enter Linux (or any other OS). Along with that also comes configuration of the fabric using a description file. Today we always stop and configure the fabric in the boot script and (again) exit it on device tree generation. This works ok for the normal booti case, but with bootefi the payload we're running may still want to access the network. So let's add a new fsl_mc command that defers configuration and stopping the hardware to when we actually exit U-Boot, so that we can still use the fabric from an EFI payload. For existing boot scripts, nothing should change with this patch. Signed-off-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
York Sun <york.sun@nxp.com> [agraf: Fix x86 build]
-
Alexander Graf authored
The efi_add_runtime_mmio prototype for disabled CONFIG_EFI_LOADER was different from the enabled one. Sync them. Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Alexander Graf authored
The NXP ls1043 and ls1046 systems do not (yet) have PSCI enablement for reset. Don't enable generic PSCI reset code on them. Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Alexander Graf authored
Some boards decided not to run ATF or other secure firmware in EL3, so they instead run U-Boot there. The uEFI spec doesn't know what EL3 is though - it only knows about EL2 and EL1. So if we see that we're running in EL3, let's get into EL2 to make payloads happy. Signed-off-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
York Sun <york.sun@nxp.com>
-
- Nov 14, 2016
-
-
Simon Glass authored
Enable this so that EFI applications (notably grub) can be run under U-Boot on x86 platforms. At present the 'hello world' EFI application is not supported for the qemu-x86_efi_payload64 board. That board builds a payload consisting of a 64-bit header and a 32-bit U-Boot, which is incompatible with the way the EFI loader builds its EFI application. The following error is obtained: x86_64-linux-ld.bfd: i386 architecture of input file `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output This could be corrected with additional Makefile rules. For now, this feature is disabled for that board. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> [agraf: drop hello kconfig bits] Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
Add compiler flags and make a few minor adjustments to support the efi loader. Signed-off-by:
Simon Glass <sjg@chromium.org> [agraf: Add Kconfig dep] Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
These files now need to be in a standard place so that they can be located by generic Makefile rules. Move them to the 'lib' directory. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
These files now need to be in a standard place so that they can be located by generic Makefile rules. Move them to the 'lib' directory. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
Add support for EFI apps on aarch64. This includes start-up and relocation code plus a link script. Signed-off-by:
Simon Glass <sjg@chromium.org> [agraf: add kconfig dep] Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
Add support for EFI apps on ARM. This includes start-up and relocation code, plus a link script and some compiler setting changes. Signed-off-by:
Simon Glass <sjg@chromium.org> [agraf: Remove whitespace change, add kconfig dep] Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
Rather than hard-coding the relocation type, add it to the ELF header file and use it from there. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot. Signed-off-by:
Simon Glass <sjg@chromium.org> [agraf: Fix documentation, add unfulfilled kconfig dep] Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
When building an EFI app we need three things: - start-up code - relocation code - link script These are all different for each architecture. We also need special compiler flags in some cases. Add top-level Makefile variables for these along with documentation. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
At present we use a CONFIG option in efi.h to determine whether we are building the EFI stub or not. This means that the same header cannot be used for EFI_LOADER support. The CONFIG option will be enabled for the whole build, even when not building the stub. Use a different define instead, set up just for the files that make up the stub. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
This should use U-Boot's standard format for hex address. Fix it. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
Make sure that the cache flushes correctly by ensuring that the end address is correctly aligned. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Simon Glass authored
There is a build warning for three x86 boards since write_smbios_table_wrapper() is not used. Fix it. Fixes: e824cf3f (smbios: Allow compilation on 64bit systems) Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Emmanuel Vadot authored
Add support for EFI console modes. Mode 0 is always 80x25 and present by EFI specification. Mode 1 is always 80x50 and not mandatory. Mode 2 and above is freely usable. If the terminal can handle mode 1, we mark it as supported. If the terminal size is greater than mode 0 and different than mode 1, we install it as mode 2. Modes can be switch with cout_set_mode. Changes in V5: Correctly detect mode before enabling mode 2. Changes in V4: Reset cursor positon on mode switch Use local variables in console query code Changes in V3: Valid mode are 0 to EFIMode-1 Fix style Changes in V2: Add mode switch Report only the modes that we support Signed-off-by:
Emmanuel Vadot <manu@bidouilliste.com> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Oleksandr Tymoshenko authored
When adding network interface node use Messaging device path with subtype MAC Address and device's MAC address as a value instead of Media Device path type with subtype File Path and path "Net" Signed-off-by:
Oleksandr Tymoshenko <gonzo@bluezbox.com> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Masahiro Yamada authored
This line is shown as depends on (ARM64 ||\302\240ARM) && OF_LIBFDT on my Emacs. Use ASCII characters only. Assuming it is (ARM64 || ARM), remove the redundancy. Unlike Linux, CONFIG_ARM includes CONFIG_ARM64 in U-Boot. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
Tom Rini authored
Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Hans de Goede authored
Ian has not had any time for sunxi for some time now and I'm in the same situation now, so I'm stepping down as sunxi custodian and marking the sunxi support as Orphan. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Ian Campbell <ijc@hellion.org.uk> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Ian Campbell <ijc@hellion.org.uk>
-
- Nov 13, 2016
-
-
Stefan Roese authored
Compiling the 'bmp' command with DM and having one of the following macros enabled: CONFIG_BMP_16BPP, CONFIG_BMP_24BPP ONFIG_BMP_32BPP generates this error: drivers/video/video_bmp.c: In function ‘video_bmp_display’: drivers/video/video_bmp.c:315:22: error: ‘lcd_line_length’ undeclared (first use in this function) fb -= width * 2 + lcd_line_length; ^ This patch moves to using the correct variable instead and enables the 'bmp' command for DM again. Signed-off-by:
Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Anatolij Gustschin <agust@denx.de>
-
Marek Vasut authored
If mac-address is changed using "setenv ethaddr ...." command the new mac-adress also must be written into the responsible ethernet driver. This fixes the legacy ethernet handling. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Hannes Schmelzer <oe5hpm@oevsv.at> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Tom Rini <trini@konsulko.com> Reviewed-by:
Hannes Schmelzer <oe5hpm@oevsv.at>
-
Vignesh R authored
Fix the divider calculation logic to choose a value so that the resulting baudrate is either equal to or closest possible baudrate less than the requested value. While at that, cleanup ti_spi_set_speed(). Signed-off-by:
Vignesh R <vigneshr@ti.com> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Vignesh R authored
Update the spi-max-frequency property of m25p80 flash slave to match that of TI QSPI controller node, so that QSPI operations happen at maximum supported frequency of 76.8MHz. Signed-off-by:
Vignesh R <vigneshr@ti.com> Reviewed-by:
Jagan Teki <jteki@openedev.com>
-
Lokesh Vutla authored
Only a certain set of PLLM/D values are recommended to configure the DDR at the required speeds for a given clock input frequency. Updating these values as specified in Data Sheet[1] Table 5-18 [1] http://www.ti.com/lit/ds/symlink/66ak2g02.pdf Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Lokesh Vutla authored
Update the PLL initialization sequence to avoid glitches while programming. User guide for the same is available at[1]. [1] http://www.ti.com/lit/ug/sprugv2h/sprugv2h.pdf Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Keerthy authored
While we setup the mmu initially we mark set_section_dcache with DCACHE_OFF flag. In case of non-LPAE mode the DCACHE_OFF macro is rightly defined with TTB_SECT_XN_MASK set so as to mark all the 4GB XN. In case of LPAE mode XN(Execute-never) bit is not set with DCACHE_OFF. Hence XN bit is not set by default for DCACHE_OFF which keeps all the regions execute okay and this leads to random speculative fetches in random memory regions which was eventually caught by kernel omap-l3-noc driver. Fix this to mark the regions as XN by default. Signed-off-by:
Keerthy <j-keerthy@ti.com> Reviewed-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Keerthy authored
Printing the option value in hex makes it more comprehensible. Signed-off-by:
Keerthy <j-keerthy@ti.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Diego Dorta authored
Add a README file to help users getting started with the board. Signed-off-by:
Diego Dorta <diego.dorta@nxp.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Fabien Parent authored
If the MAC address specified on the EEPROM is invalid (multicast or zero address), then u-boot fails to boot. Having a bad MAC address in the EEPROM should not prevent the system from booting. This commit changes the error path to just print an error messages in case of bad MAC address. Signed-off-by:
Fabien Parent <fparent@baylibre.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Alex G authored
In most cases, the SPL and u-boot.img will be on the same boot media. Since the SPL was loaded by the boot rom, the pinmux will already have been configured for this media. This, the board will still be able to boot successfully, or at least reach the u-boot console, where more recovery options are available. I've encountered this on a beaglebone black with a corrupted EEPROM. Removing this check allowed the board to boot successfully. I've also seen this on EVM-based boards with an unprogrammed EEPROM. On those boards, for some reason there were no UART messages. This made it look as if the SOC was dead. Remove the hang(), as it is not a fatal error. Also reformat the error message to be clearer as to the cause. The original message made it appear as if the wrong binary was being loaded. Signed-off-by:
Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Ladislav Michl authored
Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and Hynix H27S4G6F2DKA-BM Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Reviewed-by:
Javier Martinez Canillas <javier@samsung.com> Tested-by:
Javier Martinez Canillas <javier@samsung.com>
-
Ladislav Michl authored
Defconfigs should remain the same except CONFIG_SYS_EXTRA_OPTIONS. Drop NAND specific defconfig as flash type is runtime detected. Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Reviewed-by:
Javier Martinez Canillas <javier@samsung.com>
-
Ladislav Michl authored
As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus. Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Reviewed-by:
Javier Martinez Canillas <javier@samsung.com> Tested-by:
Javier Martinez Canillas <javier@samsung.com>
-