Re: [U-Boot] [IXP42x PATCH series v5 06/17] support CONFIG_SYS_LDSCRIPT on ARM

[Michael Schwingen]

Am 05/23/2011 02:42 AM, schrieb Marek Vasut:
> On Monday, May 23, 2011 12:00:02 AM Michael Schwingen wrote:
>> Signed-off-by: Michael Schwingen 
>> ---
> Honestly, I don't really understand this one ... Wolfgang, is this one OK to 
> merge ?
The idea was to be able to define the LD_SCRIPT variable in the board
config file.

However, it seems that another patch in the toplevel config.mk added the
same functionality after I wrote this, so this patch can be dropped
completely.

cu
Michael

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

[U-Boot] Pull request: u-boot-arm

[Albert ARIBAUD]

Hi Wolfgang,

The following changes since commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3:

   .gitignore: update list of u-boot.* files and add *.bin (2011-05-22 
23:46:26 +0200)

are available in the git repository at:
   git://git.denx.de/u-boot-arm master

David Müller (ELSOFT AG) (1):
   VCMA9: use ARM relocation feature to fix build error

Fabio Estevam (6):
   mx31pdk: Clean up mx31pdk.h file
   MX53: Add initial support for MX53SMD board.
   MX51: vision: Let video mode struct be independant of watchdog.
   MX51: vision2: Fix build for vision2 board.
   MX53: Handle silicon revision 2.1 case
   MX53: Remove CONFIG_SYS_BOOTMAPSZ from mx53 config files.

Jason Kridner (1):
   BeagleBoard: fixed typo in typecast

Jason Liu (2):
   MX53: support for freescale MX53LOCO board
   mx5: board: code clean up for checkboard code

Michael Walle (1):
   mvsata: issue hard reset on initialization

Shawn Guo (2):
   mx5: Remove unnecessary CONFIG_SYS_BOOTMAPSZ definition
   mx5: Fix CONFIG_OF_LIBFDT redefined warning

Stefano Babic (3):
   MX31: Make get_reset_cause() static and drop unreachable code
   MX5: drop config.mk from efikamx board
   MX31: drop warnings due to missing prototype for mxc_watchdog_reset()

  MAINTAINERS|2 +
  arch/arm/cpu/arm1136/mx31/generic.c|6 +-
  arch/arm/cpu/armv7/mx5/soc.c   |   10 +-
  arch/arm/include/asm/arch-mx31/clock.h |1 +
  board/efikamx/efikamx.c|   42 +---
  board/freescale/mx51evk/mx51evk.c  |   36 +---
  board/freescale/mx53evk/mx53evk.c  |   21 +--
  .../config.mk => freescale/mx53loco/Makefile}  |   36 ++-
  board/freescale/mx53loco/imximage.cfg  |   96 ++
  board/freescale/mx53loco/mx53loco.c|  302 

  .../config.mk => freescale/mx53smd/Makefile}   |   35 ++-
  board/freescale/mx53smd/imximage.cfg   |   96 ++
  board/freescale/mx53smd/mx53smd.c  |  229 +++
  board/ti/beagle/beagle.c   |2 +-
  board/ttcontrol/vision2/vision2.c  |   47 +---
  boards.cfg |6 +-
  drivers/block/mvsata_ide.c |   10 +-
  include/configs/VCMA9.h|5 +
  include/configs/mx31pdk.h  |   32 +-
  include/configs/mx51evk.h  |3 -
  include/configs/mx53evk.h  |3 -
  include/configs/mx53loco.h |  185 
  include/configs/mx53smd.h  |  191 
  include/configs/vision2.h  |1 +
  24 files changed, 1206 insertions(+), 191 deletions(-)
  rename board/{efikamx/config.mk => freescale/mx53loco/Makefile} (51%)
  create mode 100644 board/freescale/mx53loco/imximage.cfg
  create mode 100644 board/freescale/mx53loco/mx53loco.c
  rename board/{ttcontrol/vision2/config.mk => 
freescale/mx53smd/Makefile} (50%)
  create mode 100644 board/freescale/mx53smd/imximage.cfg
  create mode 100644 board/freescale/mx53smd/mx53smd.c
  create mode 100644 include/configs/mx53loco.h
  create mode 100644 include/configs/mx53smd.h

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

Re: [U-Boot] AT91: CFI support broken

[Stefan Roese]

Hi Jens,

On Friday 20 May 2011 15:01:21 Jens Scharsig wrote:
> >> u-boot/drivers/mtd/cfi_flash.c:576: undefined reference to `reset_timer'
> >> 
> >> I think this patch should be revert, as long as other modules need the
> >> reset_timer function.
> >> 
> >> Can anybody confirm this
> > 
> > I think we should fix the place where reset_timer() is still used, to use
> > get_timer() only. All other drivers that are used in atmel context do
> > not use reset_timer(), but rely on the fact that get_timer() is
> > monotonic. reset_timer() resets the value back to zero.
> > 
> > Best Regards,
> > Reinhard
> 
> what do you think about?

I would welcome it, if somebody would provide a patch to remove the 
reset_timer() call from the common CFI driver.

Best regards,
Stefan

--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] AT91: CFI support broken

[Graeme Russ]

On Monday, May 23, 2011, Stefan Roese  wrote:
> Hi Jens,
>
> On Friday 20 May 2011 15:01:21 Jens Scharsig wrote:
>> >> u-boot/drivers/mtd/cfi_flash.c:576: undefined reference to `reset_timer'
>> >>
>> >> I think this patch should be revert, as long as other modules need the
>> >> reset_timer function.
>> >>
>> >> Can anybody confirm this
>> >
>> > I think we should fix the place where reset_timer() is still used, to use
>> > get_timer() only. All other drivers that are used in atmel context do
>> > not use reset_timer(), but rely on the fact that get_timer() is
>> > monotonic. reset_timer() resets the value back to zero.
>> >
>> > Best Regards,
>> > Reinhard
>>
>> what do you think about?
>
> I would welcome it, if somebody would provide a patch to remove the
> reset_timer() call from the common CFI driver.
>

Working on it now

Regards,

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

Re: [U-Boot] [STATUS] v2011.06-rc1 released

[Minkyu Kang]

Dear Albert ARIBAUD,

On 23 May 2011 15:50, Albert ARIBAUD  wrote:
>> 3. a pull request for
>>
>> http://git.denx.de/u-boot-samsung.git
>>
>> to fix
>>
>> s5p_mmc.c: In function 's5p_mmc_initialize':
>> s5p_mmc.c:469: error: 'struct mmc' has no member named 'm_bmax'
>>
>> by
>>
>>
>> http://git.denx.de/?p=u-boot/u-boot-samsung.git;a=commit;h=f99d5b34c2c173a5e4a82e638e74b3e95f480b82
>
> Minkyu: I'll request a pull of u-boot-arm/master within a few minutes. Once
> applied by Wolfgang, please base the samsung pull req on it.
>

OK.
I'll send the pull_request after rebase.

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] common/cmd_fdt.c: fix wrong data displayed in fdt print

[Haojian Zhuang]

From: Haojian Zhuang 

All data in dtb is big endian. Some ARM devices are little-endian.
In print_data(), it displays data with big-endian format. For ARM device,
data should be converted to little-endian first.

Signed-off-by: Haojian Zhuang 
Cc: Gerald Van Baren 
---
 common/cmd_fdt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 3d0c2b7..9bdecca 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -665,7 +665,7 @@ static void print_data(const void *data, int len)
 
printf("<");
for (j = 0, p = data; j < len/4; j ++)
-   printf("0x%x%s", p[j], j < (len/4 - 1) ? " " : "");
+   printf("0x%x%s", fdt32_to_cpu(p[j]), j < (len/4 - 1) ? 
" " : "");
printf(">");
} else { /* anything else... hexdump */
const u8 *s;
-- 
1.7.4.1

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

[U-Boot] [PATCH] powerpc/85xx: Add NAND boot support for P3041/P5020DS

[Shaohui Xie]

When booting from NAND we get the environment from NAND.

Signed-off-by: Shaohui Xie 
Signed-off-by: Kumar Gala 
---
 boards.cfg   |2 ++
 include/configs/corenet_ds.h |   29 +++--
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 9f2b118..21182b9 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -574,12 +574,14 @@ P2020RDB_SPIFLASHpowerpc mpc85xx 
p1_p2_rdb   freesca
 P3041DS  powerpc mpc85xx corenet_ds  
freescale
 P3041DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P3041DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 P3041DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P3041DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
+P3041DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P3041DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 P4080DS  powerpc mpc85xx corenet_ds  
freescale
 P4080DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P4080DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 P4080DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P4080DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 P5020DS  powerpc mpc85xx corenet_ds  
freescale
 P5020DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 P5020DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
+P5020DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 mpq101   powerpc mpc85xx mpq101  
mercury-   mpq101
 stxgp3   powerpc mpc85xx stxgp3  stx
 stxssa   powerpc mpc85xx stxssa  stx   
 -   stxssa
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 9ba032b..2e45b92 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -91,6 +91,11 @@
 #define CONFIG_SYS_MMC_ENV_DEV  0
 #define CONFIG_ENV_SIZE0x2000
 #define CONFIG_ENV_OFFSET  (512 * 1097)
+#elif defined(CONFIG_NAND)
+#define CONFIG_SYS_EXTRA_ENV_RELOC
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_SIZECONFIG_SYS_NAND_BLOCK_SIZE
+#define CONFIG_ENV_OFFSET  (5 * CONFIG_SYS_NAND_BLOCK_SIZE)
 #else
 #define CONFIG_ENV_IS_IN_FLASH
 #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE - 
CONFIG_ENV_SECT_SIZE)
@@ -196,10 +201,10 @@
 #define CONFIG_SYS_FLASH_BASE_PHYS CONFIG_SYS_FLASH_BASE
 #endif
 
-#define CONFIG_SYS_BR0_PRELIM \
-   (BR_PHYS_ADDR((CONFIG_SYS_FLASH_BASE_PHYS + 0x800)) | \
-BR_PS_16 | BR_V)
-#define CONFIG_SYS_OR0_PRELIM  ((0xf8000ff7 & ~OR_GPCM_SCY & ~OR_GPCM_EHTR) \
+#define CONFIG_SYS_FLASH_BR_PRELIM \
+   (BR_PHYS_ADDR((CONFIG_SYS_FLASH_BASE_PHYS + 0x800)) \
+| BR_PS_16 | BR_V)
+#define CONFIG_SYS_FLASH_OR_PRELIM ((0xf8000ff7 & ~OR_GPCM_SCY & 
~OR_GPCM_EHTR) \
| OR_GPCM_SCY_8 | OR_GPCM_EHTR_CLEAR)
 
 #define CONFIG_SYS_BR1_PRELIM \
@@ -268,9 +273,21 @@
   | OR_FCM_TRLX \
   | OR_FCM_EHTR)
 
-#define CONFIG_SYS_BR2_PRELIM  CONFIG_SYS_NAND_BR_PRELIM /* NAND Base Address 
*/
-#define CONFIG_SYS_OR2_PRELIM  CONFIG_SYS_NAND_OR_PRELIM /* NAND Options */
+#ifdef CONFIG_NAND
+#define CONFIG_SYS_BR0_PRELIM  CONFIG_SYS_NAND_BR_PRELIM /* NAND Base Address 
*/
+#define CONFIG_SYS_OR0_PRELIM  CONFIG_SYS_NAND_OR_PRELIM /* NAND Options */
+#define CONFIG_SYS_BR2_PRELIM  CONFIG_SYS_FLASH_BR_PRELIM /* NOR Base Address 
*/
+#define CONFIG_SYS_OR2_PRELIM  CONFIG_SYS_FLASH_OR_PRELIM /* NOR Options */
+#else
+#define CONFIG_SYS_BR0_PRELIM  CONFIG_SYS_FLASH_BR_PRELIM /* NOR Base Address 
*/
+#define CONFIG_SYS_OR0_PRELIM  CONFIG_SYS_FLASH_OR_PRELIM /* NOR Options */
+#define CONFIG_SYS_BR2_PRELIM  CONFIG_SYS_NAND_BR_PRELIM /* NAND Base Address 
*/
+#define CONFIG_SYS_OR2_PRELIM  CONFIG_SYS_NAND_OR_PRELIM /* NAND Options */
+#endif
 #endif /* CONFIG_NAND_FSL_ELBC */
+#else
+#define CONFIG_SYS_BR0_PRELIM  CONFIG_SYS_FLASH_BR_PRELIM /* NOR Base Address 
*/
+#define CONFIG_SYS_OR0_PRELIM  CONFIG_SYS_FLASH_OR_PRELIM /* NOR Options */
 #endif
 
 #define CONFIG_SYS_FLASH_EMPTY_INFO
-- 
1.6.4


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

[U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Matthias Weisser]

In some cases (e.g. bootm with a elf payload which is already at the right
position) there is a in place copy of data to the same address. Catching this
saves some ms while booting.

Signed-off-by: Matthias Weisser 
---
Changes since V1:
  - Made subject more informative
  - Removed the optimization from bcopy as bcopy is not used anywhere
  
 lib/string.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/lib/string.c b/lib/string.c
index b375b81..2c4f0ec 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count)
unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
char *d8, *s8;
 
+   if (src == dest)
+   return dest;
+
/* while all data is aligned (common case), copy a word at a time */
if ( (((ulong)dest | (ulong)src) & (sizeof(*dl) - 1)) == 0) {
while (count >= sizeof(*dl)) {
@@ -497,6 +500,9 @@ void * memmove(void * dest,const void *src,size_t count)
 {
char *tmp, *s;
 
+   if (src == dest)
+   return dest;
+
if (dest <= src) {
tmp = (char *) dest;
s = (char *) src;
-- 
1.7.0.4

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

[U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Matthias Weisser]

In some cases (e.g. bootm with a elf payload which is already at the right
position) there is a in place copy of data to the same address. Catching this
saves some ms while booting.

Signed-off-by: Matthias Weisser 
---
 arch/arm/lib/memcpy.S |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 3b5aeec..f655256 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -60,6 +60,9 @@
 .globl memcpy
 memcpy:
 
+   cmp r0, r1
+   moveq   pc, lr
+
enter   r4, lr
 
subsr2, r2, #4
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Alexander Holler]

Am 23.05.2011 11:06, schrieb Matthias Weisser:
> In some cases (e.g. bootm with a elf payload which is already at the right
> position) there is a in place copy of data to the same address. Catching this
> saves some ms while booting.
>
> Signed-off-by: Matthias Weisser
> ---
>   arch/arm/lib/memcpy.S |3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
> index 3b5aeec..f655256 100644
> --- a/arch/arm/lib/memcpy.S
> +++ b/arch/arm/lib/memcpy.S
> @@ -60,6 +60,9 @@
>   .globl memcpy
>   memcpy:
>
> + cmp r0, r1
> + moveq   pc, lr
> +
>   enter   r4, lr
>
>   subsr2, r2, #4

The standard clearly say to both memory regions should not overlap when 
memcpy() is used, so I would say this is the wrong place to fix that.

Regards,

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

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Matthias Weißer]

Am 23.05.2011 11:30, schrieb Alexander Holler:
> Am 23.05.2011 11:06, schrieb Matthias Weisser:
>> In some cases (e.g. bootm with a elf payload which is already at the right
>> position) there is a in place copy of data to the same address. Catching this
>> saves some ms while booting.
>>
>> Signed-off-by: Matthias Weisser
>> ---
>>arch/arm/lib/memcpy.S |3 +++
>>1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
>> index 3b5aeec..f655256 100644
>> --- a/arch/arm/lib/memcpy.S
>> +++ b/arch/arm/lib/memcpy.S
>> @@ -60,6 +60,9 @@
>>.globl memcpy
>>memcpy:
>>
>> +cmp r0, r1
>> +moveq   pc, lr
>> +
>>  enter   r4, lr
>>
>>  subsr2, r2, #4
>
> The standard clearly say to both memory regions should not overlap when
> memcpy() is used, so I would say this is the wrong place to fix that.

Well, real world applications do this. And these two instructions 
shouldn't hurt a lot.

I first send a patch fixing only "my" problem in cmd_elf.c but Wolfgang 
suggested to do this globally. Please see 
http://www.mail-archive.com/u-boot@lists.denx.de/msg50612.html as reference.

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

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Albert ARIBAUD]

Le 23/05/2011 11:30, Alexander Holler a écrit :
> Am 23.05.2011 11:06, schrieb Matthias Weisser:
>> In some cases (e.g. bootm with a elf payload which is already at the right
>> position) there is a in place copy of data to the same address. Catching this
>> saves some ms while booting.
>>
>> Signed-off-by: Matthias Weisser
>> ---
>>arch/arm/lib/memcpy.S |3 +++
>>1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
>> index 3b5aeec..f655256 100644
>> --- a/arch/arm/lib/memcpy.S
>> +++ b/arch/arm/lib/memcpy.S
>> @@ -60,6 +60,9 @@
>>.globl memcpy
>>memcpy:
>>
>> +cmp r0, r1
>> +moveq   pc, lr
>> +
>>  enter   r4, lr
>>
>>  subsr2, r2, #4
>
> The standard clearly say to both memory regions should not overlap when
> memcpy() is used, so I would say this is the wrong place to fix that.

I think the intent here is not to enforce the standard but to handle an 
actual, and degenerate, copy request in the most efficient manner, and 
in that respect, the patch does its job.

Besides, if the patch was about enforcing the standard, then I would 
consider it highly more efficient to check the areas once in the memcpy 
function than duplicating this check before each call to the function, 
considering that the place where the copy happens is not necessarily the 
one where the source and destination were computed.

> Regards,
>
> Alexander

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

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Alexander Holler]

Am 23.05.2011 11:46, schrieb Matthias Weißer:

>> The standard clearly say to both memory regions should not overlap when
>> memcpy() is used, so I would say this is the wrong place to fix that.
>
> Well, real world applications do this. And these two instructions
> shouldn't hurt a lot.

Real bugs to this. Just see e.g the long discussion about some changes 
fo memcpy done in the glibc lately and what that did for flash-users 
because flash seemed to the same stupid stuff.

Regards,

Alexander

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

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Alexander Holler]

Hello,

Am 23.05.2011 11:49, schrieb Albert ARIBAUD:

>> The standard clearly say to both memory regions should not overlap when
>> memcpy() is used, so I would say this is the wrong place to fix that.
>
> I think the intent here is not to enforce the standard but to handle an
> actual, and degenerate, copy request in the most efficient manner, and
> in that respect, the patch does its job.
>
> Besides, if the patch was about enforcing the standard, then I would
> consider it highly more efficient to check the areas once in the memcpy
> function than duplicating this check before each call to the function,
> considering that the place where the copy happens is not necessarily the
> one where the source and destination were computed.

A fool proof solution would be to always use memmove() and get rid of 
memcpy(). But checking for overlapped regions in memcpy() is imho the 
wrong way. This just leads to more possible wrong code which uses 
memcpy() when it should use memmove().

Regards,

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

On 23/05/11 16:29, Albert ARIBAUD wrote:
> Hi all,
> 
> Sorry, could not follow the discussion although I find it very 
> interesting, so I will handle the task of coming in late and asking the 
> silly questions.
> 
> Le 23/05/2011 07:25, Graeme Russ a écrit :
> 
>> On Mon, May 23, 2011 at 3:02 PM, J. William Campbell
>>   wrote:
>>> On 5/22/2011 6:42 PM, Graeme Russ wrote:

 OK, so in summary, we can (in theory) have:
   - A timer API in /lib/ with a single u32 get_timer(u32 base) function
   - A HAL with two functions
 - u32 get_raw_ticks()
 - u32 get_raw_tick_rate() which returns the tick rate in kHz (which
   max's out at just after 4GHz)
   - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
 and get_tick_rate() to correctly maintain the ms counter used by
 get_timer() - This function can be weak (so next point)
   - If the hardware supports a native 32-bit ms counter, get_raw_ms()
 can be overridden to simply return the hardware counter. In this case,
 get_raw_ticks() would return 1
> 
> Are you sure you did not mean 'get_raw_ticks_rate' here? Besides, I'd 

Yes, I did mean get_raw_ticks_rate()

> like the name to specify the units used: 'get_raw_ticks_rate_in_khz' (or 
> conversively 'get_raw_ticks_per_ms', depending on which is simpler to 
> implement and use).
> 

indeed, get_raw_ticks_per_ms() is a better name

   - Calling of get_raw_ticks() regularly in the main loop (how ofter will
 depend on the raw tick rate, but I image it will never be necessary
 to call more often than once every few minutes)
> 
> That's to keep track of get_raw_ticks() rollovers, right? And then the 

Yes

> get_timer function (which, again, I would prefer to have '... in ms' 
> expressed in its name) would call get_raw_ticks() in confidence that at 
> most one rollover may have occurred since the last time the helper 
> function was called, so a simple difference of the current vs last tick 
> value will always be correct.

Correct - And a change to get_ms_timer() could be in order if generally
supported, but this would be a big patch across a lot of code for a simple
rename

   - If the hardware implements a native 32-bit 1ms counter, no call in
 the main loop is required
   - An optional HAL function u32 get_raw_us() which can be used for
 performance profiling (must wrap correctly)
>>>
>>> Hi All,
>>>   Graeme, I think you have stated exactly what is the "best" approach to
>>> this problem.  I will provide a version of "get_raw_ms" that is  initialized
>>> using get_raw_tick_rate that will work for all "reasonable" values of
>>> raw_tick_rate. This will be the "generic" solution. Both the initialization
>>> function and the get_raw_ms function can be overridden if there is reason to
>>> do so, like "exact" clock rates. I will do the same with get_raw_us. This
>>> will be posted sometime on Monday for people to review, and to make sure I
>>> didn't get too far off base. Thank you to both Graeme and Reinhard for
>>> looking at/working on this.. Hopefully, this solution will put this timing
>>> issue to rest for all future ports as well as the presently existing ones.
> 
> In Greame's description, I did not see a get_raw_ms, only a get_raw_us. 
> Was this last one a typo or is that a third HAL function?

get_raw_ms() is used by get_timer(). get_raw_us() is an optional function
which can be used for performance profiling


>> Great - I am in the middle of cleaning up the current usages of the timer
>> API, reducing it all down to get_timer() - I will then 'libify'
>> get_timer() and setup the hooks into the HAL get_raw_ticks() and
>> get_raw_tick_rate() API
>>
>> I think there will need to be a lot of cleanup, especially in arch/arm to
>> get this to all fit
>>
>> Regards,
>>
>> Graeme
> 
> Amicalement,

Regards,

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

[U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

There is no need to use get_timer() and reset_timer() and there are build
breakages occuring because of them (specifically cfi_flash). Remove any
usage outside arch/ to fix build breakages and to prepare for complete
removal

Signed-off-by: Graeme Russ 
---
checkpatch complains about long lines and brace usage in the board specific
flash.c files - They are deprecated and not worth fixing for style

 board/BuS/EB+MCF-EV123/flash.c |   10 ++
 board/cobra5272/flash.c|   10 ++
 board/idmr/flash.c |   10 ++
 drivers/block/mg_disk.c|1 -
 drivers/mtd/cfi_flash.c|2 --
 5 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/board/BuS/EB+MCF-EV123/flash.c b/board/BuS/EB+MCF-EV123/flash.c
index 3c36367..8b7f957 100644
--- a/board/BuS/EB+MCF-EV123/flash.c
+++ b/board/BuS/EB+MCF-EV123/flash.c
@@ -157,6 +157,7 @@ int amd_flash_erase_sector(flash_info_t * info, int sector)
 {
int state;
ulong result;
+   ulong start;

volatile u16 *addr =
(volatile u16 *) (info->start[sector]);
@@ -171,13 +172,13 @@ int amd_flash_erase_sector(flash_info_t * info, int 
sector)

/* wait until flash is ready */
state = 0;
-   set_timer (0);
+   start = get_timer(0);

do {
result = *addr;

/* check timeout */
-   if (get_timer (0) > CONFIG_SYS_FLASH_ERASE_TOUT) {
+   if (get_timer(start) > CONFIG_SYS_FLASH_ERASE_TOUT) {
MEM_FLASH_ADDR1 = CMD_READ_ARRAY;
state = ERR_TIMOUT;
}
@@ -267,6 +268,7 @@ volatile static int amd_write_word (flash_info_t * info, 
ulong dest, u16 data)
ulong result;
int cflag, iflag;
int state;
+   ulong start;

/*
 * Check if Flash is (sufficiently) erased
@@ -295,7 +297,7 @@ volatile static int amd_write_word (flash_info_t * info, 
ulong dest, u16 data)
*addr = data;

/* arm simple, non interrupt dependent timer */
-   set_timer (0);
+   start = get_timer(0);

/* wait until flash is ready */
state = 0;
@@ -303,7 +305,7 @@ volatile static int amd_write_word (flash_info_t * info, 
ulong dest, u16 data)
result = *addr;

/* check timeout */
-   if (get_timer (0) > CONFIG_SYS_FLASH_ERASE_TOUT) {
+   if (get_timer(start) > CONFIG_SYS_FLASH_ERASE_TOUT) {
state = ERR_TIMOUT;
}
if (!state && ((result & BIT_RDY_MASK) == (data & 
BIT_RDY_MASK)))
diff --git a/board/cobra5272/flash.c b/board/cobra5272/flash.c
index 33c9361..e8f02eb 100644
--- a/board/cobra5272/flash.c
+++ b/board/cobra5272/flash.c
@@ -147,6 +147,7 @@ int flash_erase (flash_info_t * info, int s_first, int 
s_last)
int iflag, cflag, prot, sect;
int rc = ERR_OK;
int chip1;
+   ulong start;

/* first look for protection bits */

@@ -190,7 +191,7 @@ int flash_erase (flash_info_t * info, int s_first, int 
s_last)
printf ("Erasing sector %2d ... ", sect);

/* arm simple, non interrupt dependent timer */
-   set_timer (0);
+   start = get_timer(0);

if (info->protect[sect] == 0) { /* not protected */
volatile u16 *addr =
@@ -211,7 +212,7 @@ int flash_erase (flash_info_t * info, int s_first, int 
s_last)
result = *addr;

/* check timeout */
-   if (get_timer (0) > 
CONFIG_SYS_FLASH_ERASE_TOUT) {
+   if (get_timer(start) > 
CONFIG_SYS_FLASH_ERASE_TOUT) {
MEM_FLASH_ADDR1 = CMD_READ_ARRAY;
chip1 = TMO;
break;
@@ -264,6 +265,7 @@ static int write_word (flash_info_t * info, ulong dest, 
ulong data)
int rc = ERR_OK;
int cflag, iflag;
int chip1;
+   ulong start;

/*
 * Check if Flash is (sufficiently) erased
@@ -291,7 +293,7 @@ static int write_word (flash_info_t * info, ulong dest, 
ulong data)
*addr = data;

/* arm simple, non interrupt dependent timer */
-   set_timer (0);
+   start = get_timer(0);

/* wait until flash is ready */
chip1 = 0;
@@ -299,7 +301,7 @@ static int write_word (flash_info_t * info, ulong dest, 
ulong data)
result = *addr;

/* check timeout */
-   if (get_timer (0) > CONFIG_SYS_FLASH_ERASE_TOUT) {
+   if (get_timer(start) > CONFIG_SYS_FLASH_ERASE_TOUT) {
chip1 = ERR | TMO;
break;
}
diff --git a/board/idmr/flash.c b/board/idmr/flash.c
index 57c9948..9f4ff2b 100644
--- a/board/idmr/flash.c
+++ b/board/idmr/fl

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear Graeme Russ,

sorry for jumping in late here (was busy with the ELDK 5.0 release).

In message  you wrote:
> OK, so in summary, we can (in theory) have:
>  - A timer API in /lib/ with a single u32 get_timer(u32 base) function
>  - A HAL with two functions
>- u32 get_raw_ticks()

What des this provide?

>- u32 get_raw_tick_rate() which returns the tick rate in kHz (which
>  max's out at just after 4GHz)

Can we please omit the _raw part in these names?

>  - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
>and get_tick_rate() to correctly maintain the ms counter used by
>get_timer() - This function can be weak (so next point)

Ditto.  What would that do?  If it gets milliseconds as the name
suggest, that's already the function needed for get_timer()?

>  - If the hardware supports a native 32-bit ms counter, get_raw_ms()
>can be overridden to simply return the hardware counter. In this case,
>get_raw_ticks() would return 1

I don't think this is possible on may systems, so I doubt if this is
auseful approach.

>  - Calling of get_raw_ticks() regularly in the main loop (how ofter will
>depend on the raw tick rate, but I image it will never be necessary
>to call more often than once every few minutes)

NAK. This concept is fundamentally broken.  I will not accept it.

>  - If the hardware implements a native 32-bit 1ms counter, no call in
>the main loop is required

We should make no such requirements.

>  - An optional HAL function u32 get_raw_us() which can be used for
>performance profiling (must wrap correctly)

Sorry for rewinding the thread.

Can we not start simple, say by a plain free-runnign 64 bit counter,
be it implemented in hardwar eor in software?  On PowerPC, we have
this immediately in form of the time base register (or more precisely
in form of the two 32 bit registers tbu and tbl representing time base
upper and time base lower).

Modelling a similar interface using _any_ kind of timer service should
be trivial.  And from there, we can just use the existing code again.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I often quote myself; it adds spice to my conversation.  - G. B. Shaw
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4dd8b3ed.4000...@comcast.net> you wrote:
>
...
>This statement, as written, is false. While it is true that the 
> power PC (and others) have a 64 bit counter that runs at a many 
> megahertz rate, it is NOT true that all 64 bits must be used to obtain a 
> millisecond timer. A millisecond timer can be produced by using the 33 
> bits of the 64 bit counter whose lsb is <= 1 ms and > 0.5 ms. This value 
> can be extracted by a right shift and masking of the 64 bit counter. Two 
> 32 bit multiplies and adds will produce a correct monotonic 1 ms timer. 
> This is certainly the best way to go on systems that do not have a 
> hardware 64 bit by 32 bit divide. See the thread "ARM timing code 
> refactoring" for an example of how this can be done. This timer will 
> NEVER result in a wrong value, although it does loose  1 ms every 1193 
> hours.

I think we should NOT bother about low level optimization details
wether or not we have a 64 bit divide instruction of if we need to
emulate it in software.  Let's keep such early optimizations out of
this phase and deal with the specific implementation later, once we
agreed on a design.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs." - Robert Firth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Scott McNutt]

Hi Graeme,

Graeme Russ wrote:
> There is no need to use get_timer() and reset_timer() and there are build

I must have missed something WRT reset_timer() -- my apologies
if I'm covering old ground.

When the timestamp is incremented using an interrupt that occurs with
a period greater than 1 ms, we can get early timeouts. reset_timer()
solved the problem. What's the recommended approach for dealing with
this without reset_timer() ?

Regards,
--Scott

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

On 23/05/11 22:09, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> sorry for jumping in late here (was busy with the ELDK 5.0 release).

I thought you were a bit quite on such a 'touchy' subject ;)

> 
> In message  you wrote:
>> OK, so in summary, we can (in theory) have:
>>  - A timer API in /lib/ with a single u32 get_timer(u32 base) function
>>  - A HAL with two functions
>>- u32 get_raw_ticks()
> 
> What des this provide?
> 
>>- u32 get_raw_tick_rate() which returns the tick rate in kHz (which
>>  max's out at just after 4GHz)
> 
> Can we please omit the _raw part in these names?
> 
>>  - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
>>and get_tick_rate() to correctly maintain the ms counter used by
>>get_timer() - This function can be weak (so next point)
> 
> Ditto.  What would that do?  If it gets milliseconds as the name
> suggest, that's already the function needed for get_timer()?

OK, there appears to be a consensus that not all hardware actually supports
a free-running timer with 1ms resolution. To overcome this, the idea is to
create a common library function which maintains the free running counter.
The library function acts as a pre-scaler using a 'raw tick counter' and a
'raw tick rate' supplied by the low level architecture. We define this weak
so that if the architecture can provide a free running 1ms counter, there
is no (code size) penalty

This approach eliminates all the existing per-arch code which (attempts) to
manage the time base behind get time. So we simplify each arch down to it's
bare essentials - Provide a counter which increments at a natural fixed
rate and what the rate is - Let common library code deal with the rest.

>>  - If the hardware supports a native 32-bit ms counter, get_raw_ms()
>>can be overridden to simply return the hardware counter. In this case,
>>get_raw_ticks() would return 1
> 
> I don't think this is possible on may systems, so I doubt if this is
> auseful approach.

x86 does as it implements a 1ms interrupt (I know other systems do as well)

>>  - Calling of get_raw_ticks() regularly in the main loop (how ofter will
>>depend on the raw tick rate, but I image it will never be necessary
>>to call more often than once every few minutes)
> 
> NAK. This concept is fundamentally broken.  I will not accept it.

Some existing timers are fundamentally broken - The glitch at the
0x to 0x rollover or rollover early - The method discussed
in this thread eliminates all such glitches. Provided pre-scaler in /lib/
(triggered by get_timer() usually) is called often enough (71 minutes for a
32-bit 1MHz counter) then there is no need. Even then, it is only important
over the time period you are measuring (i.e. two independent 5s delays 2
hours apart will not be a problem)

Kicking the pre-scaler (like kicking the watchdog) eliminates the problem
entirely.

> 
>>  - If the hardware implements a native 32-bit 1ms counter, no call in
>>the main loop is required
> 
> We should make no such requirements.

No such requirement of what?

>>  - An optional HAL function u32 get_raw_us() which can be used for
>>performance profiling (must wrap correctly)
> 
> Sorry for rewinding the thread.
> 
> Can we not start simple, say by a plain free-runnign 64 bit counter,
> be it implemented in hardwar eor in software?  On PowerPC, we have

That's exactly what we are suggesting - Let the hardware be free to
implement the counter at whatever frequency suits it. 64-bit is not needed
in reality

> this immediately in form of the time base register (or more precisely
> in form of the two 32 bit registers tbu and tbl representing time base
> upper and time base lower).
> 
> Modelling a similar interface using _any_ kind of timer service should
> be trivial.  And from there, we can just use the existing code again.

Yes, have the library function manage the actual '1ms' aspect

Regards,

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Jens Scharsig]

Am 2011-05-23 13:54, schrieb Graeme Russ:
> There is no need to use get_timer() and reset_timer() and there are build
> breakages occuring because of them (specifically cfi_flash). Remove any
> usage outside arch/ to fix build breakages and to prepare for complete
> removal
> 
> Signed-off-by: Graeme Russ 
> ---
> checkpatch complains about long lines and brace usage in the board specific
> flash.c files - They are deprecated and not worth fixing for style
> 
>  board/BuS/EB+MCF-EV123/flash.c |   10 ++

Ack, for EB+MCF-EV123 board

Best regards

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

On 23/05/11 22:19, Scott McNutt wrote:
> Hi Graeme,
> 
> Graeme Russ wrote:
>> There is no need to use get_timer() and reset_timer() and there are build
> 
> I must have missed something WRT reset_timer() -- my apologies
> if I'm covering old ground.
> 
> When the timestamp is incremented using an interrupt that occurs with
> a period greater than 1 ms, we can get early timeouts. reset_timer()
> solved the problem. What's the recommended approach for dealing with
> this without reset_timer() ?
> 

There is an active thread on the timer API right now. Short answer - The
API is broken - Calling reset_timer() is not the right solution because:
 a) It breaks recursive or nested timing loops
 b) For some arches, udelay() has a side-effect as well

All this needs fixing

Regards,

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

[U-Boot] [PATCH v3] powerpc/85xx: Fix compile errors if CONFIG_SYS_DPAA_QBMAN isn't set

[Kumar Gala]

Add ifdef protection for qp_info and liodn associated with Q/BMan.  Also
rearrange setting of _tbl_sz variables to utilize existing ifdef
protection for things like FMAN.

Also add protection around setup_portals() call in corenet_ds board
code.

Signed-off-by: Kumar Gala 
---
v3:
* Fixed typo of #define its QBMAN not QBFMAN caused build failures on p3041
v2:
* Missed one case in corenet_ds.c that also needed #ifdef protection

 arch/powerpc/cpu/mpc85xx/p3041_ids.c|   11 +++
 arch/powerpc/cpu/mpc85xx/p4080_ids.c|   13 -
 arch/powerpc/cpu/mpc85xx/p5020_ids.c|   11 +++
 board/freescale/corenet_ds/corenet_ds.c |2 ++
 4 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/p3041_ids.c 
b/arch/powerpc/cpu/mpc85xx/p3041_ids.c
index 1255898..9836588 100644
--- a/arch/powerpc/cpu/mpc85xx/p3041_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p3041_ids.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_SYS_DPAA_QBMAN
 struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
/* dqrr liodn, frame data liodn, liodn off, sdest */
SET_QP_INFO( 1,  2,  1, 0),
@@ -37,10 +38,13 @@ struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
SET_QP_INFO( 0,  0,  0, 0), /* for now sdest to 0 */
SET_QP_INFO( 0,  0,  0, 0), /* for now sdest to 0 */
 };
+#endif
 
 struct liodn_id_table liodn_tbl[] = {
+#ifdef CONFIG_SYS_DPAA_QBMAN
SET_QMAN_LIODN(31),
SET_BMAN_LIODN(32),
+#endif
 
SET_SDHC_LIODN(1, 64),
 
@@ -65,6 +69,7 @@ struct liodn_id_table liodn_tbl[] = {
SET_GUTS_LIODN(NULL, 201, rio1maintliodnr, 0),
SET_GUTS_LIODN(NULL, 202, rio2maintliodnr, 0),
 };
+int liodn_tbl_sz = ARRAY_SIZE(liodn_tbl);
 
 #ifdef CONFIG_SYS_DPAA_FMAN
 struct liodn_id_table fman1_liodn_tbl[] = {
@@ -75,6 +80,7 @@ struct liodn_id_table fman1_liodn_tbl[] = {
SET_FMAN_RX_1G_LIODN(1, 4, 14),
SET_FMAN_RX_10G_LIODN(1, 0, 15),
 };
+int fman1_liodn_tbl_sz = ARRAY_SIZE(fman1_liodn_tbl);
 #endif
 
 struct liodn_id_table sec_liodn_tbl[] = {
@@ -89,6 +95,7 @@ struct liodn_id_table sec_liodn_tbl[] = {
SET_SEC_DECO_LIODN_ENTRY(0, 97, 98),
SET_SEC_DECO_LIODN_ENTRY(1, 99, 100),
 };
+int sec_liodn_tbl_sz = ARRAY_SIZE(sec_liodn_tbl);
 
 struct liodn_id_table liodn_bases[] = {
[FSL_HW_PORTAL_SEC]  = SET_LIODN_BASE_2(64, 100),
@@ -99,7 +106,3 @@ struct liodn_id_table liodn_bases[] = {
[FSL_HW_PORTAL_PME]   = SET_LIODN_BASE_2(136, 172),
 #endif
 };
-
-int liodn_tbl_sz = ARRAY_SIZE(liodn_tbl);
-int fman1_liodn_tbl_sz = ARRAY_SIZE(fman1_liodn_tbl);
-int sec_liodn_tbl_sz = ARRAY_SIZE(sec_liodn_tbl);
diff --git a/arch/powerpc/cpu/mpc85xx/p4080_ids.c 
b/arch/powerpc/cpu/mpc85xx/p4080_ids.c
index fd155c8..560c02a 100644
--- a/arch/powerpc/cpu/mpc85xx/p4080_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p4080_ids.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_SYS_DPAA_QBMAN
 struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
/* dqrr liodn, frame data liodn, liodn off, sdest */
SET_QP_INFO( 1,  2,  1, 0),
@@ -37,6 +38,7 @@ struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
SET_QP_INFO(17, 18,  9, 0), /* for now sdest to 0 */
SET_QP_INFO(19, 20, 10, 0), /* for now sdest to 0 */
 };
+#endif
 
 struct liodn_id_table liodn_tbl[] = {
SET_USB_LIODN(1, "fsl-usb2-mph", 127),
@@ -55,10 +57,13 @@ struct liodn_id_table liodn_tbl[] = {
SET_GUTS_LIODN(NULL, 199, rio2liodnr, 0),
SET_GUTS_LIODN(NULL, 200, rmuliodnr, 0),
 
+#ifdef CONFIG_SYS_DPAA_QBMAN
SET_QMAN_LIODN(31),
SET_BMAN_LIODN(32),
+#endif
SET_PME_LIODN(128),
 };
+int liodn_tbl_sz = ARRAY_SIZE(liodn_tbl);
 
 #ifdef CONFIG_SYS_DPAA_FMAN
 struct liodn_id_table fman1_liodn_tbl[] = {
@@ -68,6 +73,7 @@ struct liodn_id_table fman1_liodn_tbl[] = {
SET_FMAN_RX_1G_LIODN(1, 3, 14),
SET_FMAN_RX_10G_LIODN(1, 0, 15),
 };
+int fman1_liodn_tbl_sz = ARRAY_SIZE(fman1_liodn_tbl);
 
 #if (CONFIG_SYS_NUM_FMAN == 2)
 struct liodn_id_table fman2_liodn_tbl[] = {
@@ -77,6 +83,7 @@ struct liodn_id_table fman2_liodn_tbl[] = {
SET_FMAN_RX_1G_LIODN(2, 3, 19),
SET_FMAN_RX_10G_LIODN(2, 0, 20),
 };
+int fman2_liodn_tbl_sz = ARRAY_SIZE(fman2_liodn_tbl);
 #endif
 #endif
 
@@ -101,6 +108,7 @@ struct liodn_id_table sec_liodn_tbl[] = {
SET_SEC_DECO_LIODN_ENTRY(3, 132, 164),
SET_SEC_DECO_LIODN_ENTRY(4, 133, 165),
 };
+int sec_liodn_tbl_sz = ARRAY_SIZE(sec_liodn_tbl);
 
 struct liodn_id_table liodn_bases[] = {
[FSL_HW_PORTAL_SEC]  = SET_LIODN_BASE_2(96, 106),
@@ -114,8 +122,3 @@ struct liodn_id_table liodn_bases[] = {
[FSL_HW_PORTAL_PME]   = SET_LIODN_BASE_2(116, 133),
 #endif
 };
-
-int liodn_tbl_sz = ARRAY_SIZE(liodn_tbl);
-int fman1_liodn_tbl_sz = ARRAY_SIZE(fman1_liodn_tbl);
-int fman2_liodn_tbl_sz = ARRAY_SIZE(fman2_liodn_tbl);
-int sec_liodn_tbl_sz = ARRAY_SIZE(sec_liodn_tbl);
diff --git a/arch/powerpc/cpu/mpc

Re: [U-Boot] [PATCH] powerpc/85xx: Add NAND boot support for P3041/P5020DS

[Kumar Gala]

On May 23, 2011, at 2:40 AM, Shaohui Xie wrote:

> 
> diff --git a/boards.cfg b/boards.cfg
> index 9f2b118..21182b9 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -574,12 +574,14 @@ P2020RDB_SPIFLASHpowerpc mpc85xx 
> p1_p2_rdb   freesca
> P3041DS  powerpc mpc85xx corenet_ds  
> freescale
> P3041DS_SDCARD powerpc mpc85xx corenet_ds 
>  freescale  -   
> P3041DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
> P3041DS_SPIFLASH   powerpc mpc85xx corenet_ds  
> freescale  -   
> P3041DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
> +P3041DS_NAND  powerpc mpc85xx corenet_ds  
> freescale  -   P3041DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8

Keep sorted by alpha, so move up before _SDCARD

> P4080DS  powerpc mpc85xx corenet_ds  
> freescale
> P4080DS_SDCARD powerpc mpc85xx corenet_ds 
>  freescale  -   
> P4080DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
> P4080DS_SPIFLASH   powerpc mpc85xx corenet_ds  
> freescale  -   
> P4080DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
> P5020DS  powerpc mpc85xx corenet_ds  
> freescale
> P5020DS_SDCARD powerpc mpc85xx corenet_ds 
>  freescale  -   
> P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
> P5020DS_SPIFLASH   powerpc mpc85xx corenet_ds  
> freescale  -   
> P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
> +P5020DS_NAND  powerpc mpc85xx corenet_ds  
> freescale  -   P5020DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8

ditto

> mpq101   powerpc mpc85xx mpq101  
> mercury-   mpq101
> stxgp3   powerpc mpc85xx stxgp3  stx
> stxssa   powerpc mpc85xx stxssa  stx  
>   -   stxssa
> diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h

thanks

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Scott McNutt]

Dear Graeme,

Graeme Russ wrote:
> On 23/05/11 22:19, Scott McNutt wrote:
>> Hi Graeme,
>>
>> Graeme Russ wrote:
>>> There is no need to use get_timer() and reset_timer() and there are build
>> I must have missed something WRT reset_timer() -- my apologies
>> if I'm covering old ground.
>>
>> When the timestamp is incremented using an interrupt that occurs with
>> a period greater than 1 ms, we can get early timeouts. reset_timer()
>> solved the problem. What's the recommended approach for dealing with
>> this without reset_timer() ?
>>
> 
> There is an active thread on the timer API right now. Short answer - The
> API is broken - Calling reset_timer() is not the right solution because:
>  a) It breaks recursive or nested timing loops
>  b) For some arches, udelay() has a side-effect as well
> 
> All this needs fixing

Understood. However, removing reset_timer() from cfi_flash.c, will
result in early timeouts for certain boards/archs. Your patch removes
commit 22d6c8faac4e9fa43232b0cf4da427ec14d72ad3 (Thu Apr 1 2010).
I'd rather not break something that has been working for over a year
before I know how to make it work again. Fair enough?

Regards,
--Scott

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear Graeme Russ,

In message <4dda5334.4060...@gmail.com> you wrote:
>
> >>  - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
> >>and get_tick_rate() to correctly maintain the ms counter used by
> >>get_timer() - This function can be weak (so next point)
> > 
> > Ditto.  What would that do?  If it gets milliseconds as the name
> > suggest, that's already the function needed for get_timer()?
> 
> OK, there appears to be a consensus that not all hardware actually supports
> a free-running timer with 1ms resolution. To overcome this, the idea is to

Indeed.  I guess most of them do not.

> create a common library function which maintains the free running counter.
> The library function acts as a pre-scaler using a 'raw tick counter' and a
> 'raw tick rate' supplied by the low level architecture. We define this weak

What are "raw" ticks?  And what are "cooked" ticks, then?

> so that if the architecture can provide a free running 1ms counter, there
> is no (code size) penalty

Why do we need a free running 1ms counter at all?  Any free running
counter of at least millisecoind resolution should be good enough.

> This approach eliminates all the existing per-arch code which (attempts) to
> manage the time base behind get time. So we simplify each arch down to it's
> bare essentials - Provide a counter which increments at a natural fixed
> rate and what the rate is - Let common library code deal with the rest.

Did you have a look at the PowerPC implementation?  I'd like to see
this used as reference.

> >>  - Calling of get_raw_ticks() regularly in the main loop (how ofter will
> >>depend on the raw tick rate, but I image it will never be necessary
> >>to call more often than once every few minutes)
> > 
> > NAK. This concept is fundamentally broken.  I will not accept it.
> 
> Some existing timers are fundamentally broken - The glitch at the
> 0x to 0x rollover or rollover early - The method discussed
> in this thread eliminates all such glitches. Provided pre-scaler in /lib/
> (triggered by get_timer() usually) is called often enough (71 minutes for a
> 32-bit 1MHz counter) then there is no need. Even then, it is only important

We already have this nightmare of code for triggering the watchdog on
systems that use it.

Assuming there are places in the main loop that get executed often
enough is a broken concept, and I will not accept any such code.

> over the time period you are measuring (i.e. two independent 5s delays 2
> hours apart will not be a problem)

What is the practical purpose of get_timer()?  What is the longest
interval we have to cover?  And what is the problem with a rollover?

> >>  - If the hardware implements a native 32-bit 1ms counter, no call in
> >>the main loop is required
> > 
> > We should make no such requirements.
> 
> No such requirement of what?

Of making any calls in the main loop.

> > Can we not start simple, say by a plain free-runnign 64 bit counter,
> > be it implemented in hardwar eor in software?  On PowerPC, we have
> 
> That's exactly what we are suggesting - Let the hardware be free to
> implement the counter at whatever frequency suits it. 64-bit is not needed
> in reality

It may not be needed on some systems, but may be needed on others
where 32 bit is too short.  Let's use the common base that is know to
work on all systems, even if it's not strictly needed on all of them.

> > this immediately in form of the time base register (or more precisely
> > in form of the two 32 bit registers tbu and tbl representing time base
> > upper and time base lower).
> > 
> > Modelling a similar interface using _any_ kind of timer service should
> > be trivial.  And from there, we can just use the existing code again.
> 
> Yes, have the library function manage the actual '1ms' aspect

This is what PPC is doing. And I understand that Reinhard did the same
in software for AT91.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Alles Gescheite ist schon gedacht worden, man muß nur versuchen,
es noch einmal zu denken.  -- Goethe, Maximen und Reflexionen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Wolfgang Denk]

Dear Jens Scharsig,

In message <4dda53b7.7020...@bus-elektronik.de> you wrote:
> Am 2011-05-23 13:54, schrieb Graeme Russ:
> > There is no need to use get_timer() and reset_timer() and there are build
> > breakages occuring because of them (specifically cfi_flash). Remove any
> > usage outside arch/ to fix build breakages and to prepare for complete
> > removal
> > 
> > Signed-off-by: Graeme Russ 
> > ---
> > checkpatch complains about long lines and brace usage in the board specific
> > flash.c files - They are deprecated and not worth fixing for style
> > 
> >  board/BuS/EB+MCF-EV123/flash.c |   10 ++
> 
> Ack, for EB+MCF-EV123 board

Can you please send a formal Acked-by: message?


Note that this is NOT nitpicking:  Patchwork will automatically add
such correct Acked-by: lines to the patch, so we don't have to track
thse manually - this saves a LOT of time to the maintainers.


Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Why waste negative entropy on comments, when you could use the  same
entropy to create bugs instead?"- Steve Elias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Jens Scharsig]

Am 2011-05-23 13:54, schrieb Graeme Russ:
> There is no need to use get_timer() and reset_timer() and there are build
> breakages occuring because of them (specifically cfi_flash). Remove any
> usage outside arch/ to fix build breakages and to prepare for complete
> removal
> 
> Signed-off-by: Graeme Russ 

for EB+MCF-EV123 board

Acked-by: Jens Scharsig 


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

[U-Boot] Formal acks and patchwork (was: [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/)

[Albert ARIBAUD]

Le 23/05/2011 15:22, Wolfgang Denk a écrit :

> Can you please send a formal Acked-by: message?
>
> Note that this is NOT nitpicking:  Patchwork will automatically add
> such correct Acked-by: lines to the patch, so we don't have to track
> thse manually - this saves a LOT of time to the maintainers.

One question: where is the information presented in patchwork, apart 
from coloring the ack line when displaying the patch discussion thread? 
I cannot find e.g. a summary list of all acks to a given patch.

> Thanks.
>
> Wolfgang Denk

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

Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement

[Detlev Zundel]

Hi Simon,

[...]

>>> I believe I have covered this ground very thoroughly and would like
>>> advice please on what to do next. The options I can see are:
>>
>> As Graeme points out, you got enough positive feedback that I encourage
>> you to continue and address the comments.
>
> OK, it would be nice to have a note from Wolfgang since without his OK
> it won't make it in, right?

Ultimately we are a democratic community, so when you get enough support
the changes will go in.  Usually we find a consensus acceptable to all
parties before resorting to such formal measures however.

Cheers
  Detlev

-- 
Q: Why did the chicken cross the Moebius strip?
A: To get to the other ... er, um ...
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5 3/4] MX5: Introduce a function for setting the chip select size

[Fabio Estevam]

Signed-off-by: Fabio Estevam 
---
Changes since v4:
- No changes
Changes since v3:
- Print the chip size in the case of error

 arch/arm/cpu/armv7/mx5/soc.c  |   30 +
 arch/arm/include/asm/arch-mx5/imx-regs.h  |5 
 arch/arm/include/asm/arch-mx5/sys_proto.h |2 +-
 3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/soc.c b/arch/arm/cpu/armv7/mx5/soc.c
index 40b8b56..e599df8 100644
--- a/arch/arm/cpu/armv7/mx5/soc.c
+++ b/arch/arm/cpu/armv7/mx5/soc.c
@@ -163,6 +163,36 @@ int cpu_mmc_init(bd_t *bis)
 #endif
 }
 
+void set_chipselect_size(int const cs_size)
+{
+   unsigned int reg;
+   struct iomuxc *iomuxc_regs = (struct weim *)IOMUXC_BASE_ADDR;
+   reg = readl(&iomuxc_regs->gpr1);
+
+   switch (cs_size) {
+   case CS0_128:
+   reg &= ~0x7;/* CS0=128MB, CS1=0, CS2=0, CS3=0 */
+   reg |= 0x5;
+   break;
+   case CS0_64M_CS1_64M:
+   reg &= ~0x3F;   /* CS0=64MB, CS1=64MB, CS2=0, CS3=0 */
+   reg |= 0x1B;
+   break;
+   case CS0_64M_CS1_32M_CS2_32M:
+   reg &= ~0x1FF;  /* CS0=64MB, CS1=32MB, CS2=32MB, CS3=0 */
+   reg |= 0x4B;
+   break;
+   case CS0_32M_CS1_32M_CS2_32M_CS3_32M:
+   reg &= ~0xFFF;  /* CS0=32MB, CS1=32MB, CS2=32MB, CS3=32MB */
+   reg |= 0x249;
+   break;
+   default:
+   printf("Unknown chip select size: %d\n", cs_size);
+   break;
+   }
+
+   writel(reg, &iomuxc_regs->gpr1);
+}
 
 void reset_cpu(ulong addr)
 {
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 9d2046a..5163614 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -214,6 +214,11 @@
 #define WDOG_EN(x) ((x) << 8)
 #define WDOG_LIMIT(x)  (((x) & 0x3) << 9)
 
+#define CS0_1280
+#define CS0_64M_CS1_64M1
+#define CS0_64M_CS1_32M_CS2_32M2
+#define CS0_32M_CS1_32M_CS2_32M_CS3_32M3
+
 /*
  * Number of GPIO pins per port
  */
diff --git a/arch/arm/include/asm/arch-mx5/sys_proto.h 
b/arch/arm/include/asm/arch-mx5/sys_proto.h
index f687503..ce63675 100644
--- a/arch/arm/include/asm/arch-mx5/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx5/sys_proto.h
@@ -27,5 +27,5 @@
 u32 get_cpu_rev(void);
 #define is_soc_rev(rev)((get_cpu_rev() & 0xFF) - rev)
 void sdelay(unsigned long);
-
+void set_chipselect_size(int const);
 #endif
-- 
1.6.0.4


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

[U-Boot] [PATCH v5 1/4] MX5: Make the weim structure complete

[Fabio Estevam]

Signed-off-by: Fabio Estevam 
---
Changes since v4:
- Change the definition of WEIM single-bit field
Changes since v3:
- No changes
Changes since v2:
- Add CS1_BASE_ADDR for MX51
- Add WEIM Registers
 arch/arm/include/asm/arch-mx5/imx-regs.h |  131 --
 1 files changed, 125 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index a1849f8..e136607 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -32,6 +32,7 @@
 #define CSD0_BASE_ADDR  0x9000
 #define CSD1_BASE_ADDR  0xA000
 #define NFC_BASE_ADDR_AXI   0xCFFF
+#define CS1_BASE_ADDR   0xB800
 #elif defined(CONFIG_MX53)
 #define IPU_CTRL_BASE_ADDR  0x1800
 #define SPBA0_BASE_ADDR 0x5000
@@ -41,6 +42,7 @@
 #define CSD1_BASE_ADDR  0xB000
 #define NFC_BASE_ADDR_AXI   0xF7FF
 #define IRAM_BASE_ADDR  0xF800
+#define CS1_BASE_ADDR   0xF400
 #else
 #error "CPU_TYPE not defined"
 #endif
@@ -129,6 +131,90 @@
 #define SAHARA_BASE_ADDR   (AIPS2_BASE_ADDR + 0x000F8000)
 
 /*
+ * WEIM CSnGCR1
+ */
+#define CSEN   1
+#define SWR(1 << 1)
+#define SRD(1 << 2)
+#define MUM(1 << 3)
+#define WFL(1 << 4)
+#define RFL(1 << 5)
+#define CRE(1 << 6)
+#define CREP   (1 << 7)
+#define BL(x)  (((x) & 0x7) << 8)
+#define WC (1 << 11)
+#define BCD(x) (((x) & 0x3) << 12)
+#define BCS(x) (((x) & 0x3) << 14)
+#define DSZ(x) (((x) & 0x7) << 16)
+#define SP (1 << 19)
+#define CSREC(x)   (((x) & 0x7) << 20)
+#define AUS(1 << 23)
+#define GBC(x) (((x) & 0x7) << 24)
+#define WP (1 << 27)
+#define PSZ(x) (((x) & 0x0f << 28)
+
+/*
+ * WEIM CSnGCR2
+ */
+#define ADH(x) (((x) & 0x3))
+#define DAPS(x)(((x) & 0x0f << 4)
+#define DAE(1 << 8)
+#define DAP(1 << 9)
+#define MUX16_BYP  (1 << 12)
+
+/*
+ * WEIM CSnRCR1
+ */
+#define RCSN(x)(((x) & 0x7))
+#define RCSA(x)(((x) & 0x7) << 4)
+#define OEN(x) (((x) & 0x7) << 8)
+#define OEA(x) (((x) & 0x7) << 12)
+#define RADVN(x)   (((x) & 0x7) << 16)
+#define RAL(1 << 19)
+#define RADVA(x)   (((x) & 0x7) << 20)
+#define RWSC(x)(((x) & 0x3f) << 24)
+
+/*
+ * WEIM CSnRCR2
+ */
+#define RBEN(x)(((x) & 0x7))
+#define RBE(1 << 3)
+#define RBEA(x)(((x) & 0x7) << 4)
+#define RL(x)  (((x) & 0x3) << 8)
+#define PAT(x) (((x) & 0x7) << 12)
+#define APR(1 << 15)
+
+/*
+ * WEIM CSnWCR1
+ */
+#define WCSN(x)(((x) & 0x7))
+#define WCSA(x)(((x) & 0x7) << 3)
+#define WEN(x) (((x) & 0x7) << 6)
+#define WEA(x) (((x) & 0x7) << 9)
+#define WBEN(x)(((x) & 0x7) << 12)
+#define WBEA(x)(((x) & 0x7) << 15)
+#define WADVN(x)   (((x) & 0x7) << 18)
+#define WADVA(x)   (((x) & 0x7) << 21)
+#define WWSC(x)(((x) & 0x3f) << 24)
+#define WBED1  (1 << 30)
+#define WAL(1 << 31)
+
+/*
+ * WEIM CSnWCR2
+ */
+#define WBED   1
+
+/*
+ * WEIM WCR
+ */
+#define BCM1
+#define GBCD(x)(((x) & 0x3) << 1)
+#define INTEN  (1 << 4)
+#define INTPOL (1 << 5)
+#define WDOG_EN(1 << 8)
+#define WDOG_LIMIT(x)  (((x) & 0x3) << 9)
+
+/*
  * Number of GPIO pins per port
  */
 #define GPIO_NUM_PIN32
@@ -231,12 +317,45 @@ struct clkctl {
 
 /* WEIM registers */
 struct weim {
-   u32 csgcr1;
-   u32 csgcr2;
-   u32 csrcr1;
-   u32 csrcr2;
-   u32 cswcr1;
-   u32 cswcr2;
+   u32 cs0gcr1;
+   u32 cs0gcr2;
+   u32 cs0rcr1;
+   u32 cs0rcr2;
+   u32 cs0wcr1;
+   u32 cs0wcr2;
+   u32 cs1gcr1;
+   u32 cs1gcr2;
+   u32 cs1rcr1;
+   u32 cs1rcr2;
+   u32 cs1wcr1;
+   u32 cs1wcr2;
+   u32 cs2gcr1;
+   u32 cs2gcr2;
+   u32 cs2rcr1;
+   u32 cs2rcr2;
+   u32 cs2wcr1;
+   u32 cs2wcr2;
+   u32 cs3gcr1;
+   u32 cs3gcr2;
+   u32 cs3rcr1;
+   u32 cs3rcr2;
+   u32 cs3wcr1;
+   u32 cs3wcr2;
+   u32 cs4gcr1;
+   u32 cs4gcr2;
+   u32 cs4rcr1;
+   u32 cs4rcr2;
+   u32 cs4wcr1;
+   u32 cs4wcr2;
+   u32 cs5gcr1;
+   u32 cs5gcr2;
+   u32 cs5rcr1;
+   u32 cs5rcr2;
+   u32 cs5wcr1;
+   u32 cs5wcr2;
+   u32 wcr;
+   u32 wiar;
+   u32 ear;
 };
 
 /* GPIO Registers */
-- 
1.6.0.4


___
U-Boot mailing 

[U-Boot] [PATCH v5 2/4] MX5: Add iomux structure

[Fabio Estevam]

Signed-off-by: Fabio Estevam 
---
Changes since v4:
- No changes
Changes since v3:
- No changes
Changes since v2:
- Distinguish iomuxc struct between MX51 and MX53

 arch/arm/include/asm/arch-mx5/imx-regs.h |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h 
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index b65b11f..3c61c7f 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -358,6 +358,29 @@ struct weim {
u32 ear;
 };
 
+#if defined(CONFIG_MX51)
+struct iomuxc {
+   u32 gpr0;
+   u32 gpr1;
+   u32 omux0;
+   u32 omux1;
+   u32 omux2;
+   u32 omux3;
+   u32 omux4;
+};
+#elif defined(CONFIG_MX53)
+struct iomuxc {
+   u32 gpr0;
+   u32 gpr1;
+   u32 gpr2;
+   u32 omux0;
+   u32 omux1;
+   u32 omux2;
+   u32 omux3;
+   u32 omux4;
+};
+#endif
+
 /* GPIO Registers */
 struct gpio_regs {
u32 gpio_dr;
-- 
1.6.0.4


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

[U-Boot] [PATCH v5 4/4] MX53: Add initial support for MX53ARD

[Fabio Estevam]

Signed-off-by: Fabio Estevam 
---
Changes since v4:
- Changed the weim cs1 settings for the single-bit fields
- Removed unused 'reg' variable inside weim_smc911x_iomux()
- Made void weim_cs1_settings() and weim_smc911x_iomux() static
Changes since v3:
- No changes
Changes since v2:
- Use macros for setting up weim register
- Use set_chipselect_size function
- Rename the file to imximage_dd3.cfg to make explicit the DDR type.
 MAINTAINERS  |1 +
 board/freescale/mx53ard/Makefile |   48 +
 board/freescale/mx53ard/imximage_dd3.cfg |   96 ++
 board/freescale/mx53ard/mx53ard.c|  306 ++
 boards.cfg   |1 +
 include/configs/mx53ard.h|  198 +++
 6 files changed, 650 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/mx53ard/Makefile
 create mode 100644 board/freescale/mx53ard/imximage_dd3.cfg
 create mode 100644 board/freescale/mx53ard/mx53ard.c
 create mode 100644 include/configs/mx53ard.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 07237e3..b63f53f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -639,6 +639,7 @@ Kristoffer Ericson 
 Fabio Estevam 
 
mx31pdk i.MX31
+   mx53ard i.MX53
mx53smd i.MX53
 
 Peter Figuli 
diff --git a/board/freescale/mx53ard/Makefile b/board/freescale/mx53ard/Makefile
new file mode 100644
index 000..c48ece8
--- /dev/null
+++ b/board/freescale/mx53ard/Makefile
@@ -0,0 +1,48 @@
+#
+# Copyright (C) 2007, Guennadi Liakhovetski 
+#
+# (C) Copyright 2011 Freescale Semiconductor, Inc.
+#
+# 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 (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := mx53ard.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/mx53ard/imximage_dd3.cfg 
b/board/freescale/mx53ard/imximage_dd3.cfg
new file mode 100644
index 000..0f298ab
--- /dev/null
+++ b/board/freescale/mx53ard/imximage_dd3.cfg
@@ -0,0 +1,96 @@
+#
+# (C) Copyright 2009
+# Stefano Babic DENX Software Engineering sba...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# 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 (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not write to the Free Software
+# Foundation Inc. 51 Franklin Street Fifth Floor Boston,
+# MA 02110-1301 USA
+#
+# Refer docs/README.imxmage for more details about how-to configure
+# and create imximage boot image
+#
+# The syntax is taken as close as possible with the kwbimage
+
+# image version
+
+IMAGE_VERSION 2
+
+# Boot Device : one of
+# spi, sd (the board has no nand neither onenand)
+
+BOOT_FROM  sd
+
+# Device Configuration Data (DCD)
+#
+# Each entry must have the format:
+# Addr-type   AddressValue
+#
+# where:
+#  Addr-type register length (1,2 or 4 bytes)
+#  Address   absolute address of the register
+#  value value to be stored in the register
+DATA 4 0x53fa8554 0x0030
+DATA 4 0x53fa8558 0x00300040
+DATA 4 0x53fa8560 0x0030
+DATA 4 0x53fa8564 0x00300040
+DATA 4 0x53fa8568 0x00300040
+DATA 4 0x53fa8570 0x0030
+DATA 4 0x53fa8574 0x0030
+DATA 4 0x53fa8578 0x0030
+DATA 4 0x53fa857c 0x00300040
+DATA 4 0x53fa8580 0x0030

Re: [U-Boot] [RFC] Review of U-Boot timer API

[J. William Campbell]

On 5/22/2011 11:29 PM, Albert ARIBAUD wrote:

Hi all,

Sorry, could not follow the discussion although I find it very
interesting, so I will handle the task of coming in late and asking the
silly questions.
I am glad you are looking at our discussion. I am sure we are going to 
need all the help/oversight/questions that we can get, as this is a 
change that will affect all architectures.

Le 23/05/2011 07:25, Graeme Russ a écrit :


On Mon, May 23, 2011 at 3:02 PM, J. William Campbell
   wrote:

On 5/22/2011 6:42 PM, Graeme Russ wrote:

OK, so in summary, we can (in theory) have:
   - A timer API in /lib/ with a single u32 get_timer(u32 base) function
   - A HAL with two functions
 - u32 get_raw_ticks()
 - u32 get_raw_tick_rate() which returns the tick rate in kHz (which
   max's out at just after 4GHz)
   - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
 and get_tick_rate() to correctly maintain the ms counter used by
 get_timer() - This function can be weak (so next point)
   - If the hardware supports a native 32-bit ms counter, get_raw_ms()
 can be overridden to simply return the hardware counter. In this case,
 get_raw_ticks() would return 1

Are you sure you did not mean 'get_raw_ticks_rate' here? Besides, I'd
like the name to specify the units used: 'get_raw_ticks_rate_in_khz' (or
conversively 'get_raw_ticks_per_ms', depending on which is simpler to
implement and use).
I think you are correct, it was the rate function desired here. I think 
the best way to go is use a "get_raw_tick_rate_in_mhz" function, because 
it is probably the easiest one to implement, and in many cases something 
like it already exists.

   - Calling of get_raw_ticks() regularly in the main loop (how ofter will
 depend on the raw tick rate, but I image it will never be necessary
 to call more often than once every few minutes)

That's to keep track of get_raw_ticks() rollovers, right? And then the
get_timer function (which, again, I would prefer to have '... in ms'
expressed in its name) would call get_raw_ticks() in confidence that at
most one rollover may have occurred since the last time the helper
function was called, so a simple difference of the current vs last tick
value will always be correct.
Exactly so. Note that this same function probably needs to be called in 
udelay for the same reason. More precisely, the get_timer function will 
call get_raw_ms, which will call get_raw_ticks. I think it may be better 
to move get_timer "down" a level in the hierarchy,
so we don't need a get_raw_ms. get_timer would then be part of the HAL. 
One would use a get_timer(0) in order to do what get_raw_ms alone would 
have done. If the user had a good reason, he would then override 
get_timer with his own version. What do you think Graeme? It reduces the 
nesting depth by one level. As for the name change to get_timer_in_ms, I 
would support it. Naturally, such a change would be up to Mr. Denk. 
Since by definition that is what the function does, it seems to be a 
good change from my point of view.

   - If the hardware implements a native 32-bit 1ms counter, no call in
 the main loop is required
   - An optional HAL function u32 get_raw_us() which can be used for
 performance profiling (must wrap correctly)

Hi All,
   Graeme, I think you have stated exactly what is the "best" approach to
this problem.  I will provide a version of "get_raw_ms" that is  initialized
using get_raw_tick_rate that will work for all "reasonable" values of
raw_tick_rate. This will be the "generic" solution. Both the initialization
function and the get_raw_ms function can be overridden if there is reason to
do so, like "exact" clock rates. I will do the same with get_raw_us. This
will be posted sometime on Monday for people to review, and to make sure I
didn't get too far off base. Thank you to both Graeme and Reinhard for
looking at/working on this.. Hopefully, this solution will put this timing
issue to rest for all future ports as well as the presently existing ones.

In Greame's description, I did not see a get_raw_ms, only a get_raw_us.
Was this last one a typo or is that a third HAL function?
get_raw_ms was referenced as a library function a few lines above.  
Right now, I think the functionality we require from the HAL is


  1. get_raw_tick_rate_in_mhz
  2. get_raw_ms
  3. get_raw_ticks
  4. (optional)get_raw_us

There is also  APIs for these functions called get_timer.

I think we need to add a call to another function called 
"initialize_timer_system" or similar that will initialize the data 
structures in gd by calling get_raw_tick_rate_in_mhz. Additionally, I 
think we need to provide a udelay function, simply because it can 
interact with calling get_raw_ms often enough. We are somewhat caught 
between two fires here, in that on the one hand we want to provide a 
very "generic" approach to the timing system that will work on "any" CPU 
while on the other hand we want to all

Re: [U-Boot] [RFC] Review of U-Boot timer API

[J. William Campbell]

On 5/23/2011 6:19 AM, Wolfgang Denk wrote:

Dear Graeme Russ,

In message<4dda5334.4060...@gmail.com>  you wrote:

  - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
and get_tick_rate() to correctly maintain the ms counter used by
get_timer() - This function can be weak (so next point)

Ditto.  What would that do?  If it gets milliseconds as the name
suggest, that's already the function needed for get_timer()?

OK, there appears to be a consensus that not all hardware actually supports
a free-running timer with 1ms resolution. To overcome this, the idea is to

Indeed.  I guess most of them do not.


create a common library function which maintains the free running counter.
The library function acts as a pre-scaler using a 'raw tick counter' and a
'raw tick rate' supplied by the low level architecture. We define this weak

What are "raw" ticks?  And what are "cooked" ticks, then?

Hi all,
 FWIW,  "cooked" ticks would be 1 ms ticks, although we never 
really use them as such.

so that if the architecture can provide a free running 1ms counter, there
is no (code size) penalty

Why do we need a free running 1ms counter at all?  Any free running
counter of at least millisecoind resolution should be good enough.
Correct. Any free running counter whose resolution is better than one 
millisecond and which is "long enough" that it will not overflow between 
calls to get_timer is sufficient.

This approach eliminates all the existing per-arch code which (attempts) to
manage the time base behind get time. So we simplify each arch down to it's
bare essentials - Provide a counter which increments at a natural fixed
rate and what the rate is - Let common library code deal with the rest.

Did you have a look at the PowerPC implementation?  I'd like to see
this used as reference.
I have looked at it as a reference. However, there is one disadvantage 
in using the PPC code as a reference. It has a 64 bit timestamp. Many 
systems do not have a 64 bit timestamp, but rather a 32 bit timestamp.  
It is possible to extend the 32 bit timestamp to a 64 bit timestamp if 
get_timer is called often enough that there will only be a single 
rollover of the bottom 32 bits  between uses. However, if that condition 
is met, there is no need to extend the timer to 64 bits. Instead, just 
convert the elapsed time since the last call (which you know) to ms and 
be done with it.  As Wolfgang said above, any counter that has better 
than 1 ms resolution  is adequate to the task. The additional 
requirement that we have stated is that the counter be long enough that 
it does not overflow between calls to get_timer. If the counter is 64 
bits long, it pretty much for sure meets this requirement  (although 
bits below 0.5 ms resolution really don't help any). If the timer is 32 
bits long, it will meet any requirements using get_timer to time out 
hardware intervals. My original implementation used a 32 bit divide and 
does exactly that. This is the shortest and simplest approach, and we 
can get that working in all cases quite easily I think. We can avoid the 
"no divide" optimization until everybody is satisfied with what we have.

  - Calling of get_raw_ticks() regularly in the main loop (how ofter will
depend on the raw tick rate, but I image it will never be necessary
to call more often than once every few minutes)

NAK. This concept is fundamentally broken.  I will not accept it.

Some existing timers are fundamentally broken - The glitch at the
0x to 0x rollover or rollover early - The method discussed
in this thread eliminates all such glitches. Provided pre-scaler in /lib/
(triggered by get_timer() usually) is called often enough (71 minutes for a
32-bit 1MHz counter) then there is no need. Even then, it is only important

We already have this nightmare of code for triggering the watchdog on
systems that use it.

Assuming there are places in the main loop that get executed often
enough is a broken concept, and I will not accept any such code.
That is fine with me. The reason this was being done was to attempt to 
emulate, as much as possible, the power PC, where the 64 bit timestamp 
counter allows calls to get_timer separated by many minutes and several 
console commands to work properly. These get timer commands will NOT 
work properly on systems that have a 32 bit counter that overflows every 
200 seconds or so. The call in the idle loop was an attempt to make the 
32 bit systems work more like the 64 bit systems. One may then either


  1.   Define calls to get_timer to measure an elapsed interval
 separated by any returns to the command processor as broken.
  2. Require the use of interrupts to extend the 32 bit timestamp.
 (This may not be possible on all systems as the timer used for
 performance monitoring does not interrupt, etc.)
  3. Allow the call in the idle loop under the assumption that we are
 talking about timing in the minutes range, not a few

[U-Boot] [PATCH v2] ARMV7: Vexpress: Add missing MMC header

[Dirk Behme]

From: Dirk Behme 

Add a header file with the missing function prototype to fix

ca9x4_ct_vxp.c: In function 'cpu_mmc_init':
ca9x4_ct_vxp.c:93: warning: implicit declaration of function 
'arm_pl180_mmci_init'

introduced by commit "ARMV7: Vexpress: Add MMC support"
(f0c64526b7e51ba997a0f1baf9e74e6d497b957e)

Signed-off-by: Dirk Behme 
CC: Andy Fleming 
CC: Matt Waddel 

---

Changes in v2: Switch angle braces to quotes.

Note: Maybe it would be better to move

int arm_pl180_mmci_init(void);

from drivers/mmc/arm_pl180_mmci.h to a header in the
include directory?

 board/armltd/vexpress/ca9x4_ct_vxp.c |1 +
 1 file changed, 1 insertion(+)

Index: u-boot.git/board/armltd/vexpress/ca9x4_ct_vxp.c
===
--- u-boot.git.orig/board/armltd/vexpress/ca9x4_ct_vxp.c
+++ u-boot.git/board/armltd/vexpress/ca9x4_ct_vxp.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include "../drivers/mmc/arm_pl180_mmci.h"
 
 static ulong timestamp;
 static ulong lastdec;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] v2011.06-rc1 released

[Dirk Behme]

On 23.05.2011 08:50, Albert ARIBAUD wrote:
> Hi all,
>
> Le 21/05/2011 09:07, Dirk Behme a écrit :
>
>> I'd like
>>
>> 1. to get
>>
>> http://patchwork.ozlabs.org/patch/95661/
>>
>> applied to fix
>>
>> ca9x4_ct_vxp.c: In function 'cpu_mmc_init':
>> ca9x4_ct_vxp.c:93: warning: implicit declaration of function
>> 'arm_pl180_mmci_init'
>>
>> building 'a9x4_ct_vxp'
>
> Sorry for nitpicking, but this patch uses angle braces for including a
> header file which is not 'system' (it's even a relative path). Could
> it use quotes instead, please?

Done:

http://lists.denx.de/pipermail/u-boot/2011-May/093194.html

Thanks

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Albert ARIBAUD]

Le 23/05/2011 19:30, J. William Campbell a écrit :

>> Did you have a look at the PowerPC implementation? I'd like to see
>> this used as reference.

> I have looked at it as a reference. However, there is one disadvantage
> in using the PPC code as a reference. It has a 64 bit timestamp. Many
> systems do not have a 64 bit timestamp, but rather a 32 bit timestamp.
> It is possible to extend the 32 bit timestamp to a 64 bit timestamp if
> get_timer is called often enough that there will only be a single
> rollover of the bottom 32 bits between uses. However, if that condition
> is met, there is no need to extend the timer to 64 bits.

Well, there is one: making sure that drivers do not need to know if 
timestamps are 32 or 64 bits, or even what resolution they are.

Granted, you could define a timestamp_t type to be either u32 or u64 
depending on the actual timestamp width, so that the driver would not 
need to know the details; but extending u32 to u64, or subtracting two 
u64 values, are not so much of an effort, and that would mean a single API.

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[J. William Campbell]

On 5/23/2011 6:19 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,

> This is what PPC is doing. And I understand that Reinhard did the same
> in software for AT91.
Hi All,
  My apologies for being a little (perhaps more than a little) 
dense. As they say, "after further review", I think the key aspect of 
the PPC timer system is that it uses the decrementer register to 
generate an interrupt at a 1 KHz rate. What I have been attempting here 
is to produce a timer system that does not use interrupts at all. This 
is a fundamental design question. Naturally, systems that can generate 
an interrupt at a 1 KHz rate (or at any (reasonable) higher rate for 
that matter) using the decrementer register can produce a 1 ms 
resolution software counter that updates "by magic". If my understanding 
of this PPC  code is incorrect, somebody please stop me before I make a 
further fool of myself!  Is it then a design requirement that the timer 
system use interrupts? Is that what is meant by using the PPC system as 
a model? If so, is it possible/reasonable on all the u-boots that are 
out there to generate and process timer interrupts at some (hopefully 
but not necessarily) programmable rate?

Best Regards,
Bill Campbell
> Best regards,
>
> Wolfgang Denk
>

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

[U-Boot] [PATCH 2/3] common/cmd_nand.c: add ifdef protection for do_bootm

[Matthew McClintock]

Right now we do not check if do_bootm is actually built into this
u-boot. Instead check define and only call do_bootm if it's actually
available.

Signed-off-by: Matthew McClintock 
---
 common/cmd_nand.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 7bd37de..44161da 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -806,9 +806,11 @@ static int nand_load_image(cmd_tbl_t *cmdtp, nand_info_t 
*nand,
local_args[0] = cmd;
local_args[1] = NULL;
 
+#ifdef CONFIG_CMD_BOOTM
printf("Automatic boot of image at addr 0x%08lx ...\n", addr);
 
do_bootm(cmdtp, 0, 1, local_args);
+#endif
return 1;
}
return 0;
-- 
1.7.3.4


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

[U-Boot] [PATCH 1/2] command/cmd_cache.c: Add optional flush arguments

[Matthew McClintock]

It might be desirable to have the ability to flush icache/dcache
within u-boot, this patch gives each arch the ability to provide
a flush_dcache/flush_icache function to let u-boot flush caches
from the prompt

Signed-off-by: Matthew McClintock 
---
There are some checkpatch.pl warnings for formatting issues. In this case
I choose to keep the same formatting as was used in the file already:

#44: FILE: common/cmd_cache.c:48:
+   case 2: flush_icache();

ERROR: trailing statements should be on next line
#70: FILE: common/cmd_cache.c:78:
+   case 2: flush_dcache();

ERROR: return is not a function, parentheses are not required
#84: FILE: common/cmd_cache.c:96:
+   return (2);

total: 3 errors, 0 warnings, 83 lines checked

 common/cmd_cache.c |   38 +-
 1 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/common/cmd_cache.c b/common/cmd_cache.c
index 5cdd834..78d53df 100644
--- a/common/cmd_cache.c
+++ b/common/cmd_cache.c
@@ -27,17 +27,26 @@
 #include 
 #include 
 
-static int on_off (const char *);
+static int parse_argv(const char *);
+
+void __flush_icache(void)
+{
+   /* please define arch specific flush_icache */
+   printf("No arch specific flush_icache available!\n");
+}
+void flush_icache(void) __attribute__((weak, alias("__flush_icache")));
 
 int do_icache ( cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
switch (argc) {
case 2: /* on / off */
-   switch (on_off(argv[1])) {
+   switch (parse_argv(argv[1])) {
case 0: icache_disable();
break;
case 1: icache_enable ();
break;
+   case 2: flush_icache();
+   break;
}
/* FALL TROUGH */
case 1: /* get status */
@@ -50,15 +59,24 @@ int do_icache ( cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
return 0;
 }
 
+void __flush_dcache(void)
+{
+   printf("No arch specific flush_dcache available!\n");
+   /* please define arch specific flush_dcache */
+}
+void flush_dcache(void) __attribute__((weak, alias("__flush_dcache")));
+
 int do_dcache ( cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
switch (argc) {
case 2: /* on / off */
-   switch (on_off(argv[1])) {
+   switch (parse_argv(argv[1])) {
case 0: dcache_disable();
break;
case 1: dcache_enable ();
break;
+   case 2: flush_dcache();
+   break;
}
/* FALL TROUGH */
case 1: /* get status */
@@ -72,9 +90,11 @@ int do_dcache ( cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 
 }
 
-static int on_off (const char *s)
+static int parse_argv(const char *s)
 {
-   if (strcmp(s, "on") == 0) {
+   if (strcmp(s, "flush") == 0) {
+   return (2);
+   } else if (strcmp(s, "on") == 0) {
return (1);
} else if (strcmp(s, "off") == 0) {
return (0);
@@ -86,13 +106,13 @@ static int on_off (const char *s)
 U_BOOT_CMD(
icache,   2,   1, do_icache,
"enable or disable instruction cache",
-   "[on, off]\n"
-   "- enable or disable instruction cache"
+   "[on, off, flush]\n"
+   "- enable, disable, or flush instruction cache"
 );
 
 U_BOOT_CMD(
dcache,   2,   1, do_dcache,
"enable or disable data cache",
-   "[on, off]\n"
-   "- enable or disable data (writethrough) cache"
+   "[on, off, flush]\n"
+   "- enable, disable, or flush data (writethrough) cache"
 );
-- 
1.7.3.4


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

[U-Boot] [PATCH 2/2] powerpc/85xx: provide 85xx flush_icache for cmd_cache

[Matthew McClintock]

This provides a function that will override the weak function
flush_icache to let 85xx boards to flush the icache

cc: Kumar Gala 
Signed-off-by: Matthew McClintock 
---
 arch/powerpc/cpu/mpc85xx/start.S |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 05db90a..f717309 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -745,6 +745,8 @@ mck_return:
 
 /* Cache functions.
 */
+.globl flush_icache
+flush_icache:
 .globl invalidate_icache
 invalidate_icache:
mfspr   r0,L1CSR1
-- 
1.7.3.4


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

[U-Boot] [PATCH 3/3] common/cmd_ximg.c: add ifdef protection for gzip uncompression

[Matthew McClintock]

Print a message if we do not have the ability to uncompress a gzip
image. Before, u-boot would just assume the routines were available

Signed-off-by: Matthew McClintock 
---
 common/cmd_ximg.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/common/cmd_ximg.c b/common/cmd_ximg.c
index dceb975..2ec7ba4 100644
--- a/common/cmd_ximg.c
+++ b/common/cmd_ximg.c
@@ -216,12 +216,18 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char 
* const argv[])
 #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
break;
case IH_COMP_GZIP:
+#ifdef CONFIG_GZIP
printf ("   Uncompressing part %d ... ", part);
if (gunzip ((void *) dest, unc_len,
(uchar *) data, &len) != 0) {
puts ("GUNZIP ERROR - image not loaded\n");
return 1;
}
+#else
+   printf("gzip decompression not supported in this"
+   " build!\n");
+   return 1;
+#endif
break;
 #if defined(CONFIG_BZIP2)
case IH_COMP_BZIP2:
-- 
1.7.3.4


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

Re: [U-Boot] Formal acks and patchwork (was: [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/)

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4dda69a1.1070...@aribaud.net> you wrote:
> 
> > Note that this is NOT nitpicking:  Patchwork will automatically add
> > such correct Acked-by: lines to the patch, so we don't have to track
> > thse manually - this saves a LOT of time to the maintainers.
> 
> One question: where is the information presented in patchwork, apart 
> from coloring the ack line when displaying the patch discussion thread? 
> I cannot find e.g. a summary list of all acks to a given patch.

PW automatically inserts this into the patch if you click on the
"Download: mbox" link, or is you access the patch through pwclient.

For example, instead of applying a patch directly from my mailbox I
use this file only to get the hash value for the PW entry, and then
use pwclient to apply it and to update it's state:

HASH=$(pwparser.py --hash <$PATCH)
if [ -z "$HASH" ]
then
echo "ERROR: $PATCH - no such entry in PatchWork" >&2
exit 1
fi

if pwclient apply -h $HASH
then
pwclient update -s 'Accepted' -h $HASH
fi

This is extremely convenient as it automatically takes care of both
the Acks and the state change.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Each honest calling, each walk of life, has its own  elite,  its  own
aristocracy based on excellence of performance. - James Bryant Conant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] disk/part.c: Make features optional

[Matthew McClintock]

If we don't want to build support for any partition types we can now
add #undef CONFIG_PARTITIONS in a board config file to keep this from
being compiled in. Otherwise boards assume this is compiled in by
default

Signed-off-by: Matthew McClintock 
---
 common/cmd_mmc.c  |2 ++
 disk/Makefile |2 +-
 drivers/mmc/mmc.c |2 ++
 include/config_defaults.h |1 +
 4 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 6166749..8e65720 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -168,7 +168,9 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
mmc_dev = mmc_get_dev(dev);
if (mmc_dev != NULL &&
mmc_dev->type != DEV_TYPE_UNKNOWN) {
+#ifdef CONFIG_PARTITIONS
print_part(mmc_dev);
+#endif
return 0;
}
 
diff --git a/disk/Makefile b/disk/Makefile
index 17266a2..5affe34 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)libdisk.o
 
-COBJS-y += part.o
+COBJS-$(CONFIG_PARTITIONS) += part.o
 COBJS-$(CONFIG_MAC_PARTITION)   += part_mac.o
 COBJS-$(CONFIG_DOS_PARTITION)   += part_dos.o
 COBJS-$(CONFIG_ISO_PARTITION)   += part_iso.o
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7e69faf..ea5cdcb 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1012,7 +1012,9 @@ int mmc_startup(struct mmc *mmc)
(mmc->cid[1] >> 8) & 0xff, mmc->cid[1] & 0xff);
sprintf(mmc->block_dev.revision, "%d.%d", mmc->cid[2] >> 28,
(mmc->cid[2] >> 24) & 0xf);
+#ifdef CONFIG_PARTITIONS
init_part(&mmc->block_dev);
+#endif
 
return 0;
 }
diff --git a/include/config_defaults.h b/include/config_defaults.h
index 0337163..d023c63 100644
--- a/include/config_defaults.h
+++ b/include/config_defaults.h
@@ -16,5 +16,6 @@
 
 #define CONFIG_GZIP 1
 #define CONFIG_ZLIB 1
+#define CONFIG_PARTITIONS 1
 
 #endif
-- 
1.7.3.4


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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4dda99bc.80...@comcast.net> you wrote:
>
> >> The library function acts as a pre-scaler using a 'raw tick counter' and a
> >> 'raw tick rate' supplied by the low level architecture. We define this weak
> > What are "raw" ticks?  And what are "cooked" ticks, then?
> Hi all,
>   FWIW,  "cooked" ticks would be 1 ms ticks, although we never 
> really use them as such.

Sorry, but I disagree here.

A tick is defined as the smallest increment of system time as measured by a
computer system (see http://en.wikipedia.org/wiki/System_time):

System time is measured by a system clock, which is typically
implemented as a simple count of the number of ticks that have
transpired since some arbitrary starting date, called the
epoch.

There is no such thing as "raw ticks", a tick is inherently "raw" and
needs scaling.

> I have looked at it as a reference. However, there is one disadvantage 
> in using the PPC code as a reference. It has a 64 bit timestamp. Many 
> systems do not have a 64 bit timestamp, but rather a 32 bit timestamp.  
> It is possible to extend the 32 bit timestamp to a 64 bit timestamp if 
> get_timer is called often enough that there will only be a single 
> rollover of the bottom 32 bits  between uses. However, if that condition 

Or if there re other methods to detect and handle such a situation. On
many systems, the timer can generate an interrupt, so it would be
trivial enough to implement the handling of this in the interrupt
handler.

> is met, there is no need to extend the timer to 64 bits. Instead, just 
> convert the elapsed time since the last call (which you know) to ms and 
> be done with it.  As Wolfgang said above, any counter that has better 
> than 1 ms resolution  is adequate to the task. The additional 
> requirement that we have stated is that the counter be long enough that 
> it does not overflow between calls to get_timer. If the counter is 64 

The design should not make any assumptions about when or how often
get_timer() is being called.  It should just work :-)

> can get that working in all cases quite easily I think. We can avoid the 
> "no divide" optimization until everybody is satisfied with what we have.

We should first get a common API and a working implementation for all
architectures before we consider any optimizations.




> That is fine with me. The reason this was being done was to attempt to 
> emulate, as much as possible, the power PC, where the 64 bit timestamp 
> counter allows calls to get_timer separated by many minutes and several 
> console commands to work properly. These get timer commands will NOT 
> work properly on systems that have a 32 bit counter that overflows every 
> 200 seconds or so. The call in the idle loop was an attempt to make the 
> 32 bit systems work more like the 64 bit systems. One may then either

Can you show me any system where it is not possible to implement a 64
bit periodic timer with sufficient resolution?

Please note:  even on PowerPC where we have a 64 bit time base
register for free, the timer services are not implemented on this
base.  Instead, the interrupt handler for the decrementer will
increment the "timestamp" counter variable (see timer_interrupt() in
arch/powerpc/lib/interrupts.c).

I bet that functionally equivalent code is available on all systems.

Note2: this is a fundamental difference between get_timer() and
udelay().  udelay() has to be available very early, but needs to be
good for a few hundred microsecods or so.  get_timer() is a high level
interface that should not suffer from any restrictions.


>1.   Define calls to get_timer to measure an elapsed interval
>   separated by any returns to the command processor as broken.

No.

>2. Require the use of interrupts to extend the 32 bit timestamp.
>   (This may not be possible on all systems as the timer used for
>   performance monitoring does not interrupt, etc.)

This is definitely an option.  It works fine on some systems.
For those systems where it doesn't work, there are probably other
alternatives.


>3. Allow the call in the idle loop under the assumption that we are
>   talking about timing in the minutes range, not a few seconds.

We must not make any such assumptions.  Assume someone is running a
standalone application (like some burn-in test software), which runs
for a couple of hours and then returns to U-Boot.

> If get_timer is used to timeout failing hardware operations, the CPU is 
> usually in a reasonably tight loop and get_timer will certainly be 
> called at least once a minute. In this case, all will be well. If 
> get_timer is used to obtain a timestamp during one u-boot command to be 
> compared with a timestamp taken by a later command (say inside a 
> script), it will not function properly if the total delay (or the delay 
> in any one command) exceeds the hardware timer rollover interval. The 

get_timer() is defined to retur

Re: [U-Boot] Formal acks and patchwork

[Albert ARIBAUD]

Le 23/05/2011 20:44, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4dda69a1.1070...@aribaud.net>  you wrote:
>>
>>> Note that this is NOT nitpicking:  Patchwork will automatically add
>>> such correct Acked-by: lines to the patch, so we don't have to track
>>> thse manually - this saves a LOT of time to the maintainers.
>>
>> One question: where is the information presented in patchwork, apart
>> from coloring the ack line when displaying the patch discussion thread?
>> I cannot find e.g. a summary list of all acks to a given patch.
>
> PW automatically inserts this into the patch if you click on the
> "Download: mbox" link, or is you access the patch through pwclient.
>
> For example, instead of applying a patch directly from my mailbox I
> use this file only to get the hash value for the PW entry, and then
> use pwclient to apply it and to update it's state:
>
>  HASH=$(pwparser.py --hash<$PATCH)
>  if [ -z "$HASH" ]
>  then
>  echo "ERROR: $PATCH - no such entry in PatchWork">&2
>  exit 1
>  fi
>
>  if pwclient apply -h $HASH
>  then
>  pwclient update -s 'Accepted' -h $HASH
>  fi
>
> This is extremely convenient as it automatically takes care of both
> the Acks and the state change.

Thanks. Looks like this could be handy for many others. Maybe it should 
be 'backported' into pwclient itself as a new command.

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4ddaa705.1040...@comcast.net> you wrote:
>
>   My apologies for being a little (perhaps more than a little) 
> dense. As they say, "after further review", I think the key aspect of 
> the PPC timer system is that it uses the decrementer register to 
> generate an interrupt at a 1 KHz rate. What I have been attempting here 
> is to produce a timer system that does not use interrupts at all. This 
> is a fundamental design question. Naturally, systems that can generate 

No, it is not.  It is an implementation detail which is irrelevant to
almost all users of U-Boot.

Or do you actucally care if your UART driver uses polling or
interrupts?

> an interrupt at a 1 KHz rate (or at any (reasonable) higher rate for 
> that matter) using the decrementer register can produce a 1 ms 
> resolution software counter that updates "by magic". If my understanding 
> of this PPC  code is incorrect, somebody please stop me before I make a 
> further fool of myself!  Is it then a design requirement that the timer 
> system use interrupts? Is that what is meant by using the PPC system as 

No, it is not a design requirement.  It is just one possible
implementation.  Any other method that achieves the same or similar
results is as good.  As noted before, on PowerPC we could have
probably avoided this and just base all timer services on the timebase
register.

[The reason for this dual implementation is historical.  When I wrote
this code, I did not know if we would ever need any fancy timer-
controlled callbacks or similar.  And I needed to implement interrupt
handling for a few other purposes (for example for use in standalone
applications; this was an explicit requirement at that time).  And the
timer was something that made a good and simple example.]

> a model? If so, is it possible/reasonable on all the u-boots that are 
> out there to generate and process timer interrupts at some (hopefully 
> but not necessarily) programmable rate?

I consider this an implementation detail.  On all architectures it
should be possible to use interrupts, so if the hardware supports a
timer that can generate interrupts it should be possible to use this.
But it is not a requirement that all implementations must work like
this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In theory, there is no difference between  theory  and  practice.  In
practice, however, there is.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Formal acks and patchwork

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4ddab341.20...@aribaud.net> you wrote:
>
> > For example, instead of applying a patch directly from my mailbox I
> > use this file only to get the hash value for the PW entry, and then
> > use pwclient to apply it and to update it's state:
> >
> >  HASH=$(pwparser.py --hash<$PATCH)
> >  if [ -z "$HASH" ]
> >  then
> >  echo "ERROR: $PATCH - no such entry in PatchWork">&2
> >  exit 1
> >  fi
> >
> >  if pwclient apply -h $HASH
> >  then
> >  pwclient update -s 'Accepted' -h $HASH
> >  fi
> >
> > This is extremely convenient as it automatically takes care of both
> > the Acks and the state change.
> 
> Thanks. Looks like this could be handy for many others. Maybe it should 
> be 'backported' into pwclient itself as a new command.

Note that there is a caveat of this approach.  Or call it bug in PW.
We frequently see patch series, which get posted in several versions.
Quite often not all patches are changed, so it happens that for
example patch 3/8 is the same in all versions 2, 3 and 4 of the patch
series.  That means all versions of this patch have the same hash.
Usually I apply the latest version, and want to change the status of
this one, but the 'pwclient -h $HASH' will always reference the
_oldest_ version of the patch.  So watchout when you see it changing
the state from "superseded" to "applied" - usually this means it
changed the wrong version.  [I reported this on the PW ML, but no
response yet.]

I should mention that I have hacked pwclient a bit to use "git am"
instead of plain "patch", and to report the status change:

@@ -110,7 +110,7 @@
 (os.path.basename(sys.argv[0])))
 sys.stderr.write("Where  is one of:\n")
 sys.stderr.write(
-"""apply : Apply a patch (in the current dir, using -p1)
+"""apply : Apply a patch (using 'git-am -3 -u 
--whitespace=strip')
 get   : Download a patch and save it locally
 projects  : List all projects
 states: Show list of potential patch states
@@ -260,7 +260,7 @@
 print "Description: %s" % patch['name']
 s = rpc.patch_get_mbox(patch_id)
 if len(s) > 0:
-proc = subprocess.Popen(['patch', '-p1'], stdin = subprocess.PIPE)
+proc = subprocess.Popen(['git', 'am', '-3', '-u', 
'--whitespace=strip'], stdin = subprocess.PIPE)
 proc.communicate(s)
 else:
 sys.stderr.write("Error: No patch content found\n")
@@ -280,6 +280,8 @@
 if state_id == 0:
 sys.stderr.write("Error: No State found matching %s*\n" % state)
 sys.exit(1)
+   old_id = patch['state']
+sys.stderr.write("## commit: %s  state: %s ==> %s\n" % (commit, 
old_id, state))
 params['state'] = state_id
 
 if commit:


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The only perfect science is hind-sight.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] bank8 in OMAP-L138 ?

[Ran Shalit]

On Sun, May 22, 2011 at 9:55 PM, Ran Shalit  wrote:

>  Hello,
>
> It seems that bank 8 is missing in
>  [u-boot.git]  /
> arch  /
> arm /
> include/
> asm/
> arch-davinci/
> gpio_defs.h
> reference for bank 8 can be found in TI document:
> http://focus.ti.com/docs/prod/folders/print/omap-l138.html
>
> I have tried to add it to my code as following:
>
> #ifndef CONFIG_SOC_DA8XX
> #define DAVINCI_GPIO_BINTEN0x01C67008
> #define DAVINCI_GPIO_BANK010x01C67010
> #define DAVINCI_GPIO_BANK230x01C67038
> #define DAVINCI_GPIO_BANK450x01C67060
> #define DAVINCI_GPIO_BANK670x01C67088
> + #define DAVINCI_GPIO_BANK80x01C670B0
> #else /* CONFIG_SOC_DA8XX */
> #define DAVINCI_GPIO_BINTEN0x01E26008
> #define DAVINCI_GPIO_BANK010x01E26010
> #define DAVINCI_GPIO_BANK230x01E26038
> #define DAVINCI_GPIO_BANK450x01E26060
> #define DAVINCI_GPIO_BANK670x01E26088
> +#define DAVINCI_GPIO_BANK80x01E260B0
> #endif /* CONFIG_SOC_DA8XX */
>
> #define davinci_gpio_bank01 ((structI  davinci_gpio *)DAVINCI_GPIO_BANK01)
> #define davinci_gpio_bank23 ((struct davinci_gpio *)DAVINCI_GPIO_BANK23)
> #define davinci_gpio_bank45 ((struct davinci_gpio *)DAVINCI_GPIO_BANK45)
> #define davinci_gpio_bank67 ((struct davinci_gpio *)DAVINCI_GPIO_BANK67)
> +#define davinci_gpio_bank8 ((struct davinci_gpio *)DAVINCI_GPIO_BANK8)
> The thing is that on accesing bank 8  the u-boot crashes. Is there any
> memory allocation or power management of bank 8 that I am not familiar with
> ?
>
> Regards,
>  Ran
>

Hello,

I am still unsure as to what can be the problem, if anyone can please send
any idea...
Thank you!
Ran
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

On 24/05/11 00:00, Andrew Dyer wrote:
> On Mon, May 23, 2011 at 06:54, Graeme Russ  wrote:
>> There is no need to use get_timer() and reset_timer() and there are build
> 
> shouldn't the above say set_timer() instead of get_timer()?
> 

Yes, thanks

Regards,

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

On 24/05/11 04:29, Scott McNutt wrote:
> Hi Bill,
> 
> J. William Campbell wrote:
>> On 5/23/2011 6:12 AM, Scott McNutt wrote:
>>> Dear Graeme,
>>>
>>> Graeme Russ wrote:
 On 23/05/11 22:19, Scott McNutt wrote:
> Hi Graeme,
>
> Graeme Russ wrote:
>> There is no need to use get_timer() and reset_timer() and there are
>> build
> I must have missed something WRT reset_timer() -- my apologies
> if I'm covering old ground.
>
> When the timestamp is incremented using an interrupt that occurs with
> a period greater than 1 ms, we can get early timeouts. reset_timer()
> solved the problem. What's the recommended approach for dealing with
> this without reset_timer() ?
>> Hi Scott,
>>   Are you saying that the interrupt frequency is greater than
>> 1000 times per second, or as I read it, the frequency is less than 1000
>> per second (period greater than 1 ms). If anything, that should make the
>> timer run slow, not fast.
>>  I wonder if it is a resolution issue. What are the typical delays in ms
>> you are using?
> 
> Some older nios2 implementations have _fixed_ 10 msec timers.
> Basically, the timestamp is incremented asynchronous to get_timer(0).
> So a  10 msec timeout can occur, for example, almost immediately if
> the timer isn't reset just prior to calling get_timer(0). There are
> more details in the comments for the following commits:
> 
> nios2: Reload timer count in reset_timer():
>   d8bc0a2889700ba063598de6d4e7d135360b537e
> 
> cfi_flash: reset timer in flash status check:
>   22d6c8faac4e9fa43232b0cf4da427ec14d72ad3
> 
> I'm totally in favor of cleaning this stuff up. It caused some
> headaches (and wasted time) about 13 months ago. My primary concern
> is to avoid breaking things that currently work for us nios2
> weenies ... at least for any length of time.
> 
> Things are a bit tight for me until next week or so. I'll probably
> come up for air around June 1st ... and I'll be glad to help out.
> 

Is there any reason why we cannot silently perform a reset_timer() any time
set_timer() is called with a parameter of 0?

Regards,

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

Re: [U-Boot] Formal acks and patchwork

[Albert ARIBAUD]

Le 23/05/2011 21:42, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4ddab341.20...@aribaud.net>  you wrote:
>>
>>> For example, instead of applying a patch directly from my mailbox I
>>> use this file only to get the hash value for the PW entry, and then
>>> use pwclient to apply it and to update it's state:
>>>
>>>   HASH=$(pwparser.py --hash<$PATCH)
>>>   if [ -z "$HASH" ]
>>>   then
>>>   echo "ERROR: $PATCH - no such entry in PatchWork">&2
>>>   exit 1
>>>   fi
>>>
>>>   if pwclient apply -h $HASH
>>>   then
>>>   pwclient update -s 'Accepted' -h $HASH
>>>   fi
>>>
>>> This is extremely convenient as it automatically takes care of both
>>> the Acks and the state change.
>>
>> Thanks. Looks like this could be handy for many others. Maybe it should
>> be 'backported' into pwclient itself as a new command.
>
> Note that there is a caveat of this approach.  Or call it bug in PW.
> We frequently see patch series, which get posted in several versions.
> Quite often not all patches are changed, so it happens that for
> example patch 3/8 is the same in all versions 2, 3 and 4 of the patch
> series.  That means all versions of this patch have the same hash.
> Usually I apply the latest version, and want to change the status of
> this one, but the 'pwclient -h $HASH' will always reference the
> _oldest_ version of the patch.  So watchout when you see it changing
> the state from "superseded" to "applied" - usually this means it
> changed the wrong version.  [I reported this on the PW ML, but no
> response yet.]
>
> I should mention that I have hacked pwclient a bit to use "git am"
> instead of plain "patch", and to report the status change:
>
> @@ -110,7 +110,7 @@
>   (os.path.basename(sys.argv[0])))
>   sys.stderr.write("Where  is one of:\n")
>   sys.stderr.write(
> -"""apply : Apply a patch (in the current dir, using -p1)
> +"""apply : Apply a patch (using 'git-am -3 -u 
> --whitespace=strip')
>   get   : Download a patch and save it locally
>   projects  : List all projects
>   states: Show list of potential patch states
> @@ -260,7 +260,7 @@
>   print "Description: %s" % patch['name']
>   s = rpc.patch_get_mbox(patch_id)
>   if len(s)>  0:
> -proc = subprocess.Popen(['patch', '-p1'], stdin = subprocess.PIPE)
> +proc = subprocess.Popen(['git', 'am', '-3', '-u', 
> '--whitespace=strip'], stdin = subprocess.PIPE)
>   proc.communicate(s)
>   else:
>   sys.stderr.write("Error: No patch content found\n")
> @@ -280,6 +280,8 @@
>   if state_id == 0:
>   sys.stderr.write("Error: No State found matching %s*\n" % state)
>   sys.exit(1)
> +   old_id = patch['state']
> +sys.stderr.write("## commit: %s  state: %s ==>  %s\n" % (commit, 
> old_id, state))
>   params['state'] = state_id
>
>   if commit:

I personally only added a "pwclient am" command to do a git am, the same 
way as "pwclient apply" does a git apply.

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[J. William Campbell]

On 5/23/2011 12:33 PM, Wolfgang Denk wrote:

Dear "J. William Campbell",

In message<4ddaa705.1040...@comcast.net>  you wrote:

   My apologies for being a little (perhaps more than a little)
dense. As they say, "after further review", I think the key aspect of
the PPC timer system is that it uses the decrementer register to
generate an interrupt at a 1 KHz rate. What I have been attempting here
is to produce a timer system that does not use interrupts at all. This
is a fundamental design question. Naturally, systems that can generate

No, it is not.  It is an implementation detail which is irrelevant to
almost all users of U-Boot.

Or do you actucally care if your UART driver uses polling or
interrupts?

Hi All,
  I might care a lot if I expect typeahead to work, or if I am 
sending a command script via a terminal emulator and I don't want to 
loose characters while u-boot is off executing a command. One might 
(correctly) say that that is too much to expect of a boot loader, and 
define polling as "good enough", which I advocate, or not. YMMV.

an interrupt at a 1 KHz rate (or at any (reasonable) higher rate for
that matter) using the decrementer register can produce a 1 ms
resolution software counter that updates "by magic". If my understanding
of this PPC  code is incorrect, somebody please stop me before I make a
further fool of myself!  Is it then a design requirement that the timer
system use interrupts? Is that what is meant by using the PPC system as

No, it is not a design requirement.  It is just one possible
implementation.  Any other method that achieves the same or similar
results is as good.  As noted before, on PowerPC we could have
probably avoided this and just base all timer services on the timebase
register.

[The reason for this dual implementation is historical.  When I wrote
this code, I did not know if we would ever need any fancy timer-
controlled callbacks or similar.  And I needed to implement interrupt
handling for a few other purposes (for example for use in standalone
applications; this was an explicit requirement at that time).  And the
timer was something that made a good and simple example.]


a model? If so, is it possible/reasonable on all the u-boots that are
out there to generate and process timer interrupts at some (hopefully
but not necessarily) programmable rate?

I consider this an implementation detail.  On all architectures it
should be possible to use interrupts, so if the hardware supports a
timer that can generate interrupts it should be possible to use this.
But it is not a requirement that all implementations must work like
  Ok, this is very nice to understand. I will attempt to summarize 
what I think this email and the previous one means. First, the required 
properties of the get_timer routine.


  1. It must have 1 millisecond resolution and accuracy (more or less).
 For instance, the old NIOS timer that incremented the timestamp by
 10 every 10 milliseconds in response to an interrupt is not compliant.
  2. The get_timer routine must have full period accuracy without any
 assumptions regarding what is going on in u-boot. This period is
 4294967 seconds or so.

I then suggest that the minimum system requirements to support the 
u-boot timer are as follows:


   * Either there exists a free-running timer whose period is > 4294967
 and whose resolution is 1 millisecond or better. This probably
 includes all 64 bit timestamp counters.
   * Or there exists a method of generating interrupts at a known rate
 of 1 millisecond or faster. This is a superset of  the current PPC
 method.
   * Or there exists a method of generating interrupts at a known fixed
 rate slower than once a millisecond AND there exists a readable
 free running counter whose period is longer or the same as the
 interrupt rate AND whose resolution is at least 1 ms. This would
 include N bit counters that generate an interrupt when they
 overflow, or some long timestamp counter with another, possibly 
 unrelated interrupt generating methodology that is faster than the

 counter overflow interval.

There are many systems that are able to do all three cases, or two of 
three, so they have a choice on how to implement get_timer(). I claim 
that these are sufficient conditions. I also claim they are necessary. 
If a hardware system does not meet these criteria, I claim it can't meet 
the get_timer requirements. Do such systems exist today that use u-boot? 
I think probably so, but maybe they are corner cases. Note that you 
cannot extend a 32 bit counter to a 64 bit counter reliably without 
using interrupts to do so when get_timer is not being called.


Systems using the first approach above have essentially all their logic 
in the get_timer routine, but MUST use at least some 64 bit arithmetic 
(actually 33 bit arithmetic if you don't count shifts) to do so because 
the delta time between calls can be very large. The routi

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

On 23/05/11 23:19, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4dda5334.4060...@gmail.com> you wrote:
>>
  - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
and get_tick_rate() to correctly maintain the ms counter used by
get_timer() - This function can be weak (so next point)
>>>
>>> Ditto.  What would that do?  If it gets milliseconds as the name
>>> suggest, that's already the function needed for get_timer()?
>>
>> OK, there appears to be a consensus that not all hardware actually supports
>> a free-running timer with 1ms resolution. To overcome this, the idea is to
> 
> Indeed.  I guess most of them do not.
> 
>> create a common library function which maintains the free running counter.
>> The library function acts as a pre-scaler using a 'raw tick counter' and a
>> 'raw tick rate' supplied by the low level architecture. We define this weak
> 
> What are "raw" ticks?  And what are "cooked" ticks, then?
> 

We never talked about cooked tick - I agree 'raw' is superfluous

>> so that if the architecture can provide a free running 1ms counter, there
>> is no (code size) penalty
> 
> Why do we need a free running 1ms counter at all?  Any free running
> counter of at least millisecoind resolution should be good enough.
> 

Because it get_timer() is 1ms - Yes, get_timer() can calculate it from a
higher resolution source, but that creates multiple implementations of the
pre-scaler of multiple arches - The goal is to reduce code duplication
here. get_timer() calls get_raw_ms() (ok, we could just call that get_ms)
which is a common library routine which does the pre-scaling. Arches which
can maintain this 1ms counter (via interrupts or native hardware counters
for example) don't need it.

>> This approach eliminates all the existing per-arch code which (attempts) to
>> manage the time base behind get time. So we simplify each arch down to it's
>> bare essentials - Provide a counter which increments at a natural fixed
>> rate and what the rate is - Let common library code deal with the rest.
> 
> Did you have a look at the PowerPC implementation?  I'd like to see
> this used as reference.
> 
  - Calling of get_raw_ticks() regularly in the main loop (how ofter will
depend on the raw tick rate, but I image it will never be necessary
to call more often than once every few minutes)
>>>
>>> NAK. This concept is fundamentally broken.  I will not accept it.
>>
>> Some existing timers are fundamentally broken - The glitch at the
>> 0x to 0x rollover or rollover early - The method discussed
>> in this thread eliminates all such glitches. Provided pre-scaler in /lib/
>> (triggered by get_timer() usually) is called often enough (71 minutes for a
>> 32-bit 1MHz counter) then there is no need. Even then, it is only important
> 
> We already have this nightmare of code for triggering the watchdog on
> systems that use it.
> 
> Assuming there are places in the main loop that get executed often
> enough is a broken concept, and I will not accept any such code.
> 
>> over the time period you are measuring (i.e. two independent 5s delays 2
>> hours apart will not be a problem)
> 
> What is the practical purpose of get_timer()?  What is the longest
> interval we have to cover?  And what is the problem with a rollover?
> 
  - If the hardware implements a native 32-bit 1ms counter, no call in
the main loop is required
>>>
>>> We should make no such requirements.
>>
>> No such requirement of what?
> 
> Of making any calls in the main loop.
> 
>>> Can we not start simple, say by a plain free-runnign 64 bit counter,
>>> be it implemented in hardwar eor in software?  On PowerPC, we have
>>
>> That's exactly what we are suggesting - Let the hardware be free to
>> implement the counter at whatever frequency suits it. 64-bit is not needed
>> in reality
> 
> It may not be needed on some systems, but may be needed on others
> where 32 bit is too short.  Let's use the common base that is know to
> work on all systems, even if it's not strictly needed on all of them.
> 
>>> this immediately in form of the time base register (or more precisely
>>> in form of the two 32 bit registers tbu and tbl representing time base
>>> upper and time base lower).
>>>
>>> Modelling a similar interface using _any_ kind of timer service should
>>> be trivial.  And from there, we can just use the existing code again.
>>
>> Yes, have the library function manage the actual '1ms' aspect
> 
> This is what PPC is doing. And I understand that Reinhard did the same
> in software for AT91.

Yes, duplicate code - lets 'libify' it

Regards,

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[J. William Campbell]

On 5/23/2011 1:10 PM, Graeme Russ wrote:
> On 24/05/11 04:29, Scott McNutt wrote:
>> Hi Bill,
>>
>> J. William Campbell wrote:
>>> On 5/23/2011 6:12 AM, Scott McNutt wrote:
 Dear Graeme,

 Graeme Russ wrote:
> On 23/05/11 22:19, Scott McNutt wrote:
>> Hi Graeme,
>>
>> Graeme Russ wrote:
>>> There is no need to use get_timer() and reset_timer() and there are
>>> build
>> I must have missed something WRT reset_timer() -- my apologies
>> if I'm covering old ground.
>>
>> When the timestamp is incremented using an interrupt that occurs with
>> a period greater than 1 ms, we can get early timeouts. reset_timer()
>> solved the problem. What's the recommended approach for dealing with
>> this without reset_timer() ?
>>> Hi Scott,
>>>Are you saying that the interrupt frequency is greater than
>>> 1000 times per second, or as I read it, the frequency is less than 1000
>>> per second (period greater than 1 ms). If anything, that should make the
>>> timer run slow, not fast.
>>>   I wonder if it is a resolution issue. What are the typical delays in ms
>>> you are using?
>> Some older nios2 implementations have _fixed_ 10 msec timers.
>> Basically, the timestamp is incremented asynchronous to get_timer(0).
>> So a  10 msec timeout can occur, for example, almost immediately if
>> the timer isn't reset just prior to calling get_timer(0). There are
>> more details in the comments for the following commits:
>>
>> nios2: Reload timer count in reset_timer():
>>d8bc0a2889700ba063598de6d4e7d135360b537e
>>
>> cfi_flash: reset timer in flash status check:
>>22d6c8faac4e9fa43232b0cf4da427ec14d72ad3
>>
>> I'm totally in favor of cleaning this stuff up. It caused some
>> headaches (and wasted time) about 13 months ago. My primary concern
>> is to avoid breaking things that currently work for us nios2
>> weenies ... at least for any length of time.
>>
>> Things are a bit tight for me until next week or so. I'll probably
>> come up for air around June 1st ... and I'll be glad to help out.
>>
> Is there any reason why we cannot silently perform a reset_timer() any time
> set_timer() is called with a parameter of 0?
Hi All,
  I assume you mean get_timer(0)?  In principle, you cannot do this 
because it could be inside another get_timer(0) loop that has already 
some time elapsed before you hit the inner get_timer(0). I think what 
needs to happen on the old NIOS with 10 ms resolution on the interrupt 
times is that all timer intervals must have 10 ms added and then rounded 
up to the nearest multiple of 10. Thus, if you wanted to wait for 1 
millisecond, you must use an argument of 20 ms to be sure you wait at 
all! If you use an argument of 10, it won't help because you could get 
an interrupt right away and exit. If these routines are nios2 specific, 
you could add a local reset_timer, but I assume they are generic. . Note 
that if these routines are not nios2 specific, is there any harm in 
waiting "too long"?

Best Regards,
Bill Campbell
> Regards,
>
> Graeme
>
>

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

On 24/05/11 06:49, J. William Campbell wrote:
> On 5/23/2011 1:10 PM, Graeme Russ wrote:
>> On 24/05/11 04:29, Scott McNutt wrote:
>>> Hi Bill,
>>>
>>> J. William Campbell wrote:
 On 5/23/2011 6:12 AM, Scott McNutt wrote:
> Dear Graeme,
>
> Graeme Russ wrote:
>> On 23/05/11 22:19, Scott McNutt wrote:
>>> Hi Graeme,
>>>
>>> Graeme Russ wrote:
 There is no need to use get_timer() and reset_timer() and there are
 build
>>> I must have missed something WRT reset_timer() -- my apologies
>>> if I'm covering old ground.
>>>
>>> When the timestamp is incremented using an interrupt that occurs with
>>> a period greater than 1 ms, we can get early timeouts. reset_timer()
>>> solved the problem. What's the recommended approach for dealing with
>>> this without reset_timer() ?
 Hi Scott,
Are you saying that the interrupt frequency is greater than
 1000 times per second, or as I read it, the frequency is less than 1000
 per second (period greater than 1 ms). If anything, that should make the
 timer run slow, not fast.
   I wonder if it is a resolution issue. What are the typical delays in ms
 you are using?
>>> Some older nios2 implementations have _fixed_ 10 msec timers.
>>> Basically, the timestamp is incremented asynchronous to get_timer(0).
>>> So a  10 msec timeout can occur, for example, almost immediately if
>>> the timer isn't reset just prior to calling get_timer(0). There are
>>> more details in the comments for the following commits:
>>>
>>> nios2: Reload timer count in reset_timer():
>>>d8bc0a2889700ba063598de6d4e7d135360b537e
>>>
>>> cfi_flash: reset timer in flash status check:
>>>22d6c8faac4e9fa43232b0cf4da427ec14d72ad3
>>>
>>> I'm totally in favor of cleaning this stuff up. It caused some
>>> headaches (and wasted time) about 13 months ago. My primary concern
>>> is to avoid breaking things that currently work for us nios2
>>> weenies ... at least for any length of time.
>>>
>>> Things are a bit tight for me until next week or so. I'll probably
>>> come up for air around June 1st ... and I'll be glad to help out.
>>>
>> Is there any reason why we cannot silently perform a reset_timer() any time
>> set_timer() is called with a parameter of 0?
> Hi All,
>  I assume you mean get_timer(0)?  In principle, you cannot do this

Yes - it's early, no coffee yet ;)
> because it could be inside another get_timer(0) loop that has already some
> time elapsed before you hit the inner get_timer(0). I think what needs to

Correct, but that is what is already happening for ALL arches in cfi due to
the reset_timer() before get_timer(0) - I am suggesting sandboxing the
problem to NIOS until we sort out the timer API properly

> happen on the old NIOS with 10 ms resolution on the interrupt times is that
> all timer intervals must have 10 ms added and then rounded up to the
> nearest multiple of 10. Thus, if you wanted to wait for 1 millisecond, you
> must use an argument of 20 ms to be sure you wait at all! If you use an
> argument of 10, it won't help because you could get an interrupt right away
> and exit. If these routines are nios2 specific, you could add a local
> reset_timer, but I assume they are generic. . Note that if these routines
> are not nios2 specific, is there any harm in waiting "too long"?

Well, we have no control over the argument in cfi driver (unless you plan
to put #ifdef NIOS all over the place)

Maybe we could round up the parameter inside get_timer() itself?

Regards,

Graeme

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

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Alexander Holler]

Hello,

Am 23.05.2011 11:03, schrieb Matthias Weisser:
> In some cases (e.g. bootm with a elf payload which is already at the right
> position) there is a in place copy of data to the same address. Catching this
> saves some ms while booting.
>
> Signed-off-by: Matthias Weisser
> ---
> Changes since V1:
>- Made subject more informative
>- Removed the optimization from bcopy as bcopy is not used anywhere
>
>   lib/string.c |6 ++
>   1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/lib/string.c b/lib/string.c
> index b375b81..2c4f0ec 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count)
>   unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>   char *d8, *s8;
>
> + if (src == dest)
> + return dest;
> +

here is the same, as in the patch I've commented before. There exist no 
reason to add a check for identity to memcpy() because memcpy doesn't 
support overlapping regions (and identity is just a special case of 
overlapping regions). If something might call memcpy() with overlapping 
or identical regions, it should use memmove().

>   /* while all data is aligned (common case), copy a word at a time */
>   if ( (((ulong)dest | (ulong)src)&  (sizeof(*dl) - 1)) == 0) {
>   while (count>= sizeof(*dl)) {
> @@ -497,6 +500,9 @@ void * memmove(void * dest,const void *src,size_t count)
>   {
>   char *tmp, *s;
>
> + if (src == dest)
> + return dest;
> +
>   if (dest<= src) {

Here it is ok, but the check <= could be modified to < too.

Just to clarify my reasoning: the only reason why memcpy() exists, is 
because it should have been a faster version of memmove() without the 
necessary checks.
So if a bug proof of version of memcpy() is wanted, there is no need to 
have a different implementation for memcpy() and memcpy() could just be 
an alias for memmove().
But adding a check for identity to memcpy() is unnecessary.

Sorry, but I had to comment this after having read to many comments in a 
bug about something similiar in

https://bugzilla.redhat.com/show_bug.cgi?id=638477

(Be aware, reading that bug might hurt your brain)

Regards,

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[J. William Campbell]

On 5/23/2011 2:02 PM, Graeme Russ wrote:
> On 24/05/11 06:49, J. William Campbell wrote:
>> On 5/23/2011 1:10 PM, Graeme Russ wrote:
>>> On 24/05/11 04:29, Scott McNutt wrote:
 Hi Bill,

 J. William Campbell wrote:
> On 5/23/2011 6:12 AM, Scott McNutt wrote:
>> Dear Graeme,
>>
>> Graeme Russ wrote:
>>> On 23/05/11 22:19, Scott McNutt wrote:
 Hi Graeme,

 Graeme Russ wrote:
> There is no need to use get_timer() and reset_timer() and there are
> build
 I must have missed something WRT reset_timer() -- my apologies
 if I'm covering old ground.

 When the timestamp is incremented using an interrupt that occurs with
 a period greater than 1 ms, we can get early timeouts. reset_timer()
 solved the problem. What's the recommended approach for dealing with
 this without reset_timer() ?
> Hi Scott,
> Are you saying that the interrupt frequency is greater than
> 1000 times per second, or as I read it, the frequency is less than 1000
> per second (period greater than 1 ms). If anything, that should make the
> timer run slow, not fast.
>I wonder if it is a resolution issue. What are the typical delays in ms
> you are using?
 Some older nios2 implementations have _fixed_ 10 msec timers.
 Basically, the timestamp is incremented asynchronous to get_timer(0).
 So a  10 msec timeout can occur, for example, almost immediately if
 the timer isn't reset just prior to calling get_timer(0). There are
 more details in the comments for the following commits:

 nios2: Reload timer count in reset_timer():
 d8bc0a2889700ba063598de6d4e7d135360b537e

 cfi_flash: reset timer in flash status check:
 22d6c8faac4e9fa43232b0cf4da427ec14d72ad3

 I'm totally in favor of cleaning this stuff up. It caused some
 headaches (and wasted time) about 13 months ago. My primary concern
 is to avoid breaking things that currently work for us nios2
 weenies ... at least for any length of time.

 Things are a bit tight for me until next week or so. I'll probably
 come up for air around June 1st ... and I'll be glad to help out.

>>> Is there any reason why we cannot silently perform a reset_timer() any time
>>> set_timer() is called with a parameter of 0?
>> Hi All,
>>   I assume you mean get_timer(0)?  In principle, you cannot do this
> Yes - it's early, no coffee yet ;)
>> because it could be inside another get_timer(0) loop that has already some
>> time elapsed before you hit the inner get_timer(0). I think what needs to
> Correct, but that is what is already happening for ALL arches in cfi due to
> the reset_timer() before get_timer(0) - I am suggesting sandboxing the
> problem to NIOS until we sort out the timer API properly
>
>> happen on the old NIOS with 10 ms resolution on the interrupt times is that
>> all timer intervals must have 10 ms added and then rounded up to the
>> nearest multiple of 10. Thus, if you wanted to wait for 1 millisecond, you
>> must use an argument of 20 ms to be sure you wait at all! If you use an
>> argument of 10, it won't help because you could get an interrupt right away
>> and exit. If these routines are nios2 specific, you could add a local
>> reset_timer, but I assume they are generic. . Note that if these routines
>> are not nios2 specific, is there any harm in waiting "too long"?
> Well, we have no control over the argument in cfi driver (unless you plan
> to put #ifdef NIOS all over the place)
>
> Maybe we could round up the parameter inside get_timer() itself?
Hi All,
That would probably be the best way to go for now. It might slow 
things down a bit though, if these delays are all desired to be "short", 
like 1 ms. We would expand the 1 ms delay to 15 ms (average) while the 
current (illegal) solution would expand a 1 ms delay to 10 ms always. It 
is worth trying I think. It is also true that any other delays in the 
program will suffer from the 10 ms resolution problem, so your idea is I 
think a good one.

Best Regards,
Bill Campbell
> Regards,
>
> Graeme
>
>
>

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

Re: [U-Boot] [PATCH 1/3] disk/part.c: Make features optional

[Kumar Gala]

On May 23, 2011, at 1:29 PM, Matthew McClintock wrote:

> If we don't want to build support for any partition types we can now
> add #undef CONFIG_PARTITIONS in a board config file to keep this from
> being compiled in. Otherwise boards assume this is compiled in by
> default
> 
> Signed-off-by: Matthew McClintock 
> ---
> common/cmd_mmc.c  |2 ++
> disk/Makefile |2 +-
> drivers/mmc/mmc.c |2 ++
> include/config_defaults.h |1 +
> 4 files changed, 6 insertions(+), 1 deletions(-)

Can you re-submit against at least v2011.06-rc1, this doesn't apply for me 
there.

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

[U-Boot] [PATCH v2 1/3] disk/part.c: Make features optional

[Matthew McClintock]

If we don't want to build support for any partition types we can now
add #undef CONFIG_PARTITIONS in a board config file to keep this from
being compiled in. Otherwise boards assume this is compiled in by
default

Signed-off-by: Matthew McClintock 
---
v2: Fix patch to apply to current tree

Note: This includes the fixes for MMC only. USB/SATA/etc need to do
something similiar

 common/cmd_mmc.c  |2 ++
 disk/Makefile |2 +-
 drivers/mmc/mmc.c |2 ++
 include/config_defaults.h |1 +
 4 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 176646d..fe8c77b 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -180,7 +180,9 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
mmc_dev = mmc_get_dev(curr_device);
if (mmc_dev != NULL &&
mmc_dev->type != DEV_TYPE_UNKNOWN) {
+#ifdef CONFIG_PARTITIONS
print_part(mmc_dev);
+#endif
return 0;
}
 
diff --git a/disk/Makefile b/disk/Makefile
index 17266a2..5affe34 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)libdisk.o
 
-COBJS-y += part.o
+COBJS-$(CONFIG_PARTITIONS) += part.o
 COBJS-$(CONFIG_MAC_PARTITION)   += part_mac.o
 COBJS-$(CONFIG_DOS_PARTITION)   += part_dos.o
 COBJS-$(CONFIG_ISO_PARTITION)   += part_iso.o
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 21aedba..f2d236c 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1007,7 +1007,9 @@ int mmc_startup(struct mmc *mmc)
(mmc->cid[1] >> 8) & 0xff, mmc->cid[1] & 0xff);
sprintf(mmc->block_dev.revision, "%d.%d", mmc->cid[2] >> 28,
(mmc->cid[2] >> 24) & 0xf);
+#ifdef CONFIG_PARTITIONS
init_part(&mmc->block_dev);
+#endif
 
return 0;
 }
diff --git a/include/config_defaults.h b/include/config_defaults.h
index 0337163..d023c63 100644
--- a/include/config_defaults.h
+++ b/include/config_defaults.h
@@ -16,5 +16,6 @@
 
 #define CONFIG_GZIP 1
 #define CONFIG_ZLIB 1
+#define CONFIG_PARTITIONS 1
 
 #endif
-- 
1.7.3.4


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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4ddac2f5.7060...@comcast.net> you wrote:
>
> Does that sound right?


I think so.

> --000308010205050804040502
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit

Could you please stop posting HTML?  Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
No more blah, blah, blah!
-- Kirk, "Miri", stardate 2713.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4ddac866.1050...@comcast.net> you wrote:
>
> > Is there any reason why we cannot silently perform a reset_timer() any time
> > set_timer() is called with a parameter of 0?
> Hi All,
>   I assume you mean get_timer(0)?  In principle, you cannot do this 
> because it could be inside another get_timer(0) loop that has already 
> some time elapsed before you hit the inner get_timer(0). I think what 
> needs to happen on the old NIOS with 10 ms resolution on the interrupt 
> times is that all timer intervals must have 10 ms added and then rounded 
> up to the nearest multiple of 10. Thus, if you wanted to wait for 1 
> millisecond, you must use an argument of 20 ms to be sure you wait at 
> all! If you use an argument of 10, it won't help because you could get 
> an interrupt right away and exit. If these routines are nios2 specific, 
> you could add a local reset_timer, but I assume they are generic. . Note 
> that if these routines are not nios2 specific, is there any harm in 
> waiting "too long"?

I think in the context of this rework get_timer() should be changed to
take no argumen. Actually noe is needed, and if used as is now it can
only cuse harm.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Hindsight is an exact science.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Wolfgang Denk]

Dear Alexander Holler,

In message <4ddacc8b.6090...@ahsoftware.de> you wrote:
> 
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count)
> > unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
> > char *d8, *s8;
> >
> > +   if (src == dest)
> > +   return dest;
> > +
> 
> here is the same, as in the patch I've commented before. There exist no 
> reason to add a check for identity to memcpy() because memcpy doesn't 
> support overlapping regions (and identity is just a special case of 
> overlapping regions). If something might call memcpy() with overlapping 
> or identical regions, it should use memmove().

In an ideal world, nobody will ever use any interfces in a
non-compliant or incorrect way.

In reality, all kind of errors happen.  A little defensive programming
like the one above helps a lot, so please stop complaining even if you
think you don't need this.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Mirrors should reflect a little before throwing back images.
- Jean Cocteau
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] China Daily (European edition, weekly, in English) advertising now open for the first time

[China Daily (European Edition Weekly)]

Hi there

We know how busy you are, so just a quick note, if we may, to let you know 
about China Daily European Edition, advertising in which is now available for 
the first time ever!

As you might see, it's a brand new and exciting opportunity, especially if your 
organisation is intending to expand in the Chinese market, and full page 
advertisements are now invited (flyer link below). It's weekly, it's in 
English, it's a tabloid size business newspaper, it's distributed to its 35000 
C-level subscription base each week, and also offers some private distribution 
to corporate receptions and business travel lounges.

We look forward to hearing your thoughts when you have a moment!

Best wishes, 

Chris Brown 

@ SKS for China Daily European Edition 

W: http://europe.chinadaily.com.cn/

T: +44 (0) 845 428 9350 / or via accts team +44 (0) 207 607 0717 ddi

FLYER/DETAILS LINK: 
http://www.sksassociates.co.uk/cd/ChinaDaily_EuropeanWeekly_MediaFlyer.pdf

Additional notes FYI:

China Daily is China's national English-language newspaper, which was founded 
in 1981. China Daily European Edition Edition (Weekly), is their European 
offering. 

For readers at home and abroad, China Daily is a popular choice among 
English-language media in China. It is the only Chinese newspaper that has 
effectively entered Western mainstream society and is the newspaper most quoted 
by the foreign press. The paper also has published the largest number of 
supplements for international meetings in China among all media outlets. Global 
readers recognize China Daily as the most authoritative and influential 
English-language media in the country. It serves as an important window for 
"China to understand the world and be understood by the world".

China Daily Media Group rides the tide of the times and drives innovations. It 
believes that "content is king". While reporting on China and commenting on the 
world, it is also accelerating efforts to become "localized" overseas, to 
improve reporting, editing and distribution networks worldwide, and to march 
toward being a world-class multiple-platform media group.


Contracted exclusively by:

SKS/Enhanced Media & Communications Ltd
1 Farnham Road, Guildford, Surrey GU2 4RG UK

"Bringing the top drawer to you!"

** It's our intention to only contact you with interesting opportunities you 
might otherwise overlook from the cream of the "top drawer"

** If you feel you have received this email in error, simply REPLY and SEND 
with the subject line intact. Thanks.

 


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

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Alexander Holler]

Am 23.05.2011 23:55, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<4ddacc8b.6090...@ahsoftware.de>  you wrote:
>>
>>> --- a/lib/string.c
>>> +++ b/lib/string.c
>>> @@ -467,6 +467,9 @@ void * memcpy(void *dest, const void *src, size_t count)
>>> unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>>> char *d8, *s8;
>>>
>>> +   if (src == dest)
>>> +   return dest;
>>> +
>>
>> here is the same, as in the patch I've commented before. There exist no
>> reason to add a check for identity to memcpy() because memcpy doesn't
>> support overlapping regions (and identity is just a special case of
>> overlapping regions). If something might call memcpy() with overlapping
>> or identical regions, it should use memmove().
>
> In an ideal world, nobody will ever use any interfces in a
> non-compliant or incorrect way.
>
> In reality, all kind of errors happen.  A little defensive programming
> like the one above helps a lot, so please stop complaining even if you
> think you don't need this.

So you I will look forward to checks for NULL pointers and similiar in 
all C standard functions implemented in u-boot to circumvent tons of 
possible real world bugs in all callers of strcpy, strlen, mem* and 
whatever.

Reads promising,

regards,

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

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Wolfgang Denk]

Dear Alexander Holler,

In message <4ddadbb6.30...@ahsoftware.de> you wrote:
>
> So you I will look forward to checks for NULL pointers and similiar in 
> all C standard functions implemented in u-boot to circumvent tons of 
> possible real world bugs in all callers of strcpy, strlen, mem* and 
> whatever.

If you think a bit about this, you may find it more difficult than you
expect.  Keep in mind that on most systems supported by U-Boot code
like

int *p = (int *)0;

print("*p = %d\n", *p);

is perfectly legal and supposed to work without any problems -
because 0 is a legal address, and it makes perfect senze that commands
like "md" or "cp" can be used to access it.  In the result, strcpy(),
strlen(), mem*() and whatever must beable to work on address 0 likeon
any other address, too.

:-P

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Minds are like parachutes - they only function when open.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Alexander Holler]

Am 24.05.2011 00:22, schrieb Wolfgang Denk:
> Dear Alexander Holler,
>
> In message<4ddadbb6.30...@ahsoftware.de>  you wrote:
>>
>> So you I will look forward to checks for NULL pointers and similiar in
>> all C standard functions implemented in u-boot to circumvent tons of
>> possible real world bugs in all callers of strcpy, strlen, mem* and
>> whatever.
>
> If you think a bit about this, you may find it more difficult than you
> expect.  Keep in mind that on most systems supported by U-Boot code
> like
>
>   int *p = (int *)0;
>
>   print("*p = %d\n", *p);
>
> is perfectly legal and supposed to work without any problems -
> because 0 is a legal address, and it makes perfect senze that commands
> like "md" or "cp" can be used to access it.  In the result, strcpy(),
> strlen(), mem*() and whatever must beable to work on address 0 likeon
> any other address, too.
>
> :-P

I've never seen a valid use of strcpy() with a null-pointer in real 
world programs, which we are talking about, except in bugs.

BTW, you missed to quote my suggestion to get rid of the implementation 
of memcpy() and use always memmove(). That would be really defensive 
programming and if the unnecessary identity-check in memcpy isn't of 
interest, the additional other check done by memmove() shouldn't be a 
problem too.

But I will stop complaining as requested and getting silent again.

Regards,

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

Hi Wolfgang,

On Tue, May 24, 2011 at 7:53 AM, Wolfgang Denk  wrote:
> Dear "J. William Campbell",
>
> In message <4ddac866.1050...@comcast.net> you wrote:
>>
>> > Is there any reason why we cannot silently perform a reset_timer() any time
>> > set_timer() is called with a parameter of 0?
>> Hi All,
>>       I assume you mean get_timer(0)?  In principle, you cannot do this
>> because it could be inside another get_timer(0) loop that has already
>> some time elapsed before you hit the inner get_timer(0). I think what
>> needs to happen on the old NIOS with 10 ms resolution on the interrupt
>> times is that all timer intervals must have 10 ms added and then rounded
>> up to the nearest multiple of 10. Thus, if you wanted to wait for 1
>> millisecond, you must use an argument of 20 ms to be sure you wait at
>> all! If you use an argument of 10, it won't help because you could get
>> an interrupt right away and exit. If these routines are nios2 specific,
>> you could add a local reset_timer, but I assume they are generic. . Note
>> that if these routines are not nios2 specific, is there any harm in
>> waiting "too long"?
>
> I think in the context of this rework get_timer() should be changed to
> take no argumen. Actually noe is needed, and if used as is now it can
> only cuse harm.
>

I think this might break stand alone applications - I am sure get_timer()
is exported. If not, sure, we can remove the argument, but that will be
a huge patch. If we do, we should change it from get_timer() to get_ms()
while we are at it

Regards,

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

Re: [U-Boot] SPI flash and release

[Mike Frysinger]

On Saturday, May 21, 2011 07:25:01 Simon Guinot wrote:
> Do you plan to push your 'sf' branch into the current release ?

i mentioned in one of the threads that i was going to push it after the 
2011.06 release.  the branch/changes were done after the 2011.06 merge window 
closed, so i wasnt comfortable pushing things to Wolfgang before the 2011.06-
rc1 release.

> I am asking because the Network Space v2 support needs commit d4d8b4e.

if it isnt in 2011.06-rc1 already, then i cant see it being suitable for merge 
before 2011.06 final.  so there shouldnt be any issues.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [FIX] cmd_nand: fix help of nand erase subcommand

[Mike Frysinger]

there's no need to specify "[FIX]" in the summary
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] command/cmd_cache.c: Add optional flush arguments

[Mike Frysinger]

On Monday, May 23, 2011 14:38:52 Matthew McClintock wrote:
> There are some checkpatch.pl warnings for formatting issues. In this case
> I choose to keep the same formatting as was used in the file already:

this is fine i think.  otherwise, you'd send another patch to first fix the 
formatting and then base this on top of that.

> +void __flush_icache(void)
> +{
> + /* please define arch specific flush_icache */
> + printf("No arch specific flush_icache available!\n");
> +}
> +void flush_icache(void) __attribute__((weak, alias("__flush_icache")));

i dont see much point in having the indirection.  just do:

void __weak flush_icache(void)
{
/* please define arch specific flush_icache */
puts("No arch specific flush_icache available!\n");
}
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement

[Mike Frysinger]

On Monday, May 23, 2011 11:22:18 Detlev Zundel wrote:
> >>> I believe I have covered this ground very thoroughly and would like
> >> 
> >>> advice please on what to do next. The options I can see are:
> >> As Graeme points out, you got enough positive feedback that I encourage
> >> you to continue and address the comments.
> > 
> > OK, it would be nice to have a note from Wolfgang since without his OK
> > it won't make it in, right?
> 
> Ultimately we are a democratic community, so when you get enough support
> the changes will go in.  Usually we find a consensus acceptable to all
> parties before resorting to such formal measures however.

s/Ultimately/For the most part/

Ultimately, Wolfgang gets final word regardless of anything else.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] .gitignore: update list of u-boot.* files and add *.bin

[Mike Frysinger]

On Sunday, May 22, 2011 17:46:36 Wolfgang Denk wrote:
> Eric Cooper wrote:
> > This patch adds additional u-boot.* files mentioned in Makefile,
> > and adds *.bin since these are deleted as part of "make clean".
> > 
> > Signed-off-by: Eric Cooper 
> > ---
> > Changes since v1:
> > 
> > Added more general *.bin pattern.
> > 
> >  .gitignore |8 +---
> >  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> Applied, thanks.

something seems to have gone wrong here ... `git log` shows:
commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3
Author: ecc 

but his original e-mail From: looks correct, so i dont know why the Author 
field is broken in the git tree ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH][v2] powerpc/85xx: Add NAND boot support for P3041/P5020DS

[Shaohui Xie]

When booting from NAND we get the environment from NAND.

Signed-off-by: Shaohui Xie 
Signed-off-by: Kumar Gala 
---
changes for v2:
move _NAND up to sorted by alpha.

 boards.cfg   |2 ++
 include/configs/corenet_ds.h |   29 +++--
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 9f2b118..f170042 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -572,12 +572,14 @@ P2020RDB_NANDpowerpc mpc85xx 
p1_p2_rdb   freesca
 P2020RDB_SDCARD  powerpc mpc85xx p1_p2_rdb   
freescale  -   P1_P2_RDB:P2020RDB,SDCARD
 P2020RDB_SPIFLASHpowerpc mpc85xx p1_p2_rdb   
freescale  -   P1_P2_RDB:P2020RDB,SPIFLASH
 P3041DS  powerpc mpc85xx corenet_ds  
freescale
+P3041DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P3041DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 P3041DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P3041DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 P3041DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P3041DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 P4080DS  powerpc mpc85xx corenet_ds  
freescale
 P4080DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P4080DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 P4080DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P4080DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 P5020DS  powerpc mpc85xx corenet_ds  
freescale
+P5020DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 P5020DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 P5020DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 mpq101   powerpc mpc85xx mpq101  
mercury-   mpq101
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 9ba032b..2e45b92 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -91,6 +91,11 @@
 #define CONFIG_SYS_MMC_ENV_DEV  0
 #define CONFIG_ENV_SIZE0x2000
 #define CONFIG_ENV_OFFSET  (512 * 1097)
+#elif defined(CONFIG_NAND)
+#define CONFIG_SYS_EXTRA_ENV_RELOC
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_SIZECONFIG_SYS_NAND_BLOCK_SIZE
+#define CONFIG_ENV_OFFSET  (5 * CONFIG_SYS_NAND_BLOCK_SIZE)
 #else
 #define CONFIG_ENV_IS_IN_FLASH
 #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE - 
CONFIG_ENV_SECT_SIZE)
@@ -196,10 +201,10 @@
 #define CONFIG_SYS_FLASH_BASE_PHYS CONFIG_SYS_FLASH_BASE
 #endif
 
-#define CONFIG_SYS_BR0_PRELIM \
-   (BR_PHYS_ADDR((CONFIG_SYS_FLASH_BASE_PHYS + 0x800)) | \
-BR_PS_16 | BR_V)
-#define CONFIG_SYS_OR0_PRELIM  ((0xf8000ff7 & ~OR_GPCM_SCY & ~OR_GPCM_EHTR) \
+#define CONFIG_SYS_FLASH_BR_PRELIM \
+   (BR_PHYS_ADDR((CONFIG_SYS_FLASH_BASE_PHYS + 0x800)) \
+| BR_PS_16 | BR_V)
+#define CONFIG_SYS_FLASH_OR_PRELIM ((0xf8000ff7 & ~OR_GPCM_SCY & 
~OR_GPCM_EHTR) \
| OR_GPCM_SCY_8 | OR_GPCM_EHTR_CLEAR)
 
 #define CONFIG_SYS_BR1_PRELIM \
@@ -268,9 +273,21 @@
   | OR_FCM_TRLX \
   | OR_FCM_EHTR)
 
-#define CONFIG_SYS_BR2_PRELIM  CONFIG_SYS_NAND_BR_PRELIM /* NAND Base Address 
*/
-#define CONFIG_SYS_OR2_PRELIM  CONFIG_SYS_NAND_OR_PRELIM /* NAND Options */
+#ifdef CONFIG_NAND
+#define CONFIG_SYS_BR0_PRELIM  CONFIG_SYS_NAND_BR_PRELIM /* NAND Base Address 
*/
+#define CONFIG_SYS_OR0_PRELIM  CONFIG_SYS_NAND_OR_PRELIM /* NAND Options */
+#define CONFIG_SYS_BR2_PRELIM  CONFIG_SYS_FLASH_BR_PRELIM /* NOR Base Address 
*/
+#define CONFIG_SYS_OR2_PRELIM  CONFIG_SYS_FLASH_OR_PRELIM /* NOR Options */
+#else
+#define CONFIG_SYS_BR0_PRELIM  CONFIG_SYS_FLASH_BR_PRELIM /* NOR Base Address 
*/
+#define CONFIG_SYS_OR0_PRELIM  CONFIG_SYS_FLASH_OR_PRELIM /* NOR Options */
+#define CONFIG_SYS_BR2_PRELIM  CONFIG_SYS_NAND_BR_PRELIM /* NAND Base Address 
*/
+#define CONFIG_SYS_OR2_PRELIM  CONFIG_SYS_NAND_OR_PRELIM /* NAND Options */
+#endif
 #endif /* CONFIG_NAND_FSL_ELBC */
+#else
+#define CONFIG_SYS_BR0_PRELIM  CONFIG_SYS_FLASH_BR_PRELIM /* NOR Base Address 
*/
+#define CONFIG_SYS_OR0_PRELIM  CONFIG_SYS_FLASH_OR_PRELIM /* NOR Options */
 #endif
 
 #define CONFIG_SYS_FLASH_EMPTY_INFO
-- 
1.6.4


___

Re: [U-Boot] [PATCH v2 1/3] disk/part.c: Make features optional

[Mike Frysinger]

On Monday, May 23, 2011 17:49:42 Matthew McClintock wrote:
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -180,7 +180,9 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[]) mmc_dev = mmc_get_dev(curr_device);
>   if (mmc_dev != NULL &&
>   mmc_dev->type != DEV_TYPE_UNKNOWN) {
> +#ifdef CONFIG_PARTITIONS
>   print_part(mmc_dev);
> +#endif

how about adding this logic to the header ?  then print_part() is 
transparently turned into a stub for all users ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] common/cmd_ximg.c: add ifdef protection for gzip uncompression

[Mike Frysinger]

On Monday, May 23, 2011 14:29:13 Matthew McClintock wrote:
> --- a/common/cmd_ximg.c
> +++ b/common/cmd_ximg.c
>   break;
>   case IH_COMP_GZIP:
> +#ifdef CONFIG_GZIP
>   printf ("   Uncompressing part %d ... ", part);
>   if (gunzip ((void *) dest, unc_len,
>   (uchar *) data, &len) != 0) {
>   puts ("GUNZIP ERROR - image not loaded\n");
>   return 1;
>   }
> +#else
> + printf("gzip decompression not supported in this"
> + " build!\n");
> + return 1;
> +#endif

a few things ...
 - dont split string constants
 - if you arent using any formats, then puts() is better
 - the #else isnt even necessary ... wrap the "case" in the #ifdef too, and 
then at runtime this will automatically fall through to the already existing 
default: case
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] common/cmd_nand.c: add ifdef protection for do_bootm

[Mike Frysinger]

On Monday, May 23, 2011 14:29:12 Matthew McClintock wrote:
> Right now we do not check if do_bootm is actually built into this
> u-boot. Instead check define and only call do_bootm if it's actually
> available.

basic idea is sound ...

> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -806,9 +806,11 @@
>   local_args[0] = cmd;
>   local_args[1] = NULL;
> 
> +#ifdef   CONFIG_CMD_BOOTM
>   printf("Automatic boot of image at addr 0x%08lx ...\n", addr);
> 
>   do_bootm(cmdtp, 0, 1, local_args);
> +#endif
>   return 1;
>   }
>   return 0;

there should be a space after the "#ifdef", not a tab.  and the ifdef should 
be around the local_args[] too.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Mike Frysinger]

On Monday, May 23, 2011 18:44:33 Graeme Russ wrote:
> I think this might break stand alone applications - I am sure get_timer()
> is exported.

the export list has a rev associated with it.  see XF_VERSION in 
include/exports.h.  u-boot will detect the mismatch at runtime and bail 
forcing people to rebuild their stand alone apps.  we've done this in the past 
(6 times even!) and no one has complained (at least with any visibility on the 
mailing list).  i dont have a problem with it.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/7] Blackfin: use on-chip reset func with newer parts

[Mike Frysinger]

Turns out the documentation is wrong and doing "RAISE 1" does not result
in a software reset, only a core reset.  So when the on-chip rom has a
functioning reset helper, use it.

Signed-off-by: Mike Frysinger 
---
 arch/blackfin/cpu/reset.c |   70 ++---
 1 files changed, 34 insertions(+), 36 deletions(-)

diff --git a/arch/blackfin/cpu/reset.c b/arch/blackfin/cpu/reset.c
index 9307e9f..e23dcc7 100644
--- a/arch/blackfin/cpu/reset.c
+++ b/arch/blackfin/cpu/reset.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cpu.h"
 
 /* A system soft reset makes external memory unusable so force
@@ -29,46 +30,40 @@ static void bfin_reset(void)
 */
__builtin_bfin_ssync();
 
-   /* The bootrom checks to see how it was reset and will
-* automatically perform a software reset for us when
-* it starts executing after the core reset.
-*/
-   if (ANOMALY_05000353 || ANOMALY_05000386) {
-   /* Initiate System software reset. */
-   bfin_write_SWRST(0x7);
+   /* Initiate System software reset. */
+   bfin_write_SWRST(0x7);
 
-   /* Due to the way reset is handled in the hardware, we need
-* to delay for 10 SCLKS.  The only reliable way to do this is
-* to calculate the CCLK/SCLK ratio and multiply 10.  For now,
-* we'll assume worse case which is a 1:15 ratio.
-*/
-   asm(
-   "LSETUP (1f, 1f) LC0 = %0\n"
-   "1: nop;"
-   :
-   : "a" (15 * 10)
-   : "LC0", "LB0", "LT0"
-   );
+   /* Due to the way reset is handled in the hardware, we need
+* to delay for 10 SCLKS.  The only reliable way to do this is
+* to calculate the CCLK/SCLK ratio and multiply 10.  For now,
+* we'll assume worse case which is a 1:15 ratio.
+*/
+   asm(
+   "LSETUP (1f, 1f) LC0 = %0\n"
+   "1: nop;"
+   :
+   : "a" (15 * 10)
+   : "LC0", "LB0", "LT0"
+   );
 
-   /* Clear System software reset */
-   bfin_write_SWRST(0);
+   /* Clear System software reset */
+   bfin_write_SWRST(0);
 
-   /* The BF526 ROM will crash during reset */
+   /* The BF526 ROM will crash during reset */
 #if defined(__ADSPBF522__) || defined(__ADSPBF524__) || defined(__ADSPBF526__)
-   bfin_read_SWRST();
+   bfin_read_SWRST();
 #endif
 
-   /* Wait for the SWRST write to complete.  Cannot rely on SSYNC
-* though as the System state is all reset now.
-*/
-   asm(
-   "LSETUP (1f, 1f) LC1 = %0\n"
-   "1: nop;"
-   :
-   : "a" (15 * 1)
-   : "LC1", "LB1", "LT1"
-   );
-   }
+   /* Wait for the SWRST write to complete.  Cannot rely on SSYNC
+* though as the System state is all reset now.
+*/
+   asm(
+   "LSETUP (1f, 1f) LC1 = %0\n"
+   "1: nop;"
+   :
+   : "a" (15 * 1)
+   : "LC1", "LB1", "LT1"
+   );
 
while (1)
/* Issue core reset */
@@ -84,7 +79,10 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 {
if (board_reset)
board_reset();
-   while (1)
-   asm("jump (%0);" : : "a" (bfin_reset));
+   if (ANOMALY_05000353 || ANOMALY_05000386)
+   while (1)
+   asm("jump (%0);" : : "a" (bfin_reset));
+   else
+   bfrom_SoftReset((void *)(L1_SRAM_SCRATCH_END - 20));
return 0;
 }
-- 
1.7.5.rc3

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

[U-Boot] [PATCH 1/7] Blackfin: use common LDSCRIPT logic

[Mike Frysinger]

Now that common code is a bit smarter when it comes to default LDSCRIPT
values, rename the default Blackfin file and drop the Blackfin-specific
config.mk logic.

Signed-off-by: Mike Frysinger 
---
 arch/blackfin/config.mk|4 
 arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} |0
 2 files changed, 0 insertions(+), 4 deletions(-)
 rename arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} (100%)

diff --git a/arch/blackfin/config.mk b/arch/blackfin/config.mk
index f0909e9..71fd53f 100644
--- a/arch/blackfin/config.mk
+++ b/arch/blackfin/config.mk
@@ -76,10 +76,6 @@ LDR_FLAGS += $(LDR_FLAGS-y)
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS += $(LDR_FLAGS-$(CONFIG_BFIN_BOOT_MODE))
 
-ifeq ($(wildcard $(TOPDIR)/board/$(BOARD)/u-boot.lds*),)
-LDSCRIPT = $(obj)arch/$(ARCH)/lib/u-boot.lds.S
-endif
-
 ifneq ($(CONFIG_SYS_TEXT_BASE),)
 $(error do not set CONFIG_SYS_TEXT_BASE for Blackfin boards)
 endif
diff --git a/arch/blackfin/lib/u-boot.lds.S b/arch/blackfin/cpu/u-boot.lds
similarity index 100%
rename from arch/blackfin/lib/u-boot.lds.S
rename to arch/blackfin/cpu/u-boot.lds
-- 
1.7.5.rc3

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

[U-Boot] [PATCH 6/7] Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support

[Mike Frysinger]

From: Harald Krapfenbauer 

These boards have an mmc/sd slot on them connected over SPI, so
enable the driver.

Signed-off-by: Harald Krapfenbauer 
Signed-off-by: Mike Frysinger 
---
 include/configs/cm-bf537e.h |   17 -
 include/configs/cm-bf537u.h |   16 +++-
 include/configs/tcm-bf537.h |   16 +++-
 3 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/include/configs/cm-bf537e.h b/include/configs/cm-bf537e.h
index 4eff9c9..7040567 100644
--- a/include/configs/cm-bf537e.h
+++ b/include/configs/cm-bf537e.h
@@ -55,7 +55,7 @@
 #define CONFIG_EBIU_AMBCTL0_VAL(B1WAT_7 | B1RAT_11 | B1HT_2 | B1ST_3 | 
B0WAT_7 | B0RAT_11 | B0HT_2 | B0ST_3)
 #define CONFIG_EBIU_AMBCTL1_VAL(B3WAT_7 | B3RAT_11 | B3HT_2 | B3ST_3 | 
B2WAT_7 | B2RAT_11 | B2HT_2 | B2ST_3)
 
-#define CONFIG_SYS_MONITOR_LEN (256 * 1024)
+#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
 #define CONFIG_SYS_MALLOC_LEN  (128 * 1024)
 
 
@@ -89,6 +89,13 @@
 
 
 /*
+ * SPI Settings
+ */
+#define CONFIG_BFIN_SPI
+#define CONFIG_ENV_SPI_MAX_HZ  3000
+
+
+/*
  * Env Storage Settings
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
@@ -122,6 +129,14 @@
 
 
 /*
+ * SPI_MMC Settings
+ */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC_SPI
+
+
+/*
  * Misc Settings
  */
 #define CONFIG_BAUDRATE115200
diff --git a/include/configs/cm-bf537u.h b/include/configs/cm-bf537u.h
index ccb3b47..5dca810 100644
--- a/include/configs/cm-bf537u.h
+++ b/include/configs/cm-bf537u.h
@@ -54,7 +54,7 @@
 #define CONFIG_EBIU_AMBCTL0_VAL(B1WAT_7 | B1RAT_11 | B1HT_2 | B1ST_3 | 
B0WAT_7 | B0RAT_11 | B0HT_2 | B0ST_3)
 #define CONFIG_EBIU_AMBCTL1_VAL(B3WAT_7 | B3RAT_11 | B3HT_2 | B3ST_3 | 
B2WAT_7 | B2RAT_11 | B2HT_2 | B2ST_3)
 
-#define CONFIG_SYS_MONITOR_LEN (256 * 1024)
+#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
 #define CONFIG_SYS_MALLOC_LEN  (128 * 1024)
 
 
@@ -87,6 +87,13 @@
 
 
 /*
+ * SPI Settings
+ */
+#define CONFIG_BFIN_SPI
+#define CONFIG_ENV_SPI_MAX_HZ  3000
+
+
+/*
  * Env Storage Settings
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
@@ -120,6 +127,13 @@
 
 
 /*
+ * SPI_MMC Settings
+ */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC_SPI
+
+/*
  * Misc Settings
  */
 #define CONFIG_BAUDRATE115200
diff --git a/include/configs/tcm-bf537.h b/include/configs/tcm-bf537.h
index 0807589..dc16f2e 100644
--- a/include/configs/tcm-bf537.h
+++ b/include/configs/tcm-bf537.h
@@ -55,7 +55,7 @@
 #define CONFIG_EBIU_AMBCTL0_VAL(B1WAT_7 | B1RAT_11 | B1HT_2 | B1ST_3 | 
B0WAT_7 | B0RAT_11 | B0HT_2 | B0ST_3)
 #define CONFIG_EBIU_AMBCTL1_VAL(B3WAT_7 | B3RAT_11 | B3HT_2 | B3ST_3 | 
B2WAT_7 | B2RAT_11 | B2HT_2 | B2ST_3)
 
-#define CONFIG_SYS_MONITOR_LEN (256 * 1024)
+#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
 #define CONFIG_SYS_MALLOC_LEN  (128 * 1024)
 
 
@@ -89,6 +89,13 @@
 
 
 /*
+ * SPI Settings
+ */
+#define CONFIG_BFIN_SPI
+#define CONFIG_ENV_SPI_MAX_HZ  3000
+
+
+/*
  * Env Storage Settings
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
@@ -122,6 +129,13 @@
 
 
 /*
+ * SPI_MMC Settings
+ */
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC_SPI
+
+/*
  * Misc Settings
  */
 #define CONFIG_BAUDRATE115200
-- 
1.7.5.rc3

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

[U-Boot] [PATCH 5/7] Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings

[Mike Frysinger]

From: Harald Krapfenbauer 

These boards can have an addon card plugged onto them, so enable
support for it.

Signed-off-by: Harald Krapfenbauer 
Signed-off-by: Mike Frysinger 
---
 board/cm-bf537e/cm-bf537e.c |   34 ++
 board/cm-bf537u/cm-bf537u.c |   39 +--
 board/tcm-bf537/tcm-bf537.c |   34 ++
 include/configs/cm-bf537e.h |3 +++
 include/configs/cm-bf537u.h |8 
 include/configs/tcm-bf537.h |4 +++-
 6 files changed, 75 insertions(+), 47 deletions(-)

diff --git a/board/cm-bf537e/cm-bf537e.c b/board/cm-bf537e/cm-bf537e.c
index 1e350dc..38dbc6e 100644
--- a/board/cm-bf537e/cm-bf537e.c
+++ b/board/cm-bf537e/cm-bf537e.c
@@ -24,27 +24,37 @@ int checkboard(void)
return 0;
 }
 
-#ifdef CONFIG_BFIN_MAC
-static void board_init_enetaddr(uchar *mac_addr)
+static void board_init_enetaddr(char *var)
 {
-   puts("Warning: Generating 'random' MAC address\n");
-   bfin_gen_rand_mac(mac_addr);
-   eth_setenv_enetaddr("ethaddr", mac_addr);
+#ifdef CONFIG_NET_MULTI
+   uchar enetaddr[6];
+
+   if (eth_getenv_enetaddr(var, enetaddr))
+   return;
+
+   printf("Warning: %s: generating 'random' MAC address\n", var);
+   bfin_gen_rand_mac(enetaddr);
+   eth_setenv_enetaddr(var, enetaddr);
+#endif
 }
 
+#ifndef CONFIG_BFIN_MAC
+# define bfin_EMAC_initialize(x) 1
+#endif
+#ifndef CONFIG_SMC911X
+# define smc911x_initialize(n, x) 1
+#endif
 int board_eth_init(bd_t *bis)
 {
-   return bfin_EMAC_initialize(bis);
+   /* return ok if at least 1 eth device works */
+   return bfin_EMAC_initialize(bis) &
+  smc911x_initialize(0, CONFIG_SMC911X_BASE);
 }
-#endif
 
 int misc_init_r(void)
 {
-#ifdef CONFIG_BFIN_MAC
-   uchar enetaddr[6];
-   if (!eth_getenv_enetaddr("ethaddr", enetaddr))
-   board_init_enetaddr(enetaddr);
-#endif
+   board_init_enetaddr("ethaddr");
+   board_init_enetaddr("eth1addr");
 
gpio_cfi_flash_init();
 
diff --git a/board/cm-bf537u/cm-bf537u.c b/board/cm-bf537u/cm-bf537u.c
index 4b7e864..a62ddd6 100644
--- a/board/cm-bf537u/cm-bf537u.c
+++ b/board/cm-bf537u/cm-bf537u.c
@@ -24,34 +24,37 @@ int checkboard(void)
return 0;
 }
 
-#ifdef CONFIG_BFIN_MAC
-static void board_init_enetaddr(uchar *mac_addr)
+static void board_init_enetaddr(char *var)
 {
-   puts("Warning: Generating 'random' MAC address\n");
-   bfin_gen_rand_mac(mac_addr);
-   eth_setenv_enetaddr("ethaddr", mac_addr);
-}
+#ifdef CONFIG_NET_MULTI
+   uchar enetaddr[6];
 
-int board_eth_init(bd_t *bis)
-{
-   return bfin_EMAC_initialize(bis);
-}
+   if (eth_getenv_enetaddr(var, enetaddr))
+   return;
+
+   printf("Warning: %s: generating 'random' MAC address\n", var);
+   bfin_gen_rand_mac(enetaddr);
+   eth_setenv_enetaddr(var, enetaddr);
 #endif
+}
 
-#ifdef CONFIG_SMC911X
+#ifndef CONFIG_BFIN_MAC
+# define bfin_EMAC_initialize(x) 1
+#endif
+#ifndef CONFIG_SMC911X
+# define smc911x_initialize(n, x) 1
+#endif
 int board_eth_init(bd_t *bis)
 {
-   return smc911x_initialize(0, CONFIG_SMC911X_BASE);
+   /* return ok if at least 1 eth device works */
+   return bfin_EMAC_initialize(bis) &
+  smc911x_initialize(0, CONFIG_SMC911X_BASE);
 }
-#endif
 
 int misc_init_r(void)
 {
-#ifdef CONFIG_BFIN_MAC
-   uchar enetaddr[6];
-   if (!eth_getenv_enetaddr("ethaddr", enetaddr))
-   board_init_enetaddr(enetaddr);
-#endif
+   board_init_enetaddr("ethaddr");
+   board_init_enetaddr("eth1addr");
 
gpio_cfi_flash_init();
 
diff --git a/board/tcm-bf537/tcm-bf537.c b/board/tcm-bf537/tcm-bf537.c
index 04d6bdb..004e0d9 100644
--- a/board/tcm-bf537/tcm-bf537.c
+++ b/board/tcm-bf537/tcm-bf537.c
@@ -24,27 +24,37 @@ int checkboard(void)
return 0;
 }
 
-#ifdef CONFIG_BFIN_MAC
-static void board_init_enetaddr(uchar *mac_addr)
+static void board_init_enetaddr(char *var)
 {
-   puts("Warning: Generating 'random' MAC address\n");
-   bfin_gen_rand_mac(mac_addr);
-   eth_setenv_enetaddr("ethaddr", mac_addr);
+#ifdef CONFIG_NET_MULTI
+   uchar enetaddr[6];
+
+   if (eth_getenv_enetaddr(var, enetaddr))
+   return;
+
+   printf("Warning: %s: generating 'random' MAC address\n", var);
+   bfin_gen_rand_mac(enetaddr);
+   eth_setenv_enetaddr(var, enetaddr);
+#endif
 }
 
+#ifndef CONFIG_BFIN_MAC
+# define bfin_EMAC_initialize(x) 1
+#endif
+#ifndef CONFIG_SMC911X
+# define smc911x_initialize(n, x) 1
+#endif
 int board_eth_init(bd_t *bis)
 {
-   return bfin_EMAC_initialize(bis);
+   /* return ok if at least 1 eth device works */
+   return bfin_EMAC_initialize(bis) &
+  smc911x_initialize(0, CONFIG_SMC911X_BASE);
 }
-#endif
 
 int misc_init_r(void)
 {
-#ifdef CONFIG_BFIN_MAC
-   uchar enetaddr[6];
-   if (!eth_getenv_enetaddr("ethaddr", enetaddr))
-   board_init_

[U-Boot] [PATCH 0/7] Blackfin fixes for 2011.06

[Mike Frysinger]

Mostly a few simple fixes noticed after the 2011.06 merge window, or due
to patches merged in that period.

Harald Krapfenbauer (3):
  Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings
  Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support
  Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings

Mike Frysinger (4):
  Blackfin: use common LDSCRIPT logic
  Blackfin: use on-chip reset func with newer parts
  Blackfin: bf548-ezkit/bf561-ezkit: update env location
  Blackfin: boards: build zlib dir with -O2

 arch/blackfin/config.mk|4 -
 arch/blackfin/cpu/reset.c  |   70 ++--
 arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} |0
 board/bct-brettl2/config.mk|1 +
 board/bf518f-ezbrd/config.mk   |1 +
 board/bf526-ezbrd/config.mk|1 +
 board/bf527-ad7160-eval/config.mk  |1 +
 board/bf527-ezkit/config.mk|1 +
 board/bf527-sdp/config.mk  |1 +
 board/bf533-ezkit/config.mk|1 +
 board/bf533-stamp/config.mk|1 +
 board/bf537-stamp/config.mk|1 +
 board/bf538f-ezkit/config.mk   |1 +
 board/bf548-ezkit/config.mk|1 +
 board/bf561-acvilon/config.mk  |1 +
 board/bf561-ezkit/config.mk|1 +
 board/cm-bf527/config.mk   |1 +
 board/cm-bf533/config.mk   |1 +
 board/cm-bf537e/cm-bf537e.c|   34 ++
 board/cm-bf537e/config.mk  |1 +
 board/cm-bf537u/cm-bf537u.c|   39 ++-
 board/cm-bf537u/config.mk  |1 +
 board/cm-bf548/config.mk   |1 +
 board/cm-bf561/config.mk   |1 +
 board/ip04/config.mk   |1 +
 board/tcm-bf518/config.mk  |1 +
 board/tcm-bf537/config.mk  |1 +
 board/tcm-bf537/tcm-bf537.c|   34 ++
 include/configs/bf548-ezkit.h  |   10 ++--
 include/configs/bf561-ezkit.h  |   23 +--
 include/configs/cm-bf537e.h|   31 +++--
 include/configs/cm-bf537u.h|   35 +++---
 include/configs/tcm-bf537.h|   31 +++--
 33 files changed, 200 insertions(+), 133 deletions(-)
 rename arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} (100%)

-- 
1.7.5.rc3

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

[U-Boot] [PATCH 4/7] Blackfin: boards: build zlib dir with -O2

[Mike Frysinger]

Now that the zlib code has been relocated to a dedicated subdir, make
sure we still build it with -O2 for boards that want speed over size.

Signed-off-by: Mike Frysinger 
---
 board/bct-brettl2/config.mk   |1 +
 board/bf518f-ezbrd/config.mk  |1 +
 board/bf526-ezbrd/config.mk   |1 +
 board/bf527-ad7160-eval/config.mk |1 +
 board/bf527-ezkit/config.mk   |1 +
 board/bf527-sdp/config.mk |1 +
 board/bf533-ezkit/config.mk   |1 +
 board/bf533-stamp/config.mk   |1 +
 board/bf537-stamp/config.mk   |1 +
 board/bf538f-ezkit/config.mk  |1 +
 board/bf548-ezkit/config.mk   |1 +
 board/bf561-acvilon/config.mk |1 +
 board/bf561-ezkit/config.mk   |1 +
 board/cm-bf527/config.mk  |1 +
 board/cm-bf533/config.mk  |1 +
 board/cm-bf537e/config.mk |1 +
 board/cm-bf537u/config.mk |1 +
 board/cm-bf548/config.mk  |1 +
 board/cm-bf561/config.mk  |1 +
 board/ip04/config.mk  |1 +
 board/tcm-bf518/config.mk |1 +
 board/tcm-bf537/config.mk |1 +
 22 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/board/bct-brettl2/config.mk b/board/bct-brettl2/config.mk
index 799a682..b3ed337 100644
--- a/board/bct-brettl2/config.mk
+++ b/board/bct-brettl2/config.mk
@@ -25,3 +25,4 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
diff --git a/board/bf518f-ezbrd/config.mk b/board/bf518f-ezbrd/config.mk
index 799a682..b3ed337 100644
--- a/board/bf518f-ezbrd/config.mk
+++ b/board/bf518f-ezbrd/config.mk
@@ -25,3 +25,4 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
diff --git a/board/bf526-ezbrd/config.mk b/board/bf526-ezbrd/config.mk
index 799a682..b3ed337 100644
--- a/board/bf526-ezbrd/config.mk
+++ b/board/bf526-ezbrd/config.mk
@@ -25,3 +25,4 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
diff --git a/board/bf527-ad7160-eval/config.mk 
b/board/bf527-ad7160-eval/config.mk
index 799a682..b3ed337 100644
--- a/board/bf527-ad7160-eval/config.mk
+++ b/board/bf527-ad7160-eval/config.mk
@@ -25,3 +25,4 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
diff --git a/board/bf527-ezkit/config.mk b/board/bf527-ezkit/config.mk
index 799a682..b3ed337 100644
--- a/board/bf527-ezkit/config.mk
+++ b/board/bf527-ezkit/config.mk
@@ -25,3 +25,4 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
diff --git a/board/bf527-sdp/config.mk b/board/bf527-sdp/config.mk
index 7271774..beb4651 100644
--- a/board/bf527-sdp/config.mk
+++ b/board/bf527-sdp/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA := --bits 16 --dma 6
diff --git a/board/bf533-ezkit/config.mk b/board/bf533-ezkit/config.mk
index c0cb9ff..7d1fc44 100644
--- a/board/bf533-ezkit/config.mk
+++ b/board/bf533-ezkit/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA := --bits 16 --dma 8
diff --git a/board/bf533-stamp/config.mk b/board/bf533-stamp/config.mk
index c0cb9ff..7d1fc44 100644
--- a/board/bf533-stamp/config.mk
+++ b/board/bf533-stamp/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA := --bits 16 --dma 8
diff --git a/board/bf537-stamp/config.mk b/board/bf537-stamp/config.mk
index 7c023d1..0adae73 100644
--- a/board/bf537-stamp/config.mk
+++ b/board/bf537-stamp/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA := --bits 16 --dma 8
diff --git a/board/bf538f-ezkit/config.mk b/board/bf538f-ezkit/config.mk
index c0cb9ff..7d1fc44 100644
--- a/board/bf538f-ezkit/config.mk
+++ b/board/bf538f-ezkit/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA := --bits 16 --dma 8
diff --git a/board/bf548-ezkit/config.mk b/board/bf548-ezkit/config.mk
index 7f38b14..ab3ff14 100644
--- a/board/bf548-ezkit/config.mk
+++ b/board/bf548-ezkit/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA   := --dma 6
diff --git a/board/bf561-acvilon/config.mk b/board/bf561-acvilon/config.mk
index 4c811ba..4d6184e 100644
--- a/board/bf561-acvilon/config.mk
+++ b/board/bf561-acvilon/config.mk
@@ -25,6 +25,7 @@
 
 CFLAGS_lib += -O2
 CFLAGS_lib/lzma += -O2
+CFLAGS_lib/zlib += -O2
 
 # Set some default LDR flags based on boot mode.
 LDR_FLAGS-BFIN_BOOT_PARA := --bits 16
diff --git a/boa

[U-Boot] [PATCH 3/7] Blackfin: bf548-ezkit/bf561-ezkit: update env location

[Mike Frysinger]

Relocate the env to one of the small end sectors to avoid issues with
embedding it, such as support being broken (by recent commit ea882baf9c1),
and for taking a while to save updates.

Signed-off-by: Mike Frysinger 
---
 include/configs/bf548-ezkit.h |   10 +-
 include/configs/bf561-ezkit.h |   23 +++
 2 files changed, 8 insertions(+), 25 deletions(-)

diff --git a/include/configs/bf548-ezkit.h b/include/configs/bf548-ezkit.h
index 4d7d877..3550fd3 100644
--- a/include/configs/bf548-ezkit.h
+++ b/include/configs/bf548-ezkit.h
@@ -113,12 +113,12 @@
 #define CONFIG_ENV_OFFSET  0x6
 #define CONFIG_ENV_SIZE0x2
 #else
+/* The BF548-EZKIT uses a top boot flash */
 #define CONFIG_ENV_IS_IN_FLASH 1
-#define CONFIG_ENV_ADDR0x20002000
-#define CONFIG_ENV_OFFSET  0x2000
-#define CONFIG_ENV_SIZE0x2000
-#define CONFIG_ENV_SECT_SIZE   (128 * 1024)
-#define CONFIG_ENV_IS_EMBEDDED_IN_LDR
+#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
CONFIG_ENV_OFFSET)
+#define CONFIG_ENV_OFFSET  (0x100 - CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_SIZECONFIG_ENV_SECT_SIZE
+#define CONFIG_ENV_SECT_SIZE   0x8000
 #endif
 
 
diff --git a/include/configs/bf561-ezkit.h b/include/configs/bf561-ezkit.h
index 33c7e18..6cfc19b 100644
--- a/include/configs/bf561-ezkit.h
+++ b/include/configs/bf561-ezkit.h
@@ -80,27 +80,10 @@
 #define CONFIG_SYS_MAX_FLASH_SECT  135
 /* The BF561-EZKIT uses a top boot flash */
 #define CONFIG_ENV_IS_IN_FLASH 1
-#define CONFIG_ENV_OFFSET  0x4000
+#define CONFIG_ENV_OFFSET  (0x80 - CONFIG_ENV_SECT_SIZE)
 #define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
CONFIG_ENV_OFFSET)
-#define CONFIG_ENV_SIZE0x2000
-#define CONFIG_ENV_SECT_SIZE   0x1
-#if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS)
-#define ENV_IS_EMBEDDED
-#else
-#define CONFIG_ENV_IS_EMBEDDED_IN_LDR
-#endif
-#ifdef ENV_IS_EMBEDDED
-/* WARNING - the following is hand-optimized to fit within
- * the sector before the environment sector. If it throws
- * an error during compilation remove an object here to get
- * it linked after the configuration sector.
- */
-# define LDS_BOARD_TEXT \
-   arch/blackfin/lib/libblackfin.o (.text*); \
-   arch/blackfin/cpu/libblackfin.o (.text*); \
-   . = DEFINED(env_offset) ? env_offset : .; \
-   common/env_embedded.o (.text*);
-#endif
+#define CONFIG_ENV_SIZECONFIG_ENV_SECT_SIZE
+#define CONFIG_ENV_SECT_SIZE   0x2000
 
 
 /*
-- 
1.7.5.rc3

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

[U-Boot] [PATCH 7/7] Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings

[Mike Frysinger]

From: Harald Krapfenbauer 

The recent commit ea882baf9c1 broke embedding environments in the middle
of a sector, so relocate it to the start of the 2nd sector.

Signed-off-by: Harald Krapfenbauer 
Signed-off-by: Mike Frysinger 
---
 include/configs/cm-bf537e.h |   11 +--
 include/configs/cm-bf537u.h |   11 +--
 include/configs/tcm-bf537.h |   11 +--
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/include/configs/cm-bf537e.h b/include/configs/cm-bf537e.h
index 7040567..9649e18 100644
--- a/include/configs/cm-bf537e.h
+++ b/include/configs/cm-bf537e.h
@@ -99,13 +99,12 @@
  * Env Storage Settings
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
-#define CONFIG_ENV_OFFSET  0x4000
-#define CONFIG_ENV_SIZE0x2000
-#define CONFIG_ENV_SECT_SIZE   0x2
+#define CONFIG_ENV_OFFSET  0x8000
+#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
CONFIG_ENV_OFFSET)
+#define CONFIG_ENV_SIZECONFIG_ENV_SECT_SIZE
+#define CONFIG_ENV_SECT_SIZE   0x8000
 #if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS)
 #define ENV_IS_EMBEDDED
-#else
-#define CONFIG_ENV_IS_EMBEDDED_IN_LDR
 #endif
 #ifdef ENV_IS_EMBEDDED
 /* WARNING - the following is hand-optimized to fit within
@@ -145,7 +144,7 @@
 #define CONFIG_UART_CONSOLE0
 #define CONFIG_BOOTCOMMAND "run flashboot"
 #define FLASHBOOT_ENV_SETTINGS \
-   "flashboot=flread 2004 100 30;" \
+   "flashboot=flread 2004 100 3c;" \
"bootm 0x100\0"
 
 
diff --git a/include/configs/cm-bf537u.h b/include/configs/cm-bf537u.h
index 5dca810..84846ef 100644
--- a/include/configs/cm-bf537u.h
+++ b/include/configs/cm-bf537u.h
@@ -97,13 +97,12 @@
  * Env Storage Settings
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
-#define CONFIG_ENV_OFFSET  0x4000
-#define CONFIG_ENV_SIZE0x2000
-#define CONFIG_ENV_SECT_SIZE   0x2
+#define CONFIG_ENV_OFFSET  0x8000
+#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
CONFIG_ENV_OFFSET)
+#define CONFIG_ENV_SIZECONFIG_ENV_SECT_SIZE
+#define CONFIG_ENV_SECT_SIZE   0x8000
 #if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS)
 #define ENV_IS_EMBEDDED
-#else
-#define CONFIG_ENV_IS_EMBEDDED_IN_LDR
 #endif
 #ifdef ENV_IS_EMBEDDED
 /* WARNING - the following is hand-optimized to fit within
@@ -142,7 +141,7 @@
 #define CONFIG_UART_CONSOLE0
 #define CONFIG_BOOTCOMMAND "run flashboot"
 #define FLASHBOOT_ENV_SETTINGS \
-   "flashboot=flread 2004 100 28;" \
+   "flashboot=flread 2004 100 30;" \
"bootm 0x100\0"
 
 
diff --git a/include/configs/tcm-bf537.h b/include/configs/tcm-bf537.h
index dc16f2e..2375fc5 100644
--- a/include/configs/tcm-bf537.h
+++ b/include/configs/tcm-bf537.h
@@ -99,13 +99,12 @@
  * Env Storage Settings
  */
 #define CONFIG_ENV_IS_IN_FLASH 1
-#define CONFIG_ENV_OFFSET  0x4000
-#define CONFIG_ENV_SIZE0x2000
-#define CONFIG_ENV_SECT_SIZE   0x2
+#define CONFIG_ENV_OFFSET  0x8000
+#define CONFIG_ENV_SIZE0x8000
+#define CONFIG_ENV_SECT_SIZE   0x8000
+#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
CONFIG_ENV_OFFSET)
 #if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS)
 #define ENV_IS_EMBEDDED
-#else
-#define CONFIG_ENV_IS_EMBEDDED_IN_LDR
 #endif
 #ifdef ENV_IS_EMBEDDED
 /* WARNING - the following is hand-optimized to fit within
@@ -144,7 +143,7 @@
 #define CONFIG_UART_CONSOLE0
 #define CONFIG_BOOTCOMMAND "run flashboot"
 #define FLASHBOOT_ENV_SETTINGS \
-   "flashboot=flread 2004 100 28;" \
+   "flashboot=flread 2004 100 30;" \
"bootm 0x100\0"
 
 
-- 
1.7.5.rc3

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

[U-Boot] Pull request u-boot-blackfin.git

[Mike Frysinger]

The following changes since commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3:

  .gitignore: update list of u-boot.* files and add *.bin (2011-05-22 23:46:26 
+0200)

are available in the git repository at:
  git://www.denx.de/git/u-boot-blackfin.git master

Harald Krapfenbauer (3):
  Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings
  Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support
  Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings

Mike Frysinger (4):
  Blackfin: use common LDSCRIPT logic
  Blackfin: use on-chip reset func with newer parts
  Blackfin: bf548-ezkit/bf561-ezkit: update env location
  Blackfin: boards: build zlib dir with -O2

 arch/blackfin/config.mk|4 -
 arch/blackfin/cpu/reset.c  |   70 ++--
 arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} |0
 board/bct-brettl2/config.mk|1 +
 board/bf518f-ezbrd/config.mk   |1 +
 board/bf526-ezbrd/config.mk|1 +
 board/bf527-ad7160-eval/config.mk  |1 +
 board/bf527-ezkit/config.mk|1 +
 board/bf527-sdp/config.mk  |1 +
 board/bf533-ezkit/config.mk|1 +
 board/bf533-stamp/config.mk|1 +
 board/bf537-stamp/config.mk|1 +
 board/bf538f-ezkit/config.mk   |1 +
 board/bf548-ezkit/config.mk|1 +
 board/bf561-acvilon/config.mk  |1 +
 board/bf561-ezkit/config.mk|1 +
 board/cm-bf527/config.mk   |1 +
 board/cm-bf533/config.mk   |1 +
 board/cm-bf537e/cm-bf537e.c|   34 ++
 board/cm-bf537e/config.mk  |1 +
 board/cm-bf537u/cm-bf537u.c|   39 ++-
 board/cm-bf537u/config.mk  |1 +
 board/cm-bf548/config.mk   |1 +
 board/cm-bf561/config.mk   |1 +
 board/ip04/config.mk   |1 +
 board/tcm-bf518/config.mk  |1 +
 board/tcm-bf537/config.mk  |1 +
 board/tcm-bf537/tcm-bf537.c|   34 ++
 include/configs/bf548-ezkit.h  |   10 ++--
 include/configs/bf561-ezkit.h  |   23 +--
 include/configs/cm-bf537e.h|   31 +++--
 include/configs/cm-bf537u.h|   35 +++---
 include/configs/tcm-bf537.h|   31 +++--
 33 files changed, 200 insertions(+), 133 deletions(-)
 rename arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} (100%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Mike Frysinger]

On Saturday, May 21, 2011 08:38:29 Graeme Russ wrote:
> NOTE: http://lists.denx.de/pipermail/u-boot/2010-June/073024.html appears
> to imply the following implementation of get_timer() is wrong:
> 
>   ulong get_timer(ulong base)
>   {
>   return get_timer_masked() - base;
>   }

while this specific code might be wrong due to assumed timer rollover 
behavior, i think the code is wrong to ignore "base" completely.  but maybe it 
doesnt matter after we rewrite things :).

> blackfin
>  - Provides a 64-bit get_ticks() which simply returns 32-bit get_timer(0)

seems to me that most arches do this

>  - get_usec_timer_64() could offer a longer period (584942 years!)

if the hardware can support that large of a timer ...

otherwise, i'd love to see the whole timer API reduced to just get_timer() and 
a proper doc/README.timer written.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Mike Frysinger]

On Monday, May 23, 2011 18:38:49 Alexander Holler wrote:
> Am 24.05.2011 00:22, schrieb Wolfgang Denk:
> > Alexander Holler wrote:
> >> So you I will look forward to checks for NULL pointers and similiar in
> >> all C standard functions implemented in u-boot to circumvent tons of
> >> possible real world bugs in all callers of strcpy, strlen, mem* and
> >> whatever.
> > 
> > If you think a bit about this, you may find it more difficult than you
> > expect.  Keep in mind that on most systems supported by U-Boot code
> > like
> > 
> > int *p = (int *)0;
> > 
> > print("*p = %d\n", *p);
> > 
> > is perfectly legal and supposed to work without any problems -
> > because 0 is a legal address, and it makes perfect senze that commands
> > like "md" or "cp" can be used to access it.  In the result, strcpy(),
> > strlen(), mem*() and whatever must beable to work on address 0 likeon
> > any other address, too.
> 
> I've never seen a valid use of strcpy() with a null-pointer in real
> world programs, which we are talking about, except in bugs.

i'm lazy and type "0" all the time for loading files, copying memory, 
displaying things, etc... in u-boot.  i dont feel like retraining my finger 
muscle memory if i dont have to ;).
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

Hi All,

OK, here goes - A much more in-depth generic analysis for a timer API

I hope this highlights why the current discussion thread has ended
up where is has

Regards,

Graeme

Definitions:
 'register' - A storage element - Can be:
   - A dedicated CPU register
   - A location in memory (as defined by a C variable for example)
   - A memory mapped storage location
   - A port-mapped storage location
   - etc

 'platform' - A complete hardware configuration which is capable of
   running U-Boot. An operation performed by 'the plaform' (such as
   incrementing a counter) is assumed to occur without software
   intervention (although initial setup and configuration may be
   required)

 'fixed' - Same across all platforms

 'constant' - Does not change between any two pre-determined events. For
   example 'between power up and power down', 'after being configured to
   the next time it is configured'

 'tick' - A constant period of time - The tick period is not fixed (see
   'fixed' above)

 'counter' - A register which increments by 1 in response to a given
   stimulus (an interupt, a programmed clock, a user pressing a button,
   a character recieved on a serial port etc)

 'tick counter' - A register which is incremented every tick (typically
   by the platform)

 'timer' - A register which stores a value representing a number of
   fixed time intervals (1ms unless otherwise noted)

 'ISR' - Interrupt Service Routine - A function which is called by the CPU
   in response to an interrupt

 'interrupt' - A asynchronous signal which causes the CPU to suspent the
   current flow of program execution and execute an ISR - Upon completion
   of the ISR, control is returned to the suspended program flow

Assumptions:
 - Every platform has a tick counter
 - Not all platforms support interrupts
 - The size of the tick counter is not fixed

Mandatory Platform Requirements:
 - A tick counter MUST exist
 - ticks MUST occur at least once every one millisecond
 - A means of reading the tick counter register MUST be provided
 - A means of obtaining the tick frequency MUST be provided
 - The tick counter MUST be unsigned
 - The tick counter MUST use the entire range of the tick counter register
   (i.e. from 'All 0's' to 'All 1's')
 - The tick counter MUST overflow from "all 1's" to "all 0's"

Goal:
 - Maintain a 1ms time base which can be obtained via a simple call to
   get_timer()
 - The timer MUST use the entire range of it's register (i.e. from
   'All 0's' to 'All 1's')
 - The timer MUST overflow from "all 1's" to "all 0's"
 - Reduce the amount of code duplication between platforms

So what do we need in order to implement a good[1] timer API?
 1. A tick counter
 2. If #1 does not have a period of 1ms, a prescaler to convert
the tick counter to a 1ms timer
 3. If #2 is a software implementation, a way of regularly calling
the prescaler

Lets look at each of these in detail:

The tick counter

There are a wide variety of implementations which can be divided into two
categories:
 Hardware Counters:
 - A non-programmable read-only hardware counter. An example is a simple
   hardware counter that is tick'd by the CPU clock starting at zero when
   the platform is powered-up
 - A non-programmable read-only hardware counter that can be reset to zero
   by writting to a control register
 - A non-programmable hardware counter which can be reset to any arbitrary
   value
 - A programmable hardware counter - Examples include:
   - A prescaler which increments the counter every 'x' CPU clocks where
 'x' is set programatically by writing to reserved control registers
   - A programmable clock source independent of the CPU clock

 Software Counters:
 - Implemented in U-Boot software (C or assembler)
 - Must be regularly triggered (usually by an interrupt)
 - Interrupt period can be programmable (arch/x86/cpu/sc520 has a good
   example) or non-programmable

If the period of the hardware counter or the interrupt generator can be
programmed to 1ms (or is fixed at 1ms) then there is no need to implement
#2 (or, therefore, #3)

Here is a list of some typical tick counter rollover durations. The
following intervals have been rounded down to the nearest whole number and
therefore represent a realistic minimum interval at which the tick counter
must be read to prevent timing glitches caused by multiple roll-overs.

 - 1ms (1kHz), 16-bit - 65 seconds
 - 1ms (1kHz), 32-bit - 49 days
 - 1ms (1kHz), 64-bit - 584,942,417 years
 - 1us (1MHz), 32-bit - 71 minutes
 - 1us (1MHz), 64-bit - 584,942 years
 - 1ns (1GHz), 32-bit - 4 seconds
 - 1ns (1GHz), 64-bit - 584 years

The Prescaler
-
The prescaler converts the tick counter (with period <1ms) to a timer with
period = 1ms. As with the tick counter, the prescaler may be implemented
in either hardware or software. Where the prescaler is implemented in
hardware (and provides a 1ms counter) there is no need to implement a
software prescaler. However, if n

[U-Boot] DSN: failed (Returned mail: Data format error)

[Mailbot for etexusa . com]

This is a Delivery Status Notification (DSN).

I was unable to deliver your message to
aust...@msdirectservices.com.

I said 
  RCPT TO:

And they gave me the error;
  550 5.1.1 : Recipient address rejected: 
undeliverable address: host frontend.servicemail24.de[84.17.190.240] said: 550 
aust...@msdirectservices.com unknown user account (in reply to RCPT TO command)

 
Reporting-MTA: dns; etexusa.com
Final-Recipient: RFC822; austria@msdirectservices.com
Action: failed
Status: 5.0.0
Received: from lists.denx.de ([122.178.174.203]) by etexusa.com for ; Mon, 23 May 2011 21:12:38 -0700
From: u-boot@lists.denx.de
To: aust...@msdirectservices.com
Subject: Returned mail: Data format error
Date: Tue, 24 May 2011 09:41:53 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=_NextPart_000_0013_FA65280B.0355EDE1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Mike Frysinger]

rather than inventing our own set of terms, how about piggybacking what Linux 
has already done ?  they have "cycle counters" and "timer counters" (which 
bubble up into "clock sources", but i dont think we need those).

further, Linux probably already has implementations we can steal for the arch-
specific "cycle counters", and the common code which takes care of scaling 
those into actual measurements of time.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

Mike,

On Tue, May 24, 2011 at 2:24 PM, Mike Frysinger  wrote:
> rather than inventing our own set of terms, how about piggybacking what Linux
> has already done ?  they have "cycle counters" and "timer counters" (which
> bubble up into "clock sources", but i dont think we need those).

I only put the terms in to clarify them within the scope of the document
to avoid the inevitable 'but that means x' arguments ;)

> further, Linux probably already has implementations we can steal for the arch-
> specific "cycle counters", and the common code which takes care of scaling
> those into actual measurements of time.

Maybe - but I think the Linux implementation might be a bit too heavy
handed - We only need a very lightweight, simple implementation. Despite
the appearance of my write-up, the suggested implementation is very
simple:

 - A common software prescaler in /lib/ (not needed if hardware provides
   an exact 1ms period counter)
 - Arch specific implementation of tick counter (already there)
 - Arch specific hook into prescaler (not needed if tick counter has a
   'long enough' roll-over period or is 1ms, otherwise a tiny ISR which
   simply calls the prescaler)

Regards,

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

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

On Tue, May 24, 2011 at 7:02 AM, Graeme Russ  wrote:

[snip]
>
> Well, we have no control over the argument in cfi driver (unless you plan
> to put #ifdef NIOS all over the place)
>
> Maybe we could round up the parameter inside get_timer() itself?

Wow, what was I on! - Oh, thats right, no coffee ;)

The parameter to get_timer() is not a timeout, it is a reference epoch

So I think adding reset_timer() to the NIOS get_timer() when the parameter
is zero is the only option

Regards,

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Reinhard Meyer]

I know its futile to repeat what I suggested about 9 months ago...

Since get_timer() is only used (to my knowledge) to break out of
loops that do not terminate normally because an expected event does
not occur, the following API would be simpler and take less time per
loop:

(I use the names A and B to avoid nitpicking on real function names
which can be later chosen arbitrarily if this idea prevails...)

uint timeout = A(timeout_in_ms);

do {...} while (!B(timeout));

OR

for (;;) {
   dowhatever...
   if (B(timeout)) {
 error_handling...
 break;
   }
}

Internally both functions would be rather trival:

uint A(uint timeout_in_ms):

return current_tick + timeout_in_ms * ticks_per_ms;

or - for better precision if ticks_per_ms is not a whole number:

return current_tick + (timeout_in_ms * ticks_per_second) / 1000;

or any fractional method to more exactly calculate that equation
without needing a 64 bit divide.

bool B(uint end_tick):

a simple unsigned subtraction of end_tick minus current_tick,
evaluating the carry flag. Since we don't get a carry flag in C
a simple methods will do:
return ((int)(end_tick - current_tick)) < 0;

options:
current_tick needs only to be uint32, to get to the largest possible timeout
any 64 bit tick counter can be right shifted to get a 32 bit value that
increments just faster than 1ms.

features:
the only complicated calculation is done before the loop starts, the loop
itself is not made significantly slower since only a subtraction (and maybe
shift to scale down a high speed tick) is required.

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

Dear Reinhard,

On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
 wrote:
> I know its futile to repeat what I suggested about 9 months ago...
>
> Since get_timer() is only used (to my knowledge) to break out of
> loops that do not terminate normally because an expected event does
> not occur, the following API would be simpler and take less time per
> loop:
>
> (I use the names A and B to avoid nitpicking on real function names
> which can be later chosen arbitrarily if this idea prevails...)
>
> uint timeout = A(timeout_in_ms);
>
> do {...} while (!B(timeout));
>
> OR
>
> for (;;) {
>  dowhatever...
>  if (B(timeout)) {
>    error_handling...
>    break;
>  }
> }
>
> Internally both functions would be rather trival:
>
> uint A(uint timeout_in_ms):
>
> return current_tick + timeout_in_ms * ticks_per_ms;
>
> or - for better precision if ticks_per_ms is not a whole number:
>
> return current_tick + (timeout_in_ms * ticks_per_second) / 1000;
>
> or any fractional method to more exactly calculate that equation
> without needing a 64 bit divide.
>
> bool B(uint end_tick):
>
> a simple unsigned subtraction of end_tick minus current_tick,
> evaluating the carry flag. Since we don't get a carry flag in C
> a simple methods will do:
> return ((int)(end_tick - current_tick)) < 0;
>

Elegant and simple but precludes using get_timer() to perform any
meaningful time measurement - However this can be resolved by
doing

start = get_current_tick();
...
duration = get_elapsed_ms(start);

get_elapsed_ms() converts (current_tick - start) to ms. It can still be
a common library routine which calls a HAL function get_tick_frequency()

> options:
> current_tick needs only to be uint32, to get to the largest possible timeout
> any 64 bit tick counter can be right shifted to get a 32 bit value that
> increments just faster than 1ms.
>
> features:
> the only complicated calculation is done before the loop starts, the loop
> itself is not made significantly slower since only a subtraction (and maybe
> shift to scale down a high speed tick) is required.
>

But we run into problems when the tick counter is only 32-bit and the tick
frequency very fast so we would need to extend the tick counter to 64-bit
and have to periodically update it.

Nevertheless, I think we have two very viable options :)

Regards,

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

Re: [U-Boot] [RFC] Review of U-Boot timer API

[Albert ARIBAUD]

Le 24/05/2011 07:43, Graeme Russ a écrit :
> Dear Reinhard,
>
> On Tue, May 24, 2011 at 3:31 PM, Reinhard Meyer
>   wrote:
>> I know its futile to repeat what I suggested about 9 months ago...
>>
>> Since get_timer() is only used (to my knowledge) to break out of
>> loops that do not terminate normally because an expected event does
>> not occur, the following API would be simpler and take less time per
>> loop:
>>
>> (I use the names A and B to avoid nitpicking on real function names
>> which can be later chosen arbitrarily if this idea prevails...)
>>
>> uint timeout = A(timeout_in_ms);
>>
>> do {...} while (!B(timeout));
>>
>> OR
>>
>> for (;;) {
>>   dowhatever...
>>   if (B(timeout)) {
>> error_handling...
>> break;
>>   }
>> }
>>
>> Internally both functions would be rather trival:
>>
>> uint A(uint timeout_in_ms):
>>
>> return current_tick + timeout_in_ms * ticks_per_ms;
>>
>> or - for better precision if ticks_per_ms is not a whole number:
>>
>> return current_tick + (timeout_in_ms * ticks_per_second) / 1000;
>>
>> or any fractional method to more exactly calculate that equation
>> without needing a 64 bit divide.
>>
>> bool B(uint end_tick):
>>
>> a simple unsigned subtraction of end_tick minus current_tick,
>> evaluating the carry flag. Since we don't get a carry flag in C
>> a simple methods will do:
>> return ((int)(end_tick - current_tick))<  0;
>>
>
> Elegant and simple but precludes using get_timer() to perform any
> meaningful time measurement - However this can be resolved by
> doing
>
>   start = get_current_tick();
>   ...
>   duration = get_elapsed_ms(start);
>
> get_elapsed_ms() converts (current_tick - start) to ms. It can still be
> a common library routine which calls a HAL function get_tick_frequency()
>
>> options:
>> current_tick needs only to be uint32, to get to the largest possible timeout
>> any 64 bit tick counter can be right shifted to get a 32 bit value that
>> increments just faster than 1ms.
>>
>> features:
>> the only complicated calculation is done before the loop starts, the loop
>> itself is not made significantly slower since only a subtraction (and maybe
>> shift to scale down a high speed tick) is required.
>>
>
> But we run into problems when the tick counter is only 32-bit and the tick
> frequency very fast so we would need to extend the tick counter to 64-bit
> and have to periodically update it.
>
> Nevertheless, I think we have two very viable options :)


Not sure I still follow what the two options are -- a heads up is welcome.

However, I do like the simplicity in having a single time unit (ticks) 
for the timer API -- asuming it covers all needs -- and providing other 
time units only as helper functions.

 > Regards,
 >
 > Graeme

> Regards,
>
> Graeme

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

[U-Boot] cannot jump to stage 2 -start_armboot routine

[zex]

Hye all,

Does any one facing this kind of problem. The hardware initilization 
is done, but somehow the code doesn't jump into the c code.
Any setting involved? Thanks in advance

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