Re: [U-Boot] SPI on PPC MPC85xx

[Matthias Dunda]

Hi again,

unfortunately I have to push this message, as I received no comment on it, yet. 

Is there a reason why the immap_t is not implemented for mpc85xx?

I tried to copy it from mpc8360 but there are so many dependent mpc83xx 
datatypes in that struct that I postponed the work on that, because I think 
it'll lead to no success...

Even trying to use the soft SPI fails, because first thing the code does is 
using that immap_t datatype... :-(

Does anyone have a comment on this?

Cheers
Matthias

Am 25.10.2010 um 13:05 schrieb Matthias:

> Hi all,
> 
> I've been trying to setup SPI on our MPC85xx based board.
> 
> Unfortunately, compilation of mpc8xxx_spi.c fails due to a missing immap_t 
> datatype.
> 
> I see, that this datatype is defined in the headers immap_83xx.h and 
> immap_86xx.h but it is not in immap_85xx.h.
> 
> I am using u-boot-2009.11.1 but I also looked into the latest git sources, 
> and there's no immap_t in that specific file neither.
> 
> Is there a reason why it is not implemented for MPC85xx? Or do I just need 
> some more defines?
> 
> So far I only have CONFIG_MPC8XXX_SPI and undef CONFIG_SOFT_SPI.
> 
> Cheers
> Matthias Dunda
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] [PATCH] make-asm-offsets: fix sed script

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> When copying the "sed" script to generate the asm-offsets.h file from
> the Linux Kbuild script into the make-asm-offsets file I missed the
> fact that the former runs in a "make" context and thus uses double
> "$$" to escape a single "$", while the latter is a shell script, where
> this must not be done.  Unfortunately the problem did not show up
> during the initial tests on Power Architecture systems, but on ARM the
> generated asm-offsets.h was not correct.
> 
> Signed-off-by: Wolfgang Denk 
> ---
>  tools/scripts/make-asm-offsets |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

Tested on the omap3_beagle board, so:

Tested-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH 3/3] tqm85xx: Update PCI code

[Wolfgang Denk]

Dear Peter Tyser,

In message <1288156533.1971.6.ca...@ptyser-laptop> you wrote:
>
> Can you send the entire bootup output?  The code is based on Freescale
> reference boards, eg the mpc8568mds, so I'd guess the problem is not
> tqm85xx-specific.

Sure. Here it is:

U-Boot 2010.09-00558-g79e6313 (Oct 26 2010 - 21:31:41)

CPU:   8555E, Version: 1.1, (0x80790011)
Core:  Unknown, Version: 2.0, (0x80200020)
Clock Configuration:
   CPU0:833.333 MHz, 
   CCB:333.333 MHz,
   DDR:166.667 MHz (333.333 MT/s data rate), LBC:41.667 MHz
CPM:   333.333 MHz
L1:D-cache 32 kB enabled
   I-cache 32 kB enabled
Board: TQM8555, serial# ABC0555 casl=25
I2C:   ready
DRAM:  128 MiB
FLASH: 128 MiB
L2:256 KB already enabled

   PCI1:  32 bit, 33 MHz, sync, host, arbiter
   Scanning PCI bus 00
PCIE1 on bus 00 - 00
PCI-X will only work at 66 MHz
In:serial
Out:   serial
Err:   serial
DTT:   1 is 41 C
Net:   FCC1, TSEC0 [PRIME], TSEC1
PS/2:  No device found
Kbd:   reset failed, no ACK

Type run flash_nfs to mount root filesystem over NFS

Hit any key to stop autoboot:  0 
=> 


Please also note the "Core:  Unknown" which is new.

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
Hiring experienced unix people is  like  a  built-in  filter  against
idiots. Hiring experienced NT people provides no such guarantee.
-- Miguel Cruz in wgl96.349$cc.122...@typhoon2.ba-dsg.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] make-asm-offsets: fix sed script

[Wolfgang Denk]

When copying the "sed" script to generate the asm-offsets.h file from
the Linux Kbuild script into the make-asm-offsets file I missed the
fact that the former runs in a "make" context and thus uses double
"$$" to escape a single "$", while the latter is a shell script, where
this must not be done.  Unfortunately the problem did not show up
during the initial tests on Power Architecture systems, but on ARM the
generated asm-offsets.h was not correct.

Signed-off-by: Wolfgang Denk 
---
 tools/scripts/make-asm-offsets |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/scripts/make-asm-offsets b/tools/scripts/make-asm-offsets
index 61c095f..4c33756 100755
--- a/tools/scripts/make-asm-offsets
+++ b/tools/scripts/make-asm-offsets
@@ -8,8 +8,8 @@ mkdir -p $(dirname $2)
 
 # Default sed regexp - multiline due to syntax constraints
 SED_CMD="/^->/{s:->#\(.*\):/* \1 */:; \
-   s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
-   s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
+   s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
+   s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}"
 
 (set -e
-- 
1.7.2.3

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

Re: [U-Boot] [PATCH] kirkwood: guruplug: Relocate NAND environment area

[Prafulla Wadaskar]

Ack, Thanks regards..
Prafulla . .

> -Original Message-
> From: Gray Remlin [mailto:g_rem...@rocketmail.com]
> Sent: Wednesday, October 27, 2010 4:31 AM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar
> Subject: [PATCH] kirkwood: guruplug: Relocate NAND environment area
> 
> Current default options increase u-boot size to overlap the
> location of the environment in NAND, move environment higher up
> 
> Signed-off-by: Gray Remlin 
> ---
>  include/configs/guruplug.h |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/configs/guruplug.h b/include/configs/guruplug.h
> index 2c2682c..30a6050 100644
> --- a/include/configs/guruplug.h
> +++ b/include/configs/guruplug.h
> @@ -72,8 +72,8 @@
>   * it has to be rounded to sector size
>   */
>  #define CONFIG_ENV_SIZE  0x2 /* 128k */
> -#define CONFIG_ENV_ADDR  0x4
> -#define CONFIG_ENV_OFFSET0x4 /* env starts here */
> +#define CONFIG_ENV_ADDR  0x6
> +#define CONFIG_ENV_OFFSET0x6 /* env starts here */
> 
>  /*
>   * Default environment variables
> --
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Heiko Schocher]

Hello Steve,

today morning I tried actual u-boot on the beagle board, and I couldn;t
compile it because a problem with the GENERATED_GBL_DATA_SIZE changes.

In this context the question raised, if the

#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - 
GENERATED_GBL_DATA_SIZE)

setup with using LOW_LEVEL_SRAM_STACK @ 0x4020FFFC is OK?

The address
a) it is not aligned
b) We should use CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR

So my question:

shouldn;t we add in "arch/arm/include/asm/arch-omap3/omap3.h" or
"include/asm/arch/cpu.h"? this 2 missing defines (described in b)),
and change in all omap3 plattforms

#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - 
GENERATED_GBL_DATA_SIZE)

to

#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)

With

CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE)
 ^
 0x4020f800
CONFIG_SYS_INIT_RAM_SIZE0x7f0

What do you think?

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

Re: [U-Boot] [PATCH V3] mmc: seperate block number into small parts for multi-write cmd

[Lei Wen]

Hi Wolfgang,

How about merging this patch? I have the same concern with Steve Sakoman on
the point of improving mmc operation performance in UBOOT.

Best regards,
Lei

On Thu, Oct 14, 2010 at 3:57 AM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message <1286811544-9312-1-git-send-email-lei...@marvell.com> you wrote:
>> Constraint the mmc framework to only send no more than 65535
>> blocks in one go during the multi-write command. This constraint
>> comes due to the limitation of 16bit width block counter register
>> at some hardware.
> ...
>
>> @@ -123,7 +111,6 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, 
>> const void*src)
>>       data.flags = MMC_DATA_WRITE;
>>
>>       err = mmc_send_cmd(mmc, &cmd, &data);
>> -
>>       if (err) {
>>               printf("mmc write failed\n\r");
>>               return err;
>
> Please don;t drop this empty line.
>
>> +     do {
>> +             /* The 65535 constraint comes from some hardware has
>> +              * only 16 bit width block number counter */
>
> Incorrect multi-line comment style.
>
>> +             cur = (blocks_todo > 65535) ? 65535 : blocks_todo;
>> +             if(mmc_write_blocks(mmc, start, cur, src) != cur)
>> +                     return -1;
>> +             blocks_todo -= cur;
>> +             start += cur;
>> +             src += cur * mmc->write_bl_len;
>> +     } while (blocks_todo > 0);
>>       return blkcnt;
>
> Please add a blank line before the "return".
>
> 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
> The games have always  strengthened  us.  Death  becomes  a  familiar
> pattern. We don't fear it as you do.
>        -- Proconsul Marcus Claudius, "Bread and Circuses",
>           stardate 4041.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3 V3] Make board_init_f under nand_boot.c a weak function

[Sughosh Ganu]

hi Scott,

On Tue Oct 26, 2010 at 02:07:06PM -0500, Scott Wood wrote:
> On Tue, 26 Oct 2010 23:27:44 +0530
> Sughosh Ganu  wrote:
> 
> >  
> >  #if defined(CONFIG_ARM) && !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
> > -void board_init_f (ulong bootflag)
> > +void __board_init_f(ulong bootflag)
> >  {
> > -   relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
> > -  CONFIG_SYS_TEXT_BASE);
> > +   relocate_code(CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
> > +   CONFIG_SYS_TEXT_BASE);
> >  }
> > +void board_init_f(ulong bootflag)__attribute__((weak,
> > +alias("__board_init_f")));
> >  #endif
> >  
> >  /*
> 
> Eventually all boards should just provide their own board_init_f,
> which could just consist of a call to a common board init helper
> function.  Or possibly a preprocessor define could be used to indicate
> that the common function should be used.


  I had prososed that in my previous mail. I see that smdk6400 is the
  only arm board using this. I think we can make this change to move
  the board_init_f to the respective board directory right away. The
  change should not impact any other boards. If fine with you, i will
  respin my patch accordingly.

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

Re: [U-Boot] [PATCH] post/drivers/i2c.c: fix compile error

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Commit 7e263ce "post/i2c: Clean up detection logic" added a "const"
> qualifier to the declaration of i2c_addr_list[], missing the fact that
> the list gets modified later in the code, which results in build
> errors like these:
> 
> i2c.c: In function 'i2c_post_test':
> i2c.c:88: error: assignment of read-only location
> 
> Remove the incorrect "const".
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Peter Tyser 
> Cc: Heiko Schocher 
> ---
>  post/drivers/i2c.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks for detecting this. If you want, you can apply
this patch directly.

Acked-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH 3/3] tqm85xx: Update PCI code

[Peter Tyser]

On Tue, 2010-10-26 at 21:54 +0200, Wolfgang Denk wrote:
> Dear Peter Tyser,
> 
> In message <1285785448-4703-3-git-send-email-pty...@xes-inc.com> you wrote:
> > Update to use the recent, common FSL PCI initialization code.
> > 
> > Signed-off-by: Peter Tyser 
> > CC: s...@denx.de
> > ---
> >  board/tqc/tqm85xx/law.c |4 +-
> >  board/tqc/tqm85xx/tlb.c |   10 ++--
> >  board/tqc/tqm85xx/tqm85xx.c |  151 
> > ---
> >  include/configs/TQM85xx.h   |   20 +++---
> >  4 files changed, 59 insertions(+), 126 deletions(-)
> 
> This commit needs fixing.
> 
> First, it corrupts the output. Some patch like this should be added:
> 
> diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
> index 2c3885f..027c429 100644
> --- a/board/tqc/tqm85xx/tqm85xx.c
> +++ b/board/tqc/tqm85xx/tqm85xx.c
> @@ -567,7 +567,7 @@ void pci_init_board (void)
>   if (!(devdisr & MPC85xx_DEVDISR_PCI1)) {
>   SET_STD_PCI_INFO(pci_info[num], 1);
>   pcie_ep = fsl_setup_hose(&pci1_hose, pci_info[num].regs);
> - printf ("\n   PCI1:  %d bit, %s MHz, %s, %s, %s\n",
> + printf ("PCI1:  %d bit, %s MHz, %s, %s, %s\n",
>   (pci_32) ? 32 : 64,
>   (pci_speed == ) ? "33" :
>   (pci_speed == ) ? "66" : "unknown",
> @@ -591,7 +591,7 @@ void pci_init_board (void)
>   }
>  #endif
>   } else {
> - printf("PCI1: disabled\n");
> + printf("PCI1:  disabled\n");
>   }
>  #else
>   setbits_be32(&gur->devdisr, MPC85xx_DEVDISR_PCI1);
> 
> 
> Even worse, we now see a (badly formatted, but this is just an added
> "bonus")
> 
>   Scanning PCI bus 00
> PCIE1 on bus 00 - 00
> 
> which is completely bogus as there on these boards nor on these
> processors.
> 
> 
> Can you please provide a fix?

Can you send the entire bootup output?  The code is based on Freescale
reference boards, eg the mpc8568mds, so I'd guess the problem is not
tqm85xx-specific.

Best,
Pete

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

[U-Boot] American Consumer email lists

[von Price]

Order this week and save. Take any individual list for $99 or 3 for $249:

HEALTHCARE

> Doctors (34 different specialties)
> Chiropractors
> Alternative Medicine 
> Dentists 
> Veterinarians 
> Hospitals 
> Pharmaceutical Companies
> Physical Therapists 
> Oncology Doctors
> US Surgery Centers
> Massage Therapists 
> Acupuncturists 
> Medical Equipment Suppliers
> Mental Health Counselors
> Psychologists

BUSINESS LISTS

> Real Estate Agents 
> US New Business Database 
> Financial Planners Database 
> Finance and Money Professionals Database


PROFESSIONALS LISTS

> USA Lawyers Database 
> Criminal Attorneys - 142,906 


Send me an email here for samples and stats: maximumresu...@gmx.us

  




Forward email to purgef...@gmx.com to purge you from our records
  




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

[U-Boot] Detailed data with many fields for businesses, healthcare and more

[Chelsea Stein]

Save on advertising list costs until this Friday:

ANY 2 lists below for just $199

ANY 7 lists below for just $499

[ HEALTHCARE ]

> Complete US Physicians Database
> Chiropractic Doctors in the USA
> American Holistic Medicine Providers/Clinics
> General Dentists in the USA
> American Veterinarians & Veterinary Clinics
> US Hospitals 
> Nursing Homes int the US 
> Pharmaceutical Company Employees
> Physical/Occupational Therapy Clinics and Therapists in the US
> Oncology Physicians in the US
> US Surgery Centers
> Massage Therapists/Therapy Clinics in America
> Acupuncturists/clinics in the US
> Medical Equipment Suppliers(USA)
> Mental Health Counselors (USA)
> Optometrists/Clinics (USA)
> Psychologists (USA)

[ BUSINESS LISTS ]

> Hotels in the USA
> Realtors in the USA 
> USA Business Database 
> Manufacturer Database (USA)
> Financial Planner Database (USA)
> Finance & Professionals Database (USA)

[ CONSUMER LISTS ]

> USA Consumer Database 
> Credit Inquiries Database (USA)
> American Homeowners

[ PROFESSIONALS LISTS ]

> USA Lawyers Database 
> Criminal Attorneys in the US


Email me for counts, breakdowns and sample spreadsheets: maximumresu...@gmx.us

  




To invoke no further correspondence status please send an email to 
purgef...@gmx.com
  




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

Re: [U-Boot] [PATCH] cmd_net: drop spurious comma in U_BOOT_CMD

[Mike Frysinger]

On Tuesday, October 26, 2010 17:45:10 Wolfgang Denk wrote:
> In message <20101026191510.5ac28152...@gemini.denx.de> I wrote:
> > Mike Frysinger wrote:
> > > Building for boards that have CONFIG_CMD_CDP enabled fail with:
> > > cmd_net.c:301: error: expected expression before ',' token
> > 
> > Applied, thanks.
> 
> I wish I had tested this before applying - and even more I wish you
> had run MAKEALL as requested when sumbitting patches.

actually, as i had stated in one of my other patches, i *was* running MAKEALL 
but the vast majority of boards were failing (probably because of your patches 
you noted some time later).  for the few boards that didnt fail in that way, 
they were failing *because of this code*.

i wrote the patch *because* MAKEALL was reporting failures due to this code.  
but perhaps the failure i was seeing was just fallout of the bad patches you 
had pushed already.  i guess i dont really care because none of my boards were 
or are failing due to this, and i'll stop trying to fix other people's board 
failures.
-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] kirkwood: guruplug: Relocate NAND environment area

[Gray Remlin]

Current default options increase u-boot size to overlap the
location of the environment in NAND, move environment higher up

Signed-off-by: Gray Remlin 
---
 include/configs/guruplug.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/guruplug.h b/include/configs/guruplug.h
index 2c2682c..30a6050 100644
--- a/include/configs/guruplug.h
+++ b/include/configs/guruplug.h
@@ -72,8 +72,8 @@
  * it has to be rounded to sector size
  */
 #define CONFIG_ENV_SIZE0x2 /* 128k */
-#define CONFIG_ENV_ADDR0x4
-#define CONFIG_ENV_OFFSET  0x4 /* env starts here */
+#define CONFIG_ENV_ADDR0x6
+#define CONFIG_ENV_OFFSET  0x6 /* env starts here */

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

Re: [U-Boot] [PATCH] cmd_net: drop spurious comma in U_BOOT_CMD

[Wolfgang Denk]

In message <20101026191510.5ac28152...@gemini.denx.de> I wrote:
> Dear Mike Frysinger,
> 
> In message <1287560010-31252-1-git-send-email-vap...@gentoo.org> you wrote:
> > Building for boards that have CONFIG_CMD_CDP enabled fail with:
> > cmd_net.c:301: error: expected expression before ',' token
> > 
> > Signed-off-by: Mike Frysinger 
> > ---
> >  common/cmd_net.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> Applied, thanks.

I wish I had tested this before applying - and even more I wish you
had run MAKEALL as requested when sumbitting patches.

Reverted, as it breaks building of some boards:

Configuring for LANTEC board...
cmd_net.c:301:1: error: macro "U_BOOT_CMD" requires 6 arguments, but only 5 
given
cmd_net.c:298: warning: data definition has no type or storage class
cmd_net.c:298: warning: type defaults to 'int' in declaration of 'U_BOOT_CMD'
make[1]: *** [/work/wd/tmp-ppc/common/cmd_net.o] Error 1


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
Unsichtbar macht sich die Dummheit, indem sie immer  größere  Ausmaße
annimmt. -- Bertold Brecht: Der Tui-Roman
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Alessandro Rubini]

> I am not convinced, as we don't have an array context here.

But sizeof(struct x) doesn't depend on how struct x is used.
You can declare a pointer and then allocate for an array.

> I don't see that with
> 
>   struct foo x;
>   struct foo y[N];
> 
> we have a guarantee that sizeof(x) == sizeof(y[0]). 

Yes, I see this requirement. But maybe we're already bikeshedding:
I won't get offended if you keep the global +15 & ~15.

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

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

Dear Alessandro Rubini,

In message <20101026211821.ga2...@morgana.i.gnudd.com> you wrote:
> > Is it guaranteed (I mean by the C standard) that the alignment of a
> > struct (which affects only the possible start address) also has effect
> > on the sizeof() for that struct, in the sense that sizeof() is
> > guaranteed to be a multiple of that alignment requirement?
> 
> Yes. Because if you make an array, all of them must be aligned, and
> the size of an array is a multiple of sizeof(array_item).  While
> alignment is not in the standard, the sizeof/array relationship is.

I am not convinced, as we don't have an array context here.

> It's in C99 draft (http://busybox.net/~landley/c99-draft.html)
> 
>   6.5.3.4 The sizeof operator
> 
>   #6
> 
>   EXAMPLE 2 Another use of the sizeof operator is to compute the
>   number of elements in an array:
> sizeof array / sizeof array[0]

I don't see that with

struct foo x;
struct foo y[N];

we have a guarantee that sizeof(x) == sizeof(y[0]). 

Maybe I'm just paranoid...

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
Until you walk a mile in another man's moccasins, you  can't  imagine
the smell.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] post/drivers/i2c.c: fix compile error

[Wolfgang Denk]

Commit 7e263ce "post/i2c: Clean up detection logic" added a "const"
qualifier to the declaration of i2c_addr_list[], missing the fact that
the list gets modified later in the code, which results in build
errors like these:

i2c.c: In function 'i2c_post_test':
i2c.c:88: error: assignment of read-only location

Remove the incorrect "const".

Signed-off-by: Wolfgang Denk 
Cc: Peter Tyser 
Cc: Heiko Schocher 
---
 post/drivers/i2c.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/post/drivers/i2c.c b/post/drivers/i2c.c
index 3080e81..4a1b1a4 100644
--- a/post/drivers/i2c.c
+++ b/post/drivers/i2c.c
@@ -74,7 +74,7 @@ int i2c_post_test (int flags)
 #else
unsigned int ret  = 0;
int j;
-   const unsigned char i2c_addr_list[] = CONFIG_SYS_POST_I2C_ADDRS;
+   unsigned char i2c_addr_list[] = CONFIG_SYS_POST_I2C_ADDRS;
 
/* Start at address 1, address 0 is the general call address */
for (i = 1; i < 128; i++) {
-- 
1.7.2.3

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

Re: [U-Boot] Timer implementations

[J. William Campbell]

On 10/26/2010 6:33 AM, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>>> Then the define CONFIG_SYS_HZ should not be in every.h since that
>>> suggests that a board developer has some freedom there...
>> Agreed - there are historical reasons this has ever been changable at
>> all.
>>
>>> and MOST IMPORTANT that some implementations of udelay() might
>>> call reset_timer() and therefore break an outer timeout loop !!!
>> Such implementations are inherently broken and need to be fixed.
> Found such in arm926ejs/omap... But then, that timer is multiple-broken:
> relocation broken (uses static data), returns 32 a bit value in get_ticks(),
> returns CONFIG_SYS_HZ in get_tbclk() instead of the rate get_ticks()
> increments...
>
> PXA:
> void udelay_masked (unsigned long usec)
> {
>   unsigned long long tmp;
>   ulong tmo;
>
>   tmo = us_to_tick(usec);
>   tmp = get_ticks() + tmo;/* get current timestamp */
>
>   while (get_ticks()<  tmp)
>   /* loop till event _OR FOREVER is tmp happens to be>  32 bit_ */
>/*NOP*/;
>
> }
>
> unsigned long long get_ticks(void)
> {
>   return readl(OSCR);
> }
> - not any better :( -- its the same code that AT91 had before I fixed it.
>
>>> It is also open if reset_timer() does actually reset the hardware timer
>>> (e.g. tbu/tbl at PPC) - which would be messing up any time difference
>>> calculation using get_ticks() - or does emulate that by remembering
>>> the hardware value and subtracting it later in every subsequent
>>> get_timer() call?
>> This is an implementation detail.
> IF we require that get_ticks() and get_timer() shall not interfere with
> each other and IF both are based on the same hardware timer only the
> second method is available (same if the hardware timer is not easyly
> resettable).
>
>>> 2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
>>> Since they are defined as having 64 bits they MUST not wrap at 32 bits,
>>> i.e. if the hardware provides only 32 bits, the upper 32 bits must be
>>> emulated by software.
>> Right.
>>
>>> Otherwise we have to document that get_ticks() cannot be used to get
>>> 64 bit time differences.
>> No. Such an implementation is broken and needs fixing.
> Original AT91 timer.c was like that, and I think other ARMs where this was
> copied around should be looked at... I don't know when get_timer() became
> 64 bits, but it seems that some implementations just did change the return
> type: uint64 get_timer(void) {return (uint64)timer_val_32;}
Hi All,

  I am pretty sure the migration to 64 bits was caused by 1) people 
not understanding that the timer operating on time DIFFERENCES would 
work fine even if the underlying timer wrapped around (most probable 
problem) and possibly 2) broken timer functions causing bogus timeouts, 
improperly "fixed" by switching to 64 bits.

I think u-boot could get along just fine with only 2 time related 
functions,  uint_32 get_timer(uint_32 base) and udelay(uint 32 delay).  
udelay will only work on "small" values of delay, on the order of 
milliseconds. It is to be used when a "short" but "precise" delay in 
microsecond resolution is required.  Users of get_timer must understand 
that it is only valid if it is called "often enough", i.e. at least once 
per period of the underlying timer. This is required because u-boot  
does not want to rely on interrupts as a timer update method. Therefore, 
all uses of get_timer must 1) call it once initially to get a start 
value, and 2) call get_timer at least once per period  of the underlying 
hardware counter. This underlying period is guaranteed to be at least 
4.29 seconds (32 bit counter at 4 GHz). Note that this does NOT mean 
that the total wait must be less than 4.29 seconds, only that the rate 
at which the elapsed time is TESTED must be adequate.

In order to implement this functionality, at least one hardware timer of 
some kind is required. An additional software "timer" in 1 ms resolution 
may be useful in maintaining the software time. If the hardware timer 
update rate is programmable, u-boot MAY set the update rate on 
initialization On initialization, u-boot MAY reset the hardware timer 
and MAY reset any associated software timer. The hardware timer MAY be 
started on initialization. On each call to get_timer(), u-boot MUST 
start the hardware timer if it was not started already. On calls to 
get_timer, u-boot MUST NOT reset the hardware timer if it was already 
started. The software timer MAY be reset if u-boot can unambiguously 
determine that  more than 4.29 seconds has elapsed since the last call 
to get_timer.

The simplest case for implementing this scheme is if two programmable 
timers exist that can be set to 1ms and 1us.  The timers are initialized 
at start-up, get_timer just returns the 32 bit 1 ms timer and udelay 
just waits for the number of ticks required on the second timer to 
elapse. The most common harder case is where there is only one timer 

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Alessandro Rubini]

> Is it guaranteed (I mean by the C standard) that the alignment of a
> struct (which affects only the possible start address) also has effect
> on the sizeof() for that struct, in the sense that sizeof() is
> guaranteed to be a multiple of that alignment requirement?

Yes. Because if you make an array, all of them must be aligned, and
the size of an array is a multiple of sizeof(array_item).  While
alignment is not in the standard, the sizeof/array relationship is.

It's in C99 draft (http://busybox.net/~landley/c99-draft.html)

  6.5.3.4 The sizeof operator

  #6

  EXAMPLE 2 Another use of the sizeof operator is to compute the
  number of elements in an array:
sizeof array / sizeof array[0]

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

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

Dear Alessandro Rubini,

In message <20101026205756.ga2...@morgana.i.gnudd.com> you wrote:
>
> Instead of:
> 
>  DEFINE(GENERATED_GBL_DATA_SIZE,
>  (sizeof(struct global_data)+15) & ~15);
> 
> I'd use:
> 
>  DEFINE(GENERATED_GBL_DATA_SIZE,
>  (sizeof(struct global_data)),
> 
> leaving the alignment requirement in the structure itself
> (include/asm/global_data.h for each architecture).

Is it guaranteed (I mean by the C standard) that the alignment of a
struct (which affects only the possible start address) also has effect
on the sizeof() for that struct, in the sense that sizeof() is
guaranteed to be a multiple of that alignment requirement?

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
panic: kernel trap (ignored)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V7] POST cleanup.

[Wolfgang Denk]

Dear Michael Zaidman,

In message 

 you wrote:
> - Revives POST for blackfin arch;
> - Removes redundant code:
>  arch/blackfin/lib/post.c
>  arch/powerpc/cpu/ppc4xx/commproc.c
>  arch/powerpc/cpu/mpc512x/common.c
> - fixes up the post_word_{load|store} usage.

Unfortunately it turns out that the code now contains a few nasty
bugs...

...
>  #define CONFIG_SYS_GBL_DATA_OFFSET   (CONFIG_SYS_INIT_RAM_END - 
> CONFIG_SYS_GBL_DATA_SIZE)
> -#define CONFIG_SYS_POST_WORD_ADDR(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
> -#define CONFIG_SYS_INIT_SP_OFFSETCONFIG_SYS_POST_WORD_ADDR
> +#define CONFIG_SYS_INIT_SP_OFFSET(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)

This is a seriously broken design, as it sneaks in storage for a
variable in a storage location where it is not expected.

The "official" layout is that we have CONFIG_SYS_INIT_RAM_BYTES
available; the top CONFIG_SYS_GBL_DATA_SIZE bytes (now
GENERATED_GBL_DATA_SIZE) are used for global data, and the part below
is used for the stack.  No other room is reserved there.

Shifting down the stack by 4 bytes as it's done here causes that the
stack is not correctly aligned any more, which may cause really nasty
subsequent errors.

But it's even worse.

> diff --git a/include/configs/mpc5121-common.h 
> b/include/configs/mpc5121-common.h
> index 96fab20..afae1ab 100644
> --- a/include/configs/mpc5121-common.h
> +++ b/include/configs/mpc5121-common.h
...
> -#define CONFIG_SYS_POST_WORD_ADDR(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
> -#define CONFIG_SYS_INIT_SP_OFFSETCONFIG_SYS_POST_WORD_ADDR
> +#define CONFIG_SYS_INIT_SP_OFFSET(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)

There the same is done, but what happens actually?

Have a look how the stack setup gets implemented in
"arch/powerpc/cpu/mpc512x/start.S":

...
244 in_flash:
245 lis r1, (CONFIG_SYS_INIT_RAM_ADDR + 
CONFIG_SYS_GBL_DATA_OFFSET)@h
246 ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + 
CONFIG_SYS_GBL_DATA_OFFSET)@l
247
248 li  r0, 0   /* Make room for stack frame header and */
249 stwur0, -4(r1)  /* clear final stack frame so that  */
250 stwur0, -4(r1)  /* stack backtraces terminate cleanly   */
...

As you can see, the code does not use CONFIG_SYS_INIT_SP_OFFSET at
all; instead it performs a calculation which should be redundant, but
in the current code it means that the location of the POST_WORD is
right in the initial stack.

I did not check if the code for other processors has similar issues.


"Reserving" private storage like that is bad, as other involved
parties probably have no knowledge of such a private reservation.


Why do we not simply reserve a word in the global data structure instead?


This bug needs pretty urgent fixing.


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 wish Captain Vimes were here. He wouldn't have  known  what  to  do
either, but he's got a much better vocabulary to be baffled in.
 - Terry Pratchett, _Guards! Guards!_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Alessandro Rubini]

>> This has already been applied, sooner than usual.  Isn't it cleaner to
>> force alignment on the structure itself? This way different architectures
>> may use different values, if the need arises.
> 
> It would be better, but how to implement that?

Instead of:

 DEFINE(GENERATED_GBL_DATA_SIZE,
 (sizeof(struct global_data)+15) & ~15);

I'd use:

 DEFINE(GENERATED_GBL_DATA_SIZE,
 (sizeof(struct global_data)),

leaving the alignment requirement in the structure itself
(include/asm/global_data.h for each architecture).

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

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

Dear Alessandro Rubini,

In message <20101026195429.ga1...@morgana.i.gnudd.com> you wrote:
>
> This has already been applied, sooner than usual.  Isn't it cleaner to
> force alignment on the structure itself? This way different architectures
> may use different values, if the need arises.

It would be better, but how to implement that? Please keep in mind
that the pointers are set up in aseembler code, where we don't have
such things as "struct" etc.  We're dealing with raw addresses here,
which is the reason we have to go through all this effort with
asm-offsets and such.

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 have a very small mind and must live with it.-- Edsger Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V6 03/10] 83xx/85xx/86xx: LBC register cleanup

[Wolfgang Denk]

Dear Kumar,

In message  you wrote:
> 
> Hmm, how about dumping all of the LBC registers and comparing
> before/after this change.

After the change (here with 2010.09-00558-g79e6313):

Board: TQM8555, serial# ABC0555 casl=25
I2C:   ready
DRAM:  128 MiB
FLASH: 128 MiB
L2:256 KB already enabled

=> fli

Bank # 1: CFI conformant FLASH (32 x 16)  Size: 64 MB in 512 Sectors
  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
  Erase timeout: 16384 ms, write timeout: 1 ms
  Buffer write timeout: 5 ms, buffer size: 32 bytes

  Sector Start Addresses:
  F800 E  F802 E  F804 E  F806 E  F808 E
  F80A E  F80C E  F80E E  F810 E  F812 E
...
  FBF2 E  FBF4FBF6 E  FBF8FBFA  
  FBFCFBFE  

Bank # 2: CFI conformant FLASH (128 x 128)  Size: 64 MB in 512 Sectors
  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
  Erase timeout: 16384 ms, write timeout: 1 ms
  Buffer write timeout: 5 ms, buffer size: 32 bytes

  Sector Start Addresses:
  FC00FC02FC04FC06FC08  
  FC0AFC0CFC0EFC10FC12  
...
  FFF2FFF4   RO   FFF6   RO   FFF8   RO   FFFA   RO 
  FFFC   RO   FFFE   RO 


ccsrbar: 0x000e  917504
altcbar: 0x  0
altcsr : 0x  0
bptr   : 0x  0
lawbar0: 0x  0
lawar0 : 0x80f0001e  -2131754978
lawbar1: 0x0008  524288
lawar1 : 0x801c  -2147483620
lawbar2: 0x000f8000  1015808
lawar2 : 0x8040001a  -2143289318
lawbar3: 0x000e2000  925696
lawar3 : 0x8017  -2147483625
lawbar4: 0x000c  786432
lawar4 : 0x80c0001c  -2134900708
lawbar5: 0x  0
lawar5 : 0x  0
lawbar6: 0x  0
lawsa6 : 0x  0
lawbar7: 0x  0
lawsa7 : 0x  0

br0: 0xf8001801  -134211583
br1: 0xf8001801  -134211583
br2: 0x  0
br3: 0x  0
br4: 0x  0
br5: 0x  0
br6: 0x  0
br7: 0x  0
or0: 0xfc40  -67108800
or1: 0xfc40  -67108800
or2: 0x  0
or3: 0x  0
or4: 0x  0
or5: 0x  0
or6: 0x  0
or7: 0x  0


before (here with v2010.06):

Board: TQM8555, serial# ABC0555 casl=25
I2C:   ready
DRAM:  128 MiB
FLASH: 128 MiB
L2:256 KB enabled

=> fli

Bank # 1: CFI conformant FLASH (32 x 16)  Size: 64 MB in 512 Sectors
  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
  Erase timeout: 16384 ms, write timeout: 1 ms
  Buffer write timeout: 5 ms, buffer size: 32 bytes

  Sector Start Addresses:
  F800 E  F802 E  F804 E  F806 E  F808 E
  F80A E  F80C E  F80E E  F810 E  F812 E
...
  FBF2 E  FBF4 E  FBF6 E  FBF8 E  FBFA E
  FBFC E  FBFE E

Bank # 2: CFI conformant FLASH (32 x 16)  Size: 64 MB in 512 Sectors
  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
  Erase timeout: 16384 ms, write timeout: 1 ms
  Buffer write timeout: 5 ms, buffer size: 32 bytes

  Sector Start Addresses:
  FC00 E  FC02 E  FC04 E  FC06 E  FC08 E
  FC0A E  FC0C E  FC0E E  FC10 E  FC12 E
...
  FFF2 E  FFF4   RO   FFF6 E RO   FFF8   RO   FFFA   RO 
  FFFC   RO   FFFE   RO 

ccsrbar: 0x000e  917504
altcbar: 0x  0
altcsr : 0x  0
bptr   : 0x  0
lawbar0: 0x  0
lawar0 : 0x80f0001e  -2131754978
lawbar1: 0x0008  524288
lawar1 : 0x801c  -2147483620
lawbar2: 0x000f8000  1015808
lawar2 : 0x8040001a  -2143289318
lawbar3: 0x000e2000  925696
lawar3 : 0x8017  -2147483625
lawbar4: 0x000c  786432
lawar4 : 0x80c0001c  -2134900708
lawbar5: 0x  0
lawar5 : 0x  0
lawbar6: 0x  0
lawsa6 : 0x  0
lawbar7: 0x  0
lawsa7 : 0x  0

br0: 0xfc001801  -67102719
br1: 0xf8001801  -134211583
br2: 0x  0
br3: 0x  0
br4: 0x  0
br5: 0x  0
br6: 0x  0
br7: 0x  0
or0: 0xfc40  -67108800
or1: 0xfc40  -67108800
or2: 0x  0
or3: 0x  0
or4: 0x  0
or

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Alessandro Rubini]

> + /* Round up to make sure size gives nice stack alignment */
> + DEFINE(GENERATED_GBL_DATA_SIZE,
> + (sizeof(struct global_data)+15) & ~15);
> +

This has already been applied, sooner than usual.  Isn't it cleaner to
force alignment on the structure itself? This way different architectures
may use different values, if the need arises.

This shows it.

struct a {
int i;
} __attribute__((aligned(16)));

struct b {
int i;
};

int main()
{
printf("%i %i\n", sizeof(struct a), sizeof(struct b));
}

It prints "16 4" as expected.

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

Re: [U-Boot] [PATCH 3/3] tqm85xx: Update PCI code

[Wolfgang Denk]

Dear Peter Tyser,

In message <1285785448-4703-3-git-send-email-pty...@xes-inc.com> you wrote:
> Update to use the recent, common FSL PCI initialization code.
> 
> Signed-off-by: Peter Tyser 
> CC: s...@denx.de
> ---
>  board/tqc/tqm85xx/law.c |4 +-
>  board/tqc/tqm85xx/tlb.c |   10 ++--
>  board/tqc/tqm85xx/tqm85xx.c |  151 
> ---
>  include/configs/TQM85xx.h   |   20 +++---
>  4 files changed, 59 insertions(+), 126 deletions(-)

This commit needs fixing.

First, it corrupts the output. Some patch like this should be added:

diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index 2c3885f..027c429 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -567,7 +567,7 @@ void pci_init_board (void)
if (!(devdisr & MPC85xx_DEVDISR_PCI1)) {
SET_STD_PCI_INFO(pci_info[num], 1);
pcie_ep = fsl_setup_hose(&pci1_hose, pci_info[num].regs);
-   printf ("\n   PCI1:  %d bit, %s MHz, %s, %s, %s\n",
+   printf ("PCI1:  %d bit, %s MHz, %s, %s, %s\n",
(pci_32) ? 32 : 64,
(pci_speed == ) ? "33" :
(pci_speed == ) ? "66" : "unknown",
@@ -591,7 +591,7 @@ void pci_init_board (void)
}
 #endif
} else {
-   printf("PCI1: disabled\n");
+   printf("PCI1:  disabled\n");
}
 #else
setbits_be32(&gur->devdisr, MPC85xx_DEVDISR_PCI1);


Even worse, we now see a (badly formatted, but this is just an added
"bonus")

Scanning PCI bus 00
PCIE1 on bus 00 - 00

which is completely bogus as there on these boards nor on these
processors.


Can you please provide a fix?

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
"It's like deja vu all over again."  - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: use the same branch insn on all architectures

[Wolfgang Denk]

In message <1287868958-29447-1-git-send-email...@denx.de> you wrote:
> For the "fixloop" implementation in start.S a number of different
> instructions was used.  Unify code so all architectures use "blo"
> here because it is more robust in case of incorrect alignments.
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Albert ARIBAUD 
> Cc: Minkyu Kang 
> Cc: Sandeep Paulraj 
> Cc: Prafulla Wadaskar 
> Cc: Stefano Babic 
> Cc: Marek Vasut 
> ---
>  arch/arm/cpu/arm1136/start.S   |2 +-
>  arch/arm/cpu/arm1176/start.S   |2 +-
>  arch/arm/cpu/arm720t/start.S   |2 +-
>  arch/arm/cpu/arm920t/start.S   |2 +-
>  arch/arm/cpu/arm925t/start.S   |2 +-
>  arch/arm/cpu/arm946es/start.S  |2 +-
>  arch/arm/cpu/arm_intcm/start.S |2 +-
>  arch/arm/cpu/ixp/start.S   |2 +-
>  arch/arm/cpu/lh7a40x/start.S   |2 +-
>  arch/arm/cpu/s3c44b0/start.S   |2 +-
>  arch/arm/cpu/sa1100/start.S|2 +-
>  11 files changed, 11 insertions(+), 11 deletions(-)

Applied.

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 Buddha, the Godhead, resides quite as comfortably in the circuits
of a digital computer or the gears of a cycle transmission as he does
at the top of a mountain or in the petals of a flower.
- R.  Pirsig, "Zen and the Art of Motorcycle Maintenance"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Remove config.mk for da8xxevm based boards.

[Wolfgang Denk]

Dear Sughosh Ganu,

In message <1287775683-17887-1-git-send-email-urwithsugh...@gmail.com> you 
wrote:
> Move CONFIG_SYS_TEXT_BASE to the board's config file, and remove the
> now unnecessary config.mk file.
> 
> Signed-off-by: Sughosh Ganu 
> ---
>  board/davinci/da8xxevm/config.mk |   43 
> --
>  include/configs/da830evm.h   |1 +
>  include/configs/da850evm.h   |1 +
>  3 files changed, 2 insertions(+), 43 deletions(-)
>  delete mode 100644 board/davinci/da8xxevm/config.mk

Applied, thanks.

Dear Sandeep, hope it's OK that I pulled this directly.

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
How many QA engineers does it take to screw in a lightbulb? 3:  1  to
screw it in and 2 to say "I told you so" when it doesn't work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm, bootm: Fix compile warning

[Wolfgang Denk]

Dear Heiko Schocher,

In message <1287988418-28003-1-git-send-email...@denx.de> you wrote:
> Fix warning:
> 
> bootm.c: In function 'bootm_linux_fdt':
> bootm.c:181: warning: unused variable 's'
> bootm.c:180: warning: unused variable 'bd'
> 
> Signed-off-by: Heiko Schocher 
> ---
>  arch/arm/lib/bootm.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)

Applied, 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
Don't put off for tomorrow what you can  do  today,  because  if  you
enjoy it today you can do it again tomorrow.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_net: drop spurious comma in U_BOOT_CMD

[Wolfgang Denk]

Dear Mike Frysinger,

In message <1287560010-31252-1-git-send-email-vap...@gentoo.org> you wrote:
> Building for boards that have CONFIG_CMD_CDP enabled fail with:
> cmd_net.c:301: error: expected expression before ',' token
> 
> Signed-off-by: Mike Frysinger 
> ---
>  common/cmd_net.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, 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
America has been discovered before, but it has always been hushed up.
- Oscar Wilde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sparc: add asm/unaligned.h

[Wolfgang Denk]

Dear Daniel Hellstrom,

In message <4cc54d00.6040...@gaisler.com> you wrote:
> 
> Mike Frysinger wrote:
> 
> >It isn't possible to build any sparc boards without this ...
> >  
> >
> I'm working on a new patch set with some of the patches going through 
> the net repo instead, according to Wolfgangs comments. It is probably 
> easier for me to make fewer commits every time submitting, and 
> submitting multiple times.

But it looks like a serious bug fix, so it should go in _now_, should
it not?

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
How come everyone's going so slow if it's called rush hour?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm1176: fix relocation

[Wolfgang Denk]

Dear Darius Augulis,

In message <20101025104707.12408.13906.st...@darius-desktop> you wrote:
> Fix relocation code for arm1176, do it like other ARM
> CPU's are doing.
> Tested only with CONFIG_SKIP_RELOCATE_UBOOT defined
> and using nand_spl (booting from nand). Test done on
> s3c6410 based board (not yet supported in main line).
> 
> Signed-off-by: Darius Augulis 
> ---
> 
> Changes since v1:
>  - Heiko comments fixed
> 
>  arch/arm/cpu/arm1176/start.S|  143 
> +++
>  arch/arm/cpu/arm1176/u-boot.lds |   15 +++-
>  2 files changed, 97 insertions(+), 61 deletions(-)

Applied, 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
It is a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: fix address setup in start.S

[Wolfgang Denk]

Dear Darius Augulis,

In message <20101025104524.12379.22378.st...@darius-desktop> you wrote:
> Fix address setup bug for ARM.
> This bug stops u-boot booting if
> CONFIG_SKIP_RELOCATE_UBOOT is defined.
> 
> Signed-off-by: Darius Augulis 
> ---
>  arch/arm/cpu/arm1136/start.S   |6 --
>  arch/arm/cpu/arm926ejs/start.S |6 --
>  arch/arm/cpu/armv7/start.S |6 --
>  arch/arm/cpu/pxa/start.S   |6 --
>  4 files changed, 16 insertions(+), 8 deletions(-)

Applied, 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
If a person (a) is poorly, (b) receives treatment  intended  to  make
him  better, and (c) gets better, then no power of reasoning known to
medical science can convince him  that  it  may  not  have  been  the
treatment that restored his health.
- Sir Peter Medawar, The Art of the Soluble
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] Add board support for hawkboard

[Wolfgang Denk]

Dear sughosh ganu,

In message  you 
wrote:
>
>  I was checking the usage of board_init_f in the nand_spl/nand_boot.c file,
> and currently only the smdk6400 board uses it. Can we then remove this
> function definition from the nand_boot.c file and put it in the respective
> board file, like the freescale boards. I think this is a cleaner way of
> implementing this. Please le me know, and i will base my changes
> accordingly. Thanks.

I'm not sure I understnad your plan correctly. If you don't mind
please submit a patch; this is easier to review then.

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 project was large enough and management communication poor enough
to prompt many members of the team to see themselves  as  contestants
making  brownie  points,  rather  than as builders making programming
products. Each suboptimized  his  piece  to  meet  his  targets;  few
stopped to think about the total effect on the customer.
  - Fred Brooks, "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot text console

[Wolfgang Denk]

Dear Kallol Biswas,

In message  you 
wrote:
>
>I have a customer request to build BIOS like user interface(UI) for
> u-boot over serial port? Something like text console with tabs on the
> top.
> Each tab will have sub-items just like BIOS.
> 
> This is for a PPC platform.
> 
> Is there any existing software/code base that can be used?

The OpenMoko port had a menu implementation which could be reused.
Alternatively, similar code has recently been added to BareBox;
adapting this should be not too difficult either.

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
Punishment becomes ineffective after a certain point. Men become  in-
sensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3 V3] Make board_init_f under nand_boot.c a weak function

[Scott Wood]

On Tue, 26 Oct 2010 23:27:44 +0530
Sughosh Ganu  wrote:

> 
>  Enable board_init_f to be overridden with a board
>  specific function.
> 
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V2:
>   * Fix the checkpatch warnings
> 
>  nand_spl/nand_boot.c |8 +---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
> index ccd0af2..01ff3e3 100644
> --- a/nand_spl/nand_boot.c
> +++ b/nand_spl/nand_boot.c
> @@ -222,11 +222,13 @@ static int nand_load(struct mtd_info *mtd, unsigned int 
> offs,
>  }
>  
>  #if defined(CONFIG_ARM) && !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
> -void board_init_f (ulong bootflag)
> +void __board_init_f(ulong bootflag)
>  {
> - relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
> -CONFIG_SYS_TEXT_BASE);
> + relocate_code(CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
> + CONFIG_SYS_TEXT_BASE);
>  }
> +void board_init_f(ulong bootflag)__attribute__((weak,
> +  alias("__board_init_f")));
>  #endif
>  
>  /*

ACK for now, but given space constraints we probably don't want to
carry around __board_init_f just to have it be overridden (will an
overridden weak alias allow the function to be optimized away by the
linker if function-sections/gc-sections is used?)

Eventually all boards should just provide their own board_init_f,
which could just consist of a call to a common board init helper
function.  Or possibly a preprocessor define could be used to indicate
that the common function should be used.

-Scott

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

Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

In message <1288104730-25651-1-git-send-email...@denx.de> you wrote:
> CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
> being able to use "sizeof(struct global_data)" in assembler files.
> Recent experience has shown that manual synchronization is not
> reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
> GENERATED_GBL_DATA_SIZE which gets automatically generated by the
> asm-offsets tool.  In the result, all definitions of this value can be
> deleted from the board config files.  We have to make sure that all
> files that reference such data include the new  file.
> 
> No other changes have been done yet, but it is obvious that similar
> changes / simplifications can be done for other, related macro
> definitions as well.
> 
> Signed-off-by: Wolfgang Denk 
> ---
> v2: round global data size up to a multiple of 16 to guarantee
> sufficient alignment of the initial stack.

Applied, 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
Is a computer language with goto's totally Wirth-less?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3 v2] include/asm-offsets.h: automatically generate assembler constants

[Wolfgang Denk]

In message <1288102798-5475-1-git-send-email...@denx.de> you wrote:
> A recurrent issue is that certain C level constructs like sizeof() or
> offsetof() cannot be used in assembler files, which is inconvenient
> when such constructs are used in the definition of macro names etc.
> 
> To avoid duplication of such definitions (and thus another cause of
> problems), we adapt the Linux way to automatically generate the
> respective definitions from the respective C header files.
> 
> In Linux, this is implemented in include/linux/kbuild.h, Kbuild, and
> arch/*/kernel/asm-offsets.c; we adapt the code from the Linux v2.6.36
> kernel tree.
> 
> We also copy the concept of the include/generated/ directory which can
> be used to hold other automatically generated files as well.
> 
> We start with an architecture-independent lib/asm-offsets.c which
> generates include/generated/generic-asm-offsets.h (included by
> include/asm-offsets.h, which is what will be referred to in the actual
> source code).  Later this may be extended by architecture-specific
> arch/*/lib/asm-offsets.c files that will generate a
> include/generated/asm-offsets.h.
> 
> Signed-off-by: Wolfgang Denk 
> ---
> v2:   fix typo
>   add SoB line

Aplied.

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
e-credibility: the non-guaranteeable likelihood that  the  electronic
data you're seeing is genuine rather than somebody's made-up crap.
- Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] Rename CONFIG_SYS_INIT_RAM_END into CONFIG_SYS_INIT_RAM_SIZE

[Wolfgang Denk]

In message <1288101601-24871-2-git-send-email...@denx.de> you wrote:
> CONFIG_SYS_INIT_RAM_END was a misnomer as it suggests this might be
> some end address; to make the meaning more clear we rename it into
> CONFIG_SYS_INIT_RAM_SIZE
> 
> No other code changes are performed in this patch, only minor editing
> of white space (due to the changed length) and the comments was done,
> where noticed.
> 
> Note that the code for the PATI and cmi_mpc5xx board configurations
> looks seriously broken.  Last known maintainers on Cc:
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Denis Peter 
> Cc: Martin Winistoerfer 

Applied.

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
Disobedience:  The silver lining to the cloud of servitude.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Mike Frysinger,

In message <1288058944-10850-1-git-send-email-vap...@gentoo.org> you wrote:
> The following changes since commit c163f4478ca72f51b28b55f74addc8fe029d7b83:
> 
>   Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2010-10-25 
> 08:06:52 +0200)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-blackfin.git master
> 
> Mike Frysinger (2):
>   Blackfin: bf527-ezkit-v2: move to boards.cfg
>   Blackfin: adi boards: set compiled size limits
> 
>  MAKEALL   |4 +---
>  Makefile  |8 
>  boards.cfg|1 +
>  include/configs/bf548-ezkit.h |1 +
>  include/configs/bfin_adi_common.h |3 +++
>  5 files changed, 6 insertions(+), 11 deletions(-)

Applied, 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
The optimum committee has no members.
   - Norman Augustine
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-ppc4xx/master

[Wolfgang Denk]

Dear Stefan Roese,

In message <201010251732.17729...@denx.de> you wrote:
> The following changes since commit c163f4478ca72f51b28b55f74addc8fe029d7b83:
> 
>   Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2010-10-25 
> 08:06:52 +0200)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Dirk Eibach (1):
>   ppc4xx: Add Io and IoCon 405EP board support

Applied, 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
God made machine language; all the rest is the work of man.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-i2c

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4cc51ed5.8040...@denx.de> you wrote:
> Hello Wolfgang,
> 
> The following changes since commit fff6ec382c139eb242bd85356e66a0bc43becb63:
> 
>   Fix building for 83xx boards with USB support (2010-10-21 20:00:41 +0200)
> 
> are available in the git repository at:
>   git://git.denx.de/u-boot-i2c.git master
> 
> Steve Sakoman (1):
>   ARMV7: OMAP: I2C driver: Fix bug found in 37XX testing
> 
>  drivers/i2c/omap24xx_i2c.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, 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
There is a biblical analogy I'd like to draw here.   Casts are to C++
Programmers what the apple was to Eve. - Scott Douglas Meyers
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] ARM: Use consistent assembler syntax

[Wolfgang Denk]

Dear Gray Remlin,

In message <4cc44e47.2050...@rocketmail.com> you wrote:
> 
> Signed-off-by: Gray Remlin 
> ---
> Patch V3  Subject line correction change to patch v2 from
> "arm926ejs: Fix two occurrences of illegal syntax assembler instructions"
> originally used in patch v1, as it now impacts more than one CPU type.
> 
> 
>  arch/arm/cpu/arm1136/start.S   |4 ++--
>  arch/arm/cpu/arm926ejs/start.S |4 ++--
>  arch/arm/cpu/armv7/start.S |4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
> index 29ed065..0425b54 100644
> --- a/arch/arm/cpu/arm1136/start.S
> +++ b/arch/arm/cpu/arm1136/start.S
> @@ -238,7 +238,7 @@ copy_loop:
> add r3, r3, r0  /* r3 <- rel dyn end in FLASH */
>  fixloop:
> ldr r0, [r2]/* r0 <- location to fix up, IN FLASH! */
> -   add r0, r9  /* r0 <- location to fix up in RAM */
> +   add r0, r0, r9  /* r0 <- location to fix up in RAM */
> ldr r1, [r2, #4]
> and r8, r1, #0xff
> cmp r8, #23 /* relative fixup? */
> @@ -252,7 +252,7 @@ fixabs:
> mov r1, r1, LSR #4  /* r1 <- symbol index in .dynsym */
> add r1, r10, r1 /* r1 <- address of symbol in
> table */

Your patch is line wrapped and white space corrupted. I applied it
manually, but please fix your mailer, or, even better, use "git
send-email" to submit patches.

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
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] hcu4, hcu5: fix out of tree building

[Wolfgang Denk]

In message <1287931883-19065-1-git-send-email...@denx.de> you wrote:
> Out of tree building of the Netstal hcu4 and hcu5 boards failed like
> that:
> 
> Assembler messages:
> Fatal error: can't create 
> /work/wd/tmp-ppc/board/netstal/hcu4/../common/fixed_sdram.o: No such file or 
> directory
> Assembler messages:
> Fatal error: can't create 
> /work/wd/tmp-ppc/board/netstal/hcu4/../common/nm_bsp.o: No such file or 
> directory
> make[1]: *** [/work/wd/tmp-ppc/board/netstal/hcu4/../common/fixed_sdram.o] 
> Error 2
> 
> Adapt (and simplify) the respective Makefiles.
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Niklaus Giger 
> ---
>  board/netstal/hcu4/Makefile |   20 ++--
>  board/netstal/hcu5/Makefile |   17 +
>  2 files changed, 19 insertions(+), 18 deletions(-)

Applied.

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
It would seem that evil retreats when forcibly confronted
-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MPC8315ERD: fix build error

[Wolfgang Denk]

In message <1287929649-19180-1-git-send-email...@denx.de> you wrote:
> Commit 29c6fbe "MPC5121: Add USB EHCI support" renamed
> CONFIG_SYS_MPC8xxx_USB_ADDR into CONFIG_SYS_FSL_USB_ADDR but missed
> to update arch/powerpc/cpu/mpc83xx/cpu_init.c, resulting in:
> 
> cpu_init.c: In function 'cpu_init_f':
> cpu_init.c:332: error: 'CONFIG_SYS_MPC8xxx_USB_ADDR' undeclared (first use in 
> this function)
> cpu_init.c:332: error: (Each undeclared identifier is reported only once
> cpu_init.c:332: error: for each function it appears in.)
> make[1]: *** [/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/cpu_init.o] Error 1
> 
> Fix this.
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Kim Phillips 
> ---
>  arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied.

Hope this is OK with you, Kim?

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
Well, the way I see it, logic is only a way of being ignorant by num-
bers. - Terry Pratchett, _Small Gods_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] VoVPN-GW_100MHz: drop unsupported board configuration

[Wolfgang Denk]

In message <1287928835-5279-1-git-send-email...@denx.de> you wrote:
> The 100MHz configuation of the VoVPN-GW has never been supported, so
> drop it now.
> 
> Signed-off-by: Wolfgang Denk 
> ---
> 
> This commit shows a problem with the concept of the "README.scrapyard"
> file: I'm supposed to enter the commit ID for the commit I'm just
> about to check in; this cannot work.  Hope we remember to clean this
> up when making the next entries...
> 
> Anybody having any better ideas?  Some clever git attributes trick?
> 
>  boards.cfg   |1 -
>  doc/README.scrapyard |1 +
>  2 files changed, 1 insertions(+), 1 deletions(-)

Aoolied, 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
I'd rather be led to hell than managed to heaven.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] lite5200b_PM: fix compile warning

[Wolfgang Denk]

In message <1287928052-28981-1-git-send-email...@denx.de> you wrote:
> Fix warning:
> 
> icecube.c: In function 'lite5200b_wakeup':
> icecube.c:83: warning: format '%08lx' expects type 'long unsigned int', but 
> argument 2 has type 'void (*)(void)'
> 
> Signed-off-by: Wolfgang Denk 
> ---
>  board/icecube/icecube.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied.

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
There are three ways to get something  done:  do  it  yourself,  hire
someone, or forbid your kids to do it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Timer implementations

[Reinhard Meyer]

On 26.10.2010 18:26, Wolfgang Denk wrote:
> Dear Nishanth Menon,
>
> In message<4cc6f23a.2040...@ti.com>  you wrote:
>>
>>> No. This code is always wrong. Please fix it as described.
>> Apologies on being a dudhead, I suppose you mean the following:
>>
>> ulong start;
>> start = get_timer(0);
>> while (!(readl(&mmc_base->stat)&  CC_MASK)) {
>>   if (get_timer(start)>  usec2ticks(MAX_RETRY_US)) {
>>   printf("%s: timedout waiting for cc2!\n", __func__);
>>   return;
>>   }
>> }
>>
>> would this be better?
>
> No, not at all, as get_timer() returns milliseconds, not ticks.
>
> You probably want something like:
>
>   ulong start = get_timer(0);
>
>   while (!(readl(&mmc_base->stat)&  CC_MASK)) {
>   if (get_timer(0) - start>= MAX_RETRY_US/1000) {
>   printf(...);
>   return;
>   }
>   udelay(100);
>   }

This will work, of course, but the original semantics of get_timer()
seems to be:

ulong start = get_timer(0);

loop {
if (get_timer(start) >= timeout_in_ms)
we_have_timeout();
}

--> get_timer(x) returns (time - x)

the subtraction is done internally.

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

[U-Boot] [PATCH v3] mmc: omap: timeout counter fix

[Nishanth Menon]

Having a loop with a counter is no timing guarentee for timing
accuracy or compiler optimizations. For e.g. the same loop counter
which runs when the MPU is running at 600MHz will timeout in around
half the time when running at 1GHz. or the example where GCC 4.5
compiles with different optimization compared to GCC 4.4. use timer
to keep track of time elapse and we use an emperical number - 1sec
for a worst case timeout.  This should never happen, and is adequate
imaginary condition for us to fail with timeout.

Signed-off-by: Nishanth Menon 
---
V3: changed the delay logic, removed udelays which was introduced in
v2 as the intent was purely to have predictable time delays. the timer
logic is based on the discussion in ML using get_timer

V2: http://www.mail-archive.com/u-boot@lists.denx.de/msg40972.html
additional cleanups + made MAX_RETRY a macro for reuse throughout
the file. tested on PandaBoard with 1GHz boot frequency and GCC4.5 on
u-boot 2010.09 + mmc patches. Requesting testing on other platforms

V1: http://www.mail-archive.com/u-boot@lists.denx.de/msg40969.html

 drivers/mmc/omap_hsmmc.c |  107 +++---
 1 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 9271470..5271794 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -31,6 +31,9 @@
 #include 
 #include 
 
+/* If we fail after 1 second wait, something is really bad */
+#define MAX_RETRY_MS   1000
+
 static int mmc_read_data(hsmmc_t *mmc_base, char *buf, unsigned int size);
 static int mmc_write_data(hsmmc_t *mmc_base, const char *buf, unsigned int 
siz);
 static struct mmc hsmmc_dev[2];
@@ -70,18 +73,29 @@ unsigned char mmc_board_init(hsmmc_t *mmc_base)
 
 void mmc_init_stream(hsmmc_t *mmc_base)
 {
+   ulong start;
 
writel(readl(&mmc_base->con) | INIT_INITSTREAM, &mmc_base->con);
 
writel(MMC_CMD0, &mmc_base->cmd);
-   while (!(readl(&mmc_base->stat) & CC_MASK))
-   ;
+   start = get_timer(0);
+   while (!(readl(&mmc_base->stat) & CC_MASK)) {
+   if (get_timer(0) - start > MAX_RETRY_MS) {
+   printf("%s: timedout waiting for cc!\n", __func__);
+   return;
+   }
+   }
writel(CC_MASK, &mmc_base->stat)
;
writel(MMC_CMD0, &mmc_base->cmd)
;
-   while (!(readl(&mmc_base->stat) & CC_MASK))
-   ;
+   start = get_timer(0);
+   while (!(readl(&mmc_base->stat) & CC_MASK)) {
+   if (get_timer(0) - start > MAX_RETRY_MS) {
+   printf("%s: timedout waiting for cc2!\n", __func__);
+   return;
+   }
+   }
writel(readl(&mmc_base->con) & ~INIT_INITSTREAM, &mmc_base->con);
 }
 
@@ -91,16 +105,28 @@ static int mmc_init_setup(struct mmc *mmc)
hsmmc_t *mmc_base = (hsmmc_t *)mmc->priv;
unsigned int reg_val;
unsigned int dsor;
+   ulong start;
 
mmc_board_init(mmc_base);
 
writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
&mmc_base->sysconfig);
-   while ((readl(&mmc_base->sysstatus) & RESETDONE) == 0)
-   ;
+   start = get_timer(0);
+   while ((readl(&mmc_base->sysstatus) & RESETDONE) == 0) {
+   if (get_timer(0) - start > MAX_RETRY_MS) {
+   printf("%s: timedout waiting for cc2!\n", __func__);
+   return TIMEOUT;
+   }
+   }
writel(readl(&mmc_base->sysctl) | SOFTRESETALL, &mmc_base->sysctl);
-   while ((readl(&mmc_base->sysctl) & SOFTRESETALL) != 0x0)
-   ;
+   start = get_timer(0);
+   while ((readl(&mmc_base->sysctl) & SOFTRESETALL) != 0x0) {
+   if (get_timer(0) - start > MAX_RETRY_MS) {
+   printf("%s: timedout waiting for softresetall!\n",
+   __func__);
+   return TIMEOUT;
+   }
+   }
writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, &mmc_base->hctl);
writel(readl(&mmc_base->capa) | VS30_3V0SUP | VS18_1V8SUP,
&mmc_base->capa);
@@ -116,8 +142,13 @@ static int mmc_init_setup(struct mmc *mmc)
(ICE_STOP | DTO_15THDTO | CEN_DISABLE));
mmc_reg_out(&mmc_base->sysctl, ICE_MASK | CLKD_MASK,
(dsor << CLKD_OFFSET) | ICE_OSCILLATE);
-   while ((readl(&mmc_base->sysctl) & ICS_MASK) == ICS_NOTREADY)
-   ;
+   start = get_timer(0);
+   while ((readl(&mmc_base->sysctl) & ICS_MASK) == ICS_NOTREADY) {
+   if (get_timer(0) - start > MAX_RETRY_MS) {
+   printf("%s: timedout waiting for ics!\n", __func__);
+   return TIMEOUT;
+   }
+   }
writel(readl(&mmc_base->sysctl) | CEN_ENABLE, &mmc_base->sysctl);
 
writel(readl(&mmc_base->hctl) | SDBP_PWRON,

[U-Boot] [PATCH 3/3 V3] Add board support for hawkboard

[Sughosh Ganu]

The patch adds basic board support for TI's OMAP-L138 based
Hawkboard. This board is pretty similar to the da850 EVM. Support for
nand and network access is added in this version.

The following bootup procedure is used.

At reset, the Rom Boot Loader(RBL), initialises the ddr and the nand
controllers and copies the second stage bootloader(nand_spl) to
RAM. The secondary bootloader then copies u-boot from a predefined
location in the nand flash to the RAM, and passes control to the
u-boot image.

Three config options are supported
* hawkboard_config - Used to create the u-boot.bin. Tftp the
 u-boot.bin image to the RAM from u-boot, and flash to the nand flash
 at address 0xe.

* hawkboard_nand_config - Used to generate the secondary
 bootloader(nand_spl) image. This creates an elf file u-boot-spl
 under nand_spl/. Create an AIS signed image using this file, and
 flash it to the nand flash at address 0x2. The ais file should
 fit in one block.

* hawkboard_uart_config - This is same as the first image, but with
 the TEXT_BASE as expected by the RBL(0xc108). Create the AIS
 Signed bin, as use the normal UART boot procedure to boot the image.

Signed-off-by: Sughosh Ganu 
---
Changes since V2:
   * Fix the checkpatch errors.
   * Fix the build issue on da850evm due to a missed out change.


 MAINTAINERS  |5 +
 arch/arm/include/asm/arch-davinci/da8xx_common.h |3 +
 arch/arm/include/asm/arch-davinci/hardware.h |5 +-
 board/davinci/common/Makefile|2 +-
 board/davinci/common/davinci_pinmux.c|  105 +++
 board/davinci/common/misc.c  |   75 
 board/davinci/da8xxevm/Makefile  |2 +
 board/davinci/da8xxevm/hawkboard.c   |   69 
 board/davinci/da8xxevm/hawkboard_nand_spl.c  |  164 +
 boards.cfg   |3 +
 drivers/mtd/nand/davinci_nand.c  |1 +
 include/configs/hawkboard.h  |  205 ++
 nand_spl/board/davinci/da8xxevm/Makefile |  141 +++
 nand_spl/board/davinci/da8xxevm/u-boot.lds   |   75 
 14 files changed, 778 insertions(+), 77 deletions(-)
 create mode 100644 board/davinci/common/davinci_pinmux.c
 create mode 100644 board/davinci/da8xxevm/hawkboard.c
 create mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
 create mode 100644 include/configs/hawkboard.h
 create mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
 create mode 100644 nand_spl/board/davinci/da8xxevm/u-boot.lds

diff --git a/MAINTAINERS b/MAINTAINERS
index b0da631..d7efc71 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -849,6 +849,11 @@ Alex Z
lartSA1100
dnp1110 SA1110
 
+Syed Mohammed Khasim 
+Sughosh Ganu 
+
+   hawkboard   ARM926EJS (OMAP-L138)
+
 -
 
 Unknown / orphaned boards:
diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h 
b/arch/arm/include/asm/arch-davinci/da8xx_common.h
index 7ae63a6..bc3092d 100644
--- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
+++ b/arch/arm/include/asm/arch-davinci/da8xx_common.h
@@ -19,6 +19,9 @@
 #ifndef __COMMON_H
 #define __COMMON_H
 
+#defineHAWKBOARD_KICK0_UNLOCK  0x83e70b13
+#defineHAWKBOARD_KICK1_UNLOCK  0x95a4f1e0
+
 struct lpsc_resource {
const int   lpsc_no;
 };
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h 
b/arch/arm/include/asm/arch-davinci/hardware.h
index 3520cf8..d006ac1 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -379,7 +379,10 @@ int clk_get(enum davinci_clk_ids id);
 /* Boot config */
 struct davinci_syscfg_regs {
dv_reg  revid;
-   dv_reg  rsvd[71];
+   dv_reg  rsvd[13];
+   dv_reg  kick0;
+   dv_reg  kick1;
+   dv_reg  rsvd1[56];
dv_reg  pinmux[20];
dv_reg  suspsrc;
dv_reg  chipsig;
diff --git a/board/davinci/common/Makefile b/board/davinci/common/Makefile
index 8d9ea00..dd022f6 100644
--- a/board/davinci/common/Makefile
+++ b/board/davinci/common/Makefile
@@ -29,7 +29,7 @@ endif
 
 LIB= $(obj)lib$(VENDOR).a
 
-COBJS  := misc.o
+COBJS  := misc.o davinci_pinmux.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
diff --git a/board/davinci/common/davinci_pinmux.c 
b/board/davinci/common/davinci_pinmux.c
new file mode 100644
index 000..ce58f71
--- /dev/null
+++ b/board/davinci/common/davinci_pinmux.c
@@ -0,0 +1,105 @@
+/*
+ * DaVinci pinmux functions.
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc Ltd, 
+ * Copyright (C) 2007 Sergey Kubushyn 
+ * Copyright (C) 2008 Lyrtech 
+ * Copyright (C) 2004 Texas Instruments.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software

[U-Boot] [PATCH 2/3 V3] Make board_init_f under nand_boot.c a weak function

[Sughosh Ganu]

 Enable board_init_f to be overridden with a board
 specific function.

Signed-off-by: Sughosh Ganu 
---
Changes since V2:
  * Fix the checkpatch warnings

 nand_spl/nand_boot.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index ccd0af2..01ff3e3 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -222,11 +222,13 @@ static int nand_load(struct mtd_info *mtd, unsigned int 
offs,
 }
 
 #if defined(CONFIG_ARM) && !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
-void board_init_f (ulong bootflag)
+void __board_init_f(ulong bootflag)
 {
-   relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
-  CONFIG_SYS_TEXT_BASE);
+   relocate_code(CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
+   CONFIG_SYS_TEXT_BASE);
 }
+void board_init_f(ulong bootflag)__attribute__((weak,
+alias("__board_init_f")));
 #endif
 
 /*
-- 
1.7.0.4

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

[U-Boot] [PATCH 1/3 V3] Move and rename common headers from under board/davinci.

[Sughosh Ganu]

 Move the davinci common headers to the architecture specific
 include file path.

Signed-off-by: Sughosh Ganu 
---
Changes since V2:
   * No change in this patch of the patchset

 .../arm/include/asm/arch-davinci/da8xx_common.h|0
 .../arm/include/asm/arch-davinci/davinci_misc.h|0
 board/davinci/common/misc.c|2 +-
 board/davinci/da8xxevm/common.c|2 +-
 board/davinci/da8xxevm/da830evm.c  |4 ++--
 board/davinci/da8xxevm/da850evm.c  |4 ++--
 board/davinci/dm355evm/dm355evm.c  |2 +-
 board/davinci/dm355leopard/dm355leopard.c  |2 +-
 board/davinci/dm365evm/dm365evm.c  |2 +-
 board/davinci/dvevm/dvevm.c|2 +-
 board/davinci/schmoogie/schmoogie.c|2 +-
 board/davinci/sffsdr/sffsdr.c  |2 +-
 board/davinci/sonata/sonata.c  |2 +-
 13 files changed, 13 insertions(+), 13 deletions(-)
 rename board/davinci/da8xxevm/common.h => 
arch/arm/include/asm/arch-davinci/da8xx_common.h (100%)
 rename board/davinci/common/misc.h => 
arch/arm/include/asm/arch-davinci/davinci_misc.h (100%)

diff --git a/board/davinci/da8xxevm/common.h 
b/arch/arm/include/asm/arch-davinci/da8xx_common.h
similarity index 100%
rename from board/davinci/da8xxevm/common.h
rename to arch/arm/include/asm/arch-davinci/da8xx_common.h
diff --git a/board/davinci/common/misc.h 
b/arch/arm/include/asm/arch-davinci/davinci_misc.h
similarity index 100%
rename from board/davinci/common/misc.h
rename to arch/arm/include/asm/arch-davinci/davinci_misc.h
diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
index b60a46e..71e7822 100644
--- a/board/davinci/common/misc.c
+++ b/board/davinci/common/misc.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include "misc.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c
index 9cd5204..36bf693 100644
--- a/board/davinci/da8xxevm/common.c
+++ b/board/davinci/da8xxevm/common.c
@@ -20,7 +20,7 @@
 
 #include 
 #include 
-#include "common.h"
+#include 
 
 #ifndef CONFIG_USE_IRQ
 void irq_init(void)
diff --git a/board/davinci/da8xxevm/da830evm.c 
b/board/davinci/da8xxevm/da830evm.c
index 8a9f988..b6b7e37 100644
--- a/board/davinci/da8xxevm/da830evm.c
+++ b/board/davinci/da8xxevm/da830evm.c
@@ -40,8 +40,8 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
-#include "common.h"
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index c8c5e1b..0420ad5 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -29,8 +29,8 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
-#include "common.h"
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/davinci/dm355evm/dm355evm.c 
b/board/davinci/dm355evm/dm355evm.c
index 87f284c..b9260b8 100644
--- a/board/davinci/dm355evm/dm355evm.c
+++ b/board/davinci/dm355evm/dm355evm.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
+#include 
 #include 
 #include 
 
diff --git a/board/davinci/dm355leopard/dm355leopard.c 
b/board/davinci/dm355leopard/dm355leopard.c
index e89786e..0ee0d11 100644
--- a/board/davinci/dm355leopard/dm355leopard.c
+++ b/board/davinci/dm355leopard/dm355leopard.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
+#include 
 #include 
 #include 
 
diff --git a/board/davinci/dm365evm/dm365evm.c 
b/board/davinci/dm365evm/dm365evm.c
index 85dbe2a..bc681f7 100644
--- a/board/davinci/dm365evm/dm365evm.c
+++ b/board/davinci/dm365evm/dm365evm.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/davinci/dvevm/dvevm.c b/board/davinci/dvevm/dvevm.c
index 073c21a..d5c851b 100644
--- a/board/davinci/dvevm/dvevm.c
+++ b/board/davinci/dvevm/dvevm.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/davinci/schmoogie/schmoogie.c 
b/board/davinci/schmoogie/schmoogie.c
index 80a0f9f..8b615a9 100644
--- a/board/davinci/schmoogie/schmoogie.c
+++ b/board/davinci/schmoogie/schmoogie.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/davinci/sffsdr/sffsdr.c b/board/davinci/sffsdr/sffsdr.c
index 657cf2b..cc3ff7d 100644
--- a/board/davinci/sffsdr/sffsdr.c
+++ b/board/davinci/sffsdr/sffsdr.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include "../common/misc.h"
+#include 
 
 #define DAVINCI_A3CR (0x01E00014)  /* EMIF-A CS3 config register. */
 #define DAVINCI_A3CR_VAL (0x3FFD)  /* EMIF-A CS3 value for FPGA. */
diff --git a/board/davinci/sonata/sonata.c b/board/dav

Re: [U-Boot] [PATCH V2] imx25: Fix reset

[Jason Liu]

Hi,

2010/10/26 Matthias Weißer :
> Am 26.10.2010 11:27, schrieb Reinhard Meyer:
>> Dear Matthias Weisser,
>>> This patch fixes the reset command on imx25
>>>
>>> Signed-off-by: Matthias Weisser
>>> +    writew(0x,®s->wcr);
>>> +    writew(0x,®s->wsr);
>>> +    writew(0x,®s->wsr);
>>
>> It might be "nicer" to use 16 Bit constants (with 4 hex digits)
>> here..?
>
> Sure. Would be nicer. I wait a bit for further comments and will create
> a V3 then.

Add please append to the commit log about why you make such change?
It will be clear to read and understand your change for this patch.

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

Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201010261117.56528.vap...@gentoo.org> you wrote:
>
> On Tuesday, October 26, 2010 10:00:01 Wolfgang Denk wrote:
> > --- a/arch/blackfin/include/asm/config.h
> > +++ b/arch/blackfin/include/asm/config.h
> > -#ifndef CONFIG_SYS_GBL_DATA_SIZE
> > -# define CONFIG_SYS_GBL_DATA_SIZE (128)
> > +#ifndef GENERATED_GBL_DATA_SIZE
> >  #endif
> 
> might as well delete this whole construct

OK, will do on check-in.

> otherwise, the rest of the Blackfin stuff looks sane to me

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
Quotation, n. The act of repeating erroneously the words of  another.
The  words  erroneously  repeated.
- Ambrose Bierce _The Devil's Dictionary_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Timer implementations

[Wolfgang Denk]

Dear Nishanth Menon,

In message <4cc6f23a.2040...@ti.com> you wrote:
>
> > No. This code is always wrong. Please fix it as described.
> Apologies on being a dudhead, I suppose you mean the following:
> 
> ulong start;
> start = get_timer(0);
> while (!(readl(&mmc_base->stat) & CC_MASK)) {
>  if (get_timer(start) > usec2ticks(MAX_RETRY_US)) {
>  printf("%s: timedout waiting for cc2!\n", __func__);
>  return;
>  }
> }
> 
> would this be better?

No, not at all, as get_timer() returns milliseconds, not ticks.

You probably want something like:

ulong start = get_timer(0);

while (!(readl(&mmc_base->stat) & CC_MASK)) {
if (get_timer(0) - start >= MAX_RETRY_US/1000) {
printf(...);
return;
}
udelay(100);
}

or such.

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
He had quite a powerful intellect, but it  was  as  powerful  like  a
locomotive,  and  ran on rails and was therefore almost impossible to
steer.  - Terry Pratchett, _Lords and Ladies_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Road sweeper

[KELVIN BROWN]

 Hello,good morning,
   My name is kelvin brown and i want to make an order
enquirer about road sweeper, and i want RS-48 Single Sweep Fodmaster and i
want to know the types and models you
 do have and also with the prices and types of payment you do accepts.Thanks
hope to hear from you soon.


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

Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot

[Loïc Minier]

On Tue, Oct 26, 2010, Premi, Sanjeev wrote:
> [sp] Didn't hear any other suggestions. But I had one more,
>  CONFIG_QUICK_BOOT.

 I don't have a strong feeling either way; I just wanted "fastboot" to
 be used in a confusing way.  Your patch seems to be largely a tuned
 u-boot config stripping down u-boot to be smaller and faster; I'm not
 sure whether there's anything similar in u-boot.

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

Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Stefan Roese]

Hi Wolfgang,

On Tuesday 26 October 2010 16:41:07 Wolfgang Denk wrote:
> You are right, especially as the resulting start address of the global
> data is usually also used as the top of the internal stack. Guess we
> should align it on 16 bytes, to be sure.

Yes, we already had this 8-byte stack align problem on ARM, IIRC.
 
> BTW - this uncovers a number of other problems.
> 
> commit 800eb096 "POST cleanup." inserts a single data word between
> global data and initial stack, thus also breaking stack alignment.
> 
> I think this approach is wrong, the POST word should be made part of
> the global_data instead.

Good idea.
 
Cheers,
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] Timer implementations

[Nishanth Menon]

Wolfgang Denk had written, on 10/26/2010 10:17 AM, the following:
> Dear Nishanth Menon,
> 
> In message <4cc6efb1.9000...@ti.com> you wrote:
>> uint64_t etime; /* actually this could be u32 */
>>
>> etime = get_ticks() + usec2ticks(MAX_RETRY_US);
>> while (!(readl(&mmc_base->stat) & CC_MASK)) {
>>  if (get_ticks() <= etime) {
>>  printf("%s: timedout waiting for cc2!\n", __func__);
>>  return;
>>  }
>> }
>>
>> sounds right?
> 
> No. This code is always wrong. Please fix it as described.
Apologies on being a dudhead, I suppose you mean the following:

ulong start;
start = get_timer(0);
while (!(readl(&mmc_base->stat) & CC_MASK)) {
 if (get_timer(start) > usec2ticks(MAX_RETRY_US)) {
 printf("%s: timedout waiting for cc2!\n", __func__);
 return;
 }
}

would this be better?

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

Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Mike Frysinger]

On Tuesday, October 26, 2010 10:00:01 Wolfgang Denk wrote:
> --- a/arch/blackfin/include/asm/config.h
> +++ b/arch/blackfin/include/asm/config.h
> -#ifndef CONFIG_SYS_GBL_DATA_SIZE
> -# define CONFIG_SYS_GBL_DATA_SIZE (128)
> +#ifndef GENERATED_GBL_DATA_SIZE
>  #endif

might as well delete this whole construct

otherwise, the rest of the Blackfin stuff looks sane to me
-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] Timer implementations

[Wolfgang Denk]

Dear Nishanth Menon,

In message <4cc6efb1.9000...@ti.com> you wrote:
>
> uint64_t etime; /* actually this could be u32 */
> 
> etime = get_ticks() + usec2ticks(MAX_RETRY_US);
> while (!(readl(&mmc_base->stat) & CC_MASK)) {
>  if (get_ticks() <= etime) {
>  printf("%s: timedout waiting for cc2!\n", __func__);
>  return;
>  }
> }
> 
> sounds right?

No. This code is always wrong. Please fix it as described.

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 first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Timer implementations

[Nishanth Menon]

Reinhard Meyer had written, on 10/26/2010 02:57 AM, the following:
> Wolfgang Denk schrieb:
>> Dear Reinhard Meyer,
>>
>> In message <4cc67ca1.9090...@emk-elektronik.de> you wrote:
>>> If implemented with true 64 bits for get_ticks() that function is useable
>>> for timeout programming:
>>>
>>> ulong timeval = get_timer (0);
>>>
>>> do {
>>> ...
>>> } while (get_timer (timeval) < TIMEOUT);
>>>
>>> It appears that the "base" parameter and return value is in CONFIG_SYS_HZ
>>> units, and not in native ticks. That causes 64 bit mul/div every
>>> time get_timer() is called. Won't hurt in a timeout loop, though.
>> But it will hurt in othe rplaces.
>>
>> Also, this code _is_ a bit different, as "get_timer(0)" makes sure
>> the counter starts ticking again at 0
> 
> Nope, it does not reset the counter itself. It returns the current
> counter value (recalculated into CONFIG_SYS_HZ units).
> Maybe you mean reset_timer() instead?
> 
> In arm9226ejs/omap/timer.c udelay() is implemented with reset_timer()
> and get_timer(). Since those functions are inherently not nestable,
> beware of base=get_timer(0); do { ... udelay(xx); ... } while 
> (get_timer(base) < TIMEOUT);
> constructs!
At least the omap3+ code arch/arm/cpu/armv7/omap-common/timer.c
__udelay() does'nt seem to reset the timer
BUT,
unsigned long long get_ticks(void)
{
 return get_timer(0);
}
ulong get_timer(ulong base)
{return get_timer_masked() - base;
}
ulong get_timer_masked(void)
{
 /* current tick value */
 ulong now = readl(&timer_base->tcrr) / (TIMER_CLOCK / 
CONFIG_SYS_HZ);

 if (now >= lastinc) /* normal mode (non roll) */
 /* move stamp fordward with absoulte diff ticks */
 timestamp += (now - lastinc);
 else/* we have rollover of incrementer */
 timestamp += ((TIMER_LOAD_VAL / (TIMER_CLOCK / 
CONFIG_SYS_HZ))
 - lastinc) + now;
 lastinc = now;
 return timestamp;
}

if I am not mistaken, this is 32bit long.. but since we have as wdenk 
mentions below a 2^32 tick duration, we can safely go with an option 
such as:
/* If we fail after 1 second wait, something is really bad */
#define MAX_RETRY_US(1 * 1000 * 1000)

uint64_t etime; /* actually this could be u32 */

etime = get_ticks() + usec2ticks(MAX_RETRY_US);
while (!(readl(&mmc_base->stat) & CC_MASK)) {
 if (get_ticks() <= etime) {
 printf("%s: timedout waiting for cc2!\n", __func__);
 return;
 }
}

sounds right?

> 
>> , and get_timer() is defined to
>> have millisecond resolution.
> 
> Actually CONFIG_SYS_HZ (whatever that is).
> 
>> So you have a guaranteed 2^32
>> milliseconds or 4294967 seconds or about 3.3 years available which
>> indeed should be sufficient to implement standard timeouts.
> 
> I think it is necessary to summarize all implicit or explicit documented
> "defined to have's" regarding the timer and then to verify that all
> implementations adhere to them.
> 
yes indeed.. :(

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

Re: [U-Boot] [PATCH 3/3 V2] Add support for hawkboard

[sughosh ganu]

hi Ben,

On Tue, Oct 26, 2010 at 6:41 PM, Ben Gardiner wrote:

> ../sugosh-da8xx-v2/3of3.patch has style problems, please review.  If
> any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> I was also unable to build the da850evm u-boot with this patch applied:
> $make mrproper ; make da850evm_config ; make -j9 all|grep -E '( error|
> warning)'
> awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }'
> boards.cfg > .boards.depend
> Configuring for da850evm board...
> davinci_pinmux.c:30:26: error: davinci_misc.h: No such file or directory
> make[1]: *** No rule to make target `.depend', needed by `libdavinci.a'.
>  Stop.
> make: *** [board/davinci/common/libdavinci.a] Error 2
> make: *** Waiting for unfinished jobs
> make: *** wait: No child processes.  Stop.
>
> For your next patch submission, I recommend running checkpatch.pl
> (from a recent linux kernel scripts/ directory) on your patches and
> also using the ./MAKEALL script [1] to test that your changes haven't
> broken other boards.
>

 Thanks a lot for the testing. Will check the patches with checkpatch script
while posting the next version.

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

[U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
being able to use "sizeof(struct global_data)" in assembler files.
Recent experience has shown that manual synchronization is not
reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
GENERATED_GBL_DATA_SIZE which gets automatically generated by the
asm-offsets tool.  In the result, all definitions of this value can be
deleted from the board config files.  We have to make sure that all
files that reference such data include the new  file.

No other changes have been done yet, but it is obvious that similar
changes / simplifications can be done for other, related macro
definitions as well.

Signed-off-by: Wolfgang Denk 
---
v2: round global data size up to a multiple of 16 to guarantee
sufficient alignment of the initial stack.

 ... [other files unchanged, suppressed to reduce size] ...
 lib/asm-offsets.c  |4 
 560 files changed, 519 insertions(+), 955 deletions(-)

... [other files unchanged, suppressed to reduce size] ...

diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
index 4eb6174..0bc70ab 100644
--- a/lib/asm-offsets.c
+++ b/lib/asm-offsets.c
@@ -21,5 +21,9 @@
 
 int main(void)
 {
+   /* Round up to make sure size gives nice stack alignment */
+   DEFINE(GENERATED_GBL_DATA_SIZE,
+   (sizeof(struct global_data)+15) & ~15);
+
return 0;
 }
-- 
1.7.2.3

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

Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Wolfgang Denk]

Dear Stefan Roese,

In message <201010261622.57768...@denx.de> you wrote:
> 
> One thing that comes to my mind while looking into this patchset is, if we 
> need to make sure that the replacement for CONFIG_SYS_GBL_DATA_SIZE is 
> (still) 
> aligned. Till now CONFIG_SYS_GBL_DATA_SIZE has been defined mostly to 
> something like 64/128/256. Now with using sizeof(struct global_data) this is 
> may not the case any more. Perhaps I'm missing something (didn't look through 
> the patchset too closely), but shouldn't we make sure that the new values 
> used 
> for the memory-reservation is at least 4-byte aligned?

You are right, especially as the resulting start address of the global
data is usually also used as the top of the internal stack. Guess we
should align it on 16 bytes, to be sure.

BTW - this uncovers a number of other problems.

commit 800eb096 "POST cleanup." inserts a single data word between
global data and initial stack, thus also breaking stack alignment.

I think this approach is wrong, the POST word should be made part of
the global_data instead.

[This was one of the reasons I did not replace
CONFIG_SYS_GBL_DATA_OFFSET yet, which usually is always
"(CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)", nor
CONFIG_SYS_INIT_SP_OFFSET, which usually is the same as
CONFIG_SYS_GBL_DATA_OFFSET.] 

Patch v3 following.

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
Witch!  Witch!  They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Kumar Gala]

On Oct 26, 2010, at 9:22 AM, Stefan Roese wrote:

> Hi Wolfgang,
> 
> On Tuesday 26 October 2010 16:00:01 Wolfgang Denk wrote:
>> CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
>> being able to use "sizeof(struct global_data)" in assembler files.
>> Recent experience has shown that manual synchronization is not
>> reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
>> GENERATED_GBL_DATA_SIZE which gets automatically generated by the
>> asm-offsets tool.  In the result, all definitions of this value can be
>> deleted from the board config files.  We have to make sure that all
>> files that reference such data include the new  file.
>> 
>> No other changes have been done yet, but it is obvious that similar
>> changes / simplifications can be done for other, related macro
>> definitions as well.
> 
> Nice. Thanks all for this work.
> 
> One thing that comes to my mind while looking into this patchset is, if we 
> need to make sure that the replacement for CONFIG_SYS_GBL_DATA_SIZE is 
> (still) 
> aligned. Till now CONFIG_SYS_GBL_DATA_SIZE has been defined mostly to 
> something like 64/128/256. Now with using sizeof(struct global_data) this is 
> may not the case any more. Perhaps I'm missing something (didn't look through 
> the patchset too closely), but shouldn't we make sure that the new values 
> used 
> for the memory-reservation is at least 4-byte aligned?
> 

I was wondering about this too, and since most of these are used to define 
CONFIG_SYS_INIT_SP_OFFSET, we probably need stack level alignment.

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

Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value

[Stefan Roese]

Hi Wolfgang,

On Tuesday 26 October 2010 16:00:01 Wolfgang Denk wrote:
> CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
> being able to use "sizeof(struct global_data)" in assembler files.
> Recent experience has shown that manual synchronization is not
> reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
> GENERATED_GBL_DATA_SIZE which gets automatically generated by the
> asm-offsets tool.  In the result, all definitions of this value can be
> deleted from the board config files.  We have to make sure that all
> files that reference such data include the new  file.
> 
> No other changes have been done yet, but it is obvious that similar
> changes / simplifications can be done for other, related macro
> definitions as well.

Nice. Thanks all for this work.

One thing that comes to my mind while looking into this patchset is, if we 
need to make sure that the replacement for CONFIG_SYS_GBL_DATA_SIZE is (still) 
aligned. Till now CONFIG_SYS_GBL_DATA_SIZE has been defined mostly to 
something like 64/128/256. Now with using sizeof(struct global_data) this is 
may not the case any more. Perhaps I'm missing something (didn't look through 
the patchset too closely), but shouldn't we make sure that the new values used 
for the memory-reservation is at least 4-byte aligned?

Thanks.

Cheers,
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

[U-Boot] [PATCH 2/3 v2] include/asm-offsets.h: automatically generate assembler constants

[Wolfgang Denk]

A recurrent issue is that certain C level constructs like sizeof() or
offsetof() cannot be used in assembler files, which is inconvenient
when such constructs are used in the definition of macro names etc.

To avoid duplication of such definitions (and thus another cause of
problems), we adapt the Linux way to automatically generate the
respective definitions from the respective C header files.

In Linux, this is implemented in include/linux/kbuild.h, Kbuild, and
arch/*/kernel/asm-offsets.c; we adapt the code from the Linux v2.6.36
kernel tree.

We also copy the concept of the include/generated/ directory which can
be used to hold other automatically generated files as well.

We start with an architecture-independent lib/asm-offsets.c which
generates include/generated/generic-asm-offsets.h (included by
include/asm-offsets.h, which is what will be referred to in the actual
source code).  Later this may be extended by architecture-specific
arch/*/lib/asm-offsets.c files that will generate a
include/generated/asm-offsets.h.

Signed-off-by: Wolfgang Denk 
---
v2: fix typo
add SoB line

 .gitignore |3 +++
 Makefile   |   21 +++--
 include/asm-offsets.h  |2 ++
 include/linux/kbuild.h |   20 
 lib/asm-offsets.c  |   25 +
 tools/scripts/make-asm-offsets |   27 +++
 6 files changed, 96 insertions(+), 2 deletions(-)
 create mode 100644 include/asm-offsets.h
 create mode 100644 include/linux/kbuild.h
 create mode 100644 lib/asm-offsets.c
 create mode 100755 tools/scripts/make-asm-offsets

diff --git a/.gitignore b/.gitignore
index 67d2cd6..e71f6ac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -40,6 +40,9 @@
 /errlog
 /reloc_off
 
+/include/generated/
+/lib/asm-offsets.s
+
 # stgit generated dirs
 patches-*
 .stgit-edit.txt
diff --git a/Makefile b/Makefile
index f8e13d7..6e146d4 100644
--- a/Makefile
+++ b/Makefile
@@ -372,7 +372,8 @@ GEN_UBOOT = \
cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
-$(obj)u-boot:  depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) 
$(obj)u-boot.lds
+$(obj)u-boot:  depend \
+   $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) 
$(obj)u-boot.lds
$(GEN_UBOOT)
 ifeq ($(CONFIG_KALLSYMS),y)
smap=`$(call SYSTEM_MAP,u-boot) | \
@@ -426,7 +427,9 @@ updater:
 
 # Explicitly make _depend in subdirs containing multiple targets to prevent
 # parallel sub-makes creating .depend files simultaneously.
-depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
+depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \
+   $(obj)include/autoconf.mk \
+   $(obj)include/generated/generic-asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(dir $(LDSCRIPT)) ; do \
$(MAKE) -C $$dir _depend ; done
 
@@ -473,6 +476,18 @@ $(obj)include/autoconf.mk: $(obj)include/config.h
sed -n -f tools/scripts/define2mk.sed > $...@.tmp && \
mv $...@.tmp $@
 
+$(obj)include/generated/generic-asm-offsets.h: $(obj)include/autoconf.mk.dep \
+   $(obj)lib/asm-offsets.s
+   @$(XECHO) Generating $@
+   tools/scripts/make-asm-offsets $(obj)lib/asm-offsets.s $@
+
+$(obj)lib/asm-offsets.s:   $(obj)include/autoconf.mk.dep \
+   $(src)lib/asm-offsets.c
+   @mkdir -p $(obj)lib
+   $(CC) -DDO_DEPS_ONLY \
+   $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) \
+   -o $@ $(src)lib/asm-offsets.c -c -S
+
 #
 else   # !config.mk
 all $(obj)u-boot.hex $(obj)u-boot.srec $(obj)u-boot.bin \
@@ -1214,6 +1229,7 @@ clean:
   $(obj)u-boot.lds   \
   $(obj)arch/blackfin/cpu/bootrom-asm-offsets.[chs]
@rm -f $(obj)include/bmp_logo.h
+   @rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
@rm -f $(ONENAND_BIN)
@@ -1237,6 +1253,7 @@ clobber:  clean
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
+   @rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l 
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l 
-print | xargs rm -f
 
diff --git a/include/asm-offsets.h b/include/asm-offsets.h
new file mode 100644
index 000..ab28184
--- /dev/null
+++ b/include/asm-offsets.h
@@ -0,0 +1,2 @@
+#include 
+/* #include  */
diff --

Re: [U-Boot] [PATCH 0/3] Introduce asm-offsets and fix CONFIG_SYS_GBL_DATA_SIZE problems

[Kumar Gala]

On Oct 26, 2010, at 8:59 AM, Wolfgang Denk wrote:

> The following patch series starts some clean up of for the handling f
> initial data; the most important change is the replacement of a
> manually configured (and thus often wrong) CONFIG_SYS_GBL_DATA_SIZE
> by an automatically generated value.
> 
> More similar clean-ups can and will be done, but this is stuff for the
> next merge window (or the "next" branch); here we focus on a fix for
> the CONFIG_SYS_GBL_DATA_SIZE problems.
> 
> The changes are mostly simple and straightforward, but they are huge
> as they affect a lots of files.
> 
> 
> [PATCH 1/3] Rename CONFIG_SYS_INIT_RAM_END into CONFIG_SYS_INIT_RAM_SIZE
> 
> CONFIG_SYS_INIT_RAM_END was a misnomer as it suggests this might be
> some end address; to make the meaning more clear we rename it into
> CONFIG_SYS_INIT_RAM_SIZE
> 
> No other code changes are performed in this patch, only minor editing
> of white space (due to the changed length) and the comments was done,
> where noticed.
> 
> Note that the code for the PATI and cmi_mpc5xx board configurations
> looks seriously broken.  Last known maintainers on Cc:
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Denis Peter 
> Cc: Martin Winistoerfer 
> ---

Acked-by: Kumar Gala 

looks good to me (beyond the typo ;)

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

Re: [U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants

[Wolfgang Denk]

Dear Alexander Stein,

In message <201010261611.59856.alexander.st...@systec-electronic.com> you wrote:
> On Tuesday 26 October 2010, 16:00:00 Wolfgang Denk wrote:
> > @@ -453,7 +456,7 @@ $(obj)System.map:   $(obj)u-boot
> > @$(call SYSTEM_MAP,$<) > $(obj)System.map
> > 
> >  #
> > -# Auto-generate the autoconf.mk file (which is included by all makefiles)
> > +# Auto-generate the autoconi.mk file (which is included by all makefiles)
> >  #
> >  # This target actually generates 2 files; autoconf.mk and autoconf.mk.dep.
> >  # the dep file is only include in this top level makefile to determine
> > when
> 
> I think thats a typo.

oops. thanks, will fix that!

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
"It is better for civilization to be going down the drain than to  be
coming up it."  - Henry Allen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants

[Alexander Stein]

On Tuesday 26 October 2010, 16:00:00 Wolfgang Denk wrote:
> @@ -453,7 +456,7 @@ $(obj)System.map: $(obj)u-boot
>   @$(call SYSTEM_MAP,$<) > $(obj)System.map
> 
>  #
> -# Auto-generate the autoconf.mk file (which is included by all makefiles)
> +# Auto-generate the autoconi.mk file (which is included by all makefiles)
>  #
>  # This target actually generates 2 files; autoconf.mk and autoconf.mk.dep.
>  # the dep file is only include in this top level makefile to determine
> when

I think thats a typo.

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

[U-Boot] [PATCH 0/3] Introduce asm-offsets and fix CONFIG_SYS_GBL_DATA_SIZE problems

[Wolfgang Denk]

The following patch series starts some clean up of for the handling f
initial data; the most important change is the replacement of a
manually configured (and thus often wrong) CONFIG_SYS_GBL_DATA_SIZE
by an automatically generated value.

More similar clean-ups can and will be done, but this is stuff for the
next merge window (or the "next" branch); here we focus on a fix for
the CONFIG_SYS_GBL_DATA_SIZE problems.

The changes are mostly simple and straightforward, but they are huge
as they affect a lots of files.


[PATCH 1/3] Rename CONFIG_SYS_INIT_RAM_END into CONFIG_SYS_INIT_RAM_SIZE

CONFIG_SYS_INIT_RAM_END was a misnomer as it suggests this might be
some end address; to make the meaning more clear we rename it into
CONFIG_SYS_INIT_RAM_SIZE

No other code changes are performed in this patch, only minor editing
of white space (due to the changed length) and the comments was done,
where noticed.

Note that the code for the PATI and cmi_mpc5xx board configurations
looks seriously broken.  Last known maintainers on Cc:

Signed-off-by: Wolfgang Denk 
Cc: Denis Peter 
Cc: Martin Winistoerfer 
---
 README |2 +-
 arch/m68k/lib/board.c  |2 +-
 arch/powerpc/cpu/74xx_7xx/start.S  |4 ++--
 arch/powerpc/cpu/mpc83xx/start.S   |4 ++--
 arch/powerpc/cpu/mpc86xx/start.S   |4 ++--
 arch/powerpc/cpu/ppc4xx/start.S|   22 +++---
 board/fads/fads.h  |4 ++--
 include/configs/A3000.h|4 ++--
 include/configs/ADCIOP.h   |4 ++--
 include/configs/AMX860.h   |4 ++--
 include/configs/AP1000.h   |4 ++--
 include/configs/APC405.h   |4 ++--
 include/configs/AR405.h|4 ++--
 include/configs/ASH405.h   |4 ++--
 include/configs/ATUM8548.h |4 ++--
 include/configs/Adder.h|4 ++--
 include/configs/Alaska8220.h   |4 ++--
 include/configs/BAB7xx.h   |4 ++--
 include/configs/BC3450.h   |6 +++---
 include/configs/BMW.h  |4 ++--
 include/configs/CANBT.h|4 ++--
 include/configs/CATcenter.h|4 ++--
 include/configs/CMS700.h   |4 ++--
 include/configs/CPC45.h|4 ++--
 include/configs/CPCI2DP.h  |4 ++--
 include/configs/CPCI405.h  |4 ++--
 include/configs/CPCI4052.h |4 ++--
 include/configs/CPCI405AB.h|4 ++--
 include/configs/CPCI405DT.h|4 ++--
 include/configs/CPCI750.h  |4 ++--
 include/configs/CPCIISER4.h|4 ++--
 include/configs/CPU86.h|4 ++--
 include/configs/CPU87.h|4 ++--
 include/configs/CRAYL1.h   |8 
 include/configs/CU824.h|4 ++--
 include/configs/DASA_SIM.h |4 ++--
 include/configs/DB64360.h  |4 ++--
 include/configs/DB64460.h  |4 ++--
 include/configs/DP405.h|4 ++--
 include/configs/DU405.h|4 ++--
 include/configs/DU440.h|4 ++--
 include/configs/EB+MCF-EV123.h |8 
 include/configs/ELPPC.h|4 ++--
 include/configs/ELPT860.h  |4 ++--
 include/configs/EP88x.h|4 ++--
 include/configs/ERIC.h |4 ++--
 include/configs/ESTEEM192E.h   |4 ++--
 include/configs/ETX094.h   |4 ++--
 include/configs/EVB64260.h |4 ++--
 include/configs/EXBITGEN.h |4 ++--
 include/configs/FADS823.h  |4 ++--
 include/configs/FADS850SAR.h   |4 ++--
 include/configs/FLAGADM.h  |4 ++--
 include/configs/FPS850L.h  |4 ++--
 include/configs/FPS860L.h  |4 ++--
 include/configs/G2000.h|4 ++--
 include/configs/GEN860T.h  |4 ++--
 include/configs/GENIETV.h  |4 ++--
 include/configs/HH405.h|4 ++--
 include/configs/HIDDEN_DRAGON.h|8 
 include/configs/HUB405.h   |4 ++--
 include/configs/IAD210.h   |4 ++--
 include/configs/ICU862.h   |4 ++--
 include/configs/IDS8247.h  |4 ++--
 include/configs/IP860.h|4 ++--
 include/configs/IPHASE4539.h   |4 ++--
 include/configs/ISPAN.h|4 ++--
 include/configs/IVML24.h   |8 
 include/configs/IVMS8.h|

[U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants

[Wolfgang Denk]

A recurrent issue is that certain C level constructs like sizeof() or
offsetof() cannot be used in assembler files, which is inconvenient
when such constructs are used in the definition of macro names etc.

To avoid duplication of such definitions (and thus another cause of
problems), we adapt the Linux way to automatically generate the
respective definitions from the respective C header files.

In Linux, this is implemented in include/linux/kbuild.h, Kbuild, and
arch/*/kernel/asm-offsets.c; we adapt the code from the Linux v2.6.36
kernel tree.

We also copy the concept of the include/generated/ directory which can
be used to hold other automatically generated files as well.

We start with an architecture-independent lib/asm-offsets.c which
generates include/generated/generic-asm-offsets.h (included by
include/asm-offsets.h, which is what will be referred to in the actual
source code).  Later this may be extended by architecture-specific
arch/*/lib/asm-offsets.c files that will generate a
include/generated/asm-offsets.h.
---
 .gitignore |3 +++
 Makefile   |   23 ---
 include/asm-offsets.h  |2 ++
 include/linux/kbuild.h |   20 
 lib/asm-offsets.c  |   25 +
 tools/scripts/make-asm-offsets |   27 +++
 6 files changed, 97 insertions(+), 3 deletions(-)
 create mode 100644 include/asm-offsets.h
 create mode 100644 include/linux/kbuild.h
 create mode 100644 lib/asm-offsets.c
 create mode 100755 tools/scripts/make-asm-offsets

diff --git a/.gitignore b/.gitignore
index 67d2cd6..e71f6ac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -40,6 +40,9 @@
 /errlog
 /reloc_off
 
+/include/generated/
+/lib/asm-offsets.s
+
 # stgit generated dirs
 patches-*
 .stgit-edit.txt
diff --git a/Makefile b/Makefile
index f8e13d7..737eb11 100644
--- a/Makefile
+++ b/Makefile
@@ -372,7 +372,8 @@ GEN_UBOOT = \
cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
-$(obj)u-boot:  depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) 
$(obj)u-boot.lds
+$(obj)u-boot:  depend \
+   $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) 
$(obj)u-boot.lds
$(GEN_UBOOT)
 ifeq ($(CONFIG_KALLSYMS),y)
smap=`$(call SYSTEM_MAP,u-boot) | \
@@ -426,7 +427,9 @@ updater:
 
 # Explicitly make _depend in subdirs containing multiple targets to prevent
 # parallel sub-makes creating .depend files simultaneously.
-depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
+depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \
+   $(obj)include/autoconf.mk \
+   $(obj)include/generated/generic-asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(dir $(LDSCRIPT)) ; do \
$(MAKE) -C $$dir _depend ; done
 
@@ -453,7 +456,7 @@ $(obj)System.map:   $(obj)u-boot
@$(call SYSTEM_MAP,$<) > $(obj)System.map
 
 #
-# Auto-generate the autoconf.mk file (which is included by all makefiles)
+# Auto-generate the autoconi.mk file (which is included by all makefiles)
 #
 # This target actually generates 2 files; autoconf.mk and autoconf.mk.dep.
 # the dep file is only include in this top level makefile to determine when
@@ -473,6 +476,18 @@ $(obj)include/autoconf.mk: $(obj)include/config.h
sed -n -f tools/scripts/define2mk.sed > $...@.tmp && \
mv $...@.tmp $@
 
+$(obj)include/generated/generic-asm-offsets.h: $(obj)include/autoconf.mk.dep \
+   $(obj)lib/asm-offsets.s
+   @$(XECHO) Generating $@
+   tools/scripts/make-asm-offsets $(obj)lib/asm-offsets.s $@
+
+$(obj)lib/asm-offsets.s:   $(obj)include/autoconf.mk.dep \
+   $(src)lib/asm-offsets.c
+   @mkdir -p $(obj)lib
+   $(CC) -DDO_DEPS_ONLY \
+   $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) \
+   -o $@ $(src)lib/asm-offsets.c -c -S
+
 #
 else   # !config.mk
 all $(obj)u-boot.hex $(obj)u-boot.srec $(obj)u-boot.bin \
@@ -1214,6 +1229,7 @@ clean:
   $(obj)u-boot.lds   \
   $(obj)arch/blackfin/cpu/bootrom-asm-offsets.[chs]
@rm -f $(obj)include/bmp_logo.h
+   @rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
@rm -f $(ONENAND_BIN)
@@ -1237,6 +1253,7 @@ clobber:  clean
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
+   @rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find $

Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards

[Premi, Sanjeev]

> -Original Message-
> From: Steve Sakoman [mailto:st...@sakoman.com] 
> Sent: Monday, October 25, 2010 8:38 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
> 
> On Mon, 2010-10-25 at 20:10 +0530, Premi, Sanjeev wrote:
> > > -Original Message-
> > > From: Steve Sakoman [mailto:st...@sakoman.com] 
> > > Sent: Monday, October 25, 2010 6:52 PM
> > > To: Premi, Sanjeev
> > > Cc: u-boot@lists.denx.de
> > > Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for 
> non-OMAP3 boards
> > > 
> > > On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote:
> > > > > -Original Message-
> > > > > From: u-boot-boun...@lists.denx.de 
> > > > > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of 
> Steve Sakoman
> > > > > Sent: Saturday, October 23, 2010 2:20 AM
> > > > > To: u-boot@lists.denx.de
> > > > > Subject: [U-Boot] [PATCH] ARMV7: Fix build for 
> non-OMAP3 boards
> > > > > 
> > > > > Commit c3d3a54 uses CONFIG_ARMV7 to determine whether 
> to call the
> > > > > v7_flush_cache_all function.  This breaks the build for 
> > > all non-OMAP3
> > > > > boards (like Panda and OMAP4430SDP) since there is only a 
> > > > > v7_flush_cache_all
> > > > > implementation for OMAP3.
> > > > > 
> > > > > This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so 
> > > > > that only boards
> > > > > with a v7_flush_cache_all will make the call.
> > > > 
> > > > [sp] Is this call board specific?
> > > 
> > > No, it is not.
> > 
> > [sp] I asked because I can see omap3/cache.S but not under 
> omap-common/
> >  (as I was expecting) - neither in omap4/
> > 
> >  Doesn't this patch works-around the problem by using 
> CONFIG_OMAP34XX?
> 
> Yes, this is a hopefully temporary fix to allow non-OMAP3 ARMV7 boards
> to build.
> 
> >  Wouldn't change in cache.S (or Makefile) be better solution/ or
> >  workaround. At least workaround will be visible to more eyes.
> 
> Ideally we would have a generic ARMV7 implementation that 
> would work for
> even non-OMAP ARMV7 processors.  Someone who is familiar with the
> differences in ARMV7 cache implementations from the various silicon
> vendors would need to do this.  This beyond my knowledge.
> 
> A "second best" solution would be to have a cache.S that 
> worked for both
> OMAP3 and OMAP4 in omap-common/
> 
> If this isn't possible, then we should add an OMAP4 specific 
> cache.S in
> omap4/
> 
> But until we settle on the proper long term strategy this patch should
> be applied so that non-OMAP3 ARMV7 boards will build.
> 

Can we indicate either in the title/ description that patch is temporary?

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

Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix

[Nishanth Menon]

Ghorai, Sukumar had written, on 10/26/2010 12:34 AM, the following:
[...]
> [Ghorai] Thanks.. This is the best approach. 
> Otherwise udelay() will increase the boot time. 
Please define "increase the boot time" with the context to the patch 
where you think the increase of boot time will be? In my experience, it 
has not. the iterations are such that:
while (condition_not_met)
udelay(10);
This is reasonable enough to wait till the condition is met.
a) u-boot boot logic is not invoked until "mmc part 0" is invoked -> 
u-boot boot time does not change
b) the actual fatload by itself will only incur minor latency addition - 
IMHO - necessary addition - in cases where the check conditions are not met.

would be great if you can illustrate within the patch areas which need 
continuous checks Vs the ones that do not need continuous checks.

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

Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot

[Premi, Sanjeev]

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
> Sent: Tuesday, October 19, 2010 10:25 PM
> To: Loïc Minier
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
> 
> > -Original Message-
> > From: Loïc Minier [mailto:l...@dooz.org] 
> > Sent: Tuesday, October 19, 2010 10:14 PM
> > To: Premi, Sanjeev
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
> > 
> > On Tue, Oct 19, 2010, Sanjeev Premi wrote:
> > > +#undef CONFIG_FAST_BOOT
> > 
> >  I wonder whether CONFIG_FAST_BOOT would cause confusion if 
> > u-boot gains
> >  support for Android fastboot someday?
> > 
> >  http://en.wikipedia.org/wiki/Fastboot
> >  http://android-dls.com/wiki/index.php?title=Fastboot
> 
> [sp] The intent here is to boot faster - hence the name.
>  Wasn't aware of any Android overlap.
> 
>  How about any of these:
>  - CONFIG_SMALL_SIZE
>  - CONFIG_FASTER_BOOT :)
>   ^^
>  Any other suggestions?

[sp] Didn't hear any other suggestions. But I had one more,
 CONFIG_QUICK_BOOT.

 Loic, does this seem okay?

~sanjeev

> 
> ~sanjeev
> 
> > 
> > -- 
> > Loïc Minier
> > 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Timer implementations

[Reinhard Meyer]

Dear Wolfgang Denk,
>> Then the define CONFIG_SYS_HZ should not be in every .h since that
>> suggests that a board developer has some freedom there...
> 
> Agreed - there are historical reasons this has ever been changable at
> all.
> 
>> and MOST IMPORTANT that some implementations of udelay() might
>> call reset_timer() and therefore break an outer timeout loop !!!
> 
> Such implementations are inherently broken and need to be fixed.

Found such in arm926ejs/omap... But then, that timer is multiple-broken:
relocation broken (uses static data), returns 32 a bit value in get_ticks(),
returns CONFIG_SYS_HZ in get_tbclk() instead of the rate get_ticks()
increments...

PXA:
void udelay_masked (unsigned long usec)
{
unsigned long long tmp;
ulong tmo;

tmo = us_to_tick(usec);
tmp = get_ticks() + tmo;/* get current timestamp */

while (get_ticks() < tmp)
/* loop till event _OR FOREVER is tmp happens to be > 32 bit_ */
 /*NOP*/;

}

unsigned long long get_ticks(void)
{
return readl(OSCR);
}
- not any better :( -- its the same code that AT91 had before I fixed it.

> 
>> It is also open if reset_timer() does actually reset the hardware timer
>> (e.g. tbu/tbl at PPC) - which would be messing up any time difference
>> calculation using get_ticks() - or does emulate that by remembering
>> the hardware value and subtracting it later in every subsequent
>> get_timer() call?
> 
> This is an implementation detail.

IF we require that get_ticks() and get_timer() shall not interfere with
each other and IF both are based on the same hardware timer only the
second method is available (same if the hardware timer is not easyly
resettable).

>> 2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
>> Since they are defined as having 64 bits they MUST not wrap at 32 bits,
>> i.e. if the hardware provides only 32 bits, the upper 32 bits must be
>> emulated by software.
> 
> Right.
> 
>> Otherwise we have to document that get_ticks() cannot be used to get
>> 64 bit time differences.
> 
> No. Such an implementation is broken and needs fixing.

Original AT91 timer.c was like that, and I think other ARMs where this was
copied around should be looked at... I don't know when get_timer() became
64 bits, but it seems that some implementations just did change the return
type: uint64 get_timer(void) {return (uint64)timer_val_32;}

> 
>> If you really closely look at the various implementations of those
>> timers, you will easyly see the wide variations implemented there.
> 
> Yes, I am aware of this :-(

I will start beautifying the AT91 timer - its already quite there,
except for a possible timer wrap problem in udelay() after a few billion
years :)

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

Re: [U-Boot] Not getting any prompt on hyper terminal

[Wolfgang Denk]

Dear Srinivas Ganji,

In message  you 
wrote:
> 
> > You should never need to modify arch/powerpc/lib/board.c and
> > arch/powerpc/cpu/ppc4xx/start.S. I recommend you undo thse changes.
> 
> We have modified the start.S file for the following #define as our
> flash start address is 0xFF00 according to flash size.

Please look at the code. You do not have to change this file. Just
provide a correct definition in your board config file.

Please do not meddle with global files.

> We have added only debug statements in board.c. We did not change any
> value/variable in this file.

"Only adding debug statements" may break a board as well, if you don't
know exactly what you are doing.

> We are using yosemite board configuration files as we derived our
> board as per the yosemite board. Please let me know, if there is any
> document / README for creating the own config files.

There is a little help in the README.

> > > make YOSEMITE_config
> >
> > I am pretty sure this is NOT the command you used. Note thate case
> > matters.
> 
> The README file which is available in the main u-boot directory says
> use CAPITAL letters YOSEMITE only. That is the reason, I used it. I
> also saw in the google where they used the CAPITAL letters for

I really have no idea what you are talking about: there is not a
single reference to Yosemite (in whatever spelling) in the README.

And the make target is "yosemite_config", and has always been like
that.  If this is different for you, your source tree must be
seriously modified (read: messed up).


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 software required `Windows 95 or better', so I installed Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3 V2] Add support for hawkboard

[Ben Gardiner]

On Mon, Oct 25, 2010 at 4:09 PM, Sughosh Ganu  wrote:
> The patch adds basic board support for TI's OMAP-L138 based
> Hawkboard. This board is pretty similar to the da850 EVM. Support for
> nand and network access is added in this version.
>
> The following bootup procedure is used.
>
> At reset, the Rom Boot Loader(RBL), initialises the ddr and the nand
> controllers and copies the second stage bootloader(nand_spl) to
> RAM. The secondary bootloader then copies u-boot from a predefined
> location in the nand flash to the RAM, and passes control to the
> u-boot image.
>
> Three config options are supported
> * hawkboard_config - Used to create the u-boot.bin. Tftp the
>  u-boot.bin image to the RAM from u-boot, and flash to the nand flash
>  at address 0xe.
>
> * hawkboard_nand_config - Used to generate the secondary
>  bootloader(nand_spl) image. This creates an elf file u-boot-spl
>  under nand_spl/. Create an AIS signed image using this file, and
>  flash it to the nand flash at address 0x2. The ais file should
>  fit in one block.
>
> * hawkboard_uart_config - This is same as the first image, but with
>  the TEXT_BASE as expected by the RBL(0xc108). Create the AIS
>  Signed bin, as use the normal UART boot procedure to boot the image.
>
> Signed-off-by: Sughosh Ganu 

Applies to c163f4478ca72f51b28b55f74addc8fe029d7b83 of
git://git.denx.de/u-boot.git.

This patch has checkpatch.pl warnings and errors:
ERROR: return is not a function, parentheses are not required#456:
FILE: board/davinci/da8xxevm/hawkboard.c:58:
+   return(0);

WARNING: space prohibited between function name and open parenthesis '('
#459: FILE: board/davinci/da8xxevm/hawkboard.c:61:
+int misc_init_r (void)

WARNING: line over 80 characters
#463: FILE: board/davinci/da8xxevm/hawkboard.c:65:
+   printf ("ARM Clock : %s MHz\n", strmhz(buf, 
clk_get(DAVINCI_ARM_CLKID)));

WARNING: space prohibited between function name and open parenthesis '('
#463: FILE: board/davinci/da8xxevm/hawkboard.c:65:
+   printf ("ARM Clock : %s MHz\n", strmhz(buf, 
clk_get(DAVINCI_ARM_CLKID)));

ERROR: return is not a function, parentheses are not required
#465: FILE: board/davinci/da8xxevm/hawkboard.c:67:
+   return(0);

ERROR: space required after that ',' (ctx:VxV)
#537: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:65:
+   { pinmux(12),1, 5 },
^

ERROR: space required after that ',' (ctx:VxV)
#538: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:66:
+   { pinmux(12),1, 6 }
^

WARNING: space prohibited between function name and open parenthesis '('
#569: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:97:
+void board_init_f (ulong bootflag)

ERROR: code indent should use tabs where possible
#601: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:129:
+^I CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);$

WARNING: space prohibited between function name and open parenthesis '('
#605: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:133:
+   relocate_code (CONFIG_SYS_NAND_U_BOOT_RELOC_SP, (gd_t *)gd,

WARNING: space prohibited between function name and open parenthesis '('
#631: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:159:
+void hang (void)

WARNING: space prohibited between function name and open parenthesis '('
#633: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:161:
+   puts ("### ERROR ### Please RESET the board ###\n");

ERROR: trailing statements should be on next line
#634: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:162:
+   for (;;);
+   for (;;);
WARNING: line over 80 characters
#721: FILE: include/configs/hawkboard.h:54:
+#define PHYS_SDRAM_1   DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start 
*/

WARNING: line over 80 characters
#725: FILE: include/configs/hawkboard.h:58:
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 
-   \

WARNING: line over 80 characters
#842: FILE: include/configs/hawkboard.h:175:
+   "mem=128M console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0xc118,"  
\

total: 6 errors, 10 warnings, 823 lines checked

../sugosh-da8xx-v2/3of3.patch has style problems, please review.  If
any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

I was also unable to build the da850evm u-boot with this patch applied:
$make mrproper ; make da850evm_config ; make -j9 all|grep -E '( error| warning)'
awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }'
boards.cfg > .boards.depend
Configuring for da850evm board...
davinci_pinmux.c:30:26: error: davinci_misc.h: No such file or directory
make[1]: *** No rule to make target `.depend', needed by `libdavinci.a'.  Stop.
make: *** [board/davinci/common/libdavinci.a] Error 2
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.

For your next patch submission, I recommend running checkpatch.pl
(from a recent linux kernel scripts/ directory) on y

Re: [U-Boot] [PATCH 2/3 V2] Make board_init_f under nand_boot.c a weak function.

[Ben Gardiner]

On Mon, Oct 25, 2010 at 4:08 PM, Sughosh Ganu  wrote:
>  Enable board_init_f to be overridden with a board specific
>  funtion.
>
> Signed-off-by: Sughosh Ganu 

Applies to c163f4478ca72f51b28b55f74addc8fe029d7b83 of
git://git.denx.de/u-boot.git.

This patch has checkpatch.pl warnings:
WARNING: space prohibited between function name and open parenthesis '('
#94: FILE: nand_spl/nand_boot.c:225:
+void __board_init_f (ulong bootflag)

WARNING: line over 80 characters
#99: FILE: nand_spl/nand_boot.c:230:
+void board_init_f (ulong bootflag)__attribute__((weak,
alias("__board_init_f")));

WARNING: space prohibited between function name and open parenthesis '('
#99: FILE: nand_spl/nand_boot.c:230:
+void board_init_f (ulong bootflag)__attribute__((weak,
alias("__board_init_f")));

The resulting u-boot is usable; tested on da850evm with NAND, env.oob and tftp.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3 V2] Move and rename common headers from under board/davinci.

[Ben Gardiner]

On Mon, Oct 25, 2010 at 4:08 PM, Sughosh Ganu  wrote:
>  Move the davinci common headers to the architecture specific
>  include file path.
>
> Signed-off-by: Sughosh Ganu 

Applies to c163f4478ca72f51b28b55f74addc8fe029d7b83 of
git://git.denx.de/u-boot.git. No checkpatch.pl errors or warnings.

The resulting u-boot is usable; tested on da850evm with NAND, env.oob and tftp.

Tested-by: Ben Gardiner 

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Timer implementations

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4cc6aadc.8050...@emk-elektronik.de> you wrote:
> 
> Then the define CONFIG_SYS_HZ should not be in every .h since that
> suggests that a board developer has some freedom there...

Agreed - there are historical reasons this has ever been changable at
all.

> and MOST IMPORTANT that some implementations of udelay() might
> call reset_timer() and therefore break an outer timeout loop !!!

Such implementations are inherently broken and need to be fixed.

> It is also open if reset_timer() does actually reset the hardware timer
> (e.g. tbu/tbl at PPC) - which would be messing up any time difference
> calculation using get_ticks() - or does emulate that by remembering
> the hardware value and subtracting it later in every subsequent
> get_timer() call?

This is an implementation detail.

> 2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
> Since they are defined as having 64 bits they MUST not wrap at 32 bits,
> i.e. if the hardware provides only 32 bits, the upper 32 bits must be
> emulated by software.

Right.

> Otherwise we have to document that get_ticks() cannot be used to get
> 64 bit time differences.

No. Such an implementation is broken and needs fixing.

> If you really closely look at the various implementations of those
> timers, you will easyly see the wide variations implemented there.

Yes, I am aware of 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
...though his invention worked superbly -- his theory was a crock  of
sewage from beginning to end. - Vernor Vinge, "The Peace War"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] NAND support on AVR32

[David Collier]

In article <20101025125554.0309a...@udp111988uds.am.freescale.net>,
scottw...@freescale.com (Scott Wood) wrote:

> *From:* Scott Wood 
> *To:* 
> *CC:* 
> *Date:* Mon, 25 Oct 2010 12:55:54 -0500
> 
> On Mon, 25 Oct 2010 14:21:00 +0100
> David Collier  wrote:
> 
> > OK - my apologies
> > 
> > I've now used the web browser, and my post is there - the problem 
> > is
> > obviously with my download from the mailing list.
> > 
> > I still don't see any relies though - so if you cn help I'd be 
> > truly
> > grateful :-)
> 
> There were replies:
> 
> http://lists.denx.de/pipermail/u-boot/2010-October/078860.html
> http://lists.denx.de/pipermail/u-boot/2010-October/078861.html
> 
> They should have also gone directly to your e-mail (separate from 
> the
> list), assuming "from_denx_ub...@dexdyne.com" is actually a valid
> address for you.
> 
> -Scott

Thanks Scott...

I spotted those by going to the web interface eventually.

I didn't get them by email at the time, but there seems to be some sort
of "wind-up-delay" when you first subscribe ( I had to rejoin as I'd been
auto-deleted ) that gives you some postings, but not others...

Of course it could have been some intervening spam-filter getting
confused

It looks as if I'm getting all messages now... so it shouldn't happen
again

TVM

D

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

Re: [U-Boot] U-boot versions - reply to RM + SW

[David Collier]

In article <2dd330d8-59ec-4a42-b251-360e19620...@googlemail.com>,
andreas.de...@googlemail.com (Andreas Bießmann) wrote:

> *From:* Andreas Bießmann 
> *To:* from_denx_ub...@dexdyne.com
> *Date:* Mon, 25 Oct 2010 19:14:07 +0200
> 
> Dear David Collier,
> 
> Am 25.10.2010 um 15:46 schrieb David Collier:
> 
> > I posted a question about NAND on AVR32, and both Reinhard Meyer 
> > and
> > Scott Wood said "why aren't you using the latest source"
> > 
> > The reason of course is that from 2008:10 until very recently, 
> > the AVR32
> > version didn't work - some issue to do with the memory mapping 
> > when
> > writing flash.
> 
> This issue was fixed in 1f36f73fe70560a2bd286a7abc8530fdc93af9ae 
> somewhere in August and is therefore mainline since v2010.09
> 
> regards
> 
> Andreas Bießmann

Thanks Andreas - but it will be a lot of work to forward my working
patches across the 2-year gap :-(

D


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

Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Joakim Tjernlund]

Andre Schwarz  wrote on 2010/10/26 14:34:57:
>
> All,
>
> >
> >> Having a look at include/asm/global_data.h gives some 40 ulongs for my
> >> MPC8377 system.
> >> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
> >>
> > Indeed. I was asking because I just discovered that most of the
> > PowerPC boards are actually broken in this respect - 89 % of them,
> > 170 out of 191 :-(
> >
> >
> >> The system is still dead after removing the 4 nops after _start.
> >>
>
> actually I'm facing another issue and don't now whether this might be
> related to this thread or not.
>
>
> Just before relocation in arch/powerpc/lib/board.c the CPU gets a "check
> stop" followed by reset during "memset()" in line 493.
>
> [snip]
> DRAM:  256 MiB
> Top of RAM usable for U-Boot at: 1000
> Reserving 341k for U-Boot at: 0ffaa000
> Reserving 512k for malloc() at: 0ff29f80
>
> - reset -
>
> U-Boot 2010.09-00488-g5edbadb-dirty (Oct 26 2010 - 14:16:00) MPC83XX
>
> Reset Status: Check Stop, External/Internal Soft, External/Internal Hard
>
>
> I know that DDR might not be 100% stable but it is basically set up
> properly.
> Removing the memset yields the next debug messages before resetting
> again while setting up SP.
>
> Is the DDR required to work 100% for a simple write operation or might
> there be another problem ?

Yes, DDR must be correct. You might get a bit further by turning off
the data cache.

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

Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

All,

>
>> Having a look at include/asm/global_data.h gives some 40 ulongs for my
>> MPC8377 system.
>> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
>>  
> Indeed. I was asking because I just discovered that most of the
> PowerPC boards are actually broken in this respect - 89 % of them,
> 170 out of 191 :-(
>
>
>> The system is still dead after removing the 4 nops after _start.
>>  

actually I'm facing another issue and don't now whether this might be 
related to this thread or not.


Just before relocation in arch/powerpc/lib/board.c the CPU gets a "check 
stop" followed by reset during "memset()" in line 493.

[snip]
DRAM:  256 MiB
Top of RAM usable for U-Boot at: 1000
Reserving 341k for U-Boot at: 0ffaa000
Reserving 512k for malloc() at: 0ff29f80

- reset -

U-Boot 2010.09-00488-g5edbadb-dirty (Oct 26 2010 - 14:16:00) MPC83XX

Reset Status: Check Stop, External/Internal Soft, External/Internal Hard


I know that DDR might not be 100% stable but it is basically set up 
properly.
Removing the memset yields the next debug messages before resetting 
again while setting up SP.

Is the DDR required to work 100% for a simple write operation or might 
there be another problem ?

256MiB DDR is mapped by single BAT and there should be no overlapping 
BATs either.


Any ideas ?

-- 

Regards,
Andre



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx25: Fix reset

[Matthias Weißer]

Am 26.10.2010 11:27, schrieb Reinhard Meyer:
> Dear Matthias Weisser,
>> This patch fixes the reset command on imx25
>>
>> Signed-off-by: Matthias Weisser
>> +writew(0x,®s->wcr);
>> +writew(0x,®s->wsr);
>> +writew(0x,®s->wsr);
>
> It might be "nicer" to use 16 Bit constants (with 4 hex digits)
> here..?

Sure. Would be nicer. I wait a bit for further comments and will create 
a V3 then.

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

[U-Boot] [PATCH 2/3] sh: Add support shmin board

[Nobuhiro Iwamatsu]

This adds support for the SHMIN SH7706 board(T-SH7706LAN).
The CPU of this board is SH7706.
There are SDRAM of 32M byte, Flash memory of 512K byte, Serial,
10Base Ether and MMC.

http://web.kyoto-inet.or.jp/people/takagaki/T-SH7706/T-SH7706.htm

Signed-off-by: Nobuhiro Iwamatsu 
---
 MAINTAINERS |1 +
 board/shmin/Makefile|   49 ++
 board/shmin/config.mk   |   27 ++
 board/shmin/lowlevel_init.S |   36 +
 board/shmin/shmin.c |  108 
 boards.cfg  |1 +
 include/configs/shmin.h |  115 +++
 7 files changed, 337 insertions(+), 0 deletions(-)
 create mode 100644 board/shmin/Makefile
 create mode 100644 board/shmin/config.mk
 create mode 100644 board/shmin/lowlevel_init.S
 create mode 100644 board/shmin/shmin.c
 create mode 100644 include/configs/shmin.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b0da631..27dc6c1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1001,6 +1001,7 @@ Nobuhiro Iwamatsu 
SH7763RDP   SH7763
RSK7203 SH7203
AP325RXASH7723
+   SHMIN   SH7706
 
 Mark Jonas 
 
diff --git a/board/shmin/Makefile b/board/shmin/Makefile
new file mode 100644
index 000..be04e2c
--- /dev/null
+++ b/board/shmin/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2010 Nobuhiro Iwamatsu
+# Copyright (C) 2008 Renesas Solutions Corp.
+#
+# u-boot/board/shmin/Makefile
+#
+# 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= lib$(BOARD).a
+
+OBJS   := shmin.o
+SOBJS  := lowlevel_init.o
+
+LIB:= $(addprefix $(obj),$(LIB))
+OBJS   := $(addprefix $(obj),$(OBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(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/shmin/config.mk b/board/shmin/config.mk
new file mode 100644
index 000..eca20d4
--- /dev/null
+++ b/board/shmin/config.mk
@@ -0,0 +1,27 @@
+#
+# Copyright (C) 2010 Nobuhiro Iwamatsu
+#
+# u-boot/board/shmin/config.mk
+#
+# 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
+
+#
+# TEXT_BASE refers to image _after_ relocation.
+#
+# NOTE: Must match value used in u-boot.lds (in this directory).
+#
+
+CONFIG_SYS_TEXT_BASE = 0x8DFC
diff --git a/board/shmin/lowlevel_init.S b/board/shmin/lowlevel_init.S
new file mode 100644
index 000..b29da35
--- /dev/null
+++ b/board/shmin/lowlevel_init.S
@@ -0,0 +1,36 @@
+/*
+ * (C) Copyright 2008, 2010 Nobuhiro Iwamatsu 
+ *
+ * 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 
+#includ

[U-Boot] [PATCH 3/3] sh: Add support showing KByte of flash memory size

[Nobuhiro Iwamatsu]

Signed-off-by: Nobuhiro Iwamatsu 
---
 arch/sh/lib/board.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/sh/lib/board.c b/arch/sh/lib/board.c
index a302fc2..bf3a5cc 100644
--- a/arch/sh/lib/board.c
+++ b/arch/sh/lib/board.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2007,2008
+ * Copyright (C) 2007, 2008, 2010
  * Nobuhiro Iwamatsu 
  *
  * This program is free software; you can redistribute it and/or
@@ -46,7 +46,11 @@ static int sh_flash_init(void)
DECLARE_GLOBAL_DATA_PTR;
 
gd->bd->bi_flashsize = flash_init();
-   printf("FLASH: %ldMB\n", gd->bd->bi_flashsize / (1024*1024));
+
+   if (gd->bd->bi_flashsize >= (1024 * 1024))
+   printf("FLASH: %ldMB\n", gd->bd->bi_flashsize / (1024*1024));
+   else
+   printf("FLASH: %ldKB\n", gd->bd->bi_flashsize / 1024);
 
return 0;
 }
-- 
1.7.2.3

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

[U-Boot] [PATCH 1/3] sh: Add support SH7706

[Nobuhiro Iwamatsu]

Signed-off-by: Nobuhiro Iwamatsu 
---
 arch/sh/include/asm/cpu_sh3.h|6 +++-
 arch/sh/include/asm/cpu_sh7706.h |   53 ++
 2 files changed, 57 insertions(+), 2 deletions(-)
 create mode 100644 arch/sh/include/asm/cpu_sh7706.h

diff --git a/arch/sh/include/asm/cpu_sh3.h b/arch/sh/include/asm/cpu_sh3.h
index 6db38a2..385f5dc 100644
--- a/arch/sh/include/asm/cpu_sh3.h
+++ b/arch/sh/include/asm/cpu_sh3.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2007 Nobuhiro Iwamatsu 
+ * (C) Copyright 2007-2009 Nobuhiro Iwamatsu 
  * (C) Copyright 2007 Yoshihiro Shimoda 
  *
  * This program is free software; you can redistribute it and/or
@@ -31,7 +31,9 @@
 #define CACHE_OC_NUM_ENTRIES   256
 #define CACHE_OC_ENTRY_SHIFT   4
 
-#if defined(CONFIG_CPU_SH7710)
+#if defined(CONFIG_CPU_SH7706)
+#include 
+#elif defined(CONFIG_CPU_SH7710)
 #include 
 #elif defined(CONFIG_CPU_SH7720)
 #include 
diff --git a/arch/sh/include/asm/cpu_sh7706.h b/arch/sh/include/asm/cpu_sh7706.h
new file mode 100644
index 000..d093f88
--- /dev/null
+++ b/arch/sh/include/asm/cpu_sh7706.h
@@ -0,0 +1,53 @@
+#ifndef _ASM_CPU_SH7706_H_
+#define _ASM_CPU_SH7706_H_
+
+#define CACHE_OC_NUM_WAYS  4
+#define CCR_CACHE_INIT 0x000D
+
+/* MMU and Cache control */
+#define MMUCR  0xFFE0
+#define CCR0xFFEC
+
+/* PFC */
+#define PACR   0xA4050100
+#define PBCR   0xA4050102
+#define PCCR   0xA4050104
+#define PETCR  0xA4050106
+
+/* Port Data Registers */
+#define PADR   0xA4050120
+#define PBDR   0xA4050122
+#define PCDR   0xA4050124
+
+/* BSC */
+#defineFRQCR   0xff80
+#defineBCR10xff60
+#defineBCR20xff62
+#defineWCR10xff64
+#defineWCR20xff66
+#defineMCR 0xff68
+
+/* SDRAM controller */
+#defineDCR 0xff6a
+#defineRTCSR   0xff6e
+#defineRTCNT   0xff70
+#defineRTCOR   0xff72
+#defineRFCR0xff74
+#define SDMR   0xD000
+#define CS3_R  0xE460
+
+/* SCIF */
+#define SCSMR_20xA4000150
+#define SCIF0_BASE SCSMR_2
+
+/* Timer */
+#define TSTR0  0xFE92
+#define TSTR   TSTR0
+#define TCNT0  0xFE98
+#define TCR0   0xFE9C
+
+/* On chip oscillator circuits */
+#defineWTCNT   0xFF84
+#defineWTCSR   0xFF86
+
+#endif /* _ASM_CPU_SH7706_H_ */
-- 
1.7.2.3

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

[U-Boot] [PATCH] net: ne2000: Add spport RTL-8019AS

[Nobuhiro Iwamatsu]

Add infomation of RTL-8016AS to hw_info.

Signed-off-by: Nobuhiro Iwamatsu 
CC: Ben Warren 
---
 drivers/net/ne2000.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index ab5eec7..7a85314 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -164,7 +164,8 @@ static hw_info_t hw_info[] = {
{ /* Volktek NPL-402CT */ 0x0060, 0x00, 0x40, 0x05, 0 },
{ /* NEC PC-9801N-J12 */ 0x0ff0, 0x00, 0x00, 0x4c, 0 },
{ /* PCMCIA Technology OEM */ 0x01c8, 0x00, 0xa0, 0x0c, 0 },
-   { /* Qemu */ 0x0, 0x52, 0x54, 0x00, 0 }
+   { /* Qemu */ 0x0, 0x52, 0x54, 0x00, 0 },
+   { /* RTL8019AS */ 0x0, 0x0, 0x18, 0x5f, 0 }
 };
 
 #define NR_INFO(sizeof(hw_info)/sizeof(hw_info_t))
-- 
1.7.2.3

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

Re: [U-Boot] Not getting any prompt on hyper terminal

[Srinivas Ganji]

On Tue, Oct 26, 2010 at 3:48 PM, Wolfgang Denk  wrote:

Dear Wolfgang Denk,

Thanks for your information.

> You should never need to modify arch/powerpc/lib/board.c and
> arch/powerpc/cpu/ppc4xx/start.S. I recommend you undo thse changes.

We have modified the start.S file for the following #define as our
flash start address is 0xFF00 according to flash size.

#define CONFIG_SYS_FLASH_BASE   0xf800
changed to
# define CONFIG_SYS_FLASH_BASE  0xff00

We have added only debug statements in board.c. We did not change any
value/variable in this file.

> Also, you should create your own board configuration instead of
> messing with the yosemite files.

We are using yosemite board configuration files as we derived our
board as per the yosemite board. Please let me know, if there is any
document / README for creating the own config files.

> ...
> > Reserving 144 Bytes for Board Info at: 03e2ff70
> > Reserving 88 Bytes for Global Data at: 03e2ff18
> > Stack Pointer at: 03e2fef8
> > bd->bi_memsize: 67108864
> > New Stack Pointer is: 03e2fef8
> > before relocate_code()
>
> This problem in handled in the FAQ; please see
> http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation

Sure. I will look into it. I will update if there is any luck for me.

> > make YOSEMITE_config
>
> I am pretty sure this is NOT the command you used. Note thate case
> matters.

The README file which is available in the main u-boot directory says
use CAPITAL letters YOSEMITE only. That is the reason, I used it. I
also saw in the google where they used the CAPITAL letters for
building the u-boot.bin file for their specific board. Please let me
know, If I am wrong or any thing I am missing here.

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

Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse

[Jason Liu]

Hi, Stefano,

2010/10/26 Stefano Babic :
> On 10/22/2010 01:25 PM, Jason Liu wrote:
>> The patch is to support getting FEC MAC address from fuse bank.
>>
>> Signed-off-by: Jason Liu 
>
> Hi Jason,
>
> patch is related to a network driver, so Ben should be informed, too.

OK,  I will resend the patch and cc Ben. Thanks for reminder. :)
>
>> +     /*
>> +      * The MX27 can store the mac address in internal eeprom
>> +      * This mechanism is also supported now by MX51 or MX25
>> +      */
>
> If all supported processors implement the same way, we do not need to
> distinguish. The comment does not add any further info.

OK, will remove it.


>
>>       struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
>>       int i;
>>
>>       for (i = 0; i < 6; i++)
>> -             mac[6-1-i] = readl(&iim->iim_bank_area0[IIM0_MAC + i]);
>> +             mac[6-1-i] = readl(&iim->iim_bank_area[IIM_MAC + i]);
>>
>>       return !is_valid_ether_addr(mac);
>> -#endif
>
>>  }
>>
>>  static int fec_set_hwaddr(struct eth_device *dev)
>> @@ -414,9 +410,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
>>       uint32_t base;
>>       struct fec_priv *fec = (struct fec_priv *)dev->priv;
>>
>> -     /* Initialize MAC address */
>> -     fec_set_hwaddr(dev);
>> -
>
> Not sure. Why is this call removed ? We have changed the storage for the
> MAC address, but we need always to set the FEC controller. What is the
> reason to drop it ?

It's because, it will print some floating  value  of MAC address when
bootup and in fact, we don't need re-set it again here..
The net framework will do that. This is why I remove. it.

>
> Best regards,
> Stefano Babic
>
> --
> =
> 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
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MX5: board version not printed corretly on MX51EVK

[Jason Liu]

Hi， Stefano,

2010/10/26 Stefano Babic :
> On 10/22/2010 01:25 PM, Jason Liu wrote:
>> Fix the board version printing issue on MX51EVK. Need to read
>> the board version via get_cpu_rev and not rely on system_rev
>> due to the system_rev not initialized at boardchecking time.
>>
>> Signed-off-by: Jason Liu 
>> ---
>>  board/freescale/mx51evk/mx51evk.c |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> Hi Jason,
>
>>
>> diff --git a/board/freescale/mx51evk/mx51evk.c 
>> b/board/freescale/mx51evk/mx51evk.c
>> index d6bb71c..c532603 100644
>> --- a/board/freescale/mx51evk/mx51evk.c
>> +++ b/board/freescale/mx51evk/mx51evk.c
>> @@ -438,6 +438,8 @@ int board_late_init(void)
>>
>>  int checkboard(void)
>>  {
>> + u32 system_rev = get_cpu_rev();
>> +
>>   puts("Board: MX51EVK ");
>>
>>   switch (system_rev & 0xff) {
>
> Then we need to clean up other part of the code: system_rev should be
> not declared globally in the file and must be removed. In the same time,
> get_board_rev() should be changed. It seems it is in any case wrong,
> because it returns the same value, and this means get_cpu_rev().
>
> As this is a cpu revision and not a board revision, it is not correct.
> If the board revision cannot be determined correctly at runtime, we
> should return a fixed value. but certainly not the cpu revision.

Yes, agree. Then we need clean up the code for vision2 board too.


>
> Best regards,
> Stefano Babic
>
> --
> =
> 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
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

[Andre Schwarz]

Wolfgang,
> Dear Andre Schwarz,
>
> In message<4cc5c226.8080...@matrix-vision.de>  you wrote:
>
>> Having a look at include/asm/global_data.h gives some 40 ulongs for my
>> MPC8377 system.
>> Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough.
>>  
> Indeed. I was asking because I just discovered that most of the
> PowerPC boards are actually broken in this respect - 89 % of them,
> 170 out of 191 :-(
>

understood - this should be easy to fix.

>> The system is still dead after removing the 4 nops after _start.
>>  
> Sorry, but it was worth a try.
>

absolutely - so don't mind.
I'm still happy to get any directions at all.

Still wondering why there's no comment from Kim etc. ...


Regards,
André

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Not getting any prompt on hyper terminal

[Wolfgang Denk]

Dear Srinivas Ganji,

In message  you 
wrote:
>
> > on Ubuntu x86 host system. However, I have modified the following file
> > contents as per my board and processor attributes.
> >
> > file name   located directory
> > -   
> > 1) yosemite.hu-boot/include/configs
> > 2) board.c u-boot/arch/powerpc/lib
> > 3) init.S and yosemite.c u-boot/board/amcc/yosemite
> > 4) start.S  u-boot/arch/powerpc/cpu/ppc4xx

You should never need to modify arch/powerpc/lib/board.c and
arch/powerpc/cpu/ppc4xx/start.S. I recommend you undo thse changes.

Also, you should create your own board configuration instead of
messing with the yosemite files.

...
> Reserving 144 Bytes for Board Info at: 03e2ff70
> Reserving 88 Bytes for Global Data at: 03e2ff18
> Stack Pointer at: 03e2fef8
> bd->bi_memsize: 67108864
> New Stack Pointer is: 03e2fef8
> before relocate_code()

This problem in handled in the FAQ; please see
http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation

> make YOSEMITE_config

I am pretty sure this is NOT the command you used. Note thate case
matters.

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
... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/
If you can follow that, you can use it.
  - Randal L. Schwartz in 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Timer implementations

[Reinhard Meyer]

Dear Wolfgang Denk,

>> Actually CONFIG_SYS_HZ (whatever that is).
> 
> It is defined to be 1000.

Ok, game with that.

Then the define CONFIG_SYS_HZ should not be in every .h since that
suggests that a board developer has some freedom there...

>> I think it is necessary to summarize all implicit or explicit documented
>> "defined to have's" regarding the timer and then to verify that all
>> implementations adhere to them.
> 
> Indeed - documentation is an are where U-Boot has a serious lack.

OK, to summarize:

1. reset_timer(), get_timer(base) operate with 1ms granularity.
An implementation MUST make that close to 1ms.
On second thought, it might be valueable to be able to set
CONFIG_SYS_HZ to the exact value of the actual granularity.
(for example 1024, if a 32kHz based timer is used).

It should be pointed out, that the pair reset_timer()/get_timer()
cannot be used nested,

and MOST IMPORTANT that some implementations of udelay() might
call reset_timer() and therefore break an outer timeout loop !!!

It is also open if reset_timer() does actually reset the hardware timer
(e.g. tbu/tbl at PPC) - which would be messing up any time difference
calculation using get_ticks() - or does emulate that by remembering
the hardware value and subtracting it later in every subsequent
get_timer() call?

2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
Since they are defined as having 64 bits they MUST not wrap at 32 bits,
i.e. if the hardware provides only 32 bits, the upper 32 bits must be
emulated by software.
Otherwise we have to document that get_ticks() cannot be used to get
64 bit time differences.

OR fall back to a 32 bit get_ticks() that should perhaps increment at
a microsecond rate (see Bill Campbell's post).

If you really closely look at the various implementations of those
timers, you will easyly see the wide variations implemented there.

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

Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4cc6a772.1080...@denx.de> you wrote:
> 
> > It may be board dependent - for exmaple, when there is some large and
> > conveniently usable SRAM on a board, you might want to use that
> > instead of any limited area on the SoC.
> 
> IRAM_BASE_SIZE is SoC dependend! You maybe mean CONFIG_SYS_INIT_SP_ADDR
> which can be of course board dependend.

No, what I mean is CONFIG_SYS_INIT_RAM_ADDR (and
CONFIG_SYS_INIT_RAM_END). CONFIG_SYS_INIT_SP_ADDR is a definition
that will go away because it can be computed from the other data.

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
Swap read error.  You lose your mind.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] maybe a priority mistake in mpc85xx_cpu\init.c

[Detlev Zundel]

Hi geniis,

> hi,
>  
> I notice that in "arch\powerpc\cpu\mpc85xx\cpu_init.c" line 193, version 
> 2010.06:
> if (! memctl->br1 & 1)
>  
> The original intention is to check if V bit of BR1 is set or not, but the 
> operator "!" has higher priority than "&" ,I think it should be changed to:
>  
> if (! (memctl->br1 & 1))
>  
> please check this question, 
> thanks!___

It would have helped if you formulated your inquiry in the form of a
patch.

Nevertheless to me it seems like this problem has been fixed in mainline
by this commit:

commit f51cdaf19141151ce2b40d562a468605340f2315
Author: Becky Bruce 
Date:   Thu Jun 17 11:37:20 2010 -0500

83xx/85xx/86xx: LBC register cleanup

Currently, 83xx, 86xx, and 85xx have a lot of duplicated code
dedicated to defining and manipulating the LBC registers.  Merge
this into a single spot.

To do this, we have to decide on a common name for the data structure
that holds the lbc registers - it will now be known as fsl_lbc_t, and we
adopt a common name for the immap layouts that include the lbc - this was
previously known as either im_lbc or lbus; use the former.

In addition, create accessors for the BR/OR regs that use in/out_be32
and use those instead of the mismash of access methods currently in play.

I have done a successful ppc build all and tested a board or two from
each processor family.

Signed-off-by: Becky Bruce 
Acked-by: Kim Phillips 
Signed-off-by: Kumar Gala 


The change includes this code replacement:

+#ifdef CONFIG_MPC85xx
+   /* if cs1 is already set via debugger, leave cs0/cs1 alone */
+   if (get_lbc_br(1) & BR_V)
+   init_br1 = 0;
+#endif

So it does indeed seem to fix the problem you noted.

Cheers
  Detlev

-- 
The proprietary-Unix players proved so ponderous, so blind, and so inept at
marketing that Microsoft was able to grab away a large part of their market
with the shockingly inferior technology of its Windows operating system.
   -- "A Brief History of Hackerdom" by Eric Steven Raymond
--
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