Re: [U-Boot] Ethernet HW loopack test

[Guy Morand]

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: mardi 21 décembre 2010 16:04
> To: Guy Morand
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] Ethernet HW loopack test
> 
> Dear Guy Morand,
> 
> please restrict your line length to approx 70 characters or so.

Yes sorry in my company they use the great M$ outlook 2010, I'm not very 
familiar
and apparently it does not know about "automatic carriage return" ... 
Adding ">" to the eplies was already a Big mess ... I'll do my best in the 
future!

> 
> In message
>  al> you wrote:
> >
> > I'm trying to write an U-Boot command to ping the other interface on
> > my pla tform. This is to test the hardware at production, the ping
> > must hit the wi re. I got deeply inspired from this patch:
> > http://lists.denx.de/pipermail/u-boot/2005-March/009317.html
> 
> I hope you also ready my comments.  These still apply.
> 
> > What changes is that I really want to ping the other interface with a
> > cross  cable and not using a special "home made" device ... The
> > problem is when I  send the ping, it is the same interface that
> > answers (the one that sent th e ping), this is not what I want. I
> > thought by changing the destination MAC  address in the packet and
> > initializing it, the other interface should answ er by itself. Actually 
> > this is not
> the case...
> ...
> > I checked with Wireshark, the packet is correctly build. Maybe my
> > approach is flawed ! Or maybe do you have another way to perform that
> kind of test ?
> 
> You a run into a number of very basic limitations here.
> 
> First, U-Boot has, so far, no clean device model yet. In your case this means
> that we can enable only one Ethenret interface at a time.
> When you enable one interface (to send a packet), all other interfaces are
> shut down and disabled, so they will never be able to see the packet, even if
> it arrives as intended.  We have been discussing improvments in this area in
> the past, but nothing got implemented or even designed yet.
> 
> Second, U-Boot is strictly single-tasking. Even if we had a better driver
> interface so we were able to "open" two network interfaces simultaneously,
> we have no infrastructure in place to run independend "send" and "receive"
> tasks.
> 
> If local loopback tests are not sufficient, you will probably find it easiest 
> to
> perform such testing using an external test machine with two network
> interfaces.
> 
> Best regards,
> 
> Wolfgang Denk

Thanks for your reply, this is more or less what I thought in my bath yesterday
evening !

> 
> --
> 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 hard to think of you as the end result of millions of  years  of 
> evolution.

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Wolfgang Denk]

Dear Dirk Behme,

In message <4d11a65e.8040...@googlemail.com> you wrote:
>
> Btw, I tried to send a summary of our issues to the Codesourcery =
> 
> mailing list:
> 
> http://www.codesourcery.com/archives/arm-gnu/msg03989.html
> 
> Let's see if we get an answer.

You got one:
http://www.codesourcery.com/archives/arm-gnu/msg03990.html

And it sounds like a reasonable explanation to me.

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
Cigarette, n.: A fire at one end, a fool at the other, and a  bit  of
tobacco in between.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Michal Simek]

Wolfgang Denk wrote:
> Dear Michal Simek,
> 
> In message <4d119d06.2010...@monstr.eu> you wrote:
>>> Please omit the "-pcs" part.  It has always been my personal
>>> preference, but I've been overruled, and we use plain Lindent these
>>> days.
>> Ok. Would it be possible to remove it from coding style page.
>> http://www.denx.de/wiki/U-Boot/CodingStyle
> 
> Sure, done.
> 
> Note: you could have fixed this yourself.  The DULG is a wiki, and
> everybody can contribute to correct and extend the documentation.
> 
>> I just used what there is.
> 
> I understand, sorry for the confusion.

No problem,

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Dirk Behme]

On 22.12.2010 08:02, Albert ARIBAUD wrote:
> Le 22/12/2010 01:11, Alexander Holler a écrit :
>> Am 21.12.2010 21:04, schrieb Dirk Behme:
>>> On 21.12.2010 20:52, Wolfgang Denk wrote:
 Dear Albert& friends,

 what is your opinion?  Should we include the memory barrier patch into
 the upcoming release (and eventually delay it for further testing), or
 release as is and solve this issue in the next release?

 I tend to leave it as is, as I expect that most people will disappear
 in the next few days for holidays, so no much testing will be done
 anyway, and we then can solve this with less pressure in the next
 release - but I'm not really sure if this is a good idea?
>>>
>>> I somehow tend to leave it as is, too.
>>>
>>> We have issues with some recent compilers. For these we found a fix
>>> using the io.h somehow the same way the Linux kernel does. But this
>>> introduces new issues for us, we haven't found a proper fix yet
>>> (except changing the code to the 'old' io.h style). But we don't know
>>> where we might have this issue additionally, yet.
>>
>> The only real problem found with that patch was one with a register
>> which doesn't like an (unmotivated) read after write.
>
> Yes, and this is enough for me to not want it right away: we caught this
> one, but how many others, so far unseen, will creep up?
>
>> On the other side, without that patch, using gcc>= 4.5.x (at least on
>> arm) proved to fail. In contrast to that problem of gcc 4.5.x ignoring
>> that volatile, 4.5.x still fixes many bugs for arm and gcc>= 4.5.x is
>> necessary for hardfloat. So it's likely that more people will start
>> using 4.5.x (4.5.2 was just released).
>
> Do we need hard floating point in u-boot? IIRC, and unless this changed,
> the kernel does not want floating point, so I wonder why u-boot would.
>
> As for getting 4.5 to work, for the next cycle people can still use pre
> 4.5 gccs / toolchains, so this is important but not urgent to the point
> of rushing decisions.

Agree.

Btw, I tried to send a summary of our issues to the Codesourcery 
mailing list:

http://www.codesourcery.com/archives/arm-gnu/msg03989.html

Let's see if we get an answer.

Best regards

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Albert ARIBAUD]

Le 22/12/2010 01:11, Alexander Holler a écrit :
> Am 21.12.2010 21:04, schrieb Dirk Behme:
>> On 21.12.2010 20:52, Wolfgang Denk wrote:
>>> Dear Albert&friends,
>>>
>>> what is your opinion?  Should we include the memory barrier patch into
>>> the upcoming release (and eventually delay it for further testing), or
>>> release as is and solve this issue in the next release?
>>>
>>> I tend to leave it as is, as I expect that most people will disappear
>>> in the next few days for holidays, so no much testing will be done
>>> anyway, and we then can solve this with less pressure in the next
>>> release - but I'm not really sure if this is a good idea?
>>
>> I somehow tend to leave it as is, too.
>>
>> We have issues with some recent compilers. For these we found a fix
>> using the io.h somehow the same way the Linux kernel does. But this
>> introduces new issues for us, we haven't found a proper fix yet
>> (except changing the code to the 'old' io.h style). But we don't know
>> where we might have this issue additionally, yet.
>
> The only real problem found with that patch was one with a register
> which doesn't like an (unmotivated) read after write.

Yes, and this is enough for me to not want it right away: we caught this 
one, but how many others, so far unseen, will creep up?

> On the other side, without that patch, using gcc>= 4.5.x (at least on
> arm) proved to fail. In contrast to that problem of gcc 4.5.x ignoring
> that volatile, 4.5.x still fixes many bugs for arm and gcc>= 4.5.x is
> necessary for hardfloat. So it's likely that more people will start
> using 4.5.x (4.5.2 was just released).

Do we need hard floating point in u-boot? IIRC, and unless this changed, 
the kernel does not want floating point, so I wonder why u-boot would.

As for getting 4.5 to work, for the next cycle people can still use pre 
4.5 gccs / toolchains, so this is important but not urgent to the point 
of rushing decisions.

> Regards,
>
> Alexander

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

Re: [U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Wolfgang Denk]

Dear Michal Simek,

In message <4d119d06.2010...@monstr.eu> you wrote:
>
> > Please omit the "-pcs" part.  It has always been my personal
> > preference, but I've been overruled, and we use plain Lindent these
> > days.
> 
> Ok. Would it be possible to remove it from coding style page.
> http://www.denx.de/wiki/U-Boot/CodingStyle

Sure, done.

Note: you could have fixed this yourself.  The DULG is a wiki, and
everybody can contribute to correct and extend the documentation.

> I just used what there is.

I understand, sorry for the confusion.

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
"Beware of programmers carrying screwdrivers."  - Chip Salzenberg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Michal Simek]

Wolfgang Denk wrote:
> Dear Michal Simek,
> 
> In message <4d1107d2.7070...@monstr.eu> you wrote:
>>> These changes are to the worse.  All.  Why do you think this would be
>>> better?
>> It is what intend suggest to do.
>> intend -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 -pcs
> 
> Please omit the "-pcs" part.  It has always been my personal
> preference, but I've been overruled, and we use plain Lindent these
> days.

Ok. Would it be possible to remove it from coding style page.
http://www.denx.de/wiki/U-Boot/CodingStyle

I just used what there is.

Best regards,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] s3c44b0/start.S: should clear .bss

[Minkyu Kang]

Dear Ender Dai,

On 10 May 2010 15:26, Ender Dai  wrote:
> .bss section should be zeroed out after relocat to ram.
>
> Signed-off-by: Ender Dai 
> ---
>  arch/arm/cpu/s3c44b0/start.S |    9 +
>  1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/s3c44b0/start.S b/arch/arm/cpu/s3c44b0/start.S
> index fe6b349..08722c1 100644
> --- a/arch/arm/cpu/s3c44b0/start.S
> +++ b/arch/arm/cpu/s3c44b0/start.S

Now, clear_bss function is applied by other patch.
Sorry to late review.
Thanks.

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler]

Am 21.12.2010 21:04, schrieb Dirk Behme:
> On 21.12.2010 20:52, Wolfgang Denk wrote:
>> Dear Albert&   friends,
>>
>> what is your opinion?  Should we include the memory barrier patch into
>> the upcoming release (and eventually delay it for further testing), or
>> release as is and solve this issue in the next release?
>>
>> I tend to leave it as is, as I expect that most people will disappear
>> in the next few days for holidays, so no much testing will be done
>> anyway, and we then can solve this with less pressure in the next
>> release - but I'm not really sure if this is a good idea?
>
> I somehow tend to leave it as is, too.
>
> We have issues with some recent compilers. For these we found a fix
> using the io.h somehow the same way the Linux kernel does. But this
> introduces new issues for us, we haven't found a proper fix yet
> (except changing the code to the 'old' io.h style). But we don't know
> where we might have this issue additionally, yet.

The only real problem found with that patch was one with a register 
which doesn't like an (unmotivated) read after write.

On the other side, without that patch, using gcc >= 4.5.x (at least on 
arm) proved to fail. In contrast to that problem of gcc 4.5.x ignoring 
that volatile, 4.5.x still fixes many bugs for arm and gcc >= 4.5.x is 
necessary for hardfloat. So it's likely that more people will start 
using 4.5.x (4.5.2 was just released).

Regards,

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Albert ARIBAUD]

Le 21/12/2010 21:04, Dirk Behme a écrit :

> I somehow tend to leave it as is, too.

Agree.

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

Re: [U-Boot] [PATCH 3/3] microblaze: Fix bdiinfo pointer

[Wolfgang Denk]

Dear Michal Simek,

In message <4dcf.5090...@monstr.eu> you wrote:
>
> >> @@ -91,15 +91,16 @@ void board_init (void)
> >>bd_t *bd;
> >>init_fnc_t **init_fnc_ptr;
> >>gd = (gd_t *) CONFIG_SYS_GBL_DATA_OFFSET;
> >> +  bd = (bd_t *) CONFIG_SYS_GBL_DATA_OFFSET - GENERATED_BD_INFO_SIZE;
> > 
> > This is actually wrong.
> > 
> > You are using CONFIG_SYS_GBL_DATA_OFFSET as if it were
> > CONFIG_SYS_GBL_DATA_ADDR, but it ain't so:  it is an _offset_, and NOT
> > and address.
> 
> I agree. BTW: Maybe nios2 and sparc use it too.

I see - I put the custodians on Cc:.

> >> -  memset ((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
> >> -  gd->bd = (bd_t *) (gd + 1); /* At end of global data */
> >> +  memset ((void *)bd, 0, GENERATED_GBL_DATA_SIZE
> >> +  + GENERATED_BD_INFO_SIZE);
> > 
> > Don't do this. Instead, use two separate memset() calls, one for gd
> > and another one for bd. The stucts may be in a contiguous area now,
> > but you would probably run into nasty bugs if this gets changed one
> > day.
> 
> I just wanted to save some instructions and no problem to separate it.

Yes, I understand this, but it's a dangerous thing to so, and
robust and maintainable code is more important than a few bytes.

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
Never call a man a fool.  Borrow from him.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Wolfgang Denk]

Dear Michal Simek,

In message <4d1107d2.7070...@monstr.eu> you wrote:
>
> > These changes are to the worse.  All.  Why do you think this would be
> > better?
> 
> It is what intend suggest to do.
> intend -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 -pcs

Please omit the "-pcs" part.  It has always been my personal
preference, but I've been overruled, and we use plain Lindent these
days.

> I am OK to remove space between macro name and argument as you suggested 
> in your other email.
> 
>  >> + DEFINE (GENERATED_GBL_DATA_SIZE,
>  >> + (sizeof (struct global_data) + 15) & ~15);
>  ^ ^   ^ ^
> 
> I believe that marked space are OK, or not?

Yes.

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 God had wanted us to use the metric system, Jesus would have  had
10 apostles."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] microblaze: Fix bd_info pointer

[Michal Simek]

Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
(sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
(currently 0x40).
Microblaze configs used 0x40(128) because this place also contained
board info structure which lies on the top of ram.

U-Boot is placed to the top of the ram (for example 0xd7ff)
and bd structure was moved out of ram.

This patch is fixing this scheme with GENERATED_BD_INFO_SIZE
which swap global data and board info structures.

For example:
Current: gd 0xd7c0, bd 0xd800
Fixed:   gd 0xd7c0, bd 0xd790

Signed-off-by: Michal Simek 
---
 arch/microblaze/lib/board.c  |8 +---
 include/configs/microblaze-generic.h |8 
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/microblaze/lib/board.c b/arch/microblaze/lib/board.c
index eeef579..b06212e 100644
--- a/arch/microblaze/lib/board.c
+++ b/arch/microblaze/lib/board.c
@@ -90,16 +90,18 @@ void board_init (void)
 {
bd_t *bd;
init_fnc_t **init_fnc_ptr;
-   gd = (gd_t *) CONFIG_SYS_GBL_DATA_OFFSET;
+   gd = (gd_t *) (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_GBL_DATA_OFFSET);
+   bd = (bd_t *) (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_GBL_DATA_OFFSET \
+   - GENERATED_BD_INFO_SIZE);
char *s;
 #if defined(CONFIG_CMD_FLASH)
ulong flash_size = 0;
 #endif
asm ("nop");/* FIXME gd is not initialize - wait */
memset ((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
-   gd->bd = (bd_t *) (gd + 1); /* At end of global data */
+   memset ((void *)bd, 0, GENERATED_BD_INFO_SIZE);
+   gd->bd = bd;
gd->baudrate = CONFIG_BAUDRATE;
-   bd = gd->bd;
bd->bi_baudrate = CONFIG_BAUDRATE;
bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
diff --git a/include/configs/microblaze-generic.h 
b/include/configs/microblaze-generic.h
index 75e4e07..090ab3b 100644
--- a/include/configs/microblaze-generic.h
+++ b/include/configs/microblaze-generic.h
@@ -137,14 +137,14 @@
 /* global pointer */
 /* start of global data */
 #defineCONFIG_SYS_GBL_DATA_OFFSET \
-   (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_SDRAM_SIZE \
-   - GENERATED_GBL_DATA_SIZE)
+   (CONFIG_SYS_SDRAM_SIZE - GENERATED_GBL_DATA_SIZE)
 
 /* monitor code */
 #defineSIZE0x4
-#defineCONFIG_SYS_MONITOR_LEN  (SIZE - GENERATED_GBL_DATA_SIZE)
+#defineCONFIG_SYS_MONITOR_LEN  SIZE
 #defineCONFIG_SYS_MONITOR_BASE \
-   (CONFIG_SYS_GBL_DATA_OFFSET - CONFIG_SYS_MONITOR_LEN)
+   (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_GBL_DATA_OFFSET \
+   - CONFIG_SYS_MONITOR_LEN - GENERATED_BD_INFO_SIZE)
 #defineCONFIG_SYS_MONITOR_END \
(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)
 #defineCONFIG_SYS_MALLOC_LEN   SIZE
-- 
1.5.5.6

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

Re: [U-Boot] [PATCH 3/3] microblaze: Fix bdiinfo pointer

[Michal Simek]

Wolfgang Denk wrote:
> Dear Michal Simek,
> 
> In message <1292955178-13018-3-git-send-email-mon...@monstr.eu> you wrote:
>> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
>> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
>> introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
>> (currently 0x40).
>> Microblaze configs used 0x40(128) because this place also contained
>> board info structure which lies on the top of ram.
> 
> In the Subject: s/bdiinfo/bd_info/
> 
>> index eeef579..8232cf0 100644
>> --- a/arch/microblaze/lib/board.c
>> +++ b/arch/microblaze/lib/board.c
>> @@ -91,15 +91,16 @@ void board_init (void)
>>  bd_t *bd;
>>  init_fnc_t **init_fnc_ptr;
>>  gd = (gd_t *) CONFIG_SYS_GBL_DATA_OFFSET;
>> +bd = (bd_t *) CONFIG_SYS_GBL_DATA_OFFSET - GENERATED_BD_INFO_SIZE;
> 
> This is actually wrong.
> 
> You are using CONFIG_SYS_GBL_DATA_OFFSET as if it were
> CONFIG_SYS_GBL_DATA_ADDR, but it ain't so:  it is an _offset_, and NOT
> and address.

I agree. BTW: Maybe nios2 and sparc use it too.

> 
>> -memset ((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
>> -gd->bd = (bd_t *) (gd + 1); /* At end of global data */
>> +memset ((void *)bd, 0, GENERATED_GBL_DATA_SIZE
>> ++ GENERATED_BD_INFO_SIZE);
> 
> Don't do this. Instead, use two separate memset() calls, one for gd
> and another one for bd. The stucts may be in a contiguous area now,
> but you would probably run into nasty bugs if this gets changed one
> day.

I just wanted to save some instructions and no problem to separate it.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/15] powerpc/8xxx: Rework XES boards pci_init_board to use common FSL PCIe code

[Peter Tyser]

On Tue, 2010-12-21 at 11:49 -0600, Kumar Gala wrote:
> On Dec 20, 2010, at 10:49 AM, Peter Tyser wrote:
> 
> > Thanks for the cleanup.  What branch should this series be applied to?
> > And are there prerequisites?  I'm having issues applying them to test
> > and review.

Any direction on how these should be applied for testing?



> >> --- a/board/xes/common/fsl_8xxx_pci.c
> >> +++ b/board/xes/common/fsl_8xxx_pci.c
> >> @@ -34,15 +34,6 @@
> >> #ifdef CONFIG_PCI1
> >> static struct pci_controller pci1_hose;
> >> #endif
> > 
> > Is there a reason PCI1 wasn't changed over too?  I see pci1_hose is
> > still referenced below, but other boards with a PCI1 don't use similar
> > code.
> 
> I was trying to limit how much clean up I did so left this to just PCIe 
> interfaces.  Normal PCI and PCI-X is something I might get around to but one 
> thing at a time

Ah, OK.  If we're removing the LAW entries for PCI1 in law.c below, how
is a LAW being set for PCI1?  It looks like PCIe laws are set in
fsl_configure_pcie(), and PCI LAWs are set via set_next_law() in
board-specific code?  I'm not seeing the call to set_next_law() in X-ES
board specific code after this change though.

Best,
Peter

> > 
> > 
> >> diff --git a/board/xes/xpedite520x/law.c b/board/xes/xpedite520x/law.c
> >> index bbfcb9d..3afb3ae 100644
> >> --- a/board/xes/xpedite520x/law.c
> >> +++ b/board/xes/xpedite520x/law.c
> >> @@ -38,10 +38,6 @@ struct law_entry law_table[] = {
> >>/* LBC window - maps 256M 0xf000 -> 0x */
> >>SET_LAW(CONFIG_SYS_FLASH_BASE2, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
> >>SET_LAW(CONFIG_SYS_NAND_BASE, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
> >> -#if CONFIG_SYS_PCI1_MEM_PHYS
> >> -  SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_1G, LAW_TRGT_IF_PCI_1),
> >> -  SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_8M, LAW_TRGT_IF_PCI_1),
> >> -#endif
> >> #if CONFIG_SYS_PCI2_MEM_PHYS
> >>SET_LAW(CONFIG_SYS_PCI2_MEM_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_PCI_2),
> >>SET_LAW(CONFIG_SYS_PCI2_IO_PHYS, LAW_SIZE_8M, LAW_TRGT_IF_PCI_2),


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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Dirk Behme]

On 21.12.2010 20:52, Wolfgang Denk wrote:
> Dear Albert&  friends,
>
> what is your opinion?  Should we include the memory barrier patch into
> the upcoming release (and eventually delay it for further testing), or
> release as is and solve this issue in the next release?
>
> I tend to leave it as is, as I expect that most people will disappear
> in the next few days for holidays, so no much testing will be done
> anyway, and we then can solve this with less pressure in the next
> release - but I'm not really sure if this is a good idea?

I somehow tend to leave it as is, too.

We have issues with some recent compilers. For these we found a fix 
using the io.h somehow the same way the Linux kernel does. But this 
introduces new issues for us, we haven't found a proper fix yet 
(except changing the code to the 'old' io.h style). But we don't know 
where we might have this issue additionally, yet.

I would like to talk with some tool chain guys about this, too.

Could we add a readme or a note somewhere about the issues with the 
recent tool chains in this release?

Best regards

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

Re: [U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Michal Simek]

Wolfgang Denk wrote:
> Dear Michal Simek,
> 
> In message <1292955178-13018-1-git-send-email-mon...@monstr.eu> you wrote:
>> Clear coding style issues.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>  lib/asm-offsets.c |6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
>> index 2209561..f1af7e2 100644
>> --- a/lib/asm-offsets.c
>> +++ b/lib/asm-offsets.c
>> @@ -19,11 +19,11 @@
>>  
>>  #include 
>>  
>> -int main(void)
>> +int main (void)
>>  {
>>  /* Round up to make sure size gives nice stack alignment */
>> -DEFINE(GENERATED_GBL_DATA_SIZE,
>> -(sizeof(struct global_data)+15) & ~15);
>> +DEFINE (GENERATED_GBL_DATA_SIZE,
>> +(sizeof (struct global_data) + 15) & ~15);
> 
> These changes are to the worse.  All.  Why do you think this would be
> better?

It is what intend suggest to do.
intend -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 -pcs

I am OK to remove space between macro name and argument as you suggested 
in your other email.

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

I believe that marked space are OK, or not?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Wolfgang Denk]

Dear Albert & friends,

what is your opinion?  Should we include the memory barrier patch into
the upcoming release (and eventually delay it for further testing), or
release as is and solve this issue in the next release?

I tend to leave it as is, as I expect that most people will disappear
in the next few days for holidays, so no much testing will be done
anyway, and we then can solve this with less pressure in the next
release - but I'm not really sure if this is a good idea?

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
A committee is a life form with six or more legs and no brain.
  -- Lazarus Long, "Time Enough For Love"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Move DECLARE_GLOBAL_DATA_PTR to file scope

[Wolfgang Denk]

Dear John Rigby,

In message <1292894871-1436-1-git-send-email-john.ri...@linaro.org> you wrote:
> It can be optimised out by the compiler otherwise resulting
> in obscure errors like a board not booting.
> 
> This has been documented in README since 2006 when these were
> first fixed up for GCC 4.x.
> 
> Signed-off-by: John Rigby 
> ---
>  arch/arm/cpu/armv7/mx5/speed.c  |4 ++--
>  arch/blackfin/cpu/serial.c  |3 ++-
>  arch/m68k/cpu/mcf547x_8x/speed.c|4 ++--
>  arch/sh/lib/board.c |4 ++--
>  board/espt/espt.c   |4 ++--
>  board/isee/igep0020/igep0020.c  |4 ++--
>  board/isee/igep0030/igep0030.c  |4 ++--
>  board/linkstation/linkstation.c |3 ++-
>  board/logicpd/zoom1/zoom1.c |5 +++--
>  board/logicpd/zoom2/zoom2.c |3 ++-
>  board/mpr2/mpr2.c   |4 ++--
>  board/ms7720se/ms7720se.c   |4 ++--
>  board/ms7722se/ms7722se.c   |4 ++--
>  board/ms7750se/ms7750se.c   |4 ++--
>  board/overo/overo.c |4 ++--
>  board/pandora/pandora.c |4 ++--
>  board/renesas/MigoR/migo_r.c|4 ++--
>  board/renesas/ap325rxa/ap325rxa.c   |4 ++--
>  board/renesas/r2dplus/r2dplus.c |4 ++--
>  board/renesas/r7780mp/r7780mp.c |4 ++--
>  board/renesas/rsk7203/rsk7203.c |4 ++--
>  board/renesas/sh7763rdp/sh7763rdp.c |4 ++--
>  board/renesas/sh7785lcr/sh7785lcr.c |4 ++--
>  board/samsung/smdk6400/smdk6400.c   |4 ++--
>  board/ti/beagle/beagle.c|4 ++--
>  board/ti/evm/evm.c  |4 ++--
>  board/ti/sdp3430/sdp.c  |4 ++--
>  drivers/i2c/omap24xx_i2c.c  |3 ++-
>  drivers/serial/s3c64xx.c|3 ++-
>  drivers/serial/serial_s5p.c |3 ++-
>  drivers/serial/serial_sh.c  |5 +++--
>  31 files changed, 64 insertions(+), 56 deletions(-)

Applied to master (with the additional fixes I mentioned).  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
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] load_addr: move to common env code

[Mike Frysinger]

Rather than keep the load_addr definition with the bootm code (which
just happens to use this), move it to the common env code.  This way
we can disable bootm support completely while retaining load_addr
usage with many other commands.

Signed-off-by: Mike Frysinger 
---
 common/cmd_bootm.c  |1 -
 common/cmd_nvedit.c |2 ++
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 1a024f1..b7f96c2 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -157,7 +157,6 @@ static boot_os_fn *boot_os[] = {
 #endif
 };
 
-ulong load_addr = CONFIG_SYS_LOAD_ADDR;/* Default Load Address */
 static bootm_headers_t images; /* pointers to os/initrd/fdt images */
 
 /* Allow for arch specific config before we boot */
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index dcc93c1..e9d3d1b 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -76,6 +76,8 @@ SPI_FLASH|MG_DISK|NVRAM|MMC|NOWHERE}
  */
 #defineMAX_ENV_SIZE(1 << 20)   /* 1 MiB */
 
+ulong load_addr = CONFIG_SYS_LOAD_ADDR;/* Default Load Address */
+
 /*
  * Table with supported baudrates (defined in config_xyz.h)
  */
-- 
1.7.3.4

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

Re: [U-Boot] [PATCH 3/3] microblaze: Fix bdiinfo pointer

[Wolfgang Denk]

Dear Michal Simek,

In message <1292955178-13018-3-git-send-email-mon...@monstr.eu> you wrote:
> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
> introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
> (currently 0x40).
> Microblaze configs used 0x40(128) because this place also contained
> board info structure which lies on the top of ram.

In the Subject: s/bdiinfo/bd_info/

> index eeef579..8232cf0 100644
> --- a/arch/microblaze/lib/board.c
> +++ b/arch/microblaze/lib/board.c
> @@ -91,15 +91,16 @@ void board_init (void)
>   bd_t *bd;
>   init_fnc_t **init_fnc_ptr;
>   gd = (gd_t *) CONFIG_SYS_GBL_DATA_OFFSET;
> + bd = (bd_t *) CONFIG_SYS_GBL_DATA_OFFSET - GENERATED_BD_INFO_SIZE;

This is actually wrong.

You are using CONFIG_SYS_GBL_DATA_OFFSET as if it were
CONFIG_SYS_GBL_DATA_ADDR, but it ain't so:  it is an _offset_, and NOT
and address.

> - memset ((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
> - gd->bd = (bd_t *) (gd + 1); /* At end of global data */
> + memset ((void *)bd, 0, GENERATED_GBL_DATA_SIZE
> + + GENERATED_BD_INFO_SIZE);

Don't do this. Instead, use two separate memset() calls, one for gd
and another one for bd. The stucts may be in a contiguous area now,
but you would probably run into nasty bugs if this gets changed one
day.

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 usually tell my classes "if you are using @ and [] together in this
class, you will almost certainly NOT get what you want. That's  going
down  the wrong tunnel. There's no cheese at the end of that tunnel."
 -- Randal L. Schwartz in <8czptuomey@gadget.cscaper.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] Autogenerate GENERATED_BD_INFO_SIZE

[Wolfgang Denk]

Dear Michal Simek,

In message <1292955178-13018-2-git-send-email-mon...@monstr.eu> you wrote:
> GENERATED_BD_INFO_SIZE represent sizeof bd_info structure
> which is used across architectures.
> This value can be used in assembler files and macros.
> 
> Signed-off-by: Michal Simek 
> ---
>  lib/asm-offsets.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
> index f1af7e2..8aba391 100644
> --- a/lib/asm-offsets.c
> +++ b/lib/asm-offsets.c
> @@ -24,6 +24,7 @@ int main (void)
>   /* Round up to make sure size gives nice stack alignment */
>   DEFINE (GENERATED_GBL_DATA_SIZE,
>   (sizeof (struct global_data) + 15) & ~15);
> + DEFINE (GENERATED_BD_INFO_SIZE, (sizeof (struct bd_info) + 15) & ~15);

Please remove the space between macro name and argument list.

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
Anything free is worth what you pay for it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Wolfgang Denk]

Dear Michal Simek,

In message <1292955178-13018-1-git-send-email-mon...@monstr.eu> you wrote:
> Clear coding style issues.
> 
> Signed-off-by: Michal Simek 
> ---
>  lib/asm-offsets.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
> index 2209561..f1af7e2 100644
> --- a/lib/asm-offsets.c
> +++ b/lib/asm-offsets.c
> @@ -19,11 +19,11 @@
>  
>  #include 
>  
> -int main(void)
> +int main (void)
>  {
>   /* Round up to make sure size gives nice stack alignment */
> - DEFINE(GENERATED_GBL_DATA_SIZE,
> - (sizeof(struct global_data)+15) & ~15);
> + DEFINE (GENERATED_GBL_DATA_SIZE,
> + (sizeof (struct global_data) + 15) & ~15);

These changes are to the worse.  All.  Why do you think this would be
better?


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
Weekends were made for programming. - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ARM] gap between _start and CONFIG_SYS_TEXT_BASE

[Wolfgang Denk]

Dear Sergey Mironov,

In message  you 
wrote:
>
> Well, the newest one I've tried was arm-none-linux-gnueabi-gcc (Gentoo
> 4.4.4-r1 p1.1, pie-0.4.5) 4.4.4. But I found it broken since it messed
> up relocation-related sections for some reason.  What compiler you
> think I should try?

I don't know and cannot comment on the gentoo compilers, but there is
plenty of other options: Poky, Linaro, ELDK, CodeSourcery,
OpenEmbedded, ...

> >> Text_base: 0x00100010
> >
> > Is there a special reason for chosing such an odd address?
> >
> > Why don't you use 0x0010 ?
> 
> Our SoC's bootloader expects this strange address. It is hardcoded
> into chip and can't be changed :(

This statement makes zero sense to me.  Your "SoC's bootloader" cannot
know or deman where you are linking your image to. It may expect a
certain entry point address, that's all - but that is completely
independent of TEXT_BASE.

> I branched out from commit # 227b7251554 and tried to stay default as
> much as possible. So I am using cpu/arm1176's default  u-boot.lds and
> start.S

OK. I recommend to adjust start.S for your entry point requirements,
and leave CONFIG_SYS_TEXT_BASE at a sane value instead.

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
Always try to do things in chronological order; it's  less  confusing
that way.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] microblaze: Fix bdiinfo pointer

[Michal Simek]

Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
(sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
(currently 0x40).
Microblaze configs used 0x40(128) because this place also contained
board info structure which lies on the top of ram.

U-Boot is placed to the top of the ram (for example 0xd7ff)
and bd structure was moved out of ram.

This patch is fixing this scheme with GENERATED_BD_INFO_SIZE
which swap global data and board info structures.

For example:
Current: gd 0xd7c0, bd 0xd800
Fixed:   gd 0xd7c0, bd 0xd790

Signed-off-by: Michal Simek 
---
 arch/microblaze/lib/board.c  |7 ---
 include/configs/microblaze-generic.h |5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/microblaze/lib/board.c b/arch/microblaze/lib/board.c
index eeef579..8232cf0 100644
--- a/arch/microblaze/lib/board.c
+++ b/arch/microblaze/lib/board.c
@@ -91,15 +91,16 @@ void board_init (void)
bd_t *bd;
init_fnc_t **init_fnc_ptr;
gd = (gd_t *) CONFIG_SYS_GBL_DATA_OFFSET;
+   bd = (bd_t *) CONFIG_SYS_GBL_DATA_OFFSET - GENERATED_BD_INFO_SIZE;
char *s;
 #if defined(CONFIG_CMD_FLASH)
ulong flash_size = 0;
 #endif
asm ("nop");/* FIXME gd is not initialize - wait */
-   memset ((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
-   gd->bd = (bd_t *) (gd + 1); /* At end of global data */
+   memset ((void *)bd, 0, GENERATED_GBL_DATA_SIZE
+   + GENERATED_BD_INFO_SIZE);
+   gd->bd = bd;
gd->baudrate = CONFIG_BAUDRATE;
-   bd = gd->bd;
bd->bi_baudrate = CONFIG_BAUDRATE;
bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
diff --git a/include/configs/microblaze-generic.h 
b/include/configs/microblaze-generic.h
index 75e4e07..fdfc0d8 100644
--- a/include/configs/microblaze-generic.h
+++ b/include/configs/microblaze-generic.h
@@ -142,9 +142,10 @@
 
 /* monitor code */
 #defineSIZE0x4
-#defineCONFIG_SYS_MONITOR_LEN  (SIZE - GENERATED_GBL_DATA_SIZE)
+#defineCONFIG_SYS_MONITOR_LEN  SIZE
 #defineCONFIG_SYS_MONITOR_BASE \
-   (CONFIG_SYS_GBL_DATA_OFFSET - CONFIG_SYS_MONITOR_LEN)
+   (CONFIG_SYS_GBL_DATA_OFFSET - CONFIG_SYS_MONITOR_LEN \
+   - GENERATED_BD_INFO_SIZE)
 #defineCONFIG_SYS_MONITOR_END \
(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)
 #defineCONFIG_SYS_MALLOC_LEN   SIZE
-- 
1.5.5.6

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

[U-Boot] [PATCH 2/3] Autogenerate GENERATED_BD_INFO_SIZE

[Michal Simek]

GENERATED_BD_INFO_SIZE represent sizeof bd_info structure
which is used across architectures.
This value can be used in assembler files and macros.

Signed-off-by: Michal Simek 
---
 lib/asm-offsets.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
index f1af7e2..8aba391 100644
--- a/lib/asm-offsets.c
+++ b/lib/asm-offsets.c
@@ -24,6 +24,7 @@ int main (void)
/* Round up to make sure size gives nice stack alignment */
DEFINE (GENERATED_GBL_DATA_SIZE,
(sizeof (struct global_data) + 15) & ~15);
+   DEFINE (GENERATED_BD_INFO_SIZE, (sizeof (struct bd_info) + 15) & ~15);
 
return 0;
 }
-- 
1.5.5.6

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

[U-Boot] [PATCH 1/3] lib/asm-offsets.c: Clean coding style

[Michal Simek]

Clear coding style issues.

Signed-off-by: Michal Simek 
---
 lib/asm-offsets.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
index 2209561..f1af7e2 100644
--- a/lib/asm-offsets.c
+++ b/lib/asm-offsets.c
@@ -19,11 +19,11 @@
 
 #include 
 
-int main(void)
+int main (void)
 {
/* Round up to make sure size gives nice stack alignment */
-   DEFINE(GENERATED_GBL_DATA_SIZE,
-   (sizeof(struct global_data)+15) & ~15);
+   DEFINE (GENERATED_GBL_DATA_SIZE,
+   (sizeof (struct global_data) + 15) & ~15);
 
return 0;
 }
-- 
1.5.5.6

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

[U-Boot] [PATCH] ppc4xx: Remove PCI support from lwmon5

[Stefan Roese]

PCI is not used at all on lwmon5. So lets remove it. It saves space and
reduces boot time a bit (approx. 50ms).

Signed-off-by: Stefan Roese 
---
 include/configs/lwmon5.h |   17 -
 1 files changed, 0 insertions(+), 17 deletions(-)

diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index aedf495..a1ead70 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -440,7 +440,6 @@
 #define CONFIG_CMD_MII
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_NFS
-#define CONFIG_CMD_PCI
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_REGINFO
 #define CONFIG_CMD_SDRAM
@@ -488,22 +487,6 @@
 #define CONFIG_MX_CYCLIC1   /* enable mdc/mwc commands  */
 #define CONFIG_VERSION_VARIABLE 1  /* include version env variable */
 
-/*
- * PCI stuff
- */
-/* General PCI */
-#define CONFIG_PCI /* include pci support  */
-#undef CONFIG_PCI_PNP  /* do (not) pci plug-and-play   */
-#define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup  */
-#define CONFIG_SYS_PCI_TARGBASE0x8000 /* PCIaddr mapped to 
CONFIG_SYS_PCI_MEMBASE*/
-
-/* Board-specific PCI */
-#define CONFIG_SYS_PCI_TARGET_INIT
-#define CONFIG_SYS_PCI_MASTER_INIT
-
-#define CONFIG_SYS_PCI_SUBSYS_VENDORID 0x10e8  /* AMCC 
*/
-#define CONFIG_SYS_PCI_SUBSYS_ID   0xcafe  /* Whatever 
*/
-
 #ifndef DEBUG
 #define CONFIG_HW_WATCHDOG 1   /* Use external HW-Watchdog */
 #endif
-- 
1.7.3.4

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

Re: [U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

Dear Wolfgang Denk:
> 
>> But it runs only , if I use the newer 4.5.1 toolchain. I think, there are
>> toolchain issues with relocation
> 
> Can you please try and investigate the issue?

I found out, that the board hangs if there u-boot access to non SDRAM
memory like NAND or frambuffer. I try to found the reason, but the
compiled code (option -0s) is hard to debug. So I compile the Code
without -Os and the board runs (also arm ELDK).
The question goes to the gcc guru's, what is the difference? The
assembly code is as expected completly different.

regards

Jens Scharsig

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

Re: [U-Boot] [PATCH V3 1/6] tqm85xx: create fixed_sdram() to do sdram setup

[Kumar Gala]

On Dec 17, 2010, at 5:17 PM, Becky Bruce wrote:

> Also, change this code to use phys_size_t instead of long int.
> Using common naming for this function will enable us to use the common
> initdram() for 85xx going forward.  Other than the type change,
> this is just a code rearrange.
> 
> Signed-off-by: Becky Bruce 
> ---
> board/tqc/tqm85xx/sdram.c |   37 +++--
> 1 files changed, 23 insertions(+), 14 deletions(-)

Stefan, Wolfgang,

Any comment as TQM85xx maintainers

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

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Kumar Gala]

On Dec 18, 2010, at 3:27 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message  you 
> wrote:
>> [ a few minor bug fixes for v2010.12 ]
>> 
>> The following changes since commit 3ac45988ab1605baaf83bd3acb80a197c9a208c2:
>> 
>>  Prepare v2010.12-rc3 (2010-12-17 10:15:38 +0100)
>> 
>> are available in the git repository at:
>>  git://git.denx.de/u-boot-mpc85xx master
>> 
>> Jerry Huang (2):
>>  fsl_esdhc: Use mmc_set_clock to set initial speed
>>  fsl_esdhc: Fix max clock frequency
>> 
>> Li Yang (1):
>>  fsl_esdhc: Fix the voltage validation process
> 
> 
> Applied, thanks.
> 
>> Matthew McClintock (1):
>>  p1022ds: enable reginfo command
> 
> No bug fix. Pulled into "next".
> 

Ok, thanks

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

Re: [U-Boot] [PATCH 08/15] powerpc/8xxx: Rework XES boards pci_init_board to use common FSL PCIe code

[Kumar Gala]

On Dec 20, 2010, at 10:49 AM, Peter Tyser wrote:

> Thanks for the cleanup.  What branch should this series be applied to?
> And are there prerequisites?  I'm having issues applying them to test
> and review.
> 
> On Fri, 2010-12-17 at 17:50 -0600, Kumar Gala wrote:
>> Remove duplicated code in MPC8572 DS board and utliize the common
>> fsl_pcie_init_board().
> 
> Looks like a copy/paste from the MPC8572.
> 
> On all the patches in the series s/utliize/utilize/.
> 
> 

Will fix, oops ;)

> 
>> --- a/board/xes/common/fsl_8xxx_pci.c
>> +++ b/board/xes/common/fsl_8xxx_pci.c
>> @@ -34,15 +34,6 @@
>> #ifdef CONFIG_PCI1
>> static struct pci_controller pci1_hose;
>> #endif
> 
> Is there a reason PCI1 wasn't changed over too?  I see pci1_hose is
> still referenced below, but other boards with a PCI1 don't use similar
> code.

I was trying to limit how much clean up I did so left this to just PCIe 
interfaces.  Normal PCI and PCI-X is something I might get around to but one 
thing at a time

> 
>> -#ifdef CONFIG_PCIE1
>> -static struct pci_controller pcie1_hose;
>> -#endif
>> -#ifdef CONFIG_PCIE2
>> -static struct pci_controller pcie2_hose;
>> -#endif
>> -#ifdef CONFIG_PCIE3
>> -static struct pci_controller pcie3_hose;
>> -#endif
> 
> 
> 
>> diff --git a/board/xes/xpedite520x/law.c b/board/xes/xpedite520x/law.c
>> index bbfcb9d..3afb3ae 100644
>> --- a/board/xes/xpedite520x/law.c
>> +++ b/board/xes/xpedite520x/law.c
>> @@ -38,10 +38,6 @@ struct law_entry law_table[] = {
>>  /* LBC window - maps 256M 0xf000 -> 0x */
>>  SET_LAW(CONFIG_SYS_FLASH_BASE2, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
>>  SET_LAW(CONFIG_SYS_NAND_BASE, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
>> -#if CONFIG_SYS_PCI1_MEM_PHYS
>> -SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_1G, LAW_TRGT_IF_PCI_1),
>> -SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_8M, LAW_TRGT_IF_PCI_1),
>> -#endif
>> #if CONFIG_SYS_PCI2_MEM_PHYS
>>  SET_LAW(CONFIG_SYS_PCI2_MEM_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_PCI_2),
>>  SET_LAW(CONFIG_SYS_PCI2_IO_PHYS, LAW_SIZE_8M, LAW_TRGT_IF_PCI_2),
> 
> The PCI2 law can be removed too.  Its not currently used on any boards
> supported by mainline U-Boot.

Ok, will remove in updated patch

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

Re: [U-Boot] [PATCH] microblaze: ll_temac driver: mask of length for newer h/w versions

[Michal Simek]

Hi John,

John Linn wrote:
> The LL TEMAC h/w changed at some point quite some time ago such that
> the length field in the BD is used for other stuff also such that the
> length needs to be masked correctly.  This change is backward
> compatible with older h/w also.
> 
> This change was tested on the 12.2 EDK system on the SP605 board.
> 
> Signed-off-by: John Linn 
> ---
>  drivers/net/xilinx_ll_temac.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

This patch is in my custodian u-boot tree.
We have discussed the ll_temac driver some weeks ago and there are some 
things which needs to be done before this driver will be possible to 
merge to the mainline. The main thing is phy lib and complete driver review.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] microblaze: ll_temac driver: mask of length for newer h/w versions

[John Linn]

The LL TEMAC h/w changed at some point quite some time ago such that
the length field in the BD is used for other stuff also such that the
length needs to be masked correctly.  This change is backward
compatible with older h/w also.

This change was tested on the 12.2 EDK system on the SP605 board.

Signed-off-by: John Linn 
---
 drivers/net/xilinx_ll_temac.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.c
index d73e22e..c31b943 100644
--- a/drivers/net/xilinx_ll_temac.c
+++ b/drivers/net/xilinx_ll_temac.c
@@ -344,7 +344,7 @@ static int xps_ll_temac_recv_sdma(struct eth_device *dev)
return 0;
}
 
-   length = rx_bd.app5;
+   length = rx_bd.app5 & 0x3FFF;
flush_cache ((u32)rx_bd.phys_buf_p, length);
 
rx_bd.buf_len = ETHER_MTU;
-- 
1.6.2.1



This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


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

Re: [U-Boot] [ARM] gap between _start and CONFIG_SYS_TEXT_BASE

[Sergey Mironov]

> In message  you 
> wrote:
>>
>> Compiler: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72)
>> 4.3.2   -- I also tried a couple of other versions without difference.
>
> Did these include more recent versions?  GCC 4.3.x is not exactly what
> I can recommend for ARM systems...

Well, the newest one I've tried was arm-none-linux-gnueabi-gcc (Gentoo
4.4.4-r1 p1.1, pie-0.4.5) 4.4.4. But I found it broken since it messed
up relocation-related sections for some reason.  What compiler you
think I should try?

>
>> Text_base: 0x00100010
>
> Is there a special reason for chosing such an odd address?
>
> Why don't you use 0x0010 ?

Our SoC's bootloader expects this strange address. It is hardcoded
into chip and can't be changed :(

> We don't know your code, nor your linker script, nor your link
> command.
>
> We don't even know which version of U-Boot you are talking about.
>
> Thus we cannot even guess what you might be doing.

O, sorry.
I branched out from commit # 227b7251554 and tried to stay default as
much as possible. So I am using cpu/arm1176's default  u-boot.lds and
start.S

> 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
> A year spent in artificial intelligence is enough to make one believe
> in God.
>


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

Re: [U-Boot] [ARM] gap between _start and CONFIG_SYS_TEXT_BASE

[Wolfgang Denk]

Dear Sergey Mironov,

In message  you 
wrote:
>
> Compiler: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72)
> 4.3.2   -- I also tried a couple of other versions without difference.

Did these include more recent versions?  GCC 4.3.x is not exactly what
I can recommend for ARM systems...

> Text_base: 0x00100010

Is there a special reason for chosing such an odd address?

Why don't you use 0x0010 ?

> Does anybody knows what is going on? How can I tell the linker to
> eliminate those gap?  Playing with . = ALIGN() in u-boot.lds didn't
> help.

We don't know your code, nor your linker script, nor your link
command.

We don't even know which version of U-Boot you are talking about.

Thus we cannot even guess what you might be doing.

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
A year spent in artificial intelligence is enough to make one believe
in God.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [ARM] gap between _start and CONFIG_SYS_TEXT_BASE

[Sergey Mironov]

Hi List.
I am working on porting U-Boot to arm1176-based SoC. It works in
general, but I had to cut off relocation because of a problem
described below. In short: Looks like u-boot fails to link correctly
with some CONFIG_SYS_TEXT_BASE values.

Board name: uemd
Compiler: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72)
4.3.2   -- I also tried a couple of other versions without difference.
Text_base: 0x00100010

I've checked that compiler really uses -Ttext 0x00100010 option while
building. But when I use nm to view actual address, I see:

u-boot-uemd % nm u-boot | grep -w _start
00100020 T _start

So there is 16-byte gap between TEXT_BASE and actual start of code.
Another way to see it is

u-boot-uemd % hexdump -Cv u-boot.bin | head -n 4
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0010  1a 00 00 ea 14 f0 9f e5  14 f0 9f e5 14 f0 9f e5  ||
0020  14 f0 9f e5 14 f0 9f e5  14 f0 9f e5 14 f0 9f e5  ||
0030  00 02 10 00 60 02 10 00  c0 02 10 00 20 03 10 00  |`... ...|

This binary will blow up either while relocating code or while first
call to malloc (probably due to invalid bss).

Does anybody knows what is going on? How can I tell the linker to
eliminate those gap?  Playing with . = ALIGN() in u-boot.lds didn't
help.

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

Re: [U-Boot] git merge summary

[Detlev Zundel]

Hi Wolfgang,

> Dear Detlev Zundel,
>
> In message  you wrote:
>> 
>> > may I ask again for opinions about enabling that feature?
>> 
>> I also would like to see it.  Wolfgang, is there anything that you
>> don't like about this option?
>
> There is two things that make me hesitate:
>
> 1) I wonder if it might have negative side effects. If it was
>generally considered a good thing I would expect that it was set
>as default, but it ain't.

Personally I cannot think of negative side effects.  Checking recent
linux commits, it seems Linus is using this himself[1] which would be a
pro argument I guess.

> 2) I don't know what exactly needs to be done.  My understandaning is
>that I can either switch this on globally for all repositories I'm
>working with (which I do not like), or it needs to be set manually
>in each and every clone of the U-Boot repo where a merge might be
>done.

As far as I can see, we should turn it on per repo so that (future)
custodians would get the setting through cloning.  Apart from that I
even don't see anything against turning it on globally.

>When I throw away a repo for some reason and start with a new clone,
>I can be pretty sure that I will forget to re-enable this.

Then we should enable it in "the master" repo from which you clone.

>What needs to be done about custodian repos etc.?

As far as I understand it, we cannot change anything in already cloned
repositories, so every custodian would need to do this configuration.
On the other hand we can add this setting (yes, I volunteer) on our git
server for all repos, so future clones will get it.

> In other words, it sounds like a thing that causes effort and can go
> wrong nevertheless.

It will cause effort, yes, alas I don't see what can go wrong. It will
be a policy that we can never enforce for individual users, so there
remains a chance that individuals will do merges without the setting.

On the other hand, I guess what really counts is whether _you_ (doing
all practically relevant merges) use it or not.  So essentially it is a
question of whether you can add that in all of your repos.

> So I'd rather wait until either this option is used as defualt by some
> new version of git, or at least until there is a broader request and
> consensus among the custodians.

In this thread you previously wrote:

> If there is an agreement (or at least no protests) we can add
> 'merge.log'.
> 
> Shall we?

Have you become more pessimistic?

Cheers
  Detlev

[1] 
http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=8cad7f06e3b1d3f9a28bb7385e8fc09d5e1bf84c
-- 
#!/usr/bin/perl
$c="print\"\#\!\/usr\/bin\/perl\
\\\$c\=\\\"\"\.quotemeta\(\$c\)\.\"\\\"\;\\n\$c;\"";
print"#!/usr/bin/perl\n\$c=\"".quotemeta($c)."\";\n$c;";
--
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

Re: [U-Boot] Porting Questions - was: [PATCH v2] microblaze: Disabling interrupt should return 1 if was enabled

[Wolfgang Denk]

Dear =?GBK?B?09q74Q==?=,

Please do not hijack existing mail threads!! 

Start a new thread, and make sure to chose a proper subject.

Please make sure to use a line length of 70 characters or so.

And never post HTML to that list.

In message <7eb125f4.fad0.12d0964185c.coremail.henrybe...@163.com> you wrote:
>
>  
> 1). First, I am useing JTAG to download image to SDRAM, base address 
> 0x4000, (32M) so I confused with
>  "CONFIG_SYS_TEXT_BASE", I think this this the relocate address, I am 
> right? Could you please help
>  me choose a address for me can working. (I choose 0x41F0, at last 
> crash on relocate: copy_loop)

No, CONFIG_SYS_TEXT_BASE is NOT the relocation address. The relocation
address gets dynamically computed and may vary.  CONFIG_SYS_TEXT_BASE
is the base address of the text segment when linking the U-Boot
image.

> 2). Second, CONFIG_SYS_INIT_SP_ADDR address is also obscure, I choose 
> 0x4200, at last crash on relocate: copy_loop)

As the name attempts to suggest, CONFIG_SYS_INIT_SP_ADDR defines the
address of the initial steck pointer in the restricted C runtime
environment before relocation.

> 3). What other thing I should do?

Read the documentation and especially existing code for other, similar
boards.

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
Microsoft Multitasking:
 several applications can crash at the same time.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Ethernet HW loopack test

[Wolfgang Denk]

Dear Guy Morand,

please restrict your line length to approx 70 characters or so.

In message  
you wrote:
>
> I'm trying to write an U-Boot command to ping the other interface on my pla
> tform. This is to test the hardware at production, the ping must hit the wi
> re. I got deeply inspired from this patch:
> http://lists.denx.de/pipermail/u-boot/2005-March/009317.html

I hope you also ready my comments.  These still apply.

> What changes is that I really want to ping the other interface with a cross
>  cable and not using a special "home made" device ... The problem is when I
>  send the ping, it is the same interface that answers (the one that sent th
> e ping), this is not what I want. I thought by changing the destination MAC
>  address in the packet and initializing it, the other interface should answ
> er by itself. Actually this is not the case...
...
> I checked with Wireshark, the packet is correctly build. Maybe my approach
> is flawed ! Or maybe do you have another way to perform that kind of test ?

You a run into a number of very basic limitations here.

First, U-Boot has, so far, no clean device model yet. In your case
this means that we can enable only one Ethenret interface at a time.
When you enable one interface (to send a packet), all other
interfaces are shut down and disabled, so they will never be able to
see the packet, even if it arrives as intended.  We have been
discussing improvments in this area in the past, but nothing got
implemented or even designed yet.

Second, U-Boot is strictly single-tasking. Even if we had a better
driver interface so we were able to "open" two network interfaces
simultaneously, we have no infrastructure in place to run independend
"send" and "receive" tasks.

If local loopback tests are not sufficient, you will probably find it
easiest to perform such testing using an external test machine with
two network interfaces.

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 hard to think of you as the end result of millions of  years  of
evolution.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] microblaze: Disabling interrupt should return 1 if was enabled

[于会]

Dear Wolfgang Denk,
 
I'm Abraham Yu, here is my first time write to you, I feel so happy to join 
the U-Boot team.
 
I was porting arm926ejs SoC to our new SoC call "AVT2210", OK! Here is some 
basically questions below:
(u-boot.1010.12.rc2 is what I am using.)
 
1). First, I am useing JTAG to download image to SDRAM, base address 
0x4000, (32M) so I confused with
 "CONFIG_SYS_TEXT_BASE", I think this this the relocate address, I am 
right? Could you please help
 me choose a address for me can working. (I choose 0x41F0, at last 
crash on relocate: copy_loop)
 
2). Second, CONFIG_SYS_INIT_SP_ADDR address is also obscure, I choose 
0x4200, at last crash on relocate: copy_loop)
 
3). What other thing I should do?
 
Thanks very much, God bless you.
 
Abraham___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] v2009.08-rc3 is out

[Wolfgang Denk]

Dear Jens Scharsig,

In message <4d10bb60.9020...@scharsoft.de> you wrote:
>
> I have tested the EB+CPUx9K2 Board. It can be compiled with gcc 4.2.2 (ELDK) 
> and gcc 4.5.1 (buildroot 2010.11).

Thanks for testing.

> But it runs only , if I use the newer 4.5.1 toolchain. I think, there are
> toolchain issues with relocation

Can you please try and investigate the issue?

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
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Ethernet HW loopack test

[Guy Morand]

Hello,

I'm trying to write an U-Boot command to ping the other interface on my 
platform. This is to test the hardware at production, the ping must hit the 
wire. I got deeply inspired from this patch:
http://lists.denx.de/pipermail/u-boot/2005-March/009317.html

What changes is that I really want to ping the other interface with a cross 
cable and not using a special "home made" device ... The problem is when I send 
the ping, it is the same interface that answers (the one that sent the ping), 
this is not what I want. I thought by changing the destination MAC address in 
the packet and initializing it, the other interface should answer by itself. 
Actually this is not the case...

I know a lot of improvement can be done but at the moment I just trying to make 
it work, this is why I let a lot of "debug" code and messages...
-- Here is some code I wrote in net/net.c --
void
NetReceive(volatile uchar * inpkt, int len)
{
 ...
 switch (x) {
 case PROT_ARP:
  ...
 case PROT_TEST:
  answerToEthloopTest(pkt, et->et_dest, et->et_src, len);
  break;
 ...
}
/* Prepare and send packet ... */
int EthLoopSend(void)
{
 int i;
 uchar *pkt;
 struct eth_device* thisEth = eth_get_dev_by_index(eth_get_dev_index());
 struct eth_device* other = thisEth->next;
 bd_t *bd = gd->bd;

 /* Choose the destination interface */
 if(other->init(other, bd)){
  printf("Couldn't initialize other interface, cannot perform test 
!\n");
  return -1;
 }

 printf("Using %s as destination device\n", other->name);
 for (i=12 ; ienetaddr, PROT_TEST);

 (void) eth_send(EtherPacket, ETHLOOP_LEN);

 return 1; /* waiting */
}

/* When no answer arrives ... */
static void EthLoopTimeout (void)
{
 eth_halt();
 NetState = NETLOOP_FAIL;  /* we did not get the reply */
}

/* The other interface answers here */
static void answerToEthloopTest(uchar *pkt, unsigned dest, unsigned src, 
unsigned len){
 int i;
 uchar tmp;
 pkt = (uchar *)EtherPacket;

 printf("Device %s answers ...\n", eth_get_name());  === Why is it 
ETSEC 0 ??!

 // Reverse src dest MAC
 for(i = 1 ; i < 6 ; i++){
  tmp = EtherPacket[i];
  EtherPacket[i] = EtherPacket[i + 6];
  EtherPacket[i + 6] = tmp;
 }

 (void)eth_send(EtherPacket, ETHLOOP_LEN);
 eth_get_dev()->halt(eth_get_dev());
}

/* When the source interface got an answer */
static void EthLoopHandler (uchar * pkt, unsigned dest, unsigned src, unsigned 
len)
{
 int i = 12;
 pkt = (uchar *)EtherPacket;

 for(i ; i < len ; i++){
  printf("Comparing %i with %i at index %i", pkt[i], i, i);
  if(pkt[i] != i){
NetState = NETLOOP_FAIL;
break;
  }
 }
}

/* Initialize the loop test */
static void EthLoopStart(void)
{
 printf ("Using %s as source device\n", eth_get_name());
 NetSetTimeout (2000, EthLoopTimeout);
 NetSetHandler (EthLoopHandler);
 EthLoopSend();
}
-- Here is the output 
--
IPSniffer=> ethloop
Speed: 10, half duplex
Using eTSEC0 as source device
Speed: 10, half duplex
Using eTSEC1 as destination device
Device eTSEC0 answers ...  > NO I WANT ETSEC1 
loopback test failed

I checked with Wireshark, the packet is correctly build. Maybe my approach is 
flawed ! Or maybe do you have another way to perform that kind of test ?

Thanks !

Guy Morand

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

Re: [U-Boot] git merge summary

[Wolfgang Denk]

Dear Detlev Zundel,

In message  you wrote:
> 
> > may I ask again for opinions about enabling that feature?
> 
> I also would like to see it.  Wolfgang, is there anything that you
> don't like about this option?

There is two things that make me hesitate:

1) I wonder if it might have negative side effects. If it was
   generally considered a good thing I would expect that it was set
   as default, but it ain't.

2) I don't know what exactly needs to be done.  My understandaning is
   that I can either switch this on globally for all repositories I'm
   working with (which I do not like), or it needs to be set manually
   in each and every clone of the U-Boot repo where a merge might be
   done.

   When I throw away a repo for some reason and start with a new clone,
   I can be pretty sure that I will forget to re-enable this.

   What needs to be done about custodian repos etc.?

In other words, it sounds like a thing that causes effort and can go
wrong nevertheless.

So I'd rather wait until either this option is used as defualt by some
new version of git, or at least until there is a broader request and
consensus among the custodians.

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
"Marriage is like a cage; one sees the birds outside desperate to get
in, and those inside desperate to get out."   - Montaigne
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] v2009.08-rc3 is out

[Jens Scharsig]

Am 22.08.2009 23:41, schrieb Wolfgang Denk:
> Hi everybody...
> 
> v2009.08-rc3 has just been released.
> 
> Please help testing, and submit  fixes  to  the  remaining  problems.
> 
Hello,

I have tested the EB+CPUx9K2 Board. It can be compiled with gcc 4.2.2 (ELDK) 
and gcc 4.5.1 (buildroot 2010.11).

But it runs only , if I use the newer 4.5.1 toolchain. I think, there are
toolchain issues with relocation

Regards 

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Albert ARIBAUD]

Le 21/12/2010 14:30, Alexander Holler a écrit :
> Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
>> Le 21/12/2010 13:35, Alexander Holler a écrit :
>>
>>> Hmm, is there actual somethinbg which should forbid the compiler to
>>> generate such code which rereads something? It might not be nice, but I
>>> don't think that it is forbidden for a compiler to do so. So the proper
>>> way to handle such, might be to use asm to avoid that the compiler
>>> touches that register.
>>
>> Yes there is something that should prevent a compiler from inserting
>> reads: these accesses are to hardware, not memory, and may cause side
>> effects even on read (these could be acknowledges, for instance; I've
>> seen instances of that myself on some HW).
>>
>> Another way to look at it is that the semantics of " *ptr = value " is a
>> pure write and should not result in a write-then-read.
>
> I think it's something like atomic_read. E.g. when reading an 32bit int
> (uint32_t i = *bla;), nothing forbids that the compiler generates code
> which reads those 4 bytes byte by byte (and so becoming a non-atomic
> operation). It's unusual to do so on 32bit architectures but valid.

OTOH, this still respects the semantics (the compiler is allowed to do a 
non-atomic read) while the bug we're seeing does not repect the 
semantics (the compiler is not asked to do any read but does one).

> Regards,
>
> Alexander

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

Re: [U-Boot] Debugging uBoot with JTAG/Trace32 ?

[Detlev Zundel]

Hi Vijay,

>  I am bit new to this field and my query here is understandably a
> bit vague. I am particularly interested in how any of you, who have had
> experience with uBoot and a JTAG debugger (like a Lauterbach), have gone
> about tackling and resolving an issue within uBoot.
>
> Specifically, I would really appreciate if you could describe the
> *problem*encountered within uBoot, and how did the JTAG/Trace32
> debugging help you
> resolve the issue.

Having a BDI at my disposal, I tackle most of U-Boot related problems
with it.  But of course a JTAG debugger is indispensible when doing a
fresh board port for a "traditionally booting"[1] system.  Usually for
such a cycle the JTAG NOR flash capability is used to program the
development U-Boot and debug it.  This continues until U-Boot is able to
flash itself.  From then on it depends on personal taste whether to use
it to debug easier (e.g. driver) problems.

Cheers
  Detlev

[1] Out of reset the CPU starts executing instructions from NOR flash

-- 
Die Mengenlehre in der Schule ist daran gescheitert, dass man sie mit ihrem
Vokabular verwechselt hat.
 -- Norbert Treitz
--
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

Re: [U-Boot] git merge summary

[Detlev Zundel]

Hi Alexander,

> may I ask again for opinions about enabling that feature?

I also would like to see it.  Wolfgang, is there anything that you
don't like about this option?

Cheers
  Detlev

-- 
5.7: Practically speaking, what is the difference between arrays and pointers?
About the difference between alcohol and marijuana; they have different
characteristics, and that's not a problem if you don't mix them too carelessly.
   - Infrequently Asked Questions in comp.lang.c
--
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

Re: [U-Boot] [PATCH 2/2] microblaze: Fix bdiinfo pointer

[Michal Simek]

Wolfgang Denk wrote:
> Dear Michal Simek,
> 
> In message <4d10a473.2030...@monstr.eu> you wrote:
>> I would like to do it but it is not easy to use sizeof because there are 
>> some dependencies in macros in common.h(lines 193-201) because I am 
>> using CONFIG_SYS_GBL_DATA_OFFSET for monitor/malloc areas.
>>
>> The best will be to be able to generate this value in lib/asm-offsets.c
>>
>> Not sure if you are ok with it.
> 
> Yes, this is OK.
> 
>> diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
>> index 2209561..36fc198 100644
>> --- a/lib/asm-offsets.c
>> +++ b/lib/asm-offsets.c
>> @@ -24,6 +24,8 @@ int main(void)
>>  /* Round up to make sure size gives nice stack alignment */
>>  DEFINE(GENERATED_GBL_DATA_SIZE,
>>  (sizeof(struct global_data)+15) & ~15);
>> +   DEFINE(GENERATED_BD_INFO_SIZE,
>> +   (sizeof(struct bd_info)+15) & ~15);
>>
>>  return 0;
>>   }
> 
> This patch is white-space corrupted, though.

It wasn't intended as a patch just show if this approach will be acceptable.

I will generate patches based on this.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] microblaze: Disabling interrupt should return 1 if was enabled

[Wolfgang Denk]

Dear Michal Simek,

In message <1292936565-24677-1-git-send-email-mon...@monstr.eu> you wrote:
> Microblaze implement enable/disable interrupts through MSR
> that's why disable_interrupts function should return 1 when interrupt
> was enabled. Return 0 when interrupt was disabled.
> 
> Signed-off-by: John Linn 
> Signed-off-by: Michal Simek 
> ---
>  arch/microblaze/cpu/interrupts.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)

Acked-by: Wolfgang Denk 

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
"Have you lived in this village all your life?""No, not yet."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] microblaze: Fix bdiinfo pointer

[Wolfgang Denk]

Dear Michal Simek,

In message <4d10a473.2030...@monstr.eu> you wrote:
>
> I would like to do it but it is not easy to use sizeof because there are 
> some dependencies in macros in common.h(lines 193-201) because I am 
> using CONFIG_SYS_GBL_DATA_OFFSET for monitor/malloc areas.
> 
> The best will be to be able to generate this value in lib/asm-offsets.c
> 
> Not sure if you are ok with it.

Yes, this is OK.

> diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
> index 2209561..36fc198 100644
> --- a/lib/asm-offsets.c
> +++ b/lib/asm-offsets.c
> @@ -24,6 +24,8 @@ int main(void)
>  /* Round up to make sure size gives nice stack alignment */
>  DEFINE(GENERATED_GBL_DATA_SIZE,
>  (sizeof(struct global_data)+15) & ~15);
> +   DEFINE(GENERATED_BD_INFO_SIZE,
> +   (sizeof(struct bd_info)+15) & ~15);
> 
>  return 0;
>   }

This patch is white-space corrupted, though.

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
Life. Don't talk to me about life.  - Marvin the Paranoid Android
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler]

Hello,

Am 21.12.2010 01:25, schrieb John Rigby:
> On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler  
> wrote:
>
>> There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
...
> Yes, you are correct, I see the same here with 4.5.2.  I noticed that
> bd did not have correct values of machine type and boot params:
>
> bd address  = 0x8FF24FE0
...

Great!

Thanks a lot for searching and finding that.

I've just tested an u-boot for the BeagleBoard with your "Move 
DECLARE..."-patch compiled with gcc 4.5.1 and it now boots. ;)

I remember having seen those two DECLARE_GLOBAL_DATA_PTR in beagle.c 
too, but I was to lazy at that time to check if that has (bad) 
consequences. ;)

Regards,

Alexander


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

Re: [U-Boot] [PATCH v2 1/9] mpc8xxx: Display RDIMM if detected

[Sergei Shtylyov]

Hello.

On 19-12-2010 1:21, Wolfgang Denk wrote:

>> Print a message when a RDIMM is detected.
> ...
>> +} else
>>  printf("ERROR:  Mix of registered buffered and unbuffered "
>>  "DIMMs detected!\n");
>> -}

> Mutli-line statement needs braces.

Well, not only that. CodingStyle requires that if some parts of the *if* 
statement used {}, then all parts need to use {}.

> Best regards,

> Wolfgang Denk

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

Re: [U-Boot] [PATCH v2] microblaze: Disabling interrupt should return 1 if was enabled

[Sergei Shtylyov]

Hello.

On 21-12-2010 16:02, Michal Simek wrote:

> Microblaze implement enable/disable interrupts through MSR
> that's why disable_interrupts function should return 1 when interrupt
> was enabled. Return 0 when interrupt was disabled.

> Signed-off-by: John Linn
> Signed-off-by: Michal Simek
[...]

> diff --git a/arch/microblaze/cpu/interrupts.c 
> b/arch/microblaze/cpu/interrupts.c
> index e9d53c1..054e09f 100644
> --- a/arch/microblaze/cpu/interrupts.c
> +++ b/arch/microblaze/cpu/interrupts.c
> @@ -41,8 +41,10 @@ void enable_interrupts (void)
>
>   int disable_interrupts (void)
>   {
> + unsigned int msr;

Empty line wouldn't hurt here...

> + MFS(msr, rmsr);
>   MSRCLR(0x2);
> - return 0;
> + return ((msr & 0x2) != 0);

External pair of () not needed.

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler]

Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
> Le 21/12/2010 13:35, Alexander Holler a écrit :
>
>> Hmm, is there actual somethinbg which should forbid the compiler to
>> generate such code which rereads something? It might not be nice, but I
>> don't think that it is forbidden for a compiler to do so. So the proper
>> way to handle such, might be to use asm to avoid that the compiler
>> touches that register.
>
> Yes there is something that should prevent a compiler from inserting
> reads: these accesses are to hardware, not memory, and may cause side
> effects even on read (these could be acknowledges, for instance; I've
> seen instances of that myself on some HW).
>
> Another way to look at it is that the semantics of " *ptr = value " is a
> pure write and should not result in a write-then-read.

I think it's something like atomic_read. E.g. when reading an 32bit int 
(uint32_t i = *bla;), nothing forbids that the compiler generates code 
which reads those 4 bytes byte by byte (and so becoming a non-atomic 
operation). It's unusual to do so on 32bit architectures but valid.

Regards,

Alexander


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

[U-Boot] your mom called me

[Francesca Hardman]

Be more than you can be as an at-home worker , I found something thats 
reces$ion proof, make up to one thousand a day with this article news site i 
found:  http://bit.ly/hq5aMX";>View this article heree
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] microblaze: Disabling interrupt should return 1 if was enabled

[Michal Simek]

Microblaze implement enable/disable interrupts through MSR
that's why disable_interrupts function should return 1 when interrupt
was enabled. Return 0 when interrupt was disabled.

Signed-off-by: John Linn 
Signed-off-by: Michal Simek 
---
 arch/microblaze/cpu/interrupts.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/cpu/interrupts.c b/arch/microblaze/cpu/interrupts.c
index e9d53c1..054e09f 100644
--- a/arch/microblaze/cpu/interrupts.c
+++ b/arch/microblaze/cpu/interrupts.c
@@ -41,8 +41,10 @@ void enable_interrupts (void)
 
 int disable_interrupts (void)
 {
+   unsigned int msr;
+   MFS(msr, rmsr);
MSRCLR(0x2);
-   return 0;
+   return ((msr & 0x2) != 0);
 }
 
 #ifdef CONFIG_SYS_INTC_0
-- 
1.5.5.6

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

Re: [U-Boot] [PATCH 2/2] microblaze: Fix bdiinfo pointer

[Michal Simek]

Wolfgang Denk wrote:
> Dear Michal Simek,
> 
> In message <1292933384-3032-3-git-send-email-mon...@monstr.eu> you wrote:
>> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
>> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
>> introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
>> (currently 0x40).
>> Microblaze configs used 0x40(128) because this place also contained
>> board info structure which lies on the top of ram.
>>
>> This patch is fixing this scheme by extending CONFIG_SYS_GBL_DATA_OFFSET
>> value. Doubled GENERATED_GBL_DATA_SIZE size is enough to store
>> gd_t and bd_t structures.
> 
> No, I will not accept this.
> 
> Please do not make assumptions abouth the size of bd_t compared to
> GENERATED_GBL_DATA_SIZE.  Use the correct size instead, as you can
> easily get using the sizeof() operator (plus some padding eventually
> to guarantee alignment, if needed).

I would like to do it but it is not easy to use sizeof because there are 
some dependencies in macros in common.h(lines 193-201) because I am 
using CONFIG_SYS_GBL_DATA_OFFSET for monitor/malloc areas.

The best will be to be able to generate this value in lib/asm-offsets.c

Not sure if you are ok with it.

diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
index 2209561..36fc198 100644
--- a/lib/asm-offsets.c
+++ b/lib/asm-offsets.c
@@ -24,6 +24,8 @@ int main(void)
 /* Round up to make sure size gives nice stack alignment */
 DEFINE(GENERATED_GBL_DATA_SIZE,
 (sizeof(struct global_data)+15) & ~15);
+   DEFINE(GENERATED_BD_INFO_SIZE,
+   (sizeof(struct bd_info)+15) & ~15);

 return 0;
  }


Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Albert ARIBAUD]

Le 21/12/2010 13:35, Alexander Holler a écrit :

> Hmm, is there actual somethinbg which should forbid the compiler to
> generate such code which rereads something? It might not be nice, but I
> don't think that it is forbidden for a compiler to do so. So the proper
> way to handle such, might be to use asm to avoid that the compiler
> touches that register.

Yes there is something that should prevent a compiler from inserting 
reads: these accesses are to hardware, not memory, and may cause side 
effects even on read (these could be acknowledges, for instance; I've 
seen instances of that myself on some HW).

Another way to look at it is that the semantics of " *ptr = value " is a 
pure write and should not result in a write-then-read.

> Regards,
>
> Alexander

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler]

Am 21.12.2010 11:53, schrieb Wolfgang Denk:
> Dear Albert ARIBAUD,
>
> In message<4d1083b4.2060...@free.fr>  you wrote:
>>
>>> And I at your suggestion tried modifying the binary changing the extra
>>> ldrb to a nop and it works.
>>
>> Seems like a compiler issue to me, as the preprocessed C source is the
>> same for the register access and does not call for a re-read (that is
>> what I wanted to see in the preprocessed version), yet the ASM sequence
>> does the re-read.
>
> I also tend to think this is a compiler problem.  Searching the gcc
> bugzilla entries for "ldrb" turns up quite a number of hits.  I'm not
> sure which of these we are running into here, but there are enough of
> them so you can chose freely :-(

Hmm, is there actual somethinbg which should forbid the compiler to 
generate such code which rereads something? It might not be nice, but I 
don't think that it is forbidden for a compiler to do so. So the proper 
way to handle such, might be to use asm to avoid that the compiler 
touches that register.

Regards,

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

Re: [U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[Michal Simek]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Michal,
> 
> In message <4d106994.10...@monstr.eu> you wrote:
>> Maybe will be worth to take a look at monitor,malloc area and stack.
>>
>> Microblaze uses:
>> end of ram
>> bd 0x40
>> gd 0x40
>> monitor area
>> malloc area
>> stack (grows down)
>>
>> Is it OK to use this scheme?
> 
> Sure. You can basicly define this as you like; the general idea is
> described in the README; normally we will reserve (dynamically, i. e.
> as needed) space for PRAM, shared log buffer and/or video frame
> buffer at the upper end of memory, so I would locate bd and gd and
> the rest below that - but you don;t support these features so far for
> microblaze, then above is fine.

I hope that we will support some of these feature in near future.

> 
> I just would use sizeof() instead of fixed sizes (which tend to be
> wrong sometimes ;-)

of course. There are some references to asm which needs to be resolve at 
first.

> 
>> I can easily fix this to previous state but will be good to synchronize 
>> this across archs.
> 
> If you are looking for a reference, use arch/powerpc/lib/board.c,
> starting here:
> 
>  394 /*
>  395  * Now that we have DRAM mapped and working, we can
>  396  * relocate the code and continue running from DRAM.
>  397  *
>  398  * Reserve memory at end of RAM for (top down in that order):
>  399  *  - area that won't get touched by U-Boot and Linux (optional)
>  400  *  - kernel log buffer
>  401  *  - protected RAM
>  402  *  - LCD framebuffer
>  403  *  - monitor code
>  404  *  - board info struct
>  405  */
> 

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] microblaze: Fix bdiinfo pointer

[Wolfgang Denk]

Dear Michal Simek,

In message <1292933384-3032-3-git-send-email-mon...@monstr.eu> you wrote:
> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
> introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
> (currently 0x40).
> Microblaze configs used 0x40(128) because this place also contained
> board info structure which lies on the top of ram.
> 
> This patch is fixing this scheme by extending CONFIG_SYS_GBL_DATA_OFFSET
> value. Doubled GENERATED_GBL_DATA_SIZE size is enough to store
> gd_t and bd_t structures.

No, I will not accept this.

Please do not make assumptions abouth the size of bd_t compared to
GENERATED_GBL_DATA_SIZE.  Use the correct size instead, as you can
easily get using the sizeof() operator (plus some padding eventually
to guarantee alignment, if needed).

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've got to get something inside me. Some coffee  or  something.  And
then the world will somehow be better.
 - Terry Pratchett, _Men at Arms_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] microblaze: Disabling interrupt should return 1 if implemented

[Wolfgang Denk]

Dear Michal Simek,

In message <1292933384-3032-2-git-send-email-mon...@monstr.eu> you wrote:
> Microblaze implement enable/disable interrupts through MSR
> that's why disable_interrupts function should return 1.
> 
> Signed-off-by: John Linn 
> Signed-off-by: Michal Simek 
> ---
>  arch/microblaze/cpu/interrupts.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/microblaze/cpu/interrupts.c 
> b/arch/microblaze/cpu/interrupts.c
> index e9d53c1..331746c 100644
> --- a/arch/microblaze/cpu/interrupts.c
> +++ b/arch/microblaze/cpu/interrupts.c
> @@ -42,7 +42,7 @@ void enable_interrupts (void)
>  int disable_interrupts (void)
>  {
>   MSRCLR(0x2);
> - return 0;
> + return 1;
>  }

I think this is wrong.  disable_interrupts() should return 1 only if
interrupts were enabled before, so code like this can make sure that
some parts are run with interrupts disabled, but then restore the
previous state, no matter if this had interrupts on or off:

int flag = disable_interrupts();
...
do something
...
if (flag)
enable_interrupts();

With your code, we would ALWAYS enable interrupts, even if these were
off before.

For reference, see for example arch/powerpc/lib/interrupts.c

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
Quote from the Boss... "I didn't say it was your fault.  I said I was
going to blame it on you."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Microblaze fixes

[Michal Simek]

Hi Wolfgang,

I am sending two patches for review. I don't expect that someone will
have any compains about that's why I have create fix branch in my custodian repo
and you can pull them. 

Both patches are fixes and if possible, I would like to add them 
to your branch. I have looked at schedule and if you don't want to merge
it, I will ask for merging in upcomming merge window.

Thanks,
Michal


The following changes since commit 71aab09b2c1edd1b6e00819abd1e31c04db04f36:
  Wolfgang Denk (1):
Merge branch 'master' of /home/wd/git/u-boot/custodians

are available in the git repository at:

  git://www.denx.de/git/u-boot-microblaze.git fix

Michal Simek (2):
  microblaze: Disabling interrupt should return 1 if implemented
  microblaze: Fix bdiinfo pointer

 arch/microblaze/cpu/interrupts.c |2 +-
 arch/microblaze/lib/board.c  |2 +-
 include/configs/microblaze-generic.h |7 +--
 3 files changed, 7 insertions(+), 4 deletions(-)



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

[U-Boot] [PATCH 2/2] microblaze: Fix bdiinfo pointer

[Michal Simek]

Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
(sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
(currently 0x40).
Microblaze configs used 0x40(128) because this place also contained
board info structure which lies on the top of ram.

This patch is fixing this scheme by extending CONFIG_SYS_GBL_DATA_OFFSET
value. Doubled GENERATED_GBL_DATA_SIZE size is enough to store
gd_t and bd_t structures.

U-Boot is placed to the top of the ram (for example 0xd7ff)
and bd structure was moved out of ram.

For example:
Current: gd 0xd7c0, bd 0xd800
Fixed:   gd 0xd780, bd 0xd7c0

Signed-off-by: Michal Simek 
---
 arch/microblaze/lib/board.c  |2 +-
 include/configs/microblaze-generic.h |7 +--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/microblaze/lib/board.c b/arch/microblaze/lib/board.c
index eeef579..e215684 100644
--- a/arch/microblaze/lib/board.c
+++ b/arch/microblaze/lib/board.c
@@ -96,7 +96,7 @@ void board_init (void)
ulong flash_size = 0;
 #endif
asm ("nop");/* FIXME gd is not initialize - wait */
-   memset ((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
+   memset ((void *)gd, 0, 2 * GENERATED_GBL_DATA_SIZE); /* gd/bd space */
gd->bd = (bd_t *) (gd + 1); /* At end of global data */
gd->baudrate = CONFIG_BAUDRATE;
bd = gd->bd;
diff --git a/include/configs/microblaze-generic.h 
b/include/configs/microblaze-generic.h
index 75e4e07..ec152bf 100644
--- a/include/configs/microblaze-generic.h
+++ b/include/configs/microblaze-generic.h
@@ -135,14 +135,17 @@
 #defineCONFIG_SYS_MEMTEST_END  (CONFIG_SYS_SDRAM_BASE + 0x1000)
 
 /* global pointer */
+/* Allocate 2 * GENERATED_GBL_DATA_SIZE (0x40) size for global data and
+ * board info structure(size 0x24). Would be better to use sizeof but
+ * this requires more changes to asm code */
 /* start of global data */
 #defineCONFIG_SYS_GBL_DATA_OFFSET \
(CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_SDRAM_SIZE \
-   - GENERATED_GBL_DATA_SIZE)
+   - 2 * GENERATED_GBL_DATA_SIZE)
 
 /* monitor code */
 #defineSIZE0x4
-#defineCONFIG_SYS_MONITOR_LEN  (SIZE - GENERATED_GBL_DATA_SIZE)
+#defineCONFIG_SYS_MONITOR_LEN  SIZE
 #defineCONFIG_SYS_MONITOR_BASE \
(CONFIG_SYS_GBL_DATA_OFFSET - CONFIG_SYS_MONITOR_LEN)
 #defineCONFIG_SYS_MONITOR_END \
-- 
1.5.5.6

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

[U-Boot] [PATCH 1/2] microblaze: Disabling interrupt should return 1 if implemented

[Michal Simek]

Microblaze implement enable/disable interrupts through MSR
that's why disable_interrupts function should return 1.

Signed-off-by: John Linn 
Signed-off-by: Michal Simek 
---
 arch/microblaze/cpu/interrupts.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/cpu/interrupts.c b/arch/microblaze/cpu/interrupts.c
index e9d53c1..331746c 100644
--- a/arch/microblaze/cpu/interrupts.c
+++ b/arch/microblaze/cpu/interrupts.c
@@ -42,7 +42,7 @@ void enable_interrupts (void)
 int disable_interrupts (void)
 {
MSRCLR(0x2);
-   return 0;
+   return 1;
 }
 
 #ifdef CONFIG_SYS_INTC_0
-- 
1.5.5.6

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4d1083b4.2060...@free.fr> you wrote:
>
> > And I at your suggestion tried modifying the binary changing the extra
> > ldrb to a nop and it works.
>
> Seems like a compiler issue to me, as the preprocessed C source is the
> same for the register access and does not call for a re-read (that is
> what I wanted to see in the preprocessed version), yet the ASM sequence
> does the re-read.

I also tend to think this is a compiler problem.  Searching the gcc
bugzilla entries for "ldrb" turns up quite a number of hits.  I'm not
sure which of these we are running into here, but there are enough of
them so you can chose freely :-(

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
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[Wolfgang Denk]

Dear Michal,

In message <4d106994.10...@monstr.eu> you wrote:
> 
> Maybe will be worth to take a look at monitor,malloc area and stack.
> 
> Microblaze uses:
> end of ram
> bd 0x40
> gd 0x40
> monitor area
> malloc area
> stack (grows down)
> 
> Is it OK to use this scheme?

Sure. You can basicly define this as you like; the general idea is
described in the README; normally we will reserve (dynamically, i. e.
as needed) space for PRAM, shared log buffer and/or video frame
buffer at the upper end of memory, so I would locate bd and gd and
the rest below that - but you don;t support these features so far for
microblaze, then above is fine.

I just would use sizeof() instead of fixed sizes (which tend to be
wrong sometimes ;-)

> I can easily fix this to previous state but will be good to synchronize 
> this across archs.

If you are looking for a reference, use arch/powerpc/lib/board.c,
starting here:

 394 /*
 395  * Now that we have DRAM mapped and working, we can
 396  * relocate the code and continue running from DRAM.
 397  *
 398  * Reserve memory at end of RAM for (top down in that order):
 399  *  - area that won't get touched by U-Boot and Linux (optional)
 400  *  - kernel log buffer
 401  *  - protected RAM
 402  *  - LCD framebuffer
 403  *  - monitor code
 404  *  - board info struct
 405  */


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 there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Albert ARIBAUD]

Le 21/12/2010 09:46, John Rigby a écrit :
> On Tue, Dec 21, 2010 at 1:35 AM, Dirk Behme  wrote:
>>
>> (Resend with corrected broken example)
>>
>> On 21.12.2010 08:21, Albert ARIBAUD wrote:
>>> Hi Dirk,
>>>
>>> Le 21/12/2010 08:11, Dirk Behme a écrit :
>>>
 But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
 ldrbr3, [r3]) is still open? Has anybody tried to replace it with
 a nop in the binary to be sure this is the root cause?
>>>
>>> Can you try and preprocess the C file for both the broken and working
>>> cases, then post the preprocessed C extract? Differences at the C level
>>> may help understanding differences at the asm level.
>>
>> gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>>
>> Work:
>> 
>>
>> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>>  uint32_t ctrl)
>> {
>>   register struct nand_chip *this = mtd->priv;
>>   ...
>>   if (cmd != -1)
>>
>>(*(volatile unsigned char *)(this->IO_ADDR_W) = (cmd));
>> }
>>
>> if (cmd != NAND_CMD_NONE)
>>84:  e3710001cmn r1, #1
>> origwriteb(cmd, this->IO_ADDR_W);
>>88:  15933004ldrne   r3, [r3, #4]
>>8c:  120110ffandne   r1, r1, #255; 0xff
>>90:  15c31000strbne  r1, [r3]
>>94:  e12fff1ebx  lr
>> ...
>>
>>
>> Broken:
>> ==
>>
>> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>>  uint32_t ctrl)
>> {
>>   register struct nand_chip *this = mtd->priv;
>>
>> ...
>>
>>   if (cmd != -1)
>>({ __asm__ __volatile__ ("" : : : "memory"); (*(volatile unsigned
>> char *)(this->IO_ADDR_W) = (cmd)); });
>> }
>>
>> if (cmd != NAND_CMD_NONE)
>>84:  e3710001cmn r1, #1
>>88:  012fff1ebxeqlr
>> writeb(cmd, this->IO_ADDR_W);
>>8c:  e5933004ldr r3, [r3, #4]
>>90:  e20110ffand r1, r1, #255; 0xff
>>94:  e5c31000strbr1, [r3]
>>98:  e5d33000ldrbr3, [r3]
>>9c:  e12fff1ebx  lr
>>
>>
>> The issue seems to be the additional 'ldrb  r3, [r3]' added by the
>> compiler in the broken version.
>>
>
> And I at your suggestion tried modifying the binary changing the extra
> ldrb to a nop and it works.

Seems like a compiler issue to me, as the preprocessed C source is the 
same for the register access and does not call for a re-read (that is 
what I wanted to see in the preprocessed version), yet the ASM sequence 
does the re-read.

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

[U-Boot] [PATCH] update VCMA9 port

[David Müller]

This patch brings the VCMA9 port in sync with the latest U-Boot
version by doing the following:
 - do the necessary adjustments to support the ARM relocation feature
 - use the CFI flash driver (and removing the old one)
 - various cleanups and coding style fixes

Signed-off-by: David Mueller 

diff --git a/board/mpl/vcma9/Makefile b/board/mpl/vcma9/Makefile
index 27cef1d..59c25f9 100644
--- a/board/mpl/vcma9/Makefile
+++ b/board/mpl/vcma9/Makefile
@@ -28,7 +28,7 @@ endif
 
 LIB= $(obj)lib$(BOARD).o
 
-COBJS  := vcma9.o flash.o cmd_vcma9.o
+COBJS  := vcma9.o cmd_vcma9.o
 COBJS  += ../common/common_util.o
 
 SOBJS  := lowlevel_init.o
diff --git a/board/mpl/vcma9/cmd_vcma9.c b/board/mpl/vcma9/cmd_vcma9.c
index 0d5f46e..0f02b7e 100644
--- a/board/mpl/vcma9/cmd_vcma9.c
+++ b/board/mpl/vcma9/cmd_vcma9.c
@@ -43,7 +43,7 @@ static uchar cs8900_chksum(ushort data)
 
 DECLARE_GLOBAL_DATA_PTR;
 
-extern void print_vcma9_info(void);
+extern void vcma9_print_info(void);
 extern int vcma9_cantest(int);
 extern int vcma9_nandtest(void);
 extern int vcma9_nanderase(void);
@@ -60,7 +60,7 @@ int do_vcma9(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
char cs8900_name[10];
if (strcmp(argv[1], "info") == 0)
{
-   print_vcma9_info();
+   vcma9_print_info();
return 0;
}
 #if defined(CONFIG_CS8900)
diff --git a/board/mpl/vcma9/config.mk b/board/mpl/vcma9/config.mk
index e345913..fef5308 100644
--- a/board/mpl/vcma9/config.mk
+++ b/board/mpl/vcma9/config.mk
@@ -1,5 +1,5 @@
 #
-# (C) Copyright 2002, 2003
+# (C) Copyright 2002, 2003, 2010
 # David Mueller, ELSOFT AG, 
 #
 # MPL VCMA9 board with S3C2410X (ARM920T) cpu
@@ -7,18 +7,10 @@
 # see http://www.mpl.ch/ for more information about the MPL VCMA9
 #
 
-#
-# MPL VCMA9 has 1 bank of minimal 16 MB DRAM
-# from 0x3000
-#
 # Linux-Kernel is expected to be at 3000'8000, entry 3000'8000
 # optionally with a ramdisk at 3040'
 #
-# we load ourself to 33F8'
+# NOR flash is mapped at address 0
 #
-# download area is 3080'
-#
-
 
-#CONFIG_SYS_TEXT_BASE = 0x30F8
-CONFIG_SYS_TEXT_BASE = 0x33F8
+CONFIG_SYS_TEXT_BASE = 0x0
diff --git a/board/mpl/vcma9/flash.c b/board/mpl/vcma9/flash.c
deleted file mode 100644
index 7abf9cf..000
--- a/board/mpl/vcma9/flash.c
+++ /dev/null
@@ -1,432 +0,0 @@
-/*
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH 
- * Alex Zuepke 
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include 
-
-ulong myflush (void);
-
-
-#define FLASH_BANK_SIZEPHYS_FLASH_SIZE
-#define MAIN_SECT_SIZE  0x1/* 64 KB */
-
-flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
-
-
-#define CMD_READ_ARRAY 0x00F0
-#define CMD_UNLOCK10x00AA
-#define CMD_UNLOCK20x0055
-#define CMD_ERASE_SETUP0x0080
-#define CMD_ERASE_CONFIRM  0x0030
-#define CMD_PROGRAM0x00A0
-#define CMD_UNLOCK_BYPASS  0x0020
-
-#define MEM_FLASH_ADDR1(*(volatile u16 
*)(CONFIG_SYS_FLASH_BASE + (0x0555 << 1)))
-#define MEM_FLASH_ADDR2(*(volatile u16 
*)(CONFIG_SYS_FLASH_BASE + (0x02AA << 1)))
-
-#define BIT_ERASE_DONE 0x0080
-#define BIT_RDY_MASK   0x0080
-#define BIT_PROGRAM_ERROR  0x0020
-#define BIT_TIMEOUT0x8000  /* our flag */
-
-#define READY 1
-#define ERR   2
-#define TMO   4
-
-/*---
- */
-
-ulong flash_init (void)
-{
-   int i, j;
-   ulong size = 0;
-
-   for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; i++) {
-   ulong flashbase = 0;
-
-   flash_info[i].flash_id =
-#if defined(CONFIG_AMD_LV400)
-   (AMD_MANUFACT & FLASH_VENDMASK) |
-   (AMD_ID_LV400B & FLASH_TYPEMASK);
-#elif defined(CONFIG_AMD_LV800)
-   (AMD_MANUFACT & FLASH_VENDMASK) |
-   (AMD_ID_LV800B & FLASH_TYPEMASK);
-#else
-#error "Unknown flash configured"
-#endif
-   flash_info[i].size = FLASH_BANK_SIZE;
-   flash_info[i].sector_count = CONFIG_SYS_MAX_FLASH_SECT

[U-Boot] [PATCH] add AM29F400BB to table of supported legacy flashs

[David Müller]

Signed-off-by: David Mueller 

diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 223fb71..da8c9b1 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -41,6 +41,7 @@
 #define AM29DL800BB0x22CB
 #define AM29DL800BT0x224A
 
+#define AM29F400BB 0x22AB
 #define AM29F800BB 0x2258
 #define AM29F800BT 0x22D6
 #define AM29LV400BB0x22BA
@@ -296,6 +297,23 @@ static const struct amd_flash_info jedec_table[] = {
 #ifdef CONFIG_SYS_FLASH_LEGACY_512Kx16
{
.mfr_id = (u16)AMD_MANUFACT,
+   .dev_id = AM29F400BB,
+   .name   = "AMD AM29F400BB",
+   .uaddr  = {
+   [1] = MTD_UADDR_0x0555_0x02AA /* x16 */
+   },
+   .DevSize= SIZE_512KiB,
+   .CmdSet = CFI_CMDSET_AMD_LEGACY,
+   .NumEraseRegions= 4,
+   .regions= {
+   ERASEINFO(0x04000, 1),
+   ERASEINFO(0x02000, 2),
+   ERASEINFO(0x08000, 1),
+   ERASEINFO(0x1, 7),
+   }
+   },
+   {
+   .mfr_id = (u16)AMD_MANUFACT,
.dev_id = AM29LV400BB,
.name   = "AMD AM29LV400BB",
.uaddr  = {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] ftgmac100: support of gigabit eth ftgmac100

[Macpaul Lin]

Add Faraday's ftgmac100 (gigabit ethernet)
MAC controller's driver.

Signed-off-by: Macpaul Lin 
---
Changes for v2:
   - Coding Style cleanup
   - Makefile Order sorted
   - Volatile statement eliminated
   - Error handling added
   - Autonegotiation timeout value rechecked
   - Link speed detection code is reduced
   - Logic of autonegotiation and Link speed update reorganized
   - Redundent registers offset table cleared
   - The explaination of sub configuration of this
 driver has moved into README

Changes for v3:
   - Coding Style clean up about
- 2 continue blank line
- incorrect multi-line comment style
- useless else statement and return value statement
- make multi-line statement into single line which doesn't exceed 80 chars
- brance with multi-line statement (comments included before one line code)

 README  |   12 +
 drivers/net/Makefile|1 +
 drivers/net/ftgmac100.c |  570 +++
 drivers/net/ftgmac100.h |  255 +
 include/netdev.h|1 +
 5 files changed, 839 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/ftgmac100.c
 create mode 100644 drivers/net/ftgmac100.h

diff --git a/README b/README
index 68f5fb0..d7a23cd 100644
--- a/README
+++ b/README
@@ -861,6 +861,18 @@ The following options need to be configured:
Define this to use i/o functions instead of macros
(some hardware wont work with macros)
 
+   CONFIG_FTGMAC100
+   Support for Faraday's FTGMAC100 Gigabit SoC Ethernet
+
+   CONFIG_FTGMAC100_EGIGA
+   Define this to use GE link update with gigabit PHY.
+   Define this if FTGMAC100 is connected to gigabit PHY.
+   If your system has 10/100 PHY only, it might not occur
+   wrong behavior. Because PHY usually return timeout or
+   useless data when polling gigabit status and gigabit
+   control registers. This behavior won't affect the
+   correctnessof 10/100 link speed update.
+
CONFIG_SMC911X
Support for SMSC's LAN911x and LAN921x chips
 
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index b605eea..fd9d0b4 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_EP93XX) += ep93xx_eth.o
 COBJS-$(CONFIG_ETHOC) += ethoc.o
 COBJS-$(CONFIG_FEC_MXC) += fec_mxc.o
 COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o
+COBJS-$(CONFIG_FTGMAC100) += ftgmac100.o
 COBJS-$(CONFIG_FTMAC100) += ftmac100.o
 COBJS-$(CONFIG_GRETH) += greth.o
 COBJS-$(CONFIG_INCA_IP_SWITCH) += inca-ip_sw.o
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
new file mode 100644
index 000..dc7a80e
--- /dev/null
+++ b/drivers/net/ftgmac100.c
@@ -0,0 +1,570 @@
+/*
+ * Faraday FTGMAC100 Ethernet
+ *
+ * (C) Copyright 2009 Faraday Technology
+ * Po-Yu Chuang 
+ *
+ * (C) Copyright 2010 Andes Technology
+ * Macpaul Lin 
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ftgmac100.h"
+
+#define ETH_ZLEN   60
+
+#define mdelay(n) ({unsigned long msec = (n); while (msec--) udelay(1000); })
+
+/* RBSR - hw default init value is also 0x640 */
+#define RBSR_DEFAULT_VALUE 0x640
+
+/* PKTBUFSTX/PKTBUFSRX must both be power of 2 */
+#define PKTBUFSTX  4   /* must be power of 2 */
+
+struct ftgmac100_data {
+   struct ftgmac100_txdes txdes[PKTBUFSTX];
+   struct ftgmac100_rxdes rxdes[PKTBUFSRX];
+   int tx_index;
+   int rx_index;
+   int phy_addr;
+};
+
+/*
+ * struct mii_bus functions
+ */
+static int ftgmac100_mdiobus_read(struct eth_device *dev, int phy_addr,
+   int regnum)
+{
+   struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+   int phycr;
+   int i;
+
+   phycr = readl(&ftgmac100->phycr);
+
+   /* preserve MDC cycle threshold */
+   phycr &= FTGMAC100_PHYCR_MDC_CYCTHR_MASK;
+
+   phycr |= FTGMAC100_PHYCR_PHYAD(phy_addr)
+ |  FTGMAC100_PHYCR_REGAD(regnum)
+ |  FTGMAC100_PHYCR_MIIRD;
+
+   writel(phycr, &ftgmac100->phycr);
+
+   for 

[U-Boot] microblaze: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value (25ddd1fb0a2281b182529afbc8fda5de2dc16d96)

[Michal Simek]

Hi Wolfgang,

I have just found that your patch (in subject) break gd/bd pointer for 
Microblaze. I have done patch which fix it but not sure if is correct.

Microblaze uses small space at the end of ram for gd and bd.

For example:
end of ram   0xd7ff 
bd   0xd7ff ffc0
gd   0xd7ff ff80

Your patch uses GENERATED_GBL_DATA_SIZE which is aligned size for 
gb_t(0x40) and caused that bd structure (because it is on higher 
addresses) is moved out of ram because gd is on 0xd7ff ffc0. Actual size 
of bd_t is 0x24 but it is no problem to use 0x40 as aligned size.

The main my point is how should look like position of gd/bd.

Maybe will be worth to take a look at monitor,malloc area and stack.

Microblaze uses:
end of ram
bd 0x40
gd 0x40
monitor area
malloc area
stack (grows down)

Is it OK to use this scheme?

I can easily fix this to previous state but will be good to synchronize 
this across archs.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[John Rigby]

On Tue, Dec 21, 2010 at 1:35 AM, Dirk Behme  wrote:
>
> (Resend with corrected broken example)
>
> On 21.12.2010 08:21, Albert ARIBAUD wrote:
>> Hi Dirk,
>>
>> Le 21/12/2010 08:11, Dirk Behme a écrit :
>>
>>> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
>>> ldrb    r3, [r3]) is still open? Has anybody tried to replace it with
>>> a nop in the binary to be sure this is the root cause?
>>
>> Can you try and preprocess the C file for both the broken and working
>> cases, then post the preprocessed C extract? Differences at the C level
>> may help understanding differences at the asm level.
>
> gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>
> Work:
> 
>
> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>     uint32_t ctrl)
> {
>  register struct nand_chip *this = mtd->priv;
>  ...
>  if (cmd != -1)
>
>   (*(volatile unsigned char *)(this->IO_ADDR_W) = (cmd));
> }
>
>        if (cmd != NAND_CMD_NONE)
>   84:  e3710001        cmn     r1, #1
>                origwriteb(cmd, this->IO_ADDR_W);
>   88:  15933004        ldrne   r3, [r3, #4]
>   8c:  120110ff        andne   r1, r1, #255    ; 0xff
>   90:  15c31000        strbne  r1, [r3]
>   94:  e12fff1e        bx      lr
>        ...
>
>
> Broken:
> ==
>
> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>     uint32_t ctrl)
> {
>  register struct nand_chip *this = mtd->priv;
>
> ...
>
>  if (cmd != -1)
>   ({ __asm__ __volatile__ ("" : : : "memory"); (*(volatile unsigned
> char *)(this->IO_ADDR_W) = (cmd)); });
> }
>
>        if (cmd != NAND_CMD_NONE)
>   84:  e3710001        cmn     r1, #1
>   88:  012fff1e        bxeq    lr
>                writeb(cmd, this->IO_ADDR_W);
>   8c:  e5933004        ldr     r3, [r3, #4]
>   90:  e20110ff        and     r1, r1, #255    ; 0xff
>   94:  e5c31000        strb    r1, [r3]
>   98:  e5d33000        ldrb    r3, [r3]
>   9c:  e12fff1e        bx      lr
>
>
> The issue seems to be the additional 'ldrb      r3, [r3]' added by the
> compiler in the broken version.
>

And I at your suggestion tried modifying the binary changing the extra
ldrb to a nop and it works.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] mtd board tx25

[davide doninelli]

Hi,
Someone configured u-boot with mtd support for Karo tx25 board? Config file 
don't configure it.


best regard 
Davide Doninelli


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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Dirk Behme]

On 21.12.2010 09:17, Wolfgang Denk wrote:
> Dear Dirk Behme,
>
> In message<4d105fb3.3090...@googlemail.com>  you wrote:
>>
>> Broken:
>> ==
> ...
>> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>>   uint32_t ctrl)
>> {
>>register struct nand_chip *this = mtd->priv;
>> ...
>>if (cmd != -1)
>> ({ do { } while (0); (*(volatile unsigned char *)(this->IO_ADDR_W)>
>> = (cmd)); });
>
> But this is the old, discarded version of the patch.
>
> I though we had agreed that we have to use the
>
>   __asm__ __volatile__ ("" : : : "memory")
>
> version instead?

Yes.

I mixed the patches :(

Sorry for the noise. I just sent the hopefully correct version some 
minutes ago.

Thanks

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Dirk Behme]

(Resend with corrected broken example)

On 21.12.2010 08:21, Albert ARIBAUD wrote:
> Hi Dirk,
>
> Le 21/12/2010 08:11, Dirk Behme a écrit :
>
>> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
>> ldrbr3, [r3]) is still open? Has anybody tried to replace it with
>> a nop in the binary to be sure this is the root cause?
>
> Can you try and preprocess the C file for both the broken and working
> cases, then post the preprocessed C extract? Differences at the C level
> may help understanding differences at the asm level.

gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)

Work:


static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
 uint32_t ctrl)
{
  register struct nand_chip *this = mtd->priv;
  ...
  if (cmd != -1)

   (*(volatile unsigned char *)(this->IO_ADDR_W) = (cmd));
}

if (cmd != NAND_CMD_NONE)
   84:  e3710001cmn r1, #1
origwriteb(cmd, this->IO_ADDR_W);
   88:  15933004ldrne   r3, [r3, #4]
   8c:  120110ffandne   r1, r1, #255; 0xff
   90:  15c31000strbne  r1, [r3]
   94:  e12fff1ebx  lr
...


Broken:
==

static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
 uint32_t ctrl)
{
  register struct nand_chip *this = mtd->priv;

...

  if (cmd != -1)
   ({ __asm__ __volatile__ ("" : : : "memory"); (*(volatile unsigned 
char *)(this->IO_ADDR_W) = (cmd)); });
}

if (cmd != NAND_CMD_NONE)
   84:  e3710001cmn r1, #1
   88:  012fff1ebxeqlr
writeb(cmd, this->IO_ADDR_W);
   8c:  e5933004ldr r3, [r3, #4]
   90:  e20110ffand r1, r1, #255; 0xff
   94:  e5c31000strbr1, [r3]
   98:  e5d33000ldrbr3, [r3]
   9c:  e12fff1ebx  lr


The issue seems to be the additional 'ldrb  r3, [r3]' added by the 
compiler in the broken version.

Best regards

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

Re: [U-Boot] [PATCH] Move DECLARE_GLOBAL_DATA_PTR to file scope

[Albert ARIBAUD]

Le 21/12/2010 09:07, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d104687.4030...@free.fr>  you wrote:
>> Le 21/12/2010 02:27, John Rigby a =E9crit :
>>> It can be optimised out by the compiler otherwise resulting
>>> in obscure errors like a board not booting.
>>>
>>> This has been documented in README since 2006 when these were
>>> first fixed up for GCC 4.x.
>>>
>>> Signed-off-by: John Rigby
>>> ---
>>
>> I think this should be considered a bug fix and a potent(ial) help in
>> getting as many ARM boards working as possible, and so should be put in
>> v2010.12 if still possible.
>
> Indeed.
>
> Shall I consider this a formal "Acked-by:" ?

Yes, please.

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Wolfgang Denk]

Dear Dirk Behme,

In message <4d105fb3.3090...@googlemail.com> you wrote:
>
> Broken:
> ==
...
> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>  uint32_t ctrl)
> {
>   register struct nand_chip *this = mtd->priv;
> ...
>   if (cmd != -1)
>({ do { } while (0); (*(volatile unsigned char *)(this->IO_ADDR_W) >
> = (cmd)); });

But this is the old, discarded version of the patch.

I though we had agreed that we have to use the

__asm__ __volatile__ ("" : : : "memory")

version instead?

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
Program maintenance is an entropy-increasing process,  and  even  its
most skilfull execution only delays the subsidence of the system into
unfixable obsolescence.   - 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] [PATCH] Move DECLARE_GLOBAL_DATA_PTR to file scope

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4d104687.4030...@free.fr> you wrote:
> Le 21/12/2010 02:27, John Rigby a =E9crit :
> > It can be optimised out by the compiler otherwise resulting
> > in obscure errors like a board not booting.
> >
> > This has been documented in README since 2006 when these were
> > first fixed up for GCC 4.x.
> >
> > Signed-off-by: John Rigby
> > ---
>
> I think this should be considered a bug fix and a potent(ial) help in
> getting as many ARM boards working as possible, and so should be put in 
> v2010.12 if still possible.

Indeed.

Shall I consider this a formal "Acked-by:" ?

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 human race is faced with a cruel choice: work  or  daytime  tele-
vision.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Move DECLARE_GLOBAL_DATA_PTR to file scope

[Wolfgang Denk]

Dear John Rigby,

In message <1292894871-1436-1-git-send-email-john.ri...@linaro.org> you wrote:
> It can be optimised out by the compiler otherwise resulting
> in obscure errors like a board not booting.
> 
> This has been documented in README since 2006 when these were
> first fixed up for GCC 4.x.
> 
> Signed-off-by: John Rigby 

Thanks for the cleanup.  Much appreciated.

However, this patch appears to miss a few places.  I think we should
additionally change the following:


>From 2ff61b7d2c288508d4873f1f80f7549886e00ee2 Mon Sep 17 00:00:00 2001
From: Wolfgang Denk 
Date: Tue, 21 Dec 2010 08:46:24 +0100
Subject: [PATCH] Move DECLARE_GLOBAL_DATA_PTR to file scope

Fix some additional places.

Signed-off-by: Wolfgang Denk 
---
 arch/arm/cpu/armv7/mx5/speed.c|2 ++
 arch/m68k/cpu/mcf52x2/cpu.c   |3 +--
 arch/sh/lib/board.c   |3 ---
 board/logicpd/zoom1/zoom1.c   |1 -
 board/samsung/smdk6400/smdk6400.c |2 --
 drivers/serial/serial_sh.c|1 -
 6 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx5/speed.c b/arch/arm/cpu/armv7/mx5/speed.c
index 826b3b1..2187e8e 100644
--- a/arch/arm/cpu/armv7/mx5/speed.c
+++ b/arch/arm/cpu/armv7/mx5/speed.c
@@ -28,7 +28,9 @@
 #include 
 #include 
 
+#ifdef CONFIG_FSL_ESDHC
 DECLARE_GLOBAL_DATA_PTR;
+#endif
 
 int get_clocks(void)
 {
diff --git a/arch/m68k/cpu/mcf52x2/cpu.c b/arch/m68k/cpu/mcf52x2/cpu.c
index 9fb717c..fb60462 100644
--- a/arch/m68k/cpu/mcf52x2/cpu.c
+++ b/arch/m68k/cpu/mcf52x2/cpu.c
@@ -74,8 +74,7 @@ int watchdog_disable(void)
 {
volatile wdog_t *wdt = (volatile wdog_t *)(MMAP_WDOG);
 
-   wdt->sr = 0x; /* reset watchdog counteDECLARE_GLOBAL_DATA_PTR;
-r */
+   wdt->sr = 0x; /* reset watchdog counter */
wdt->sr = 0x;
wdt->cr = 0;/* disable watchdog timer */
 
diff --git a/arch/sh/lib/board.c b/arch/sh/lib/board.c
index 8f50b09..3d201b2 100644
--- a/arch/sh/lib/board.c
+++ b/arch/sh/lib/board.c
@@ -99,7 +99,6 @@ static int sh_mem_env_init(void)
 #if defined(CONFIG_CMD_NET)
 static int sh_net_init(void)
 {
-   DECLARE_GLOBAL_DATA_PTR;
gd->bd->bi_ip_addr = getenv_IPaddr("ipaddr");
return 0;
 }
@@ -139,8 +138,6 @@ init_fnc_t *init_sequence[] =
 
 void sh_generic_init(void)
 {
-   DECLARE_GLOBAL_DATA_PTR;
-
bd_t *bd;
init_fnc_t **init_fnc_ptr;
 
diff --git a/board/logicpd/zoom1/zoom1.c b/board/logicpd/zoom1/zoom1.c
index efc2e1d..7ef13cc 100644
--- a/board/logicpd/zoom1/zoom1.c
+++ b/board/logicpd/zoom1/zoom1.c
@@ -41,7 +41,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-
 /*
  * Routine: board_init
  * Description: Early hardware init.
diff --git a/board/samsung/smdk6400/smdk6400.c 
b/board/samsung/smdk6400/smdk6400.c
index bc22f0f..35aa40b 100644
--- a/board/samsung/smdk6400/smdk6400.c
+++ b/board/samsung/smdk6400/smdk6400.c
@@ -80,8 +80,6 @@ int board_init(void)
 
 int dram_init(void)
 {
-   DECLARE_GLOBAL_DATA_PTR;
-
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
 
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 30dea7c..0103a29 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -23,7 +23,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-
 #if defined(CONFIG_CONS_SCIF0)
 # define SCIF_BASE SCIF0_BASE
 #elif defined(CONFIG_CONS_SCIF1)
-- 
1.7.3.3



I will add these when applying.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Dirk Behme]

On 21.12.2010 08:21, Albert ARIBAUD wrote:
> Hi Dirk,
>
> Le 21/12/2010 08:11, Dirk Behme a écrit :
>
>> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
>> ldrbr3, [r3]) is still open? Has anybody tried to replace it with
>> a nop in the binary to be sure this is the root cause?
>
> Can you try and preprocess the C file for both the broken and working
> cases, then post the preprocessed C extract? Differences at the C level
> may help understanding differences at the asm level.

gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)

Work:


static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
 uint32_t ctrl)
{
  register struct nand_chip *this = mtd->priv;
  ...
  if (cmd != -1)

   (*(volatile unsigned char *)(this->IO_ADDR_W) = (cmd));
}

if (cmd != NAND_CMD_NONE)
   84:  e3710001cmn r1, #1
origwriteb(cmd, this->IO_ADDR_W);
   88:  15933004ldrne   r3, [r3, #4]
   8c:  120110ffandne   r1, r1, #255; 0xff
   90:  15c31000strbne  r1, [r3]
   94:  e12fff1ebx  lr
...


Broken:
==

static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
 uint32_t ctrl)
{
  register struct nand_chip *this = mtd->priv;
...
  if (cmd != -1)
   ({ do { } while (0); (*(volatile unsigned char *)(this->IO_ADDR_W) 
= (cmd)); });
}

if (cmd != NAND_CMD_NONE)
   84:  e3710001cmn r1, #1
writeb(cmd, this->IO_ADDR_W);
   88:  15933004ldrne   r3, [r3, #4]
   8c:  120110ffandne   r1, r1, #255; 0xff
   90:  15c31000strbne  r1, [r3]
   94:  15d33000ldrbne  r3, [r3]
   98:  e12fff1ebx  lr
...


The issue seems to be the additional 'ldrbner3, [r3]' added by the 
compiler in the broken version.

Best regards

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