Re: [PATCH RESEND] clk: rockchip: rk3588: Set SPLL frequency during SPL stage

[Heiko Stübner]

Hi Quentin,

Am Mittwoch, 22. Mai 2024, 15:59:24 CEST schrieb Quentin Schulz:
> On 5/22/24 2:15 PM, Heiko Stuebner wrote:
> > From: Heiko Stuebner 
> > 
> > All parts expect the SPLL to run at 702MHz. In U-Boot it's the SPLL_HZ
> > declaring this rate and in the kernel it's a fixed clock definition.
> > 
> > While everything is expecting 702MHz, the SPLL is not running that
> > frequency when coming from the bootrom though, instead it's running
> > at 351MHz and the vendor-u-boot just sets it to the expected frequency.
> > 
> > The SPLL itself is located inside the secure-BUSCRU and in theory
> > accessible as an SCMI clock, though this requires an unknown amount
> > of cooperation from trusted-firmware to set at a later stage, though
> > during the SPL stage we can still access the relevant CRU directly.
> > 
> > The SPLL is for example necessary for the DSI controllers to produce
> > output.
> > 
> > As the SPLL is "just" another rk3588 pll, just set the desired rate
> > directly during the SPL stage.
> > 
> > Tested on rk3588-rock5b and rk3588-tiger by reading back the PLL rate
> > and also observing working DSI output with this change.
> > 
> > Fixes: 6737771600d4 ("rockchip: rk3588: Add support for sdmmc clocks in 
> > SPL")
> > Suggested-by: Andy Yan 
> > Signed-off-by: Heiko Stuebner 
> > Cc: Jonas Karlman 
> > ---
> > Resend, because I forgot the u-boot list
> > 
> >   .../include/asm/arch-rockchip/cru_rk3588.h|  1 +
> >   drivers/clk/rockchip/clk_rk3588.c | 26 ---
> >   2 files changed, 24 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h 
> > b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
> > index a4507e5fdd7..85b4da0bc2c 100644
> > --- a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
> > +++ b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
> > @@ -29,6 +29,7 @@ enum rk3588_pll_id {
> > V0PLL,
> > AUPLL,
> > PPLL,
> > +   SPLL,
> > PLL_COUNT,
> >   };
> >   
> > diff --git a/drivers/clk/rockchip/clk_rk3588.c 
> > b/drivers/clk/rockchip/clk_rk3588.c
> > index 4c611a39049..5384b3213f5 100644
> > --- a/drivers/clk/rockchip/clk_rk3588.c
> > +++ b/drivers/clk/rockchip/clk_rk3588.c
> > @@ -37,6 +37,7 @@ static struct rockchip_pll_rate_table rk3588_pll_rates[] 
> > = {
> > RK3588_PLL_RATE(78600, 1, 131, 2, 0),
> > RK3588_PLL_RATE(74250, 4, 495, 2, 0),
> > RK3588_PLL_RATE(722534400, 8, 963, 2, 24850),
> > +   RK3588_PLL_RATE(70200, 3, 351, 2, 0),
> > RK3588_PLL_RATE(6, 2, 200, 2, 0),
> > RK3588_PLL_RATE(59400, 2, 198, 2, 0),
> > RK3588_PLL_RATE(2, 3, 400, 4, 0),
> > @@ -65,6 +66,11 @@ static struct rockchip_pll_clock rk3588_pll_clks[] = {
> >  RK3588_MODE_CON0, 0, 15, 0, rk3588_pll_rates),
> > [PPLL] = PLL(pll_rk3588, PLL_PPLL, RK3588_PMU_PLL_CON(128),
> >  RK3588_MODE_CON0, 10, 15, 0, rk3588_pll_rates),
> > +#ifdef CONFIG_SPL_BUILD
> > +   /* SBUSCRU MODE_CON has the same register offset as the main MODE_CON */
> > +   [SPLL] = PLL(pll_rk3588, 0, RK3588_PLL_CON(136),
> > +RK3588_MODE_CON0, 0, 15, 0, rk3588_pll_rates),
> 
> FYI, it seems the rk3588 clock driver doesn't lock the PLL with the 
> lock_shift member, so 15 here is useless. Maybe we should switch 
> RK3588_PLLCON6_LOCK_STATUS to (1 << lock_shift) there for it to make 
> sense. Anyway, nothing specific to your patch.
> 
> RK3588_PLL_CON(136) is unreadable :/ Though I understand where it's 
> coming from as we have the same issue from V0PLL to PPLL. Can't we have 
> something a bit more proper here, e.g.
> 
> #define RK3588_SBUSCRU_SPLL_CON(x) ((x) * 4 + 0x220)
> 
> and then use RK3588_SBUSCRU_SPLL_CON(0) here?

sounds doable ;-)


> I'm also a bit wary of defining SPLL (and for that matter also V0PLL to 
> PPLL) with offsets relative to a different base than CRU (SBUSCRU for 
> SPLL for example) while all the others seem to have offsets relative to 
> CRU, c.f. RK3588_B0_PLL_CON(x). Specifically, it seems we are calling 
> rockchip_pll_set_rate with priv->cru which is the base of CRU. I am now
> not entirely sure anything from V0PLL to PPLL is actually working since 
> we use offsets relative to some xCRU but call the function with the 
> CRU_BASE.
> 
> So... wondering if we shouldn't have:
> 
> #define RK3588_SBUSCRU_BASE0x18000
> #define RK3588_SBUSCRU_SPLL_CON(x) ((x) * 4 + 0x220 + RK3588_SBUSCRU_BASE)
> 
> and then in the probe of the scru driver, use CRU_BASE as the base, 
> otherwise we're doing some mixing and I don't like that too much. Or 

At least for the SPLL we're calling

ret = rockchip_pll_set_rate(_pll_clks[SPLL],
   (void *)BUSSCRU_BASE, SPLL, SPLL_HZ);

so no mention of priv->cru there at all and the pll-function internally
only hand down that iomem pointer. The scru-clock driver also is
very specific to the SPL, as it the whole thing will be inaccessible
after TF-A has run.

Re: [PATCH 00/10] rockchip: px30: migrate to common bss and stack addresses + UART fixes for evb-px30

[Heiko Stübner]

Am Mittwoch, 22. Mai 2024, 10:39:25 CEST schrieb Quentin Schulz:
> Hi Tom,
> 
> On 5/21/24 8:04 PM, Tom Rini wrote:
> > On Tue, May 21, 2024 at 07:39:53PM +0200, Quentin Schulz wrote:
> >> PX30 Ringneck ran out of memory in the allocation pool of U-Boot proper
> >> pre-reloc. Something needed to be done. Jonas did migrate a few SoCs
> >> already to this common bss+stack addresses so it made sense to follow
> >> the same route for one additional SoC: PX30.
> >>
> >> While at it, also fix a few issues related to UART on the PX30 Mini EVB
> >> I could test.
> >>
> >> Boot (to U-Boot CLI) tested on PX30 Ringneck and PX30 Mini-EVB.
> >>
> >> Thanks to Jonas for hinting where to look at.
> >>
> >> Signed-off-by: Quentin Schulz 
> >> ---
> >> Quentin Schulz (10):
> >>rockchip: px30: default TPL_SYS_MALLOC_F_LEN to 0x600 on PX30 
> >> Kconfig level
> >>rockchip: Use common bss and stack addresses on PX30
> >>rockchip: ringneck_px30: Use common bss and stack addresses
> >>rockchip: evb-px30: Use common bss and stack addresses
> >>rockchip: firefly-px30: Use common bss and stack addresses
> >>rockchip: odroid-go2: Use common bss and stack addresses
> >>rockchip: px30-core-*: Use common bss and stack addresses
> >>rockchip: px30: make UART pinmux accessible to TPL/SPL DTB
> >>rockchip: evb-px30: do not remove pinctrl nodes from SPL DTB
> >>rockchip: evb-px30: make UART5 the debug UART
> >>
> >>   arch/arm/dts/px30-u-boot.dtsi | 16 
> >>   arch/arm/mach-rockchip/px30/Kconfig   |  8 +++-
> >>   configs/evb-px30_defconfig| 23 
> >> +--
> >>   configs/firefly-px30_defconfig| 19 +++
> >>   configs/odroid-go2_defconfig  | 19 +++
> >>   configs/px30-core-ctouch2-of10-px30_defconfig | 19 +++
> >>   configs/px30-core-ctouch2-px30_defconfig  | 19 +++
> >>   configs/px30-core-edimm2.2-px30_defconfig | 19 +++
> >>   configs/ringneck-px30_defconfig   | 19 +++
> >>   9 files changed, 46 insertions(+), 115 deletions(-)
> >> ---
> >> base-commit: a7f0154c412859323396111dd0c09dbafbc153cb
> >> change-id: 20240521-px30-2024-07-rc-7136f6241d29
> > 
> > As I assume we want to fix the platforms for v2024.07, is this the level
> > of config changes everyone is comfortable with on the platforms? Or
> > should we just go with the minimum for release and the rest to -next?
> > 
> 
> I can tell you that Ringneck doesn't work anymore on v2024.07-rc, but 
> the PX30 Mini EVB was still reaching U-Boot CLI without the changes. I 
> don't know about the other boards.
> 
> So I could split this into two series, one for master, one for next.
> 
> I could suggest: patch 1 to 3 in master, the rest in next. Patch 1 is 
> just moving things around. Patch 2 is doing nothing if nobody uses 
> ROCKCHIP_COMMON_STACK_ADDR and SPL_SHARES_INIT_SP_ADDR (which is the 
> case for px30 boards). Patch 3 is for fixing Ringneck, which I know is 
> broken.
> 
> Heiko having access to the Odroid Go2, maybe he could test without my 
> patches and see if it reaches the CLI to know if we should pull it in 
> for master as well.

I did that yesterday evening. The Odroid Go2 also reached u-boot CLI
and also booted without these changes. So I guess it's small enough
or whatever.

So at least the Go2 is fine on 2024.07-rc3 either way with or without
this series.

Heiko

Re: [PATCH 01/10] rockchip: px30: default TPL_SYS_MALLOC_F_LEN to 0x600 on PX30 Kconfig level

[Heiko Stübner]

Am Dienstag, 21. Mai 2024, 19:39:54 CEST schrieb Quentin Schulz:
> From: Quentin Schulz 
> 
> This is the kind of setting that typically doesn't need to be changed
> between boards based on the same SoC, so let's make it the default in
> PX30 Kconfig so we don't have to care about it in the defconfig if we
> don't want to.
> 
> Signed-off-by: Quentin Schulz 

the TPL part should be pretty similar for all boards, so having the malloc
pool size centrally makes a lot of sense.

Reviewed-by: Heiko Stuebner 

Re: [PATCH 00/10] rockchip: px30: migrate to common bss and stack addresses + UART fixes for evb-px30

[Heiko Stübner]

Am Dienstag, 21. Mai 2024, 19:39:53 CEST schrieb Quentin Schulz:
> PX30 Ringneck ran out of memory in the allocation pool of U-Boot proper
> pre-reloc. Something needed to be done. Jonas did migrate a few SoCs
> already to this common bss+stack addresses so it made sense to follow
> the same route for one additional SoC: PX30.
> 
> While at it, also fix a few issues related to UART on the PX30 Mini EVB
> I could test.
> 
> Boot (to U-Boot CLI) tested on PX30 Ringneck and PX30 Mini-EVB.
> 
> Thanks to Jonas for hinting where to look at.

u-boot 2024.07-rc3 with this series on an Odroid Go2

Tested-by: Heiko Stuebner 

Device boots and boots into a Debian image sucessfully.


Heiko

Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

[Heiko Stübner]

Am Dienstag, 14. Mai 2024, 18:42:36 CEST schrieb Tom Rini:

[...]

> git-subtree-dir: dts/upstream
> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> ---
> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> -next branch. To test these changes yourself locally, either use my
> "WIP/14May2024-next" branch or run:
> ./dts/update-dts-subtree.sh pull v6.9-dts
> yourself locally. I intend to wait a few days to apply this to -next, to
> give people time to test.

On
- rk3588-rock5b
- rk3588-jaguar
- rk3588-tiger (pending patch)

Tested-by: Heiko Stuebner 

Re: [PATCH v2] rockchip: add support for Theobroma Systems SOM-RK3588-Q7 Tiger module

[Heiko Stübner]

Am Mittwoch, 8. Mai 2024, 10:34:57 CEST schrieb Quentin Schulz:
> Hi Kever,
> 
> On 5/8/24 4:42 AM, Kever Yang wrote:
> > Hi Quentin,
> > 
> >  Could you please update this patch with OF_UPSTREAM support?
> > 
> 
> No, I cannot yet :/
> 
> Tiger is only available in Linux kernel v6.9-rcX and dts/ in U-Boot is 
> currently at v6.8.

Looks like Tom plans on updating the dts in -next soon'ish [0]
With the patch adapted to the OF_UPSTREAM situation
(dropping rk3588-tiger.dtsi and rk3588-tiger-haikou.dts and dropping
one usbdp node in -uboot.dtsi):

Tested-by: Heiko Stuebner 



[0] https://lore.kernel.org/all/20240514164236.516595-1-tr...@konsulko.com/

Re: [PATCH v2 1/2] rockchip: ringneck-px30: always reset STM32 companion controller on boot

[Heiko Stübner]

Am Freitag, 3. November 2023, 10:28:12 CET schrieb Quentin Schulz:
> From: Quentin Schulz 
> 
> It's happened that glitches on the STM32_RST and STM32_BOOT lines have
> put the STM32 companion microcontroller into DFU mode making it not boot
> its FW, rendering it useless for the user.
> 
> Considering that the STM32 companion microcontroller is always reset on
> a reboot or power cycle, resetting it once again in U-Boot SPL isn't
> going to hurt it any more.
> 
> For ATtiny companion microcontroller, the situation is a bit different
> because a reboot or power cycle doesn't reset it. Additionally, since it
> can only be reset with a UPDI reset on the STM32_RST line, and that is
> virtually impossible to mistakenly trigger, the ATtiny is unlikely to be
> in unwanted reset or enter reset because U-Boot toggles STM32_RST line.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 

Reviewed-by: Heiko Stuebner 

Re: [PATCH] rockchip: ringneck-px30: enable i2c command

[Heiko Stübner]

Am Mittwoch, 25. Oktober 2023, 13:17:12 CEST schrieb Quentin Schulz:
> From: Quentin Schulz 
> 
> This is a useful tool to check the presence of a device on a specific
> i2c bus, so let's enable it.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 

Reviewed-by: Heiko Stuebner 

Re: [PATCH 2/2] rockchip: ringneck-px30: enable SPL_BOARD_INIT

[Heiko Stübner]

Am Mittwoch, 25. Oktober 2023, 11:51:15 CEST schrieb Quentin Schulz:
> From: Quentin Schulz 
> 
> Now that Ringneck requires some board-specific code (namely resetting
> the MCU companion controller) to be run during SPL stage, let's enable
> SPL_BOARD_INIT.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 

Reviewed-by: Heiko Stuebner 

> ---
>  configs/ringneck-px30_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig
> index b4666d0e90f..420c9cd1e89 100644
> --- a/configs/ringneck-px30_defconfig
> +++ b/configs/ringneck-px30_defconfig
> @@ -38,6 +38,7 @@ CONFIG_SPL_PAD_TO=0x0
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
>  CONFIG_SPL_BSS_START_ADDR=0x400
>  CONFIG_SPL_BSS_MAX_SIZE=0x4000
> +CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_BOOTROM_SUPPORT=y
>  # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
>  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> 
> 

Re: [PATCH 1/2] rockchip: ringneck-px30: always reset STM32 companion controller on boot

[Heiko Stübner]

Hi Quentin,

Am Mittwoch, 25. Oktober 2023, 11:51:14 CEST schrieb Quentin Schulz:
> From: Quentin Schulz 
> 
> It's happened that glitches on the STM32_RST and STM32_BOOT lines have
> put the STM32 companion microcontroller into DFU mode making it not boot
> its FW, rendering it useless for the user.
> 
> Considering that the STM32 companion microcontroller is always reset on
> a reboot or power cycle, resetting it once again in U-Boot SPL isn't
> going to hurt it any more.
> 
> For ATtiny companion microcontroller, the situation is a bit different
> because a reboot or power cycle doesn't reset it. Additionally, since it
> can only be reset with a UPDI reset on the STM32_RST line, and that is
> virtually impossible to mistakenly trigger, the ATtiny is unlikely to be
> in unwanted reset or enter reset because U-Boot toggles STM32_RST line.
> 
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  .../ringneck_px30/ringneck-px30.c  | 52 
> ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c 
> b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
> index bb1bb4acf5c..804a991e281 100644
> --- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c
> +++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
> @@ -16,12 +16,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -169,3 +171,53 @@ int misc_init_r(void)
>  
>   return 0;
>  }
> +
> +#define STM32_RST100 // GPIO3_A4
> +#define STM32_BOOT   101 // GPIO3_A5

is "//" the preferred comment style in u-boot?
I'd somehow expect  "/* GPIO3_A4 */"


> +void spl_board_init(void)
> +{
> + /*
> +  * Glitches on STM32_BOOT and STM32_RST lines during poweroff or power
> +  * on may put the STM32 companion microcontroller into DFU mode, let's
> +  * always reset it into normal mode instead.
> +  * Toggling the STM32_RST line is safe to do with the ATtiny companion
> +  * microcontroller variant because it will not trigger an MCU reset
> +  * since only a UPDI reset command will. Since a UPDI reset is difficult
> +  * to mistakenly trigger, glitches to the lines are theoretically also
> +  * incapable of triggering an actual ATtiny reset.
> +  */
> + int ret = gpio_request(STM32_RST, "STM32_RST");
> +

nit: int ret;
ret = gpio_request()

so that is connects to the if(ret) below it, like the others?

> + if (ret) {
> + debug("Failed to request STM32_RST\n");
> + return;
> + }
> +
> + ret = gpio_request(STM32_BOOT, "STM32_BOOT");
> + if (ret) {
> + debug("Failed to request STM32_BOOT\n");
> + return;
> + }
> +
> + // Rely on HW pull-down for inactive level

nit: /* foo */ ?

> + ret = gpio_direction_input(STM32_BOOT);
> + if (ret) {
> + debug("Failed to configure STM32_BOOT\n");
> + return;
> + }
> +
> + ret = gpio_direction_output(STM32_RST, 0);
> + if (ret) {
> + debug("Failed to configure STM32_RST\n");
> + return;
> + }
> +
> + mdelay(1);
> +
> + ret = gpio_direction_output(STM32_RST, 1);
> + if (ret) {
> + debug("Failed to configure STM32_RST\n");
> + return;
> + }
> +}


Heiko

Re: [PATCH] riscv: fix compitible with binutils 2.38

[Heiko Stübner]

Hi,

Am Montag, 23. Mai 2022, 14:05:27 CEST schrieb Coelacanthus:
> commit 6df2a016c0c8a3d0933ef33dd192ea6606b115e3 from linux kernel
> 
> Since binutils 2.38, default ISA spec version switch to 20191213,
> in this version, original I extension be split into I, Zicsr and Zifencei.
> Zicsr is csr read/write (csrr*/csrw*) instructions, and Zifencei
> is fence.i instruction.
> This will cause compile error like this:
> Error: unrecognized opcode `csrr a5,0xc01'
> Error: unrecognized opcode `fence.i'
> 
> This commit add code to detect new Zicsr and Zifencei extensions,
> and enable it when needed.
> 
> Signed-off-by: Coelacanthus 
> Cc: Rick Chen 
> Cc: Leo 

while this fixes the build issue I'm seeing after a recent binutils,
there has been already a patch proposed for this fix [0]
and in that thread some pending issue was discussed as well.

So please coordinate with the other people over there :-)


Thanks
Heiko

[0] 
https://lore.kernel.org/all/20220128134713.2322800-1-alexandre.gh...@canonical.com/

> ---
>  arch/riscv/Makefile | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 0b80eb8d86..62712f8d38 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -24,7 +24,14 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
>   CMODEL = medany
>  endif
>  
> -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
> +RISCV_MARCH_y = $(ARCH_BASE)$(ARCH_A)$(ARCH_C)
> +
> +# Newer binutils versions default to ISA spec version 20191213 which moves 
> some
> +# instructions from the I extension to the Zicsr and Zifencei extensions.
> +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -mabi=$(ABI) 
> -march=$(RISCV_MARCH_y)_zicsr_zifencei)
> +RISCV_MARCH_$(toolchain-need-zicsr-zifencei) := 
> $(RISCV_MARCH_y)_zicsr_zifencei
> +
> +ARCH_FLAGS = -march=$(RISCV_MARCH_y) -mabi=$(ABI) \
>-mcmodel=$(CMODEL)
>  
>  PLATFORM_CPPFLAGS+= $(ARCH_FLAGS)
> 

Re: [PATCH] riscv: Fix build against binutils 2.38

[Heiko Stübner]

Am Freitag, 28. Januar 2022, 14:47:13 CEST schrieb Alexandre Ghiti:
> The following description is copied from the equivalent patch for the
> Linux Kernel proposed by Aurelien Jarno:
> 
> From version 2.38, binutils default to ISA spec version 20191213. This
> means that the csr read/write (csrr*/csrw*) instructions and fence.i
> instruction has separated from the `I` extension, become two standalone
> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> this causes the following build failure:
> 
> arch/riscv/cpu/mtrap.S: Assembler messages:
> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> 
> Signed-off-by: Alexandre Ghiti 

After upgrading my binutils to the recent snapshot package
in Debian-unstable (2.38.50.20220622-1), I've also run into that issue:

/home/devel/hstuebner/04_riscv/sun20i_d1_u-boot/drivers/timer/riscv_timer.c: 
Assembler messages:
/home/devel/hstuebner/04_riscv/sun20i_d1_u-boot/drivers/timer/riscv_timer.c:24: 
Error: unrecognized opcode `csrr a0,0xc01', extension `zicsr' required
make[3]: *** 
[/home/devel/hstuebner/04_riscv/sun20i_d1_u-boot/scripts/Makefile.build:254: 
drivers/timer/riscv_timer.o] Fehler 1


Is there progress in getting this patch applied to u-boot in some way?
Also it looks like there was another patch with similar content submitted
recently [0].


In any case:

On a D1-Nezha it fixes the build (and boot)
Tested-by: Heiko Stuebner 


Thanks
Heiko


[0] 
https://lore.kernel.org/all/ph7pr14mb5594fd11d1be74284f554bebce...@ph7pr14mb5594.namprd14.prod.outlook.com/

> ---
>  arch/riscv/Makefile | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 0b80eb8d86..53d1194ffb 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -24,7 +24,16 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
>   CMODEL = medany
>  endif
>  
> -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
> +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C)
> +
> +# Newer binutils versions default to ISA spec version 20191213 which moves 
> some
> +# instructions from the I extension to the Zicsr and Zifencei extensions.
> +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -mabi=$(ABI) 
> -march=$(RISCV_MARCH)_zicsr_zifencei)
> +ifeq ($(toolchain-need-zicsr-zifencei),y)
> + RISCV_MARCH := $(RISCV_MARCH)_zicsr_zifencei
> +endif
> +
> +ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \
>-mcmodel=$(CMODEL)
>  
>  PLATFORM_CPPFLAGS+= $(ARCH_FLAGS)
> 

Re: [PATCH] arm: dts: rk3399-puma: re-add vdd_log for uboot

[Heiko Stübner]

Hi Quentin,

Am Montag, 3. Januar 2022, 13:26:09 CET schrieb Quentin Schulz:
> Hi Heiko,
> 
> On 12/26/21 13:45, Heiko Stuebner wrote:
> > The rk3399-puma board needs a 950mV vdd_log to work stable.
> > This was already added in
> > commit 77012e79ffc3 ("rockchip: rk3399-puma: Set VDD_LOG to 950 mV")
> > but lost again with
> > commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
> > 
> > So to make puma stable again re-add the vdd_log pwm regulator.
> > As it is not part of the mainline Linux dts right now, add it
> > to the -u-boot dtsi for puma.
> > 
> > Fixes: 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
> > Signed-off-by: Heiko Stuebner 
> > ---
> >   arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 11 +++
> >   1 file changed, 11 insertions(+)
> > 
> > diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi 
> > b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > index 29846c4b00..76eb51d2d7 100644
> > --- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
> > @@ -49,6 +49,17 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <180>;
> > };
> > +
> > +   vdd_log: vdd-log {
> > +   compatible = "pwm-regulator";
> > +   pwms = < 0 25000 1>;
> > +   regulator-name = "vdd_log";
> > +   regulator-min-microvolt = <80>;
> > +   regulator-max-microvolt = <140>;
> > +   regulator-always-on;
> > +   regulator-boot-on;
> > +   regulator-init-microvolt = <95>;
> > +   };
> >   };
> >   
> >{
> 
> Is this a spurious patch by any chance?

yep, I realized that I was on 2021.01 still. Shortly after that the vdd_log was 
re-added
by Christoph.


Heiko

> 
> https://source.denx.de/u-boot/u-boot/-/commit/1621afc84f8a109cfdb98c9e370c355289e07870
>  
> seems to have more or less the same content, sent (and merged) about a 
> year ago by Christoph.
> 
> Moreover, it seems to still be there in master: 
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi#L52-L62
> 
> Cheers,
> Quentin
> 

Re: macb clock handling (Was: [PATCH v1 4/5] net: macb: Compatible as per device tree)

[Heiko Stübner]

Hi,

Am Donnerstag, 11. November 2021, 10:41:46 CET schrieb Heiko Stübner:
> not wanting to hijack this too much, but does the mac driver also need
> some sort of clock handling?
> 
> Because on the Icicle I have here, I'm running into "TX timeout" errors:
> 
> RISC-V # dhcp
> ethernet@20112000: PHY present at 9
> ethernet@20112000: Starting autonegotiation...
> ethernet@20112000: Autonegotiation complete
> ethernet@20112000: link up, 1000Mbps full-duplex (lpa: 0x3800)
> BOOTP broadcast 1
> ethernet@20112000: TX timeout
> BOOTP broadcast 2
> ethernet@20112000: TX timeout
> BOOTP broadcast 3
> ethernet@20112000: TX timeout
> BOOTP broadcast 4
> ethernet@20112000: TX timeout
> 
> The sifive variant of the macb distinguishes between speeds in its
> cllk_init callback, so I guess the Icicle might need that as well?

just for "the archive", i.e. when people read this in the future:

I got this solved by updating the HSS to a recent release (2021.11
in this case).

So now I do have working network in u-boot.


Heiko


> Am Freitag, 22. Oktober 2021, 10:56:47 CET schrieb Padmarao Begari:
> > Update compatible as per Microchip PolarFire SoC ethernet
> > device node.
> > 
> > Signed-off-by: Padmarao Begari 
> > ---
> >  drivers/net/macb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> > index 8c6461e717..1b867bd5c2 100644
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
> > { .compatible = "cdns,zynq-gem" },
> > { .compatible = "sifive,fu540-c000-gem",
> >   .data = (ulong)_config },
> > -   { .compatible = "microchip,mpfs-mss-gem",
> > +   { .compatible = "microchip,mpfs-gem",
> >   .data = (ulong)_config },
> > { }
> >  };
> > 
> 
> 

macb clock handling (Was: [PATCH v1 4/5] net: macb: Compatible as per device tree)

[Heiko Stübner]

Hi,

not wanting to hijack this too much, but does the mac driver also need
some sort of clock handling?

Because on the Icicle I have here, I'm running into "TX timeout" errors:

RISC-V # dhcp
ethernet@20112000: PHY present at 9
ethernet@20112000: Starting autonegotiation...
ethernet@20112000: Autonegotiation complete
ethernet@20112000: link up, 1000Mbps full-duplex (lpa: 0x3800)
BOOTP broadcast 1
ethernet@20112000: TX timeout
BOOTP broadcast 2
ethernet@20112000: TX timeout
BOOTP broadcast 3
ethernet@20112000: TX timeout
BOOTP broadcast 4
ethernet@20112000: TX timeout

The sifive variant of the macb distinguishes between speeds in its
cllk_init callback, so I guess the Icicle might need that as well?


Thanks
Heiko

Am Freitag, 22. Oktober 2021, 10:56:47 CET schrieb Padmarao Begari:
> Update compatible as per Microchip PolarFire SoC ethernet
> device node.
> 
> Signed-off-by: Padmarao Begari 
> ---
>  drivers/net/macb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 8c6461e717..1b867bd5c2 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
>   { .compatible = "cdns,zynq-gem" },
>   { .compatible = "sifive,fu540-c000-gem",
> .data = (ulong)_config },
> - { .compatible = "microchip,mpfs-mss-gem",
> + { .compatible = "microchip,mpfs-gem",
> .data = (ulong)_config },
>   { }
>  };
> 

Re: [PATCH v1] rockchip: rk3188-cru-common: sync clock dt-binding header from Linux

[Heiko Stübner]

Am Montag, 21. Juni 2021, 09:39:20 CEST schrieb Johan Jonker:
> In order to update the DT for rk3066 and rk3188
> sync the clock dt-binding header.
> This is the state as of v5.12 in Linux.
> 
> Signed-off-by: Johan Jonker 

Reviewed-by: Heiko Stuebner 

> ---
>  include/dt-bindings/clock/rk3188-cru-common.h | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/include/dt-bindings/clock/rk3188-cru-common.h 
> b/include/dt-bindings/clock/rk3188-cru-common.h
> index 1e7931da0c..afad90680f 100644
> --- a/include/dt-bindings/clock/rk3188-cru-common.h
> +++ b/include/dt-bindings/clock/rk3188-cru-common.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>  /*
>   * Copyright (c) 2014 MundoReader S.L.
>   * Author: Heiko Stuebner 
> @@ -59,12 +59,14 @@
>  #define ACLK_LCDC1   196
>  #define ACLK_GPU 197
>  #define ACLK_SMC 198
> -#define ACLK_CIF 199
> +#define ACLK_CIF1199
>  #define ACLK_IPP 200
>  #define ACLK_RGA 201
>  #define ACLK_CIF0202
>  #define ACLK_CPU 203
>  #define ACLK_PERI204
> +#define ACLK_VEPU205
> +#define ACLK_VDPU206
>  
>  /* pclk gates */
>  #define PCLK_GRF 320
> @@ -125,8 +127,12 @@
>  #define HCLK_NANDC0  467
>  #define HCLK_CPU 468
>  #define HCLK_PERI469
> +#define HCLK_CIF1470
> +#define HCLK_VEPU471
> +#define HCLK_VDPU472
> +#define HCLK_HDMI473
>  
> -#define CLK_NR_CLKS  (HCLK_PERI + 1)
> +#define CLK_NR_CLKS  (HCLK_HDMI + 1)
>  
>  /* soft-reset indices */
>  #define SRST_MCORE   2
> 

Re: [PATCH] ram: rockchip: px30: add a config-based ddr selection

[Heiko Stübner]

Hi Simon,

Am Freitag, 2. Oktober 2020, 07:58:35 CEST schrieb Heiko Stübner:
> Am Freitag, 2. Oktober 2020, 04:09:56 CEST schrieb Simon Glass:
> > On Thu, 1 Oct 2020 at 12:40, Heiko Stuebner  wrote:
> > >
> > > From: Heiko Stuebner 
> > >
> > > The SRAM on the PX30 is not big enough to hold multiple DDR configs
> > > so it needs to be selected during build.
> > >
> > > So far simply the DDR3 config was always selected and getting DDR4
> > > or LPDDR2/3 initialized would require a code modification.
> > >
> > > So add Kconfig options similar to RK3399 to allow selecting the DDR4
> > > and LPDDR2/3 options instead, while DDR3 stays the default as before.
> > >
> > > Signed-off-by: Heiko Stuebner 
> > > ---
> > >  drivers/ram/rockchip/Kconfig  | 21 +
> > >  drivers/ram/rockchip/sdram_px30.c |  8 
> > >  2 files changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/ram/rockchip/Kconfig b/drivers/ram/rockchip/Kconfig
> > > index 8e97c2f49e..c459bbf5e2 100644
> > > --- a/drivers/ram/rockchip/Kconfig
> > > +++ b/drivers/ram/rockchip/Kconfig
> > > @@ -22,6 +22,27 @@ config RAM_ROCKCHIP_DEBUG
> > >   This is an option for developers to understand the ram drivers
> > >   initialization, configurations and etc.
> > >
> > > +config RAM_PX30_DDR4
> > > +   bool "DDR3 support for Rockchip PX30"
> > > +   depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > > +   help
> > > + This enables DDR4 sdram support instead of the default DDR3 
> > > support
> > > + on Rockchip PC30 SoCs.
> > > +
> > > +config RAM_PX30_LPDDR2
> > > +   bool "LPDDR2 support for Rockchip PX30"
> > > +   depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > > +   help
> > > + This enables LPDDR2 sdram support instead of the default DDR3 
> > > support
> > > + on Rockchip PC30 SoCs.
> > > +
> > > +config RAM_PX30_LPDDR3
> > > +   bool "LPDDR3 support for Rockchip PX30"
> > > +   depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > > +   help
> > > + This enables LPDDR3 sdram support instead of the default DDR3 
> > > support
> > > + on Rockchip PC30 SoCs.
> > > +
> > >  config RAM_RK3399_LPDDR4
> > > bool "LPDDR4 support for Rockchip RK3399"
> > > depends on RAM_ROCKCHIP && ROCKCHIP_RK3399
> > > diff --git a/drivers/ram/rockchip/sdram_px30.c 
> > > b/drivers/ram/rockchip/sdram_px30.c
> > > index fd5763d0a0..2f1f6e9c0c 100644
> > > --- a/drivers/ram/rockchip/sdram_px30.c
> > > +++ b/drivers/ram/rockchip/sdram_px30.c
> > > @@ -125,7 +125,15 @@ u32 addrmap[][8] = {
> > >  struct dram_info dram_info;
> > >
> > >  struct px30_sdram_params sdram_configs[] = {
> > > +#if defined(CONFIG_RAM_PX30_DDR4)
> > > +#include   "sdram-px30-ddr4-detect-333.inc"
> > > +#elif defined(CONFIG_RAM_PX30_LPDDR2)
> > > +#include   "sdram-px30-lpddr2-detect-333.inc"
> > > +#elif defined(CONFIG_RAM_PX30_LPDDR3)
> > > +#include   "sdram-px30-lpddr3-detect-333.inc"
> > > +#else
> > >  #include   "sdram-px30-ddr3-detect-333.inc"
> > > +#endif
> > 
> > How about putting this in the device tree? I think that would be a better 
> > place.
> 
> On the PX30 the TPL does the ram initialization and the SRAM it runs in
> is very limited, so the PX30-TPL doesn't even have devicetree support
> available - hence the ram selection needs to selected at compiletime.
> 
> Even right now we're "dancing" very narrowly on the limit ;-)

Just to provide some more detail, in the PX30-TPL there is neither
devicetree nor driver model support and of the 10240bytes of
available sram, the current TPL binary already uses 10184 bytes.

So right now we have a whopping 56 bytes still available, which doesn't
leave wiggleroom at all and I actually need to hope that uboot stays
on its diet ;-) .


Heiko

Re: [PATCH] ram: rockchip: px30: add a config-based ddr selection

[Heiko Stübner]

Hi Simon,

Am Freitag, 2. Oktober 2020, 04:09:56 CEST schrieb Simon Glass:
> Hi Heiko,
> 
> On Thu, 1 Oct 2020 at 12:40, Heiko Stuebner  wrote:
> >
> > From: Heiko Stuebner 
> >
> > The SRAM on the PX30 is not big enough to hold multiple DDR configs
> > so it needs to be selected during build.
> >
> > So far simply the DDR3 config was always selected and getting DDR4
> > or LPDDR2/3 initialized would require a code modification.
> >
> > So add Kconfig options similar to RK3399 to allow selecting the DDR4
> > and LPDDR2/3 options instead, while DDR3 stays the default as before.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> >  drivers/ram/rockchip/Kconfig  | 21 +
> >  drivers/ram/rockchip/sdram_px30.c |  8 
> >  2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/ram/rockchip/Kconfig b/drivers/ram/rockchip/Kconfig
> > index 8e97c2f49e..c459bbf5e2 100644
> > --- a/drivers/ram/rockchip/Kconfig
> > +++ b/drivers/ram/rockchip/Kconfig
> > @@ -22,6 +22,27 @@ config RAM_ROCKCHIP_DEBUG
> >   This is an option for developers to understand the ram drivers
> >   initialization, configurations and etc.
> >
> > +config RAM_PX30_DDR4
> > +   bool "DDR3 support for Rockchip PX30"
> > +   depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > +   help
> > + This enables DDR4 sdram support instead of the default DDR3 
> > support
> > + on Rockchip PC30 SoCs.
> > +
> > +config RAM_PX30_LPDDR2
> > +   bool "LPDDR2 support for Rockchip PX30"
> > +   depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > +   help
> > + This enables LPDDR2 sdram support instead of the default DDR3 
> > support
> > + on Rockchip PC30 SoCs.
> > +
> > +config RAM_PX30_LPDDR3
> > +   bool "LPDDR3 support for Rockchip PX30"
> > +   depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > +   help
> > + This enables LPDDR3 sdram support instead of the default DDR3 
> > support
> > + on Rockchip PC30 SoCs.
> > +
> >  config RAM_RK3399_LPDDR4
> > bool "LPDDR4 support for Rockchip RK3399"
> > depends on RAM_ROCKCHIP && ROCKCHIP_RK3399
> > diff --git a/drivers/ram/rockchip/sdram_px30.c 
> > b/drivers/ram/rockchip/sdram_px30.c
> > index fd5763d0a0..2f1f6e9c0c 100644
> > --- a/drivers/ram/rockchip/sdram_px30.c
> > +++ b/drivers/ram/rockchip/sdram_px30.c
> > @@ -125,7 +125,15 @@ u32 addrmap[][8] = {
> >  struct dram_info dram_info;
> >
> >  struct px30_sdram_params sdram_configs[] = {
> > +#if defined(CONFIG_RAM_PX30_DDR4)
> > +#include   "sdram-px30-ddr4-detect-333.inc"
> > +#elif defined(CONFIG_RAM_PX30_LPDDR2)
> > +#include   "sdram-px30-lpddr2-detect-333.inc"
> > +#elif defined(CONFIG_RAM_PX30_LPDDR3)
> > +#include   "sdram-px30-lpddr3-detect-333.inc"
> > +#else
> >  #include   "sdram-px30-ddr3-detect-333.inc"
> > +#endif
> 
> How about putting this in the device tree? I think that would be a better 
> place.

On the PX30 the TPL does the ram initialization and the SRAM it runs in
is very limited, so the PX30-TPL doesn't even have devicetree support
available - hence the ram selection needs to selected at compiletime.

Even right now we're "dancing" very narrowly on the limit ;-)

Heiko

Re: [PATCH v6 1/8] lib: rsa: distinguish between tpl and spl for CONFIG_RSA_VERIFY

[Heiko Stübner]

Am Donnerstag, 18. Juni 2020, 16:23:21 CEST schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> While the SPL may want to do signature checking this won't be
> the case for TPL in all cases, as TPL is mostly used when the
> amount of initial memory is not enough for a full SPL.
> 
> So on a system where SPL uses DM but TPL does not we currently
> end up with a TPL compile error of:
> 
> lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete 
> type ‘struct checksum_algo’
> 
> To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguish
> between both. If someone really needs FIT signature checking in
> TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added.
> 
> Signed-off-by: Heiko Stuebner 
> Reviewed-by: Philipp Tomsich 

with it looking like everybody is happy with the fixes series now,
whom do I need to pester into picking it up? :-D


Thanks
Heiko


> ---
> changes in v5:
> - drop change that belongs in patch 2/8
> changes in v4:
> - amound -> amount
> - found another entry to handle
> changes in v2:
> - fix typo "distinguis(h)"
> 
>  lib/rsa/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
> index 14ed3cb401..c61ebfd79e 100644
> --- a/lib/rsa/Makefile
> +++ b/lib/rsa/Makefile
> @@ -5,6 +5,6 @@
>  # (C) Copyright 2000-2007
>  # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>  
> -obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
> +obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
>  obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
>  obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
> 

Re: [PATCH v4 6/6] rockchip: make_fit_atf: add signature handling

[Heiko Stübner]

Hi Tom,

Am Dienstag, 30. Juni 2020, 14:36:40 CEST schrieb Tom Rini:
> On Fri, Jun 19, 2020 at 12:45:50PM +0200, Heiko Stuebner wrote:
> 
> > From: Heiko Stuebner 
> > 
> > If the newly added fit-generator key-options are found, append needed
> > signature nodes to all generated image blocks, so that they can get
> > signed when mkimage later compiles the .itb from the generated .its.
> > 
> > Signed-off-by: Heiko Stuebner 
> 
> First, I want to echo what Simon said.  We need to move towards having
> less ad-hoc scripts for these kind of final modifiers.

looking at Simon's binman series is on my todo list, so yes I do agree
with you :-) .

> > ---
> >  arch/arm/mach-rockchip/make_fit_atf.py | 57 +-
> >  1 file changed, 56 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
> > b/arch/arm/mach-rockchip/make_fit_atf.py
> > index d15c32b303..de7dc19d11 100755
> > --- a/arch/arm/mach-rockchip/make_fit_atf.py
> > +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> > @@ -14,6 +14,14 @@ import sys
> >  import getopt
> >  import logging
> >  import struct
> > +try:
> > +   # in python3 Cryptodome succeeds Crypto
> > +   import Cryptodome
> > +   from Cryptodome.PublicKey import RSA
> > +except:
> > +   import Crypto
> > +   from Crypto.PublicKey import RSA
> 
> Is it that older python3 would support "Cryto" not "Cryptodome"  or
> python2?  If the latter, we should just drop it.  We do however need to
> document, and should try and be user friendly about catching the
> failure, that we now need the pycrypto module installed.  Thanks!

python3 only seems to have Cryptodome, while python2 only seems to
have Crypto. And with for example Debian's default python is still being
python2 for a bit longer, I wanted to support both, especially as it it
works like a drop-in replacement.

Heiko

Re: [BUG] ut lib lib_rsa_verify_valid crashes on qemu_arm if RSA_VERIFY_WITH_PKEY=y

[Heiko Stübner]

Am Dienstag, 9. Juni 2020, 12:22:36 CEST schrieb Heinrich Schuchardt:
> On 09.06.20 12:11, Heiko Stübner wrote:
> > Hi Akashi,
> >
> > Am Dienstag, 9. Juni 2020, 11:22:35 CEST schrieb AKASHI Takahiro:
> >> Heinrich,
> >>
> >> On Tue, Jun 09, 2020 at 03:54:44AM +, Heinrich Schuchardt wrote:
> >>> Am June 9, 2020 1:42:14 AM UTC schrieb AKASHI Takahiro 
> >>> :
> >>>> Heinrich,
> >>>>
> >>>> On Mon, Jun 08, 2020 at 11:08:53PM +0200, Heinrich Schuchardt wrote:
> >>>>> Hello Takahiro,
> >>>>>
> >>>>> when trying to execute command
> >>>>>
> >>>>> ut lib lib_rsa_verify_valid
> >>>>>
> >>>>> on qemu_arm_defconfig with CONFIG_UNIT_TEST=y and
> >>>>> CONFIG_RSA_VERIFY_WITH_PKEY=y it crashes in
> >>>>>
> >>>>> free((void *)prop->modulus) called from
> >>>>> rsa_free_key_prop() called from
> >>>>> rsa_verify_key() called from
> >>>>> rsa_verify_with_pkey().
> >>>>>
> >>>>> Without CONFIG_RSA_VERIFY_WITH_PKEY=y the problem does not occur.
> >>>>> On qemu_arm64_defconfig the problem does not occur.
> >>>>
> >>>> I can't reproduce your problem on v2020.07-rc4 exactly with
> >>>> qemu_arm64_defconfig + PKEY=y:
> >>>>
> >>>> U-Boot 2020.07-rc4-dirty (Jun 09 2020 - 10:33:30 +0900)
> >>>>
> >>>> ...
> >>>>
> >>>> => ut lib
> >>>> Running 11 lib tests
> >>>> Test: lib_asn1_pkcs7
> >>>> Test: lib_asn1_pkey
> >>>> Test: lib_asn1_x509
> >>>> Test: lib_memcpy
> >>>> Test: lib_memmove
> >>>> Test: lib_memset
> >>>> Test: lib_rsa_verify_invalid
> >>>> Test: lib_rsa_verify_valid
> >>>> Test: lib_test_bin2hex
> >>>> Test: lib_test_hex2bin
> >>>> Test: lib_test_hex_to_bin
> >>>> Failures: 0
> >>>>
> >>>>
> >>>> -Takahiro Akashi
> >>>
> >>> As said I only see the problem with 32 bit qemu_arm_defconfig.
> >>
> >> Okay. I think that the size of rrtmp variable is not good enough
> >> and when it is handed over to br_i32_decode(), it accidentally
> >> destroys (*prop)->modulus.
> >>
> >> Heiko's patch:
> >>   https://lists.denx.de/pipermail/u-boot/2020-May/413101.html
> >> will also fix this issue, but I'm not yet confident that
> >> the solution here, doubling max_rsa_size, is a right approach.
> >
> > The algorithm does write outside its memory area with a big enough key
> > and I have to confess I had a hard time understanding it ;-) .
> >
> > So what would be needed to get more confidence?
> >
> > Because for me it looks like either the algorithm does strange things
> > or the memory area is too small - I don't really see a third option ;-) .
> 
> Your patch allocates unnecessary memory for key sizes below 4096 and
> allocates too little for key sizes above 4096 bits. So with a bad key
> size you can crash the code again.

valid point :-) .

I guess I got sidetracked with u-boot signature handling only doing up
to 4096bit right now and was not questioning the existing usage of
max_rsa_size enough.

Re: [BUG] ut lib lib_rsa_verify_valid crashes on qemu_arm if RSA_VERIFY_WITH_PKEY=y

[Heiko Stübner]

Hi Akashi,

Am Dienstag, 9. Juni 2020, 11:22:35 CEST schrieb AKASHI Takahiro:
> Heinrich,
> 
> On Tue, Jun 09, 2020 at 03:54:44AM +, Heinrich Schuchardt wrote:
> > Am June 9, 2020 1:42:14 AM UTC schrieb AKASHI Takahiro 
> > :
> > >Heinrich,
> > >
> > >On Mon, Jun 08, 2020 at 11:08:53PM +0200, Heinrich Schuchardt wrote:
> > >> Hello Takahiro,
> > >> 
> > >> when trying to execute command
> > >> 
> > >> ut lib lib_rsa_verify_valid
> > >> 
> > >> on qemu_arm_defconfig with CONFIG_UNIT_TEST=y and
> > >> CONFIG_RSA_VERIFY_WITH_PKEY=y it crashes in
> > >> 
> > >> free((void *)prop->modulus) called from
> > >> rsa_free_key_prop() called from
> > >> rsa_verify_key() called from
> > >> rsa_verify_with_pkey().
> > >> 
> > >> Without CONFIG_RSA_VERIFY_WITH_PKEY=y the problem does not occur.
> > >> On qemu_arm64_defconfig the problem does not occur.
> > >
> > >I can't reproduce your problem on v2020.07-rc4 exactly with
> > >qemu_arm64_defconfig + PKEY=y:
> > >
> > >U-Boot 2020.07-rc4-dirty (Jun 09 2020 - 10:33:30 +0900)
> > >
> > >...
> > >
> > >=> ut lib
> > >Running 11 lib tests
> > >Test: lib_asn1_pkcs7
> > >Test: lib_asn1_pkey
> > >Test: lib_asn1_x509
> > >Test: lib_memcpy
> > >Test: lib_memmove
> > >Test: lib_memset
> > >Test: lib_rsa_verify_invalid
> > >Test: lib_rsa_verify_valid
> > >Test: lib_test_bin2hex
> > >Test: lib_test_hex2bin
> > >Test: lib_test_hex_to_bin
> > >Failures: 0
> > >
> > >
> > >-Takahiro Akashi
> > 
> > As said I only see the problem with 32 bit qemu_arm_defconfig.
> 
> Okay. I think that the size of rrtmp variable is not good enough
> and when it is handed over to br_i32_decode(), it accidentally
> destroys (*prop)->modulus.
> 
> Heiko's patch:
>   https://lists.denx.de/pipermail/u-boot/2020-May/413101.html
> will also fix this issue, but I'm not yet confident that
> the solution here, doubling max_rsa_size, is a right approach.

The algorithm does write outside its memory area with a big enough key
and I have to confess I had a hard time understanding it ;-) .

So what would be needed to get more confidence?

Because for me it looks like either the algorithm does strange things
or the memory area is too small - I don't really see a third option ;-) .


Heiko

Re: [PATCH v5 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()

[Heiko Stübner]

Am Freitag, 22. Mai 2020, 16:19:31 CEST schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> Right now in multiple places there are only checks for the full
> CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants.
> 
> This breaks when the rsa functions get enabled for SPL, for example to
> verify u-boot proper from spl.
> 
> So fix this by using the existing helpers to distinguis between
> build-steps.
> 
> Signed-off-by: Heiko Stuebner 

transplanting a tag from v4:
Reviewed-by: Philipp Tomsich 

Re: [PATCH v5 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations

[Heiko Stübner]

Am Freitag, 22. Mai 2020, 16:19:35 CEST schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> padding_pss_verify only works with the default pss salt setting of -2
> (length to be automatically determined based on the PSS block structure)
> not -1 (salt length set to the maximum permissible value), which makes
> verifications of signatures with that saltlen fail.
> 
> Until this gets implemented at least document this behaviour.
> 
> Signed-off-by: Heiko Stuebner 

transplanting a tag from v4:
Reviewed-by: Philipp Tomsich 

Re: [PATCH v5 3/8] lib: rsa: bring exp_len in line when generating a key_prop

[Heiko Stübner]

Am Freitag, 22. Mai 2020, 16:19:32 CEST schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> The exponent field of struct key_prop gets allocated an uint64_t,
> and the contents are positioned from the back, so an exponent of
> "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1"
> 
> Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len
> to the size returned from the parser, while on the other hand the
> when getting the key from the devicetree exp_len always gets set to
> sizeof(uint64_t).
> 
> So bring that in line with the established code.
> 
> Signed-off-by: Heiko Stuebner 

transplanting a tag from v4:
Reviewed-by: Philipp Tomsich 

Re: [PATCH v5 5/8] lib: rsa: free local arrays after use in rsa_gen_key_prop()

[Heiko Stübner]

Am Freitag, 22. Mai 2020, 16:19:34 CEST schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> n, rr and rrtmp are used for internal calculations, but in the end
> the results are copied into separately allocated elements of the
> actual key_prop, so the n, rr and rrtmp elements are not used anymore
> when returning from the function and should of course be freed.
> 
> Signed-off-by: Heiko Stuebner 

transplanting a tag from v4:
Reviewed-by: Philipp Tomsich 

Re: [PATCH v5 4/8] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()

[Heiko Stübner]

Am Freitag, 22. Mai 2020, 16:19:33 CEST schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> When calculating rrtmp/rr rsa_gen_key_prop() tries to make
> (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and
> (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[]
> with rlen being num_bits * 2
> 
> On a 4096bit key this comes down to to 257 uint32_t elements
> in rr and 256 elements in rrtmp but with the current allocation
> rr and rrtmp only have 129 uint32_t elements.
> 
> On 2048bit keys this works by chance as the defined max_rsa_size=4096
> allocates a suitable number of elements, but with an actual 4096bit key
> this results in other memory parts getting overwritten.
> 
> so double the number of elements in rr and rrtmp so that it matches
> the needed number and should increase nicely if max_rsa_size gets
> increased in the future.
> 
> Signed-off-by: Heiko Stuebner 

transplanting a tag from v4:
Reviewed-by: Simon Glass 

Re: [PATCH 1/2] rockchip: spl: do full dram_init instead of only probing

[Heiko Stübner]

Hi Kever,

Am Freitag, 15. Mai 2020, 04:07:41 CEST schrieb Kever Yang:
> 
> On 2020/5/12 下午6:34, Heiko Stuebner wrote:
> > From: Heiko Stuebner 
> >
> > Parts of later SPL may need RAM information as well, so do full
> > dram_init() call, which includes the existing dram probing but also
> > initializes the ram information in gd.
> 
> NAK.
> 
> I would prefer to use DM interface and leave the decision of ram 
> initialization to the ram driver.

With CONFIG_SPL_RAM, we get dram_init from mach-rockchip/sdram.c
not some board-specific variant and the in the code change below you
can see that it is guarded by such a defined(CONFIG_SPL_RAM).

That dram_init() function does only:
- uclass_get_device(UCLASS_RAM, 0, );
- ram_get_info(dev, );
- gd->ram_size = ram.size;


So the only difference between the old code and my change is that it
will store information about usable ram in the gd struct, so that other
parts of the SPL can access it - and we of course keep using the DM
interface as before ;-) .


Heiko


> > All Rockchip SoCs use a TPL+SPL combination now, so that's ok for all
> > of them.
> Still not all of the board use the combination.
> >
> > Signed-off-by: Heiko Stuebner 
> > Change-Id: I2c7496f2d88d65a9f80f74d2139bf307bb4b442b
> 
> Please remove the Change-Id next time.
> 
> Thanks,
> 
> - Kever
> 
> > ---
> >   arch/arm/mach-rockchip/spl.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> > index 0b76af6080..0eda2c3485 100644
> > --- a/arch/arm/mach-rockchip/spl.c
> > +++ b/arch/arm/mach-rockchip/spl.c
> > @@ -135,13 +135,15 @@ void board_init_f(ulong dummy)
> > /* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
> > timer_init();
> >   #endif
> > -#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_OS_BOOT)
> > +#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_RAM)
> > debug("\nspl:init dram\n");
> > -   ret = uclass_get_device(UCLASS_RAM, 0, );
> > +   ret = dram_init();
> > if (ret) {
> > printf("DRAM init failed: %d\n", ret);
> > return;
> > }
> > +   gd->ram_top = gd->ram_base + get_effective_memsize();
> > +   gd->ram_top = board_get_usable_ram_top(gd->ram_size);
> >   #endif
> > preloader_console_init();
> >   }
> 
> 
> 

Re: [PATCH v2 7/7] rockchip: make_fit_atf: add signature handling

[Heiko Stübner]

Hi Kever,

Am Freitag, 1. Mai 2020, 12:32:23 CEST schrieb Kever Yang:
> 
> On 2020/4/21 上午8:23, Heiko Stuebner wrote:
> > From: Heiko Stuebner 
> >
> > If the newly added fit-generator key-options are found, append needed
> > signature nodes to all generated image blocks, so that they can get
> > signed when mkimage later compiles the .itb from the generated .its.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> >   arch/arm/mach-rockchip/make_fit_atf.py | 51 +-
> >   1 file changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
> > b/arch/arm/mach-rockchip/make_fit_atf.py
> > index d15c32b303..5b353f9d0a 100755
> > --- a/arch/arm/mach-rockchip/make_fit_atf.py
> > +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> > @@ -14,6 +14,8 @@ import sys
> >   import getopt
> >   import logging
> >   import struct
> > +import Crypto
> > +from Crypto.PublicKey import RSA
> >   
> 
> +Traceback (most recent call last):
> 1395 
> +
>  
> File "arch/arm/mach-rockchip/make_fit_atf.py", line 17, in 
> 1396 
> +
>  
> import Crypto
> 1397 
> +ModuleNotFoundError:
>  
> No module named 'Crypto'
> 
> 
> Please help to update .gitlab-ci.yml, or else it will report the error.

I'm not sure, how ... i.e. the missing package is 
"pycrypto" (or "python-crypto" when installing from a distribution package)

So I guess it's about adding that dependency to both .travis.yml and
.gitlab-ci.yml, but is it enough to just do a


diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index beaf9b9042..863c3dea51 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -68,6 +68,7 @@ build all 64bit ARM platforms:
 - virtualenv -p /usr/bin/python3 /tmp/venv
 - . /tmp/venv/bin/activate
 - pip install pyelftools
+- pip install pycrypto
 - ret=0;
   ./tools/buildman/buildman -o /tmp -P -E -W aarch64 || ret=$?;
   if [[ $ret -ne 0 ]]; then

Re: [PATCH] rsa: fix alignment issue when getting public exponent

[Heiko Stübner]

Am Montag, 4. Mai 2020, 16:17:52 CEST schrieb Simon Glass:
> +Tom Rini
> 
> On Sun, 3 May 2020 at 05:26, Heiko Stuebner  wrote:
> >
> > From: Heiko Stuebner 
> >
> > To fill the exponent field of the rsa_public_key struct, rsa_mod_exp_sw
> > did a cast to uint64_t of the key_prop->public_exponent field.
> > But that alignment is not guaranteed in all cases.
> >
> > This came to light when in my spl-fit-signature the key-name exceeded
> > a certain length and with it the verification then started failing.
> > (naming it "integrity" worked fine, "integrity-uboot" failed)
> >
> > key_prop.public_exponent itself is actually a void-pointer, fdt_getprop()
> > also just returns such a void-pointer and inside the devicetree the 64bit
> > exponent is represented as 2 32bit numbers, so assuming a 64bit alignment
> > can lead to false reads.
> >
> > So just use the already existing rsa_convert_big_endian() to do the actual
> > conversion from the dt's big-endian to the needed uint64 value.
> >
> > Fixes: fc2f4246b4b3 ("rsa: Split the rsa-verify to separate the modular 
> > exponentiation")
> > Signed-off-by: Heiko Stuebner 
> > ---
> >  lib/rsa/rsa-mod-exp.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> 
> Nice find! This probably changed when we updated the DT recently since
> the unaligned-access thing was reverted I think. Or has this problem
> been there forever?

To me it looks like it must've been present since the beginning.
In commit e0f2f1553414 ("Implement generalised RSA public exponents for 
verified boot")
which introduced the exponent handling it already did:

const uint64_t *public_exponent;
public_exponent = fdt_getprop(blob, node, "rsa,exponent", );

So if the fdt_getprop internals didn't change since then it would've
even then cast the void* to an uint64*


I really don't understand yet why the longer key-name would trigger it
though ... names like "dev", "integrity" work fine and seemingly starting
at a certain length the alignment changed.


Heiko

> Reviewed-by: Simon Glass 
> 

Re: [PATCH v2 7/7] rockchip: make_fit_atf: add signature handling

[Heiko Stübner]

Hi Kever,

Am Freitag, 1. Mai 2020, 12:32:23 CEST schrieb Kever Yang:
> On 2020/4/21 上午8:23, Heiko Stuebner wrote:
> > From: Heiko Stuebner 
> >
> > If the newly added fit-generator key-options are found, append needed
> > signature nodes to all generated image blocks, so that they can get
> > signed when mkimage later compiles the .itb from the generated .its.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> >   arch/arm/mach-rockchip/make_fit_atf.py | 51 +-
> >   1 file changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
> > b/arch/arm/mach-rockchip/make_fit_atf.py
> > index d15c32b303..5b353f9d0a 100755
> > --- a/arch/arm/mach-rockchip/make_fit_atf.py
> > +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> > @@ -14,6 +14,8 @@ import sys
> >   import getopt
> >   import logging
> >   import struct
> > +import Crypto
> > +from Crypto.PublicKey import RSA
> >   
> 
> +Traceback (most recent call last):
> 1395 
> +
>  
> File "arch/arm/mach-rockchip/make_fit_atf.py", line 17, in 
> 1396 
> +
>  
> import Crypto
> 1397 
> +ModuleNotFoundError:
>  
> No module named 'Crypto'
> 
> 
> Please help to update .gitlab-ci.yml, or else it will report the error.

The ci stuff probably needs to install pycrypto from pip (or python-crypto
when using a .deb), but I have no clue how this works or how to test any
changes to that locally.

But I guess something like below might do the trick?

Heiko


diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index beaf9b9042..863c3dea51 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -68,6 +68,7 @@ build all 64bit ARM platforms:
 - virtualenv -p /usr/bin/python3 /tmp/venv
 - . /tmp/venv/bin/activate
 - pip install pyelftools
+- pip install pycrypto
 - ret=0;
   ./tools/buildman/buildman -o /tmp -P -E -W aarch64 || ret=$?;
   if [[ $ret -ne 0 ]]; then

Re: [PATCH v2 5/7] spl: fit: enable signing a generated u-boot.itb

[Heiko Stübner]

Hi Kever,

Am Donnerstag, 30. April 2020, 11:03:38 CEST schrieb Kever Yang:
> This patch will cause build fail on sandbox_spl_defconfig:
> 
> dtc: option requires an argument -- 'p'

sandbox_spl is confusing on first glance, it enables the spl_fit-options
but does not define any fit sources.

But I also found a general issue with my code below, and by fixing that
one sandbox_spl also gets happy again.

> On 2020/4/21 上午8:23, Heiko Stuebner wrote:
> > From: Heiko Stuebner 
> >
> > With SPL_FIT_SIGNATURE enabled we will likely want a generated
> > u-boot.itb to be signed and the key stores so that the spl can
> > reach it.
> >
> > So add a SPL_FIT_SIGNATURE_KEY_DIR option and suitable hooks
> > into the Makefile to have mkimage sign the .itb and store the
> > used key into the spl dtb file.
> >
> > The added dependencies should make sure that the u-boot.itb
> > gets generated before the spl-binary gets build, so that there
> > is the necessary space for the key to get included.
> >
> > Signed-off-by: Heiko Stuebner 
> > Reviewed-by: Philipp Tomsich 
> > ---
> >   Kconfig  |  8 
> >   Makefile | 11 ++-
> >   2 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/Kconfig b/Kconfig
> > index 4051746319..15a783a67d 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -451,6 +451,14 @@ config SPL_FIT_SIGNATURE
> > select SPL_RSA_VERIFY
> > select IMAGE_SIGN_INFO
> >   
> > +config SPL_FIT_SIGNATURE_KEY_DIR
> > +   string "key directory for signing U-Boot FIT image"
> > +   depends on SPL_FIT_SIGNATURE
> > +   default "keys"
> > +   help
> > + The directory to give to mkimage to retrieve keys from when
> > + generating a signed U-Boot FIT image.
> > +
> >   config SPL_LOAD_FIT
> > bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
> > select SPL_FIT
> > diff --git a/Makefile b/Makefile
> > index 26307fd4a6..8e7a7cb50e 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1394,6 +1394,14 @@ MKIMAGEFLAGS_u-boot.itb =
> >   else
> >   MKIMAGEFLAGS_u-boot.itb = -E
> >   endif
> > +ifdef CONFIG_SPL_FIT_SIGNATURE
> > +ifdef CONFIG_SPL_OF_CONTROL
> > +MKIMAGEFLAGS_u-boot.itb += -K dts/dt-spl.dtb -r
> > +ifneq ($(CONFIG_SPL_FIT_SIGNATURE_KEY_DIR),"")
> > +MKIMAGEFLAGS_u-boot.itb += -k $(CONFIG_SPL_FIT_SIGNATURE_KEY_DIR)
> > +endif
> > +endif
> > +endif
> >   
> >   u-boot.itb: u-boot-nodtb.bin \
> > $(if 
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
> > @@ -1913,7 +1921,8 @@ spl/u-boot-spl.bin: spl/u-boot-spl
> >   
> >   spl/u-boot-spl: tools prepare \
> > $(if 
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb)
> >  \
> > -   $(if 
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
> > +   $(if 
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
> >  \
> > +   $(if $(CONFIG_SPL_FIT_GENERATOR),u-boot.itb FORCE)

I now realized that this is the wrong check ... i.e. it only checks for
SPL_FIT_GENERATOR but that is a string so always defined if SPL_LOAD_FIT
is enabled ... also this doesn't take into account SPL_FIT_SOURCE, so the
way to go seems to be to check against $U_BOOT_ITS and
CONFIG_SPL_FIT_SIGNATZRE instead which gets defined if a suitable fit
source is available.


Background for this dependency is that the signature must be done before
the spl-binary gets build, because mkimage for the .itb needs to write the
key to the spl dtb.


I'll send an updated patch as a reply to this mail.


Heiko

Re: [PATCH 4/8] usb: dwc3: add make compatible for rockchip platform

[Heiko Stübner]

Am Dienstag, 28. April 2020, 11:21:07 CEST schrieb Marek Vasut:
> On 4/28/20 11:05 AM, Frank Wang wrote:
> > Hi Marek,
> > 
> > On 2020/4/28 16:27, Marek Vasut wrote:
> >> On 4/28/20 8:27 AM, Frank Wang wrote:
> >>> RK3399 Type-C PHY is required that must hold whole USB3.0 OTG controller
> >>> in resetting to hold pipe power state in P2 before initializing the PHY.
> >>> This commit fixed it and added device compatible for rockchip platform.
> >>>
> >>> Signed-off-by: Frank Wang 
> >>> ---
> >>>   drivers/usb/dwc3/dwc3-generic.c | 33 +++--
> >>>   1 file changed, 27 insertions(+), 6 deletions(-)
> >>>
> >>> [...]
> >>>   +/*
> >>> + * It must hold whole USB3.0 OTG controller in resetting to hold
> >>> pipe
> >>> + * power state in P2 before initializing TypeC PHY on RK3399
> >>> platform.
> >>> + */
> >>> +if (device_is_compatible(dev->parent, "rockchip,rk3399-dwc3")) {
> >>> +reset_assert_bulk(>resets);
> >>> +udelay(1);
> >> Reset delay should be handled by the reset controller, no ?
> > This is dwc3's reset phandle linked to CRU on Rockchip platform,
> > however, the reset driver just update the register value, and the timing
> > need to be guaranteed by invoker itself.
> 
> If the reset controller needs a delay after toggling the bit, then it
> should add such delay, no ?

But normally the time a reset line should be pulled low/high whatever
is specified in the datasheet of the relevant controller (type-c phy here).

My most recent experience is with dsi panels, where the panel-controller's
datasheet specifies how long its reset line needs to be pulled to achieve
a full reset of the controller - and I guess it will be similar with other
controllers.

So to me this doesn't look like a property of the reset controller, but the
controller connected to the reset line - especially as different
"reset-clients" will have different timing constraints.


Heiko

Re: [PATCH 7/7] rockchip: make_fit_atf: add signature handling

[Heiko Stübner]

Hi Simon,

Am Montag, 20. April 2020, 01:38:20 CEST schrieb Simon Glass:
> On Fri, 17 Apr 2020 at 16:07, Heiko Stuebner  wrote:
> >
> > From: Heiko Stuebner 
> >
> > If the newly added fit-generator key-options are found, append needed
> > signature nodes to all generated image blocks, so that they can get
> > signed when mkimage later compiles the .itb from the generated .its.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> >  arch/arm/mach-rockchip/make_fit_atf.py | 51 +-
> >  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> Was there an effort to move this to binman?

The generation really is part of the core build process.
When creating the u-boot.itb with signed entries, mkimage -K writes the
data of the used key to dt-spl.dtb which then gets put into the spl binary.
[spl needs the key-data in its dtb to verify the signatures]

So I don't really see how this would work without moving the whole
spl generation to binman.


Heiko

Re: [U-Boot] [PATCH v2 2/2] rockchip: px30: enable spl-fifo-mode for both emmc and sdmmc on evb

[Heiko Stübner]

Hi Patrick,

Am Donnerstag, 28. November 2019, 00:38:45 CET schrieb Patrick Wildt:
> On Tue, Nov 19, 2019 at 12:04:02PM +0100, Heiko Stuebner wrote:
> > From: Heiko Stuebner 
> > 
> > As part of loading trustedfirmware, the SPL is required to place portions
> > of code into the socs sram but the mmc controllers can only do dma
> > transfers into the regular memory, not sram.
> > 
> > The results of this are not directly visible in u-boot itself, but
> > manifest as security-relate cpu aborts during boot of for example Linux.
> > 
> > There were a number of attempts to solve this elegantly but so far
> > discussion is still ongoing, so to make the board at least boot correctly
> > put both mmc controllers into fifo-mode, which also circumvents the
> > issue for now.
> > 
> > Signed-off-by: Heiko Stuebner 
> 
> Hi,
> 
> is this also needed on RK3399 based machines?  I have a NanoPC-T4,
> where the eMMC is on the Arasan controller and the SD card on the
> dwmmc.  So if I boot from SD card I need this as well?

I think so. That dma-to-sram issue is supposed to be present on a lot
(maybe all?) Rockchip SoCs. And I think I remember running into that
issue on rk3399 as well already in the past.

Not sure if that is limited to the dw-mmc only though or the arasan is
also affected - maybe Kever knows :-)


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] tests: add OP-TEE test suite

[Heiko Stübner]

Am Mittwoch, 23. Oktober 2019, 16:46:41 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> OP-TEE can get supplied with a devicetree and will then insert
> its firmware node and reserved-memory sections into it.
> As this devicetree often is not the one supplied to a later
> loaded kernel, a previous commit added functionality to transfer
> these nodes onto that new devicetree.
> 
> To make sure this functionality stays intact, also add a test
> for the transfer functionality.
> 
> Signed-off-by: Heiko Stuebner 

this patch already received in v2 a
Reviewed-by: Simon Glass 



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/4] fdtdec: only create phandle if caller wants it in fdtdec_add_reserved_memory()

[Heiko Stübner]

Am Mittwoch, 23. Oktober 2019, 16:46:39 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> The phandlep pointer returning the phandle to the caller is optional
> and if it is not set when calling fdtdec_add_reserved_memory() it is
> highly likely that the caller is not interested in a phandle to the
> created reserved-memory area and really just wants that area added.
> 
> So just don't create a phandle in that case.
> 
> Signed-off-by: Heiko Stuebner 

this patch already received in v2 a
Reviewed-by: Simon Glass 



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/4] fdtdec: protect against another NULL phandlep in fdtdec_add_reserved_memory()

[Heiko Stübner]

Am Mittwoch, 23. Oktober 2019, 16:46:38 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner 
> 
> The change adding fdtdec_add_reserved_memory() already protected the added
> phandle against the phandlep being NULL - making the phandlep var optional.
> 
> But in the early code checking for an already existing carveout this check
> was not done and thus the phandle assignment could run into trouble,
> so add a check there as well, which makes the function still return
> successfully if a matching region is found, even though no-one wants to
> work with the phandle.
> 
> Fixes: c9222a08b3f7 ("fdtdec: Implement fdtdec_add_reserved_memory()")
> Signed-off-by: Heiko Stuebner 

this patch already received in v2 a
Reviewed-by: Simon Glass 




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] rockchip: clk: rv1108: remove duplicate reset init

[Heiko Stübner]

Hi Kever,

Am Donnerstag, 7. November 2019, 10:03:19 CET schrieb Kever Yang:
> On 2019/10/24 上午1:45, Heiko Stuebner wrote:
> > rockchip_reset_bind() already does the needed init for the reset
> > registers, only referenced the wrong cru structure.
> >
> > So we can get rid of the open-coded reset init and just fix
> > the correct cru reference.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> >   drivers/clk/rockchip/clk_rv1108.c | 13 +
> >   1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/clk/rockchip/clk_rv1108.c 
> > b/drivers/clk/rockchip/clk_rv1108.c
> > index 3ebb007fab..5dc31e1eb0 100644
> > --- a/drivers/clk/rockchip/clk_rv1108.c
> > +++ b/drivers/clk/rockchip/clk_rv1108.c
> > @@ -698,22 +698,11 @@ static int rv1108_clk_bind(struct udevice *dev)
> > }
> >   
> >   #if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)
> > -   ret = offsetof(struct rk3368_cru, softrst_con[0]);
> > +   ret = offsetof(struct rv1108_cru, softrst_con[0]);
> > ret = rockchip_reset_bind(dev, ret, 13);
> > if (ret)
> > debug("Warning: software reset driver bind faile\n");
> >   #endif
> > -   ret = device_bind_driver_to_node(dev, "rockchip_reset", "reset",
> > -dev_ofnode(dev), _child);
> 
> You can't just remove this blob of code, for there is a 'sysreset' 
> driver and a 'reset' driver, they are
> 
> different, so you should fix this part to be available 'sysreset' driver 
> so that the software can reset the SoC.

While there is a sysreset driver, it seems the rv1108 only did init
the softrst code here and not the sysreset at all.

So rockchip_reset_bind really only does the same as the remove
part of code. What I did see was that struct softreset_reg
still is defined in the rockchip clock.h and after this patch no-one
is using at all anymore. The rockchip_reset driver uses a different
struct altogether it seems.

Adding an appropriate sysreset driver for rv1108
should likely be a separate patch though.

Heiko


> > -   if (ret) {
> > -   debug("Warning: No rockchip reset driver: ret=%d\n", ret);
> > -   } else {
> > -   sf_priv = malloc(sizeof(struct softreset_reg));
> > -   sf_priv->sf_reset_offset = offsetof(struct rv1108_cru,
> > -   softrst_con[0]);
> > -   sf_priv->sf_reset_num = 13;
> > -   sf_child->priv = sf_priv;
> > -   }
> >   
> > return 0;
> >   }
> 
> 
> 




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] rockchip: make_fit_atf.py: allow inclusion of a tee binary

[Heiko Stübner]

Hi Simon,

Am Mittwoch, 30. Oktober 2019, 02:49:46 CET schrieb Simon Glass:
> On Tue, 22 Oct 2019 at 03:45, Kever Yang  wrote:
> > On 2019/10/22 上午7:46, Simon Glass wrote:
> > > On Mon, 14 Oct 2019 at 03:07, Kever Yang  
> > > wrote:
> > >>
> > >> On 2019/10/7 上午2:10, Heiko Stuebner wrote:
> > >>> A trusted execution environment should also get loaded as loadable from
> > >>> a fit image, so add the possibility to present a tee.elf to 
> > >>> make_fit_atf.py
> > >>> that then gets included as additional loadable into the generated its.
> > >>>
> > >>> For ease of integration the additional loadable is created as atf_(x+1)
> > >>> after all others to re-use core generation loops.
> > >>>
> > >>> Tested against the combinations of 1-part-atf and multi-part-atf each
> > >>> time with and without a tee binary present.
> > >>>
> > >>> Signed-off-by: Heiko Stuebner 
> > >> Reviewed-by: Kever Yang
> > >>
> > >>
> > >> Thanks,
> > >> - Kever
> > >>> ---
> > >>> changes in v2: none
> > >>>
> > >>>arch/arm/mach-rockchip/make_fit_atf.py | 52 
> > >>> +++---
> > >>>1 file changed, 46 insertions(+), 6 deletions(-)
> > > I see there is an effort to move this to binman. To me that is a much
> > > more productive approach!
> >
> >
> > Do you mean the patch set from Jagan for rockchip platform to using binman?
> >
> > That patch is actually using the output of the u-boot.itb which is based
> > on this script.
> >
> > >
> > > Is there a feature or example missing in binman that you need to get
> > > this over the hump?
> >
> >
> > I think Heiko and you has a discussion about this in previous version
> > thread.
> > The U-Boot project build output is: tpl.bin, spl.bin, u-boot.bin
> > For rockchip platform, package needs:
> > - pack tpl.bin+spl.bin with mkimage -rksd/rkspi into idbloader.img
> > - get ATF binaries from bl31.bin/optee.bin with a script
> > - generate u-boot.its to describe the u-boot.itb
> > - pack u-boot.bin and ATF/OPTEE binaries into u-boot.itb with mkimage -f
> > u-boot.its
> >
> > Does the binman mainly target for pack the idbloader.img+u-boot.itb?
> 
> I actually think binman could handle all of that.
> 
> Is there something I could do that would help with that?

I think the main sparse element is time here and maybe a voluteer with
enough of time available to lay the groundwork.

Like on my personal side, I really don't see me finding the time to
actually look at binman and finding out how everything should
translate from the current state to binman - soonish.

Hooking up new small things into an existing infrastructure is somehow
alway easier ;-) . 

Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 11/12] rockchip: add px30 architecture core

[Heiko Stübner]

Hi Kever,

Am Freitag, 25. Oktober 2019, 04:49:54 CEST schrieb Kever Yang:
> On 2019/10/25 上午7:28, Heiko Stuebner wrote:
> > From: Kever Yang 
> >
> > Add core architecture code to support the px30 soc.
> > This includes a separate tpl board file due to very limited
> > sram size as well as a non-dm sdram driver, as this also has
> > to fit into the tiny sram.
> 
> 
> Could you leave the sram code and make it possible to use the common 
> sdram code
> 
> I have send out:
> 
> https://patchwork.ozlabs.org/cover/1183700/
> 
> The sram driver should goes to driver/ram folder instead of arch/arm folder.

That won't work. For the px30, the ddr-init portion will need to stay in
arch-rockchip/px30 I'm afraid.

To compile things in drivers/ram you need to have TPL_RAM enabled
which in turn depends on TPL_DM which in turn makes the tpl size
to big.

So drivers/ram/... can probably only contain the dm-based part I introduce
in patch9 of this series.


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] image: fdt: copy possible optee nodes to a loaded devicetree

[Heiko Stübner]

Hi Patrick,

Am Mittwoch, 23. Oktober 2019, 09:10:52 CEST schrieb Patrick DELAUNAY:
> Hi Jens and Heiko,
> 
> > From: U-Boot  On Behalf Of Jens Wiklander
> > Sent: mercredi 23 octobre 2019 08:46
> > 
> > On Tue, Oct 22, 2019 at 09:04:27PM +0200, Heiko Stuebner wrote:
> > > From: Heiko Stuebner 
> > >
> > > The loading convention for optee or any other tee on arm64 is as bl32
> > > parameter to the trusted-firmware. So TF-A gets invoked with the TEE
> > > as
> > > bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps
> > > into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33.
> > >
> > > All of them get passed a devicetree as parameter and all components
> > > often get loaded from a FIT image.
> > >
> > > OP-TEE will create additional nodes in that devicetree namely a
> > > firmware node and possibly multiple reserved-memory nodes.
> > >
> > > While this devicetree is used in main u-boot, in most cases it won't
> > > be the one passed to the actual kernel. Instead most boot commands
> > > will load a new devicetree from somewhere like mass storage of the
> > > network, so if that happens u-boot should transfer the optee nodes to 
> > > that new
> > devicetree.
> > >
> > > To make that happen introduce optee_copy_fdt_nodes() called from the
> > > dt setup function in image-fdt which after checking for the optee
> > > presence in the u-boot dt will make sure a optee node is present in
> > > the kernel dt and transfer any reserved-memory regions it can find.
> > >
> > > Signed-off-by: Heiko Stuebner 
> > > ---
> > > changes in v2:
> > > - don't create a new optee firmware-node, but instead copy the
> > >   compatible+method properties from the old fdt blob.
> > >
> > >  common/image-fdt.c  |   8 +++
> > >  include/tee/optee.h |   9 +++
> > >  lib/optee/optee.c   | 132 
> > >  3 files changed, 149 insertions(+)
> > >
> > [snip]
> 
> On STM32MP1 platform (armv7 with TF-A support), 
> we can use BL32 = OP-TEE or spmin provide by TF-A

That is the same I'm hoping to have at some point for the RK3288
soc I'm also working on :-D .

But why do you need different handling then? Except BL32 being baked
into the TF-A binary on arm32, shouldn't the loading patch be somewhat
similar (SPL -> TF-A -> OP-Tee -> U-Boot) so that OP-Tee also can insert its
nodes there?

(Haven't looked too deeply at this yet)

> So we are plan to have the same type of feature but with an inversed logical:
> 
> - Op-Tee nodes (firmwares and reserved) are present in kernel device tree
> - U-Boot deactivated these nodes when TEE is not present, with the next 
> function called in ft_system_setup:

Having the OP-Tee nodes hard-coded in the devicetree in kernel sources
sounds somewhat counter intuitive to me.

For the firmware node it shouldn't matter much, except that there may
also be other TEEs other than OP-Tee that people may want to load.

But when the reserved memory is hard-coded in the kernel, you bind
yourself to one specific version of your TEE. I.e. what happens when
a future version of your platform support wants to move the memory
region OP-Tee wants to occupy. With OP-Tee handling the reservation
this should be somewhat transparent to bootloader and kernel, as
just the reserved-memory changes.


> static void stm32_fdt_disable_optee(void *blob)
> {
>   int off, node;
> 
>   off = fdt_node_offset_by_compatible(blob, -1, "linaro,optee-tz");
>   if (off >= 0 && fdtdec_get_is_enabled(blob, off))
>   fdt_status_disabled(blob, off);
> 
>   /* Disabled "optee@..." reserved-memory node */
>   off = fdt_path_offset(blob, "/reserved-memory/");
>   if (off < 0)
>   return;
>   for (node = fdt_first_subnode(blob, off);
>node >= 0;
>node = fdt_next_subnode(blob, node)) {
>   if (!strncmp(fdt_get_name(blob, node, NULL), "optee@", 6))
>   fdt_status_disabled(blob, node);
>   }
> }
> 
> What is  the better for you ?
> 1/ Copy the U-Boot op-tee nodes in kernel device tree (where op-tee nodes was 
> present)
> or 
> 2/ Deactivate the op-tee nodes in kernel device tree (where op-tee nodes are 
> present)
> 
> The advantage of us is to upstream a Linux Kernel device tree with the 
> correct op-tee nodes...

In any case, the copying we're doing here should not affect any present
OP-Tee nodes in the kernel dts and only proceed if both
(a) U-Boot dts does contain an OP-Tee node
(b) Kernel dts does _not yet_ contain an OP-Tee node

are valid.


Heiko

> > Looks good to me:
> > Reviewed-by: Jens Wiklander 
> > 
> > Cheers,
> > Jens
> 
> Patrick
> 




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] image: fdt: copy possible optee nodes to a loaded devicetree

[Heiko Stübner]

Hi Simon,

Am Dienstag, 22. Oktober 2019, 14:08:04 CEST schrieb Heiko Stübner:
> Am Dienstag, 22. Oktober 2019, 02:17:00 CEST schrieb Simon Glass:
> > On Mon, 7 Oct 2019 at 18:22, Heiko Stuebner  wrote:
> > >
> > > The loading convention for optee or any other tee on arm64 is as bl32
> > > parameter to the trusted-firmware. So TF-A gets invoked with the TEE as
> > > bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps
> > > into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33.
> > >
> > > All of them get passed a devicetree as parameter and all components often
> > > get loaded from a FIT image.
> > >
> > > OP-TEE will create additional nodes in that devicetree namely a firmware
> > > node and possibly multiple reserved-memory nodes.
> > >
> > > While this devicetree is used in main u-boot, in most cases it won't be
> > > the one passed to the actual kernel. Instead most boot commands will load
> > > a new devicetree from somewhere like mass storage of the network, so if
> > > that happens u-boot should transfer the optee nodes to that new 
> > > devicetree.
> > >
> > > To make that happen introduce optee_copy_fdt_nodes() called from the dt
> > > setup function in image-fdt which after checking for the optee presence
> > > in the u-boot dt will make sure a optee node is present in the kernel dt
> > > and transfer any reserved-memory regions it can find.
> > >
> > > Signed-off-by: Heiko Stuebner 
> > > ---
> > > This goes together with my bl32 work for the spl_atf loader in
> > > https://patchwork.ozlabs.org/patch/1172565/
> > >
> > >  common/image-fdt.c  |   8 
> > >  include/tee/optee.h |   9 
> > >  lib/optee/optee.c   | 112 
> > >  3 files changed, 129 insertions(+)
> > 
> > Could we please get a test for this new functionality?
> 
> We can try ;-) , but I think I'll need some pointers how this should be done.
> 
> On first glance, test/overlay/* seems to be a good inspiration. Aka the new
> function relies on an opaque OP-TEE binary modifying the .itb's dt-blob
> between SPL and main-U-Boot, so working with stub devicetrees for
> testing seems reasonable.
> 
> Aka checking cases of optee-nodes in old_fdt and not having them.

I just did go ahead and implemented a test like that, see v2 series.
Is this what you had in mind?

Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] image: fdt: copy possible optee nodes to a loaded devicetree

[Heiko Stübner]

Hi Simon,

Am Dienstag, 22. Oktober 2019, 02:17:00 CEST schrieb Simon Glass:
> On Mon, 7 Oct 2019 at 18:22, Heiko Stuebner  wrote:
> >
> > The loading convention for optee or any other tee on arm64 is as bl32
> > parameter to the trusted-firmware. So TF-A gets invoked with the TEE as
> > bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps
> > into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33.
> >
> > All of them get passed a devicetree as parameter and all components often
> > get loaded from a FIT image.
> >
> > OP-TEE will create additional nodes in that devicetree namely a firmware
> > node and possibly multiple reserved-memory nodes.
> >
> > While this devicetree is used in main u-boot, in most cases it won't be
> > the one passed to the actual kernel. Instead most boot commands will load
> > a new devicetree from somewhere like mass storage of the network, so if
> > that happens u-boot should transfer the optee nodes to that new devicetree.
> >
> > To make that happen introduce optee_copy_fdt_nodes() called from the dt
> > setup function in image-fdt which after checking for the optee presence
> > in the u-boot dt will make sure a optee node is present in the kernel dt
> > and transfer any reserved-memory regions it can find.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> > This goes together with my bl32 work for the spl_atf loader in
> > https://patchwork.ozlabs.org/patch/1172565/
> >
> >  common/image-fdt.c  |   8 
> >  include/tee/optee.h |   9 
> >  lib/optee/optee.c   | 112 
> >  3 files changed, 129 insertions(+)
> 
> Could we please get a test for this new functionality?

We can try ;-) , but I think I'll need some pointers how this should be done.

On first glance, test/overlay/* seems to be a good inspiration. Aka the new
function relies on an opaque OP-TEE binary modifying the .itb's dt-blob
between SPL and main-U-Boot, so working with stub devicetrees for
testing seems reasonable.

Aka checking cases of optee-nodes in old_fdt and not having them.

Looking at the README though points me to "TODO: convert to pytest" it
seems. Though that README.md only talks about interacting with the
u-boot console, so I'm not sure how that should work.


Thanks
Heiko




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] rockchip: make_fit_atf.py: allow inclusion of a tee binary

[Heiko Stübner]

Hi Simon,

Am Donnerstag, 10. Oktober 2019, 19:06:12 CEST schrieb Simon Glass:
> On Tue, 1 Oct 2019 at 14:23, Heiko Stuebner  wrote:
> > A trusted execution environment should also get loaded as loadable from
> > a fit image, so add the possibility to present a tee.elf to make_fit_atf.py
> > that then gets included as additional loadable into the generated its.
> >
> > For ease of integration the additional loadable is created as atf_(x+1)
> > after all others to re-use core generation loops.
> >
> > Tested against the combinations of 1-part-atf and multi-part-atf each
> > time with and without a tee binary present.
> >
> > Signed-off-by: Heiko Stuebner 
> > ---
> >  arch/arm/mach-rockchip/make_fit_atf.py | 52 +++---
> >  1 file changed, 46 insertions(+), 6 deletions(-)
> >
> 
> Instead of building up another tool, could we use binman for this? If
> not, what is missing?

make_fit_atf.py is the existing tool and I've no real experience with
binman so far, so I don't really know.

make_fit_atf.py is the script used to create the u-boot.its used as base
for the uboot fit image loaded from SPL, so it's the script set in the
SPL_FIT_GENERATOR Kconfig similar to sunxi and riscv.

For this it parses the ATF.elf and (now) TEE.elf to get the actual load
addresses for the loadables (the ATF.elf contains separate sections for
main DDR and often additional SRAM locations for loadables of variable
number) and creates the .its based on this data.


Looking at the binman README:
"Binman considers FIT to be one of the binaries it can place in the image.
Where possible it is best to put as much as possible in the FIT, with binman
used to deal with cases not covered by FIT."

So it looks like that should stay as it is? Or is that documentation outdated?


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: derive ethaddr from cpuid

[Heiko Stübner]

Hi Rohan,

Am Mittwoch, 10. Juli 2019, 14:08:31 CEST schrieb Rohan Garg:
> Hey Heiko
> > Also, that code looks pretty much like the same in rk3399-puma.
> > 
> > So maybe it might be good to have this in a common location so
> > more boards can access common code instead of duplicating that
> > whole function numerous times?
> 
> Sounds good to me, do you have any recommendations where something like this 
> would live?

From a cursory glance, it looks like most Rockchip socs have that cpu-id
value in the efuse (I checked rk3288, rk3399, rk3328 ... rk3368 efuse looks
similar but I'm not sure yet if it also has that id value).

So in any case I'd suggest somewhere in mach-rockchip, so that all
Rockchip socs can profit from that if they want.

It might be good to separate the cpu-id reading from the serial-generation
though, to parameterize the offset+length.

cpu_id = rockchip_cpuid_from_efuse(offset, length);
//containing the efuse related code
rockchip_cpuid_set(cpu_id);
//containing the calculations and env-setting


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: derive ethaddr from cpuid

[Heiko Stübner]

Hi Rohan, Kever,

Am Mittwoch, 10. Juli 2019, 08:37:33 CEST schrieb Kever Yang:
> Hi Rohan,
> 
>  The code change looks good to me, but could you help to separate
> the rock pi config update into another patch?

Also, that code looks pretty much like the same in rk3399-puma.

So maybe it might be good to have this in a common location so
more boards can access common code instead of duplicating that
whole function numerous times?


Heiko


> On 2019/7/9 下午6:37, Rohan Garg wrote:
> > Generate a MAC address based on the cpuid available in the efuse
> > block: Use the first 6 byte of the cpuid's SHA256 hash and set the
> > locally administered bits. Also ensure that the multicast bit is
> > cleared.
> >
> > The MAC address is only generated and set if there is no ethaddr
> > present in the saved environment.
> >
> > This is based off of Klaus Goger's work in 8adc9d
> >
> > Signed-off-by: Rohan Garg 
> >
> > ---
> >
> >   board/rockchip/evb_rk3399/evb-rk3399.c | 98 ++
> >   configs/rock-pi-4-rk3399_defconfig |  1 +
> >   2 files changed, 99 insertions(+)
> >
> > diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c 
> > b/board/rockchip/evb_rk3399/evb-rk3399.c
> > index eb1b832274..af57cd86a5 100644
> > --- a/board/rockchip/evb_rk3399/evb-rk3399.c
> > +++ b/board/rockchip/evb_rk3399/evb-rk3399.c
> > @@ -6,8 +6,11 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > +#include 
> >   #include 
> >   #include 
> > +#include 
> >   
> >   int board_init(void)
> >   {
> > @@ -33,3 +36,98 @@ int board_init(void)
> >   out:
> > return 0;
> >   }
> > +
> > +static void setup_macaddr(void)
> > +{
> > +#if CONFIG_IS_ENABLED(CMD_NET)
> > +   int ret;
> > +   const char *cpuid = env_get("cpuid#");
> > +   u8 hash[SHA256_SUM_LEN];
> > +   int size = sizeof(hash);
> > +   u8 mac_addr[6];
> > +
> > +   /* Only generate a MAC address, if none is set in the environment */
> > +   if (env_get("ethaddr"))
> > +   return;
> > +
> > +   if (!cpuid) {
> > +   debug("%s: could not retrieve 'cpuid#'\n", __func__);
> > +   return;
> > +   }
> > +
> > +   ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, );
> > +   if (ret) {
> > +   debug("%s: failed to calculate SHA256\n", __func__);
> > +   return;
> > +   }
> > +
> > +   /* Copy 6 bytes of the hash to base the MAC address on */
> > +   memcpy(mac_addr, hash, 6);
> > +
> > +   /* Make this a valid MAC address and set it */
> > +   mac_addr[0] &= 0xfe;  /* clear multicast bit */
> > +   mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
> > +   eth_env_set_enetaddr("ethaddr", mac_addr);
> > +#endif
> > +}
> > +
> > +static void setup_serial(void)
> > +{
> > +#if CONFIG_IS_ENABLED(ROCKCHIP_EFUSE)
> > +   const u32 cpuid_offset = 0x7;
> > +   const u32 cpuid_length = 0x10;
> > +
> > +   struct udevice *dev;
> > +   int ret, i;
> > +   u8 cpuid[cpuid_length];
> > +   u8 low[cpuid_length/2], high[cpuid_length/2];
> > +   char cpuid_str[cpuid_length * 2 + 1];
> > +   u64 serialno;
> > +   char serialno_str[17];
> > +
> > +   /* retrieve the device */
> > +   ret = uclass_get_device_by_driver(UCLASS_MISC,
> > + DM_GET_DRIVER(rockchip_efuse), );
> > +   if (ret) {
> > +   debug("%s: could not find efuse device\n", __func__);
> > +   return;
> > +   }
> > +
> > +   /* read the cpu_id range from the efuses */
> > +   ret = misc_read(dev, cpuid_offset, , sizeof(cpuid));
> > +   if (ret) {
> > +   debug("%s: reading cpuid from the efuses failed\n",
> > + __func__);
> > +   return;
> > +   }
> > +
> > +   memset(cpuid_str, 0, sizeof(cpuid_str));
> > +   for (i = 0; i < 16; i++)
> > +   sprintf(_str[i * 2], "%02x", cpuid[i]);
> > +
> > +   debug("cpuid: %s\n", cpuid_str);
> > +
> > +   /*
> > +* Mix the cpuid bytes using the same rules as in
> > +*   ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
> > +*/
> > +   for (i = 0; i < 8; i++) {
> > +   low[i] = cpuid[1 + (i << 1)];
> > +   high[i] = cpuid[i << 1];
> > +   }
> > +
> > +   serialno = crc32_no_comp(0, low, 8);
> > +   serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
> > +   snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
> > +
> > +   env_set("cpuid#", cpuid_str);
> > +   env_set("serial#", serialno_str);
> > +#endif
> > +}
> > +
> > +int misc_init_r(void)
> > +{
> > +   setup_serial();
> > +   setup_macaddr();
> > +   return 0;
> > +}
> > diff --git a/configs/rock-pi-4-rk3399_defconfig 
> > b/configs/rock-pi-4-rk3399_defconfig
> > index be670df23f..dc84ded86c 100644
> > --- a/configs/rock-pi-4-rk3399_defconfig
> > +++ b/configs/rock-pi-4-rk3399_defconfig
> > @@ -58,3 +58,4 @@ CONFIG_USB_ETHER_SMSC95XX=y
> >   CONFIG_USE_TINY_PRINTF=y
> >   CONFIG_SPL_TINY_MEMSET=y
> >   CONFIG_ERRNO_STR=y
> > +CONFIG_MISC_INIT_R=y
> 
> 
> ___
> U-Boot 

Re: [U-Boot] [PATCH 2/3] bouncebuf: Add DMA validation check to addr_aligned().【请注意，邮件由u-boot-boun...@lists.denx.de代发】 addr_aligned().

[Heiko Stübner]

Hi Simon,

Am Dienstag, 4. Juni 2019, 05:23:14 CEST schrieb Kever Yang:
> On 05/19/2019 12:08 AM, Simon Glass wrote:
> > On Tue, 7 May 2019 at 03:05, Christoph Muellner
> >  wrote:
> >> Currently addr_aligned() performs an alignment and a length check
> >> to validate the DMA address. However, some machines have stricter
> >> restrictions of DMA-able addresses.
> >>
> >> This patch adds a call to mach_addr_is_dmaable() to honor this
> >> machine specific restrictions.
> >>
> >> Signed-off-by: Christoph Muellner 
> >> 
> >> ---
> >>
> >>  common/bouncebuf.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> > I feel like this should be handled with DM. Can we add a new method to
> > the DMA uclass to check an address? If not provided by the DMA driver,
> > we can assume the address is OK.
> 
> The DMA in MMC controller which is not stand alone, do not using the
> driver of DMA uclass, so I'm afraid this is not able to using DMA uclass
> for this address check.

were you able to consider Kever's response?

The issue bites us for example when the mmc-driver with its internal dma
does transfer atf loadables to the socs sram. There is no system dma
controller involved but so far we're experiencing this on _all_ Rockchip
socs that need multiple parts of the ATF be written to different memory
locations. (the sram code is obviously needed for suspend/resume).


Thanks
Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] rockchip: rk3399: add tpl support

[Heiko Stübner]

Am Donnerstag, 18. April 2019, 08:35:49 CEST schrieb Philipp Tomsich:
> Simon,
> 
> > On 18.04.2019, at 06:32, Simon Glass  wrote:
> > 
> > Hi Kever,
> > 
> > On Mon, 1 Apr 2019 at 02:21, Kever Yang  wrote:
> >> 
> >> Rockchip platform suppose to use TPL(run in SRAM) as dram init and
> >> SPL(run in DDR SDRAM) as pre-loader, so that the SPL would not be
> >> limited by SRAM size.
> >> This patch add rk3399-board-tpl.c and its common configs.
> > 
> > So this means that TPL inits SDRAM? That seems strange to me...why
> > have SPL at all, then? What is SPL supported to do on RK3399
> > platforms?
> 
> For TPL->SPL implementation on Rockchip, we generally rely on the BootROM
> to load the TPL stage (to SRAM) and the SPL stage (to the start of DRAM).  The
> BootROM usually limits the size of the SPL stage, so we can’t use a full 
> U-Boot
> already.
> 
> Even more constricting are the TPL size constraints (as this seems to have 
> originally
> only been intended to be size-optimized DRAM init code) on some devices.

and maybe for a broader functionality description, something needs to
load things like ATF via a FIT image from a mmc for example.
(which needs FIT code and also real mmc drivers).

And as we experienced on rk3288 as well recently, SRAM may be very well
too small to accomplish that, so TPL needs to init the sdram separately
to make room for the code needed to get ATF up and running, which must
be done before jumping into proper uboot.

Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] common: bouncebuf: handle address in sram for rockchip platform

[Heiko Stübner]

Hi Kever,

Am Dienstag, 2. April 2019, 10:46:54 CEST schrieb Kever Yang:
> Rockchip SOC's mmc controller does not support read data
> from mmc to sram, we need a bounce buffer(in sdram), and then
> copy to sram.
> 
> Signed-off-by: Kever Yang 
> ---
> 
>  common/bouncebuf.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/common/bouncebuf.c b/common/bouncebuf.c
> index a7098e2caf..364fb17c96 100644
> --- a/common/bouncebuf.c
> +++ b/common/bouncebuf.c
> @@ -26,6 +26,18 @@ static int addr_aligned(struct bounce_buffer *state)
>   return 0;
>   }
>  
> +#ifdef CONFIG_ARCH_ROCKCHIP
> + /*
> +  * Rockchip SOC's mmc controller does not support read data
> +  * from mmc to sram, we need a bounce buffer(in sdram), and then
> +  * copy to sram.
> +  */
> + if (((ulong)state->user_buffer & 0xfff8) ==
> + CONFIG_ROCKCHIP_IRAM_BASE) {
> + debug("Unsupport IRAM space %p\n", state->user_buffer);
> + return 0;
> + }

wouldn't it be easier to just check for "in-ddr-region"?
Rockchip SoCs may have multiple sram areas one might want to use.

Also I get the feeling this should not live in an ARCH_ROCKCHIP ifdef.
Instead maybe define some sort of kconfig settings to describe the
directly usable memory areas, that the bounce_buffer then could use?


Heiko

> +#endif
>   /* Aligned */
>   return 1;
>  }
> 




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3288 SPL size

[Heiko Stübner]

Hi,

Am Freitag, 5. April 2019, 12:10:21 CEST schrieb Wadim Egorov:
> it seems the new common rockchip pinctrl driver does not really fit into
> our phycore-rk3288 SPL setup. It works for every other rk3288 based
> board because they don't need special power configurations at the SPL stage.
> 
> So my question is: is there any work going on to reduce the SPL size
> even more?
> 
> Besides that, I think I can remove the power stuff at the SPL stage from
> our board. The SOM was redesigned and is equipped with an STM8 connected
> to the RK818. The required setup we did before in the SPL is now done by
> the ST controller. I know there are only a few SOMs without the STM8 out
> in the wild. So if I remove it it will affect only a few people who
> probably already have both boards.

alternatively you could introduce a tpl-stage, similar to what Amarula
does with their Vyasa board. With spl in ram there is obviously no size
limitation anymore.

But obviously if the power-fix isn't actually needed anymore, dropping
it might be the easiest solution.


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] optee: support rockchip optee binary release

[Heiko Stübner]

Hi Kever,

Am Montag, 1. April 2019, 11:49:35 CEST schrieb Kever Yang:
> On 04/01/2019 01:42 PM, Heiko Stübner wrote:
> > Am Montag, 1. April 2019, 04:32:28 CEST schrieb Kever Yang:
> >> On 04/01/2019 05:02 AM, Heiko Stübner wrote:
> >>> Am Freitag, 29. März 2019, 13:16:26 CET schrieb Kever Yang:
> >>>> On 03/29/2019 07:25 PM, Philipp Tomsich wrote:
> >>>>>> On 29.03.2019, at 12:21, Kever Yang  wrote:
> >>>>>>
> >>>>>> Rockchip provide tee binary release in 'rkbin' repository:
> >>>>>> https://github.com/rockchip-linux/rkbin
> >>>>>> For some historical reason, rockchip optee binary is using
> >>>>>> 'r1' instead of 'lr' as U-Boot entry.
> >>>>>>
> >>>>>> Signed-off-by: Kever Yang 
> >>>>>> ---
> >>>>>>
> >>>>>> common/spl/spl_optee.S | 3 +++
> >>>>>> 1 file changed, 3 insertions(+)
> >>>>>>
> >>>>>> diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S
> >>>>>> index 8bd1949ddf..092307b3cc 100644
> >>>>>> --- a/common/spl/spl_optee.S
> >>>>>> +++ b/common/spl/spl_optee.S
> >>>>>> @@ -8,5 +8,8 @@
> >>>>>>
> >>>>>> ENTRY(spl_optee_entry)
> >>>>>>ldr lr, =CONFIG_SYS_TEXT_BASE
> >>>>>> +#ifdef CONFIG_ARCH_ROCKCHIP
> >>>>> Can we make this selectable based on a dedicated config-option?  We 
> >>>>> provide our
> >>>>> own OPTEE port for some of our modules and I would like to have this as 
> >>>>> an opt-in
> >>>>> or opt-out option in Kconfig.
> >>>> I think you are using OPTEE for RK3368/RK3399, right? Then the use case
> >>>> is different, you are using OPTEE as bl32 for armv8, and this spl_optee 
> >>>> is
> >>>> for armv7 only.
> >>>> I'm OK to add a Kconfig option if you really have different usage,
> >>>> and I think this patch does not break things because the no one use 'r1'
> >>>> now.
> >>> rk3229 has support in upstream op-tee, so possibly the calling convention
> >>> is different with that? And of course there may come a time when people
> >>> may want to use upstream-op-tee instead of a binary-blob.
> >> Upstream op-tee is using 'lr' and rockchip binary is now using 'r1' for
> >> u-boot entry.
> >> So upstream op-tee can be boot if my patch series for rk3229 is merged,
> >> and with this patch, people can chose to use rockchip binary for rk3229
> >> or other
> >> armv7 SoCs.
> > Yes, an that is the reason there should be a Kconfig symbol for that :-)
> 
> I don't think we need the Kconfig symbol now because I think user don't have
> to make this choice in SPL, user only need to use the firmware they need.
> With this patch, both upstream and Rockchip OP-TEE can be supported,
> it does not break support for upstream op-tee.
> The Kconfig symbol is needed if only one choice is available, isn't it?

In a related spl-atf change from last week, I saw today, I also saw the
comment to not mix architecture hacks with common code, so I guess
having a "ifdef ROCKCHIP" in common applies here.

From what I understood right now, all Rockchip vendor OP-Tees use r1,
so at least on rk3229 there is already a choice to use either upstream
op-tee build from source or the binary rockchip one.


> >> eg. I'll add op-tee support for rk3288 later because of the psci needed
> >> by mainline kernel.
> > please keep in mind that old device-trees in mainline need to stay working
> > aka you cannot expect people to update their firmware just to keep using
> > mainline kernels. So u-boot should modify the kernel-devicetree accordingly
> > to enable psci, before starting the kernel.
> 
> Well, I think the U-Boot should support op-tee first, and then kernel can
> decide to use PSCI or not, user can still use old style if they don't
> want a psci.
> But if U-Boot don't support op-tee, then kernel is not able to use PSCI.

of course ... this was not meant to be criticism of any sort ;-)

Just a reminder, before somebody starts posting kernel patches converting
the in-kernel devicetree to only psci.


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] optee: support rockchip optee binary release

[Heiko Stübner]

Am Montag, 1. April 2019, 04:32:28 CEST schrieb Kever Yang:
> Hi Heiko,
> 
> 
> On 04/01/2019 05:02 AM, Heiko Stübner wrote:
> > Hi Kever,
> >
> > Am Freitag, 29. März 2019, 13:16:26 CET schrieb Kever Yang:
> >> On 03/29/2019 07:25 PM, Philipp Tomsich wrote:
> >>>> On 29.03.2019, at 12:21, Kever Yang  wrote:
> >>>>
> >>>> Rockchip provide tee binary release in 'rkbin' repository:
> >>>> https://github.com/rockchip-linux/rkbin
> >>>> For some historical reason, rockchip optee binary is using
> >>>> 'r1' instead of 'lr' as U-Boot entry.
> >>>>
> >>>> Signed-off-by: Kever Yang 
> >>>> ---
> >>>>
> >>>> common/spl/spl_optee.S | 3 +++
> >>>> 1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S
> >>>> index 8bd1949ddf..092307b3cc 100644
> >>>> --- a/common/spl/spl_optee.S
> >>>> +++ b/common/spl/spl_optee.S
> >>>> @@ -8,5 +8,8 @@
> >>>>
> >>>> ENTRY(spl_optee_entry)
> >>>>  ldr lr, =CONFIG_SYS_TEXT_BASE
> >>>> +#ifdef CONFIG_ARCH_ROCKCHIP
> >>> Can we make this selectable based on a dedicated config-option?  We 
> >>> provide our
> >>> own OPTEE port for some of our modules and I would like to have this as 
> >>> an opt-in
> >>> or opt-out option in Kconfig.
> >> I think you are using OPTEE for RK3368/RK3399, right? Then the use case
> >> is different, you are using OPTEE as bl32 for armv8, and this spl_optee is
> >> for armv7 only.
> >> I'm OK to add a Kconfig option if you really have different usage,
> >> and I think this patch does not break things because the no one use 'r1'
> >> now.
> > rk3229 has support in upstream op-tee, so possibly the calling convention
> > is different with that? And of course there may come a time when people
> > may want to use upstream-op-tee instead of a binary-blob.
> 
> Upstream op-tee is using 'lr' and rockchip binary is now using 'r1' for
> u-boot entry.
> So upstream op-tee can be boot if my patch series for rk3229 is merged,
> and with this patch, people can chose to use rockchip binary for rk3229
> or other
> armv7 SoCs.

Yes, an that is the reason there should be a Kconfig symbol for that :-)


> eg. I'll add op-tee support for rk3288 later because of the psci needed
> by mainline kernel.

please keep in mind that old device-trees in mainline need to stay working
aka you cannot expect people to update their firmware just to keep using
mainline kernels. So u-boot should modify the kernel-devicetree accordingly
to enable psci, before starting the kernel.

In my ATF adventure I already did some smallish adaptions on the kernel
side for this:
https://github.com/mmind/linux-rockchip/commit/27bce39800a14abe08d5a5994abef29f9b543c68


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] optee: support rockchip optee binary release

[Heiko Stübner]

Hi Kever,

Am Freitag, 29. März 2019, 13:16:26 CET schrieb Kever Yang:
> On 03/29/2019 07:25 PM, Philipp Tomsich wrote:
> >> On 29.03.2019, at 12:21, Kever Yang  wrote:
> >>
> >> Rockchip provide tee binary release in 'rkbin' repository:
> >> https://github.com/rockchip-linux/rkbin
> >> For some historical reason, rockchip optee binary is using
> >> 'r1' instead of 'lr' as U-Boot entry.
> >>
> >> Signed-off-by: Kever Yang 
> >> ---
> >>
> >> common/spl/spl_optee.S | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S
> >> index 8bd1949ddf..092307b3cc 100644
> >> --- a/common/spl/spl_optee.S
> >> +++ b/common/spl/spl_optee.S
> >> @@ -8,5 +8,8 @@
> >>
> >> ENTRY(spl_optee_entry)
> >>ldr lr, =CONFIG_SYS_TEXT_BASE
> >> +#ifdef CONFIG_ARCH_ROCKCHIP
> > Can we make this selectable based on a dedicated config-option?  We provide 
> > our
> > own OPTEE port for some of our modules and I would like to have this as an 
> > opt-in
> > or opt-out option in Kconfig.
> 
> I think you are using OPTEE for RK3368/RK3399, right? Then the use case
> is different, you are using OPTEE as bl32 for armv8, and this spl_optee is
> for armv7 only.
> I'm OK to add a Kconfig option if you really have different usage,
> and I think this patch does not break things because the no one use 'r1'
> now.

rk3229 has support in upstream op-tee, so possibly the calling convention
is different with that? And of course there may come a time when people
may want to use upstream-op-tee instead of a binary-blob.

Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Veyron Speedy / ASUS C201 fixes

[Heiko Stübner]

Am Sonntag, 31. März 2019, 21:34:00 CEST schrieb Urja Rannikko:
> Hi,
> 
> On Fri, Mar 29, 2019 at 1:56 PM Heiko Stübner  wrote:
> >
> > In my u-boot list archive I only see the list itself als recipient.
> > You may want to resend your series with actual maintainers in Cc
> > so that they actually see your patches :-) .
> >
> > Similar to the kernel, uboot also has a scripts/get_maintainer.pl
> > script to give you a list of applicable maintainers (Philipp and Simon
> > in this case)
> 
> I did CC these to 3 maintainers (who you mentioned plus Jaehoon Chung
> for MMC ...), as given by that script - weird that you dont see those.
> Gmail is showing them in the one i sent so atleast i didnt forget but
> maybe the list filtered them (?).

yeah, that is possible ... for whatever reason
and I could only reply to the list mail itself ... so all good then :-)


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] dw_mmc: turn on the IO supply

[Heiko Stübner]

Am Freitag, 22. März 2019, 20:14:36 CET schrieb Urja Rannikko:
> Fixes the microSD slot on the ASUS C201.
> 
> Signed-off-by: Urja Rannikko 
> ---
>  drivers/mmc/dw_mmc.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 93a836eac3..e1960b213a 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define PAGE_SIZE 4096
>  
> @@ -440,6 +441,7 @@ static int dwmci_set_ios(struct mmc *mmc)
>  #endif
>   struct dwmci_host *host = (struct dwmci_host *)mmc->priv;
>   u32 ctype, regs;
> + int ret;
>  
>   debug("Buswidth = %d, clock: %d\n", mmc->bus_width, mmc->clock);
>  
> @@ -469,6 +471,19 @@ static int dwmci_set_ios(struct mmc *mmc)
>   if (host->clksel)
>   host->clksel(host);
>  
> +#ifdef CONFIG_DM_REGULATOR

this should be 
#if CONFIG_IS_ENABLED(DM_REGULATOR)

because otherwise an SPL-build using the mmc driver may fail with

drivers/mmc/dw_mmc.c: In function ‘dwmci_set_ios’:
drivers/mmc/dw_mmc.c:475:9: error: ‘struct mmc’ has no member named 
‘vqmmc_supply’
  if (mmc->vqmmc_supply) {
 ^~
drivers/mmc/dw_mmc.c:477:27: error: ‘struct mmc’ has no member named 
‘vqmmc_supply’
regulator_set_value(mmc->vqmmc_supply, 180);
   ^~
drivers/mmc/dw_mmc.c:479:27: error: ‘struct mmc’ has no member named 
‘vqmmc_supply’
regulator_set_value(mmc->vqmmc_supply, 330);
   ^~
drivers/mmc/dw_mmc.c:481:44: error: ‘struct mmc’ has no member named 
‘vqmmc_supply’
   ret = regulator_set_enable_if_allowed(mmc->vqmmc_supply, true);


> + if (mmc->vqmmc_supply) {
> + if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
> + regulator_set_value(mmc->vqmmc_supply, 180);
> + else
> + regulator_set_value(mmc->vqmmc_supply, 330);
> +
> + ret = regulator_set_enable_if_allowed(mmc->vqmmc_supply, true);
> + if (ret)
> + return ret;
> + }
> +#endif
> +
>   return 0;
>  }
>  
> 




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Veyron Speedy / ASUS C201 fixes

[Heiko Stübner]

Hi Urja,

Am Freitag, 22. März 2019, 20:14:32 CET schrieb Urja Rannikko:
> Just saying: I'm not familiar with this stuff so i might've misunderstood
> something in my commit messages, but anyways i managed to make it boot.
> 
> There's more stuff than just these, but i decided I'd keep it short...
> If you want to know my full setup, you can check out my gh repo for now:
> https://github.com/urjaman/u-boot/commits/c201-stuff
> 
> Notably I did include http://patchwork.ozlabs.org/patch/1040541/ in my
> tree when testing (rk3288 pinctrl patch that was linked to on
> the previous thread i found about the veyron speedy being broken).
> 
> The one thing that I havent yet fixed is that the USB host port on
> the otg-capable controller (near screen) doesn't work - one guess i have
> is that the dwc2 host driver doesn't force it into host mode...
> (It doesn't even read dr_mode ...)
> 
> Urja Rannikko (4):
>   pinctrl: exit pinconfig_post_bind if there are no subnodes
>   rk3288-board: remove pinctrl call for debug uart
>   rk3288-board: cosmetic: document selecting RK PWM
>   dw_mmc: turn on the IO supply

In my u-boot list archive I only see the list itself als recipient.
You may want to resend your series with actual maintainers in Cc
so that they actually see your patches :-) .

Similar to the kernel, uboot also has a scripts/get_maintainer.pl
script to give you a list of applicable maintainers (Philipp and Simon
in this case)

Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

[Heiko Stübner]

Hi Philipp,

Am Donnerstag, 28. Februar 2019, 13:46:44 CET schrieb Heiko Stübner:
> Am Donnerstag, 28. Februar 2019, 13:36:52 CET schrieb Philipp Tomsich:
> > > On 28.02.2019, at 11:50, Heiko Stübner  wrote:
> > > 
> > > Hi David,
> > > 
> > > Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
> > >> Hi Heinrich and Michael,
> > >> 
> > >> Another thing i see is that I missed a patch, for the 3288 gpio0, its
> > >> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
> > >> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
> > >> while request the GPIO0A4. It requires a patch:
> > >> 
> > >> http://patchwork.ozlabs.org/patch/1040541/
> > >> <http://patchwork.ozlabs.org/patch/1040541/>>
> > > 
> > > I've also just stumbled onto the issue of recent uboots not booting
> > > on rk3288. While your patch seems to have reached patchwork, somehow
> > > the u-boot list seems to have lost it - as it's neither in public
> > > archives nor in my inbox it seems.
> > 
> > Please note that I had requested changes to that patch during review.
> > I’ll ping David again on when he expect to have those changes implemented
> > and ready.
> 
> yeah, I saw that in patchwork, but couldn't comment due to the patch
> seemingly not having reach the actual u-boot list strangely.
> 
> That patch doesn't seem to help me right now anyway, as I somehow seem
> be stuck on mem_malloc_init() hanging when called from initr_malloc()
> (board_r.c) and am not yet sure what is going on there
> (on u-boot-master from last friday).

This problem seems to be memory-related somehow?
My 2GB rk3288-evb comes up fine to the uboot prompt, while
my 1GB rk3288-phycore hangs in said mem_malloc_init().


rk3288-evb (2GB):
[...]
Relocation Offset is: 7ed88000
Relocating to 7ed88000, new gd at 7cd7fed8, sp at 7cd76230
[...]
initr_malloc: before mem_malloc_init
using memory 0x7cd8-0x7ed88000 for malloc()
initr_malloc: after mem_malloc_init
[...]


rk3288-phycore (1GB):
[...]
Relocation Offset is: 3ff7b000
Relocating to 3ff7b000, new gd at 3df72ee0, sp at 3df68f60
[...]
initr_malloc: before mem_malloc_init
using memory 0x3df73000-0x3ff7b000 for malloc()
[HANG]


Do you have some tips what I need to poke for this issue?


Heiko

> > > Applying the patch does not make my board (phycore-rk3288 in this case)
> > > get farther though - I'll investigate more.
> > > 
> > > 
> > > But it looks like we should be having the same issue in the kernel, just
> > > never triggered it, as the gpio0 are of more esotheric uses normally.
> > > 
> > > Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
> > > wouldn't be enough and use that for iomux, pull and drv, similar to
> > > what we do for the pull/drv register source already.
> > > 
> > > That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
> > > and PULL_TYPE_WRITABLE_32BIT .
> > > 
> > > 
> > > Heiko
> > > 
> > >> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
> > >>> On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
> > >>>> Hi
> > >>>> 
> > >>>> [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space
> > >>>> after
> > >>>> relocation
> > >>>> 
> > >>>> Can you check it if you have the same problem?
> > >>> 
> > >>> Applying all the changes causes SPL not to start.
> > >>> 
> > >>> CONFIG_SYS_MALLOC_F_LEN=0x4000
> > >>> does not solve the problem.
> > >>> 
> > >>> Best regards
> > >>> 
> > >>> Heinrich
> > >>> 
> > >>>> Michael
> > >>>> 
> > >>>> 
> > >>>> On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt
> > >>>>  > >>>> 
> > >>>> <mailto:xypron.g...@gmx.de> wrote:
> > >>>> On 2/17/19 9:19 AM, David Wu wrote:
> > >>>>> Hi Henrich,
> > >>>>> 
> > >>>>> 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> > >>>>>> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
> > >>>> 
> > >>>>>> 
> > >>>>>> Hello David, hello Philipp,
> > >>>>>> 
> > >>>>>> what are your ideas to reduce the SPL size t

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

[Heiko Stübner]

Am Donnerstag, 28. Februar 2019, 13:36:52 CET schrieb Philipp Tomsich:
> > On 28.02.2019, at 11:50, Heiko Stübner  wrote:
> > 
> > Hi David,
> > 
> > Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
> >> Hi Heinrich and Michael,
> >> 
> >> Another thing i see is that I missed a patch, for the 3288 gpio0, its
> >> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
> >> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
> >> while request the GPIO0A4. It requires a patch:
> >> 
> >> http://patchwork.ozlabs.org/patch/1040541/
> >> <http://patchwork.ozlabs.org/patch/1040541/>> 
> > I've also just stumbled onto the issue of recent uboots not booting
> > on rk3288. While your patch seems to have reached patchwork, somehow
> > the u-boot list seems to have lost it - as it's neither in public
> > archives nor in my inbox it seems.
> 
> Please note that I had requested changes to that patch during review.
> I’ll ping David again on when he expect to have those changes implemented
> and ready.

yeah, I saw that in patchwork, but couldn't comment due to the patch
seemingly not having reach the actual u-boot list strangely.

That patch doesn't seem to help me right now anyway, as I somehow seem
be stuck on mem_malloc_init() hanging when called from initr_malloc() 
(board_r.c) and am not yet sure what is going on there
(on u-boot-master from last friday).




> > Applying the patch does not make my board (phycore-rk3288 in this case)
> > get farther though - I'll investigate more.
> > 
> > 
> > But it looks like we should be having the same issue in the kernel, just
> > never triggered it, as the gpio0 are of more esotheric uses normally.
> > 
> > Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
> > wouldn't be enough and use that for iomux, pull and drv, similar to
> > what we do for the pull/drv register source already.
> > 
> > That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
> > and PULL_TYPE_WRITABLE_32BIT .
> > 
> > 
> > Heiko
> > 
> >> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
> >>> On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
> >>>> Hi
> >>>> 
> >>>> [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space after
> >>>> relocation
> >>>> 
> >>>> Can you check it if you have the same problem?
> >>> 
> >>> Applying all the changes causes SPL not to start.
> >>> 
> >>> CONFIG_SYS_MALLOC_F_LEN=0x4000
> >>> does not solve the problem.
> >>> 
> >>> Best regards
> >>> 
> >>> Heinrich
> >>> 
> >>>> Michael
> >>>> 
> >>>> 
> >>>> On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt  >>>> 
> >>>> <mailto:xypron.g...@gmx.de> wrote:
> >>>> On 2/17/19 9:19 AM, David Wu wrote:
> >>>>> Hi Henrich,
> >>>>> 
> >>>>> 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> >>>>>> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
> >>>> 
> >>>>>> 
> >>>>>> Hello David, hello Philipp,
> >>>>>> 
> >>>>>> what are your ideas to reduce the SPL size to under 0x7800 again?
> >>>>>> Or will you move all rk3288 boards to TPL like
> >>>>>> TARGET_VYASA_RK3288?
> >>>>> 
> >>>>> CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can
> >>>>> make
> >>>>> spl boot. As the Tinker does not use the i2c to read the MAC
> >>>>> address
> >>>>> from eeprom at the SPL stage, which is at uboot.
> >>>>> 
> >>>> Hello David,
> >>>> 
> >>>> the SPL image size now just fits:
> >>>> Image Type:   Rockchip RK32 (SD/MMC) boot image
> >>>> Data Size:30720 bytes
> >>>> 
> >>>> SPL is successful. But MMC is failing in main U-Boot:
> >>>> 
> >>>> ```
> >>>> U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
> >>>> +0100)
> >>>> Returning to boot ROM...
> >>>> 
> >>>> 
> >>>> U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

[Heiko Stübner]

Hi David,

Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
> Hi Heinrich and Michael,
> 
> Another thing i see is that I missed a patch, for the 3288 gpio0, its
> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
> while request the GPIO0A4. It requires a patch:
> 
> http://patchwork.ozlabs.org/patch/1040541/

I've also just stumbled onto the issue of recent uboots not booting
on rk3288. While your patch seems to have reached patchwork, somehow
the u-boot list seems to have lost it - as it's neither in public
archives nor in my inbox it seems.

Applying the patch does not make my board (phycore-rk3288 in this case)
get farther though - I'll investigate more.


But it looks like we should be having the same issue in the kernel, just
never triggered it, as the gpio0 are of more esotheric uses normally.

Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
wouldn't be enough and use that for iomux, pull and drv, similar to
what we do for the pull/drv register source already.

That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
and PULL_TYPE_WRITABLE_32BIT .


Heiko


> 
> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
> > On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >> 
> >> [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space after
> >> relocation
> >> 
> >> Can you check it if you have the same problem?
> > 
> > Applying all the changes causes SPL not to start.
> > 
> > CONFIG_SYS_MALLOC_F_LEN=0x4000
> > does not solve the problem.
> > 
> > Best regards
> > 
> > Heinrich
> > 
> >> Michael
> >> 
> >> 
> >> On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt  >> 
> >>  wrote:
> >>  On 2/17/19 9:19 AM, David Wu wrote:
> >>  > Hi Henrich,
> >>  > 
> >>  > 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> >>  >> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
> >>  
> >>  
> >>  >> Hello David, hello Philipp,
> >>  >> 
> >>  >> what are your ideas to reduce the SPL size to under 0x7800 again?
> >>  >> Or will you move all rk3288 boards to TPL like
> >>  >> TARGET_VYASA_RK3288?
> >>  > 
> >>  > CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can
> >>  > make
> >>  > spl boot. As the Tinker does not use the i2c to read the MAC
> >>  > address
> >>  > from eeprom at the SPL stage, which is at uboot.
> >>  
> >>  Hello David,
> >>  
> >>  the SPL image size now just fits:
> >>  Image Type:   Rockchip RK32 (SD/MMC) boot image
> >>  Data Size:30720 bytes
> >>  
> >>  SPL is successful. But MMC is failing in main U-Boot:
> >>  
> >>  ```
> >>  U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
> >>  +0100)
> >>  Returning to boot ROM...
> >>  
> >>  
> >>  U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +0100)
> >>  
> >>  Model: Tinker-RK3288
> >>  DRAM:  2 GiB
> >>  MMC:   dwmmc@ff0c: 1
> >>  Loading Environment from MMC...
> >>  ```
> >>  
> >>  No further output here.
> >>  
> >>  With some debug output enabled:
> >>  
> >>  ```
> >>  U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 -
> >>  13:05:10
> >>  +0100)
> >>  Returning to boot ROM...
> >>  mmc_bind: alias ret=0, devnum=1
> >>  env_init: Environment MMC init done (ret=-2)
> >>  
> >>  
> >>  U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10
> >>  +0100)
> >>  
> >>  Model: Tinker-RK3288
> >>  DRAM:  2 GiB
> >>  mmc_bind: alias ret=0, devnum=1
> >>  MMC:   dwmmc@ff0c: 1
> >>  Loading Environment from MMC...
> >>  ```
> >>  
> >>  Any suggestion how to proceed?
> >>  
> >>  CC: Jaehoon.
> >>  
> >>  Best regards
> >>  
> >>  Heinrich
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/10] rockchip: add tpl and OPTEE support for rk3229

[Heiko Stübner]

Hi Kever,

Am Mittwoch, 6. September 2017, 10:14:27 CET schrieb Kever Yang:
> Add some generic options for TPL support for arm 32bit, and then
> and TPL support for rk3229(cortex-A7), and then add OPTEE support
> in SPL.

I was now finally able to test this series and I'm getting mixed results.
I was following the instructions in the evb-rk3229 README file.


On the uboot side it seems to work nicely when applied against 2017.09.

But when I try to rebase it on top of the next branch of u-boot-rockchip
I end up with the TPL claiming a "Missing DTB", so it looks like it needs
a respin to follow the recent changes.

On the optee-side I also seem to do something wrong or so.
When using the binaries from the rkbin github repository I end up with
[0] and [1].
When compiling the most-recent optee it fails with [2].

With some intermediate optee or the one from Tony Xie's repository
it compiles and uboot seems to start, but then fails when the kernel tries
to bring up the secondary cpus [3]. And interestingly while it seems to go
through optee, I don't see any optee-messages.

If you could point me into the right direction, I would be very grateful :-)


Thanks
Heiko


[0]
TPL Inittimer init done
Returning to boot ROM...

U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
Trying to boot from MMC1
INF TEE-CORE:init_primary_helper:319: Initializing (1.0.1-65-gf1567d3-dev #22 
Fri Mar 24 06:16:54 UTC 2017 arm)
INF TEE-CORE:init_primary_helper:320: Release version: 1.9
INF TEE-CORE:init_teecore:79: teecore inits done
[hangs here]

[1]
TPL Inittimer init done
Returning to boot ROM...

U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
Trying to boot from MMC1
INF [0x0] TEE-CORE:init_primary_helper:366: Initializing 
(1.1.0-120-gb4aded8-dev #3 Wed Dec 28 01:56:52 UTC 2016 arm)
INF [0x0] TEE-CORE:init_primary_helper:367: Release version: 1.6
INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
[hangs here]

[2]
make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x
 CHK out/arm-plat-rockchip/conf.mk
 UPD out/arm-plat-rockchip/conf.mk
 CHK out/arm-plat-rockchip/include/generated/conf.h
 UPD out/arm-plat-rockchip/include/generated/conf.h
 CHK out/arm-plat-rockchip/core/include/generated/asm-defines.h
make: *** No rule, to create „core/include/tee/tee_cryp_provider.h“,  needed by
 „out/arm-plat-rockchip/core/arch/arm/kernel/user_ta.o“.

[3]
TPL Inittimer init done
Returning to boot ROM...

U-Boot SPL 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 19:24:42)
Trying to boot from MMC1


U-Boot 2017.09-rc4-00031-gf82145695e-dirty (Nov 20 2017 - 21:29:43 +0100)

Model: Nexbox A95X R1
DRAM:  1022 MiB
[...]
Starting kernel ...

[0.00] Booting Linux on physical CPU 0xf00
[0.00] Linux version 4.14.0-13997-g55102e6ed32a-dirty (hstuebner@phil) 
(gcc version 7.2.0 (Debian 7.2.0-11)) #437 SMP Mon Nov 20 11:33:35 CET 2017
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: Nexbox A95X R1
[0.00] earlycon: uart8250 at MMIO32 0x1103 (options '')
[0.00] bootconsole [uart8250] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0x9c00
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.0 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] random: fast init done
[0.00] percpu: Embedded 17 pages/cpu @ef7a4000 s39116 r8192 d22324 
u69632
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
[...]
[0.00] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00
[0.00] Setting up static identity map for 0x6030 - 0x603000a0
[0.00] Hierarchical SRCU implementation.
[0.00] EFI services will not be available.
[0.00] smp: Bringing up secondary CPUs ...
[hangs here]

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot Boot issue about rk3188

[Heiko Stübner]

Am Montag, 25. September 2017, 19:49:01 CEST schrieb Andy Yan:
> Hi Heiko:
> 
> On 2017年09月25日 18:29, Heiko Stübner wrote:
> > Hi Andy,
> > 
> > Am Montag, 25. September 2017, 17:45:03 CEST schrieb Andy Yan:
> >> On 2017年09月22日 13:56, Heiko Stuebner wrote:
> >>> Am Freitag, 22. September 2017, 08:50:49 CEST schrieb Andy Yan:
> >>>> Hi Heiko:
> >>>> 
> >>>> On 2017年09月22日 08:24, Andy Yan wrote:
> >>>>> Hi Heiko:
> >>>>> 
> >>>>> On 2017年09月21日 22:55, Heiko Stübner wrote:
> >>>>>> Hi Andy,
> >>>>>> 
> >>>>>> Am Donnerstag, 21. September 2017, 22:03:32 CEST schrieb Andy Yan:
> >>>>>>> Hi Heiko:
> >>>>>>> I try to boot the upstream u-boot-rockchip branch  on my rk3188
> >>>>>>> board
> >>>>>>> with(rock_defconfig)
> >>>>>>> 
> >>>>>>> But I got this error:
> >>>>>>> early_init()
> >>>>>>> nit_and_scan() returned error -22
> >>>>>>> early_init() failed: -22
> >>>>>>> ERROR ### Please RESET the board ###
> >>>>>>> 
> >>>>>>> the current commit head is: 782088d("rockchip: imply ADC and
> >>>>>>> SARADC_ROCKCHIP
> >>>>>>> on supported SoCs") Do you ever meet something like this?
> >>>>>> 
> >>>>>> that is very strange. When testing Philipp's branch, I was also
> >>>>>> testing the
> >>>>>> commit you mention to see if anything broke since I last changed
> >>>>>> u-boot
> >>>>>> on my radxa rock. And the above commit started just fine, when
> >>>>>> starting
> >>>>>> from an sd-card.
> >>>>>> 
> >>>>>> Not sure from which medium you're starting though. But from what I
> >>>>>> remember Pawel got nand working in his rk3066 series, but that is not
> >>>>>> yet merged.
> >>>>>> 
> >>>>>   I boot from emmc, I will go on hack on it.
> >>>>>   
> >>>>I finally can boot it with the rock_defconfig. But the way to
> >>>> 
> >>>> package the tpl spl u-boot a little different.
> >>>> 
> >>>>cat ${DIR}/out/tpl/u-boot-tpl.bin > tplspl.bin
> >>>>truncate -s 1020 tplspl.bin
> >>>>   
> >>>>   sed -i "/^/{1s/^/RK31/}" tplspl.bin
> >>>>   cat ${DIR}/out/spl/u-boot-spl.bin > spl.bin
> >>>>   truncate -s %2048 spl.bin
> >>>>   cat spl.bin >> tplspl.bin
> >>>>   
> >>>>   Then the tplspl.bin + u-boot.bin should package by
> >>>> 
> >>>> boot_merger(tplsplb.in for FLashData, u-boot.bin for FlashBoot) from
> >>>> 
> >>>> rockchip downstream u-boot repo:
> >>>>   ./tools/boot_merger ./tools/rk_tools/RKBOOT/RK310BMINIALL.ini
> >>>>   
> >>>>   download to emmc by "upgrade_tool ul" command. According to our
> >>>> 
> >>>> bootrom code author, the rk31(maybe include rk30) bootrom has a
> >>>> limitation that the idbblock
> >>>> couldn't accessed by upgrade_tool wl command.
> >>> 
> >>> I do have a script handling that [0]. At least for the sd-card variant
> >>> a simple "openssl rc4" works just as well as the legacy boot_merger :-)
> >>> 
> >>> Heiko
> >>> 
> >>> [0]
> >>> https://github.com/mmind/u-boot-rockchip/commit/81458bde873d6cf588e082cc
> >>> f
> >>> 556e818f46ad9df
> >>> 
> >>  Is there a way to download the out that generated by[0] to
> >> 
> >> emmc/flash? It seems that the upgrate_tool can't access 0x40 of the
> >> emmc/nand on rk3188.
> > 
> > you have the @rock-chips.com address, so I'd guess you might even have
> > the better resources to find out ;-)  .
> 
> Actually, as I mail last week, I can download  the image packaged by
> boot_merge (with ddr bin from rockchip as 471 and rk30usbplug as 472,
> tplspl as Flashdata u-boot.bing as Flashboot) to nand/emmc.
> 
> When you mentioned your scripts, I though you have a better way.

Sadly not really, as I'm just using a sd-card in rk3188, I normally just dd 
the image to the card and everything works then.


> > In any case, as I said I haven't looked at all at the internal storage on
> > my radxarock so far.
> > 
> > But as the rk3066 and rk3188 are so similar I've added Paweł.
> > 
> > @Paweł: you had uboot starting from nand on your rk3066 board, maybe you
> > could describe how you wrote it to the board so maybe Andy can check if
> > he needs to adapt anything?
> > 
> > 
> > Thanks
> > Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot Boot issue about rk3188

[Heiko Stübner]

Hi Andy,

Am Donnerstag, 21. September 2017, 22:03:32 CEST schrieb Andy Yan:
> Hi Heiko:
> I try to boot the upstream u-boot-rockchip branch  on my rk3188 board
> with(rock_defconfig)
> 
> But I got this error:
> early_init()
> nit_and_scan() returned error -22
> early_init() failed: -22
> ERROR ### Please RESET the board ###
> 
> the current commit head is: 782088d("rockchip: imply ADC and SARADC_ROCKCHIP
> on supported SoCs") Do you ever meet something like this?

that is very strange. When testing Philipp's branch, I was also testing the 
commit you mention to see if anything broke since I last changed u-boot
on my radxa rock. And the above commit started just fine, when starting
from an sd-card.

Not sure from which medium you're starting though. But from what I
remember Pawel got nand working in his rk3066 series, but that is not
yet merged.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/6] rockchip: back-to-bootrom: replace assembly-implementation with C-code

[Heiko Stübner]

Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:
> > On 21 Sep 2017, at 11:44, Heiko Stuebner  wrote:
> > 
> > Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:
> >> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:
> >>> Recent discussions confirmed (what the code always assumed): the
> >>> Rockchip BROM always enters U-Boot with the stack-pointer valid
> >>> (i.e. the U-Boot startup code is running off the BROM stack).
> >>> 
> >>> We can thus replace the back-to-bootrom code (i.e. both the
> >>> save_boot_params and back_to_bootrom implementations) using C-code
> >>> based on setjmp/longjmp.  The new implementation is already structured
> >>> to allow an easy drop-in of Andy's changes to enter download-mode when
> >>> returning to the BROM.
> >>> 
> >>> This turned out to require a some tweaking to system.h (making sure
> >>> that the prototype for save_boot_params_ret is visible for A64)and
> >>> start.S (so binutils knows that this is a possible function entry and
> >>> it can correctly insert A32-to-Thumb transitions) and taking the axe
> >>> to setjmp.h (which created quite a few issues with it not expecting
> >>> A32/T32/Thumb call-sites and some fragility from GCC being smart about
> >>> the clobber-list of the inline assembly... which led to r9 not being
> >>> saved or restored).
> >> 
> >> This is missing information on dependant series. Using the
> >> u-boot-rockchip
> >> repository which is at
> >> 782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported
> >> SoCs")
> >> 
> >> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing
> >> some
> >> dependencies.
> >> 
> >> And the u-boot mailinglist seems to be configured very strangely, as it
> >> seems to rip apart patch-series only sending me some parts.
> >> 
> >> So far I can at least say, that the u-boot-rockchip repo at the above
> >> commit still boots. Could you please point me to mbox versions
> >> of needed base patches?
> > 
> > Also, with patches 1-3 and 5 applied the radxarock board fails to start.
> > I see the SPL banner and a "Returning to boot ROM..." and then nothing.
> > 
> > I do belive it may have something to do with the TPL's + SPL's stack both
> > being at the end of SRAM? Having the SPL go back to TPL and then
> > back to bootrom was my original intention as well, but didn't work at
> > the time.
> 
> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t
> work.  However, the jump_to_spl() is at least partially to blame (we already
> have a working C-runtime and there’s no point in reentering through the
> reset entry-point).
> 
> I need to ponder this a bit, but my gut feeling is that the TPL->SPL
> transition can be done in a less intrusive way and may allow us to retain
> the TPL stack.

Alternatively, if you can think of an easier solution we could do away with
the TPL in its current form. When I did the rk3188 support, this looked like
the least-messy way to me, but it really only does the one jump back
to the bootrom - so I'm not sure if there isn't simply an easier solution.

And for example the (still wip?) rk3066 series did use spl+tpl in a different
way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar
with the rk3066 simply not having the sd-boot capability, so if we want to
have nand-boot on rk3188 as well in the future, this may need a different
rework again.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace assembly-implementation with C-code

[Heiko Stübner]

Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich:
> Andy,
> 
> > On 19 Sep 2017, at 09:19, Andy Yan  wrote:
> > 
> > Hi Philipp:
> > 
> > On 2017年09月19日 10:06, Andy Yan wrote:
> >> Hi Philipp:
> >> 
> >> On 2017年09月19日 02:18, Philipp Tomsich wrote:
> >>> Recent discussions confirmed (what the code always assumed): the
> >>> Rockchip BROM always enters U-Boot with the stack-pointer valid
> >>> (i.e. the U-Boot startup code is running off the BROM stack).
> >>> 
> >>> We can thus replace the back-to-bootrom code (i.e. both the
> >>> save_boot_params and back_to_bootrom implementations) using C-code
> >>> based on setjmp/longjmp.  The new implementation is already structured
> >>> to allow an easy drop-in of Andy's changes to enter download-mode when
> >>> returning to the BROM.
> >>> 
> >>> This entails one minor tweak to asm/system.h, which only exported
> >>> the save_boot_params_ret prototype for ARMv7, but not for AArch64.
> >>> 
> >>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we
> >>> can safely call save_boot_params_ret().
> >>> 
> >>This still have a problem, because the setjmp  implementation for
> >>ARM32 platform  has humb code when CONFIG_SYS_THUMB_BUILD is>> 
> >> enabled, this is a default setting for most ARMv7 boards.
> >> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD)
> >> ".align 2\n"
> >> "adr r0, jmp_target\n"
> >> "add r0, r0, $1\n"  // r0 stored the jump target address and with bit[0]
> >> = 1, this will trigger a thumb switch in longjmp with code "bx r0"
> >> #endif
> >> 
> >> When I force the setjmp code go arm code path, I can back to bootrom
> >> successfully, But I got a data abort exception in later. it seems it
> >> happens when bootrom finished the uboot code copy, when jump to sdram, I
> >> need a further debug.
> > 
> > I found that r9 also need to be preserved, it seems that it hold the sdram
> > base.
> Thanks for testing and debugging: this is invaluable support, as I only have
> AArch64 boards to test.
> 
> The r9 issue will be easy enough to resolve.
> However, it looks like I will need more work on setjmp/longjmp to make this
> safe both for T32 and A32. Plus: I need to figure out why this didn’t show
> in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board
> I looked at).
> 
> Might be tomorrow or Thursday until I can provide an new version.

From this conversation, it looks to me that I should wait for that new
version for testing on rk3188, as it will likely show the same issues, right?


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/19] ARM: dts: rockchip: prefer u-boot, dm-pre-reloc rather than u-boot, dm-spl

[Heiko Stübner]

Hi Pawel,

Am Freitag, 11. August 2017, 22:57:29 CEST schrieb Paweł Jarosz:
> rk3xxx.dtsi is used by rk3188 and rk3066. rk3188 uses alocated data in spl
> but rk3066 needs it in tpl.
> 
> Signed-off-by: Paweł Jarosz 
> ---
> Changes since v1:
> - none
> 
>  arch/arm/dts/rk3xxx.dtsi | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/dts/rk3xxx.dtsi b/arch/arm/dts/rk3xxx.dtsi
> index 6d9e36d..d1c205b 100644
> --- a/arch/arm/dts/rk3xxx.dtsi
> +++ b/arch/arm/dts/rk3xxx.dtsi
> @@ -135,7 +135,7 @@
>   };
> 
>   noc: syscon@10128000 {
> - u-boot,dm-spl;
> + u-boot,dm-pre-reloc;

That probably won't work on rk3188. I haven't looked to closely
on the rk3188 support for a while, but there we used the TPL for
the single jump back to the bootloader after reading the 1KB
of initial code.

So with the code as is, this would make the rk3188 TPL most likely to big.

As both the rk3066 and rk3188 are very similar, I'd guess the best
option would be to just adapt the rk3188 to you newer rk3066
approach, so that they don't diverge to much. Especially as the
rk3188 has the same nand controller and people may want to
boot of on-chip nand on the rk3188 in the future as well.


Heiko

>   compatible = "rockchip,rk3188-noc", "syscon";
>   reg = <0x10128000 0x2000>;
>   };
> @@ -218,13 +218,13 @@
>   pmu: pmu@20004000 {
>   compatible = "rockchip,rk3066-pmu", "syscon";
>   reg = <0x20004000 0x100>;
> - u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
>   };
> 
>   grf: grf@20008000 {
>   compatible = "syscon";
>   reg = <0x20008000 0x200>;
> - u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
>   };
> 
>   dmc: dmc@2002 {
> @@ -238,7 +238,7 @@
>  0x2004 0x294>;
>   clocks = < PCLK_DDRUPCTL>, < PCLK_PUBL>;
>   clock-names = "pclk_ddrupctl", "pclk_publ";
> - u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
>   };
> 
>   i2c0: i2c@2002d000 {


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3188/rock_defconfig sdmmc failures

[Heiko Stübner]

Hi Artturi,

Am Mittwoch, 6. September 2017, 01:50:38 CEST schrieb Artturi Alm:
> So, being optimistic, i added compatible found from
> arch/arm/dts/rk3xxx.dtsi, included by rk3188:
> 
> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
> index e7fcf89..a879fcd 100644
> --- a/drivers/mmc/rockchip_dw_mmc.c
> +++ b/drivers/mmc/rockchip_dw_mmc.c
> @@ -160,6 +160,7 @@ static int rockchip_dwmmc_bind(struct udevice *dev)
> 
>  static const struct udevice_id rockchip_dwmmc_ids[] = {
> { .compatible = "rockchip,rk3288-dw-mshc" },
> +   { .compatible = "rockchip,rk2928-dw-mshc" },
> { }
>  };

The rk3188 SPL is using OF_PLATDATA which transforms the devicetree entry
into a struct during compilation to save space in the image.
Relevant to this would be the U_BOOT_DRIVER below that compatibles, which
currently binds to the rockchip_rk3288_dw_mshc transformed compatible.

Adding a second U_BOOT_DRIVER entry there might help for the probing,
but seeing that the dw-mmc in the Linux kernel behaves differently for
rk3188 and rk3288 onwards, I'm not sure if it would work out of the box.

[...]

> now i've "successfully" enabled usb, but it took like +30tries
> w/"usb reset" until the host ports succesfully found my usb mass storage,
> and sometimes it leaves the dwc2 otg controller in a state where
> "usb tree" will fault while printing out, and reset the board, so i'd
> rather have sdmmc working for now instead, as it is enabled already in
> the default config for the board.

For usb you might want to make sure the usb host regulator is enabled
I have the below commands in my netboot uboot for the rock and it is
working quite reliable and so far I haven't seen usb-related issues there.

regulator dev host-pwr;
regulator enable;
usb start;


Hope that helps a bit
Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/52] Support OF_PLATDATA in TPL, enable RK3368 DRAM init and add RK3368-uQ7

[Heiko Stübner]

Hi Łukasz,

Am Montag, 24. Juli 2017, 11:23:05 CEST schrieb Łukasz Majewski:
> On 07/24/2017 10:59 AM, Heiko Stübner wrote:
> > Am Montag, 24. Juli 2017, 16:38:52 CEST schrieb Andy Yan:
> >> Hi Philipp:
> >> 
> >> On 2017年07月21日 18:55, Dr. Philipp Tomsich wrote:
> >>>> On 21 Jul 2017, at 04:33, Andy Yan <andy@rock-chips.com> wrote:
> >>>> 
> >>>> Hi:
> >>>> 
> >>>> On 2017年07月19日 04:35, Philipp Tomsich wrote:
> >>>>> Here's a series that has a lot going on, but I didn't want to split it
> >>>>> to allow everyone to understand the motivation between some of the
> >>>>> changes to the SPL/TPL framework.  The short summary of this is
> >>>>> "enablement for DRAM init on the RK3368 with everything else that's
> >>>>> necessary to do it using OF_PLATDATA in TPL".
> >>>>> 
> >>>>> Enabling the RK3368 created a few more challenges that I'd expected:
> >>>>>   - I needed different stack locations, text addresses and sizes for
> >>>>>   
> >>>>> TPL and SPL
> >>>>>   
> >>>>>   - the TPL stage was to use OF_PLATDATA and SPL was to use full
> >>>>>   OF_CONTROL
> >>>>>   - with the RK3368 TPL stage, there was a need to extend the
> >>>>>   back-to-bootrom
> >>>>>   
> >>>>> support for Rockchip to AArch64
> >>>>>   
> >>>>>   - I wanted to start folding some of the Rockchip specific SPL
> >>>>>   support
> >>>>>   
> >>>>> (i.e. back-to-bootrom) back into the general SPL framework to
> >>>>> allow
> >>>>> using it as a general boot method
> >>>> 
> >>>> I have a confusion here: according to the README.TPL,  TPL is Third
> >>>> Program Loader, which loaded by the SPL. So I think it should run after
> >>>> the SPL. But from RK3188 and RK3368 TPL implementation , they all run
> >>>> before SPL.Maybe it is my misunderstanding, hope to get some
> >>>> guidance.:-)>
> >>> 
> >>> I think you are right and most Rockchip boards have been using this the
> >>> wrong way around.
> > 
> > Actually at first I also had the ordering of SPL -> TPL -> uboot for
> > rk3188
> > but after discussions with Simon and Tom Rini, the opinion was that TPL
> > stands for "tiny" program loader and should run before the full SPL.
> 
> Has something changed since:
> 
> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/tpl-presentation.pdf
> 
> I've always thought that we do have SPL -> TPL -> u-boot -> Linux
> 
> If there was a change, then:
> 
> 1. The TPL name is a bit misleading (considering the above
> presentation/status)
> 
> 2. IMHO the code running before SPL (to do some _real_ early init)
> should be named more descriptive like PreSPL.

I've gone back and looked up the previous discussion. It was part of a thread 
where we only included Tom later on to clarify spl/tpl usage, so there is no 
list-reference, but I guess I can just quote the part:

- 8< ---
Am Donnerstag, 26. Januar 2017, 12:57:40 CEST schrieben Tom Rini:
> On Thu, Jan 26, 2017 at 07:23:25AM -0700, Simon Glass wrote:
> > +Tom for question below.
> > 
> > Hi Heiko,
> > 
> > On 17 December 2016 at 15:51, Heiko Stübner <he...@sntech.de> wrote:
> > > Hi,
> > > 
> > > Am Samstag, 17. Dezember 2016, 09:57:51 schrieb Simon Glass:
> > >> I cannot see the .S code in that tree. If it is a few instructions
> > >> then it is fine. But if it is a lot of code I question why it cannot
> > >> be written mostly in C?
> > > 
> > > The .S was just my question to Kever how he envisioned this "preloader"
> > > being implemented. Right now all my parts are fully C-based.
> > > 
> > >> Using TPL seems OK to me. But from my understanding TPL runs before
> > >> SPL. So the sequence should be: TPL -> SPL -> U-Boot. This makes some
> > >> sense because SPL is a more full-featured loader, and TPL is just a
> > >> mini-loader to get the SPL running.
> > > 
> > > hmm, I think SPL -> TPL -> U-Boot would be the correct order :-)
> > > Based on the TPL being the "tertiary program loader" where the SPL only
> > > is the "secondary program loader" and based on the slides from 2013 in
> > > [0].> 
> > That seems wrong to me. A secondary load loads the primary loader,
> > which surely means that the tertiary should load the secondary, i.e.
> > 
> > I think it should be:
> >2 loads 1 (SPL loads U-Boot)
> >3 loads 2 which loads 1 (TPL loads SPL which loads U-Boot)
> > 
> > The alternative is:
> >2 loads 3 which loads 1
> > 
> > which seems really odd.
> > 
> > Note that PowerPC appears to use TPL->SPL->U-Boot when I last looked
> > at it. Of course I could be wrong.
> 
> Yes, naming is hard.  TPL (which is maybe better thought of as Tiny not
> Tertiary) loads SPL loads U-Boot.
- 8< ---


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/52] Support OF_PLATDATA in TPL, enable RK3368 DRAM init and add RK3368-uQ7

[Heiko Stübner]

Am Montag, 24. Juli 2017, 16:38:52 CEST schrieb Andy Yan:
> Hi Philipp:
> 
> On 2017年07月21日 18:55, Dr. Philipp Tomsich wrote:
> >> On 21 Jul 2017, at 04:33, Andy Yan  wrote:
> >> 
> >> Hi:
> >> 
> >> On 2017年07月19日 04:35, Philipp Tomsich wrote:
> >>> Here's a series that has a lot going on, but I didn't want to split it
> >>> to allow everyone to understand the motivation between some of the
> >>> changes to the SPL/TPL framework.  The short summary of this is
> >>> "enablement for DRAM init on the RK3368 with everything else that's
> >>> necessary to do it using OF_PLATDATA in TPL".
> >>> 
> >>> Enabling the RK3368 created a few more challenges that I'd expected:
> >>>   - I needed different stack locations, text addresses and sizes for
> >>>   
> >>> TPL and SPL
> >>>   
> >>>   - the TPL stage was to use OF_PLATDATA and SPL was to use full
> >>>   OF_CONTROL
> >>>   - with the RK3368 TPL stage, there was a need to extend the
> >>>   back-to-bootrom
> >>>   
> >>> support for Rockchip to AArch64
> >>>   
> >>>   - I wanted to start folding some of the Rockchip specific SPL support
> >>>   
> >>> (i.e. back-to-bootrom) back into the general SPL framework to allow
> >>> using it as a general boot method
> >> 
> >> I have a confusion here: according to the README.TPL,  TPL is Third
> >> Program Loader, which loaded by the SPL. So I think it should run after
> >> the SPL. But from RK3188 and RK3368 TPL implementation , they all run
> >> before SPL.Maybe it is my misunderstanding, hope to get some
> >> guidance.:-)> 
> > I think you are right and most Rockchip boards have been using this the
> > wrong way around.

Actually at first I also had the ordering of SPL -> TPL -> uboot for rk3188
but after discussions with Simon and Tom Rini, the opinion was that TPL
stands for "tiny" program loader and should run before the full SPL.

So I switched that stuff around on rk3188.


Heiko

>  Only RK3188 uses TPL now.
> 
> > With the fine-grained configurability that I created for the RK3368, it
> > will be easy enough to switch this around on the RK3368. However, this
> > will then also be done for the other RK3xxx devices to restore
> > consistency.
> > 
> > I would prefer to first add the RK3368 support with the “backwards
> > TPL/SPL” (i.e. TPL before SPL) to remain consistent with current
> > mach-rockchip usage of the TPL/SPL terminology. Once this is merged, we
> > can then switch this around for each board individually.> 
> >>> So I ended up separating quite a bit of features between SPL and TPL
> >>> while keeping things transparent to the few other boards using TPL (at
> >>> least I hope that things are transparent, as we didn't have any of
> >>> those in our lab to test on)...
> >>> 
> >>> Tested with: RK3368-uQ7, Debian 9, Linux 4.13-rc1.
> >>> 
> >>> Just one final remark: the DMC driver for the RK3368 currently covers
> >>> the configuration we use on the RK3368-uQ7 (i.e. 32bit wide, 2 ranks)
> >>> and is stress-tested (including 8-way SPEC runs) at all 3 supported
> >>> speeds.  I've built a bit of infrastructure (e.g. the way the
> >>> memory-schedule is determined) that I hope will be a useful
> >>> starting-point in unifying the drivers for the various closely related
> >>> DRAM controllers (e.g. for the RK3288) for Rockchip devices in the
> >>> future.
> >>> 
> >>> Klaus Goger (1):
> >>>rockchip: board: puma_rk3399: rename ATF firmware
> >>> 
> >>> Philipp Tomsich (51):
> >>>spl: add a 'return to bootrom' boot method
> >>>spl: configure 'return to bootrom' separately for SPL and TPL
> >>>rockchip: back-to-bootrom: add 'back-to-bootrom' support for AArch64
> >>>rockchip: back-to-bootrom: split BACK_TO_BOOTROM for TPL/SPL
> >>>rockchip: back-to-bootrom: simplify the #ifdef-check for LIBGENERIC
> >>>in
> >>>
> >>>  TPL/SPL
> >>>
> >>>spl: dm: Kconfig: use more specific prereqs for SPL_REGMAP and
> >>>
> >>>  SPL_SYSCON
> >>>
> >>>spl: dm: Kconfig: split REGMAP/SYSCON support for TPL from SPL
> >>>spl: dm: Kconfig: SPL_RAM depends on SPL_DM
> >>>spl: dm: Kconfig: introduce TPL_RAM (in analogy to SPL_RAM)
> >>>spl: dm: Kconfig: SPL_CLK depens on SPL_DM
> >>>spl: dm: Kconfig: split CLK support for SPL and TPL
> >>>spl: dm: Kconfig: split OF_CONTROL and OF_PLATDATA between SPL and
> >>>TPL
> >>>spl: dm: use CONFIG_IS_ENABLED to test for the DM option
> >>>armv8: remove unused low-level modules from TPL
> >>>armv8: spl: Support separate stack for TPL
> >>>spl: allow a separate TEXT_BASE, LDSCRIPT and MAX_SIZE for TPL
> >>>spl: Kconfig: split SYS_MALLOC_SIMPLE for TPL and SPL
> >>>lib: spl: differentiate between TPL and SPL for
> >>>
> >>>  libfdt/of_control/of_platdata
> >>>
> >>>spl: consistently use $(SPL_TPL_) to select features for SPL and TPL
> >>>
> >>>  builds
> >>>
> >>>spl: add TPL_DRIVER_MISC_SUPPORT option
> >>>

Re: [U-Boot] [PATCH 0/5] fix the boot issue of Rockchip RK3036

[Heiko Stübner]

Hi Andy,

Am Montag, 3. Juli 2017, 16:02:59 CEST schrieb Andy Yan:
> On 2017年06月30日 16:14, Dr. Philipp Tomsich wrote:
> >> On 30 Jun 2017, at 09:47, Andy Yan  wrote:
> >> As Kever mentioned in [0], the RK3036 based boards could't
> >> bootup for a long time.
> >> After a git bisect, I found the RK3036 SPL code size has
> >> increased from patch [1] [2]. Before Tom's patch [1], the
> >> SPL size is 3160 bytes, but it becomes 4080 bytes after [1]
> >> applied. After a look at this patch, I realised I should
> >> disable SPL_USE_ARCH_MEMCPY/MEMSET, and the code size indeed
> >> come down after I disabled them. But I got a LD error after
> >> apply patch[2]: "undefined reference to memset", RK3036 SPL
> >> didn't use lib/string because of the sram space imitation.
> >> The compile succeed after CONFIG_SPL_LIBGENERIC_SUPPORT enabled,
> >> but the spl code size become 3248 bytes.
> >> 
> >> Additionally, Simon post patch [3] call printf to print a
> >> message before back to bootrom from spl, which make the spl
> >> code size increased to nearly 3.7 kb.
> >> 
> >> RK3036 SPL only has 4kb sram to use, the spl code will use
> >> 3.4 ~ 3.5 kb, the last 0.5kb are used for SP and GD, so there
> >> is no space for malloc.
> > 
> > gcc-6-arm-linux-gnueabi
> > What version of GCC are you using?
> > If your problem can also be solved by moving to GCC 6.3 (or newer) and
> > the code-size improvements there, I’d rather just require a more recent
> > GCC version.
> 
>  I default use arm-linux-gnueabe-gcc v5.4.
>  The current upstream kylin-rk3036_defconfig compiled by gcc-5.4 is
> 4384 bytes, the size comes down to 3936 bytes if I use
> arm-linux-gnueabihf-gcc v6.3 from linaro. But this is still too large
> for rk3036.
>  Disable SPL_USE_ARCH_MEMCPY/MEMSET will make the spl size comes
> down to 3042 bytes by gcc v6.3. But I still need some hack: enable
> CONFIG_SPL_LIBGENERIC to get support for memset, masks Simon's print in
> bootrom.c, or the code size will become very large. Event though this
> hack make things work, we still lost a few hundreds bytes by function
> board_init_f_alloc_reserve, because platforms with very limit sram like
> rk3036 will return to bootrom after the dram initialized, they never use
> the malloc space. This few hundreds bytes is a large space for 4kb
> sarm,  it's better to letf them for code or SP.

For a start, maybe you could take a look at Simon's size reduction
series from april. The TPL-specific stuff may not be that interesting,
but the first patch adds a totally slimmed down memset, which
may be better for real hard size constraints

[PATCH v2 0/5] Patches to reduce TPL code size:
https://www.mail-archive.com/u-boot@lists.denx.de/msg243443.html


Heiko

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/7] rockchip: Split sdram common function into sdram_common.c

[Heiko Stübner]

Am Dienstag, 13. Juni 2017, 11:31:53 CEST schrieb Dr. Philipp Tomsich:
> Kever,
> 
> thanks a lot! I had just started to work on RK3368 SPL code and the DDR
> controller would have been next on the list…
> You saved me quite a bit of work there.

Although the sdram drivers for rk3328 and rk3368 only seem to provide the
non-spl portions for now.

Kever, is there a rough time estimate for spl support for these socs?
(Got a rk3328-rock64 sample yesterday, so would be interested on getting
a mainline u-boot to run on it)


Thanks
Heiko

> 
> Regards,
> Philipp.
> 
> > On 13 Jun 2017, at 11:29, Kever Yang  wrote:
> > 
> > 
> > Some function like the dram capability decode and dram_init() are
> > the same for all Rockchip SoCs, maybe alaso cap detect function later,
> > add sdram_common.c for all SoC driver.
> > 
> > Kever Yang (7):
> >  rockchip: add sdram_common for common functions
> >  rockchip: use common sdram function
> >  rockchip: rk3328: add sdram driver in U-Boot
> >  rockchip: rk3368: add sdram driver for U-Boot
> >  rockchip: dts: rk3328: add dmc node
> >  rockchip: dts: rk3368: add dmc node
> >  rockchip: correct the bank0 ram size
> > 
> > arch/arm/dts/rk3328.dtsi  |  7 ++
> > arch/arm/dts/rk3368.dtsi  |  7 ++
> > arch/arm/include/asm/arch-rockchip/ddr_rk3288.h   | 48 ---
> > arch/arm/include/asm/arch-rockchip/grf_rk3368.h   |  4 +-
> > arch/arm/include/asm/arch-rockchip/sdram_common.h | 58 ++
> > arch/arm/mach-rockchip/Makefile   |  3 +
> > arch/arm/mach-rockchip/rk3188-board.c | 22 -
> > arch/arm/mach-rockchip/rk3188/sdram_rk3188.c  | 61 +++---
> > arch/arm/mach-rockchip/rk3288-board.c | 22 -
> > arch/arm/mach-rockchip/rk3288/sdram_rk3288.c  | 74 +
> > arch/arm/mach-rockchip/rk3328/Makefile|  1 +
> > arch/arm/mach-rockchip/rk3328/sdram_rk3328.c  | 66 +++
> > arch/arm/mach-rockchip/rk3368/Makefile|  1 +
> > arch/arm/mach-rockchip/rk3368/sdram_rk3368.c  | 66 +++
> > arch/arm/mach-rockchip/rk3399/sdram_rk3399.c  | 97
> > ++- arch/arm/mach-rockchip/sdram_common.c
> > | 71 + board/rockchip/evb_rk3328/evb-rk3328.c   
> > |  8 +-
> > board/rockchip/evb_rk3399/evb-rk3399.c| 24 +-
> > board/rockchip/sheep_rk3368/sheep_rk3368.c|  9 +--
> > board/theobroma-systems/puma_rk3399/puma-rk3399.c | 24 +-
> > 20 files changed, 324 insertions(+), 349 deletions(-)
> > create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_common.h
> > create mode 100644 arch/arm/mach-rockchip/rk3328/sdram_rk3328.c
> > create mode 100644 arch/arm/mach-rockchip/rk3368/sdram_rk3368.c
> > create mode 100644 arch/arm/mach-rockchip/sdram_common.c


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 05/13] rockchip: rk3066: add rk3066 platform devicetree file

[Heiko Stübner]

Am Mittwoch, 7. Juni 2017, 17:12:24 CEST schrieb Paweł Jarosz:
> Hi Simon,
> 
> W dniu 06.06.2017 o 23:10, Simon Glass pisze:
> > Hi Pawel,
> > 
> > On 6 June 2017 at 12:50, Paweł Jarosz  wrote:
> >> rk3066 peripherials include usb, i2c, pwm, gpio, sdio, sdmmc, emmc, spi,
> >> watchdog and uart
> >> 
> >> Signed-off-by: Paweł Jarosz 
> >> ---
> >> 
> >>   arch/arm/dts/rk3066a.dtsi | 699
> >>   ++ 1 file changed, 699
> >>   insertions(+)
> >>   create mode 100644 arch/arm/dts/rk3066a.dtsi
> > 
> > How come this file has 'a' on the end?
> > 
> > Reviewed-by: Simon Glass 
> 
> Not sure why ... as there is no rk3066a named chip (acording to
> datasheet) but there is rk3066b.
> I have copied linux source without renaming it.

actually there are "only" rk3066a and rk3066b ... only the rk3066a often
just gets called rk3066. If you look in device schematics you always find
the rk3066a naming.

Also, so far I haven't seen any rk3066b yet, therefore we have no support
for it at all.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: doc: update latest info to document

[Heiko Stübner]

Hi Kever,

Am Montag, 15. Mai 2017, 21:18:00 CEST schrieb Kever Yang:
> - Add some rk3399 and rk3328 boards;
> - use rkdeveloptool instead of rkflashtool;
> - use opensource.rock-chips.com instead of wikidot;
> - other update.
> 
> Signed-off-by: Kever Yang 
> ---
> 
>  doc/README.rockchip | 38 --
>  1 file changed, 24 insertions(+), 14 deletions(-)
> 
> diff --git a/doc/README.rockchip b/doc/README.rockchip
> index 2d8cf9f..229db0d 100644
> --- a/doc/README.rockchip
> +++ b/doc/README.rockchip
> @@ -14,9 +14,6 @@ many Rockchip devices [1] [2].
>  The current mainline support is experimental only and is not useful for
>  anything. It should provide a base on which to build.
> 
> -So far only support for the RK3288 and RK3036 is provided.
> -
> -
>  Prerequisites
>  =
> 
> @@ -26,17 +23,18 @@ You will need:
> - Power connection to 5V using the supplied micro-USB power cable
> - Separate USB serial cable attached to your computer and the Firefly
>  (connect to the micro-USB connector below the logo)
> -   - rkflashtool [3]
> -   - openssl (sudo apt-get install openssl)
> +   - rkdeveloptool [3]

In my personal opinion, rkflashtool should stay. You can very well add
rkdeveloptool as a second option, but rkflashtool was there first and
also is the one that most distributions contain in their repositories.
And both tools seem to have the same functionality.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] string: Provide a slimmed-down memset()

[Heiko Stübner]

Am Sonntag, 2. April 2017, 09:50:28 CEST schrieb Simon Glass:
> Most of the time the optimised memset() is what we want. For extreme
> situations such as TPL it may be too large. For example on the 'rock'
> board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and
> the rodata bug, this patch is enough to reduce the TPL image below the
> limit.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2:
> - Adjust the option to be SPL-only
> - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET)
> 
>  lib/Kconfig  | 8 
>  lib/string.c | 6 --
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 65c01573e1..58b5717dcd 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -52,6 +52,14 @@ config LIB_RAND
>   help
> This library provides pseudo-random number generator functions.
> 
> +config SPL_TINY_MEMSET
> + bool "Use a very small memset() in SPL"
> + help
> +   The faster memset() is the arch-specific one (if available) enabled
> +   by CONFIG_USE_ARCH_MEMSET. If that is not enabled, we can still get
> +   better performance by write a word at a time. Enable this option
> +   to reduce code size slightly at the cost of some speed.

Wording sounds off, I guess we could do something like

[...better performance by] writing a word at a time. In very size-constrained
environments even this may be to big though. [Enable this option...]

Otherwise
Reviewed-by: Heiko Stuebner 

> +
>  source lib/dhry/Kconfig
> 
>  source lib/rsa/Kconfig
> diff --git a/lib/string.c b/lib/string.c
> index 67d5f6a421..c1a28c14ce 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -437,8 +437,10 @@ char *strswab(const char *s)
>  void * memset(void * s,int c,size_t count)
>  {
>   unsigned long *sl = (unsigned long *) s;
> - unsigned long cl = 0;
>   char *s8;
> +
> +#if !CONFIG_IS_ENABLED(TINY_MEMSET)
> + unsigned long cl = 0;
>   int i;
> 
>   /* do it one word at a time (32 bits or 64 bits) while possible */
> @@ -452,7 +454,7 @@ void * memset(void * s,int c,size_t count)
>   count -= sizeof(*sl);
>   }
>   }
> - /* fill 8 bits at a time */
> +#endif   /* fill 8 bits at a time */
>   s8 = (char *)sl;
>   while (count--)
>   *s8++ = c;


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/5] Patches to reduce TPL code size

[Heiko Stübner]

Am Sonntag, 2. April 2017, 09:50:27 CEST schrieb Simon Glass:
> With the rockchip 'rock' board some build and code size problems have come
> to light with TPL. This series provides a few ideas to improve things.

great stuff!

With these patches applied, rk3188-rock still boots and the TPL has
come down to 616byte on gcc-4.9 and 592bytes on gcc-6.3, so

Tested-by: Heiko Stuebner 

We have like vast amounts of free space in tpl now ;-)

I guess I should fold your TINY_MEMSET option into my rock board,
once you've applied the core patch?


Heiko


> 
> Changes in v2:
> - Adjust the option to be SPL-only
> - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET)
> - Add a new patch to enable CONFIG_SPL_TINY_MEMSET
> - Add new patch to allow driver model to be disabled for TPL
> - Add new patch to allow driver-model serial to be disabled for TPL
> 
> Simon Glass (5):
>   string: Provide a slimmed-down memset()
>   rockchip: rock: Enable CONFIG_SPL_TINY_MEMSET
>   Makefile: Provide an option to select SPL or TPL
>   dm: core: Allow driver model to be disabled for TPL
>   dm: serial: Allow driver-model serial to be disabled for TPL
> 
>  configs/rock_defconfig  |  1 +
>  drivers/Makefile|  2 +-
>  drivers/core/Kconfig| 14 ++
>  drivers/serial/Kconfig  | 20 
>  drivers/serial/Makefile |  2 +-
>  lib/Kconfig |  8 
>  lib/string.c|  6 --
>  scripts/Kbuild.include  |  6 ++
>  scripts/Makefile.spl|  6 ++
>  9 files changed, 61 insertions(+), 4 deletions(-)


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] rockchip: rk3188: Switch to new i2c IP blocks

[Heiko Stübner]

Am Donnerstag, 23. März 2017, 21:28:08 CET schrieb Simon Glass:
> Hi Heiko,
> 
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
> > The rk3066/rk3188 introduced new i2c IP blocks but kept the old ones
> > around just in case. The default also points to these old controllers.
> > 
> > The "new" blocks proved stable and nobody ever used the old ones anywhere,
> > not in the kernel and not in U-Boot, so to be able to reuse the already
> > existing driver make the rk3188 switch to the new ones in U-Boot as well.
> > 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  arch/arm/mach-rockchip/rk3188-board-spl.c | 21 +
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/arch/arm/mach-rockchip/rk3188-board-spl.c
> > b/arch/arm/mach-rockchip/rk3188-board-spl.c index affd959f86..14847a7b1b
> > 100644
> > --- a/arch/arm/mach-rockchip/rk3188-board-spl.c
> > +++ b/arch/arm/mach-rockchip/rk3188-board-spl.c
> > @@ -17,6 +17,7 @@
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > +#include 
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > @@ -102,6 +103,7 @@ void board_init_f(ulong dummy)
> > 
> >  {
> >  
> > struct udevice *pinctrl, *dev;
> > struct rk3188_pmu *pmu;
> > 
> > +   struct rk3188_grf *grf;
> > 
> > int ret;
> > 
> > /* Example code showing how to enable the debug UART on RK3188 */
> > 
> > @@ -154,6 +156,25 @@ void board_init_f(ulong dummy)
> > 
> > error("pmu syscon returned %ld\n", PTR_ERR(pmu));
> > 
> > SAVE_SP_ADDR = readl(>sys_reg[2]);
> > 
> > +   /* init common grf settings */
> > +   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> > +   if (IS_ERR(grf)) {
> > +   error("grf syscon returned %ld\n", PTR_ERR(grf));
> > +   } else {
> > +   /* make i2c controllers use the new IP */
> > +   rk_clrsetreg(>soc_con1,
> > +   RKI2C4_SEL_MASK << RKI2C4_SEL_SHIFT |
> > +   RKI2C3_SEL_MASK << RKI2C3_SEL_SHIFT |
> > +   RKI2C2_SEL_MASK << RKI2C2_SEL_SHIFT |
> > +   RKI2C1_SEL_MASK << RKI2C1_SEL_SHIFT |
> > +   RKI2C0_SEL_MASK << RKI2C0_SEL_SHIFT,
> > +   RKI2C4_SEL_MASK << RKI2C4_SEL_SHIFT |
> > +   RKI2C3_SEL_MASK << RKI2C3_SEL_SHIFT |
> > +   RKI2C2_SEL_MASK << RKI2C2_SEL_SHIFT |
> > +   RKI2C1_SEL_MASK << RKI2C1_SEL_SHIFT |
> > +   RKI2C0_SEL_MASK << RKI2C0_SEL_SHIFT);
> > +   }
> 
> Can you move this to the pinctrl driver?

Are you sure that is the right approach?

This setting switches the i2c controller IP block used, while the i2c-pins are 
not affected by this at all. You could also use the i2c pins with the other 
i2c controller with the same pinctrl settings, so it feels a tiny bit strange 
to burden the pinctrl driver with this.

Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 19/20] rockchip: rk3188: Add Radxa Rock board

[Heiko Stübner]

Hi Simon,

Am Donnerstag, 23. März 2017, 10:18:31 CET schrieb Simon Glass:
> On 21 February 2017 at 13:35, Simon Glass  wrote:
> > On 18 February 2017 at 11:46, Heiko Stuebner  wrote:
> >> The Rock is a RK3188 based single board computer by Radxa.
> >> Currently it still relies on the proprietary DDR init and
> >> cannot use the generic SPL, but at least is able to boot
> >> a linux kernel and system up to a regular login prompt.
> >> 
> >> Signed-off-by: Heiko Stuebner 
> >> Reviewed-by: Simon Glass 
> >> Tested-by: Kever Yang 
> >> ---
> >> 
> >>  arch/arm/dts/Makefile |   1 +
> >>  arch/arm/dts/rk3188-radxarock.dts | 382
> >>  ++
> >>  arch/arm/mach-rockchip/rk3188/Kconfig |  11 +
> >>  board/radxa/rock/Kconfig  |  15 ++
> >>  board/radxa/rock/MAINTAINERS  |   6 +
> >>  board/radxa/rock/Makefile |   7 +
> >>  board/radxa/rock/rock.c   |   7 +
> >>  configs/rock_defconfig|  56 +
> >>  include/configs/rock.h|  30 +++
> >>  9 files changed, 515 insertions(+)
> >>  create mode 100644 arch/arm/dts/rk3188-radxarock.dts
> >>  create mode 100644 board/radxa/rock/Kconfig
> >>  create mode 100644 board/radxa/rock/MAINTAINERS
> >>  create mode 100644 board/radxa/rock/Makefile
> >>  create mode 100644 board/radxa/rock/rock.c
> >>  create mode 100644 configs/rock_defconfig
> >>  create mode 100644 include/configs/rock.h
> > 
> > Applied to u-boot-rockchip, thanks!
> 
> Just a reminder that I had to drop this patch as it does not build.
> Can you please resend this one? I have also reverted the README patch
> but can apply that myself once this board is enabled.

ah, I should probably fold the patch fixing the build issue into this one. I'll 
create a new series and collect all the different sets flying around.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/6] dm: core: Allow multiple drivers to bind for a single node

[Heiko Stübner]

Hi Simon,

Am Sonntag, 12. März 2017, 14:21:35 CET schrieb Simon Glass:
> On 3 March 2017 at 03:52, Dr. Philipp Tomsich
>  wrote:
> > On 03 Mar 2017, at 05:52, Simon Glass  wrote:
> > On 22 February 2017 at 13:47, Philipp Tomsich
> >  wrote:
> > 
> > Currently, driver binding stops once it encounters the first
> > compatible driver that doesn't refuse to bind. However, there are
> > cases where a single node will need to be handled by multiple driver
> > classes. For those cases we provide a configurable option to continue
> > to bind after the first driver has been found.
> > 
> > The first use cases for this are from the DM conversion of the sunxi
> > (Allwinner) architecture:
> > * pinctrl (UCLASS_PINCTRL) and gpio (UCLASS_GPIO) drivers need to
> > 
> >   bind against a single node
> > 
> > * clock (UCLASS_CLK) and reset (UCLASS_RESET) drivers also need to
> > 
> >   bind against a single node
> > 
> > Does linux work this way? Another approach would be to have a separate
> > MISC driver with two children, one pinctrl, one clk.
> > 
> > 
> > The linux CLK driver creates and registers a reset-controller; the PINCTRL
> > driver
> > does the same with the gpio-controller. Similar code to do this is easily
> > possible in
> > U-Boot … see sunxi_pctrl_bind_gpio(…) in [PATCH v2 1/6] of this series.
> > 
> > However, binding multiple times makes for much simpler code and allows to
> > keep
> > driver data in separate drivers.
> 
> My question was more whether Linux registers multiple drivers with one
> device node. It's just not something I expected.
> 
> I'm not really convinced on this. It will break the current one-to-one
> relationship, and functions like device_get_child_by_of_offset(). I
> think it would be better to have a MISC driver with two children.

In the regular device model the Linux kernel also generally has a one-to-one 
model. There are special cases, like clock and timer init using special 
handling, or things like "syscon" which acts like more of a flag and can live 
next to a regular device.

Therefore things like the Rockchip clock controller create the reset 
controller included in the CRU block. A behaviour the uboot clk driver mimics.

Also doesn't allowing multiple drivers to sit on top of a node create 
contention on who gets access to registers? At least in the kernel multiple 
mappings of registers are generally not favoured.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip breakage with "spl: Remove overwrite of relocated malloc limit"

[Heiko Stübner]

Am Dienstag, 7. März 2017, 10:01:02 CET schrieb Simon Glass:
> Hi,
> 
> On 6 March 2017 at 23:56, Kever Yang <kever.y...@rock-chips.com> wrote:
> > Hi Heiko,
> > 
> > That patch break all the Rockchip SoCs SPL which using spl_init().
> > 
> > Eddie send one patch for rk3288 by add a spl_early_init(), which is
> > under review, I also look forward for better solution.
> 
> Is this a problem for the upcoming release? I have not seen the
> breakage on firefly (although I found a few other problems) so did not
> think it needed to be resolved right away.

not for the rk3188 - as it is not part of a release yet, but if you look at 
Eddie's patches, it seems like it of course affects rk3288.

Although I'd think there must be a nicer way than duplicating spl_init to fix 
that issue :-) .


Heiko

> > On 03/07/2017 08:42 AM, Heiko Stübner wrote:
> >> Hi,
> >> 
> >> I just realized patch b3d2861eb20a ("spl: Remove overwrite of relocated
> >> malloc
> >> limit") introduces breakage in my rk3188 uboot code (and should most
> >> likely
> >> also affect the very similar other rockchip spl boards).
> >> 
> >> The boards call spl_init in their board_init_f functions because they
> >> need
> >> the
> >> spl infrastructure to find and bringup the devicetree stuff and things
> >> like
> >> pinctrl and ram.
> >> 
> >> With the recent change mentioned above, spl_init fails with
> >> 
> >> spl_init() failed: -12
> >> 
> >> because
> >> 
> >> dm_init_and_scan() returned error -12
> >> 
> >> because
> >> 
> >> dm_init() failed: -12
> >> 
> >> ...
> >> because
> >> 
> >> Missing uclass for driver root_driver
> >> 
> >> because
> >> 
> >> uclass_add calls calloc, which fails with the -ENOMEM (-12)
> >> 
> >> I still lack uboot experience to see the correct way forward. Reverting
> >> that
> >> patch of course makes my board start uboot again [and most likely the
> >> other
> >> Rockchip SPLs as well], but there is possibly some better solution
> >> [Or there is simply something very wrong with my rk3188 stuff :-) ].
> >> 
> >> 
> >> Heiko
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] rockchip breakage with "spl: Remove overwrite of relocated malloc limit"

[Heiko Stübner]

Hi,

I just realized patch b3d2861eb20a ("spl: Remove overwrite of relocated malloc 
limit") introduces breakage in my rk3188 uboot code (and should most likely 
also affect the very similar other rockchip spl boards).

The boards call spl_init in their board_init_f functions because they need the 
spl infrastructure to find and bringup the devicetree stuff and things like 
pinctrl and ram.

With the recent change mentioned above, spl_init fails with
spl_init() failed: -12
because
dm_init_and_scan() returned error -12
because
dm_init() failed: -12
...
because
Missing uclass for driver root_driver
because
uclass_add calls calloc, which fails with the -ENOMEM (-12)

I still lack uboot experience to see the correct way forward. Reverting that 
patch of course makes my board start uboot again [and most likely the other 
Rockchip SPLs as well], but there is possibly some better solution
[Or there is simply something very wrong with my rk3188 stuff :-) ].


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/16] rk3188 uboot support

[Heiko Stübner]

Hi Simon,

Am Donnerstag, 16. Februar 2017, 13:43:45 CET schrieb Simon Glass:
> On 3 February 2017 at 09:09, Heiko Stuebner  wrote:
> > this is meant as a status update and possible discussion for
> > the core parts if needed.
> > 
> > After talking with Simon and Tom the order is now also correct
> > with tpl -> spl -> uboot.
> > 
> > 
> > Status right now is:
> > - the full uboot still works
> > - the tpl/spl does start and is able to configure the ddr
> > 
> >   into a working state
> > 
> > - The jump spl -> bootrom -> uboot doesn't work though
> > 
> > On the other hand, Kever was able to make this work, booting
> > from nand when building the image with a very ancient tool.
> > 
> > All newer tools (including boot_merger.c from Rockchip's uboot)
> > do not produce working images. But it is possible to produce
> > a working sd-boot image using the proprietary 1st-stage loader.
> > 
> > See the temporary mkuboot script in the last patch, which can
> > create both types of images now (especially wrt. the needed
> > rc4 encryption of everything).
> > 
> > Combining this (it does work using some special tool), it looks
> > like there is still some minor glitch in the way we build the
> > spl image somewhere.
> 
> What should we do with this series? There are a few minor things to
> resolve but other than that, do you think it is ready to apply?

It's somehow always on the backburner, but I already started fixing the things 
you pointed out. Though I'll be in Portland, Mountain View and San Francisco 
for the next two weeks, so will only be able to resend the fixes after that.


> The above problem could perhaps be resolved later if there is a
> suitable README describing it?

Kever  already found out, that the sd read the bootrom does fails when trying 
to load the uboot from the spl. I'm still trying to investigate this [same 
Portland remark applies], but if you're ok with stuff going in in this state, 
that is definitly fine by me, as it spares me from sending the full series all 
the time ;-)


Heiko

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/16] dm: allow limiting pre-reloc markings to spl or tpl

[Heiko Stübner]

Hi Simon,

Am Montag, 6. Februar 2017, 07:34:54 CET schrieb Simon Glass:
> On 3 February 2017 at 08:09, Heiko Stuebner  wrote:
> > Right now the u-boot,dm-pre-reloc flag will make each marked node
> > always appear in both spl and tpl. But systems needing an additional
> > tpl might have special constraints for each, like the spl needing to
> > be very tiny.
> > 
> > So introduce two additional flags to mark nodes for only spl or tpl
> > environments and introduce a function dm_fdt_pre_reloc to automate
> > the necessary checks in code instances checking for pre-relocation
> > flags.
> > 
> > The behaviour of the original flag stays untouched and still marks
> > a node for both spl and tpl.
> > 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  doc/driver-model/README.txt  |  4 
> >  drivers/clk/at91/pmc.c   |  3 ++-
> >  drivers/core/root.c  |  2 +-
> >  drivers/core/util.c  | 29 +
> >  drivers/pinctrl/pinctrl-uclass.c |  3 ++-
> >  include/dm/util.h|  2 ++
> >  scripts/Makefile.spl |  7 ++-
> >  tools/dtoc/dtoc.py   |  2 ++
> >  8 files changed, 48 insertions(+), 4 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> s/u-boot/U-Boot
> 
> Please add a comment for dm_fdt_pre_reloc() in the header file.
> 
> Two things to consider:
> 
> - Should we drop the use of u-boot,dm-pre-reloc in Makefile.spl, and
> convert all users to your version? This would mean having both
> u-boot,dm-pre-reloc and u-boot,dm-spl in some cases, I suspect.
^^ u-boot,dm-spl and u-boot,dm-tpl I guess

Dropping u-boot,dm-pre-reloc is for you to decide, as you wrote the original 
implementation ;-) . It will save one fdt-query but might need several 
iterations as I guess new boards will add new ones after we remove the old 
ones.

> - Can you use #ifdef in SPL/TPL to reduce code size fractionally in
> dm_fdt_pre_reloc()?

Do you mean moving the
+   dm_spl = fdt_getprop(blob, offset, "u-boot,dm-spl", NULL);
+   dm_tpl = fdt_getprop(blob, offset, "u-boot,dm-tpl", NULL);

into the existing #ifdef CONFIG_TPL_BUILD / SPL_BUILD blocks or something 
else?


Thanks
Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Am Mittwoch, 30. November 2016, 19:20:30 schrieb Simon Glass:
> Hi Heiko,
> 
> On 30 November 2016 at 04:52, Heiko Stübner <he...@sntech.de> wrote:
> > Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
> >> Hi Heiko,
> >> 
> >> On 29 November 2016 at 16:45, Heiko Stübner <he...@sntech.de> wrote:
> >> > Hi Simon,
> >> > 
> >> > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> >> >> This v3 patch is an update on Sjoerd's original v2 series from
> >> >> Feburary.
> >> >> I have dealt with the changes requested at the time, and adjusted the
> >> >> way
> >> >> that the speed change is handled.
> >> >> 
> >> >> Tested on firefly-rk3288, rock2.
> >> > 
> >> > Tested on a firefly as well. Though I get mixed results in my netboot
> >> > environment. At 100MBit (manually limited) everything seems fine:
> >> > 
> >> > --
> >> > Speed: 100, full duplex
> >> > BOOTP broadcast 1
> >> > BOOTP broadcast 2
> >> > DHCP client bound to address 192.168.140.58 (269 ms)
> >> > Using ethernet@ff29 device
> >> > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> >> > Filename 'hstuebner/firefly.vmlinuz'.
> >> > Load address: 0x400
> >> > Loading:
> >> > #
> >> > 
> >> >  ##
> >> >  ###
> >> >  ##
> >> >  ###
> >> >  ##
> >> >  ###
> >> >  ##
> >> >  ###
> >> >  ##
> >> >  ###
> >> >  ##
> >> >  ###
> >> >  #
> >> >  2.9 MiB/s
> >> > 
> >> > done
> >> > Bytes transferred = 7033483 (6b528b hex)
> >> > --
> >> > 
> >> > 5 out of 5 boots worked fine.
> >> > 
> >> > 
> >> > but at 1000MHz I only get:
> >> > 
> >> > --
> >> > Speed: 1000, full duplex
> >> > BOOTP broadcast 1
> >> > BOOTP broadcast 2
> >> > DHCP client bound to address 192.168.140.57 (270 ms)
> >> > Using ethernet@ff29 device
> >> > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> >> > Filename 'hstuebner/firefly.vmlinuz'.
> >> > Load address: 0x400
> >> > Loading: #T #T #T ##T T #T #T T T #T 
> >> > Retry count exceeded; starting again
> >> > --
> >> > 
> >> > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown
> >> > reason.
> >> > I'm not sure if just my switch is some special snowflake (TL-SG1024
> >> > from
> >> > TP- Link) or there is some other voodoo at work here.
> >> > 
> >> > The rootfs over nfs seems to work fine on 1000MBit though.
> >> 
> >> Yes I see some timeouts, although I don't think it is anything to do
> >> with the driver conversion. Or does this not happen unless my patches
> >> are applied?
> > 
> > nope, really looks like some other parts are just not fast enough? And the
> > setup of GRF and so on, look the same as in the linux kernel, so should be
> > fine as well.
> 
> So to be clear, are you saying that the same problem happens on a
> downstream tree that you tried, or not?

nope, didn't say that. The firefly actually is my first board using the 
internal 
ethernet. My other boards normally use usb-ethernet adapters as the arc-emac 
used in other socs isn't supported at all yet.


> In terms of 'not fast enough' you could try turning off HDMI if that
> is on. Also see veyron_init() and see if you can adapt that to firefly
> to get the clock speed up?

Sadly not until after the 11th of december. But I guess we could just merge it 
now and hopefully fixup the special case later on. It seems to work always at 
100MBit and it seems also at 1000MBit on your side.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Hi Simon,

Am Mittwoch, 30. November 2016, 12:52:22 schrieb Heiko Stübner:
> Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
> > On 29 November 2016 at 16:45, Heiko Stübner <he...@sntech.de> wrote:
> > > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> > >> This v3 patch is an update on Sjoerd's original v2 series from
> > >> Feburary.
> > >> I have dealt with the changes requested at the time, and adjusted the
> > >> way
> > >> that the speed change is handled.
> > >> 
> > >> Tested on firefly-rk3288, rock2.
> > > 
> > > Tested on a firefly as well. Though I get mixed results in my netboot
> > > environment. At 100MBit (manually limited) everything seems fine:

so assuming the 1000MBit issue comes from somewhere else, this series
Tested-by: Heiko Stuebner <he...@sntech.de>


> > > --
> > > Speed: 100, full duplex
> > > BOOTP broadcast 1
> > > BOOTP broadcast 2
> > > DHCP client bound to address 192.168.140.58 (269 ms)
> > > Using ethernet@ff29 device
> > > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> > > Filename 'hstuebner/firefly.vmlinuz'.
> > > Load address: 0x400
> > > Loading:
> > > #
> > > 
> > >  ###
> > >  ##
> > >  ###
> > >  ##
> > >  ###
> > >  ##
> > >  ###
> > >  ##
> > >  ###
> > >  ##
> > >  ###
> > >  ##
> > >  #
> > >  2.9 MiB/s
> > > 
> > > done
> > > Bytes transferred = 7033483 (6b528b hex)
> > > --
> > > 
> > > 5 out of 5 boots worked fine.
> > > 
> > > 
> > > but at 1000MHz I only get:
> > > 
> > > --
> > > Speed: 1000, full duplex
> > > BOOTP broadcast 1
> > > BOOTP broadcast 2
> > > DHCP client bound to address 192.168.140.57 (270 ms)
> > > Using ethernet@ff29 device
> > > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> > > Filename 'hstuebner/firefly.vmlinuz'.
> > > Load address: 0x400
> > > Loading: #T #T #T ##T T #T #T T T #T 
> > > Retry count exceeded; starting again
> > > --
> > > 
> > > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown
> > > reason.
> > > I'm not sure if just my switch is some special snowflake (TL-SG1024 from
> > > TP- Link) or there is some other voodoo at work here.
> > > 
> > > The rootfs over nfs seems to work fine on 1000MBit though.
> > 
> > Yes I see some timeouts, although I don't think it is anything to do
> > with the driver conversion. Or does this not happen unless my patches
> > are applied?
> 
> nope, really looks like some other parts are just not fast enough? And the
> setup of GRF and so on, look the same as in the linux kernel, so should be
> fine as well.
> 
> 
> Heiko

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
> Hi Heiko,
> 
> On 29 November 2016 at 16:45, Heiko Stübner <he...@sntech.de> wrote:
> > Hi Simon,
> > 
> > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> >> This v3 patch is an update on Sjoerd's original v2 series from Feburary.
> >> I have dealt with the changes requested at the time, and adjusted the way
> >> that the speed change is handled.
> >> 
> >> Tested on firefly-rk3288, rock2.
> > 
> > Tested on a firefly as well. Though I get mixed results in my netboot
> > environment. At 100MBit (manually limited) everything seems fine:
> > 
> > --
> > Speed: 100, full duplex
> > BOOTP broadcast 1
> > BOOTP broadcast 2
> > DHCP client bound to address 192.168.140.58 (269 ms)
> > Using ethernet@ff29 device
> > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> > Filename 'hstuebner/firefly.vmlinuz'.
> > Load address: 0x400
> > Loading: #
> > 
> >  #
> >  #
> >  #
> >  #
> >  #
> >  #
> >  #
> >  2.9 MiB/s
> > 
> > done
> > Bytes transferred = 7033483 (6b528b hex)
> > --
> > 
> > 5 out of 5 boots worked fine.
> > 
> > 
> > but at 1000MHz I only get:
> > 
> > --
> > Speed: 1000, full duplex
> > BOOTP broadcast 1
> > BOOTP broadcast 2
> > DHCP client bound to address 192.168.140.57 (270 ms)
> > Using ethernet@ff29 device
> > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> > Filename 'hstuebner/firefly.vmlinuz'.
> > Load address: 0x400
> > Loading: #T #T #T ##T T #T #T T T #T 
> > Retry count exceeded; starting again
> > --
> > 
> > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
> > I'm not sure if just my switch is some special snowflake (TL-SG1024 from
> > TP- Link) or there is some other voodoo at work here.
> > 
> > The rootfs over nfs seems to work fine on 1000MBit though.
> 
> Yes I see some timeouts, although I don't think it is anything to do
> with the driver conversion. Or does this not happen unless my patches
> are applied?

nope, really looks like some other parts are just not fast enough? And the 
setup of GRF and so on, look the same as in the linux kernel, so should be fine 
as well.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Hi Simon,

Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> This v3 patch is an update on Sjoerd's original v2 series from Feburary.
> I have dealt with the changes requested at the time, and adjusted the way
> that the speed change is handled.
> 
> Tested on firefly-rk3288, rock2.

Tested on a firefly as well. Though I get mixed results in my netboot 
environment. At 100MBit (manually limited) everything seems fine:

--
Speed: 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.140.58 (269 ms)
Using ethernet@ff29 device
TFTP from server 192.168.140.1; our IP address is 192.168.140.58
Filename 'hstuebner/firefly.vmlinuz'.
Load address: 0x400
Loading: #
 #
 #
 #
 #
 #
 #
 #
 2.9 MiB/s
done
Bytes transferred = 7033483 (6b528b hex)
--

5 out of 5 boots worked fine.


but at 1000MHz I only get:

--
Speed: 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.140.57 (270 ms)
Using ethernet@ff29 device
TFTP from server 192.168.140.1; our IP address is 192.168.140.57
Filename 'hstuebner/firefly.vmlinuz'.
Load address: 0x400
Loading: #T #T #T ##T T #T #T T T #T 
Retry count exceeded; starting again
--

on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
I'm not sure if just my switch is some special snowflake (TL-SG1024 from TP-
Link) or there is some other voodoo at work here.

The rootfs over nfs seems to work fine on 1000MBit though.


Heiko

> Original cover letter:
> To add support I've taken a slightly different approach then some of the
> other boards with a designware IP block, by creating a new driver to
> take care of the platfrom glue which subclasses the main designware driver
> instead of adding the compatibility string the designware driver
> directly and doing the SoC specific setup in the board files. This seems
> quite a bit more elegant in a device model based world.
> 
> I've only tested this series on a Radxa Rock 2 board, it would be great
> if someone could test this on other boards with the designware IP
> especially for those with the reset GPIO in devicetree (e.g. some of the
> Allwinner boards).
> 
> Compared to the first one round the pinctrl related bits were dropped as
> RK3288 now has a full pinctrl driver. Furthermore the started hook in the
> designware driver was renamed to fix_mac_speed in line with what linux
> uses and moved to the dw_link_adjust function.
> 
> Changes in v3:
> - Add a few new patches
> - Add comments for struct gmac_rk3288_platdata
> - Add new patch to adjust dw_adjust_link() to return an error
> - Add new patch to enable networking on evb-rk3288
> - Add new patch to export the operation functions
> - Add new patch to split the link init into a separate function
> - Adjust binding to use r/tx-delay instead of r/tx_delay
> - Drop the 'net: designware: Add a fix_mac_speed hook' patch
> - Sort includes
> - Use debug() instead of printf() for error
> - Use function calls instead of fix_mac_speed() hook
> - Use new clk interface
> 
> Changes in v2:
> - Adjust to new hook name
> - Fix various coding style nits
> 
> Simon Glass (4):
>   net: designware: Adjust dw_adjust_link() to return an error
>   net: designware: Split the link init into a separate function
>   net: designware: Export the operation functions
>   rockchip: evb-rk3339: Enable DHCP
> 
> Sjoerd Simons (5):
>   net: designware: Export various functions/struct to allow subclassing
>   net: gmac_rk3288: Add RK3288 GMAC driver
>   rockchip: Enable networking support on rock2 and firefly
>   rockchip: Add PXE and DHCP to the default boot targets
>   rockchip: Drop Ethernet from the TODO
> 
>  configs/evb-rk3399_defconfig  |   3 +
>  configs/firefly-rk3288_defconfig  |   4 +
>  configs/rock2_defconfig   |   4 +
>  doc/README.rockchip   |   1 -
>  drivers/net/Kconfig   |   7 ++
>  drivers/net/Makefile  |   1 +
>  drivers/net/designware.c  |  57 ++
>  drivers/net/designware.h  |  13 
>  drivers/net/gmac_rk3288.c | 154
> ++ include/configs/rockchip-common.h | 
>  4 +-
>  10 files changed, 230 insertions(+), 18 deletions(-)
>  create mode 100644 drivers/net/gmac_rk3288.c

___
U-Boot mailing list

Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel

[Heiko Stübner]

Am Dienstag, 29. November 2016, 14:40:49 schrieb Simon Glass:
> Hi Rick,
> 
> On 29 November 2016 at 11:22, Rick Bronson  wrote:
> > Hi Heiko and Simon,
> > 
> >   Thank you both for your help, I really appreciate it.
> >   
> >   No, I do not have the Linux mainline running yet as I was focusing
> > 
> > on getting the mainline u-boot running since I saw some references
> > that implied I may need that to use the mainline Linux.  I did try the
> > mainline kernel with the vendor-fork u-boot but got nothing pas the
> > "Loading Linux" line from u-boot.
> > 
> >   I think what I will probably do is take the easy way out and use the
> > 
> > vendor-fork u-boot since that boots on this hardware.
> > 
> >   But since I've invested some amount of time in the mainline u-boot
> > 
> > and it's drinving me mad that I can't seem to figure out what's wrong,
> > I do have one last question (hopefully).
> 
> It would certainly make sense to invest in getting this running if you can.
> 
> >   I've got mainline u-boot getting this far (I added debug to show
> > 
> > what GPIO0 and 2 are outputting).
> > 
> > 
> > U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
> > Trying to boot from MMC1
> > Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
> > ...
> > 
> > 
> >   I've modified rk3288-firefly.dts (the closest thing to hardware I
> > 
> > have) to set the eMMC reset line high but as you see above, nothing is
> > set on any GPIO.  This leads me to believe that I do not understand
> > how the device tree is loaded/used in SPL.  Can anyone point me to
> > help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
> > tried both) or how to debug if I am in fact even reading my dtb.
> 
> You should be able to use 'gpio status' to see the GPIO state once you
> get to U-Boot.
> 
> But if your board is booting SPL from MMC how can it possibly fail to
> load U-Boot from MMC? The MMC GPIO must already work for you to get
> this far. Or are you loading SPL from something other than MMC?

Or you can try enabling the 
CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
option, which will simply let the on-chip rom also load the 2nd stage uboot 
seemingly using the same method as for the spl.

I'm currently testing Simon's network patches and this option works quite 
nicely.


Heiko

> You want u-boot-spl.bin (which includes the device tree).
> 
> >   Thanks again,
> >   
> >   Rick
> > 
> > PS.  My Makefile is here if you are so inclined:
> > http://members.efn.org/~rick/pub/Makefile  See the targets u-boot-denx
> > and uboot_new_flash to see what I've tried.
> 
> You could push your tree somewhere or a patch showing what changes you
> have made.
> 
> Regards,
> Simon
> 
> >> From he...@sntech.de Tue Nov 29 08:45:02 2016
> >> To: u-boot@lists.denx.de
> >> Cc: Simon Glass , Rick Bronson ,
> > 
> > "eddie.cai" ,
> > linux-rockc...@lists.infradead.org
> > 
> >> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> >> Date: Tue, 29 Nov 2016 11:20:52 +0100
> >> 
> >> Hi Rick,
> >> 
> >> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> >> > + A few rockchip people and linux-rockchip
> >> > 
> >> > Hi Rick,
> >> > 
> >> > On 25 November 2016 at 11:20, Rick Bronson  wrote:
> >> > > Hi All,
> >> > > 
> >> > >   I've got unsupported RK3288 hardware running the latest git u-boot
> >> > >   to
> >> > > 
> >> > > SPL as explained in
> >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My
> >> > > goal
> >> > > is to run the mainline (ie. not Android) Linux kernel on this
> >> > > hardware
> >> > > 
> >> > > and wondered:
> >> > >  - Do I need to get the latest git u-boot to run before I can run the
> >> > > 
> >> > > mainline kernel?  Or can I use
> >> > > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> >> > > u-boot fully.
> >> > 
> >> > It's up to you - obviously mainline is where the development should
> >> > be, but there is no requirement that I know of.
> >> 
> >> correct, the (mainline-)kernel runs just fine on both the vendor-fork of
> > 
> > uboot
> > 
> >> as well as on mainline.
> >> 
> >> > Does mainline run on your board?
> >> > 
> >> > >  - The device tree seems to be in two places, once via:
> >> > > resource_tool --image=resource2.img --pack linux/logo.bmp
> >> > > ${DTS}.dtb
> >> > >   
> >> > >   that gets put into the resource file and then again at the end of
> >> > >   the
> >> > > 
> >> > > kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
> >> > > I get things like:
> >> > > 
> >> > > Unknow param: MACHINE_MODEL:rk30sdk!
> >> > > Unknow param: MACHINE_ID:007!
> >> 
> >> ARM_APPEND_DTB is meant for boards where the bootloader cannot load the
> >> devicetree (to old or so) and also cannot be reasonably exchanged. So the
> >> append-mechanism was invented to allow 

Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel

[Heiko Stübner]

Hi Rick,

Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> + A few rockchip people and linux-rockchip
> 
> Hi Rick,
> 
> On 25 November 2016 at 11:20, Rick Bronson  wrote:
> > Hi All,
> > 
> >   I've got unsupported RK3288 hardware running the latest git u-boot to
> > 
> > SPL as explained in
> > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My goal
> > is to run the mainline (ie. not Android) Linux kernel on this hardware
> > 
> > and wondered:
> >  - Do I need to get the latest git u-boot to run before I can run the
> > 
> > mainline kernel?  Or can I use
> > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> > u-boot fully.
> 
> It's up to you - obviously mainline is where the development should
> be, but there is no requirement that I know of.

correct, the (mainline-)kernel runs just fine on both the vendor-fork of uboot 
as well as on mainline.


> Does mainline run on your board?
> 
> >  - The device tree seems to be in two places, once via:
> > resource_tool --image=resource2.img --pack linux/logo.bmp
> > ${DTS}.dtb
> >   
> >   that gets put into the resource file and then again at the end of the
> > 
> > kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
> > I get things like:
>
> > Unknow param: MACHINE_MODEL:rk30sdk!
> > Unknow param: MACHINE_ID:007!

ARM_APPEND_DTB is meant for boards where the bootloader cannot load the 
devicetree (to old or so) and also cannot be reasonably exchanged. So the 
append-mechanism was invented to allow bundling the devicetree with the actual 
kernel image, so that to the bootloader it looks like just any other kernel 
image.

So you essentially only need one or the other. Also at least mainline uboot 
also supports the FIT image type, where you can bundle the devicetree in a 
more generalized way.

For your message I would guess the kernel didn't find a usable devicetree 
somehow and was falling back to ATAGS-based board selection?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 7/9] rockchip: evb-rk3339: Enable DHCP

[Heiko Stübner]

Hi Simon,

Am Sonntag, 27. November 2016, 10:01:47 schrieb Simon Glass:
> This is the only RK3288 device without DHCP. Enable it so that we
  ^^ rk3288/rk3399?
> can use a common BOOT_TARGET_DEVICES setting. It is likely useful to be
> able to use USB networking, at least. Full networking can be enabled when
> a suitable platform needs it.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v3:
> - Add new patch to enable networking on evb-rk3288

same here :-)


Heiko

> 
> Changes in v2: None
> 
>  configs/evb-rk3399_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
> index 40a8295..be522fb 100644
> --- a/configs/evb-rk3399_defconfig
> +++ b/configs/evb-rk3399_defconfig
> @@ -11,6 +11,9 @@ CONFIG_CMD_MMC=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
>  # CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_DHCP=y
> +CONFIG_CMD_MII=y
> +CONFIG_CMD_PING=y
>  CONFIG_CMD_TIME=y
>  CONFIG_CMD_EXT2=y
>  CONFIG_CMD_EXT4=y

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

[Heiko Stübner]

Hi,

Am Donnerstag, 28. Juli 2016, 21:46:04 schrieb Doug Anderson:
> On Mon, Jul 11, 2016 at 7:45 PM, Kever Yang  
wrote:
> > Hi Simon,
> > 
> > CC Doug for this topic.
> > 
> > On 07/12/2016 07:54 AM, Simon Glass wrote:
> >> Hi Kever,
> >> 
> >> On 11 July 2016 at 00:58, Kever Yang  wrote:
> >>> Hi Simon,
> >>> 
> >>> On 07/09/2016 10:39 PM, Simon Glass wrote:
>  Hi Kever,
>  
>  On 7 July 2016 at 20:45, Kever Yang  wrote:
> > The grf setting for rkpwm is only need in rk3288, other SoCs like
> > RK3399 which also use rkpwm do not need set the grf, let's add a
> > MACRO to make the code only for RK3288.
> > 
> > Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477
>  
>  patman will automatically remove these for you.
> >>> 
> >>> Will use patman for my new patches later, thanks.
> >>> 
> > Signed-off-by: Kever Yang 
> > ---
> > 
> >drivers/pwm/rk_pwm.c | 8 
> >1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
> > index 2d289a4..e34adf0 100644
> > --- a/drivers/pwm/rk_pwm.c
> > +++ b/drivers/pwm/rk_pwm.c
> > @@ -13,8 +13,10 @@
> > 
> >#include 
> >#include 
> >#include 
> > 
> > +#ifdef CONFIG_ROCKCHIP_RK3288
> > 
> >#include 
> >#include 
> > 
> > +#endif
> > 
> >#include 
> >#include 
> > 
> > @@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
> > 
> >struct rk_pwm_priv {
> >
> >   struct rk3288_pwm *regs;
> > 
> > +#ifdef CONFIG_ROCKCHIP_RK3288
> > 
> >   struct rk3288_grf *grf;
> > 
> > +#endif
> > 
> >};
> >
> >static int rk_pwm_set_config(struct udevice *dev, uint channel,
> >uint
> > 
> > period_ns,
> > @@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct
> > udevice
> > *dev)
> > 
> >   struct regmap *map;
> >   
> >   priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
> > 
> > +#ifdef CONFIG_ROCKCHIP_RK3288
> > 
> >   map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
> >   if (IS_ERR(map))
> >   
> >   return PTR_ERR(map);
> >   
> >   priv->grf = regmap_get_range(map, 0);
> > 
> > +#endif
>  
>  I'd like to find a better way. Do all chips have a grf? If so then
>  perhaps we can have a function like grf_enable_pwm() in the core SoC
>  code and call it here. The #ifdef can be there.
>  
>  Or perhaps we should have a general soc.c, with its own struct
>  containing pointers to grf, sgrf, etc. It can be set up at the start,
>  and then provide a soc_enable_pwm() function to enable the pwm.
>  
>  What do you think?
> >>> 
> >>> Every Rockchip soc have grf, and maybe sgrf, pmugrf which much like
> >>> grf. The content in grf are very different for different SoC, it gathers
> >>> all kinds of system/module control registers .
> >>> Back to the grf setting for pwm, this control operation is only need in
> >>> RK3288, not in RK3399 and new SoC further. so I think the '#ifdef' is
> >>> better to stay in driver file like rk_pwm.c.
> >>> 
> >>> For these system control registers, I'm sure the dedicate general soc.c
> >>> is
> >>> needed, because they are not so common for different module and
> >>> different
> >>> Soc. We are not able to have a common framework for them, a general
> >>> soc.c
> >>> won't help much except all the system control are gather in one file .
> >>> 
> >>> I think the GRF setting is part of the module and driver, so we can
> >>> leave
> >>> it
> >>> as it is,
> >>> and a simple syscon driver is enough for grf like what is kernel do.
> >> 
> >> I looked quickly at the Linux pwm driver but I don't see any grf
> >> access there. How does the grf register get set in Linux? I really
> >> want to avoid SoC-specific #ifdefs in drivers.
> > 
> > Doug(in cc list) send the patch for this pwm setting, but it seems does
> > not
> > accept by upstream,
> > I think people also don't like this grf access in driver and prefer this
> > kind of one time init operation
> > to be done in bootloader.
> > patchset 1 implement in arch/arm/mach-rockchip/rockchip.c
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280064.h
> > tml patchset 4 implement in drivers/pwm_rockchip.c
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280715.h
> > tml
> > 
> > Hi Doug,
> > 
> > Do you have any suggestion here?
> 
> Heiko will skin me for suggesting it, but one option would be to
> consider this as a pinmux thing in the linux kernel.  The GRF can
> choose between two IP blocks internally: the old PWM IP block or the
> 

Re: [U-Boot] [PATCH v2 0/8] basic rockchip rk3188 support

[Heiko Stübner]

Hi Simon,

Am Mittwoch, 27. Juli 2016, 21:42:47 schrieb Simon Glass:
> On 22 July 2016 at 15:51, Heiko Stuebner  wrote:
> > Second version. Simon already applied the cleanup patches from my
> > first version. I've tried to address Simons comments and hopefully
> > haven't overlooked any.
> > 
> > SPL is still missing, so following Simons comment from earlier
> > it cannot go in yet, but maybe the first two cleanups can.
> 
> Re the first patch, if you can resend it as a 'move' patch then I can
> apply it. Please base on u-boot-rockchip/master.

ok, I can do that :-)

> For rk3188, yes I would prefer to wait until we have the proper SPL.
> It sounds like you are close? I don't have an rk3188 board - I could
> get a TV box with that chip but I'm not sure if it would work for
> development.

I wouldn't call it close, but it's moving along somewhat and we figure out the 
special requirements step by step. As for yout getting a box, I guess the 
worst part is finding serial pin testpoints. For booting the rk3188 seems to be 
the easiest of them all - if you plug in a suitably prepared card, it will 
always prefer this one over everything else.


Heiko

> > changes in v2:
> > - move clock drivers to subdirectory
> > - use already available log2 function in clock drivers
> > - SPDX header in clock bindings
> > - showcase rk3188 arch code and rock board
> > 
> > Heiko Stuebner (10):
> >   rockchip: move clock drivers into a subdirectory
> >   rockchip: remove log2 reimplementation from clock drivers
> >   rockchip: rk3188: Add header files for PMU and GRF
> >   rockchip: rk3188: Add pinctrl driver
> >   rockchip: rk3188: Bring in rk3066/rk3188 clock bindings
> >   rockchip: rk3188: Add clock driver
> >   rockchip: rk3188: add core support
> >   rockchip: rk3188: Radxa Rock board
> >   add unfinished SPL support
> >   hacks to make my rock netboot a fit image
> >  
> >  arch/arm/dts/Makefile   |   1 +
> >  arch/arm/dts/rk3188-radxarock.dts   | 406 +++
> >  arch/arm/dts/rk3188.dtsi| 631 ++
> >  arch/arm/dts/rk3xxx.dtsi| 431 
> >  arch/arm/include/asm/arch-rockchip/cru_rk3188.h | 183 +
> >  arch/arm/include/asm/arch-rockchip/grf_rk3188.h | 589 
> >  arch/arm/include/asm/arch-rockchip/pmu_rk3188.h |  36 +
> >  arch/arm/mach-rockchip/Kconfig  |  11 +
> >  arch/arm/mach-rockchip/Makefile |   2 +
> >  arch/arm/mach-rockchip/rk3188-board-spl.c   | 190 ++
> >  arch/arm/mach-rockchip/rk3188/Kconfig   |  20 +
> >  arch/arm/mach-rockchip/rk3188/Makefile  |  10 +
> >  arch/arm/mach-rockchip/rk3188/clk_rk3188.c  |  17 +
> >  arch/arm/mach-rockchip/rk3188/reset_rk3188.c|  47 ++
> >  arch/arm/mach-rockchip/rk3188/sdram_rk3188.c| 839
> >  +++ arch/arm/mach-rockchip/rk3188/syscon_rk3188.c  
> >  |  24 +
> >  board/radxa/rock/Kconfig|  15 +
> >  board/radxa/rock/MAINTAINERS|   6 +
> >  board/radxa/rock/Makefile   |   7 +
> >  board/radxa/rock/rock.c |  32 +
> >  configs/rock_defconfig  |  80 +++
> >  drivers/clk/Makefile|   3 +-
> >  drivers/clk/clk_rk3036.c| 386 ---
> >  drivers/clk/clk_rk3288.c| 851
> >   drivers/clk/rockchip/Makefile  
> >  |   9 +
> >  drivers/clk/rockchip/clk_rk3036.c   | 382 +++
> >  drivers/clk/rockchip/clk_rk3188.c   | 493 ++
> >  drivers/clk/rockchip/clk_rk3288.c   | 847
> >  +++ drivers/pinctrl/Kconfig
> >  |   9 +
> >  drivers/pinctrl/rockchip/Makefile   |   1 +
> >  drivers/pinctrl/rockchip/pinctrl_rk3188.c   | 613 +
> >  drivers/usb/host/dwc2.c |   4 +-
> >  include/configs/rk3188_common.h | 109 +++
> >  include/configs/rock.h  |  66 ++
> >  include/dt-bindings/clock/rk3066a-cru.h |  32 +
> >  include/dt-bindings/clock/rk3188-cru-common.h   | 248 +++
> >  include/dt-bindings/clock/rk3188-cru.h  |  48 ++
> >  tools/rkcommon.c|   1 +
> >  38 files changed, 6438 insertions(+), 1241 deletions(-)
> >  create mode 100644 arch/arm/dts/rk3188-radxarock.dts
> >  create mode 100644 arch/arm/dts/rk3188.dtsi
> >  create mode 100644 arch/arm/dts/rk3xxx.dtsi
> >  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3188.h
> >  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3188.h
> >  create mode 100644 arch/arm/include/asm/arch-rockchip/pmu_rk3188.h
> >  create mode 100644 arch/arm/mach-rockchip/rk3188-board-spl.c
> >  create mode 100644 arch/arm/mach-rockchip/rk3188/Kconfig
> >  

Re: [U-Boot] [PATCH] rockchip: fix rk3036 SPL build

[Heiko Stübner]

Hi Simon,

Am Freitag, 22. Juli 2016, 20:31:36 schrieb Simon Glass:
> On 20 July 2016 at 19:47, Kever Yang  wrote:
> > Simon apply my V4 patch which still have some problem, he said that he
> > 
> > will rebase
> > with a new patch set either if I send a new version or send fixes, but he
> > won't be available till next week.
> > 
> > I have send out my V5 patch which including the code of this patch.
> 
> Please can you check u-boot-rockchip and see if this looks OK now?

yep, I've rebased on top of your master branch from just now, and everything 
still builds and runs just fine (rk3036, rk3188 and rk3288).

Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/8] rockchip: rk3188: add core support

[Heiko Stübner]

Am Freitag, 22. Juli 2016, 23:51:11 schrieb Heiko Stuebner:
> Add the core architecture code for the rk3188.
> It doesn't support the SPL yet, as because of some
> unknown error it doesn't start yet.
> 
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/dts/rk3188.dtsi  | 631
> ++ arch/arm/dts/rk3xxx.dtsi  |
> 431 ++ arch/arm/mach-rockchip/Kconfig|  11
> +
>  arch/arm/mach-rockchip/Makefile   |   1 +
>  arch/arm/mach-rockchip/rk3188/Kconfig |   9 +
>  arch/arm/mach-rockchip/rk3188/Makefile|   9 +
>  arch/arm/mach-rockchip/rk3188/clk_rk3188.c|  17 +
>  arch/arm/mach-rockchip/rk3188/reset_rk3188.c  |  47 ++
>  arch/arm/mach-rockchip/rk3188/syscon_rk3188.c |  24 +
>  include/configs/rk3188_common.h   |  95 
>  tools/rkcommon.c  |   1 +
>  11 files changed, 1276 insertions(+)
>  create mode 100644 arch/arm/dts/rk3188.dtsi
>  create mode 100644 arch/arm/dts/rk3xxx.dtsi
>  create mode 100644 arch/arm/mach-rockchip/rk3188/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3188/Makefile
>  create mode 100644 arch/arm/mach-rockchip/rk3188/clk_rk3188.c
>  create mode 100644 arch/arm/mach-rockchip/rk3188/reset_rk3188.c
>  create mode 100644 arch/arm/mach-rockchip/rk3188/syscon_rk3188.c
>  create mode 100644 include/configs/rk3188_common.h
> 
> diff --git a/arch/arm/dts/rk3188.dtsi b/arch/arm/dts/rk3188.dtsi
> new file mode 100644
> index 000..ef1b962
> --- /dev/null
> +++ b/arch/arm/dts/rk3188.dtsi
> @@ -0,0 +1,631 @@
> +/*
> + * Copyright (c) 2013 MundoReader S.L.
> + * Author: Heiko Stuebner 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */

it seems I forgot more license-header conversions in these new two patches.
Sorry about that.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] rockchip: cosmetics, a fix and first steps on the rk3188

[Heiko Stübner]

Hi Simon,

Am Montag, 18. Juli 2016, 06:16:33 schrieb Simon Glass:
> On 17 July 2016 at 09:27, Simon Glass <s...@chromium.org> wrote:
> > On 17 July 2016 at 09:20, Heiko Stübner <he...@sntech.de> wrote:
> >> Am Sonntag, 17. Juli 2016, 08:14:06 schrieb Simon Glass:
> >>> Hi Heiko,
> >>> 
> >>> On 15 July 2016 at 16:17, Heiko Stuebner <he...@sntech.de> wrote:
> >>> > I've made some nice progress on using mainline uboot on the rk3188
> >>> > and would like to dump some first results.
> >>> > 
> >>> > Right now I can use uboot on the rk3188 with the Rockchip binary ddr
> >>> > init,
> >>> > similar to what barebox does and can even netboot a kernel image using
> >>> > a usb ethernet adapter [0] .
> >>> > 
> >>> > While working on this I found quite some cosmetic stuff that shouldn't
> >>> > persist to make extending easier. So while I don't know what the
> >>> > policy
> >>> > is for my standalone pinctrl and clock drivers (without the actual
> >>> > board)
> >>> > at least the cosmetics + fix might get in at least.
> >>> 
> >>> Nice work!
> >>> 
> >>> It would be best to add the drivers with the board - otherwise they
> >>> are just dead code. How far away is it?
> >> 
> >> The big issue is the SPL. Right now I'm using Rockchip's ddr-init as spl-
> >> replacement, and I'd say this second part is nearly ready - only minor
> >> cleanups.
> >> 
> >> The memory-setup is supposed to be very much similar to the rk3288 (same
> >> dw_upctl and ddr-phy), but it looks like the very first steps are
> >> somewhat
> >> different and I haven't been able to make the spl output anything on the
> >> serial console yet ... which could stem from some difference in what the
> >> soc expects or just some dumb mistake on my part :-)
> > 
> > That's always tricky.
> > 
> > You may already know this, but the EARLY_UART setting is used on
> > rk3288 to display a character as soon as SPL starts. You might be able
> > to do something similar. The main issue I had was getting the pinmux
> > setting right.
> > 
> > As a test, you can start with booting SPL from the ddr-init binary I
> > suspect. I have not tried it but it should work. Then the pinmux
> > should already be set up (since ddr-init outputs to serial).

yep, changing the SPL_TEXT_BASE to the ram address and using the spl as 2nd 
stage brings me the expected
earlyuart running
message.

I've also dumped the sram contents after a sucessful boot using the rk ddr-
init + uboot and can see that the ddr-init is sitting at the 0x800 offset in 
sram - including the rk31 header, so I'm pretty sure the sram-based 
SPL_TEXT_BASE should be 0x10080804 - yet no lifesign.

Judging by how the rk3036 declares its SPL_STACK, I guess 0x10087fff should 
also be right.

> I'm going to apply the earlier patches in your series. Once you have a
> working board we can apply the rest (to avoid adding dead code).

great ... everything I don't need to carry over helps ;-) .


Going forward, I see both the rk3368 and rk3399 support initially not 
providing a spl but sitting on top of the binary ddr init + ATF.
Is that also something doable for my rk3188 or do you _require_ the spl there?

I.e. bringing the support without spl forward should be fairly easy, so doing 
that first sounds nice, before worrying about the strange things the SPL needs.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ARM64: rockchip: Add initial support for RK3368 based GeekBox

[Heiko Stübner]

Hi Andreas,

Am Montag, 18. Juli 2016, 03:06:07 schrieb Andreas Färber:
> The RK3368 is an octa-core Cortex-A53 SoC from Rockchip.
> 
> The GeekBox is a TV box from GeekBuying, based on an MXM3 module.
> The module can be used with base boards such as the GeekBox Landingship.
> 
> This adds basic support to chain-load U-Boot from Rockchip's miniloader.
> 
>   $ ./lollipop_u-boot/tools/loaderimage --pack u-boot.bin u-boot.img
>   # ./utils/upgrade_tool di uboot u-boot.img
> 
> Implemented is the serial console, but no boot media drivers yet.
> 
> Note that flashing the resulting U-Boot will not allow you to enter the
> rockusb mode any more via "Update" button. Instead, you will need to
> short two pins on the bottom of the module to enter MaskRom mode and
> re-flash the loader:
> 
>   # ./utils/upgrade_tool ul ./lollipop_u-boot/RK3368MiniLoaderAll_V2.40.bin
>   # ./utils/upgrade_tool di uboot u-boot.img
> 
> Signed-off-by: Andreas Färber 
> ---
>  arch/arm/Kconfig   |  4 ---
>  arch/arm/dts/rk3368.dtsi   |  1 +
>  arch/arm/mach-rockchip/Kconfig | 14 ++
>  arch/arm/mach-rockchip/Makefile|  1 +
>  arch/arm/mach-rockchip/rk3368/Kconfig  | 14 ++
>  arch/arm/mach-rockchip/rk3368/Makefile |  7 +
>  arch/arm/mach-rockchip/rk3368/rk3368.c | 28 
>  board/geekbuying/geekbox/Kconfig   | 15 +++
>  board/geekbuying/geekbox/Makefile  |  7 +
>  board/geekbuying/geekbox/geekbox.c | 26 +++
>  configs/geekbox_defconfig  | 20 +++
>  include/configs/geekbox.h  | 19 ++
>  include/configs/rk3368_common.h| 47
> ++ 13 files changed, 199 insertions(+), 4
> deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk3368/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3368/Makefile
>  create mode 100644 arch/arm/mach-rockchip/rk3368/rk3368.c
>  create mode 100644 board/geekbuying/geekbox/Kconfig
>  create mode 100644 board/geekbuying/geekbox/Makefile
>  create mode 100644 board/geekbuying/geekbox/geekbox.c
>  create mode 100644 configs/geekbox_defconfig
>  create mode 100644 include/configs/geekbox.h
>  create mode 100644 include/configs/rk3368_common.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f9fddad..4ff1a26 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -838,14 +838,10 @@ config STM32
> 
>  config ARCH_ROCKCHIP
>   bool "Support Rockchip SoCs"
> - select SUPPORT_SPL
> - select SPL
>   select OF_CONTROL
>   select BLK
>   select DM
> - select SPL_DM
>   select SYS_MALLOC_F
> - select SPL_SYS_MALLOC_SIMPLE
>   select DM_GPIO
>   select DM_I2C
>   select DM_MMC
[...]
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 86b77f8..597f043 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -3,6 +3,10 @@ if ARCH_ROCKCHIP
>  config ROCKCHIP_RK3288
>   bool "Support Rockchip RK3288"
>   select CPU_V7
> + select SUPPORT_SPL
> + select SPL
> + select SPL_DM
> + select SPL_SYS_MALLOC_SIMPLE
>   help
> The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17
> including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
> @@ -13,12 +17,21 @@ config ROCKCHIP_RK3288
>  config ROCKCHIP_RK3036
>   bool "Support Rockchip RK3036"
>   select CPU_V7
> + select SUPPORT_SPL
> + select SPL
> + select SPL_DM
> + select SPL_SYS_MALLOC_SIMPLE
>   help
> The Rockchip RK3036 is a ARM-based SoC with a dual-core Cortex-A7
> including NEON and GPU, Mali-400 graphics, several DDR3 options
> and video codec support. Peripherals include Gigabit Ethernet,
> USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.

looks like both you and Kever need that separation of the SPL symbols (me as 
well for the rk3188 for the time being), so it might make sense to split that 
out into a separate patch, all could use.

I guess it might also make it easier for Simon to find an order to apply the 
patches?


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/9] rockchip: rk3188: Add pinctrl driver

[Heiko Stübner]

Hi Simon,

Am Sonntag, 17. Juli 2016, 08:13:51 schrieb Simon Glass:
> On 15 July 2016 at 16:17, Heiko Stuebner  wrote:
> > Add a driver which supports pin multiplexing setup for the most commonly
> > used peripherals.
> > 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  drivers/pinctrl/Kconfig   |   9 +
> >  drivers/pinctrl/rockchip/Makefile |   1 +
> >  drivers/pinctrl/rockchip/pinctrl_rk3188.c | 614
> >  ++ 3 files changed, 624 insertions(+)
> >  create mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3188.c
> 
> Acked-by: Simon Glass 
> 
> But is it possible to use some common code with the rk3288 driver?
> Things like rk3288_pinctrl_set_pins()?

I don't really think that will fly.

The iomux area always sees a lot of creativity when the GRF gets designed.

For example on the rk3288 you have gpio0 iomux + pull + etc in the pmu and all 
other banks in the grf. On the rk3188 the iomux is contained completely in the 
grf but the pull setting of the first _12_ pins are living in the pmu - and 
even their ordering is inverted - see the whole if(flags) part in the rk3188 
pinctrl driver.

The rk3399 introduces even more funny things. So I don't see where we would 
save without adding all the indirection the linux driver currently has.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 9/9] rockchip: rk3188: Add clock driver

[Heiko Stübner]

Am Sonntag, 17. Juli 2016, 08:13:58 schrieb Simon Glass:
> Hi Heiko,
> 
> On 15 July 2016 at 16:17, Heiko Stuebner  wrote:
> > Add a driver for setting up and modifying the various PLLs and peripheral
> > clocks on the RK3188.
> > 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  arch/arm/include/asm/arch-rockchip/cru_rk3188.h | 186 ++
> >  drivers/clk/Makefile|   1 +
> >  drivers/clk/clk_rk3188.c| 464
> >   3 files changed, 651 insertions(+)
> >  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3188.h
> >  create mode 100644 drivers/clk/clk_rk3188.c
> 
> Could you add a patch to move these files into a drivers/clk/rockchip
> directory?

ok

> > new file mode 100644
> > index 000..4c28393
> > --- /dev/null
> > +++ b/drivers/clk/clk_rk3188.c
> > @@ -0,0 +1,465 @@
> > +/*
> > + * (C) Copyright 2015 Google, Inc
> > + * (C) Copyright 2016 Heiko Stuebner 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +struct rk3188_clk_priv {
> > +   struct rk3188_grf *grf;
> > +   struct rk3188_cru *cru;
> > +   ulong rate;
> > +   bool has_bwadj;
> > +};
> > +
> > +struct pll_div {
> > +   u32 nr;
> > +   u32 nf;
> > +   u32 no;
> > +};
> > +
> > +enum {
> > +   VCO_MAX_HZ  = 2200U * 100,
> > +   VCO_MIN_HZ  = 440 * 100,
> > +   OUTPUT_MAX_HZ   = 2200U * 100,
> > +   OUTPUT_MIN_HZ   = 30 * 100,
> > +   FREF_MAX_HZ = 2200U * 100,
> > +   FREF_MIN_HZ = 30 * 1000,
> > +};
> > +
> > +enum {
> > +   /* PLL CON0 */
> > +   PLL_OD_MASK = 0x0f,
> > +
> > +   /* PLL CON1 */
> > +   PLL_NF_MASK = 0x1fff,
> > +
> > +   /* PLL CON2 */
> > +   PLL_BWADJ_MASK  = 0x0fff,
> > +
> > +   /* PLL CON3 */
> > +   PLL_RESET_SHIFT = 5,
> > +
> > +   /* GRF_SOC_STATUS0 */
> > +   SOCSTS_DPLL_LOCK= 1 << 5,
> > +   SOCSTS_APLL_LOCK= 1 << 6,
> > +   SOCSTS_CPLL_LOCK= 1 << 7,
> > +   SOCSTS_GPLL_LOCK= 1 << 8,
> > +};
> > +
> > +#define RATE_TO_DIV(input_rate, output_rate) \
> > +   ((input_rate) / (output_rate) - 1);
> > +
> > +#define DIV_TO_RATE(input_rate, div)   ((input_rate) / ((div) + 1))
> > +
> > +#define PLL_DIVISORS(hz, _nr, _no) {\
> > +   .nr = _nr, .nf = (u32)((u64)hz * _nr * _no / OSC_HZ), .no = _no};\
> > +   _Static_assert(((u64)hz * _nr * _no / OSC_HZ) * OSC_HZ /\
> > +  (_nr * _no) == hz, #hz "Hz cannot be hit with PLL
> > "\
> > +  "divisors on line " __stringify(__LINE__));
> > +
> > +/* Keep divisors as low as possible to reduce jitter and power usage */
> > +static const struct pll_div apll_init_cfg = PLL_DIVISORS(APLL_HZ, 1, 1);
> > +static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2);
> > +static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2);
> > +
> > +void *rockchip_get_cru(void)
> > +{
> > +   struct rk3188_clk_priv *priv;
> > +   struct udevice *dev;
> > +   int ret;
> > +
> > +   ret = uclass_get_device_by_name(UCLASS_CLK,
> > +   "clock-controller@2000",
> > );
> 
> This seems odd. Could you use uclass_get_device(UCLASS_CLK, 0, .) ?

Index 0 actually gets me the 24MHz oscillator fixed clock :-), which is why I 
switched to the by-name variant to not depend on some dts or uclass ordering.
I'm wondering how that works on the other socs.

> 
> > +   if (ret)
> > +   return ERR_PTR(ret);
> > +
> > +   priv = dev_get_priv(dev);
> > +
> > +   return priv->cru;
> > +}
> > +
> > +static int rkclk_set_pll(struct rk3188_cru *cru, enum rk_clk_id clk_id,
> > +const struct pll_div *div, bool has_bwadj)
> > +{
> > +   int pll_id = rk_pll_id(clk_id);
> > +   struct rk3188_pll *pll = >pll[pll_id];
> > +   /* All PLLs have same VCO and output frequency range restrictions.
> > */ +   uint vco_hz = OSC_HZ / 1000 * div->nf / div->nr * 1000;
> > +   uint output_hz = vco_hz / div->no;
> > +
> > +   debug("PLL at %x: nf=%d, nr=%d, no=%d, vco=%u Hz, output=%u Hz\n",
> > + (uint)pll, div->nf, div->nr, div->no, vco_hz, output_hz);
> > +   assert(vco_hz >= VCO_MIN_HZ && vco_hz <= VCO_MAX_HZ &&
> > +  output_hz >= OUTPUT_MIN_HZ && output_hz <= OUTPUT_MAX_HZ &&
> > +  (div->no == 1 || !(div->no % 2)));
> > +
> > +   /* enter reset */
> > +   rk_setreg(>con3, 1 << PLL_RESET_SHIFT);
> > +
> > +   rk_clrsetreg(>con0,
> > +CLKR_MASK << 

Re: [U-Boot] [PATCH 0/9] rockchip: cosmetics, a fix and first steps on the rk3188

[Heiko Stübner]

Am Sonntag, 17. Juli 2016, 08:14:06 schrieb Simon Glass:
> Hi Heiko,
> 
> On 15 July 2016 at 16:17, Heiko Stuebner  wrote:
> > I've made some nice progress on using mainline uboot on the rk3188
> > and would like to dump some first results.
> > 
> > Right now I can use uboot on the rk3188 with the Rockchip binary ddr init,
> > similar to what barebox does and can even netboot a kernel image using
> > a usb ethernet adapter [0] .
> > 
> > While working on this I found quite some cosmetic stuff that shouldn't
> > persist to make extending easier. So while I don't know what the policy
> > is for my standalone pinctrl and clock drivers (without the actual board)
> > at least the cosmetics + fix might get in at least.
> 
> Nice work!
> 
> It would be best to add the drivers with the board - otherwise they
> are just dead code. How far away is it?

The big issue is the SPL. Right now I'm using Rockchip's ddr-init as spl-
replacement, and I'd say this second part is nearly ready - only minor 
cleanups.

The memory-setup is supposed to be very much similar to the rk3288 (same 
dw_upctl and ddr-phy), but it looks like the very first steps are somewhat 
different and I haven't been able to make the spl output anything on the 
serial console yet ... which could stem from some difference in what the soc 
expects or just some dumb mistake on my part :-)


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/5] add support for rk3399 soc and evb

[Heiko Stübner]

Hi Kever,

Am Freitag, 15. Juli 2016, 16:42:08 schrieb Kever Yang:
> This patchset add support for rk3399 with ATF based on
> Rockchip miniloader as secondary bootloader instead of
> u-boot SPL.
> 
> Rockchip miniloader init the DRAM and load the ATF and
> u-boot to runing address, and then jump to ATF, ATM
> do some init and switch to EL2/EL1 mode before jump to
> next loader which is u-boot here.
> 
> Pls reference board/rockchip/evb_rk3399/README to setup
> the board.
> 
> Will migrate to SPL once its ready for ATF.
> 
> This patch set is based on below patch:
> "board: move all the rockchip board in one folder"
> 
> This patch set has been test on rk3399 evb board.

just for my own little board-farm, for the rk3368 the bringup should be 
similar, right?


> Changes in v3:
> Rebase on patch from Andreas:
> [PATCH] rockchip: Exclude rk_timer for ARM64
> [PATCH] rockchip: Clean up CPU selection
> 
> Changes in v2:
> fix description error on board Kconfig
> fix a binary path error
> 
> Kever Yang (5):
>   dts: add support for rkchichip rk3399 soc
>   ARM64: rockchip: add support for rk3399 SoC based evb-board
>   config: add config file for evb-rk3399
>   mmc: rockchip: add SDHCI driver support for rockchip soc
>   ARM64: evb-rk3399: add a README for this board setup

somehow this last patch never makes it to the lists in all 3 versions till 
now.


Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mips: fix DTC unit warnings

[Heiko Stübner]

Am Freitag, 15. April 2016, 12:30:58 schrieb Tom Rini:
> On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> > Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> > > Fix following warnings for all mips based boards:
> > >  mips:  +   pic32mzdask
> > > 
> > > +Warning (unit_address_vs_reg): Node /memory has a reg or ranges
> > > property, but no unit name +Warning (unit_address_vs_reg): Node
> > > /cpus/cpu@0 has a unit name, but no reg property
> > > 
> > > Signed-off-by: Heiko Schocher 
> > > ---
> > > This warnings pop up with the DTC compiler:
> > > $ /tmp/dtc/dtc -v
> > > Version: DTC 1.4.1-gbeef80b8
> > > 
> > > This fixes the compile warnings for:
> > > https://travis-ci.org/hsdenx/u-boot/jobs/123254184
> > > 
> > > see:
> > > https://travis-ci.org/hsdenx/u-boot/jobs/123281033
> > > 
> > >  arch/mips/dts/pic32mzda.dtsi | 2 +-
> > >  arch/mips/dts/skeleton.dtsi  | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> > > index 8a554f9..791c364 100644
> > > --- a/arch/mips/dts/pic32mzda.dtsi
> > > +++ b/arch/mips/dts/pic32mzda.dtsi
> > > @@ -27,7 +27,7 @@
> > > 
> > >   };
> > >   
> > >   cpus {
> > > 
> > > - cpu@0 {
> > > + cpu {
> > > 
> > >   compatible = "mips,mips14kc";
> > >   
> > >   };
> > >   
> > >   };
> > > 
> > > diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> > > index 24ee6c3..643996c 100644
> > > --- a/arch/mips/dts/skeleton.dtsi
> > > +++ b/arch/mips/dts/skeleton.dtsi
> > > @@ -16,7 +16,7 @@
> > > 
> > >   aliases {
> > >   };
> > > 
> > > - memory {
> > > + memory@0 {
> > 
> > I have just been told on linux-rockchip mailing list that such a change
> > should not be done as /memory is being special-cased in dtc warnings for
> > the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> > size on /memory@0.
> > 
> > If that is untrue, please someone object on the Linux mailing lists.
> 
> Uh, what?  From dtc:
> 
> commit c9d9121683b35281239305e15adddfff2b462cf9
> Author: Stephen Warren 
> Date:   Fri Feb 19 15:59:29 2016 +1100
> 
> Warn on node name unit-address presence/absence mismatch
> 
> ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> node that has a reg property must include a unit address in its name
> with value matching the first entry in its reg property. Conversely, if
> a node does not have a reg property, the node name must not include a
> unit address. Also allow ranges property as it is deemed valid, but
> ePAPR is not clear about it.
> 
> Implement a check for this. The code doesn't validate the format of the
> unit address; ePAPR implies this may vary from (containing bus) binding
> to binding, so doing so would be much more complex.
> 
> Signed-off-by: Stephen Warren 
> [robh: also allow non-empty ranges]
> Signed-off-by: Rob Herring 
> [moved new test in check_table]
> Signed-off-by: David Gibson 
> 
> That's where that warning comes from.

and that is supposed to get a special case for memory. On the kernel variant 
of dtc the change got deactivated again and will only trigger the warnings 
with a special command currently.

Also in another thread [0] on the arm-kernel-list Rob Herring explicitly 
stated:

>> This has come up before and been beaten to death. Bottom line is plain
>> "memory" is allowed, and I plan to add that exception to dtc."

And as stated there as well, memory@0 is not correct in all cases, as it would 
need to be memory@baseaddress, so for example on Rockchip
- memory@0 for the rk3288
- memory@6000 for rk3188 and other A9s

So it's definitly not suitable for a general node in that skeleton,dtsi


Heiko

[0] http://www.spinics.net/lists/arm-kernel/msg494038.html

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot