Re: [U-Boot] [PATCH v2 3/8] riscv: Add EFI application infrastructure

[陳建志]

> The hello world binary and a few selftests require to build EFI target 
> binaries, not just the EFI host environment.
>
> This patch adds all required files to generate an EFI binary for RISC-V.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> new in v2
> ---
>  arch/riscv/config.mk   |  5 ++
>  arch/riscv/lib/Makefile| 11 +
>  arch/riscv/lib/elf_riscv32_efi.lds | 70 +++  
> arch/riscv/lib/elf_riscv64_efi.lds | 70 +++
>  arch/riscv/lib/reloc_riscv_efi.c   | 97 
> ++
>  5 files changed, 253 insertions(+)
>  create mode 100644 arch/riscv/lib/elf_riscv32_efi.lds
>  create mode 100644 arch/riscv/lib/elf_riscv64_efi.lds
>  create mode 100644 arch/riscv/lib/reloc_riscv_efi.c
>
> diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk index 
> 69f4cf6ce8..9175aa765d 100644
> --- a/arch/riscv/config.mk
> +++ b/arch/riscv/config.mk
> @@ -19,10 +19,12 @@ endif
>
>  ifdef CONFIG_32BIT
>  PLATFORM_LDFLAGS   += -m $(32bit-emul)
> +EFI_LDS:= elf_riscv32_efi.lds
>  endif
>
>  ifdef CONFIG_64BIT
>  PLATFORM_LDFLAGS   += -m $(64bit-emul)
> +EFI_LDS:= elf_riscv64_efi.lds
>  endif
>
>  CONFIG_STANDALONE_LOAD_ADDR = 0x \ @@ -31,3 +33,6 @@ 
> CONFIG_STANDALONE_LOAD_ADDR = 0x \
>  PLATFORM_CPPFLAGS  += -ffixed-gp -fpic
>  PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 
> -ffunction-sections  LDFLAGS_u-boot += --gc-sections -static -pie
> +
> +EFI_CRT0   := crt0_riscv_efi.o
> +EFI_RELOC  := reloc_riscv_efi.o

Hi Alexander

make fail as below

make[1]: *** No rule to make target 'arch/riscv/lib/crt0_riscv_efi.o',
needed by '__build'.  Stop.
Makefile:1340: recipe for target 'arch/riscv/lib' failed

Shall crt0_riscv_efi.c be uploaded there ?

B.R.

Rick

> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 
> 6d97aa2719..33f80ebdca 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -13,3 +13,14 @@ obj-$(CONFIG_CMD_GO) += boot.o
>  obj-y  += cache.o
>  obj-y  += interrupts.o
>  obj-y   += setjmp.o
> +
> +# For building EFI apps
> +CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
> +CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI)
> +
> +CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI)
> +CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI)
> +
> +extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC)
> +extra-$(CONFIG_CMD_BOOTEFI_SELFTEST) += $(EFI_CRT0) $(EFI_RELOC)
> +extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
> diff --git a/arch/riscv/lib/elf_riscv32_efi.lds 
> b/arch/riscv/lib/elf_riscv32_efi.lds
> new file mode 100644
> index 00..96d11985b0
> --- /dev/null
> +++ b/arch/riscv/lib/elf_riscv32_efi.lds
> @@ -0,0 +1,70 @@
> +/*
> + * U-Boot riscv32 EFI linker script
> + *
> + * SPDX-License-Identifier:BSD-2-Clause
> + *
> + * Modified from arch/arm/lib/elf_aarch64_efi.lds  */
> +
> +OUTPUT_FORMAT("elf32-littleriscv", "elf32-littleriscv",
> +"elf32-littleriscv")
> +OUTPUT_ARCH(riscv)
> +ENTRY(_start)
> +SECTIONS
> +{
> +   .text 0x0 : {
> +   _text = .;
> +   *(.text.head)
> +   *(.text)
> +   *(.text.*)
> +   *(.gnu.linkonce.t.*)
> +   *(.srodata)
> +   *(.rodata*)
> +   . = ALIGN(16);
> +   }
> +   _etext = .;
> +   _text_size = . - _text;
> +   .dynamic  : { *(.dynamic) }
> +   .data : {
> +   _data = .;
> +   *(.sdata)
> +   *(.data)
> +   *(.data1)
> +   *(.data.*)
> +   *(.got.plt)
> +   *(.got)
> +
> +   /*
> +* The EFI loader doesn't seem to like a .bss section, so we
> +* stick it all into .data:
> +*/
> +   . = ALIGN(16);
> +   _bss = .;
> +   *(.sbss)
> +   *(.scommon)
> +   *(.dynbss)
> +   *(.bss)
> +   *(.bss.*)
> +   *(COMMON)
> +   . = ALIGN(16);
> +   _bss_end = .;
> +   _edata = .;
> +   }
> +   .rela.dyn : { *(.rela.dyn) }
> +   .rela.plt : { *(.rela.plt) }
> +   .rela.got : { *(.rela.got) }
> +   .rela.data : { *(.rela.data) *(.rela.data*) }
> +   _data_size = . - _etext;
> +
> +   . = ALIGN(4096);
> +   .dynsym   : { *(.dynsym) }
> +   . = ALIGN(4096);
> +   .dynstr   : { *(.dynstr) }
> +   . = ALIGN(4096);
> +   .note.gnu.build-id : { *(.note.gnu.build-id) }
> +   /DISCARD/ : {
> +   *(.rel.reloc)
> +   *(.eh_frame)
> +   *(.note.GNU-stack)
> +   }
> +   .comment 0 : { *(.comment) }
> +}
> diff --git a/arch/riscv/lib/elf_riscv64_efi.lds 
> b/arch/riscv/lib/elf_riscv64_efi.lds
> new file mode 100644
> index 00..25c863de8a
> --- /dev/null

Re: [U-Boot] [PATCH] DW SPI: invert wait condition in dw_spi_xfer

[Jagan Teki]

On Thu, Apr 19, 2018 at 8:17 PM, Eugeniy Paltsev
 wrote:
> While switching to readl_poll_timeout macros from custom code
> the waiting condition was accidently inverted, so it was pure
> luck that this code works at least in some conditions.
>
> Fix that by inverting exit condition for readl_poll_timeout.
>
> Fixes: c6b4f031d9 ("DW SPI: fix tx data loss on FIFO flush")
>
> Signed-off-by: Eugeniy Paltsev 
> ---

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

Re: [U-Boot] [PATCH 4/4] syscon: add Linux-compatible syscon API

[Masahiro Yamada]

Hi Simon,


2018-04-23 5:11 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 17 April 2018 at 20:38, Masahiro Yamada 
> wrote:
>> The syscon implementation in U-Boot is different from that in Linux.
>> Thus, DT files imported from Linux do not work for U-Boot.
>>
>> In U-Boot driver model, each node is bound to a dedicated driver
>> that is the most compatible to it.  This design gets along with the
>> concept of DT, and the syscon in Linux originally worked like that.
>>
>> However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon
>> interface from platform devices") changed the behavior because it is
>> useful to let a device bind to another driver, but still works as a
>> syscon provider.
>>
>> That change had happened before U-Boot initially supported the syscon
>> driver by commit 6f98b7504f70 ("dm: Add support for generic system
>> controllers (syscon)").  So, the U-Boot's syscon works differently
>> from the beginning.  I'd say this is mis-implementation given that
>> DT is not oriented to a particular project, but Linux is the canon
>> of DT in practice.
>>
>> The problem typically arises in the combination of "syscon" and
>> "simple-mfd" compatibles.
>>
>> In Linux, they are orthogonal, i.e., the order between "syscon" and
>> "simple-mfd" does not matter at all.
>>
>> Assume the following compatible.
>>
>>compatible = "foo,bar-syscon", "syscon", "simple-mfd";
>>
>> In U-Boot, this device node is bound to the syscon driver
>> (driver/core/syscon-uclass.c) since the "syscon" is found to be the
>> most compatible.  Then, syscon_get_regmap() succeeds.
>>
>> However,
>>
>>compatible = "foo,bar-syscon", "simple-mfd", "syscon";
>>
>> does not work because this node is bound to the simple-bus driver
>> (drivers/core/simple-bus.c) in the favor of "simple-mfd" compatible.
>> The compatible string "syscon" is just dismissed.
>>
>> Moreover,
>>
>>compatible = "foo,bar-syscon", "syscon";
>>
>> works like the first case because the syscon driver populates the
>> child devices.  This is wrong because populating children is the job
>> of "simple-mfd" (or "simple-bus").
>>
>> This commit ports syscon_node_to_regmap() from Linux.  This API
>> does not require the given node to be bound to a driver in any way.
>>
>> Reported-by: Kunihiko Hayashi 
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  drivers/core/syscon-uclass.c | 63
> 
>>  include/syscon.h |  8 ++
>>  2 files changed, 71 insertions(+)
>
> I was not aware of this change in how Linux worked, but it makes sense.
>
> Please can you add a test for this?


I do not believe a missing test would block this patch,
but I volunteered to add it (as a separate patch).

http://patchwork.ozlabs.org/patch/902733/




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

Re: [U-Boot] [PATCH 3/4] regmap: change regmap_init_mem() to take ofnode instead udevice

[Masahiro Yamada]

Hi Simon,


2018-04-23 5:10 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 17 April 2018 at 20:38, Masahiro Yamada 
> wrote:
>> Currently, regmap_init_mem() takes udevice. This requires the node
>> has already been associated with a device. It prevents syscon/regmap
>> from behaving like those in Linux.
>>
>> Change the first argumenet to take the device node.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  arch/arm/mach-aspeed/ast2500/sdram_ast2500.c |  2 +-
>>  drivers/core/regmap.c| 11 +--
>>  drivers/core/syscon-uclass.c |  2 +-
>>  drivers/phy/meson-gxl-usb2.c |  2 +-
>>  drivers/phy/meson-gxl-usb3.c |  2 +-
>>  drivers/ram/rockchip/dmc-rk3368.c|  2 +-
>>  drivers/ram/rockchip/sdram_rk3188.c  |  2 +-
>>  drivers/ram/rockchip/sdram_rk322x.c  |  2 +-
>>  drivers/ram/rockchip/sdram_rk3288.c  |  2 +-
>>  drivers/ram/rockchip/sdram_rk3399.c  |  2 +-
>>  drivers/ram/stm32mp1/stm32mp1_ram.c  |  2 +-
>>  drivers/reset/reset-meson.c  |  2 +-
>>  include/regmap.h |  4 ++--
>>  13 files changed, 18 insertions(+), 19 deletions(-)
>
> Can you please add a simple test for regmap on sandbox?
>

No.

Please stop this boiler-plate response.

Simple tests for regmap already exist in test/dm/regmap.c

regmap_init_mem() is not a new function, and it is tested
through other function tests.

You block patches several times before
by making the contributors say "Sorry, I am busy".


I am really busy, but I need to fix the misimplementation
of syscon for Socionext drivers.

Why should I be annoyed by additional work
to fix the problem?


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

Re: [U-Boot] [PATCH 2/4] dm: ofnode: add ofnode_device_is_compatible() helper

[Masahiro Yamada]

2018-04-23 5:11 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 17 April 2018 at 20:38, Masahiro Yamada 
> wrote:
>> device_is_compatible() takes udevice, but there is no such a helper
>> that takes ofnode.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  drivers/core/device.c |  8 +---
>>  drivers/core/ofnode.c | 11 +++
>>  include/dm/ofnode.h   | 11 +++
>>  3 files changed, 23 insertions(+), 7 deletions(-)
>
> Please can you add a call to this to a test?
>

No.

I do not see any ofnode helper test in test/dm/.

You are requesting additional work beyond this patch.
It is unfair.


This helper is tested indirectly by other tests.

Of course, you (and anybody) are free to add per-helper grained tests,
but this is not a good reason to block this patch.




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

Re: [U-Boot] [PATCH v2 1/4] regmap: clean up regmap allocation

[Masahiro Yamada]

2018-04-19 12:14 GMT+09:00 Masahiro Yamada :
> Putting zero length array at the end of struct is a common technique
> to embed arbitrary length of members.  There is no good reason to let
> regmap_alloc_count() branch by "if (count <= 1)".
>
> As far as I understood the code, regmap->base is an alias of
> regmap->ranges[0].start, but it is not helpful but make the code
> just ugly.
>
> Rename regmap_alloc_count() to regmap_alloc() because the _count
> suffix seems pointless.
>
> Signed-off-by: Masahiro Yamada 
> ---

Simon gave r-b to v1.
Copy-pasting it to v2.

Reviewed-by: Simon Glass 


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

[U-Boot] [PATCH] test: regmap: test Linux-compatible syscon_node_to_regmap()

[Masahiro Yamada]

Like Linux, syscon_node_to_regmap() allows a node to work as a syscon
provider without binding it to a syscon driver.  Test this.

Requested-by: Simon Glass 
Signed-off-by: Masahiro Yamada 
---

 arch/sandbox/dts/test.dts |  8 
 test/dm/regmap.c  | 17 +
 2 files changed, 25 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 06d0e8c..3c25cb7 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -393,6 +393,14 @@
0x38 8>;
};
 
+   syscon@2 {
+   compatible = "simple-mfd", "syscon";
+   reg = <0x40 5
+   0x48 6
+   0x50 7
+   0x58 8>;
+   };
+
timer {
compatible = "sandbox,timer";
clock-frequency = <100>;
diff --git a/test/dm/regmap.c b/test/dm/regmap.c
index 8125345..698a013 100644
--- a/test/dm/regmap.c
+++ b/test/dm/regmap.c
@@ -20,6 +20,7 @@ static int dm_test_regmap_base(struct unit_test_state *uts)
 {
struct udevice *dev;
struct regmap *map;
+   ofnode node;
int i;
 
ut_assertok(uclass_get_device(UCLASS_SYSCON, 0, ));
@@ -48,6 +49,22 @@ static int dm_test_regmap_base(struct unit_test_state *uts)
map = syscon_get_regmap(dev);
ut_asserteq_ptr(ERR_PTR(-ENOEXEC), map);
 
+   /* A different device can be a syscon by using Linux-compat API */
+   node = ofnode_path("/syscon@2");
+   ut_assert(ofnode_valid(node));
+
+   map = syscon_node_to_regmap(node);
+   ut_assertok_ptr(map);
+   ut_asserteq(4, map->range_count);
+   ut_asserteq(0x40, map->ranges[0].start);
+   for (i = 0; i < 4; i++) {
+   const unsigned long addr = 0x40 + 8 * i;
+
+   ut_asserteq(addr, map->ranges[i].start);
+   ut_asserteq(5 + i, map->ranges[i].size);
+   ut_asserteq(addr, map_to_sysmem(regmap_get_range(map, i)));
+   }
+
return 0;
 }
 DM_TEST(dm_test_regmap_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/2] arm: Add minimal support for Cortex-R5

[Lokesh Vutla]

On Friday 20 April 2018 07:21 PM, Michal Simek wrote:
> This minimal support will be used by Xilinx ZynqMP R5 cpu.
> 
> Signed-off-by: Michal Simek 
> ---
> 
>  arch/arm/Kconfig  |  6 ++
>  arch/arm/cpu/armv7r/Makefile  |  4 
>  arch/arm/cpu/armv7r/config.mk |  3 +++
>  arch/arm/cpu/armv7r/cpu.c | 24 
>  arch/arm/cpu/armv7r/start.S   | 17 +
>  5 files changed, 54 insertions(+)
>  create mode 100644 arch/arm/cpu/armv7r/Makefile
>  create mode 100644 arch/arm/cpu/armv7r/config.mk
>  create mode 100644 arch/arm/cpu/armv7r/cpu.c
>  create mode 100644 arch/arm/cpu/armv7r/start.S
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5fbce03667d..b10804f55224 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -192,6 +192,10 @@ config CPU_V7M
>   select THUMB2_KERNEL
>   select SYS_CACHE_SHIFT_5
>  
> +config CPU_V7R
> + bool
> + select SYS_CACHE_SHIFT_6

select HAS_THUMB2 might be a good option?

> +
>  config CPU_PXA
>   bool
>   select SYS_CACHE_SHIFT_5
> @@ -209,6 +213,7 @@ config SYS_CPU
>   default "arm1176" if CPU_ARM1176
>   default "armv7" if CPU_V7
>   default "armv7m" if CPU_V7M
> + default "armv7r" if CPU_V7R
>   default "pxa" if CPU_PXA
>   default "sa1100" if CPU_SA1100
>   default "armv8" if ARM64
> @@ -223,6 +228,7 @@ config SYS_ARM_ARCH
>   default 6 if CPU_ARM1176
>   default 7 if CPU_V7
>   default 7 if CPU_V7M
> + default 7 if CPU_V7R
>   default 5 if CPU_PXA
>   default 4 if CPU_SA1100
>   default 8 if ARM64

I did a grep of CPU_V7, and you might want to update for CPU_V7R in the
following places:

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4fa8b38397..f4bc1f250d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -18,6 +18,7 @@ arch-$(CONFIG_CPU_ARM1136)=-march=armv5
 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
 arch-$(CONFIG_CPU_V7)  =$(call cc-option, -march=armv7-a, \
 $(call cc-option, -march=armv7, -march=armv5))
+arch-$(CONFIG_CPU_V7R) =-march=armv7-r
 arch-$(CONFIG_ARM64)   =-march=armv8-a

 # On Tegra systems we must build SPL for the armv4 core on the device
@@ -41,6 +42,7 @@ tune-$(CONFIG_CPU_PXA)=-mcpu=xscale
 tune-$(CONFIG_CPU_ARM1136) =
 tune-$(CONFIG_CPU_ARM1176) =
 tune-$(CONFIG_CPU_V7)  =
+tune-$(CONFIG_CPU_V7R) =
 tune-$(CONFIG_ARM64)   =

 # Evaluate tune cc-option calls now


> diff --git a/arch/arm/cpu/armv7r/Makefile b/arch/arm/cpu/armv7r/Makefile
> new file mode 100644
> index ..3c66976dfa62
> --- /dev/null
> +++ b/arch/arm/cpu/armv7r/Makefile

hmm..do we really need to create a separate folder? IIUC, the main
difference between V7 and V7R is MMU vs MPU. IMHO, we should be able to
get it using Kconfigs.

Thanks and regards,
Lokesh

> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +extra-y := start.o
> +obj-y += cpu.o
> diff --git a/arch/arm/cpu/armv7r/config.mk b/arch/arm/cpu/armv7r/config.mk
> new file mode 100644
> index ..224d191ff846
> --- /dev/null
> +++ b/arch/arm/cpu/armv7r/config.mk
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +PLATFORM_CPPFLAGS += -mcpu=cortex-r5 -DARMR5
> diff --git a/arch/arm/cpu/armv7r/cpu.c b/arch/arm/cpu/armv7r/cpu.c
> new file mode 100644
> index ..e384a530c5e0
> --- /dev/null
> +++ b/arch/arm/cpu/armv7r/cpu.c
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2018 Xilinx, Inc. (Michal Simek)
> + */
> +
> +#include 
> +
> +/*
> + * This is called right before passing control to
> + * the Linux kernel point.
> + */
> +int cleanup_before_linux(void)
> +{
> + return 0;
> +}
> +
> +/*
> + * Perform the low-level reset.
> + */
> +void reset_cpu(ulong addr)
> +{
> + while (1)
> + ;
> +}
> diff --git a/arch/arm/cpu/armv7r/start.S b/arch/arm/cpu/armv7r/start.S
> new file mode 100644
> index ..d6e8eecf54b7
> --- /dev/null
> +++ b/arch/arm/cpu/armv7r/start.S
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) Copyright 2015
> + * Kamil Lulko, 
> + *
> + */
> +
> +#include 
> +
> +.globl   reset
> +.type reset, %function
> +reset:
> + W(b)_main
> +
> +.globl   c_runtime_cpu_setup
> +c_runtime_cpu_setup:
> + mov pc, lr
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 13/16] arm: socfpga: stratix10: Add timer support for Stratix10 SoC

[Marek Vasut]

On 04/23/2018 03:54 AM, Ley Foon Tan wrote:
> On Thu, Apr 19, 2018 at 4:21 PM, Marek Vasut  wrote:
>> On 04/19/2018 07:26 AM, See, Chin Liang wrote:
>>> On Thu, 2018-04-19 at 04:59 +0200, Marek Vasut wrote:
 On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
>
> Add timer support for Stratix SoC
 Is this really custom timer or is that some armv8 thing you're adding
 here ? Don't we already have a generic implementation for that ? If
 not,
 that's what we should do here.
>>>
>>> Yes but not the init function. It's left with platform specific code to
>>> init it.
>>
>> Where is the common part ?
>>
>> --
>> Best regards,
>> Marek Vasut
> 
> timer_init weak function is in lib/time.c and common code is in this
> file as well.
> 
> int __weak timer_init(void)
> {
> return 0;
> }

Oh, that's what you use, I see.

I suspect having a timer_gen5. and timer_gen10.c would be a bit cleaner
than the ifdef.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 3/3] Adding wget

[Duncan Hare]

>From: Simon Glass 
 >To: Duncan Hare  
 >Sent: Sunday, April 22, 2018 1:10 PM
 >Subject: Re: [PATCH v10 3/3] Adding wget
   >
>Hi Duncan,

>On 17 April 2018 at 15:58, Duncan Hare  wrote:
>> From: Simon Glass 
>> It has been through patman, and the only errors flagged a packed structures,
>> necessary for packed headers.

>It should be possible in the Python test to enable an http server on localhost 
>with a few lines of code, and then connect to it in the test?
Yes server at port 80. The server can be tested with the wget command which can 
be installed on linux.I doubt that loop-back like this will produce the 
scrambling of packet order which is a feature of push down stacks for packet 
queuesin the internet.
The pi is easy to overrun when testing on a low latency network, because the 
TCP send window size is defined by the number ofnet_rx_buffers, which is 
controlled the CONFIG_SYS_RX_ETH_BUFFER in include.net.h,  which sets PKTBUFSRX 
at the beginning of include/net.h, 
which in-turn defines a buffer pool in net/net.c, array named  net_pkt_buf.
Hence my comment in a different thread about buffering on the pi. Few of the 
socs appear to use net_pkt_buf  buffers for net traffic.

If there are too many transmission errors the sending tcp drops the connection. 
My solution to this is to halve the size of 
CONFIG_SYS_RX_ETH_BUFFER until transmission works.
If I was thinking about a buffer pool for in the drivers, I'd implement it in 
net/net.c. Interface "getbuffer," returns a pointer, 
and increments an index to the next net_rx_buffer with no protection for 
overrun. Overrun is managed by ack numbers in TCPand timeout in UDP.

Possibly CONFIG_SYS_RX_ETH_BUFFER could come under Kconfig.

>Regards,
>Simon
RegardsDuncan


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

Re: [U-Boot] Network Packet Buffers: raspberrypi: variable uchar *net_rx_packets[PKTBUFSRX] in net/net.c

[Duncan Hare]

From: Simon Glass 


 To: Duncan Hare  
Cc: Joe Hershberger ; U-Boot Mailing List 

 Sent: Sunday, April 22, 2018 1:15 PM
 Subject: Re: Network Packet Buffers: raspberrypi: variable uchar 
*net_rx_packets[PKTBUFSRX] in net/net.c
   
Hi Duncan,

>On 17 April 2018 at 12:59, Duncan Hare  wrote:
>> Simon
>>
>> Is it possible to modify the network driver for the raspberry pi to use
>> the buffer pool defined in net.c?
>>
>> It appears to have a single buffer, defined in the driver.
>>
>> In addition the buffer pool should be defined in memory outside the
>> u-boot image. With the current definition is the buffer pool a
>> part of the u-boot image?

>Are you referring to the USB driver? If so, which one? Normally the buffers 
>are in BSS if they are not allocated with malloc(). So the buffers are not in 
>the U-Boot image in flash, >but do take up space in RAM at run-time after 
>relocation.
Do not recall the filename of the driver. 

>Regards,
>Simon
Hi Simon
Ethernet driver. But it might also be the usb driver . I don't know the detail 
at that level of the raspberry soc.
 Duncan Hare

714 931 7952


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

Re: [U-Boot] [PATCH v1 10/16] arm: dts: Add dts for Stratix10 SoC

[Ley Foon Tan]

On Thu, Apr 19, 2018 at 10:54 AM, Marek Vasut  wrote:
> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
>> Device tree for Stratix10 SoC
>>
>> Signed-off-by: Chin Liang See 
>> Signed-off-by: Ley Foon Tan 
>
>
> Is this pulled from mainline Linux or not ?
>
> --
> Best regards,
> Marek Vasut

Will remove this patch and uses commit 81577a3b044645 from Dinh.

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

Re: [U-Boot] [PATCH v1 13/16] arm: socfpga: stratix10: Add timer support for Stratix10 SoC

[Ley Foon Tan]

On Thu, Apr 19, 2018 at 4:21 PM, Marek Vasut  wrote:
> On 04/19/2018 07:26 AM, See, Chin Liang wrote:
>> On Thu, 2018-04-19 at 04:59 +0200, Marek Vasut wrote:
>>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:

 Add timer support for Stratix SoC
>>> Is this really custom timer or is that some armv8 thing you're adding
>>> here ? Don't we already have a generic implementation for that ? If
>>> not,
>>> that's what we should do here.
>>
>> Yes but not the init function. It's left with platform specific code to
>> init it.
>
> Where is the common part ?
>
> --
> Best regards,
> Marek Vasut

timer_init weak function is in lib/time.c and common code is in this
file as well.

int __weak timer_init(void)
{
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 05/16] arm: socfpga: misc: Add CONFIG_SYS_L2_PL310 switch

[Ley Foon Tan]

On Fri, Apr 20, 2018 at 7:00 PM, Marek Vasut  wrote:
> On 04/20/2018 09:49 AM, Ley Foon Tan wrote:
>> On Thu, Apr 19, 2018 at 4:19 PM, Marek Vasut  wrote:
>>> On 04/19/2018 07:15 AM, See, Chin Liang wrote:
 On Thu, 2018-04-19 at 04:47 +0200, Marek Vasut wrote:
> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
>>
>> Add CONFIG_SYS_L2_PL310 conditional build.
> Why ?
>

 In ARM64, L2 cache controller is accessed through processor registers.
 Hence we shall make this conditional in order this file can be shared
 across SOCFPGAs.
>>>
>>> That should be in the patch description .
>>> Do you ever add the PL310 register access on S10 later in the set?
>>>
>>> --
>> Okay, will update description.
>> No, S10 doesn't use PL310 registers.
>
> If this PL310 is Gen5 specific, then keep it in some Gen5 file.
>
> --
> Best regards,
> Marek Vasut.

Arria 10 needs this PL310 as well. So, we keep it in common misc.

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

Re: [U-Boot] [PATCH v1 06/16] arm: socfpga: misc: Move eth reset to common misc driver

[Ley Foon Tan]

On Thu, Apr 19, 2018 at 4:20 PM, Marek Vasut  wrote:
> On 04/19/2018 05:13 AM, Ley Foon Tan wrote:
>> On Thu, Apr 19, 2018 at 10:47 AM, Marek Vasut  wrote:
>>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
 Move eth reset to common misc driver so can used by other device families.

 Signed-off-by: Chin Liang See 
 Signed-off-by: Ley Foon Tan 
>>>
>>> Shouldn't this use the reset framework instead ?
>>>
>> What reset framework you refer to? drivers/reset?
>
> I think so, there were patches from Dinh earlier this month
>  2ac718821a   | Dinh Nguyen  | reset: socfpga: add reset driver for
> SoCFPGA platform
>
Noted, will remove this change.

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

Re: [U-Boot] [RFC] rules for SPDX-License-Identifier

[Fabio Estevam]

Hi Tom,

On Sat, Apr 14, 2018 at 10:57 AM, Tom Rini  wrote:

> Ugh.  It also looks like it wouldn't be easy to make it a relaxed check.
> So we can either ignore SPDX_LICENSE_TAG in .checkpatch.conf (and be no
> worse but not better than before) or a coccinelle script to whack all of
> our current tags into kernel-style tags?

I like more the coccinelle script idea to make U-Boot to match the
SPDX notation used in the kernel.

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

[U-Boot] [PATCH] HACK: Some further clang support for ARM

[Tom Rini]

- Have logic in one place for -ffixed-r9 or -ffixed-x18 as clang -target
  aarch64-linux-gnu will warn about being passed an invalid arugment,
  -ffixed-r9.  I should submit this on its own as a cleanup.
- clang does NOT like:
  str8w   r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
  and makes it a fatal error.  Work-around this by expanding the macro
  by hand in 3 places.

Not included in here is that clang does not at all care for the EFI
loader saving / restoring gd in C as it does.  This is already
documented in doc/README.clang, but I'm spelling it out here.

Cc: Alexander Graf 
Signed-off-by: Tom Rini 
---
 arch/arm/config.mk   | 10 --
 arch/arm/cpu/armv8/config.mk |  1 -
 arch/arm/lib/memcpy.S|  4 ++--
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index b448ed0b3ebd..f42aa35f4e59 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -13,12 +13,18 @@ CONFIG_STANDALONE_LOAD_ADDR = 0xc10
 endif
 endif
 
-CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections
+ifeq ($(CONFIG_ARM64),y)
+FIXED_GD_REG := -ffixed-x18
+else
+FIXED_GD_REG := -ffixed-r9
+endif
+
+CFLAGS_NON_EFI := -fno-pic $(FIXED_GD_REG) -ffunction-sections -fdata-sections
 CFLAGS_EFI := -fpic -fshort-wchar
 
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
--fno-common -ffixed-r9
+-fno-common $(FIXED_GD_REG)
 PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
   $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
 
diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk
index 27b66d41b1a8..2b6ced6648ec 100644
--- a/arch/arm/cpu/armv8/config.mk
+++ b/arch/arm/cpu/armv8/config.mk
@@ -4,7 +4,6 @@
 #
 # SPDX-License-Identifier: GPL-2.0+
 #
-PLATFORM_RELFLAGS += -fno-common -ffixed-x18
 
 PF_NO_UNALIGNED := $(call cc-option, -mstrict-align)
 PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 588b3f8971ae..307c3bbc1472 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -96,7 +96,7 @@ ENTRY(memcpy)
 3: PLD(pld [r1, #124]  )
 4: ldr8w   r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
subsr2, r2, #32
-   str8w   r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f
+   stmia   r0!, {r3, r4, r5, r6, r7, r8, ip, lr}
bge 3b
PLD(cmn r2, #96 )
PLD(bge 4b  )
@@ -212,7 +212,7 @@ ENTRY(memcpy)
orr r9, r9, ip, lspush #\push
mov ip, ip, lspull #\pull
orr ip, ip, lr, lspush #\push
-   str8w   r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
+   stmia   r0!, {r3, r4, r5, r6, r7, r8, r9, ip}
bge 12b
PLD(cmn r2, #96 )
PLD(bge 13b )
-- 
2.7.4

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

[U-Boot] [PATCH] clang: Update documentation

[Tom Rini]

As of clang-5.0, things have changed a bit.  First, we cannot
automatically guess -target values as if we do not pass one with CC then
cc-option will fail.  Second, to disable movt/movw relocations the
argument has become -mno-movt.

Related to the target part, we cannot use arm-none-eabi as that ends up
being too generic of an ARM target for things like say rpi_3_32b to
work.

Signed-off-by: Tom Rini 
---
 arch/arm/config.mk |  5 ++---
 doc/README.clang   | 18 +++---
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 9c213b897cd5..b448ed0b3ebd 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -23,9 +23,8 @@ PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
   $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
 
 # LLVM support
-LLVMS_RELFLAGS := $(call cc-option,-mllvm,) \
-   $(call cc-option,-target arm-none-eabi,) \
-   $(call cc-option,-arm-use-movt=0,)
+LLVM_RELFLAGS  := $(call cc-option,-mllvm,) \
+   $(call cc-option,-mno-movt,)
 PLATFORM_RELFLAGS  += $(LLVM_RELFLAGS)
 
 PLATFORM_CPPFLAGS += -D__ARM__
diff --git a/doc/README.clang b/doc/README.clang
index e0491b2d7e6b..475bb1e2ed8b 100644
--- a/doc/README.clang
+++ b/doc/README.clang
@@ -10,16 +10,11 @@ used to get its value. This does lead to larger code then 
strictly
 necessary, but at least works.
 
 NOTE: target compilation only work for _some_ ARM boards at the moment.
-Also Aarch64 is not supported: Most notably boards which aren't using
-the generic board will fail to compile, but since those are expected
-to be converted this will solve itself. Boards which reassign gd in c
-will also fail to compile, but there is in no strict reason to do so
-in the ARM world, since crt0.S takes care of this. These assignments
-can be avoided by changing the init calls but this is not in mainline yet.
-
-NOTE: without the -mllvm -arm-use-movt=0 flags U-Boot will compile
-fine, but llvm might hardcode addresses in movw / movt pairs, which
-cannot be relocated and U-Boot will fail at runtime.
+Also AArch64 is not supported currently due to a lack of private libgcc
+support.  Boards which reassign gd in c will also fail to compile, but there is
+in no strict reason to do so in the ARM world, since crt0.S takes care of this.
+These assignments can be avoided by changing the init calls but this is not in
+mainline yet.
 
 Debian (based)
 --
@@ -29,7 +24,8 @@ sudo apt-get install clang
 Note that we still use binutils for some tools so we must continue to set
 CROSS_COMPILE. To compile U-Boot with clang on linux without IAS use e.g.:
 make HOSTCC=clang rpi_2_defconfig
-make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- CC=clang -j8
+make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
+CC="clang -target arm-linux-gnueabi" -j8
 
 It can also be used to compile sandbox:
 make HOSTCC=clang sandbox_defconfig
-- 
2.7.4

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

Re: [U-Boot] [PULL] u-boot-sh/master

[Tom Rini]

On Sun, Apr 22, 2018 at 05:29:25AM +0200, Marek Vasut wrote:

> The following changes since commit a35747b5e1261adfb27ab87575dea4b17e247da2:
> 
>   Merge git://git.denx.de/u-boot-uniphier (2018-04-18 16:24:26 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to f7aa3cd4a81c7a1ef480e39a1b979483452325cb:
> 
>   ARM: rmobile: Update E2 Silk (2018-04-21 18:33:31 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-usb/master

[Tom Rini]

On Sun, Apr 22, 2018 at 05:29:46AM +0200, Marek Vasut wrote:

> The following changes since commit a35747b5e1261adfb27ab87575dea4b17e247da2:
> 
>   Merge git://git.denx.de/u-boot-uniphier (2018-04-18 16:24:26 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 38276090ee7fda6b31cac638d8c5f4fb61f57b0b:
> 
>   usb: dwc3-of-simple: fix error check of clk_get_bulk when disabled
> (2018-04-21 18:38:56 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] Migrate IMAGE_FORMAT_LEGACY to Kconfig

[Tom Rini]

On Fri, Apr 20, 2018 at 09:25:38PM +, Alex Kiernan wrote:

> This converts IMAGE_FORMAT_LEGACY to Kconfig
> 
> Signed-off-by: Alex Kiernan 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Network Packet Buffers: raspberrypi: variable uchar *net_rx_packets[PKTBUFSRX] in net/net.c

[Simon Glass]

Hi Duncan,

On 17 April 2018 at 12:59, Duncan Hare  wrote:
> Simon
>
> Is it possible to modify the network driver for the raspberry pi to use
> the buffer pool defined in net.c?
>
> It appears to have a single buffer, defined in the driver.
>
> In addition the buffer pool should be defined in memory outside the
> u-boot image. With the current definition is the buffer pool a
> part of the u-boot image?

Are you referring to the USB driver? If so, which one? Normally the buffers
are in BSS if they are not allocated with malloc(). So the buffers are not
in the U-Boot image in flash, but do take up space in RAM at run-time after
relocation.

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

Re: [U-Boot] [PATCH 1/3] rockchip: rk3036: add ofdata_to_platdata() callback for driver

[Simon Glass]

Hi Kever,

On 18 April 2018 at 02:05, Kever Yang  wrote:
> Parse of data in dedicate api instead of in probe().

dedicated

Also please can you call it a 'method' rather than a 'callback'? I feel
that a callback is something provided by subsystem A which calls subsystem
B, to allow B to call back into A. In this case, the driver is not the
caller - it is just a driver.

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

Re: [U-Boot] [PATCH 6/7] video_display: Add power_on function

[Simon Glass]

Hi Mario,

On 18 April 2018 at 02:30, Mario Six  wrote:
> Hi Simon,
>
> On Thu, Apr 12, 2018 at 6:36 PM, Simon Glass  wrote:
>> Hi Mario,
>>
>> On 11 April 2018 at 00:35, Mario Six  wrote:
>>> Hi Simon,
>>>
>>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass  wrote:
 Hi Mario,

 On 28 March 2018 at 20:40, Mario Six  wrote:
> Add a power_on function to the display uclass to allow devices to be
> probed and powered-on separately.

 Is this different from the 'enable' method?

>>>
>>> I was thinking that this is more low-level than the enable method,
which also
>>> sets display parameters. I could also use the enable method if it's
alright to
>>> disregard the panel_bpp and timing parameters.
>>
>> Yes it's fine to ignore those. I'm just trying to use existing API
>> calls where possible (without being silly about it!)
>>
>
> OK, I'll switch to that function then.
>
>>>
 Also note that we have a panel uclass that might be useful.

>>>
>>> The Logicore driver is probably more low-level than that, but I'll take
a look.
>>
>> OK. Conceptually a panel is just a display panel, so could be of any
>> type, I think.
>>
>
> Took another look: The panel uclass is still a bit thin, but the only
operation
> (enable_backlight) sounds more that it's supposed to contain drivers for
"real"
> panels (i.e. physical display devices). The Logicore TX really just
generates a
> DP signal and does not display it itself (the upcoming board has no
display
> capability at all, actually). So it probably better fits in the display
uclass.

OK I see. Please be sure to mention this info in your patches.

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

Re: [U-Boot] [PATCH 1/3] core: Add function to get device for ofnode

[Simon Glass]

Hi Mario,

On 18 April 2018 at 02:20, Mario Six  wrote:
> Hi Simon,
>
> On Thu, Apr 12, 2018 at 6:42 PM, Simon Glass  wrote:
>> Hi Mario,
>>
>> On 10 April 2018 at 05:34, Mario Six  wrote:
>>> Hi Simon,
>>>
>>> On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass  wrote:
 Hi Mario,

 On 28 March 2018 at 20:37, Mario Six  wrote:
> It's sometimes useful to get the device associated with a given
ofnode.
> Implement a function to implement this lookup operation.

 Where would you use this? Can you not use phandles to find the device?
 Or uclass_get_device_by_ofnode() ?

>>>
>>> The function is used with the dev_{enable,disable}_by_path in the next
patch:
>>> If I used any of the uclass_* functions or similar, the device would be
probed,
>>> which is not what I want, since the device may not actually be
physically
>>> present.
>>
>> So how about using uclass_find_device_by_ofnode() ?
>>
>
> That would work for the disabling, true, but not for the enabling (which
is
> what is used in the upcoming board): Since the node is declared as
disabled in
> the DT, the device is not even bound (so uclass_find_device_by_ofnode)
won't
> return it.
>
> A more elegant solution would be to have device_probe check again if the
> underlying ofnode is disabled, and stop the probing if that's the case.
In this
> scenario the disabled devices would still be displayed in the tree, but
never
> probed, which is probably OK (I don't know if there would be any side
effects
> with iterating through devices, for example). But changing the behavior
of such
> elementary API functions is probably not a good idea.

That seems to be a different topic.

Fundamentally I don't see the difference between
uclass_find_device_by_ofnode() and your ofnode_dev().

If you want to enable something after probing you will have to call
device_bind() or similar. If that is your intent, I think you need a
different function from ofnode_dev(), since it also relies on the device
already being bound.

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

Re: [U-Boot] [PATCH 0/5] Use Android DT image format for TI boards

[Simon Glass]

Hi,

On 17 April 2018 at 14:57, Andrew F. Davis  wrote:
> On 04/16/2018 03:32 PM, Sam Protsenko wrote:
>> Android documentation recommends using new image format for storing dtb
>> and dtbo files: [1]. Using that format, we can pack several dtb files to
>> dtb.img, and also pack several dtbo files to dtbo.img. Then those images
>> should be flashed to eMMC partitions, called "dtb" and "dtbo"
>> respectively.
>>
>
>
> I'm not convinced adding yet another one-off Android specific partition
> format is what we need right now. With FIT images this is a solved
> problem, why does Android need to go down a different path here?

Agreed.

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

Re: [U-Boot] [PATCH 2/4] dm: ofnode: add ofnode_device_is_compatible() helper

[Simon Glass]

Hi Masahiro,

On 17 April 2018 at 20:38, Masahiro Yamada 
wrote:
> device_is_compatible() takes udevice, but there is no such a helper
> that takes ofnode.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/core/device.c |  8 +---
>  drivers/core/ofnode.c | 11 +++
>  include/dm/ofnode.h   | 11 +++
>  3 files changed, 23 insertions(+), 7 deletions(-)

Please can you add a call to this to a test?

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

Re: [U-Boot] [PATCH 4/4] syscon: add Linux-compatible syscon API

[Simon Glass]

Hi Masahiro,

On 17 April 2018 at 20:38, Masahiro Yamada 
wrote:
> The syscon implementation in U-Boot is different from that in Linux.
> Thus, DT files imported from Linux do not work for U-Boot.
>
> In U-Boot driver model, each node is bound to a dedicated driver
> that is the most compatible to it.  This design gets along with the
> concept of DT, and the syscon in Linux originally worked like that.
>
> However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon
> interface from platform devices") changed the behavior because it is
> useful to let a device bind to another driver, but still works as a
> syscon provider.
>
> That change had happened before U-Boot initially supported the syscon
> driver by commit 6f98b7504f70 ("dm: Add support for generic system
> controllers (syscon)").  So, the U-Boot's syscon works differently
> from the beginning.  I'd say this is mis-implementation given that
> DT is not oriented to a particular project, but Linux is the canon
> of DT in practice.
>
> The problem typically arises in the combination of "syscon" and
> "simple-mfd" compatibles.
>
> In Linux, they are orthogonal, i.e., the order between "syscon" and
> "simple-mfd" does not matter at all.
>
> Assume the following compatible.
>
>compatible = "foo,bar-syscon", "syscon", "simple-mfd";
>
> In U-Boot, this device node is bound to the syscon driver
> (driver/core/syscon-uclass.c) since the "syscon" is found to be the
> most compatible.  Then, syscon_get_regmap() succeeds.
>
> However,
>
>compatible = "foo,bar-syscon", "simple-mfd", "syscon";
>
> does not work because this node is bound to the simple-bus driver
> (drivers/core/simple-bus.c) in the favor of "simple-mfd" compatible.
> The compatible string "syscon" is just dismissed.
>
> Moreover,
>
>compatible = "foo,bar-syscon", "syscon";
>
> works like the first case because the syscon driver populates the
> child devices.  This is wrong because populating children is the job
> of "simple-mfd" (or "simple-bus").
>
> This commit ports syscon_node_to_regmap() from Linux.  This API
> does not require the given node to be bound to a driver in any way.
>
> Reported-by: Kunihiko Hayashi 
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/core/syscon-uclass.c | 63

>  include/syscon.h |  8 ++
>  2 files changed, 71 insertions(+)

I was not aware of this change in how Linux worked, but it makes sense.

Please can you add a test for this?

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

Re: [U-Boot] [PATCH 1/4] regmap: clean up regmap allocation

[Simon Glass]

Hi Masahiro,

On 17 April 2018 at 20:38, Masahiro Yamada 
wrote:
> Putting zero length array at the end of struct is a common technique
> to embed arbitrary length of members.  There is no good reason to let
> regmap_alloc_count() branch by "if (count <= 1)".
>
> As far as I understood the code, regmap->base is an alias of
> regmap->ranges[0].start, but it is not helpful but make the code
> just ugly.
>
> Rename regmap_alloc_count() to regmap_alloc() because the _count
> suffix seems pointless.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/core/regmap.c | 31 +--
>  include/regmap.h  |  7 ++-
>  2 files changed, 11 insertions(+), 27 deletions(-)

This seems fine to me and does not increase the number of allocations.

Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH 7/7] video_display: Add Xilinx LogiCore DP TX

[Simon Glass]

Hi Mario,

On 18 April 2018 at 02:52, Mario Six  wrote:
> Hi Simon,
>
> On Thu, Apr 12, 2018 at 6:38 PM, Simon Glass  wrote:
>> Hi Mario,
>>
>> On 11 April 2018 at 01:27, Mario Six  wrote:
>>> Hi Simon,
>>>
>>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass  wrote:
 Hi Mario,

 On 28 March 2018 at 20:40, Mario Six  wrote:
> Add a driver for the Xilinx LogiCORE DisplayPort IP core.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/video/Kconfig|8 +
>  drivers/video/Makefile   |1 +
>  drivers/video/logicore_dp_dpcd.h |  342 ++
>  drivers/video/logicore_dp_tx.c   | 1974
++
>  drivers/video/logicore_dp_tx.h   |   40 +
>  drivers/video/logicore_dp_tx_regif.h |  365 +++
>  6 files changed, 2730 insertions(+)
>  create mode 100644 drivers/video/logicore_dp_dpcd.h
>  create mode 100644 drivers/video/logicore_dp_tx.c
>  create mode 100644 drivers/video/logicore_dp_tx.h
>  create mode 100644 drivers/video/logicore_dp_tx_regif.h

 Is it possible to have common code with the other DP drivers?

>>>
>>> While the DP transmitters, of course, all do similar things (e.g. they
all
>>> eventually set a lane count), the implementation details differ
greatly, and I
>>> think trying to merge them would only make things more confusing, since
the
>>> drivers tend to be pretty elaborate (looking at the exynos driver, for
>>> example).
>>
>> OK. Are they merged in Linux?
>>
>
> The Linux DP drivers don't share a common code base either (grepping
> "lane_count" in drivers/gpu shows different implementations of lane
setting and
> link training).

OK, well that is suggestive. Perhaps duplicating the code is best.

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

Re: [U-Boot] [PATCH] pinctrl: do not set_state for device without valid ofnode

[Simon Glass]

On 18 April 2018 at 03:54, Kever Yang  wrote:
> Not all the udevice have a available DT node, eg. rksd...@ff50.blk
> which add by mmc_bind(), these device do not have/need set pinctrl
> state.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/pinctrl/pinctrl-uclass.c | 6 ++
>  1 file changed, 6 insertions(+)

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

Re: [U-Boot] [PATCH 3/4] regmap: change regmap_init_mem() to take ofnode instead udevice

[Simon Glass]

Hi Masahiro,

On 17 April 2018 at 20:38, Masahiro Yamada 
wrote:
> Currently, regmap_init_mem() takes udevice. This requires the node
> has already been associated with a device. It prevents syscon/regmap
> from behaving like those in Linux.
>
> Change the first argumenet to take the device node.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/mach-aspeed/ast2500/sdram_ast2500.c |  2 +-
>  drivers/core/regmap.c| 11 +--
>  drivers/core/syscon-uclass.c |  2 +-
>  drivers/phy/meson-gxl-usb2.c |  2 +-
>  drivers/phy/meson-gxl-usb3.c |  2 +-
>  drivers/ram/rockchip/dmc-rk3368.c|  2 +-
>  drivers/ram/rockchip/sdram_rk3188.c  |  2 +-
>  drivers/ram/rockchip/sdram_rk322x.c  |  2 +-
>  drivers/ram/rockchip/sdram_rk3288.c  |  2 +-
>  drivers/ram/rockchip/sdram_rk3399.c  |  2 +-
>  drivers/ram/stm32mp1/stm32mp1_ram.c  |  2 +-
>  drivers/reset/reset-meson.c  |  2 +-
>  include/regmap.h |  4 ++--
>  13 files changed, 18 insertions(+), 19 deletions(-)

Can you please add a simple test for regmap on sandbox?

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

Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address

[Tuomas Tynkkynen]

On Fri, 20 Apr 2018 13:03:47 +0300
Tuomas Tynkkynen  wrote:

> Hi Alexander,
> 
> What do you think of these patches? I haven't done testing with the
> big kernels / DTBs yet, just that my previously-working kernel still
> boots.
> 

I've now verified that these two patches work as expected. I tested:

- RPi 1 running mainline kernel
- RPi 1 running downstream kernel
- RPi 3 running mainline kernel in 64-bit mode
- RPi 3 running mainline kernel in 32-bit mode
- RPi 3 running downstream kernel in 32-bit mode
- RPi 3B+ running downstream kernel in 32-bit mode

This was with the extlinux.conf distro boot. I don't know to what
extent these variables affect EFI boot.

> Tuomas Tynkkynen (2):
>   rpi: Fix fdt_high & initrd_high for 64-bit builds
>   rpi: Change load addresses to make more room for the kernel & DTB
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Makefile: Update clang warning disables from Linux

[Tom Rini]

Re-sync the logic about which clang warnings to disable from v4.17-rc1.
Note that we don't disable all of the same ones as for now we haven't
run into any cases of warnings from clang in code from upstream Linux.

Signed-off-by: Tom Rini 
---
 Makefile | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Makefile b/Makefile
index 64351eb769e2..143644c98759 100644
--- a/Makefile
+++ b/Makefile
@@ -610,6 +610,13 @@ endif
 endif
 
 KBUILD_CFLAGS += $(call cc-option,-Wno-format-nonliteral)
+ifeq ($(cc-name),clang)
+KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
+KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
+KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
+KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
+endif
 
 # turn jbsr into jsr for m68k
 ifeq ($(ARCH),m68k)
-- 
2.7.4

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

[U-Boot] [PATCH] video-uclass: Fix logical-not-parentheses warning

[Tom Rini]

With clang-4.0 and later we see:
warning: logical not is only applied to the left hand side of this bitwise
operator [-Wlogical-not-parentheses]
if ((!gd->flags & GD_FLG_RELOC))
 ^  ~

And while the compiler suggests adding parenthesis around gd->flags, a
reading of the code says that we want to know when GD_FLG_RELOC is not
set and then return.

Cc: Simon Glass 
Cc: Anatolij Gustschin 
Signed-off-by: Tom Rini 
---
 drivers/video/video-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index b5bb8e0efde5..93fdc6828b1e 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -272,7 +272,7 @@ static int video_post_bind(struct udevice *dev)
ulong size;
 
/* Before relocation there is nothing to do here */
-   if ((!gd->flags & GD_FLG_RELOC))
+   if (!(gd->flags & GD_FLG_RELOC))
return 0;
size = alloc_fb(dev, );
if (addr < gd->video_bottom) {
-- 
2.7.4

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

Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

[Jorge Ramirez-Ortiz]

On 04/20/2018 09:07 PM, Ramon Fried wrote:

Actually, I already verified that. the driver probes twice, once
before and once after relocation.
In case of serial, it's not a big deal to re-initialize the hardware,
but I agree it's worthless.

Ok. just checked, it's first probed before relocation.


ah of course, the db820 - what I was using to validate- doesnt probe 
early despite the change because the uart node doesnt use the clock.

cool, looks good to me.


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