fs/squashfs: Fix some hardlinks reading the wrong inode
In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.
The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.
In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.
Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.
Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.
A squashfs image to test this can be created like so:
Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.
John Keeping [Tue, 20 Apr 2021 18:19:44 +0000 (19:19 +0100)]
fit: Fix verification of images with external data
The "-E" option to mkimage generates a FIT with external data using the
data-size and data-offset properties which must both be ignored when
verifying a signature.
Add "data-offset" to the list of excluded properties for signature
verification; since the line is now too long, re-format the list to
one-per-line and make it static since the data is constant.
Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Fri, 30 Jul 2021 07:20:17 +0000 (15:20 +0800)]
mtd: spi-nor: Mask out fast read if not requested in DT
The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.
If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same logic in
spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
the Linux kernel v5.14-rc3.
[1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel tree
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Bin Meng [Wed, 28 Jul 2021 12:50:14 +0000 (20:50 +0800)]
spi: spi-mem-nodm: Fix read data size issue
When slave drivers don't set the max_read_size, the spi-mem should
directly use data.nbytes and not limit to any size. But current
logic will limit to the max_write_size.
This commit mirrors the same changes in the dm version done in
commit 535b1fdb8e5e ("spi: spi-mem: Fix read data size issue").
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
- Fixed broken ICH SPI driver in software sequencer mode
- Added "m25p,fast-read" to SPI flash node for x86 boards
- Drop ROM_NEEDS_BLOBS and BUILD_ROM for x86 ROM builds
- Define a default TSC timer frequency for all x86 boards
- x86 MTRR MSR programming codes bug fixes
- x86 "hob" command bug fixes
- Don't program MTRR for DRAM for FSP1
- Move INIT_PHASE_END_FIRMWARE to FSP2
- Use external graphics card by default on Intel Crown Bay
- tangier: Fix DMA controller IRQ polarity in CSRT
Simon Glass [Sat, 24 Jul 2021 15:03:38 +0000 (09:03 -0600)]
lib: Allow using 0x when a decimal value is requested
U-Boot mostly uses hex for value input, largely because addresses are much
easier to understand in hex.
But in some cases a decimal value is requested, such as where the value is
small or hex does not make sense in the context. In these cases it is
sometimes useful to be able to provide a hex value in any case, if only to
resolve any ambiguity.
Add this functionality, for increased flexibility.
Simon Glass [Sat, 24 Jul 2021 15:03:35 +0000 (09:03 -0600)]
lib: Move common digit-parsing code into a function
The code to convert a character into a digit is repeated twice in this
file. Factor it out into a separate function. This also makes the code a
little easier to read.
Simon Glass [Sat, 24 Jul 2021 15:03:32 +0000 (09:03 -0600)]
lib: Drop unnecessary check for hex digit
If we see 0x then we can assume this is the start of a hex value. It
does not seem necessary to check for a hex digit after that since it will
happen when parsing the value anyway.
Drop this check to simplify the code and reduce size. Add a few more test
cases for when a 0x prefix is used.
Bin Meng [Mon, 2 Aug 2021 07:05:16 +0000 (15:05 +0800)]
x86: crownbay: Use external graphics card by default
The board routes the Integrated Graphics Device (IGD) to an LVDS
panel, which is less popular than a PCIe based graphics card.
Disable the IGD so that it does not show up in the PCI configuration
space as a VGA display controller, so we can use an external PCIe
graphics card with whatever cable we have.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 2 Aug 2021 07:05:15 +0000 (15:05 +0800)]
x86: queensbay: Return directly if IGD / SDVO were already disabled
Initialize 'igd' and 'sdvo' to NULL so that we just need to test
them against NULL later, to be compatible with that case that IGD
and SDVO devices were already in disabled state.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 2 Aug 2021 09:45:22 +0000 (17:45 +0800)]
x86: fsp: Only FSP2 has INIT_PHASE_END_FIRMWARE
For FSP1, there is no such INIT_PHASE_END_FIRMWARE.
Move board_final_cleanup() to fsp2 directory.
Fixes: 7c73cea44290 ("x86: Notify the FSP of the 'end firmware' event") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 2 Aug 2021 09:45:21 +0000 (17:45 +0800)]
x86: fsp: Don't program MTRR for DRAM for FSP1
There are several outstanding issues as to why this does not apply
to FSP1:
* For FSP1, the system memory and reserved memory used by FSP are
already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
same RES_MEM_RESERVED resource type. Its address is programmed
and reported by FSP to be near the top of 4 GiB space, which is
not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
to be exactly the power of 2. This causes reserved bits of the
IA32_MTRR_PHYSMASK register to be written which generates #GP.
For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:28 +0000 (16:45 +0800)]
x86: cmd: hob: Fix display of resource type for system memory
The resource type for system memory is currently displayed as
"unknown", which is wrong.
Fixes: 51af144eb7a0 ("x86: Allow showing details about a HOB entry") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:27 +0000 (16:45 +0800)]
x86: cmd: hob: Fix the command usage and help messages
At present the hob command usage and help messages are messed up
in a single line. They should be separated.
This was a regression introduced when [seq] and [-v] were added
to the command.
Fixes: d11544dfa9f4 ("x86: hob: Add way to show a single hob entry") Fixes: 51af144eb7a0 ("x86: Allow showing details about a HOB entry") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:26 +0000 (16:45 +0800)]
x86: mtrr: Abort if requested size is not power of 2
The size parameter of mtrr_add_request() and mtrr_set_next_var()
shall be power of 2, otherwise the logic creates a mask that does
not meet the requirement of IA32_MTRR_PHYSMASK register.
Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:25 +0000 (16:45 +0800)]
x86: mtrr: Skip MSRs that were already programmed in mtrr_commit()
At present mtrr_commit() programs the MTRR MSRs starting from
index 0, which may overwrite MSRs that were already programmed
by previous boot stage or FSP.
Switch to call mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:24 +0000 (16:45 +0800)]
x86: mtrr: Do not clear the unused ones in mtrr_commit()
Current mtrr_commit() logic assumes that MTRR MSRs are programmed
consecutively from index 0 to its maximum number, and whenever it
detects an unused one, it clears all other MTRRs starting from that
one. However this may not always be the case.
In fact, the clear is not much helpful because these MTRRs come out
of reset as disabled already. Drop the clear codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 28 Jul 2021 04:00:23 +0000 (12:00 +0800)]
x86: dts: Define a default TSC timer frequency
If for some reason, TSC timer frequency cannot be determined from
hardware, nor is it specified in the device tree, U-Boot will panic
resulting in endless reset during boot.
Let's define a default TSC timer frequency using the Kconfig value
CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
/include/ otherwise the macro is not pre-processed).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 28 Jul 2021 04:00:22 +0000 (12:00 +0800)]
x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQ
Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.
This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andy Shevchenko [Fri, 30 Jul 2021 20:15:44 +0000 (23:15 +0300)]
x86: tangier: Fix DMA controller IRQ polarity in CSRT
IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.
Note, in DSDT (see southcluster.asl) it's described correctly.
Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 28 Jul 2021 10:28:56 +0000 (18:28 +0800)]
spi: ich: Limit slave->max_read_size
Since commit 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
(in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
in software sequencer mode.
ICH controller can only transfer a small number of bytes at once.
Before commit 43c145b8b3ee, the logic happens to make sure data.nbytes
is limited to slave->max_write_size but after commit 43c145b8b3ee
data.nbytes is no longer limited because slave->max_read_size is not
initialized with a valid number.
Fixes: 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Sun, 1 Aug 2021 18:41:22 +0000 (14:41 -0400)]
Merge tag 'dm-pull-1aug21' of https://source.denx.de/u-boot/custodians/u-boot-dm
sandbox TPM-emulator improvements
rST documentation and fixes for moveconfig
handle empty 'ranges' property in dtoc
patman warning for invalid tag
clean-ups to 'fdt add' command
Simon Glass [Thu, 29 Jul 2021 01:23:10 +0000 (19:23 -0600)]
dtoc: Fix widening an int array to an int
An int array can hold a single int so we should not need to do anything
in the widening operation. However due to a quirk in the code, an int[3]
widened with an int produced an int[4]. Fix this and add a test.
Fix a comment typo while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Tom Rini <trini@konsulko.com>
Simon Glass [Thu, 29 Jul 2021 01:23:09 +0000 (19:23 -0600)]
dtoc: Rename is_wider_than() to reduce confusion
The current name is confusing because the logic is actually backwards from
what you might expect. Rename it to needs_widening() and update the
comments.
Simon Glass [Sat, 24 Jul 2021 21:14:39 +0000 (15:14 -0600)]
sandbox: Reduce keyed autoboot delay
The autoboot tests are a recent addition to U-Boot, providing much-needed
coverage in this area.
A side effect of the keyed autoboot test is that this feature is enabled
in sandbox always. This changes the autoboot prompt and confuses the
pytests. Some tests become slower, for example the vboot tests take about
27s now instead of 3s.
We don't actually need this feature enabled to be able to run the tests.
Add a switch to allow sandbox to turn it on and off as needed. Use this
in the one test that needs it.
Add a command-line flag in case this is desired in normal use.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 25c8b9f298e ("test: add first autoboot unit tests") Reviewed-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Simon Glass [Thu, 22 Jul 2021 03:35:50 +0000 (21:35 -0600)]
doc: Move coccinelle into its own section
This tool has nothing to do with testing. It is for refactoring code
automatically using a 'semantic patch' tool.
Create a new section for 'refactoring' and move it into there. It is
likely that other topics may fall under the same heading, such as
using moveconfig and search/replace tools.
Simon Glass [Wed, 21 Jul 2021 20:55:26 +0000 (14:55 -0600)]
fdt: Show the type of devicetree with fdt addr
It seems useful to show whether the address of the Control or Working
devicetree is being shown. Add support for this. Drop the confusing 0x
prefix since the command itself only accepts hex.
Simon Glass [Sun, 18 Jul 2021 20:18:05 +0000 (14:18 -0600)]
sandbox: tpm: Correct handling of SANDBOX_TPM_PCR_NB
This is the number of PCRs, so the current check is off by one. Also the
map itself should not be checked, just the resulting pcr_index, to avoid
confusing people who read the code.
Simon Glass [Sun, 18 Jul 2021 20:18:04 +0000 (14:18 -0600)]
sandbox: tpm: Support storing device state in tpm2
At present the tpm2 emulator does not support storing the device state.
Add this so we can handle the normal vboot flow through the sandbox
executables (VPL->SPL etc.) with the TPM contents staying in place.
Note: sandbox has not yet been converted to use livetree for the state
information, since livetree does not yet support writing to the tree.
Simon Glass [Sun, 18 Jul 2021 20:17:59 +0000 (14:17 -0600)]
sandbox: tpm: Support the define-space command
Add support for this command, moving away from the previous approach of
hard-coding the initial data in the driver, now that the kernel-space data
has to be set up by the higher-level vboot code.
Simon Glass [Sun, 18 Jul 2021 20:17:58 +0000 (14:17 -0600)]
sandbox: tpm: Tidy up reading and writing of device state
At present this code assumes that the TPM data has been read but this may
not be the case. Refactor the code to use a separate pointer so we know
the current state of the data.
When scrolling the TrueType console a buffer overrun occurs.
Fixes: a29b012037cc ("video: Add a console driver that uses TrueType fonts") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
- Move the PSCI runtime code for H3/A23/A33 into SRAM
- Pick the environment from the actual MMC boot device (SD card vs.
eMMC)
- Plus a small improvement from Icenowy, just for good measure.
Samuel Holland [Mon, 19 Apr 2021 03:21:41 +0000 (22:21 -0500)]
sunxi: A23/A33/H3: Move sun8i secure monitor to SRAM A2
So far for the H3, A23, and A33 SoCs, we use DRAM to hold the secure
monitor code (providing PSCI runtime services). And while those SoCs do
not have the secure SRAM B like older SoCs, there is enough (secure)
SRAM A2 to put the monitor code and data in there instead.
Follow the design of 64-bit SoCs and use the first part for the monitor,
and the last 16 KiB for the SCP firmware. With this change, the monitor
no longer needs to reserve a region in DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: amend commit message, fix R40 and V3s build] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Mon, 19 Apr 2021 03:16:21 +0000 (22:16 -0500)]
sunxi: Select environment MMC based on boot device
Currently, the environment is always stored in eMMC if eMMC is enabled
in the config. This means images written to SD and eMMC will cross-
contaminate their environments unless the configuration is changed.
By dropping the device number from the environment location string and
implementing mmc_get_env_dev, we will always use the environment from
the boot device when booting from SD/eMMC.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
serial: a37xx: Do not call get_ref_clk() in _debug_uart_init()
Static inline function _debug_uart_init() should avoid calling external
(non-inline) functions. Therefore do not call get_ref_clk() in
_debug_uart_init() and reimplement its functionality without external
function calls.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Tony Dinh [Mon, 26 Jul 2021 06:01:19 +0000 (23:01 -0700)]
arm: kirkwood: Dreamplug: Use Ethernet PHY name and address from device tree
In DM Ethernet, the old "egiga0" and 'egiga1" names are no longer valid,
so replace these with Ethernet PHY names from device tree. Also, read
Ethernet PHY address for each port from device tree.
Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
The PWM pins on North Bridge on Armada 37xx can be configured into PWM
or GPIO functions. When in PWM function, each pin can also be configured
to drive low on 0 and tri-state on 1 (LED mode).
The current definitions handle this by declaring two pin groups for each
pin:
- group "pwmN" with functions "pwm" and "gpio"
- group "ledN_od" ("od" for open drain) with functions "led" and "gpio"
This is semantically incorrect. The correct definition for each pin
should be one group with three functions: "pwm", "led" and "gpio".
Change the "pwmN" groups to support "led" function.
Remove "ledN_od" groups. This cannot break backwards compatibility with
older device trees: no device tree uses it since there is no PWM driver
for this SOC yet. Also "ledN_od" groups are not even documented.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
tools: kwbimage: Remove v1 kwbimage SPL padding to CONFIG_SYS_U_BOOT_OFFS bytes
This padding depends on board config file and therefore it makes the
mkimage binary tool board specific, which is not correct. One cannot use
mkimage tool built as a result for board A to generate images for board
B, even if both A and B are on the same platform.
This CONFIG_SYS_U_BOOT_OFFS padding was needed when kwbimage v1 contained
SPL code which loaded U-Boot proper based on CONFIG_SYS_U_BOOT_OFFS,
instead of reading correct offset from kwbimage header.
Now that SPL code parses kwbimage header and deterinate correct offset,
there is no need for this CONFIG_SYS_U_BOOT_OFFS padding anymore.
By removing it we also reduce the size of SPL code and therefore also
decrease the final size of v1 kwbimage. This means there is more space
for U-Boot proper binary.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
arm: mvebu: Remove legacy U-Boot header from kwbimage v1 files
The SPL code now already parses kwbimage v1 headers where all necessary
information about how to load and execute U-Boot proper is present. The
legacy 64-byte U-Boot header is not used anymore.
Remove this 64-byte header by putting u-boot.bin binary (instead of
u-boot.img) into kwbimage v1 and let SPL code or BootROM to load U-Boot
directly at its execution address.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header
Now that proper load and execution addresses are set in v1 kwbimage we
can use it for loading and booting U-Boot proper.
Use the new spl_parse_board_header() function to implement parsing the
kwbimage v1 header. Use information from this header to locate offset and
size of the U-Boot proper binary, instead of using the legacy U-Boot
header which is prepended to the U-Boot proper binary stored at fixed
offset. This has the advantage that we do not need to relay on legacy
U-Boot header anymore and therefore U-Boot proper binary can be stored at
any offset, as is the case when loading & booting U-Boot proper by
BootROM. The CONFIG_SYS_U_BOOT_OFFS option is therefore not used by SPL
code anymore.
Also allow to compile U-Boot SPL without CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_MMC_SUPPORT or CONFIG_SPL_SATA_SUPPORT set. In this case
BootROM is used for loading and executing U-Boot proper. This reduces the
size of U-Boot's SPL image. By default these config options are enabled
and so BootROM loading is not used. In some cases BootROM reads from SPI
NOR at lower speed than U-Boot SPL. So people can decide whether they
want to have smaller SPL binary at the cost of slower boot.
Therefore dependency on CONFIG_SPL_DM_SPI, CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_SPI_LOAD, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPL_DM_GPIO,
CONFIG_SPL_DM_MMC, CONFIG_SPL_GPIO_SUPPORT, CONFIG_SPL_LIBDISK_SUPPORT,
CONFIG_SPL_MMC_SUPPORT, CONFIG_SPL_SATA_SUPPORT and
CONFIG_SPL_LIBDISK_SUPPORT is changed from strict to related "imply"
(which can be selectivelly turned off and causes booting via BootROM).
Options CONFIG_SYS_SPI_U_BOOT_OFFS,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET have to to be set to
zero as they define the location where kwbimage header starts. It is the
location where BootROM expects start of the kwbimage from which it reads,
parses and executes SPL part. The same applies to option
CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR, which has to be set to one.
Update all config files to set correct values of these options and set
CONFIG_SYS_U_BOOT_OFFS to the correct value - the offset where U-Boot
proper starts.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
SPL: Add support for parsing board / BootROM specific image types
Platform specific BootROM may use its own image type for loading SPL or
U-Boot proper. In some cases it makes sense to not use BootROM supplied
code for booting U-Boot proper but rather to use U-Boot SPL for this,
e.g. when U-Boot SPL can load U-Boot proper faster than BootROM. In this
case it is required for platform board code to parse and load U-Boot in
BootROM specific image type.
This change adds support for parsing platform / board / BootROM specific
image types via weak function spl_parse_board_header() which is called
before marking boot image as a raw.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
SPL: Add support for specifying offset between header and image
Some image types (e.g. kwbimage v1) store the offset to SPL binary and
offset to U-Boot proper binary in their headers. To avoid reading SPL
binary when loading U-Boot proper, add support for specifying offset in
struct spl_image_info, which defines the offset from the beginning of
the header and the beginning of the executable data.
Initial support is added only for SPI, MMC and SATA code. We can extend
it later if needed.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
arm: mvebu: Use U-Boot's SPL BootROM framework for booting from NAND/UART
Current code uses hack in board_init_f() which calls return_to_bootrom()
to skip U-Boot SPL code and return back to BootROM to load U-Boot via
UART or from NAND.
This change migrates that hack from the board_init_f() function and
changes it to return BOOT_DEVICE_BOOTROM instead of returning to BootROM
directly, so that U-Boot's SPL framework is used for returning to
BootROM.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
arm: mvebu: Implement return_to_bootrom() via U-Boot's SPL framework
U-Boot's SPL framework already has an API for loading U-Boot via
BootROM.
Implement the function board_return_to_bootrom() for mvebu SPL code.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
arm: mvebu: Mark return_to_bootrom() as a noreturn function
This function does not return, so add the appropriate compiler flag.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
Register r0 should be set to return value 0x0 - NO_ERR.
Set r0 with return value after all registers are restored from the
stack, so that the return value is always correct.
Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 944c7a317675 ("arm: mvebu: Add option to use UART xmodem protocol via kwboot") Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
projects / u-boot.git / log
