This reverts commit 8c36e99f21.
There is misunderstanding in commit 8c36e99f21 ("armv8: release
slave cores from CPU_RELEASE_ADDR"). How to bring the slave cores
into U-Boot proper is platform-specific. So, it should be cared
in SoC/board files instead of common/spl/spl.c. As you see SPL
is the acronym of Secondary Program Loader, there is generally
something that runs before SPL (the First one is usually Boot ROM).
How to wake up slave cores from the Boot ROM is really SoC specific.
So, the intention for the spin table support is to bring the slave
cores into U-Boot proper in an SoC specific manner. (this must be
done after relocation. see below.)
If you bring the slaves into SPL, it is SoC own code responsibility
to transfer them to U-Boot proper. The Spin Table defines the
interface between a boot-loader and Linux kernel. It is unrelated
to the interface between SPL and U-Boot proper.
One more thing is missing in the commit; spl_image->entry_point
points to the entry address of U-Boot *before* relocation. U-Boot
relocates itself between board_init_f() and board_init_r(). This
means the master CPU sees the different copy of the spin code than
the slave CPUs enter. The spin_table_update_dt() protects the code
*after* relocation. As a result, the slave CPUs spin in unprotected
code, which leads to unstable behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
spl_init on some boards is called after stack and heap relocation, on
some platforms spl_relocate_stack_gd is called to handle setting the
limit to its value CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN when simple
SPL malloc is enabled during relocation. spl_init should then not
re-assign the old pre-relocation limit when this is defined.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This option should not really be user selectable. Note that on PowerPC
we currently only need BOARD_LATE_INIT when CHAIN_OF_TRUST is enabled so be
conditional on that.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (for UniPhier)
Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.
TBD: Move all of the definitions in the include/status_led.h to the
relevant board's defconfig files.
Tested boards: CL-SOM-AM57x, CM-T335
Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
Instead of disabling the data cache in the bootelf command, disabling
it in the do_bootm_qnxelf function.
Some ELF binary might want the cache enabled.
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
We can make the code read more easily here by simply using memset()
always as when we don't have an optimized version of the function we
will still have a version of this function around anyhow.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We have long had available optimized versions of the memset and memcpy
functions that are borrowed from the Linux kernel. We should use these
in normal conditions as the speed wins in many workflows outweigh the
relatively minor size increase. However, we have a number of places
where we're simply too close to size limits in SPL and must be able to
make the size vs performance trade-off in those cases.
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Cc: Eric Jarrige <eric.jarrige@armadeus.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Magnus Lilja <lilja.magnus@gmail.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Chander Kashyap <k.chander@samsung.com>
Cc: Akshay Saraswat <akshay.s@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
These files are only included for build by the make system
when CONFIG_SPL_{EXT,FAT}_SUPPORT is enabled, remove the unneed
checks for these in the source files.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
IEC 80000-13:2008 Quantities and units
Part 13: Information science and technology
defines the prefixes to use for binary multiples.
So instead of writing
Data Size: 6726132 Bytes = 6568.49 kB = 6.41 MB
in dumpimage we should write
Data Size: 6726132 Bytes = 6568.49 KiB = 6.41 MiB.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In 35fc84f, bootm was refactored so plain 'bootm' and
'bootm <subcommand>' shared a common implementation.
The 'bootm ramdisk' command implementation is now part of the common
implementation but not invoke by plain 'bootm' since the original
implementation never did ramdisk relocation. Instead, ramdisk
relocation happened in image_setup_linux() which is typically called
during the OS portion of 'bootm'.
On ARM, parameters to the Linux kernel can either be passed by FDT or
ATAGS. When using FDT, image_setup_linux() is called which also triggers
ramdisk relocation. When using ATAGS, image_setup_linux() is _not_
called because it mostly does FDT setup.
Instead of calling image_setup_linux() in both FDT and ATAGS cases,
include BOOTM_STATE_RAMDISK in the requested states during a plain
'bootm' if CONFIG_SYS_BOOT_RAMDISK_HIGH is set and remove the ramdisk
relocation from image_setup_linux(). This causes ramdisk relocation to
happen on any system where CONFIG_SYS_BOOT_RAMDISK_HIGH regardless of
the OS being booted. Also remove IMAGE_ENABLE_RAMDISK_HIGH as it was
only used by the now-removed code from image_setup_linux().
Signed-off-by: Rick Altherr <raltherr@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
By enabling DM_USB information about number of storage devices
was lost.
Get this information back simply by printing number of devices detected
via BLK uclass.
For example:
scanning bus 0 for devices... 7 USB Device(s) found
scanning usb for storage devices... 3 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
When using ARMv8 with ARMV8_SPIN_TABLE=y, we want the slave cores to
wait on spin_table_cpu_release_addr, until the Linux kernel will "wake" them
by writing to that location. The address of spin_table_cpu_release_addr is
transferred to the kernel using the device tree that is updated by
spin_table_update_dt().
However, if we also use SPL, then the slave cores are stuck at
CPU_RELEASE_ADDR instead and as a result, never wake up.
This patch releases the slave cores by writing spl_image->entry_point to
CPU_RELEASE_ADDR location before the end of the SPL code
(at jump_to_image_no_args()).
That way, the slave cores will start to execute the u-boot and will get to
the spin-table code and wait on the correct address
(spin_table_cpu_release_addr).
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a new top-level config option so support booting an image stored
in RAM. This allows to move the RAM boot support into a sparate file
and having a single condition to compile that file.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
There is no CONFIG_OF_PLATDATA, only CONFIG_SPL_OF_PLATDATA, so rename
the two references to CONFIG_OF_PLATDATA to CONFIG_SPL_OF_PLATDATA.
Signed-off-by: Tom Rini <trini@konsulko.com>
SPLASH_STORAGE_RAW is defined as 0, so a check against & will
never be true. These flags are never combined so do a check
against == instead.
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Enable support for loading a splash image from within a FIT image.
The image is assumed to be generated with mkimage -E flag to hold
the data external to the FIT.
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
New scan should unbind all block devices not to be listed again.
Without this patch if scsi reset or scan is called new block devices are
created which point to the same id and lun.
For example:
ZynqMP> scsi scan
scsi_scan: if_type=2, devnum=0: sdhci@ff170000.blk, 6, 0
scsi_scan: if_type=2, devnum=0: ahci@fd0c0000.id1lun0, 2, 0
scsi_scan: if_type=2, devnum=0: ahci@fd0c0000.id1lun0, 2, 1
scsi_scan: if_type=2, devnum=0: ahci@fd0c0000.id1lun0, 2, 2
scsi_scan: if_type=2, devnum=0: ahci@fd0c0000.id1lun0, 2, 3
scsi_scan: if_type=2, devnum=0: ahci@fd0c0000.id1lun0, 2, 4
scanning bus for devices...
Device 0: (1:0) Vendor: ATA Prod.: KINGSTON SVP200S Rev: 501A
Type: Hard Disk
Capacity: 57241.8 MB = 55.9 GB (117231408 x 512)
Reported-by: Ken Ma <make@marvell.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Simon Glass <sjg@chromium.org>
Since entry_point and load_addr are addresses, they should be
represented as longs to cover the whole address space and to avoid
warning when compiling the SPL in 64-bit.
Also adjust debug prints to add the 'l' specifier, where needed.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
When we want to use Secure Boot with HAB from SPL over U-Boot.img,
we need to append the IVT to the image and leave space for the CSF.
Images generated as firmware_ivt can directly be signed using the
Freescale code signing tool. For creation of a CSF, mkimage outputs
the correct HAB Blocks for the image.
The changes to the usual firmware image class are quite small,
that is why I implemented that directly into the default_image.
Cc: sbabic@denx.de
v2-Changes: None
Signed-off-by: Sven Ebenfeld <sven.ebenfeld@gmail.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
Stop boot process if fpga programming fails.
Without this patch boot process continues even if fpga programming
failed.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.
intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().
scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.
scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.
SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The most of ethernet drivers are using this mdio registration sequence.
strcpy(priv->bus->name, "emac");
mdio_register(priv->bus);
Where driver can be used only with one MDIO bus because only unique
name should be used.
Other drivers are using unique device name for MDIO registration to
support multiple instances.
snprintf(priv->bus->name, sizeof(bus->name), "%s", name);
With DM dev->seq is used more even in logs
(like random MAC address generation:
printf("\nWarning: %s (eth%d) using random MAC address - %pM\n",
dev->name, dev->seq, pdata->enetaddr);
)
where eth%d prefix is used.
Simplify driver code to register mdio device with dev->seq number
to simplify mdio registration and reduce code duplication across
all drivers. With DM_SEQ_ALIAS enabled dev->seq reflects alias setting.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Create a boot_from_devices() function to handle trying each device. This
helps to reduce the size of the already-large board_init_r() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to name each method so that we can print out this name when
using the method. Currently this happens using a separate function. In
preparation for unifying this, add a name to each method.
The name is only available if we have libcommon support (i.e can use
printf()).
Signed-off-by: Simon Glass <sjg@chromium.org>
The most of ethernet drivers are using this mdio registration sequence.
strcpy(priv->bus->name, "emac");
mdio_register(priv->bus);
Where driver can be used only with one MDIO bus because only unique
name should be used.
Other drivers are using unique device name for MDIO registration to
support multiple instances.
snprintf(priv->bus->name, sizeof(bus->name), "%s", name);
With DM dev->seq is used more even in logs
(like random MAC address generation:
printf("\nWarning: %s (eth%d) using random MAC address - %pM\n",
dev->name, dev->seq, pdata->enetaddr);
)
where eth%d prefix is used.
Simplify driver code to register mdio device with dev->seq number
to simplify mdio registration and reduce code duplication across
all drivers. With DM_SEQ_ALIAS enabled dev->seq reflects alias setting.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
For example:
Board: Xilinx Zynq
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id
Warning: ethernet@e000b000 (eth0) using random MAC address -
7a:fc:90:53:6a:41
eth0: ethernet@e000b000ZYNQ GEM: e000c000, phyaddr ffffffff, interface
rgmii-id
Warning: ethernet@e000c000 (eth3) using random MAC address -
1a:ff:d7:1a:a1:b2
, eth3: ethernet@e000c000
** Bad device size - mmc 0 **
Checking if uenvcmd is set ...
Hit any key to stop autoboot: 0
Zynq> mdio list
eth0:
17 - Marvell 88E1111S <--> ethernet@e000b000
eth3:
17 - Marvell 88E1111S <--> ethernet@e000c000
Zynq>
All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.
intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().
scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.
scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.
SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Series-changes: 2
- Use CONFIG_DM_SCSI instead of mix of DM_SCSI and DM_SATA
Ceva sata has never used sata commands that's why keep it in
SCSI part only.
- Separate scsi_scan() for DM_SCSI and do not change cmd/scsi.c
- Extend platdata
Series-changes: 3
- Fix scsi_scan return path
- Fix header location uclass-internal.h
- Add scsi_max_devs under !DM_SCSI
- Add new header device-internal because of device_probe()
- Redesign block device creation algorithm
- Use device_unbind in error path
- Create block device with id and lun numbers (lun was there in v2)
- Cleanup dev_num initialization in block device description
with fixing parameters in blk_create_devicef
- Create new Kconfig menu for SATA/SCSI drivers
- Extend description for DM_SCSI
- Fix Kconfig dependencies
- Fix kernel doc format in scsi_platdata
- Fix ahci_init_one - vendor variable
Series-changes: 4
- Fix Kconfig entry
- Remove SPL ifdef around SCSI uclass
- Clean ahci_print_info() ifdef logic
The patch
"dm: spl: mmc: Support CONFIG_BLK in SPL MMC"
(sha1: 87bce4e5c0)
converted FAT part of spl_mmc_do_fs_boot() but forget to update also EXT
part by 's/&mmc->block_dev/mmc_get_blk_desc(mmc)/'.
This patch is fixing compilation error when CONFIG_SPL_EXT_SUPPORT
is enabled.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
After an image is selected out of a FIT blob for further processing we
run an optional, platform specific, post-processing function on this
component. This post-processing may modify the position and size of the
image, so after post-processing we update the location and size for this
image in the FIT header. This can cause problems as the position of
subsequent components in the FIT blob are only referenced by relative
position to the end of the last component. When we resize or move a
component the following components position will be calculated
incorrectly. To fix this, we do not update the FIT header but instead
only update our local understanding of the image data. This also allows
us to re-run post-processing steps if needed.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Tested-by: Carlos Hernandez <ceh@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
