Re: [U-Boot] [RESEND PATCH 1/4] arm:goni: Update configuration for goni target

[Lukasz Majewski]

On Fri, 05 Jul 2013 13:17:07 +0900, Jaehoon Chung wrote:
> On 07/04/2013 07:52 PM, Lukasz Majewski wrote:
> > From: Arkadiusz Wlodarczyk 
> > 
> > Configuration file for GONI has been updated to support FAT file
> > system, new mmc partitioning scheme and read linux kernel from eMMC
> > instead of OneNAND.
> > 
> > Signed-off-by: Arkadiusz Wlodarczyk 
> > Signed-off-by: Kyungmin Park 
> > Tested-by: Arkadiusz Wlodarczyk 
> > Cc: Minkyu Kang 
> > ---
> >  include/configs/s5p_goni.h |   17 +
> >  1 file changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
> > index 56e8347..ec43652 100644
> > --- a/include/configs/s5p_goni.h
> > +++ b/include/configs/s5p_goni.h
> > @@ -107,7 +107,7 @@
> >  
> >  #define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
> >  
> > -#define CONFIG_BOOTCOMMAND "run ubifsboot"
> > +#define CONFIG_BOOTCOMMAND "run mmcboot"
> >  
> >  #define CONFIG_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
> >  
> > @@ -137,7 +137,7 @@
> > "onenand erase 0x0156 0x1eaa;" \
> > "onenand write 0x3200 0x126 0x8C\0" \
> > "bootk=" \
> > -   "onenand read 0x30007FC0 0xc0 0x60;" \
> > +   "run loaduimage;" \
> > "bootm 0x30007FC0\0" \
> > "flashboot=" \
> > "set bootargs root=/dev/mtdblock${bootblock} " \
> > @@ -156,16 +156,21 @@
> > "set bootargs " CONFIG_RAMDISK_BOOT \
> > " initrd=0x3300,8M ramdisk=8192\0" \
> > "mmcboot=" \
> > -   "set bootargs root=${mmcblk}
> > rootfstype=${rootfstype}" \
> > +   "set bootargs
> > root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
> > +   "rootfstype=${rootfstype}" \
> Could you add the "rootwait"?

Yes, correct. Thanks for pointing.

> > CONFIG_UBI_MTD " ${opts} ${lcdinfo} " \
> > CONFIG_COMMON_BOOT "; run bootk\0" \
> > "boottrace=setenv opts initcall_debug; run bootcmd\0" \
> > "bootchart=set opts init=/sbin/bootchartd; run bootcmd\0" \
> > "verify=n\0" \
> > -   "rootfstype=cramfs\0" \
> > +   "rootfstype=ext4\0" \
> > "console=" CONFIG_DEFAULT_CONSOLE \
> > "mtdparts=" MTDPARTS_DEFAULT \
> > "meminfo=mem=80M mem=256M@0x4000
> > mem=128M@0x5000\0" \
> > +   "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart}
> > 0x30007FC0 uImage\0" \
> > +   "mmcdev=0\0" \
> > +   "mmcbootpart=2\0" \
> > +   "mmcrootpart=5\0" \
> > "mmcblk=/dev/mmcblk1p1\0" \
> mmcblk can be removed?

Yes, it seems redundant here.


> 
> Best Regards,
> Jaehoon Chung
> > "bootblock=9\0" \
> > "ubiblock=8\0" \
> > @@ -211,6 +216,10 @@
> >  
> >  #define CONFIG_DOS_PARTITION   1
> >  
> > +/* FAT */
> > +#define CONFIG_CMD_FAT
> > +#define CONFIG_FAT_WRITE
> > +
> >  #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR -
> > 0x100) 
> >  #define CONFIG_SYS_CACHELINE_SIZE   64
> > 
> 

Thanks for review.

-- 
Best regards,

Lukasz Majewski

Samsung R&D 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 v3 2/2] cmd_sf: let "sf update" preserve the final part of the last sector

[Gerlando Falauto]

Hi Jagan,

On 07/04/2013 06:26 PM, Jagan Teki wrote:

On Thu, Jul 4, 2013 at 12:03 AM, Gerlando Falauto
 wrote:

Since "sf update" erases the last block as a whole, but only rewrites
the meaningful initial part of it, the rest would be left erased,
potentially erasing meaningful information.
So, as a safety measure, have it rewrite the original content.

Signed-off-by: Gerlando Falauto 
Cc: Valentin Longchamp 
Cc: Holger Brunck 
Acked-by: Simon Glass 
---
  common/cmd_sf.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index ab35a94..1141dc1 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -152,8 +152,10 @@ static const char *spi_flash_update_block(struct spi_flash 
*flash, u32 offset,
  {
 debug("offset=%#x, sector_size=%#x, len=%#zx\n",
 offset, flash->sector_size, len);
-   if (spi_flash_read(flash, offset, len, cmp_buf))
+   /* Read the entire sector so to allow for rewriting */
+   if (spi_flash_read(flash, offset, flash->sector_size, cmp_buf))
 return "read";
+   /* Compare only what is meaningful (len) */
 if (memcmp(cmp_buf, buf, len) == 0) {
 debug("Skip region %x size %zx: no change\n",
 offset, len);
@@ -163,8 +165,16 @@ static const char *spi_flash_update_block(struct spi_flash 
*flash, u32 offset,
 /* Erase the entire sector */
 if (spi_flash_erase(flash, offset, flash->sector_size))
 return "erase";
+   /* Write the initial part of the block from the source */
 if (spi_flash_write(flash, offset, len, buf))
 return "write";


I din't understand why the below write is required again-
As erase ops requires only sector operation and read + write will do
the operations on partial sizes

Can you send the failure case w/o this.


I'm not sure I understand your question.
I thought the commit message above was clear enough.

In any case, the idea is to have "sf update" be as agnostic as possible 
wrt to sector size, so it virtually only erases the same amount of data 
as it is going to overwrite. The rest will be preserved.


This way you could, for instance, store some binary proprietary firmware 
towards the end of the space reserved for u-boot, without having to 
reserve a whole flash sector for it. The reason for doing such a thing 
(as opposed to just embedding it within u-boot itself) is licensing 
issues, so you might want to keep the firmware as close as possible to 
the u-boot binary yet not link it.

Then when you update u-boot (GPL), your firmware is preserved.

Another extreme use case that comes to my mind would be where you have 
the u-boot environment within the same sector where u-boot lies, though

a) I'm not sure it's even possible
b) is of course a BAD, BAD idea
c) See b)
d) See c) and then b), plus is a BAD idea and therefore discouraged
e) it would only make sense if the u-boot environment is never meant to 
be altered except during production


To be honest with you, I don't remember if there was a real use case 
leading me to write this or if it was just all hypothetical or I just 
thought it was nicer that way.


As for changes of v3 wrt v2, the two should be functionally equivalent:
- In v2 I used a memcpy() to write the whole sector at once
- In v3 I avoided the memcpy() but this requires writing the two 
portions separately.


Hope this answers your question.

Thank you,
Gerlando


--
Thanks,
Jagan.

+   /* If it's a partial sector, rewrite the existing part */
+   if (len != flash->sector_size) {
+   /* Rewrite the original data to the end of the sector */
+   if (spi_flash_write(flash, offset + len,
+   flash->sector_size - len, &cmp_buf[len]))
+   return "write";
+   }
 return NULL;
  }

--
1.8.0.1



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

Re: [U-Boot] : MACB TX timeout

[Bo Shen]

Hi Jagan,

On 7/5/2013 10:48, Jagan Teki wrote:

Hi Bo Shen,

Thanks for your info.

On Fri, Jul 5, 2013 at 7:04 AM, Bo Shen  wrote:

Hi Jagan Teki,


On 7/5/2013 03:36, Jagan Teki wrote:


Hi,

Did anyone find this TX timeout issue on macb(gmac)?
I observed this issue when i enable d-cache.

Log:

zynq-uboot> ping 10.10.70.101
gmac0: PHY present at 7
gmac0: link up, 1000Mbps full-duplex (lpa: 0x3800)
Using gmac0 device
gmac0: TX timeout
gmac0: TX timeout
ping failed; host 10.10.70.101 is not alive



Sure, this will happen, as the macb driver is not worked with d-cache
enabled.

Can you point any existing driver that have a d-cache working.


I see the driver of ftgmac100 is doing the thing, but I am not sure 
whether the code is merged.



If you want to let the macb work with d-cache enable, you should modify the
driver.

BTW, if you want to enable d-cache, the MMU must be enabled.

Specific setup to enable to MMU, please point.
I see that we need to write dram_bank_mmu_setup() and
arm_init_domains() on d-cache enable code in
soc folders is that true? please let me know your views.


I am sorry, no information can share with you at this moment.


--
Thanks,
Jagan.



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

Re: [U-Boot] [U-boot] DFU tools copyright

[Lukasz Majewski]

On Thu, 04 Jul 2013 22:08:12 +0100, Stefan Schmidt wrote:
> Hello.
> 
> On Thu, 2013-07-04 at 11:37, Lukasz Majewski wrote:
> > On Thu, 04 Jul 2013 17:20:34 +0800, tiger...@viatech.com.cn wrote:
> > 
> > > Hi, experts:
> > > I found DFU tool code had been put in drivers/dfu directory.
> > > Previously, it was owned by Samsung Electronics.
> > > 
> > 
> > Could you be more specific here? 
> > 
> > All DFU related files have following headers:
> > /*
> >  * g_dnl.c -- USB Downloader Gadget
> >  *
> >  * Copyright (C) 2012 Samsung Electronics
> >  * Lukasz Majewski  
> 
> Which reminds about an issue I brought up before. Your DFU
> implementation is heavily based on the original DFU code Harald Welte
> wrote. The state machine even still have the same fixmes and comments
> but you removed his, and maybe others, copyright here.
> 

You are right here. The state machine was only slightly modified by us.

I will update the f_dfu.c file accordingly to bring back proper credits.

I'm sorry for the situation - it was not intentional.

> As you definitely not wrote the code from scratch you should keep the
> original copyright intact and not only placing the Samsung copyright
> here.
> 
> regards
> Stefan Schmidt
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


-- 
Best regards,

Lukasz Majewski

Samsung R&D 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] [PATCH] common: board_f: Fix build error when CONFIG_TRACE is not defined

[Tushar Behera]

When CONFIG_TRACE is not defined, definition of trace_early_init is not
compiled and we get following error.

common/libcommon.o:(.data.init_sequence_f+0xc): undefined reference to 
`trace_early_init'

While at it, also define reserve_trace only if CONFIG_TRACE is defined.

CC: Simon Glass 
Signed-off-by: Tushar Behera 
---
 common/board_f.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index ab4242a..a685368 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -501,17 +501,17 @@ static int reserve_lcd(void)
 }
 #endif /* CONFIG_LCD */
 
+#ifdef CONFIG_TRACE
 static int reserve_trace(void)
 {
-#ifdef CONFIG_TRACE
gd->relocaddr -= CONFIG_TRACE_BUFFER_SIZE;
gd->trace_buff = map_sysmem(gd->relocaddr, CONFIG_TRACE_BUFFER_SIZE);
debug("Reserving %dk for trace data at: %08lx\n",
  CONFIG_TRACE_BUFFER_SIZE >> 10, gd->relocaddr);
-#endif
 
return 0;
 }
+#endif
 
 #if defined(CONFIG_VIDEO) && (!defined(CONFIG_PPC) || defined(CONFIG_8xx)) \
&& !defined(CONFIG_ARM) && !defined(CONFIG_X86)
@@ -833,7 +833,9 @@ static init_fnc_t init_sequence_f[] = {
 #endif
setup_mon_len,
setup_fdt,
+#ifdef CONFIG_TRACE
trace_early_init,
+#endif
 #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/* TODO: can this go into arch_cpu_init()? */
probecpu,
@@ -977,7 +979,9 @@ static init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_LCD
reserve_lcd,
 #endif
+#ifdef CONFIG_TRACE
reserve_trace,
+#endif
/* TODO: Why the dependency on CONFIG_8xx? */
 #if defined(CONFIG_VIDEO) && (!defined(CONFIG_PPC) || defined(CONFIG_8xx)) \
&& !defined(CONFIG_ARM) && !defined(CONFIG_X86)
-- 
1.7.9.5

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

Re: [U-Boot] [U-boot] DFU tools copyright

[Stefan Schmidt]

Hello.

> On Thu, 04 Jul 2013 22:08:12 +0100, Stefan Schmidt wrote:
>> Hello.
>>
>> On Thu, 2013-07-04 at 11:37, Lukasz Majewski wrote:
>> > On Thu, 04 Jul 2013 17:20:34 +0800, tiger...@viatech.com.cn wrote:
>> >
>> > > Hi, experts:
>> > > I found DFU tool code had been put in drivers/dfu directory.
>> > > Previously, it was owned by Samsung Electronics.
>> > >
>> >
>> > Could you be more specific here?
>> >
>> > All DFU related files have following headers:
>> > /*
>> >  * g_dnl.c -- USB Downloader Gadget
>> >  *
>> >  * Copyright (C) 2012 Samsung Electronics
>> >  * Lukasz Majewski  
>>
>> Which reminds about an issue I brought up before. Your DFU
>> implementation is heavily based on the original DFU code Harald Welte
>> wrote. The state machine even still have the same fixmes and comments
>> but you removed his, and maybe others, copyright here.
>>
>
> You are right here. The state machine was only slightly modified by us.
>
> I will update the f_dfu.c file accordingly to bring back proper credits.

Cool. The patchset I sent April 2012 which was for reference only should
have the correct credits in the old_dfu.c file.
http://lists.denx.de/pipermail/u-boot/2012-April/121864.html

> I'm sorry for the situation - it was not intentional.

No worries. This was not meant to blame anyone. Just something that needs
correction. Just took the change to remind about it. :)

regards
Stefan Schmidt

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

[U-Boot] [PATCH] dfu: Update DFU's authorship history

[Lukasz Majewski]

The DFU's state machine original implementation author and copyright were
missing.

Signed-off-by: Lukasz Majewski 
---
 drivers/usb/gadget/f_dfu.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index e3fa0e3..6adf15c 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -5,6 +5,10 @@
  * authors: Andrzej Pietrasiewicz 
  *  Lukasz Majewski 
  *
+ * Based on OpenMoko u-boot: drivers/usb/usbdfu.c
+ * (C) 2007 by OpenMoko, Inc.
+ * Author: Harald Welte 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH] dfu: Update DFU's authorship history

[Stefan Schmidt]

Hello.

> The DFU's state machine original implementation author and copyright were
> missing.
>
> Signed-off-by: Lukasz Majewski 
> ---
>  drivers/usb/gadget/f_dfu.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
> index e3fa0e3..6adf15c 100644
> --- a/drivers/usb/gadget/f_dfu.c
> +++ b/drivers/usb/gadget/f_dfu.c
> @@ -5,6 +5,10 @@
>   * authors: Andrzej Pietrasiewicz 
>   *  Lukasz Majewski 
>   *
> + * Based on OpenMoko u-boot: drivers/usb/usbdfu.c
> + * (C) 2007 by OpenMoko, Inc.
> + * Author: Harald Welte 
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
>   * the Free Software Foundation; either version 2 of the License, or
> --
> 1.7.10.4

You missed Haralds personal copyright from 2006.
+ * based on existing SAM7DFU code from OpenPCD:
+ * (C) Copyright 2006 by Harald Welte 

While he was working on this for OpenMoko which gives them the copyright
he did work on this code before which means his own copyright does also
apply.

regards
Stefan Schmidt


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

[U-Boot] [PATCH v2] dfu: Update DFU's authorship history

[Lukasz Majewski]

The DFU's state machine original implementation author and copyright were
missing.

Signed-off-by: Lukasz Majewski 

---
Changes for v2:
- Add the whole Harald's development history
---
 drivers/usb/gadget/f_dfu.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index e3fa0e3..d7ae0c0 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -5,6 +5,13 @@
  * authors: Andrzej Pietrasiewicz 
  *  Lukasz Majewski 
  *
+ * Based on OpenMoko u-boot: drivers/usb/usbdfu.c
+ * (C) 2007 by OpenMoko, Inc.
+ * Author: Harald Welte 
+ *
+ * based on existing SAM7DFU code from OpenPCD:
+ * (C) Copyright 2006 by Harald Welte 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 0/4 V4]EXYNOS: Convert Assembly code to c and make it common

[Minkyu Kang]

On 04/07/13 15:59, Rajeshwari Shinde wrote:
> Convert the assembly code in board/samsung to c and move the same to arch/arm.
> lds file made common across SMDKV310, Origen and SMDK5250.
> Add the power reset and exit wakeup api for exynos.
> Initialise GPIO for uart in Origen and SMDKV310 using pinmux.
> 
> Changes in V2:
> - Rebased on latest u-boot-samsung tree.
> - Incorporated review comments from Simon glass and
> Minkyu Kang.
> Changes in V3:
>   - Optimised the mem_ctrl_init function for exynos4.
>   - Removed magic numbers.
> Changes in V4:
>   - Used samsung_get_base api instead of hardcoding base address.
> 
> Rajeshwari Shinde (4):
>   EXYNOS: Add API for power reset and exit wakeup
>   EXYNOS: LDS file move to common
>   EXYNOS4210: Configure GPIO for uart
>   EXYNOS: Move files from board/samsung to arch/arm
> 
>  arch/arm/cpu/armv7/exynos/Makefile |   17 +-
>  .../arm/cpu/armv7/exynos}/clock_init.h |0
>  arch/arm/cpu/armv7/exynos/clock_init_exynos4.c |   95 +
>  .../arm/cpu/armv7/exynos/clock_init_exynos5.c  |   56 ++--
>  arch/arm/cpu/armv7/exynos/common_setup.h   |   45 ++
>  .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
>  .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c  |   27 +-
>  arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c   |  213 ++
>  .../arm/cpu/armv7/exynos/exynos4_setup.h   |  397 +--
>  .../arm/cpu/armv7/exynos/exynos5_setup.h   |   28 +-
>  arch/arm/cpu/armv7/exynos/lowlevel_init.c  |   73 
>  arch/arm/cpu/armv7/exynos/pinmux.c |   40 ++
>  arch/arm/cpu/armv7/exynos/power.c  |   50 +++
>  .../arm/cpu/armv7/exynos}/spl_boot.c   |   74 +++-
>  arch/arm/include/asm/arch-exynos/cpu.h |   13 +-
>  arch/arm/include/asm/arch-exynos/power.h   |   12 +
>  .../exynos-uboot-spl.lds}  |0
>  board/samsung/origen/Makefile  |   11 +-
>  board/samsung/origen/lowlevel_init.S   |  357 -
>  board/samsung/origen/mem_setup.S   |  421 
> 
>  board/samsung/origen/mmc_boot.c|   58 ---
>  board/samsung/origen/origen.c  |   46 +++
>  board/samsung/smdk5250/Makefile|   14 +-
>  board/samsung/smdkv310/Makefile|   10 +-
>  board/samsung/smdkv310/lowlevel_init.S |  414 ---
>  board/samsung/smdkv310/mem_setup.S |  365 -
>  board/samsung/smdkv310/mmc_boot.c  |   60 ---
>  board/samsung/smdkv310/smdkv310.c  |   46 +++
>  include/configs/exynos5250-dt.h|   10 +-
>  include/configs/origen.h   |9 +-
>  include/configs/smdkv310.h |8 +-
>  31 files changed, 985 insertions(+), 1991 deletions(-)
>  rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/clock_init.h 
> (100%)
>  create mode 100644 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c
>  rename board/samsung/smdk5250/clock_init.c => 
> arch/arm/cpu/armv7/exynos/clock_init_exynos5.c (94%)
>  create mode 100644 arch/arm/cpu/armv7/exynos/common_setup.h
>  rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/dmc_common.c 
> (97%)
>  rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/dmc_init_ddr3.c 
> (92%)
>  create mode 100644 arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c
>  rename board/samsung/origen/origen_setup.h => 
> arch/arm/cpu/armv7/exynos/exynos4_setup.h (65%)
>  rename board/samsung/smdk5250/setup.h => 
> arch/arm/cpu/armv7/exynos/exynos5_setup.h (96%)
>  create mode 100644 arch/arm/cpu/armv7/exynos/lowlevel_init.c
>  rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/spl_boot.c (74%)
>  rename board/samsung/{smdk5250/smdk5250-uboot-spl.lds => 
> common/exynos-uboot-spl.lds} (100%)
>  delete mode 100644 board/samsung/origen/lowlevel_init.S
>  delete mode 100644 board/samsung/origen/mem_setup.S
>  delete mode 100644 board/samsung/origen/mmc_boot.c
>  delete mode 100644 board/samsung/smdkv310/lowlevel_init.S
>  delete mode 100644 board/samsung/smdkv310/mem_setup.S
>  delete mode 100644 board/samsung/smdkv310/mmc_boot.c
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH v2] dfu: Update DFU's authorship history

[Stefan Schmidt]

Hello.

> The DFU's state machine original implementation author and copyright were
> missing.
>
> Signed-off-by: Lukasz Majewski 

Acked-by: Stefan Schmidt 

>
> ---
> Changes for v2:
> - Add the whole Harald's development history
> ---
>  drivers/usb/gadget/f_dfu.c |7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
> index e3fa0e3..d7ae0c0 100644
> --- a/drivers/usb/gadget/f_dfu.c
> +++ b/drivers/usb/gadget/f_dfu.c
> @@ -5,6 +5,13 @@
>   * authors: Andrzej Pietrasiewicz 
>   *  Lukasz Majewski 
>   *
> + * Based on OpenMoko u-boot: drivers/usb/usbdfu.c
> + * (C) 2007 by OpenMoko, Inc.
> + * Author: Harald Welte 
> + *
> + * based on existing SAM7DFU code from OpenPCD:
> + * (C) Copyright 2006 by Harald Welte 
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
>   * the Free Software Foundation; either version 2 of the License, or
> --
> 1.7.10.4

regards
Stefan Schmidt

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

Re: [U-Boot] [PATCH] arm:trats: Increase malloc pool size (for DFU ext4 transfers)

[Minkyu Kang]

On 29/06/13 01:43, Lukasz Majewski wrote:
> Commit:
> dfu: make data buffer size configurable
> SHA1: 89a72b2e0e141042c9109185e02d39b2107ffc62
> 
> replaced statically allocated buffers with one allocated with memalign.
> 
> Malloc pool size of 1MiB was too small, since we needed bigger buffer to
> transfer for example uImage.
> 
> Signed-off-by: Lukasz Majewski 
> Cc: Minkyu Kang 
> ---
>  include/configs/trats.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index 53fcf79..90562c4 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -66,7 +66,7 @@
>  #define CONFIG_MACH_TYPE MACH_TYPE_TRATS
>  
>  /* Size of malloc() pool */
> -#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (1 << 20))
> +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (16 << 20))
>  
>  /* select serial console configuration */
>  #define CONFIG_SERIAL2   /* use SERIAL 2 */
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH] power:bat:trats: Break battery charging with ctrl+C

[Minkyu Kang]

On 25/06/13 22:28, Lukasz Majewski wrote:
> Add support for disabling battery charging with ctrl+C keyboard
> combination pressed.
> Moreover the battery update is done more frequently.
> 
> Signed-off-by: Lukasz Majewski 
> Cc: Tom Rini 
> ---
>  drivers/power/battery/bat_trats.c |   13 +
>  drivers/power/power_core.c|3 ++-
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 

applied to u-boot-samsung.

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

[U-Boot] please pull u-boot-samsung master

[Minkyu Kang]

Dear Albert,

The following changes since commit 7737c994609ffb50194d5ddb67467ae0fcd8f775:

  net2big_v2: initialize LEDs at startup (2013-06-20 14:01:23 +0530)

are available in the git repository at:

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

for you to fetch changes up to 9dfa3d0734df4aad107def2c900d1514ac7510ac:

  power:bat:trats: Break battery charging with ctrl+C (2013-07-05 18:46:14 
+0900)


Ajay Kumar (1):
  video: exynos_fb: Add the missing #else clause

Amar (1):
  EXYNOS5: I2C: Add FDT and non-FDT support for I2C

Axel Lin (2):
  gpio: s3c2440_gpio: Fix wrong writel arguments
  gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code

Bernie Thompson (1):
  exynos: Adjust the starting MIF voltage to 1.05v

Rajeshwari Shinde (9):
  EXYNOS5: FDT: Add compatible strings for Serial
  EXYNOS5: FDT: Add serial device node values
  S5P: Serial: Add fdt support to driver
  CONFIG: EXYNOS5: Enable silent console
  SMDK5250: Remove reduntant code
  EXYNOS: Add API for power reset and exit wakeup
  EXYNOS: LDS file move to common
  EXYNOS4210: Configure GPIO for uart
  EXYNOS: Move files from board/samsung to arch/arm

Simon Glass (1):
  exynos: Enable mmc for snow

Łukasz Majewski (2):
  arm:trats: Increase malloc pool size (for DFU ext4 transfers)
  power:bat:trats: Break battery charging with ctrl+C

 arch/arm/cpu/armv7/exynos/Makefile |   17 +-
 .../arm/cpu/armv7/exynos}/clock_init.h |0
 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c |   95 +
 .../arm/cpu/armv7/exynos/clock_init_exynos5.c  |   56 +--
 arch/arm/cpu/armv7/exynos/common_setup.h   |   45 +++
 .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
 .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c  |   27 +-
 arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c   |  213 ++
 .../arm/cpu/armv7/exynos/exynos4_setup.h   |  397 +-
 .../arm/cpu/armv7/exynos/exynos5_setup.h   |   28 +-
 arch/arm/cpu/armv7/exynos/lowlevel_init.c  |   73 
 arch/arm/cpu/armv7/exynos/pinmux.c |   40 ++
 arch/arm/cpu/armv7/exynos/power.c  |   50 +++
 .../arm/cpu/armv7/exynos}/spl_boot.c   |   84 +++-
 arch/arm/dts/exynos5250.dtsi   |   27 ++
 arch/arm/include/asm/arch-exynos/cpu.h |   13 +-
 arch/arm/include/asm/arch-exynos/power.h   |   12 +
 arch/arm/include/asm/arch-exynos/spl.h |1 +
 .../exynos-uboot-spl.lds}  |0
 board/samsung/dts/exynos5250-smdk5250.dts  |2 +
 board/samsung/dts/exynos5250-snow.dts  |   26 ++
 board/samsung/origen/Makefile  |   11 +-
 board/samsung/origen/lowlevel_init.S   |  357 -
 board/samsung/origen/mem_setup.S   |  421 
 board/samsung/origen/mmc_boot.c|   58 ---
 board/samsung/origen/origen.c  |   46 +++
 board/samsung/smdk5250/Makefile|   14 +-
 board/samsung/smdk5250/smdk5250.c  |2 +-
 board/samsung/smdkv310/Makefile|   10 +-
 board/samsung/smdkv310/lowlevel_init.S |  414 ---
 board/samsung/smdkv310/mem_setup.S |  365 -
 board/samsung/smdkv310/mmc_boot.c  |   60 ---
 board/samsung/smdkv310/smdkv310.c  |   46 +++
 drivers/gpio/s3c2440_gpio.c|6 +-
 drivers/gpio/s5p_gpio.c|9 +-
 drivers/i2c/s3c24x0_i2c.c  |   12 +-
 drivers/power/battery/bat_trats.c  |   13 +-
 drivers/power/power_core.c |3 +-
 drivers/serial/serial_s5p.c|   78 
 drivers/video/exynos_fimd.c|3 +-
 include/configs/exynos5250-dt.h|   12 +-
 include/configs/origen.h   |9 +-
 include/configs/smdkv310.h |8 +-
 include/configs/trats.h|2 +-
 include/fdtdec.h   |1 +
 include/power/max77686_pmic.h  |2 +
 lib/fdtdec.c   |1 +
 47 files changed, 1154 insertions(+), 2022 deletions(-)
 rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/clock_init.h 
(100%)
 create mode 100644 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c
 rename board/samsung/smdk5250/clock_init.c => 
arch/arm/cpu/armv7/exynos/clock_init_exynos5.c (94%)
 create mode 100644 arch/arm/cpu/armv7/exynos/common_setup.h
 rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/dmc_common.c (97%)
 rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/dmc_init_ddr3.

[U-Boot] [PATCH] arm: exynos: fix clock calculation

[Minkyu Kang]

There are differnce with clock calcuation by cpu variations.
This patch will fix it according to user manual.

Signed-off-by: Minkyu Kang 
Signed-off-by: Rajeshwari Shinde 
---
 arch/arm/cpu/armv7/exynos/clock.c |   37 +
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index e1c4246..da43373 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -85,6 +85,7 @@ static struct set_epll_con_val exynos5_epll_div[] = {
 static int exynos_get_pll_clk(int pllreg, unsigned int r, unsigned int k)
 {
unsigned long m, p, s = 0, mask, fout;
+   unsigned int div;
unsigned int freq;
/*
 * APLL_CON: MIDV [25:16]
@@ -113,11 +114,39 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r, 
unsigned int k)
fout = (m + k / 65536) * (freq / (p * (1 << s)));
} else if (pllreg == VPLL) {
k = k & 0xfff;
-   /* FOUT = (MDIV + K / 1024) * FIN / (PDIV * 2^SDIV) */
-   fout = (m + k / 1024) * (freq / (p * (1 << s)));
+
+   /*
+* Exynos4210
+* FOUT = (MDIV + K / 1024) * FIN / (PDIV * 2^SDIV)
+*
+* Exynos4412
+* FOUT = (MDIV + K / 65535) * FIN / (PDIV * 2^SDIV)
+*
+* Exynos5250
+* FOUT = (MDIV + K / 65536) * FIN / (PDIV * 2^SDIV)
+*/
+   if (proid_is_exynos4210())
+   div = 1024;
+   else if (proid_is_exynos4412())
+   div = 65535;
+   else if (proid_is_exynos5250())
+   div = 65536;
+   else
+   return 0;
+
+   fout = (m + k / div) * (freq / (p * (1 << s)));
} else {
-   /* FOUT = MDIV * FIN / (PDIV * 2^SDIV) */
-   fout = m * (freq / (p * (1 << s)));
+   /*
+* Exynos4210
+* FOUT = MDIV * FIN / (PDIV * 2^SDIV)
+*
+* Exynos4412 / Exynos5250
+* FOUT = MDIV * FIN / (PDIV * 2^(SDIV-1))
+*/
+   if (proid_is_exynos4210())
+   fout = m * (freq / (p * (1 << s)));
+   else
+   fout = m * (freq / (p * (1 << (s - 1;
}
 
return fout;
-- 
1.7.9.5

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

Re: [U-Boot] compiled failed when turned off gcc optimazition

[TigerLiu]

Hi, experts:

Would any expert fix this question?

It seems related MOVW instruction's usuage when turning off gcc
optimazition.

 

If i just turned on "-O1" or "-O2", still failed to compile uboot code.

 

Best wishes,

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

Re: [U-Boot] Ethernet support on mx6slevk board

[Wang Huan-B18965]

Hi, Shawn,

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Shawn Guo
> Sent: Friday, July 05, 2013 11:42 AM
> To: Estevam Fabio-R49496; U-Boot-Denx
> Subject: [U-Boot] Ethernet support on mx6slevk board
> 
> Hi,
> 
> I'm running U-Boot 2013.07-rc2 and seeing Ethernet is failed to
> initialize.  Is it a known issue or something not supported yet?  It's
> unlikely my setup problem, since I have a vendor U-Boot running the
> board just fine.
[Alison Wang] I am not sure it is caused by my previous patch 
bcb6e9023a119a1cbcaf8289576e5aa155331802
Which FEC_RCNTRL_MII_MODE may not be set correctly for other boards. As I don't 
have
Mx6slevk board, could you revert and try again?

Thanks!

commit bcb6e9023a119a1cbcaf8289576e5aa155331802
Author: Alison Wang 
Date:   Mon May 27 22:55:43 2013 +

net: fec_mxc: Add support for Vybrid VF610

This patch adds FEC support for Vybrid VF610 platform.

In function fec_open(), RCR register is only set as RGMII mode. But RCR
register should be set as RMII mode for VF610 platform.
This configuration is already done in fec_reg_setup(), so this piece of
code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits.

Signed-off-by: Alison Wang 
Reviewed-by: Benoit Thebaudeau 

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 4dbcdca..da95e28 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -516,9 +516,7 @@ static int fec_open(struct eth_device *edev)
 #ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
-   u32 rcr = (readl(&fec->eth->r_cntrl) &
-   ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
-   FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
+   u32 rcr = readl(&fec->eth->r_cntrl) & ~FEC_RCNTRL_RMII_10T;
if (speed == _1000BASET)
ecr |= FEC_ECNTRL_SPEED;
else if (speed != _100BASET)

Best Regards,
Alison Wang

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

Re: [U-Boot] Ethernet support on mx6slevk board

[Fabio Estevam]

On Fri, Jul 5, 2013 at 12:42 AM, Shawn Guo  wrote:
> Hi,
>
> I'm running U-Boot 2013.07-rc2 and seeing Ethernet is failed to
> initialize.  Is it a known issue or something not supported yet?  It's
> unlikely my setup problem, since I have a vendor U-Boot running the
> board just fine.

Could you please show the boot log?

I am currently without access to my mx6sl board and will have access
to it only next Wednesday.

Regards,

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

Re: [U-Boot] Ethernet support on mx6slevk board

[Fabio Estevam]

On Fri, Jul 5, 2013 at 12:42 AM, Shawn Guo  wrote:
> Hi,
>
> I'm running U-Boot 2013.07-rc2 and seeing Ethernet is failed to
> initialize.  Is it a known issue or something not supported yet?  It's
> unlikely my setup problem, since I have a vendor U-Boot running the
> board just fine.

Ok, I just looked at it and when I submitted the initial board support
I did not add Ethernet support.

I have only tested booting kernel/dtb via mmc with this platform.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Ethernet support on mx6slevk board

[Fabio Estevam]

On Fri, Jul 5, 2013 at 9:37 AM, Shawn Guo  wrote:

> Ok, it's something not supported yet, and I have to stay with vendor
> U-Boot for another while.

I will work on adding Ethernet support for mx6slevk when I come back
to the office on Wednesday.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/2] dfu:ext4:fix Fix DFU upload functionality

[Tom Rini]

On Wed, Jul 03, 2013 at 11:49:20PM +0200, Marek Vasut wrote:
> Dear Tom Rini,
> 
> > On Fri, Jun 28, 2013 at 06:41:50PM +0200, ??ukasz Majewski wrote:
> > > For the first eMMC read of data for upload, use the "large" dfu_buf (now
> > > configurable) instead of usb request buffer allocated at composite layer
> > > (which is 4KiB) [*].
> > > 
> > > For eMMC the whole file is read, which usually is larger than the buffer
> > > [*] provided with usb request.
> > > 
> > > Signed-off-by: Lukasz Majewski 
> > > Cc: Tom Rini 
> > > Cc: Pantelis Antoniou 
> > > Cc: Marek Vasut 
> > > Cc: Heiko Schocher 
> > 
> > Applied to u-boot/master, thanks!
> 
> Tom, why are you picking USB changes now? This is creating quite some mess ...

Just trying to clear up the queue of fixes.

-- 
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/2] am335x_evm: Update, document Falcon Mode support

[Tom Rini]

On Thu, Jul 04, 2013 at 07:39:48AM +, Romain Izard wrote:
> Tom> +A further word of warning about using eMMC and partition tables.  When
> Tom> +working with SD cards we can get away with erasing small areas at a 
> time,
> Tom> +however on eMMC we must keep erases aligned to eraseblocks and thus the
> Tom> +first erase we issue will erase the partition table.
> 
> Peter> Really? I thought eMMC behaved just like SD cards?
> 
> Tom> Yes, really.  We know what the erase block size is, and round our
> Tom> commands, probably because we really have to.  SD cards take care of
> Tom> things for us, for better or worse.
> 
> But why do we bother with erasing the eMMC in the first place? The erase
> commands are wholly optional, and only make sense as a TRIM mechanism,
> which is not our case as we will fill the memory as soon as it has been
> erased.
> 
> There is no problem in writing directly in the memory, even if it has
> not been erased previously. Or is it a measure to detect interrupted
> writes ?

I hadn't thought of it like that, I had been thinking of it like NAND
for some reason.  I'll update the instructions (and write a bunch of
garbage first) and re-confirm things.  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] Ethernet support on mx6slevk board

[Shawn Guo]

On Fri, Jul 05, 2013 at 08:44:38AM -0300, Fabio Estevam wrote:
> On Fri, Jul 5, 2013 at 12:42 AM, Shawn Guo  wrote:
> > Hi,
> >
> > I'm running U-Boot 2013.07-rc2 and seeing Ethernet is failed to
> > initialize.  Is it a known issue or something not supported yet?  It's
> > unlikely my setup problem, since I have a vendor U-Boot running the
> > board just fine.
> 
> Ok, I just looked at it and when I submitted the initial board support
> I did not add Ethernet support.
> 
> I have only tested booting kernel/dtb via mmc with this platform.

Ok, it's something not supported yet, and I have to stay with vendor
U-Boot for another while.

Shawn

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

Re: [U-Boot] [PATCH v2 1/5] bootm: Handle errors consistently

[Tom Rini]

On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:

> A recent bootm fix left the error path incomplete. Reinstate this so that
> failures in bootm stages are handled properly.
> 
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Correct checking in the no-error case


OK, this conflicts with the change I posted (and pushed later than I
thought I had).  Can you confirm the code is good in mainline now?
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] [U-Boot, 2/2] dfu:ext4:fix Fix DFU upload functionality

[Marek Vasut]

Dear Tom Rini,

> On Wed, Jul 03, 2013 at 11:49:20PM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> > > On Fri, Jun 28, 2013 at 06:41:50PM +0200, ??ukasz Majewski wrote:
> > > > For the first eMMC read of data for upload, use the "large" dfu_buf
> > > > (now configurable) instead of usb request buffer allocated at
> > > > composite layer (which is 4KiB) [*].
> > > > 
> > > > For eMMC the whole file is read, which usually is larger than the
> > > > buffer [*] provided with usb request.
> > > > 
> > > > Signed-off-by: Lukasz Majewski 
> > > > Cc: Tom Rini 
> > > > Cc: Pantelis Antoniou 
> > > > Cc: Marek Vasut 
> > > > Cc: Heiko Schocher 
> > > 
> > > Applied to u-boot/master, thanks!
> > 
> > Tom, why are you picking USB changes now? This is creating quite some
> > mess ...
> 
> Just trying to clear up the queue of fixes.

Ok, if you manage to merge it with the USB PR ...

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

Re: [U-Boot] compiled failed when turned off gcc optimazitionAT

[Albert ARIBAUD]

Hi tiger...@viatech.com.cn,

On Fri, 5 Jul 2013 18:31:50 +0800,  wrote:

> Hi, experts:
> 
> Would any expert fix this question?
> 
> It seems related MOVW instruction's usuage when turning off gcc
> optimazition.
> 
>  
> 
> If i just turned on "-O1" or "-O2", still failed to compile uboot code.

I have seen the issue arise, and looked it up with the help of Jeroen
Hofstee (Cc:). It is somehow related to the fact that on ARM, U-Boot
(especially the DM) relies on ARM ELF relocation records all being of
the R_ARM_RELATIVE type, while for -O{0,1,2} the compiler generates
(some) MOVW-related relocation record types.

I have local branches related to this. I need to go through them and
will post them but not for 2013.07 as these are not fixes, and there
is no bug per se since U-Boot is supposed to build with -Os, not
-O{0,1,2}.

> Best wishes,

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

Re: [U-Boot] [U-Boot, 2/2] dfu:ext4:fix Fix DFU upload functionality

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/05/2013 09:55 AM, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On Wed, Jul 03, 2013 at 11:49:20PM +0200, Marek Vasut wrote:
>>> Dear Tom Rini,
>>> 
 On Fri, Jun 28, 2013 at 06:41:50PM +0200, ??ukasz Majewski
 wrote:
> For the first eMMC read of data for upload, use the "large"
> dfu_buf (now configurable) instead of usb request buffer
> allocated at composite layer (which is 4KiB) [*].
> 
> For eMMC the whole file is read, which usually is larger
> than the buffer [*] provided with usb request.
> 
> Signed-off-by: Lukasz Majewski  Cc:
> Tom Rini  Cc: Pantelis Antoniou
>  Cc: Marek Vasut
>  Cc: Heiko Schocher 
 
 Applied to u-boot/master, thanks!
>>> 
>>> Tom, why are you picking USB changes now? This is creating
>>> quite some mess ...
>> 
>> Just trying to clear up the queue of fixes.
> 
> Ok, if you manage to merge it with the USB PR ...

Yup, fit right on top.  I'll stop being an overarching custodian and
let you grab the copyright fix :)

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1tOoAAoJENk4IS6UOR1WUToP/1+NJg5S9fFWaFWFfya0eRhi
N3qdiA9bTs2hye/EwPB75HQ7tllWmr5/pHwFXLvkrCbV8pL/P2SnSch/lmN4PX7l
qC6EEz5xlgpy0vhPQ8S+rLgoa2qavurBFAR2G3D+s2s4NkjSTmUrs/VHnzXOexKI
6DG4gu8FrNBvE0SMCfuXHJcRD7rEvXYsDH0sz+21DlhFr/WIk1ErREP3rXHk0ffp
b0rOWvdYTQcceYDgXS70JSXpwmRl/QWga8UpdseNtujhz18RX3C8W8XG6dSoTZGv
CYZQzAldU9k5y/S1c7t1W87Himc6bZfcuTYlXpvAB2isN02S3jQmzmdFZ95xc0Lv
AZUV05VRAsVKXkwihpmxUCBwTafzcczFjm48bdJ5n5Qvpy5VnwsiFucHyB4/9ikv
1e3eOueaxLaMNHCHfiP/J8tr8/4H8M+dq4HKQvjZdmCsBqEHiKUUDQIKTFaryOg2
sohWAH6v76qK2CjQ2I2rHju1lMeLeOHpR33ZUb0FBVLRVzdZl9QD3rTRuW840pPt
OCdscioGWatJ0YkND4giCey15O38IaKQ0Q6McqoZe/GIhvt2tqTWJrKdM1d76lXZ
9TaYLKxY20GAvfxPAopUaNdnwFiu3uefwZpMsJGbqg+aJyOuncCqXRDKprru9bbj
chpFHxwvm/wGhkLDleeO
=XazZ
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Fwd: U-Boot 2013.04: himport_r: can't insert "..."into hash table

[Thomas O'Hara]

Hi,

I am using u-Boot 2013.04 to boot an AT91SAM9263-based board. I use a
GCC/uClibc cross compiler which I updated to use GCC-4.7.3 and came across
a strange problem (see attached log files).

uBoot_GCC-4.7.1.log- Bootstrap built with GCC-4.7.3
   - uBoot built with cross-compiler based
on GCC-4.7.1
   - Kernel built with GCC-4.7.3

uBoot_GCC-4.7.3a.log  - Bootstrap built with GCC-4.7.3
   - uBoot is built with GCC-4.7.3 and
throws the hash table error shown
   - Kernel built with GCC-4.7.3

uBoot_GCC-4.7.3b.log  - Bootstrap built with GCC-4.7.3
   - uBoot is built with GCC-4.7.3 and
halts after the "using default environment" message shown
   - Kernel built with GCC-4.7.3


The uBoot source code is the same for all builds. The hash-tables problem
seems to have occurred in the past with uBoot-2010.12. I tested the builds
on 10 different boards and 8 resulted in the uBoot_GCC-4.7.3b log while 2
resulted in the uBoot_GCC-4.7.3a log. All 10 boards worked correctly when
uBoot was built with the GCC-4.7.1 based cross compiler.

Initially I assumed that the fault was with the compiler but both the
bootstrap and the kernel compile and run fine, only uBoot fails.

I did some further investigation and discovered that when the GCC/uClibc
cross-compiler is built with the following sources, uBoot builds and runs
correctly.

binutils-2.22
gcc-4.7.1
gmp-5.0.5
linux-3.6.11
mpc-1.0
mpfr-3.1.1
uClibc-0.9.33.2

When the GCC/uClibc cross-compiler is built with the following sources,
uBoot builds without error but does not run.

binutils-2.23
gcc-4.7.2
gmp-5.0.5
linux-3.6.11
mpc-1.0.1
mpfr-3.1.1
uClibc-0.9.33.2

I'm continuing to narrow this down but I was wondering if anyone has
already come across this and could help me resolve it more quickly.

Cheers,

Tom

-- 
Life, liberty and...


uBoot_GCC-4.7.1.log
Description: Binary data


uBoot_GCC-4.7.3a.log
Description: Binary data


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

Re: [U-Boot] [U-Boot, 2/2] dfu:ext4:fix Fix DFU upload functionality

[Marek Vasut]

Dear Tom Rini,

> On 07/05/2013 09:55 AM, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On Wed, Jul 03, 2013 at 11:49:20PM +0200, Marek Vasut wrote:
> >>> Dear Tom Rini,
> >>> 
>  On Fri, Jun 28, 2013 at 06:41:50PM +0200, ??ukasz Majewski
>  
>  wrote:
> > For the first eMMC read of data for upload, use the "large"
> > dfu_buf (now configurable) instead of usb request buffer
> > allocated at composite layer (which is 4KiB) [*].
> > 
> > For eMMC the whole file is read, which usually is larger
> > than the buffer [*] provided with usb request.
> > 
> > Signed-off-by: Lukasz Majewski  Cc:
> > Tom Rini  Cc: Pantelis Antoniou
> >  Cc: Marek Vasut
> >  Cc: Heiko Schocher 
>  
>  Applied to u-boot/master, thanks!
> >>> 
> >>> Tom, why are you picking USB changes now? This is creating
> >>> quite some mess ...
> >> 
> >> Just trying to clear up the queue of fixes.
> > 
> > Ok, if you manage to merge it with the USB PR ...
> 
> Yup, fit right on top.  I'll stop being an overarching custodian and
> let you grab the copyright fix :)

I see discussion , not patch. Link?

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

Re: [U-Boot] [U-Boot, 2/2] dfu:ext4:fix Fix DFU upload functionality

[Lukasz Majewski]

On Fri, 05 Jul 2013 16:32:03 +0200, Marek Vasut wrote:

Hi,

> Dear Tom Rini,
> 
> > On 07/05/2013 09:55 AM, Marek Vasut wrote:
> > > Dear Tom Rini,
> > > 
> > >> On Wed, Jul 03, 2013 at 11:49:20PM +0200, Marek Vasut wrote:
> > >>> Dear Tom Rini,
> > >>> 
> >  On Fri, Jun 28, 2013 at 06:41:50PM +0200, ??ukasz Majewski
> >  
> >  wrote:
> > > For the first eMMC read of data for upload, use the "large"
> > > dfu_buf (now configurable) instead of usb request buffer
> > > allocated at composite layer (which is 4KiB) [*].
> > > 
> > > For eMMC the whole file is read, which usually is larger
> > > than the buffer [*] provided with usb request.
> > > 
> > > Signed-off-by: Lukasz Majewski  Cc:
> > > Tom Rini  Cc: Pantelis Antoniou
> > >  Cc: Marek Vasut
> > >  Cc: Heiko Schocher 
> >  
> >  Applied to u-boot/master, thanks!
> > >>> 
> > >>> Tom, why are you picking USB changes now? This is creating
> > >>> quite some mess ...
> > >> 
> > >> Just trying to clear up the queue of fixes.
> > > 
> > > Ok, if you manage to merge it with the USB PR ...
> > 
> > Yup, fit right on top.  I'll stop being an overarching custodian and
> > let you grab the copyright fix :)
> 
> I see discussion , not patch. Link?
> 

Here you are:
http://patchwork.ozlabs.org/patch/257068/

:-)

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


-- 
Best regards,

Lukasz Majewski

Samsung R&D 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] PCIe support for Tegra T30 ?

[Stephen Warren]

On 07/05/2013 08:41 AM, Bob Koninckx wrote:
> Hi,
> 
> Are there any plans for adding PCIe support for Tegra T30 SoC in the
> near future? If not, what would it take if we would want to do this
> ourselves. Any pointer in the right directions would be greatly
> appreciated.

I don't believe anyone is actively working on this at present. It would
be great to have this support in place.

If you want to take a crack at it yourself, I suggest the following
resources:

Thierry Reding has recently created a new PCIe driver for Tegra in the
Linux kernel. You can find this as part of:

git://gitorious.org/thierryreding/linux.git next

The downstream U-Boot port for the Tegra20 TrimSlice board has PCIe
support, for the built-in NIC. You can find that at:

git://gitorious.org/trimslice-u-boot/trimslice-u-boot.git master

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

Re: [U-Boot] [PATCH v5 1/1] NET: Improve TFTP booting performance when CONFIG_USB_KEYBOARD

[Stephen Warren]

On 07/03/2013 10:01 PM, Jim Lin wrote:
> TFTP booting is slow when a USB keyboard is installed and
> CONFIG_USB_KEYBOARD is defined.
> This fix is to change Ctrl-C polling to every second when NET transfer
> is running.

Tested-by: Stephen Warren 

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

[U-Boot] How to prepare a MTD partion?

[Woody Wu]

Hi,

After defined MTD partions in kernel and u-boot, what's the next steps
to make it mountable?

I have defined two data partitions in MTD out of my NAND flash, each of
which has size of about 800M. Then I want to make them as Yaffs2 and
j2ffs and mount them to use.

In PC linux, I know there are something like mkfs.xxx, which seems not
the case for MTD partitions.  So, can anyone be so kind to tell me
what are steps I need to do in u-boot and out-of-uboot?

Thanks in advance!
-- 
I can't go back to yesterday - because I was a different person then
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung master

[Albert ARIBAUD]

Hi Minkyu,

On Fri, 05 Jul 2013 19:08:06 +0900, Minkyu Kang 
wrote:

> Dear Albert,
> 
> The following changes since commit 7737c994609ffb50194d5ddb67467ae0fcd8f775:
> 
>   net2big_v2: initialize LEDs at startup (2013-06-20 14:01:23 +0530)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-samsung master
> 
> for you to fetch changes up to 9dfa3d0734df4aad107def2c900d1514ac7510ac:
> 
>   power:bat:trats: Break battery charging with ctrl+C (2013-07-05 18:46:14 
> +0900)
> 
> 
> Ajay Kumar (1):
>   video: exynos_fb: Add the missing #else clause
> 
> Amar (1):
>   EXYNOS5: I2C: Add FDT and non-FDT support for I2C
> 
> Axel Lin (2):
>   gpio: s3c2440_gpio: Fix wrong writel arguments
>   gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code
> 
> Bernie Thompson (1):
>   exynos: Adjust the starting MIF voltage to 1.05v
> 
> Rajeshwari Shinde (9):
>   EXYNOS5: FDT: Add compatible strings for Serial
>   EXYNOS5: FDT: Add serial device node values
>   S5P: Serial: Add fdt support to driver
>   CONFIG: EXYNOS5: Enable silent console
>   SMDK5250: Remove reduntant code
>   EXYNOS: Add API for power reset and exit wakeup
>   EXYNOS: LDS file move to common
>   EXYNOS4210: Configure GPIO for uart
>   EXYNOS: Move files from board/samsung to arch/arm
> 
> Simon Glass (1):
>   exynos: Enable mmc for snow
> 
> Łukasz Majewski (2):
>   arm:trats: Increase malloc pool size (for DFU ext4 transfers)
>   power:bat:trats: Break battery charging with ctrl+C
> 
>  arch/arm/cpu/armv7/exynos/Makefile |   17 +-
>  .../arm/cpu/armv7/exynos}/clock_init.h |0
>  arch/arm/cpu/armv7/exynos/clock_init_exynos4.c |   95 +
>  .../arm/cpu/armv7/exynos/clock_init_exynos5.c  |   56 +--
>  arch/arm/cpu/armv7/exynos/common_setup.h   |   45 +++
>  .../arm/cpu/armv7/exynos}/dmc_common.c |7 +-
>  .../arm/cpu/armv7/exynos}/dmc_init_ddr3.c  |   27 +-
>  arch/arm/cpu/armv7/exynos/dmc_init_exynos4.c   |  213 ++
>  .../arm/cpu/armv7/exynos/exynos4_setup.h   |  397 +-
>  .../arm/cpu/armv7/exynos/exynos5_setup.h   |   28 +-
>  arch/arm/cpu/armv7/exynos/lowlevel_init.c  |   73 
>  arch/arm/cpu/armv7/exynos/pinmux.c |   40 ++
>  arch/arm/cpu/armv7/exynos/power.c  |   50 +++
>  .../arm/cpu/armv7/exynos}/spl_boot.c   |   84 +++-
>  arch/arm/dts/exynos5250.dtsi   |   27 ++
>  arch/arm/include/asm/arch-exynos/cpu.h |   13 +-
>  arch/arm/include/asm/arch-exynos/power.h   |   12 +
>  arch/arm/include/asm/arch-exynos/spl.h |1 +
>  .../exynos-uboot-spl.lds}  |0
>  board/samsung/dts/exynos5250-smdk5250.dts  |2 +
>  board/samsung/dts/exynos5250-snow.dts  |   26 ++
>  board/samsung/origen/Makefile  |   11 +-
>  board/samsung/origen/lowlevel_init.S   |  357 -
>  board/samsung/origen/mem_setup.S   |  421 
> 
>  board/samsung/origen/mmc_boot.c|   58 ---
>  board/samsung/origen/origen.c  |   46 +++
>  board/samsung/smdk5250/Makefile|   14 +-
>  board/samsung/smdk5250/smdk5250.c  |2 +-
>  board/samsung/smdkv310/Makefile|   10 +-
>  board/samsung/smdkv310/lowlevel_init.S |  414 ---
>  board/samsung/smdkv310/mem_setup.S |  365 -
>  board/samsung/smdkv310/mmc_boot.c  |   60 ---
>  board/samsung/smdkv310/smdkv310.c  |   46 +++
>  drivers/gpio/s3c2440_gpio.c|6 +-
>  drivers/gpio/s5p_gpio.c|9 +-
>  drivers/i2c/s3c24x0_i2c.c  |   12 +-
>  drivers/power/battery/bat_trats.c  |   13 +-
>  drivers/power/power_core.c |3 +-
>  drivers/serial/serial_s5p.c|   78 
>  drivers/video/exynos_fimd.c|3 +-
>  include/configs/exynos5250-dt.h|   12 +-
>  include/configs/origen.h   |9 +-
>  include/configs/smdkv310.h |8 +-
>  include/configs/trats.h|2 +-
>  include/fdtdec.h   |1 +
>  include/power/max77686_pmic.h  |2 +
>  lib/fdtdec.c   |1 +
>  47 files changed, 1154 insertions(+), 2022 deletions(-)
>  rename {board/samsung/smdk5250 => arch/arm/cpu/armv7/exynos}/clock_init.h 
> (100%)
>  create mode 100644 arch/arm/cpu/armv7/exynos/clock_init_exynos4.c
>  rename board/samsung/smdk5250/clock_init.c => 
>

Re: [U-Boot] [PATCH v2 1/5] bootm: Handle errors consistently

[Simon Glass]

Hi Tom,

On Fri, Jul 5, 2013 at 5:59 AM, Tom Rini  wrote:

> On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:
>
> > A recent bootm fix left the error path incomplete. Reinstate this so that
> > failures in bootm stages are handled properly.
> >
> > Signed-off-by: Simon Glass 
> > ---
> > Changes in v2:
> > - Correct checking in the no-error case
>
>
> OK, this conflicts with the change I posted (and pushed later than I
> thought I had).  Can you confirm the code is good in mainline now?
> Thanks!
>

It's close, but I think it still needs this near the end
of do_bootm_states(), something like:

 else if (ret == BOOTM_ERR_RESET) do_reset(cmdtp, flag, argc, argv); + else
if (ret) + puts("subcommand not supported\n"); return ret;

If you agree, I can prepare a patch as part of the bootz update.

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

Re: [U-Boot] [PATCH] common: board_f: Fix build error when CONFIG_TRACE is not defined

[Simon Glass]

Hi Tushar,

On Fri, Jul 5, 2013 at 1:40 AM, Tushar Behera wrote:

> When CONFIG_TRACE is not defined, definition of trace_early_init is not
> compiled and we get following error.
>
> common/libcommon.o:(.data.init_sequence_f+0xc): undefined reference to
> `trace_early_init'
>
> While at it, also define reserve_trace only if CONFIG_TRACE is defined.
>
> CC: Simon Glass 
> Signed-off-by: Tushar Behera 
> ---
>  common/board_f.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index ab4242a..a685368 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -501,17 +501,17 @@ static int reserve_lcd(void)
>  }
>  #endif /* CONFIG_LCD */
>
> +#ifdef CONFIG_TRACE
>  static int reserve_trace(void)
>  {
> -#ifdef CONFIG_TRACE
> gd->relocaddr -= CONFIG_TRACE_BUFFER_SIZE;
> gd->trace_buff = map_sysmem(gd->relocaddr,
> CONFIG_TRACE_BUFFER_SIZE);
> debug("Reserving %dk for trace data at: %08lx\n",
>   CONFIG_TRACE_BUFFER_SIZE >> 10, gd->relocaddr);
> -#endif
>
> return 0;
>  }
> +#endif
>
>  #if defined(CONFIG_VIDEO) && (!defined(CONFIG_PPC) ||
> defined(CONFIG_8xx)) \
> && !defined(CONFIG_ARM) && !defined(CONFIG_X86)
> @@ -833,7 +833,9 @@ static init_fnc_t init_sequence_f[] = {
>  #endif
> setup_mon_len,
> setup_fdt,
> +#ifdef CONFIG_TRACE
> trace_early_init,
> +#endif
>  #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
> /* TODO: can this go into arch_cpu_init()? */
> probecpu,
> @@ -977,7 +979,9 @@ static init_fnc_t init_sequence_f[] = {
>  #ifdef CONFIG_LCD
> reserve_lcd,
>  #endif
> +#ifdef CONFIG_TRACE
> reserve_trace,
> +#endif
> /* TODO: Why the dependency on CONFIG_8xx? */
>  #if defined(CONFIG_VIDEO) && (!defined(CONFIG_PPC) ||
> defined(CONFIG_8xx)) \
> && !defined(CONFIG_ARM) && !defined(CONFIG_X86)
>

Does the static inline not work for you? What toolchain are you using? I
assume this is ARM?

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

Re: [U-Boot] [PATCH v2 1/5] bootm: Handle errors consistently

[Tom Rini]

On Fri, Jul 05, 2013 at 12:52:03PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, Jul 5, 2013 at 5:59 AM, Tom Rini  wrote:
> 
> > On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:
> >
> > > A recent bootm fix left the error path incomplete. Reinstate this so that
> > > failures in bootm stages are handled properly.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > > Changes in v2:
> > > - Correct checking in the no-error case
> >
> >
> > OK, this conflicts with the change I posted (and pushed later than I
> > thought I had).  Can you confirm the code is good in mainline now?
> > Thanks!
> >
> 
> It's close, but I think it still needs this near the end
> of do_bootm_states(), something like:
> 
>  else if (ret == BOOTM_ERR_RESET) do_reset(cmdtp, flag, argc, argv); + else
> if (ret) + puts("subcommand not supported\n"); return ret;
> 
> If you agree, I can prepare a patch as part of the bootz update.

How do we get there in the code?  When we do any subcalls is where we've
got that puts already.  Failures from that point on are either the OS
bootm part failed (and return is > 0) or one of the BOOTM_ERR codes.  Or
did I miss a case still?

-- 
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 v2 1/5] bootm: Handle errors consistently

[Simon Glass]

Hi Tom,

On Fri, Jul 5, 2013 at 1:15 PM, Tom Rini  wrote:

> On Fri, Jul 05, 2013 at 12:52:03PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, Jul 5, 2013 at 5:59 AM, Tom Rini  wrote:
> >
> > > On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:
> > >
> > > > A recent bootm fix left the error path incomplete. Reinstate this so
> that
> > > > failures in bootm stages are handled properly.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > > Changes in v2:
> > > > - Correct checking in the no-error case
> > >
> > >
> > > OK, this conflicts with the change I posted (and pushed later than I
> > > thought I had).  Can you confirm the code is good in mainline now?
> > > Thanks!
> > >
> >
> > It's close, but I think it still needs this near the end
> > of do_bootm_states(), something like:
> >
> >  else if (ret == BOOTM_ERR_RESET) do_reset(cmdtp, flag, argc, argv); +
> else
> > if (ret) + puts("subcommand not supported\n"); return ret;
> >
> > If you agree, I can prepare a patch as part of the bootz update.
>
> How do we get there in the code?  When we do any subcalls is where we've
> got that puts already.  Failures from that point on are either the OS
> bootm part failed (and return is > 0) or one of the BOOTM_ERR codes.  Or
> did I miss a case still?
>

I think this is when the boot_os function returns an error. At least the
old code had quite a lot of printf()s for that case.

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

Re: [U-Boot] [PATCH v2 1/5] bootm: Handle errors consistently

[Tom Rini]

On Fri, Jul 05, 2013 at 01:21:09PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, Jul 5, 2013 at 1:15 PM, Tom Rini  wrote:
> 
> > On Fri, Jul 05, 2013 at 12:52:03PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, Jul 5, 2013 at 5:59 AM, Tom Rini  wrote:
> > >
> > > > On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:
> > > >
> > > > > A recent bootm fix left the error path incomplete. Reinstate this so
> > that
> > > > > failures in bootm stages are handled properly.
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > > > ---
> > > > > Changes in v2:
> > > > > - Correct checking in the no-error case
> > > >
> > > >
> > > > OK, this conflicts with the change I posted (and pushed later than I
> > > > thought I had).  Can you confirm the code is good in mainline now?
> > > > Thanks!
> > > >
> > >
> > > It's close, but I think it still needs this near the end
> > > of do_bootm_states(), something like:
> > >
> > >  else if (ret == BOOTM_ERR_RESET) do_reset(cmdtp, flag, argc, argv); +
> > else
> > > if (ret) + puts("subcommand not supported\n"); return ret;
> > >
> > > If you agree, I can prepare a patch as part of the bootz update.
> >
> > How do we get there in the code?  When we do any subcalls is where we've
> > got that puts already.  Failures from that point on are either the OS
> > bootm part failed (and return is > 0) or one of the BOOTM_ERR codes.  Or
> > did I miss a case still?
> >
> 
> I think this is when the boot_os function returns an error. At least the
> old code had quite a lot of printf()s for that case.

We had a printf per subcommand before, and just a single one now.  We
didn't say the 'go' subcommand failed however, just what the
function happened to print out.

-- 
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 v2 1/5] bootm: Handle errors consistently

[Simon Glass]

Hi Tom,

On Fri, Jul 5, 2013 at 1:29 PM, Tom Rini  wrote:

> On Fri, Jul 05, 2013 at 01:21:09PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, Jul 5, 2013 at 1:15 PM, Tom Rini  wrote:
> >
> > > On Fri, Jul 05, 2013 at 12:52:03PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, Jul 5, 2013 at 5:59 AM, Tom Rini  wrote:
> > > >
> > > > > On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:
> > > > >
> > > > > > A recent bootm fix left the error path incomplete. Reinstate
> this so
> > > that
> > > > > > failures in bootm stages are handled properly.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > - Correct checking in the no-error case
> > > > >
> > > > >
> > > > > OK, this conflicts with the change I posted (and pushed later than
> I
> > > > > thought I had).  Can you confirm the code is good in mainline now?
> > > > > Thanks!
> > > > >
> > > >
> > > > It's close, but I think it still needs this near the end
> > > > of do_bootm_states(), something like:
> > > >
> > > >  else if (ret == BOOTM_ERR_RESET) do_reset(cmdtp, flag, argc, argv);
> +
> > > else
> > > > if (ret) + puts("subcommand not supported\n"); return ret;
> > > >
> > > > If you agree, I can prepare a patch as part of the bootz update.
> > >
> > > How do we get there in the code?  When we do any subcalls is where
> we've
> > > got that puts already.  Failures from that point on are either the OS
> > > bootm part failed (and return is > 0) or one of the BOOTM_ERR codes.
>  Or
> > > did I miss a case still?
> > >
> >
> > I think this is when the boot_os function returns an error. At least the
> > old code had quite a lot of printf()s for that case.
>
> We had a printf per subcommand before, and just a single one now.  We
> didn't say the 'go' subcommand failed however, just what the
> function happened to print out.
>

Yes that looks right to me. But I believe that the GO command is not
supposed to return, so it might be harmless to put the message there in all
cases. If not, we can add a special case for GO.

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

Re: [U-Boot] test HYP mode in arch/arm/cpu/armv7/start.S

[Albert ARIBAUD]

Hi tiger...@viatech.com.cn,

On Tue, 2 Jul 2013 10:22:03 +0800,  wrote:

> Hi, experts:
> I found it would determine whether CPU was in HYP mode or not before
> switching to SVC mode in reset handler.
> 
> So, why need to test HYP mode?
> So, which case could cause CPU in HYP mode during U-Boot boot stage?

IIUC, U-Boot might actually be started from some earlier stage, e.g.
some ROM code, which may have switched the CPU into HYP mode already.

> Best wishes,

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

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

[Albert ARIBAUD]

Hi Bo,

On Tue,  2 Jul 2013 12:35:54 +, Bo Shen 
wrote:

> flush cache before disable it
> 
> Signed-off-by: Bo Shen 
> ---
>  arch/arm/cpu/arm926ejs/cpu.c |5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/cpu.c b/arch/arm/cpu/arm926ejs/cpu.c
> index 626384c..10aa165 100644
> --- a/arch/arm/cpu/arm926ejs/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/cpu.c
> @@ -46,15 +46,14 @@ int cleanup_before_linux (void)
>  
>   disable_interrupts ();
>  
> + /* flush I/D-cache */
> + cache_flush();
>  
>   /* turn off I/D-cache */
>   icache_disable();
>   dcache_disable();
>   l2_cache_disable();
>  
> - /* flush I/D-cache */
> - cache_flush();
> -
>   return 0;
>  }

What is this change supposed to fix? There is no need to flush before
disabling, and actually, flushing before disabling runs the risk that
between the two, some cache lines be dirtied again so that cache and
memory won't be coherent any more.

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

Re: [U-Boot] [PATCHv2] socfpga: Move board/socfpga_cyclone5 to board/socfpga

[Albert ARIBAUD]

Hi dingu...@altera.com,

On Tue, 2 Jul 2013 17:00:18 -0500,  wrote:

> From: Dinh Nguyen 
> 
> Because the SOCFPGA platform will include support for Cyclone V and
> Arria V FPGA parts, renaming socfpga_cyclone5 folder to socfpga to
> be more generic.
> 
> Signed-off-by: Dinh Nguyen 
> Reviewed-by: Pavel Machek 
> Cc: Chin Liang See 
> Cc: Wolfgang Denk 
> CC: Pavel Machek 
> Cc: Tom Rini 
> 
> v2:
> - Add Reviewed-by: Pavel Machek
> - Cc: Tom Rini
> ---

Do you really mean that V2 is the exact same code as V1? If it is, then
V2 is unneeded. And if V2 is different from V1, then history should
tells us the difference(s).

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

Re: [U-Boot] Marvell SheevaPlug v2013.04 Refresh (ask for review)

[Albert ARIBAUD]

Hi Gérald,

On Tue, 02 Jul 2013 23:17:51 +0200, DrEagle  wrote:

> Hi,
> 
> I have started to rework all the MVSDIO driver, and some more enhancements, 
> to make a cool updated and workable SheevaPlug.
> I have take the v2013.04 denx uBoot to base my patchs.
> 
> If you can take a look inside and give me needed feedback.
> 
> I want to precise that I do not easily practice GIT features.

Pease submit patch according to the patch submission guidelines at
. Especially, do not send
patches to the list as attachments; instead, use 'git format-patch' and
'git send-email'. Also, put the relevant custodians and/or maintainers
in Cc: of your mail.

> Regards,
> Gérald

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

Re: [U-Boot] [U-boot] monitor length question

[Albert ARIBAUD]

Hi tiger...@viatech.com.cn,

On Wed, 3 Jul 2013 11:19:13 +0800,  wrote:

> Hi, experts:
> I am studying u-boot latest code now.
> I have a question about monitor length.
> 1. in board_init_f() function in arch\arm\lib\board.c
>Gd->mon_len = _bss_end_ofs;
> 2. in board_init_r() function in arch\arm\lib\board.c
> 　　Monitor_flash_len = _end_ofs;
> 
> Because _end_ofs < _bss_end_ofs, so it confused me!
> Why need to discard some data when re-calculating monitor_in board_init_r() 
> function.

Both functions don't compute the same thing.

GD->mon_len computes the monitor length including BSS, because it is
the length in RAM at run time, which matters e.g. for relocating  the
monitor -- relocation copies the text and data but not the BSS.

Monitor_flash_len, as the name implies, computes the monitor length
excluding BSS, because this is the length in FLASH, and BSS does not
exist in the flashed image; even if we know its size at build time,
BSS will only exist after relocation, just before entering board_init_r.

> Best wishes,

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

Re: [U-Boot] [PATCH] cramfs: fix bug for wrong filename comparison

[Albert ARIBAUD]

Hi Holger,

On Thu,  4 Jul 2013 10:29:46 +0200, Holger Brunck
 wrote:

> If we have the following entry in cramfs:
> => cramfsls
>  -rw-r--r--  1922689 uImage
> 
> cramfsload would also succeed if we try to do:
> => cramfsload uImage_1
> CRAMFS load complete: 1922689 bytes loaded to 0x10
> 
> The old code succeeds if the begin of the filename we search matches
> with a filename stored in cramfs. But the searched file may have
> additional characters and is therfore not the file we are looking for.
> So compare also the length of the filename we search and the
> filename we found in cramfs. This leads to:
> => cramfsload uImage_1
> can't find corresponding entry
> CRAMFS LOAD ERROR<0> for uImage_1!
> 
> which is the behaviour we want.
> Signed-off-by: Holger Brunck 
> cc: Wolfgang Denk 
> ---

Can't the commit message above be summarized as follows?

---8<---
"cramfsload uImage_1" succeeds even though the actual file is named
"uImage".

Fix file name comparison when one name is the prefix of the other.
---8<---

The demonstrative part of the commit message can go here, below the
commit message delimiter '---'.

>  fs/cramfs/cramfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/cramfs/cramfs.c b/fs/cramfs/cramfs.c
> index 910955d..e578a1e 100644
> --- a/fs/cramfs/cramfs.c
> +++ b/fs/cramfs/cramfs.c
> @@ -126,7 +126,8 @@ static unsigned long cramfs_resolve (unsigned long begin, 
> unsigned long offset,
>   namelen--;
>   }
>  
> - if (!strncmp (filename, name, namelen)) {
> + if (!strncmp(filename, name, namelen) &&
> + (namelen == strlen(filename))) {
>   char *p = strtok (NULL, "/");
>  
>   if (raw && (p == NULL || *p == '\0'))


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

Re: [U-Boot] [PATCH] zmx25: Select CONFIG_OF_LIBFDT

[Albert ARIBAUD]

Hi Fabio,

On Thu,  4 Jul 2013 17:30:08 -0300, Fabio Estevam 
wrote:

> From: Fabio Estevam 
> 
> Allow the boot of a device tree kernel.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  include/configs/zmx25.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/zmx25.h b/include/configs/zmx25.h
> index e9216d9..871009d 100644
> --- a/include/configs/zmx25.h
> +++ b/include/configs/zmx25.h
> @@ -90,6 +90,7 @@
>  #include 
>  #define CONFIG_CMD_NET
>  #define CONFIG_CMD_CACHE
> +#define CONFIG_OF_LIBFDT
>  
>  /*
>   * Additional command

CC:ing the board maintainer as per the MAINTAINER file.

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

Re: [U-Boot] [PATCH] zmx25: Select CONFIG_OF_LIBFDT

[Fabio Estevam]

Hi Albert,

On Fri, Jul 5, 2013 at 6:25 PM, Albert ARIBAUD
 wrote:

> CC:ing the board maintainer as per the MAINTAINER file.

I added Matthias on Cc on my original patch submission.

Regards,

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

Re: [U-Boot] [PATCH] zmx25: Select CONFIG_OF_LIBFDT

[Albert ARIBAUD]

Hi Fabio,

On Fri, 5 Jul 2013 18:32:32 -0300, Fabio Estevam 
wrote:

> Hi Albert,
> 
> On Fri, Jul 5, 2013 at 6:25 PM, Albert ARIBAUD
>  wrote:
> 
> > CC:ing the board maintainer as per the MAINTAINER file.
> 
> I added Matthias on Cc on my original patch submission.

If <1372969808-29545-1-git-send-email-feste...@gmail.com> is your
original patch submission, then no, Matthias was not Cc:ed there.

> Regards,
> 
> Fabio Estevam

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

Re: [U-Boot] [PATCH] zmx25: Select CONFIG_OF_LIBFDT

[Albert ARIBAUD]

Hi Fabio again,

On Fri, 5 Jul 2013 23:45:38 +0200, Albert ARIBAUD
 wrote:

> Hi Fabio,
> 
> On Fri, 5 Jul 2013 18:32:32 -0300, Fabio Estevam 
> wrote:
> 
> > Hi Albert,
> > 
> > On Fri, Jul 5, 2013 at 6:25 PM, Albert ARIBAUD
> >  wrote:
> > 
> > > CC:ing the board maintainer as per the MAINTAINER file.
> > 
> > I added Matthias on Cc on my original patch submission.
> 
> If <1372969808-29545-1-git-send-email-feste...@gmail.com> is your
> original patch submission, then no, Matthias was not Cc:ed there.

I note that, for some reason, my message had Matthias in Cc: but on the
list his Cc: was removed -- IIRC, that's a bug in the mailing list SW.
Maybe the same happened to your original submission.

> > Regards,
> > 
> > Fabio Estevam

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