2018-05-06 21:58:06 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0+
|
2012-06-13 07:29:47 +00:00
|
|
|
#
|
|
|
|
|
# (C) Copyright 2000-2006
|
|
|
|
|
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
|
|
|
|
|
|
2013-11-21 08:06:44 +00:00
|
|
|
obj-y = cpu_info.o
|
2013-10-17 08:34:48 +00:00
|
|
|
obj-y += emac.o
|
|
|
|
|
|
|
|
|
|
obj-$(CONFIG_DISPLAY_BOARDINFO) += board.o
|
2018-05-02 10:09:23 +00:00
|
|
|
obj-$(CONFIG_TMU_TIMER) += ../../sh/lib/time.o
|
2013-11-21 08:06:44 +00:00
|
|
|
obj-$(CONFIG_R8A7740) += lowlevel_init.o cpu_info-r8a7740.o pfc-r8a7740.o
|
2018-05-02 10:09:23 +00:00
|
|
|
obj-$(CONFIG_RCAR_GEN2) += lowlevel_init_ca15.o cpu_info-rcar.o
|
2023-10-16 09:25:41 +00:00
|
|
|
obj-$(CONFIG_RCAR_64) += lowlevel_init_gen3.o
|
|
|
|
|
obj-$(CONFIG_RCAR_GEN3) += cpu_info-rcar.o memmap-gen3.o
|
|
|
|
|
obj-$(CONFIG_RCAR_GEN4) += cpu_info-rcar.o memmap-gen3.o
|
2021-03-17 14:11:50 +00:00
|
|
|
obj-$(CONFIG_RZ_G2) += cpu_info-rzg.o
|
2023-10-16 09:25:41 +00:00
|
|
|
obj-$(CONFIG_RZG2L) += cpu_info-rzg2l.o memmap-rzg2l.o
|
ARM: rmobile: Add recovery SPL for R-Car Gen3
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2018-10-03 10:44:13 +00:00
|
|
|
|
2020-10-27 12:06:51 +00:00
|
|
|
ifneq ($(CONFIG_R8A779A0),)
|
|
|
|
|
obj-$(CONFIG_ARMV8_PSCI) += psci-r8a779a0.o
|
|
|
|
|
endif
|
|
|
|
|
|
ARM: rmobile: Add recovery SPL for R-Car Gen3
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2018-10-03 10:44:13 +00:00
|
|
|
OBJCOPYFLAGS_u-boot-spl.srec := -O srec
|
|
|
|
|
quiet_cmd_objcopy = OBJCOPY $@
|
|
|
|
|
cmd_objcopy = $(OBJCOPY) --gap-fill=0x00 $(OBJCOPYFLAGS) \
|
|
|
|
|
$(OBJCOPYFLAGS_$(@F)) $< $@
|
|
|
|
|
|
|
|
|
|
spl/u-boot-spl.srec: spl/u-boot-spl FORCE
|
|
|
|
|
$(call if_changed,objcopy)
|
|
|
|
|
|
2023-06-19 22:43:18 +00:00
|
|
|
srec_cat_gte_160 := ${shell expr `srec_cat -VERSION | grep ^srec_cat | sed 's/^.* //g' | cut -f1-2 -d.` \>= "1.60"}
|
|
|
|
|
ifeq "$(srec_cat_gte_160)" "1"
|
|
|
|
|
srec_cat_le_cmd := "-constant-l-e"
|
|
|
|
|
else
|
|
|
|
|
srec_cat_le_cmd := "-l-e-constant"
|
|
|
|
|
endif
|
|
|
|
|
|
2021-03-15 22:24:06 +00:00
|
|
|
ifneq ($(CONFIG_R8A774C0)$(CONFIG_R8A77990)$(CONFIG_R8A77995),)
|
ARM: rmobile: Add recovery SPL for R-Car Gen3
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2018-10-03 10:44:13 +00:00
|
|
|
#
|
|
|
|
|
# The first 6 generate statements generate the R-Car Gen3 SCIF loader header.
|
|
|
|
|
# The subsequent generate statements represent the following chunk of assembler
|
|
|
|
|
# code, which copies the loaded data from 0xe6304030 to 0xe6318000. This is to
|
|
|
|
|
# work around a limitation of the D3/E3 BootROM, which does not permit loading
|
|
|
|
|
# to 0xe6318000 directly.
|
|
|
|
|
#
|
|
|
|
|
# mov x0, #0xe6000000
|
|
|
|
|
# orr x0, x0, #0x00300000
|
|
|
|
|
# orr x1, x0, #0x00004000
|
|
|
|
|
# orr x1, x1, #0x00000030
|
|
|
|
|
#
|
|
|
|
|
# orr x2, x0, #0x00018000
|
|
|
|
|
# mov x0, x2
|
|
|
|
|
# mov x3, #0x7000
|
|
|
|
|
#1: ldp x4, x5, [x1], #16
|
|
|
|
|
#
|
|
|
|
|
# stp x4, x5, [x2], #16
|
|
|
|
|
# subs x3, x3, #16
|
|
|
|
|
# b.ge 1b
|
|
|
|
|
# br x0
|
|
|
|
|
#
|
|
|
|
|
quiet_cmd_srec_cat = SRECCAT $@
|
|
|
|
|
cmd_srec_cat = srec_cat -output $@ -M 8 $< -M 8 \
|
|
|
|
|
-offset -0x13fd0 \
|
|
|
|
|
-Output_Block_Size 16 \
|
2023-06-19 22:43:18 +00:00
|
|
|
-generate 0xe6300400 0xe6300404 $(srec_cat_le_cmd) 0x0 4 \
|
|
|
|
|
-generate 0xe630048c 0xe6300490 $(srec_cat_le_cmd) 0x0 4 \
|
|
|
|
|
-generate 0xe63005d4 0xe63005d8 $(srec_cat_le_cmd) 0xe6304000 4 \
|
|
|
|
|
-generate 0xe63006e4 0xe63006e8 $(srec_cat_le_cmd) $2 4 \
|
|
|
|
|
-generate 0xe6301154 0xe6301158 $(srec_cat_le_cmd) 0xe6304000 4 \
|
|
|
|
|
-generate 0xe6301264 0xe6301268 $(srec_cat_le_cmd) $2 4 \
|
|
|
|
|
-generate 0xe6304000 0xe6304004 $(srec_cat_le_cmd) 0xd2bcc000 4 \
|
|
|
|
|
-generate 0xe6304004 0xe6304008 $(srec_cat_le_cmd) 0xb26c0400 4 \
|
|
|
|
|
-generate 0xe6304008 0xe630400c $(srec_cat_le_cmd) 0xb2720001 4 \
|
|
|
|
|
-generate 0xe630400c 0xe6304010 $(srec_cat_le_cmd) 0xb27c0421 4 \
|
|
|
|
|
-generate 0xe6304010 0xe6304014 $(srec_cat_le_cmd) 0xb2710402 4 \
|
|
|
|
|
-generate 0xe6304014 0xe6304018 $(srec_cat_le_cmd) 0xaa0203e0 4 \
|
|
|
|
|
-generate 0xe6304018 0xe630401c $(srec_cat_le_cmd) 0xd28e0003 4 \
|
|
|
|
|
-generate 0xe630401c 0xe6304020 $(srec_cat_le_cmd) 0xa8c11424 4 \
|
|
|
|
|
-generate 0xe6304020 0xe6304024 $(srec_cat_le_cmd) 0xa8811444 4 \
|
|
|
|
|
-generate 0xe6304024 0xe6304028 $(srec_cat_le_cmd) 0xf1004063 4 \
|
|
|
|
|
-generate 0xe6304028 0xe630402c $(srec_cat_le_cmd) 0x54ffffaa 4 \
|
|
|
|
|
-generate 0xe630402c 0xe6304030 $(srec_cat_le_cmd) 0xd61f0000 4
|
ARM: rmobile: Add recovery SPL for R-Car Gen3
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2018-10-03 10:44:13 +00:00
|
|
|
else
|
|
|
|
|
quiet_cmd_srec_cat = SRECCAT $@
|
|
|
|
|
cmd_srec_cat = srec_cat -output $@ -M 8 $< -M 8 \
|
|
|
|
|
-Output_Block_Size 16 \
|
2023-06-19 22:43:18 +00:00
|
|
|
-generate 0xe6300400 0xe6300404 $(srec_cat_le_cmd) 0x0 4 \
|
|
|
|
|
-generate 0xe630048c 0xe6300490 $(srec_cat_le_cmd) 0x0 4 \
|
|
|
|
|
-generate 0xe63005d4 0xe63005d8 $(srec_cat_le_cmd) $(CONFIG_SPL_TEXT_BASE) 4 \
|
|
|
|
|
-generate 0xe63006e4 0xe63006e8 $(srec_cat_le_cmd) $2 4 \
|
|
|
|
|
-generate 0xe6301154 0xe6301158 $(srec_cat_le_cmd) $(CONFIG_SPL_TEXT_BASE) 4 \
|
|
|
|
|
-generate 0xe6301264 0xe6301268 $(srec_cat_le_cmd) $2 4
|
ARM: rmobile: Add recovery SPL for R-Car Gen3
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2018-10-03 10:44:13 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
spl/u-boot-spl.scif: spl/u-boot-spl.srec spl/u-boot-spl.bin
|
|
|
|
|
$(call cmd,srec_cat,$(shell wc -c spl/u-boot-spl.bin | awk '{printf("0x%08x\n",$$1)}'))
|
|
|
|
|
|
|
|
|
|
# if srec_cat is present build u-boot-spl.scif by default
|
|
|
|
|
has_srec_cat = $(call try-run,srec_cat -VERSion,y,n)
|
2020-07-19 19:56:01 +00:00
|
|
|
INPUTS-$(has_srec_cat) += u-boot-spl.scif
|
ARM: rmobile: Add recovery SPL for R-Car Gen3
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2018-10-03 10:44:13 +00:00
|
|
|
CLEAN_FILES += u-boot-spl.scif
|
