Commit Graph

14 Commits

Author SHA1 Message Date
Michal Simek
55de09292f arm64: zynqmp: Call psu_init from board_early_init_f
For some mini platforms there could be a need to include psu_init.
That's why move it to board file instead of spl only file.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-08-02 09:11:52 +02:00
Michal Simek
b0259c840e arm64: zynqmp: Add comment about level shifter mode v1
Silicon v1 didn't support SD boot mode with level shifter.
Because system can't boot any error message is not shown
that's why comment is just a record if someone tries to debug it.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-06-20 16:40:58 +02:00
Jean-Francois Dagenais
8bf62ae7da arm64: zynqmp: spl: use given boot_device instead of fetching it again
The boot_device argument to spl_boot_mode was massively added without
actually modifying the existing functions.

This commit actually makes use of the handed value, which is the same.

Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-06-19 16:53:10 +02:00
Jean-Francois Dagenais
e3fdf5d056 arm64: zynqmp: spl: fix dual SD controller support
When enabling both SDHCI controllers, spl_mmc.c would actually choose
device sdhci0 even if booted from sdhci1 (boot_device). This is because
spl_mmc_get_device_index(boot_device) expects BOOT_DEVICE_MMC2[_2] in
order to return index 1 instead of 0.

The #if defined(...) statement is copied from board/xilinx/zynqmp/zynqmp.c

So the key to properly enabling both controllers as boot sources is
defining both CONFIG_ZYNQ_SDHCI0 and CONFIG_ZYNQ_SDHCI1 in your board's
include/configs/*.h.

Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-06-19 16:53:09 +02:00
Michal Simek
bd89fba202 arm64: zynqmp: Wire SD1 level shifter mode to SPL
Add missing SD boot mode to SPL. zcu102-rev1.0 is supporting
this boot mode.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-06-19 16:53:09 +02:00
Michal Simek
509d4b9545 ARM64: zynqmp: Generate handoff structure for ATF
Xilinx ATF extending options for passing images from BL2(FSBL)
to BL31. U-Boot SPL is FSBL replacement that's why it should generate
handoff structure the same. Support only one entry which is U-Boot in
EL2 itself. When FIT image is adopted structure generate should be data
driven.

Currently ATF is placing this structure at the beggining of OCM which is
rewriting early parts of ATF which should be unused at that time.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2017-01-10 10:22:05 +01:00
Michal Simek
2661081c30 ARM64: zynqmp: List secondary software boot modes
Using alternative bootmode field to support automatic secondary boot
modes. It is purely software setting where SW modes are using free
bootmode combinations.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-12-02 14:35:57 +01:00
Michal Simek
47359a0394 ARM64: zynqmp: Fix secondary bootmode enabling
Do not setup use_alt bit which copy alternative boot mode to
boot mode. The reason is that this bit is cleared after POR
but not after any software reset which will cause
that after SW reset bootrom will look for different boot image.

This patch setups alternative boot mode selection (purely SW
handling) and extends code to read this alternative boot mode first and
use it if it is setup.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-11-15 15:28:05 +01:00
Michal Simek
5242772c51 ARM64: zynqmp: Fix USB ulpi phy sequence
It should be enough to call low(5us)->high pulse for all cases
to provide proper reset. There is no need to call high->low->high.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-09-22 07:33:21 +02:00
Michal Simek
48255f5276 ARM64: zynqmp: Add support for USB ulpi phy reset via mode pins
Mode pins can be used as output for reset. Xilinx boards are using
this feature as additional way how to reset USB phys and also others
chips on the boards.
Mode1 is used on all these boards for this feature.
Let SPL toggle reset on this pin by default.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-09-22 07:33:21 +02:00
Michal Simek
d58fc12eb7 ARM64: zynqmp: Add support for DFU from SPL
SPL needs to have bigger stack size because of USB.
Simple malloc needs to be disabled because dfu code requires different
allocation functions. There is no space in OCM that's why random place
in DDR is used.

BOOTD must be disabled because it is causing compilation error.

All variables are disabled and used only variables valid for DFU because
they are simple huge. Including automatic variables added by
CONFIG_ENV_VARS_UBOOT_CONFIG.
Hardcode addresses for u-boot, atf, kernel and dtb
just for SPL DFU code.

Enable SPL DFU for zcu100.
Create new usb_dfu_spl variable just to run Linux kernel loaded in SPL.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-09-22 07:33:21 +02:00
Michal Simek
7f491d7b30 ARM64: zynqmp: Force certain bootmode for SPL
ZynqMP provides an option to overwrite bootmode setting which
can change SPL behavior.
For example: boot SPL via JTAG and then SPL loads images from SD.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-09-22 07:33:20 +02:00
Marek Vasut
2b1cdafa9f common: Pass the boot device into spl_boot_mode()
The SPL code already knows which boot device it calls the spl_boot_mode()
on, so pass that information into the function. This allows the code of
spl_boot_mode() avoid invoking spl_boot_device() again, but it also lets
board_boot_order() correctly alter the behavior of the boot process.

The later one is important, since in certain cases, it is desired that
spl_boot_device() return value be overriden using board_boot_order().

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>
[add newly introduced zynq variant]
Signed-aff-by: Andreas Bießmann <andreas@biessmann.org>
2016-06-26 20:17:22 +02:00
Michal Simek
e6a9ed04e7 ARM64: zynqmp: Add SPL support support
Support RAM and MMC boot mode in SPL also with SPL_FIT images.

In MMC boot mode two boot options are available:
1) Boot flow with ATF(EL3) and full U-Boot(EL2):
 aarch64-linux-gnu-objcopy -O binary bl31.elf bl31.bin
 mkimage -A arm64 -O linux -T kernel -C none -a 0xfffe5000 -e 0xfffe5000
 -d bl31.bin atf.ub
 cp spl/boot.bin <sdcard fat partition>
 cp atf.ub <sdcard fat partition>
 cp u-boot.bin <sdcard fat partition>

2) Boot flow with full U-Boot(EL3):
 cp spl/boot.bin <sdcard>
 cp u-boot*.img <sdcard>

3) emmc boot mode
 dd if=/dev/zero of=sd.img bs=1024 count=1024
 parted sd.img mktable msdos
 parted sd.img mkpart p fat32 0% 100%
 kpartx -a sd.img
 mkfs.vfat /dev/mapper/loop0p1
 mount /dev/mapper/loop0p1 /mnt/
 cp spl/boot.bin /mnt
 cp u-boot.img /mnt
 cp u-boot.bin /mnt
 cp atf.ub /mnt
 umount /dev/mapper/loop0p1
 kpartx -d sd.img
 cp sd.img /tftpboot/

 and program it via u-boot
 tftpb 10000 sd.img
 mmcinfo
 mmc write 10000 0 $filesize
 mmc rescan
 mmc part
 ls mmc 0

psu_init() function contains low level SoC setup generated for every HW
design by Xilinx design tools. xil_io.h is only supporting file to fix
all dependencies from tools. The same solution was used on Xilinx Zynq.

The patch also change CONFIG_SYS_INIT_SP_ADDR to the end of OCM which
stays at the same location all the time.
Bootrom expects starting address to be at 0xfffc0000 that's why this
address is SPL_TEXT_BASE.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2016-05-24 11:15:01 +02:00