Re: [U-Boot] [PATCH 4/4 v2] dm: test: Add test for device removal

[Simon Glass]

Hi Stefan,

On 20 March 2017 at 05:51, Stefan Roese  wrote:
> Add a test for the correct device removal. Currently two different ways
> for device removal are supported:
>
> - Normal device removal via the device_remove() API
> - Removal via selective device driver flags (DM_FLAG_ACTIVE_DMA)
>
> This new test "remove_active_dma" adds tests cases for those both ways
> of removal.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
> v2:
> - New patch in patchset
>
>  test/dm/core.c| 41 +
>  test/dm/test-driver.c |  1 +
>  2 files changed, 42 insertions(+)
>
> diff --git a/test/dm/core.c b/test/dm/core.c
> index 07b2419ea4..ef85e6b79c 100644
> --- a/test/dm/core.c
> +++ b/test/dm/core.c
> @@ -656,6 +656,47 @@ static int dm_test_pre_reloc(struct unit_test_state *uts)
>  }
>  DM_TEST(dm_test_pre_reloc, 0);
>
> +/*
> + * Test that removal of devices, either via the "normal" device_remove()
> + * API or via the device driver selective flag works as expected
> + */
> +static int dm_test_remove_active_dma(struct unit_test_state *uts)
> +{
> +   struct dm_test_state *dms = uts->priv;
> +   struct udevice *dev;
> +
> +   ut_assertok(device_bind_by_name(dms->root, false, _info_manual,
> +   ));
> +   ut_assert(dev);
> +
> +   /* Probe the device */
> +   ut_assertok(device_probe(dev));
> +
> +   /* Test if device is active right now */
> +   ut_asserteq(true, device_active(dev));
> +
> +   /* Remove the device via selective remove flag */
> +   dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
> +
> +   /* Test if device is inactive right now */
> +   ut_asserteq(false, device_active(dev));
> +
> +   /* Probe the device again */
> +   ut_assertok(device_probe(dev));
> +
> +   /* Test if device is active right now */
> +   ut_asserteq(true, device_active(dev));
> +
> +   /* Remove the device via "normal" remove API */
> +   ut_assertok(device_remove(dev, DM_REMOVE_NORMAL));

This doesn't actually test a device not getting removed (due to its
flag) I think. Can you add a test for that?

> +
> +   /* Test if device is inactive right now */
> +   ut_asserteq(false, device_active(dev));
> +
> +   return 0;
> +}
> +DM_TEST(dm_test_remove_active_dma, 0);
> +
>  static int dm_test_uclass_before_ready(struct unit_test_state *uts)
>  {
> struct uclass *uc;
> diff --git a/test/dm/test-driver.c b/test/dm/test-driver.c
> index d10af51147..1a2932e519 100644
> --- a/test/dm/test-driver.c
> +++ b/test/dm/test-driver.c
> @@ -145,6 +145,7 @@ U_BOOT_DRIVER(test_manual_drv) = {
> .probe  = test_manual_probe,
> .remove = test_manual_remove,
> .unbind = test_manual_unbind,
> +   .flags  = DM_FLAG_ACTIVE_DMA,
>  };
>
>  U_BOOT_DRIVER(test_pre_reloc_drv) = {
> --
> 2.12.0
>

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

Re: [U-Boot] [PATCH 2/4 v3] dm: core: Add dm_remove_devices_flags() and hook it into device_remove()

[Simon Glass]

Hi Stefan,

On 25 March 2017 at 19:17, Simon Glass  wrote:
> Hi Stefan,
>
> On 22 March 2017 at 00:28, Stefan Roese  wrote:
>> The new function dm_remove_devices_flags() is intented for driver specific
>> last-stage cleanup operations before the OS is started. This patch adds
>> this functionality and hooks it into the common device_remove()
>> function.
>>
>> Drivers wanting to use this feature for some last-stage removal calls,
>> need to add one of the DM_REMOVE_xx flags to their driver .flags.
>>
>> Signed-off-by: Stefan Roese 
>> Reviewed-by: Simon Glass 
>> ---
>> v3:
>> - Add conditional compilation to fix compilation breakage on platforms
>>   without DM and DM_DEVICE_REMOVE support. With this change, Travis
>>   compiles all targets without any error
>>
>> v2:
>> - Added Simons Reviewed-by
>>
>>  drivers/core/device-remove.c | 15 +++
>>  drivers/core/root.c  |  9 +
>>  include/dm/root.h| 16 
>>  3 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
>> index b80bf52320..ca4680f7c2 100644
>> --- a/drivers/core/device-remove.c
>> +++ b/drivers/core/device-remove.c
>> @@ -174,7 +174,12 @@ int device_remove(struct udevice *dev, uint flags)
>> if (ret)
>> goto err;
>>
>> -   if (drv->remove) {
>> +   /*
>> +* Remove the device if called with the "normal" remove flag set,
>> +* or if the remove flag matches the driver flags
>> +*/
>> +   if (drv->remove &&
>> +   ((flags & DM_REMOVE_NORMAL) || (flags & drv->flags))) {

This seems to be comparing different things. The DM_REMOVE_NORMAL flag
is not from the same enum as drv->flags, is it?

>
> You are changing the condition here but still call the post_remove()
> method immediately below. If you decide note to remove the device then
> I think you should not call that function.
>
>> ret = drv->remove(dev);
>> if (ret)
>> goto err_remove;
>> @@ -188,10 +193,12 @@ int device_remove(struct udevice *dev, uint flags)
>> }
>> }
>>
>> -   device_free(dev);
>> +   if ((flags & DM_REMOVE_NORMAL) || (flags & drv->flags)) {
>> +   device_free(dev);
>>
>> -   dev->seq = -1;
>> -   dev->flags &= ~DM_FLAG_ACTIVATED;
>> +   dev->seq = -1;
>> +   dev->flags &= ~DM_FLAG_ACTIVATED;
>> +   }
>>
>> return ret;

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

Re: [U-Boot] [PATCH] rockchip: clk: rk3399: 24MHz is not a power of 2

[Simon Glass]

On 24 March 2017 at 12:35, Philipp Tomsich
 wrote:
> The clock driver for the RK3399 mistakenly used (24 * 2^20) where it
> should have used (24 * 10^6) in a few calculations.
>
> This commits fixes this.
>
> Signed-off-by: Philipp Tomsich 
> ---
>
>  drivers/clk/rockchip/clk_rk3399.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH] ARMv8: add GOT sections to the list of sections copied

[Simon Glass]

On 24 March 2017 at 12:08, Philipp Tomsich
 wrote:
> Recent Linux distributions (e.g. Debian 9) include cross-compilers for
> AArch64, but only for the aarch64-linux-gnu triplet only. It can thus
> be expected that users will attempt to use the system cross-compiler
> (instead of an aarch64-elf variant) to compile U-Boot for their ARMv8
> target systems.
>
> One key differences between an aarch64-linux-gnu and an aarch64-elf
> compiler are the default settings regarding position-independent: with
> the aarch64-linux-gnu compiler, the default will create and use the
> global offset table.
>
> This change-set adjusts the list of sections copied on ARMv8 to include
> the GOT sections. With this added, the list matches the previous setup
> for AArch32 closely.
>
> Note that this is not an 'academic' issue, but was in fact encountered
> by our QA during testing of the RK3399-Q7 BSP and resulted in an
> early failure of the SPL stage during FDT setup.
>
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
>
> ---
>
>  arch/arm/config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH 5/6] dts: rk3399: add gmac for the rk3399

[Simon Glass]

On 24 March 2017 at 12:24, Philipp Tomsich
 wrote:
> This change adds the gmac node (i.e. the GMAC Ethernet controller) as
> defined in the Linux DTS.

It's useful to mention which version/commit of Linux you got it from.

>
> Signed-off-by: Philipp Tomsich 
> ---
>
>  arch/arm/dts/rk3399.dtsi | 55 
> 
>  1 file changed, 55 insertions(+)

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

Re: [U-Boot] [PATCH 3/6] rockchip: clk: rk3399: add clocking support for Ethernet

[Simon Glass]

On 24 March 2017 at 12:24, Philipp Tomsich
 wrote:
> The Ethernet driver for the RK3288/3399 GMAC makes sure that the clock
> is ungated through a call to clk_set_rate(...). Even though nothing
> needs to be done on the RK3399 (the clock gates are open and the clock
> is external), we need to implement enough support to at least return
> success to enable driver probing.
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> ---
>
>  drivers/clk/rockchip/clk_rk3399.c | 4 
>  1 file changed, 4 insertions(+)

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

Re: [U-Boot] [PATCH 6/6] dts: rk3399-puma: add gmac for the RK3399-Q7

[Simon Glass]

Hi Philipp,

On 24 March 2017 at 12:24, Philipp Tomsich
 wrote:
> This change enables the Gigabit Ethernet support on the RK3399-Q7.
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> ---
>
>  arch/arm/dts/rk3399-puma.dts | 30 ++
>  1 file changed, 30 insertions(+)

Acked-by: Simon Glass 

But I don't see this board in mainline. What tree are you basing this patch on?

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

Re: [U-Boot] [PATCH] rockchip: arm64: rk3399: remove unconditional debug message

[Simon Glass]

On 24 March 2017 at 12:10, Philipp Tomsich
 wrote:
> An earlier upstream change contained an unconditional debug message
> which would show up as a message similar to the following in the
> U-Boot startup (after the ATF and before the U-Boot banner):
>   time 159f019, 0
>
> This commit removes this message (instead of making if conditional on
> being a debug-build), as it doesn't pertain to any initialisation done
> in this file.
>
> Signed-off-by: Philipp Tomsich 
>
> ---
>
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 1 -
>  1 file changed, 1 deletion(-)

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

Re: [U-Boot] [PATCH] rockchip: spl: RK3399: add COUNTER_FREQUENCY define to rk3399_common.h

[Simon Glass]

On 23 March 2017 at 21:39, Kever Yang  wrote:
> Hi Philipp,
>
> On 03/24/2017 06:27 AM, Philipp Tomsich wrote:
>>
>> The BootROM of the RK3399 SoC does not initialise the cntfrq_el0 (which
>> holds the value 0 (zero) on entry into the SPL. This causes the timebase
>> for U-Boot not to advance (and will cause a hang where a timeout would
>> be expected... e.g. if something goes wrong during MMC/SD card startup).
>>
>> This change defines COUNTER_FREQUENCY, which is used by the AArch64 init
>> code in arch/arm/cpu/armv8/start.S to set up cntfrq_el0 (if necessary).
>>
>> Signed-off-by: Philipp Tomsich 
>> ---
>>
>>   include/configs/rk3399_common.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/configs/rk3399_common.h
>> b/include/configs/rk3399_common.h
>> index aeee805..c44f8ad 100644
>> --- a/include/configs/rk3399_common.h
>> +++ b/include/configs/rk3399_common.h
>> @@ -19,6 +19,8 @@
>>   #define CONFIG_SPL_DRIVERS_MISC_SUPPORT
>>   #define CONFIG_SPL_SERIAL_SUPPORT
>>   +#define COUNTER_FREQUENCY   2400
>> +
>>   #define CONFIG_SYS_NS16550_MEM32
>> #define CONFIG_SYS_TEXT_BASE0x0020
>
>
> Reveiwed-by: Kever Yang 

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

Re: [U-Boot] [PATCH 4/6] net: gmac_rockchip: Add support for the RK3399 GMAC

[Simon Glass]

On 25 March 2017 at 13:09, Joe Hershberger  wrote:
> On Fri, Mar 24, 2017 at 2:24 PM, Philipp Tomsich
>  wrote:
>> The GMAC in the RK3399 is very similar to the RK3288 variant (i.e. it
>> is a Designware GMAC core and requires similar configuration as the
>> RK3288 to switch it to RGMII and set up the TX/RX delays for Gigabit).
>> The key difference is that the register offsets (within the GRF block)
>> and bit-offsets (within those registers) used to hold the configuration
>> differ between the various RK32/33 CPUs.
>>
>> This change refactors the gmac_rockchip.c driver to use a function
>> table (selected via driver_data) to factor our these differences. Each
>
> Typo: "factor out".
>
>> function's implementation then matches the underlying processor.
>>
>> Some collateral changes are needed in the definitions describing the
>> bits and offsets in the GRF are needed to prefix each set of symbolic
>> constants with the SoC name to avoid name clashes... and in doing so,
>> the shifts for masks and constants have been moved into the header
>> files for readability (and to make it easier to stay below 80 chars).
>>
>> X-AffectedPlatforms: RK3399-Q7
>> Signed-off-by: Philipp Tomsich 
>> Tested-by: Klaus Goger 
>
> Acked-by: Joe Hershberger 

Acked-by: Simon Glass 

I can fix the typo when applying if there are no other comments.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] rockchip: pinctrl: rk3399: add GMAC (RGMII only) support

[Simon Glass]

On 24 March 2017 at 12:24, Philipp Tomsich
 wrote:
> To add GMAC (Gigabit Ethernet) support (limited to RGMII only at this
> point), we need support for additional pin-configuration.  This commit
> adds the pinctrl support for GMAC in RGMII signalling mode:
>  * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID
>  * adds the required defines (in the GRF support) for configuring the
>GPIOC pins for RGMII
>  * configures the RGMII pins (in GPIOC) when requested via pinctrl
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> ---
>
>  arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 37 ++
>  arch/arm/include/asm/arch-rockchip/periph.h |  1 +
>  drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 42 
> +
>  3 files changed, 80 insertions(+)
>

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

Re: [U-Boot] [PATCH 2/6] rockchip: clk: rk3399: fix warnings for unused variables in SPL/non-SPL

[Simon Glass]

On 24 March 2017 at 12:24, Philipp Tomsich
 wrote:
> Due to differences in the code paths for SPL and non-SPL, some static
> constant structures remain unused in each build variant. This raises
> warnings with recent GCC versions (we currently use GCC-6.3).
>
> The warnings addressed in this commit (by matching #if conditions for
> the variable definition with their uses) are:
>
> * for the SPL build:
> drivers/clk/rockchip/clk_rk3399.c:53:29: warning: 'cpll_init_cfg' defined 
> but not used [-Wunused-const-variable=]
>  static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2, 
> 2);
>  ^
> drivers/clk/rockchip/clk_rk3399.c:52:29: warning: 'gpll_init_cfg' defined 
> but not used [-Wunused-const-variable=]
>  static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2, 
> 1);
>  ^
> * for the non-SPL build:
> drivers/clk/rockchip/clk_rk3399.c:54:29: warning: 'ppll_init_cfg' defined 
> but not used [-Wunused-const-variable=]
>  static const struct pll_div ppll_init_cfg = PLL_DIVISORS(PPLL_HZ, 2, 2, 
> 1);
>  ^
>
> Signed-off-by: Philipp Tomsich 
> ---
>
>  drivers/clk/rockchip/clk_rk3399.c | 5 +
>  1 file changed, 5 insertions(+)

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

Re: [U-Boot] [PATCH v2 1/7] rockchip: video: Split out HDMI controller code

[Simon Glass]

On 20 March 2017 at 16:01, Jernej Skrabec  wrote:
> Designware HDMI controller and phy are used in other SoCs as well. Split
> out platform independent code.
>
> DW HDMI has 8 bit registers but they can be represented as 32 bit
> registers as well. Add support to select access mode.
>
> EDID reading code use reading by blocks which is not supported by other
> SoCs in general. Make it more general using byte by byte approach, which
> is also used in Linux driver.
>
> Finally, not all DW HDMI controllers are accompanied with DW HDMI phy.
> Support custom phys by making controller code independent from phy code.
>
> Signed-off-by: Jernej Skrabec 
> Tested-by: Nickey Yang 
> Reviewed-by: Simon Glass 
> ---
> Changes in v2:
> - added tested by tag
> - added reviewed by tag
>
>  arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h | 456 --
>  drivers/video/dw_hdmi.c  | 764 
> +++
>  drivers/video/rockchip/Makefile  |   2 +-
>  drivers/video/rockchip/rk_hdmi.c | 757 +-
>  drivers/video/rockchip/rk_vop.c  |   1 -
>  include/dw_hdmi.h| 486 ++
>  6 files changed, 1275 insertions(+), 1191 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-rockchip/hdmi_rk3288.h
>  create mode 100644 drivers/video/dw_hdmi.c
>  create mode 100644 include/dw_hdmi.h

Tested on firefly-rk3288:
Tested-by: Simon Glass 
Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] rockchip: pinctrl: use per-SoC option names for Kconfig

[Simon Glass]

On 22 March 2017 at 07:05, Simon Glass  wrote:
> On 17 March 2017 at 13:41, Philipp Tomsich
>  wrote:
>> The config options for pinctrl on the RK3188, RK3288, RK3328 and
>> RK3399 previously showed up in menuconfig with the generic string
>> descriptor "Rockchip pin control driver" requiring one to look through
>> the help/full description to identify which chip each menu entry was
>> for.
>>
>> This change renames each option with the chip-name in the description
>> string to make it easy to identify the configuration options in
>> menuconfig.
>>
>> Signed-off-by: Philipp Tomsich 
>> ---
>>
>>  drivers/pinctrl/Kconfig | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 7/8] rockchip: i2c: Add compatibles for Rockchip Cortex-A9 socs

[Simon Glass]

On 23 March 2017 at 21:28, Simon Glass  wrote:
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
>> The Cortex-A9 socs rk3066 and rk3188 share the IP but have their own
>> compatible values, so add them to make the i2c on these platforms accessible.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>  drivers/i2c/rk_i2c.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] rockchip: clk: rk3188: Allow configuration of the armclk

[Simon Glass]

On 23 March 2017 at 21:27, Simon Glass  wrote:
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
>> The armclk starts in slow mode (24MHz) on the rk3188, which makes the whole
>> startup take a lot of time. We therefore want to at least move to the safe
>> 600MHz value we can use with default pmic settings.
>> This is also the freqency the proprietary sdram-init leaves the cpu at.
>>
>> For boards that have pmic control later in u-boot, we also add the option
>> to set the maximum frequency of 1.6GHz, if they so desire.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>  arch/arm/include/asm/arch-rockchip/cru_rk3188.h |  1 +
>>  drivers/clk/rockchip/clk_rk3188.c   | 63 
>> +
>>  2 files changed, 64 insertions(+)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] rockchip: rk3188: Cleanup some SPL/TPL rename leftovers

[Simon Glass]

On 23 March 2017 at 21:27, Simon Glass  wrote:
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
>> In the beginning, we did SPL -> TPL -> U-Boot, but after clarification
>> of the real ordering swapped SPL and TPL.
>> It seems some renames were forgotten and may confuse future readers, so
>> also swap these to reflect the actual ordering.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>  arch/arm/mach-rockchip/rk3188-board-tpl.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8] rockchip: rk3188: Decode the actual amount of ram

[Simon Glass]

On 23 March 2017 at 21:27, Simon Glass  wrote:
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
>> There was still a static ram value set in the rk3188-board from the
>> time where we didn't have actual sdram init code.
>> Now the sdram init leaves the ram information in SYS_REG2 and we can
>> decode it similarly to the rk3288.
>>
>> Right now we have two duplicates of that code, which is still ok and
>> doesn't really count as common code yet, but if we get a third copy
>> at some point from a newer soc, we should think about moving that to
>> a more general position.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>  arch/arm/mach-rockchip/rk3188-board.c | 18 --
>>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: spl: use spl_early_init() instead of spl_init()

[Simon Glass]

On 22 March 2017 at 07:06, Simon Glass  wrote:
> On 20 March 2017 at 00:47, Kever Yang  wrote:
>> Rockchip spl driver needs using spl_early_init().
>>
>> Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit)
>> Signed-off-by: Kever Yang 
>> ---
>>
>>  arch/arm/mach-rockchip/rk3188-board-spl.c | 4 ++--
>>  arch/arm/mach-rockchip/rk3399-board-spl.c | 4 ++--
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/8] rockchip: rk3188: sdram: Set correct sdram base

[Simon Glass]

On 23 March 2017 at 21:27, Simon Glass  wrote:
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
>> Right now we're setting the wrong value of 0 as base in the ram_info struct,
>> which is obviously wrong for the rk3188. So instead set the correct value
>> we already have in CONFIG_SYS_SDRAM_BASE.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>  arch/arm/mach-rockchip/rk3188/sdram_rk3188.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/8] rockchip: rk3188: Setup the armclk in spl

[Simon Glass]

On 23 March 2017 at 21:28, Simon Glass  wrote:
> On 20 March 2017 at 05:40, Heiko Stuebner  wrote:
>> The armclk starts in slow mode (24MHz) on the rk3188, which results in U-Boot
>> startup taking a lot of time (U-Boot itself, but also the rc4 decoding done
>> in the bootrom).
>>
>> With default pmic settings we can always reach a safe frequency of 600MHz
>> which is also the frequency the proprietary loader left the armclk at,
>> without needing access to the systems pmic.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>  arch/arm/mach-rockchip/rk3188-board-spl.c | 24 
>>  1 file changed, 24 insertions(+)
>
> Acked-by: Simon Glass 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/4] rockchip: mkimage: pad the header to 8-bytes (using a 'nop') for RK3399

[Simon Glass]

On 15 March 2017 at 05:08, Philipp Tomsich
 wrote:
> The RK3399 boot code (running as AArch64) poses a bit of a challenge
> for SPL image generation:
>  * The BootROM will start execution right after the 4-byte header (at
>the odd instruction word loaded into SRAM at 0xff8c2004, with the
>'RK33' boot magic residing at 0xff8c2000).
>  * The default padding (during ELF generation) for AArch64 is 0x0,
>which is an illegal instruction and the .text section needs to be
>naturally aligned (someone might locate a 64bit constant relative
>to the section start and unaligned loads trigger a fault for all
>privileged modes of an ARMv8)... so we can't simply define the
>CONFIG_SPL_TEXT_BASE option to the odd address (0xff8c2004).
>  * Finally, we don't want to change the values used for padding of
>the SPL .text section for all ARMv8 targets to the instruction
>word encoding 'nop', as this would affect all padding in this
>section and might hide errors that would otherwise quickly trigger
>an illegal insn exception.
>
> To deal with this situation, we modify the rkimage generation to
>  - understand the fact that the RK3399 needs to pad the header to an
>8 byte boundary using an AArch64 'nop'
>  - the necessary logic to adjust the header_size (which controls the
>location where the payload is copied into the image) and to insert
>this padding (AArch64 insn words are always little-endian) into
>the image following the 4-byte header magic.
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
> ---
>
> Changes in v2: None
>
>  tools/rkcommon.c | 97 
> +---
>  tools/rkcommon.h | 23 ++
>  tools/rksd.c | 17 +++---
>  tools/rkspi.c| 17 +++---
>  4 files changed, 118 insertions(+), 36 deletions(-)
>

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] rockchip: rk3188: add README.rockchip paragraph describing sd boot

[Simon Glass]

On 23 March 2017 at 20:40, Kever Yang  wrote:
> Hi Heiko,
>
>
> On 03/24/2017 07:41 AM, Heiko Stuebner wrote:
>>
>> Building sd images for rk3188 requires more steps due to the needed split
>> into TPL and SPL as loaders. Describe how to build an image for it in a
>> separate paragraph in the READER.rockchip file.
>>
>> Signed-off-by: Heiko Stuebner 
>> ---
>>   doc/README.rockchip | 26 ++
>>   1 file changed, 26 insertions(+)
>>
[...]

>
> Reviewed-by: Kever Yang 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] rockchip: rk3188: enable TPL_LIBGENERIC for generic memset

[Simon Glass]

On 23 March 2017 at 17:41, Heiko Stuebner  wrote:
> Commit c67c8c604b6c ("board_init.c: Always use memset()") dropped the naive
> memset alternative from board_init_f_init_reserve.
> So activate CONFIG_TPL_LIBGENERIC for that common memset implementation.
> We cannot use the ARCH-specific memset, as that would incur 200bytes of
> additional TPL size, space we do not have.
>
> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/mach-rockchip/rk3188/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
>

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/4] rockchip: mkimage: simplify start/size calculation for rc4_encode

[Simon Glass]

On 15 March 2017 at 05:08, Philipp Tomsich
 wrote:
> The RC4 encoding works on full blocks, but the calculation of the
> starting offset and size are needlessly complicated by using a
> reference value known to be offset into a block by the size of the
> header and then correcting for the (hard-coded) size of the header
> (i.e. 4 bytes).
>
> We change this over to use the RK_SPL_HDR_START directly (which is
> known to be on a block boundary).
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
> ---
>
> Changes in v2: None
>
>  tools/rksd.c  | 4 ++--
>  tools/rkspi.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] rockchip: spl: RK3399: use boot0 hook to create space for SPL magic

[Simon Glass]

On 15 March 2017 at 05:08, Philipp Tomsich
 wrote:
> The SPL binary needs to be prefixed with the boot magic ('RK33' for
> the RK3399) on the Rockchip platform and starts execution of the
> instruction word following immediately after this boot magic.
>
> This poses a challenge for AArch64 (ARMv8) binaries, as the .text
> section would need to start on the odd address, violating natural
> alignment (and potentially triggering a fault for any code that
> tries to access 64bit values embedded in the .text section).
>
> A quick and easy fix is to have the .text section include the 'RK33'
> magic and pad it with a boot0 hook to insert 4 bytes of padding at the
> start of the section (with the intention of having mkimage overwrite
> this padding with the appropriate boot magic). This avoids having to
> modify the linker scripts or more complex logic in mkimage.
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
>
> ---
>
> Changes in v2:
> - Use BOOT0_HOOK to insert space into the SPL payload that can be
>   overwritten with the boot magic (e.g. 'RK33') by rkimage
>
>  arch/arm/include/asm/arch-rockchip/boot0.h | 18 ++
>  arch/arm/mach-rockchip/Kconfig |  1 +
>  include/configs/rk3399_common.h|  2 +-
>  3 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/boot0.h

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] rockchip: mkimage: update rkimage to support pre-padded payloads

[Simon Glass]

On 15 March 2017 at 05:08, Philipp Tomsich
 wrote:
> To simplify the creation of AArch64 SPL images for the RK3399, we
> use the ENABLE_ARM_SOC_BOOT0_HOOK option and prepend 4 bytes of
> padding at the start of the text section. This makes it easy for
> mkimage to rewrite this word with the 'RK33' boot magic.
>
> This change brings logic to calculate the header size and allocate
> the header back in sync. For the RK3399 we now limit the header to
> before the payload (i.e. the 'header0' and the padding up to the
> actual image) and overwrite the first word (inserted by the
> boot0-hook for this purpose) with the 'RK33' magic in-place.
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
>
> ---
>
> Changes in v2:
> - Change rkimage to overwrite this padding for the RK3399 instead of
>   inserting an artificial 'nop'
>
>  tools/rkcommon.c | 31 +--
>  tools/rkcommon.h | 13 -
>  2 files changed, 13 insertions(+), 31 deletions(-)

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] rockchip: configs: correct mmc env dev for rk3288 based boards

[Simon Glass]

On 15 March 2017 at 03:28, Jacob Chen  wrote:
> we are using mmc alias , so mmc index have been changed.
> now mmc dev 0 is emmc and mmc dev 1 is sdmmc.
>
> Signed-off-by: Jacob Chen 
> ---
>
>  include/configs/evb_rk3288.h  | 2 +-
>  include/configs/fennec_rk3288.h   | 2 +-
>  include/configs/popmetal_rk3288.h | 2 +-
>  include/configs/tinker_rk3288.h   | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] rockchip: rk3188: Add Radxa Rock board

[Simon Glass]

Hi,

On 23 March 2017 at 17:41, Heiko Stuebner  wrote:
> The Rock is a RK3188 based single board computer by Radxa.
> Currently it still relies on the proprietary DDR init and
> cannot use the generic SPL, but at least is able to boot
> a linux kernel and system up to a regular login prompt.
>
> Signed-off-by: Heiko Stuebner 
> Reviewed-by: Simon Glass 
> Tested-by: Kever Yang 
> ---
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3188-radxarock.dts | 382 
> ++
>  arch/arm/mach-rockchip/rk3188/Kconfig |  11 +
>  board/radxa/rock/Kconfig  |  15 ++
>  board/radxa/rock/MAINTAINERS  |   6 +
>  board/radxa/rock/Makefile |   7 +
>  board/radxa/rock/rock.c   |   7 +
>  configs/rock_defconfig|  58 ++
>  include/configs/rock.h|  30 +++
>  9 files changed, 517 insertions(+)
>  create mode 100644 arch/arm/dts/rk3188-radxarock.dts
>  create mode 100644 board/radxa/rock/Kconfig
>  create mode 100644 board/radxa/rock/MAINTAINERS
>  create mode 100644 board/radxa/rock/Makefile
>  create mode 100644 board/radxa/rock/rock.c
>  create mode 100644 configs/rock_defconfig
>  create mode 100644 include/configs/rock.h

I am still having trouble applying this patch. I get build errors:

   arm:  +   rock
+arch/arm/Makefile:22: CONFIG_CPU_V7  -march=armv7-a
+make[2]: *** No rule to make target 'dts/dt.dtb', needed by
'tpl/u-boot-tpl.dtb'.  Stop.
+make[1]: *** [tpl/u-boot-tpl.bin] Error 2
+make: *** [sub-make] Error 2
001 /1  rock

Also there seems to be a duplicate config:

   arm:  +   rock
+In file included from include/configs/rock.h:11:0,
+ from include/config.h:5,
+ from include/common.h:21,
+ from arch/arm/lib/asm-offsets.c:15:
+ #define CONFIG_SYS_THUMB_BUILD
+ ^
+ from lib/asm-offsets.c:15:
+In file included from include/linux/kconfig.h:4:0,
+ from :0:
+include/generated/autoconf.h:10:0: note: this is the location of the
previous definition
+ #define CONFIG_SYS_THUMB_BUILD 1


What toolchain are you using to build this?

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

Re: [U-Boot] [PATCH v2 1/2] rockchip: rk3399: spl: add UART0 support for SPL

[Simon Glass]

Hi,

On 23 March 2017 at 20:12, Kever Yang  wrote:
>
> Hi Philipp,
>
>
> On 03/24/2017 06:24 AM, Philipp Tomsich wrote:
>>
>> The RK3399-Q7 ("Puma") SoM exposes UART0 as the Qseven UART (i.e. the
>> serial line available via standardised pins on the edge connector and
>> available on a RS232 connector).
>>
>> To support boards (such as the RK3399-Q7) that require UART0 as a
>> debug console, we match CONFIG_DEBUG_UART_BASE and add the appropriate
>> iomux setup to the rk3399 SPL code.
>>
>> As we are already touching this code, we also move the board-specific
>> UART setup (i.e. iomux setup) into board_debug_uart_init(). This will
>> be called from the debug UART init when CONFIG_DEBUG_UART_BOARD_INIT
>> is set.
>>
>> Signed-off-by: Philipp Tomsich 
>> ---
>>
>> Changes in v2:
>> - Changed hex constant to lowercase
>>
>>   arch/arm/include/asm/arch-rockchip/grf_rk3399.h |  8 +++
>>   arch/arm/mach-rockchip/rk3399-board-spl.c   | 29 
>> ++---
>>   2 files changed, 29 insertions(+), 8 deletions(-)

This patch causes a build error for me:

   aarch64:  +   evb-rk3399
+arch/arm/mach-rockchip/rk3399-board-spl.c:60:6: error: redefinition
of 'board_debug_uart_init'
+ void board_debug_uart_init(void)
+  ^
+In file included from arch/arm/mach-rockchip/rk3399-board-spl.c:8:0:
+include/debug_uart.h:68:20: note: previous definition of
'board_debug_uart_init' was here
+ static inline void board_debug_uart_init(void)
+^
+make[3]: *** [spl/arch/arm/mach-rockchip/rk3399-board-spl.o] Error 1
+make[2]: *** [spl/arch/arm/mach-rockchip] Error 2
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2


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

Re: [U-Boot] [PATCH v2 2/2] rockchip: config: rk3399: update defconfigs and rk3399_common

[Simon Glass]

Hi,

On 23 March 2017 at 16:24, Philipp Tomsich
 wrote:
> With everything set up to define CONFIG_BAUDRATE via defconfig and
> with to have the SPL debug UART either on UART0 or UART2, the configs
> for the RK3399 EVB and for the RK3399-Q7 can be updated.
>
> Signed-off-by: Philipp Tomsich 
>
> ---
>
> Changes in v2: None
>
>  configs/evb-rk3399_defconfig| 2 ++
>  configs/puma_defconfig  | 4 +++-
>  include/configs/rk3399_common.h | 1 -
>  3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
> index 22405ce..7a82869 100644
> --- a/configs/evb-rk3399_defconfig
> +++ b/configs/evb-rk3399_defconfig
> @@ -43,7 +43,9 @@ CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_PWM_ROCKCHIP=y
>  CONFIG_RAM=y
>  CONFIG_SPL_RAM=y
> +CONFIG_BAUDRATE=150
>  CONFIG_DEBUG_UART=y
> +CONFIG_DEBUG_UART_BOARD_INIT=y
>  CONFIG_DEBUG_UART_BASE=0xFF1A
>  CONFIG_DEBUG_UART_CLOCK=2400
>  CONFIG_DEBUG_UART_SHIFT=2
> diff --git a/configs/puma_defconfig b/configs/puma_defconfig
> index 515185e..8e29d96 100644
> --- a/configs/puma_defconfig
> +++ b/configs/puma_defconfig

I don't have this file in my tree. Is this based on mainline?

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

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

[Simon Glass]

Hi Heiko,

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

It still seems like pinctrl to me, in that you are selecting which IP
block uses those pins. If you don't want it in pinctrl, perhaps this
whole thing should go in the I2C driver?

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

Re: [U-Boot] [PATCH 1/4 v2] dm: core: Add flags parameter to device_remove()

[Simon Glass]

On 20 March 2017 at 05:51, Stefan Roese  wrote:
> This patch adds the flags parameter to device_remove() and changes all
> calls to this function to provide the default value of DM_REMOVE_NORMAL
> for "normal" device removal.
>
> This is in preparation for the driver specific pre-OS (e.g. DMA
> cancelling) remove support.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
> v2:
> - Changes DM_FLAG macro as suggested by Simon
> - Minor comment change as suggested by Simon
>
>  arch/x86/cpu/queensbay/tnc.c   |  4 ++--
>  cmd/cros_ec.c  |  2 +-
>  cmd/sf.c   |  2 +-
>  drivers/block/blk-uclass.c |  2 +-
>  drivers/block/sandbox.c|  2 +-
>  drivers/core/device-remove.c   |  9 +
>  drivers/core/device.c  |  2 +-
>  drivers/core/root.c|  2 +-
>  drivers/core/uclass.c  |  2 +-
>  drivers/mmc/mmc-uclass.c   |  2 +-
>  drivers/mtd/spi/sandbox.c  |  2 +-
>  drivers/mtd/spi/sf-uclass.c|  2 +-
>  drivers/spi/spi-uclass.c   |  4 ++--
>  drivers/usb/emul/sandbox_hub.c |  2 +-
>  drivers/usb/host/usb-uclass.c  |  4 ++--
>  include/dm/device-internal.h   |  5 +++--
>  include/dm/device.h| 26 ++
>  test/dm/bus.c  |  8 
>  test/dm/core.c | 16 
>  test/dm/eth.c  |  2 +-
>  test/dm/spi.c  |  2 +-
>  21 files changed, 65 insertions(+), 37 deletions(-)
>

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

Re: [U-Boot] [PATCH 2/4 v3] dm: core: Add dm_remove_devices_flags() and hook it into device_remove()

[Simon Glass]

Hi Stefan,

On 22 March 2017 at 00:28, Stefan Roese  wrote:
> The new function dm_remove_devices_flags() is intented for driver specific
> last-stage cleanup operations before the OS is started. This patch adds
> this functionality and hooks it into the common device_remove()
> function.
>
> Drivers wanting to use this feature for some last-stage removal calls,
> need to add one of the DM_REMOVE_xx flags to their driver .flags.
>
> Signed-off-by: Stefan Roese 
> Reviewed-by: Simon Glass 
> ---
> v3:
> - Add conditional compilation to fix compilation breakage on platforms
>   without DM and DM_DEVICE_REMOVE support. With this change, Travis
>   compiles all targets without any error
>
> v2:
> - Added Simons Reviewed-by
>
>  drivers/core/device-remove.c | 15 +++
>  drivers/core/root.c  |  9 +
>  include/dm/root.h| 16 
>  3 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index b80bf52320..ca4680f7c2 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -174,7 +174,12 @@ int device_remove(struct udevice *dev, uint flags)
> if (ret)
> goto err;
>
> -   if (drv->remove) {
> +   /*
> +* Remove the device if called with the "normal" remove flag set,
> +* or if the remove flag matches the driver flags
> +*/
> +   if (drv->remove &&
> +   ((flags & DM_REMOVE_NORMAL) || (flags & drv->flags))) {

You are changing the condition here but still call the post_remove()
method immediately below. If you decide note to remove the device then
I think you should not call that function.

> ret = drv->remove(dev);
> if (ret)
> goto err_remove;
> @@ -188,10 +193,12 @@ int device_remove(struct udevice *dev, uint flags)
> }
> }
>
> -   device_free(dev);
> +   if ((flags & DM_REMOVE_NORMAL) || (flags & drv->flags)) {
> +   device_free(dev);
>
> -   dev->seq = -1;
> -   dev->flags &= ~DM_FLAG_ACTIVATED;
> +   dev->seq = -1;
> +   dev->flags &= ~DM_FLAG_ACTIVATED;
> +   }
>
> return ret;
>

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

Re: [U-Boot] [PATCH v2 00/45] Add PPv2.2 support to the mvpp2 ethernet driver and enable it for A7k/8k

[Joe Hershberger]

Hi Stefan,

On Thu, Mar 23, 2017 at 12:01 PM, Stefan Roese  wrote:
>
> This patchset does the following things:
>
> - It brings the latest Linux changes from the mvpp2 ethernet driver done
>   by Thomas Petazzoni to the U-Boot version of this driver. This enables
>   the usage of this driver on the new Marvell Armada 7k / 8k ARMv8 SoCs.
>
> - This driver is enabled for the currently available Armada 7k / 8k
>   boards and the necessary configuration is done to the config header.
>
> v2 status:
> The GoP / NetC patch has been split into multiple smaller patches for
> easier review. The code for untested / unsupported interfaces (like
> QSGMII, XAUI and RXAUI) has been removed for now.
>
> Thanks,
> Stefan

I think you should be good to go to pull this into your board tree.

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

Re: [U-Boot] [PATCH v2 40/45] net: mvpp2: Add missing PHY_INTERFACE_MODE_RGMII_ID

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:02 PM, Stefan Roese  wrote:
> Add a missing occurrance of PHY_INTERFACE_MODE_RGMII_ID, which should
> be handled identical to PHY_INTERFACE_MODE_RGMII.
>
> Signed-off-by: Stefan Roese 
> Cc: Stefan Chulski 
> Cc: Kostya Porotchkin 
> Cc: Nadav Haklai 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 37/45] net: mvpp2: Read phy-speed from DT to select between 1GB and 2.5GB SGMII

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:02 PM, Stefan Roese  wrote:
> Read the "phy-speed" DT property to differentiate between 1 and 2.5GB
> SGMII operations. Please note that its unclear right now, if this
> DT property will be accepted in mainline Linux. If not, we need to
> revisit this code and change it to use the accepted property.
>
> Signed-off-by: Stefan Roese 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 36/45] net: mvpp2: Restructure probe / init functions

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:02 PM, Stefan Roese  wrote:
> This patch does a bit of restructuring of the probe / init functions,
> mainly to allow earlier register access as it is needed for the upcoming
> GoP (Group of Ports) and NetC (Net Complex) code.
>
> Signed-off-by: Stefan Roese 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 24/45] net: mvpp2: adapt rxq distribution to PPv2.2

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:01 PM, Stefan Roese  wrote:
> From: Thomas Petazzoni 
>
> In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4
> RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7
> to the second port, 8->11 to the third port, etc.
>
> In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate
> RXQs from the range of 32 RXQs available for each port. So port 0 must
> use RXQs in the range 0->31, port 1 in the range 32->63, etc.
>
> This commit adapts the mvpp2 to this difference between PPv2.1 and
> PPv2.2:
>
> - The constant definition MVPP2_MAX_RXQ is replaced by a new field
>   'max_port_rxqs' in 'struct mvpp2', which stores the maximum number of
>   RXQs per port. This field is initialized during ->probe() depending
>   on the IP version.
>
> - MVPP2_RXQ_TOTAL_NUM is removed, and instead we calculate the total
>   number of RXQs by multiplying the number of ports by the maximum of
>   RXQs per port. This was anyway used in only one place.
>
> - In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted
>   to cope with the different allocation strategy between PPv2.1 and
>   PPv2.2. Due to this change, the 'next_first_rxq' argument of this
>   function is no longer needed and is removed.
>
> Signed-off-by: Thomas Petazzoni 
> Signed-off-by: Stefan Roese 
> ---

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

Re: [U-Boot] [PATCH v2 34/45] net: mvpp2: Add RX and TX FIFO configuration for PPv2.2

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:02 PM, Stefan Roese  wrote:
> This patch adds the PPv2.2 specific FIFO configuration to the mvpp2
> driver. The RX FIFO packet data size is changed to the recommended
> FIFO sizes. The TX FIFO configuration is newly added.
>
> Signed-off-by: Stefan Roese 
> Cc: Stefan Chulski 
> Cc: Kostya Porotchkin 
> Cc: Nadav Haklai 

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

Re: [U-Boot] [PATCH v2 39/45] net: mvpp2: Add GoP and NetC support for port 0 (SFI)

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:02 PM, Stefan Roese  wrote:
> This patch adds the GoP (Group of Ports) and NetC (Net Complex) setup to
> the Marvell mvpp2 ethernet driver for the missing port 0. This code is
> mostly copied from the Marvell U-Boot version and was written by Stefan
> Chulski. Please note that only SFI support have been added, as this
> is the only interface that this code has been tested with. XAUI and
> RXAUI support might follow at a later stage.
>
> Signed-off-by: Stefan Roese 
> Cc: Stefan Chulski 
> Cc: Kostya Porotchkin 
> Cc: Nadav Haklai 
> Cc: Joe Hershberger 
>
> ---
>
> Changes in v2:
> - New patch
>
>  drivers/net/mvpp2.c | 161 
> 
>  1 file changed, 161 insertions(+)
>
> diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
> index 76370faff0..7b4f7a22bd 100644
> --- a/drivers/net/mvpp2.c
> +++ b/drivers/net/mvpp2.c
> @@ -3234,6 +3234,130 @@ static int gop_gpcs_reset(struct mvpp2_port *port, 
> enum mv_reset act)
> return 0;
>  }
>
> +/* Set the internal mux's to the required PCS in the PI */
> +static int gop_xpcs_mode(struct mvpp2_port *port, int num_of_lanes)
> +{
> +   u32 val;
> +   int lane;
> +
> +   switch (num_of_lanes) {
> +   case 1:
> +   lane = 0;
> +   break;
> +   case 2:
> +   lane = 1;
> +   break;
> +   case 4:
> +   lane = 2;
> +   break;
> +   default:
> +   return -1;
> +   }
> +
> +   /* configure XG MAC mode */
> +   val = readl(port->priv->xpcs_base + MVPP22_XPCS_GLOBAL_CFG_0_REG);
> +   val &= ~MVPP22_XPCS_PCSMODE_OFFS;
> +   val &= ~MVPP22_XPCS_LANEACTIVE_MASK;
> +   val |= (2 * lane) << MVPP22_XPCS_LANEACTIVE_OFFS;
> +   writel(val, port->priv->xpcs_base + MVPP22_XPCS_GLOBAL_CFG_0_REG);
> +
> +   return 0;
> +}
> +
> +static int gop_mpcs_mode(struct mvpp2_port *port)
> +{
> +   u32 val;
> +
> +   /* configure PCS40G COMMON CONTROL */
> +   val = readl(port->priv->mpcs_base + PCS40G_COMMON_CONTROL);
> +   val &= ~FORWARD_ERROR_CORRECTION_MASK;
> +   writel(val, port->priv->mpcs_base + PCS40G_COMMON_CONTROL);
> +
> +   /* configure PCS CLOCK RESET */
> +   val = readl(port->priv->mpcs_base + PCS_CLOCK_RESET);
> +   val &= ~CLK_DIVISION_RATIO_MASK;
> +   val |= 1 << CLK_DIVISION_RATIO_OFFS;
> +   writel(val, port->priv->mpcs_base + PCS_CLOCK_RESET);
> +
> +   val &= ~CLK_DIV_PHASE_SET_MASK;
> +   val |= MAC_CLK_RESET_MASK;
> +   val |= RX_SD_CLK_RESET_MASK;
> +   val |= TX_SD_CLK_RESET_MASK;
> +   writel(val, port->priv->mpcs_base + PCS_CLOCK_RESET);
> +
> +   return 0;
> +}
> +
> +/* Set the internal mux's to the required MAC in the GOP */
> +static int gop_xlg_mac_mode_cfg(struct mvpp2_port *port, int 
> num_of_act_lanes)
> +{
> +   u32 val;
> +
> +   /* configure 10G MAC mode */
> +   val = readl(port->base + MVPP22_XLG_CTRL0_REG);
> +   val |= MVPP22_XLG_RX_FC_EN;
> +   writel(val, port->base + MVPP22_XLG_CTRL0_REG);
> +
> +   val = readl(port->base + MVPP22_XLG_CTRL3_REG);
> +   val &= ~MVPP22_XLG_CTRL3_MACMODESELECT_MASK;
> +   val |= MVPP22_XLG_CTRL3_MACMODESELECT_10GMAC;
> +   writel(val, port->base + MVPP22_XLG_CTRL3_REG);
> +
> +   /* read - modify - write */
> +   val = readl(port->base + MVPP22_XLG_CTRL4_REG);
> +   val &= ~MVPP22_XLG_MODE_DMA_1G;
> +   val |= MVPP22_XLG_FORWARD_PFC_EN;
> +   val |= MVPP22_XLG_FORWARD_802_3X_FC_EN;
> +   val &= ~MVPP22_XLG_EN_IDLE_CHECK_FOR_LINK;
> +   writel(val, port->base + MVPP22_XLG_CTRL4_REG);
> +
> +   /* Jumbo frame support: 0x1400 * 2 = 0x2800 bytes */
> +   val = readl(port->base + MVPP22_XLG_CTRL1_REG);
> +   val &= ~MVPP22_XLG_MAX_RX_SIZE_MASK;
> +   val |= 0x1400 << MVPP22_XLG_MAX_RX_SIZE_OFFS;
> +   writel(val, port->base + MVPP22_XLG_CTRL1_REG);
> +
> +   /* unmask link change interrupt */
> +   val = readl(port->base + MVPP22_XLG_INTERRUPT_MASK_REG);
> +   val |= MVPP22_XLG_INTERRUPT_LINK_CHANGE;
> +   val |= 1; /* unmask summary bit */
> +   writel(val, port->base + MVPP22_XLG_INTERRUPT_MASK_REG);
> +
> +   return 0;
> +}
> +
> +/* Set PCS to reset or exit from reset */
> +static int gop_xpcs_reset(struct mvpp2_port *port, enum mv_reset reset)

Same comment here on the enum for the reset command.

> +{
> +   u32 val;
> +
> +   /* read - modify - write */
> +   val = readl(port->priv->xpcs_base + MVPP22_XPCS_GLOBAL_CFG_0_REG);
> +   if (reset == RESET)
> +   val &= ~MVPP22_XPCS_PCSRESET;
> +   else
> +   val |= MVPP22_XPCS_PCSRESET;
> +   writel(val, port->priv->xpcs_base + MVPP22_XPCS_GLOBAL_CFG_0_REG);
> +
> +   return 0;
> +}
> +
> +/* Set the MAC to reset or 

Re: [U-Boot] [PATCH v2 38/45] net: mvpp2: Add GoP and NetC support for ports 2 & 3 (RGMII & SGMII)

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:02 PM, Stefan Roese  wrote:
> This patch adds the GoP (Group of Ports) and NetC (Net Complex) setup to
> the Marvell mvpp2 ethernet driver. This code is mostly copied from the
> Marvell U-Boot version and was written by Stefan Chulski. Please
> note that only RGMII and SGMII support have been added, as these are
> the only interfaces that this code has been tested with.
>
> Signed-off-by: Stefan Roese 
> Cc: Stefan Chulski 
> Cc: Kostya Porotchkin 
> Cc: Nadav Haklai 
> Cc: Joe Hershberger 
>
> ---
>
> Changes in v2:
> - New patch
>
>  drivers/net/mvpp2.c | 766 
> +++-
>  1 file changed, 758 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
> index 6f9a4137f8..76370faff0 100644
> --- a/drivers/net/mvpp2.c
> +++ b/drivers/net/mvpp2.c



> @@ -2833,6 +2986,570 @@ static inline void mvpp2_gmac_max_rx_size_set(struct 
> mvpp2_port *port)
> writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
>  }
>
> +/* PPv2.2 GoP/GMAC config */
> +
> +/* Set the MAC to reset or exit from reset */
> +static int gop_gmac_reset(struct mvpp2_port *port, enum mv_reset reset)

Is this copied from somewhere? The enum parameter seems unnecessary.
Why not just int for type?

> +{
> +   u32 val;
> +
> +   /* read - modify - write */
> +   val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
> +   if (reset == RESET)
> +   val |= MVPP2_GMAC_PORT_RESET_MASK;
> +   else
> +   val &= ~MVPP2_GMAC_PORT_RESET_MASK;
> +   writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
> +
> +   return 0;
> +}
> +
> +/*
> + * gop_gpcs_mode_cfg
> + *
> + * Configure port to working with Gig PCS or don't.
> + */
> +static int gop_gpcs_mode_cfg(struct mvpp2_port *port, bool en)

Similar here. Copied? Do we really use "bool" in U-Boot much? I care
less about this one that the enum above, though.

> +{
> +   u32 val;
> +
> +   val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
> +   if (en)
> +   val |= MVPP2_GMAC_PCS_ENABLE_MASK;
> +   else
> +   val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
> +   /* enable / disable PCS on this port */
> +   writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
> +
> +   return 0;
> +}


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

Re: [U-Boot] [PATCH 4/6] net: gmac_rockchip: Add support for the RK3399 GMAC

[Joe Hershberger]

On Fri, Mar 24, 2017 at 2:24 PM, Philipp Tomsich
 wrote:
> The GMAC in the RK3399 is very similar to the RK3288 variant (i.e. it
> is a Designware GMAC core and requires similar configuration as the
> RK3288 to switch it to RGMII and set up the TX/RX delays for Gigabit).
> The key difference is that the register offsets (within the GRF block)
> and bit-offsets (within those registers) used to hold the configuration
> differ between the various RK32/33 CPUs.
>
> This change refactors the gmac_rockchip.c driver to use a function
> table (selected via driver_data) to factor our these differences. Each

Typo: "factor out".

> function's implementation then matches the underlying processor.
>
> Some collateral changes are needed in the definitions describing the
> bits and offsets in the GRF are needed to prefix each set of symbolic
> constants with the SoC name to avoid name clashes... and in doing so,
> the shifts for masks and constants have been moved into the header
> files for readability (and to make it easier to stay below 80 chars).
>
> X-AffectedPlatforms: RK3399-Q7
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 

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

Re: [U-Boot] [PATCH v2] net: macb: add remove callback

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:53 AM, Wenyou Yang  wrote:
> To avoid the failure of mdio_register(), add the remove callback
> to unregister the mii_dev when removing the ethernet device.
>
> Signed-off-by: Wenyou Yang 

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

Re: [U-Boot] [PATCH] net: macb: align the compatibles with kernel

[Joe Hershberger]

On Thu, Mar 23, 2017 at 12:54 AM, Wenyou Yang  wrote:
> Add the compatibles to align with the kernel.
>
> Signed-off-by: Wenyou Yang 

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

Re: [U-Boot] [PATCH v5] drivers/net/phy: add fixed-phy / fixed-link support

[Joe Hershberger]

On Thu, Mar 23, 2017 at 10:11 AM, Hannes Schmelzer  wrote:
>
> From: Hannes Schmelzer 
>
> This patch adds support for having a "fixed-link" to some other MAC
> (like some embedded switch-device).
>
> For this purpose we introduce a new phy-driver, called "Fixed PHY".
>
> Fixed PHY works only with CONFIG_DM_ETH enabled, since the fixed-link is
> described with a subnode below ethernet interface.
>
> Most ethernet drivers (unfortunately not all are following same scheme
> for searching/attaching phys) are calling "phy_connect(...)" for getting
> a phy-device.
> At this point we link in, we search here for a subnode called "fixed-
> link", once found we start phy_device_create(...) with the special phy-
> id PHY_FIXED_ID (0xa5a55a5a).
>
> During init the "Fixed PHY" driver has registered with this id and now
> gets probed, during probe we get all the details about fixed-link out of
> dts, later on the phy reports this values.
>
> Signed-off-by: Hannes Schmelzer 
>
> Signed-off-by: Hannes Schmelzer 

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

Re: [U-Boot] [PATCH][v2]board: freescale: ls2080a/ls2088a: Enable PPA

[york sun]

On 03/06/2017 09:48 PM, Santan Kumar wrote:
> Enable PPA on LS2080A, LS2088A boards:
> -LS2080ARDB, LS2080AQDS
> -LS2088ARDB, LS2088AQDS
>
> Signed-off-by: Santan Kumar 
> Signed-off-by: Abhimanyu Saini 
> Signed-off-by: Priyanka Jain 
> ---
> Changes for v2:
>  Changed the subject
>  Made changes based on latest ppa config
>
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 1 +
>  board/freescale/ls2080aqds/ls2080aqds.c   | 8 
>  board/freescale/ls2080ardb/ls2080ardb.c   | 7 +++
>  configs/ls2080aqds_defconfig  | 1 +
>  configs/ls2080ardb_defconfig  | 1 +
>  5 files changed, 18 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index adccdf1..bbbe2de 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -136,6 +136,7 @@ config SYS_LS_PPA_FW_ADDR
>   hex "Address of PPA firmware loading from"
>   depends on FSL_LS_PPA
>   default 0x4050 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT
> + default 0x580a0 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
>   default 0x6050 if SYS_LS_PPA_FW_IN_XIP
>   help
> If the PPA firmware locate at XIP flash, such as NOR or
> diff --git a/board/freescale/ls2080aqds/ls2080aqds.c 
> b/board/freescale/ls2080aqds/ls2080aqds.c
> index 73a61fd..894dc74 100644
> --- a/board/freescale/ls2080aqds/ls2080aqds.c
> +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> @@ -19,6 +19,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_FSL_LS_PPA
> +#include 
> +#endif
> +
>
>  #include "../common/qixis.h"
>  #include "ls2080aqds_qixis.h"
> @@ -224,6 +228,10 @@ int board_init(void)
>   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
>   rtc_enable_32khz_output();
>
> +#ifdef CONFIG_FSL_LS_PPA
> + ppa_init();
> +#endif
> +

Does it matter if ppa_init() runs first, or sec_init() runs first? I am 
trying to resolve a conflict.

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

Re: [U-Boot] [PATCH] T1042RDB: Remove nand secure boot compilation error

[york sun]

On 03/14/2017 02:25 AM, Vinitha Pillai-B57223 wrote:
> After application of SPL size reduction patch, powerPC

Please be specific. Which patch/commit broke it?

York

> compilation breaks, as a macro CONFIG_CMD_BLOB is being
> defined for powerpc, but for SPL size reducion blobbing
> has been removed for SPL compilation. So that had to be removed
> from SPL compilation for powerPC platform as well.
>
> Signed-off-by: Vinitha Pillai 
> Signed-off-by: Sumit Garg 
> ---
>  arch/powerpc/include/asm/fsl_secure_boot.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h 
> b/arch/powerpc/include/asm/fsl_secure_boot.h
> index 2e937f0..1f22b77 100644
> --- a/arch/powerpc/include/asm/fsl_secure_boot.h
> +++ b/arch/powerpc/include/asm/fsl_secure_boot.h
> @@ -107,7 +107,6 @@
>  #endif /* ifdef CONFIG_SPL_BUILD */
>
>  #define CONFIG_CMD_ESBC_VALIDATE
> -#define CONFIG_CMD_BLOB
>  #define CONFIG_FSL_SEC_MON
>  #define CONFIG_SHA_PROG_HW_ACCEL
>  #define CONFIG_RSA_FREESCALE_EXP
> @@ -117,6 +116,7 @@
>  #endif
>
>  #ifndef CONFIG_SPL_BUILD
> +#define CONFIG_CMD_BLOB
>  /*
>   * fsl_setenv_chain_of_trust() must be called from
>   * board_late_init()
>

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

Re: [U-Boot] [PATCH] armv8: ls1046aqds: added ppa support

[york sun]

On 03/09/2017 11:03 PM, Yuantian Tang wrote:
> PPA is used on ls1046aqds to support sleep, hotplug feature.
> Add PPA support to enable them.
>
> Signed-off-by: Tang Yuantian 
> ---
>  board/freescale/ls1046aqds/ls1046aqds.c |  5 +
>  include/configs/ls1046aqds.h| 11 +++
>  2 files changed, 16 insertions(+)



> diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h
> index 4b3b21e..f8f74aa 100644
> --- a/include/configs/ls1046aqds.h
> +++ b/include/configs/ls1046aqds.h
> @@ -9,6 +9,17 @@
>
>  #include "ls1046a_common.h"
>
> +#if defined(CONFIG_FSL_LS_PPA)
> +#define CONFIG_ARMV8_PSCI
> +#define CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
> +#define SEC_FIRMWARE_ERET_ADDR_REVERT
> +
> +#define CONFIG_SYS_LS_PPA_FW_IN_XIP
> +#ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP
> +#define  CONFIG_SYS_LS_PPA_FW_ADDR   0x6050
> +#endif
> +#endif
> +
>  #if defined(CONFIG_NAND_BOOT) || defined(CONFIG_SD_BOOT)
>  #define CONFIG_SYS_TEXT_BASE 0x8200
>  #elif defined(CONFIG_QSPI_BOOT)
>

This is wrong! Please use Kconfig. The options are already there. You 
cannot select CONFIG_ARMV8_PSCI with PPA. Please consult Zhiqiang Hou if 
you have questions.

York


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

Re: [U-Boot] [PATCH 1/2][v3] armv8: ls2080a: Reorganise NAND_BOOT code in config flag

[york sun]

On 03/02/2017 03:41 AM, Santan Kumar wrote:
> Add CONFIG_NAND_BOOT config flag to organise
> NAND_BOOT specific code in config flag like
> -nand-boot specfic errata errata_rcw_src()
> -CONFIG_SYS_NAND_U_BOOT_DST,etc
>
> Signed-off-by: Santan Kumar 
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Abhimanyu Saini 
> ---
> Changes for v3:
>  Rebased to latest codebase
>  Incorporated York's comments to defined CONFIG_NAND_BOOT
>  in new line
>
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +-
>  configs/ls2080aqds_nand_defconfig   | 1 +
>  configs/ls2080ardb_nand_defconfig   | 1 +
>  include/configs/ls2080a_common.h| 5 +
>  include/configs/ls2080aqds.h| 4 +++-
>  5 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 9489f85..fa68baf 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -134,7 +134,7 @@ void erratum_a009635(void)
>
>  static void erratum_rcw_src(void)
>  {
> -#if defined(CONFIG_SPL)
> +#if defined(CONFIG_SPL) && defined(CONFIG_NAND_BOOT)
>   u32 __iomem *dcfg_ccsr = (u32 __iomem *)DCFG_BASE;
>   u32 __iomem *dcfg_dcsr = (u32 __iomem *)DCFG_DCSR_BASE;
>   u32 val;
> diff --git a/configs/ls2080aqds_nand_defconfig 
> b/configs/ls2080aqds_nand_defconfig
> index 8910938..bc0b9b1 100644
> --- a/configs/ls2080aqds_nand_defconfig
> +++ b/configs/ls2080aqds_nand_defconfig
> @@ -12,6 +12,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> +CONFIG_NAND_BOOT=y
>  CONFIG_SYS_EXTRA_OPTIONS="NAND, LS2080A"
>  CONFIG_BOOTDELAY=10
>  CONFIG_SPL=y
> diff --git a/configs/ls2080ardb_nand_defconfig 
> b/configs/ls2080ardb_nand_defconfig
> index 8223111..d449190 100644
> --- a/configs/ls2080ardb_nand_defconfig
> +++ b/configs/ls2080ardb_nand_defconfig
> @@ -12,6 +12,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_OF_STDOUT_VIA_ALIAS=y
> +CONFIG_NAND_BOOT=y
>  CONFIG_SYS_EXTRA_OPTIONS="NAND, LS2080A"
>  CONFIG_BOOTDELAY=10
>  CONFIG_SPL=y
> diff --git a/include/configs/ls2080a_common.h 
> b/include/configs/ls2080a_common.h
> index 4173d9a..ae72939 100644
> --- a/include/configs/ls2080a_common.h
> +++ b/include/configs/ls2080a_common.h
> @@ -216,6 +216,7 @@ unsigned long long get_qixis_addr(void);
>
>  #define CONFIG_PANIC_HANG/* do not reset board on panic */
>
> +#ifdef CONFIG_SPL

Why this?

>  #define CONFIG_SPL_BSS_START_ADDR0x8010
>  #define CONFIG_SPL_BSS_MAX_SIZE  0x0010
>  #define CONFIG_SPL_FRAMEWORK
> @@ -225,11 +226,15 @@ unsigned long long get_qixis_addr(void);
>  #define CONFIG_SPL_TARGET"u-boot-with-spl.bin"
>  #define CONFIG_SPL_TEXT_BASE 0x1800a000
>
> +#ifdef CONFIG_NAND_BOOT
> +#define CONFIG_SPL_NAND_SUPPORT

This is a Kconfig option. Please select it properly.

>  #define CONFIG_SYS_NAND_U_BOOT_DST   0x8040
>  #define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST
> +#endif
>  #define CONFIG_SYS_SPL_MALLOC_SIZE   0x0010
>  #define CONFIG_SYS_SPL_MALLOC_START  0x8020
>  #define CONFIG_SYS_MONITOR_LEN   (640 * 1024)
> +#endif
>
>  #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
>
> diff --git a/include/configs/ls2080aqds.h b/include/configs/ls2080aqds.h
> index 08d1586..93f6b51 100644
> --- a/include/configs/ls2080aqds.h
> +++ b/include/configs/ls2080aqds.h
> @@ -197,7 +197,8 @@ unsigned long get_board_ddr_clk(void);
>   FTIM2_GPCM_TWP(0x3E))
>  #define CONFIG_SYS_CS3_FTIM3 0x0
>
> -#if defined(CONFIG_SPL) && defined(CONFIG_NAND)
> +#if defined(CONFIG_SPL)
> +#if defined(CONFIG_NAND_BOOT)
>  #define CONFIG_SYS_CSPR1_EXT CONFIG_SYS_NOR0_CSPR_EXT
>  #define CONFIG_SYS_CSPR1 CONFIG_SYS_NOR0_CSPR_EARLY
>  #define CONFIG_SYS_CSPR1_FINAL   CONFIG_SYS_NOR0_CSPR
> @@ -233,6 +234,7 @@ unsigned long get_board_ddr_clk(void);
>  #define CONFIG_SPL_PAD_TO0x2
>  #define CONFIG_SYS_NAND_U_BOOT_OFFS  (256 * 1024)
>  #define CONFIG_SYS_NAND_U_BOOT_SIZE  (640 * 1024)
> +#endif
>  #else
>  #define CONFIG_SYS_CSPR0_EXT CONFIG_SYS_NOR0_CSPR_EXT
>  #define CONFIG_SYS_CSPR0 CONFIG_SYS_NOR0_CSPR_EARLY
>

Since you are reorganizing NAND boot, can you comb through all 
Layerscape NAND boot and make them consistent in the sense of location 
in RAM, malloc space, etc.? Or even better, can you also take SD boot 
and make them consistent? I would like to see the RAM version at the 
same location, with plenty of space ahead of it (may be used for falcon 
boot).

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

Re: [U-Boot] [PATCH] powerpc: e6500: Lock/unlock 1 cache instead of L1 as init_ram

[york sun]

On 03/01/2017 07:37 PM, Ruchika Gupta wrote:
> Fir E6500 cores, L2 cache has been used as init_ram. L1 cache is a write
> through cache on E6500.If lines are not locked in both L1 and L2 caches,
> crashes are observed during secure boot. This patch locks/unlocks both L1
> as well as L2 cache to prevent the crash.

I didn't even know you could/should lock L1. Any reason why it would crash?

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

Re: [U-Boot] [PATCHV2] tools: plbimage support generate rcw file

[york sun]

On 02/25/2017 04:38 PM, yuan linyu wrote:
> From: yuan linyu 
>
> some system will not generate pbl format u-boot, but require rcw.
>
> Signed-off-by: yuan linyu 
> ---
>  tools/pblimage.c | 48 +++-
>  1 file changed, 27 insertions(+), 21 deletions(-)
>

Alison,

This patch looks OK to me. Would you confirm?

York


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

Re: [U-Boot] [PATCH v2] armv8: fsl-lsch3: Instantiate TZASC configuration in 2 groups

[york sun]

On 02/23/2017 02:27 AM, Ashish Kumar wrote:
>  Number of TZASC instances may vary across NXP SoCs.
>  So put TZASC configuration under instance specific defines.
>

Please fix the indentation. Otherwise this patch looks OK.

York

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

Re: [U-Boot] [PATCH v2] armv8:fsl-layerscape: Add registers space defination for CCI-400 bus

[york sun]

On 02/23/2017 02:27 AM, Ashish Kumar wrote:
>  CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which
>  provides full cache coherency between two clusters of multi-core
>  CPUs and I/O coherency for devices and I/O masters.
>
>  This patch add new CONFIG defination and move existing register
>  space definaton of CCI-400 bus from from immap_lsch2 to fsl_immap,
>  so that it can be used for both chasis 2 and chasis 3.
>

All of your patches have the (sometime inconsistent) indentation in 
commit message. Please fix.

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

Re: [U-Boot] [PATCH v2] armv8:fsl-layerscape: Add registers space defination for CCI-400 bus

[york sun]

On 02/23/2017 02:27 AM, Ashish Kumar wrote:
>  CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which
>  provides full cache coherency between two clusters of multi-core
>  CPUs and I/O coherency for devices and I/O masters.
>
>  This patch add new CONFIG defination and move existing register
>  space definaton of CCI-400 bus from from immap_lsch2 to fsl_immap,
>  so that it can be used for both chasis 2 and chasis 3.
>
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> ---
> v2:
>  Add new Kconfig in alphabetic order
>
>  README |  9 
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  6 +++
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  1 +
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  1 +
>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  | 48 
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
>  include/fsl_immap.h| 51 
> ++
>  7 files changed, 69 insertions(+), 48 deletions(-)
>



>  #define SMMU_SCR1(SMMU_BASE + 0x4)
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> index 0678fba..04add3b 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> @@ -10,6 +10,7 @@
>  #define __ARCH_FSL_LSCH3_IMMAP_H_
>
>  #define CONFIG_SYS_IMMR  0x0100
> +#define CONFIG_SYS_CCI400_ADDR   (CONFIG_SYS_IMMR + 
> 0x309)

Can you move this macro to Kconfig and clean up existing use?

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

Re: [U-Boot] [PATCH v2 1/2] spi: fsl_qspi: Add support for one chip select

[york sun]

On 02/21/2017 12:55 AM, Suresh Gupta wrote:
> SOC’s like LS1012A has only one chip select signal
> out to connect with flash. So at one time only one
> flash is active and it is not possible to scan other
> flash at run time.
>
> Signed-off-by: Suresh Gupta 
> ---
>  drivers/spi/fsl_qspi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index b2a0583..e61c67b 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -1037,8 +1037,11 @@ static int fsl_qspi_probe(struct udevice *bus)
>* setting the size of these devices to 0.  This would ensure
>* that the complete memory map is assigned to only one flash device.
>*/
> - qspi_write32(priv->flags, >regs->sfa1ad, priv->amba_base[1]);
> + qspi_write32(priv->flags, >regs->sfa1ad,
> +  priv->amba_base[0] + amba_size_per_chip);
>   switch (priv->num_chipselect) {
> + case 1:
> + break;
>   case 2:
>   qspi_write32(priv->flags, >regs->sfa2ad,
>priv->amba_base[1]);
>

Jagan, this patch looks OK to me. Ack?

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

Re: [U-Boot] [PATCH] ls1043ardb: SPL size reduction in case of non-xip boot

[york sun]

On 02/27/2017 07:45 PM, Sumit Garg wrote:
>> -Original Message-
>> From: york sun
>> Sent: Monday, February 27, 2017 10:33 PM
>> To: Sumit Garg ; u-boot@lists.denx.de
>> Cc: Ruchika Gupta ; Prabhakar Kushwaha
>> ; Mingkai Hu ; Vini
>> Pillai 
>> Subject: Re: [PATCH] ls1043ardb: SPL size reduction in case of non-xip boot
>>
>> On 02/20/2017 03:18 AM, Sumit Garg wrote:
>>> Using changes in this patch we were able to reduce approx 10k size of
>>> u-boot-spl.bin image. Following is breif description of changes to
>>> reduce SPL size:
>>> 1. Changes in board/freescale/ls1043ardb/Makefile to remove
>>>compilation of eth.c and cpld.c in case of SPL build.
>>> 2. Changes in board/freescale/ls1043ardb/ls1043ardb.c to keep
>>>only ddr_init and board_early_init_f funcations in case of SPL
>>>build.
>>> 3. Changes in ls1043a_common.h & ls1043ardb.h to remove driver
>>>specific macros due to which static data was being compiled in
>>>case of SPL build.
>>> 4. Disable MMC driver from bieng compiled in case of SPL NAND
>>>build and NAND driver from bieng compiled in case of SPL MMC build.
>>> 5. Remove I2C driver support from SPL in case of LS1043ARDB.
>>>
>>> Signed-off-by: Vinitha Pillai-B57223 
>>
>> Remove the B57223 from the name, unless you really want it.
>>
>
> Sure will remove it.
>
>>> Signed-off-by: Sumit Garg 
>>> ---
>>>  board/freescale/ls1043ardb/Makefile |  4 +++-
>>>  board/freescale/ls1043ardb/ls1043ardb.c | 32 ++-
>> -
>>>  configs/ls1043ardb_sdcard_defconfig |  1 -
>>>  include/configs/ls1043a_common.h| 14 --
>>>  include/configs/ls1043ardb.h|  6 ++
>>>  5 files changed, 39 insertions(+), 18 deletions(-)
>>
>> This patch cause compiling warning for board/freescale/ls1043aqds/eth.c.
>> Please fix.
>>
>> York
>
> Will fix compilation warning.
>

Please send your update.

York

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

Re: [U-Boot] [PATCH 1/1] Secure Boot: Set NPSWA_EN bit for SNVS state transition to happen in EL2.

[york sun]

On 02/15/2017 08:27 AM, york@nxp.com wrote:
> On 02/15/2017 04:23 AM, Udit Agarwal wrote:
>> For Layerscape chasis Gen 3 based platforms, during PPA execution
>> exception level transition happens from EL3 to EL2. While in EL2 state
>> SNVS state doesnot changes from secure to non secure state in
>> case of ESBC failure.
>>
>> So to enable the SNVS transition in EL2 state, NPSWA_EN bit has to be set
>> when in EL3 state.
>
> Wouldn't this be better implemented in PPA firmware?
>

I didn't hear from you. Please consider this patch rejected and work 
with PPA team to address the issue.

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

Re: [U-Boot] [PATCH 2/3] armv8: ls1088ardb: Add support for LS1088ARDB platform

[york sun]

On 02/15/2017 07:08 AM, Ashish Kumar wrote:
> LS1088A is an ARMv8 implementation. The LS1088ARDB is an evaluatoin
> platform that supports the LS1088A family SoCs. This patch add basic
> support of the platform.
>
> Signed-off-by: Alison Wang 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> Signed-off-by: Shaohui Xie 
> ---
>  arch/arm/Kconfig   |  12 +
>  arch/arm/cpu/armv8/Kconfig |   1 +
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  31 +-
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   1 +
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |   6 +-
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|   4 +
>  arch/arm/dts/Makefile  |   3 +-
>  arch/arm/dts/fsl-ls1088a-rdb.dts   |  40 +++
>  arch/arm/dts/fsl-ls1088a.dtsi  |  78 +
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |  68 -
>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   2 +-
>  .../asm/arch-fsl-layerscape/ls1088a_stream_id.h|  57 
>  board/freescale/ls1088a/Kconfig|  15 +
>  board/freescale/ls1088a/MAINTAINERS|   9 +
>  board/freescale/ls1088a/Makefile   |   9 +
>  board/freescale/ls1088a/ddr.c  | 243 +++
>  board/freescale/ls1088a/ddr.h  |  46 +++
>  board/freescale/ls1088a/eth_ls1088ardb.c   | 102 +++
>  board/freescale/ls1088a/ls1088a.c  | 334 
> +
>  board/freescale/ls1088a/ls1088a_qixis.h|  34 +++
>  configs/ls1088ardb_defconfig   |  25 ++
>  configs/ls1088ardb_qspi_defconfig  |  33 ++
>  drivers/ddr/fsl/util.c |   2 +-
>  include/configs/ls1088a_common.h   | 199 
>  include/configs/ls1088ardb.h   | 327 
>  25 files changed, 1673 insertions(+), 8 deletions(-)
>  create mode 100644 arch/arm/dts/fsl-ls1088a-rdb.dts
>  create mode 100644 arch/arm/dts/fsl-ls1088a.dtsi
>  create mode 100644 
> arch/arm/include/asm/arch-fsl-layerscape/ls1088a_stream_id.h
>  create mode 100644 board/freescale/ls1088a/Kconfig
>  create mode 100644 board/freescale/ls1088a/MAINTAINERS
>  create mode 100644 board/freescale/ls1088a/Makefile
>  create mode 100644 board/freescale/ls1088a/ddr.c
>  create mode 100644 board/freescale/ls1088a/ddr.h
>  create mode 100644 board/freescale/ls1088a/eth_ls1088ardb.c
>  create mode 100644 board/freescale/ls1088a/ls1088a.c
>  create mode 100644 board/freescale/ls1088a/ls1088a_qixis.h
>  create mode 100644 configs/ls1088ardb_defconfig
>  create mode 100644 configs/ls1088ardb_qspi_defconfig
>  create mode 100644 include/configs/ls1088a_common.h
>  create mode 100644 include/configs/ls1088ardb.h
>

You are mixing board patch and SoC patch. Please separate the SoC patch 
and squash with your patch #1.

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

Re: [U-Boot] [PATCH 1/3] armv8: ls1088a: Add NXP LS1088A SoC support

[york sun]

On 02/15/2017 07:07 AM, Ashish Kumar wrote:
> The QorIQ LS1088A processor is built on the Layerscape
> architecture combining eight ARM A53 processor cores
> with advanced, high-performance datapath acceleration
> and networks, peripheral interfaces required for
> networking, wireless infrastructure, and general-purpose
> embedded applications.
>
> LS1088A is compliant to the Layerscape Chassis Generation 3.
>
> Features summary:
>  - Eight 32-bit / 64-bit ARM v8 Cortex-A53 CPUs
>  - Cores are in 2 cluster of 4-cores each
>  - Cache coherent interconnect (CCI-400)
>  - One 64-bit DDR4 SDRAM memory controller with ECC
>  - Data path acceleration architecture 2.0 (DPAA2)
>  - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs
>  - QSPI, IFC, 3 PCIe, 1 SATA, 2 USB, 1 SDXC, 2 DUARTs etc
>

Please remove the indentation in commit message.

> Signed-off-by: Alison Wang 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
>  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  10 ++
>  arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 124 
> +
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |  46 
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +
>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   1 +
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  11 ++
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   4 +
>  drivers/net/ldpaa_eth/Makefile |   1 +
>  drivers/net/ldpaa_eth/ls1088a.c|  87 +++
>  10 files changed, 292 insertions(+)
>  create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
>  create mode 100644 drivers/net/ldpaa_eth/ls1088a.c
>



> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> index 83f5501..3aed123 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> @@ -219,6 +219,52 @@
>
>  #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC1
>
> +#elif defined(CONFIG_ARCH_LS1088A)
> +#define CONFIG_MAX_CPUS  8
> +#define CONFIG_SYS_FSL_NUM_CC_PLLS   3
> +#define CONFIG_SYS_FSL_IFC_BANK_COUNT8
> +#define CONFIG_NUM_DDR_CONTROLLERS   1
> +#define CONFIG_SYS_FSL_CLUSTER_CLOCKS{ 1, 1 }
> +#define CONFIG_SYS_FSL_PLATFORM_CLK_RATIO1
> +#define CONFIG_GICV3
> +#define CONFIG_FSL_TZPC_BP147
> +#define CONFIG_FSL_TZASC_400
> +#define CONFIG_FSL_TZASC_1
> +
> +#define  SRDS_MAX_LANES  4
> +#define CONFIG_SYS_FSL_SRDS_1
> +#define CONFIG_SYS_FSL_SRDS_2
> +
> +/* DDR */
> +#define CONFIG_SYS_FSL_DDR_LE
> +#define CONFIG_SYS_LS2_DDR_BLOCK1_SIZE   ((phys_size_t)2 << 30)
> +#define CONFIG_MAX_MEM_MAPPEDCONFIG_SYS_LS2_DDR_BLOCK1_SIZE
> +
> +#define CONFIG_SYS_FSL_CCSR_GUR_LE
> +#define CONFIG_SYS_FSL_CCSR_SCFG_LE
> +#define CONFIG_SYS_FSL_ESDHC_LE
> +#define CONFIG_SYS_FSL_IFC_LE
> +#define CONFIG_SYS_FSL_PEX_LUT_LE
> +
> +#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN
> +
> +/* SFP */
> +#define CONFIG_SYS_FSL_SFP_VER_3_4
> +#define CONFIG_SYS_FSL_SFP_LE
> +#define CONFIG_SYS_FSL_SRK_LE
> +
> +/* SEC */
> +#define CONFIG_SYS_FSL_SEC_LE
> +#define CONFIG_SYS_FSL_SEC_COMPAT5
> +
> +/* Security Monitor */
> +#define CONFIG_SYS_FSL_SEC_MON_LE
> +
> +/* Secure Boot */
> +#define CONFIG_ESBC_HDR_LS
> +
> +/* DCFG - GUR */
> +#define CONFIG_SYS_FSL_CCSR_GUR_LE
>  #else
>  #error SoC not defined
>  #endif

Many of your config macros were moved into Kconfig. You made the update 
in your #2 and #3 patches. How did you miss this one? Please update your 
patch.

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

Re: [U-Boot] [PATCH v2] armv8:fsl-layerscape: Avoid RCWSR28 register hard-coding

[york sun]

On 02/15/2017 07:04 AM, Ashish Kumar wrote:
> From: Prabhakar Kushwaha 
>
> SerDes information is not necessary to be present in RCWSR29 register.
> It may vary from SoC to SoC.
>
> So Avoid RCWSR28 register hard-coding.
>
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> ---
> v2:
> Incorporate York's Review comments
>
>  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 28 
> --
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  9 +++
>  2 files changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> index c2fc646..955e0b7 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> @@ -51,20 +51,22 @@ int is_serdes_configured(enum srds_prtcl device)
>  int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
>  {
>   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
> - u32 cfg = gur_in32(>rcwsr[28]);
> + u32 cfg = 0;
>   int i;
>
>   switch (sd) {
>  #ifdef CONFIG_SYS_FSL_SRDS_1
>   case FSL_SRDS_1:
> - cfg &= FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_MASK;
> - cfg >>= FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT;
> + cfg = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS1_REGSR - 1]);
> + cfg &= FSL_CHASSIS3_SRDS1_PRTCL_MASK;
> + cfg >>= FSL_CHASSIS3_SRDS1_PRTCL_SHIFT;
>   break;
>  #endif
>  #ifdef CONFIG_SYS_FSL_SRDS_2
>   case FSL_SRDS_2:
> - cfg &= FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK;
> - cfg >>= FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT;
> + cfg = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS2_REGSR - 1]);
> + cfg &= FSL_CHASSIS3_SRDS2_PRTCL_MASK;
> + cfg >>= FSL_CHASSIS3_SRDS2_PRTCL_SHIFT;
>   break;
>  #endif
>   default:
> @@ -83,8 +85,8 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
>   return -ENODEV;
>  }
>
> -void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32 sd_prctl_shift,
> - u8 serdes_prtcl_map[SERDES_PRCTL_COUNT])
> +void serdes_init(u32 sd, u32 sd_addr, u32 rcwsr, u32 sd_prctl_mask,

I am OK with this patch. Looks like this function serdes_init() is only 
used locally. Can you make another patch to change all serves_init() to 
static (ls1021a, lsch2, mpc85xx)?

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

Re: [U-Boot] unused-const-variable warnings in FSL DDR driver

[york sun]

On 02/10/2017 02:00 AM, Thomas Schaefer wrote:
>> On Thu, Feb 09, 2017 at 05:51:36PM +, york sun wrote:
>>> On 02/09/2017 09:46 AM, Thomas Schaefer wrote:
>>
>>> On 02/09/2017 02:32 AM, Thomas Schaefer wrote:
 Hi York,



>
> I've built u-boot for T1042RDB with and without the above patch applied. 
> Actually, binary images
> created are the same (with the exception of build timestamp of course), so 
> GCC actually removes
> the unused variables.
>
> When adding __maybe_unsued attribute to the variable definitions, warnings 
> don't show up anymore:
>
> diff --git a/drivers/ddr/fsl/options.c b/drivers/ddr/fsl/options.c
> index d6a8fcb216..64aaa77047 100644
> --- a/drivers/ddr/fsl/options.c
> +++ b/drivers/ddr/fsl/options.c

Thomas,

Can you put your patch together with proper commit message and 
signature? I prefer your solution than this one 
http://patchwork.ozlabs.org/patch/726353/

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