Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
is in use (which it should be when building for secure parts),
the TI secure development package is used to create a valid
secure boot image. The u-boot SPL build processes is NOT aware
of the details of creating the boot image - all of that information
is encapsulated in the TI secure development package, which is
available from TI. More info can be found in README.ti-secure
Right now, two image types are generated, MLO and X-LOADER. The types
are important, as certain boot modes implemented by the device's ROM
boot loader require one or the other (they are not equivalent). The
output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
the name that the device ROM bootloader requires for loading from the
FAT partition of an SD card (same as on non-secure devices).
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
the start address past secure reserved memory and the size of the
security certificate that precedes the boot image on secure devices).
Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
internal memory actually available on the various device flavors
(Common minimum internal RAM guaranteed for various flavors of
DRA7xx/AM57xx is 512KB).
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds a new defconfig file for the AM43xx secure device.
This is the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_ISW_ENTRY_ADDR updated for secure images.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds code to detect AM43xx HS EVMS - the string in the
I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
for evm detection, regardless of whether the evm is for
GP or HS parts, and updates board init to use that.
Modifies findfdt command to pick up am437x-gp-evm.dtb for
the HS EVMs also, as the boards are similar except for
some security specific changes around power supply and
enclosure protection.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Updates configs/am43xx_evm.h to use CONFIG options from
SOC specific Kconfig file for various calculations.
On AM43x devices, the address of SPL entry point depends on
the device type, i.e. whether it is secure or non-secure.
Further, for non-secure devices, the SPL entry point is different
between USB HOST boot mode, other "memory" boot modes (MMC, NAND)
and "peripheral" boot modes (UART, USB)
To add to the complexity, on secure devices, in addition to the
above differences, the SPL entry point can change because of the
space occupied by other components (other than u-boot or spl)
that go into a secure boot image.
To prevent the user from having to modify source files every time
any component of the secure image changes, the value of
CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
is supplied in the am43xx_*_defconfig files
Using the CONFIG options also enables us to do away with some
compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
for different boot modes.
On QSPI devices, the same problem described above occurs w.r.t. the
address of the u-boot entry point in flash, when booting secure
devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
a Kconfig option and the defconfig files.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Modifies the config.mk to build secure images when building
the SPL for secure devices.
Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.
Refer to README.ti-secure for more information.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds a centralized config_secure.mk in omap-common for
OMAP-style TI secure devices to use for boot image generation
Depending on the boot media, different images are needed for
secure devices. These commands generates u-boot*_HS_* files that
need to be used to boot secure devices.
Please refer to README.ti-secure for more information.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
when building images for secure devices. This flag is used
to invoke the secure image creation tools for creating a
boot image that can be used on secure devices. This flag
may also be used to conditionally compile code specific
to secure devices.
This terminology will be used by all OMAP architecture devices,
hence introducing to a common location.
With the creation of Kconfig for omap-common, moved the
sourcing of the Kconfig files for the omap3/4/5 and am33xx
devices from arch/arm/KConfig to the omap-common one.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.
This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.
Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.
a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.
b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.
Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds doc/README.ti-secure file to explain in generic terms
how boot images need to be created for secure devices from
Texas Instruments.
Specific details for creating secure boot images for the
AM43xx, DRA7xx and AM57xx secure devices from Texas
Instruments are also provided in the README file.
Secure devices require a security development package (SECDEV)
package that can be downloaded from:
http://www.ti.com/mysecuresoftware
Login is required and access is granted under appropriate NDA
and export control restrictions.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since CONFIG_OF_BOARD_SETUP depends on CONFIG_OF_LIBFDT:
config OF_BOARD_SETUP
bool "Set up board-specific details in device tree before boot"
depends on OF_LIBFDT
...
remove superfluous tests of CONFIG_OF_LIBFDT when testing for
CONFIG_OF_BOARD_SETUP.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
[trini: Typo fix: s/ifdefi/ifdef/]
Signed-off-by: Tom Rini <trini@konsulko.com>
Large file transfers, flash erasing and more complicated tests
requires more time to finish. Provide a way to setup specific
timeout directly in test.
For example description for 50s test:
timeout = 50000
with u_boot_console.temporary_timeout(timeout):
u_boot_console.run_command(...)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Recently Linux is gaining support for efifb on AArch64 and that support actually
tries to make use of the frame buffer address we expose to it via gop.
While this wouldn't be bad in theory, in practice it means a few bad things
1) We expose 16bit frame buffers as 32bit today
2) Linux can't deal with overlapping non-PCI regions between efifb and
a different frame buffer driver
For now, let's just disable exposure of the frame buffer address. Most OSs that
get booted will have a native driver for the GPU anyway.
Signed-off-by: Alexander Graf <agraf@suse.de>
[trini: Remove line_len entirely]
Signed-off-by: Tom Rini <trini@konsulko.com>
We put the system table into our runtime services data section so that
payloads may still access it after exit_boot_services. However, most fields
in it are quite useless once we're in that state, so let's just patch them
out.
With this patch we don't get spurious warnings when running EFI binaries
anymore.
Signed-off-by: Alexander Graf <agraf@suse.de>
With dropping support for some boards and the deletion of some source
files, it appears that both of these directories are now superfluous.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
These are no longer used. The migration is complete. Drop these options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Angelo Dureghello <angelo@sysam.it>
Acked-by: Andreas Bießmann <andreas@biessmann.org>
This option is always enabled and is about to be removed. Drop references
to it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>
Since generic board init is enabled, this is not used. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Since generic board init is enabled, this is not used. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Angelo Dureghello <angelo@sysam.it>
Since generic board init is enabled, this is not used. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Andreas Bießmann <andreas@biessmann.org>
It is well past the deadline for conversion to generic board init. Remove
the old code.
Please test this and perhaps send a follow-up patch if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
This includes the following fixes:
- Define needed __init_end symbol - see initr_reloc_global_data()
- Drop SH-specific struct bd_info
- Add an empty relocate_code() function
This prevents build errors with generic board, but the code will still need
work. Perhaps this is a better alternative than deleting the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow this to be unset, such that gd->mon_len is invalid. This seems to be
what the sh architecture does.
Signed-off-by: Simon Glass <sjg@chromium.org>
Remove the warning from the Makefile, since boards that do not use generic
board will no longer build. Also update documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>
It is well past the deadline for conversion to generic board init. Remove
the old code.
Stefan, can you test this please and perhaps send a follow-up patch if needed?
Signed-off-by: Simon Glass <sjg@chromium.org>
The client architecture that we pass to a dhcp server depends on the target
payload that we want to execute. An EFI binary has a different client arch
than a legacy binary or a u-boot binary.
So let's parameterize the pxe client arch field to allow an override via
the distro script, so that our efi boot path can tell the dhcp server that
it's actually an efi firmware.
Signed-off-by: Alexander Graf <agraf@suse.de>
We know for certain that we have 32bit DMA hardware, but 64bit addresses
on LS2085A and ZynqMP, so let's enable EFI bounce buffers for all defconfigs
on these SoCs.
Signed-off-by: Alexander Graf <agraf@suse.de>
Some hardware that is supported by U-Boot can not handle DMA above 32bits.
For these systems, we need to come up with a way to expose the disk interface
in a safe way.
This patch implements EFI specific bounce buffers. For non-EFI cases, this
apparently was no issue so far, since we can just define our environment
variables conveniently.
Signed-off-by: Alexander Graf <agraf@suse.de>
This adds platform code for the Amlogic Meson GXBaby (S905) SoC and a
board definition for ODROID-C2. This initial submission only supports
UART and Ethernet (through the existing Designware driver). DTS files
are the ones submitted to Linux arm-soc for 4.7 [1].
[1] https://patchwork.ozlabs.org/patch/603583/
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
All members of the DMA descriptor must be 32-bit, even on 64-bit
architectures: change the type to u32 to ensure this. Also, fix
other warnings.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Use phys_addr_t not unsigned long long to test that we're within
DMA'able memory]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add a psci_system_reset() which calls the SYSTEM_RESET function of
PSCI 0.2 and can be used by boards that support it to implement
reset_cpu().
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we can expose network functionality to EFI applications,
the logical next step is to load them via pxe to execute them as
well.
This patch adds the necessary bits to the distro script to automatically
load and execute EFI payloads. It identifies the dhcp client as a uEFI
capable PXE client, hoping the server returns a tftp path to a workable
EFI binary that we can then execute.
To enable boards that don't come with a working device tree preloaded,
this patch also adds support to load a device tree from the /dtb directory
on the remote tftp server.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
There are client identifiers specifically reserved for ARM U-Boot
according to http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture.
So let's actually make use of them rather than the bogus 0x100 that
we emitted so far.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Drop the Xilinx define to 0x100 as it's not the correct value to
use].
Signed-off-by: Tom Rini <trini@konsulko.com>
Enable CONFIG_BLK to move to using driver model for block devices. This
affects MMC booting in SPL, as well as MMC access in U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
When these functions are not compiled in, we still need to declare the
correct function signature to avoid a build warnings in SPL. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code does not currently build with driver model enabled for block
devices. Update it to correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
