Re: [PATCH 025/149] board: beckhoff: Remove and add needed includes

[Patrick Brünn]

Tested-by: Patrick Bruenn 


On Tue, 2024-04-30 at 20:41 -0600, Tom Rini wrote:
> CAUTION: External Email!!
> Remove  from this board vendor directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Patrick Bruenn 
> ---
>  board/beckhoff/mx53cx9020/mx53cx9020.c   | 1 -
>  board/beckhoff/mx53cx9020/mx53cx9020_video.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/board/beckhoff/mx53cx9020/mx53cx9020.c 
> b/board/beckhoff/mx53cx9020/mx53cx9020.c
> index e7b131836b61..3a766728a6f7 100644
> --- a/board/beckhoff/mx53cx9020/mx53cx9020.c
> +++ b/board/beckhoff/mx53cx9020/mx53cx9020.c
> @@ -7,7 +7,6 @@
>   * Copyright (C) 2011 Freescale Semiconductor, Inc.
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/board/beckhoff/mx53cx9020/mx53cx9020_video.c 
> b/board/beckhoff/mx53cx9020/mx53cx9020_video.c
> index bf4729025622..fd28a70f4d72 100644
> --- a/board/beckhoff/mx53cx9020/mx53cx9020_video.c
> +++ b/board/beckhoff/mx53cx9020/mx53cx9020_video.c
> @@ -7,7 +7,6 @@
>   * Copyright (C) 2012 Freescale Semiconductor, Inc.
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 

This email contains confidential information. If you have received it in error, 
you must not read, use, copy or pass on this e-mail or its attachments. If you 
have received the e-mail in error, please inform me immediately by reply e-mail 
and then delete this e-mail from your system. Thank you

Diese E-Mail enthält vertrauliche Informationen. Sollten Sie sie irrtümlich 
erhalten haben, dürfen Sie diese E-Mail oder ihre Anhänge nicht lesen, 
verwenden, kopieren oder weitergeben. Sollten Sie die Mail versehentlich 
erhalten haben, teilen Sie mir dies bitte umgehend per Antwort-E-Mail mit und 
löschen Sie diese E-Mail dann aus Ihrem System. Vielen Dank

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075

Re: [U-Boot] [PATCH v3 3/5] dm: led: move default state support in led uclass

[Patrick Brünn]

Hi Patrick,
sorry, for responding so late, I am in the middle of a vacation at the moment.
>From: Patrick Delaunay [mailto:patrick.delau...@st.com]
>Sent: Dienstag, 24. Juli 2018 10:59
>Subject: [PATCH v3 3/5] dm: led: move default state support in led uclass
>
>This patch save common LED property "default-state" value
>in post bind of LED uclass.
>The configuration for this default state is only performed when
>led_default_state() is called;
>It can be called in your board_init()
>or it could added in init_sequence_r[] in future.
>
>Reviewed-by: Simon Glass 
>Signed-off-by: Patrick Delaunay 
>---
>
>Changes in v3: None
>Changes in v2: None
>
> drivers/led/led-uclass.c | 54
>
> drivers/led/led_gpio.c   |  8 ---
> include/led.h| 23 +
> 3 files changed, 77 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
>index 2f4d69e..141401d 100644
>--- a/drivers/led/led-uclass.c
>+++ b/drivers/led/led-uclass.c
>@@ -8,6 +8,7 @@
> #include 
> #include 
> #include 
>+#include 
> #include 
> #include 
>
>@@ -63,8 +64,61 @@ int led_set_period(struct udevice *dev, int period_ms)
> }
> #endif
>
>+static int led_post_bind(struct udevice *dev)
>+{
>+  struct led_uc_plat *uc_pdata;
>+  const char *default_state;
>+
>+  uc_pdata = dev_get_uclass_platdata(dev);
>+
>+  /* common optional properties */
>+  uc_pdata->default_state = LED_DEF_NO;
>+  default_state = dev_read_string(dev, "default-state");
>+  if (default_state) {
>+  if (!strncmp(default_state, "on", 2))
>+  uc_pdata->default_state = LED_DEF_ON;
>+  else if (!strncmp(default_state, "off", 3))
>+  uc_pdata->default_state = LED_DEF_OFF;
>+  else if (!strncmp(default_state, "keep", 4))
>+  uc_pdata->default_state = LED_DEF_KEEP;
>+  }
>+
>+  return 0;
>+}
>+
>+int led_default_state(void)
>+{
>+  struct udevice *dev;
>+  struct uclass *uc;
>+  struct led_uc_plat *uc_pdata;
>+  int ret;
>+
>+  ret = uclass_get(UCLASS_LED, );
>+  if (ret)
>+  return ret;
>+  for (uclass_find_first_device(UCLASS_LED, );
>+   dev;
>+   uclass_find_next_device()) {
>+  uc_pdata = dev_get_uclass_platdata(dev);
>+  if (!uc_pdata || uc_pdata->default_state == LED_DEF_NO)
>+  continue;
>+  ret = device_probe(dev);
>+  if (ret)
>+  return ret;
>+  if (uc_pdata->default_state == LED_DEF_ON)
>+  led_set_state(dev, LEDST_ON);
>+  else if (uc_pdata->default_state == LED_DEF_OFF)
>+  led_set_state(dev, LEDST_OFF);
>+  printf("%s: default_state=%d\n",
>+ uc_pdata->label, uc_pdata->default_state);
Do you really want to keep this printf()?
>+  }
>+
>+  return ret;
>+}
>+
> UCLASS_DRIVER(led) = {
>   .id = UCLASS_LED,
>   .name   = "led",
>+  .post_bind  = led_post_bind,
>   .per_device_platdata_auto_alloc_size = sizeof(struct led_uc_plat),
> };
>diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
>index 533587d..93f6b91 100644
>--- a/drivers/led/led_gpio.c
>+++ b/drivers/led/led_gpio.c
>@@ -57,7 +57,6 @@ static int led_gpio_probe(struct udevice *dev)
> {
>   struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
>   struct led_gpio_priv *priv = dev_get_priv(dev);
>-  const char *default_state;
>   int ret;
>
>   /* Ignore the top-level LED node */
>@@ -68,13 +67,6 @@ static int led_gpio_probe(struct udevice *dev)
>   if (ret)
>   return ret;
>
>-  default_state = dev_read_string(dev, "default-state");
>-  if (default_state) {
>-  if (!strncmp(default_state, "on", 2))
>-  gpio_led_set_state(dev, LEDST_ON);
>-  else if (!strncmp(default_state, "off", 3))
>-  gpio_led_set_state(dev, LEDST_OFF);
>-  }
Is it necessary to move this code out of led_gpio_probe()?
If possible I would keep it here and implement led_default_state()
similar to mmc_initialize(->mmc_probe()). Than we could avoid
enum led_def_state_t and the double evaluation of default_state.

>   return 0;
> }
>
>diff --git a/include/led.h b/include/led.h
>index 940b97f..ff45f03 100644
>--- a/include/led.h
>+++ b/include/led.h
>@@ -8,12 +8,27 @@
> #define __LED_H
>
> /**
>+ * enum led_default_state - The initial state of the LED.
>+ * see Documentation/devicetree/bindings/leds/common.txt
>+ */
>+enum led_def_state_t {
>+  LED_DEF_NO,
>+  LED_DEF_ON,
>+  LED_DEF_OFF,
>+  LED_DEF_KEEP
>+};
>+
>+/**
>  * struct led_uc_plat - Platform data the uclass stores about each device
>  *
>  * @label:LED label
>+ * @default_state* - The initial state of the LED.
>+  see 

Re: [U-Boot] [PATCH v3 5/5] sandbox: led: use new function to configure default state

[Patrick Brünn]

>From: Patrick Delaunay [mailto:patrick.delau...@st.com]
>Sent: Dienstag, 24. Juli 2018 10:59
>Subject: [PATCH v3 5/5] sandbox: led: use new function to configure default
>state
>
>Initialize the led with the default state defined in device tree
>in board_init and solve issue with test for led default state.
>
>Reviewed-by: Simon Glass 
>
>
>Signed-off-by: Patrick Delaunay 
>---
>Led default-state is correctly handle in Sandbox, tested with:
>  ./u-boot -d ./arch/sandbox/dts/test.dtb
>  => led list
>  sandbox:red 
>  sandbox:green   
>  sandbox:default_on on
>  sandbox:default_off off
>
>This patch solve "make tests" issue introduced by
>http://patchwork.ozlabs.org/patch/943651/
>
>Changes in v3: None
>Changes in v2:
>  - add sandbox impact and test update
>
> board/sandbox/sandbox.c | 9 +
> common/board_r.c| 3 ++-
> test/dm/led.c   | 3 +++
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
>diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
>index 195f620..66b5f24 100644
>--- a/board/sandbox/sandbox.c
>+++ b/board/sandbox/sandbox.c
>@@ -6,6 +6,7 @@
> #include 
> #include 
> #include 
>+#include 
> #include 
> #include 
> #include 
>@@ -47,6 +48,14 @@ int dram_init(void)
>   return 0;
> }
>
>+int board_init(void)
>+{
>+#ifdef CONFIG_LED
>+  led_default_state();
>+#endif /* CONFIG_LED */

I think you forgot to apply Simons suggestion here, like you did for 4/5

>+  return 0;
>+}
>...

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075



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

Re: [U-Boot] [PATCH v2 2/3] dm: led: auto probe() LEDs with "default-state"

[Patrick Brünn]

>From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>Sent: Dienstag, 3. April 2018 19:53
>To: linux-kernel-dev <linux-kernel-...@beckhoff.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Patrick Brünn
><p.bru...@beckhoff.com>; Ziping Chen <techping.c...@gmail.com>
>Subject: Re: [PATCH v2 2/3] dm: led: auto probe() LEDs with "default-state"
>
>On 3 April 2018 at 15:31,  <linux-kernel-...@beckhoff.com> wrote:
>> From: Patrick Bruenn <p.bru...@beckhoff.com>
>>
...
>>
>> diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
>> index e68d8d3864..d2fe3d5ad5 100644
>> --- a/drivers/led/led_gpio.c
>> +++ b/drivers/led/led_gpio.c
>> @@ -11,6 +11,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -120,6 +121,14 @@ static int led_gpio_bind(struct udevice *parent)
>> return ret;
>> uc_plat = dev_get_uclass_platdata(dev);
>> uc_plat->label = label;
>> +
>> +   if (ofnode_read_string(node, "default-state")) {
>
>Here I think you mean ofnode_read_boot() ?
>
Yes, you are right I will resend a v3 with ofnode_read_bool().

It took me quite a while to understand that "read_bool" means "has_property".

Thanks for your help!
Patrick
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH] dm: mmc: socfpga: call dwmci_probe()

[Patrick Brünn]

>From: Patrick Brünn
>Sent: Donnerstag, 8. März 2018 06:39
>>From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>>Sent: Donnerstag, 8. März 2018 04:57
>>On 03/08/2018 12:12 PM, Marek Vasut wrote:
>>> On 03/08/2018 03:17 AM, Jaehoon Chung wrote:
>>>> On 03/06/2018 05:07 PM, linux-kernel-...@beckhoff.com wrote:
>>>>> From: Patrick Bruenn <p.bru...@beckhoff.com>
>>>>>
>>>>> On a socfpga_cyclone5 based board the SD card, was never powered
>up.
>>For
>>>>> other dw_mmc based SoCs dwmci_probe() is called in the platform
>>specific
>>>>> probe(). It seems this call is missing for socfpga_dw_mmc.
>>>>>
>>>>> With this change DWMCI_PWREN is set by dmwci_init().
>>>>>
>>>>> Signed-off-by: Patrick Bruenn <p.bru...@beckhoff.com>
>>>>
>>>> Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
>>>>
>>>> Will apply this patch before releasing v2018.03.
>>>> (I have a problem about accessing git.denx.de. After fixing my problem,
>>will resend email about applying.)
>>>
>>> DWMMC works on SoCFPGA for me (tested on rc4), so I don't understand
>>what this patch is trying to fix. I'd prefer if you did not hastily apply 
>>this.
>>
>>It's my misunderstanding. When i checked more. I think that Marek is right.
>>Thanks Marek for pointing out.
>>
>Okay, but do you have any hint what I am doing wrong? My board (cx8100 not
>mainline, yet) is based on socfpga_cyclone5. And on my board "
>dwmci_writel(host, DWMCI_PWREN, 1);" is never called, because
>dwmci_init() is never called.
>As far as I can see with CONFIG_DM_MMC enabled dwmci_init() should be
>called by dwmci_probe().
>
>exynos  and rockchip do call dwmci_probe() within
>exynos/rockchip_dwmmc_probe().
>but socfpga_dwmmc_probe() is missing this call. So I looked deeper but found
>no place for socfpga platform to call dwmci_probe() or dwmci_init().
>What am I missing?
>
I got an idea, what might be the difference between my board and your boards.
I suspect you use U-BOOT SPL without CONFIG_DM_MMC set, so
dwmci_init() is called indirectly by mmc_start_init().
Now, when your main U-Boot (with CONFIG_DM_MMC) is launched,
everything is already configured and it isn't necessary to call dwmci_init() 
again.
On my board the Altera MPL is used (and I can't replace it).  Which seems to
disable DWMCI_PWREN before launching U-Boot.
If my assumption is correct, I still think it is a U-Boot bug to assume code 
like in
dwmci_init() was already run before U-Boot gets in control.
Besides exynos/rockchip_dw_mmc don't have this precondition requirement.

Please take your time to look deeper into this issue, before deciding anything.
I don't think we need to rush this into the next release, as normal mainline
boards are "accidently" not affected.

Thanks and regards,
Patrick

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH] dm: mmc: socfpga: call dwmci_probe()

[Patrick Brünn]

>From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
>Sent: Donnerstag, 8. März 2018 04:57
>On 03/08/2018 12:12 PM, Marek Vasut wrote:
>> On 03/08/2018 03:17 AM, Jaehoon Chung wrote:
>>> On 03/06/2018 05:07 PM, linux-kernel-...@beckhoff.com wrote:
 From: Patrick Bruenn 

 On a socfpga_cyclone5 based board the SD card, was never powered up.
>For
 other dw_mmc based SoCs dwmci_probe() is called in the platform
>specific
 probe(). It seems this call is missing for socfpga_dw_mmc.

 With this change DWMCI_PWREN is set by dmwci_init().

 Signed-off-by: Patrick Bruenn 
>>>
>>> Reviewed-by: Jaehoon Chung 
>>>
>>> Will apply this patch before releasing v2018.03.
>>> (I have a problem about accessing git.denx.de. After fixing my problem,
>will resend email about applying.)
>>
>> DWMMC works on SoCFPGA for me (tested on rc4), so I don't understand
>what this patch is trying to fix. I'd prefer if you did not hastily apply this.
>
>It's my misunderstanding. When i checked more. I think that Marek is right.
>Thanks Marek for pointing out.
>
Okay, but do you have any hint what I am doing wrong? My board (cx8100 not 
mainline, yet) is based on socfpga_cyclone5. And on my board " 
dwmci_writel(host, DWMCI_PWREN, 1);" is never called, because dwmci_init() is 
never called.
As far as I can see with CONFIG_DM_MMC enabled dwmci_init() should be called by 
dwmci_probe().

exynos  and rockchip do call dwmci_probe() within exynos/rockchip_dwmmc_probe().
but socfpga_dwmmc_probe() is missing this call. So I looked deeper but found no 
place for socfpga platform to call dwmci_probe() or dwmci_init().
What am I missing?

Maybe this diff helps:
u-boot$ diff configs/socfpga_cx8100_defconfig configs/socfpga_cyclone5_defconfig
2d1
< CONFIG_API=y
6c5
< CONFIG_TARGET_SOCFPGA_CX8100=y
---
> CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
8c7,8
< CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_cx8100"
---
> CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_socdk"
> CONFIG_DISTRO_DEFAULTS=y
9a10
> # CONFIG_USE_BOOTCOMMAND is not set
13c14
< CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_cx8100.dtb"
---
> CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_socdk.dtb"
16d16
< CONFIG_BOARD_EARLY_INIT_F=y
20,21d19
< CONFIG_HUSH_PARSER=y
< CONFIG_CMD_BOOTZ=y
29d26
< CONFIG_CMD_PART=y
34,37d30
< CONFIG_CMD_DHCP=y
< CONFIG_CMD_PXE=y
< CONFIG_CMD_MII=y
< CONFIG_CMD_PING=y
39d31
< CONFIG_CMD_EXT4=y
41,42d32
< CONFIG_CMD_FAT=y
< CONFIG_CMD_FS_GENERIC=y
54,56d43
< CONFIG_CMD_LED=y
< CONFIG_LED=y
< CONFIG_LED_GPIO=y
60a48
> CONFIG_SPI_FLASH_MACRONIX=y

Thanks for your time and patience,
Patrick

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] fs/fat: device not booting since conversion to dir iterators

[Patrick Brünn]

Hi Simon,

>From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>Sent: Dienstag, 19. Dezember 2017 16:42
>Hi Patrick,
>
>On 13 December 2017 at 03:15, Patrick Brünn <p.bru...@beckhoff.com>
>wrote:
>>>From: Patrick Brünn
>>>Sent: Donnerstag, 30. November 2017 12:22
>>>
>>>Since commit 8eafae209c35932d9a6560809c55ee4641534236
>>>my mx53cx9020_defconfig stopped booting.
>>>...
>>>It seems important to read into do_fat_read_at_block. If I
>>>allocate a temporary buffer and read into that one, I still
>>>can't boot. That seems strange to me as, I couldn't find
>>>any uninitialized access to do_fat_read_at_block anywhere.
>>>
>> I believe I finally tracked it down to the linker.
>>
>> Without accessing do_fat_read_at_block within fat.c, I find
>> .bss. do_fat_read_at_block as "discarded input section" in
>> my u-boot.map
>>
>> With a patch like this:
>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
>> index d16883fa10..8e70fdbc8d 100644
>> --- a/fs/fat/fat.c
>> +++ b/fs/fat/fat.c
>> @@ -1157,6 +1157,7 @@ int fat_opendir(const char *filename, struct
>fs_dir_stream **dirsp)
>> return -ENOMEM;
>> memset(dir, 0, sizeof(*dir));
>>
>> +   if (do_fat_read_at_block[0])
>> +   printf("value doesn't matter, the access is important\n");
>> +
>> ret = fat_itr_root(>itr, >fsdata);
>> if (ret)
>> goto fail_free_dir;
>>
>> The section isn't discarded and my board boots again.
>>
>>
>> Another workaround would be:
>> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
>> index 124b44a337..02f61fcc3c 100644
>> --- a/arch/arm/config.mk
>> +++ b/arch/arm/config.mk
>> @@ -17,7 +17,7 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-
>sections -fdata-sections
>>  CFLAGS_EFI := -fpic -fshort-wchar
>>
>>  LDFLAGS_FINAL += --gc-sections
>> -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
>> +PLATFORM_RELFLAGS += -ffunction-sections \
>>  -fno-common -ffixed-r9
>>  PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
>>$(call cc-option,-mshort-load-bytes,$(call 
>> cc-option,-malignment-traps,))
>>
>> Or a hack like:
>> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
>> index 37d4c605ac..b916cbc733 100644
>> --- a/arch/arm/cpu/u-boot.lds
>> +++ b/arch/arm/cpu/u-boot.lds
>> @@ -219,6 +219,7 @@ SECTIONS
>> }
>>
>> .bss_end __bss_limit (OVERLAY) : {
>> +   KEEP(*(.bss.do_fat_read_at_block));
>> KEEP(*(.__bss_end));
>> }
>>
>> I also tried to mark do_fat_read_at_block as:
>> volatile, __used and/or __attribute__((externally_visible))
>>
>> This doesn't help.
>>
>> Moving it into fat_write.c doesn't help either(with/without static)
>>
>> My toolchain is:
>> ~/u-boot$ arm-linux-gnueabihf-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=arm-linux-gnueabihf-gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/6/lto-
>wrapper
>> Target: arm-linux-gnueabihf
>> Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' --
>with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-
>languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-
>suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --
>without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
>--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-
>libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-
>object --disable-libitm --disable-libquadmath --enable-plugin --enable-
>default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
>--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-
>cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-
>6-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-
>cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
>--disable-libgcj --with-target-system-zlib --enable-objc-gc=auto --enable-
>multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16
>--with-float=hard --with-mode=thumb --enable-checking=release --
>build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-
>gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-
>linux-gnueabihf/include
>> Thread model: posix

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 13:30
>On 12/18/2017 01:16 PM, Patrick Brünn wrote:
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Montag, 18. Dezember 2017 12:52
>>> On 12/18/2017 12:40 PM, Patrick Brünn wrote:
[...]
>>> btw do you use SPL ? If not, you should ...
>> I will read more about SPL. Until now, I thought I will only benefit,
>> if my initial boot media is limited in size. As we boot from sdcard,
>> that wasn't a problem to store 360k u-boot.
>
>The other is that you can ie. skip the whole u-boot altogether and boot
>linux directly.
>
Okay, I will try that.
>I wonder if it would be better to keep the static variable and avoid
>calling the get_ram_size() twice, it can save some CPU cycles. Besides
>that, thanks for the explanation/discussion !1
>
The pleasure was all mine. I will test SPL on my board and in case that's 
working I think it still makes sense to move our common code into one file. Is 
arch/arm/mach-imx/mx53_dram.c the best location for it?
At first I tried board/freescale/common/ but in that case I needed to use ugly 
relative pathes in the Makefiles "../../"

Regards, Patrick

---
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Patrick Brünn
>Sent: Dienstag, 19. Dezember 2017 05:29
>>From: Marek Vasut [mailto:ma...@denx.de]
>>Sent: Montag, 18. Dezember 2017 13:30
>>On 12/18/2017 01:16 PM, Patrick Brünn wrote:
>>>> From: Marek Vasut [mailto:ma...@denx.de]
>>>> Sent: Montag, 18. Dezember 2017 12:52
>>>> On 12/18/2017 12:40 PM, Patrick Brünn wrote:
>[...]
>>>> btw do you use SPL ? If not, you should ...
>>> I will read more about SPL. Until now, I thought I will only benefit,
>>> if my initial boot media is limited in size. As we boot from sdcard,
>>> that wasn't a problem to store 360k u-boot.
>>
>>The other is that you can ie. skip the whole u-boot altogether and boot
>>linux directly.
>>
>Okay, I will try that.
>>I wonder if it would be better to keep the static variable and avoid
>>calling the get_ram_size() twice, it can save some CPU cycles. Besides
>>that, thanks for the explanation/discussion !1
>>
>The pleasure was all mine. I will test SPL on my board and in case that's
>working I think it still makes sense to move our common code into one file. Is
>arch/arm/mach-imx/mx53_dram.c the best location for it?
>At first I tried board/freescale/common/ but in that case I needed to use ugly
>relative pathes in the Makefiles "../../"
I spend a few hours this morning to experiment with SPL. From what I saw it
would require some additional patches to enable SPL_MMC for imx53 and
a few more changes to our sdcard layout (FAT vs. EXT4). Seeing all these
additional #ifdefs to consider I just don't have a good feeling to port that 
adhoc
for our board.
Directly booting Linux still sounds tempting, but for the moment I cannot spend
more effort into SPL for mx53cx9020. I will put that on my todo list. But for 
now
I would like to concentrate to get mainline boot on mx53cx9020, again.

I would suggest:
1. I keep m53evk.c untouched for now.
2a. Either patch both mx53cx9020 and mx53loco to avoid static mx53_dram_size,
   and have the shared code in arch/arm/mach-imx/mx53_dram.c
2b. Or patch only board/beckhoff/mx53cx9020/mx53cx9020.c

Fabio, what do you prefer?

Regards, Patrick

---
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 11:57
>On 12/18/2017 11:47 AM, Patrick Brünn wrote:
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Montag, 18. Dezember 2017 10:17
>>> On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>>>> From: Patrick Bruenn <p.bru...@beckhoff.com>
>>>>
>>>> Static variables are not available during board_init_f().
>>>
>>> They are, since the board runs from RAM at that point already.
>>>
>> From reading the README and common/board_f.c I got the impression,
>> that dram_init() is called before it's save to access mx53_dram_size.
>> And as that change seemed to cure the strange behavior I described
>> in [1] and [2], I prepared a patch for my board, which ended up to be
>> requested for m53evk and mx53loco, too.
>
>Technically yes, board_init_f means it runs from FLASH and has no or
>minimal storage available. On the MX53 with SPL, it's running from RAM
>so it's safe to use static variables too.
>
Thank's for your explanation.

>>>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>>>> dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
>>>> multiple calls to get_ram_size().
>>>>
>>>> Reused dram initialization functions from arch/arm/mach-
>>> imx/mx5/mx53_dram.c
>>>>
>>>> Signed-off-by: Patrick Bruenn <p.bru...@beckhoff.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v2: None
>>>>
>>>>
>>>> Only compile tested with make m53evk_defconfig
>>>
>>> Are you sure this patch retains the original functionality ? Note the
>>> warning ...
>>
>> Effectively it changes:
>>  -  return mx53_dram_size[0];
>> +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>>
>> So, yes I am convinced that get_effective_memsize() still returns only the
>size
>> of the first dram bank.
>
>I suspect that will fails on M53 due to it's split-bank configuration.
>The board has two DRAM banks with a hole between them.
>
This is how mx53_dram_size was initialized on m53 before that patch:
-   mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
-   mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);

So to me that's, absolutely the same. With the only difference, that 
get_ram_size(bank0)
is called multiple times, now.
>> However, I would be fine with just keeping the changes to my board
>(cx9020).
>> And if anyone has a better idea of what might be the root cause of [1] and
>[2],
>> I would absolute appreciate any input to that.
>
>If your board also has two DRAM banks with a hole between them and you
>can test if this works fine, then I'm OK with this change.
>
Yes, cx9020 uses two 512MB banks with 1GB between PHYS_SDRAM_1/2, too.

>> Best regards and thanks in advance for any feedback,
>> Patrick
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2017-November/313214.html
>> [2] https://lists.denx.de/pipermail/u-boot/2017-December/314480.html
>>
>> ---
>> Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans
>Beckhoff
>> Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
>>
>>
>
>
>--
>Best regards,
>Marek Vasut
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH] arm: imx: cx9020: remove usage of mx53_dram_size

[Patrick Brünn]

Hi Lothar,
>From: Lothar Waßmann [mailto:l...@karo-electronics.de]
>Sent: Freitag, 15. Dezember 2017 15:02
>
>Hi,
>
>On Fri, 15 Dec 2017 13:56:15 +0100 linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> Global variables are not available during board_init_f().
>>
>s/Global/static/
>
I fixed that for v2. Unfortunately everywhere but in the cover letter :-(.

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 12:52
>On 12/18/2017 12:40 PM, Patrick Brünn wrote:
>>> From: Marek Vasut [mailto:ma...@denx.de]
>>> Sent: Montag, 18. Dezember 2017 11:57
>>> On 12/18/2017 11:47 AM, Patrick Brünn wrote:
>>>>> From: Marek Vasut [mailto:ma...@denx.de]
>>>>> Sent: Montag, 18. Dezember 2017 10:17
>>>>> On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>>>>>> From: Patrick Bruenn <p.bru...@beckhoff.com>
>>>>>>
>>>>>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>>>>>> dram_init(), dram_init_banksize() and get_effective_memsize() to
>avoid
>>>>>> multiple calls to get_ram_size().
>>>>>>
>>>>>> Reused dram initialization functions from arch/arm/mach-
>>>>> imx/mx5/mx53_dram.c
>>>>>>
>>>>>> Signed-off-by: Patrick Bruenn <p.bru...@beckhoff.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2: None
>>>>>>
>>>>>>
>>>>>> Only compile tested with make m53evk_defconfig
>>>>>
>>>>> Are you sure this patch retains the original functionality ? Note the
>>>>> warning ...
>>>>
>>>> Effectively it changes:
>>>>  -  return mx53_dram_size[0];
>>>> +   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>>>>
>>>> So, yes I am convinced that get_effective_memsize() still returns only the
>>> size
>>>> of the first dram bank.
>>>
>>> I suspect that will fails on M53 due to it's split-bank configuration.
>>> The board has two DRAM banks with a hole between them.
>>>
>> This is how mx53_dram_size was initialized on m53 before that patch:
>> -   mx53_dram_size[0] = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
>> -   mx53_dram_size[1] = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
>>
>> So to me that's, absolutely the same. With the only difference, that
>get_ram_size(bank0)
>> is called multiple times, now.
>
>The get_ram_size() above is called for two different bank (addresses),
>not for bank0 twice. Maybe I'm missing something.
>
>btw where's the patch adding mx53_dram.c ? I don't see it in mainline yet.
>
It's #2 of this series:
https://lists.denx.de/pipermail/u-boot/2017-December/314742.html

>>>> However, I would be fine with just keeping the changes to my board
>>> (cx9020).
>>>> And if anyone has a better idea of what might be the root cause of [1]
>and
>>> [2],
>>>> I would absolute appreciate any input to that.
>>>
>>> If your board also has two DRAM banks with a hole between them and you
>>> can test if this works fine, then I'm OK with this change.
>>>
>> Yes, cx9020 uses two 512MB banks with 1GB between PHYS_SDRAM_1/2,
>too.
>
>Then that should be the same situation. Can you share "bdinfo" from that
>board of yours?
>
=> bdinfo
arch_number = 0x
boot_params = 0x7100
DRAM bank   = 0x
-> start= 0x7000
-> size = 0x2000
DRAM bank   = 0x0001
-> start= 0xB000
-> size = 0x2000
eth0name= FEC
ethaddr = 00:01:05:23:87:85
current eth = FEC
ip_addr = 
baudrate= 115200 bps
TLB addr= 0x8FFF
relocaddr   = 0x8FF8B000
reloc off   = 0x1878B000
irq_sp  = 0x8F586960
sp start= 0x8F586950
FB base = 0x8F58C7C0
Early malloc usage: 134 / 400
fdt_blob = 8f586978

>btw do you use SPL ? If not, you should ...
I will read more about SPL. Until now, I thought I will only benefit,
if my initial boot media is limited in size. As we boot from sdcard,
that wasn't a problem to store 360k u-boot.

Regards,
Patrick
---
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size

[Patrick Brünn]

>From: Marek Vasut [mailto:ma...@denx.de]
>Sent: Montag, 18. Dezember 2017 10:17
>On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> Static variables are not available during board_init_f().
>
>They are, since the board runs from RAM at that point already.
>
From reading the README and common/board_f.c I got the impression,
that dram_init() is called before it's save to access mx53_dram_size.
And as that change seemed to cure the strange behavior I described
in [1] and [2], I prepared a patch for my board, which ended up to be
requested for m53evk and mx53loco, too.

>> 'static uint32_t mx53_dram_size[2];' was used in board specific
>> dram_init(), dram_init_banksize() and get_effective_memsize() to avoid
>> multiple calls to get_ram_size().
>>
>> Reused dram initialization functions from arch/arm/mach-
>imx/mx5/mx53_dram.c
>>
>> Signed-off-by: Patrick Bruenn 
>>
>> ---
>>
>> Changes in v2: None
>>
>>
>> Only compile tested with make m53evk_defconfig
>
>Are you sure this patch retains the original functionality ? Note the
>warning ...

Effectively it changes:
 -  return mx53_dram_size[0];
+   return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);

So, yes I am convinced that get_effective_memsize() still returns only the size
of the first dram bank.
However, I would be fine with just keeping the changes to my board (cx9020).
And if anyone has a better idea of what might be the root cause of [1] and [2],
I would absolute appreciate any input to that.

Best regards and thanks in advance for any feedback,
Patrick

[1] https://lists.denx.de/pipermail/u-boot/2017-November/313214.html
[2] https://lists.denx.de/pipermail/u-boot/2017-December/314480.html

---
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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

Re: [U-Boot] fs/fat: device not booting since conversion to dir iterators

[Patrick Brünn]

>From: Patrick Brünn
>Sent: Donnerstag, 30. November 2017 12:22
>
>Since commit 8eafae209c35932d9a6560809c55ee4641534236
>my mx53cx9020_defconfig stopped booting.
>...
>It seems important to read into do_fat_read_at_block. If I
>allocate a temporary buffer and read into that one, I still
>can't boot. That seems strange to me as, I couldn't find
>any uninitialized access to do_fat_read_at_block anywhere.
>
I believe I finally tracked it down to the linker.

Without accessing do_fat_read_at_block within fat.c, I find
.bss. do_fat_read_at_block as "discarded input section" in
my u-boot.map

With a patch like this:
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index d16883fa10..8e70fdbc8d 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1157,6 +1157,7 @@ int fat_opendir(const char *filename, struct 
fs_dir_stream **dirsp)
return -ENOMEM;
memset(dir, 0, sizeof(*dir));

+   if (do_fat_read_at_block[0])
+   printf("value doesn't matter, the access is important\n");
+
ret = fat_itr_root(>itr, >fsdata);
if (ret)
goto fail_free_dir;

The section isn't discarded and my board boots again.


Another workaround would be:
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 124b44a337..02f61fcc3c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -17,7 +17,7 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections 
-fdata-sections
 CFLAGS_EFI := -fpic -fshort-wchar

 LDFLAGS_FINAL += --gc-sections
-PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
+PLATFORM_RELFLAGS += -ffunction-sections \
 -fno-common -ffixed-r9
 PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
   $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))

Or a hack like:
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 37d4c605ac..b916cbc733 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -219,6 +219,7 @@ SECTIONS
}

.bss_end __bss_limit (OVERLAY) : {
+   KEEP(*(.bss.do_fat_read_at_block));
KEEP(*(.__bss_end));
}

I also tried to mark do_fat_read_at_block as:
volatile, __used and/or __attribute__((externally_visible))

This doesn't help.

Moving it into fat_write.c doesn't help either(with/without static)

My toolchain is:
~/u-boot$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm 
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross/jre 
--enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf-cross 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf-cross 
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--disable-libgcj --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a 
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- 
--includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)

~/u-boot$ arm-linux-gnueabihf-ld -v
GNU ld (GNU Binutils for Debian) 2.28


Does anyone have an idea what else I can try to prevent my linker from removing
do_fat_read_at_block?

Regards,
Patrick
--
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075



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

[U-Boot] fs/fat: device not booting since conversion to dir iterators

[Patrick Brünn]

Since commit 8eafae209c35932d9a6560809c55ee4641534236
my mx53cx9020_defconfig stopped booting.
I could "fix" that commit with this patch:
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index bbba7947ee..b99ec85097 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1035,6 +1035,9 @@ int file_fat_ls(const char *dir)
int files = 0, dirs = 0;
int ret;

+   //fix_fat
+   disk_read(0, PREFETCH_BLOCKS, do_fat_read_at_block);
+
ret = fat_itr_root(itr, );
if (ret)
return ret;

Since then file_fat_ls() has been moved/replaced with
fs_ls_generic(). So I had to adjust that workaround.
And added the dummy disk_read() into fs_opendir() callback:
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fe78439cf..be6eaeb68e 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1155,6 +1155,7 @@ int fat_opendir(const char *filename, struct 
fs_dir_stream **dirsp)
if (!dir)
return -ENOMEM;

+   disk_read(0, PREFETCH_BLOCKS, do_fat_read_at_block);
ret = fat_itr_root(>itr, >fsdata);
if (ret)
goto fail_free_dir;

It seems important to read into do_fat_read_at_block. If I
allocate a temporary buffer and read into that one, I still
can't boot. That seems strange to me as, I couldn't find
any uninitialized access to do_fat_read_at_block anywhere.

Another workaround is to disable CMD_FAT:
diff --git a/configs/mx53cx9020_defconfig b/configs/mx53cx9020_defconfig
index b704f32fbf..2d560aabc1 100644
--- a/configs/mx53cx9020_defconfig
+++ b/configs/mx53cx9020_defconfig
@@ -15,7 +15,7 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
-CONFIG_CMD_FAT=y
+CONFIG_DOS_PARTITION=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_MMC=y


My device is powered by an i.MX53 and configured to
load u-boot from sdcard. That sdcard doesn't have any
FAT partition on it:
Disk /dev/mmcblk0: 471 MiB, 493879296 bytes, 964608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbbd9d8f6

Device Boot StartEnd Sectors  Size Id Type
/dev/mmcblk0p1 * 2048 489471  487424  238M 83 Linux

Maybe my sdcard layout is broken, too. If you need any
additional info or have any idea whatelse I could try,
please let me know.

Thanks in advance,
Patrick
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075



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

Re: [U-Boot] [PATCH v4] arm: imx: add i.MX53 Beckhoff CX9020 Embedded PC

[Patrick Brünn]

Hi Stefano,
>
>On 04/11/2016 11:57, linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> Add CX9020 board based on mx53loco.
>> Add simplified imx53 base device tree from kernel v4.8-rc8, to reuse
>> serial_mxc with DTE and prepare for device tree migration of other
>> functions and imx53 devices.
>>
>> The CX9020 differs from i.MX53 Quick Start Board by:
>> - use uart2 instead of uart1
>> - DVI-D connector instead of VGA
>> - no audio
>> - CCAT FPGA connected to emi
>> - enable rtc
>>
>> Signed-off-by: Patrick Bruenn 
>>
>> ---
>> Version 4 should address most of the issues Stefan, Jagan and Simon
>pointed out.
>
>There is still some small issues that avoid the patches to be merged.
>Board cannot be built due to missing CONFIG_:
>
>   arm:  +   mx53cx9020
>+drivers/video/cfb_console.c: In function 'cfg_video_init':
>+drivers/video/cfb_console.c:2022:23: error:
>'CONFIG_SYS_CONSOLE_FG_COL'
>undeclared (first use in this function)
>+drivers/video/cfb_console.c:2022:23: note: each undeclared identifier
>is reported only once for each function it appears in
>+drivers/video/cfb_console.c:2025:23: error:
>'CONFIG_SYS_CONSOLE_BG_COL'
>undeclared (first use in this function)
>+make[3]: *** [drivers/video/cfb_console.o] Error 1
>+make[2]: *** [drivers/video] Error 2
>+make[1]: *** [drivers] Error 2
>
>
>I have checked why and I could fix with the following patch:
>
Thank you for your effort!
>
>---
> configs/mx53cx9020_defconfig | 6 ++
> include/configs/mx53cx9020.h | 4 
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
>diff --git a/configs/mx53cx9020_defconfig b/configs/mx53cx9020_defconfig
>index 3603907..6954cf5 100644
>--- a/configs/mx53cx9020_defconfig
>+++ b/configs/mx53cx9020_defconfig
>@@ -11,6 +11,7 @@ CONFIG_CMD_BOOTZ=y
> CONFIG_CMD_MMC=y
> #CONFIG_CMD_USB=y
> # CONFIG_CMD_SETEXPR is not set
>+CONFIG_VIDEO=y
> CONFIG_CMD_DHCP=y
> CONFIG_CMD_MII=y
> CONFIG_CMD_PING=y
>@@ -27,3 +28,8 @@ CONFIG_FPGA_CYCLON2=y
> CONFIG_CMD_FPGA=y
> CONFIG_PINCTRL=y
> CONFIG_PINCTRL_IMX5=y
>+# CONFIG_VIDEO_SW_CURSOR is not set
>+CONFIG_CFB_CONSOLE=y
>+CONFIG_VGA_AS_SINGLE_DEVICE=y
>+CONFIG_SYS_CONSOLE_BG_COL=0x00
>+CONFIG_SYS_CONSOLE_FG_COL=0xa0
>diff --git a/include/configs/mx53cx9020.h b/include/configs/mx53cx9020.h
>index ac8b2a2..87c75d4 100644
>--- a/include/configs/mx53cx9020.h
>+++ b/include/configs/mx53cx9020.h
>@@ -187,11 +187,7 @@
>
> /* Framebuffer and LCD */
> #define CONFIG_PREBOOT
>-#define CONFIG_VIDEO
> #define CONFIG_VIDEO_IPUV3
>-#define CONFIG_CFB_CONSOLE
>-#define CONFIG_VGA_AS_SINGLE_DEVICE
>-#define CONFIG_SYS_CONSOLE_IS_IN_ENV
> #define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
> #define CONFIG_VIDEO_BMP_RLE8
> #define CONFIG_SPLASH_SCREEN
>--
>2.7.4
>
>Now on you: if you agree, I can integrate this fix into your patch and
>merge it into the u-boot-imx tree. If you disagree, please check it and
>send an update version, thanks !

Agreed!
I applied it and did a test run. Everything works as it is supposed to be.

Best regards,
Patrick

Signed-off-by: Patrick Bruenn 

>
>Best regards,
>Stefano Babic
>
>--
>===
>==
>DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>===
>==

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075



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

Re: [U-Boot] [PATCH v2] arm: imx: add i.MX53 Beckhoff CX9020 Embedded PC

[Patrick Brünn]

>From: Stefano Babic [mailto:sba...@denx.de]
>Sent: Montag, 17. Oktober 2016 13:27
Hi Stefano and Jagan,
>
>On 17/10/2016 11:19, Jagan Teki wrote:
>> On Fri, Oct 7, 2016 at 9:44 PM,   wrote:
>>> From: Patrick Bruenn 
>>>
>>> Add CX9020 board based on mx53loco.
>>> Add simplified imx53 base device tree from kernel v4.8-rc8, to reuse
>>> serial_mxc with DTE and prepare for device tree migration of other
>>> functions and imx53 devices.
>>>
>>> The CX9020 differs from i.MX53 Quick Start Board by:
>>> - use uart2 instead of uart1
>>> - DVI-D connector instead of VGA
>>> - no audio
>>> - CCAT FPGA connected to emi
>>> - enable rtc
>>>
>>> Signed-off-by: Patrick Bruenn 
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - remove #include  from mx53cx9020.c
>>> - remove obsolete CONFIG_CMD_CCAT from mx53cx9020.h
>>>
>>>  arch/arm/Kconfig |   7 +
>>>  arch/arm/dts/Makefile|   2 +
>>>  arch/arm/dts/imx53-cx9020.dts|  26 ++
>>>  arch/arm/dts/imx53.dtsi  |  41 ++
>>>  board/beckhoff/mx53cx9020/Kconfig|  15 +
>>>  board/beckhoff/mx53cx9020/MAINTAINERS|   6 +
>>>  board/beckhoff/mx53cx9020/Makefile   |   9 +
>>>  board/beckhoff/mx53cx9020/imximage.cfg   |  82 
>>>  board/beckhoff/mx53cx9020/mx53cx9020.c   | 563
>+++
>>>  board/beckhoff/mx53cx9020/mx53cx9020_video.c |  83 
>>>  configs/mx53cx9020_defconfig |  19 +
>>>  include/configs/mx53cx9020.h | 208 ++
>>>  12 files changed, 1061 insertions(+)
>>>  create mode 100644 arch/arm/dts/imx53-cx9020.dts
>>>  create mode 100644 arch/arm/dts/imx53.dtsi
>>>  create mode 100644 board/beckhoff/mx53cx9020/Kconfig
>>>  create mode 100644 board/beckhoff/mx53cx9020/MAINTAINERS
>>>  create mode 100644 board/beckhoff/mx53cx9020/Makefile
>>>  create mode 100644 board/beckhoff/mx53cx9020/imximage.cfg
>>>  create mode 100644 board/beckhoff/mx53cx9020/mx53cx9020.c
>>>  create mode 100644 board/beckhoff/mx53cx9020/mx53cx9020_video.c
>>>  create mode 100644 configs/mx53cx9020_defconfig
>>>  create mode 100644 include/configs/mx53cx9020.h
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index f55d5b2..ece610a 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -480,6 +480,12 @@ config TARGET_MX53LOCO
>>> bool "Support mx53loco"
>>> select CPU_V7
>>>
>>> +config TARGET_MX53CX9020
>>> +   bool "Support mx53cx9020"
>>> +   select CPU_V7
>>> +   select DM
>>> +   select DM_SERIAL
>>> +
>>>  config TARGET_MX53SMD
>>> bool "Support mx53smd"
>>> select CPU_V7
>>> @@ -965,6 +971,7 @@ source "board/freescale/mx51evk/Kconfig"
>>>  source "board/freescale/mx53ard/Kconfig"
>>>  source "board/freescale/mx53evk/Kconfig"
>>>  source "board/freescale/mx53loco/Kconfig"
>>> +source "board/beckhoff/mx53cx9020/Kconfig"
>>>  source "board/freescale/mx53smd/Kconfig"
>>>  source "board/freescale/s32v234evb/Kconfig"
>>>  source "board/freescale/vf610twr/Kconfig"
>>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>>> index 04d47e7..3f753ba 100644
>>> --- a/arch/arm/dts/Makefile
>>> +++ b/arch/arm/dts/Makefile
>>> @@ -286,6 +286,8 @@ dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \
>>> imx6dl-icore.dtb \
>>> imx6q-icore.dtb
>>>
>>> +dtb-$(CONFIG_TARGET_MX53CX9020) += imx53-cx9020.dtb
>>
>> This should be MX arch config entry, not the target one.
>
>Yes, thanks Jagan. Please check inside Makefile. You could use
>CONFIG_MX53 for this.
>
I will fix this in v3 (together with the removed CONFIG_DISPLAY_BOARDINFO)
>>> +int board_mmc_init(bd_t *bis)
>>> +{
>>> +   static const iomux_v3_cfg_t sd1_pads[] = {
>>> +   NEW_PAD_CTRL(MX53_PAD_SD1_CMD__ESDHC1_CMD,
>SD_CMD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD1_CLK__ESDHC1_CLK,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD1_DATA0__ESDHC1_DAT0,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD1_DATA1__ESDHC1_DAT1,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD1_DATA2__ESDHC1_DAT2,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD1_DATA3__ESDHC1_DAT3,
>SD_PAD_CTRL),
>>> +   MX53_PAD_GPIO_1__GPIO1_1,
>>> +   };
>>> +
>>> +   static const iomux_v3_cfg_t sd2_pads[] = {
>>> +   NEW_PAD_CTRL(MX53_PAD_SD2_CMD__ESDHC2_CMD,
>SD_CMD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD2_CLK__ESDHC2_CLK,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD2_DATA0__ESDHC2_DAT0,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD2_DATA1__ESDHC2_DAT1,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD2_DATA2__ESDHC2_DAT2,
>SD_PAD_CTRL),
>>> +   NEW_PAD_CTRL(MX53_PAD_SD2_DATA3__ESDHC2_DAT3,
>SD_PAD_CTRL),
>>> +   MX53_PAD_GPIO_4__GPIO1_4,
>>> +   };
>>
>> Since, it's have dts 

Re: [U-Boot] [PATCH v2] arm: imx: add i.MX53 Beckhoff CX9020 Embedded PC

[Patrick Brünn]

>From: Stefano Babic [mailto:sba...@denx.de]
>Sent: Montag, 17. Oktober 2016 09:32
>
>On 07/10/2016 18:14, linux-kernel-...@beckhoff.com wrote:
>> From: Patrick Bruenn 
>>
>> Add CX9020 board based on mx53loco.
>> Add simplified imx53 base device tree from kernel v4.8-rc8, to reuse
>> serial_mxc with DTE and prepare for device tree migration of other
>> functions and imx53 devices.
>>
>> The CX9020 differs from i.MX53 Quick Start Board by:
>> - use uart2 instead of uart1
>> - DVI-D connector instead of VGA
>> - no audio
>> - CCAT FPGA connected to emi
>> - enable rtc
>>
>> Signed-off-by: Patrick Bruenn 
>>
>> ---
>
>> +
>> +#ifndef __CONFIG_H
>> +#define __CONFIG_H
>> +
>> +#define CONFIG_MX53
>> +
>> +#define CONFIG_DISPLAY_BOARDINFO
>> +
>
>This results to be defined twice (default is enabled, resulting in a
>warning by building the board. If you agree, I fix it myself before
>applying.
>
Sure I am fine with that.
Thanks and regards,
Patrick

Signed-off-by: Patrick Bruenn 
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075



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

Re: [U-Boot] [PATCH] arm: imx: add i.MX53 Beckhoff CX9020 Embedded PC

[Patrick Brünn]

>From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>Sent: Mittwoch, 28. September 2016 19:52
>Subject: Re: [PATCH] arm: imx: add i.MX53 Beckhoff CX9020 Embedded PC
>
>Hi,
Hi Simon,
thanks for the fast feedback.
>
>On 28 September 2016 at 09:46,   wrote:
>> From: Patrick Bruenn 
>>
>> Add CX9020 board based on mx53loco.
>> Add simplified imx53 base device tree from kernel v4.8-rc8, to reuse
>> serial_mxc with DTE and prepare for device tree migration of other
>> functions and imx53 devices.
>>
>> The CX9020 differs from i.MX53 Quick Start Board by:
>> - use uart2 instead of uart1
>> - DVI-D connector instead of VGA
>> - no audio
>> - CCAT FPGA connected to emi
>> - enable rtc
>>
>> Signed-off-by: Patrick Bruenn 
>>
>> ---
>>
>>  arch/arm/Kconfig |   7 +
>>  arch/arm/dts/Makefile|   2 +
>>  arch/arm/dts/imx53-cx9020.dts|  26 ++
>>  arch/arm/dts/imx53.dtsi  |  41 ++
>>  board/beckhoff/mx53cx9020/Kconfig|  15 +
>>  board/beckhoff/mx53cx9020/MAINTAINERS|   6 +
>>  board/beckhoff/mx53cx9020/Makefile   |   9 +
>>  board/beckhoff/mx53cx9020/imximage.cfg   |  82 
>>  board/beckhoff/mx53cx9020/mx53cx9020.c   | 564
>+++
>>  board/beckhoff/mx53cx9020/mx53cx9020_video.c |  83 
>>  configs/mx53cx9020_defconfig |  19 +
>>  include/configs/mx53cx9020.h | 211 ++
>>  12 files changed, 1065 insertions(+)
>>  create mode 100644 arch/arm/dts/imx53-cx9020.dts
>>  create mode 100644 arch/arm/dts/imx53.dtsi
>>  create mode 100644 board/beckhoff/mx53cx9020/Kconfig
>>  create mode 100644 board/beckhoff/mx53cx9020/MAINTAINERS
>>  create mode 100644 board/beckhoff/mx53cx9020/Makefile
>>  create mode 100644 board/beckhoff/mx53cx9020/imximage.cfg
>>  create mode 100644 board/beckhoff/mx53cx9020/mx53cx9020.c
>>  create mode 100644 board/beckhoff/mx53cx9020/mx53cx9020_video.c
>>  create mode 100644 configs/mx53cx9020_defconfig
>>  create mode 100644 include/configs/mx53cx9020.h
>
>There are a few things here that should use driver model:
>
>- Video
>- LED GPIOs
>- Pinctrl
>
>Is that future work?
>
Yes. As this is my first patch, I tried to keep it as less invasive as possible.
Pinctrl would be the first thing on my list, but it looked like I would have
to add something similar to pinctrl-imx6/7.c for imx5 so I didn't include it
into this patch.
Same thing for imx53.dtsi. Right now, it is a stripped down (but diffable)
version from kernel.org. My plan was to gradually migrate parts of that
dtsi to u-boot, when I use them.
Is that compliant with u-boot development style?
Would you prefer a series with all the imx5 infrastructure patches first
and the cx9020 board as last patch?

Regards,
Patrick
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075


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