Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
Am 20.06.24 um 19:08 schrieb Tom Rini: On Thu, Jun 20, 2024 at 07:03:26PM +0200, Alex Bee wrote: Am 20.06.24 um 12:24 schrieb Quentin Schulz: From: Quentin Schulz No meaningful changes were made to this SoM since February 2021. Nobody from Theobroma has booted anything recent on that product since July 2021 at the latest. The product isn't available to buy anymore and disappeared from our website. This product is therefore unmaintained and it would be disingenuous to say the opposite, so drop support for RK3368 Lion. If you're a user of Lion, feel free to revert this patch or contact our sales/support department. That's a pretty interesting support-strategy. While I really don't care for this board, please don't go ahead and remove the whole TPL-/SPL-part for RK3368 in yet another pointless "cleanup" only because lion was one the of last/only user. Even if EOL RK3368 is getting finally interesting in regards of display pipeline as we are finally getting a OSS gpu driver [0]. I'm planning to add a board which uses TPL/SPL soonish (when my rare spare time allows). Please update the MAINTAINERS file for the relevant to your future platform, or even better possibly get a skeleton of this platform posted. Thanks. I don't think the whole platform would get removed as it has several users (and is maintained) - I just was a bit worried that TPL/SPL support could get removed, but now noticed there is one more user: evb-px5. So: sorry for noise. So I will go the usual way via upstream DT (linux tree) addition and so forth.
Re: [PATCH next 2/2] rockchip: remove support for Theobroma Systems RK3368 Lion
Am 20.06.24 um 12:24 schrieb Quentin Schulz: From: Quentin Schulz No meaningful changes were made to this SoM since February 2021. Nobody from Theobroma has booted anything recent on that product since July 2021 at the latest. The product isn't available to buy anymore and disappeared from our website. This product is therefore unmaintained and it would be disingenuous to say the opposite, so drop support for RK3368 Lion. If you're a user of Lion, feel free to revert this patch or contact our sales/support department. That's a pretty interesting support-strategy. While I really don't care for this board, please don't go ahead and remove the whole TPL-/SPL-part for RK3368 in yet another pointless "cleanup" only because lion was one the of last/only user. Even if EOL RK3368 is getting finally interesting in regards of display pipeline as we are finally getting a OSS gpu driver [0]. I'm planning to add a board which uses TPL/SPL soonish (when my rare spare time allows). Alex [0] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/issues/1
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
Am 22.05.24 um 18:20 schrieb Jonas Karlman:
On 2024-05-22 16:18, Alex Bee wrote:
Am 13.05.24 um 01:22 schrieb Jonas Karlman:
On 2024-05-13 00:34, Alex Bee wrote:
Am 12.05.24 um 23:37 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-12 21:49, Alex Bee wrote:
Am 11.05.24 um 20:47 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-11 19:44, Alex Bee wrote:
Hi Jonas,
Am 11.05.24 um 13:28 schrieb Jonas Karlman:
This series add gpio request() and pinctrl gpio_request_enable() ops so
that a gpio requested pin automatically use gpio pinmux and U-Boot
behaves more similar to Linux kernel.
I'm not sure that's a good idea.
While linux does it the same way, we really shouldn't expect every
software/os/ … which uses DT (now or in future) to implicitly switch the
pin function when using a pin as gpio. So the real fix would probably be
to add the the correct pinctrl settings to the upstream DT of those
boards and sync it later on (not sure those if those SoCs already using
OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now.
I fully agree that the pinctrl for the problematic boards should be
corrected in upstream DT, but that is a separate issue and should not
block adding support for the request()/gpio_request_enable() ops.
While the pcie reset-gpios full board freeze that was my driving factor
to fully implement the gpio request() ops it is not the only use case,
using the gpio cmd on a pin that use a non-gpio pinmux is another.
Or do you see any technical issue with having the gpio request() ops
implemented and having it ensure gpio pinmux is used on a gpio requested
pin? Similar to how gpio/pinctrl is behaving in Linux and on some other
platforms in U-Boot?
No, no general ("technical") issue with adding a .request hook to the gpio
driver. But now you are now moving the original workaround to an even more
invisible place which does things implicitly. Maybe just don't remove the
pinctrl from the boards u-boot-dtsi's - just replace it with
&pcie30x2m1_pins {
rockchip,pins =
<2 RK_PD4 4 &pcfg_pull_none>,
<2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>,
<2 RK_PD5 4 &pcfg_pull_none>;
};
Even if it would (now) work without. It, at least, documents that there are
things left to do for the upstream DT.
This is what I was doing when testing PCIe on ROCK 3B, I would still like
to drop the "bad" workaround for ROCK 3A and E25 and have it fixed in
upstream DT and let it trickle back now that RK356x use OF_UPSTREAM.
I do not see the point of keeping a workaround that no longer is needed,
especially when there is plans to also adjust upstream DT.
Yeah, sure: but that certainly should be done/happen first, before it's
removed here. Everybody knows how long that takes, patches being forgotten
I am fully aware of patches being forgotten :-)
Still, here I try to cleanup a bad workaround that I probably never should
have added in the first place.
Why is it bad? It's incomplete and the correct pin configuration should
have been added to the upstream board DT in the first place. That's what
*-u-boot.dtsi are doing at times :) It's not as worse as adding implicit
pin function switching to a driver to compensate the incomplete/incorrect
upstream board device tree, imho.
From my point-of-view the upstream pinctrl is more correct and I wrongly
added a patch that completely disregarded existing pinctrl just to fix
pci enumeration in U-Boot when no pci device is connected without
thinking of how it could affect linux/bsd, hence why I now think that old
workaround/hack is something bad and something I want to cleanup/remove.
Yeah, sure. That's why I suggested[0] to replace the current override like
...
-&pcie3x2 {
- pinctrl-0 = <&pcie3x2_reset_h>;
-};
-
-&pinctrl {
- pcie {
- pcie3x2_reset_h: pcie3x2-reset-h {
- rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
+&pcie30x2m1_pins {
+ rockchip,pins =
+ <2 RK_PD4 4 &pcfg_pull_none>,
+ <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>,
+ <2 RK_PD5 4 &pcfg_pull_none>;
};
The proper upstream solution should probably add another pinctrl-set to
rk3568-pinctrl.dtsi - someting like
...
+ /omit-if-no-ref/
+ pcie30x2m1_ep_pins: pcie30x2m1-ep-pins {
+ rockchip,pins =
+ /* pcie30x2_clkreqnm1 */
+ <2 RK_PD4 4 &pcfg_pull_none>,
+ /* pcie30x2_perstnm1 */
+ <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>,
+ /* pcie30x2_wakenm1 */
+ <2 RK_PD5 4 &pcfg_pull_none>;
+ };
+
...
and boards needing this just switch from pcie30x2m1_pins to
pcie30x2m1_ep_pins
In my mind the current pinctrl use for pcie3 in U-Boot is describing the
hw much worse than what is done in upstream Linux.
No, not really. It describes pin settings wrong. The DT s
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
Am 13.05.24 um 01:22 schrieb Jonas Karlman:
On 2024-05-13 00:34, Alex Bee wrote:
Am 12.05.24 um 23:37 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-12 21:49, Alex Bee wrote:
Am 11.05.24 um 20:47 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-11 19:44, Alex Bee wrote:
Hi Jonas,
Am 11.05.24 um 13:28 schrieb Jonas Karlman:
This series add gpio request() and pinctrl gpio_request_enable() ops so
that a gpio requested pin automatically use gpio pinmux and U-Boot
behaves more similar to Linux kernel.
I'm not sure that's a good idea.
While linux does it the same way, we really shouldn't expect every
software/os/ … which uses DT (now or in future) to implicitly switch the
pin function when using a pin as gpio. So the real fix would probably be
to add the the correct pinctrl settings to the upstream DT of those
boards and sync it later on (not sure those if those SoCs already using
OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now.
I fully agree that the pinctrl for the problematic boards should be
corrected in upstream DT, but that is a separate issue and should not
block adding support for the request()/gpio_request_enable() ops.
While the pcie reset-gpios full board freeze that was my driving factor
to fully implement the gpio request() ops it is not the only use case,
using the gpio cmd on a pin that use a non-gpio pinmux is another.
Or do you see any technical issue with having the gpio request() ops
implemented and having it ensure gpio pinmux is used on a gpio requested
pin? Similar to how gpio/pinctrl is behaving in Linux and on some other
platforms in U-Boot?
No, no general ("technical") issue with adding a .request hook to the gpio
driver. But now you are now moving the original workaround to an even more
invisible place which does things implicitly. Maybe just don't remove the
pinctrl from the boards u-boot-dtsi's - just replace it with
&pcie30x2m1_pins {
rockchip,pins =
<2 RK_PD4 4 &pcfg_pull_none>,
<2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>,
<2 RK_PD5 4 &pcfg_pull_none>;
};
Even if it would (now) work without. It, at least, documents that there are
things left to do for the upstream DT.
This is what I was doing when testing PCIe on ROCK 3B, I would still like
to drop the "bad" workaround for ROCK 3A and E25 and have it fixed in
upstream DT and let it trickle back now that RK356x use OF_UPSTREAM.
I do not see the point of keeping a workaround that no longer is needed,
especially when there is plans to also adjust upstream DT.
Yeah, sure: but that certainly should be done/happen first, before it's
removed here. Everybody knows how long that takes, patches being forgotten
I am fully aware of patches being forgotten :-)
Still, here I try to cleanup a bad workaround that I probably never should
have added in the first place.
Why is it bad? It's incomplete and the correct pin configuration should
have been added to the upstream board DT in the first place. That's what
*-u-boot.dtsi are doing at times :) It's not as worse as adding implicit
pin function switching to a driver to compensate the incomplete/incorrect
upstream board device tree, imho.
What you were saying in reply to Mark's email is not completely true: Not
all pins are initialized with gpio func as default. It actually depends on
the pin which function the bootrom sets initially. In case of RK356x's
GPIO2_PD6 (the pin in question) it's BT656_D6M0 (func2), for instance. So,
in fact, you are changing it's function when implicitly setting it's func
to gpio (func0).
Sure, bootrom will change pin func on some pins so that it e.g. can read
from storage etc, but in general gpio mux is what most pins will use
after POR.
On my ROCK 3A I see the pcie30x2m1 pins using func0 (gpio) after POR:
=> pinmux status
GPIO2_D4 : gpio
GPIO2_D5 : gpio
GPIO2_D6 : gpio
And with this after a "pci enum":
=> pinmux status
GPIO2_D4 : func-4
GPIO2_D5 : func-4
GPIO2_D6 : gpio
Not sure why your board would use BT656_D6M0 (func2) after POR unless
there is some other code writing to the IOMUX regs.
Oh, I haven't checked on an actual board - I trusted the TRM [0], page 253
GRF_GPIO2D_IOMUX_H[10:8] is (should be) 0x2. But (sadly) there are lot of
blobs involved. for RK35xx SoCs - so maybe something switches the func for
this pin for some reason.
The only thing this series changes is that when a U-Boot drivers use e.g.
gpio_request_by_name("reset-gpios") the referenced pin in DT will
implicitly be configured for gpio func.
I would still like to understand if there is any other reason, not
related to dropping current "bad" PCIe DT workaround, to not to adopt
this implicit configuration and match Linux kernel?
Generally speaking: device trees _must_ represent the actual hardware
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
Am 12.05.24 um 23:37 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-12 21:49, Alex Bee wrote:
Am 11.05.24 um 20:47 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-11 19:44, Alex Bee wrote:
Hi Jonas,
Am 11.05.24 um 13:28 schrieb Jonas Karlman:
This series add gpio request() and pinctrl gpio_request_enable() ops so
that a gpio requested pin automatically use gpio pinmux and U-Boot
behaves more similar to Linux kernel.
I'm not sure that's a good idea.
While linux does it the same way, we really shouldn't expect every
software/os/ … which uses DT (now or in future) to implicitly switch the
pin function when using a pin as gpio. So the real fix would probably be
to add the the correct pinctrl settings to the upstream DT of those
boards and sync it later on (not sure those if those SoCs already using
OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now.
I fully agree that the pinctrl for the problematic boards should be
corrected in upstream DT, but that is a separate issue and should not
block adding support for the request()/gpio_request_enable() ops.
While the pcie reset-gpios full board freeze that was my driving factor
to fully implement the gpio request() ops it is not the only use case,
using the gpio cmd on a pin that use a non-gpio pinmux is another.
Or do you see any technical issue with having the gpio request() ops
implemented and having it ensure gpio pinmux is used on a gpio requested
pin? Similar to how gpio/pinctrl is behaving in Linux and on some other
platforms in U-Boot?
No, no general ("technical") issue with adding a .request hook to the gpio
driver. But now you are now moving the original workaround to an even more
invisible place which does things implicitly. Maybe just don't remove the
pinctrl from the boards u-boot-dtsi's - just replace it with
&pcie30x2m1_pins {
rockchip,pins =
<2 RK_PD4 4 &pcfg_pull_none>,
<2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>,
<2 RK_PD5 4 &pcfg_pull_none>;
};
Even if it would (now) work without. It, at least, documents that there are
things left to do for the upstream DT.
This is what I was doing when testing PCIe on ROCK 3B, I would still like
to drop the "bad" workaround for ROCK 3A and E25 and have it fixed in
upstream DT and let it trickle back now that RK356x use OF_UPSTREAM.
I do not see the point of keeping a workaround that no longer is needed,
especially when there is plans to also adjust upstream DT.
Yeah, sure: but that certainly should be done/happen first, before it's
removed here. Everybody knows how long that takes, patches being forgotten
What you were saying in reply to Mark's email is not completely true: Not
all pins are initialized with gpio func as default. It actually depends on
the pin which function the bootrom sets initially. In case of RK356x's
GPIO2_PD6 (the pin in question) it's BT656_D6M0 (func2), for instance. So,
in fact, you are changing it's function when implicitly setting it's func
to gpio (func0).
Sure, bootrom will change pin func on some pins so that it e.g. can read
from storage etc, but in general gpio mux is what most pins will use
after POR.
On my ROCK 3A I see the pcie30x2m1 pins using func0 (gpio) after POR:
=> pinmux status
GPIO2_D4 : gpio
GPIO2_D5 : gpio
GPIO2_D6 : gpio
And with this after a "pci enum":
=> pinmux status
GPIO2_D4 : func-4
GPIO2_D5 : func-4
GPIO2_D6 : gpio
Not sure why your board would use BT656_D6M0 (func2) after POR unless
there is some other code writing to the IOMUX regs.
Oh, I haven't checked on an actual board - I trusted the TRM [0], page 253
GRF_GPIO2D_IOMUX_H[10:8] is (should be) 0x2. But (sadly) there are lot of
blobs involved. for RK35xx SoCs - so maybe something switches the func for
this pin for some reason.
The only thing this series changes is that when a U-Boot drivers use e.g.
gpio_request_by_name("reset-gpios") the referenced pin in DT will
implicitly be configured for gpio func.
I would still like to understand if there is any other reason, not
related to dropping current "bad" PCIe DT workaround, to not to adopt
this implicit configuration and match Linux kernel?
Generally speaking: device trees _must_ represent the actual hardware
completely independent from any driver or any software. They are NOT
helpers or configuration for drivers. Drivers can use them and have to
adapt to them - not vice versa. So: Being as explict as possible is a must.
At some point, it is planned, to split whole DT "subsystem" from the linux
kernel.
I also have a vague remembering (some mailing list discussion I can't find
right now), that this whole implicit function switching of pins is sort of
"not welcome" in linux anymore. So adding it here also is sort of a "step
back" from that POV.
Alex
[0
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
Am 11.05.24 um 20:47 schrieb Jonas Karlman:
Hi Alex,
On 2024-05-11 19:44, Alex Bee wrote:
Hi Jonas,
Am 11.05.24 um 13:28 schrieb Jonas Karlman:
This series add gpio request() and pinctrl gpio_request_enable() ops so
that a gpio requested pin automatically use gpio pinmux and U-Boot
behaves more similar to Linux kernel.
I'm not sure that's a good idea.
While linux does it the same way, we really shouldn't expect every
software/os/ … which uses DT (now or in future) to implicitly switch the
pin function when using a pin as gpio. So the real fix would probably be
to add the the correct pinctrl settings to the upstream DT of those
boards and sync it later on (not sure those if those SoCs already using
OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now.
I fully agree that the pinctrl for the problematic boards should be
corrected in upstream DT, but that is a separate issue and should not
block adding support for the request()/gpio_request_enable() ops.
While the pcie reset-gpios full board freeze that was my driving factor
to fully implement the gpio request() ops it is not the only use case,
using the gpio cmd on a pin that use a non-gpio pinmux is another.
Or do you see any technical issue with having the gpio request() ops
implemented and having it ensure gpio pinmux is used on a gpio requested
pin? Similar to how gpio/pinctrl is behaving in Linux and on some other
platforms in U-Boot?
No, no general ("technical") issue with adding a .request hook to the gpio
driver. But now you are now moving the original workaround to an even more
invisible place which does things implicitly. Maybe just don't remove the
pinctrl from the boards u-boot-dtsi's - just replace it with
&pcie30x2m1_pins {
rockchip,pins =
<2 RK_PD4 4 &pcfg_pull_none>,
<2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>,
<2 RK_PD5 4 &pcfg_pull_none>;
};
Even if it would (now) work without. It, at least, documents that there are
things left to do for the upstream DT.
What you were saying in reply to Mark's email is not completely true: Not
all pins are initialized with gpio func as default. It actually depends on
the pin which function the bootrom sets initially. In case of RK356x's
GPIO2_PD6 (the pin in question) it's BT656_D6M0 (func2), for instance. So,
in fact, you are changing it's function when implicitly setting it's func
to gpio (func0).
Alex
Regards,
Jonas
Alex
With the gpio and pinctrl ops implemented this series also remove a PCIe
reset-gpios related device lock-up workaround from board u-boot.dtsi.
PX30, RK3066, RK3188, RK356x and RK3588 are the only SoCs that currently
define gpio-ranges props and is affected by this series.
A follow up series adding support for the pinmux status cmd will also
add gpio-ranges props for remaining RK SoCs.
Jonas Karlman (4):
pinctrl: rockchip: Add gpio_request_enable() ops
gpio: rockchip: Add request() ops
rockchip: rk3568-rock-3a: Drop PCIe reset-gpios workaround
rockchip: rk3568-radxa-e25: Drop PCIe reset-gpios workaround
arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 12 ---
arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 12 ---
drivers/gpio/rk_gpio.c| 10 ++
.../pinctrl/rockchip/pinctrl-rockchip-core.c | 31 +++
4 files changed, 41 insertions(+), 24 deletions(-)
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
Hi Jonas, Am 11.05.24 um 13:28 schrieb Jonas Karlman: This series add gpio request() and pinctrl gpio_request_enable() ops so that a gpio requested pin automatically use gpio pinmux and U-Boot behaves more similar to Linux kernel. I'm not sure that's a good idea. While linux does it the same way, we really shouldn't expect every software/os/ … which uses DT (now or in future) to implicitly switch the pin function when using a pin as gpio. So the real fix would probably be to add the the correct pinctrl settings to the upstream DT of those boards and sync it later on (not sure those if those SoCs already using OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now. Alex With the gpio and pinctrl ops implemented this series also remove a PCIe reset-gpios related device lock-up workaround from board u-boot.dtsi. PX30, RK3066, RK3188, RK356x and RK3588 are the only SoCs that currently define gpio-ranges props and is affected by this series. A follow up series adding support for the pinmux status cmd will also add gpio-ranges props for remaining RK SoCs. Jonas Karlman (4): pinctrl: rockchip: Add gpio_request_enable() ops gpio: rockchip: Add request() ops rockchip: rk3568-rock-3a: Drop PCIe reset-gpios workaround rockchip: rk3568-radxa-e25: Drop PCIe reset-gpios workaround arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 12 --- arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 12 --- drivers/gpio/rk_gpio.c| 10 ++ .../pinctrl/rockchip/pinctrl-rockchip-core.c | 31 +++ 4 files changed, 41 insertions(+), 24 deletions(-)
[PATCH] timer-uclass: Always use "clock-frequency" property as fallback
Currently the "clock-frequency" DT property is only being considered as an
fallback if either there is no clock driver, the clock driver implements
the request-op correctly or there is no clock defined for the timer at all.
This patch makes "clock-frequency" also being picked as a fallback if
getting the clock-rate fails, since clk_get(_by_index) will return no
error, if a clock driver does not implement the request-op and does also
not support getting the rate of the clock in question.
timer_post_probe will take care if the property does not exist in the DT or
is defined as 0.
Signed-off-by: Alex Bee
---
This is currently an issue for Rockchip RK3188 and potentially also for RK3368:
The clock driver does not implement the request-op. Even if we would add it:
timer-uclass always picks the first clock and the DT bindings for Rockchip timer
requires us to place the pclk first and and the timer source clock second.
drivers/timer/timer-uclass.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
index 0c2018bfe3..60ff65529a 100644
--- a/drivers/timer/timer-uclass.c
+++ b/drivers/timer/timer-uclass.c
@@ -66,13 +66,13 @@ static int timer_pre_probe(struct udevice *dev)
err = clk_get_by_index(dev, 0, &timer_clk);
if (!err) {
ret = clk_get_rate(&timer_clk);
- if (IS_ERR_VALUE(ret))
- return ret;
- uc_priv->clock_rate = ret;
- } else {
- uc_priv->clock_rate =
- dev_read_u32_default(dev, "clock-frequency", 0);
+ if (!IS_ERR_VALUE(ret)) {
+ uc_priv->clock_rate = ret;
+ return 0;
+ }
}
+
+ uc_priv->clock_rate = dev_read_u32_default(dev,
"clock-frequency", 0);
}
return 0;
--
2.42.0
Re: [PATCH v2 5/5] optee: Support Rockchip OP-TEE binaries
Hi Kever, Am 19.07.23 um 09:28 schrieb Kever Yang: Hi Alex, On 2023/7/18 22:57, Alex Bee wrote: Currently the only ARM Rockchip SoC which is supported by upstream optee-os is RK322x. For all other ARM SoCs a vendor-provided OP-TEE binary has to be used to have a TEE available. Those are using a calling convension different from upstream optee-os. This introduces CONFIG_ROCKCHIP_OPTEE_BINARY which signals that any of those vendor binaries is used and changes the calling convension accordingly. Signed-off-by: Alex Bee --- arch/arm/mach-rockchip/Kconfig | 8 common/spl/spl_optee.S | 4 2 files changed, 12 insertions(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 17dd43155d..83d8a2a056 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -449,6 +449,14 @@ config ROCKCHIP_BOOT_MODE_REG The Soc will enter to different boot mode(defined in asm/arch-rockchip/boot_mode.h) according to the value from this register. +config ROCKCHIP_OPTEE_BINARY + bool "Use a OP-TEE binary provided by Rockchip" + depends on SPL_OPTEE_IMAGE + default y if ROCKCHIP_RK3036 || ROCKCHIP_RK3128 || ROCKCHIP_RK3288 This patch is not need for now. the rk3036 works without OPTEE, and rk3288 is able to use ATF instead for OPTEE which upstreamed by Heiko. Thanks for your review. I'm aware of Heiko's ATF BL32 implemenation for RK3288. But what about RK3128/RK3036? They might wwork w/o RK OPTEE-binaries in regards of SMP bringup, but still you have no TEE. You're right: It's not strictly required to have support for RK OPTEE-binaries, but also it doesn't hurt and it's fully optional to use it for those SoCs. Besides RK's TEE-implementations provide some more services via SMCC calls (DVFS for DRAM, for instance) which are not supported (yet) by upstream variants. I don't like the requirement of this patch either, but unfortunately the TEE binaries RK provides are built with wrong/incompatible flags. Regards, Alex Thanks, - Kever + help + This option enables the usage of vendor-provided OP-TEE binaries. + Say Y if you are using OP-TEE binary provided by Rockchip. + config ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON bool "Disable device boot on power plug-in" depends on PMIC_RK8XX diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S index a269904d38..ea41d8adb6 100644 --- a/common/spl/spl_optee.S +++ b/common/spl/spl_optee.S @@ -7,6 +7,10 @@ #include ENTRY(spl_optee_entry) +#ifdef CONFIG_ROCKCHIP_OPTEE_BINARY + ldr r1, =CONFIG_TEXT_BASE +#else ldr lr, =CONFIG_TEXT_BASE +#endif mov pc, r3 ENDPROC(spl_optee_entry)
[PATCH v2 5/5] optee: Support Rockchip OP-TEE binaries
Currently the only ARM Rockchip SoC which is supported by upstream optee-os is RK322x. For all other ARM SoCs a vendor-provided OP-TEE binary has to be used to have a TEE available. Those are using a calling convension different from upstream optee-os. This introduces CONFIG_ROCKCHIP_OPTEE_BINARY which signals that any of those vendor binaries is used and changes the calling convension accordingly. Signed-off-by: Alex Bee --- arch/arm/mach-rockchip/Kconfig | 8 common/spl/spl_optee.S | 4 2 files changed, 12 insertions(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 17dd43155d..83d8a2a056 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -449,6 +449,14 @@ config ROCKCHIP_BOOT_MODE_REG The Soc will enter to different boot mode(defined in asm/arch-rockchip/boot_mode.h) according to the value from this register. +config ROCKCHIP_OPTEE_BINARY + bool "Use a OP-TEE binary provided by Rockchip" + depends on SPL_OPTEE_IMAGE + default y if ROCKCHIP_RK3036 || ROCKCHIP_RK3128 || ROCKCHIP_RK3288 + help + This option enables the usage of vendor-provided OP-TEE binaries. + Say Y if you are using OP-TEE binary provided by Rockchip. + config ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON bool "Disable device boot on power plug-in" depends on PMIC_RK8XX diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S index a269904d38..ea41d8adb6 100644 --- a/common/spl/spl_optee.S +++ b/common/spl/spl_optee.S @@ -7,6 +7,10 @@ #include ENTRY(spl_optee_entry) +#ifdef CONFIG_ROCKCHIP_OPTEE_BINARY + ldr r1, =CONFIG_TEXT_BASE +#else ldr lr, =CONFIG_TEXT_BASE +#endif mov pc, r3 ENDPROC(spl_optee_entry) -- 2.41.0
[PATCH v2 4/5] rockchip: evb_rk3229: Update/fix README
This updates the evb_rk3229's README on howto create / use the FIT image created by binman. Also fix some wrong paths and update filenames which have changed in recent upstream optee-os versions. Signed-off-by: Alex Bee --- board/rockchip/evb_rk3229/README | 72 +--- 1 file changed, 48 insertions(+), 24 deletions(-) diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README index 9068225e27..a8dcc40f09 100644 --- a/board/rockchip/evb_rk3229/README +++ b/board/rockchip/evb_rk3229/README @@ -13,25 +13,23 @@ Compile the OP-TEE > cd optee_os > make clean - > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x - Get tee.bin in this step, copy it to U-Boot root dir: - > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin + > make CROSS_COMPILE=arm-none-eabi- PLATFORM=rockchip-rk322x + Get tee-raw.bin in this step, copy it to U-Boot root dir: + > cp out/arm-plat-rockchip/core/tee-raw.bin ../u-boot/tee.bin Compile the U-Boot == > cd ../u-boot - > export CROSS_COMPILE=arm-linux-gnueabihf- > make evb-rk3229_defconfig - > make - > make u-boot.itb + > TEE=tee.bin CROSS_COMPILE=arm-linux-gnueabihf- make - Get tpl/u-boot-tpl.bin, spl/u-boot-spl.bin and u-boot.itb in this step. + Get u-boot-rockchip.bin in this step. Compile the rkdeveloptool === Follow instructions in latest README - > cd ../rkflashtool + > cd ../rkdeveloptool > autoreconf -i > ./configure > make @@ -42,30 +40,56 @@ Compile the rkdeveloptool Both origin binaries and Tool are ready now, choose either option 1 or option 2 to deploy U-Boot. -Package the image -= - - > cd ../u-boot - > tools/mkimage -n rk322x -T rksd -d tpl/u-boot-spl.bin idbloader.img - > cat spl/u-boot-spl.bin >> idbloader.img - - Get idbloader.img in this step. - Flash the image to eMMC === Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then: > cd .. - > rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin - > rkdeveloptool wl 64 u-boot/idbloader.img - > rkdeveloptool wl 0x4000 u-boot/u-boot.itb - > rkdeveloptool rd + > rkdeveloptool/rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin + > rkdeveloptool/rkdeveloptool wl 64 u-boot/u-boot-rockchip.bin + > rkdeveloptool/rkdeveloptool rd Flash the image to SD card == - > dd if=u-boot/idbloader.img of=/dev/sdb seek=64 - > dd if=u-boot/u-boot.itb of=/dev/sdb seek=16384 + > dd if=u-boot/u-boot-rockchip.bin of=/dev/sdb seek=64 + +You should be able to get U-Boot log message with OP-TEE boot info: + +U-Boot TPL 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51) +Trying to boot from BOOTROM +Returning to boot ROM... + +U-Boot SPL 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51 +0200) +Trying to boot from MMC1 +I/TC: +I/TC: Non-secure external DT found +I/TC: Switching console to device: /serial@1103 +I/TC: OP-TEE version: 3.22.0-27-g893a762d1 (gcc version 10.3.1 20210621 (release) (15:10.3-2021.07-4)) #1 Sat Jul 15 12:14:36 UTC 2023 arm +I/TC: WARNING: This OP-TEE configuration might be insecure! +I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html +I/TC: Primary CPU initializing +M/TC: Not protecting region 1: 0x6840-0x6860 +I/TC: Primary CPU switching to normal world boot + + +U-Boot 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51 +0200) + +Model: Rockchip RK3229 Evaluation board +DRAM: 1 GiB (effective 992 MiB) +Core: 113 devices, 16 uclasses, devicetree: separate +MMC: mmc@3000: 1, mmc@3002: 0 +Loading Environment from MMC... Card did not respond to voltage select! : -110 +*** Warning - No block device, using default environment + +In:serial@1103 +Out: serial@1103 +Err: serial@1103 +Model: Rockchip RK3229 Evaluation board +Net: +Warning: ethernet@3020 (eth0) using random MAC address - 72:65:2b:f1:c5:0a +eth0: ethernet@3020 +Hit any key to stop autoboot: 0 +=> -You should be able to get U-Boot log message with OP-TEE boot info. For more detail, please reference to: http://opensource.rock-chips.com/wiki_Boot_option -- 2.41.0
[PATCH v2 3/5] rockchip: RK322x: Select SPL_OPTEE_IMAGE
For RK322x series ARM SoCs the OP-TEE is non-optional, as besides the TEE it also provides the PSCI implementation, which is expected to be available by upstream linux. Select CONFIG_SPL_OPTEE_IMAGE if an FIT image is built. Signed-off-by: Alex Bee --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 9d6d20bf8e..17dd43155d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -106,6 +106,7 @@ config ROCKCHIP_RK322X imply ROCKCHIP_COMMON_BOARD imply SPL_SERIAL imply SPL_ROCKCHIP_COMMON_BOARD + select SPL_OPTEE_IMAGE if SPL_FIT imply TPL_SERIAL imply TPL_ROCKCHIP_COMMON_BOARD select TPL_LIBCOMMON_SUPPORT -- 2.41.0
[PATCH v2 2/5] configs: evb-rk3229: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN
An OP-TEE FIT image will fail to extract in SPL because the malloc stack size is currently limited to 0x2000 for evb-rk3229 board. In SPL we do not have to care about size limitations, since we are no longer bound to SRAM limits after DRAM initialization has been done in TPL. Use the default value for CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN in order successfully unpack the FIT image. Signed-off-by: Alex Bee --- configs/evb-rk3229_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index cf73afeded..73015f098c 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -31,7 +31,7 @@ CONFIG_SPL_PAD_TO=0x7f8000 CONFIG_SPL_NO_BSS_LIMIT=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10 CONFIG_SPL_OPTEE_IMAGE=y CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_GPT=y -- 2.41.0
[PATCH v2 1/5] rockchip: Support OP-TEE for ARM in FIT images created by binman
CONFIG_SPL_OPTEE_IMAGE option is used during DRAM size detection for
Rockchip ARM platform to indicate that an OP-TEE binary was already loaded
and a Trusted Execution Environment (TEE) is available in order to
block/reserve a memory-region for it.
This adds a bunch of new `#if's` to u-boot-rockchip.dtsi to include the
OP-TEE binary in the FIT image for ARM SOCs if CONFIG_SPL_OPTEE_IMAGE is
selected.
That makes it a little harder to read, but I opted for that, because all
the duplicates in an extra ARM-OP-TEE-specfic .dtsi would be the greater
evil, IMHO. Besides it's more likley being "forgotten" to sync when changes
in u-boot-rockchip.dtsi are made.
The no longer required rockchip-optee.dtsi and it's inclusions are dropped.
The hardcoded load address is common across all OP-TEE implemenations for
Rockchip (vendor and upstream).
The OP-TEE-binary is non-optional if CONFIG_SPL_OPTEE_IMAGE is selected and
there will be an error if the file does not exist and/or `TEE=` build
option is missing.
Signed-off-by: Alex Bee
---
arch/arm/dts/rk3288-u-boot.dtsi | 1 -
arch/arm/dts/rockchip-optee.dtsi | 64 ---
arch/arm/dts/rockchip-u-boot.dtsi | 38 --
3 files changed, 35 insertions(+), 68 deletions(-)
delete mode 100644 arch/arm/dts/rockchip-optee.dtsi
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 1920698884..c4c5a2d225 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -4,7 +4,6 @@
*/
#include "rockchip-u-boot.dtsi"
-#include "rockchip-optee.dtsi"
/ {
aliases {
diff --git a/arch/arm/dts/rockchip-optee.dtsi b/arch/arm/dts/rockchip-optee.dtsi
deleted file mode 100644
index d84c10cf43..00
--- a/arch/arm/dts/rockchip-optee.dtsi
+++ /dev/null
@@ -1,64 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2020 Google LLC
- */
-
-#include
-
-#if defined(CONFIG_HAS_ROM) && defined(CONFIG_FIT)
-&binman {
- itb {
- filename = "u-boot.itb";
- fit {
- fit,external-offset = ;
- description = "FIT image with OP-TEE support";
- #address-cells = <1>;
-
- images {
- uboot {
- description = "U-Boot";
- type = "standalone";
- os = "U-Boot";
- arch = "arm";
- compression = "none";
- load = ;
-
- u-boot-nodtb {
- };
- };
- optee {
- description = "OP-TEE";
- type = "firmware";
- arch = "arm";
- os = "tee";
- compression = "none";
- load = <(CFG_SYS_SDRAM_BASE +
0x840)>;
- entry = <(CFG_SYS_SDRAM_BASE +
0x840)>;
-
- blob-ext {
- filename = "tee.bin";
- };
- };
- fdt {
- description = CONFIG_SYS_BOARD;
- type = "flat_dt";
- compression = "none";
-
- u-boot-dtb {
- };
- };
- };
-
- configurations {
- default = "conf";
- conf {
- description = CONFIG_SYS_BOARD;
- firmware = "optee";
- loadables = "uboot";
- fdt = "fdt";
- };
- };
- };
- };
-};
-#endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index 2878b80926..be2658e8ef 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -33,9 +33,13 @@
};
};
-#if defined(CONFIG_SPL_FIT) && defined(CONFIG_ARM64)
+#if defined(CONFIG_SPL
[PATCH v2 0/5] rockchip: Support OP-TEE binaries in ARM FIT images
This adds support for OP-TEE binaries to Rockchip's ARM FIT image generation by binman. Currently there is an extra (and outdated) rockchip-optee.dtsi which can create an u-boot.itb which can also hold the OP-TEE binary. It has to be included manually in the respective SoC-specific device trees. But even if that is done, it won't be merged in rockchip-u-boot.bin, which aims to be platform-consistent. The bootable FIT image must therefore currently be created manually. This will be done automatically with this patch-set and a single u-boot-rockchip.bin file with an bootable FIT image containing all binaries will be generated. Additionally this series adds a configuration option which has to be set if a vendor-provided OP-TEE binary is used. This is required as those use a different calling convention. For RK3036, RK3128 and RK3288 SoCs this currently the only option to get an TEE, as no upstream implementation exists for them. Those binaries can be found at [1] There are also some adaptions for RK322x in order to successfully use that FIT image and some changes to the documenation. This series has been tested on RK3229 (both vendor and upstream OP-TEE) and RK3288 (vendor implementation only). [1] https://github.com/rockchip-linux/rkbin Changes in v2: 1/5: * whitespace fixes in rockchip-u-boot.dtsi 2/5: * instead of dropping CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN, set it to the current default value 3/5: * fix: `select SPL_OPTEE_IMAGE` instead of `select CONFIG_SPL_OPTEE_IMAGE` in Kconfig 4/5: * refer to use "tee-raw.bin" instead of "tee-pager_v2.bin" in README (Jerome Forissier) 5/5: * drop empty line in Kconfig help text * fix subject "OPTEE" -> "OP-TEE" * ROCKCHIP_OPTEE_BINARY should depend on SPL_OPTEE_IMAGE only, as the latter depends on SPL_FIT already (via `depends on SPL_LOAD_FIT || SPL_LOAD_FIT_FULL`) Alex Bee (5): rockchip: Support OP-TEE for ARM in FIT images created by binman configs: evb-rk3229: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN rockchip: RK322x: Select SPL_OPTEE_IMAGE rockchip: evb_rk3229: Update/fix README optee: Support Rockchip OP-TEE binaries arch/arm/dts/rk3288-u-boot.dtsi | 1 - arch/arm/dts/rockchip-optee.dtsi | 64 --- arch/arm/dts/rockchip-u-boot.dtsi | 38 ++-- arch/arm/mach-rockchip/Kconfig| 9 board/rockchip/evb_rk3229/README | 72 --- common/spl/spl_optee.S| 4 ++ configs/evb-rk3229_defconfig | 2 +- 7 files changed, 97 insertions(+), 93 deletions(-) delete mode 100644 arch/arm/dts/rockchip-optee.dtsi base-commit: 890233ca5569e5787d8407596a12b9fca80952bf -- 2.41.0
Re: [PATCH v1 4/5] rockchip: evb_rk3229: Update/fix README
Hi Jerome, Am 17.07.23 um 15:42 schrieb Jerome Forissier: On 7/16/23 10:10, Alex Bee wrote: This updates the evb_rk3229's README on howto create / use the FIT image created by binman. Also fix some wrong paths and update filenames which have changed in recent upstream optee-os versions. Signed-off-by: Alex Bee --- board/rockchip/evb_rk3229/README | 72 +--- 1 file changed, 48 insertions(+), 24 deletions(-) diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README index 9068225e27..e4c88bac06 100644 --- a/board/rockchip/evb_rk3229/README +++ b/board/rockchip/evb_rk3229/README @@ -13,25 +13,23 @@ Compile the OP-TEE > cd optee_os > make clean - > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x - Get tee.bin in this step, copy it to U-Boot root dir: - > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin + > make CROSS_COMPILE=arm-none-eabi- PLATFORM=rockchip-rk322x + Get tee-pager_v2.bin in this step, copy it to U-Boot root dir: + > cp out/arm-plat-rockchip/core/tee-pager_v2.bin ../u-boot/tee.bin Since OP-TEE 3.21.0, there is a tee-raw.bin file. I recommend using it instead of tee-pager_v2.bin. Technically they are identical when the OP-TEE "pager" feature is disabled, but the name makes more sense. Thanks for the hint. I'll change that in v2. Regards, Alex
[PATCH v1 5/5] optee: Support Rockchip OPTEE binaries
Currently the only ARM Rockchip SoC which is supported by upstream optee-os is RK322x. For all other ARM SoCs a vendor-provided OP-TEE binary has to be used to have a TEE available. Those are using a calling convension different from upstream optee-os. This introduces CONFIG_ROCKCHIP_OPTEE_BINARY which signals that any of those vendor binaries is used and changes the calling convension accordingly. Signed-off-by: Alex Bee --- arch/arm/mach-rockchip/Kconfig | 9 + common/spl/spl_optee.S | 4 2 files changed, 13 insertions(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 9f12524aeb..41a9c4fe95 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -449,6 +449,15 @@ config ROCKCHIP_BOOT_MODE_REG The Soc will enter to different boot mode(defined in asm/arch-rockchip/boot_mode.h) according to the value from this register. +config ROCKCHIP_OPTEE_BINARY + bool "Use a OP-TEE binary provided by Rockchip" + depends on SPL_FIT && SPL_OPTEE_IMAGE + default y if ROCKCHIP_RK3036 || ROCKCHIP_RK3128 || ROCKCHIP_RK3288 + help + This option enables the usage of vendor-provided OP-TEE binaries. + + Say Y if you are using OP-TEE binary provided by Rockchip. + config ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON bool "Disable device boot on power plug-in" depends on PMIC_RK8XX diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S index a269904d38..ea41d8adb6 100644 --- a/common/spl/spl_optee.S +++ b/common/spl/spl_optee.S @@ -7,6 +7,10 @@ #include ENTRY(spl_optee_entry) +#ifdef CONFIG_ROCKCHIP_OPTEE_BINARY + ldr r1, =CONFIG_TEXT_BASE +#else ldr lr, =CONFIG_TEXT_BASE +#endif mov pc, r3 ENDPROC(spl_optee_entry) -- 2.41.0
[PATCH v1 4/5] rockchip: evb_rk3229: Update/fix README
This updates the evb_rk3229's README on howto create / use the FIT image created by binman. Also fix some wrong paths and update filenames which have changed in recent upstream optee-os versions. Signed-off-by: Alex Bee --- board/rockchip/evb_rk3229/README | 72 +--- 1 file changed, 48 insertions(+), 24 deletions(-) diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README index 9068225e27..e4c88bac06 100644 --- a/board/rockchip/evb_rk3229/README +++ b/board/rockchip/evb_rk3229/README @@ -13,25 +13,23 @@ Compile the OP-TEE > cd optee_os > make clean - > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x - Get tee.bin in this step, copy it to U-Boot root dir: - > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin + > make CROSS_COMPILE=arm-none-eabi- PLATFORM=rockchip-rk322x + Get tee-pager_v2.bin in this step, copy it to U-Boot root dir: + > cp out/arm-plat-rockchip/core/tee-pager_v2.bin ../u-boot/tee.bin Compile the U-Boot == > cd ../u-boot - > export CROSS_COMPILE=arm-linux-gnueabihf- > make evb-rk3229_defconfig - > make - > make u-boot.itb + > TEE=tee.bin CROSS_COMPILE=arm-linux-gnueabihf- make - Get tpl/u-boot-tpl.bin, spl/u-boot-spl.bin and u-boot.itb in this step. + Get u-boot-rockchip.bin in this step. Compile the rkdeveloptool === Follow instructions in latest README - > cd ../rkflashtool + > cd ../rkdeveloptool > autoreconf -i > ./configure > make @@ -42,30 +40,56 @@ Compile the rkdeveloptool Both origin binaries and Tool are ready now, choose either option 1 or option 2 to deploy U-Boot. -Package the image -= - - > cd ../u-boot - > tools/mkimage -n rk322x -T rksd -d tpl/u-boot-spl.bin idbloader.img - > cat spl/u-boot-spl.bin >> idbloader.img - - Get idbloader.img in this step. - Flash the image to eMMC === Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then: > cd .. - > rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin - > rkdeveloptool wl 64 u-boot/idbloader.img - > rkdeveloptool wl 0x4000 u-boot/u-boot.itb - > rkdeveloptool rd + > rkdeveloptool/rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin + > rkdeveloptool/rkdeveloptool wl 64 u-boot/u-boot-rockchip.bin + > rkdeveloptool/rkdeveloptool rd Flash the image to SD card == - > dd if=u-boot/idbloader.img of=/dev/sdb seek=64 - > dd if=u-boot/u-boot.itb of=/dev/sdb seek=16384 + > dd if=u-boot/u-boot-rockchip.bin of=/dev/sdb seek=64 + +You should be able to get U-Boot log message with OP-TEE boot info: + +U-Boot TPL 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51) +Trying to boot from BOOTROM +Returning to boot ROM... + +U-Boot SPL 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51 +0200) +Trying to boot from MMC1 +I/TC: +I/TC: Non-secure external DT found +I/TC: Switching console to device: /serial@1103 +I/TC: OP-TEE version: 3.22.0-27-g893a762d1 (gcc version 10.3.1 20210621 (release) (15:10.3-2021.07-4)) #1 Sat Jul 15 12:14:36 UTC 2023 arm +I/TC: WARNING: This OP-TEE configuration might be insecure! +I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html +I/TC: Primary CPU initializing +M/TC: Not protecting region 1: 0x6840-0x6860 +I/TC: Primary CPU switching to normal world boot + + +U-Boot 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51 +0200) + +Model: Rockchip RK3229 Evaluation board +DRAM: 1 GiB (effective 992 MiB) +Core: 113 devices, 16 uclasses, devicetree: separate +MMC: mmc@3000: 1, mmc@3002: 0 +Loading Environment from MMC... Card did not respond to voltage select! : -110 +*** Warning - No block device, using default environment + +In:serial@1103 +Out: serial@1103 +Err: serial@1103 +Model: Rockchip RK3229 Evaluation board +Net: +Warning: ethernet@3020 (eth0) using random MAC address - 72:65:2b:f1:c5:0a +eth0: ethernet@3020 +Hit any key to stop autoboot: 0 +=> -You should be able to get U-Boot log message with OP-TEE boot info. For more detail, please reference to: http://opensource.rock-chips.com/wiki_Boot_option -- 2.41.0
[PATCH v1 3/5] rockchip: RK322x: select SPL_OPTEE_IMAGE
For RK322x series ARM SoCs the OP-TEE is non-optional, as besides the TEE it also provides the PSCI implementation, which is expected to be available by upstream linux. Select CONFIG_SPL_OPTEE_IMAGE if an FIT image is built. Signed-off-by: Alex Bee --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 9d6d20bf8e..9f12524aeb 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -106,6 +106,7 @@ config ROCKCHIP_RK322X imply ROCKCHIP_COMMON_BOARD imply SPL_SERIAL imply SPL_ROCKCHIP_COMMON_BOARD + select CONFIG_SPL_OPTEE_IMAGE if SPL_FIT imply TPL_SERIAL imply TPL_ROCKCHIP_COMMON_BOARD select TPL_LIBCOMMON_SUPPORT -- 2.41.0
[PATCH v1 2/5] evb-rk3229_defconfig: Drop SPL_STACK_R_MALLOC_SIMPLE_LEN
An OP-TEE FIT image will fail to extract in SPL because the malloc stack size is currently limited to 0x2000 for evb-rk3229 board. In SPL we do not have to care about size limitations, since we are no longer bound to SRAM limits after DRAM initialization has been done in TPL. Drop that definition, so that the default defined will be used, in order to successfully boot that image. Signed-off-by: Alex Bee --- configs/evb-rk3229_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index cf73afeded..b818d11b69 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -31,7 +31,6 @@ CONFIG_SPL_PAD_TO=0x7f8000 CONFIG_SPL_NO_BSS_LIMIT=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000 CONFIG_SPL_OPTEE_IMAGE=y CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_GPT=y -- 2.41.0
[PATCH v1 1/5] rockchip: Support OP-TEE for ARM in FIT images created by binman
CONFIG_SPL_OPTEE_IMAGE option is used during DRAM size detection for
Rockchip ARM platform to indicate that an OP-TEE binary was already loaded
and a Trusted Execution Environment (TEE) is available in order to
block/reserve a memory-region for it.
This adds a bunch of new `#if's` to u-boot-rockchip.dtsi to include the
OP-TEE binary in the FIT image for ARM SOCs if CONFIG_SPL_OPTEE_IMAGE is
selected.
That makes it a little harder to read, but I opted for that, because all
the duplicates in an extra ARM-OP-TEE-specfic .dtsi would be the greater
evil, IMHO. Besides it's more likley being "forgotten" to sync when changes
in u-boot-rockchip.dtsi are made.
The no longer required rockchip-optee.dtsi and it's inclusions are dropped.
The hardcoded load address is common across all OP-TEE implemenations for
Rockchip (vendor and upstream).
The OP-TEE-binary is non-optional if CONFIG_SPL_OPTEE_IMAGE is selected and
there will be an error if the file does not exist and/or `TEE=` build
option is missing.
Signed-off-by: Alex Bee
---
arch/arm/dts/rk3288-u-boot.dtsi | 1 -
arch/arm/dts/rockchip-optee.dtsi | 64 ---
arch/arm/dts/rockchip-u-boot.dtsi | 38 --
3 files changed, 35 insertions(+), 68 deletions(-)
delete mode 100644 arch/arm/dts/rockchip-optee.dtsi
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 1920698884..c4c5a2d225 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -4,7 +4,6 @@
*/
#include "rockchip-u-boot.dtsi"
-#include "rockchip-optee.dtsi"
/ {
aliases {
diff --git a/arch/arm/dts/rockchip-optee.dtsi b/arch/arm/dts/rockchip-optee.dtsi
deleted file mode 100644
index d84c10cf43..00
--- a/arch/arm/dts/rockchip-optee.dtsi
+++ /dev/null
@@ -1,64 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2020 Google LLC
- */
-
-#include
-
-#if defined(CONFIG_HAS_ROM) && defined(CONFIG_FIT)
-&binman {
- itb {
- filename = "u-boot.itb";
- fit {
- fit,external-offset = ;
- description = "FIT image with OP-TEE support";
- #address-cells = <1>;
-
- images {
- uboot {
- description = "U-Boot";
- type = "standalone";
- os = "U-Boot";
- arch = "arm";
- compression = "none";
- load = ;
-
- u-boot-nodtb {
- };
- };
- optee {
- description = "OP-TEE";
- type = "firmware";
- arch = "arm";
- os = "tee";
- compression = "none";
- load = <(CFG_SYS_SDRAM_BASE +
0x840)>;
- entry = <(CFG_SYS_SDRAM_BASE +
0x840)>;
-
- blob-ext {
- filename = "tee.bin";
- };
- };
- fdt {
- description = CONFIG_SYS_BOARD;
- type = "flat_dt";
- compression = "none";
-
- u-boot-dtb {
- };
- };
- };
-
- configurations {
- default = "conf";
- conf {
- description = CONFIG_SYS_BOARD;
- firmware = "optee";
- loadables = "uboot";
- fdt = "fdt";
- };
- };
- };
- };
-};
-#endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index 2878b80926..36a3fbf3ab 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -33,9 +33,13 @@
};
};
-#if defined(CONFIG_SPL_FIT) && defined(CONFIG_ARM64)
+#if defined(CONFIG_SPL_
[PATCH v1 0/5] rockchip: Support OP-TEE binaries in ARM FIT images
This adds support for OP-TEE binaries to Rockchip's ARM FIT image generation by binman. Currently there is an extra (and outdated) rockchip-optee.dtsi which can create an u-boot.itb which can also hold the OP-TEE binary. It has to be included manually in the respective SoC-specific device trees. But even if that is done, it won't be merged in rockchip-u-boot.bin, which aims to be platform-consistent. The bootable FIT image must therefore currently be created manually. This will be done automatically with this patch-set and a single u-boot-rockchip.bin file with an bootable FIT image containing all binaries will be generated. Additionally this series adds a configuration option which has to be set if a vendor-provided OP-TEE binary is used. This is required as those use a different calling convention. For RK3036, RK3128 and RK3288 SoCs this currently the only option to get an TEE, as no upstream implementation exists for them. Those binaries can be found at [1] There are also some adaptions for RK322x in order to successfully use that FIT image and some changes to the documenation. This series has been tested on RK3229 (both vendor and upstream OP-TEE) and RK3288 (vendor implementation only). [1] https://github.com/rockchip-linux/rkbin Alex Bee (5): rockchip: Support OP-TEE for ARM in FIT images created by binman evb-rk3229_defconfig: Drop SPL_STACK_R_MALLOC_SIMPLE_LEN rockchip: RK322x: select SPL_OPTEE_IMAGE rockchip: evb_rk3229: Update/fix README optee: Support Rockchip OPTEE binaries arch/arm/dts/rk3288-u-boot.dtsi | 1 - arch/arm/dts/rockchip-optee.dtsi | 64 --- arch/arm/dts/rockchip-u-boot.dtsi | 38 ++-- arch/arm/mach-rockchip/Kconfig| 10 + board/rockchip/evb_rk3229/README | 72 --- common/spl/spl_optee.S| 4 ++ configs/evb-rk3229_defconfig | 1 - 7 files changed, 97 insertions(+), 93 deletions(-) delete mode 100644 arch/arm/dts/rockchip-optee.dtsi base-commit: e6e67bb9e0a40f3eb3c87d16935192821987c3e0 -- 2.41.0
Re: [PATCH v2 2/5] ARM: dts: rockchip: update rk3xxx.dtsi
Hi all,
I understand that copying dts'es from upstream kernel seems an easy
thing to do, but we should be careful:
Now that mmc-indexes are defined in board level device trees in kernel ,
mmc boot order (which I just fixed some month ago [1]) is different per
board.
This is now broken again - at least for rk3188 and rk3399 (from what
I've seen) and it is not fixable with an extra -u-boot.dtsi.
Any idea (without having to define an extra config include/configs per
board?)
[1]
https://github.com/u-boot/u-boot/commit/b212ad24a604b00b240add35516b7381965deb31
Alex
Am 25.06.21 um 15:26 schrieb Johan Jonker:
> In the Linux DT the file rk3xxx.dtsi is shared between
> rk3066 and rk3188. This file has recently had some updates.
> For a future rk3066 support in U-boot this file must also update.
> Move U-boot specific things in a rk3xxx-u-boot.dtsi file.
>
> Signed-off-by: Johan Jonker
> Reviewed-by: Kever Yang
> ---
>
> Changed V2:
> add vpu node
> changed u-boot include
> ---
> arch/arm/dts/rk3188-radxarock.dts | 4 +
> arch/arm/dts/rk3188.dtsi | 1 +
> arch/arm/dts/rk3xxx-u-boot.dtsi | 35 +++
> arch/arm/dts/rk3xxx.dtsi | 215
> +-
> 4 files changed, 181 insertions(+), 74 deletions(-)
> create mode 100644 arch/arm/dts/rk3xxx-u-boot.dtsi
>
> diff --git a/arch/arm/dts/rk3188-radxarock.dts
> b/arch/arm/dts/rk3188-radxarock.dts
> index 61367126ba..10527a052d 100644
> --- a/arch/arm/dts/rk3188-radxarock.dts
> +++ b/arch/arm/dts/rk3188-radxarock.dts
> @@ -12,6 +12,10 @@
> model = "Radxa Rock";
> compatible = "radxa,rock", "rockchip,rk3188";
>
> + aliases {
> + mmc0 = &mmc0;
> + };
> +
> chosen {
> /* stdout-path = &uart2; */
> stdout-path = "serial2:115200n8";
> diff --git a/arch/arm/dts/rk3188.dtsi b/arch/arm/dts/rk3188.dtsi
> index 7bcca6a02d..d872dac174 100644
> --- a/arch/arm/dts/rk3188.dtsi
> +++ b/arch/arm/dts/rk3188.dtsi
> @@ -8,6 +8,7 @@
> #include
> #include
> #include "rk3xxx.dtsi"
> +#include "rk3xxx-u-boot.dtsi"
>
> / {
> compatible = "rockchip,rk3188";
> diff --git a/arch/arm/dts/rk3xxx-u-boot.dtsi b/arch/arm/dts/rk3xxx-u-boot.dtsi
> new file mode 100644
> index 00..581594c35d
> --- /dev/null
> +++ b/arch/arm/dts/rk3xxx-u-boot.dtsi
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/ {
> + noc: syscon@10128000 {
> + compatible = "rockchip,rk3188-noc", "syscon";
> + reg = <0x10128000 0x2000>;
> + u-boot,dm-spl;
> + };
> +
> + dmc: dmc@2002 {
> + /* unreviewed u-boot-specific binding */
> + compatible = "rockchip,rk3188-dmc", "syscon";
> + reg = <0x2002 0x3fc
> +0x2004 0x294>;
> + clocks = <&cru PCLK_DDRUPCTL>, <&cru PCLK_PUBL>;
> + clock-names = "pclk_ddrupctl", "pclk_publ";
> + rockchip,cru = <&cru>;
> + rockchip,grf = <&grf>;
> + rockchip,pmu = <&pmu>;
> + rockchip,noc = <&noc>;
> + u-boot,dm-spl;
> + };
> +};
> +
> +&grf {
> + u-boot,dm-spl;
> +};
> +
> +&pmu {
> + u-boot,dm-spl;
> +};
> +
> +&uart2 {
> + clock-frequency = <2400>;
> +};
> diff --git a/arch/arm/dts/rk3xxx.dtsi b/arch/arm/dts/rk3xxx.dtsi
> index 612ed44bd6..616a828e0c 100644
> --- a/arch/arm/dts/rk3xxx.dtsi
> +++ b/arch/arm/dts/rk3xxx.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0+ OR X11
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> /*
> * Copyright (c) 2013 MundoReader S.L.
> * Author: Heiko Stuebner
> @@ -6,9 +6,12 @@
>
> #include
> #include
> -#include "skeleton.dtsi"
> +#include
>
> / {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> interrupt-parent = <&gic>;
>
> aliases {
> @@ -18,9 +21,6 @@
> i2c2 = &i2c2;
> i2c3 = &i2c3;
> i2c4 = &i2c4;
> - mshc0 = &emmc;
> - mshc1 = &mmc0;
> - mshc2 = &mmc1;
> serial0 = &uart0;
> serial1 = &uart1;
> serial2 = &uart2;
> @@ -29,47 +29,6 @@
> spi1 = &spi1;
> };
>
> - amba {
> - compatible = "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - dmac1_s: dma-controller@20018000 {
> - compatible = "arm,pl330", "arm,primecell";
> - reg = <0x20018000 0x4000>;
> - interrupts = ,
> - ;
> - #dma-cells = <1>;
> - arm,pl330-broken-no-flushp;
> - clocks = <&cru ACLK_DMA1>;
> - clock-names = "apb_pclk";
> - };
> -
> - dmac1_ns: dma-controller@2001c000 {
> - compatible = "arm,pl330", "arm,primecell";
Re: [RFC PATCH v1 0/6] add rk3318 A95X Z2 board
Hi Johan,
Am 30.06.21 um 18:22 schrieb Johan Jonker:
With a new board from a recent Linux DT the U-boot rk3328.dtsi
is in need for an update.
Please advise what to do with usb3 regulators, aliases and
other stuff that has to change.
Also some of the U-boot board files could use some
dtbs_check for bogus properties and restyling... ;)
While at bogus properties:
The ddc-i2c-scl-* properties you are defining in the hdmi node of
rk3318-a95x-z2.dts look like an leftover from vendor kernel: they do not
exist for the upstream dw-hdmi driver in neither u-boot nor kernel.
(Not sure this would pop up with dtbs_check currently)
Alex.
rk3328 USB2 and USB3 only roughly tested.
===
Howto use:
Compile bl31.elf:
git clone --depth 1 https://github.com/ARM-software/arm-trusted-firmware.git
cd arm-trusted-firmware
make realclean
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3328
export BL31=//arm-trusted-firmware/build/rk3328/release/bl31/bl31.elf
cd ..
Compile U-boot:
git clone --depth 1 https://github.com/u-boot/u-boot.git uboot
cd uboot
make CROSS_COMPILE=aarch64-linux-gnu- a95x-z2-rk3318_defconfig all
===
Use U-boot to create a GPT on a SD card,
because of partition GUID and sizes.
mmc dev 0
mmc info
gpt write mmc 0 $partitions
mmc part
===
Write to SD card:
export DISK=/dev/mmcblk0
sudo dd if=./idbloader.img of=${DISK} seek=64
sudo dd if=./u-boot.itb of=${DISK} seek=16384
sync
===
Format boot partition with fat16.
Add /Image and /rk3318-a95x-z2.dtb
Add extlinux dir with extlinux.conf
label kernel
kernel /Image
fdt /rk3318-a95x-z2.dtb
append root=/dev/mmcblk0p5 rw console=tty0 console=ttyS2,150n8
earlycon=uart8250,mmio32,0xff13,keep $
===
Use fastboot:
Hit any key to stop autoboot:
usb start
usb dev 1
fastboot usb 1
=
sudo fastboot devices -l
sudo fastboot erase loader1
sudo fastboot erase loader2
sudo fastboot flash loader1 idbloader.img
sudo fastboot flash loader2 u-boot.itb
=
ctrl-c
reset
===
Johan Jonker (6):
arm: dts: rockchip: update rk3328.dtsi
arm: dts: rockchip: remove usb_host0_xhci node from rk3328-u-boot.dtsi
arm: dts: rockchip: move mmc aliases to board files
arm: dts: rockchip: move spi0 u-boot,dm-pre-reloc and alias to rk3328
board files
rockchip: rk3318: add a95x-z2-rk3318_defconfig file
arm: dts: rockchip: add rk3318 A95X Z2 board
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi| 59 +
arch/arm/dts/rk3318-a95x-z2.dts| 384 +
arch/arm/dts/rk3328-evb-u-boot.dtsi| 2 +-
arch/arm/dts/rk3328-evb.dts| 8 +-
arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-nanopi-r2s.dts | 6 +-
arch/arm/dts/rk3328-roc-cc-u-boot.dtsi | 4 +-
arch/arm/dts/rk3328-roc-cc.dts | 7 +-
arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 4 +-
arch/arm/dts/rk3328-rock-pi-e.dts | 7 +-
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 10 +-
arch/arm/dts/rk3328-rock64.dts | 7 +-
arch/arm/dts/rk3328-u-boot.dtsi| 21 --
arch/arm/dts/rk3328.dtsi | 109
board/rockchip/evb_rk3328/MAINTAINERS | 6 +
configs/a95x-z2-rk3318_defconfig | 102
doc/board/rockchip/rockchip.rst| 2 +
18 files changed, 661 insertions(+), 80 deletions(-)
create mode 100644 arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3318-a95x-z2.dts
create mode 100644 configs/a95x-z2-rk3318_defconfig
[PATCH] rockchip: Fix MMC boot order
Basically all, i.e. rk3036.dtsi, rk3128.dtsi, rk3xxx.dtsi, rk322x.dtsi, rk3288.dtsi, rk3308-u-boot.dtsi, rk3328-u-boot.dtsi, rk3399-u-boot.dtsi and px30-u-boot.dtsi Rockchip SoC devicetrees which have mmc indexes are defining eMMC as mmc0 and sdmmc as mmc1. This means that the rule to try to boot from the SD card first is ignored, which as per comment is what we want and is important for distros, which rely on that. Fix this by setting the correct mmc index, i.e. first from mmc1 (SD card), second from mmc0 (eMMC). Signed-off-by: Alex Bee --- include/configs/rockchip-common.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h index 0b9e24d1db..ba7061a287 100644 --- a/include/configs/rockchip-common.h +++ b/include/configs/rockchip-common.h @@ -14,11 +14,11 @@ #ifndef CONFIG_SPL_BUILD -/* First try to boot from SD (index 0), then eMMC (index 1) */ +/* First try to boot from SD (index 1), then eMMC (index 0) */ #if CONFIG_IS_ENABLED(CMD_MMC) #define BOOT_TARGET_MMC(func) \ - func(MMC, mmc, 0) \ - func(MMC, mmc, 1) + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) #else #define BOOT_TARGET_MMC(func) #endif -- 2.27.0
[PATCH] rockchip: sdram: fix dram_init_banksize
Currently 2.5 GB is calculated as DRAM size for a 1 GB RK322x board
if CONFIG_SPL_OPTEE is set. This is troublesome when booting a
linux kernel since this size will be injected in FDT of the kernel.
gd->bd->bi_dram[0].start (which is basically CONFIG_SYS_SDRAM_BASE)
must not be taken into consideration for calculation of second bank
size, since this offset is already included in calculation of "top".
After applying this patch 992 MB (1024 MB - 32 MB reserved for
optee-os) is correctly calculated and has also been verified on
2 GB boards.
Signed-off-by: Alex Bee
---
arch/arm/mach-rockchip/sdram.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 24fe6cc8f0..4c637b7767 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -56,16 +56,14 @@ int dram_init_banksize(void)
- CONFIG_SYS_SDRAM_BASE;
gd->bd->bi_dram[1].start = tos_parameter->tee_mem.phy_addr +
tos_parameter->tee_mem.size;
- gd->bd->bi_dram[1].size = gd->bd->bi_dram[0].start
- + top - gd->bd->bi_dram[1].start;
+ gd->bd->bi_dram[1].size = top - gd->bd->bi_dram[1].start;
} else {
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
gd->bd->bi_dram[0].size = 0x840;
/* Reserve 32M for OPTEE with TA */
gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE
+ gd->bd->bi_dram[0].size + 0x200;
- gd->bd->bi_dram[1].size = gd->bd->bi_dram[0].start
- + top - gd->bd->bi_dram[1].start;
+ gd->bd->bi_dram[1].size = top - gd->bd->bi_dram[1].start;
}
#else
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
--
2.25.1
