Re: [U-Boot] [PATCH v2 1/2] m68k: add malloc memory for early malloc

[Angelo Dureghello]

Hi Simon,

On 22/04/2016 20:33, Simon Glass wrote:

Hi Angelo,

On 15 April 2016 at 10:38, Angelo Dureghello  wrote:

Hi Simon,


On 15/04/2016 17:23, Simon Glass wrote:


Hi Angelo,

On 15 April 2016 at 08:42, Angelo Dureghello  wrote:


Hi Simon,


On 15/04/2016 16:14, Simon Glass wrote:



Hi Angelo,

On 27 December 2015 at 21:22, Simon Glass  wrote:



On 20 December 2015 at 08:54, Angelo Dureghello 
wrote:



To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used.
So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and
call to board_init_f_mem() is added for all cpu's.

Signed-off-by: Angelo Dureghello 

---

Changes in v2: None

arch/m68k/cpu/mcf5227x/start.S   | 8 
arch/m68k/cpu/mcf523x/start.S| 8 
arch/m68k/cpu/mcf52x2/start.S| 8 
arch/m68k/cpu/mcf530x/cpu_init.c | 2 +-
arch/m68k/cpu/mcf530x/start.S| 8 
arch/m68k/cpu/mcf532x/start.S| 8 
arch/m68k/cpu/mcf5445x/start.S   | 8 
arch/m68k/cpu/mcf547x_8x/start.S | 8 
arch/m68k/include/asm/config.h   | 2 --
9 files changed, 57 insertions(+), 3 deletions(-)




Reviewed-by: Simon Glass 




Unfortunately this breaks a lot of boards so I cannot apply it:

22: m68k: add malloc memory for early malloc
 m68k:  +   M5475FFE M5475GFE M5485AFE M5475BFE M52277EVB
M5485FFE M54451EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5475EFE
M5485CFE M54451EVB_stmicro M5485BFE M5485HFE M54418TWR_serial_rmii
M5475DFE M52277EVB_stmicro M5475AFE M5485GFE M54418TWR_nand_mii
eb_cpu5282_internal amcore M53017EVB M54418TWR_nand_rmii_lowfreq
M54418TWR M5475CFE M5485EFE M5485DFE eb_cpu5282
+arch/m68k/cpu/mcf547x_8x/start.o: In function `_start':
+build/../arch/m68k/cpu/mcf547x_8x/start.S:153: undefined reference to
`board_init_f_mem'
+build/../arch/m68k/cpu/mcf547x_8x/start.S:153:(.text+0x470):
relocation truncated to fit: R_68K_PC16 against undefined symbol
`board_init_f_mem'
+make[1]: *** [u-boot] Error 1
+make: *** [sub-make] Error 2
+arch/m68k/cpu/mcf5227x/start.o: In function `_start':
+build/../arch/m68k/cpu/mcf5227x/start.S:384: undefined reference to
`board_init_f_mem'
+arch/m68k/cpu/mcf5445x/start.o: In function `_start':
+build/../arch/m68k/cpu/mcf5445x/start.S:669: undefined reference to
`board_init_f_mem'
+build/../arch/m68k/cpu/mcf5445x/start.S:669:(.text+0x41c): relocation
truncated to fit: R_68K_PC16 against undefined symbol
`board_init_f_mem'
+build/../arch/m68k/cpu/mcf5227x/start.S:384:(.text+0x44a): relocation
truncated to fit: R_68K_PC16 against undefined symbol
`board_init_f_mem'
+arch/m68k/cpu/mcf52x2/start.o: In function `_after_flashbar_copy':
+build/../arch/m68k/cpu/mcf52x2/start.S:203: undefined reference to
`board_init_f_mem'
+build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x494): relocation
truncated to fit: R_68K_PC16 against undefined symbol
`board_init_f_mem'
+arch/m68k/cpu/mcf530x/start.o: In function `_start':
+build/../arch/m68k/cpu/mcf530x/start.S:142: undefined reference to
`board_init_f_mem'
+build/../arch/m68k/cpu/mcf530x/start.S:142:(.text+0x45e): relocation
truncated to fit: R_68K_PC16 against undefined symbol
`board_init_f_mem'
+arch/m68k/cpu/mcf532x/start.o: In function `_start':
+build/../arch/m68k/cpu/mcf532x/start.S:160: undefined reference to
`board_init_f_mem'
+arch/m68k/cpu/mcf52x2/start.o: In function `_start':
+build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x456): relocation
truncated to fit: R_68K_PC16 against undefined symbol
`board_init_f_mem'



Issue was not there at that submit time, now it seems due to growing of
u-boot size.

The "truncated to fit" issue is fixed with this patch.

https://patchwork.ozlabs.org/patch/609150/

So if you apply the above, and then this current, all should work.



There is mention of a v2 patch there - is it coming?



No, v2 was an attempt to fix the issue trough the linker script, but was too
complex.
So this is the definitive patch.


I'm not really sure what to do here - the patches do not apply cleanly
to mainline. Can you please point me to the patches that should be
applied, and the order? Or perhaps resend if necessary. I am trying
this:

http://patchwork.ozlabs.org/bundle/sjg/dm6/



1) http://patchwork.ozlabs.org/patch/609150/
has already been applied to master, just tried buildman and all boards
compile.



2) http://patchwork.ozlabs.org/patch/559343/
can't apply correctly anymore due to the patch 1 above, i'll resend a 
new updated version.


3) http://patchwork.ozlabs.org/patch/559344/
It applies as is. But it is the 2/2 of the patch 2 above (559343), so i 
resend in short a patch v3 including both patches (559343 and 559344).


So you don't need to do nothing until i send v.3.

Regards,
Angelo Dureghello




Regards,
Simon


___

Re: [U-Boot] [PATCHv2] cmd: Kconfig: Add a Kconfig options for a few CMD

[Tom Rini]

On Thu, Apr 21, 2016 at 09:18:59AM -0500, Dinh Nguyen wrote:
> Hi Simon,
> 
> On 04/21/2016 09:13 AM, Simon Glass wrote:
> > Hi Dinh,
> > 
> > On 21 April 2016 at 08:05, Dinh Nguyen  wrote:
> >>
> >> Add the following CMD options to Kconfig:
> >>
> >> CMD_BOOTZ
> >> CMD_ASKENV
> >> CMD_GREPENV
> >> CMD_USB_MASS_STORAGE
> >> CMD_FAT
> >> CMD_MII
> >> CMD_CACHE
> >> CMD_DFU
> >> CMD_EXT2
> >> CMD_EXT4
> >> CMD_EXT4_WRITE
> >> CMD_FS_GENERIC
> >> CMD_MMC
> >>
> >> Signed-off-by: Dinh Nguyen 
> >> ---
> >> v2: remove an extra CMD_DFU
> >> ---
> >>  cmd/Kconfig | 72 
> >> +
> >>  1 file changed, 72 insertions(+)
> > 
> > Can you convert existing users with moveconfig.py?
> > 
> 
> Yes, I started doing the moveconfig, starting with ARM, but I saw Tom's
> message to hold off because it might conflict with his work. I'll be
> happy to do the moveconfig, when I get Tom's OK to move ahead.

I am making progress on this front but there's much that had not already
been converted, so I'm taking care of that first.

-- 
Tom


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

Re: [U-Boot] [PATCH 30/60] ARM: tegra: remove pmu.h

[Stephen Warren]

On 04/22/2016 12:32 PM, Simon Glass wrote:

Hi Stephen,

On 19 April 2016 at 14:59, Stephen Warren  wrote:

From: Stephen Warren 

This header is duplicated many times, and does nothing but prototype a
single function that's used solely by mach-tegra code. Move the proto-
type of mach-tegra/cpu.h. That's not an awesome location for it, but
other similar functions like pmic_enable_cpu_vdd() are already there.



Reviewed-by: Simon Glass 

I wonder if it would be better to retain the header name and move
pmic_enable_cpu_vdd()?


I think that pmu_set_nominal() (the function moved into cpu.h by this 
patch) and pmic_enable_cpu_vdd() serve essentially the same semantic 
purpose, but are used on different sets of SoCs via ifdefs or weak 
functions. I expect that early in the part 2 series, I'll get rid of 
more code in board2.c's board_init() and put it into something like 
tegra_board_init_soc(), prototyped in board_init.h or soc_init.h.


Or put another way, I expect I'll clean up the "not a great location" 
issue mentioned in this patch description pretty soon.

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

[U-Boot] [PATCH] ARM: sama5d2: Implement boot device autodetection

[Marek Vasut]

Implement support for saving ARM register R4 early during boot using
save_boot_params . Implement support for decoding the stored register
R4 value in spl_boot_device() to obtain boot device from which the
SoC booted. This way, the SPL will always load U-Boot from the same
device from which the SPL itself booted instead of using hard-coded
boot device.

This functionality is useful for example when booting sama5d2-xplained
from SD card, where by default the SPL would try loading the U-Boot
from eMMC and fail. This is because eMMC is on SDHCI0 (BOOT_DEVICE_MMC1),
while SD slot is on SDHCI1 (BOOT_DEVICE_MMC2) and the SPL was hard-wired
to always boot from BOOT_DEVICE_MMC1.

Signed-off-by: Marek Vasut 
Cc: Andreas Bießmann 
Cc: Wenyou Yang 
---
 arch/arm/mach-at91/Makefile   |  2 +-
 arch/arm/mach-at91/bootparams_atmel.S | 18 
 arch/arm/mach-at91/include/mach/sama5d2.h | 12 +++
 arch/arm/mach-at91/spl.c  | 36 +++
 4 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-at91/bootparams_atmel.S

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 4424523..d2abf31 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_AT91SAM9G20) += sdram.o spl_at91.o
 obj-$(CONFIG_AT91SAM9M10G45) += mpddrc.o spl_at91.o
 obj-$(CONFIG_AT91SAM9N12) += mpddrc.o spl_at91.o
 obj-$(CONFIG_AT91SAM9X5) += mpddrc.o spl_at91.o
-obj-$(CONFIG_SAMA5D2) += mpddrc.o spl_atmel.o matrix.o atmel_sfr.o
+obj-$(CONFIG_SAMA5D2) += bootparams_atmel.o mpddrc.o spl_atmel.o matrix.o 
atmel_sfr.o
 obj-$(CONFIG_SAMA5D3) += mpddrc.o spl_atmel.o
 obj-$(CONFIG_SAMA5D4) += mpddrc.o spl_atmel.o matrix.o atmel_sfr.o
 obj-y += spl.o
diff --git a/arch/arm/mach-at91/bootparams_atmel.S 
b/arch/arm/mach-at91/bootparams_atmel.S
new file mode 100644
index 000..568094b
--- /dev/null
+++ b/arch/arm/mach-at91/bootparams_atmel.S
@@ -0,0 +1,18 @@
+/*
+ * Atmel SAMA5Dx boot parameter handling
+ *
+ * Copyright (c) 2016 Marek Vasut 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+ENTRY(save_boot_params)
+   ldr r0, =bootrom_stash
+   str r4, [r0, #0]
+   b   save_boot_params_ret
+ENDPROC(save_boot_params)
diff --git a/arch/arm/mach-at91/include/mach/sama5d2.h 
b/arch/arm/mach-at91/include/mach/sama5d2.h
index dd5a2a7..e6d498c 100644
--- a/arch/arm/mach-at91/include/mach/sama5d2.h
+++ b/arch/arm/mach-at91/include/mach/sama5d2.h
@@ -225,6 +225,18 @@
 /* No PMECC Galois table in ROM */
 #define NO_GALOIS_TABLE_IN_ROM
 
+/* Boot modes stored by BootROM in r4 */
+#define ATMEL_SAMA5D2_BOOT_FROM_OFF0
+#define ATMEL_SAMA5D2_BOOT_FROM_MASK   0xf
+#define ATMEL_SAMA5D2_BOOT_FROM_SPI(0 << 0)
+#define ATMEL_SAMA5D2_BOOT_FROM_MCI(1 << 0)
+#define ATMEL_SAMA5D2_BOOT_FROM_SMC(2 << 0)
+#define ATMEL_SAMA5D2_BOOT_FROM_TWI(3 << 0)
+#define ATMEL_SAMA5D2_BOOT_FROM_QSPI   (4 << 0)
+
+#define ATMEL_SAMA5D2_BOOT_DEV_ID_OFF  4
+#define ATMEL_SAMA5D2_BOOT_DEV_ID_MASK 0xf
+
 #ifndef __ASSEMBLY__
 unsigned int get_chip_id(void);
 unsigned int get_extension_chip_id(void);
diff --git a/arch/arm/mach-at91/spl.c b/arch/arm/mach-at91/spl.c
index 27a405a..c4ed224 100644
--- a/arch/arm/mach-at91/spl.c
+++ b/arch/arm/mach-at91/spl.c
@@ -23,6 +23,40 @@ void at91_disable_wdt(void)
 }
 #endif
 
+#if defined(CONFIG_SAMA5D2)
+struct {
+   u32 r4;
+} bootrom_stash __attribute__((section(".data")));
+
+u32 spl_boot_device(void)
+{
+   u32 dev = (bootrom_stash.r4 >> ATMEL_SAMA5D2_BOOT_FROM_OFF) &
+ ATMEL_SAMA5D2_BOOT_FROM_MASK;
+   u32 off = (bootrom_stash.r4 >> ATMEL_SAMA5D2_BOOT_DEV_ID_OFF) &
+ ATMEL_SAMA5D2_BOOT_DEV_ID_MASK;
+
+#if defined(CONFIG_SYS_USE_MMC)
+   if (dev == ATMEL_SAMA5D2_BOOT_FROM_MCI) {
+   if (off == 0)
+   return BOOT_DEVICE_MMC1;
+   if (off == 1)
+   return BOOT_DEVICE_MMC2;
+   printf("ERROR: MMC controller %i not present!\n", dev);
+   hang();
+   }
+#endif
+
+#if defined(CONFIG_SYS_USE_SERIALFLASH) || defined(CONFIG_SYS_USE_SPIFLASH)
+   if (dev == ATMEL_SAMA5D2_BOOT_FROM_SPI)
+   return BOOT_DEVICE_SPI;
+#endif
+
+   printf("ERROR: SMC/TWI/QSPI boot device not supported!\n"
+  "   Boot device %i, controller number %i\n", dev, off);
+
+   return BOOT_DEVICE_NONE;
+}
+#else
 u32 spl_boot_device(void)
 {
 #ifdef CONFIG_SYS_USE_MMC
@@ -34,12 +68,14 @@ u32 spl_boot_device(void)
 #endif
return BOOT_DEVICE_NONE;
 }
+#endif
 
 u32 spl_boot_mode(void)
 {
switch (spl_boot_device()) {
 #ifdef CONFIG_SYS_USE_MMC
case BOOT_DEVICE_MMC1:
+   case BOOT_DEVICE_MMC2:
return MMCSD_MODE_FS;
break;
 #endif

[U-Boot] [PATCH] dfu: ram: fix number base of RAM entity parameters

[Stephen Warren]

From: Stephen Warren 

U-Boot typically interprets unprefixed numbers as base 16, and DFU RAM
entity parsing has historically done so. Reverse the change to default
to base 10, so that values in previously working command-lines aren't
mis-parsed, causing RAM corruption, crashes, hangs, etc.

Fixes: 6aeb877afef0 ("drivers: dfu: ram: fix a crash with dfu ram with invalid 
dfu_alt_info env")

Cc: Mugunthan V N 
Cc: Tom Rini 
Signed-off-by: Stephen Warren 
---
 drivers/dfu/dfu_ram.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
index 1391a0d52b6d..c1b00217c911 100644
--- a/drivers/dfu/dfu_ram.c
+++ b/drivers/dfu/dfu_ram.c
@@ -72,8 +72,8 @@ int dfu_fill_entity_ram(struct dfu_entity *dfu, char *devstr, 
char *s)
}
 
dfu->layout = DFU_RAM_ADDR;
-   dfu->data.ram.start = (void *)simple_strtoul(argv[1], NULL, 0);
-   dfu->data.ram.size = simple_strtoul(argv[2], NULL, 0);
+   dfu->data.ram.start = (void *)simple_strtoul(argv[1], NULL, 16);
+   dfu->data.ram.size = simple_strtoul(argv[2], NULL, 16);
 
dfu->write_medium = dfu_write_medium_ram;
dfu->get_medium_size = dfu_get_medium_size_ram;
-- 
2.8.1

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

Re: [U-Boot] [PATCH v2 1/2] m68k: add malloc memory for early malloc

[Simon Glass]

Hi Angelo,

On 15 April 2016 at 10:38, Angelo Dureghello  wrote:
> Hi Simon,
>
>
> On 15/04/2016 17:23, Simon Glass wrote:
>>
>> Hi Angelo,
>>
>> On 15 April 2016 at 08:42, Angelo Dureghello  wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> On 15/04/2016 16:14, Simon Glass wrote:


 Hi Angelo,

 On 27 December 2015 at 21:22, Simon Glass  wrote:
>
>
> On 20 December 2015 at 08:54, Angelo Dureghello 
> wrote:
>>
>>
>> To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used.
>> So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and
>> call to board_init_f_mem() is added for all cpu's.
>>
>> Signed-off-by: Angelo Dureghello 
>>
>> ---
>>
>> Changes in v2: None
>>
>>arch/m68k/cpu/mcf5227x/start.S   | 8 
>>arch/m68k/cpu/mcf523x/start.S| 8 
>>arch/m68k/cpu/mcf52x2/start.S| 8 
>>arch/m68k/cpu/mcf530x/cpu_init.c | 2 +-
>>arch/m68k/cpu/mcf530x/start.S| 8 
>>arch/m68k/cpu/mcf532x/start.S| 8 
>>arch/m68k/cpu/mcf5445x/start.S   | 8 
>>arch/m68k/cpu/mcf547x_8x/start.S | 8 
>>arch/m68k/include/asm/config.h   | 2 --
>>9 files changed, 57 insertions(+), 3 deletions(-)
>
>
>
> Reviewed-by: Simon Glass 



 Unfortunately this breaks a lot of boards so I cannot apply it:

 22: m68k: add malloc memory for early malloc
 m68k:  +   M5475FFE M5475GFE M5485AFE M5475BFE M52277EVB
 M5485FFE M54451EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5475EFE
 M5485CFE M54451EVB_stmicro M5485BFE M5485HFE M54418TWR_serial_rmii
 M5475DFE M52277EVB_stmicro M5475AFE M5485GFE M54418TWR_nand_mii
 eb_cpu5282_internal amcore M53017EVB M54418TWR_nand_rmii_lowfreq
 M54418TWR M5475CFE M5485EFE M5485DFE eb_cpu5282
 +arch/m68k/cpu/mcf547x_8x/start.o: In function `_start':
 +build/../arch/m68k/cpu/mcf547x_8x/start.S:153: undefined reference to
 `board_init_f_mem'
 +build/../arch/m68k/cpu/mcf547x_8x/start.S:153:(.text+0x470):
 relocation truncated to fit: R_68K_PC16 against undefined symbol
 `board_init_f_mem'
 +make[1]: *** [u-boot] Error 1
 +make: *** [sub-make] Error 2
 +arch/m68k/cpu/mcf5227x/start.o: In function `_start':
 +build/../arch/m68k/cpu/mcf5227x/start.S:384: undefined reference to
 `board_init_f_mem'
 +arch/m68k/cpu/mcf5445x/start.o: In function `_start':
 +build/../arch/m68k/cpu/mcf5445x/start.S:669: undefined reference to
 `board_init_f_mem'
 +build/../arch/m68k/cpu/mcf5445x/start.S:669:(.text+0x41c): relocation
 truncated to fit: R_68K_PC16 against undefined symbol
 `board_init_f_mem'
 +build/../arch/m68k/cpu/mcf5227x/start.S:384:(.text+0x44a): relocation
 truncated to fit: R_68K_PC16 against undefined symbol
 `board_init_f_mem'
 +arch/m68k/cpu/mcf52x2/start.o: In function `_after_flashbar_copy':
 +build/../arch/m68k/cpu/mcf52x2/start.S:203: undefined reference to
 `board_init_f_mem'
 +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x494): relocation
 truncated to fit: R_68K_PC16 against undefined symbol
 `board_init_f_mem'
 +arch/m68k/cpu/mcf530x/start.o: In function `_start':
 +build/../arch/m68k/cpu/mcf530x/start.S:142: undefined reference to
 `board_init_f_mem'
 +build/../arch/m68k/cpu/mcf530x/start.S:142:(.text+0x45e): relocation
 truncated to fit: R_68K_PC16 against undefined symbol
 `board_init_f_mem'
 +arch/m68k/cpu/mcf532x/start.o: In function `_start':
 +build/../arch/m68k/cpu/mcf532x/start.S:160: undefined reference to
 `board_init_f_mem'
 +arch/m68k/cpu/mcf52x2/start.o: In function `_start':
 +build/../arch/m68k/cpu/mcf52x2/start.S:203:(.text+0x456): relocation
 truncated to fit: R_68K_PC16 against undefined symbol
 `board_init_f_mem'

>>>
>>> Issue was not there at that submit time, now it seems due to growing of
>>> u-boot size.
>>>
>>> The "truncated to fit" issue is fixed with this patch.
>>>
>>> https://patchwork.ozlabs.org/patch/609150/
>>>
>>> So if you apply the above, and then this current, all should work.
>>
>>
>> There is mention of a v2 patch there - is it coming?
>>
>
> No, v2 was an attempt to fix the issue trough the linker script, but was too
> complex.
> So this is the definitive patch.

I'm not really sure what to do here - the patches do not apply cleanly
to mainline. Can you please point me to the patches that should be
applied, and the order? Or perhaps resend if necessary. I am trying
this:

http://patchwork.ozlabs.org/bundle/sjg/dm6/

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

Re: [U-Boot] [PATCH 31/60] ARM: tegra: move powergate.h to

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Machine-specific headers should be in this location. Eventually, we'll
> move all headers from arch/arm/include to arch/arm/mach-tegra/include,
> or find a way to delete them. This change also removes multiple useless
> empty wrappers for this header.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/include/asm/arch-tegra114/powergate.h   |  6 --
>  arch/arm/include/asm/arch-tegra124/powergate.h   |  6 --
>  arch/arm/include/asm/arch-tegra20/powergate.h|  6 --
>  arch/arm/include/asm/arch-tegra210/powergate.h   | 12 
> 
>  arch/arm/include/asm/arch-tegra30/powergate.h|  6 --
>  .../asm/arch-tegra => mach-tegra/include/mach}/powergate.h   | 10 --
>  arch/arm/mach-tegra/powergate.c  |  4 ++--
>  arch/arm/mach-tegra/tegra124/psci.c  |  2 +-
>  drivers/pci/pci_tegra.c  |  2 +-
>  9 files changed, 12 insertions(+), 42 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-tegra114/powergate.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra124/powergate.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra20/powergate.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra210/powergate.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra30/powergate.h
>  rename arch/arm/{include/asm/arch-tegra => 
> mach-tegra/include/mach}/powergate.h (83%)

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

Re: [U-Boot] [PATCH 36/60] ARM: tegra: move mc.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there.
> Since the definitions are used by code in mach-tegra/ itself, not just in
> SoC-specific mach-tegra/tegraNNN/, and the content varies per SoC, we need
> to put it in the (somewhat isolated)  include directory rather than
> in mach-tegra/ directly.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/ap.c| 2 
> +-
>  arch/arm/mach-tegra/board.c | 2 
> +-
>  arch/arm/mach-tegra/gpu.c   | 2 
> +-
>  .../{include/asm/arch-tegra114 => mach-tegra/tegra114/include/soc}/mc.h | 2 
> +-
>  .../{include/asm/arch-tegra124 => mach-tegra/tegra124/include/soc}/mc.h | 0
>  .../{include/asm/arch-tegra20 => mach-tegra/tegra20/include/soc}/mc.h   | 2 
> +-
>  .../{include/asm/arch-tegra210 => mach-tegra/tegra210/include/soc}/mc.h | 0
>  .../{include/asm/arch-tegra30 => mach-tegra/tegra30/include/soc}/mc.h   | 2 
> +-
>  8 files changed, 6 insertions(+), 6 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra114 => 
> mach-tegra/tegra114/include/soc}/mc.h (97%)
>  rename arch/arm/{include/asm/arch-tegra124 => 
> mach-tegra/tegra124/include/soc}/mc.h (100%)
>  rename arch/arm/{include/asm/arch-tegra20 => 
> mach-tegra/tegra20/include/soc}/mc.h (97%)
>  rename arch/arm/{include/asm/arch-tegra210 => 
> mach-tegra/tegra210/include/soc}/mc.h (100%)
>  rename arch/arm/{include/asm/arch-tegra30 => 
> mach-tegra/tegra30/include/soc}/mc.h (97%)

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

Re: [U-Boot] [PATCH 34/60] ARM: tegra: move flow.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there.
> Since the definitions are used by code in mach-tegra/ itself, not just in
> SoC-specific mach-tegra/tegraNNN/, and the content varies per SoC, we need
> to put it in the (somewhat isolated)  include directory rather than
> in mach-tegra/ directly.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/powergate.c   | 2 +-
>  arch/arm/mach-tegra/tegra114/cpu.c| 2 +-
>  .../asm/arch-tegra30 => mach-tegra/tegra114/include/soc}/flow.h   | 8 
> 
>  arch/arm/mach-tegra/tegra124/cpu.c| 2 +-
>  .../asm/arch-tegra124 => mach-tegra/tegra124/include/soc}/flow.h  | 6 +++---
>  arch/arm/mach-tegra/tegra124/psci.c   | 2 +-
>  .../asm/arch-tegra20 => mach-tegra/tegra20/include/soc}/flow.h| 4 ++--
>  arch/arm/mach-tegra/tegra20/warmboot_avp.c| 2 +-
>  .../asm/arch-tegra210 => mach-tegra/tegra210/include/soc}/flow.h  | 6 +++---
>  arch/arm/mach-tegra/tegra30/cpu.c | 2 +-
>  .../asm/arch-tegra114 => mach-tegra/tegra30/include/soc}/flow.h   | 8 
> 
>  11 files changed, 22 insertions(+), 22 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra30 => 
> mach-tegra/tegra114/include/soc}/flow.h (67%)
>  rename arch/arm/{include/asm/arch-tegra124 => 
> mach-tegra/tegra124/include/soc}/flow.h (93%)
>  rename arch/arm/{include/asm/arch-tegra20 => 
> mach-tegra/tegra20/include/soc}/flow.h (85%)
>  rename arch/arm/{include/asm/arch-tegra210 => 
> mach-tegra/tegra210/include/soc}/flow.h (90%)
>  rename arch/arm/{include/asm/arch-tegra114 => 
> mach-tegra/tegra30/include/soc}/flow.h (67%)

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

Re: [U-Boot] [PATCH 35/60] nyan-big: remove direct MC register access

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Equivalent code is already present in the core Tegra board file, so
> there's no point repeating it here. This removes the only use of
>  from outside arch/arm/mach-tegra/.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/gpu.c|  1 +
>  board/nvidia/nyan-big/nyan-big.c | 13 -
>  2 files changed, 1 insertion(+), 13 deletions(-)

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

Re: [U-Boot] [PATCH 33/60] ARM: tegra: fix bug in Tegra20 flow.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> According to the TRM, Tegra20's flow controller has a xrq_events field
> too. Suspend/resume (via LP0) does still work after this fix, implying
> the write to halt_cpu1_events in warmboot_avp.c isn't actually necessary,
> since this patch causes it to access a different register.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/include/asm/arch-tegra20/flow.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH 28/60] ARM: tegra: move sdram_param.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> Signed-off-by: Stephen Warren 
> ---
>  .../{include/asm/arch-tegra20 => mach-tegra/tegra20}/sdram_param.h  | 6 
> +++---
>  arch/arm/mach-tegra/tegra20/warmboot.c  | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra20 => 
> mach-tegra/tegra20}/sdram_param.h (96%)

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

Re: [U-Boot] [PATCH 32/60] ARM: tegra: add SoC-specific include directory

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Add arch/arm/mach-tegra/tegraNNN/include. We'll use this to house headers
> that must vary between SoCs (e.g. clock lists, register layouts that
> aren't static across chip versions, etc.) in a  name-space. This
> will allow code in mach-tegra/ to access those register definitions without
> polluting the more public  or  namespaces or the directories
> they map to.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/config.mk | 13 +
>  1 file changed, 13 insertions(+)
>  create mode 100644 arch/arm/mach-tegra/config.mk

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

Re: [U-Boot] [PATCH 30/60] ARM: tegra: remove pmu.h

[Simon Glass]

Hi Stephen,

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is duplicated many times, and does nothing but prototype a
> single function that's used solely by mach-tegra code. Move the proto-
> type of mach-tegra/cpu.h. That's not an awesome location for it, but
> other similar functions like pmic_enable_cpu_vdd() are already there.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/include/asm/arch-tegra114/pmu.h | 13 -
>  arch/arm/include/asm/arch-tegra124/pmu.h | 14 --
>  arch/arm/include/asm/arch-tegra20/pmu.h  | 14 --
>  arch/arm/include/asm/arch-tegra210/pmu.h | 14 --
>  arch/arm/include/asm/arch-tegra30/pmu.h  | 13 -
>  arch/arm/mach-tegra/board2.c |  1 -
>  arch/arm/mach-tegra/cpu.h|  2 ++
>  arch/arm/mach-tegra/emc.c|  1 -
>  8 files changed, 2 insertions(+), 70 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra124/pmu.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra20/pmu.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra210/pmu.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra30/pmu.h

Reviewed-by: Simon Glass 

I wonder if it would be better to retain the header name and move
pmic_enable_cpu_vdd()?

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

Re: [U-Boot] [PATCH 29/60] ARM: tegra: move sysctr.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path. Also, unify the 3 identical
> copies of the file into one.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/include/asm/arch-tegra124/sysctr.h| 26 
> --
>  arch/arm/include/asm/arch-tegra210/sysctr.h| 26 
> --
>  .../asm/arch-tegra114 => mach-tegra}/sysctr.h  |  8 +++
>  arch/arm/mach-tegra/tegra114/clock.c   |  2 +-
>  arch/arm/mach-tegra/tegra124/clock.c   |  2 +-
>  arch/arm/mach-tegra/tegra210/clock.c   |  2 +-
>  6 files changed, 7 insertions(+), 59 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-tegra124/sysctr.h
>  delete mode 100644 arch/arm/include/asm/arch-tegra210/sysctr.h
>  rename arch/arm/{include/asm/arch-tegra114 => mach-tegra}/sysctr.h (81%)

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

Re: [U-Boot] [PATCH 27/60] ARM: tegra: move emc.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> tegra_set_emc() is moved between two emc.h so that mach-tegra/emc.h
> defines fairly public interfaces to the EMC functionality, and emc_priv.h
> contains internal register details.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/board2.c|  3 ---
>  arch/arm/mach-tegra/emc.c   |  1 -
>  arch/arm/mach-tegra/emc.h   | 14 ++
>  arch/arm/mach-tegra/tegra20/emc.c   |  3 ++-
>  .../emc.h => mach-tegra/tegra20/emc_priv.h} | 17 
> +++--
>  arch/arm/mach-tegra/tegra20/warmboot.c  |  3 ++-
>  6 files changed, 21 insertions(+), 20 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra20/emc.h => 
> mach-tegra/tegra20/emc_priv.h} (83%)

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

Re: [U-Boot] [PATCH 26/60] ARM: tegra: delete unused headers

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> These headers aren't included by anything, so can be deleted.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/include/asm/arch-tegra210/ahb.h | 80 
> 
>  1 file changed, 80 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-tegra210/ahb.h

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

Re: [U-Boot] [PATCH 25/60] ARM: tegra: use consistently named include guards

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> ... and add one missing set of include guards.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/cpu.h  | 6 ++
>  arch/arm/mach-tegra/emc.h  | 6 +++---
>  arch/arm/mach-tegra/tegra20/crypto.h   | 6 +++---
>  arch/arm/mach-tegra/tegra20/warmboot_avp.h | 4 ++--
>  4 files changed, 14 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH 23/60] ARM: tegra: move xusb-padctl.h to

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Machine-specific headers should be in this location. Eventually, we'll
> move all headers from arch/arm/include to arch/arm/mach-tegra/include,
> or find a way to delete them.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/board2.c | 2 +-
>  .../asm/arch-tegra => mach-tegra/include/mach}/xusb-padctl.h | 4 ++--
>  arch/arm/mach-tegra/xusb-padctl-common.h | 9 
> -
>  arch/arm/mach-tegra/xusb-padctl-dummy.c  | 4 ++--
>  drivers/pci/pci_tegra.c  | 5 +++--
>  5 files changed, 12 insertions(+), 12 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra => 
> mach-tegra/include/mach}/xusb-padctl.h (92%)

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

Re: [U-Boot] [PATCH 24/60] ARM: tegra: unify+move {board, sys_proto}.h to

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Machine-specific headers should be in this location. Eventually, we'll
> move all headers from arch/arm/include to arch/arm/mach-tegra/include,
> or find a way to delete them.
>
> Both board and sys_proto.h served the same purpose; a place to prototype
> functions implemented by the board and called by code in mach-tegra/.
> Merge them into a single file to reduce the number of headers.
>
> board_init_uart_f() is private to code in mach-tegra/ so remove its
> prototype from the public  header. cpu.h isn't a great place for
> it, but other functions implemented in the same C file are prototyped
> there, so it'll do for now. When the C files are all refactored for
> Tegra186, this should be cleaned up.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/include/asm/arch-tegra/sys_proto.h| 33 
> --
>  arch/arm/mach-tegra/board.c|  3 +-
>  arch/arm/mach-tegra/board2.c   |  4 +--
>  arch/arm/mach-tegra/cpu.h  |  2 ++
>  arch/arm/mach-tegra/emc.c  |  1 -
>  .../arch-tegra => mach-tegra/include/mach}/board.h | 33 
> +-
>  arch/arm/mach-tegra/spl.c  |  2 +-
>  arch/arm/mach-tegra/tegra20/pmu.c  |  1 -
>  board/avionic-design/common/tamonten.c |  3 +-
>  board/nvidia/seaboard/seaboard.c   |  2 +-
>  board/toradex/colibri_t20/colibri_t20.c|  2 +-
>  11 files changed, 35 insertions(+), 51 deletions(-)
>  delete mode 100644 arch/arm/include/asm/arch-tegra/sys_proto.h
>  rename arch/arm/{include/asm/arch-tegra => mach-tegra/include/mach}/board.h 
> (63%)

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

Re: [U-Boot] [PATCH 22/60] ARM: tegra: move warmboot.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/ap.c   | 1 -
>  arch/arm/mach-tegra/board.c| 1 -
>  arch/arm/mach-tegra/board2.c   | 4 +++-
>  arch/arm/mach-tegra/tegra20/warmboot.c | 2 +-
>  arch/arm/{include/asm/arch-tegra => mach-tegra/tegra20}/warmboot.h | 4 ++--
>  arch/arm/mach-tegra/tegra20/warmboot_avp.c | 2 +-
>  6 files changed, 7 insertions(+), 7 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra => mach-tegra/tegra20}/warmboot.h 
> (98%)

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

Re: [U-Boot] [PATCH] debug_uart: output CR along with LF

[Simon Glass]

Hi Tom,

On 22 April 2016 at 12:19, Tim Chick  wrote:
>
> On 20/04/2016 15:40, Simon Glass wrote:
>> Hi Tim,
>>
>> On 7 April 2016 at 11:20, Tim Chick  wrote:
>>> Sorry for top posting. Not in the office at the moment.
>>>
>>> Yes, I call debug_uart_init() before I have SDRAM, in lowlevel_init(). I
>>> need the debug uart to help me debug lowlevel_init!
 The patch below fixes it, and keeps your change:
>>
>> Yes your patch looks correct to me. I have also used the debug UART
>> without a stack.
>>
> OK. What needs to be done to get it applied?
>
> Shall I submit as a "normal" patch?

Yes, try using patman.

Regards,
Simon

>
> Thanks,
> Tim
>
>
>> Reviewed-by: Simon Glass 
>>

 Thanks,
 Tim


 ---

 diff --git a/include/debug_uart.h b/include/debug_uart.h
 index 0d640b9..2980ae6 100644
 --- a/include/debug_uart.h
 +++ b/include/debug_uart.h
 @@ -115,17 +115,23 @@ void printhex8(uint value);
   * Now define some functions - this should be inserted into the serial
 driver
   */
  #define DEBUG_UART_FUNCS \
 -   void printch(int ch) \
 +\
 +   static inline void _printch(int ch) \
 { \
 if (ch == '\n') \
 _debug_uart_putc('\r'); \
 _debug_uart_putc(ch); \
 } \
  \
 +   void printch(int ch) \
 +   { \
 +   _printch(ch); \
 +   } \
 +\
 void printascii(const char *str) \
 { \
 while (*str) \
 -   printch(*str++); \
 +   _printch(*str++); \
 } \
  \
 static inline void printhex1(uint digit) \
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>>
>>>
>
> * Email Confidentiality Notice 
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 20/60] ARM: tegra: move pmc.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/ap.c  | 2 +-
>  arch/arm/mach-tegra/board.c   | 2 +-
>  arch/arm/mach-tegra/board2.c  | 2 +-
>  arch/arm/mach-tegra/clock.c   | 2 +-
>  arch/arm/mach-tegra/cmd_enterrcm.c| 4 ++--
>  arch/arm/mach-tegra/cpu.c | 4 ++--
>  arch/arm/{include/asm/arch-tegra => mach-tegra}/pmc.h | 6 +++---
>  arch/arm/mach-tegra/tegra114/cpu.c| 4 ++--
>  arch/arm/mach-tegra/tegra124/cpu.c| 2 +-
>  arch/arm/mach-tegra/tegra124/psci.c   | 2 +-
>  arch/arm/mach-tegra/tegra20/cpu.c | 4 ++--
>  arch/arm/mach-tegra/tegra20/warmboot.c| 2 +-
>  arch/arm/mach-tegra/tegra20/warmboot_avp.c| 2 +-
>  arch/arm/mach-tegra/tegra30/cpu.c | 2 +-
>  board/nvidia/nyan-big/nyan-big.c  | 1 -
>  15 files changed, 20 insertions(+), 21 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra => mach-tegra}/pmc.h (99%)

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

Re: [U-Boot] [PATCH 21/60] ARM: tegra: move scu.h

[Simon Glass]

On 19 April 2016 at 14:59, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/ap.c  | 2 +-
>  arch/arm/mach-tegra/cpu.c | 2 +-
>  arch/arm/{include/asm/arch-tegra => mach-tegra}/scu.h | 8 
>  3 files changed, 6 insertions(+), 6 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra => mach-tegra}/scu.h (91%)

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

Re: [U-Boot] [PATCH 19/60] ARM: tegra: move gpu.h

[Simon Glass]

On 19 April 2016 at 14:58, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/board2.c  | 2 +-
>  arch/arm/mach-tegra/gpu.c | 6 +++---
>  arch/arm/{include/asm/arch-tegra => mach-tegra}/gpu.h | 8 
>  3 files changed, 8 insertions(+), 8 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra => mach-tegra}/gpu.h (80%)

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

Re: [U-Boot] [PATCH 18/60] ARM: tegra: move fuse.h

[Simon Glass]

On 19 April 2016 at 14:58, Stephen Warren  wrote:
> From: Stephen Warren 
>
> This header is only needed by code local to mach-tegra, so move it there
> to avoid polluting the global include path.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/ap.c   | 2 +-
>  arch/arm/{include/asm/arch-tegra => mach-tegra}/fuse.h | 8 
>  arch/arm/mach-tegra/tegra20/warmboot.c | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
>  rename arch/arm/{include/asm/arch-tegra => mach-tegra}/fuse.h (83%)

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

Re: [U-Boot] [PATCH] debug_uart: output CR along with LF

[Tim Chick]

On 20/04/2016 15:40, Simon Glass wrote:
> Hi Tim,
> 
> On 7 April 2016 at 11:20, Tim Chick  wrote:
>> Sorry for top posting. Not in the office at the moment.
>>
>> Yes, I call debug_uart_init() before I have SDRAM, in lowlevel_init(). I
>> need the debug uart to help me debug lowlevel_init!
>>> The patch below fixes it, and keeps your change:
> 
> Yes your patch looks correct to me. I have also used the debug UART
> without a stack.
>
OK. What needs to be done to get it applied?

Shall I submit as a "normal" patch?

Thanks,
Tim


> Reviewed-by: Simon Glass 
> 
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> ---
>>>
>>> diff --git a/include/debug_uart.h b/include/debug_uart.h
>>> index 0d640b9..2980ae6 100644
>>> --- a/include/debug_uart.h
>>> +++ b/include/debug_uart.h
>>> @@ -115,17 +115,23 @@ void printhex8(uint value);
>>>   * Now define some functions - this should be inserted into the serial
>>> driver
>>>   */
>>>  #define DEBUG_UART_FUNCS \
>>> -   void printch(int ch) \
>>> +\
>>> +   static inline void _printch(int ch) \
>>> { \
>>> if (ch == '\n') \
>>> _debug_uart_putc('\r'); \
>>> _debug_uart_putc(ch); \
>>> } \
>>>  \
>>> +   void printch(int ch) \
>>> +   { \
>>> +   _printch(ch); \
>>> +   } \
>>> +\
>>> void printascii(const char *str) \
>>> { \
>>> while (*str) \
>>> -   printch(*str++); \
>>> +   _printch(*str++); \
>>> } \
>>>  \
>>> static inline void printhex1(uint digit) \
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>>

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

Re: [U-Boot] [GIT] Pull request: u-boot-dfu

[Marek Vasut]

On 04/22/2016 06:38 PM, Stephen Warren wrote:
> On 04/22/2016 10:33 AM, Lukasz Majewski wrote:
>> +CC ing u-boot mailing list.
>>
>> The following changes since commit
>> e6c0bc0643e5a4387fecbcf83080d0b796eb067c:
>>
>>usb: gadget Move: CONFIG_G_DNL_* to Kconfig (2016-04-20 11:43:28
>>+0200)
>>
>> are available in the git repository at:
>>
>>u-boot-dfu/master
>>
>> for you to fetch changes up to 6aeb877afef0c2d6cd3ea74e1b7d3a061d7cbd85:
>>
>>drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info
>>env (2016-04-22 17:03:54 +0200)
> 
> Given that this currently fails DFU RAM testing on Tegra, let's hold off
> until that's fixed. I plan to investigate later today after I fix an
> unrelated emergency.

OK, will wait

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

Re: [U-Boot] [GIT] Pull request: u-boot-dfu

[Stephen Warren]

On 04/22/2016 10:33 AM, Lukasz Majewski wrote:

+CC ing u-boot mailing list.

The following changes since commit
e6c0bc0643e5a4387fecbcf83080d0b796eb067c:

   usb: gadget Move: CONFIG_G_DNL_* to Kconfig (2016-04-20 11:43:28
   +0200)

are available in the git repository at:

   u-boot-dfu/master

for you to fetch changes up to 6aeb877afef0c2d6cd3ea74e1b7d3a061d7cbd85:

   drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info
   env (2016-04-22 17:03:54 +0200)


Given that this currently fails DFU RAM testing on Tegra, let's hold off 
until that's fixed. I plan to investigate later today after I fix an 
unrelated emergency.

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

[U-Boot] [GIT] Pull request: u-boot-dfu

[Lukasz Majewski]

+CC ing u-boot mailing list.

The following changes since commit
e6c0bc0643e5a4387fecbcf83080d0b796eb067c:

  usb: gadget Move: CONFIG_G_DNL_* to Kconfig (2016-04-20 11:43:28
  +0200)

are available in the git repository at:

  u-boot-dfu/master 

for you to fetch changes up to 6aeb877afef0c2d6cd3ea74e1b7d3a061d7cbd85:

  drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info
  env (2016-04-22 17:03:54 +0200)


Mugunthan V N (1):
  drivers: dfu: ram: fix a crash with dfu ram with invalid
dfu_alt_info env

Roger Quadros (5):
  fastboot: Fix wMaxPacketSize for High-Speed IN endpoint
  fastboot: Enable the respective speed endpoints at runtime
  fastboot: Clean up bulk-out logic
  usb: s3c-otg: Fix short packet for request size > ep.maxpacket
  usb: s3c-otg: Fix remaining bytes in debug messages

Łukasz Majewski (4):
  usb: mass storage: Initialize ret variable to zero
  tests: py: dfu: Add variables to store dfu alt numbers for test
and dummy files tests: py: dfu: Add functionality to set
different u-boot's dfu env variable
  tests: py: dfu: Provide
functionality to set test and dummy files alt settings

 cmd/usb_mass_storage.c |   2 +-
 drivers/dfu/dfu_ram.c  |  21 ++---
 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c |   6 +++---
 drivers/usb/gadget/f_fastboot.c| 
104
 test/py/tests/test_dfu.py  |  44 
++-- 

5 files changed, 120
 insertions(+), 57 deletions(-)


-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] DFU tests failing in test/py on Tegra

[Stephen Warren]

Lukasz, today test/py's DFU test fails on u-boot-dfu.git branch master 
on all Tegra boards where my automated system is running it, when 
testing RAM-based DFU. I'll try and investigate/bisect later today, but 
if anything jumps out at you...

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

Re: [U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Thu, Apr 21, 2016 at 07:38:17PM -0400, Tom Rini wrote:
> On Thu, Apr 21, 2016 at 05:56:11PM -0500, Andreas Dannenberg wrote:
> > On Thu, Apr 21, 2016 at 04:27:42PM -0400, Tom Rini wrote:
> > > On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> > > > On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > > > > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > > > > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > > > > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > > > > >>>Update the CPU string output so that the device
> > > > > >>>type is now included as part of the CPU string that
> > > > > >>>is printed as the SPL or u-boot comes up. This update
> > > > > >>>adds a suffix of the form "-GP" or "-HS" for production
> > > > > >>>devices, so that general purpose (GP) and high security
> > > > > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > > > > >>
> > > > > >>When I'm building for AM437x HS and running on the device I don't 
> > > > > >>see
> > > > > >>that output. It seems like there is something funny going on with
> > > > > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated 
> > > > > >>in
> > > > > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > > > > >>preloader_console_init() in spl.c, hence the function that prints 
> > > > > >>the
> > > > > >>chip-type/rev specifics never gets invoked.
> > > > > >
> > > > > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > > > > >I'll get the device name/type output by SPL as expected so that piece
> > > > > >works. However this patch's commit message  implies the same should 
> > > > > >also
> > > > > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > > > > >hardware at my desk but I looked at some boot logs from our test 
> > > > > >farms
> > > > > >and I also don't see the device ID output by SPL so that may be just 
> > > > > >how
> > > > > >it currently is implemented generally for AM437* and has nothing to 
> > > > > >do
> > > > > >with the patch discussed here.
> > > > > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > > > > statement "Applies to all OMAP5 variants" in the commit message. The 
> > > > > omap4/5
> > > > > use in the commit header is because the omap4 cpu.h header file had 
> > > > > to be
> > > > > updated in order to not break omap4 builds (because those builds DO 
> > > > > use this
> > > > > hwinit-common.c).
> > > > 
> > > > Daniel,
> > > > thanks for clarifying/confirming my suspicion. Then I'm okay with this 
> > > > patch.
> > > 
> > > Can we do a follow-up that moves this otherwise common code into the
> > > rest of the families?
> > 
> > Hi Tom,
> > just to make sure I understand your suggestion correctly, this is about
> > a behind the scenes optimization to remove the code duplication we
> > currently have in .../asm/arch-omap(4|5)/cpu.h, rather than making the
> > CPU string output as part of SPL work on all of our (TI) platforms, yes?
> 
> I want as much consolidate and consistency of output as is both feasible
> and practical.

Agreed. Consistency and consolidation would make sense here. I just
added an item to our internal issue tracker to capture this suggestion
but I can't yet comment on when we'll get to it.

Thanks and Regards,
Andreas

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

Re: [U-Boot] Unable to compile

[Kevin Welsh]

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Friday, April 22, 2016 9:50 AM
> To: Kevin Welsh 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] Unable to compile
> 
> On Fri, Apr 22, 2016 at 03:33:13AM +, Kevin Welsh wrote:
> > After moving to v2006.03, I can no longer compile with my existing
> defconfig:
> >
> >
> > cmd/built-in.o: In function `do_fastboot':
> > /home/kdubious/u-boot/cmd/fastboot.c:34: undefined reference to
> `g_dnl_clear_detach'
> > /home/kdubious/u-boot/cmd/fastboot.c:35: undefined reference to
> `g_dnl_register'
> > /home/kdubious/u-boot/cmd/fastboot.c:39: undefined reference to
> `g_dnl_board_usb_cable_connected'
> > /home/kdubious/u-boot/cmd/fastboot.c:47: undefined reference to
> `g_dnl_detach'
> > /home/kdubious/u-boot/cmd/fastboot.c:57: undefined reference to
> `g_dnl_unregister'
> > /home/kdubious/u-boot/cmd/fastboot.c:58: undefined reference to
> `g_dnl_clear_detach'
> > cmd/built-in.o: In function `do_usb_mass_storage':
> > /home/kdubious/u-boot/cmd/usb_mass_storage.c:159: undefined
> reference to `fsg_init'
> > /home/kdubious/u-boot/cmd/usb_mass_storage.c:166: undefined
> reference to `g_dnl_register'
> > /home/kdubious/u-boot/cmd/usb_mass_storage.c:176: undefined
> reference to `g_dnl_board_usb_cable_connected'
> > /home/kdubious/u-boot/cmd/usb_mass_storage.c:183: undefined
> reference to `g_dnl_board_usb_cable_connected'
> > /home/kdubious/u-boot/cmd/usb_mass_storage.c:206: undefined
> reference to `fsg_main_thread'
> > /home/kdubious/u-boot/cmd/usb_mass_storage.c:222: undefined
> reference to `g_dnl_unregister'
> > cmd/built-in.o: In function `do_dfu':
> > /home/kdubious/u-boot/cmd/dfu.c:56: undefined reference to
> `g_dnl_clear_detach'
> > /home/kdubious/u-boot/cmd/dfu.c:57: undefined reference to
> `g_dnl_register'
> > /home/kdubious/u-boot/cmd/dfu.c:59: undefined reference to
> `g_dnl_detach'
> > /home/kdubious/u-boot/cmd/dfu.c:106: undefined reference to
> `g_dnl_unregister'
> > /home/kdubious/u-boot/cmd/dfu.c:114: undefined reference to
> `g_dnl_clear_detach'
> > /home/kdubious/u-boot/cmd/dfu.c:27: undefined reference to
> `dfu_defer_flush'
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > assertion fail ../../bfd/elf32-arm.c:7696
> > arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not
> > found in the linker script
> > arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation
> >
> >
> > Am doing something wrong?
> 
> It's likely some option to enable the gadget controller you use has moved to
> Kconfig, re-run menuconfig/config/etc and enable it.
> 
> --
> Tom

Hi Tom,

That seems to have fixed it where I can build, but now u-boot fails:

Net:   eth0: ethernet@01c5
starting USB...
USB0:   undefined instruction
pc : [<6008>]  lr : [<7ef843b8>]
reloc pc : []lr : [<4a0363b8>]
sp : 7af25918  ip :  fp : c1c20bf2
r10: 7af2fa70  r9 : 7af2dee0 r8 : 01c14000
r7 :   r6 :  r5 :   r4 : 7af2fa80
r3 : 6000  r2 : 015a70dc r1 : 01c20c00  r0 : 7af2fa80
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

Kevin

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

Re: [U-Boot] Unable to compile

[Tom Rini]

On Fri, Apr 22, 2016 at 02:24:16PM +, Kevin Welsh wrote:
> > -Original Message-
> > From: Tom Rini [mailto:tr...@konsulko.com]
> > Sent: Friday, April 22, 2016 9:50 AM
> > To: Kevin Welsh 
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] Unable to compile
> > 
> > On Fri, Apr 22, 2016 at 03:33:13AM +, Kevin Welsh wrote:
> > > After moving to v2006.03, I can no longer compile with my existing
> > defconfig:
> > >
> > >
> > > cmd/built-in.o: In function `do_fastboot':
> > > /home/kdubious/u-boot/cmd/fastboot.c:34: undefined reference to
> > `g_dnl_clear_detach'
> > > /home/kdubious/u-boot/cmd/fastboot.c:35: undefined reference to
> > `g_dnl_register'
> > > /home/kdubious/u-boot/cmd/fastboot.c:39: undefined reference to
> > `g_dnl_board_usb_cable_connected'
> > > /home/kdubious/u-boot/cmd/fastboot.c:47: undefined reference to
> > `g_dnl_detach'
> > > /home/kdubious/u-boot/cmd/fastboot.c:57: undefined reference to
> > `g_dnl_unregister'
> > > /home/kdubious/u-boot/cmd/fastboot.c:58: undefined reference to
> > `g_dnl_clear_detach'
> > > cmd/built-in.o: In function `do_usb_mass_storage':
> > > /home/kdubious/u-boot/cmd/usb_mass_storage.c:159: undefined
> > reference to `fsg_init'
> > > /home/kdubious/u-boot/cmd/usb_mass_storage.c:166: undefined
> > reference to `g_dnl_register'
> > > /home/kdubious/u-boot/cmd/usb_mass_storage.c:176: undefined
> > reference to `g_dnl_board_usb_cable_connected'
> > > /home/kdubious/u-boot/cmd/usb_mass_storage.c:183: undefined
> > reference to `g_dnl_board_usb_cable_connected'
> > > /home/kdubious/u-boot/cmd/usb_mass_storage.c:206: undefined
> > reference to `fsg_main_thread'
> > > /home/kdubious/u-boot/cmd/usb_mass_storage.c:222: undefined
> > reference to `g_dnl_unregister'
> > > cmd/built-in.o: In function `do_dfu':
> > > /home/kdubious/u-boot/cmd/dfu.c:56: undefined reference to
> > `g_dnl_clear_detach'
> > > /home/kdubious/u-boot/cmd/dfu.c:57: undefined reference to
> > `g_dnl_register'
> > > /home/kdubious/u-boot/cmd/dfu.c:59: undefined reference to
> > `g_dnl_detach'
> > > /home/kdubious/u-boot/cmd/dfu.c:106: undefined reference to
> > `g_dnl_unregister'
> > > /home/kdubious/u-boot/cmd/dfu.c:114: undefined reference to
> > `g_dnl_clear_detach'
> > > /home/kdubious/u-boot/cmd/dfu.c:27: undefined reference to
> > `dfu_defer_flush'
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24
> > > assertion fail ../../bfd/elf32-arm.c:7696
> > > arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not
> > > found in the linker script
> > > arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation
> > >
> > >
> > > Am doing something wrong?
> > 
> > It's likely some option to enable the gadget controller you use has moved to
> > Kconfig, re-run menuconfig/config/etc and enable it.
> > 
> > --
> > Tom
> 
> Hi Tom,
> 
> That seems to have fixed it where I can build, but now u-boot fails:
> 
> Net:   eth0: ethernet@01c5
> starting USB...
> USB0:   undefined instruction
> pc : [<6008>]  lr : [<7ef843b8>]
> reloc pc : []lr : [<4a0363b8>]
> sp : 7af25918  ip :  fp : c1c20bf2
> r10: 7af2fa70  r9 : 7af2dee0 r8 : 01c14000
> r7 :   r6 :  r5 :   r4 : 7af2fa80
> r3 : 6000  r2 : 015a70dc r1 : 01c20c00  r0 : 7af2fa80
> Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...

I would do a 'git log' on the relevant reference platforms to see what
else you might be missing.

-- 
Tom


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

Re: [U-Boot] [PATCH] drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info env

[Tom Rini]

On Fri, Apr 22, 2016 at 02:19:25PM +0530, Mugunthan V N wrote:

> U-Boot crashes when an invalid dfu_alt_info is set and tried
> using dfu command. Fixing this as it is handled in dfu-mmc.
> 
> => dfu 0 ram 0
> data abort
> pc : [<9ff893d6>]  lr : [<9ff6edb9>]
> reloc pc : [<808323d6>]lr : [<80817db9>]
> sp : 9ef36cf0  ip : 0158 fp : 9ffbc0b8
> r10: 9ffbc0b8  r9 : 9ef36ed8 r8 : 
> r7 :   r6 : 9ffbc0c8 r5 : 9ef36cfc  r4 : 9ef392c8
> r3 : 0004  r2 :  r1 : 9ff9a985  r0 : 
> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> Signed-off-by: Mugunthan V N 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Fri, Apr 22, 2016 at 12:08:20PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit ee8b25fa354da7cfaafe0e6781e873c74c29bbad:
> 
>   Prepare v2016.05-rc2 (2016-04-21 09:37:33 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git testing
> 
> for you to fetch changes up to 7b63b1832b6e7671c4009bc084045a19cd86c87c:
> 
>   x86: Correct typo of Miao Yan's email address (2016-04-22 11:26:32 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull ARC changes

[Tom Rini]

On Thu, Apr 21, 2016 at 05:11:40PM +, Alexey Brodkin wrote:

> Hi Tom,
> 
> The following changes since commit ee8b25fa354da7cfaafe0e6781e873c74c29bbad:
> 
>   Prepare v2016.05-rc2 (2016-04-21 09:37:33 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arc.git 
> 
> for you to fetch changes up to 2a8382c6fe7ddf0e15791b3ffa5f390a674a212b:
> 
>   arc/cache: really do flush_dcache_all() even if IOC exists (2016-04-21 
> 20:09:59 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] drivers/gpio/pm8916_gpio.c: Make pid be uint32_t

[Mateusz Kulikowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 20.04.2016 23:25, Tom Rini wrote:
> On Mon, Apr 18, 2016 at 10:23:24PM +0200, Mateusz Kulikowski wrote:
[..]

>>
>> I think (now, when the coverity pointed out mistake) that we should add
>> in that case check if pid fits in 16-bits, as this is maximum pid value on 
>> spmi bus.
>>
>> This checks should be done in pm8916_gpio_probe() and pm8916_probe().
>>
>> Would you like to do it in your series or want me to post another patch on 
>> top of them?
> 
> Please do a follow up, thanks!
> 
Will do that, but it will take a few days as I have a lot of non-coding related 
assignments now :)

btw. SPMI core checks pid and sid internally during reads/writes so we're 
pretty safe anyway.

Regards,
Mateusz
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXGjE2AAoJELvtohmVtQzBMj4H/3+zypiWH9BZdDheztNA6yZt
vN2fIz9kWQB8GFoBktU7kRAAWXaTDB0CWsKQmcqnJtZJeqyUV0Dj1CEJoS4fcptD
Lq0uljuufLkfkSb/XhRe5sLxWbvygHVrGBz/OemFCQivBlu8MEe4pwNyEUFwTHrc
otF9Uk1y92HjsyaQhjMX6WWR5Ei8hrVSryppt1eRFoGBAw9uL7TcKnc96IKrbFZ+
ns/40n/K8O2k8J2JMxMXB1QbJj/lEj/y4yY2Il2B2Z3WHb4ZhErtoko55uh0bGf4
PoGH1wPTZxNrcKn0CCwnHxmIxGJMpJ8XyZYhsEI4J+ZBs7izzb4dSn8ekOsr1nI=
=Y2ca
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unable to compile

[Tom Rini]

On Fri, Apr 22, 2016 at 03:33:13AM +, Kevin Welsh wrote:
> After moving to v2006.03, I can no longer compile with my existing defconfig:
> 
> 
> cmd/built-in.o: In function `do_fastboot':
> /home/kdubious/u-boot/cmd/fastboot.c:34: undefined reference to 
> `g_dnl_clear_detach'
> /home/kdubious/u-boot/cmd/fastboot.c:35: undefined reference to 
> `g_dnl_register'
> /home/kdubious/u-boot/cmd/fastboot.c:39: undefined reference to 
> `g_dnl_board_usb_cable_connected'
> /home/kdubious/u-boot/cmd/fastboot.c:47: undefined reference to `g_dnl_detach'
> /home/kdubious/u-boot/cmd/fastboot.c:57: undefined reference to 
> `g_dnl_unregister'
> /home/kdubious/u-boot/cmd/fastboot.c:58: undefined reference to 
> `g_dnl_clear_detach'
> cmd/built-in.o: In function `do_usb_mass_storage':
> /home/kdubious/u-boot/cmd/usb_mass_storage.c:159: undefined reference to 
> `fsg_init'
> /home/kdubious/u-boot/cmd/usb_mass_storage.c:166: undefined reference to 
> `g_dnl_register'
> /home/kdubious/u-boot/cmd/usb_mass_storage.c:176: undefined reference to 
> `g_dnl_board_usb_cable_connected'
> /home/kdubious/u-boot/cmd/usb_mass_storage.c:183: undefined reference to 
> `g_dnl_board_usb_cable_connected'
> /home/kdubious/u-boot/cmd/usb_mass_storage.c:206: undefined reference to 
> `fsg_main_thread'
> /home/kdubious/u-boot/cmd/usb_mass_storage.c:222: undefined reference to 
> `g_dnl_unregister'
> cmd/built-in.o: In function `do_dfu':
> /home/kdubious/u-boot/cmd/dfu.c:56: undefined reference to 
> `g_dnl_clear_detach'
> /home/kdubious/u-boot/cmd/dfu.c:57: undefined reference to `g_dnl_register'
> /home/kdubious/u-boot/cmd/dfu.c:59: undefined reference to `g_dnl_detach'
> /home/kdubious/u-boot/cmd/dfu.c:106: undefined reference to `g_dnl_unregister'
> /home/kdubious/u-boot/cmd/dfu.c:114: undefined reference to 
> `g_dnl_clear_detach'
> /home/kdubious/u-boot/cmd/dfu.c:27: undefined reference to `dfu_defer_flush'
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
> ../../bfd/elf32-arm.c:7696
> arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in 
> the linker script
> arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation
> 
> 
> Am doing something wrong?

It's likely some option to enable the gadget controller you use has
moved to Kconfig, re-run menuconfig/config/etc and enable it.

-- 
Tom


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

[U-Boot] Unable to compile

[Kevin Welsh]

After moving to v2006.03, I can no longer compile with my existing defconfig:


cmd/built-in.o: In function `do_fastboot':
/home/kdubious/u-boot/cmd/fastboot.c:34: undefined reference to 
`g_dnl_clear_detach'
/home/kdubious/u-boot/cmd/fastboot.c:35: undefined reference to `g_dnl_register'
/home/kdubious/u-boot/cmd/fastboot.c:39: undefined reference to 
`g_dnl_board_usb_cable_connected'
/home/kdubious/u-boot/cmd/fastboot.c:47: undefined reference to `g_dnl_detach'
/home/kdubious/u-boot/cmd/fastboot.c:57: undefined reference to 
`g_dnl_unregister'
/home/kdubious/u-boot/cmd/fastboot.c:58: undefined reference to 
`g_dnl_clear_detach'
cmd/built-in.o: In function `do_usb_mass_storage':
/home/kdubious/u-boot/cmd/usb_mass_storage.c:159: undefined reference to 
`fsg_init'
/home/kdubious/u-boot/cmd/usb_mass_storage.c:166: undefined reference to 
`g_dnl_register'
/home/kdubious/u-boot/cmd/usb_mass_storage.c:176: undefined reference to 
`g_dnl_board_usb_cable_connected'
/home/kdubious/u-boot/cmd/usb_mass_storage.c:183: undefined reference to 
`g_dnl_board_usb_cable_connected'
/home/kdubious/u-boot/cmd/usb_mass_storage.c:206: undefined reference to 
`fsg_main_thread'
/home/kdubious/u-boot/cmd/usb_mass_storage.c:222: undefined reference to 
`g_dnl_unregister'
cmd/built-in.o: In function `do_dfu':
/home/kdubious/u-boot/cmd/dfu.c:56: undefined reference to `g_dnl_clear_detach'
/home/kdubious/u-boot/cmd/dfu.c:57: undefined reference to `g_dnl_register'
/home/kdubious/u-boot/cmd/dfu.c:59: undefined reference to `g_dnl_detach'
/home/kdubious/u-boot/cmd/dfu.c:106: undefined reference to `g_dnl_unregister'
/home/kdubious/u-boot/cmd/dfu.c:114: undefined reference to `g_dnl_clear_detach'
/home/kdubious/u-boot/cmd/dfu.c:27: undefined reference to `dfu_defer_flush'
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the 
linker script
arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation


Am doing something wrong?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Richard Weinberger]

Heiko,

Am 22.04.2016 um 12:20 schrieb Heiko Schocher:
>> Think of places where work is scheduled but the caller blocked
>> the worker because the work has to be done later.
>> Fastmap is one of these use cases but AFAIK it won't matter
>> as no CPU scheduler is involved and will interrupt Fastmap.
> 
> Can you explain this a little bit?

As I said, when you are in a code region where parallel
work must not happen as it will, for example, confuse your state
you block the worker.
But you are still allowed to schedule new work which will
executed after you unblock it.
For the fastmap example I gave it should be fine but I didn't check
all code paths in UBI for u-boot single thread safety. :-)

What I wanted to say is that executing work directly at schedule
time does not match 1:1 the POV of Linux UBI and is error prone.
These are issues you won't notice by compile testing.

An alternative approach would be not executing work
directly while scheduling it but in produce_free_peb().
UBI is designed to work with the worker being disabled.
All UBI work will then happen synchronous and should also work
in u-boot.

>> In the long run I suggest removing the whole Linux UBI implementation
>> from u-boot and add a small (read only!) implementation which can
>> also read UBIFS. Reading UBIFS is not a big deal. Also journal reply
>> can be done in-memory.
> 
> Hmm.. I think read only is not for all boards an option, as we also
> create UBI Volumes and/or write to them in U-Boot ...

Depends.
IMHO a bootloader has exactly one job, loading a kernel
and booting it. And not being a poor man's general purpose operating
system where you can also do management stuff like managing UBI volumes. ;-)

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

[U-Boot] U-boot Stand alone Program

[karthik poojary]

Dear All,

I am trying to run standalone program Hello_world.bin on my
target.
My target is having arm imx6 processor.The board which I am using is not
supported by u-boot so I have done some changes to wandboard source files
since it had similar specs as my board . Now when I try to run standalone
on u-boot it resets or gets struck.

I would really appreciate any help I could get

PFA :Logfiles

Regards
Karthik Poojary


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

Re: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Richard Weinberger]

Am 21.04.2016 um 14:14 schrieb Boris Brezillon:
 No idea, if the correct fix not would be to move this erase_worker
 call after the attach phase ended, as Richard suggested, or if this
 fix is also valid ...
>>>
>>> I discussed that with Richard, and I think moving the ->free_count
>>> assignment before iterating over the ->erase list is a good solution.
>>
>> Ah! Ok, than its fine for me too.
>>
>>> I know the Linux code is assuming that the UBI thread is not launched
>>> yet when we call ubi_wl_init(), but to me it seems a bit risky to rely
>>> on this assumption (what if we do the UBI thread creation a bit
>>> earlier for some reason?). And, of course, as you explained, uboot does
>>> not know anything about threads, so all UBI works are executed
>>> synchronously, which makes this implementation buggy in uboot.
>>
>> Hmm... is it also a valid fix for linux then?
> 
> Well, it's not required, but it's making the code more future proof
> IMO. So again, I'll let Richard decide on this aspect.

As discussed with Boris, I'm not a huge fan of the said patch but I
understand the need for it.
Please send it to linux-mtd I'll apply it.

That said, the root cause of the whole issue is that due to the
single thread nature of u-boot UBI work is directly executed
at schedule time. For u-boot this works more or less.
But UBI allows work being scheduled when the background thread is
disabled/paused or not spawned.
The free_count patch papers exactly over one of these cases.
Let's hope that there are not other (more nasty) cases where
u-boot and Linux UBI behave differently.
Think of places where work is scheduled but the caller blocked
the worker because the work has to be done later.
Fastmap is one of these use cases but AFAIK it won't matter
as no CPU scheduler is involved and will interrupt Fastmap.

Boris and I worked the last months on a bigger UBI project
where we also had to port our UBI changes to u-boot.
Now I'm not so sure anymore whether it is a good idea to
copy UBI from Linux to u-boot. We faced a lot of
issues due to the single thread model. I changed the work
model in UBI to make locking less complicated. It turned out
that on u-boot it made things more complicated.
At least Boris had a lot of "fun". ;-)

In the long run I suggest removing the whole Linux UBI implementation
from u-boot and add a small (read only!) implementation which can
also read UBIFS. Reading UBIFS is not a big deal. Also journal reply
can be done in-memory.
Beside of code complexity it will also reduce u-boot's .text size.
Thomas' SPL patches are a very good start.
I'd also offer my help.

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

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Ian Campbell]

On Fri, 2016-04-22 at 14:12 +0100, Andre Przywara wrote:
> Hi,
> 
> On 22/04/16 13:09, Hans de Goede wrote:
> > 
> > Hi,
> > 
> > On 22-04-16 13:46, Andre Przywara wrote:
> > > 
> > > Hi Hans,
> > > 
> > > thanks for the information and the heads up!
> > > 
> > > On 22/04/16 11:48, Hans de Goede wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On 22-04-16 11:32, Ian Campbell wrote:
> > > > > 
> > > > > On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
> > > > > > 
> > > > > > > 
> > > > > > > I wonder if what you are observing could be possibly
> > > > > > > explained by
> > > > > > > just
> > > > > > > a usual data corruption problem? Which may be happening
> > > > > > > when the DRAM
> > > > > > > clock speed is set higher than this particular device is
> > > > > > > able to
> > > > > > > handle
> > > > > > > in a reliable way. Inserting just one or more NOP
> > > > > > > instructions
> > > > > > > instead
> > > > > > > of the barrier could possibly change some timings too.
> > > > > > > 
> > > > > > > If this patch helps, then it's fine. But I wonder if it
> > > > > > > is not merely
> > > > > > > making the problem latent instead of fixing the root
> > > > > > > cause?
> > > > > > I do believe that this patch addresses a real problem and
> > > > > > is not
> > > > > > hiding
> > > > > > some dram timing issues, I might be wrong about the write-
> > > > > > buffer being
> > > > > > the cause, it could simply be that the compiler is doing
> > > > > > something bad
> > > > > > (despite the accesses being marked as volatile)  and that
> > > > > > the DSB
> > > > > > stops
> > > > > > the compiler from optimizing things too much.
> > > > > I have a _very_ vague memory of seeing something not
> > > > > disimilar to this
> > > > > (apparent write buffer interactions with MMU disabled) in the
> > > > > early
> > > > > days of Xen development, but that was probably on models and
> > > > > so may not
> > > > > have been representative of the intended behaviour of
> > > > > eventual silicon.
> > > > > 
> > > > > It might be interesting to have a look at the generated
> > > > > assembly and
> > > > > see if it differs in more or less than the addition of the
> > > > > single
> > > > > instruction and perhaps experiment with just a compiler
> > > > > barrier.
> > > > > 
> > > > > Andre, do you have any insights on this?
> > > Agree on the compiler barrier, frankly I don't see how this
> > > should break
> > > with caches on or off unless the actual instruction order is
> > > wrong or
> > > the compiler optimized something away.
> > > Regardless of the write buffer the core should make sure the
> > > subsequent
> > > reads return the value written before - especially if we are
> > > talking UP
> > > here.
> > "the core should make sure the subsequent reads return the value
> > written
> > before"
> > that is exactly the problem, we are writing 2 different values
> > to so DRAM_BASE and DRAM_BASE + 512MiB, then read them both back
> > and compare them, expecting them to be the same (both reads
> > returning
> > the last written value) if the ramsize is 512MiB (this is used in
> > several places
> > in the dram controller code to auto-config number of rows, columns,
> > etc.).
> > 
> > But the core seems to just return the last written value,
> > rather then actually going out to the RAM and reading it from
> > there, which results in the function always returning false
> > (i.o.w. it claims no DRAM phys address wraparound is happening
> >  at 512MiB).
> Oh, right, I missed that part, sorry.
> So this is about physical aliasing?
> The DRAM controller has only n address lines connected, and changing a
> line >n shouldn't make a difference, right?

Correct, it's a technique used to try and size the DRAM by determing n
by observation of the aliasing patterns.

> And the write succeeds and does trigger an asynchronous abort?

                                 ^n't

> So I did a quick poll around the office and people say that "dsb" is the
> right thing to do here (with MMU off).
> As this is backed by practical experience, I'd just say: good to go!

Patch therefore:

Acked-by: Ian Campbell 

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

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Andre Przywara]

Hi,

On 22/04/16 13:09, Hans de Goede wrote:
> Hi,
> 
> On 22-04-16 13:46, Andre Przywara wrote:
>> Hi Hans,
>>
>> thanks for the information and the heads up!
>>
>> On 22/04/16 11:48, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 22-04-16 11:32, Ian Campbell wrote:
 On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
>> I wonder if what you are observing could be possibly explained by
>> just
>> a usual data corruption problem? Which may be happening when the DRAM
>> clock speed is set higher than this particular device is able to
>> handle
>> in a reliable way. Inserting just one or more NOP instructions
>> instead
>> of the barrier could possibly change some timings too.
>>
>> If this patch helps, then it's fine. But I wonder if it is not merely
>> making the problem latent instead of fixing the root cause?
> I do believe that this patch addresses a real problem and is not
> hiding
> some dram timing issues, I might be wrong about the write-buffer being
> the cause, it could simply be that the compiler is doing something bad
> (despite the accesses being marked as volatile)  and that the DSB
> stops
> the compiler from optimizing things too much.

 I have a _very_ vague memory of seeing something not disimilar to this
 (apparent write buffer interactions with MMU disabled) in the early
 days of Xen development, but that was probably on models and so may not
 have been representative of the intended behaviour of eventual silicon.

 It might be interesting to have a look at the generated assembly and
 see if it differs in more or less than the addition of the single
 instruction and perhaps experiment with just a compiler barrier.

 Andre, do you have any insights on this?
>>
>> Agree on the compiler barrier, frankly I don't see how this should break
>> with caches on or off unless the actual instruction order is wrong or
>> the compiler optimized something away.
>> Regardless of the write buffer the core should make sure the subsequent
>> reads return the value written before - especially if we are talking UP
>> here.
> 
> "the core should make sure the subsequent reads return the value written
> before"
> that is exactly the problem, we are writing 2 different values
> to so DRAM_BASE and DRAM_BASE + 512MiB, then read them both back
> and compare them, expecting them to be the same (both reads returning
> the last written value) if the ramsize is 512MiB (this is used in
> several places
> in the dram controller code to auto-config number of rows, columns, etc.).
> 
> But the core seems to just return the last written value,
> rather then actually going out to the RAM and reading it from
> there, which results in the function always returning false
> (i.o.w. it claims no DRAM phys address wraparound is happening
>  at 512MiB).

Oh, right, I missed that part, sorry.
So this is about physical aliasing?
The DRAM controller has only n address lines connected, and changing a
line >n shouldn't make a difference, right?
And the write succeeds and does trigger an asynchronous abort?

In this case you would indeed need some kind of "flushing", with caches
on I'd say a DCCIMVAC (Clean and Invalidate data or unified cache line
by MVA to PoC).

So I did a quick poll around the office and people say that "dsb" is the
right thing to do here (with MMU off).
As this is backed by practical experience, I'd just say: good to go!


> The DSB seems to fix this, but it might very well be the
> compiler being to clever (although all accesses are done
> through volatile pointers, so it really should not).

Plus those writel and readl macros already have a compiler barrier,
though on the "wrong" side for our purpose (before the write and after
the read).

Cheers,
Andre.

> 
> I'll try the barrier() fix when I've some time.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
>>
>>>
>>> Andre here is the original mail/patch for reference:
>>>
>>>  sunxi: mctl_mem_matches: Add missing memory barrier
>>>
>>>  We are running with the caches disabled when mctl_mem_matches gets
>>> called,
>>>  but the cpu's write buffer is still there and can still get in
>>> the way,
>>>  add a memory barrier to fix this.
>>>
>>>  This avoids mctl_mem_matches always returning false in some cases,
>>> which
>>>  was resulting in:
>>>
>>> 
>>>
>>> @@ -31,6 +32,7 @@ bool mctl_mem_matches(u32 offset)
>>>   /* Try to write different values to RAM at two addresses */
>>>   writel(0, CONFIG_SYS_SDRAM_BASE);
>>>   writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
>>> +DSB;
>>>   /* Check if the same value is actually observed when reading
>>> back */
>>>   return readl(CONFIG_SYS_SDRAM_BASE) ==
>>>  readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
>>>
>>>
>>> What this code is trying to do is determine RAM (chip) size by seeing
>>> when
>>> writing to RAM wrapsaround.
>>>
>>> This works with 

Re: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Boris Brezillon]

On Fri, 22 Apr 2016 13:53:00 +0200
Heiko Schocher  wrote:

> 
> > An alternative approach would be not executing work
> > directly while scheduling it but in produce_free_peb().
> > UBI is designed to work with the worker being disabled.
> > All UBI work will then happen synchronous and should also work
> > in u-boot.
> 
> Sounds good!

Not so good actually. I tried that, and ended up with tasks stalled in
the work queue because the implementation was never "scheduling" the
do_work() loop.

Let's keep it simple, in uboot everything is synchronous, and you can't
be preempted by another task, so it's safe to assume that "scheduling a
work" == "executing it right away". IMHO, the kernel should also assume
that "scheduling a work" might involve "the work may have been done
before the ubi_schedule_work() function returns": when you schedule a
work to be done and wake up the thread responsible for dequeuing UBI
works, the scheduler can decide to schedule this thread right away,
which means this work can be done before the caller gets back to the
instruction just after ubi_schedule_work().

Of course, this has to be nuanced for the "attach procedure", because at
this time the UBI thread is not launched yet. But even in this
specific case, I think it's safer to assume that, maybe one day, the UBI
thread might be running when ubi_wl_init() is called, which is why I
suggested to also apply this patch to Linux.

> 
> >>> In the long run I suggest removing the whole Linux UBI implementation
> >>> from u-boot and add a small (read only!) implementation which can
> >>> also read UBIFS. Reading UBIFS is not a big deal. Also journal reply
> >>> can be done in-memory.
> >>
> >> Hmm.. I think read only is not for all boards an option, as we also
> >> create UBI Volumes and/or write to them in U-Boot ...
> >
> > Depends.
> > IMHO a bootloader has exactly one job, loading a kernel
> > and booting it. And not being a poor man's general purpose operating
> > system where you can also do management stuff like managing UBI volumes. ;-)
> 
> Heh...

That's another topic ;).

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SAMA5D2 xplained SD/eMMC boot

[Marek Vasut]

On 04/22/2016 02:54 AM, Yang, Wenyou wrote:
> Hi Marek,

Hi!

>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: 2016年4月21日 10:59
>> To: Yang, Wenyou 
>> Cc: u-boot@lists.denx.de
>> Subject: Re: SAMA5D2 xplained SD/eMMC boot
>>
>> On 04/21/2016 04:46 AM, Yang, Wenyou wrote:
>>> Hi,
>>
>> Hi!
>>
>> [...]
>> pile of unnecessary email headers redacted.
>> [...]
>>
>> Hi!
>>
>> I've been playing around with latest mainline u-boot on sama5d2
>> xplained ultra. I noticed that if I want to boot the board from
>> SD card (SDHCI1), the board will indeed load the SPL from it,
>> but SPL will try to load u-boot.img from eMMC
>> (SDHCI0) and fail, as my eMMC is blank.
>
> Yes, there is some issue to load u-boot.img. I found there is
> something to do on
 sdhci.c.
>
> You can try this branch, it should works.
>
> https://github.com/linux4sam/u-boot-at91/commits/u-boot-2016.03-
> at
> 91

 I am not interested in using non-mainline stuff. Do you have any
 particular patch/commit which I can refer to ? I do not think
 this has anything to do with sdhci.c driver at all, it has to do
 with detecting the boot device from which SPL was started and
 loading u-boot.img from the same boot device instead of always using
>> SDHCI0.
>>>
>>> I will test the mainline code. I will let you know when I get something.
>>
>> OK.
>>
>> Does the SoC have any sort of register which lists the current boot 
>> device ?
>
> In this SoC, there is not register to list the current boot device.

 And thus, it is not possible to detect at runtime from which device
 the SoC booted and thus load u-boot.img from the same device. Correct ?
>>>
>>> Yes,
>>
>> Ha, thanks for confirming.
> 
> Sorry, can I correct what I said yesterday?

What if I said "no" ? :-)

> There is a register to list the boot information exported by ROMCode.
> 
> The boot information is stored in R4 register when the ROMCode jumps to the 
> bootstrap. 

Ha, so the U-Boot SPL can save the r4 register early in the boot and
extract the boot device from it. That's neat. Thanks!

> Here is the contents definitions R4 on the SAMA5D2 (improved compared to old 
> MPUs to take care of IOSet features).

Is this stuff somewhere in the SAMA5Dx datasheet ? It'd be nice to
know/have this information for other SAMA5Dx too (d3 and d4).

> /* bootFrom ID Definitions */
> #define BOOT_FROM_KEY (0xBAu << 24)
> 
> #define BOOT_FROM_SPI (0x0u << 0)
> #define BOOT_FROM_MCI (0x1u << 0)
> #define BOOT_FROM_SMC (0x2u << 0)
> #define BOOT_FROM_TWI (0x3u << 0)
> #define BOOT_FROM_QSPI(0x4u << 0)
> 
> /* ID number of the IP from the data sheet */
> #define BOOT_FROM_ID0   (0x0u << 4)
> #define BOOT_FROM_ID1   (0x1u << 4)
> #define BOOT_FROM_ID2   (0x2u << 4)
> #define BOOT_FROM_ID3   (0x3u << 4)
> #define BOOT_FROM_ID4   (0x4u << 4)
> 
> #define BOOT_FROM_ID_Pos  4
> #define BOOT_FROM_ID_Msk  (0xfu << BOOT_FROM_ID_Pos)
> #define BOOT_FROM_ID(value)   ((BOOT_FROM_ID_Msk & ((value) << 
> BOOT_FROM_ID_Pos)))
> 
> #define BOOT_FROM_TYPE_SD_OR_AT25 (0x0u << 8)
> #define BOOT_FROM_TYPE_MMC_OR_AT45  (0x1u << 8)
> #define BOOT_FROM_TYPE_EMMC   (0x2u << 8)
> 
> /* QSPI serial flashes */
> #define BOOT_FROM_TYPE_SPANSION   (0x0u << 8)
> #define BOOT_FROM_TYPE_MICRON (0x1u << 8)
> #define BOOT_FROM_TYPE_MACRONIX   (0x2u << 8)
> 
> /* Chip Select or (MCI) Slot identifier used in code by the IP. */
> #define BOOT_FROM_CS0   (0x0u << 12) // Slot A
> #define BOOT_FROM_CS1   (0x1u << 12) // Slot B
> #define BOOT_FROM_CS2   (0x2u << 12) // Slot C
> #define BOOT_FROM_CS3   (0x3u << 12) // Slot D
> #define BOOT_FROM_CS4   (0x4u << 12)
> 
> #define BOOT_FROM_CS_Pos12
> #define BOOT_FROM_CS_Msk(0xfu << BOOT_FROM_CS_Pos)
> #define BOOT_FROM_CS(value) ((BOOT_FROM_CS_Msk & ((value) << 
> BOOT_FROM_CS_Pos)))
> 
> #define BOOT_FROM_IOSET_Pos 16
> #define BOOT_FROM_IOSET_Msk (0x3u << BOOT_FROM_IOSET_Pos)
> #define BOOT_FROM_IOSET(value)   ((BOOT_FROM_IOSET_Msk & ((value) << 
> BOOT_FROM_IOSET_Pos)))>>
> 
> 
>> [...]
>>
>> --
>> Best regards,
>> Marek Vasut
> 
> Sorry for incorrect information before.

No problem, thanks for the update!

> Best Regards,
> Wenyou Yang
> 


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

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Hans de Goede]

Hi,

On 22-04-16 13:46, Andre Przywara wrote:

Hi Hans,

thanks for the information and the heads up!

On 22/04/16 11:48, Hans de Goede wrote:

Hi,

On 22-04-16 11:32, Ian Campbell wrote:

On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:

I wonder if what you are observing could be possibly explained by just
a usual data corruption problem? Which may be happening when the DRAM
clock speed is set higher than this particular device is able to handle
in a reliable way. Inserting just one or more NOP instructions instead
of the barrier could possibly change some timings too.

If this patch helps, then it's fine. But I wonder if it is not merely
making the problem latent instead of fixing the root cause?

I do believe that this patch addresses a real problem and is not hiding
some dram timing issues, I might be wrong about the write-buffer being
the cause, it could simply be that the compiler is doing something bad
(despite the accesses being marked as volatile)  and that the DSB stops
the compiler from optimizing things too much.


I have a _very_ vague memory of seeing something not disimilar to this
(apparent write buffer interactions with MMU disabled) in the early
days of Xen development, but that was probably on models and so may not
have been representative of the intended behaviour of eventual silicon.

It might be interesting to have a look at the generated assembly and
see if it differs in more or less than the addition of the single
instruction and perhaps experiment with just a compiler barrier.

Andre, do you have any insights on this?


Agree on the compiler barrier, frankly I don't see how this should break
with caches on or off unless the actual instruction order is wrong or
the compiler optimized something away.
Regardless of the write buffer the core should make sure the subsequent
reads return the value written before - especially if we are talking UP
here.


"the core should make sure the subsequent reads return the value written before"
that is exactly the problem, we are writing 2 different values
to so DRAM_BASE and DRAM_BASE + 512MiB, then read them both back
and compare them, expecting them to be the same (both reads returning
the last written value) if the ramsize is 512MiB (this is used in several places
in the dram controller code to auto-config number of rows, columns, etc.).

But the core seems to just return the last written value,
rather then actually going out to the RAM and reading it from
there, which results in the function always returning false
(i.o.w. it claims no DRAM phys address wraparound is happening
 at 512MiB).

The DSB seems to fix this, but it might very well be the
compiler being to clever (although all accesses are done
through volatile pointers, so it really should not).

I'll try the barrier() fix when I've some time.

Regards,

Hans








Andre here is the original mail/patch for reference:

 sunxi: mctl_mem_matches: Add missing memory barrier

 We are running with the caches disabled when mctl_mem_matches gets
called,
 but the cpu's write buffer is still there and can still get in the way,
 add a memory barrier to fix this.

 This avoids mctl_mem_matches always returning false in some cases,
which
 was resulting in:



@@ -31,6 +32,7 @@ bool mctl_mem_matches(u32 offset)
  /* Try to write different values to RAM at two addresses */
  writel(0, CONFIG_SYS_SDRAM_BASE);
  writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
+DSB;
  /* Check if the same value is actually observed when reading back */
  return readl(CONFIG_SYS_SDRAM_BASE) ==
 readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);


What this code is trying to do is determine RAM (chip) size by seeing when
writing to RAM wrapsaround.

This works with the DSB but not without (without it always returns false)
this is on a Cortex A7 with the mmu (and data caches) disabled.

Ian, I can try using just a compiler barrier, but I've never done so
before, how do I insert one ?


barrier();

I am busy at the moment, but will take a look later.

Cheers,
Andre.


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

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Andre Przywara]

Hi Hans,

thanks for the information and the heads up!

On 22/04/16 11:48, Hans de Goede wrote:
> Hi,
> 
> On 22-04-16 11:32, Ian Campbell wrote:
>> On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
 I wonder if what you are observing could be possibly explained by just
 a usual data corruption problem? Which may be happening when the DRAM
 clock speed is set higher than this particular device is able to handle
 in a reliable way. Inserting just one or more NOP instructions instead
 of the barrier could possibly change some timings too.

 If this patch helps, then it's fine. But I wonder if it is not merely
 making the problem latent instead of fixing the root cause?
>>> I do believe that this patch addresses a real problem and is not hiding
>>> some dram timing issues, I might be wrong about the write-buffer being
>>> the cause, it could simply be that the compiler is doing something bad
>>> (despite the accesses being marked as volatile)  and that the DSB stops
>>> the compiler from optimizing things too much.
>>
>> I have a _very_ vague memory of seeing something not disimilar to this
>> (apparent write buffer interactions with MMU disabled) in the early
>> days of Xen development, but that was probably on models and so may not
>> have been representative of the intended behaviour of eventual silicon.
>>
>> It might be interesting to have a look at the generated assembly and
>> see if it differs in more or less than the addition of the single
>> instruction and perhaps experiment with just a compiler barrier.
>>
>> Andre, do you have any insights on this?

Agree on the compiler barrier, frankly I don't see how this should break
with caches on or off unless the actual instruction order is wrong or
the compiler optimized something away.
Regardless of the write buffer the core should make sure the subsequent
reads return the value written before - especially if we are talking UP
here.

> 
> Andre here is the original mail/patch for reference:
> 
> sunxi: mctl_mem_matches: Add missing memory barrier
> 
> We are running with the caches disabled when mctl_mem_matches gets
> called,
> but the cpu's write buffer is still there and can still get in the way,
> add a memory barrier to fix this.
> 
> This avoids mctl_mem_matches always returning false in some cases,
> which
> was resulting in:
> 
> 
> 
> @@ -31,6 +32,7 @@ bool mctl_mem_matches(u32 offset)
>  /* Try to write different values to RAM at two addresses */
>  writel(0, CONFIG_SYS_SDRAM_BASE);
>  writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> +DSB;
>  /* Check if the same value is actually observed when reading back */
>  return readl(CONFIG_SYS_SDRAM_BASE) ==
> readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
> 
> 
> What this code is trying to do is determine RAM (chip) size by seeing when
> writing to RAM wrapsaround.
> 
> This works with the DSB but not without (without it always returns false)
> this is on a Cortex A7 with the mmu (and data caches) disabled.
> 
> Ian, I can try using just a compiler barrier, but I've never done so
> before, how do I insert one ?

barrier();

I am busy at the moment, but will take a look later.

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

[U-Boot] [PATCH] mmc: sdhci: add const qualifier to the name of struct sdhci_host

[Masahiro Yamada]

This allows to drop annoying (char *) casts when setting the host
name of struct sdhci_host.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/pci_mmc.c | 2 +-
 drivers/mmc/pic32_sdhci.c | 2 +-
 drivers/mmc/zynq_sdhci.c  | 2 +-
 include/sdhci.h   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c
index 5fb7151..340eef6 100644
--- a/drivers/mmc/pci_mmc.c
+++ b/drivers/mmc/pci_mmc.c
@@ -28,7 +28,7 @@ int pci_mmc_init(const char *name, struct pci_device_id 
*mmc_supported)
if (!mmc_host)
return -ENOMEM;
 
-   mmc_host->name = (char *)name;
+   mmc_host->name = name;
dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
mmc_host->ioaddr = (void *)iobase;
mmc_host->quirks = 0;
diff --git a/drivers/mmc/pic32_sdhci.c b/drivers/mmc/pic32_sdhci.c
index 28da55d..e03d6dd 100644
--- a/drivers/mmc/pic32_sdhci.c
+++ b/drivers/mmc/pic32_sdhci.c
@@ -29,7 +29,7 @@ static int pic32_sdhci_probe(struct udevice *dev)
return -EINVAL;
 
host->ioaddr= ioremap(addr, size);
-   host->name  = (char *)dev->name;
+   host->name  = dev->name;
host->quirks= SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_NO_CD;
host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
"bus-width", 4);
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 039ec16..b59feca 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -43,7 +43,7 @@ static int arasan_sdhci_ofdata_to_platdata(struct udevice 
*dev)
 {
struct sdhci_host *host = dev_get_priv(dev);
 
-   host->name = (char *)dev->name;
+   host->name = dev->name;
host->ioaddr = (void *)dev_get_addr(dev);
 
return 0;
diff --git a/include/sdhci.h b/include/sdhci.h
index 23893b5..e0f6667 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -235,7 +235,7 @@ struct sdhci_ops {
 };
 
 struct sdhci_host {
-   char *name;
+   const char *name;
void *ioaddr;
unsigned int quirks;
unsigned int host_caps;
-- 
1.9.1

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

Re: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Heiko Schocher]

Hello Richard,

Am 22.04.2016 um 12:48 schrieb Richard Weinberger:

Heiko,

Am 22.04.2016 um 12:20 schrieb Heiko Schocher:

Think of places where work is scheduled but the caller blocked
the worker because the work has to be done later.
Fastmap is one of these use cases but AFAIK it won't matter
as no CPU scheduler is involved and will interrupt Fastmap.


Can you explain this a little bit?


As I said, when you are in a code region where parallel
work must not happen as it will, for example, confuse your state
you block the worker.
But you are still allowed to schedule new work which will
executed after you unblock it.
For the fastmap example I gave it should be fine but I didn't check
all code paths in UBI for u-boot single thread safety. :-)

What I wanted to say is that executing work directly at schedule
time does not match 1:1 the POV of Linux UBI and is error prone.
These are issues you won't notice by compile testing.


Ok, thanks for the explanation!


An alternative approach would be not executing work
directly while scheduling it but in produce_free_peb().
UBI is designed to work with the worker being disabled.
All UBI work will then happen synchronous and should also work
in u-boot.


Sounds good!


In the long run I suggest removing the whole Linux UBI implementation
from u-boot and add a small (read only!) implementation which can
also read UBIFS. Reading UBIFS is not a big deal. Also journal reply
can be done in-memory.


Hmm.. I think read only is not for all boards an option, as we also
create UBI Volumes and/or write to them in U-Boot ...


Depends.
IMHO a bootloader has exactly one job, loading a kernel
and booting it. And not being a poor man's general purpose operating
system where you can also do management stuff like managing UBI volumes. ;-)


Heh...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] EHCI timed out on TD - token=0x80008d80

[Marek Vasut]

On 04/22/2016 09:19 AM, Manjunath wrote:
> Hello Marek,
> 
> I checked with mainline uboot as well. The issue is now clearer.  Here are 
> some info:
> 
> 1. The board uses SMARC module 
> 2. Whenever reboot command is given the usb is detected correctly.
> 3. When i give a hard reset, the following log is seen.
> 
> U-Boot > usb start
> (Re)start USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
> 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> 
> 4. Again i boot and do a soft reboot, the same USB is detected.
> 
> This is definitely something related to power.
> 
> 
> This is something mysterious for me. Anybody has any clue please let me know.

Try setenv usb_pgood_delay 1 , increases delay after enabling port
power.

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

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Hans de Goede]

Hi,

On 22-04-16 11:32, Ian Campbell wrote:

On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:

I wonder if what you are observing could be possibly explained by just
a usual data corruption problem? Which may be happening when the DRAM
clock speed is set higher than this particular device is able to handle
in a reliable way. Inserting just one or more NOP instructions instead
of the barrier could possibly change some timings too.

If this patch helps, then it's fine. But I wonder if it is not merely
making the problem latent instead of fixing the root cause?

I do believe that this patch addresses a real problem and is not hiding
some dram timing issues, I might be wrong about the write-buffer being
the cause, it could simply be that the compiler is doing something bad
(despite the accesses being marked as volatile)  and that the DSB stops
the compiler from optimizing things too much.


I have a _very_ vague memory of seeing something not disimilar to this
(apparent write buffer interactions with MMU disabled) in the early
days of Xen development, but that was probably on models and so may not
have been representative of the intended behaviour of eventual silicon.

It might be interesting to have a look at the generated assembly and
see if it differs in more or less than the addition of the single
instruction and perhaps experiment with just a compiler barrier.

Andre, do you have any insights on this?


Andre here is the original mail/patch for reference:

sunxi: mctl_mem_matches: Add missing memory barrier

We are running with the caches disabled when mctl_mem_matches gets called,
but the cpu's write buffer is still there and can still get in the way,
add a memory barrier to fix this.

This avoids mctl_mem_matches always returning false in some cases, which
was resulting in:



@@ -31,6 +32,7 @@ bool mctl_mem_matches(u32 offset)
/* Try to write different values to RAM at two addresses */
writel(0, CONFIG_SYS_SDRAM_BASE);
writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
+   DSB;
/* Check if the same value is actually observed when reading back */
return readl(CONFIG_SYS_SDRAM_BASE) ==
   readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);


What this code is trying to do is determine RAM (chip) size by seeing when
writing to RAM wrapsaround.

This works with the DSB but not without (without it always returns false)
this is on a Cortex A7 with the mmu (and data caches) disabled.

Ian, I can try using just a compiler barrier, but I've never done so
before, how do I insert one ?

Regards,

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

Re: [U-Boot] [PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Heiko Schocher]

Hello Richard,

Am 22.04.2016 um 11:34 schrieb Richard Weinberger:

Am 21.04.2016 um 14:14 schrieb Boris Brezillon:

No idea, if the correct fix not would be to move this erase_worker
call after the attach phase ended, as Richard suggested, or if this
fix is also valid ...


I discussed that with Richard, and I think moving the ->free_count
assignment before iterating over the ->erase list is a good solution.


Ah! Ok, than its fine for me too.


I know the Linux code is assuming that the UBI thread is not launched
yet when we call ubi_wl_init(), but to me it seems a bit risky to rely
on this assumption (what if we do the UBI thread creation a bit
earlier for some reason?). And, of course, as you explained, uboot does
not know anything about threads, so all UBI works are executed
synchronously, which makes this implementation buggy in uboot.


Hmm... is it also a valid fix for linux then?


Well, it's not required, but it's making the code more future proof
IMO. So again, I'll let Richard decide on this aspect.


As discussed with Boris, I'm not a huge fan of the said patch but I
understand the need for it.
Please send it to linux-mtd I'll apply it.


Ok, done.


That said, the root cause of the whole issue is that due to the
single thread nature of u-boot UBI work is directly executed
at schedule time. For u-boot this works more or less.
But UBI allows work being scheduled when the background thread is
disabled/paused or not spawned.
The free_count patch papers exactly over one of these cases.
Let's hope that there are not other (more nasty) cases where
u-boot and Linux UBI behave differently.


:-(


Think of places where work is scheduled but the caller blocked
the worker because the work has to be done later.
Fastmap is one of these use cases but AFAIK it won't matter
as no CPU scheduler is involved and will interrupt Fastmap.


Can you explain this a little bit?


Boris and I worked the last months on a bigger UBI project
where we also had to port our UBI changes to u-boot.
Now I'm not so sure anymore whether it is a good idea to
copy UBI from Linux to u-boot. We faced a lot of
issues due to the single thread model. I changed the work
model in UBI to make locking less complicated. It turned out
that on u-boot it made things more complicated.
At least Boris had a lot of "fun". ;-)


Heh...


In the long run I suggest removing the whole Linux UBI implementation
from u-boot and add a small (read only!) implementation which can
also read UBIFS. Reading UBIFS is not a big deal. Also journal reply
can be done in-memory.


Hmm.. I think read only is not for all boards an option, as we also
create UBI Volumes and/or write to them in U-Boot ...


Beside of code complexity it will also reduce u-boot's .text size.
Thomas' SPL patches are a very good start.


Yes, I hope to get soon an Ack/Response from Ladislav and/or Enric,
so we can integrate them into mainline.


I'd also offer my help.


Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info env

[Lukasz Majewski]

Hi Mugunthan,

> U-Boot crashes when an invalid dfu_alt_info is set and tried
> using dfu command. Fixing this as it is handled in dfu-mmc.
> 
> => dfu 0 ram 0
> data abort
> pc : [<9ff893d6>]  lr : [<9ff6edb9>]
> reloc pc : [<808323d6>]lr : [<80817db9>]
> sp : 9ef36cf0  ip : 0158 fp : 9ffbc0b8
> r10: 9ffbc0b8  r9 : 9ef36ed8 r8 : 
> r7 :   r6 : 9ffbc0c8 r5 : 9ef36cfc  r4 : 9ef392c8
> r3 : 0004  r2 :  r1 : 9ff9a985  r0 : 
> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> Signed-off-by: Mugunthan V N 
> ---
> 
> Verified this on AM335x BBB, added logs [1] without fix and with fix
> 
> [1]: http://pastebin.ubuntu.com/15978003/
> 
> ---
>  drivers/dfu/dfu_ram.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
> index e094a94..1391a0d 100644
> --- a/drivers/dfu/dfu_ram.c
> +++ b/drivers/dfu/dfu_ram.c
> @@ -54,19 +54,26 @@ static int dfu_read_medium_ram(struct dfu_entity
> *dfu, u64 offset, 
>  int dfu_fill_entity_ram(struct dfu_entity *dfu, char *devstr, char
> *s) {
> - char *st;
> + const char *argv[3];
> + const char **parg = argv;
> +
> + for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
> + *parg = strsep(, " ");
> + if (*parg == NULL) {
> + error("Invalid number of arguments.\n");
> + return -ENODEV;
> + }
> + }
>  
>   dfu->dev_type = DFU_DEV_RAM;
> - st = strsep(, " ");
> - if (strcmp(st, "ram")) {
> - error("unsupported device: %s\n", st);
> + if (strcmp(argv[0], "ram")) {
> + error("unsupported device: %s\n", argv[0]);
>   return -ENODEV;
>   }
>  
>   dfu->layout = DFU_RAM_ADDR;
> - dfu->data.ram.start = (void *)simple_strtoul(s, , 16);
> - s++;
> - dfu->data.ram.size = simple_strtoul(s, , 16);
> + dfu->data.ram.start = (void *)simple_strtoul(argv[1], NULL,
> 0);
> + dfu->data.ram.size = simple_strtoul(argv[2], NULL, 0);
>  
>   dfu->write_medium = dfu_write_medium_ram;
>   dfu->get_medium_size = dfu_get_medium_size_ram;

Acked-by: Lukasz Majewski 

Build tested with buildman:
./tools/buildman/buildman.py --branch=HEAD ti --detail --verbose
--show_errors --force-build --count=9 --output-dir=./BUILD/

-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Enable LDO3 at 3.3V on A13-OLinuXino board

[Ian Campbell]

On Thu, 2016-04-14 at 16:51 +0200, Hans de Goede wrote:
> LDO3 is used for the VGA output, this fixes a regression where the
> VGA
> output on these boards would no longer work.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

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

Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier

[Ian Campbell]

On Fri, 2016-04-15 at 09:34 +0200, Hans de Goede wrote:
> > I wonder if what you are observing could be possibly explained by just
> > a usual data corruption problem? Which may be happening when the DRAM
> > clock speed is set higher than this particular device is able to handle
> > in a reliable way. Inserting just one or more NOP instructions instead
> > of the barrier could possibly change some timings too.
> > 
> > If this patch helps, then it's fine. But I wonder if it is not merely
> > making the problem latent instead of fixing the root cause?
> I do believe that this patch addresses a real problem and is not hiding
> some dram timing issues, I might be wrong about the write-buffer being
> the cause, it could simply be that the compiler is doing something bad
> (despite the accesses being marked as volatile)  and that the DSB stops
> the compiler from optimizing things too much.

I have a _very_ vague memory of seeing something not disimilar to this
(apparent write buffer interactions with MMU disabled) in the early
days of Xen development, but that was probably on models and so may not
have been representative of the intended behaviour of eventual silicon.

It might be interesting to have a look at the generated assembly and
see if it differs in more or less than the addition of the single
instruction and perhaps experiment with just a compiler barrier.

Andre, do you have any insights on this?

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

[U-Boot] [PATCH] usb: mass storage: Initialize ret variable to zero

[Lukasz Majewski]

Up till now this variable wasn't initialized. However, now GCC (4.9.2)
is complaining about it.

To suppress this waning this automatic variable has been set to 0.

Signed-off-by: Lukasz Majewski 
---
 cmd/usb_mass_storage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
index ac53a73..101a87e 100644
--- a/cmd/usb_mass_storage.c
+++ b/cmd/usb_mass_storage.c
@@ -56,7 +56,7 @@ static int ums_init(const char *devtype, const char 
*devnums_part_str)
struct blk_desc *block_dev;
disk_partition_t info;
int partnum;
-   int ret;
+   int ret = 0;
struct ums *ums_new;
 
s = strdup(devnums_part_str);
-- 
2.0.0.rc2

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

[U-Boot] [PATCH] drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info env

[Mugunthan V N]

U-Boot crashes when an invalid dfu_alt_info is set and tried
using dfu command. Fixing this as it is handled in dfu-mmc.

=> dfu 0 ram 0
data abort
pc : [<9ff893d6>]  lr : [<9ff6edb9>]
reloc pc : [<808323d6>]lr : [<80817db9>]
sp : 9ef36cf0  ip : 0158 fp : 9ffbc0b8
r10: 9ffbc0b8  r9 : 9ef36ed8 r8 : 
r7 :   r6 : 9ffbc0c8 r5 : 9ef36cfc  r4 : 9ef392c8
r3 : 0004  r2 :  r1 : 9ff9a985  r0 : 
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

resetting ...

Signed-off-by: Mugunthan V N 
---

Verified this on AM335x BBB, added logs [1] without fix and with fix

[1]: http://pastebin.ubuntu.com/15978003/

---
 drivers/dfu/dfu_ram.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
index e094a94..1391a0d 100644
--- a/drivers/dfu/dfu_ram.c
+++ b/drivers/dfu/dfu_ram.c
@@ -54,19 +54,26 @@ static int dfu_read_medium_ram(struct dfu_entity *dfu, u64 
offset,
 
 int dfu_fill_entity_ram(struct dfu_entity *dfu, char *devstr, char *s)
 {
-   char *st;
+   const char *argv[3];
+   const char **parg = argv;
+
+   for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
+   *parg = strsep(, " ");
+   if (*parg == NULL) {
+   error("Invalid number of arguments.\n");
+   return -ENODEV;
+   }
+   }
 
dfu->dev_type = DFU_DEV_RAM;
-   st = strsep(, " ");
-   if (strcmp(st, "ram")) {
-   error("unsupported device: %s\n", st);
+   if (strcmp(argv[0], "ram")) {
+   error("unsupported device: %s\n", argv[0]);
return -ENODEV;
}
 
dfu->layout = DFU_RAM_ADDR;
-   dfu->data.ram.start = (void *)simple_strtoul(s, , 16);
-   s++;
-   dfu->data.ram.size = simple_strtoul(s, , 16);
+   dfu->data.ram.start = (void *)simple_strtoul(argv[1], NULL, 0);
+   dfu->data.ram.size = simple_strtoul(argv[2], NULL, 0);
 
dfu->write_medium = dfu_write_medium_ram;
dfu->get_medium_size = dfu_get_medium_size_ram;
-- 
2.8.1.101.g72d917a

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

[U-Boot] [PATCH v2 1/2] arm: Fix SCFG ICID reg addresses

[Vincent Siles]

On the LS102x boards, in order to initialize the ICID values of masters,
the dev_stream_id array holds absolute offsets from the base of SCFG.

In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
before adding the offset, leading to an invalid address. Casting it to
void * solves the issue.

Signed-off-by: Vincent Siles 
---

Changes in v2:
- switch from (u8 *) to (void *)
- split modifications in two patches

 board/freescale/common/ls102xa_stream_id.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/freescale/common/ls102xa_stream_id.c 
b/board/freescale/common/ls102xa_stream_id.c
index f434269..39e7b30 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -10,11 +10,11 @@
 
 void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
 {
-   uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
+   void *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
int i;
 
for (i = 0; i < num; i++)
-   out_be32(scfg + id[i].offset, id[i].stream_id);
+   out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
 }
 
 void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
-- 
1.9.1

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

[U-Boot] [PATCH v2 2/2] arm: uniform usage of u32 in ls102x caam config

[Vincent Siles]

Mix usage of uint32_t and u32 fixed in favor of u32

Signed-off-by: Vincent Siles 

---

Changes in v2:
- Casting to void * instead of u8 *
- Splitted commit into two seperate ones

 board/freescale/common/ls102xa_stream_id.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/common/ls102xa_stream_id.c 
b/board/freescale/common/ls102xa_stream_id.c
index 39e7b30..3d5404e 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table 
*tbl, int size)
else
liodn = tbl[i].id[0];
 
-   out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
+   out_le32((u32 *)(tbl[i].reg_offset), liodn);
}
 }
-- 
1.9.1

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

Re: [U-Boot] EHCI timed out on TD - token=0x80008d80

[Manjunath]

Hello Marek,

I checked with mainline uboot as well. The issue is now clearer.  Here are some 
info:

1. The board uses SMARC module 
2. Whenever reboot command is given the usb is detected correctly.
3. When i give a hard reset, the following log is seen.

U-Boot > usb start
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found

4. Again i boot and do a soft reboot, the same USB is detected.

This is definitely something related to power.


This is something mysterious for me. Anybody has any clue please let me know.


Regards,
Manju



- Original Message -
From: "Marek Vasut" 
To: "u-boot" 
Cc: "Manjunath" , "fabio estevam" 
Sent: Thursday, April 21, 2016 3:44:48 PM
Subject: Re: EHCI timed out on TD - token=0x80008d80

On 04/21/2016 08:25 AM, Manjunath wrote:
> Hello Marek,

Hi

> If the USB is detected successfully, then below are the logs.

My understanding is that you use u-boot 2013.04, which is about three
years old now ? If you observe some problem, please try with mainline
first and report back.

> U-Boot > usb start
> (Re)start USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... New Device 0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
> length 0x40
> set address 1
> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 
> 0x0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 
> length 0x12
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
> length 0x9
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 
> length 0x19
> get_conf_no 0 Result 25, wLength 25

[...]

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