Merge branch 'for-next/mvebu'

ARM: Layerscape: TQMLS1046a: Support booting from QSPI ...

We have to build correct images suitable for QSPI, thus have to call
lspbl_spi_image instead of lspbl_image. In lowlevel code call the
xload function which detects the bootsource rather than hardcoding
SD/MMC.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Layerscape: TQMLS1046a: unify pbi files ...

This unifies the two different pbi files. With our approach for QSPI
booting differences in the pbi files are not necessary:

- We do not do execute in place for QSPI, so we do not need different
  image execution addresses
- Setting up the QSPI clock doesn't hurt even for SD boot

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Layerscape: Add QSPI boot support ...

Booting Layerscape from QSPI is a bit tricky and the approach we take is
different from the one U-Boot has taken, so it's worth writing and
reading the following explanation.

The QSPI controller can map the Flash contents into the memory space (On
LS1046a at 0x40000000). The PBL unit uses this to read the RCW from this
memory window. The Layerscape SoCs have a PowerPC history, so it seemed
appropriate for the designers to let the QSPI controller operate in
big endian mode by default. To let the SoC see the correct RCW we have
to write the RCW and PBI data with be64 endianess. Our PBL image tool
pokes the initial binary into the SoC internal SRAM using PBI data as
done with SD/MMC boot aswell. barebox then changes the QSPI controller
endianess to le64 to properly read the barebox binary (placed at an
flash offset of 128KiB, so found in memory at 0x40020000) into SDRAM and
jumps to it.

U-Boot has another approach. Here the initial binary is executed in
place directly at 0x40100000. This means the QSPI controller endianess
must be swapped inside the PBI data. This has the effect that the whole
RCW/PBI data must be 64bit endianess swapped *except* the very last word
of the PBI data which contains the CRC command and is read already with
changed endianess. As a conclusion when porting QSPI PBI files from U-Boot
to barebox skip commands changing the endianess in the QSPI controller
and make sure the image is executed in internal SRAM and not in the
Flash memory window.

Lines like this should be removed:

09550000 000f400c

This sets the binary execution address:

09570604 40100000

For barebox it should be changed to 0x10000000.

As a result the PBI files can probably be unified between SD and QSPI
boot.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Layerscape: TQMLS1046a: Unify SD and eMMC images ...

TQ has unified SD and eMMC images in their U-Boot. Do the same in
barebox aswell.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

arm: add basic support for the Armada XP DB platform ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/stm32'

Merge branch 'for-next/layerscape'

ARM: Makefile.imx: group and sort board entries ...

Add new grouping comments for vf6xx- and Cortex-A7 based i.MX6 boards.
Sort moved entries alphabetically.

Signed-off-by: Alexander Kurz <akurz@blala.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Layerscape: Add TQ TQMLS1046a board support ...

This adds support for the TQ TQMLS1046a board. Currently supported:

- UART
- SD/MMC
- Network on eth3, eth2 currently not working for unknown reasons

First stage support exists but is currently untested. Serdes ports are
not yet supported.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Layerscape: Add LS1046a RDB board support ...

The RDB is the Freescale LS1046a reference board. This patch adds
support for it. Currently supported:

- DDR4 RAM as read from SPD EEPROM
- UART
- SD/MMC
- RGMII network ports

The Serdes ports are currently not supported.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Add basic Layerscape support ...

This adds basic Layerscape support:

- Makefile/Kconfig
- Register maps
- errata workarounds

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

pbl multiimage: Allow to check image sizes ...

PBL images are often constrained in size by limitations exposed by
the SoCs SRAM size or partition sizes on the boot device. So far
we tried to configure these limits in Kconfig, but with PBL multi
images and thus different limitations for the different supported
images this no longer works. This patch has another approach for
it:

During build time make variables containing the relevant sizes for
each image are created. These are:

PBL_CODE_SIZE_$(symbol)
PBL_MEMORY_SIZE_$(symbol)
PBL_IMAGE_SIZE_$(symbol)

PBL_CODE_SIZE_$(symbol) contains the pure code size of the PBL, it
should be smaller than the available SRAM during boot. Normally the
PBL's bss segment also needs to be in the initial SRAM, for this
case PBL_MEMORY_SIZE_$(symbol) is the relevant variable.
PBL_IMAGE_SIZE_$(symbol) contains the full size of the PBL image
including the compressed payload (but without any image headers
created later by SoC specific image tools).

$(symbol) is a placeholder for the start symbol used for this PBL image,
thus for the i.MX53 QSB with entry start_imx53_loco

PBL_CODE_SIZE_start_imx53_loco

will be created. The images/Makefile.* can use these variables directly
to check sizes or specify the same variables with a "MAX_" prefix. So
when images/Makefile.imx specifies

MAX_PBL_CODE_SIZE_start_imx53_loco = 0x10000

then the build system will make sure that the PBL code for the QSB will
not get bigger than 64KiB.

Also included in this patch are the size restrictions for the i.MX8MQ
images as an example how to use this.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: Add initial STM32MP1 support ...

This adds initial STMicroelectronics MP1 support along with support
for the DK2 devel board. Only very basic support:

- UART
- SDRAM memory base/size
- No 1st stage support

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/rpi'

Merge branch 'for-next/misc'

images: pbl: verify CONFIG_BAREBOX_MAX_IMAGE_SIZE is not exceeded ...

For platforms such as the at91, the boot ROM imposes an upper limit
on barebox file size.  Prior to 5a1a5ed253 ("ARM: images: use piggydata"),
BAREBOX_MAX_PBLX_SIZE seems to have been the way to go for limiting
the size of the final barebox binary when using the PBL.
With pblx removed, this variable is of no use, so have the existing
BAREBOX_MAX_IMAGE_SIZE replace its functionality.

Currently BAREBOX_MAX_IMAGE_SIZE is only checked against in the non-PBL
case, so add a check in the PBL case as well.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: phyCORE-i.MX8M SOM support ...

The phyCORE-i.MX8M aka PCL-066 is a SoM containing a i.MX8M SoC.

phyCORE-i.MX8M:
 - 1GB LPDDR4 RAM
 - eMMC
 - microSD
 - Ethernet

Signed-off-by: Christian Hemp <christian.hemp@posteo.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: rpi: Add device tree for Compute Module 3. ...

Compute Module needs "no-sd" property on the MMC interface otherwise
mci-bcm2835 hangs on SD card probe.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/mips'

Merge branch 'for-next/imx'

Revert "images: Drop unnecessary fix_size" ...

This reverts commit 5c0e165.

The fix_size scripts is not necessary for newer ARM toolchains,
it is however necessary for the older ARM toolchains (gcc-5 and older).

The original reason to drop fix_size was that it doesn't work on MIPS.
With this patch we add the -i flag so that we ignore unknown images
and can succesfully build MIPS images.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: i.MX: Add support for ZII i.MX8MQ based devices ...

Add support for the following ZII i.MX8MQ based boards:

   - ZII i.MX8MQ RMB3
   - ZII i.MX8MQ Zest

Most of the basic peripherals are supported by this patch. More
advanced features such as PCIe, display support, etc, are planned to
be added later.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

MIPS: ath79: add spi and sram bootstrap helpers ...

At least some ath79 SoC have build in 32K RAM. It allow us to use
lowlevel portion of barebox to bootstrap the system by using JTAG
debugger (For example OpenOCD).
Since ath79 has no reliable way to stop the CPU execution before
reading SPI Flash, this can cause different issues. To avoid it, we
need to flash a execution trap with software debug breakpoint to the
flash.

The workflow should be as follow:
- After power on or reset the CPU will start execution of SPI flash.
  As soon as software debug breakpoint is executed, CPU will halt and
  notify OpenOCD about breakpoint event.
- OpenOCD will load reduced barebox to SRAM and execute it.
  This part will do all needed low level initialization - PLL, RAM and
  trigger second breakpoint event.
- OpenOCD will load full barebox version to the main RAM and start
  execution.

It can be used for bring-up, so no regular flashing is needed.

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: imx: add support for Udoo Neo full ...

Original patch from Uwe Kleine-König, I fixed the
review comments and the imxcfg file to use the udoo neo values.

I also tested the support on the udoo neo full board.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

images: check for use of obsolete pblx-* ...

pblx-* has been removed in 5a1a5ed253 ("ARM: images: use piggydata")
and using it (e.g. because a patchset was rebased) results in a non-obvious:

	make[1]: *** No rule to make target 'images/*.pblx.*', \
	needed by 'images/barebox-*.img'.  Stop.

Avoid this by explicitly failing with an error message whenever pblx-y
or pblx- has been defined.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

images: pblx is now pblb ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

images: Drop unnecessary fix_size ...

Now that we compile the compressed binary into the decompressor we
no longer need fix_size but can use the linker to fill in the image
size into the binary.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/ultrascale'

Merge branch 'for-next/mips'