Add a host Kconfig for FIT_VERBOSE. With this we can use
CONFIG_IS_ENABLED(FIT_VERBOSE) directly in the tools build, so drop the
forcing of this in the image.h header.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

Add a host Kconfig for OF_LIBFDT. With this we can use
CONFIG_IS_ENABLED(OF_LIBFDT) directly in the tools build, so drop the
unnecessary indirection.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

Make use of the host Kconfig for FIT. With this we can use
CONFIG_IS_ENABLED(FIT) directly in the host build, so drop the unnecessary
indirection.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

We can use the __maybe_unused attribute to avoid some of the #ifdefs in
this file. Update the functions accordingly.

Note: The actual hashing interface is still a mess, with four separate
combinations and lots of #ifdefs. This should really use a driver
approach, e.g. as is done with partition drivers.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

At present when building host tools, we force CONFIG_SHAxxx to be enabled
regardless of the board Kconfig setting. This is done in the image.h
header file.

For SPL we currently just assume the algorithm is desired if U-Boot proper
enables it.

Clean this up by adding new Kconfig options to enable hashing on the host,
relying on CONFIG_IS_ENABLED() to deal with the different builds.

Add new SPL Kconfigs for hardware-accelerated hashing, to maintain the
current settings.

This allows us to drop the image.h code and the I_WANT_MD5 hack.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

Unfortunately these were removed by mistake. This means that adding hash
support to SPL brings in all software algorithms, with a substantial
increase in code size.

The origin of the problem was renaming them to SPL_FIT_xxx and then these
were removed altogether in a later commit.

Add them back. This aligns with CONFIG_MD5, for example, which has an SPL
variant.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Fixes: f5bc9c25 ("image: Rename SPL_SHAxxx_SUPPORT to SPL_FIT_SHAxxx")
Fixes: eb5171dd ("common: Remove unused CONFIG_FIT_SHAxxx selectors")
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

In preparation for enabling CONFIG_IS_ENABLED() on the host build, add
some options to enable the various FIT options expected in these tools.
This will ensure that the code builds correctly when CONFIG_TOOLS_xxx
is distinct from CONFIG_xxx.

Drop some #ifdefs which are immediately unnecessary (many more are in
later patches).
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

At present we must separately test for the host build for many options,
since we force them to be enabled. For example, CONFIG_FIT is always
enabled in the host tools, even if CONFIG_FIT is not enabled by the
board itself.

It would be more convenient if we could use, for example,
CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the
host. Add support for this.

With this and the tools_build() function, we should be able to remove all
the #ifdefs currently needed in code that is build by tools and targets.

This will be even nicer when we move to using CONFIG(xxx) everywhere,
since all the #ifdef and IS_ENABLED/CONFIG_IS_ENABLED stuff will go away.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> # b4f73886Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

With the new TOOLS_LIBCRYPTO and some other changes, it seems that we are
heading towards calling this a tools build rather than a host build,
although of course it does happen on the host.

I cannot think of anything built by the host which cannot be described as
a tool, so rename this function.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>

Drop some more ifdefs in image-board.c and also the FPGA part of bootm.c
which calls into it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add a macro to handle manually relocating a pointer. Update the iamge code
to use this to avoid needing #ifdefs.

This also fixes a bug where the 'done' flag was not set.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rather than adding an #ifdef and open-coding this calculation, add a
helper function to handle it. Use this in the image code.
Signed-off-by: NSimon Glass <sjg@chromium.org>

To avoid having #ifdefs in a few functions which are completely different
in the board and host code, create a new image-host.c file.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Tidy up the warnings.
Signed-off-by: NSimon Glass <sjg@chromium.org>

To avoid a large #ifdef in the image.c file, move the affected code into
a separate file.

Avoid any style fix-ups for easier review. Those are in the next patch.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Adjust this function so that preprocessor macros are not needed. With
this, the host build uses more of the same header files as the target
build.

Rather than definining CONFIG_SYS_MALLOC_LEN, add a CONSERVE_MEMORY
define, since that is the purpose of the value.

This appears to have no impact on code size from a spot check of a few
boards (snow, firefly-rk3288, boston32r2el, m53menlo).
Signed-off-by: NSimon Glass <sjg@chromium.org>

The gzip API uses the u64 type in it, which is not available in the host
build. This makes it impossible to include the header file.

We could make this type available, but it seems unnecessary. Limiting the
compression size to that of the 'unsigned long' type seems good enough. On
32-bit machines the limit then becomes 4GB, which likely exceeds available
RAM anyway, therefore it should be sufficient. On 64-bit machines this is
effectively u64 anyway.

Update the header file and implementation to use 'ulong' instead of 'u64'.

Add a definition of u32 for the cases that seem to need exactly that
length. This should be safe enough.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The zstd implementation prints the error in image_decomp() which is
incorrect and does not match other algorithms. Drop this and let the
caller report the error.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present this function is full of preprocessor macros. Adjust it to
check for an unsupported algorithm after the switch(). This will allow
us to drop the macros.

Fix up the return-value path and an extra blank line while we are here.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Use the common function to avoid code duplication.
Acked-by: NQu Wenruo <wqu@suse.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

The existing zstd API requires the same sequence of calls to perform its
task. Create a helper for U-Boot, to avoid code duplication, as is done
with other compression algorithms. Make use of of this from the image
code.

Note that the zstd code lacks a test in test/compression.c and this should
be added by the maintainer.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function should have a comment explaining what it does. Add one.
Signed-off-by: NSimon Glass <sjg@chromium.org>

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add a function to duplicate a memory region, a little like strdup().
Signed-off-by: NSimon Glass <sjg@chromium.org>

- a37xx: pci: Increase PCIe IO size from 64 KiB to 1 MiB (Pali)
- phy: marvell: a3700: Misc improvements (Pali)
- a38x serdes cleanup (Pali)
- A3720 PCIe enhancements (Pali & Marek)
- mvebu: mvebu_armada-8k: Puzzle M801 enhancements (Robert)
- mvebu: x530: Remove custom kwbimage.cfg (Chris)
- mvebu: Select SPL_SKIP_LOWLEVEL_INIT on ARMADA_32BIT (Stefan)

Commit ca1a4c86 ("mvebu: select boot device at SoC level") made it
unnecessary for the A385 boards to have their own kwbimage.cfg but as
the x530 was in flight at the time it was added with it's own
kwbimage.cfg. Remove the custom kwbimage.cfg as the SoC level file is
suitable.
Signed-off-by: NChris Packham <judge.packham@gmail.com>
Reviewed-by: NStefan Roese <sr@denx.de>

Since the CP1 pinctrl is not properly set in the DTS, there is no
need for setting the pinctrl by writing hardcoded values to the MPP
registers.

So, drop the code relating to that.

Fixes: 87c220d0 ("arm: mvebu: mvebu_armada-8k: Add support for initializing iEi Puzzle-M801 networking")
Signed-off-by: NRobert Marko <robert.marko@sartura.hr>
Reviewed-by: NStefan Roese <sr@denx.de>

Current CP1 pinctrl that is set on the Puzzle M801 is incorrect.
CP1 pins are only used for the SMI bus and the MSS I2C, all other
pins are just GPIO-s.

Due to this being set completely wrong, the pinctrl was actually
ended up being hardcoded in the board_early_init_f() step so that
SMI would work.

That is obviously not the right thing to do, so convert the register
hex values that were being written to individual pin modes and set it
in the DTS.
Add the SMI pins to the CP1 MDIO node as otherwise CP1 pinctrl does
not get probed without an consumer.

Fixes: 2ae2b8a2 ("arm: mvebu: Initial iEi Puzzle-M801 support")
Signed-off-by: NRobert Marko <robert.marko@sartura.hr>
Reviewed-by: NStefan Roese <sr@denx.de>

Select SPL_SKIP_LOWLEVEL_INIT on 32bit Armada platforms via Kconfig,
as this was removed from mach/config.h in a2ac2b96 ("Convert
CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig").
Signed-off-by: NStefan Roese <sr@denx.de>
Fixes: a2ac2b96 ("Convert CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig")
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Behún <kabel@kernel.org>
Cc: Pali Rohár <pali@kernel.org>
Tested-by: NPali Rohár <pali@kernel.org>

There were several changes for this structure but the documentation was
not changed at the time. Fix this.
Signed-off-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Update indentation in driver's private structure.
Signed-off-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.

When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.

CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.

We do not need to enable it when setting the HW up.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.

The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge

Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.

Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.

Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).

When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.

When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.

U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.

Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
  busno = PCI_BUS(bdf) - dev_seq(bus)

Stefan: Small fix of header masking as suggested by Pali.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

These are part of SOC_CONTROL_REG1 register, not PEX_CAPABILITIES_REG.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Remove unused PCIe functions from SerDes code. They are unused and are
duplicated either from generic PCIe code or from pci_mvebu.c.

Remove also unused PCIe macros from SerDes code. They are just obfuscated
variants of standards macros in include/pci.h or in pci_mvebu.c.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

This code is trying to parse PCIe config space of PCIe card connected on
the other end of link and then is trying to force 5.0 GT/s speed via Target
Link Speed bits in PCIe Root Port Link Control 2 Register on the local part
of link if it sees that card supports 5.0 GT/s via Max Link Speed bits in
Link Capabilities Register.

The code is incorrect for more reasons:
- Accessing config space of an endpoint card cannot be done immediately.
  If the PCIe link is not up, reading vendor/device ID registers will
  return all ones.
- Parsing is incomplete, so it can cause issues even for working cards.

Moreover there is no need to force speed to 5.0 GT/s via Target Link Speed
bits on PCIe Root Port Link Control 2 Register. Hardware changes speed from
2.5 GT/s to 5.0 GT/s autonomously when it is supported.

Most importantly, this code does not change link speed at all, since
because after updating Target Link Speed bits on PCIe Root Port Link
Control 2 Register, it is required to retrain the link, and the code for
that is completely missing.

The code was probably needed for making buggy endpoint cards work. Such a
workaround, though, should be implemented via PCIe subsystem (via quirks,
for example), as buggy cards could also affect other PCIe controllers.

Note that this code is fully unrelated to a38x SerDes code and really
should not have been included in SerDes initialization. Usage of magic
constants without names and comments made this SerDes code hard to read and
understand.

Remove this PCIe application code from low level SerDes code. As this code
is configuring only 5.0 GT/s part, in the worst case, it could leave buggy
cards at the initial speed of 2.5 GT/s (if somehow before this change they
could have been "upgraded" to 5.0 GT/s speed even with missing link
retraining). Compliant cards which just need longer initialization should
work better after this change.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

PCI device ID is part of the PCIe controller SoC / revision. For Root
Complex mode (which is the default and the only mode supported currently
by U-Boot and Linux kernel), it is PCI device ID of PCIe Root Port device.

If there is some issue with this device ID, it should be set / updated by
PCIe controller driver (pci_mvebu.c), as this register resides in address
space of the controller. It shouldn't be done in SerDes initialization
code.

In the worst case (a specific board for example) it could be done via
U-Boot's weak function board_pex_config().

But it should not be overwritten globally for all A38x devices.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>

Enabling Common Clock Configuration bit in PCIe Root Port Link Control
Register should not be done unconditionally. It is enabled by operating
system as part of ASPM. Also after enabling Common Clock Configuration it
is required to do more work, like retraining link. Some cards may be broken
due to this incomplete Common Clock Configuration and some cards are broken
and do not support ASPM at all.

Remove this incomplete code for Common Clock Configuration. It really
should not be done in SerDes code as it is not related to SerDes, but to
PCIe subsystem.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>