Re: [PATCH] rockchip: Add delay after link-training
On Sat, 2020-06-27 at 20:57 +0800, Kever Yang wrote: > Hi Kurt, > > > On 2020/6/4 上午5:17, Peter Geis wrote: > > > > > On Tue, Jun 2, 2020 at 11:12 AM Kurt Miller > > wrote: > > > > > > On Tue, 2020-06-02 at 10:23 +0800, Shawn Lin wrote: > > > > > > > > 在 2020/6/2 9:59, Kever Yang 写道: > > > > > > > > > > Hi Kurt, > > > > > > > > > > On 2020/6/2 上午4:30, Kurt Miller wrote: > > > > > > > > > > > > On at least the RockPro64, many cards will trip a > > > > > > synchronous abort when first accessing PCIe config space > > > > > > during bus scanning. A delay after link training allows > > > > > > some of these cards to function. > > > > > > > > > > > > Signed-off-by: Kurt Miller > > > > > > --- > > > > > > On the RockPro64, some pci cards trip a synchronous abort when > > > > > > scanning the > > > > > > pci bus. For example with HighPoint Rocket Raid 640L which is based > > > > > > on > > > > > > Marvell 88SE9230 I see this: > > > > > > > > > > > > => pci > > > > > > "Synchronous Abort" handler, esr 0x96000210 > > > > > > elr: 0022d034 lr : 0022cfd0 (reloc) > > > > > > elr: f4568034 lr : f4567fd0 > > > > > > x0 : 0010 x1 : f800 > > > > > > x2 : x3 : 0010 > > > > > > x4 : f2559290 x5 : > > > > > > x6 : 0001 x7 : f2559860 > > > > > > x8 : 0030 x9 : 0008 > > > > > > x10: 0010 x11: f251fd1c > > > > > > x12: 1421 x13: 1468 > > > > > > x14: f251fd4c x15: > > > > > > x16: 00060001 x17: 001f > > > > > > x18: f2532dc0 x19: f251fcd0 > > > > > > x20: 0001 x21: > > > > > > x22: 0001 x23: f45d4000 > > > > > > x24: x25: f45bc000 > > > > > > x26: x27: > > > > > > x28: f2541440 x29: f251fc20 > > > > > > > > > > > > Code: 54c1 35a5 93407c00 f9400081 (b8616800) > > > > > > Resetting CPU ... > > > > > > > > > > > > Adding a delay after link training works-around the problem. I > > > > > > added this > > > > > > delay to the OpenBSD rkpcie driver as well: > > > > > > > > > > > > https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 > > > > > > > > > > > > > > > > > > HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield > > > > > > SAS9211-4i > > > > > > needs a 1 second delay, so I arbitrarily decided on 2 seconds. > > > > > > > > > > > > The delay work-around was originally discovered by nuumio: > > > > > > https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee > > > > > > > > > > > > > > > > > > drivers/pci/pcie_rockchip.c | 8 > > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > > > diff --git a/drivers/pci/pcie_rockchip.c > > > > > > b/drivers/pci/pcie_rockchip.c > > > > > > index 0edc2464a8..51cfbf6b18 100644 > > > > > > --- a/drivers/pci/pcie_rockchip.c > > > > > > +++ b/drivers/pci/pcie_rockchip.c > > > > > > @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct > > > > > > udevice > > > > > > *dev) > > > > > > goto err_power_off_phy; > > > > > > } > > > > > > +/* > > > > > > + * XXX: On at least the RockPro64, many cards will trip a > > > > > > + * synchronous abort when first accessing PCIe config space > > > > > > + * during bus scanning. A delay after link training allows > > > > > > +
Re: [PATCH] rockchip: Add delay after link-training
On Tue, 2020-06-02 at 10:23 +0800, Shawn Lin wrote: > > 在 2020/6/2 9:59, Kever Yang 写道: > > > > Hi Kurt, > > > > On 2020/6/2 上午4:30, Kurt Miller wrote: > > > > > > On at least the RockPro64, many cards will trip a > > > synchronous abort when first accessing PCIe config space > > > during bus scanning. A delay after link training allows > > > some of these cards to function. > > > > > > Signed-off-by: Kurt Miller > > > --- > > > On the RockPro64, some pci cards trip a synchronous abort when > > > scanning the > > > pci bus. For example with HighPoint Rocket Raid 640L which is based on > > > Marvell 88SE9230 I see this: > > > > > > => pci > > > "Synchronous Abort" handler, esr 0x96000210 > > > elr: 0022d034 lr : 0022cfd0 (reloc) > > > elr: f4568034 lr : f4567fd0 > > > x0 : 0010 x1 : f800 > > > x2 : x3 : 0010 > > > x4 : f2559290 x5 : > > > x6 : 0001 x7 : f2559860 > > > x8 : 0030 x9 : 0008 > > > x10: 0010 x11: f251fd1c > > > x12: 1421 x13: 1468 > > > x14: f251fd4c x15: > > > x16: 00060001 x17: 001f > > > x18: f2532dc0 x19: f251fcd0 > > > x20: 0001 x21: > > > x22: 0001 x23: f45d4000 > > > x24: x25: f45bc000 > > > x26: x27: > > > x28: f2541440 x29: f251fc20 > > > > > > Code: 54c1 35a5 93407c00 f9400081 (b8616800) > > > Resetting CPU ... > > > > > > Adding a delay after link training works-around the problem. I added this > > > delay to the OpenBSD rkpcie driver as well: > > > > > > https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 > > > > > > > > > > > > HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield > > > SAS9211-4i > > > needs a 1 second delay, so I arbitrarily decided on 2 seconds. > > > > > > The delay work-around was originally discovered by nuumio: > > > https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee > > > > > > > > > > > > drivers/pci/pcie_rockchip.c | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c > > > index 0edc2464a8..51cfbf6b18 100644 > > > --- a/drivers/pci/pcie_rockchip.c > > > +++ b/drivers/pci/pcie_rockchip.c > > > @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct udevice > > > *dev) > > > goto err_power_off_phy; > > > } > > > + /* > > > + * XXX: On at least the RockPro64, many cards will trip a > > > + * synchronous abort when first accessing PCIe config space > > > + * during bus scanning. A delay after link training allows > > > + * some of these cards to function. > > > + */ > > > + mdelay(2000); > > I don't understand what kind of delay for init needs 2 Seconds, root > > cause will preferred. Hi Kever, While working on this issue for the OpenBSD PCIe driver I was not able to determine the root cause. I tested the following adapters: ROCKPro64 2 Port SATA StarTech PEXSAT32 2 Port SATA Samsung 970 Evo NVMe w/m.2 adapter IO CREST SI-PEX40148 2 Port SATA IO CREST SI-PEX40057 4 port HighPoint Rocket Raid 640L Crossfield SAS9211-4i Del PERC H200 Dell PERC 6/i Intel Gigabit VT Quad Port Server All of the above adapters successfully link trained, however three of them would panic upon the first read of the PCI config space. nuumio's work-around of placing a delay after link-training allows these cards to work. HighPoint Rocket Raid 640L ~1.75 sec delay Crossfield SAS9211-4i ~1 sec delay Dell PERC H200 ~1 sec delay In attempt to determine if there was a way to detect how long to wait, I compared every status and debug register documented in the rk3399 TRM part 2 for the PCI controller. I compared the values pre-delay and post-delay. I was not able to find a value that would indicate it was safe to proceed. > Strictly speaking, how long should we need for this had been provided, > see this: > > https://patchwork.kernel.org/patch/11561977/ > > If you need more dela
Re: [PATCH] rockchip: Add delay after link-training
On Tue, 2020-06-02 at 02:16 +0530, Jagan Teki wrote:
> On Tue, Jun 2, 2020 at 2:00 AM Kurt Miller wrote:
> >
> >
> > On at least the RockPro64, many cards will trip a
> > synchronous abort when first accessing PCIe config space
> > during bus scanning. A delay after link training allows
> > some of these cards to function.
> Can you check does the SoC has external PCIe pwr-pin GPIO?
>
> I did see unstable SSD behavior on rock960 but fixed with this.
> https://github.com/radxa/u-boot/blob/stable-4.4-rockpi4/board/rockchip/evb_rk3399/evb-rk3399.c#L168
The schematic has:
GPIO1_D0/TCPD_VBUS_SOURCE2_d ---L26>>PCIE_PWR
and arch/arm/dts/rk3399-rockpro64.dtsi has:
{
pcie {
pcie_pwr_en: pcie-pwr-en {
rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO _pull_none>;
};
};
};
Does that answer your question? I'm rather new at this so
I may need more guidance if I miss understood your question.
Thanks,
-Kurt
[PATCH] rockchip: Add delay after link-training
On at least the RockPro64, many cards will trip a synchronous abort when first accessing PCIe config space during bus scanning. A delay after link training allows some of these cards to function. Signed-off-by: Kurt Miller --- On the RockPro64, some pci cards trip a synchronous abort when scanning the pci bus. For example with HighPoint Rocket Raid 640L which is based on Marvell 88SE9230 I see this: => pci "Synchronous Abort" handler, esr 0x96000210 elr: 0022d034 lr : 0022cfd0 (reloc) elr: f4568034 lr : f4567fd0 x0 : 0010 x1 : f800 x2 : x3 : 0010 x4 : f2559290 x5 : x6 : 0001 x7 : f2559860 x8 : 0030 x9 : 0008 x10: 0010 x11: f251fd1c x12: 1421 x13: 1468 x14: f251fd4c x15: x16: 00060001 x17: 001f x18: f2532dc0 x19: f251fcd0 x20: 0001 x21: x22: 0001 x23: f45d4000 x24: x25: f45bc000 x26: x27: x28: f2541440 x29: f251fc20 Code: 54c1 35a5 93407c00 f9400081 (b8616800) Resetting CPU ... Adding a delay after link training works-around the problem. I added this delay to the OpenBSD rkpcie driver as well: https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield SAS9211-4i needs a 1 second delay, so I arbitrarily decided on 2 seconds. The delay work-around was originally discovered by nuumio: https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee drivers/pci/pcie_rockchip.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c index 0edc2464a8..51cfbf6b18 100644 --- a/drivers/pci/pcie_rockchip.c +++ b/drivers/pci/pcie_rockchip.c @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct udevice *dev) goto err_power_off_phy; } + /* +* XXX: On at least the RockPro64, many cards will trip a +* synchronous abort when first accessing PCIe config space +* during bus scanning. A delay after link training allows +* some of these cards to function. +*/ + mdelay(2000); + /* Initialize Root Complex registers. */ writel(PCIE_LM_VENDOR_ROCKCHIP, priv->apb_base + PCIE_LM_VENDOR_ID); writel(PCI_CLASS_BRIDGE_PCI << 16, -- 2.26.2
Re: [PATCH] rockchip: rockpro64: Set cooling levels for pwm-fan
On Fri, 2020-05-29 at 13:00 -0600, Simon Glass wrote: > Hi Kurt, > > On Fri, 29 May 2020 at 06:42, Kurt Miller wrote: > > > > > > On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote: > > > > > > On Thu, May 28, 2020 at 8:32 PM Kurt Miller > > > wrote: > > > > > > > > > > > > > > > > The cooling levels are tuned to the fan that comes with the rockpro64 > > > > NAS > > > > case. A gpu_thermal zone was not added because having two active cooling > > > > maps control one physical fan causes them to compete for the fan speed > > > > which results in erratic fan behavior. > > > Is there any reason this shouldn't go to the linux kernel first and > > > then be synced back to the standard rk3399-rockpro64.dtsi? > > Is that a requirement? I do my primary development on OpenBSD and > > while I use Linux for work tasks, I don't have available time right > > now to push these changes to Linux kernel first. > > > The problem is that we need to keep Linux and U-Boot in sync. If a DT > change is submitted only to one then it isn't clear who is taking on > the task of syncing them up. > > You don't actually need to be using Linux to send a DT change - just > clone Linux, apply your patch and send to devicet...@vger.kernel.org. > I wonder if it would be good enough to cc that group and the Linux > maintainer on these patches, assuming the files are currently in sync? > But probably a new patch is needed. > Thank you for the pointers. I'll give that a try. Best, -Kurt
Re: [PATCH] rockchip: rockpro64: Set cooling levels for pwm-fan
On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote:
> On Thu, May 28, 2020 at 8:32 PM Kurt Miller
> wrote:
> >
> >
> > The cooling levels are tuned to the fan that comes with the rockpro64 NAS
> > case. A gpu_thermal zone was not added because having two active cooling
> > maps control one physical fan causes them to compete for the fan speed
> > which results in erratic fan behavior.
> Is there any reason this shouldn't go to the linux kernel first and
> then be synced back to the standard rk3399-rockpro64.dtsi?
Is that a requirement? I do my primary development on OpenBSD and
while I use Linux for work tasks, I don't have available time right
now to push these changes to Linux kernel first.
>
> >
> > Signed-off-by: Kurt Miller
> > ---
> >
> > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 43 +++
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > index deaa3efd39..c0e0396758 100644
> > --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > @@ -13,6 +13,49 @@
> > chosen {
> > u-boot,spl-boot-order = "same-as-spl", ,
> > };
> > +
> > + fan: pwm-fan {
> > + cooling-levels = <0 40 80 255>;
> > + };
> > +};
> > +
> > +_thermal {
> > + trips {
> > + cpu_warm: cpu_warm {
> > + temperature = <5>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > +
> > + cpu_med: cpu_med {
> > + temperature = <6>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > +
> > + cpu_hot: cpu_hot {
> > + temperature = <65000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map2 {
> > + trip = <_warm>;
> > + cooling-device = < THERMAL_NO_LIMIT 1>;
> > + };
> > +
> > + map3 {
> > + trip = <_med>;
> > + cooling-device = < THERMAL_NO_LIMIT 2>;
> > + };
> > +
> > + map4 {
> > + trip = <_hot>;
> > + cooling-device = < 2 THERMAL_NO_LIMIT>;
> > + };
> > + };
> > };
> >
> > _center {
> > --
> > 2.26.2
> >
[PATCH] rockchip: rockpro64: Set cooling levels for pwm-fan
The cooling levels are tuned to the fan that comes with the rockpro64 NAS
case. A gpu_thermal zone was not added because having two active cooling
maps control one physical fan causes them to compete for the fan speed
which results in erratic fan behavior.
Signed-off-by: Kurt Miller
---
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index deaa3efd39..c0e0396758 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -13,6 +13,49 @@
chosen {
u-boot,spl-boot-order = "same-as-spl", ,
};
+
+ fan: pwm-fan {
+ cooling-levels = <0 40 80 255>;
+ };
+};
+
+_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <5>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_med: cpu_med {
+ temperature = <6>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <_warm>;
+ cooling-device = < THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <_med>;
+ cooling-device = < THERMAL_NO_LIMIT 2>;
+ };
+
+ map4 {
+ trip = <_hot>;
+ cooling-device = < 2 THERMAL_NO_LIMIT>;
+ };
+ };
};
_center {
--
2.26.2
Re: [PATCH] pci: Make Rockchip PCIe voltage regulators optional
On Sun, 2020-05-24 at 22:32 +0200, Mark Kettenis wrote:
> The vpcie*-supply properties are optional and these are absent on
> boards like the ROCKPro64 and Firefly RK3399 where the voltage is
> supplied by always-on regulators that are already enabled upon
> boot. Make these regulators optional and properly check their
> presence before attempting to enable them.
>
> Makes PCIe work on un U-Boot on the boards mentioned above.
>
> Signed-off-by: Mark Kettenis
Tested by: Kurt Miller
Model: Pine64 RockPro64 v2.1
=> pci
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
_
00.00.00 0x1d87 0x0100 Bridge device 0x04
=> pci 1
Scanning PCI devices on bus 1
BusDevFun VendorId DeviceId Device Class Sub-Class
_
01.00.00 0x1b4b 0x9128 Mass storage controller 0x06
> ---
> drivers/pci/pcie_rockchip.c | 33 -
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c
> index 82a8396e42..0edc2464a8 100644
> --- a/drivers/pci/pcie_rockchip.c
> +++ b/drivers/pci/pcie_rockchip.c
> @@ -322,7 +322,7 @@ static int rockchip_pcie_set_vpcie(struct udevice *dev)
> struct rockchip_pcie *priv = dev_get_priv(dev);
> int ret;
>
> - if (!IS_ERR(priv->vpcie3v3)) {
> + if (priv->vpcie3v3) {
> ret = regulator_set_enable(priv->vpcie3v3, true);
> if (ret) {
> dev_err(dev, "failed to enable vpcie3v3 (ret=%d)\n",
> @@ -331,24 +331,31 @@ static int rockchip_pcie_set_vpcie(struct udevice *dev)
> }
> }
>
> - ret = regulator_set_enable(priv->vpcie1v8, true);
> - if (ret) {
> - dev_err(dev, "failed to enable vpcie1v8 (ret=%d)\n", ret);
> - goto err_disable_3v3;
> + if (priv->vpcie1v8) {
> + ret = regulator_set_enable(priv->vpcie1v8, true);
> + if (ret) {
> + dev_err(dev, "failed to enable vpcie1v8 (ret=%d)\n",
> + ret);
> + goto err_disable_3v3;
> + }
> }
>
> - ret = regulator_set_enable(priv->vpcie0v9, true);
> - if (ret) {
> - dev_err(dev, "failed to enable vpcie0v9 (ret=%d)\n", ret);
> - goto err_disable_1v8;
> + if (priv->vpcie0v9) {
> + ret = regulator_set_enable(priv->vpcie0v9, true);
> + if (ret) {
> + dev_err(dev, "failed to enable vpcie0v9 (ret=%d)\n",
> + ret);
> + goto err_disable_1v8;
> + }
> }
>
> return 0;
>
> err_disable_1v8:
> - regulator_set_enable(priv->vpcie1v8, false);
> + if (priv->vpcie1v8)
> + regulator_set_enable(priv->vpcie1v8, false);
> err_disable_3v3:
> - if (!IS_ERR(priv->vpcie3v3))
> + if (priv->vpcie3v3)
> regulator_set_enable(priv->vpcie3v3, false);
> return ret;
> }
> @@ -424,14 +431,14 @@ static int rockchip_pcie_parse_dt(struct udevice *dev)
>
> ret = device_get_supply_regulator(dev, "vpcie1v8-supply",
> >vpcie1v8);
> - if (ret) {
> + if (ret && ret != -ENOENT) {
> dev_err(dev, "failed to get vpcie1v8 supply (ret=%d)\n", ret);
> return ret;
> }
>
> ret = device_get_supply_regulator(dev, "vpcie0v9-supply",
> >vpcie0v9);
> - if (ret) {
> + if (ret && ret != -ENOENT) {
> dev_err(dev, "failed to get vpcie0v9 supply (ret=%d)\n", ret);
> return ret;
> }
Re: [PATCH v2 2/2] rockchip: Enable PCIe and NVMe on ROCKPro64
On Mon, 2020-05-25 at 11:00 +0200, Mark Kettenis wrote: > Enable CONFIG_PCI and CONFIG_NVME and related configs for the > ROCKPro64 board. > > Signed-off-by: Mark Kettenis Tested by: Kurt Miller Model: Pine64 RockPro64 v2.1 => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x1d87 0x0100 Bridge device 0x04 => pci 1 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b4b 0x9128 Mass storage controller 0x06 > --- > Changes in v2: > - Extend commit message > > configs/rockpro64-rk3399_defconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/configs/rockpro64-rk3399_defconfig > b/configs/rockpro64-rk3399_defconfig > index 95037a191d..b472167283 100644 > --- a/configs/rockpro64-rk3399_defconfig > +++ b/configs/rockpro64-rk3399_defconfig > @@ -19,6 +19,7 @@ CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPT=y > CONFIG_CMD_MMC=y > CONFIG_CMD_USB=y > +CONFIG_CMD_PCI=y > # CONFIG_CMD_SETEXPR is not set > CONFIG_CMD_TIME=y > CONFIG_SPL_OF_CONTROL=y > @@ -38,10 +39,13 @@ CONFIG_SPI_FLASH_GIGADEVICE=y > CONFIG_DM_ETH=y > CONFIG_ETH_DESIGNWARE=y > CONFIG_GMAC_ROCKCHIP=y > +CONFIG_NVME=y > +CONFIG_PCI=y > CONFIG_PMIC_RK8XX=y > CONFIG_REGULATOR_PWM=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_ROCKCHIP=y > +CONFIG_DM_RESET=y > CONFIG_RAM_RK3399_LPDDR4=y > CONFIG_BAUDRATE=115200 > CONFIG_DEBUG_UART_SHIFT=2
Re: [PATCH] rockchip: rk3328: rock64 - fix gen3 SPL hang
On Wed, 2020-05-20 at 16:30 +0800, Chen-Yu Tsai wrote:
> On Wed, May 20, 2020 at 4:05 PM Matwey V. Kornilov
> wrote:
> >
> >
> > вт, 19 мая 2020 г. в 17:30, Kurt Miller :
> > >
> > >
> > > On Tue, 2020-05-19 at 12:48 +0300, Matwey V. Kornilov wrote:
> > > >
> > > > вт, 19 мая 2020 г. в 01:06, Kurt Miller :
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 2020-05-13 at 16:10 -0400, Kurt Miller wrote:
> > > > > >
> > > > > >
> > > > > > On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks. Have you already checked it on gen2? I think I have gen2
> > > > > > > board to test.
> > > > > > Yes, I have both gen3 and gen2 boards. gen2 continues to work
> > > > > > with this patch as well.
> > > > > Hi Matwey,
> > > > Hi Kurt,
> > > >
> > > > Sorry for the late reply. I've just managed to apply you patch on top
> > > > of ed9a3aa645 and it didn't work for me on 2GB v2.0 rock64 board.
> > > >
> > > > U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 12:44:16)
> > > > LPDDR3, 800MHz
> > > > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > > > Trying to boot from BOOTROM
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 12:44:16
> > > > +0300)
> > > > Trying to boot from MMC1
> > > > [and nothing else happens here]
> > > >
> > > > What do you think may be the reason?
> > > Hi Matwey,
> > >
> > Hi Kurt,
> >
> > >
> > > Thank you for testing the patch. Hmm, are you building with ATF 2.3?
> > You are right here, I was testing with ATF 2.1, while ATF 2.3 works
> > correctly.
> > First working commit in ATF is 0aad563c ("rockchip: Update BL31_BASE
> > to 0x4").
Great! I did some more gen2 testing as well. Booting with just eMMC
works and with both eMMC and uSD also works for me.
> > I suppose, it is worth to mention in the commit message for this
> > patch. What do you think?
> This was already mentioned in commits such as
>
> c0a474b9d9a1 rockchip: evb-rk3328: Enable support ATF in SPL
> 4690ef8907e9 rockchip: rk3288-evb: update SPL_STACK/MALLOC_LEN config
> with rk3399
> 6024467bcc0e rockchip: config: update CONFIG_SPL_MAX_SIZE for 64bit CPUs
> 006ab58d4636 rockchip: rk3399: update SPL_STACK_R_ADDR
>
> ChenYu
>
Yes this changed back in the 2020.01 release time-frame. If the
commit message needs improvement, please suggest what you want
and I can resubmit the patch.
Thanks,
-Kurt
> >
> >
> > >
> > >
> > > I’m booting from the uSD without an eMMC installed. Are you booting
> > > from the eMMC or have one installed?
> > I'm booting from uSD without eMMC installed also.
> >
> >
> > >
> > >
> > > Here are some background emails related to the gen3 freeze. I also
> > > included the output for when gen3 fails below and the output for
> > > my gen2 2gb and gen3 4gb with the patch.
> > >
> > > https://marc.info/?l=u-boot=158550521101881=2
> > > https://marc.info/?l=u-boot=156427088018689=2
> > >
> > > Gen2 2GB with patch:
> > >
> > > U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15)
> > > LPDDR3, 800MHz
> > > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > >
> > > U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15
> > > -0400)
> > > Trying to boot from MMC1
> > > NOTICE: BL31: v2.3():2.3
> > > NOTICE: BL31: Built : 11:30:57, May 15 2020
> > > NOTICE: BL31:Rockchip release version: v1.2
> > > INFO:ARM GICv2 driver initialized
> > > INFO:plat_rockchip_pmu_init: pd status 0xe
> > > INFO:BL31: Initializing runtime services
> > > INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
> > > INFO:BL31: Preparing for EL3 exit to normal world
> > > INFO:Entry point address = 0x20
> > > INFO:SPSR = 0x3c9
> > >
> > >
> > > U-Boot 2020.07-
Re: [PATCH] rockchip: rk3328: rock64 - fix gen3 SPL hang
On Tue, 2020-05-19 at 12:48 +0300, Matwey V. Kornilov wrote: > вт, 19 мая 2020 г. в 01:06, Kurt Miller : > > > > > > On Wed, 2020-05-13 at 16:10 -0400, Kurt Miller wrote: > > > > > > On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote: > > > > > > > > > > > > Thanks. Have you already checked it on gen2? I think I have gen2 board > > > > to test. > > > Yes, I have both gen3 and gen2 boards. gen2 continues to work > > > with this patch as well. > > Hi Matwey, > Hi Kurt, > > Sorry for the late reply. I've just managed to apply you patch on top > of ed9a3aa645 and it didn't work for me on 2GB v2.0 rock64 board. > > U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 12:44:16) > LPDDR3, 800MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 12:44:16 +0300) > Trying to boot from MMC1 > [and nothing else happens here] > > What do you think may be the reason? Hi Matwey, Thank you for testing the patch. Hmm, are you building with ATF 2.3? I’m booting from the uSD without an eMMC installed. Are you booting from the eMMC or have one installed? Here are some background emails related to the gen3 freeze. I also included the output for when gen3 fails below and the output for my gen2 2gb and gen3 4gb with the patch. https://marc.info/?l=u-boot=158550521101881=2 https://marc.info/?l=u-boot=156427088018689=2 Gen2 2GB with patch: U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15) LPDDR3, 800MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 -0400) Trying to boot from MMC1 NOTICE: BL31: v2.3():2.3 NOTICE: BL31: Built : 11:30:57, May 15 2020 NOTICE: BL31:Rockchip release version: v1.2 INFO:ARM GICv2 driver initialized INFO:plat_rockchip_pmu_init: pd status 0xe INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 U-Boot 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 -0400) Model: Pine64 Rock64 DRAM: 2 GiB PMIC: RK8050 (on=0x40, off=0x01) MMC: mmc@ff50: 1, mmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Pine64 Rock64 Net: eth0: ethernet@ff54 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk m...@ff50.blk... ** Unrecognized filesystem type ** Card did not respond to voltage select! Scanning disk m...@ff52.blk... Disk m...@ff52.blk not ready Found 3 disks BootOrder not defined EFI boot manager: Cannot load any image 169176 bytes read in 15 ms (10.8 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC disks: sd0* Gen3 4GB with patch: U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15) LPDDR3, 800MHz BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 -0400) Trying to boot from MMC1 NOTICE: BL31: v2.3():2.3 NOTICE: BL31: Built : 11:30:57, May 15 2020 NOTICE: BL31:Rockchip release version: v1.2 INFO:ARM GICv2 driver initialized INFO:plat_rockchip_pmu_init: pd status 0xe INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 U-Boot 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 -0400) Model: Pine64 Rock64 DRAM: 4 GiB PMIC: RK8050 (on=0x40, off=0x00) MMC: mmc@ff50: 1, mmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Pine64 Rock64 Net: eth0: ethernet@ff54 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk m...@ff50.blk... ** Unrecognized filesystem type ** Card did not respond to voltage select! Scanning disk m...@ff52.blk... Disk m...@ff52.blk not ready Found 3 disks BootOrder not de
Re: [PATCH] rockchip: rk3328: rock64 - fix gen3 SPL hang
On Wed, 2020-05-13 at 16:10 -0400, Kurt Miller wrote:
> On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> >
> > Thanks. Have you already checked it on gen2? I think I have gen2 board to
> > test.
> Yes, I have both gen3 and gen2 boards. gen2 continues to work
> with this patch as well.
Hi Matwey,
Is there anything else you need to complete your review of
this patch?
Thanks,
-Kurt
>
> >
> >
> > ср, 13 мая 2020 г. в 22:55, Kurt Miller :
> > >
> > >
> > >
> > > Use the same approach as ROC-RK3328-CC which enables SPL GPIO,
> > > pinctl and regulator support. This allows the gen3 board to
> > > boot through SPL and does not break gen2 in the process.
> > >
> > > Signed-off-by: Kurt Miller
> > > ---
> > >
> > > arch/arm/dts/rk3328-rock64-u-boot.dtsi | 21 +
> > > configs/rock64-rk3328_defconfig| 7 ++-
> > > 2 files changed, 27 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > > b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > > index 8318bf4e60..f076075076 100644
> > > --- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > > +++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > > @@ -11,6 +11,22 @@
> > > };
> > > };
> > >
> > > + {
> > > + u-boot,dm-spl;
> > > +};
> > > +
> > > + {
> > > + u-boot,dm-spl;
> > > +};
> > > +
> > > +_gpio {
> > > + u-boot,dm-spl;
> > > +};
> > > +
> > > +_pull_up_4ma {
> > > + u-boot,dm-spl;
> > > +};
> > > +
> > > _host0_xhci {
> > > vbus-supply = <_host_5v>;
> > > status = "okay";
> > > @@ -25,3 +41,8 @@
> > > /delete-property/ regulator-always-on;
> > > /delete-property/ regulator-boot-on;
> > > };
> > > +
> > > +/* Need this and all the pinctrl/gpio stuff above to set pinmux */
> > > +_sd {
> > > + u-boot,dm-spl;
> > > +};
> > > diff --git a/configs/rock64-rk3328_defconfig
> > > b/configs/rock64-rk3328_defconfig
> > > index 7d096d38c6..0bc2198f5c 100644
> > > --- a/configs/rock64-rk3328_defconfig
> > > +++ b/configs/rock64-rk3328_defconfig
> > > @@ -1,6 +1,7 @@
> > > CONFIG_ARM=y
> > > CONFIG_ARCH_ROCKCHIP=y
> > > CONFIG_SYS_TEXT_BASE=0x0020
> > > +CONFIG_SPL_GPIO_SUPPORT=y
> > > CONFIG_ENV_OFFSET=0x3F8000
> > > CONFIG_ROCKCHIP_RK3328=y
> > > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > > @@ -25,6 +26,8 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
> > > # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> > > CONFIG_TPL_SYS_MALLOC_SIMPLE=y
> > > CONFIG_SPL_STACK_R=y
> > > +CONFIG_SPL_I2C_SUPPORT=y
> > > +CONFIG_SPL_POWER_SUPPORT=y
> > > CONFIG_SPL_ATF=y
> > > CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> > > CONFIG_CMD_BOOTZ=y
> > > @@ -36,7 +39,7 @@ CONFIG_CMD_TIME=y
> > > CONFIG_SPL_OF_CONTROL=y
> > > CONFIG_TPL_OF_CONTROL=y
> > > CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64"
> > > -CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
> > > interrupt-parent assigned-clocks assigned-clock-
> > > rates assigned-clock-parents"
> > > +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
> > > assigned-clock-rates assigned-clock-
> > > parents"
> > > CONFIG_TPL_OF_PLATDATA=y
> > > CONFIG_ENV_IS_IN_MMC=y
> > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > @@ -64,7 +67,9 @@ CONFIG_PINCTRL=y
> > > CONFIG_SPL_PINCTRL=y
> > > CONFIG_DM_PMIC=y
> > > CONFIG_PMIC_RK8XX=y
> > > +CONFIG_SPL_DM_REGULATOR=y
> > > CONFIG_REGULATOR_PWM=y
> > > +CONFIG_SPL_DM_REGULATOR_FIXED=y
> > > CONFIG_DM_REGULATOR_FIXED=y
> > > CONFIG_REGULATOR_RK8XX=y
> > > CONFIG_PWM_ROCKCHIP=y
> > > --
> > > 2.26.0
> > >
Re: [PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux
On Thu, 2020-05-14 at 12:10 +0800, Chen-Yu Tsai wrote:
> Hi Kurt
>
> On Tue, May 12, 2020 at 3:00 AM Kurt Miller
> wrote:
> >
> >
> > On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> > >
> > > From: Chen-Yu Tsai
> > >
> > > This syncs rk3328 device tree files from the Linux kernel next-20200324.
> > > The last commit to touch these files is:
> > >
> > > b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")
> > >
> > > Additional changes not yet in the Linux kernel include:
> > >
> > > arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from
> > > grf node
> > > arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux
> > > options
> > > arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"
> > >
> > > Changes include:
> > >
> > > - conversion of raw pin numbers to macros
> > > - removal of deprecated RK_FUNC_* macros
> > > - update of device tree binding headers
> > > - new devices
> > > - device tree cleanups
> > > - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot
> > >
> > > This includes a re-ordering of the USB device nodes compared to upstream
> > > Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
> > > currently required as otherwise the dwc2 controller would not be able to
> > > detect devices in some cases. This may be due to lack of USB PHY support
> > > in U-boot.
> > Hi Chen-Yu,
> >
> > Thank you for syncing rk3328 device tree files. On the rock64 with
> > v2020.04 one USB 2.0 port was working (the lower one). Building
> > master now with this merged, no USB ports are working. No power
> > appears to be enabled on them and USB devices are not recognized.
> When I was working on v3, it was based on
>
> d202f67db077 Merge branch '2020-04-25-master-imports'
>
> And it was definitely working. My Rock64 is back in its case, so I tested
> again with the ROC-RK3328-CC just now. All three USB ports work properly,
> on both the old tree and current master.
>
> Are you using the defconfig, or have you deviated from it? XHCI must be
> enabled, as VBUS is tied to it (to get everything to work).
>
Hi Chen-Yu,
Thank you for your reply. I've tested with and without the SPL gen3 changes
I posted yesterday on gen2 and gen3 boards. In all cases there's no power
to all three usb ports. The only other change I have in defconfig is
adjusting the baud rate.
Mark Kettenis suggested I revert Patch 9/9 from this series and with
that reverted the one USB 2.0 port works again. Mark has a better
understanding of the issues and perhaps can comment further - cc'ed.
Regards,
-Kurt
Re: [PATCH] rockchip: rk3328: rock64 - fix gen3 SPL hang
On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> Thanks. Have you already checked it on gen2? I think I have gen2 board to
> test.
Yes, I have both gen3 and gen2 boards. gen2 continues to work
with this patch as well.
>
> ср, 13 мая 2020 г. в 22:55, Kurt Miller :
> >
> >
> > Use the same approach as ROC-RK3328-CC which enables SPL GPIO,
> > pinctl and regulator support. This allows the gen3 board to
> > boot through SPL and does not break gen2 in the process.
> >
> > Signed-off-by: Kurt Miller
> > ---
> >
> > arch/arm/dts/rk3328-rock64-u-boot.dtsi | 21 +
> > configs/rock64-rk3328_defconfig| 7 ++-
> > 2 files changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > index 8318bf4e60..f076075076 100644
> > --- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> > @@ -11,6 +11,22 @@
> > };
> > };
> >
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_gpio {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_pull_up_4ma {
> > + u-boot,dm-spl;
> > +};
> > +
> > _host0_xhci {
> > vbus-supply = <_host_5v>;
> > status = "okay";
> > @@ -25,3 +41,8 @@
> > /delete-property/ regulator-always-on;
> > /delete-property/ regulator-boot-on;
> > };
> > +
> > +/* Need this and all the pinctrl/gpio stuff above to set pinmux */
> > +_sd {
> > + u-boot,dm-spl;
> > +};
> > diff --git a/configs/rock64-rk3328_defconfig
> > b/configs/rock64-rk3328_defconfig
> > index 7d096d38c6..0bc2198f5c 100644
> > --- a/configs/rock64-rk3328_defconfig
> > +++ b/configs/rock64-rk3328_defconfig
> > @@ -1,6 +1,7 @@
> > CONFIG_ARM=y
> > CONFIG_ARCH_ROCKCHIP=y
> > CONFIG_SYS_TEXT_BASE=0x0020
> > +CONFIG_SPL_GPIO_SUPPORT=y
> > CONFIG_ENV_OFFSET=0x3F8000
> > CONFIG_ROCKCHIP_RK3328=y
> > CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
> > @@ -25,6 +26,8 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
> > # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> > CONFIG_TPL_SYS_MALLOC_SIMPLE=y
> > CONFIG_SPL_STACK_R=y
> > +CONFIG_SPL_I2C_SUPPORT=y
> > +CONFIG_SPL_POWER_SUPPORT=y
> > CONFIG_SPL_ATF=y
> > CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> > CONFIG_CMD_BOOTZ=y
> > @@ -36,7 +39,7 @@ CONFIG_CMD_TIME=y
> > CONFIG_SPL_OF_CONTROL=y
> > CONFIG_TPL_OF_CONTROL=y
> > CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64"
> > -CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
> > interrupt-parent assigned-clocks assigned-clock-
> > rates assigned-clock-parents"
> > +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
> > assigned-clock-rates assigned-clock-
> > parents"
> > CONFIG_TPL_OF_PLATDATA=y
> > CONFIG_ENV_IS_IN_MMC=y
> > CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > @@ -64,7 +67,9 @@ CONFIG_PINCTRL=y
> > CONFIG_SPL_PINCTRL=y
> > CONFIG_DM_PMIC=y
> > CONFIG_PMIC_RK8XX=y
> > +CONFIG_SPL_DM_REGULATOR=y
> > CONFIG_REGULATOR_PWM=y
> > +CONFIG_SPL_DM_REGULATOR_FIXED=y
> > CONFIG_DM_REGULATOR_FIXED=y
> > CONFIG_REGULATOR_RK8XX=y
> > CONFIG_PWM_ROCKCHIP=y
> > --
> > 2.26.0
> >
>
[PATCH] rockchip: rk3328: rock64 - fix gen3 SPL hang
Use the same approach as ROC-RK3328-CC which enables SPL GPIO,
pinctl and regulator support. This allows the gen3 board to
boot through SPL and does not break gen2 in the process.
Signed-off-by: Kurt Miller
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 21 +
configs/rock64-rk3328_defconfig| 7 ++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 8318bf4e60..f076075076 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -11,6 +11,22 @@
};
};
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_gpio {
+ u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+ u-boot,dm-spl;
+};
+
_host0_xhci {
vbus-supply = <_host_5v>;
status = "okay";
@@ -25,3 +41,8 @@
/delete-property/ regulator-always-on;
/delete-property/ regulator-boot-on;
};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+_sd {
+ u-boot,dm-spl;
+};
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 7d096d38c6..0bc2198f5c 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_ROCKCHIP_RK3328=y
CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
@@ -25,6 +26,8 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
CONFIG_TPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
CONFIG_SPL_ATF=y
CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
CONFIG_CMD_BOOTZ=y
@@ -36,7 +39,7 @@ CONFIG_CMD_TIME=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_TPL_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64"
-CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
assigned-clock-rates assigned-clock-parents"
CONFIG_TPL_OF_PLATDATA=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
@@ -64,7 +67,9 @@ CONFIG_PINCTRL=y
CONFIG_SPL_PINCTRL=y
CONFIG_DM_PMIC=y
CONFIG_PMIC_RK8XX=y
+CONFIG_SPL_DM_REGULATOR=y
CONFIG_REGULATOR_PWM=y
+CONFIG_SPL_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_REGULATOR_RK8XX=y
CONFIG_PWM_ROCKCHIP=y
--
2.26.0
Re: [PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux
On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> This syncs rk3328 device tree files from the Linux kernel next-20200324.
> The last commit to touch these files is:
>
> b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")
>
> Additional changes not yet in the Linux kernel include:
>
> arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf
> node
> arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
> arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"
>
> Changes include:
>
> - conversion of raw pin numbers to macros
> - removal of deprecated RK_FUNC_* macros
> - update of device tree binding headers
> - new devices
> - device tree cleanups
> - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot
>
> This includes a re-ordering of the USB device nodes compared to upstream
> Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
> currently required as otherwise the dwc2 controller would not be able to
> detect devices in some cases. This may be due to lack of USB PHY support
> in U-boot.
Hi Chen-Yu,
Thank you for syncing rk3328 device tree files. On the rock64 with
v2020.04 one USB 2.0 port was working (the lower one). Building
master now with this merged, no USB ports are working. No power
appears to be enabled on them and USB devices are not recognized.
Do you have any suggestions for me to try to get them enabled again?
Thanks,
-Kurt
>
> Signed-off-by: Chen-Yu Tsai
> ---
> Changes since v2:
> - Dropped reviewed-by
> - Moved dwc2 OTG device node after EHCI/OHCI to make dwc2 work again
> Changes since v1:
> - Added Kever's reviewed-by
> ---
> arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
> arch/arm/dts/rk3328-evb.dts | 196 ++--
> arch/arm/dts/rk3328-rock64.dts | 132 ++-
> arch/arm/dts/rk3328.dtsi| 1414 +--
> 4 files changed, 1166 insertions(+), 581 deletions(-)
>
> diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi
> b/arch/arm/dts/rk3328-evb-u-boot.dtsi
> index 8ba53cf8f44b..4bfa0c2330ba 100644
> --- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
> @@ -40,6 +40,11 @@
> status = "okay";
> };
>
> + {
> + /* Integrated PHY unsupported by U-boot */
> + status = "broken";
> +};
> +
> _host0_xhci {
> vbus-supply = <_host_xhci>;
> status = "okay";
> diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
> index 97bef37cf610..6abc6f4a86cf 100644
> --- a/arch/arm/dts/rk3328-evb.dts
> +++ b/arch/arm/dts/rk3328-evb.dts
> @@ -1,6 +1,6 @@
> -// SPDX-License-Identifier: GPL-2.0+
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> /*
> - * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
> */
>
> /dts-v1/;
> @@ -11,24 +11,51 @@
> compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
>
> chosen {
> - stdout-path =
> + stdout-path = "serial2:150n8";
> };
>
> - vcc3v3_sdmmc: sdmmc-pwren {
> + dc_12v: dc-12v {
> compatible = "regulator-fixed";
> - regulator-name = "vcc3v3";
> - gpio = < 30 GPIO_ACTIVE_LOW>;
> + regulator-name = "dc_12v";
> regulator-always-on;
> regulator-boot-on;
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <_enable_h>;
> +
> + /*
> + * On the module itself this is one of these (depending
> + * on the actual card populated):
> + * - SDIO_RESET_L_WL_REG_ON
> + * - PDN (power down when low)
> + */
> + reset-gpios = < 18 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = < 30 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio>;
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <_io>;
> };
>
> - vcc5v0_otg: vcc5v0-otg-drv {
> + vcc_sys: vcc-sys {
> compatible = "regulator-fixed";
> - enable-active-high;
> - regulator-name = "vcc5v0_otg";
> - gpio = < 27 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
> + vin-supply = <_12v>;
> };
>
> vcc_phy:
Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> Hi everyone,
>
> This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> dropping the custom board target, and dealing with the pinmuxing
> through proper use of DM regulators / GPIO / pinctrl in SPL.
>
> This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
> single board computer.
>
> The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> card size development board based on the Rockchip RK3328 SoC, with:
>
> - 1/2/4 GB DDR4 DRAM
> - eMMC connector for optional module
> - micro SD card slot
> - 1 x USB 3.0 host port
> - 2 x USB 2.0 host port
> - 1 x USB 2.0 OTG port
> - HDMI video output
> - TRRS connector with audio and composite video output
> - gigabit Ethernet
> - consumer IR receiver
> - debug UART pins
>
> Originally I started with Loic's patches, and syncing the device tree
> files from Linux. That didn't get very far, with SPL failing to detect
> the SD card. Examining the schematics and internal state of GRF and
> GPIOs, I realized that the logic for the SD card power enable switch
> is opposite that of what the SD card controller's SDMMC0_PWREN pin
> would use. Instead, directly using the GPIO is required.
>
> To deal with this, DM regulator and GPIO are enabled in SPL, and
> various device nodes are marked with u-boot,dm-spl to have them work.
> pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
> pin muxed over to GPIO.
>
> Along the way, there are some clean-ups of existing dts files, moving
> U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> from Linux. Only boards already existing in U-boot are synced. DT
> binding header files are synced separately as there is already one
> patch floating around. The DT sync also includes clean-up changes only
> recently posted, and likely won't make it in for at least a few weeks.
>
> Please have a look, and test if possible. I cc-ed a couple people that
> showed interest in this board on mailing lists recently.
>
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (6):
> rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
> rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
> dt-bindings: clock: rk3328: sync from upstream Linux kernel
> dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> rockchip: dts: rk3328: Sync device tree files from Linux
> rockchip: rk3328: Add support for ROC-RK3328-CC board
>
> arch/arm/dts/Makefile |1 +
> arch/arm/dts/rk3328-evb-u-boot.dtsi | 39 +
> arch/arm/dts/rk3328-evb.dts | 220 +--
> arch/arm/dts/rk3328-roc-cc-u-boot.dtsi| 38 +
> .../{rk3328-rock64.dts => rk3328-roc-cc.dts} | 135 +-
> arch/arm/dts/rk3328-rock64.dts| 132 +-
> arch/arm/dts/rk3328.dtsi | 1420 +++--
> board/rockchip/evb_rk3328/MAINTAINERS |7 +
> configs/roc-cc-rk3328_defconfig | 103 ++
> doc/README.rockchip |4 +-
> include/dt-bindings/clock/rk3328-cru.h| 212 +--
> include/dt-bindings/power/rk3328-power.h | 19 +
> 12 files changed, 1578 insertions(+), 752 deletions(-)
> create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
> create mode 100644 configs/roc-cc-rk3328_defconfig
> create mode 100644 include/dt-bindings/power/rk3328-power.h
>
Hi ChenYu,
I needed to apply the following additional diff to your patchset
to allow the Rock64 v3 board to boot through SPL. I copied the
same approach from your ROC-RK3328-CC changes. While it works
it needs expert review.
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index e5946d2d2d..7d4ae66834 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -11,6 +11,27 @@
};
};
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_gpio {
+ u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+ u-boot,dm-spl;
+};
+
_host0_xhci {
status = "okay";
};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+_sd {
+ u-boot,dm-spl;
+};
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 826c7a6917..5e4516635e 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_ROCKCHIP_RK3328=y
CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
@@ -25,6 +26,8 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
CONFIG_TPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
CONFIG_SPL_ATF=y
Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board
On Wed, 2020-04-01 at 18:09 +0800, Chen-Yu Tsai wrote:
> On Tue, Mar 31, 2020 at 8:37 PM Jagan Teki wrote:
> >
> >
> > On Tue, Mar 31, 2020 at 5:16 PM Chen-Yu Tsai wrote:
> > >
> > >
> > > On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki
> > > wrote:
> > > >
> > > >
> > > > On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai wrote:
> > > > >
> > > > >
> > > > > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Hi Chen-Yu,
> > > > > >
> > > > > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > From: Chen-Yu Tsai
> > > > > > >
> > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a
> > > > > > > credit
> > > > > > > card size development board based on the Rockchip RK3328 SoC,
> > > > > > > with:
> > > > > > >
> > > > > > > - 1/2/4 GB DDR4 DRAM
> > > > > > > - eMMC connector for optional module
> > > > > > > - micro SD card slot
> > > > > > > - 1 x USB 3.0 host port
> > > > > > > - 2 x USB 2.0 host port
> > > > > > > - 1 x USB 2.0 OTG port
> > > > > > > - HDMI video output
> > > > > > > - TRRS connector with audio and composite video output
> > > > > > > - gigabit Ethernet
> > > > > > > - consumer IR receiver
> > > > > > > - debug UART pins
> > > > > > >
> > > > > > > The ROC-RK3328-CC has the enable pin of the SD card power switch
> > > > > > > tied
> > > > > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which
> > > > > > > is
> > > > > > > muxed by default. SDMMC0_PWREN is an active high signal
> > > > > > > controlled by
> > > > > > > the MMC controller, however the switch enable is active low, and
> > > > > > > pulled low (enabled) by default to make things work on boot.
> > > > > > >
> > > > > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to
> > > > > > > enable
> > > > > > > power to the card. The default GPIO state for the pin is
> > > > > > > pull-down and
> > > > > > > input, which doesn't require extra configuration when paired with
> > > > > > > the
> > > > > > > external pull-down and active low switch.
> > > > > > >
> > > > > > > Thus we make a custom target for this board and do the muxing in
> > > > > > > its
> > > > > > > spl_board_init() function.
> > > > > > >
> > > > > > > The device tree file is synced from the Linux kernel
> > > > > > > next-20200324.
> > > > > > >
> > > > > > > Signed-off-by: Chen-Yu Tsai
> > > > > > > ---
> > > > > > [snip]
> > > > > >
> > > > > > >
> > > > > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > > new file mode 100644
> > > > > > > index ..f2318e71ac33
> > > > > > > --- /dev/null
> > > > > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > > @@ -0,0 +1,7 @@
> > > > > > > +ROC-RK3328-CC
> > > > > > > +M: Loic Devulder
> > > > > > > +M: Chen-Yu Tsai
> > > > > > > +S: Maintained
> > > > > > > +F: board/firefly/roc-cc-rk3328/
> > > > > > > +F: configs/roc-rk3328-cc_defconfig
> > > > > > > +F: arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile
> > > > > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > > new file mode 100644
> > > > > > > index ..1550b5f5f16e
> > > > > > > --- /dev/null
> > > > > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > > @@ -0,0 +1 @@
> > > > > > > +obj-y := board.o
> > > > > > > diff --git a/board/firefly/roc-cc-rk3328/board.c
> > > > > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > > > > new file mode 100644
> > > > > > > index ..eca58c86b53e
> > > > > > > --- /dev/null
> > > > > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > > > > @@ -0,0 +1,38 @@
> > > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > > +/*
> > > > > > > + * (C) Copyright 2020 Chen-Yu Tsai
> > > > > > > + */
> > > > > > > +#include
> > > > > > > +
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +
> > > > > > > +#if defined(CONFIG_SPL_BUILD)
> > > > > > > +
> > > > > > > +#define GRF_BASE 0xFF10
> > > > > > > +
> > > > > > > +enum {
> > > > > > > + GPIO_0_D6_GPIO = 0 << 12,
> > > > > > > + GPIO_0_D6_MASK = 0x3 << 12
> > > > > > > +};
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * The ROC-RK3328-CC has the enable pin of the SD card power
> > > > > > > switch tied
> > > > > > > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN,
> > > > > > > which is
> > > > > > > + * muxed by default. SDMMC0_PWREN is an active high signal
> > > > > > > controlled by
> > > > > > > + * the MMC controller, however the switch enable is active low,
> > > > > > > and
> > > > > > > + * pulled low (enabled) by default to make things work on boot.
> > > > > > > + *
> > > > > > > + * As such, we need to mux away from SDMMC0_PWREN and use GPIO
> > > > > > > to enable
> > > > > > > +
Re: [PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> Hi everyone,
>
> This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
> single board computer.
>
> The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> card size development board based on the Rockchip RK3328 SoC, with:
>
> - 1/2/4 GB DDR4 DRAM
> - eMMC connector for optional module
> - micro SD card slot
> - 1 x USB 3.0 host port
> - 2 x USB 2.0 host port
> - 1 x USB 2.0 OTG port
> - HDMI video output
> - TRRS connector with audio and composite video output
> - gigabit Ethernet
> - consumer IR receiver
> - debug UART pins
>
> Originally I started with Loic's patches, and syncing the device tree
> files from Linux. That didn't get very far, with SPL failing to detect
> the SD card. Examining the schematics and internal state of GRF and
> GPIOs, I realized that the logic for the SD card power enable switch
> is opposite that of what the SD card controller's SDMMC0_PWREN pin
> would use. Instead, directly using the GPIO is required.
>
> Thus this series creates a special target for this board to handle
> muxing this specific pin to GPIO state. The GPIO is left in input mode,
> letting the external pull-down work its magic.
>
> Along the way, there are some clean-ups of existing dts files, moving
> U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> from Linux. Only boards already existing in U-boot are synced. DT
> binding header files are synced separately as there is already one
> patch floating around. The DT sync also includes clean-up changes only
> recently posted, and likely won't make it in for at least a few weeks.
>
> Please have a look, and test if possible. I cc-ed a couple people that
> showed interest in this board on mailing lists recently.
>
Thank you for updating the dts for rk3328. I have Rock64 v2 and v3
boards and have tested your patchset with OpenBSD-current. The v2 board
is working and I have not noticed any regressions. The v3 board prior
to your patchset was not booting and continues to not boot.
U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24)
LPDDR3, 800MHz
BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 -0400)
Trying to boot from MMC1
Card did not respond to voltage select!
spl: mmc init failed with error: -95
Trying to boot from MMC2
Card did not respond to voltage select!
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
The Rock64 v3 board issues are unrelated to your patch set, but I
believe it needs a similar approach as ROC-RK3328-CC. Here is some
info previously posted regarding this:
https://marc.info/?t=15575150651=1=2
Regards,
-Kurt
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (6):
> rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
> rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
> dt-bindings: clock: rk3328: sync from upstream Linux kernel
> dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> rockchip: dts: rk3328: Sync device tree files from Linux
> rockchip: rk3328: Add support for ROC-RK3328-CC board
>
> arch/arm/dts/Makefile |1 +
> arch/arm/dts/rk3328-evb-u-boot.dtsi | 39 +
> arch/arm/dts/rk3328-evb.dts | 220 +--
> arch/arm/dts/rk3328-roc-cc-u-boot.dtsi| 17 +
> .../{rk3328-rock64.dts => rk3328-roc-cc.dts} | 135 +-
> arch/arm/dts/rk3328-rock64.dts| 132 +-
> arch/arm/dts/rk3328.dtsi | 1420 +++--
> arch/arm/mach-rockchip/rk3328/Kconfig |8 +
> board/firefly/roc-cc-rk3328/Kconfig | 24 +
> board/firefly/roc-cc-rk3328/MAINTAINERS |7 +
> board/firefly/roc-cc-rk3328/Makefile |1 +
> board/firefly/roc-cc-rk3328/board.c | 38 +
> configs/roc-cc-rk3328_defconfig | 97 ++
> doc/README.rockchip |4 +-
> include/dt-bindings/clock/rk3328-cru.h| 212 +--
> include/dt-bindings/power/rk3328-power.h | 19 +
> 16 files changed, 1622 insertions(+), 752 deletions(-)
> create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
> create mode 100644 board/firefly/roc-cc-rk3328/Kconfig
> create mode 100644 board/firefly/roc-cc-rk3328/MAINTAINERS
> create mode 100644 board/firefly/roc-cc-rk3328/Makefile
> create mode 100644 board/firefly/roc-cc-rk3328/board.c
> create mode 100644 configs/roc-cc-rk3328_defconfig
> create mode 100644 include/dt-bindings/power/rk3328-power.h
>
Re: [PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
On Sat, 2020-03-28 at 01:44 +0800, Chen-Yu Tsai wrote: > Hi, > > On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller > wrote: > > > > > > On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote: > > > > > > From: Chen-Yu Tsai > > > > > > Hi everyone, > > > > > > This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC > > > single board computer. > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit > > > card size development board based on the Rockchip RK3328 SoC, with: > > > > > > - 1/2/4 GB DDR4 DRAM > > > - eMMC connector for optional module > > > - micro SD card slot > > > - 1 x USB 3.0 host port > > > - 2 x USB 2.0 host port > > > - 1 x USB 2.0 OTG port > > > - HDMI video output > > > - TRRS connector with audio and composite video output > > > - gigabit Ethernet > > > - consumer IR receiver > > > - debug UART pins > > > > > > Originally I started with Loic's patches, and syncing the device tree > > > files from Linux. That didn't get very far, with SPL failing to detect > > > the SD card. Examining the schematics and internal state of GRF and > > > GPIOs, I realized that the logic for the SD card power enable switch > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin > > > would use. Instead, directly using the GPIO is required. > > > > > > Thus this series creates a special target for this board to handle > > > muxing this specific pin to GPIO state. The GPIO is left in input mode, > > > letting the external pull-down work its magic. > > > > > > Along the way, there are some clean-ups of existing dts files, moving > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync > > > from Linux. Only boards already existing in U-boot are synced. DT > > > binding header files are synced separately as there is already one > > > patch floating around. The DT sync also includes clean-up changes only > > > recently posted, and likely won't make it in for at least a few weeks. > > > > > > Please have a look, and test if possible. I cc-ed a couple people that > > > showed interest in this board on mailing lists recently. > > > > > Thank you for updating the dts for rk3328. I have Rock64 v2 and v3 > > boards and have tested your patchset with OpenBSD-current. The v2 board > > is working and I have not noticed any regressions. The v3 board prior > > to your patchset was not booting and continues to not boot. > > > > U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24) > > LPDDR3, 800MHz > > BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB > > Trying to boot from BOOTROM > > Returning to boot ROM... > > > > U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 > > -0400) > > Trying to boot from MMC1 > > Card did not respond to voltage select! > > spl: mmc init failed with error: -95 > > Trying to boot from MMC2 > > Card did not respond to voltage select! > > spl: mmc init failed with error: -95 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > The Rock64 v3 board issues are unrelated to your patch set, but I > > believe it needs a similar approach as ROC-RK3328-CC. Here is some > > info previously posted regarding this: > > > > https://marc.info/?t=15575150651=1=2 > So based on the changes from Pine64, it looks like v3 follows a similar > design as the ROC-RK3328-CC, that is use the SDMMC0_PWREN pin to control > power to the SD card. On the Rock64 v3, there's no external pull-down, > but the internal pull-down might be enough... > > You could try setting the target to ROC-RK3328-CC through menuconfig > after you use the defconfig for rock64 and see if that works for you. > Yes, that works for both the v2 and v3 boards. Thank you. Would you be able to create a patch 7 in your series to apply this approch to the rock64? Regards, -Kurt
[PATCH] dt-bindings: clock: rk3328 sync from upstream Linux kernel
This adds the following commits from upstream: 916f562fb28a Merge tag 'clk-for-linus' 0dc14b013f79 clk: rockchip: add clock id for watchdog pclk on rk3328 c942fddf8793 treewide: Replace GPLv2 boilerplate/reference with SPDX - e690d1b0dd3d Merge branch 'v4.21-shared/clkids' into v4.21-clk/next 02bee9e545ef clk: rockchip: add clock ID of ACODEC for rk3328 df7b1f2e0a4a clk: rockchip: fix ID of 8ch clock of I2S1 for rk3328 224a63844173 clk: rockchip: remove HCLK_VIO from rk3328 dt header bdc7dd67e7d9 clk: rockchip: add rk3328 clk_mac2io_ext ID 6cc1aef0ad0d clk: rockchip: add dt-binding header for rk3328 Signed-off-by: Kurt Miller --- include/dt-bindings/clock/rk3328-cru.h | 212 - 1 file changed, 106 insertions(+), 106 deletions(-) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index cde61ed883..555b4ff660 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -1,6 +1,7 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ +/* SPDX-License-Identifier: GPL-2.0-or-later */ /* - * (C) Copyright 2016 Rockchip Electronics Co., Ltd + * Copyright (c) 2016 Rockchip Electronics Co. Ltd. + * Author: Elaine */ #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H @@ -90,119 +91,118 @@ #define SCLK_MAC2IO_EXT102 /* dclk gates */ -#define DCLK_LCDC 180 -#define DCLK_HDMIPHY 181 -#define HDMIPHY182 -#define USB480M183 -#define DCLK_LCDC_SRC 184 +#define DCLK_LCDC 120 +#define DCLK_HDMIPHY 121 +#define HDMIPHY122 +#define USB480M123 +#define DCLK_LCDC_SRC 124 /* aclk gates */ -#define ACLK_AXISRAM 190 -#define ACLK_VOP_PRE 191 -#define ACLK_USB3OTG 192 -#define ACLK_RGA_PRE 193 -#define ACLK_DMAC 194 -#define ACLK_GPU 195 -#define ACLK_BUS_PRE 196 -#define ACLK_PERI_PRE 197 -#define ACLK_RKVDEC_PRE198 -#define ACLK_RKVDEC199 -#define ACLK_RKVENC200 -#define ACLK_VPU_PRE 201 -#define ACLK_VIO_PRE 202 -#define ACLK_VPU 203 -#define ACLK_VIO 204 -#define ACLK_VOP 205 -#define ACLK_GMAC 206 -#define ACLK_H265 207 -#define ACLK_H264 208 -#define ACLK_MAC2PHY 209 -#define ACLK_MAC2IO210 -#define ACLK_DCF 211 -#define ACLK_TSP 212 -#define ACLK_PERI 213 -#define ACLK_RGA 214 -#define ACLK_IEP 215 -#define ACLK_CIF 216 -#define ACLK_HDCP 217 +#define ACLK_AXISRAM 130 +#define ACLK_VOP_PRE 131 +#define ACLK_USB3OTG 132 +#define ACLK_RGA_PRE 133 +#define ACLK_DMAC 134 +#define ACLK_GPU 135 +#define ACLK_BUS_PRE 136 +#define ACLK_PERI_PRE 137 +#define ACLK_RKVDEC_PRE138 +#define ACLK_RKVDEC139 +#define ACLK_RKVENC140 +#define ACLK_VPU_PRE 141 +#define ACLK_VIO_PRE 142 +#define ACLK_VPU 143 +#define ACLK_VIO 144 +#define ACLK_VOP 145 +#define ACLK_GMAC 146 +#define ACLK_H265 147 +#define ACLK_H264 148 +#define ACLK_MAC2PHY 149 +#define ACLK_MAC2IO150 +#define ACLK_DCF 151 +#define ACLK_TSP 152 +#define ACLK_PERI 153 +#define ACLK_RGA 154 +#define ACLK_IEP 155 +#define ACLK_CIF 156 +#define ACLK_HDCP 157 /* pclk gates */ -#define PCLK_GPIO0 300 -#define PCLK_GPIO1 301 -#define PCLK_GPIO2 302 -#define PCLK_GPIO3 303 -#define PCLK_GRF 304 -#define PCLK_I2C0 305 -#define PCLK_I2C1 306 -#define PCLK_I2C2 307 -#define PCLK_I2C3 308 -#define PCLK_SPI 309 -#define PCLK_UART0 310 -#define PCLK_UART1 311 -#define PCLK_UART2 312 -#define PCLK_TSADC 313 -#define PCLK_PWM 314 -#define PCLK_TIMER 315 -#define PCLK_BUS_PRE 316 -#define PCLK_PERI_PRE 317 -#define PCLK_HDMI_CTRL 318 -#define PCLK_HDMI_PHY 319 -#define PCLK_GMAC 320 -#define PCLK_H265 321 -#define PCLK_MAC2PHY 322 -#define PCLK_MAC2IO323 -#define PCLK_USB3PHY_OTG 324 -#define PCLK_USB3PHY_PIPE 325 -#define PCLK_USB3_GRF 326 -#define PCLK_USB2_GRF 327 -#define PCLK_HDMIPHY 328 -#define PCLK_DDR 329 -#define PCLK_PERI 330 -#define PCLK_HDMI 331 -#define PCLK_HDCP
rockchip: rk3328 clock bindings
I noted that the u-boot clock bindings differ from upstream Linux for rk3328. Which values are correct and how does u-boot plan on addressing this discrepancy? https://github.com/u-boot/u-boot/blob/master/include/dt-bindings/clock/rk3328-cru.h vs https://github.com/torvalds/linux/blob/master/include/dt-bindings/clock/rk3328-cru.h For dclk gates, aclk gates, pclk gates and hclk gates the numbering differs. Thanks, -Kurt
Re: [U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected【请注意，邮件由lists.intric...@gmail.com代发】
Hi Kever, On Mon, 2019-11-18 at 11:05 +0800, Kever Yang wrote: > Hi Kurt, > > On 2019/11/14 上午2:44, Kurt Miller wrote: > > > > On Tue, 2019-09-17 at 12:02 -0400, Kurt Miller wrote: > > > > > > On Tue, 2019-09-17 at 10:57 +0800, Kever Yang wrote: > > > > > > > > Hi Kurt, > > > > > > > > Could you try with below update: > > > > > > > > > > > > diff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > > > b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > > > index 4a4414a960..dc9db047cb 100644 > > > > --- a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > > > +++ b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > > > @@ -13,8 +13,8 @@ > > > > 0x2 > > > > 0x1 > > > > 0x0 > > > > - 0xf > > > > - 0xf > > > > + 0x10 > > > > + 0x10 > > > > 1 > > > > 0x80241d22 > > > > 0x15050f08 > > > > @@ -28,8 +28,8 @@ > > > > 0x2 > > > > 0x1 > > > > 0x0 > > > > - 0xf > > > > - 0xf > > > > + 0x10 > > > > + 0x10 > > > > 1 > > > > 0x80241d22 > > > > 0x15050f08 > > > > > > > > Thanks, > > > > - Kever > > > Hi Kever, > > > > > > Yes, that diff does correct the memory size detection > > > for my board: > > > > > > U-Boot TPL 2019.10-rc3-00332-ga314ec1bfd-dirty (Sep 17 2019 - 11:55:26) > > > con reg > > > cru , cic , grf , sgrf , pmucru , pmu > > > Starting SDRAM initialization... > > > sdram_init: data trained for rank 1, ch 0 > > > sdram_init: data trained for rank 1, ch 1 > > > Channel 0: LPDDR4, 50MHz > > > BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB > > > Channel 1: LPDDR4, 50MHz > > > BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB > > > 256B stride > > > lpddr4_set_ctl: channel 0 training pass > > > lpddr4_set_ctl: channel 1 training pass > > > lpddr4_set_rate: change freq to 400 mhz 0, 1 > > > lpddr4_set_ctl: channel 0 training pass > > > lpddr4_set_ctl: channel 1 training pass > > > lpddr4_set_rate: change freq to 800 mhz 1, 0 > > > Finish SDRAM initialization... > > > Trying to boot from BOOTROM > > > Returning to boot ROM... > > Hi Kever, > > > > Following up on this issue. I retested 2020.01-rc2 to see if > > memory size detection has been fixed yet. Without your diff above > > applied, 2020.01-rc2 still detects 2G memory instead of 4G: > > Could you try with latest u-boot-rockchip? > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > The latest u-boot-rockchip does detect the correct memory size. I'll keep an eye out for the next rockchip pull to master occurs. Thank you, -Kurt U-Boot TPL 2020.01-rc2-04834-g59b01eb7a1-dirty (Nov 18 2019 - 10:34:14) con reg ffa8 ffa80800 ffa82000 ffa84000 ffa88000 ffa88800 ffa8a000 ffa8c000 cru ff76, cic ff62, grf ff32, sgrf ff33, pmucru ff75, pmu ff31 Starting SDRAM initialization... sdram_init: data trained for rank 1, ch 0 sdram_init: data trained for rank 1, ch 1 Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 8 mhz 1, 0 Finish SDRAM initialization... Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.01-rc2-04834-g59b01eb7a1-dirty (Nov 18 2019 - 10:34:14 -0500) Trying to boot from MMC1 NOTICE: BL31: v2.2(debug):2.2 NOTICE: BL31: Built : 10:33:33, Nov 18 2019 INFO:GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 INFO:plat_rockchip_pmu_init(1605): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 U-Boot 2020.01-rc2-04834-g59b01eb7a1-
Re: [U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected
On Tue, 2019-09-17 at 12:02 -0400, Kurt Miller wrote: > On Tue, 2019-09-17 at 10:57 +0800, Kever Yang wrote: > > > > Hi Kurt, > > > > Could you try with below update: > > > > > > diff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > index 4a4414a960..dc9db047cb 100644 > > --- a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > +++ b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > > @@ -13,8 +13,8 @@ > > 0x2 > > 0x1 > > 0x0 > > - 0xf > > - 0xf > > + 0x10 > > + 0x10 > > 1 > > 0x80241d22 > > 0x15050f08 > > @@ -28,8 +28,8 @@ > > 0x2 > > 0x1 > > 0x0 > > - 0xf > > - 0xf > > + 0x10 > > + 0x10 > > 1 > > 0x80241d22 > > 0x15050f08 > > > > Thanks, > > - Kever > Hi Kever, > > Yes, that diff does correct the memory size detection > for my board: > > U-Boot TPL 2019.10-rc3-00332-ga314ec1bfd-dirty (Sep 17 2019 - 11:55:26) > con reg > cru , cic , grf , sgrf , pmucru , pmu > Starting SDRAM initialization... > sdram_init: data trained for rank 1, ch 0 > sdram_init: data trained for rank 1, ch 1 > Channel 0: LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB > Channel 1: LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB > 256B stride > lpddr4_set_ctl: channel 0 training pass > lpddr4_set_ctl: channel 1 training pass > lpddr4_set_rate: change freq to 400 mhz 0, 1 > lpddr4_set_ctl: channel 0 training pass > lpddr4_set_ctl: channel 1 training pass > lpddr4_set_rate: change freq to 800 mhz 1, 0 > Finish SDRAM initialization... > Trying to boot from BOOTROM > Returning to boot ROM... Hi Kever, Following up on this issue. I retested 2020.01-rc2 to see if memory size detection has been fixed yet. Without your diff above applied, 2020.01-rc2 still detects 2G memory instead of 4G: U-Boot TPL 2020.01-rc2-dirty (Nov 13 2019 - 13:18:40) con reg ffa8 ffa80800 ffa82000 ffa84000 ffa88000 ffa88800 ffa8a000 ffa8c000 cru ff76, cic ff62, grf ff32, sgrf ff33, pmucru ff75, pmu ff31 Starting SDRAM initialization... sdram_init: data trained for rank 1, ch 0 sdram_init: data trained for rank 1, ch 1 Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB 256B stride lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 400 mhz 0, 1 lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 800 mhz 1, 0 Finish SDRAM initialization... Trying to boot from BOOTROM Returning to boot ROM... With your diff above applied I get 4G correctly: U-Boot TPL 2020.01-rc2-dirty (Nov 13 2019 - 13:23:22) con reg ffa8 ffa80800 ffa82000 ffa84000 ffa88000 ffa88800 ffa8a000 ffa8c000 cru ff76, cic ff62, grf ff32, sgrf ff33, pmucru ff75, pmu ff31 Starting SDRAM initialization... sdram_init: data trained for rank 1, ch 0 sdram_init: data trained for rank 1, ch 1 Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 400 mhz 0, 1 lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 800 mhz 1, 0 Finish SDRAM initialization... Trying to boot from BOOTROM Returning to boot ROM... Regards, -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix memory instability on ROCK64
On Sun, 2019-10-06 at 12:28 -0400, Simon South wrote: > These two patches fix small issues with the Rockchip RK3328 SDRAM > driver that prevented my PINE64 ROCK64 from booting and running > normally using U-Boot's TPL [1]. > > The first patch updates the phy_dll_bypass_set() function to use the > correct units for its DDR-frequency parameter, which is already > specified in MHz and does not need converting. This issue caused the > DRAM controller to be misconfigured for all but the lowest memory > speeds. > > The second patch fixes an apparent typo in phy_cfg() that caused the > DRAM controller's deskew registers to be loaded with incorrect values: > Instead of copying from the second 44-element portion of the > skew-value array the driver instead re-used a portion of the first. > This also produced instability. > > With both these patches applied my ROCK64 boots and runs normally > using the U-Boot TPL and a memory frequency of either 800 or 933 MHz: > In both cases the "mtest" memory-test command runs indefinitely > without error, and I can boot into NetBSD successfully without the > kernel hanging or panicking. > > [1] https://lists.denx.de/pipermail/u-boot/2019-September/384076.html > > Simon South (2): > ram: rk3328: Use correct frequency units in function > ram: rk3328: Fix loading of skew values > > drivers/ram/rockchip/sdram_rk3328.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Your corrections also have helped OpenBSD/arm64 boot using u-boot TPL on Rock64. Here is one test report result: https://marc.info/?l=openbsd-arm=157041723301520=2 Thank you for tracking down the problems. -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected【请注意，邮件由u-boot-boun...@lists.denx.de代发】 detected
On Thu, 2019-09-19 at 11:03 +0530, Jagan Teki wrote: > Hi Kever, > > On Wed, Sep 18, 2019 at 10:31 AM Jagan Teki > wrote: > > > > > > On Wed, Sep 18, 2019 at 9:09 AM Kever Yang > > wrote: > > > > > > > > > Hi Jagan, > > > > > > Seems like your and Kurt's board have different DRAM type: > > > > > > - 16bit row + 1 CS > > > > > > - 15bit row + 2 CS > > > > > > Capacity detect function is missing for the driver now, and it's not able > > > > > > to detect the correct size like Kurt is using. > > Got it. let me send the quick check patch, thanks. > Are you looking to fix this for the release? if yes, then we can > create another sdram*.dtsi for this specific dram board otherwise we > can fix this MW. Adding cap detection would alter the existing > behaviour of sdram driver, which indeed a risky to do at this point of > time since we are close to release. Hi Kever, Jagen, Is this being considered for fixing prior to release? My offer to test patches is still available. Thank you, -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected
On Tue, 2019-09-17 at 10:57 +0800, Kever Yang wrote: > Hi Kurt, > > Could you try with below update: > > > diff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > index 4a4414a960..dc9db047cb 100644 > --- a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > +++ b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > @@ -13,8 +13,8 @@ > 0x2 > 0x1 > 0x0 > - 0xf > - 0xf > + 0x10 > + 0x10 > 1 > 0x80241d22 > 0x15050f08 > @@ -28,8 +28,8 @@ > 0x2 > 0x1 > 0x0 > - 0xf > - 0xf > + 0x10 > + 0x10 > 1 > 0x80241d22 > 0x15050f08 > > Thanks, > - Kever Hi Kever, Yes, that diff does correct the memory size detection for my board: U-Boot TPL 2019.10-rc3-00332-ga314ec1bfd-dirty (Sep 17 2019 - 11:55:26) con reg cru , cic , grf , sgrf , pmucru , pmu Starting SDRAM initialization... sdram_init: data trained for rank 1, ch 0 sdram_init: data trained for rank 1, ch 1 Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB 256B stride lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 400 mhz 0, 1 lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 800 mhz 1, 0 Finish SDRAM initialization... Trying to boot from BOOTROM Returning to boot ROM... Thank you, -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected
Re-testing with master as of Sep 12 and the wrong memory size continues to be detected (2G detected while the board has 4G). The board has the following marking on it: Rockpro64_V2.1 2018-07-02 RAM Chips: PS052-053 BT 83RL I'd be happy to test any proposed patches to correct the memory size detection on this board. On Wed, 2019-08-28 at 17:45 -0400, Kurt Miller wrote: > The board has 4G memory but only 2G is detected by TPL. Please > let me know if additional information is needed. > > With u-boot master TPL output: > > U-Boot TPL 2019.10-rc3-00020-ge4b8dd9b34-dirty (Aug 28 2019 - 17:26:44) > LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB > LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB > 256B stride > Trying to boot from BOOTROM > Returning to boot ROM... > > With rkbin rk3399_ddr_800MHz_v1.23.bin output: > > DDR Version 1.23 20190709 > In > channel 0 > CS = 0 > MR0=0xB8 > MR4=0x2 > MR5=0xFF > MR8=0x10 > MR12=0x72 > MR14=0x72 > MR18=0x0 > MR19=0x0 > MR24=0x8 > MR25=0x0 > channel 1 > CS = 0 > MR0=0xB8 > MR4=0x2 > MR5=0xFF > MR8=0x10 > MR12=0x72 > MR14=0x72 > MR18=0x0 > MR19=0x0 > MR24=0x8 > MR25=0x0 > channel 0 training pass! > channel 1 training pass! > change freq to 416MHz 0,1 > Channel 0: LPDDR4,416MHz > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB > Channel 1: LPDDR4,416MHz > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB > 256B stride > channel 0 > CS = 0 > MR0=0xB8 > MR4=0x2 > MR5=0xFF > MR8=0x10 > MR12=0x72 > MR14=0x72 > MR18=0x0 > MR19=0x0 > MR24=0x8 > MR25=0x0 > channel 1 > CS = 0 > MR0=0xB8 > MR4=0x2 > MR5=0xFF > MR8=0x10 > MR12=0x72 > MR14=0x72 > MR18=0x0 > MR19=0x0 > MR24=0x8 > MR25=0x0 > channel 0 training pass! > channel 1 training pass! > channel 0, cs 0, advanced training done > channel 1, cs 0, advanced training done > change freq to 856MHz 1,0 > ch 0 ddrconfig = 0x101, ddrsize = 0x40 > ch 1 ddrconfig = 0x101, ddrsize = 0x40 > pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD > OUT ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] rockchip: rk3399: TPL: rockpro64: Wrong memory size detected
The board has 4G memory but only 2G is detected by TPL. Please let me know if additional information is needed. With u-boot master TPL output: U-Boot TPL 2019.10-rc3-00020-ge4b8dd9b34-dirty (Aug 28 2019 - 17:26:44) LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB 256B stride Trying to boot from BOOTROM Returning to boot ROM... With rkbin rk3399_ddr_800MHz_v1.23.bin output: DDR Version 1.23 20190709 In channel 0 CS = 0 MR0=0xB8 MR4=0x2 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0xB8 MR4=0x2 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0xB8 MR4=0x2 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0xB8 MR4=0x2 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD OUT ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
Hi Kever, On Tue, 2019-08-20 at 10:46 +0800, Kever Yang wrote: > Hi Kurt, > > > Does this patch fix your issue? > > https://patchwork.ozlabs.org/patch/1147457/ > Yes! It fixes my boot issue. Thank you for working on it. However there is a second issue. Only 2G of memory was recognized instead of the 4G the board has. I added this to get more debug output: diff --git a/drivers/ram/rockchip/sdram_rk3399.c b/drivers/ram/rockchip/sdram_rk3399.c index 81fc71c051..0f876217c8 100644 --- a/drivers/ram/rockchip/sdram_rk3399.c +++ b/drivers/ram/rockchip/sdram_rk3399.c @@ -5,6 +5,10 @@ * Adapted from coreboot. */ +#ifndef DEBUG +#define DEBUG +#endif + #include #include #include U-Boot TPL 2019.10-rc2-00036-ga2ca54ff52-dirty (Aug 20 2019 - 09:41:36) con reg cru , cic , grf , sgrf , pmucru , pmu Starting SDRAM initialization... sdram_init: data trained for rank 1, ch 0 sdram_init: data trained for rank 1, ch 1 Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB 256B stride lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 400 mhz 0, 1 lpddr4_set_ctl: channel 0 training pass lpddr4_set_ctl: channel 1 training pass lpddr4_set_rate: change freq to 800 mhz 1, 0 Finish SDRAM initialization... Trying to boot from BOOTROM Returning to boot ROM... Note that both the Row and Size differers from the rkbin TPL output: change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride Regards, -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
Hi Jagan, On Mon, 2019-08-19 at 23:26 +0530, Jagan Teki wrote: > Is your board running at 50MHz? (look like No). No it is running at 800Mhz or 856MHz (see rkbin TPL output below). > As I said please > explore step-by-step > 00: First boot the board rkbin => SPL => U-Boot proper This step was completed already. Here is the output again for reference: DDR Version 1.23 20190709 In channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD OUT > 01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and > replace rkbin withTPL I am stuck here. I see that there were three 800Mhz entries in the rkbin rk3399_ddr_800MHz_v1.20.bin file that was used to create ./arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi. rk3399-sdram-lpddr4-100.dtsi has one entry that appears to be from the first 800Mhz data in rk3399_ddr_800MHz_v1.20.bin. Using the instructions you linked: https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html I have inspected rkbin rk3399_ddr_800MHz_v1.23.bin and found there are two 800Mhz entries in it. I have extracted the two entries but have have questions that the instructions don't address well. Why does the existing rk3399-sdram-lpddr4-100.dtsi only have one entry while the instructions appear to indicate there should be two, one for single and another for dual ranked? Step 6 refers to editing the dtsi file: "..., edit the initial values (don’t forget that they are in little endian form) to match what the SPL code expects, convert the frequency value from the binary back into MHz (line 38 in the attached dtsi files for reference)" I believe I was able to convert the data into the updated values correctly (see attached diff). However, one value stood out to me. The 800Mhz value of 0x2faf0800 was converted into decimal 50 in the existing data whereas other sdram files converted it into 1/2 the Mhz value (e.g. 800Mhz -> 400). With it set to 50 I get this output before it stops: U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 18:45:16) pctl_start: Failed to init pctl for channel 0 With it set to 400 I get this output before it stops: U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 19:14:10) sdram_init: DDR3 - 400MHz failed! rk3399_dmc_init DRAM init failed -22 Missing DTB > 02: Then dump the regmap if 01 failed. > > Jagan. 01 failed. With the timings diff reverted I get this before it freezes: U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39) LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB 256B stride cic: ctr10: (0xff62 - 0x14) cic: status0: (0xff620010 - 0x101) grf: ddrc0_con0 (0xff77e380 - 0x1f81) grf: ddrc1_con0 (0xff77e388 - 0x1f81) grf: soc_con0 (0xff77e200 - 0x7) pmu: noc_auto_ena (0xff3100d8 - 0x0) pmu: bus_idle_req (0xff310060 - 0x0) pmu: bus_idle_st (0xff310064 - 0x0) pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1) pmugrf: os_reg3 (0xff32030c - 0x2005) pmusgrf: soc_con4 (0xff33e010 - 0x2600) Please let me know other items can be tried to get this up and running with the U-Boot TPL. Regards, -Kurtdiff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, 2019-08-19 at 22:08 +0530, Jagan Teki wrote: > On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller > wrote: > > > > > > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote: > > > > > > > > > > > > > > > From: Jagan Teki > > > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > > > > > + Kever > > > > > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > The Rockpro64_V2.1 2018-07-02 using master code base freezes > > > > > with only the following output: > > > > > > > > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - > > > > > 22:31:31) > > > > > > > > > > Whereas another board dated 2018-06-06 works and outputs the > > > > > following: > > > > > > > > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - > > > > > 22:31:31) > > > > > Trying to boot from BOOTROM > > > > > Returning to boot ROM... > > > > > > > > > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - > > > > > 22:31:31 +0200) > > > > > > > > > > Both board have 4G RAM. > > > > > > > > > > U-Boot was built by Mark Kettenis from master with only the > > > > > baud rate changed for both tests. The 2018-07-02 board has different > > > > > markings for the CPU and the RAM as follows: > > > > > > > > > > 2018-06-06 2018-07-02 > > > > > CPU: RK3399 RK3399 > > > > > SBETMF976 1652 SBETNM271 1826 > > > > > > > > > > RAM: PS006-075 BT PS052-053 BT > > > > > N1YJ 83RL > > > > > > > > > > Please let me know if there is additional information needed to > > > > > further diagnose the boot freeze. > > > > Please use mainline, and with doc/README.rockchip instructions. > > > This is mainline as of Aug 16. I built the image for Kurt and it the > > > same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my > > > board. > > > > > > > > > > > > > > > I'm able to boot with mainline tree. > > > Sure I can believe that. I believe your board from the same batch as > > > mine. I suspect that the DRAM used on Kurt's board may require > > > slightly different timings. > > > > > While my board (2018-07-02) freezes with Aug 16 mainline TPL, > > it does boot ok with the rockchip-linux TPL with the following > > output which may have some useful info: > I think rockchip-linux doesn't have lddr4 code instead they rely on > ddr bin, you can use same bin in Mainline w/o enabling TPL it would > work like > > rkbin => SPL => U-Boot proper > > > > > > > DDR Version 1.23 20190709 > > In > > channel 0 > > CS = 0 > > MR0=0xB8 > > MR4=0x1 > > MR5=0xFF > > MR8=0x10 > > MR12=0x72 > > MR14=0x72 > > MR18=0x0 > > MR19=0x0 > > MR24=0x8 > > MR25=0x0 > > channel 1 > > CS = 0 > > MR0=0xB8 > > MR4=0x1 > > MR5=0xFF > > MR8=0x10 > > MR12=0x72 > > MR14=0x72 > > MR18=0x0 > > MR19=0x0 > > MR24=0x8 > > MR25=0x0 > > channel 0 training pass! > > channel 1 training pass! > > change freq to 416MHz 0,1 > > Channel 0: LPDDR4,416MHz > > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB > > Channel 1: LPDDR4,416MHz > > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB > > 256B stride > > channel 0 > > CS = 0 > > MR0=0xB8 > > MR4=0x1 > > MR5=0xFF > > MR8=0x10 > > MR12=0x72 > > MR14=0x72 > > MR18=0x0 > > MR19=0x0 > > MR24=0x8 > > MR25=0x0 > > channel 1 > > CS = 0 > > MR0=0xB8 > > MR4=0x1 > > MR5=0xFF > > MR8=0x10 > > MR12=0x72 > > MR14=0x72 > > MR18=0x0 > > MR19=0x0 > > MR24=0x8 > > MR25=0x0 > > channel 0 training pass! > > channel 1 training pass! > > channel 0, cs 0, advanced training done > > channel 1, cs 0, advanced training done > > change freq to 856MHz 1,0 > > ch 0 ddrconfig = 0x101, ddrsize = 0x40 > > ch 1
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller
> wrote:
> >
> >
> > Hi Michael,
> >
> > On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > >
> > > It's possible to dump the register after training in mainline uboot?
> > I'm working on getting master to build now. How would I
> > go about dumping the register after training?
> It would be a bit hard, I tried below sequence at the end of
> sdram_init (sorry for direct copy)
>
> printf("cic: ctr10: (0x%x - 0x%x)\n", >cic->cic_ctrl0,
> readl(>cic->cic_ctrl0));
> printf("cic: status0: (0x%x - 0x%x)\n",
> >cic->cic_status0, readl(>cic->cic_status0));
> printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> >grf->ddrc0_con0, readl(>grf->ddrc0_con0));
> printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> >grf->ddrc1_con0, readl(>grf->ddrc1_con0));
> printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
> readl(>grf->soc_con0));
> printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> >pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
> printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> >pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
> printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> >pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
> printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> >pmugrf->os_reg2, readl(>pmugrf->os_reg2));
> printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> >pmugrf->os_reg3, readl(>pmugrf->os_reg3));
> printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> >pmusgrf->soc_con4, readl(>pmusgrf->soc_con4));
Thank you. I have built mainline with CONFIG_RAM_ROCKCHIP_DEBUG=y
with your printf's above and it outputs the following before freezing:
U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
cic: ctr10: (0xff62 - 0x14)
cic: status0: (0xff620010 - 0x101)
grf: ddrc0_con0 (0xff77e380 - 0x1f81)
grf: ddrc1_con0 (0xff77e388 - 0x1f81)
grf: soc_con0 (0xff77e200 - 0x7)
pmu: noc_auto_ena (0xff3100d8 - 0x0)
pmu: bus_idle_req (0xff310060 - 0x0)
pmu: bus_idle_st (0xff310064 - 0x0)
pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
pmugrf: os_reg3 (0xff32030c - 0x2005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)
Note that 'Size=1024MB' is incorrect. With 'rockchip-linux' TPL
I see 'Size=2048MB'.
Regards,
-Kurt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
Hi Michael, On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote: > It's possible to dump the register after training in mainline uboot? I'm working on getting master to build now. How would I go about dumping the register after training? Regards, -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote: > > > > From: Jagan Teki > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > + Kever > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > wrote: > > > > > > > > > Hello, > > > > > > The Rockpro64_V2.1 2018-07-02 using master code base freezes > > > with only the following output: > > > > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > > > > > Whereas another board dated 2018-06-06 works and outputs the following: > > > > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > > Trying to boot from BOOTROM > > > Returning to boot ROM... > > > > > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 > > > +0200) > > > > > > Both board have 4G RAM. > > > > > > U-Boot was built by Mark Kettenis from master with only the > > > baud rate changed for both tests. The 2018-07-02 board has different > > > markings for the CPU and the RAM as follows: > > > > > > 2018-06-06 2018-07-02 > > > CPU: RK3399 RK3399 > > > SBETMF976 1652 SBETNM271 1826 > > > > > > RAM: PS006-075 BT PS052-053 BT > > > N1YJ 83RL > > > > > > Please let me know if there is additional information needed to > > > further diagnose the boot freeze. > > Please use mainline, and with doc/README.rockchip instructions. > This is mainline as of Aug 16. I built the image for Kurt and it the > same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my > board. > > > > > I'm able to boot with mainline tree. > Sure I can believe that. I believe your board from the same batch as > mine. I suspect that the DRAM used on Kurt's board may require > slightly different timings. > While my board (2018-07-02) freezes with Aug 16 mainline TPL, it does boot ok with the rockchip-linux TPL with the following output which may have some useful info: DDR Version 1.23 20190709 In channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0xB8 MR4=0x1 MR5=0xFF MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD OUT ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
Hello, The Rockpro64_V2.1 2018-07-02 using master code base freezes with only the following output: U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) Whereas another board dated 2018-06-06 works and outputs the following: U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 +0200) Both board have 4G RAM. U-Boot was built by Mark Kettenis from master with only the baud rate changed for both tests. The 2018-07-02 board has different markings for the CPU and the RAM as follows: 2018-06-06 2018-07-02 CPU: RK3399 RK3399 SBETMF976 1652 SBETNM271 1826 RAM: PS006-075 BT PS052-053 BT N1YJ 83RL Please let me know if there is additional information needed to further diagnose the boot freeze. Regards, -Kurt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
