Re: [U-Boot] [PATCH] cmd: part: use MAX_SEARCH_PARTITIONS for part search

[Dr. Philipp Tomsich]

> On 7 Sep 2018, at 11:37, Kever Yang  wrote:
> 
> Use Macro instead of hard code.

Nitpick: mentioning where the macro is defined (and if it was recently 
introduced,
what commit this references) would be helpful in a cursory review.  I just ran a
'git grep’ instead ;-)

> Signed-off-by: Kever Yang 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [U-Boot, 1/8] rockchip: add STIMER_BASE for Rockchip SoCs

[Dr . Philipp Tomsich]

Kever,

[Sorry for the delay, I am switching laptops and this got stuck in my Drafts 
folder
on the old machine — which I noticed only today]

> On 3 Sep 2018, at 05:21, Kever Yang  wrote:
> 
> Hi Philipp,
> 
> 
> On 08/30/2018 05:11 PM, Philipp Tomsich wrote:
>> 
>> 
>> On Wed, 18 Apr 2018, Kever Yang wrote:
>> 
>>> Most of Rockchip SoCs have ARM arch/generic timer whose clock source
>>> is from one of secure timer(if the soc supports Trust environment).
>>> 
>>> STIMER can only access in secure mode, so it should be init before
>>> the proper U-Boot(usually in non-secure mode).
>>> Add a MACRO for timer base addr so that we can init with a common
>>> function in SPL/TPL.
>>> 
>>> Signed-off-by: Kever Yang 
>> 
>> See below for required changes.
>> 
>>> ---
>>> 
>>> arch/arm/mach-rockchip/Kconfig | 16 
>>> 1 file changed, 16 insertions(+)
>>> 
>>> diff --git a/arch/arm/mach-rockchip/Kconfig
>>> b/arch/arm/mach-rockchip/Kconfig
>>> index 0adaed4..55d3d5c 100644
>>> --- a/arch/arm/mach-rockchip/Kconfig
>>> +++ b/arch/arm/mach-rockchip/Kconfig
>>> @@ -191,6 +191,22 @@ config ROCKCHIP_BOOT_MODE_REG
>>>   The Soc will enter to different boot mode(defined in
>>> asm/arch/boot_mode.h)
>>>   according to the value from this register.
>>> 
>>> +config ROCKCHIP_STIMER_BASE
>>> +hex "Rockchip Secure timer base address"
>>> +default 0x200440a0 if ROCKCHIP_RK3036
>>> +default 0x20018020 if ROCKCHIP_RK3126
>>> +default 0x200440a0 if ROCKCHIP_RK3128
>>> +default 0x110d0020 if ROCKCHIP_RK322X
>>> +default 0xff810020 if ROCKCHIP_RK3288
>>> +default 0xff1d0020 if ROCKCHIP_RK3328
>>> +default 0xff830020 if ROCKCHIP_RK3368
>>> +default 0xff8680a0 if ROCKCHIP_RK3399
>>> +default 0x10350020 if ROCKCHIP_RV1108
>>> +default 0
>>> +help
>>> +  The secure timer inited in SPL/TPL in secure word, ARM generic
>>> timer
>>> +  works after this timer work.
>> 
>> NAK.
>> This is not a user-configurable/selectable option, but rather a
>> function of the chip used.
>> This belongs into a header file in arch/arm/include/asm/arch-rockchip.
> 
> Yes, you are correct in one way, but I think if this goes to header
> file, it will separate in different
> header file for different SoCs, or with a lot if MACRO like "#if
> defined(CONFIG_ROCKCHIP_RK3288) #elif"
> in one header file.

I don’t care whether we make this different files (my preferred choice in
the long run … i.e. after we clean up the header-file directory) or put it
into single file: at the moment both variants are common in our 
asm/arch-rockchip directory …

> Make ROCKCHIP_STIMER_BASE in Kconfig and use like ROCKCHIP_BOOT_MODE_REG
> seems like a better idea to make things simple.
> 
> Actually there are many other configs like this:
> - DEBUG_UART_BASE

This is an excellent example and really needs to go into Kconfig, as the
UART selection is done via this (e.g. we use a different DEBUG_UART
on the RK3399-Q7 than on Rockchip’s reference design) and it’s not
something the chip designs but rather a selection from a list encoded as
an address.

> - IRAM_START
> - DRAM_START
> 
> One more consideration is, I don't think make SoC configs into too much
> place is a good idea,
> now we have 3 places for configs:
> - Kconfig default value
> - configs/soc_defconfig
> - include/configs/soc_header.h (this is moving to Kconfig one by one now)
> 
> so I would not like to move it into arch/arm/include/asm/arch-rockchip,
> if you insist this should go to header file instead of Kconfig, I would
> prefer
> to use header file in 'include/configs/' folder, how do you think?

All of this should eventually go into asm/arch-rockchip, unless it’s a
an board-specific overrride/configuration item (include/configs was historically
meant for boards and not for SOCs). I believe that include/configs/ will
eventually be almost completely replaced by Kconfig entries and that
any SOC-related things will need to go into asm/arch-rockchip.

If you could put it into asm/arch-rockchip, I’d prefer this.
However, if you want to have it in include/configs, I won’t delay the series
because of it and we’ll deal with the clean-up when the time comes.

Thanks,
Philipp.

> 
> Thanks,
> - Kever
>> 
>>> +
>>> config ROCKCHIP_SPL_RESERVE_IRAM
>>> hex "Size of IRAM reserved in SPL"
>>> default 0

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

Re: [U-Boot] [PATCH] rockchip: add TPL_TINY_FRAMEWORK support

[Dr. Philipp Tomsich]

> On 28 Aug 2018, at 11:23, Kever Yang  wrote:
> 
> Rockchip BootRom support load firmware from storage media twice,
> one for ddr sdram init code into sram and another time to load
> firmware into DDR. For ddr sdram init code(which is TPL in U-Boot
> project), it's OK to re-use the stack and vector table. In order
> to get more available sram space, we need to skip all the init code
> from U-Boot project including start.S, reset.S and framework.
> 
> Signed-off-by: Kever Yang 

Reviewed-by: Philipp Tomsich 

See below for a few recommended changes, a question and one required change.

> ---
> 
> arch/arm/cpu/armv7/start.S |   2 +
> arch/arm/cpu/armv8/start.S |   2 +
> arch/arm/include/asm/arch-rockchip/boot0.h |  10 ++
> arch/arm/mach-rockchip/Kconfig |  12 +++
> arch/arm/mach-rockchip/Makefile|   2 +
> arch/arm/mach-rockchip/tiny_tpl.c  | 106 +
> 6 files changed, 134 insertions(+)
> create mode 100644 arch/arm/mach-rockchip/tiny_tpl.c
> 
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 81edec01bf..548d9ff23a 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -38,7 +38,9 @@
> reset:
>   /* Allow the board to save important registers */
>   b   save_boot_params
> +#if !CONFIG_IS_ENABLED(TINY_FRAMEWORK)
> save_boot_params_ret:
> +#endif

Having the label here will not increase code-size, so there’s no point in
making this conditional.

> #ifdef CONFIG_ARMV7_LPAE
> /*
>  * check for Hypervisor support
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index d4db4d044f..e0f8fad10c 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -31,6 +31,7 @@ _start:
>   b   reset
> #endif
> 
> +#if !CONFIG_IS_ENABLED(TINY_FRAMEWORK)
>   .align 3
> 
> .globl_TEXT_BASE
> @@ -361,3 +362,4 @@ ENDPROC(c_runtime_cpu_setup)
> WEAK(save_boot_params)
>   b   save_boot_params_ret/* back to my caller */
> ENDPROC(save_boot_params)
> +#endif
> diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
> b/arch/arm/include/asm/arch-rockchip/boot0.h
> index 9ea4708ada..7f00494513 100644
> --- a/arch/arm/include/asm/arch-rockchip/boot0.h
> +++ b/arch/arm/include/asm/arch-rockchip/boot0.h
> @@ -41,8 +41,18 @@ entry_counter:
> 
> #if (defined(CONFIG_SPL_BUILD) || defined(CONFIG_ARM64))
>   /* U-Boot proper of armv7 do not need this */
> +#if CONFIG_IS_ENABLED(TINY_FRAMEWORK)
> + /* Allow the board to save important registers */
> + b save_boot_params
> +.globl   save_boot_params_ret
> +.type   save_boot_params_ret, %function
> +
> +save_boot_params_ret:
> + b board_init_f
> +#else
>   b reset
> #endif
> +#endif

I don’t like these nested #if primitives.
Is there a way to do this without nesting?
E.g. 

#if CONFIG_IS_ENABLED(TINY_FRAMEWORK)
b reset
#elif …
original code
#endif

> 
> #if !defined(CONFIG_ARM64)
>   /*
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 187aa14184..be23bcc37e 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -306,6 +306,18 @@ config TPL_ROCKCHIP_EARLYRETURN_TO_BROM
> config SPL_MMC_SUPPORT
>   default y if !SPL_ROCKCHIP_BACK_TO_BROM
> 
> +config TPL_TINY_FRAMEWORK
> + bool "Tiny TPL for DDR init"
> + depends on TPL && !TPL_FRAMEWORK
> + default y
> + help
> +   Rockchip BootRom support load firmware from storage media twice,
> +   one for ddr sdram init code into sram and another time to load
> +   firmware into DDR. For ddr sdram init code(which is TPL in U-Boot
> +   project), it's OK to re-use the stack and vector table. In order
> +   to get more available sram space, we need to skip all the init code
> +   from U-Boot project including start.S, reset.S and framework.
> +
> source "arch/arm/mach-rockchip/rk3036/Kconfig"
> source "arch/arm/mach-rockchip/rk3128/Kconfig"
> source "arch/arm/mach-rockchip/rk3188/Kconfig"
> diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
> index 83afdac99d..c88700f10d 100644
> --- a/arch/arm/mach-rockchip/Makefile
> +++ b/arch/arm/mach-rockchip/Makefile
> @@ -9,6 +9,8 @@
> obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
> 
> +obj-tpl-$(CONFIG_TPL_TINY_FRAMEWORK) += tiny_tpl.o
> +
> obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o
> obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
> obj-tpl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-tpl.o
> diff --git a/arch/arm/mach-rockchip/tiny_tpl.c 
> b/arch/arm/mach-rockchip/tiny_tpl.c
> new file mode 100644
> index 00..47f15c0af1
> --- /dev/null
> +++ b/arch/arm/mach-rockchip/tiny_tpl.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2018 Rockchip Electronics Co., Ltd
> + */
> +
> +#include 
> 

Re: [U-Boot] [U-Boot, 01/10] rockchip: enable DEBUG_UART_BOARD_INIT by default

[Dr. Philipp Tomsich]

Kever,

Could you rebase this series to u-boot-rockchip/next and resubmit?
I’d like to avoid any issues from manually fixing up git-am issues (as I 
happened to introduce on last set of UART changes).

Thanks,
Philipp.

> On 29 Aug 2018, at 20:33, Philipp Tomsich 
>  wrote:
> 
>> All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board
>> UART IOMUX, enable it by default.
>> 
>> Signed-off-by: Kever Yang 
>> ---
>> 
>> arch/arm/Kconfig   | 2 ++
>> arch/arm/mach-rockchip/Kconfig | 3 ---
>> 2 files changed, 2 insertions(+), 3 deletions(-)
>> 
> 
> Reviewed-by: Philipp Tomsich 
> ___
> 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] rockchip: dts: fix unnecessary '-cells' warning

[Dr. Philipp Tomsich]

> On 28 Aug 2018, at 11:57, Kever Yang  wrote:
> 
> Fix warning below:
> unnecessary #address-cells/#size-cells without "ranges" or child "reg"
> property
> 
> Signed-off-by: Kever Yang 

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

Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state

[Dr. Philipp Tomsich]

> On 24 Aug 2018, at 17:54, Andreas Dannenberg  wrote:
> 
> Philipp,
> 
> On Fri, Aug 24, 2018 at 04:42:15PM +0200, Dr. Philipp Tomsich wrote:
>> +Kever
>> 
>>> On 24 Aug 2018, at 16:12, Tom Rini  wrote:
>>> 
>>> On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
>>> 
>>>> From: Andreas Dannenberg 
>>>> 
>>>> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
>>>> which introduced the functionality for setting clock defaults such as
>>>> rates and parents will skip the processing when executing in a re-reloc
>>>> state. This for example can prevent the assigning of clock parents
>>>> when running in SPL code. Go ahead and remove this limitation.
>>>> 
>>>> Signed-off-by: Andreas Dannenberg 
>>>> Signed-off-by: Lokesh Vutla 
>>>> ---
>>>> drivers/clk/clk-uclass.c | 4 
>>>> 1 file changed, 4 deletions(-)
>>>> 
>>>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>>>> index 2b15978e14..04b369aa5a 100644
>>>> --- a/drivers/clk/clk-uclass.c
>>>> +++ b/drivers/clk/clk-uclass.c
>>>> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
>>>> {
>>>>int ret;
>>>> 
>>>> -  /* If this is running pre-reloc state, don't take any action. */
>>>> -  if (!(gd->flags & GD_FLG_RELOC))
>>>> -  return 0;
>>>> -
>>>>debug("%s(%s)\n", __func__, dev_read_name(dev));
>>>> 
>>>>ret = clk_set_default_parents(dev);
>>> 
>>> Philipp? David?  Comments?  Thanks!
>> 
>> If I remember correctly, David had a concern regarding an increase in
>> boottime if we ran this twice… adding Kever, as he was also involved
>> in the discussion.
>> 
>> I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
>> boottime increase comes from the fact that some devices have a large
>> number of assigned-clocks, that the device-tree processing has a cost,
>> and that we don’t have a way of synchronising between SPL and full
>> U-Boot to avoid redoing the complete init-flow.
> 
> Good to know some of the background; when I did this patch initially it
> was not really clear why this was removed and it obviously was an issue
> for what I was doing that I had to overcome and re-adding this was the
> simpliest thing to do at that time.
> 
>> Maybe we should have a SPL-specific property for the assigned-clocks
>> to be set pre-reloc?
> 
> Need to think about this some more. Generally we probably want to do as
> little as possible before relocation. Unfortunately for the K3 family of
> SoCs much is dependent on loading/installing the system firmware (SYSFW)
> image including to get DDR operational which itself requires us to use a
> lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg
> problem…

If you need someone to throw your thoughts at, feel free to share them with
me.  With the newer Rockchip devices that I am focused on, we also do a lot
DT/DM stuff pre-reloc (I have a 100+KB SPL stage on the RK3399 at the 
moment) and this trend is likely to increase … e.g. I may split the RK3399
to use TPL for DRAM-init and will then have the SPL stage running from
DRAM which will remove the last remaining size constraints.

--Philipp.

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

Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state

[Dr. Philipp Tomsich]

+Kever

> On 24 Aug 2018, at 16:12, Tom Rini  wrote:
> 
> On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
> 
>> From: Andreas Dannenberg 
>> 
>> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
>> which introduced the functionality for setting clock defaults such as
>> rates and parents will skip the processing when executing in a re-reloc
>> state. This for example can prevent the assigning of clock parents
>> when running in SPL code. Go ahead and remove this limitation.
>> 
>> Signed-off-by: Andreas Dannenberg 
>> Signed-off-by: Lokesh Vutla 
>> ---
>> drivers/clk/clk-uclass.c | 4 
>> 1 file changed, 4 deletions(-)
>> 
>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>> index 2b15978e14..04b369aa5a 100644
>> --- a/drivers/clk/clk-uclass.c
>> +++ b/drivers/clk/clk-uclass.c
>> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
>> {
>>  int ret;
>> 
>> -/* If this is running pre-reloc state, don't take any action. */
>> -if (!(gd->flags & GD_FLG_RELOC))
>> -return 0;
>> -
>>  debug("%s(%s)\n", __func__, dev_read_name(dev));
>> 
>>  ret = clk_set_default_parents(dev);
> 
> Philipp? David?  Comments?  Thanks!

If I remember correctly, David had a concern regarding an increase in
boottime if we ran this twice… adding Kever, as he was also involved
in the discussion.

I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
boottime increase comes from the fact that some devices have a large
number of assigned-clocks, that the device-tree processing has a cost,
and that we don’t have a way of synchronising between SPL and full
U-Boot to avoid redoing the complete init-flow.

Maybe we should have a SPL-specific property for the assigned-clocks
to be set pre-reloc?

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

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

Re: [U-Boot] [PATCH 3/3] bootcount: add DM-based backing store for bootcount

[Dr. Philipp Tomsich]

Simon,

> On 23 Aug 2018, at 12:45, Simon Glass  wrote:
> 
> Hi Philipp,
> 
> On 17 August 2018 at 06:56, Dr. Philipp Tomsich
>  wrote:
>> Simon,
>> 
>> On 17 Aug 2018, at 14:49, Simon Glass  wrote:
>> 
>> Hi Philipp,
>> 
>> On 14 August 2018 at 05:39, Dr. Philipp Tomsich
>>  wrote:
>> 
>> Lukasz,
>> 
>> On 14 Aug 2018, at 13:10, Lukasz Majewski  wrote:
>> 
>> Hi Philipp,
>> 
>> The original bootcount methods do not provide an interface to DM and
>> rely on a static configuration for I2C devices (e.g. bus, chip-addr,
>> etc. are configured through defines statically).  On a modern system
>> that exposes multiple devices in a DTS-configurable way, this is less
>> than optimal and a interface to DM-based devices will be desirable.
>> 
>> This adds a simple driver that is DM-aware and configurable via DTS:
>> the /chosen/u-boot,bootcount-device property is used to detect the DM
>> device storing the bootcount and deviceclass-specific commands are
>> used to read/write the bootcount.
>> 
>> Initially, this provides support for the following DM devices:
>> * RTC devices implementing the read8/write8 ops
>> 
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>> ---
>> 
>> doc/device-tree-bindings/chosen.txt | 27 +++
>> drivers/bootcount/Kconfig   | 12 +
>> drivers/bootcount/Makefile  |  1 +
>> drivers/bootcount/bootcount_dm.c| 93
>> + 4 files changed, 133
>> insertions(+) create mode 100644 drivers/bootcount/bootcount_dm.c
>> 
>> diff --git a/doc/device-tree-bindings/chosen.txt
>> b/doc/device-tree-bindings/chosen.txt index da7b4e6..734fd15 100644
>> --- a/doc/device-tree-bindings/chosen.txt
>> +++ b/doc/device-tree-bindings/chosen.txt
>> @@ -42,6 +42,33 @@ Example
>>};
>> };
>> 
>> +u-boot,bootcount-device property
>> +
>> +In a DM-based system, the bootcount may be stored in a device known
>> to +the DM framework (e.g. in a battery-backed SRAM area within a RTC
>> +device).  To identify the device to be used for the bootcount, the
>> +u-boot,bootcount-device property needs to point to the target device.
>> +
>> +Further configuration in the target device's node may be required
>> +(e.g. an offset into an I2C RTC's address space), depending on the
>> +UCLASS of the target device.
>> +
>> +Example
>> +---
>> +/ {
>> +chosen {
>> +u-boot,bootcount-device = 
>> +};
>> +
>> +i2c2 {
>> +rv3029: rtc@56 {
>> +compatible = "mc,rv3029";
>> +reg = <0x56>;
>> +u-boot,bootcount-offset = <0x38>;
>> +};
>> +};
>> +};
>> +
>> u-boot,spl-boot-order property
>> --
>> 
>> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
>> index d335ed1..cdde7b5 100644
>> --- a/drivers/bootcount/Kconfig
>> +++ b/drivers/bootcount/Kconfig
>> @@ -70,6 +70,18 @@ config BOOTCOUNT_AT91
>>bool "Boot counter for Atmel AT91SAM9XE"
>>depends on AT91SAM9XE
>> 
>> +config BOOTCOUNT_DM
>> +bool "Boot counter in a device-model device"
>> +help
>> +  Enables reading/writing the bootcount in a device-model
>> +  device referenced from the /chosen node.  The type of the
>> +  device is detected from DM and any additional configuration
>> +  information (e.g. the offset into a RTC device that
>> supports
>> +  read32/write32) is read from the device's node.
>> +
>> +  At this time the following DM device classes are supported:
>> +   * RTC (using read32/write32)
>> +
>> endchoice
>> 
>> config BOOTCOUNT_ALEN
>> diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
>> index 68bc006..e8ed729 100644
>> --- a/drivers/bootcount/Makefile
>> +++ b/drivers/bootcount/Makefile
>> @@ -7,3 +7,4 @@ obj-$(CONFIG_BOOTCOUNT_RAM)  += bootcount_ram.o
>> obj-$(CONFIG_BOOTCOUNT_ENV)  += bootcount_env.o
>> obj-$(CONFIG_BOOTCOUNT_I2C)  += bootcount_i2c.o
>> obj-$(CONFIG_BOOTCOUNT_EXT)  += bootcount_ext.o
>> +obj-$(CONFIG_BOOTCOUNT_DM)  += bootcount_dm.o
>> diff --git a/drivers/bootcount/bootcount_dm.c
>> b/drivers/bootcount/bootcount_dm.c new file mode 100644
>> 

Re: [U-Boot] [PATCH 3/3] bootcount: add DM-based backing store for bootcount

[Dr. Philipp Tomsich]

Simon,

> On 17 Aug 2018, at 14:49, Simon Glass  wrote:
> 
> Hi Philipp,
> 
> On 14 August 2018 at 05:39, Dr. Philipp Tomsich
>  <mailto:philipp.toms...@theobroma-systems.com>> wrote:
>> Lukasz,
>> 
>>> On 14 Aug 2018, at 13:10, Lukasz Majewski  wrote:
>>> 
>>> Hi Philipp,
>>> 
>>>> The original bootcount methods do not provide an interface to DM and
>>>> rely on a static configuration for I2C devices (e.g. bus, chip-addr,
>>>> etc. are configured through defines statically).  On a modern system
>>>> that exposes multiple devices in a DTS-configurable way, this is less
>>>> than optimal and a interface to DM-based devices will be desirable.
>>>> 
>>>> This adds a simple driver that is DM-aware and configurable via DTS:
>>>> the /chosen/u-boot,bootcount-device property is used to detect the DM
>>>> device storing the bootcount and deviceclass-specific commands are
>>>> used to read/write the bootcount.
>>>> 
>>>> Initially, this provides support for the following DM devices:
>>>> * RTC devices implementing the read8/write8 ops
>>>> 
>>>> Signed-off-by: Philipp Tomsich 
>>>> Tested-by: Klaus Goger 
>>>> ---
>>>> 
>>>> doc/device-tree-bindings/chosen.txt | 27 +++
>>>> drivers/bootcount/Kconfig   | 12 +
>>>> drivers/bootcount/Makefile  |  1 +
>>>> drivers/bootcount/bootcount_dm.c| 93
>>>> + 4 files changed, 133
>>>> insertions(+) create mode 100644 drivers/bootcount/bootcount_dm.c
>>>> 
>>>> diff --git a/doc/device-tree-bindings/chosen.txt
>>>> b/doc/device-tree-bindings/chosen.txt index da7b4e6..734fd15 100644
>>>> --- a/doc/device-tree-bindings/chosen.txt
>>>> +++ b/doc/device-tree-bindings/chosen.txt
>>>> @@ -42,6 +42,33 @@ Example
>>>> };
>>>> };
>>>> 
>>>> +u-boot,bootcount-device property
>>>> +
>>>> +In a DM-based system, the bootcount may be stored in a device known
>>>> to +the DM framework (e.g. in a battery-backed SRAM area within a RTC
>>>> +device).  To identify the device to be used for the bootcount, the
>>>> +u-boot,bootcount-device property needs to point to the target device.
>>>> +
>>>> +Further configuration in the target device's node may be required
>>>> +(e.g. an offset into an I2C RTC's address space), depending on the
>>>> +UCLASS of the target device.
>>>> +
>>>> +Example
>>>> +---
>>>> +/ {
>>>> +chosen {
>>>> +u-boot,bootcount-device = 
>>>> +};
>>>> +
>>>> +i2c2 {
>>>> +rv3029: rtc@56 {
>>>> +compatible = "mc,rv3029";
>>>> +reg = <0x56>;
>>>> +u-boot,bootcount-offset = <0x38>;
>>>> +};
>>>> +};
>>>> +};
>>>> +
>>>> u-boot,spl-boot-order property
>>>> --
>>>> 
>>>> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
>>>> index d335ed1..cdde7b5 100644
>>>> --- a/drivers/bootcount/Kconfig
>>>> +++ b/drivers/bootcount/Kconfig
>>>> @@ -70,6 +70,18 @@ config BOOTCOUNT_AT91
>>>> bool "Boot counter for Atmel AT91SAM9XE"
>>>> depends on AT91SAM9XE
>>>> 
>>>> +config BOOTCOUNT_DM
>>>> +bool "Boot counter in a device-model device"
>>>> +help
>>>> +  Enables reading/writing the bootcount in a device-model
>>>> +  device referenced from the /chosen node.  The type of the
>>>> +  device is detected from DM and any additional configuration
>>>> +  information (e.g. the offset into a RTC device that
>>>> supports
>>>> +  read32/write32) is read from the device's node.
>>>> +
>>>> +  At this time the following DM device classes are supported:
>>>> +   * RTC (using read32/write32)
>>>> +
>>>> endchoice
>>>> 
>>>> config BOOTCOUNT_ALEN
>>>> diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
>&

Re: [U-Boot] [PATCH v2] kconfig: fix typo 'parition'

[Dr. Philipp Tomsich]

> On 16 Aug 2018, at 09:44, Simon Goldschmidt  
> wrote:
> 
> Replaced misspelled words "parition"/"paritioning" (missing 't') in two
> Kconfig files by correct words "partition"/"partitioning"
> 
> Signed-off-by: Simon Goldschmidt 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH 1/3] rtc: rv3029: add to Kconfig

[Dr. Philipp Tomsich]

> On 14 Aug 2018, at 18:46, Heinrich Schuchardt  wrote:
> 
> On 08/14/2018 11:51 AM, Philipp Tomsich wrote:
>> The MicroCrystal RV3029 driver didn't have a Kconfig entry and was not used
>> anywhere. Add it to Kconfig to make it selectable.
>> 
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>> ---
>> 
>> drivers/rtc/Kconfig | 10 ++
>> 1 file changed, 10 insertions(+)
>> 
>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> index 5436509..8a6e796 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -42,6 +42,16 @@ config RTC_ISL1208
>>This driver supports reading and writing the RTC/calendar and detects
>>total power failures.
>> 
>> +config RTC_RV3029
>> +bool "Enable RV3029 driver"
>> +depends on DM_RTC
>> +help
>> +  The MicroCrystal RV3029 is a I2C Real Time Clock (RTC) with 8-byte
> 
> %s/a I2C/an I2C/
> 
>> +  battery-backed SRAM.
>> +
>> +  This driver supports reading and writing the RTC/calendar and the
> 
> What do you mean by calendar? If you just mean the RTC date register,
> just drop the misleading word.
> 
> %s/RTC\/calendar/RTC/

The RV3029 datasheet also describes the devices as a RTC/calendar:
"The RV-3029 is a CMOS low power, real-time clock/calendar module…”

In the same Kconfig, there’s the same duality (i.e. RTC _and_ calendar) in the
help text for the
RTC_PCF2127
RTC_ISL1208

Happy to drop this here, if that’s the consensus...

> 
>> +  battery-baced SRAM section.
> 
> %s/baced/backed/
> 
> Best regards
> 
> Heinrich
> 
>> +
>> config RTC_RX8010SJ
>>  bool "Enable RX8010SJ driver"
>>  depends on DM_RTC
>> 
> 

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

Re: [U-Boot] [PATCH 3/3] bootcount: add DM-based backing store for bootcount

[Dr. Philipp Tomsich]

Lukasz,

> On 14 Aug 2018, at 13:10, Lukasz Majewski  wrote:
> 
> Hi Philipp,
> 
>> The original bootcount methods do not provide an interface to DM and
>> rely on a static configuration for I2C devices (e.g. bus, chip-addr,
>> etc. are configured through defines statically).  On a modern system
>> that exposes multiple devices in a DTS-configurable way, this is less
>> than optimal and a interface to DM-based devices will be desirable.
>> 
>> This adds a simple driver that is DM-aware and configurable via DTS:
>> the /chosen/u-boot,bootcount-device property is used to detect the DM
>> device storing the bootcount and deviceclass-specific commands are
>> used to read/write the bootcount.
>> 
>> Initially, this provides support for the following DM devices:
>> * RTC devices implementing the read8/write8 ops
>> 
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>> ---
>> 
>> doc/device-tree-bindings/chosen.txt | 27 +++
>> drivers/bootcount/Kconfig   | 12 +
>> drivers/bootcount/Makefile  |  1 +
>> drivers/bootcount/bootcount_dm.c| 93
>> + 4 files changed, 133
>> insertions(+) create mode 100644 drivers/bootcount/bootcount_dm.c
>> 
>> diff --git a/doc/device-tree-bindings/chosen.txt
>> b/doc/device-tree-bindings/chosen.txt index da7b4e6..734fd15 100644
>> --- a/doc/device-tree-bindings/chosen.txt
>> +++ b/doc/device-tree-bindings/chosen.txt
>> @@ -42,6 +42,33 @@ Example
>>  };
>> };
>> 
>> +u-boot,bootcount-device property
>> +
>> +In a DM-based system, the bootcount may be stored in a device known
>> to +the DM framework (e.g. in a battery-backed SRAM area within a RTC
>> +device).  To identify the device to be used for the bootcount, the
>> +u-boot,bootcount-device property needs to point to the target device.
>> +
>> +Further configuration in the target device's node may be required
>> +(e.g. an offset into an I2C RTC's address space), depending on the
>> +UCLASS of the target device.
>> +
>> +Example
>> +---
>> +/ {
>> +chosen {
>> +u-boot,bootcount-device = 
>> +};
>> +
>> +i2c2 {
>> +rv3029: rtc@56 {
>> +compatible = "mc,rv3029";
>> +reg = <0x56>;
>> +u-boot,bootcount-offset = <0x38>;
>> +};
>> +};
>> +};
>> +
>> u-boot,spl-boot-order property
>> --
>> 
>> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
>> index d335ed1..cdde7b5 100644
>> --- a/drivers/bootcount/Kconfig
>> +++ b/drivers/bootcount/Kconfig
>> @@ -70,6 +70,18 @@ config BOOTCOUNT_AT91
>>  bool "Boot counter for Atmel AT91SAM9XE"
>>  depends on AT91SAM9XE
>> 
>> +config BOOTCOUNT_DM
>> +bool "Boot counter in a device-model device"
>> +help
>> +  Enables reading/writing the bootcount in a device-model
>> +  device referenced from the /chosen node.  The type of the
>> +  device is detected from DM and any additional configuration
>> +  information (e.g. the offset into a RTC device that
>> supports
>> +  read32/write32) is read from the device's node.
>> +
>> +  At this time the following DM device classes are supported:
>> +   * RTC (using read32/write32)
>> +
>> endchoice
>> 
>> config BOOTCOUNT_ALEN
>> diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
>> index 68bc006..e8ed729 100644
>> --- a/drivers/bootcount/Makefile
>> +++ b/drivers/bootcount/Makefile
>> @@ -7,3 +7,4 @@ obj-$(CONFIG_BOOTCOUNT_RAM)  += bootcount_ram.o
>> obj-$(CONFIG_BOOTCOUNT_ENV)  += bootcount_env.o
>> obj-$(CONFIG_BOOTCOUNT_I2C)  += bootcount_i2c.o
>> obj-$(CONFIG_BOOTCOUNT_EXT)  += bootcount_ext.o
>> +obj-$(CONFIG_BOOTCOUNT_DM)  += bootcount_dm.o
>> diff --git a/drivers/bootcount/bootcount_dm.c
>> b/drivers/bootcount/bootcount_dm.c new file mode 100644
>> index 000..99bdb88
>> --- /dev/null
>> +++ b/drivers/bootcount/bootcount_dm.c
>> @@ -0,0 +1,93 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * (C) Copyright 2018 Theobroma Systems Design und Consulting GmbH
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +const u8 bootcount_magic = 0xbc;
>> +
>> +static void bootcount_store_rtc(struct udevice *dev, ulong a)
>> +{
>> +#if CONFIG_IS_ENABLED(DM_RTC)
>> +u32 offset;
>> +const char *offset_propname = "u-boot,bootcount-offset";
>> +const u16 val = bootcount_magic << 8 | (a & 0xff);
>> +
>> +if (dev_read_u32(dev, offset_propname, ) < 0) {
>> +debug("%s: requires %s\n", __func__,
>> offset_propname);
>> +return;
>> +}
>> +
>> +if (rtc_write16(dev, offset, val) < 0) {
>> +debug("%s: rtc_write16 failed\n", __func__);
>> +return;
>> +}
>> +#endif
>> +}
>> +
>> +static u32 bootcount_load_rtc(struct udevice *dev)
>> +{
>> +#if CONFIG_IS_ENABLED(DM_RTC)
>> +u32 offset;
>> +const char 

Re: [U-Boot] [PATCH] spl: fix debug print in spl_common_init()

[Dr. Philipp Tomsich]

> On 13 Aug 2018, at 11:24, Simon Goldschmidt  
> wrote:
> 
> spl_common_init() debug-prints "spl_early_init()\n" but it is
> called both from spl_early_init() and spl_init().
> 
> Fix this by moving the debug() statement to the calling functions
> which now print their name.
> 
> Signed-off-by: Simon Goldschmidt 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH] kconfig: fix typo 'parition'

[Dr. Philipp Tomsich]

> On 13 Aug 2018, at 11:34, Simon Goldschmidt  
> wrote:
> 
> %s/parition/partition

Make this a whole sentence to make it easier to read.

> 
> Signed-off-by: Simon Goldschmidt 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH 1/9] dm: allow 4GB of DRAM on 32bit systems

[Dr. Philipp Tomsich]

> On 2 Aug 2018, at 22:36, Simon Glass  wrote:
> 
> On 26 July 2018 at 07:59, Philipp Tomsich
>  > wrote:
>> Even on 32bit systems a full 4GB of DRAM may be installed and reported
>> by the DRAM controller.  Whether these 4GB are larger available
>> depends on the size/configuration of address decoding windows and
>> architectural features (e.g. consider a hypothetical architecture that
>> uses dedicated instructions to access the 'memory-mapped' peripheral
>> IO ranges).  In U-Boot, the available DRAM, as reported by the
>> device-model is independent of the accessible DRAM (i.e. adjusted top
>> and effective size).
>> 
>> This was first reported against the RK3288, which may have 4GB DRAM
>> attached, but will have a small (e.g. 128MB) window not accessible due
>> to address decoding limitations.
>> 
>> The solution is to increase the types used for storing the ram_size to
>> have at least 33 bits even on 32bit systems... i.e. we need to use a
>> u64 for these always (this was previously only the case for
>> PHYS_64BIT, which will have unwanted side-effects for 32bit systems
>> and would require more intrusive changes).
>> 
>> This commit changes the size-field in 'struct ram' and the ram_size in
>> 'gd' to be a u64.
>> 
>> Reported-by: Marty E. Plummer 
>> Signed-off-by: Philipp Tomsich 
>> ---
>> 
>> include/asm-generic/global_data.h | 2 +-
>> include/ram.h | 9 -
>> 2 files changed, 9 insertions(+), 2 deletions(-)
>> 
> 
> Reviewed-by: Simon Glass mailto:s...@chromium.org>>
> 
>> diff --git a/include/asm-generic/global_data.h 
>> b/include/asm-generic/global_data.h
>> index 0fd4900..f3d687c 100644
>> --- a/include/asm-generic/global_data.h
>> +++ b/include/asm-generic/global_data.h
>> @@ -55,7 +55,7 @@ typedef struct global_data {
>>unsigned long ram_base; /* Base address of RAM used by U-Boot 
>> */
>>unsigned long ram_top;  /* Top address of RAM used by U-Boot 
>> */
>>unsigned long relocaddr;/* Start address of U-Boot in RAM */
>> -   phys_size_t ram_size;   /* RAM size */
>> +   u64 ram_size;   /* RAM size */
>>unsigned long mon_len;  /* monitor len */
>>unsigned long irq_sp;   /* irq stack pointer */
>>unsigned long start_addr_sp;/* start_addr_stackpointer */
>> diff --git a/include/ram.h b/include/ram.h
>> index 67e22d7..1fe024f 100644
>> --- a/include/ram.h
>> +++ b/include/ram.h
>> @@ -9,7 +9,14 @@
>> 
>> struct ram_info {
>>phys_addr_t base;
>> -   size_t size;
>> +   /*
>> +* We use a 64bit type for the size to correctly handle 32bit
>> +* systems with 4GB of DRAM (which would overflow a 32bit type
>> +* and read back as 0).  For 64bit systems, we assume (for now)
> 
> forever :-)
> 
>> +* that they will always have less than 2^65 byte of DRAM
>> +* installed. -- prt
> 
> Is the prt your signature? I suggest dropping it.

In fact it is. But I’ll need to rewrite the entire comment anyway for the next
version of this series as there’s even more functions and places that the
memory size is stored in...

> 
>> +*/
>> +   u64 size;
>> };
>> 
>> struct ram_ops {
>> --
>> 2.1.4
>> 
> 
> Regards,
> Simon

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

Re: [U-Boot] [PATCH] board_f: drop 'dead code' in ram_top computation

[Dr. Philipp Tomsich]

> On 27 Jul 2018, at 11:16, Philipp Tomsich 
>  wrote:
> 
> gd->ram_top is assigned to twice on consecutive lines and the compiler
> won't be able to tell that the first assignment is dead (including its
> r-value) due to the r-value containing a (side-effect free) function
> call.
> 
> This drops the first assignment.
> 
> Signed-off-by: Philipp Tomsich 
> ---
> 
> common/board_f.c | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/common/board_f.c b/common/board_f.c
> index 88d7700..1b8a003 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -283,7 +283,6 @@ static int setup_dest_addr(void)
> #ifdef CONFIG_SYS_SDRAM_BASE
>   gd->ram_base = CONFIG_SYS_SDRAM_BASE;
> #endif
> - gd->ram_top = gd->ram_base + get_effective_memsize();
>   gd->ram_top = board_get_usable_ram_top(gd->mon_len);
>   gd->relocaddr = gd->ram_top;
>   debug("Ram top: %08lX\n", (ulong)gd->ram_top);
> -- 
> 2.1.4
> 

Oh my, I’ll need to revise, as board_get_usable_ram_top is implemented as 
follows:
> /* Get the top of usable RAM */
> __weak ulong board_get_usable_ram_top(ulong total_size)
> {
> #ifdef CONFIG_SYS_SDRAM_BASE
>   /*  
>  * Detect whether we have so much RAM that it goes past the end of 
> our  
>  * 32-bit address space. If so, clip the usable RAM so it doesn't.
>   
>  */
>   if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
>   /*  
>  * Will wrap back to top of 32-bit space when reservations
>   
>  * are made.  
>   
>  */
> return 0;
> #endif
>   return gd->ram_top;
> }

I.e. it consumes the previous value of gd->ram_top and ignores its argument.
I’ll clean this up before someone else falls into the same pit.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/9] rockchip: support 4GB DRAM on 32bit systems

[Dr. Philipp Tomsich]

> On 27 Jul 2018, at 09:50, Carlo Caione  wrote:
> 
> On Fri, 2018-07-27 at 00:54 +0200, Dr. Philipp Tomsich wrote:
>>> On 26 Jul 2018, at 22:05, Carlo Caione  wrote:
>>> 
>>> On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote:
>>>> The calculation in `rockchip_sdram_size` would overflow for 4GB
>>>> on
>>>> 32bit systems (i.e. when PHYS_64BIT is not defined).
>>>> 
>>>> This makes the internal variables and the signature prototype use
>>>> a
>>>> u64 to ensure that we can represent the 33rd bit (as in '4GB').
>>>> 
>>> 
>>> Hi Philipp,
>>> just to let you know that this is still not working on the veyron
>>> jerry
>>> chromebook with 4GB I have here (RK3288). The boot stops at:
>>> 
>>> U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
>>> Trying to boot from SPI
>>> 
>>> U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
>>> 
>>> Model: Google Jerry
>>> DRAM:  0 Bytes
>>> 
>>> I'm still investigating why but for sure there are several points
>>> to
>>> fix to have a proper debug, see [0].
>> 
>> I reread ‘rockchip_sdram_size’ and it looks as if I forgot to mark
>> the value
>> shifted to create chipsize_mb as ULL.  When looking at this code I
>> had an
>> uneasy feeling that this might run into the C type rules (i.e. 1 will
>> be a 32bit
>> integer and shifting it by 32 would result in 0), but I didn’t think
>> that this
>> would ever be the case and that any 4GB DRAM setup would be made
>> up of multiple channels or of multiple ranks.
> 
> It doesn't hurt but rockchip_sdram_size() is returning the correct
> value of 0x1 in my tests.

The 'gd->bd->bi_dram[i].size’ path will also be involved and truncate this
later on, but I am not convinced that it’s worth fixing the dram banks info
for the general case.

Generally, typing for these bi_dram structures seems a mess: they are
often cast to 32bit and sometimes to 64bit in common code (i.e. fdtdec.c
uses unsigned long long).
I hope I can avoid touching this code.

Btw, here’s a gem from board_f.c (these two lines are after each other):
> gd->ram_top = gd->ram_base + get_effective_memsize();
> gd->ram_top = board_get_usable_ram_top(gd->mon_len);

As the first line is clearly deal (except the fact that the compiler can’t tell
that get_effective_memsize() should be side-effect free), we can drop it.
I’ll send a separate patch for this to be picked up by Tom…

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

Re: [U-Boot] [PATCH 2/9] rockchip: support 4GB DRAM on 32bit systems

[Dr. Philipp Tomsich]

> On 26 Jul 2018, at 22:05, Carlo Caione  wrote:
> 
> On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote:
>> The calculation in `rockchip_sdram_size` would overflow for 4GB on
>> 32bit systems (i.e. when PHYS_64BIT is not defined).
>> 
>> This makes the internal variables and the signature prototype use a
>> u64 to ensure that we can represent the 33rd bit (as in '4GB').
>> 
> 
> Hi Philipp,
> just to let you know that this is still not working on the veyron jerry
> chromebook with 4GB I have here (RK3288). The boot stops at:
> 
> U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
> Trying to boot from SPI
> 
> U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
> 
> Model: Google Jerry
> DRAM:  0 Bytes
> 
> I'm still investigating why but for sure there are several points to
> fix to have a proper debug, see [0].

I reread ‘rockchip_sdram_size’ and it looks as if I forgot to mark the value
shifted to create chipsize_mb as ULL.  When looking at this code I had an
uneasy feeling that this might run into the C type rules (i.e. 1 will be a 32bit
integer and shifting it by 32 would result in 0), but I didn’t think that this
would ever be the case and that any 4GB DRAM setup would be made
up of multiple channels or of multiple ranks.

> 
> Also I was wondering if we should also fix get_effective_memsize() and
> gd->bd->bi_dram[].size
> 
> [0]https://gist.github.com/carlocaione/b93cfd9ee71e07fcf68d5c02256ff0fa
> 
> Cheers,
> 
> -- 
> Carlo Caione 

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

Re: [U-Boot] [PATCH 2/9] rockchip: support 4GB DRAM on 32bit systems

[Dr. Philipp Tomsich]

> On 26 Jul 2018, at 22:05, Carlo Caione  wrote:
> 
> On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote:
>> The calculation in `rockchip_sdram_size` would overflow for 4GB on
>> 32bit systems (i.e. when PHYS_64BIT is not defined).
>> 
>> This makes the internal variables and the signature prototype use a
>> u64 to ensure that we can represent the 33rd bit (as in '4GB').
>> 
> 
> Hi Philipp,
> just to let you know that this is still not working on the veyron jerry
> chromebook with 4GB I have here (RK3288). The boot stops at:
> 
> U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
> Trying to boot from SPI
> 
> U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
> 
> Model: Google Jerry
> DRAM:  0 Bytes
> 
> I'm still investigating why but for sure there are several points to
> fix to have a proper debug, see [0].
> 
> Also I was wondering if we should also fix get_effective_memsize() and
> gd->bd->bi_dram[].size
> 
> [0]https://gist.github.com/carlocaione/b93cfd9ee71e07fcf68d5c02256ff0fa

Thanks for identifying these two… I’ll pick them up and include in the next
series.

> 
> Cheers,
> 
> -- 
> Carlo Caione 

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

Re: [U-Boot] [PATCH 2/9] rockchip: support 4GB DRAM on 32bit systems

[Dr. Philipp Tomsich]

> On 26 Jul 2018, at 22:05, Carlo Caione  wrote:
> 
> On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote:
>> The calculation in `rockchip_sdram_size` would overflow for 4GB on
>> 32bit systems (i.e. when PHYS_64BIT is not defined).
>> 
>> This makes the internal variables and the signature prototype use a
>> u64 to ensure that we can represent the 33rd bit (as in '4GB').
>> 
> 
> Hi Philipp,
> just to let you know that this is still not working on the veyron jerry
> chromebook with 4GB I have here (RK3288). The boot stops at:
> 
> U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
> Trying to boot from SPI
> 
> U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100)
> 
> Model: Google Jerry
> DRAM:  0 Bytes
> 
> I'm still investigating why but for sure there are several points to
> fix to have a proper debug, see [0].
> 
> Also I was wondering if we should also fix get_effective_memsize() and
> gd->bd->bi_dram[].size

Yes, we should. I missed that one…
I only have RK3368 and RK3399 targets to test here, so your testing is very
much appreciated.

> 
> [0]https://gist.github.com/carlocaione/b93cfd9ee71e07fcf68d5c02256ff0fa
> 
> Cheers,
> 
> --
> Carlo Caione 



signature.asc
Description: Message signed with OpenPGP
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,2/3] ARM: add RK3399 Ficus board

[Dr. Philipp Tomsich]

Ezequiel,

> On 25 Jul 2018, at 22:31, Ezequiel Garcia  wrote:
> 
> On Sat, 2018-07-21 at 16:23 +0200, Dr. Philipp Tomsich wrote:
>> Ezequiel,
>> 
>> This series breaks the build (see 
>> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/406351695).
>> Did you test with Travis prior to submitting?
>> 
> 
> No, I haven't. It's quite odd, as the README patch just adds some 
> documentation.

I responded to this mail, as there’s no cover letter.
It’s the series breaking the build, not the README change.

> I am having a hard time figuring out how could it break the build,
> and I do not see any logs in the travis-ci link either.

Does the direct link to the line with the error work for you:
https://travis-ci.org/ptomsich/u-boot-rockchip/jobs/406351815#L1330

If not, I’ll have to copy this into a mail manually...

> 
> Any ideas?
> 
>> When you revise, I’d also prefer a ‘rockchip:’ and a ‘board:’ tag over the 
>> ARM tag …
>> 
> 
> OK, I will.
> 
>> Thanks,
>> Philipp.
>> 
>> 
>>> On 20 Jul 2018, at 19:30, Philipp Tomsich 
>>>  wrote:
>>> 
>>>> This commit adds support for RK3399 Ficus board,
>>>> aka ROCK960 Enterprise Edition.
>>>> 
>>>> Following peripherals are tested and known to work:
>>>> * Gigabit Ethernet
>>>> * USB 2.0
>>>> * MMC
>>>> 
>>>> Signed-off-by: Ezequiel Garcia 
>>>> Reviewed-by: Simon Glass 
>>>> Reviewed-by: Philipp Tomsich 
>>>> ---
>>>> arch/arm/dts/Makefile|   1 +
>>>> arch/arm/dts/rk3399-ficus.dts| 564 +++
>>>> board/rockchip/evb_rk3399/README |   2 +
>>>> configs/ficus-rk3399_defconfig   |  71 
>>>> 4 files changed, 638 insertions(+)
>>>> create mode 100644 arch/arm/dts/rk3399-ficus.dts
>>>> create mode 100644 configs/ficus-rk3399_defconfig
>>>> 
>>> 
>>> Acked-by: Philipp Tomsich 
>>> ___
>>> 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 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

Marty,

> On 6 Jul 2018, at 05:11, Marty E. Plummer  wrote:
> 
> On Sat, May 19, 2018 at 02:08:53PM +0200, Dr. Philipp Tomsich wrote:
>> Marty,
>> 
>>> On 19 May 2018, at 12:40, Marty E. Plummer  wrote:
>>> 
>>> So explain to me what you'd like me to do here, if you would. What I
>>> gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it
>>> works or what? I can flash/reflash u-boot and coreboot pretty easily on
>>> the device, so I'm down for any sort of hardware testing needed to get
>>> this into a usable state.
>> 
>> Yes, just enable PHYS_64BIT and report on how far it goes (activating some
>> debug may be helpful to understand what goes wrong, if it fails).
>> 
>> My gut feeling is that it could work, but there’s a number of pitfalls and 
>> we may
>> not be lucky.
>> 
> Testing flipping CONFIG_PHYS_64BIT, both with and without my 'clamping'
> patch to sdram_common.c, has the same results, in that all that is
> output on the servo console is that wierd  output. Where to from
> here, then?

I have a patchset for changing the relevant fields in U-Boot to allow for 
33bits (i.e. using u64) for the RAM size and it finally passes Travis cleanly.
It will be another round or two of cleanup before I can submit the series — 
once this happens, I’ll copy you so you can give your Tested-by if it works…

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

Re: [U-Boot] [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)

[Dr. Philipp Tomsich]

> On 24 Jul 2018, at 07:12, Marty E. Plummer  wrote:
> 
> On Fri, Jul 13, 2018 at 12:31:49PM +0200, Dr. Philipp Tomsich wrote:
>> 
>>> On 7 May 2018, at 02:20, Marty E. Plummer  wrote:
>>> 
>>> On Mon, May 07, 2018 at 12:12:54AM +0200, klaus.go...@theobroma-systems.com 
>>> <mailto:klaus.go...@theobroma-systems.com> wrote:
>>>> 
>>>>> On 06.05.2018, at 16:25, Marty E. Plummer  wrote:
>>>>> 
>>>>> This adds support for the ASUS C201, a RK3288-based clamshell
>>>>> device. The device tree comes from linus's linux tree at
>>>>> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539. The SDRAM parameters
>>>>> are for 4GB Samsung LPDDR3, decoded from coreboot's
>>>>> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
>>>>> 
>>>>> Signed-off-by: Marty E. Plummer 
>>>>> ---
>>>>> arch/arm/dts/Makefile |   1 +
>>>>> arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++
>>>>> arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
>>>>> arch/arm/mach-rockchip/rk3288/Kconfig |  11 ++
>>>>> board/google/veyron/Kconfig   |  16 ++
>>>>> configs/chromebook_speedy_defconfig   |  96 +++
>>>>> 6 files changed, 315 insertions(+), 1 deletion(-)
>>>>> create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
>>>>> create mode 100644 configs/chromebook_speedy_defconfig
>>>>> 
>>>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>>>> index ac7667b1e8..ee04d9bedd 100644
>>>>> --- a/arch/arm/dts/Makefile
>>>>> +++ b/arch/arm/dts/Makefile
>>>>> @@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>>>>>   rk3288-veyron-jerry.dtb \
>>>>>   rk3288-veyron-mickey.dtb \
>>>>>   rk3288-veyron-minnie.dtb \
>>>>> + rk3288-veyron-speedy.dtb \
>>>>>   rk3288-vyasa.dtb \
>>>>>   rk3328-evb.dtb \
>>>>>   rk3368-lion.dtb \
>>>>> diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts 
>>>>> b/arch/arm/dts/rk3288-veyron-speedy.dts
>>>>> new file mode 100644
>>>>> index 00..d5383cef0d
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/dts/rk3288-veyron-speedy.dts
>>>> 
>>>> This file looks quite different then the one I see on kernel.org with that 
>>>> revision id. So you are sure you
>>>> imported that one?
>>> Dafuq... it seems I borked something up in doing the patch juggling to
>>> turn my single-commit mess of a patch (you know, the 'get the thing to
>>> work branch') into a good patch series I messed up on this one.
>>>> 
>>>>> @@ -0,0 +1,189 @@
>>>>> +/*
>>>>> + * Google Veyron Speedy Rev 1+ board device tree source
>>>>> + *
>>>>> + * Copyright 2015 Google, Inc
>>>>> + *
>>>>> + * SPDX-License-Identifier:  GPL-2.0
>>>> 
>>>> This file is dual licensed upstream, keep it that way.
>>>> The comment will claim it's a X11 license but the license text below
>>>> is actually MIT so you may want to use the MIT SPDX tag for that.
>>>> 
>>> Yeah, I was listening in on the convo on irc. So, even though it 'says'
>>> its GPL/X11, the actual license text is MIT, so I should use that tag?
>>> Its not my code, obviously, so I have no dog in that race anyways.
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +#include "rk3288-veyron-chromebook.dtsi"
>>>>> +#include "cros-ec-sbs.dtsi"
>>>>> +
>>>>> +/ {
>>>>> + model = "Google Speedy";
>>>>> + compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
>>>>> +  "google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
>>>>> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
>>>>> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
>>>>> +  "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
>>>>> +
>>>>> + chosen {
>>>>> + stdout-path = 
>>>>> + };
>>

Re: [U-Boot] [U-Boot,2/3] ARM: add RK3399 Ficus board

[Dr. Philipp Tomsich]

Ezequiel,

This series breaks the build (see 
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/406351695).
Did you test with Travis prior to submitting?

When you revise, I’d also prefer a ‘rockchip:’ and a ‘board:’ tag over the ARM 
tag …

Thanks,
Philipp.


> On 20 Jul 2018, at 19:30, Philipp Tomsich 
>  wrote:
> 
>> This commit adds support for RK3399 Ficus board,
>> aka ROCK960 Enterprise Edition.
>> 
>> Following peripherals are tested and known to work:
>> * Gigabit Ethernet
>> * USB 2.0
>> * MMC
>> 
>> Signed-off-by: Ezequiel Garcia 
>> Reviewed-by: Simon Glass 
>> Reviewed-by: Philipp Tomsich 
>> ---
>> arch/arm/dts/Makefile|   1 +
>> arch/arm/dts/rk3399-ficus.dts| 564 +++
>> board/rockchip/evb_rk3399/README |   2 +
>> configs/ficus-rk3399_defconfig   |  71 
>> 4 files changed, 638 insertions(+)
>> create mode 100644 arch/arm/dts/rk3399-ficus.dts
>> create mode 100644 configs/ficus-rk3399_defconfig
>> 
> 
> Acked-by: Philipp Tomsich 
> ___
> 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] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Tom,

The first batch of changes for u-boot-rockchip/master in this iteration is 
ready for you to pull.
The associated Travis report (prior to the rebase) is at
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/406299101

Thanks,
Philipp.


The following changes since commit 0dd1fc09bb16869fd8adaaad082cd554c60b2c1a:

  board/imgtec/boston: Add new defconfigs to the MAINTAINERS list (2018-07-20 
15:55:10 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to a2a5053a15e4059c7445737d60f7b8425ca863f8:

  rockchip: utilize CONFIG_DEFAULT_FDT_FILE (2018-07-21 01:56:59 +0200)


Alexander Kochetkov (2):
  rockchip: i2c: enable i2c controller for rk3066 and rk3188
  rockchip: rk3188: add rk_board_late_init() hook

Carlo Caione (3):
  rk3288: veyron: Init boot-on regulators
  rk3288: Disable JTAG function from sdmmc0 IO
  rockchip: veyron: Set vcc33_sd regulator value

Heinrich Schuchardt (3):
  rockchip: evb-rk3399: correct README for board bring up
  rockchip: doc: clarify usage of CONFIG_SPL_ROCKCHIP_BACK_TO_BROM
  rockchip: rk3399: spl: add missing \n to output

Jakob Unterwurzacher (1):
  rockchip: board: lion-rk3368: increase phy autonegotiation timeout

Klaus Goger (2):
  rockchip: rk3399: change boot_target based on u-boot, spl-boot-device
  rockchip: utilize CONFIG_DEFAULT_FDT_FILE

Philipp Tomsich (4):
  smartweb: use SPL_TINY_MEMSET
  spl: record boot_device into spl_image and call spl_perform_fixups
  spl: document 'chosen/u-boot, spl-boot-device'
  rockchip: rk3399: inject 'u-boot, spl-boot-device' for next-stage

 arch/arm/mach-rockchip/rk3188-board.c |  7 +-
 arch/arm/mach-rockchip/rk3288-board.c | 26 ++-
 arch/arm/mach-rockchip/rk3399-board-spl.c | 50 +++-
 board/rockchip/evb_rk3399/README  |  2 +-
 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 74 ++
 common/spl/spl.c  | 12 ++-
 configs/chromebit_mickey_defconfig|  1 +
 configs/chromebook_jerry_defconfig|  1 +
 configs/chromebook_minnie_defconfig   |  1 +
 configs/evb-px5_defconfig |  1 +
 configs/evb-rk3036_defconfig  |  1 +
 configs/evb-rk3128_defconfig  |  1 +
 configs/evb-rk3229_defconfig  |  1 +
 configs/evb-rk3288_defconfig  |  1 +
 configs/evb-rk3328_defconfig  |  1 +
 configs/evb-rk3399_defconfig  |  1 +
 configs/evb-rv1108_defconfig  |  1 +
 configs/fennec-rk3288_defconfig   |  1 +
 configs/firefly-rk3288_defconfig  |  1 +
 configs/firefly-rk3399_defconfig  |  1 +
 configs/geekbox_defconfig |  1 +
 configs/kylin-rk3036_defconfig|  1 +
 configs/lion-rk3368_defconfig |  1 +
 configs/miqi-rk3288_defconfig |  1 +
 configs/phycore-rk3288_defconfig  |  1 +
 configs/popmetal-rk3288_defconfig |  1 +
 configs/puma-rk3399_defconfig |  1 +
 configs/rock2_defconfig   |  1 +
 configs/rock_defconfig|  1 +
 configs/sheep-rk3368_defconfig|  1 +
 configs/smartweb_defconfig|  1 +
 configs/tinker-rk3288_defconfig   |  1 +
 configs/vyasa-rk3288_defconfig|  1 +
 doc/README.rockchip   |  8 +-
 doc/device-tree-bindings/chosen.txt   | 10 +++
 drivers/i2c/rk_i2c.c  | 94 +--
 include/configs/lion_rk3368.h |  2 +
 include/configs/rk3036_common.h   |  1 +
 include/configs/rk3128_common.h   |  1 +
 include/configs/rk3188_common.h   |  1 +
 include/configs/rk322x_common.h   |  1 +
 include/configs/rk3288_common.h   |  2 +-
 include/configs/rk3328_common.h   |  1 +
 include/configs/rk3368_common.h   |  1 +
 include/configs/rk3399_common.h   |  2 +-
 include/spl.h |  7 ++
 46 files changed, 312 insertions(+), 17 deletions(-)

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

Re: [U-Boot] [U-Boot, 1/3] arm: dts: rockchip: add some common pin-settings to rk3399

[Dr. Philipp Tomsich]

> On 20 Jul 2018, at 19:14, Ezequiel Garcia  wrote:
> 
> On Fri, 2018-07-20 at 18:26 +0200, Philipp Tomsich wrote:
>> 
>> On Mon, 16 Jul 2018, Ezequiel Garcia wrote:
>> 
>>> From: Randy Li 
>>> 
>>> Those pins would be used by many boards.
>> 
>> The Rockchip pinctrl driver in U-Boot does not (yet) read the DTS for pin 
>> configuration information.
>> 
>> Is this a sync of the Linux DTS (which seems unlikely, as I'd expect more 
>> changes) or why are we doing this as part of this series?
>> 
> 
> As a matter of fact, it is a sync. It is literally this commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v4.19-armsoc/dts64=b41023282d07b61a53e2c9b9508912b1e7ce7b4f
> 
> It's just needed so that at least the ficus.dts file compiles.
> 
> Thanks,
> Eze

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

Re: [U-Boot] [U-Boot, 3/3] rockchip: rk3399: Add more instructions to the README

[Dr. Philipp Tomsich]

Thanks for the clarification, I’ll take this as-is.

> On 20 Jul 2018, at 19:09, Ezequiel Garcia  wrote:
> 
> On Fri, 2018-07-20 at 18:28 +0200, Philipp Tomsich wrote:
>> 
>> On Mon, 16 Jul 2018, Ezequiel Garcia wrote:
>> 
>>> This commit adds a content section and also instructions
>>> on how to create a bootable SD/MMC device for RK3399 boards.
>> 
>> Are any of these instructions Ficus-specific?  We have our own README for 
>> our own boards, as these have different instructions from the EVB boards.
>> 
> 
> Nope, it applies to any rk3399 board. And the rest of the file as well,
> as long as the board has eMMC.
> 
>> Just wondering, as I'd have expected this to come in as part of the ficus 
>> board-directory...
>> 
> 
> Yeah, but all the instructions on this file applied to the Ficus
> (and to many others) so I decided to just extend it for now.
> 
> If it needs moving to some generic doc, I think we can do that as a follow up 
> patch.
> 
>>> Signed-off-by: Ezequiel Garcia 
>>> Reviewed-by: Simon Glass 
>> 
>> Reviewed-by: Philipp Tomsich 
>> 
> 
> Thanks for the review!
> Eze

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

Re: [U-Boot] [PATCH v2 01/11] arch: arm: mach-rockchip: rk3288: Enable regulators in board_init

[Dr. Philipp Tomsich]

Janine,

> On 18 Jul 2018, at 10:46, Janine Hagemann  wrote:
> 
> At start-up, the regulators have to be enabled. Let's use
> regulators_enable_boot_on() to enable the regulators needed
> for boot.
> 
> Signed-off-by: Wadim Egorov 
> Signed-off-by: Janine Hagemann 

An equivalent change from Carlo has already been applied to U-Boot master.
Please review whether there’s additional changes needed, otherwise I’ll just
skip this one when processing.

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

[U-Boot] CONFIG_SPL_TINY_MEMSET for configs/smartweb_defconfig?

[Dr. Philipp Tomsich]

Heiko,

I have a SPL change assigned in my queue that breaks the smartweb config due to 
increasing SPL by a few bytes of extra code.  I’d like to enable 
CONFIG_SPL_TINY_MEMSET in configs/smartweb_defconfig to fix this.

If this is ok with you, I’ll submit a patch against the defconfing and then 
take it through the rockchip-tree (so I have a clean Travis run), once you give 
it a Reviewed or Acked tag.

Let me know if you have any concerns,
Philipp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sysreset: Add support for gpio-restart

[Dr. Philipp Tomsich]

> On 13 Jul 2018, at 11:15, Michal Simek  wrote:
> 
> The Linux kernel has binding for gpio-restart node.
> This patch is adding basic support without supporting any optional
> properties.

Nice. This may also give us an opportunity to streamline some of the reset
logic (and the FDT-interface to the ATF) on our RK3399-Q7 board.

> This driver was tested on Microblaze system where gpio is connected to
> SoC reset logic.
> Output value is handled via gpios cells values.
> 
> In gpio_reboot_request() set_value is writing 1 because
> dm_gpio_set_value() is capable to changing it when it is ACTIVE_LOW.
> ...
>   if (desc->flags & GPIOD_ACTIVE_LOW)
>   value = !value;
> ...
> 
> Signed-off-by: Michal Simek 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

[Dr. Philipp Tomsich]

Joe,

> On 14 Jun 2018, at 20:26, Joe Hershberger  wrote:
> 
> On Thu, Jun 14, 2018 at 1:12 PM, Dr. Philipp Tomsich
>  wrote:
>> 
>>> On 14 Jun 2018, at 19:39, Joe Hershberger  wrote:
>>> 
>>> On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  
>>> wrote:
>>>> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
>>>> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
>>>> to enable the RX delay.
>>>> The MASK was used in a wrong way.
>>>> 
>>>> Signed-off-by: Janine Hagemann 
>>> 
>>> Acked-by: Joe Hershberger 
>> 
>> Reviewed-by: Philipp Tomsich 
> 
> I assume I should take this series? Or would you prefer to?


I’ll take these as part of the larger series.

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

Re: [U-Boot] [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)

[Dr. Philipp Tomsich]

> On 7 May 2018, at 02:20, Marty E. Plummer  wrote:
> 
> On Mon, May 07, 2018 at 12:12:54AM +0200, klaus.go...@theobroma-systems.com 
>  wrote:
>> 
>>> On 06.05.2018, at 16:25, Marty E. Plummer  wrote:
>>> 
>>> This adds support for the ASUS C201, a RK3288-based clamshell
>>> device. The device tree comes from linus's linux tree at
>>> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539. The SDRAM parameters
>>> are for 4GB Samsung LPDDR3, decoded from coreboot's
>>> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
>>> 
>>> Signed-off-by: Marty E. Plummer 
>>> ---
>>> arch/arm/dts/Makefile |   1 +
>>> arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++
>>> arch/arm/mach-rockchip/rk3288-board-spl.c |   3 +-
>>> arch/arm/mach-rockchip/rk3288/Kconfig |  11 ++
>>> board/google/veyron/Kconfig   |  16 ++
>>> configs/chromebook_speedy_defconfig   |  96 +++
>>> 6 files changed, 315 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
>>> create mode 100644 configs/chromebook_speedy_defconfig
>>> 
>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>> index ac7667b1e8..ee04d9bedd 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>>> rk3288-veyron-jerry.dtb \
>>> rk3288-veyron-mickey.dtb \
>>> rk3288-veyron-minnie.dtb \
>>> +   rk3288-veyron-speedy.dtb \
>>> rk3288-vyasa.dtb \
>>> rk3328-evb.dtb \
>>> rk3368-lion.dtb \
>>> diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts 
>>> b/arch/arm/dts/rk3288-veyron-speedy.dts
>>> new file mode 100644
>>> index 00..d5383cef0d
>>> --- /dev/null
>>> +++ b/arch/arm/dts/rk3288-veyron-speedy.dts
>> 
>> This file looks quite different then the one I see on kernel.org with that 
>> revision id. So you are sure you
>> imported that one?
> Dafuq... it seems I borked something up in doing the patch juggling to
> turn my single-commit mess of a patch (you know, the 'get the thing to
> work branch') into a good patch series I messed up on this one.
>> 
>>> @@ -0,0 +1,189 @@
>>> +/*
>>> + * Google Veyron Speedy Rev 1+ board device tree source
>>> + *
>>> + * Copyright 2015 Google, Inc
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0
>> 
>> This file is dual licensed upstream, keep it that way.
>> The comment will claim it's a X11 license but the license text below
>> is actually MIT so you may want to use the MIT SPDX tag for that.
>> 
> Yeah, I was listening in on the convo on irc. So, even though it 'says'
> its GPL/X11, the actual license text is MIT, so I should use that tag?
> Its not my code, obviously, so I have no dog in that race anyways.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "rk3288-veyron-chromebook.dtsi"
>>> +#include "cros-ec-sbs.dtsi"
>>> +
>>> +/ {
>>> +   model = "Google Speedy";
>>> +   compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
>>> +"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
>>> +"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
>>> +"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
>>> +"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
>>> +
>>> +   chosen {
>>> +   stdout-path = 
>>> +   };
>>> +
>>> +   panel_regulator: panel-regulator {
>>> +   compatible = "regulator-fixed";
>>> +   enable-active-high;
>>> +   gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_enable_h>;
>>> +   regulator-name = "panel_regulator";
>>> +   startup-delay-us = <10>;
>>> +   vin-supply = <_sys>;
>>> +   };
>>> +
>>> +   vcc18_lcd: vcc18-lcd {
>>> +   compatible = "regulator-fixed";
>>> +   enable-active-high;
>>> +   gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_1v8_disp_en>;
>>> +   regulator-name = "vcc18_lcd";
>>> +   regulator-always-on;
>>> +   regulator-boot-on;
>>> +   vin-supply = <_wl>;
>>> +   };
>>> +
>>> +   backlight_regulator: backlight-regulator {
>>> +   compatible = "regulator-fixed";
>>> +   enable-active-high;
>>> +   gpio = < RK_PB4 GPIO_ACTIVE_HIGH>;
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_pwr_en>;
>>> +   regulator-name = "backlight_regulator";
>>> +   vin-supply = <_sys>;
>>> +   startup-delay-us = <15000>;
>>> +   };
>>> +};
>>> +
>>> + {
>>> +   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
>>> +   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
>>> +   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
>>> +   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
>>> +   0x8 0x1f4>;
>>> +   rockchip,phy-timing = <0x48d7dd93 0x187008d8 

Re: [U-Boot] [PATCH v3 4/4] rk3288: Convert register defines to const uintptr_t

[Dr. Philipp Tomsich]

> On 9 Jul 2018, at 05:05, Simon Glass  wrote:
> 
> On 11 June 2018 at 13:00, Carlo Caione  wrote:
>> From: Carlo Caione 
>> 
>> No functional change but at least we can now guarantee type safety.
>> 
>> Signed-off-by: Carlo Caione 
>> ---
>> arch/arm/mach-rockchip/rk3288-board.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> I'm not sure this affects type safety. The value in the #define has
> the same value (and type) as your variables.

I prefer this as locally defined const variables, so I’ve squashed this onto 
2/4.

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

Re: [U-Boot] [PATCH 1/1] rockchip: rk3399: spl: add missing \n to output

[Dr. Philipp Tomsich]

Ezequiel,

I started to apply my backlog yesterday and this is currently in one of my trees
running through travis.  You should see the ‘applied to master’ message at the
latest tomorrow.

Thanks,
Philipp.

> On 11 Jul 2018, at 15:06, Ezequiel Garcia  
> wrote:
> 
> On 3 June 2018 at 19:28, Dr. Philipp Tomsich
>  wrote:
>> 
>>> On 3 Jun 2018, at 21:10, Heinrich Schuchardt  wrote:
>>> 
>>> Without the patch SPL (in case of an error) creates an output like:
>>> 
>>>  U-Boot SPL board initMissing DTB
>>> 
>>> The patch adds the missing line feed. So now we get:
>>> 
>>>  U-Boot SPL board init
>>>  Missing DTB
>>> 
>>> Signed-off-by: Heinrich Schuchardt 
>> 
>> Reviewed-by: Philipp Tomsich 
>> Acked-by: Philipp Tomsich 
>> 
> 
> Guys,
> 
> Any chance we pick this one?
> 
> Thanks,
> -- 
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

> On 10 Jul 2018, at 16:41, Simon Glass  wrote:
> 
> Hi,
> 
> On 8 May 2018 at 04:21, Dr. Philipp Tomsich
>  <mailto:philipp.toms...@theobroma-systems.com>> wrote:
>> Marty,
>> 
>>> On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
>>> 
>>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>>> 
>>>>> On 7 May 2018, at 04:34, Marty E. Plummer  wrote:
>>>>> 
>>>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>>>>>> Hi Marty,
>>>>>> 
>>>>>> 
>>>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>>>>>> 
>>>>>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>>>>>> is incorrectly detected as 0 Bytes of ram.
>>>>>> 
>>>>>> I know the root cause for this issue, and I have a local patch for it.
>>>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>>>>>> before
>>>>>> the max size before return with '<<20'. Sorry for forgot to send it out.
>>>>>> 
>>>>>>> 
>>>>>>> Signed-off-by: Marty E. Plummer 
>>>>>>> ---
>>>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>>>>>> b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>> index 76dbdc8715..a9c9f970a4 100644
>>>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>> @@ -10,6 +10,8 @@
>>>>>>> #include 
>>>>>>> #include 
>>>>>>> #include 
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> 
>>>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>>  size_t size_mb = 0;
>>>>>>>  u32 ch;
>>>>>>> 
>>>>>>> - u32 sys_reg = readl(reg);
>>>>>>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>>>>>> -& SYS_REG_NUM_CH_MASK);
>>>>>>> + if (!size_mb) {
>>>>>> 
>>>>>> I don't understand this and follow up changes, we don't really need it,
>>>>>> isn't it?
>>>>>> I think don't need the changes before here.
>>>>> Yeah, that was just another level of indentation for the if (!size_mb)
>>>>> guard, but I've reworked the patch to not do that as it was pointed out
>>>>> that since size_mb is initialized to 0 prior.
>>>>>>> + /*
>>>>>>> +  * we use the 0x~0xfeff space
>>>>>>> +  * since 0xff00~0x is soc register space
>>>>>>> +  * so we reserve it
>>>>>>> +  */
>>>>>>> + size_mb = min(size_mb, 0xff00/SZ_1M);
>>>>>> 
>>>>>> This is what we really need, as Klaus point out, we need to use
>>>>>> SDRAM_MAX_SIZE
>>>>>> instead of hard code.
>>>>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
>>>>> build and boot tested on my hardware.
>>>> 
>>>> In that case you just masked the problem but didn???t solve it: assuming 
>>>> size_mb
>>>> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
>>>> is 0x1__ )
>>>> which overflows to 0x0 when converted to a u32.
>>>> 
>>>> In other words: we need to figure out where the truncation occurs (image 
>>>> what
>>>> happens if a new 32bit processor with LPAE comes out???).
>>>> 
>>> A very valid point. With the following patch to sdram_common.c and
>>> sdram_rk3288.c applied I get the debug output that follows it:
>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>> b/arch/arm/

Re: [U-Boot] build fail due to dependence error

[Dr. Philipp Tomsich]

> On 9 Jul 2018, at 09:18, Patrick DELAUNAY  wrote:
> 
>> From: U-Boot  On Behalf Of Masahiro Yamada
>> Sent: lundi 9 juillet 2018 07:27
>> Subject: Re: [U-Boot] build fail due to dependence error
>> 
>> Hi.
>> 
>> 
>> 2018-07-09 11:39 GMT+09:00 Simon Glass :
>>> +Masahiro who might know
>>> 
>>> On 2 July 2018 at 01:23, Dr. Philipp Tomsich
>>>  wrote:
>>>> Kever,
>>>> 
>>>> Could you check the build artifacts in Jenkins to see whether after
>>>> the ‘make [configname]_defconfig’, the link for asm/arch is correctly
>>>> set up?
>>>> 
>>>> Thanks,
>>>> Philipp.
>>>> 
>>>> On 2 Jul 2018, at 09:54, Kever Yang  wrote:
>>>> 
>>>> Hi Simon,
>>>> 
>>>> 
>>>> On 06/30/2018 12:19 PM, Simon Glass wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On 28 June 2018 at 01:41, Dr. Philipp Tomsich
>>>>  wrote:
>>>> 
>>>> Kever,
>>>> 
>>>> is the link for ‘asm’ set up correctly?
>>>> 
>>>> Thanks,
>>>> Philipp.
>>>> 
>>>> On 28 Jun 2018, at 10:38, Kever Yang  wrote:
>>>> 
>>>> Hi Simon,
>>>> 
>>>>   Do you have any idea about this error?
>>>> 
>>>> 
>>>> CC  lib/asm-offsets.s
>>>> CC  arch/arm/lib/asm-offsets.s
>>>> fixdep: error opening config file:
>>>> arch/arm/include/asm/arch/hardware.h: No such file or directory
>>>> Kbuild:64: recipe for target 'arch/arm/lib/asm-offsets.s' failed
>>>> make[1]: *** [arch/arm/lib/asm-offsets.s] Error 2
>>>> make[1]: *** 正在等待未完成的任务
>>>> CHK include/config.h
>>>> Makefile:1340: recipe for target 'prepare0' failed
>>>> 
>>>> Thanks,
>>>> - Kever
>>>> 
>>>> On 06/01/2018 05:59 PM, Kever Yang wrote:
>>>> 
>>>> Hi Guys,
>>>> 
>>>>I met below error from time to time when build U-Boot project.
>>>> 
>>>> fixdep: error opening config file:
>>>> arch/arm/include/asm/arch/hardware.h: No such file or directory
>>>> 
>>>>   The folder 'arch/arm/include/asm/arch' is a link for
>>>> 'arch/arm/include/asm/arch-rockchip',
>>>> 
>>>> which is dynamic generate by build system, I thinks there should be
>>>> some dependency issue?
>>>> 
>>>>   How to fix this kind of issue?
>>>> 
>>>> I am not sure what is going on there. I don't see this.
>>>> 
>>>> Are you using 'make distclean' or 'make mrproper' on your object tree
>>>> every now and then?
>>>> 
>>>> 
>>>> This is happen sometimes in our Jenkins verify, It will gone when I
>>>> rebase the patch(re-build without any change), we do 'make distclean'
>>>> every time before a new build.
>> 
>> 
>> Hmm, I cannot reproduce this error.
>> 
>> 
>> I have no clue about this.
> 
> Just for information, I have also the same issue sometime in the same context 
> (Jenkins build) for stm32mp1 board.
> 
> The error is : "Missing stm32.h file in the directory include/asm/arch/"
> 
> I try to understood the dependency issue, but I don't found any issue: 
> the needed symbolic link is done just before in the trace of the artifact...
> 
> 2018-03-03-17-00-02] | if [ -d 
> /opt/STM/workspace/workdir/rdk/build-stm32mp1/tmp-glibc/work/stm32mp1-stm32mpvalid-linux-gnueabi/u-boot-basic-stm32mp/2018.01-git-AUTOINC+d741b91b3c.r0/git/arch/arm/mach-stm32mp/include/mach
>  ]; then   \
> [2018-03-03-17-00-02] |dest=arch/arm/mach-stm32mp/include/mach;   
>   \
> [2018-03-03-17-00-02] | else  
>\
> [2018-03-03-17-00-02] |dest=arch/arm/include/asm/arch-stm32mp;   \
> [2018-03-03-17-00-02] | fi;   
>\
> [2018-03-03-17-00-02] | ln -fsn 
> /opt/STM/workspace/workdir/rdk/build-stm32mp1/tmp-glibc/work/stm32mp1-stm32mpvalid-linux-gnueabi/u-boot-basic-stm32mp/2018.01-git-AUTOINC+d741b91b3c.r0/git/$dest
>  include/asm/arch
> [2018-03-03-17-00-02] | fixdep: error opening config file: 
> include/asm/arch/stm32.h: No such file or directory
> 
> I don't understood why the dependency failed
> 
> Perhaps it is because in our Jenkins task the p

Re: [U-Boot] build fail due to dependence error

[Dr. Philipp Tomsich]

Kever,

Could you check the build artifacts in Jenkins to see whether after
the ‘make [configname]_defconfig’, the link for asm/arch is correctly
set up?

Thanks,
Philipp.

> On 2 Jul 2018, at 09:54, Kever Yang  wrote:
> 
> Hi Simon,
> 
> 
> On 06/30/2018 12:19 PM, Simon Glass wrote:
>> Hi,
>> 
>> On 28 June 2018 at 01:41, Dr. Philipp Tomsich
>>  wrote:
>>> Kever,
>>> 
>>> is the link for ‘asm’ set up correctly?
>>> 
>>> Thanks,
>>> Philipp.
>>> 
>>> On 28 Jun 2018, at 10:38, Kever Yang  wrote:
>>> 
>>> Hi Simon,
>>> 
>>>Do you have any idea about this error?
>>> 
>>> 
>>> CC  lib/asm-offsets.s
>>>  CC  arch/arm/lib/asm-offsets.s
>>> fixdep: error opening config file: arch/arm/include/asm/arch/hardware.h: No
>>> such file or directory
>>> Kbuild:64: recipe for target 'arch/arm/lib/asm-offsets.s' failed
>>> make[1]: *** [arch/arm/lib/asm-offsets.s] Error 2
>>> make[1]: *** 正在等待未完成的任务
>>>  CHK include/config.h
>>> Makefile:1340: recipe for target 'prepare0' failed
>>> 
>>> Thanks,
>>> - Kever
>>> 
>>> On 06/01/2018 05:59 PM, Kever Yang wrote:
>>> 
>>> Hi Guys,
>>> 
>>> I met below error from time to time when build U-Boot project.
>>> 
>>> fixdep: error opening config file: arch/arm/include/asm/arch/hardware.h: No
>>> such file or directory
>>> 
>>>The folder 'arch/arm/include/asm/arch' is a link for
>>> 'arch/arm/include/asm/arch-rockchip',
>>> 
>>> which is dynamic generate by build system, I thinks there should be some
>>> dependency issue?
>>> 
>>>How to fix this kind of issue?
>> I am not sure what is going on there. I don't see this.
>> 
>> Are you using 'make distclean' or 'make mrproper' on your object tree
>> every now and then?
> 
> This is happen sometimes in our Jenkins verify, It will gone when I
> rebase the patch(re-build without any change),
> we do 'make distclean' every time before a new build.
> 
> Thanks,
> - Kever
>> Regards,
>> Simon

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

Re: [U-Boot] build fail due to dependence error

[Dr. Philipp Tomsich]

Kever,

is the link for ‘asm’ set up correctly?

Thanks,
Philipp.

> On 28 Jun 2018, at 10:38, Kever Yang  wrote:
> 
> Hi Simon,
> 
> Do you have any idea about this error?
> 
> CC  lib/asm-offsets.s
>   CC  arch/arm/lib/asm-offsets.s
> fixdep: error opening config file: arch/arm/include/asm/arch/hardware.h: No 
> such file or directory
> Kbuild:64: recipe for target 'arch/arm/lib/asm-offsets.s' failed
> make[1]: *** [arch/arm/lib/asm-offsets.s] Error 2
> make[1]: *** 正在等待未完成的任务
>   CHK include/config.h
> Makefile:1340: recipe for target 'prepare0' failed
> 
> Thanks,
> - Kever
> On 06/01/2018 05:59 PM, Kever Yang wrote:
>> Hi Guys,
>> 
>>  I met below error from time to time when build U-Boot project.
>> 
>> fixdep: error opening config file: arch/arm/include/asm/arch/hardware.h: No 
>> such file or directory
>> 
>> The folder 'arch/arm/include/asm/arch' is a link for
>> 'arch/arm/include/asm/arch-rockchip',
>> 
>> which is dynamic generate by build system, I thinks there should be some
>> dependency issue?
>> 
>> How to fix this kind of issue?
>> 
>> 
>> Thanks,
>> 
>> - Kever
>> 
>> ___
>> 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 2/2] arm: timer: sunxi: add Allwinner timer erratum workaround

[Dr. Philipp Tomsich]

> On 27 Jun 2018, at 02:42, Andre Przywara  wrote:
> 
> The Allwinner A64 SoCs suffers from an arch timer implementation erratum,
> where sometimes the lower 11 bits of the counter value erroneously
> become all 0's or all 1's [1]. This leads to sudden jumps, both forwards and
> backwards, with the latter one often showing weird behaviour.

Feels like a throwback a discussions between us from about 2 years back. ;-)
Too bad that there’s still no Errata-document for the A64...

> Port the workaround proposed for Linux to U-Boot and activate it for all
> A64 boards.
> This fixes crashes when accessing MMC devices (SD cards), caused by a
> recent change to actually use the counter value for timeout checks.
> 
> Fixes: 5ff8e54888e4d26a352453564f7f599d29696dc9 ("sunxi: improve throughput
> in the sunxi_mmc driver")
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576886.html
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Philipp Tomsich 

> ---
> arch/arm/cpu/armv8/generic_timer.c | 24 
> arch/arm/mach-sunxi/Kconfig|  4 
> 2 files changed, 28 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/generic_timer.c 
> b/arch/arm/cpu/armv8/generic_timer.c
> index 3d04fde650..c1706dcec1 100644
> --- a/arch/arm/cpu/armv8/generic_timer.c
> +++ b/arch/arm/cpu/armv8/generic_timer.c
> @@ -46,6 +46,30 @@ unsigned long timer_read_counter(void)
> 
>   return cntpct;
> }
> +#elif CONFIG_SUNXI_A64_TIMER_ERRATUM
> +/*
> + * This erratum sometimes flips the lower 11 bits of the counter value
> + * to all 0's or all 1's, leading to jumps forwards or backwards.
> + * Backwards jumps might be interpreted all roll-overs and be treated as
> + * huge jumps forward.
> + * The workaround is to check whether the lower 11 bits of the counter are
> + * all 0 or all 1, then discard this value and read again.
> + * This occasionally discards valid values, but will catch all erroneous
> + * reads and fixes the problem reliably. Also this mostly requires only a
> + * single read, so does not have any significant overhead.
> + * The algorithm was conceived by Samuel Holland.
> + */
> +unsigned long timer_read_counter(void)
> +{
> + unsigned long cntpct;
> +
> + isb();
> + do {
> + asm volatile("mrs %0, cntpct_el0" : "=r" (cntpct));
> + } while (((cntpct + 1) & GENMASK(10, 0)) <= 1);
> +
> + return cntpct;
> +}
> #else
> /*
>  * timer_read_counter() using the Arm Generic Timer (aka arch timer).
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index a3f7723028..3624a03947 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -84,6 +84,9 @@ config SUNXI_HIGH_SRAM
>   Chips using the latter setup are supposed to select this option to
>   adjust the addresses accordingly.
> 
> +config SUNXI_A64_TIMER_ERRATUM
> + bool
> +
> # Note only one of these may be selected at a time! But hidden choices are
> # not supported by Kconfig
> config SUNXI_GEN_SUN4I
> @@ -270,6 +273,7 @@ config MACH_SUN50I
>   select SUNXI_DRAM_DW_32BIT
>   select FIT
>   select SPL_LOAD_FIT
> + select SUNXI_A64_TIMER_ERRATUM
> 
> config MACH_SUN50I_H5
>   bool "sun50i (Allwinner H5)"
> -- 
> 2.14.4
> 

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

Re: [U-Boot] [PATCH v2 1/6] dm: SMEM (Shared memory) uclass

[Dr. Philipp Tomsich]

> On 22 Jun 2018, at 04:11, Ramon Fried  wrote:
> 
> This is a uclass for Shared memory manager drivers.
> 
> A Shared Memory Manager driver implements an interface for allocating
> and accessing items in the memory area shared among all of the
> processors.
> 
> Signed-off-by: Ramon Fried 

Reviewed-by: Philipp Tomsich 

See below for a requested correction.

> 
> ---
> 
> Changes in v2:
> (As suggested by Simon Glass)
> - Introduced a new dm class (CLASS_SMEM) instead of CLASS_SOC.
> - Added sandbox driver
> - Added testing for DM class.
> 
> drivers/Makefile   |  1 +
> drivers/smem/Kconfig   |  2 +
> drivers/smem/Makefile  |  5 +++
> drivers/smem/smem-uclass.c | 53 
> include/dm/uclass-id.h |  1 +
> include/smem.h | 84 ++
> 6 files changed, 146 insertions(+)
> create mode 100644 drivers/smem/Kconfig
> create mode 100644 drivers/smem/Makefile
> create mode 100644 drivers/smem/smem-uclass.c
> create mode 100644 include/smem.h
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index a213ea9671..ba4a561358 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -98,6 +98,7 @@ obj-y += pwm/
> obj-y += reset/
> obj-y += input/
> # SOC specific infrastructure drivers.
> +obj-y += smem/
> obj-y += soc/
> obj-$(CONFIG_REMOTEPROC) += remoteproc/
> obj-y += thermal/
> diff --git a/drivers/smem/Kconfig b/drivers/smem/Kconfig
> new file mode 100644
> index 00..64337a8b8e
> --- /dev/null
> +++ b/drivers/smem/Kconfig
> @@ -0,0 +1,2 @@
> +menuconfig SMEM
> + bool  "SMEM (Shared Memory mamanger) support"
> diff --git a/drivers/smem/Makefile b/drivers/smem/Makefile
> new file mode 100644
> index 00..ca55c4512d
> --- /dev/null
> +++ b/drivers/smem/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Makefile for the U-Boot SMEM interface drivers
> +
> +obj-$(CONFIG_SMEM) += smem-uclass.o
> diff --git a/drivers/smem/smem-uclass.c b/drivers/smem/smem-uclass.c
> new file mode 100644
> index 00..07ed1a92d8
> --- /dev/null
> +++ b/drivers/smem/smem-uclass.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 Ramon Fried 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int smem_alloc(struct udevice *dev, unsigned int host,
> + unsigned int item, size_t size)
> +{
> + struct smem_ops *ops = smem_get_ops(dev);
> +
> + if (!ops->alloc)
> + return -ENOSYS;
> +
> + return ops->alloc(host, item, size);
> +}
> +
> +void *smem_get(struct udevice *dev, unsigned int host,
> + unsigned int item, size_t *size)
> +{
> + struct smem_ops *ops = smem_get_ops(dev);
> +
> + if (!ops->get)
> + return NULL;
> +
> + return ops->get(host, item, size);
> +}
> +
> +int smem_get_free_space(struct udevice *dev, unsigned int host, size_t *free)
> +{
> + struct smem_ops *ops = smem_get_ops(dev);
> +
> + int ret;
> +
> + if (!ops->get_free_space)
> + return -ENOSYS;
> +
> + ret = ops->get_free_space(host);
> + if (ret > 0)
> + *free = ret;
> + else
> + return ret;
> +
> + return 0;
> +}
> +
> +UCLASS_DRIVER(smem) = {
> + .id = UCLASS_SMEM,
> + .name   = "smem",
> +};
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index d7f9df3583..a39643ec5e 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -74,6 +74,7 @@ enum uclass_id {
>   UCLASS_RTC, /* Real time clock device */
>   UCLASS_SCSI,/* SCSI device */
>   UCLASS_SERIAL,  /* Serial UART */
> + UCLASS_SMEM,/* Shared memory interface */
>   UCLASS_SPI, /* SPI bus */
>   UCLASS_SPMI,/* System Power Management Interface bus */
>   UCLASS_SPI_FLASH,   /* SPI flash */
> diff --git a/include/smem.h b/include/smem.h
> new file mode 100644
> index 00..201960232c
> --- /dev/null
> +++ b/include/smem.h
> @@ -0,0 +1,84 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * header file for smem driver.
> + *
> + * Copyright (c) 2018 Ramon Fried 
> + */
> +
> +#ifndef _smemh_
> +#define _smemh_
> +
> +/* struct smem_ops: Operations for the SMEM uclass */
> +struct smem_ops {
> + /**
> +  * alloc() - allocate space for a smem item
> +  *
> +  * @host:   remote processor id, or -1
> +  * @item:   smem item handle
> +  * @size:   number of bytes to be allocated
> +  * @return 0 if OK, -ve on error
> +  */
> + int (*alloc)(unsigned int host,
> + unsigned int item, size_t size);
> +
> + /**
> +  * get() - Resolve ptr of size of a smem item
> +  *
> +  * @host:   the remote processor, of -1
> +  * @item:   smem item handle
> +  * @size:   pointer to be filled out with the size of the item
> +  * @return  pointer on success, NULL 

Re: [U-Boot] [PATCH 0/4] rockchip: Reduce prerequisites from the host

[Dr. Philipp Tomsich]

Vicente,

> On 18 Jun 2018, at 22:07, Vicente Bergas  wrote:
> 
> On Wed, 13 Jun 2018 11:51:13 +0800, kever.yang at rock-chips.com wrote:
>> (snip)
>> I just not understand why remove the dependency on python is so important,
>> there already many modules depend on python.
> 
> On Wed, 13 Jun 2018 11:57:48 +0800, kever.yang at rock-chips.com wrote:
>> (snip)
>> Could you share why you don't want to use python, can convert the
>> script to C?
> 
> Hi Kever,
> there are several reasons, here are the ones I can think of:
> 1.- Python is a ~100MB weight dependency.
> 2.- Because of (1) I don not have it installed by default.
> 3.- My Linux distribution of choice defaults to python3 but
> u-boot requires 'python' to be python2.
> 4.- "Shall use C language whenever possible."
> http://www.denx.de/wiki/U-Boot/DesignRequirements
> 5.- It is not just a dependency on what needs to be installed
> on the host, is also a dependency on which programming
> languages u-boot's contributors need to know about.
> So, it can be considered an entry barrier.

Given that most of the recent FDT infrastructure (e.g. tools/dtoc) and
binman are Python, the overall opinion on Python seems to have
changed (and no-one bothered to update the Wiki).

That said: the original python-implementation (i.e. the .py tool in
the rockchip subdirectory) is a bit unfortunate as well, as any processing
of binaries to build a final bootable image should nowadays be included
in binman.

> I don not have strong feelings on this getting merged and certainly
> will not get upset if it does not. It is entirely your decision.
> 
> I have submitted this patch series mostly "for your information" and
> because Philipp thought that it "looks worthwhile”:

Just for the record: I want to have this patch in the mailing-list archive,
so it is archived and can be found by anyone working on this aspect
of our bootup in the future.

I still stand by my initial assessment that it’s worthwhile to not lose this
info and make sure it’s archived ;-)

Thanks,
Philipp.

> On Fri, 1 Jun 2018 00:37:17 +0200, philipp.tomsich at
> theobroma-systems.com wrote:
>> (snip)
>>> On 1 Jun 2018, at 00:28, Vicente Bergas  wrote:
>> (snip)
>>> SPL_FIT_GENERATOR and SPL_OF_PLATDATA require python.
>>> In order to remove this dependency:
>>> 1.- I have written a C version for SPL_FIT_GENERATOR.
>>> 2.- Disabled SPL_OF_PLATDATA, it just works.
>>> 
>>> MKIMAGE_DTC_PATH requires dtc in the PATH.
>>> In order to remove this dependency, I have changed it to use the built-in 
>>> one.
>>> 
>>> If there is interest in those changes, I can post the full patch.
>> 
>> Please submit a patch--it certainly looks worthwhile.
> 
> Regards,
>  Vicenç.

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

Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

[Dr. Philipp Tomsich]

> On 14 Jun 2018, at 19:39, Joe Hershberger  wrote:
> 
> On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
>> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
>> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
>> to enable the RX delay.
>> The MASK was used in a wrong way.
>> 
>> Signed-off-by: Janine Hagemann 
> 
> Acked-by: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 2/3] rk3288: Disable JTAG function from sdmmc0 IO

[Dr. Philipp Tomsich]

On 11 Jun 2018, at 19:08, Carlo Caione  wrote:
> 
> On Mon, 2018-06-11 at 10:41 +0200, Dr. Philipp Tomsich wrote:
>>> On 11 Jun 2018, at 10:08, Carlo Caione  wrote:
> 
> /cut
>>> +#define GRF_SOC_CON0 0xff770244
>>> #define GRF_SOC_CON2 0xff77024c
>> 
>> Could you convert these to ‘const uintptr_t GRF_SOC_CON0 = …’ ?
>> The compiler will generate the same code for a const as if it’s a
>> define, but we’ll
>> have full type-safety.
> 
> Yeah, no problem. But if this is ok with you in v3 I'm going to leave
> this patch as is and adding one more patch to convert both the lines at
> the same time.

Sure. Add another patch and I’ll squash it when applying.

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

Re: [U-Boot] [PATCH v2 2/3] rk3288: Disable JTAG function from sdmmc0 IO

[Dr. Philipp Tomsich]

> On 11 Jun 2018, at 10:08, Carlo Caione  wrote:
> 
> From: Carlo Caione 
> 
> The GRF_SOC_CON0.grf_force_jtag bit is automatically set at boot and it
> is preventing the SDMMC to work correctly. Disable the JTAG function on
> the assumption that a working SD has higher priority over JTAG.
> 
> Signed-off-by: Carlo Caione 
> Reviewed-by: Simon Glass 

Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 

See below for a nitpick ...

> ---
> arch/arm/mach-rockchip/rk3288-board.c | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mach-rockchip/rk3288-board.c 
> b/arch/arm/mach-rockchip/rk3288-board.c
> index 0365793009..bf24d8e074 100644
> --- a/arch/arm/mach-rockchip/rk3288-board.c
> +++ b/arch/arm/mach-rockchip/rk3288-board.c
> @@ -307,6 +307,7 @@ U_BOOT_CMD(
>   ""
> );
> 
> +#define GRF_SOC_CON0 0xff770244
> #define GRF_SOC_CON2 0xff77024c

Could you convert these to ‘const uintptr_t GRF_SOC_CON0 = …’ ?
The compiler will generate the same code for a const as if it’s a define, but 
we’ll
have full type-safety.

> 
> int board_early_init_f(void)
> @@ -339,5 +340,11 @@ int board_early_init_f(void)
>   }
>   rk_setreg(GRF_SOC_CON2, 1 << 0);
> 
> + /*
> +  * Disable JTAG on sdmmc0 IO. The SDMMC won't work until this bit is
> +  * cleared
> +  */
> + rk_clrreg(GRF_SOC_CON0, 1 << 12);
> +
>   return 0;
> }
> -- 
> 2.17.1
> 

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

Re: [U-Boot] [PATCH v2 1/3] rk3288: veyron: Init boot-on regulators

[Dr. Philipp Tomsich]

> On 11 Jun 2018, at 10:08, Carlo Caione  wrote:
> 
> From: Carlo Caione 
> 
> Use regulators_enable_boot_on() to init all the regulators with
> regulator-boot-on property.
> 
> Signed-off-by: Carlo Caione 
> Reviewed-by: Simon Glass 

Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH v2 3/3] rockchip: veyron: Set vcc33_sd regulator value

[Dr. Philipp Tomsich]

> On 11 Jun 2018, at 10:08, Carlo Caione  wrote:
> 
> From: Carlo Caione 
> 
> On the veyron board the vcc33_sd regulator is used as vmmc-supply for
> the SD card. This regulator is powered in the MMC core during power on
> but its value is never actually set.
> 
> In the veyron platform the reset value for the LDO output is 1.8V while
> the standard (min and max) value for this regulator defined in the DTS
> is 3.3V. When the MMC core enable the regulator without setting its
> value, the output is automatically set to 1.8V instead of 3.3V.
> 
> With this patch we preemptively set the value to 3.3V.
> 
> Signed-off-by: Carlo Caione 
> Reviewed-by: Simon Glass 

Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH RESEND 1/2] rockchip: make_fit_atf: use elf entry point

[Dr. Philipp Tomsich]

Mian,

Did you change anything or is this just a resend with the same content?
I didn’t have a chance to review this yet, so wanted to make sure I work off
the latest version...

Thanks,
Philipp.

> On 8 Jun 2018, at 10:47, Mian Yousaf Kaukab  wrote:
> 
> make_fit_atf.py uses physical address of first segment as the
> entry point to bl31. It is incorrect and causes following abort
> when bl31_entry() is called:
> 
> U-Boot SPL board initTrying to boot from MMC1
> "Synchronous Abort" handler, esr 0x0200
> elr:  lr : ff8c7e8c
> x 0: ff8e x 1: 
> x 2:  x 3: ff8e0180
> x 4:  x 5: 
> x 6: 0030 x 7: ff8e0188
> x 8: 01e0 x 9: 
> x10: 0007fcdc x11: 002881b8
> x12: 01a2 x13: 0198
> x14: 0007fdcc x15: 002881b8
> x16: 003c0724 x17: 003c0718
> x18: 0007fe80 x19: ff8e
> x20: 0020 x21: ff8e
> x22:  x23: 0007fe30
> x24: ff8d1c3c x25: ff8d5000
> x26: deadbeef x27: 04a0
> x28: 009c x29: 0007fd90
> 
> Fix it by using the entry point from the elf header.
> 
> Signed-off-by: Mian Yousaf Kaukab 
> ---
> arch/arm/mach-rockchip/make_fit_atf.py | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
> b/arch/arm/mach-rockchip/make_fit_atf.py
> index 6b3d9201c9..b88a5e1f16 100755
> --- a/arch/arm/mach-rockchip/make_fit_atf.py
> +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> @@ -53,7 +53,7 @@ DT_END="""
> };
> """
> 
> -def append_atf_node(file, atf_index, phy_addr):
> +def append_atf_node(file, atf_index, phy_addr, elf_entry):
> """
> Append ATF DT node to input FIT dts file.
> """
> @@ -67,7 +67,7 @@ def append_atf_node(file, atf_index, phy_addr):
> print >> file, '\t\t\tcompression = "none";'
> print >> file, '\t\t\tload = <0x%08x>;' % phy_addr
> if atf_index == 1:
> -print >> file, '\t\t\tentry = <0x%08x>;' % phy_addr
> +print >> file, '\t\t\tentry = <0x%08x>;' % elf_entry
> print >> file, '\t\t};'
> print >> file, ''
> 
> @@ -141,12 +141,13 @@ def generate_atf_fit_dts(fit_file_name, bl31_file_name, 
> uboot_file_name, dtbs_fi
> 
> with open(bl31_file_name) as bl31_file:
> bl31 = ELFFile(bl31_file)
> +elf_entry = bl31.header['e_entry']
> for i in range(bl31.num_segments()):
> seg = bl31.get_segment(i)
> if ('PT_LOAD' == seg.__getitem__(ELF_SEG_P_TYPE)):
> paddr = seg.__getitem__(ELF_SEG_P_PADDR)
> p= seg.__getitem__(ELF_SEG_P_PADDR)
> -append_atf_node(fit_file, i+1, paddr)
> +append_atf_node(fit_file, i+1, paddr, elf_entry)
> atf_cnt = i+1
> append_fdt_node(fit_file, dtbs_file_name)
> print >> fit_file, '%s' % DT_IMAGES_NODE_END
> --
> 2.11.0
> 



signature.asc
Description: Message signed with OpenPGP
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] rockchip: rk3399: spl: add missing \n to output

[Dr. Philipp Tomsich]

> On 3 Jun 2018, at 21:10, Heinrich Schuchardt  wrote:
> 
> Without the patch SPL (in case of an error) creates an output like:
> 
>   U-Boot SPL board initMissing DTB
> 
> The patch adds the missing line feed. So now we get:
> 
>   U-Boot SPL board init
>   Missing DTB
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH 1/1] rockchip: evb-rk3399: correct README for board bring up

[Dr. Philipp Tomsich]

> On 3 Jun 2018, at 16:50, Heinrich Schuchardt  wrote:
> 
> %s/rkflashtool/rkdeveloptool/
> 
> We are using rkdeveloptool not rkflashtool.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 

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

Re: [U-Boot] Exception Level switching seems broken on RK3399

[Dr. Philipp Tomsich]

Vincente,

> On 1 Jun 2018, at 00:28, Vicente Bergas  wrote:
> 
> On Thu, May 24, 2018 at 7:05 PM, Dr. Philipp Tomsich
>  wrote:
>> Vincente,
>> 
>> On 24 May 2018, at 18:48, Vicente Bergas  wrote:
>> 
>> Hello Philipp,
>> your answer is much appreciated.
>> 
>> On Thu, May 24, 2018 at 1:07 PM, Dr. Philipp Tomsich
>>  wrote:
>> 
>> Vincente,
>> 
>> On 19 May 2018, at 16:58, Vicente Bergas  wrote:
>> 
>> Hello,
>> I am writing this from a standalone Sapphire board [1],
>> that is, without the Excavator base board.
>> The CPU is the Rockchip RK3399, which implements ARMv8.0-A.
>> 
>> Currently the boot process is:
>> 1.- Boot ROM
>> 2.- SPL, provided as closed source binary blob [2]
>> 
>> 
>> SPL-support is available in mainline U-Boot.  We developed this for
>> the RK3399-Q7 and it has been successfully used on other RK3399
>> boards (e.g. I know that some Firefly-users are using this).
>> 
>> 
>> Thank you!
>> 
>> 
>> 3.- ATF, closed source binary blob [3]
>>   (not using the one from [2] because of stability issues)
>> 
>> 
>> Why use the closed-source blob, if the RK3399 is supported in the ATF
>> mainline and an ATF can be compiled from source?
>> 
>> 
>> Currently I am using both binary blobs (SPL and ATF) because I could
>> not make it work another way. I'll give it another try.
>> 
>> 
>> 4.- Mainline u-boot, master branch
>> 5.- Mainline linux, master branch
>> 
>> I would like to use an opensource boot process.
>> As a first approach I try to completely remove the ATF and
>> replace the SPL with the one from u-boot.
>> The modified boot process looks like:
>> 1.- Boot ROM
>> 2.- SPL, from mainline u-boot, master branch
>> 3.- Mainline u-boot, master branch
>> 4.- Mainline linux, master branch
>> But it is not working.
>> 
>> The replaced SPL works fine and loads u-boot.
>> U-boot also works fine, loads linux and jumps into it.
>> 
>> 
>> Yes, we’ve done some work to enable us to run U-Boot in EL3 on
>> the RK3399 (as we use it for programming the secure e-fuses on
>> the RK3399-Q7 in our factory programming setup).
>> 
>> 
>> I can indeed confirm that U-Boot runs fine in EL3.
>> 
>> 
>> But then, linux never gets executed.
>> 
>> I have traced the issue to: arch/arm/include/asm/macro.h
>> 202: msr  spsr_el3, \tmp
>> 203: msr  elr_el3, \ep
>> 204: eret // This is the last instruction executed
>> 
>> For testing, I have also set CONFIG_ARMV8_SWITCH_TO_EL1 and
>> checked that switch_to_el1 from arch/arm/lib/bootm.c is not reached.
>> 
>> At this point I have a few questions:
>> 1.- Is my first approach feasible? That is, is it possible to boot
>>   this CPU without ATF?
>> 
>> 
>> It is feasible (i.e.: requires implementation work) but not recommended:
>> Linux will use PSCI to bring up the secondary CPUs.  We have run Linux
>> (limited to a single CPU) in EL3 on this CPU during our own board bringup,
>> but I would strongly discourage this as it will entail unnecessary effort.
>> 
>> 
>> There is a misunderstanding here. My intention was to run U-Boot in EL3,
>> then switch to EL2 or EL1 from within U-Boot and afterwards run Linux
>> in the lower EL.
>> 
>> 
>> 2.- If so, what should I do to make it work? Probably it is just
>>   a configuration issue, but I do not know what to check. [4]
>> 3.- Else, why do I need ATF?
>> 
>> 
>> ATF is the secure monitor on ARMv8 and provides services such as PSCI
>> to start up secondary CPUs.  It will usually also be part of
>> power-management
>> on most SoCs (after all: power configuration needs to be done in the secure
>> envelope).
>> 
>> 
>> Do you mean that without ATF I can only run a single CPU core?
>> 
>> 
>> Linux (on the RK3399) uses PSCI to start the secondary CPUs and uses SMC
>> (secure monitor call) to call into PSCI.  The PSCI handlers thus live within
>> ATF.
>> 
>> While it is technically possible to start up the other cores using other
>> mechanisms,
>> it is the ‘road less travelled’.
>> 
>> Cheers,
>> Philipp.
>> 
>> 
>> Regards,
>> Vicenç.
>> 
>> 
>> Regards,
>> Philipp.
>> 
>> 
>> Regards,
>> Vicenç.
> 
> Hello Philipp,
> I have managed to make it work. It turns out that support for
> this platform was added to mainl

Re: [U-Boot] [PATCH] rtc: Add read8 and write8 support to isl1208 driver

[Dr. Philipp Tomsich]

> On 31 May 2018, at 20:14, Trent Piepho  wrote:
> 
> This can be used for device register access from board code.
> 
> This allows access to capabilities in the RTC chip not abstracted in
> U-Boot's RTC class.  E.g., device NVRAM or a tamper detection circuit.
> 
> Cc: Klaus Goger 
> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Signed-off-by: Trent Piepho 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH v1 1/4] spl: record boot_device into spl_image and call spl_perform_fixups

[Dr. Philipp Tomsich]

Lukasz,

> On 25 May 2018, at 00:11, Lukasz Majewski  wrote:
> 
> Hi Philipp,
> 
>> On some boards, we want to give the board/architecture-specific code a
>> chance to look at where the next image has been loaded from and
>> perform fixups before starting the next image.  This is of particular
>> importance, when we probe multiple devices for bootable payloads and
>> boot the first one found.
>> 
>> This change adds the following:
>> - we record the boot_device used into the spl_image structure
>> - we provide an extension-point for boards/architectures that can
>>   perform late fixups depending on a fully populated spl_image
>>   structure (i.e. we'll know the final boot_device and have info
>>   on the image type and operating system to be booted).
>> 
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>> ---
>> 
>> common/spl/spl.c | 12 +++-
>> include/spl.h|  7 +++
>> 2 files changed, 18 insertions(+), 1 deletion(-)
>> 
>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>> index a09ada3..a1e7b9f 100644
>> --- a/common/spl/spl.c
>> +++ b/common/spl/spl.c
>> @@ -80,6 +80,11 @@ int __weak bootz_setup(ulong image, ulong *start,
>> ulong *end) }
>> #endif
>> 
>> +/* Weak default function for arch/board-specific fixups to the
>> spl_image_info */ +void __weak spl_perform_fixups(struct
>> spl_image_info *spl_image) +{
>> +}
>> +
>> void spl_fixup_fdt(void)
>> {
>> #if defined(CONFIG_SPL_OF_LIBFDT) &&
>> defined(CONFIG_SYS_SPL_ARGS_ADDR) @@ -445,8 +450,10 @@ static int
>> boot_from_devices(struct spl_image_info *spl_image, else
>>  puts("SPL: Unsupported Boot Device!\n");
>> #endif
>> -if (loader && !spl_load_image(spl_image, loader))
>> +if (loader && !spl_load_image(spl_image, loader)) {
>> +spl_image->boot_device = spl_boot_list[i];
>>  return 0;
>> +}
>>  }
>> 
>>  return -ENODEV;
>> @@ -498,6 +505,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>> #ifdef CONFIG_SYS_SPL_ARGS_ADDR
>>  spl_image.arg = (void *)CONFIG_SYS_SPL_ARGS_ADDR;
>> #endif
>> +spl_image.boot_device = BOOT_DEVICE_NONE;
>>  board_boot_order(spl_boot_list);
>> 
>>  if (boot_from_devices(_image, spl_boot_list,
>> @@ -506,6 +514,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>>  hang();
>>  }
>> 
>> +spl_perform_fixups(_image);
>> +
>> #ifdef CONFIG_CPU_V7M
>>  spl_image.entry_point |= 0x1;
>> #endif
>> diff --git a/include/spl.h b/include/spl.h
>> index 8454ea7..8628787 100644
>> --- a/include/spl.h
>> +++ b/include/spl.h
>> @@ -29,6 +29,7 @@ struct spl_image_info {
>> #if CONFIG_IS_ENABLED(LOAD_FIT)
>>  void *fdt_addr;
>> #endif
>> +u32 boot_device;
>>  u32 size;
>>  u32 flags;
>>  void *arg;
>> @@ -296,4 +297,10 @@ void spl_invoke_atf(struct spl_image_info
>> *spl_image);
>>  * can implement 'board_return_to_bootrom'.
>>  */
>> void board_return_to_bootrom(void);
>> +
>> +/**
>> + * spl_perform_fixups() - arch/board-specific callback before
>> processing
>> + *the boot-payload
>> + */
>> +void spl_perform_fixups(struct spl_image_info *spl_image);
>> #endif
> 
> Have I understood correctly that after applying this patch I can define
> my own spl_perform_fixup() function in my board's spl.c and then decide
> if I want to boot kernel/u-boot proper from eMMC, even if I started the
> boot process from SPI-NOR (where SPL is placed) ?

Starting from SPI-NOR and then continuing from eMMC is already possible
using other mechanisms (e.g. we use FIT images and the boot device list
infrastructure)… so no, this is something different.

This was implemented for the full U-Boot to decide where to boot the OS from.
Our use-case is that if SPL boots the full U-Boot from external storage, we’d 
like
to continue booting from external storage.

Patches 3 + 4 from the series show an example implementation for our RK3399-Q7:
- patch 3 injects a property into the DTS seen by the full U-Boot stage
- patch 4 uses this to change the order of mmc0 and mmc1 in the env for 
distroboot

> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Exception Level switching seems broken on RK3399

[Dr. Philipp Tomsich]

Vincente,

> On 24 May 2018, at 18:48, Vicente Bergas <vice...@gmail.com> wrote:
> 
> Hello Philipp,
> your answer is much appreciated.
> 
> On Thu, May 24, 2018 at 1:07 PM, Dr. Philipp Tomsich
> <philipp.toms...@theobroma-systems.com 
> <mailto:philipp.toms...@theobroma-systems.com>> wrote:
>> Vincente,
>> 
>>> On 19 May 2018, at 16:58, Vicente Bergas <vice...@gmail.com> wrote:
>>> 
>>> Hello,
>>> I am writing this from a standalone Sapphire board [1],
>>> that is, without the Excavator base board.
>>> The CPU is the Rockchip RK3399, which implements ARMv8.0-A.
>>> 
>>> Currently the boot process is:
>>> 1.- Boot ROM
>>> 2.- SPL, provided as closed source binary blob [2]
>> 
>> SPL-support is available in mainline U-Boot.  We developed this for
>> the RK3399-Q7 and it has been successfully used on other RK3399
>> boards (e.g. I know that some Firefly-users are using this).
> 
> Thank you!
> 
>> 
>>> 3.- ATF, closed source binary blob [3]
>>>(not using the one from [2] because of stability issues)
>> 
>> Why use the closed-source blob, if the RK3399 is supported in the ATF
>> mainline and an ATF can be compiled from source?
> 
> Currently I am using both binary blobs (SPL and ATF) because I could
> not make it work another way. I'll give it another try.
> 
>> 
>>> 4.- Mainline u-boot, master branch
>>> 5.- Mainline linux, master branch
>>> 
>>> I would like to use an opensource boot process.
>>> As a first approach I try to completely remove the ATF and
>>> replace the SPL with the one from u-boot.
>>> The modified boot process looks like:
>>> 1.- Boot ROM
>>> 2.- SPL, from mainline u-boot, master branch
>>> 3.- Mainline u-boot, master branch
>>> 4.- Mainline linux, master branch
>>> But it is not working.
>>> 
>>> The replaced SPL works fine and loads u-boot.
>>> U-boot also works fine, loads linux and jumps into it.
>> 
>> Yes, we’ve done some work to enable us to run U-Boot in EL3 on
>> the RK3399 (as we use it for programming the secure e-fuses on
>> the RK3399-Q7 in our factory programming setup).
> 
> I can indeed confirm that U-Boot runs fine in EL3.
> 
>> 
>>> But then, linux never gets executed.
>>> 
>>> I have traced the issue to: arch/arm/include/asm/macro.h
>>> 202: msr  spsr_el3, \tmp
>>> 203: msr  elr_el3, \ep
>>> 204: eret // This is the last instruction executed
>>> 
>>> For testing, I have also set CONFIG_ARMV8_SWITCH_TO_EL1 and
>>> checked that switch_to_el1 from arch/arm/lib/bootm.c is not reached.
>>> 
>>> At this point I have a few questions:
>>> 1.- Is my first approach feasible? That is, is it possible to boot
>>>this CPU without ATF?
>> 
>> It is feasible (i.e.: requires implementation work) but not recommended:
>> Linux will use PSCI to bring up the secondary CPUs.  We have run Linux
>> (limited to a single CPU) in EL3 on this CPU during our own board bringup,
>> but I would strongly discourage this as it will entail unnecessary effort.
> 
> There is a misunderstanding here. My intention was to run U-Boot in EL3,
> then switch to EL2 or EL1 from within U-Boot and afterwards run Linux
> in the lower EL.
> 
>> 
>>> 2.- If so, what should I do to make it work? Probably it is just
>>>a configuration issue, but I do not know what to check. [4]
>>> 3.- Else, why do I need ATF?
>> 
>> ATF is the secure monitor on ARMv8 and provides services such as PSCI
>> to start up secondary CPUs.  It will usually also be part of power-management
>> on most SoCs (after all: power configuration needs to be done in the secure
>> envelope).
> 
> Do you mean that without ATF I can only run a single CPU core?

Linux (on the RK3399) uses PSCI to start the secondary CPUs and uses SMC
(secure monitor call) to call into PSCI.  The PSCI handlers thus live within 
ATF.

While it is technically possible to start up the other cores using other 
mechanisms,
it is the ‘road less travelled’.

Cheers,
Philipp.

> 
> Regards,
>  Vicenç.
> 
>> 
>> Regards,
>> Philipp.
>> 
>>> 
>>> Regards,
>>> Vicenç.
>>> 
>>> [1] http://opensource.rock-chips.com/wiki_Excavator_sapphire_board
>>> [2] https://github.com/rockchip-linux/rkbin/tree/29mirror
>>> [3] 
>>> https://raw.githubusercontent.com/nightseas/armbian-build/master/packages/blobs/rockchip64/trust.img
>>> 

Re: [U-Boot] Exception Level switching seems broken on RK3399

[Dr. Philipp Tomsich]

Vincente,

> On 19 May 2018, at 16:58, Vicente Bergas  wrote:
> 
> Hello,
> I am writing this from a standalone Sapphire board [1],
> that is, without the Excavator base board.
> The CPU is the Rockchip RK3399, which implements ARMv8.0-A.
> 
> Currently the boot process is:
> 1.- Boot ROM
> 2.- SPL, provided as closed source binary blob [2]

SPL-support is available in mainline U-Boot.  We developed this for
the RK3399-Q7 and it has been successfully used on other RK3399
boards (e.g. I know that some Firefly-users are using this).

> 3.- ATF, closed source binary blob [3]
> (not using the one from [2] because of stability issues)

Why use the closed-source blob, if the RK3399 is supported in the ATF
mainline and an ATF can be compiled from source?

> 4.- Mainline u-boot, master branch
> 5.- Mainline linux, master branch
> 
> I would like to use an opensource boot process.
> As a first approach I try to completely remove the ATF and
> replace the SPL with the one from u-boot.
> The modified boot process looks like:
> 1.- Boot ROM
> 2.- SPL, from mainline u-boot, master branch
> 3.- Mainline u-boot, master branch
> 4.- Mainline linux, master branch
> But it is not working.
> 
> The replaced SPL works fine and loads u-boot.
> U-boot also works fine, loads linux and jumps into it.

Yes, we’ve done some work to enable us to run U-Boot in EL3 on
the RK3399 (as we use it for programming the secure e-fuses on
the RK3399-Q7 in our factory programming setup).

> But then, linux never gets executed.
> 
> I have traced the issue to: arch/arm/include/asm/macro.h
> 202: msr  spsr_el3, \tmp
> 203: msr  elr_el3, \ep
> 204: eret // This is the last instruction executed
> 
> For testing, I have also set CONFIG_ARMV8_SWITCH_TO_EL1 and
> checked that switch_to_el1 from arch/arm/lib/bootm.c is not reached.
> 
> At this point I have a few questions:
> 1.- Is my first approach feasible? That is, is it possible to boot
> this CPU without ATF?

It is feasible (i.e.: requires implementation work) but not recommended:
Linux will use PSCI to bring up the secondary CPUs.  We have run Linux
(limited to a single CPU) in EL3 on this CPU during our own board bringup,
but I would strongly discourage this as it will entail unnecessary effort.

> 2.- If so, what should I do to make it work? Probably it is just
> a configuration issue, but I do not know what to check. [4]
> 3.- Else, why do I need ATF?

ATF is the secure monitor on ARMv8 and provides services such as PSCI
to start up secondary CPUs.  It will usually also be part of power-management
on most SoCs (after all: power configuration needs to be done in the secure
envelope).

Regards,
Philipp.

> 
> Regards,
>  Vicenç.
> 
> [1] http://opensource.rock-chips.com/wiki_Excavator_sapphire_board
> [2] https://github.com/rockchip-linux/rkbin/tree/29mirror
> [3] 
> https://raw.githubusercontent.com/nightseas/armbian-build/master/packages/blobs/rockchip64/trust.img
> [4]
> CONFIG_ARM=y
> CONFIG_ARCH_ROCKCHIP=y
> CONFIG_SYS_TEXT_BASE=0x0020
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> CONFIG_SYS_MALLOC_F_LEN=0x4000
> CONFIG_ROCKCHIP_RK3399=y
> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> CONFIG_SPL_STACK_R_ADDR=0x8
> # CONFIG_PSCI_RESET is not set
> CONFIG_CMD_HDMIDETECT=y
> CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
> CONFIG_DEBUG_UART=y
> CONFIG_BOOTDELAY=1
> # CONFIG_DISPLAY_CPUINFO is not set
> # CONFIG_DISPLAY_BOARDINFO is not set
> CONFIG_SPL_STACK_R=y
> CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> # CONFIG_CMD_IMI is not set
> # CONFIG_CMD_XIMG is not set
> # CONFIG_CMD_SAVEENV is not set
> # CONFIG_CMD_FLASH is not set
> # CONFIG_CMD_LOADB is not set
> # CONFIG_CMD_LOADS is not set
> CONFIG_CMD_MMC=y
> CONFIG_CMD_USB=y
> # CONFIG_CMD_SETEXPR is not set
> # CONFIG_CMD_NET is not set
> # CONFIG_DOS_PARTITION is not set
> # CONFIG_ISO_PARTITION is not set
> CONFIG_SPL_OF_CONTROL=y
> CONFIG_REGMAP=y
> CONFIG_SPL_REGMAP=y
> CONFIG_SYSCON=y
> CONFIG_SPL_SYSCON=y
> CONFIG_CLK=y
> CONFIG_SPL_CLK=y
> CONFIG_ROCKCHIP_GPIO=y
> CONFIG_SYS_I2C_ROCKCHIP=y
> # CONFIG_MMC_WRITE is not set
> # CONFIG_MMC_HW_PARTITIONING is not set
> CONFIG_MMC_DW=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_ROCKCHIP=y
> CONFIG_DM_ETH=y
> # CONFIG_NETDEVICES is not set
> CONFIG_PINCTRL=y
> CONFIG_SPL_PINCTRL=y
> CONFIG_PINCTRL_ROCKCHIP_RK3399=y
> CONFIG_DM_PMIC=y
> CONFIG_PMIC_RK8XX=y
> CONFIG_REGULATOR_PWM=y
> CONFIG_DM_REGULATOR_FIXED=y
> CONFIG_REGULATOR_RK8XX=y
> CONFIG_PWM_ROCKCHIP=y
> CONFIG_RAM=y
> CONFIG_SPL_RAM=y
> CONFIG_BAUDRATE=150
> CONFIG_DEBUG_UART_BASE=0xFF1A
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_GENERIC=y
> CONFIG_USB_STORAGE=y
> CONFIG_USB_KEYBOARD=y
> CONFIG_USB_HOST_ETHER=y
> CONFIG_USB_ETHER_ASIX=y
> CONFIG_USB_ETHER_ASIX88179=y
> CONFIG_USB_ETHER_MCS7830=y
> CONFIG_USB_ETHER_RTL8152=y
> 

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

Marty,

> On 19 May 2018, at 12:40, Marty E. Plummer <hanet...@startmail.com> wrote:
> 
> On Mon, May 14, 2018 at 05:56:27PM +0200, Dr. Philipp Tomsich wrote:
>> I had a bit more time to look into this and it looks as if we have two 
>> problem-spots...
>> 
>> First, there's a type-mismatch between ram_info.size (a size_t) and 
>> gd.ram_size (phys_size_t).
>> While we can increase the size of a phys_size_t to 64bit (by defining 
>> CONFIG_PHYS_64BIT),
>> the size_t will always be an unsigned int on a 32bit arm architecture.  So 
>> here's one possible
>> pitfall that should be resolved.
>> 
>> Once this is adjusted, we might just increase the width of ram_info.size to 
>> 64bit by enabling
>> CONFIG_PHYS_64BIT ... however, this comes with a caveat: the default cell 
>> sizes for the
>> FDT (via fdtdec) also increases.  I.e. if any come in our arch or the 
>> drivers still goes through
>> the fdtdec-functions, we'll end up with a problem.
>> 
>> As my test coverage is limited to 64bit targets, I can't tell whether 
>> defining the PHYS_64BIT
>> configuration would be possible for the RK3288 -- if it is, we'd have a 
>> rather easy way forward
>> and could reuse the phys_size_t for ram_info.size.
>> 
>> I'd appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us 
>> into a lot
>> of trouble on the RK3288 or whether this will trigger just a few minor 
>> adjustments...
>> 
>> Thanks,
>> Philipp.
> 
> So explain to me what you'd like me to do here, if you would. What I
> gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it
> works or what? I can flash/reflash u-boot and coreboot pretty easily on
> the device, so I'm down for any sort of hardware testing needed to get
> this into a usable state.

Yes, just enable PHYS_64BIT and report on how far it goes (activating some
debug may be helpful to understand what goes wrong, if it fails).

My gut feeling is that it could work, but there’s a number of pitfalls and we 
may
not be lucky.

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

I had a bit more time to look into this and it looks as if we have two 
problem-spots...

First, there's a type-mismatch between ram_info.size (a size_t) and gd.ram_size 
(phys_size_t).
While we can increase the size of a phys_size_t to 64bit (by defining 
CONFIG_PHYS_64BIT),
the size_t will always be an unsigned int on a 32bit arm architecture.  So 
here’s one possible
pitfall that should be resolved.

Once this is adjusted, we might just increase the width of ram_info.size to 
64bit by enabling
CONFIG_PHYS_64BIT … however, this comes with a caveat: the default cell sizes 
for the
FDT (via fdtdec) also increases.  I.e. if any come in our arch or the drivers 
still goes through
the fdtdec-functions, we’ll end up with a problem.

As my test coverage is limited to 64bit targets, I can’t tell whether defining 
the PHYS_64BIT
configuration would be possible for the RK3288 — if it is, we’d have a rather 
easy way forward
and could reuse the phys_size_t for ram_info.size.

I’d appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us 
into a lot
of trouble on the RK3288 or whether this will trigger just a few minor 
adjustments…

Thanks,
Philipp.

> On 9 May 2018, at 09:24, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
>> 
>> On 9 May 2018, at 07:29, Marty E. Plummer <hanet...@startmail.com> wrote:
>> 
>> On Tue, May 08, 2018 at 11:08:14PM +0200, Dr. Philipp Tomsich wrote:
>>> 
>>>> On 8 May 2018, at 21:21, Marty E. Plummer <hanet...@startmail.com> wrote:
>>>> 
>>>> On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
>>>>> Marty,
>>>>> 
>>>>>> On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
>>>>>> 
>>>>>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>>>>>> 
>>>>>>>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>>>>>>>>> Hi Marty,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>>>>>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>>>>>>>>> 
>>>>>>>>>> Without this change, my u-boot build for the asus c201 chromebook 
>>>>>>>>>> (4GiB)
>>>>>>>>>> is incorrectly detected as 0 Bytes of ram.
>>>>>>>>> 
>>>>>>>>> I know the root cause for this issue, and I have a local patch for it.
>>>>>>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>>>>>>>>> before
>>>>>>>>> the max size before return with '<<20'. Sorry for forgot to send it 
>>>>>>>>> out.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
>>>>>>>>>> ---
>>>>>>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 
>>>>>>>>>> ---
>>>>>>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>>>>>>>>> 
>>>>>>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>>>>>>>>> b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>>>>> index 76dbdc8715..a9c9f970a4 100644
>>>>>>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>>>>>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>>>>> @@ -10,6 +10,8 @@
>>>>>>>>>> #include 
>>>>>>>>>> #include 
>>>>>>>>>> #include 
>>>>>>>>>> +#include 
>>>>>>>>>> +#include 
>>>>>>>>>> 
>>>>>>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>>>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>>>>>  size_t size_mb = 0;
>>>>>>>>>>  u32 ch;
>>>>&

Re: [U-Boot] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Travis report (prior to a final rebase onto your latest master) is at
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/378666041

> On 14 May 2018, at 17:32, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
> Tom,
> 
> I have two fixes for regressions (that unfortunately ended up in the last 
> release) in my tree,
> ready for a merge onto master.
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit ca70cbabdcd19bf157ae4fa984559b126071ccff:
> 
>  Merge git://git.denx.de/u-boot-marvell (2018-05-14 08:52:48 -0400)
> 
> are available in the git repository at:
> 
>  git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to ed1030e1523541801ae1e36bc34ee6872d474184:
> 
>  rockchip: clk: rk3288: handle clk_enable requests for GMAC (2018-05-14 
> 17:30:40 +0200)
> 
> 
> Jonathan Gray (2):
>  rockchip: set SYS_NS16550_MEM32 for all SoCs
>  rockchip: clk: rk3288: handle clk_enable requests for GMAC
> 
> drivers/clk/rockchip/clk_rk3288.c | 10 ++
> include/configs/rockchip-common.h |  2 ++
> 2 files changed, 12 insertions(+)
> 

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

[U-Boot] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Tom,

I have two fixes for regressions (that unfortunately ended up in the last 
release) in my tree,
ready for a merge onto master.

Thanks,
Philipp.


The following changes since commit ca70cbabdcd19bf157ae4fa984559b126071ccff:

  Merge git://git.denx.de/u-boot-marvell (2018-05-14 08:52:48 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to ed1030e1523541801ae1e36bc34ee6872d474184:

  rockchip: clk: rk3288: handle clk_enable requests for GMAC (2018-05-14 
17:30:40 +0200)


Jonathan Gray (2):
  rockchip: set SYS_NS16550_MEM32 for all SoCs
  rockchip: clk: rk3288: handle clk_enable requests for GMAC

 drivers/clk/rockchip/clk_rk3288.c | 10 ++
 include/configs/rockchip-common.h |  2 ++
 2 files changed, 12 insertions(+)

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

Re: [U-Boot] [PATCH v2] Makefile: adopt --std=gnu11 for HOSTCFLAGS on Linux

[Dr. Philipp Tomsich]

> On 14 May 2018, at 16:53, Mark Kettenis  wrote:
> 
>> From: Philipp Tomsich 
>> Date: Mon, 14 May 2018 15:22:06 +0200
>> 
>> Following the conversion of the SPDX license tags, a number of files
>> compiled with -pedantic now generate warnings similar to the following
>> for using C99-style '//' comments in ISO C90 code:
>> 
>>  tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
>> ISO C90
>>   // SPDX-License-Identifier: GPL-2.0+
>>   ^
>> 
>> The SPDX comment-style change means that these files have adopted C99,
>> so need to change the language-standard to --std=gnu99 or --std=gnu11
>> to let the compiler know this.
>> 
>> As we now require GCC 6 or newer for the cross-compiler, the project has
>> implicitly moved the project to GNU11: let older GCC versions on various
>> Linux distros know to treat our host tools as GNU11 as well.
> 
> Note that the requirement is on the cross-compiler, not the host
> compiler.  On our "primary" architectures OpenBSD 6.3 ships with Clang
> 5.0.1 and the current development version uses Clang 6.0.0, which
> default to --std=gnu11.  I do hope those will continue to be supported
> as the host compiler…

Many of the files in question (e.g. lib/sha{1,256}.c) are shared between
the target and the host tools.

>> References: commit 83d290c56fab ("SPDX: Convert all of our single license 
>> tags to Linux Kernel style")
>> Signed-off-by: Philipp Tomsich 
>> ---
>> 
>> Changes in v2:
>> - Set '--std=gnu11' during compilation of host tools on Linux.
>> 
>> Makefile | 9 +
>> 1 file changed, 9 insertions(+)
>> 
>> diff --git a/Makefile b/Makefile
>> index f31ee60..d08fb6a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -258,6 +258,15 @@ HOSTCFLAGS   = -Wall -Wstrict-prototypes -O2 
>> -fomit-frame-pointer \
>>  $(if $(CONFIG_TOOLS_DEBUG),-g)
>> HOSTCXXFLAGS = -O2
>> 
>> +# With the move to GCC 6, we have implicitly upgraded our language
>> +# standard to GNU11 (see https://gcc.gnu.org/gcc-5/porting_to.html).
>> +# Some Linux distributions (including RHEL7, SLES13, Debian 8) still
>> +# have older compilers as their default, so we make it explicit for
>> +# these that our host tools are GNU11 (i.e. C11 w/ GNU extensions).
>> +ifeq ($(HOSTOS),linux)
>> +HOSTCFLAGS += --std=gnu11
>> +endif
>> +
>> ifeq ($(HOSTOS),cygwin)
>> HOSTCFLAGS   += -ansi
>> endif
>> -- 
>> 2.1.4
>> 
>> ___
>> 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] tools: adopt --std=gnu99 where C99 comments are needed

[Dr. Philipp Tomsich]

While it’s not directly related to this patch, we should clearly state that
the U-Boot code base (with the possible exception of the tools/ directory,
which I have started touching here) has _implicitly_ moved to GNU11 
(yes, even newer than C99), when be upgraded beyond GCC 5.

For reference, see the "Default standard is now GNU11” section at 
https://gcc.gnu.org/gcc-5/porting_to.html

Do we want to
(a) document this somewhere (which file in doc/ would be appropriate?)
(b) explicitly set the “--std=“ flag to make sure that people (and their 
compilers)
are aware of this?

Thanks,
Philipp.

> On 14 May 2018, at 13:53, Philipp Tomsich 
>  wrote:
> 
> Following the conversion of the SPDX license tags, a number of files
> compiled with -pedantic now generate warnings similar to the following
> for using C99-style '//' comments in ISO C90 code:
> 
>  tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in ISO 
> C90
>   // SPDX-License-Identifier: GPL-2.0+
>   ^
> 
> The SPDX comment-style change means that these files have adopted C99,
> so we change the language-standard to --std=gnu99 to let the compiler
> know this.
> 
> References: commit 83d290c56fab ("SPDX: Convert all of our single license 
> tags to Linux Kernel style")
> Signed-off-by: Philipp Tomsich 
> ---
> 
> tools/Makefile | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 5dd33ed..079d902 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -38,11 +38,11 @@ hostprogs-$(CONFIG_BUILD_ENVCRC) += envcrc
> envcrc-objs := envcrc.o lib/crc32.o env/embedded.o lib/sha1.o
> 
> hostprogs-$(CONFIG_CMD_NET) += gen_eth_addr
> -HOSTCFLAGS_gen_eth_addr.o := -pedantic
> +HOSTCFLAGS_gen_eth_addr.o := --std=gnu99 -pedantic
> 
> hostprogs-$(CONFIG_CMD_NET) += gen_ethaddr_crc
> gen_ethaddr_crc-objs := gen_ethaddr_crc.o lib/crc8.o
> -HOSTCFLAGS_gen_ethaddr_crc.o := -pedantic
> +HOSTCFLAGS_gen_ethaddr_crc.o := --std=gnu99 -pedantic
> 
> hostprogs-$(CONFIG_CMD_LOADS) += img2srec
> HOSTCFLAGS_img2srec.o := -pedantic
> @@ -200,10 +200,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
> # that won't build on some weird host compiler -- though there are lots of
> # exceptions for files that aren't complaint.
> HOSTCFLAGS_crc32.o := -pedantic
> -HOSTCFLAGS_crc8.o := -pedantic
> +HOSTCFLAGS_crc8.o := --std=gnu99 -pedantic
> HOSTCFLAGS_md5.o := -pedantic
> -HOSTCFLAGS_sha1.o := -pedantic
> -HOSTCFLAGS_sha256.o := -pedantic
> +HOSTCFLAGS_sha1.o := --std=gnu99 -pedantic
> +HOSTCFLAGS_sha256.o := --std=gnu99 -pedantic
> 
> quiet_cmd_wrap = WRAP$@
> cmd_wrap = echo "\#include <../$(patsubst $(obj)/%,%,$@)>" >$@
> -- 
> 2.1.4
> 

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

Re: [U-Boot] rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC

[Dr. Philipp Tomsich]

> On 14 May 2018, at 12:42, Jonathan Gray <j...@jsg.id.au> wrote:
> 
> On Mon, May 14, 2018 at 11:28:38AM +0200, Wadim Egorov wrote:
>> Hi,
>> 
>> 
>> Am 08.05.2018 um 10:05 schrieb Dr. Philipp Tomsich:
>>> Looks like the designware GMAC driver is trying to enable a clock and
>>> can???t deal with the -ENOENT.  Could you try to see which clock it is
>>> requesting and add the necessary entries in the clock-enable function?
>>> 
>>> If you have a patch, I???ll try to prioritise it, so we get these 
>>> regressions
>>> cleaned up quickly (note that these had all been in rc3???if we???d known
>>> earlier, I could have reverted them out for the release).
>>> 
>>> @Wadim: could you please also look into this, as your board should have
>>> similar problems (unless your device-tree is very different). 
>> unfortunately I am not able to test ethernet on our board right now,
>> because there are a few things missing in the designware/gmac part.
>> But someone is working on it right now :)
>> 
>> Anyway, it looks like Jonathan fixed the problem, right?
>> 
>> Regards,
>> Wadim
> 
> The patch I sent out works for me.  Hasn't landed in u-boot-rockchip or
> master yet though.

I had been waiting for Wadim to also take a look.  I’ll take his remark as
a “can’t test” and will move it along.

I plan to request a pull into master, once we have all these regression fixes
collected (I hope this is the last one).

> 
>> 
>>> 
>>> Thanks,
>>> Philipp.
>>> 
>>>> On 8 May 2018, at 09:51, Jonathan Gray <j...@jsg.id.au> wrote:
>>>> 
>>>> On Thu, Apr 26, 2018 at 09:05:33AM +0200, Philipp Tomsich wrote:
>>>>>> The generic ehci-driver (ehci-generic.c) will try to enable the clocks
>>>>>> listed in the DTSI. If this fails (e.g. due to clk_enable not being
>>>>>> implemented in a driver and -ENOSYS being returned by the clk-uclass),
>>>>>> the driver will bail our and print an error message.
>>>>>> 
>>>>>> This implements a minimal clk_enable for the RK3288 and supports the
>>>>>> clocks mandatory for the EHCI controllers; as these are enabled by
>>>>>> default we simply return success.
>>>>>> 
>>>>>> Signed-off-by: Wadim Egorov <w.ego...@phytec.de>
>>>>>> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
>>>>>> Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
>>>>>> ---
>>>>>> drivers/clk/rockchip/clk_rk3288.c | 13 +
>>>>>> 1 file changed, 13 insertions(+)
>>>>>> 
>>>>> Applied to u-boot-rockchip, thanks!
>>>> This change broke Ethernet on tinker-rk3288.
>>>> 
>>>> U-Boot 2018.05-2-g6ea9f3dd70 (May 08 2018 - 17:21:32 +1000)
>>>> 
>>>> Model: Tinker-RK3288
>>>> DRAM:  2 GiB
>>>> MMC:   dwmmc@ff0c: 1
>>>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>>>> environment
>>>> 
>>>> Failed (-5)
>>>> In:serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Model: Tinker-RK3288
>>>> Net:   failed to enable clock 0
>>>> No ethernet found.
>>>> 
>>>> After reverting it:
>>>> 
>>>> U-Boot 2018.05-3-g338bfe2fbf (May 08 2018 - 17:40:09 +1000)
>>>> 
>>>> Model: Tinker-RK3288
>>>> DRAM:  2 GiB
>>>> MMC:   dwmmc@ff0c: 1
>>>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>>>> environment
>>>> 
>>>> Failed (-5)
>>>> In:serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Model: Tinker-RK3288
>>>> Net:   eth0: ethernet@ff29
>>>> Hit any key to stop autoboot:  0
>>>> 
>>>> If the default case returned ENOSYS or ENOTSUPP instead of ENOENT it
>>>> would work given the changes that were made last time this broke.
>>>> 
>>>> commit 1693a577be14a92e61563bad306aa11a359757f5
>>>> Author: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
>>>> Date:   Tue Feb 6 17:12:09 2018 +0300
>>>> 
>>>>   NET: designware: fix clock enable
>> 
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de>
>> https://lists.denx.de/listinfo/u-boot <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] GCC 7.x vs. C++ comments

[Dr. Philipp Tomsich]

> On 9 May 2018, at 15:49, Tom Rini  wrote:
> 
> On Wed, May 09, 2018 at 02:46:54PM +0200, Wolfgang Denk wrote:
>> Dear Tom,
>> 
>> In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote:
>>> 
>>> We should go and update [1] to note some special exemptions to the rule.
>> 
>> I'm not happy about this.
>> 
>>> I see you missed out on the SPDX thread over here:
>>> https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat
>> 
>> Marek already said what was on my mind, and got ignored.
>> Would it have changed anything if I had posted another complaint?
> 
> Ignored, no.  Counts as a veto?  No.  And if you had chimed in too, I
> don't know if that would have gotten anyone else to also chime in.
> Looking over the thread again there's two yes votes, two no votes, two
> people that chimed in on the thread but didn't express a yes or no to
> the change, and then no one else has said anything.  The main thing I
> see currently is a whole lot of ambivalence.

Although I am ambivalent to the underlying discussion, I have strong
opinions regarding the language/standard-compliance...

My vote goes to C++ comments and upgrading the language standard
to C99 (or rather gnu99, as our code uses extensions).  This will (at least
somewhat) match how the default C compliance level in GCC has evolved
over the GCC 6 through GCC 8 release cycles.

And while we’re at it, we should allow "for (int i = 0; …”-style C99 declaration
of loop iterations within the loop-head.

> 
>> I'm doing now, and apparently I get ignored, too.  So what exactly
>> is your argument?
>> 
>>> myself, I see it as more worthwhile to (a) follow the kernel in this
>>> area (for both tooling and consistency and ease of development for our
>>> overlapping community) (b) save space (in just about every conversion we
>>> went from 2 lines to 1 line).  Thanks!
>> 
>> OK, so you decided, and any additional discussion is futile...
> 
> It's not futile, but here's as best I can tell, the arguments:
> Against Linux Kernel style SPDX tags:
> - Don't like // style comments
> - Visually inconsistent / jarring
> 
> For Linux Kernel style SPDX tags:
> - Has higher visibility.
> - Has tooling to enforce correctly formatted tags.
> - Shorter (enforced as a single line comment means we don't have people
>  spacing around it).
> - Consistent expectations for our overlapping developer community.
> 
> Things that could be taken, without changing overall formatting:
> - Logic operators for exceptions/dual-license/etc
> 
> If people speak up against the change now that we've done it, we could
> revert and then add in the "LICENSE-A OR LICENSE-B" change.  Thanks!
> 
> -- 
> Tom

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

[U-Boot] GCC 7.x vs. C++ comments

[Dr. Philipp Tomsich]

Tom,

I recently ran a local buildman with a came across these:
>   cc -Wp,-MD,tools/.gen_eth_addr.d -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o tools/gen_eth_addr 
> tools/gen_eth_addr.c  
> tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in ISO 
> C90
>  // SPDX-License-Identifier: GPL-2.0+
>  ^
> tools/gen_eth_addr.c:1:1: warning: (this will be reported only once per input 
> file)
>   cc -Wp,-MD,tools/.gen_ethaddr_crc.o.d -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/gen_ethaddr_crc.o 
> tools/gen_ethaddr_crc.c
> tools/gen_ethaddr_crc.c:1:1: warning: C++ style comments are not allowed in 
> ISO C90
>  // SPDX-License-Identifier: GPL-2.0+
>  ^
> tools/gen_ethaddr_crc.c:1:1: warning: (this will be reported only once per 
> input file)
>   echo "#include <../lib/crc8.c>" >tools/lib/crc8.c
>   cc -Wp,-MD,tools/lib/.crc8.o.d -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/lib/crc8.o 
> tools/lib/crc8.c
> In file included from tools/lib/crc8.c:1:0:
> ./tools/../lib/crc8.c:1:1: warning: C++ style comments are not allowed in ISO 
> C90
>  // SPDX-License-Identifier: GPL-2.0+
>  ^

The system compiler was a
> Using built-in specs.
> COLLECT_GCC=cc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 
> 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-4.9 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
> --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
> --enable-libstdcxx-time=yes --enable-gnu-unique-object 
> --disable-vtable-verify --enable-plugin --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) 


What’s your preferred solution:
(a) change these comments
(b) change our Makefiles to let GCC know that we are compiling 
gnu99/C99?

Neither solution is too appealing to me, so I am asking...

Thanks,
Philipp.



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

Re: [U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Dr. Philipp Tomsich]

Kever,

if this affects all SoCs, then apparently nobody tested -rc3 … I had made sure 
that
all these last-minute changes had gone in before rc3.

Regards,
Philipp.

> On 9 May 2018, at 10:12, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
> Kever,
> 
> There were a number a merge conflicts with this series and it looks like I 
> missed
> one of them.  This is the risk when I try to resolve conflicts instead of 
> asking for 
> a series to be rebased onto master…
> 
> Regards,
> Philipp.
> 
>> On 9 May 2018, at 10:06, Kever Yang <kever.y...@rock-chips.com> wrote:
>> 
>> Hi Jonathan,
>> 
>> 
>>Thanks for the patch, and it's interesting how this is missing,
>> 
>> it means all the rockchip socs can not get console output with v2018.05 :(
>> 
>> 
>> Thanks,
>> - Kever
>> On 05/08/2018 06:43 PM, Jonathan Gray wrote:
>>> Add back part of patch send out as
>>> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
>>> gotten lost when it got merged to set SYS_NS16550_MEM32.
>>> 
>>> Allows serial output to work on tinker-rk3288 again after
>>> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
>>> 
>>> Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
>>> Signed-off-by: Jonathan Gray <j...@jsg.id.au>
>>> Cc: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
>>> ---
>>> include/configs/rockchip-common.h | 2 ++
>>> 1 file changed, 2 insertions(+)
>>> 
>>> diff --git a/include/configs/rockchip-common.h 
>>> b/include/configs/rockchip-common.h
>>> index dee82ca99d..68e1105a4b 100644
>>> --- a/include/configs/rockchip-common.h
>>> +++ b/include/configs/rockchip-common.h
>>> @@ -7,6 +7,8 @@
>>> #define _ROCKCHIP_COMMON_H_
>>> #include 
>>> 
>>> +#define CONFIG_SYS_NS16550_MEM32
>>> +
>>> #ifndef CONFIG_SPL_BUILD
>>> 
>>> /* First try to boot from SD (index 0), then eMMC (index 1) */
>> 
>> 
> 
> ___
> 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] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Dr. Philipp Tomsich]

Kever,

There were a number a merge conflicts with this series and it looks like I 
missed
one of them.  This is the risk when I try to resolve conflicts instead of 
asking for 
a series to be rebased onto master…

Regards,
Philipp.

> On 9 May 2018, at 10:06, Kever Yang  wrote:
> 
> Hi Jonathan,
> 
> 
> Thanks for the patch, and it's interesting how this is missing,
> 
> it means all the rockchip socs can not get console output with v2018.05 :(
> 
> 
> Thanks,
> - Kever
> On 05/08/2018 06:43 PM, Jonathan Gray wrote:
>> Add back part of patch send out as
>> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
>> gotten lost when it got merged to set SYS_NS16550_MEM32.
>> 
>> Allows serial output to work on tinker-rk3288 again after
>> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
>> 
>> Signed-off-by: Kever Yang 
>> Signed-off-by: Jonathan Gray 
>> Cc: Philipp Tomsich 
>> ---
>> include/configs/rockchip-common.h | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/include/configs/rockchip-common.h 
>> b/include/configs/rockchip-common.h
>> index dee82ca99d..68e1105a4b 100644
>> --- a/include/configs/rockchip-common.h
>> +++ b/include/configs/rockchip-common.h
>> @@ -7,6 +7,8 @@
>> #define _ROCKCHIP_COMMON_H_
>> #include 
>> 
>> +#define CONFIG_SYS_NS16550_MEM32
>> +
>> #ifndef CONFIG_SPL_BUILD
>> 
>> /* First try to boot from SD (index 0), then eMMC (index 1) */
> 
> 

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

> On 9 May 2018, at 07:29, Marty E. Plummer <hanet...@startmail.com> wrote:
> 
> On Tue, May 08, 2018 at 11:08:14PM +0200, Dr. Philipp Tomsich wrote:
>> 
>>> On 8 May 2018, at 21:21, Marty E. Plummer <hanet...@startmail.com> wrote:
>>> 
>>> On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
>>>> Marty,
>>>> 
>>>>> On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
>>>>> 
>>>>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>>>>> 
>>>>>>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>>>>>>>> Hi Marty,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>>>>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>>>>>>>> 
>>>>>>>>> Without this change, my u-boot build for the asus c201 chromebook 
>>>>>>>>> (4GiB)
>>>>>>>>> is incorrectly detected as 0 Bytes of ram.
>>>>>>>> 
>>>>>>>> I know the root cause for this issue, and I have a local patch for it.
>>>>>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>>>>>>>> before
>>>>>>>> the max size before return with '<<20'. Sorry for forgot to send it 
>>>>>>>> out.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>>>>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>>>>>>>> 
>>>>>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>>>>>>>> b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>>>> index 76dbdc8715..a9c9f970a4 100644
>>>>>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>>>>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>>>> @@ -10,6 +10,8 @@
>>>>>>>>> #include 
>>>>>>>>> #include 
>>>>>>>>> #include 
>>>>>>>>> +#include 
>>>>>>>>> +#include 
>>>>>>>>> 
>>>>>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>>>>   size_t size_mb = 0;
>>>>>>>>>   u32 ch;
>>>>>>>>> 
>>>>>>>>> - u32 sys_reg = readl(reg);
>>>>>>>>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>>>>>>>> -& SYS_REG_NUM_CH_MASK);
>>>>>>>>> + if (!size_mb) {
>>>>>>>> 
>>>>>>>> I don't understand this and follow up changes, we don't really need it,
>>>>>>>> isn't it?
>>>>>>>> I think don't need the changes before here.
>>>>>>> Yeah, that was just another level of indentation for the if (!size_mb)
>>>>>>> guard, but I've reworked the patch to not do that as it was pointed out
>>>>>>> that since size_mb is initialized to 0 prior.
>>>>>>>>> + /*
>>>>>>>>> +  * we use the 0x~0xfeff space
>>>>>>>>> +  * since 0xff00~0x is soc register space
>>>>>>>>> +  * so we reserve it
>>>>>>>>> +  */
>>>>>>>>> + size_mb = min(size_mb, 0xff00/SZ_1M);
>>>>>>>> 
>>>>>>>> This is what we really need, as Klaus point out, we need to use
>>>>>>>> SDRAM_MAX_SIZE
>>>>>>>> instead of h

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

> On 8 May 2018, at 21:21, Marty E. Plummer <hanet...@startmail.com> wrote:
> 
> On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
>> Marty,
>> 
>>> On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
>>> 
>>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>>> 
>>>>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> wrote:
>>>>> 
>>>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>>>>>> Hi Marty,
>>>>>> 
>>>>>> 
>>>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>>>>>> 
>>>>>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>>>>>> is incorrectly detected as 0 Bytes of ram.
>>>>>> 
>>>>>> I know the root cause for this issue, and I have a local patch for it.
>>>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>>>>>> before
>>>>>> the max size before return with '<<20'. Sorry for forgot to send it out.
>>>>>> 
>>>>>>> 
>>>>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
>>>>>>> ---
>>>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>>>>>> b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>> index 76dbdc8715..a9c9f970a4 100644
>>>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>>>>>> @@ -10,6 +10,8 @@
>>>>>>> #include 
>>>>>>> #include 
>>>>>>> #include 
>>>>>>> +#include 
>>>>>>> +#include 
>>>>>>> 
>>>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>> size_t size_mb = 0;
>>>>>>> u32 ch;
>>>>>>> 
>>>>>>> -   u32 sys_reg = readl(reg);
>>>>>>> -   u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>>>>>> -  & SYS_REG_NUM_CH_MASK);
>>>>>>> +   if (!size_mb) {
>>>>>> 
>>>>>> I don't understand this and follow up changes, we don't really need it,
>>>>>> isn't it?
>>>>>> I think don't need the changes before here.
>>>>> Yeah, that was just another level of indentation for the if (!size_mb)
>>>>> guard, but I've reworked the patch to not do that as it was pointed out
>>>>> that since size_mb is initialized to 0 prior.
>>>>>>> +   /*
>>>>>>> +* we use the 0x~0xfeff space
>>>>>>> +* since 0xff00~0x is soc register space
>>>>>>> +* so we reserve it
>>>>>>> +*/
>>>>>>> +   size_mb = min(size_mb, 0xff00/SZ_1M);
>>>>>> 
>>>>>> This is what we really need, as Klaus point out, we need to use
>>>>>> SDRAM_MAX_SIZE
>>>>>> instead of hard code.
>>>>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
>>>>> build and boot tested on my hardware.
>>>> 
>>>> In that case you just masked the problem but didn???t solve it: assuming 
>>>> size_mb
>>>> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
>>>> is 0x1__ )
>>>> which overflows to 0x0 when converted to a u32.
>>>> 
>>>> In other words: we need to figure out where the truncation occurs (image 
>>>> what
>>>> happens if a new 32bit processor with LPAE comes out???).
>>>> 
>>> A very valid point. With the following patch to sdram_common.c and
>>> sdram_rk32

Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: enable SYS_NS16550 for all SoCs by default

[Dr. Philipp Tomsich]

Good catch.  I had a few merge-conflicts when merging that series.
That one might have gotten lost.

> On 8 May 2018, at 12:31, Jonathan Gray <j...@jsg.id.au> wrote:
> 
> On Tue, May 08, 2018 at 09:41:32AM +0200, Dr. Philipp Tomsich wrote:
>> Kever,
>> 
>> Could you analyse and provide (against master) a patch for this?
>> We???ll need to catch any left-overs from your changes at the start of the 
>> cycle
>> before we try to merge any of the more invasive changes you have in-flight.
>> 
>> Thanks,
>> Philipp.
> 
> The patch in https://patchwork.ozlabs.org/patch/900546/ had a change in
> include/configs/rockchip-common.h which was not included in the commit
> that made it into to tree as c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
> 
> After adding that back it works.
> 
> diff --git a/include/configs/rockchip-common.h 
> b/include/configs/rockchip-common.h
> index dee82ca99d..68e1105a4b 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -7,6 +7,8 @@
> #define _ROCKCHIP_COMMON_H_
> #include 
> 
> +#define CONFIG_SYS_NS16550_MEM32
> +
> #ifndef CONFIG_SPL_BUILD
> 
> /* First try to boot from SD (index 0), then eMMC (index 1) */

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

Simon,

Looks like we’d like to have a 64bit type for size in ‘struct ram_info’ (see 
below).
Let us know what you think of the proposed change.

Thanks,
Philipp.


> On 8 May 2018, at 12:21, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
> Marty,
> 
>> On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
>> 
>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>>> 
>>>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> wrote:
>>>> 
>>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>>>>> Hi Marty,
>>>>> 
>>>>> 
>>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>>>>> 
>>>>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>>>>> is incorrectly detected as 0 Bytes of ram.
>>>>> 
>>>>> I know the root cause for this issue, and I have a local patch for it.
>>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>>>>> before
>>>>> the max size before return with '<<20'. Sorry for forgot to send it out.
>>>>> 
>>>>>> 
>>>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
>>>>>> ---
>>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>>>>> 
>>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>>>>> b/arch/arm/mach-rockchip/sdram_common.c
>>>>>> index 76dbdc8715..a9c9f970a4 100644
>>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>>>>> @@ -10,6 +10,8 @@
>>>>>> #include 
>>>>>> #include 
>>>>>> #include 
>>>>>> +#include 
>>>>>> +#include 
>>>>>> 
>>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>>  size_t size_mb = 0;
>>>>>>  u32 ch;
>>>>>> 
>>>>>> -u32 sys_reg = readl(reg);
>>>>>> -u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>>>>> -   & SYS_REG_NUM_CH_MASK);
>>>>>> +if (!size_mb) {
>>>>> 
>>>>> I don't understand this and follow up changes, we don't really need it,
>>>>> isn't it?
>>>>> I think don't need the changes before here.
>>>> Yeah, that was just another level of indentation for the if (!size_mb)
>>>> guard, but I've reworked the patch to not do that as it was pointed out
>>>> that since size_mb is initialized to 0 prior.
>>>>>> +/*
>>>>>> + * we use the 0x~0xfeff space
>>>>>> + * since 0xff00~0x is soc register space
>>>>>> + * so we reserve it
>>>>>> + */
>>>>>> +size_mb = min(size_mb, 0xff00/SZ_1M);
>>>>> 
>>>>> This is what we really need, as Klaus point out, we need to use
>>>>> SDRAM_MAX_SIZE
>>>>> instead of hard code.
>>>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
>>>> build and boot tested on my hardware.
>>> 
>>> In that case you just masked the problem but didn???t solve it: assuming 
>>> size_mb
>>> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
>>> is 0x1__ )
>>> which overflows to 0x0 when converted to a u32.
>>> 
>>> In other words: we need to figure out where the truncation occurs (image 
>>> what
>>> happens if a new 32bit processor with LPAE comes out???).
>>> 
>> A very valid point. With the following patch to sdram_common.c and
>> sdram_rk3288.c applied I get the debug output that follows it:
>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>> b/arch/arm/mach-rockchip/sdram_common.c
>> index 232a7fa655..0fe69bf558 100644
>> --- a/arc

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

Marty,

> On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
> 
> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>> 
>>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> wrote:
>>> 
>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>>>> Hi Marty,
>>>> 
>>>> 
>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>>>> 
>>>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>>>> is incorrectly detected as 0 Bytes of ram.
>>>> 
>>>> I know the root cause for this issue, and I have a local patch for it.
>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>>>> before
>>>> the max size before return with '<<20'. Sorry for forgot to send it out.
>>>> 
>>>>> 
>>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
>>>>> ---
>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>>>> 
>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>>>> b/arch/arm/mach-rockchip/sdram_common.c
>>>>> index 76dbdc8715..a9c9f970a4 100644
>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>>>> @@ -10,6 +10,8 @@
>>>>> #include 
>>>>> #include 
>>>>> #include 
>>>>> +#include 
>>>>> +#include 
>>>>> 
>>>>> DECLARE_GLOBAL_DATA_PTR;
>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>>>>   size_t size_mb = 0;
>>>>>   u32 ch;
>>>>> 
>>>>> - u32 sys_reg = readl(reg);
>>>>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>>>> -& SYS_REG_NUM_CH_MASK);
>>>>> + if (!size_mb) {
>>>> 
>>>> I don't understand this and follow up changes, we don't really need it,
>>>> isn't it?
>>>> I think don't need the changes before here.
>>> Yeah, that was just another level of indentation for the if (!size_mb)
>>> guard, but I've reworked the patch to not do that as it was pointed out
>>> that since size_mb is initialized to 0 prior.
>>>>> + /*
>>>>> +  * we use the 0x~0xfeff space
>>>>> +  * since 0xff00~0x is soc register space
>>>>> +  * so we reserve it
>>>>> +  */
>>>>> + size_mb = min(size_mb, 0xff00/SZ_1M);
>>>> 
>>>> This is what we really need, as Klaus point out, we need to use
>>>> SDRAM_MAX_SIZE
>>>> instead of hard code.
>>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
>>> build and boot tested on my hardware.
>> 
>> In that case you just masked the problem but didn???t solve it: assuming 
>> size_mb
>> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB is 
>> 0x1__ )
>> which overflows to 0x0 when converted to a u32.
>> 
>> In other words: we need to figure out where the truncation occurs (image what
>> happens if a new 32bit processor with LPAE comes out???).
>> 
> A very valid point. With the following patch to sdram_common.c and
> sdram_rk3288.c applied I get the debug output that follows it:
> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> b/arch/arm/mach-rockchip/sdram_common.c
> index 232a7fa655..0fe69bf558 100644
> --- a/arch/arm/mach-rockchip/sdram_common.c
> +++ b/arch/arm/mach-rockchip/sdram_common.c
> @@ -4,6 +4,7 @@
>  * SPDX-License-Identifier: GPL-2.0+
>  */
> 
> +#define DEBUG 1
> #include 
> #include 
> #include 
> @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>   SYS_REG_ROW_3_4_MASK;
> 
>   chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> + debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
> chipsize_mb);
> 
>   if (rank > 1)
>   chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
>   if (row_3_4)
>

Re: [U-Boot] [PATCH] rockchip: clk: rk3288: handle clk_enable requests for GMAC

[Dr. Philipp Tomsich]

> On 8 May 2018, at 11:49, Jonathan Gray  wrote:
> 
> Since b0ba1e7e9d9b9441a18048ec67a3b3100c096975
> (rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC)
> Ethernet no longer probes on RK3288.
> 
> Add no-ops for GMAC clocks observed to be requested which match the
> clk_enable cases in RK3368 and RK3399.
> 
> Signed-off-by: Jonathan Gray 
> Cc: Wadim Egorov 
> Cc: Philipp Tomsich 

Thanks for the quick turnaround.
I’ll give this a day or two, for others to also review/test and will then
merge from the front of the queue.

Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC

[Dr. Philipp Tomsich]

Looks like the designware GMAC driver is trying to enable a clock and
can’t deal with the -ENOENT.  Could you try to see which clock it is
requesting and add the necessary entries in the clock-enable function?

If you have a patch, I’ll try to prioritise it, so we get these regressions
cleaned up quickly (note that these had all been in rc3—if we’d known
earlier, I could have reverted them out for the release).

@Wadim: could you please also look into this, as your board should have
similar problems (unless your device-tree is very different). 

Thanks,
Philipp.

> On 8 May 2018, at 09:51, Jonathan Gray  wrote:
> 
> On Thu, Apr 26, 2018 at 09:05:33AM +0200, Philipp Tomsich wrote:
>>> The generic ehci-driver (ehci-generic.c) will try to enable the clocks
>>> listed in the DTSI. If this fails (e.g. due to clk_enable not being
>>> implemented in a driver and -ENOSYS being returned by the clk-uclass),
>>> the driver will bail our and print an error message.
>>> 
>>> This implements a minimal clk_enable for the RK3288 and supports the
>>> clocks mandatory for the EHCI controllers; as these are enabled by
>>> default we simply return success.
>>> 
>>> Signed-off-by: Wadim Egorov 
>>> Acked-by: Philipp Tomsich 
>>> Reviewed-by: Philipp Tomsich 
>>> ---
>>> drivers/clk/rockchip/clk_rk3288.c | 13 +
>>> 1 file changed, 13 insertions(+)
>>> 
>> 
>> Applied to u-boot-rockchip, thanks!
> 
> This change broke Ethernet on tinker-rk3288.
> 
> U-Boot 2018.05-2-g6ea9f3dd70 (May 08 2018 - 17:21:32 +1000)
> 
> Model: Tinker-RK3288
> DRAM:  2 GiB
> MMC:   dwmmc@ff0c: 1
> Loading Environment from MMC... *** Warning - bad CRC, using default 
> environment
> 
> Failed (-5)
> In:serial
> Out:   serial
> Err:   serial
> Model: Tinker-RK3288
> Net:   failed to enable clock 0
> No ethernet found.
> 
> After reverting it:
> 
> U-Boot 2018.05-3-g338bfe2fbf (May 08 2018 - 17:40:09 +1000)
> 
> Model: Tinker-RK3288
> DRAM:  2 GiB
> MMC:   dwmmc@ff0c: 1
> Loading Environment from MMC... *** Warning - bad CRC, using default 
> environment
> 
> Failed (-5)
> In:serial
> Out:   serial
> Err:   serial
> Model: Tinker-RK3288
> Net:   eth0: ethernet@ff29
> Hit any key to stop autoboot:  0
> 
> If the default case returned ENOSYS or ENOTSUPP instead of ENOENT it
> would work given the changes that were made last time this broke.
> 
> commit 1693a577be14a92e61563bad306aa11a359757f5
> Author: Eugeniy Paltsev 
> Date:   Tue Feb 6 17:12:09 2018 +0300
> 
>NET: designware: fix clock enable

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

Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: enable SYS_NS16550 for all SoCs by default

[Dr. Philipp Tomsich]

Kever,

Could you analyse and provide (against master) a patch for this?
We’ll need to catch any left-overs from your changes at the start of the cycle
before we try to merge any of the more invasive changes you have in-flight.

Thanks,
Philipp.

> On 8 May 2018, at 09:30, Jonathan Gray  wrote:
> 
> On Thu, Apr 26, 2018 at 09:05:37AM +0200, Philipp Tomsich wrote:
>>> All rockchip SoCs can use ns16550 driver, enable it for all
>>> and set SYS_NS16550_MEM32 for all SoCs.
>>> 
>>> Version-changes: 2
>>> - use imply instead of select
>>> 
>>> Signed-off-by: Kever Yang 
>>> Acked-by: Philipp Tomsich 
>>> Reviewed-by: Philipp Tomsich 
>>> ---
>>> 
>>> Changes in v2: None
>>> 
>>> arch/arm/Kconfig  | 1 +
>>> arch/arm/mach-rockchip/Kconfig| 1 -
>>> include/configs/rk3036_common.h   | 3 ---
>>> include/configs/rk3128_common.h   | 2 --
>>> include/configs/rk3188_common.h   | 2 --
>>> include/configs/rk322x_common.h   | 1 -
>>> include/configs/rk3288_common.h   | 2 --
>>> include/configs/rk3328_common.h   | 2 --
>>> include/configs/rk3368_common.h   | 2 --
>>> include/configs/rk3399_common.h   | 2 --
>>> include/configs/rockchip-common.h | 2 ++
>>> include/configs/rv1108_common.h   | 3 ---
>>> 12 files changed, 3 insertions(+), 20 deletions(-)
>>> 
>> 
>> Applied to u-boot-rockchip, thanks!
> 
> With U-Boot 2018.05 there is no serial console output on tinker-rk3288,
> a regression from 2018.03.  I have bisected it to this commit.
> 
> Reverting c3c0331db1fb7b1f4ff41e144fc04353b37c785c and
> eb3d707e99fcd2213d5f8f0fe4ae53ad416b377e restores serial output with
> 2018.05.
> 
> c3c0331db1fb7b1f4ff41e144fc04353b37c785c is the first bad commit
> commit c3c0331db1fb7b1f4ff41e144fc04353b37c785c
> Author: Kever Yang  >
> Date:   Thu Apr 19 11:37:09 2018 +0800
> 
>rockchip: enable SYS_NS16550 for all SoCs by default
> 
>All rockchip SoCs can use ns16550 driver, enable it for all
>and set SYS_NS16550_MEM32 for all SoCs.
> 
>Version-changes: 2
>- use imply instead of select
> 
>Signed-off-by: Kever Yang  >
>Acked-by: Philipp Tomsich  >
>Reviewed-by: Philipp Tomsich  >
> 
> :04 04 f7cc8b28ae8179fdc15896bbb55279f205a54008 
> d07108bbf467735f31f31c083a9068dff71da247 M  arch
> :04 04 d0a0422fc55afdcb5abb82f24b9a0af8de3d39a6 
> 33c7fcf6f28f44a8c416f95313e7a30b2f73f8f0 M  include

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

> On 7 May 2018, at 04:34, Marty E. Plummer  wrote:
> 
> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>> Hi Marty,
>> 
>> 
>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>> 
>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>> is incorrectly detected as 0 Bytes of ram.
>> 
>> I know the root cause for this issue, and I have a local patch for it.
>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to before
>> the max size before return with '<<20'. Sorry for forgot to send it out.
>> 
>>> 
>>> Signed-off-by: Marty E. Plummer 
>>> ---
>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>> 
>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>> b/arch/arm/mach-rockchip/sdram_common.c
>>> index 76dbdc8715..a9c9f970a4 100644
>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>> @@ -10,6 +10,8 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> +#include 
>>> 
>>> DECLARE_GLOBAL_DATA_PTR;
>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>> size_t size_mb = 0;
>>> u32 ch;
>>> 
>>> -   u32 sys_reg = readl(reg);
>>> -   u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>> -  & SYS_REG_NUM_CH_MASK);
>>> +   if (!size_mb) {
>> 
>> I don't understand this and follow up changes, we don't really need it,
>> isn't it?
>> I think don't need the changes before here.
> Yeah, that was just another level of indentation for the if (!size_mb)
> guard, but I've reworked the patch to not do that as it was pointed out
> that since size_mb is initialized to 0 prior.
>>> +   /*
>>> +* we use the 0x~0xfeff space
>>> +* since 0xff00~0x is soc register space
>>> +* so we reserve it
>>> +*/
>>> +   size_mb = min(size_mb, 0xff00/SZ_1M);
>> 
>> This is what we really need, as Klaus point out, we need to use
>> SDRAM_MAX_SIZE
>> instead of hard code.
> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> build and boot tested on my hardware.

In that case you just masked the problem but didn’t solve it: assuming size_mb
is size_t (I’ll assume this is 64bit, but did not check), then your 4GB is 
0x1__ )
which overflows to 0x0 when converted to a u32.

In other words: we need to figure out where the truncation occurs (image what
happens if a new 32bit processor with LPAE comes out…).

>> 
>> Thanks,
>> - Kever
>>> }
>>> 
>>> return (size_t)size_mb << 20;
>> 
>> 
> ___
> 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 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

> On 6 May 2018, at 16:25, Marty E. Plummer  wrote:
> 
> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> 
> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> is incorrectly detected as 0 Bytes of ram.

Could you elaborate what the change is and what root-cause this addresses (4GB
reporting as 0 sounds a bit like a 32bit type overflowing)?
It’s really hard to tell from the patch below (which seems to have everything 
simply
reformatted to a different indentation)...

> 
> Signed-off-by: Marty E. Plummer 
> ---
> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> 1 file changed, 37 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> b/arch/arm/mach-rockchip/sdram_common.c
> index 76dbdc8715..a9c9f970a4 100644
> --- a/arch/arm/mach-rockchip/sdram_common.c
> +++ b/arch/arm/mach-rockchip/sdram_common.c
> @@ -10,6 +10,8 @@
> #include 
> #include 
> #include 
> +#include 
> +#include 
> 
> DECLARE_GLOBAL_DATA_PTR;
> size_t rockchip_sdram_size(phys_addr_t reg)
> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>   size_t size_mb = 0;
>   u32 ch;
> 
> - u32 sys_reg = readl(reg);
> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> -& SYS_REG_NUM_CH_MASK);
> + if (!size_mb) {

Given that there’s a “size_mb = 0” just above it, this will always evaluate
to true… 

> 
> - debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> - for (ch = 0; ch < ch_num; ch++) {
> - rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> - SYS_REG_RANK_MASK);
> - col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & SYS_REG_COL_MASK);
> - bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
> - cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> - SYS_REG_CS0_ROW_MASK);
> - cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> - SYS_REG_CS1_ROW_MASK);
> - bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> - SYS_REG_BW_MASK));
> - row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> - SYS_REG_ROW_3_4_MASK;
> + u32 sys_reg = readl(reg);
> + u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> +& SYS_REG_NUM_CH_MASK);
> 
> - chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> + debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> + for (ch = 0; ch < ch_num; ch++) {
> + rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> + SYS_REG_RANK_MASK);
> + col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & 
> SYS_REG_COL_MASK);
> + bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & 
> SYS_REG_BK_MASK);
> + cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> + SYS_REG_CS0_ROW_MASK);
> + cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> + SYS_REG_CS1_ROW_MASK);
> + bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> + SYS_REG_BW_MASK));
> + row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> + SYS_REG_ROW_3_4_MASK;
> 
> - if (rank > 1)
> - chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> - if (row_3_4)
> - chipsize_mb = chipsize_mb * 3 / 4;
> - size_mb += chipsize_mb;
> - debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
> -   rank, col, bk, cs0_row, bw, row_3_4);
> + chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> +
> + if (rank > 1)
> + chipsize_mb += chipsize_mb >> (cs0_row - 
> cs1_row);
> + if (row_3_4)
> + chipsize_mb = chipsize_mb * 3 / 4;
> + size_mb += chipsize_mb;
> + debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 
> %d\n",
> +   rank, col, bk, cs0_row, bw, row_3_4);
> + }
> +
> + /*
> +  * we use the 0x~0xfeff space
> +  * since 0xff00~0x is soc register space
> +  * so we reserve it
> +  */
> + size_mb = min(size_mb, 0xff00/SZ_1M);
>   }
> 
>   return (size_t)size_mb << 20;
> -- 
> 2.17.0
> 
> ___
> 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

Re: [U-Boot] [PATCH v2 1/3] drivers: Add board uclass

[Dr. Philipp Tomsich]

Simon,

> On 1 May 2018, at 01:12, Simon Glass <s...@chromium.org> wrote:
> 
> Hi,
> 
> On 27 April 2018 at 07:02, Dr. Philipp Tomsich
> <philipp.toms...@theobroma-systems.com 
> <mailto:philipp.toms...@theobroma-systems.com>> wrote:
>> 
>>> On 27 Apr 2018, at 14:51, Mario Six <mario@gdsys.cc 
>>> <mailto:mario@gdsys.cc>> wrote:
>>> 
>>> Since there is no canonical "board device" that can be used in board
>>> files, it is difficult to use DM function for board initialization in
>>> these cases.
>>> 
>>> Hence, add a uclass that implements a simple "board device", which can
>>> hold devices not suitable anywhere else in the device tree, and is also
>>> able to read encoded information, e.g. hard-wired GPIOs on a GPIO
>>> expander, read-only memory ICs, etc. that carry information about the
>>> hardware.
> 
> With comments below:
> 
> Reviewed-by: Simon Glass <s...@chromium.org <mailto:s...@chromium.org>>
> 
>> 
>> A board-uclass should model a board (i.e. provide implementations for
>> the same key abstractions that we have in place today: e.g., board_init).
>> 
>> This seems more like a specialised form of a misc-device.
>> 
>>> The devices of this uclass expose methods to read generic data types
>>> (integers, strings, booleans) to encode the information provided by the
>>> hardware.
>> 
>> Again, this is what a misc-device is intended for… and extending the
>> misc-device APIs (or having a convenience layer on top of its ioctl
>> interface?) might be more appropriate.
>> 
>> After reviewing the below, the similarities to the misc-device are even
>> more apparent: if you need typed access to a key-value pair, this can
>> be easily implemented through a common ioctl with semantic sugar
>> at the misc-uclass level.
> 
> A misc device might be similar in action but it is not the same in
> terms of concept. For example it would be very strange to have a misc
> device which points to lots of other devices that are on the board.
> For example, consider this hypothetical case:
> 
> board {
>   identity-eeprom = <>;
>   id-gpios = < 2>, < 4>;
>   ec = <_ec>;
> };

Maybe I am getting hung up on the ‘board’ name, as in my mind the board
selection should be based on the top-level .compatible:
e.g.compatible = "tsd,rk3399-q7", "tsd,puma", "rockchip,rk3399";
and the selected board-classes could then encapsulate the various init
hooks and inquire into devices defined via /aliases, /config and /chosen.

A board-class should restructure existing board.c-files into the .ops that
are used there (i.e. init, late-init, usb-init, debug-uart-init, etc.) ... this 
is
different from what’s being proposed here.

The hypothetical case you give is already covered wholly by today’s device
model. Let me explain with a counter example:
aliases {
identity-eeprom = <>;
id-gpios = <>;
ec = <_ec>;
}

board-id {
/* a good use for a hypothetical misc-device that exports the
   values of a variable-length list of GPIOs */
.compatible = “identity-gpios”;
id-gpios = < 2>, < 4>;
}

> Here we point to a few devices which may otherwise require specific
> device-tree references to locate. Already we are seeing this sort of
> code in U-Boot:
> 
> /* find the grf node */
> node = fdt_node_offset_by_compatible(blob, -1,
> "rockchip,rk3288-grf”);

This is usually caused by badly-modelled device-trees or missing device
tree support in drivers.
In this specific case it’s a wart caused by dwc2_udc_probe(…) and that
this is not called from the device-tree.

I would hope that this will eventually be included converted to the device
model and that the info will be processed from the dwc2_udc driver.

> ret = regulator_get_by_platname("vdd_arm", );
> if (ret) {
> debug("Cannot set regulator name\n");
> return ret;
> }

I know this specific example, and it’s from a use case, where a voltage
needs to be slowly raised.  The reason for this being there is that we
don’t have the same DTS as in Linux and the modelling (and driver)
for the PMU subsystem are not there. 

So I don’t seem to follow on how this would resolve itself with the
proposed board-uclass.

> These are the sorts of things which suggest that some sort of 'board
> directory', pointing to the things that the board needs to init, would
> be useful.

In fact, I have been raising the topic of having a ‘board’ and a ‘soc’
uclass a f

Re: [U-Boot] [PATCH 3/5] api: Flush cache when closing api

[Dr. Philipp Tomsich]

> On 30 Apr 2018, at 10:34, Emmanuel Vadot  wrote:
> 
> Signed-off-by: Emmanuel Vadot 
> ---
> api/api.c | 11 +++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/api/api.c b/api/api.c
> index 7eee2fc083..7d1608b520 100644
> --- a/api/api.c
> +++ b/api/api.c
> @@ -290,6 +290,17 @@ static int API_dev_close(va_list ap)
>   if (!err)
>   di->state = DEV_STA_CLOSED;
> 
> +#if defined(CONFIG_SYS_HAVE_DCACHE_MAINTENANCE) && \
> + !defined(CONFIG_SYS_DCACHE_OFF)
> + if (dcache_status())
> + flush_dcache_all();
> +#endif
> +#if defined(CONFIG_SYS_HAVE_ICACHE_MAINTENANCE) && \
> + !defined(CONFIG_SYS_ICACHE_OFF)
> + if (icache_status())
> + invalidate_icache_all();
> +#endif

Wouldn’t it be a cleaner option to make flush_dcache_all and 
invalidate_icache_all
weak-functions and provide a default implementation that does nothing. Those
architectures that then need to implement specific cache maintenance, could
override these as required.

>   return err;
> }
> 
> -- 
> 2.16.3
> 

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

Re: [U-Boot] [PATCH v2 1/3] drivers: Add board uclass

[Dr. Philipp Tomsich]

> On 27 Apr 2018, at 14:51, Mario Six  wrote:
> 
> Since there is no canonical "board device" that can be used in board
> files, it is difficult to use DM function for board initialization in
> these cases.
> 
> Hence, add a uclass that implements a simple "board device", which can
> hold devices not suitable anywhere else in the device tree, and is also
> able to read encoded information, e.g. hard-wired GPIOs on a GPIO
> expander, read-only memory ICs, etc. that carry information about the
> hardware.

A board-uclass should model a board (i.e. provide implementations for
the same key abstractions that we have in place today: e.g., board_init).

This seems more like a specialised form of a misc-device.

> The devices of this uclass expose methods to read generic data types
> (integers, strings, booleans) to encode the information provided by the
> hardware.

Again, this is what a misc-device is intended for… and extending the
misc-device APIs (or having a convenience layer on top of its ioctl
interface?) might be more appropriate.

After reviewing the below, the similarities to the misc-device are even
more apparent: if you need typed access to a key-value pair, this can
be easily implemented through a common ioctl with semantic sugar
at the misc-uclass level.

> Signed-off-by: Mario Six 
> ---
> 
> v1 -> v2:
> * Corrected description of dev parameter of devinfo_detect
> * Added size parameter to devinfo_get_str
> * Expanded uclass documentation
> * Added function to get devinfo instance
> * Renamed the uclass from devinfo to board
> 
> ---
> drivers/Kconfig  |   2 +
> drivers/Makefile |   1 +
> drivers/board/Kconfig|  17 +++
> drivers/board/Makefile   |   9 
> drivers/board/board-uclass.c |  61 +++
> include/board.h  | 115 +++
> include/dm/uclass-id.h   |   1 +
> 7 files changed, 206 insertions(+)
> create mode 100644 drivers/board/Kconfig
> create mode 100644 drivers/board/Makefile
> create mode 100644 drivers/board/board-uclass.c
> create mode 100644 include/board.h
> 
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index c2e813f5ad..19c7c448c0 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -22,6 +22,8 @@ source "drivers/ddr/Kconfig"
> 
> source "drivers/demo/Kconfig"
> 
> +source "drivers/board/Kconfig"
> +
> source "drivers/ddr/fsl/Kconfig"
> 
> source "drivers/dfu/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 6846d181aa..fecf64021c 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -72,6 +72,7 @@ obj-y += block/
> obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/
> obj-$(CONFIG_CPU) += cpu/
> obj-y += crypto/
> +obj-y += board/
> obj-y += firmware/
> obj-$(CONFIG_FPGA) += fpga/
> obj-y += misc/
> diff --git a/drivers/board/Kconfig b/drivers/board/Kconfig
> new file mode 100644
> index 00..cc1cf27205
> --- /dev/null
> +++ b/drivers/board/Kconfig
> @@ -0,0 +1,17 @@
> +menuconfig BOARD
> + bool "Device Information"
> + help
> +   Support methods to query hardware configurations from internal
> +   mechanisms (e.g. reading GPIO values, determining the presence of
> +   devices on busses, etc.). This enables the usage of U-Boot with
> +   modular board architectures.
> +
> +if BOARD
> +
> +
> +config BOARD_GAZERBEAM
> + bool "Enable device information for the Gazerbeam board"
> + help
> +   Support querying device information for the gdsys Gazerbeam board.
> +
> +endif
> diff --git a/drivers/board/Makefile b/drivers/board/Makefile
> new file mode 100644
> index 00..397706245a
> --- /dev/null
> +++ b/drivers/board/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# (C) Copyright 2017
> +# Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-$(CONFIG_BOARD) += board-uclass.o
> +obj-$(CONFIG_BOARD_GAZERBEAM) += gazerbeam.o
> diff --git a/drivers/board/board-uclass.c b/drivers/board/board-uclass.c
> new file mode 100644
> index 00..3137437245
> --- /dev/null
> +++ b/drivers/board/board-uclass.c
> @@ -0,0 +1,61 @@
> +/*
> + * (C) Copyright 2017
> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int get_board(struct udevice **devp)
> +{
> + return uclass_first_device_err(UCLASS_BOARD, devp);
> +}
> +
> +int board_detect(struct udevice *dev)
> +{
> + struct board_ops *ops = board_get_ops(dev);
> +
> + if (!ops->detect)
> + return -ENOSYS;
> +
> + return ops->detect(dev);
> +}
> +
> +int board_get_bool(struct udevice *dev, int id, bool *val)
> +{
> + struct board_ops *ops = board_get_ops(dev);
> +
> + if (!ops->get_bool)
> + return -ENOSYS;
> +
> + return ops->get_bool(dev, id, val);
> +}
> +
> +int board_get_int(struct udevice *dev, int 

Re: [U-Boot] [PATCH v3 1/2] arm: preserve lr correctly in arm926ejs startup code

[Dr. Philipp Tomsich]

> On 26 Apr 2018, at 20:18, Klaus Goger  
> wrote:
> 
> When building the mxs platform in thumb mode gcc generates code using
> the intra procedure call scratch register (ip/r12) for the calling the
> lowlevel_init function. This modifies the lr in flush_dcache which
> causes u-boot proper to end in an endless loop.
> 
> 40002334:   e1a0c00emov ip, lr
> 40002338:   eb00df4cbl  4003a070
> <__lowlevel_init_from_arm>
> 4000233c:   e1a0e00cmov lr, ip
> 40002340:   e1a0f00emov pc, lr
> [...]
> 4003a070 <__lowlevel_init_from_arm>:
> 4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
> <__lowlevel_init_from_arm+0xc>
> 4003a074:   e08fc00cadd ip, pc, ip
> 4003a078:   e12fff1cbx  ip
> 4003a07c:   fffc86cd.word   0xfffc86cd
> 
> Instead of using the the ip/r12 register we use sl/r10 to preserve the
> link register.
> 
> According to "Procedure Call Standard for the ARM Architecture" by ARM
> subroutines have to preserve the contents of register r4-r8, r10, r11
> and SP. So using r12 to store the link register will fail if the called
> function is using r12 and not preserving it as allowed.

Maybe you could rephrase this one, as the “not preserving it as allowed”
made me read this twice until I realised that it is equivalent to “does not
preserve (and is not required by the PCS to preserve)”?

> This can happen in ARM and thumb mode but will definitely be triggered
> by building it in thumb.
> Using r10 should be safe in any case as we are startup code and not
> called by any C-function and no stack is set up.
> 
> Signed-off-by: Klaus Goger 
> Signed-off-by: Christoph Muellner 

Reviewed-by: Philipp Tomsich 

> 
> ---
> 
> Changes in v3:
> - reword commit message as it isn't thumb specific
> - use r10 instead of sl alias as we don't use it as stack limit pointer
> - revert return to a pc mov as it is a unnecessary change for this patch
> 
> Changes in v2:
> - use bl instead of blx to call lowlevel_init
> - remove mxs tag as it apply to all arm926ejs platforms
> 
> arch/arm/cpu/arm926ejs/start.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
> index 959d1ed86d..a625b39787 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -105,9 +105,9 @@ flush_dcache:
>   /*
>* Go setup Memory and board specific bits prior to relocation.
>*/
> - mov ip, lr  /* perserve link reg across call */
> + mov r10, lr /* perserve link reg across call */
>   bl  lowlevel_init   /* go setup pll,mux,memory */
> - mov lr, ip  /* restore link */
> + mov lr, r10 /* restore link */
> #endif
>   mov pc, lr  /* back to my caller */
> #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> --
> 2.11.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



signature.asc
Description: Message signed with OpenPGP
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,2/3] rockchip: rk3188: add timer3 node

[Dr. Philipp Tomsich]

> On 26 Apr 2018, at 09:14, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
> 
>> On 26 Apr 2018, at 04:50, Kever Yang <kever.y...@rock-chips.com> wrote:
>> 
>> Hi Philipp,
>> 
>> On 04/25/2018 06:17 PM, Dr. Philipp Tomsich wrote:
>>> Kever,
>>> 
>>>> On 25 Apr 2018, at 12:04, Philipp Tomsich 
>>>> <philipp.toms...@theobroma-systems.com> wrote:
>>>> 
>>>>> Add dts node for timer3.
>>>>> Because of the rockchip timer can only KNOWN "dtd_rockchip_rk3368_timer"
>>>>> with OF_PLATDATA enable, so we override its compatible to
>>>>> "rockchip,rk3368-timer".
>>>>> 
>>>>> Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
>>>>> ---
>>>>> 
>>>>> arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 6 ++
>>>>> arch/arm/dts/rk3188.dtsi  | 6 ++
>>>>> 2 files changed, 12 insertions(+)
>>>>> 
>>>> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
>>> This looks like a work-around that we’ll have to revert eventually.
>>> I would instead extend the driver to recognise the ‘rockchip,rk3188-timer’
>>> and ‘rockchip,rk3288-timer’ as well.
>>> 
>>> Please confirm that both these .compatible strings should also be handled
>>> by the same driver and I’ll make the change when applying this series.
>> 
>> Do you mean you want patch like this? I do not like add lots
>> #ifdef/#elif like this.
>> +++ b/drivers/timer/rockchip_timer.c
>> @@ -17,7 +17,11 @@ DECLARE_GLOBAL_DATA_PTR;
>> 
>> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>> struct rockchip_timer_plat {
>> +#ifdef CONFIG_ROCKCHIP_RK3368
>>struct dtd_rockchip_rk3368_timer dtd;
>> +#elif CONFIG_ROCKCHIP_RK3188
>> +   struct dtd_rockchip_rk3188_timer dtd;
>> +#endif
>> };
>> #endif
> 
> The OF_PLATDATA implementation is really broken in this regard: the
> only fix I can think of would be to emit "struct dtd_…” for every compatible
> listed in the DTS.

I stand corrected: the OF_PLATDATA implementation (i.e. dtoc) already
created #define entries for all aliases in the compatible-list of a DTS node.

We’ll have to clean up our DTS files and this driver in the next release
cycle and simply need to make sure that a common compatible is found
across all devices (and the driver expects that common structure name).

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

[U-Boot] [PULL] Please pull u-boot-rockchip

[Dr. Philipp Tomsich]

Tom,

I have a number of fixes, cleanups and config-changes for the upcoming release
ready for you in u-boot-rockchip/master.  Please pull.

The Travis-CI report for this tree can be found at
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/371249739

Thanks,
Philipp.


The following changes since commit 5512f5ccf1dc5cec068f8efa1d8ce81f51a988d3:

  Merge git://git.denx.de/u-boot-video (2018-04-24 20:27:43 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to eb3d707e99fcd2213d5f8f0fe4ae53ad416b377e:

  rockchip: defconfig: remove CONFIG_SYS_NS16550 (2018-04-25 22:20:07 +0200)


Heinrich Schuchardt (1):
  rockchip: rk3288: provide ${fdtfile}

Kever Yang (11):
  rockchip: rk3188: add -u-boot.dtsi for rock-rk3188
  rockchip: rk3188: add timer3 node
  rockchip: rk3188: use DM timer instead of rk_timer
  rockchip: rk3036: add ofdata_to_platdata() method for driver
  rockchip: rk3128: add ofdata_to_platdata() method for driver
  rockchip: rv1108: add ofdata_to_platdata() method for driver
  rockchip: rk322x: update TPL_TEXT_BASE
  rockchip: rk322x: update MACRO for back-to-brom
  Revert "rockchip: firefly: Add "usb start" to auto-start USB device"
  rockchip: enable SYS_NS16550 for all SoCs by default
  rockchip: defconfig: remove CONFIG_SYS_NS16550

Klaus Goger (1):
  rockchip: defconfig: puma-rk3399: enable RTC

Patrick Uiterwijk (1):
  arm: rockchip: make_fit_atf: remove unneeded imports

Peter Robinson (1):
  config: evb-rk3399: enable make uboot.itb

Philipp Tomsich (1):
  rockchip: timer: add compatible strings for rk3188 and rk3288

Wadim Egorov (1):
  rockchip: clk: rk3288: add clk_enable function and support USB HOST0/HSIC

 arch/arm/Kconfig  |  1 +
 arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 24 
 arch/arm/dts/rk3188-radxarock.dts |  6 +-
 arch/arm/dts/rk3188.dtsi  |  8 ++--
 arch/arm/mach-rockchip/Kconfig|  1 -
 arch/arm/mach-rockchip/Makefile   |  2 ++
 arch/arm/mach-rockchip/make_fit_atf.py|  2 --
 arch/arm/mach-rockchip/rk3188-board-spl.c |  2 --
 arch/arm/mach-rockchip/rk322x-board-spl.c |  2 +-
 configs/chromebit_mickey_defconfig|  1 -
 configs/chromebook_jerry_defconfig|  1 -
 configs/chromebook_minnie_defconfig   |  1 -
 configs/evb-rk3128_defconfig  |  1 -
 configs/evb-rk3229_defconfig  |  1 -
 configs/evb-rk3288_defconfig  |  1 -
 configs/evb-rk3328_defconfig  |  1 -
 configs/evb-rk3399_defconfig  |  4 +++-
 configs/fennec-rk3288_defconfig   |  1 -
 configs/firefly-rk3288_defconfig  |  1 -
 configs/firefly-rk3399_defconfig  |  1 -
 configs/miqi-rk3288_defconfig |  1 -
 configs/phycore-rk3288_defconfig  |  1 -
 configs/popmetal-rk3288_defconfig |  1 -
 configs/puma-rk3399_defconfig |  3 ++-
 configs/rock2_defconfig   |  1 -
 configs/rock_defconfig|  4 +++-
 configs/tinker-rk3288_defconfig   |  1 -
 configs/vyasa-rk3288_defconfig|  1 -
 drivers/clk/rockchip/clk_rk3036.c | 11 ++-
 drivers/clk/rockchip/clk_rk3128.c | 11 ++-
 drivers/clk/rockchip/clk_rk3288.c | 13 +
 drivers/clk/rockchip/clk_rv1108.c | 10 +-
 drivers/timer/rockchip_timer.c|  2 ++
 include/configs/firefly-rk3288.h  |  3 +--
 include/configs/rk3036_common.h   |  3 ---
 include/configs/rk3128_common.h   |  2 --
 include/configs/rk3188_common.h   |  5 -
 include/configs/rk322x_common.h   |  3 +--
 include/configs/rk3288_common.h   |  3 +--
 include/configs/rv1108_common.h   |  3 ---
 40 files changed, 90 insertions(+), 54 deletions(-)
 create mode 100644 arch/arm/dts/rk3188-radxarock-u-boot.dtsi
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,2/3] rockchip: rk3188: add timer3 node

[Dr. Philipp Tomsich]

> On 26 Apr 2018, at 04:50, Kever Yang <kever.y...@rock-chips.com> wrote:
> 
> Hi Philipp,
> 
> On 04/25/2018 06:17 PM, Dr. Philipp Tomsich wrote:
>> Kever,
>> 
>>> On 25 Apr 2018, at 12:04, Philipp Tomsich 
>>> <philipp.toms...@theobroma-systems.com> wrote:
>>> 
>>>> Add dts node for timer3.
>>>> Because of the rockchip timer can only KNOWN "dtd_rockchip_rk3368_timer"
>>>> with OF_PLATDATA enable, so we override its compatible to
>>>> "rockchip,rk3368-timer".
>>>> 
>>>> Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
>>>> ---
>>>> 
>>>> arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 6 ++
>>>> arch/arm/dts/rk3188.dtsi  | 6 ++
>>>> 2 files changed, 12 insertions(+)
>>>> 
>>> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
>> This looks like a work-around that we’ll have to revert eventually.
>> I would instead extend the driver to recognise the ‘rockchip,rk3188-timer’
>> and ‘rockchip,rk3288-timer’ as well.
>> 
>> Please confirm that both these .compatible strings should also be handled
>> by the same driver and I’ll make the change when applying this series.
> 
> Do you mean you want patch like this? I do not like add lots
> #ifdef/#elif like this.
> +++ b/drivers/timer/rockchip_timer.c
> @@ -17,7 +17,11 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
>  struct rockchip_timer_plat {
> +#ifdef CONFIG_ROCKCHIP_RK3368
> struct dtd_rockchip_rk3368_timer dtd;
> +#elif CONFIG_ROCKCHIP_RK3188
> +   struct dtd_rockchip_rk3188_timer dtd;
> +#endif
>  };
>  #endif

The OF_PLATDATA implementation is really broken in this regard: the
only fix I can think of would be to emit "struct dtd_…” for every compatible
listed in the DTS.

> @@ -153,6 +157,7 @@ static const struct timer_ops rockchip_timer_ops = {
>  
>  static const struct udevice_id rockchip_timer_ids[] = {
> { .compatible = "rockchip,rk3368-timer" },
> +   { .compatible = "rockchip,rk3188-timer" },
> {}
>  };

I actually referred only to this part (i.e. adding the .compatible).

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

Re: [U-Boot] [PATCH] sysreset: rockchip: use dev_read_addr_ptr get cru base

[Dr. Philipp Tomsich]

Andy,

> On 24 Mar 2018, at 11:50, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
> 
>> On 24 Mar 2018, at 07:49, Andy Yan <andy@rock-chips.com> wrote:
>> 
>> Use system api dev_read_addr_ptr to get cru reg base,
>> rather than rockchip private api rockchip_get_cru, which
>> will be cleanup later.
>> 
>> Signed-off-by: Andy Yan <andy@rock-chips.com>
> 
> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
> Reviewed-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>

This one breaks the build:
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/371147039
Please revise accordingly.

Always ensure that a submitted series does not cause any build failures
 as this is a major distraction when trying to process multiple series…

Thanks,
Philipp.

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

Re: [U-Boot] [U-Boot,2/3] rockchip: rk3188: add timer3 node

[Dr. Philipp Tomsich]

Kever,

> On 25 Apr 2018, at 12:04, Philipp Tomsich 
>  wrote:
> 
>> Add dts node for timer3.
>> Because of the rockchip timer can only KNOWN "dtd_rockchip_rk3368_timer"
>> with OF_PLATDATA enable, so we override its compatible to
>> "rockchip,rk3368-timer".
>> 
>> Signed-off-by: Kever Yang 
>> ---
>> 
>> arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 6 ++
>> arch/arm/dts/rk3188.dtsi  | 6 ++
>> 2 files changed, 12 insertions(+)
>> 
> 
> Acked-by: Philipp Tomsich 

This looks like a work-around that we’ll have to revert eventually.
I would instead extend the driver to recognise the ‘rockchip,rk3188-timer’
and ‘rockchip,rk3288-timer’ as well.

Please confirm that both these .compatible strings should also be handled
by the same driver and I’ll make the change when applying this series.

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

Re: [U-Boot] [PATCH v2 3/3] rockchip: rv1108: add ofdata_to_platdata() method for driver

[Dr. Philipp Tomsich]

> On 24 Apr 2018, at 05:27, Kever Yang  wrote:
> 
> Parse of data in dedicated api instead of in probe().
> 
> The clk_set_rate() may be called before the clk driver is probed,
> after core support set default clock.
> This patch fix system abort issue since:
> f4fcba5 clk: implement clk_set_defaults()
> 
> Signed-off-by: Kever Yang 

Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH v2 2/3] rockchip: rk3128: add ofdata_to_platdata() method for driver

[Dr. Philipp Tomsich]

> On 24 Apr 2018, at 05:27, Kever Yang  wrote:
> 
> Parse of data in dedicated api instead of in probe().
> 
> The clk_set_rate() may be called before the clk driver is probed,
> after core support set default clock.
> This patch fix system abort issue since:
> f4fcba5 clk: implement clk_set_defaults()
> 
> Signed-off-by: Kever Yang 

Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Dr. Philipp Tomsich]

Kever,

> On 13 Apr 2018, at 09:51, Kever Yang  wrote:
> On 04/08/2018 09:45 AM, Kever Yang wrote:
> 
 +__weak int arch_cpu_init(void)
 +{
 +return 0;
 +}
 +
 +__weak int rk_board_init_f(void)
 +{
 +return 0;
 +}
>>> This doesn't really help in modularising our board-support and I am
>>> not a fan of adding something like 'rk_board_init_f' in the first place.
>>> 
>>> Instead this should be implemented in a way that actually makes the
>>> code structure easier and more resilient for the future (having __weak
>>> functions at the architecture-level doesn't really help)... in fact
>>> the only other uses of __weak in the U-Boot source-base are within
>>> SPL, as there's no other way to provide hooks there.
>> I know your proposal is to use DM for board init, then could you make it
>> more
>> clear about how to handle this in your solution?
>> We need to do:
>> - same board init flow for all rockchip platform;
>> - something different but common in soc level;
>> - something different in board level;
> 
> I didn't see your response for this, could you send out your patches?

This isn’t at the stage of a patch-set yet… I had asked for comments to
this, so we could design this in a way that benefits all platforms.

> I admit that I'm not very clear about the limitation of '__weak' function,
> but I do see there are many '__weak' function in common/board_f/r.c,
> and my common board file is connect to the board_r.c.

I like __weak as a way to provide a hook for something that is part of the
common API (so it’s ok, if spl.c uses this).  However, I don’t want individual
platforms to suddenly expose new extension points.

And with the two examples above (arch_cpu_init and rk_board_init_f), you
basically highlight what’s wrong about using __weak at this level:
1   arch_cpu_init is an extension point to do low-level initialisation for a
CPU (not a board).  Implementation for it usually live below 
arch/arm/cpu
and takes care of things like MMU maintenance.  Now we suddenly provide
this below arch/arm/mach-rockchip … and using a __weak function.
This goes against everything that users will expect.  So just move it
to arch/arm/cpu (you’ll probably need to have 2 separate ones for
armv7 and armv8) and nothing unexpected will ever happen.
2   If we rk_board_init_f here, we are again changing the extension API
of U-Boot: board_init_f belongs to each board (i.e. any board can expect
to override it w/o ill effect), but now you’d suddenly create a link 
error.
Instead users need to override rk_board_init_f.  This is a documentation
nightmare (and the current solution would be to provide a common
function that all board_init_f implementations could call as their head
or tail…).

My question—as to whether the DM could/should be extended to CPUs,
SoCs, architectures and boards—was meant to discuss exactly these
observed issues in how boards and SoCs today interact.

I usually don’t mind to touch APIs and extend them (or the driver model),
but a solution for how to handle board/SoC/CPU init sequences is nothing
I want to start before getting an actual design discussion going and reaching
something resembling a consensus of how this aspect of U-Boot should be
structured in a year’s (or two years’) time.

> 
> @Simon, @Tom,
> Could you kindly give some comment here?
> 
> Thanks,
> - Kever

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

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Dr. Philipp Tomsich]

> On 10 Apr 2018, at 14:32, Tom Rini  wrote:
> 
> On Tue, Apr 10, 2018 at 02:54:09PM +0800, Kever Yang wrote:
>> Hi Tom,
>> 
>> 
>> On 04/09/2018 06:35 AM, Tom Rini wrote:
 I have do a lot of test and re-work in my local branch and at last make
 it landed in
 rockchip vendor U-Boot, with testing in most of SoCs(not including
 rk3066/rk3188).
 Well, I do try to split it into pieces, but I found that actually not
 help very much
 except waste much more time:
 - The target is(very clear) to make rockchip soc board file in a good
 shape with common files,
 instead of copy-paste for each soc(more than 10 of them now)
 - then we need to identify what's common and what should go to soc and
 board;
 - remove using common rockchip timer and use arm generic timer instead
 for armv7
 SoCs(rk3066 and rk3188 need still using rockchip timer)
 - most soc need to do uart init, boot order select, and some
 arch_cpu_init().
 - don't break the boards already working, so I still leave some code
 which not so common
 in board file, but I would like to remove or move them into right
 place if I got a board
 to verify;
 
 @Simon, @Tom,
 This patch set is to remove some common files and add some other common
 files for
 all Rockchip SoCs, I have to make sure the whole patch set can running
 good for all SoCs,
 but it's really hard to make every patch to build and work perfect for
 all SoCs, is there
 any mandatory rules for this?
>>> So you mean possibly breaking some existing platforms?  I don't like the
>>> idea of doing that...
>> 
>> No, I'm not intent to to breaking some existing platforms,
>> this patch set including 36 patches, all the platform should work fine
>> after apply all these patches, but if only some of them applied,
>> there is compile error or running error because of feature missing.
> 
> OK.  Similar to the Linux kernel, it's not a good thing to break
> buildability of things during a patch series.


Independent of this: this is not a single series, but multiple series rolled
into one.  Once the commit messages are reworked to convey what’s
changed in a more meaningful way, this will be even more apparent
than it already is today.

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

Re: [U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default

[Dr. Philipp Tomsich]

> On 9 Apr 2018, at 10:01, Neil Armstrong  wrote:
> 
> On 30/03/2018 18:52, Joe Hershberger wrote:
>> Some boards expect to find more than one phy while other boards are old
>> and need to be limited to a specific phy address. Only limit the phy
>> address for boards that opt in.
>> 
>> Signed-off-by: Joe Hershberger 

Reviewed-by: Philipp Tomsich 

See below for recommended change.

>> 
>> ---
>> 
>> configs/am335x_baltos_defconfig| 1 +
>> configs/am335x_shc_defconfig   | 1 +
>> configs/am335x_shc_ict_defconfig   | 1 +
>> configs/am335x_shc_netboot_defconfig   | 1 +
>> configs/am335x_shc_prompt_defconfig| 1 +
>> configs/am335x_shc_sdboot_defconfig| 1 +
>> configs/am335x_shc_sdboot_prompt_defconfig | 1 +
>> configs/devkit3250_defconfig   | 1 +
>> configs/ds414_defconfig| 1 +
>> configs/khadas-vim_defconfig   | 1 +
>> configs/libretech-cc_defconfig | 1 +
>> configs/p212_defconfig | 1 +
>> configs/pepper_defconfig   | 1 +
>> configs/work_92105_defconfig   | 1 +
>> configs/x600_defconfig | 1 +
>> drivers/net/phy/Kconfig| 8 
>> 16 files changed, 23 insertions(+)
>> 
>> diff --git a/configs/am335x_baltos_defconfig 
>> b/configs/am335x_baltos_defconfig
>> index ab7d96d..ed7d3a7 100644
>> --- a/configs/am335x_baltos_defconfig
>> +++ b/configs/am335x_baltos_defconfig
>> @@ -42,6 +42,7 @@ CONFIG_BOOTCOUNT_LIMIT=y
>> CONFIG_SYS_OMAP24_I2C_SPEED=1000
>> CONFIG_MMC_OMAP_HS=y
>> CONFIG_NAND=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_defconfig b/configs/am335x_shc_defconfig
>> index fb714da..ade16b9 100644
>> --- a/configs/am335x_shc_defconfig
>> +++ b/configs/am335x_shc_defconfig
>> @@ -35,6 +35,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_ict_defconfig 
>> b/configs/am335x_shc_ict_defconfig
>> index 2568e3d..ac19a74 100644
>> --- a/configs/am335x_shc_ict_defconfig
>> +++ b/configs/am335x_shc_ict_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_netboot_defconfig 
>> b/configs/am335x_shc_netboot_defconfig
>> index 16071fb..31f1847 100644
>> --- a/configs/am335x_shc_netboot_defconfig
>> +++ b/configs/am335x_shc_netboot_defconfig
>> @@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_prompt_defconfig 
>> b/configs/am335x_shc_prompt_defconfig
>> index bbad6dd..803304e 100644
>> --- a/configs/am335x_shc_prompt_defconfig
>> +++ b/configs/am335x_shc_prompt_defconfig
>> @@ -34,6 +34,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_sdboot_defconfig 
>> b/configs/am335x_shc_sdboot_defconfig
>> index 82a61a3..2d4f4d1 100644
>> --- a/configs/am335x_shc_sdboot_defconfig
>> +++ b/configs/am335x_shc_sdboot_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_sdboot_prompt_defconfig 
>> b/configs/am335x_shc_sdboot_prompt_defconfig
>> index 82a61a3..2d4f4d1 100644
>> --- a/configs/am335x_shc_sdboot_prompt_defconfig
>> +++ b/configs/am335x_shc_sdboot_prompt_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig
>> index e1a9b49..b69808c 100644
>> --- a/configs/devkit3250_defconfig
>> +++ b/configs/devkit3250_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_MTD_NOR_FLASH=y
>> CONFIG_NAND=y
>> CONFIG_SPL_NAND_SIMPLE=y
>> CONFIG_PHYLIB=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHY_ADDR=31
>> CONFIG_DM_SERIAL=y
>> CONFIG_SYS_NS16550=y
>> diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
>> index 5d1d6ab..d68e64e 100644
>> --- a/configs/ds414_defconfig
>> +++ b/configs/ds414_defconfig
>> @@ -39,6 +39,7 @@ 

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Dr. Philipp Tomsich]

Kever,

> On 8 Apr 2018, at 03:45, Kever Yang  wrote:
> 
> Philipp,
> 
> 
> On 04/02/2018 05:28 AM, Philipp Tomsich wrote:
>> 
>> 
>> On Tue, 27 Mar 2018, Kever Yang wrote:
>> 
>>> We use common board/spl/tpl file for all rockchip SoCs,
>>> - all the SoC spec setting should move into SoC file like rk3288.c;
>>> - tpl is option and only purpose to init DRAM, clock, uart(option);
>>> - spl do secure relate one time init, boot device select, boot into
>>>  U-Boot or trust or OS in falcon mode;
>>> - board do boot mode detect, enable regulator, usb init and so on.
>> 
>> There's too much going on in a single commit/single series.
>> This needs to be split up into multiple, independent steps (e.g. one
>> for the timer changes, another one for the UART changes)...
> 
> I understand review the patches piece by piece is much more comfortable,

In fact I do not like to do these reviews, as they are a tiresome chore…
…but they need to be done, as some issues are best caught at this stage.
Note, that a good commit message (i.e. one that summarises the status
quo/presents the motivation for the specific change; then summarises
what is changed how and to what effect; finally notes on anything that
the reviewer/someone debugging in the future should know) helps very
much in reviewing.

However, a review can not catch all issues and once a patch-set gets
to a certain level of complexity, it is likely to introduce unnecessary
breakage that could have been avoided in a review (if there simply
hadn’t been too many changes at once).

Consequently, we need a clean history consisting of orthogonal changes
so we can bisect and revert if necessary (and I’d prefer not to revert an
entire series)… which again requires patches that are (a) in a healthy
application-order and (b) do a well-defined number of things well.

> and this patch including "too much" things. And I never expect this
> patch set
> can be merge quickly, but we have to do this ASAP before more SoC coming.

The quickest way to get at least some of this merged quickly (e.g. the
UART changes) is to have smaller series for these.

> I have do a lot of test and re-work in my local branch and at last make
> it landed in
> rockchip vendor U-Boot, with testing in most of SoCs(not including
> rk3066/rk3188).
> Well, I do try to split it into pieces, but I found that actually not
> help very much
> except waste much more time:
> - The target is(very clear) to make rockchip soc board file in a good
> shape with common files,
> instead of copy-paste for each soc(more than 10 of them now)
> - then we need to identify what's common and what should go to soc and
> board;
> - remove using common rockchip timer and use arm generic timer instead
> for armv7
> SoCs(rk3066 and rk3188 need still using rockchip timer)
> - most soc need to do uart init, boot order select, and some
> arch_cpu_init().
> - don't break the boards already working, so I still leave some code
> which not so common
> in board file, but I would like to remove or move them into right
> place if I got a board
> to verify;
> 
> @Simon, @Tom,
> This patch set is to remove some common files and add some other common
> files for
> all Rockchip SoCs, I have to make sure the whole patch set can running
> good for all SoCs,
> but it's really hard to make every patch to build and work perfect for
> all SoCs, is there
> any mandatory rules for this?
> 
> I have to do a lot of temporary work for this like add temporary MACRO
> for those SoCs
> convert to use common code, and remove it after all the SoCs have
> convert to use common
> code, which have no any help for what we get at last, but it really cost
> a lot of time.
> 
>> 
>>> 
>>> Signed-off-by: Kever Yang 
>> 
>> See below for requested changes (beyond splitting this up).
>> Reviewing this in this state is a real chore, so I'll probably have
>> more comments, once I see this presented in more manageable parcels.
>> 
>>> ---
>>> 
>>> arch/arm/mach-rockchip/Makefile |  23 +
>>> arch/arm/mach-rockchip/board.c  | 136 
>>> arch/arm/mach-rockchip/spl.c| 195
>>> 
>>> arch/arm/mach-rockchip/tpl.c| 111 +++
>>> 4 files changed, 445 insertions(+), 20 deletions(-)
>>> create mode 100644 arch/arm/mach-rockchip/board.c
>>> create mode 100644 arch/arm/mach-rockchip/spl.c
>>> create mode 100644 arch/arm/mach-rockchip/tpl.c
>>> 
>>> diff --git a/arch/arm/mach-rockchip/Makefile
>>> b/arch/arm/mach-rockchip/Makefile
>>> index e1b0519..3aba66c 100644
>>> --- a/arch/arm/mach-rockchip/Makefile
>>> +++ b/arch/arm/mach-rockchip/Makefile
>>> @@ -11,15 +11,8 @@
>>> obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
>>> obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
>>> 
>>> -obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o
>>> -obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
>>> -
>>> 

Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Dr. Philipp Tomsich]

Kever,

> On 9 Apr 2018, at 00:35, Tom Rini  wrote:
> 
> On Sun, Apr 08, 2018 at 09:45:22AM +0800, Kever Yang wrote:
>> Philipp,
>> 
>> 
>> On 04/02/2018 05:28 AM, Philipp Tomsich wrote:
>>> 
>>> 
>>> On Tue, 27 Mar 2018, Kever Yang wrote:
>>> 
 We use common board/spl/tpl file for all rockchip SoCs,
 - all the SoC spec setting should move into SoC file like rk3288.c;
 - tpl is option and only purpose to init DRAM, clock, uart(option);
 - spl do secure relate one time init, boot device select, boot into
  U-Boot or trust or OS in falcon mode;
 - board do boot mode detect, enable regulator, usb init and so on.
>>> 
>>> There's too much going on in a single commit/single series.
>>> This needs to be split up into multiple, independent steps (e.g. one
>>> for the timer changes, another one for the UART changes)...
>> 
>> I understand review the patches piece by piece is much more comfortable,
>> and this patch including "too much" things. And I never expect this
>> patch set
>> can be merge quickly, but we have to do this ASAP before more SoC coming.
>> I have do a lot of test and re-work in my local branch and at last make
>> it landed in
>> rockchip vendor U-Boot, with testing in most of SoCs(not including
>> rk3066/rk3188).
>> Well, I do try to split it into pieces, but I found that actually not
>> help very much
>> except waste much more time:
>> - The target is(very clear) to make rockchip soc board file in a good
>> shape with common files,
>> instead of copy-paste for each soc(more than 10 of them now)
>> - then we need to identify what's common and what should go to soc and
>> board;
>> - remove using common rockchip timer and use arm generic timer instead
>> for armv7
>> SoCs(rk3066 and rk3188 need still using rockchip timer)
>> - most soc need to do uart init, boot order select, and some
>> arch_cpu_init().
>> - don't break the boards already working, so I still leave some code
>> which not so common
>> in board file, but I would like to remove or move them into right
>> place if I got a board
>> to verify;

Having a clean commit-history and the ability to bisect and revert individual
patches is an important requirement for the overall project.

I thought to have already provided you the needed guidance on how to get
most fo this merged and highlighted where architectural discussions will be
needed.

So to get most of this merged quickly, you will need to break this up into
series that are more manageable (this is likely to not be a full list):
 * the changes for split out the UART configs
 * the timer changes
 * adding a common board-file and switching boards over
For the common board-file, you should add this first and then start moving
SoCs over onto this new file.  I believe (my memory may be wrong) to have
commented so in some of the individual reviews.

Finally, there’s a few architectural issues to discuss:
 1. You are merging the “board”-files, but these are now merged across
multiple SoCs and across multiple boards per SoC.  This is already
causing some fraying at the edges (e.g. the number of rk_* hooks and
the weak functions added).  We should very carefully consider how
this will affect adding boards (which may have a specific market
segment in mind and may—for lack of a better example—not want
to have rockusb included) in the future.
 2. The new weak-functions are causing a major headache: they are at
odds with us trying to move to DM across the entire tree. I strongly
believe that these weak functions will cause added debug issues in
the short term and that they will eventually be replaced with more
DM-like model in the long term.

Thanks,
Philipp.

>> @Simon, @Tom,
>> This patch set is to remove some common files and add some other common
>> files for
>> all Rockchip SoCs, I have to make sure the whole patch set can running
>> good for all SoCs,
>> but it's really hard to make every patch to build and work perfect for
>> all SoCs, is there
>> any mandatory rules for this?
> 
> So you mean possibly breaking some existing platforms?  I don't like the
> idea of doing that...
> 
> -- 
> Tom

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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Dr. Philipp Tomsich]

> On 3 Apr 2018, at 12:39, Icenowy Zheng  wrote:
> 
> 
> 
> 于 2018年4月3日 GMT+08:00 下午6:13:17, Andre Przywara  > 写到:
>> Hi,
>> 
>> On 03/04/18 10:29, Maxime Ripard wrote:
>>> On Thu, Mar 29, 2018 at 01:21:38PM +0100, Andre Przywara wrote:
 Hi,
 
 On 29/03/18 10:37, Maxime Ripard wrote:
> On Wed, Mar 28, 2018 at 07:31:51PM +0800, Icenowy Zheng wrote:
>> 于 2018年3月28日 GMT+08:00 下午7:28:07, Maxime Ripard
>>  写到:
>>> On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote:
 
 
 于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard
>>>  写到:
> On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
>  写到:
>>> On Fri, Mar 23, 2018 at 04:18:56PM +0800, Icenowy Zheng
>> wrote:
 The get_ram_size() function in U-Boot can only deal with
>> memory
> size
 smaller than 2GiB. To enable the support of 3GiB DRAM on
>> newer
> 64-bit
 SoCs, an alternative way to detect DRAM size is needed.
>>> 
>>> Why not just fixing get_ram_size then?
>> 
>> Even if it's fixed it won't support 3GiB DRAM at all.
> 
> Why?
 
 It has an assumption that the size is pow of 2.
>>> 
>>> I guess this would be fixable too? (or one could create a variant
>>> without that assumption).
>> 
>> I don't think its principle allows such kind of fix, as it just
>> checks writing then reading at some offset that is pow if 2.
> 
> You could do have a bunch of algorithm actually. One would be to
>> write
> the address in memory and try to detect where exactly it starts to
> loop.
> 
> You could do a bisection in the opposite direction once you settled
> for the upper limit (so you would have for example a workable 2G, a
> non-workable 4G, and then you try intervals that you always divide
>> by
> two, so testing then 3G (that works), then halfway between 3G and
>> 4G,
> etc.
> 
>> For hacking it, see my implementation in v1, which assumes the
>> only size supported bigger than 2GiB is 3GiB (which is
>> acceptable on sunxi, but might not work on other platforms).
>> 
>> As Andre said, that function has another big problem -- it detects
>> memory with writing to it. This is risky.
> 
> How is it risky when it's done by the SPL?
 
 Originally that was my confusion as well: It's not the SPL calling
>> that
 function. The DRAM controller init function in there knows very
 precisely how much DRAM we have, but we don't communicate this to
>> U-Boot
 proper. So U-Boot *proper* goes ahead and probes the DRAM. This
>> means it
 could step into secure memory, for instance. On sunxi64 we have the
>> ATF
 running between SPL and U-Boot, also all kind of secure payloads
>> could
 already have been registered.
 So I wonder if it would be easier to somehow pass on this *one* word
>> of
 information between SPL and U-Boot proper to avoid calling this
>> function
 altogether?
>>> 
>>> That would definitely make sense yes.
>> 
>> So since the SPL loads the DT anyway (from the FIT image) and puts it
>> at
>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>> just patch the actual DRAM size in there?
>> IIRC we don't have any FDT write code in the SPL at the moment, and
>> pulling it in would probably push it over the edge again, but:
>> We should be able to somewhat short-cut it, if it's just about to
>> actually *patch* an existing value, as of:
>> - make sure we have a memory node and a reg property in the DT
>> - in the SPL learn the fdt offset of that reg property
>> -  patch in the memory size into the second word 
>> - teach U-Boot proper to read the memory size from the DT
>> - optionally look at #address-cells and #size-cells to make this
>> "second
>> word hack" more robust
>> 
>> This could actually be a rather generic patch, just with some "avoid
>> libfdt write library" hack to address our size issue. Maybe we already
>> have something like that for some platform (Rockchip comes to mind?)
> 
> Rockchip recalculates the memory size with the parameters
> in GRF when running the main U-Boot, so both TPL/SPL
> and miniloader can load mainline U-Boot.

More accurately, the GRF currently is used to store an encoded DRAM
configuration and the next stage can rely on this being there.

If the memory is initialised by miniloader, U-Boot reads the GRF and calculates
the memory size from that.  If U-Boot sets up DRAM, then it also populates the
GRF registers.

With more and more SOCs moving away from miniloader, there’s a good chance
that this will change at some point in the future and the 

Re: [U-Boot] [PATCH 1/2] image: fit: Show firmware configuration property if present

[Dr. Philipp Tomsich]

> On 26 Mar 2018, at 16:31, Michal Simek  wrote:
> 
> SPL ATF support requires to have firmware property which should be also
> listed by mkimage -l when images is created.
> 
> The patch is also using this macro in spl_fit to match keyword.
> 
> When image is created:
> Default Configuration: 'config'
> Configuration 0 (config)
>  Description:  ATF with full u-boot
>  Kernel:   unavailable
>  Firmware: atf
>  FDT:  dtb
> 
> Signed-off-by: Michal Simek 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [U-Boot, 18/36] rockchip: rk3188: remove rockchip timer as sys timer

[Dr. Philipp Tomsich]

Arturri,

> On 2 Apr 2018, at 11:38, Artturi Alm  wrote:
> 
> On Sun, Apr 01, 2018 at 10:21:50PM +0200, Philipp Tomsich wrote:
>>> We use ARM arch timer instead.
>>> 
>>> Signed-off-by: Kever Yang 
>>> ---
>>> 
>>> include/configs/rk3188_common.h | 3 ---
>>> 1 file changed, 3 deletions(-)
>>> 
>> 
>> Acked-by: Philipp Tomsich 
> 
> fwiw., i don't believe rk3188(Cortex-A9) has the armv7 'arch timer'.
> please do test before applying..

I won’t be able to test this one (and a number other ones), as I only
have access to RK3399 and RK3368 boards.

Feel free to validate this on your end and comment on this patch.

This patch set is not on my list for the current release cycle, due to
it affecting all boards and the associated test effort needed.  I am
considering either for a ‘next’-branch or for a topic-branch to be
created later in this cycle (e.g. branched off rc2?).

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

Re: [U-Boot] [PATCH] mkimage: do not fail if there is no print_header function

[Dr. Philipp Tomsich]

> On 30 Mar 2018, at 10:28, Guillaume GARDET  wrote:
> 
> Commit 253c60a breaks the exit value of 'mkimage -T rkimage'
> and print the following  error:
>  mkimage: Can't print header for Rockchip Boot Image support: Success
> 
> It is not a failure to not print headers, so just display the warning message,
> and finish the function properly.
> 
> Signed-off-by: Guillaume GARDET 

Reviewed-by: Philipp Tomsich 

> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
> tools/mkimage.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 28ff35e670..4e561820e7 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -588,9 +588,8 @@ int main(int argc, char **argv)
>   if (tparams->print_header)
>   tparams->print_header (ptr);
>   else {
> - fprintf (stderr, "%s: Can't print header for %s: %s\n",
> - params.cmdname, tparams->name, strerror(errno));
> - exit (EXIT_FAILURE);
> + fprintf (stderr, "%s: Can't print header for %s\n",
> + params.cmdname, tparams->name);
>   }
> 
>   (void) munmap((void *)ptr, sbuf.st_size);
> -- 
> 2.13.6
> 

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

[U-Boot] [PULL] Please pull from u-boot-rockchip

[Dr. Philipp Tomsich]

Tom,

Here’s a PR for a few changes available on the rockchip-tree for integration 
into master.
While these are mainly bug-fixes, the plan is to have another PR either 
just-in-time for rc1
or slightly after with some larger series that still need review and discussion.

Thanks,
Philipp.

The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f:

  Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to 6837c58666165b7b040bf5a5b9dfebc8354f5883:

  rockchip: sdhci: support 8bit bus-width (2018-03-28 23:47:08 +0200)


Alexander Kochetkov (3):
  rockchip: pinctrl: rk3036: Move the iomux definitions into pinctrl-driver
  rockchip: pinctrl: rk3188: Move the iomux definitions into pinctrl-driver
  rockchip: clk: rk3188: update dpll settings to make EMAC work

Heinrich Schuchardt (4):
  driver: ram: rockchip: rk3399: missing counter increment
  usb: rockchip: remove duplicate assignement.
  video: rk3399_mipi: correct error checking
  video: rk3288_mipi: check in rk_mipi_ofdata_to_platdata

Mark Kettenis (1):
  rockchip: rk3399: set fdtfile

Philipp Tomsich (5):
  rockchip: pinctrl: rk3399: fix GPIO2B1 and GPIO2B2 shift value
  rockchip: pinctrl: rk3399: add support for I2C[123467]
  rockchip: defconfig: puma-rk3399: enable DMA for SDHCI controller
  rockchip: mmc: update MAINTAINERS
  rockchip: sdhci: support 8bit bus-width

Punit Agrawal (2):
  video: rk3399_mipi: Combine NULL check into IS_ERR_OR_NULL()
  video: rk3288_mipi: Combine NULL check into IS_ERR_OR_NULL()

 MAINTAINERS |   2 +
 arch/arm/include/asm/arch-rockchip/grf_rk3036.h | 409 
-
 arch/arm/include/asm/arch-rockchip/grf_rk3188.h | 380 
--
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h |  34 -
 configs/puma-rk3399_defconfig   |   1 +
 drivers/clk/rockchip/clk_rk3188.c   |   2 +-
 drivers/mmc/rockchip_sdhci.c|   8 +++
 drivers/pinctrl/rockchip/pinctrl_rk3036.c   | 410 
++
 drivers/pinctrl/rockchip/pinctrl_rk3188.c   | 380 
++
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   |  61 ++--
 drivers/ram/rockchip/sdram_rk3399.c |   1 +
 drivers/usb/gadget/f_rockusb.c  |   1 -
 drivers/video/rockchip/rk3288_mipi.c|   2 +-
 drivers/video/rockchip/rk3399_mipi.c|   2 +-
 include/configs/rk3399_common.h |   1 +
 15 files changed, 893 insertions(+), 801 deletions(-)

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

Re: [U-Boot] [PATCH 26/36] rockchip: rk1108: remove rockchip timer for sys timer

[Dr. Philipp Tomsich]

> On 27 Mar 2018, at 11:29, Kever Yang  wrote:
> 
> We use ARM arch timer instead.

Could you please provide a more useful commit message.
Please consider that most people that look through the GIT log are
not familiar with our platform.

Thanks,
Philipp.

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

Re: [U-Boot] [PATCH] sysreset: rockchip: use dev_read_addr_ptr get cru base

[Dr. Philipp Tomsich]

> On 24 Mar 2018, at 07:49, Andy Yan  wrote:
> 
> Use system api dev_read_addr_ptr to get cru reg base,
> rather than rockchip private api rockchip_get_cru, which
> will be cleanup later.
> 
> Signed-off-by: Andy Yan 

Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Moving the rk_board_late_init() hook to a device-model based implementation.

[Dr. Philipp Tomsich]

Simon,

ping?

Thanks,
Philipp.

> On 26 Feb 2018, at 14:02, Dr. Philipp Tomsich 
> <philipp.toms...@theobroma-systems.com> wrote:
> 
> Simon & Kever,
> 
> We have the rk_board_late_init() hook for the Rockchip boards and I’d like to 
> convert
> these to some sort of device-model based implementation.
> 
> Here’s what I’d propose as a minimal implementation:
> 1.Introduce a new UCLASS_BOARD
> 2.Trigger on the top-level ‘compatible’ string (e.g. "tsd,rk3399-q7” for 
> our RK3399-Q7 board) from the DTS.
> 3.Provide ops for at least the following hooks:
>   .board_late_init[used on Rockchip for setup_boot_mode() 
> … or for calling rk_board_late_init]
>   .board_init_f   [e.g. our DDR and SRAM security region 
> setup]
>   .board_fit_config_name_match
> 
> For a more full-fledged implementation, I would like to have a UCLASS_SOC in 
> addition to the UCLASS_BOARD and iterate over the same list of compatible 
> strings to find a UCLASS_SOC … then perform a two step-init: i.e. first the 
> SOC, then the BOARD.
> This would be used to have common init-code, such as what we have for the 
> RK3399 in arch_cpu_init() — i.e. "Emmc clock generator: disable the clock 
> multipilier”.
> 
> Thanks in advance for taking the time to review and comment,
> —Philipp.
> 
> 
>> On 26 Feb 2018, at 13:37, Alexander Kochetkov <al.koc...@gmail.com> wrote:
>> 
>> All other rockchip boards have rk_board_late_init() hook,
>> so add it to rk3188 boards also.
>> 
>> Signed-off-by: Alexander Kochetkov <al.koc...@gmail.com>
>> ---
>> arch/arm/mach-rockchip/rk3188-board.c |7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/mach-rockchip/rk3188-board.c 
>> b/arch/arm/mach-rockchip/rk3188-board.c
>> index 916d18f..fc58aeb 100644
>> --- a/arch/arm/mach-rockchip/rk3188-board.c
>> +++ b/arch/arm/mach-rockchip/rk3188-board.c
>> @@ -20,6 +20,11 @@
>> 
>> DECLARE_GLOBAL_DATA_PTR;
>> 
>> +__weak int rk_board_late_init(void)
>> +{
>> +return 0;
>> +}
>> +
>> int board_late_init(void)
>> {
>>  struct rk3188_grf *grf;
>> @@ -35,7 +40,7 @@ int board_late_init(void)
>>  NOC_REMAP_MASK << NOC_REMAP_SHIFT);
>>  }
>> 
>> -return 0;
>> +return rk_board_late_init();
>> }
>> 
>> int board_init(void)
>> -- 
>> 1.7.9.5
>> 
> 
> ___
> 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 1/1] video: rk3399_mipi: correct error checking

[Dr. Philipp Tomsich]

Punit,

> On 19 Mar 2018, at 18:21, Punit Agrawal  wrote:
> 
> Heinrich Schuchardt > writes:
> 
>> Pointers are never negative. Use macro IS_ERR() for checking.
>> cf. rk3288_mipi.c
>> 
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> drivers/video/rockchip/rk3399_mipi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/video/rockchip/rk3399_mipi.c 
>> b/drivers/video/rockchip/rk3399_mipi.c
>> index 9ef202bf09..7560e0c07b 100644
>> --- a/drivers/video/rockchip/rk3399_mipi.c
>> +++ b/drivers/video/rockchip/rk3399_mipi.c
>> @@ -128,7 +128,7 @@ static int rk_mipi_ofdata_to_platdata(struct udevice 
>> *dev)
>>  struct rk_mipi_priv *priv = dev_get_priv(dev);
>> 
>>  priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
>> -if (priv->grf <= 0) {
>> +if (!priv->grf || IS_ERR(priv->grf)) {
> 
> The above two checks can be combined into IS_ERR_OR_NULL().

Please submit a patch and I’ll squash it onto this one.

Thanks,
Philipp.

> 
>>  debug("%s: Get syscon grf failed (ret=%p)\n",
>>__func__, priv->grf);
>>  return  -ENXIO;

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