Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Dirk Behme]

Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <4a9cbb9d.6030...@googlemail.com> you wrote:
>> Sorry if I'm wrong, but looking into top level rules.mk
> ...
>> this doesn't distinguish between .c and .S sources?
> 
> No, it does not.
> 
>> That is, it doesn't use AFLAGS set in config.mk to generate assembly 
>> dependencies? So setting  -D__ASSEMBLY__ while generating assembly 
>> dependencies is missing here?
> 
> It's not needed. At least for none of the files in mainline.

Does this mean you will accept a patch that removes -D__ASSEMBLY__ 
from AFLAGS in config.mk?

Best regards

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

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Wolfgang Denk]

Dear Dirk Behme,

In message <4a9cbb9d.6030...@googlemail.com> you wrote:
>
> Sorry if I'm wrong, but looking into top level rules.mk
...
> this doesn't distinguish between .c and .S sources?

No, it does not.

> That is, it doesn't use AFLAGS set in config.mk to generate assembly 
> dependencies? So setting  -D__ASSEMBLY__ while generating assembly 
> dependencies is missing here?

It's not needed. At least for none of the files in mainline.

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 it has syntax, it isn't user friendly.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Dirk Behme]

Dirk Behme wrote:
> Dirk Behme wrote:
>> Wolfgang Denk wrote:
 Any expert here could have look to which options are taken for ARM's 
 assembly dependency generation? It seems to me that -D__ASSEMBLY__ 
 is missing there?
>>>
>>> I have no clue what you are talking about...
>>
>> It seems to me that dependencies for ARM assembly files are generated 
>> with different (incomplete?) options than the compilation is done. 
>> That is, it seems to me that for ARM assembly file compilation, 
>> -D__ASSEMBLY__ is set, while for dependency generation it isn't.
>>
>> I'm asking if anybody can give me a hint where I have to look for the 
>> (compiler/assembler) options used for dependency generation (for 
>> lib_arm/*.S for lib_arm/.depend) or if any expert likes to have a look 
>> to this (most probably being faster than me then ;) ).
> 
> Example: Put
> 
> #ifndef __ASSEMBLY__
> #error "Foo"
> #endif
> 
> into a lib_arm/*.S file you like (and which is build ;)) and test what 
> happens. I would assume, if -D__ASSEMBLY__ is used everywhere correctly, 
> no error message should be given.

Sorry if I'm wrong, but looking into top level rules.mk

_depend:$(obj).depend

$(obj).depend:  $(src)Makefile $(TOPDIR)/config.mk $(SRCS)
@rm -f $@
@for f in $(SRCS); do \
g=`basename $$f | sed -e 's/\(.*\)\.\w/\1.o/'`; \
$(CC) -M $(HOSTCFLAGS) $(CPPFLAGS) -MQ $(obj)$$g $$f >> 
$@ ; \
done

this doesn't distinguish between .c and .S sources?

That is, it doesn't use AFLAGS set in config.mk to generate assembly 
dependencies? So setting  -D__ASSEMBLY__ while generating assembly 
dependencies is missing here?

Best regards

Dirk



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

Re: [U-Boot] [PATCH v6 2/2] arm: A320: Add support for Faraday A320 evaluation board

[Po-Yu Chuang]

Dear Jean-Christophe PLAGNIOL-VILLARD,

2009/8/20 Po-Yu Chuang :
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>> From: Po-Yu Chuang 
>>
>> This patch adds support for A320 evaluation board from Faraday. This board
>> uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
>> FA526 is an ARMv4 processor and uses the ARM920T source in this patch.
>>
>> Signed-off-by: Po-Yu Chuang 
> I failed to CC you again, but the patches appear in the mailing list.
> Hope you can see them.
>
> The command I used is like below.
> Is there anything wrong?
>
> git send-email \
> --from=ratbert.chu...@gmail.com \
> --to=u-b...@lists.denx.de \
> --cc=plagn...@jcrosoft.com \
> --cc...@denx.de \
> --cc=augulis.dar...@gmail.com \
> 0002-arm-A320-Add-support-for-Faraday-A320-evaluation-boa.patch

Did you get the patches?
or I need to resend again?

best regards,
Po-Yu Chuang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Writing files to filesystem

[Mike Frysinger]

On Monday 31 August 2009 12:33:28 Ricardo Martínez wrote:
> I would like to write text files to JFFS2 filesystem from an application
> launched by u-boot.
>
> I mean something similar to C library functions fopen and fprintf. The
> purpose is programming a simple logger.
>
> I've been taking a look at the sources and I think fopen and fprintf or
> similars do not exist in u-boot, only printf and fprintf for stdeer, stdout
> & stdin.

correct, u-boot has no support for writing any file system, nor file i/o in 
general
-mike


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

[U-Boot] [STATUS] U-Boot 2009.08 Release

[Wolfgang Denk]

Hi everybody,

U-Boot v2009.08 has been released and is available from the git
repository and the FTP server.

The "next" branch has been pulled into mainline ("master" branch) and
will be removed soon.

The Merge Window for the next release is open until
Monday, September 21, 2009, i. e. 21 days remaining.

The next release is scheduled for November 18, 2009.

See  http://www.denx.de/wiki/U-Boot/ReleaseCycle  for details,
including guestimates for thenext releases after that.


A little statistics [1] - changes since release v2009.06:

Processed 724 csets from 96 developers
34 employers found
A total of 83512 lines added, 52725 removed (delta 30787)

Compare v2009.06:

Processed 470 csets from 74 developers
27 employers found
A total of 51824 lines added, 17041 removed (delta 34783)

Developers with the most changesets
Wolfgang Denk   75 (10.4%)
Peter Tyser 69 (9.5%)
Jean-Christophe PLAGNIOL-VILLARD   57 (7.9%)
Mike Frysinger  56 (7.7%)
Stefan Roese40 (5.5%)
Prafulla Wadaskar   23 (3.2%)
Tom Rix 22 (3.0%)
David Brownell  17 (2.3%)
Kumar Gala  16 (2.2%)
Matthias Fuchs  16 (2.2%)
...

Developers with the most changed lines
Wolfgang Denk 14835 (12.9%)
Jean-Christophe PLAGNIOL-VILLARD 10512 (9.2%)
Matthias Fuchs8471 (7.4%)
Mike Frysinger6553 (5.7%)
Scott Wood5620 (4.9%)
Prafulla Wadaskar 5290 (4.6%)
Giuseppe Condorelli   4937 (4.3%)
Stefan Roese  3988 (3.5%)
Roy Zang  3515 (3.1%)
Peter Tyser   2954 (2.6%)
...

Developers with the most lines removed
Matthias Fuchs6924 (13.1%)
Scott Wood5607 (10.6%)
Jean-Christophe PLAGNIOL-VILLARD 3606 (6.8%)
Michal Simek  1024 (1.9%)
Kim Phillips   927 (1.8%)
Sandeep Paulraj 70 (0.1%)
galak   62 (0.1%)
Timur Tabi  51 (0.1%)
Matthias Ludwig 29 (0.1%)
Grazvydas Ignotas   16 (0.0%)
...

Developers with the most signoffs (total 1047)
Stefan Roese   139 (13.3%)
Kumar Gala 103 (9.8%)
Ben Warren  81 (7.7%)
Mike Frysinger  77 (7.4%)
Peter Tyser 72 (6.9%)
Jean-Christophe PLAGNIOL-VILLARD   71 (6.8%)
Scott Wood  45 (4.3%)
Kim Phillips39 (3.7%)
Remy Bohmer 29 (2.8%)
Prafulla Wadaskar   23 (2.2%)
...

Developers with the most reviews (total 14)
Ronen Shitrit6 (42.9%)
Angelo Castello  4 (28.6%)
Alessandro Rubini2 (14.3%)
Ira W. Snyder2 (14.3%)

Developers with the most test credits (total 24)
Jean-Christophe PLAGNIOL-VILLARD4 (16.7%)
Wolfgang Denk4 (16.7%)
Ira W. Snyder2 (8.3%)
Mike Frysinger   2 (8.3%)
Tom Rix  2 (8.3%)
Dirk Behme   2 (8.3%)
Heiko Schocher   2 (8.3%)
Magnus Lilja 2 (8.3%)
Andrzej Wolski   2 (8.3%)
Gaye Abdoulaye Walsimou  2 (8.3%)

Developers who gave the most tested-by credits (total 24)
Wolfgang Denk   18 (75.0%)
Ben Warren   1 (4.2%)
Peter Tyser  1 (4.2%)
Kim Phillips 1 (4.2%)
David Brownell   1 (4.2%)
Bernhard Weirich 1 (4.2%)
Dieter Kiermaier 1 (4.2%)

Developers with the most report credits (total 2)
Andrzej Wolski   2 (100.0%)

Developers who gave the most report credits (total 2)
Wolfgang Denk1 (50.0%)
Mike Frysinger   1 (50.0%)

Top changeset contributors by employer
DENX Software Engineering  140 (19.3%)
(Unknown)  102 (14.1%)
Extreme Engineering Solutions   70 (9.7%)
Freescale   63 (8.7%)
Analog Devices  62 (8.6%)
jcrosoft57 (7.9%)
Wind River  25 (3.5%)
Marvell 23 (3.2%)
ESD Electronics 20 (2.8%)
EmCraft Systems  8 (1.1%)
...

Top lines changed by employer
DENX Software Engineering 21436 (18.7%)
jcrosoft  14682 (12.8%)
Freescale 13641 (11.9%)
ESD Electronics   12184 (10.6%)
(Unknown) 10998 (9.6%)
Analog Devices9980 (8.7%)
Marvell   5290 (4.6%)
ST Microelectronics   4937 (4.3%)
Extreme Engineering Solutions 4350 (3.8%)
EmCraft Systems   2851 (2.5%)
...

Employers with the most signoffs (total 1047)
Freescale  222 (21.2%)
DENX Software Engineering  185 (17.7%)
(Unknown)  180 (17.2%)
Analog Devices  82 (7.8%)
Extreme Engineering Solutions   75 (7.2%)
jcrosoft71 (6.8%)
Oce Technologies29 (2.8%)
Marvell 25 (2.4%)
Wind River

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Becky Bruce]

On Aug 31, 2009, at 6:57 AM, Wolfgang Denk wrote:

> Dear Haavard Skinnemoen,
>
> In message <20090830224218.10f14...@siona> you wrote:
>>
>>> Well, VA==PA is the default setting for U-Boot that shall be used  
>>> for
>>> all systems, unless it is really impossible on a board to  
>>> implement an
>>> exception from that rule.
>>
>> While not impossible, following that rule on the NGW100 would require
>> that I either disable the caches (which would result in a massive
>> slowdown) or start using the MMU more actively to get the caching
>> properties right.
>
> OK, so this would be the plan for a clean fix, then?

Sorry, guys, I'm still not clear on what's going on. Haavard, did you  
expect each call to flash_map to return a different VA each time (i.e.  
you're trying to do some sort of dynamic mapping), or are you just  
calling it to get the VA that corresponds to some PA, since VA != PA  
on these 2 boards?


>
>>> In almost all cases RAM and NOR flash fit easily in the physical
>>> address space of the CPUs, and for the sake of this majority of
>>> systems it must be possible to access memory on such systems  
>>> assuming
>>> a simple 1:1 mapping.
>>
>> You're ignoring cache issues.
>
> Indeed I am, and intentionally, because this is a different topic. If
> your system requires to set up the MMU to enable  caching,  then  you
> are  supposed  to  do  it  in  a  way compatible with the rest of the
> software design, i. e. as transparently  as  possible.  None  of  the
> architectures  I  know resonably well have problems setting up a 1: 1
> address mapping even when the MMU is on (but I  have  to  admit  that
> AVR32 is not among these architectures).
>
>> Technically, the addresses seen by the CPU are virtual. And I don't
>> think systems with a cache should be considered 'very special' these
>> days...
>
> Cache should not be relevant  at  all  when  defining  a  physcal  or
> virtual memory map.

>
>> But exactly what's wrong with hiding all this complexity inside
>> map_physmem()? It was designed _exactly_ for this purpose -- to allow
>> platforms with non-trivial mappings between VA and PA to do the
>> necessary mapping when the driver requests it.
>
> Sorry, I don't know that code and it's users well enough to coment.
> Maybe Becky and/or Stefan can shed some light on this...

The problem is that would mean the CFI driver would be treating start  
as a PA, while every other flash driver that I looked at treats it as  
a VA.  That kind of inconsistency would be bad. Plus, Wolfgang,  
Stefan, Kumar, and I discussed this on the list/IRC last november and  
agreed that it made sense for command-line foo (including the flash  
commands)  to take a virtual address as the argument.  Platforms that  
have a non-fixed memory map would need to provide a command-line  
interface to get a VA to use (since that's highly unusual and expected  
to remain so).

>
>
>> That PA==VA rule is pretty much the reason we're in this mess -- if
>
> Let's say, the fact that this rule has not been stricter enforced has
> caused that teh appearant problems were not discovered earlier.
>
>> more platforms had broken this rule, perhaps more of the code would
>
> Heh. If more  platforms had broken this rule we would probably have
> become aware of these violations earlier, and stopped them doing such
> naughty things ;-)

Well, u-boot was supposed to be simple, and a VA=PA assumption ended  
up built into a lot of the code.  Which isn't a problem until you need  
something different  I had a lot of fun standing on my head trying  
to get 36-bit physical addressing on PowerPC working as a result of  
this.   I suspect the next big u-boot problem will be the need for  
dynamic mappings, because we're assuming for the most part now that  
the board memory map is static.

>
>
> As it seems, this requires some more discussion, i. e. a clean fix
> within the next couple of days is unlikely.  To me that means that it
> makes no sense to offer to delay the release of v2009.08 by a week or
> so, as we'd still not be ready then.  I will therefore proceed as
> planned, putting up with the fact that some (two, IIRC?) AVR32 boards
> are broken in this release. [we had a very long testing phase, and the
> problem is not exactly new, so it should have been detected (and
> fixed) long before.]

SGTM.  But then, it isn't my board that's broken. We do need a  
solution here, but I think we have time to work it out.

Cheers,
Becky

>
> 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
> 1st Old Man:  Gee, its windy today.
> 2nd Old Man:  No it's not... it's Thursday.
> 3rd Old Man:  Yeh, me too.  Let's go for a beer.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Becky Bruce]

On Aug 30, 2009, at 1:11 PM, Wolfgang Denk wrote:

> Dear Haavard & Becky,
>
> In message <20090830173640.2af9c...@siona> you wrote:
>>
>>> The only way for that to work
>>> is when VA=PA (or, depending on what you were doing with the  
>>> address,
>
> Well, VA==PA is the default setting for U-Boot that shall be used for
> all systems, unless it is really impossible on a board to implement an
> exception from that rule.

>
>>> you just got lucky).  The CFI driver was the outlier - all the other
>>> flash code was treating the start field as a VA already.  So I don't
>>> think just  reverting the patch is the answer.
>
> We did not even have any notion of VA's in U-Boot until very
> recently, and I call on everybody not to make U-Boot more complicated
> than necessary.

There have always been VAs in U-boot, whether the programmer was aware  
of it or not.  They just happened to always be the same as a PA, and  
we never needed a separate "U-boot concept" for them.  However,  for  
any system with an MMU that has been turned on by u-boot, the notion  
of VAs exists.  You can't dereference a PA directly in a system with  
translation (even though the MMU is going to translate it to 1:1), and  
that's what all of the flash drivers were doing.  You can *treat* a PA  
as a VA and dereference it when you're 1:1, but at that point, you are  
in fact using it as a VA (nevermind its value).

>
> In almost all cases RAM and NOR flash fit easily in the physical
> address space of the CPUs, and for the sake of this majority of
> systems it must be possible to access memory on such systems assuming
> a simple 1:1 mapping.

Agreed.

>
>
> Becky: the fact that Haavard's code is breaking is not considered an
> indication of a deficiency in his code.

I'm not calling the code deficient, just a bit inconsistent, and it  
wasn't clear to me why.  When code uses the same value 1) by mapping  
it and 2) by dereferencing it directly, that's a bit strange.  Why map  
it in some cases and in not others?  How is that supposed to work when  
VA!=PA or when the VA can change? This is one of the reasons that it  
seemed to make sense to modify the driver as I did - it should now be  
able to work when VA!=PA as well as when we're 1:1.  I could find no  
users that seemed to need the dynamic mapping.  However, if anyone  
does need to *dynamically* map the flash in and out with a different  
VA each time, then we do need to do things a bit differently and we  
should look into a solution for that.  Clearly, I'm not the expert on  
the CFI code, so when I published that patch I expected someone to  
smack me if I was being a moron :)

>
> If the CFI driver kind of allowed for VAs before (but incompletely /
> incorrectly), then this dis not cause problems on any systems using a
> strict 1:1 mapping.
>
> Any changes to the code to correctly support other mappings must be
> done in a way that they (1) do not break and (2) do not add additional
> burdon on systems with a simple 1:1 mapping.

Agreed, there shouldn't be any burden on those systems.

>
>
>>> Everything is treated as virtual unless it's being used for hardware
>>> setup.
>
> Thisis NOT correct. U-Boot usually does NOT use virtual addresses.
> Only very few systems do, and these must care not to disturb the
> majority of systems which do no need to differentiate between
> physical and virtual addresses.

I'm not saying it *is* a VA as far as U-Boot knows, but that it is  
*treated* as one, as mentioned above.   And this code was not expected  
to disturb the 1:1 case.

>
>>> If you use something to do memory accesses, it's virtual.
>
> Unless you have a very special system you can rely on a strict 1:1
> mapping.

>
>>> A
>>> lot of code had been just using the PA as a VA, because things were
>>> always mapped 1-1.
>
> Not only were, but _are_ and _will_be_.

Of course - that should continue to be the default case unless it  
needs to differ for some reason.

>
>> There are basically two ways to fix it: Either go back to using
>> physical addresses in the flash API, or make CONFIG_ENV_ADDR virtual
>
> I understand we cannot do that, because some systems need to map (NOR)
> flash to virtual addresses outside the physical address space. Ok, so
> the CFI driver shall consistently be able to use VAs - but on simple
> systems with a 1:1 mapping there shall be no need in the system
> configuration to spend any thoughts on this.
>
>> (and from what I hear, the jffs2 code needs a similar fix.) This  
>> patch
>> does the latter, but it seems like it doesn't fix things
>> completely, and Wolfgang didn't appear very happy about it.
>
> Indeed I'm deeply trouble when log standing rules get silently bent
> and even broken.

I agree 100% that 1:1 support should not be disturbed, since that's  
the default case.   There was absolutely no intent here to bend any  
"log standing rules", and nothing has been done here that  
should have any impact on 1:1 as far as I'm aware.  It's the !1:1 case

Re: [U-Boot] [PATCH] Add common code dir for Matrix Vision boards.

[Wolfgang Denk]

Dear Andre Schwarz,

In message <1251728304-26888-1-git-send-email-andre.schw...@matrix-vision.de> 
you wrote:
> This fixes current build failure.
> 
> Signed-off-by: Andre Schwarz 

Hm... You did not test your patch, did you?

-> git-am -3 -i -u --whitespace=strip ~/Mail/U-Boot/8023
Commit Body is:
--
Add common code dir for Matrix Vision boards.

This fixes current build failure.

Signed-off-by: Andre Schwarz 
--
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying: Add common code dir for Matrix Vision boards.
/home/wd/git/u-boot/work/.git/rebase-apply/patch:168: trailing whitespace.

warning: 1 line applied after fixing whitespace errors.
...
Configuring for MVBLM7 board...
mvblm7.c: In function 'misc_init_r':
mvblm7.c:108: warning: implicit declaration of function 'mv_reset_environment'


I'm a bit disappointed that this warning is still present. I think  I
pointed it out before...

OK, I fixed it for you.

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 all Klatchian to me.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,

In message <1251722510.4189.67.ca...@swa-m460> you wrote:
> 
> git send-mail always creates two or more mails. The first one is
> unnecessary for a single patch, i.e. not a patch series.

It never did that for me. Are you sure you are generating the input
for "git send-mail" using "git format-patch"? If yes, can you please
send me a copy of this generated patch (directly, not on the ML;
please wrap it into a tarball so it gets sent unmodified).


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
You've no idea of what a poor opinion  I  have  of  myself,  and  how
little I deserve it.  - W. S. Gilbert
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090831155327.62b58...@hskinnemoen-d830> you wrote:
>
> Possibly. But it means even more effort and even larger code, so I'm
> not exactly happy about it.

Really? Sorry if I'm asking dumb questions - I don't know  AVR32:  is
it  true  that  stting  up a non-1:1 mapping for the NOR flash (i. e.
what you are doing now) is easier (less code) than setting up  a  1:1
mapping? What exactly are the reasons for this?

> > Indeed I am, and intentionally, because this is a different topic. If
> > your system requires to set up the MMU to enable  caching,  then  you
> > are  supposed  to  do  it  in  a  way compatible with the rest of the
> > software design, i. e. as transparently  as  possible.  None  of  the
> > architectures  I  know resonably well have problems setting up a 1: 1
> > address mapping even when the MMU is on (but I  have  to  admit  that
> > AVR32 is not among these architectures).
> 
> I suspect quite a few other architectures run with caches disabled
> because it's not safe to run with caches enabled with the current
> software design.

Well, usually we run with IC on and  with  DC  off,  usually  because
quite  a  number  of  drivers  and  other  code do not use proper I/O
accessors yet, and/or because it's easier and  nobody  really  cares.
For  example  on  PowerPC,  adding support for the data cache usually
gives only a minimal performance boost.  This  may  be  different  on
other architectures.

> > Cache should not be relevant  at  all  when  defining  a  physcal  or
> > virtual memory map.
> 
> Physical, no, but it's very common that the MMU defines caching
> properties (enabled/disabled, writeback/writethrough, etc.)

Agreed. But it should be not so difficult to use the MMU to set up  a
1:1  mapping  if  you have to set up the MMU at all - or is there any
problems with that which I'm not aware of?

> > Heh. If more  platforms had broken this rule we would probably have
> > become aware of these violations earlier, and stopped them doing such
> > naughty things ;-)
> 
> Seems like you think it's more important to follow arbitrary rules than
> writing code that works well.

Keeping the code as simple as possible is not exactly an arbitrary
rule. At least not for 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
Any time things appear to be going better, you have overlooked  some-
thing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Writing files to filesystem

[Ricardo Martínez]

Hi,
 
I would like to write text files to JFFS2 filesystem from an application
launched by u-boot.
 
I mean something similar to C library functions fopen and fprintf. The
purpose is programming a simple logger.
 
I've been taking a look at the sources and I think fopen and fprintf or
similars do not exist in u-boot, only printf and fprintf for stdeer, stdout
& stdin.
 
I've also found logbuff_printk, which writes string to global vector
buf[1024]. Maybe this is the best approach to my requirements, not writing
to filesystem, just
memory storing and printing when required.
 
Any piece of advice in order to implement that kind of easy logger would be
really appreciated.
 
Thank you very much
Ricardo

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

[U-Boot] [PATCH] Add common code dir for Matrix Vision boards.

[Andre Schwarz]

This fixes current build failure.

Signed-off-by: Andre Schwarz 
---
 board/matrix_vision/common/Makefile|   54 ++
 board/matrix_vision/common/mv_common.c |  126 
 board/matrix_vision/common/mv_common.h |   25 ++
 3 files changed, 205 insertions(+), 0 deletions(-)
 create mode 100644 board/matrix_vision/common/Makefile
 create mode 100644 board/matrix_vision/common/mv_common.c
 create mode 100644 board/matrix_vision/common/mv_common.h

diff --git a/board/matrix_vision/common/Makefile 
b/board/matrix_vision/common/Makefile
new file mode 100644
index 000..b496258
--- /dev/null
+++ b/board/matrix_vision/common/Makefile
@@ -0,0 +1,54 @@
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)board/$(VENDOR)/common)
+endif
+
+LIB= $(obj)lib$(VENDOR).a
+
+COBJS-y= mv_common.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/matrix_vision/common/mv_common.c 
b/board/matrix_vision/common/mv_common.c
new file mode 100644
index 000..ed23e56
--- /dev/null
+++ b/board/matrix_vision/common/mv_common.c
@@ -0,0 +1,126 @@
+/*
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schw...@matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static char* entries_to_keep[] = {
+   "serial#", "ethaddr", "eth1addr", "model_info", "sensor_cnt",
+   "fpgadatasize", "ddr_size", "use_dhcp", "use_static_ipaddr",
+   "static_ipaddr", "static_netmask", "static_gateway",
+   "syslog", "watchdog", "netboot", "evo8serialnumber" };
+
+#define MV_MAX_ENV_ENTRY_LENGTH64
+#define MV_KEEP_ENTRIESARRAY_SIZE(entries_to_keep)
+
+void mv_reset_environment(void)
+{
+   int i;
+   char *s[MV_KEEP_ENTRIES];
+   char entries[MV_KEEP_ENTRIES][MV_MAX_ENV_ENTRY_LENGTH];
+
+   printf("\n*** RESET ENVIRONMENT ***\n");
+
+   memset(entries, 0, MV_KEEP_ENTRIES * MV_MAX_ENV_ENTRY_LENGTH);
+   for (i = 0; i < MV_KEEP_ENTRIES; i++) {
+   s[i] = getenv(entries_to_keep[i]);
+   if (s[i]) {
+   printf("save '%s' : %s\n", entries_to_keep[i], s[i]);
+   strncpy(entries[i], s[i], MV_MAX_ENV_ENTRY_LENGTH);
+   }
+   }
+
+   gd->env_valid = 0;
+   env_relocate();
+
+   for (i = 0; i < MV_KEEP_ENTRIES; i++) {
+   if (s[i]) {
+   printf("restore '%s' : %s\n", entries_to_keep[i], s[i]);
+   setenv(entries_to_keep[i], s[i]);
+   }
+   }
+
+   saveenv();
+}
+
+int mv_load_fpga(void)
+{
+   int result;
+   size_t data_size = 0;
+   void *fpga_data = NULL;
+   char *datastr = getenv("fp

Re: [U-Boot] mx27 ethernet support

[Fabio Estevam]

Hi Johann,

--- On Mon, 8/31/09, Johann Steinbrecher  
wrote:

> From: Johann Steinbrecher 
> Subject: [U-Boot] mx27 ethernet support
> To: u-boot@lists.denx.de
> Date: Monday, August 31, 2009, 7:35 AM
> Hello,
> 
> is there aan ethernet support for the imx27 processor.
> Where can I get the
> required patches?

Yes, please check 
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/net/fec_mxc.c;h=bd83a249ee34a3ca3291dc1cac5aa6290ec6cca5;hb=master

Regards,

Fabio Estevam


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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Wolfgang Denk  wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20090830224218.10f14...@siona> you wrote:
> >
> > > Well, VA==PA is the default setting for U-Boot that shall be used for
> > > all systems, unless it is really impossible on a board to implement an
> > > exception from that rule.
> > 
> > While not impossible, following that rule on the NGW100 would require
> > that I either disable the caches (which would result in a massive
> > slowdown) or start using the MMU more actively to get the caching
> > properties right.
> 
> OK, so this would be the plan for a clean fix, then?

Possibly. But it means even more effort and even larger code, so I'm
not exactly happy about it.

> > > In almost all cases RAM and NOR flash fit easily in the physical
> > > address space of the CPUs, and for the sake of this majority of
> > > systems it must be possible to access memory on such systems assuming
> > > a simple 1:1 mapping.
> > 
> > You're ignoring cache issues.
> 
> Indeed I am, and intentionally, because this is a different topic. If
> your system requires to set up the MMU to enable  caching,  then  you
> are  supposed  to  do  it  in  a  way compatible with the rest of the
> software design, i. e. as transparently  as  possible.  None  of  the
> architectures  I  know resonably well have problems setting up a 1: 1
> address mapping even when the MMU is on (but I  have  to  admit  that
> AVR32 is not among these architectures).

I suspect quite a few other architectures run with caches disabled
because it's not safe to run with caches enabled with the current
software design.

> > Technically, the addresses seen by the CPU are virtual. And I don't
> > think systems with a cache should be considered 'very special' these
> > days...
> 
> Cache should not be relevant  at  all  when  defining  a  physcal  or
> virtual memory map.

Physical, no, but it's very common that the MMU defines caching
properties (enabled/disabled, writeback/writethrough, etc.)

> > That PA==VA rule is pretty much the reason we're in this mess -- if
> 
> Let's say, the fact that this rule has not been stricter enforced has
> caused that teh appearant problems were not discovered earlier.
> 
> > more platforms had broken this rule, perhaps more of the code would
> 
> Heh. If more  platforms had broken this rule we would probably have
> become aware of these violations earlier, and stopped them doing such
> naughty things ;-)

Seems like you think it's more important to follow arbitrary rules than
writing code that works well.

> As it seems, this requires some more discussion, i. e. a clean fix
> within the next couple of days is unlikely.  To me that means that it
> makes no sense to offer to delay the release of v2009.08 by a week or
> so, as we'd still not be ready then.  I will therefore proceed as
> planned, putting up with the fact that some (two, IIRC?) AVR32 boards
> are broken in this release. [we had a very long testing phase, and the
> problem is not exactly new, so it should have been detected (and
> fixed) long before.]

Yes, I agree.

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

Re: [U-Boot] [PATCH 2/3] Reset interrupted i2c slaves (galaxy5200)

[Detlev Zundel]

Hello Heiko,

>>> Reset any i2c devices that may have been interrupted by a system reset.
>>> Normally this would be accomplished by clocking the line until SCL and SDA
>>> are released and then sending a start condtiion (From an Atmel datasheet).
>>> But since there is only write access to these lines on the MPC5200 we can
>>> only attempt to reset any slave devices by sending more start commands than
>>> bits the slave is attempting to transmit.
>> 
>> You may want to talk to Heiko (on CC) about this deblocking stuff.
>> Heiko implemented an algorithm which seems to work very good for a lot
>> of different cpu types.
>
> But this is realized for the bitbang driver, and actual only manufacturer
> (keymile) specific. 

I don't see a reason, why deblockiung an I2C bus should be manufacturer
specific...

> So, if we can use the I2C pins as GPIO, it is maybe
> an option, but a fast look in the mpc5200 users manual, didn;t show me
> a way for using the I2C pins as GPIO, so, we must implement a CPU
> specific (as we did it for the 83xx) way.
>
>> I think it may be worth to reuse what's available there.  And much more,
>> the algorithm Heiko has implemented has been thoroughly tested on actual
>> hardware whereas from your commit-msg it seems that your implementation
>> is more a theoretical one at the moment.
>
> As I understood Eric, there is only write access to the I2C pins, so
> we couldn;t use "my" deblocking mechanism. As Erics way is as the
> standard deblocking mechanism in the bitbang driver, I think, it is
> okay.

Ok, thanks for validating though!  Maybe we should add some
documentation notes about the various places where such things are done?

Cheers
  Detlev

-- 
The Speedo3 is very similar to other Intel network chips, that is to say
"apparently designed on a different planet".
   -- drivers/net/eepro100.c in Linux source
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Fwd: Re: mpc8315 DDR2 controller]

[Marcos Cunha]

Dears,

I found the problem.

The reference board (MPC8315ERDB) has 128MB DDR2. The new design has 
256MB DDR2. I chanced  the  size  macros in \incluce\configs\MPC8315E.h

#define CFG_DDR_SIZE256 /* MB */
#define CFG_DDR_CS0_BNDS0x000F  

But I forgot change MMU configurations. Below the correct configuration.

#define CFG_IBAT0U  (CFG_SDRAM_BASE | BATU_BL_256M| BATU_VS | BATU_VP)

Thanks,

Marcos Cunha
Electrical Engineer

Wolfgang Denk wrote:
> Dear Marcos Cunha,
>
> In message <4a944ee0.1000...@atlantico.com.br> you wrote:
>   
>> I am using u-boot 1.2.0 for mpc8315e processor with BDI2000 debugger in
>> a new design based on MPC8315ERDB.  Our board has a different DDR2 and
>> Flash memory. The flash memory works fine. The problem could be DDR2.
>> 
>
> U-Boot 1.2.0 is more than 2 years old.
>
> You really should not use such ancient stuff for a new design.
>
> You get the expected reply: please update, use current code and try
> again. If the problem still persists, please report back.
>
> Best regards,
>
> Wolfgang Denk
>
>   


-- 
cid:image002.gif@01C8B04F.DE139770

*Marcos Aurélio pinto cunha, PMP
Engenheiro eletricista / electrical engineer
***

cid:image002.gif@01C8B04F.DE139770

cid:image003.gif@01C8B04F.DE139770



Fone: +55 (85) 3216.7934
Fax: +55 (85) 3216.7864

Skype: marcos.cunha.ufc


*ISO 9001 : 2000 - CMMI3***



*www.atlantico.com.br ***


-- 
cid:image002.gif@01C8B04F.DE139770

*Marcos Aurélio pinto cunha, PMP
Engenheiro eletricista / electrical engineer
***

cid:image002.gif@01C8B04F.DE139770

cid:image003.gif@01C8B04F.DE139770



Fone: +55 (85) 3216.7934
Fax: +55 (85) 3216.7864

Skype: marcos.cunha.ufc


*ISO 9001 : 2000 - CMMI3***



*www.atlantico.com.br ***

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

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Dirk Behme]

Dirk Behme wrote:
> Wolfgang Denk wrote:
>>> Any expert here could have look to which options are taken for ARM's 
>>> assembly dependency generation? It seems to me that -D__ASSEMBLY__ is 
>>> missing there?
>>
>> I have no clue what you are talking about...
> 
> It seems to me that dependencies for ARM assembly files are generated 
> with different (incomplete?) options than the compilation is done. That 
> is, it seems to me that for ARM assembly file compilation, 
> -D__ASSEMBLY__ is set, while for dependency generation it isn't.
> 
> I'm asking if anybody can give me a hint where I have to look for the 
> (compiler/assembler) options used for dependency generation (for 
> lib_arm/*.S for lib_arm/.depend) or if any expert likes to have a look 
> to this (most probably being faster than me then ;) ).

Example: Put

#ifndef __ASSEMBLY__
#error "Foo"
#endif

into a lib_arm/*.S file you like (and which is build ;)) and test what 
happens. I would assume, if -D__ASSEMBLY__ is used everywhere 
correctly, no error message should be given.

Best regards

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

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Dirk Behme]

Wolfgang Denk wrote:
>> Any expert here could have look to which options are taken for ARM's 
>> assembly dependency generation? It seems to me that -D__ASSEMBLY__ is 
>> missing there?
> 
> I have no clue what you are talking about...

It seems to me that dependencies for ARM assembly files are generated 
with different (incomplete?) options than the compilation is done. 
That is, it seems to me that for ARM assembly file compilation, 
-D__ASSEMBLY__ is set, while for dependency generation it isn't.

I'm asking if anybody can give me a hint where I have to look for the 
(compiler/assembler) options used for dependency generation (for 
lib_arm/*.S for lib_arm/.depend) or if any expert likes to have a look 
to this (most probably being faster than me then ;) ).

Best regards

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

Re: [U-Boot] mpc8315 DDR2 controller

[Marcos Cunha]

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

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[André Schwarz]

Wolfgang,

On Mon, 2009-08-31 at 14:07 +0200, Wolfgang Denk wrote:
> Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
> 
> In message <1251712526.4189.25.ca...@swa-m460> you wrote:
> >
> > ok - Signed-off-by is missing although my .gitconfig has "signoff =
> > true" set in [format] section ... looks like I need -s arg at git
> > format-patch. Any hints about this ?
> 
> The Signed-off-by: does not get added when exporting the commit as a
> patch, but when committing the changes, i. e. it is part of the commit
> message, not added later.

But giving "-s" to git format-patch actually adds the Singed-off-by: ...

Anyway ... I'll do as you suggest, i.e. add it to the commit message.

> 
> > I also couldn't figure out how to send a *single* mail for a single
> > patch, i.e. without this initial stuff. IMHO this is only needed for a
> > patch series.
> 
> What do you mean by "initial stuff" ?

git send-mail always creates two or more mails. The first one is
unnecessary for a single patch, i.e. not a patch series.

> 
> > Is there anything else you want me to fix for this patch before I
> > resubmit it ?
> 
> Please provide a usable commit message (if needed, use "git commit
> --amend", eventually as part of a "git rebase -i", to fix the commit
> message in your repository) and make sure it contains a Signed-off-by:
> line.

ah - excellent. That's what I've been looking for. Thank you.

Regards,
André

> 
> 
> Best regards,
> 
> Wolfgang Denk
> 



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

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[André Schwarz]

Wolfgang,

On Mon, 2009-08-31 at 14:11 +0200, Wolfgang Denk wrote:
> Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
> 
> In message <1251712526.4189.25.ca...@swa-m460> you wrote:
> > 
> > Is there anything else you want me to fix for this patch before I
> > resubmit it ?
> 
> And please fix the compiler warnings:
> 
> ...
> Configuring for MVBC_P board...
> mv_common.c: In function 'mv_load_fpga':
> mv_common.c:93: warning: implicit declaration of function 'fpga_load'

ok - missed that.

> e1000.c: In function 'e1000_transmit':
> e1000.c:5019: warning: passing argument 1 of 'virt_to_phys' discards 
> qualifiers from pointer target type

That's e1000 driver. Looks like a recent change from Timur.

f81ecb5d drivers/net/e1000.c (Timur Tabi  2009-08-17 15:55:38
-0500 5019)   txp->buffer_addr = cpu_to_le64(virt_to_bus(hw->pdevr. 

> ...
> Configuring for MVBLM7 board...
> mv_common.c: In function 'mv_load_fpga':
> mv_common.c:93: warning: implicit declaration of function 'fpga_load'
> mvblm7.c: In function 'misc_init_r':
> mvblm7.c:108: warning: implicit declaration of function 'mv_reset_environment'

will fix.


Regards,
André

> ...
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 



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

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,

In message <1251712526.4189.25.ca...@swa-m460> you wrote:
>
> ok - Signed-off-by is missing although my .gitconfig has "signoff =
> true" set in [format] section ... looks like I need -s arg at git
> format-patch. Any hints about this ?

The Signed-off-by: does not get added when exporting the commit as a
patch, but when committing the changes, i. e. it is part of the commit
message, not added later.

> I also couldn't figure out how to send a *single* mail for a single
> patch, i.e. without this initial stuff. IMHO this is only needed for a
> patch series.

What do you mean by "initial stuff" ?

> Is there anything else you want me to fix for this patch before I
> resubmit it ?

Please provide a usable commit message (if needed, use "git commit
--amend", eventually as part of a "git rebase -i", to fix the commit
message in your repository) and make sure it contains a Signed-off-by:
line.


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 all seemed, he thought, to be rather a lot of  trouble  to  go  to
just sharpen a razor blade.  - Terry Pratchett, _The Light Fantastic_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,

In message <1251712526.4189.25.ca...@swa-m460> you wrote:
> 
> Is there anything else you want me to fix for this patch before I
> resubmit it ?

And please fix the compiler warnings:

...
Configuring for MVBC_P board...
mv_common.c: In function 'mv_load_fpga':
mv_common.c:93: warning: implicit declaration of function 'fpga_load'
e1000.c: In function 'e1000_transmit':
e1000.c:5019: warning: passing argument 1 of 'virt_to_phys' discards qualifiers 
from pointer target type
...
Configuring for MVBLM7 board...
mv_common.c: In function 'mv_load_fpga':
mv_common.c:93: warning: implicit declaration of function 'fpga_load'
mvblm7.c: In function 'misc_init_r':
mvblm7.c:108: warning: implicit declaration of function 'mv_reset_environment'
...


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 you hear an onion ring, answer it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Intel IQ31244

[Uladzislau Rezki]

On Sat, Aug 29, 2009 at 10:04 AM, Jean-Christophe
PLAGNIOL-VILLARD wrote:
> On 13:26 Fri 28 Aug     , Uladzislau Rezki wrote:
>> Hello list,
>>
>> I have Intel IQ31244 board that is based on XScale-IOP8032x Family processor.
>> I want to use u-boot as embedded loader but it seems to me that this
>> board is not
>> supported by u-boot.
>>
>> So, my questions are: Is it possible to build u-boot for my device ?
>> Has anyone had any
>> experience with such device ?
> It's not supported for now
> we only support ixp425
> but it will not be so difficult to add it
>
OK, i got it. Well, in this case i have another question regarding
porting, though i have not searched any related documentation yet... i
am going to do that.

Do you have any porting guide or something like that ?

Thanks.

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090830224218.10f14...@siona> you wrote:
>
> > Well, VA==PA is the default setting for U-Boot that shall be used for
> > all systems, unless it is really impossible on a board to implement an
> > exception from that rule.
> 
> While not impossible, following that rule on the NGW100 would require
> that I either disable the caches (which would result in a massive
> slowdown) or start using the MMU more actively to get the caching
> properties right.

OK, so this would be the plan for a clean fix, then?

> > In almost all cases RAM and NOR flash fit easily in the physical
> > address space of the CPUs, and for the sake of this majority of
> > systems it must be possible to access memory on such systems assuming
> > a simple 1:1 mapping.
> 
> You're ignoring cache issues.

Indeed I am, and intentionally, because this is a different topic. If
your system requires to set up the MMU to enable  caching,  then  you
are  supposed  to  do  it  in  a  way compatible with the rest of the
software design, i. e. as transparently  as  possible.  None  of  the
architectures  I  know resonably well have problems setting up a 1: 1
address mapping even when the MMU is on (but I  have  to  admit  that
AVR32 is not among these architectures).

> Technically, the addresses seen by the CPU are virtual. And I don't
> think systems with a cache should be considered 'very special' these
> days...

Cache should not be relevant  at  all  when  defining  a  physcal  or
virtual memory map.

> But exactly what's wrong with hiding all this complexity inside
> map_physmem()? It was designed _exactly_ for this purpose -- to allow
> platforms with non-trivial mappings between VA and PA to do the
> necessary mapping when the driver requests it.

Sorry, I don't know that code and it's users well enough to coment.
Maybe Becky and/or Stefan can shed some light on this...


> That PA==VA rule is pretty much the reason we're in this mess -- if

Let's say, the fact that this rule has not been stricter enforced has
caused that teh appearant problems were not discovered earlier.

> more platforms had broken this rule, perhaps more of the code would

Heh. If more  platforms had broken this rule we would probably have
become aware of these violations earlier, and stopped them doing such
naughty things ;-)


As it seems, this requires some more discussion, i. e. a clean fix
within the next couple of days is unlikely.  To me that means that it
makes no sense to offer to delay the release of v2009.08 by a week or
so, as we'd still not be ready then.  I will therefore proceed as
planned, putting up with the fact that some (two, IIRC?) AVR32 boards
are broken in this release. [we had a very long testing phase, and the
problem is not exactly new, so it should have been detected (and
fixed) long before.]

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
1st Old Man:  Gee, its windy today.
2nd Old Man:  No it's not... it's Thursday.
3rd Old Man:  Yeh, me too.  Let's go for a beer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MCI support for AT91 family processors.

[Sami Kantoluoto]

On Mon, Aug 31, 2009 at 01:39:26PM +0200, Albin Tonnerre wrote:
> On Mon, Aug 31, 2009 at 02:22:47PM +0300, Sami Kantoluoto wrote :
> > On Sun, Aug 30, 2009 at 01:08:27AM +0200, Albin Tonnerre wrote:
> > > On Sat, Aug 29, 2009 at 08:18:32PM +0300, Sami Kantoluoto wrote :
> > > > Fixed to parse CSD correctly on little endian processors as gcc orders
> > > > bitfields differently between big and little endian ones.
> > > 
> > > Please also see this patch, which will fix those bugs as weel, while 
> > > switching
> > > to the new GENRIC_MMC API:
> > > http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
> > > I'd highly appreciate if you could test it, to get some feedback
> > 
> > Thanks, I'll test when I get some time later this week but I think (by 
> > reading the patch so I probably missed something) it won't solve the CSD
> > problem. The real reason of the "CSD problem" of course is that how the
> > mmc_csd structure is defined (host byte order not taken in account or
> > at least how gcc handles bitfields).
> 
> drivers/mmc/mmc.c does not actually use the bitfield to parse the csd struct,
> and got fixed a while back to work no matter what endianness you're
> using, so it should solve it anyway.

Ok. Like I said (in other post) I was using the older u-boot version before
so I'm not too familiar with current one (and wasn't actually with the old
one either ;-). I'll try to do my homework better next time!


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

Re: [U-Boot] [PATCH] MCI support for AT91 family processors.

[Albin Tonnerre]

On Mon, Aug 31, 2009 at 02:22:47PM +0300, Sami Kantoluoto wrote :
> On Sun, Aug 30, 2009 at 01:08:27AM +0200, Albin Tonnerre wrote:
> > On Sat, Aug 29, 2009 at 08:18:32PM +0300, Sami Kantoluoto wrote :
> > > Fixed to parse CSD correctly on little endian processors as gcc orders
> > > bitfields differently between big and little endian ones.
> > 
> > Please also see this patch, which will fix those bugs as weel, while 
> > switching
> > to the new GENRIC_MMC API:
> > http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
> > I'd highly appreciate if you could test it, to get some feedback
> 
> Thanks, I'll test when I get some time later this week but I think (by 
> reading the patch so I probably missed something) it won't solve the CSD
> problem. The real reason of the "CSD problem" of course is that how the
> mmc_csd structure is defined (host byte order not taken in account or
> at least how gcc handles bitfields).
> 

drivers/mmc/mmc.c does not actually use the bitfield to parse the csd struct,
and got fixed a while back to work no matter what endianness you're using, so it
should solve it anyway.

> [snip]
> 
> > the configuration for the MCI controller, which should be done in the
> > at91sam*_devices.c files. See the attached patch (relying on the patch
> > mentionned above) that adds such support. It's not complete yet either: it
> > partially lacks support for models which have 2 MCI controllers, but
> > that's not the case of the 9G20 anyway (that's just a matter of putting
> > proper ifdefs before defining AT91_BASE_MCI).
> > If what I've done in this patch is not the way to go, I'd appreciate
> > guidance on how to do it correctly.
> 
> It seems ok to me except one comment about the interface:
> 
> > diff --git a/include/asm-arm/arch-at91/at91_common.h 
> > b/include/asm-arm/arch-at91/at91_common.h
> >
> > +void at91_mci0_hw_init(int);
> > +void at91_mci1_hw_init(int);
> 
> I'm just wondering if the bus width should be configurable. It's probably
> quite unusual to use just one data bit but not impossible though. So maybe
> the interface call could be:
> 
> void at91_mci0_hw_init(int bwForSlotA, bwForSlotB)
> 
> Where the bwForSlot is either 0 (which means slot is not used), 1 or 4.

I guess I'll just use something similar to what the spi init function does (eg.
take only 1 argument, and use 1 << 0 for slot A/B, 1 << 1 for 1wire/4wires)

Thanks for your comments.

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MCI support for AT91 family processors.

[Sami Kantoluoto]

On Sun, Aug 30, 2009 at 01:08:27AM +0200, Albin Tonnerre wrote:
> On Sat, Aug 29, 2009 at 08:18:32PM +0300, Sami Kantoluoto wrote :
> > Fixed to parse CSD correctly on little endian processors as gcc orders
> > bitfields differently between big and little endian ones.
> 
> Please also see this patch, which will fix those bugs as weel, while switching
> to the new GENRIC_MMC API:
> http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
> I'd highly appreciate if you could test it, to get some feedback

Thanks, I'll test when I get some time later this week but I think (by 
reading the patch so I probably missed something) it won't solve the CSD
problem. The real reason of the "CSD problem" of course is that how the
mmc_csd structure is defined (host byte order not taken in account or
at least how gcc handles bitfields).

[snip]

> the configuration for the MCI controller, which should be done in the
> at91sam*_devices.c files. See the attached patch (relying on the patch
> mentionned above) that adds such support. It's not complete yet either: it
> partially lacks support for models which have 2 MCI controllers, but
> that's not the case of the 9G20 anyway (that's just a matter of putting
> proper ifdefs before defining AT91_BASE_MCI).
> If what I've done in this patch is not the way to go, I'd appreciate
> guidance on how to do it correctly.

It seems ok to me except one comment about the interface:

> diff --git a/include/asm-arm/arch-at91/at91_common.h 
> b/include/asm-arm/arch-at91/at91_common.h
>
> +void at91_mci0_hw_init(int);
> +void at91_mci1_hw_init(int);

I'm just wondering if the bus width should be configurable. It's probably
quite unusual to use just one data bit but not impossible though. So maybe
the interface call could be:

void at91_mci0_hw_init(int bwForSlotA, bwForSlotB)

Where the bwForSlot is either 0 (which means slot is not used), 1 or 4.


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

[U-Boot] mx27 ethernet support

[Johann Steinbrecher]

Hello,

is there aan ethernet support for the imx27 processor. Where can I get the
required patches?

Greetings

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

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Wolfgang Denk]

Dear Dirk Behme,

In message <4a9b8c3c.7080...@googlemail.com> you wrote:
> 
> for ARM I'm including
> 
> include/asm-arm/assembler.h
> 
> in an assembly file. Doing this, I get preprocessor error message

Hm... I get this:

-> ls include/asm-arm/assembler.h
ls: cannot access include/asm-arm/assembler.h: No such file or directory

> Any expert here could have look to which options are taken for ARM's 
> assembly dependency generation? It seems to me that -D__ASSEMBLY__ is 
> missing there?

I have no clue what you are talking about...

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
Real programmers don't comment their code. It was hard to  write,  it
should be hard to understand.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[André Schwarz]

Wolfgang, Kim,

ok - Signed-off-by is missing although my .gitconfig has "signoff =
true" set in [format] section ... looks like I need -s arg at git
format-patch. Any hints about this ?

I also couldn't figure out how to send a *single* mail for a single
patch, i.e. without this initial stuff. IMHO this is only needed for a
patch series.

Is there anything else you want me to fix for this patch before I
resubmit it ?


Regards,
André

On Mon, 2009-08-31 at 10:27 +0200, Andre Schwarz wrote:
> ---
>  board/matrix_vision/common/Makefile|   54 ++
>  board/matrix_vision/common/mv_common.c |  125 
> 
>  board/matrix_vision/common/mv_common.h |   25 +++
>  3 files changed, 204 insertions(+), 0 deletions(-)
>  create mode 100644 board/matrix_vision/common/Makefile
>  create mode 100644 board/matrix_vision/common/mv_common.c
>  create mode 100644 board/matrix_vision/common/mv_common.h
> 
> diff --git a/board/matrix_vision/common/Makefile 
> b/board/matrix_vision/common/Makefile
> new file mode 100644
> index 000..b496258
> --- /dev/null
> +++ b/board/matrix_vision/common/Makefile
> @@ -0,0 +1,54 @@
> +#
> +# (C) Copyright 2006
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> +# MA 02111-1307 USA
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +ifneq ($(OBJTREE),$(SRCTREE))
> +$(shell mkdir -p $(obj)board/$(VENDOR)/common)
> +endif
> +
> +LIB  = $(obj)lib$(VENDOR).a
> +
> +COBJS-y  = mv_common.o
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB):  $(obj).depend $(OBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS)
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean:   clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/matrix_vision/common/mv_common.c 
> b/board/matrix_vision/common/mv_common.c
> new file mode 100644
> index 000..284de16
> --- /dev/null
> +++ b/board/matrix_vision/common/mv_common.c
> @@ -0,0 +1,125 @@
> +/*
> + * (C) Copyright 2008
> + * Andre Schwarz, Matrix Vision GmbH, andre.schw...@matrix-vision.de
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static char* entries_to_keep[] = {
> + "serial#", "ethaddr", "eth1addr", "model_info", "sensor_cnt",
> + "fpgadatasize", "ddr_size", "use_dhcp", "use_static_ipaddr",
> + "static_ipaddr", "static_netmask", "static_gateway",
> + "syslog", "watchdog", "netboot", "evo8serialnumber" };
> +
> +#define MV_MAX_ENV_ENTRY_LENGTH  64
> +#define MV_KEEP_ENTRIES  ARRAY_SIZE(entries_to_keep)
> +
> +void mv_reset_environment(void)
> +{
> + int i;
> + char *s[MV_KEEP_ENTRIES];
> + char entries[MV_KEEP_ENTRIES][MV_MAX_ENV_ENTRY_LENGTH];
> +
> + printf("\n*** RESET ENVIRONMENT ***\n");
> +
> + memset(entries, 0, MV_KEEP_ENTRIES * MV_MAX_ENV_ENTRY_LENGTH);
> + for (i = 0; i < MV_KEEP_ENTRIES; i++) {
> + s[i] = getenv(entries_to_keep[i]);
> + if (s[i]) {
> +  

Re: [U-Boot] [PATCH v4 0/4]: bitops cleanup and fixes

[Simon Kagstrom]

On Mon, 24 Aug 2009 09:06:05 +0200
Simon Kagstrom  wrote:

> This update to the patch series just cleans up the commit messages to
> have the comments in the git comments section.

Sorry to ping you all, but are there any more comments on work to be
done before this patch series can be accepted? The patches were these:

   [PATCH v4 1/4]: Move __set/clear_bit from ubifs.h to bitops.h
   [PATCH v4 2/4]: arm: Make arm bitops endianness-independent
   [PATCH v4 3/4]: Define ffs/fls for all architectures
   [PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit for ARM

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

[U-Boot] ARM preprocessor error generating assembly dependencies

[Dirk Behme]

Hi,

for ARM I'm including

include/asm-arm/assembler.h

in an assembly file. Doing this, I get preprocessor error message

include/asm/assembler.h:17:2: error: #error "Only include this from 
assembly code"

This is due to __ASSEMBLY__ not defined, but It seems to me that this 
message comes from *dependency* generation, not from compilation.

For compilation,  -D__ASSEMBLY__ is set and it compiles fine.

Doing

#define __ASSEMBLY__
#include 

in assembly file fixes the error while generating dependencies, but 
results in __ASSEMBLY__ redefined message while compilation.

Any expert here could have look to which options are taken for ARM's 
assembly dependency generation? It seems to me that -D__ASSEMBLY__ is 
missing there?

Many thanks and best regards

Dirk

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

Re: [U-Boot] Intel IQ31244

[Uladzislau Rezki]

On Sat, Aug 29, 2009 at 10:04 AM, Jean-Christophe
PLAGNIOL-VILLARD wrote:
> On 13:26 Fri 28 Aug     , Uladzislau Rezki wrote:
>> Hello list,
>>
>> I have Intel IQ31244 board that is based on XScale-IOP8032x Family processor.
>> I want to use u-boot as embedded loader but it seems to me that this
>> board is not
>> supported by u-boot.
>>
>> So, my questions are: Is it possible to build u-boot for my device ?
>> Has anyone had any
>> experience with such device ?
> It's not supported for now
> we only support ixp425
> but it will not be so difficult to add it
>
OK, i got it. Well, in this case i have another question regarding
porting, though
i have not searched any related documentation yet... i am going to do that.

Do you have any porting guide or something like that ?

Thanks.

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

[U-Boot] [PATCH] fix broken matrix vision boards

[Andre Schwarz]

boards are currently broken due to missing common dir inside board dir.

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

[U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[Andre Schwarz]

---
 board/matrix_vision/common/Makefile|   54 ++
 board/matrix_vision/common/mv_common.c |  125 
 board/matrix_vision/common/mv_common.h |   25 +++
 3 files changed, 204 insertions(+), 0 deletions(-)
 create mode 100644 board/matrix_vision/common/Makefile
 create mode 100644 board/matrix_vision/common/mv_common.c
 create mode 100644 board/matrix_vision/common/mv_common.h

diff --git a/board/matrix_vision/common/Makefile 
b/board/matrix_vision/common/Makefile
new file mode 100644
index 000..b496258
--- /dev/null
+++ b/board/matrix_vision/common/Makefile
@@ -0,0 +1,54 @@
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)board/$(VENDOR)/common)
+endif
+
+LIB= $(obj)lib$(VENDOR).a
+
+COBJS-y= mv_common.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/matrix_vision/common/mv_common.c 
b/board/matrix_vision/common/mv_common.c
new file mode 100644
index 000..284de16
--- /dev/null
+++ b/board/matrix_vision/common/mv_common.c
@@ -0,0 +1,125 @@
+/*
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schw...@matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static char* entries_to_keep[] = {
+   "serial#", "ethaddr", "eth1addr", "model_info", "sensor_cnt",
+   "fpgadatasize", "ddr_size", "use_dhcp", "use_static_ipaddr",
+   "static_ipaddr", "static_netmask", "static_gateway",
+   "syslog", "watchdog", "netboot", "evo8serialnumber" };
+
+#define MV_MAX_ENV_ENTRY_LENGTH64
+#define MV_KEEP_ENTRIESARRAY_SIZE(entries_to_keep)
+
+void mv_reset_environment(void)
+{
+   int i;
+   char *s[MV_KEEP_ENTRIES];
+   char entries[MV_KEEP_ENTRIES][MV_MAX_ENV_ENTRY_LENGTH];
+
+   printf("\n*** RESET ENVIRONMENT ***\n");
+
+   memset(entries, 0, MV_KEEP_ENTRIES * MV_MAX_ENV_ENTRY_LENGTH);
+   for (i = 0; i < MV_KEEP_ENTRIES; i++) {
+   s[i] = getenv(entries_to_keep[i]);
+   if (s[i]) {
+   printf("save '%s' : %s\n", entries_to_keep[i], s[i]);
+   strncpy(entries[i], s[i], MV_MAX_ENV_ENTRY_LENGTH);
+   }
+   }
+
+   gd->env_valid = 0;
+   env_relocate();
+
+   for (i = 0; i < MV_KEEP_ENTRIES; i++) {
+   if (s[i]) {
+   printf("restore '%s' : %s\n", entries_to_keep[i], s[i]);
+   setenv(entries_to_keep[i], s[i]);
+   }
+   }
+
+   saveenv();
+}
+
+int mv_load_fpga(void)
+{
+   int result;
+   size_t data_size = 0;
+   void *fpga_data = NULL;
+   char *datastr = getenv("fpgadata");
+   char *sizestr = getenv("fpgadatasize");
+
+   if (get

Re: [U-Boot] [[PATCH]] add Matrix Vision specific dir for common code.

[André Schwarz]

huh - please ignore !
A "cc" has crept in by accident.

On Mon, 2009-08-31 at 10:17 +0200, Andre Schwarz wrote:
> ---
>  board/matrix_vision/common/Makefile|   54 ++
>  board/matrix_vision/common/mv_common.c |  125 
> 
>  board/matrix_vision/common/mv_common.h |   25 +++
>  3 files changed, 204 insertions(+), 0 deletions(-)
>  create mode 100644 board/matrix_vision/common/Makefile
>  create mode 100644 board/matrix_vision/common/mv_common.c
>  create mode 100644 board/matrix_vision/common/mv_common.h
> 
> diff --git a/board/matrix_vision/common/Makefile 
> b/board/matrix_vision/common/Makefile
> new file mode 100644
> index 000..b496258
> --- /dev/null
> +++ b/board/matrix_vision/common/Makefile
> @@ -0,0 +1,54 @@
> +#
> +# (C) Copyright 2006
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> +# MA 02111-1307 USA
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +ifneq ($(OBJTREE),$(SRCTREE))
> +$(shell mkdir -p $(obj)board/$(VENDOR)/common)
> +endif
> +
> +LIB  = $(obj)lib$(VENDOR).a
> +
> +COBJS-y  = mv_common.o
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB):  $(obj).depend $(OBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS)
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean:   clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/matrix_vision/common/mv_common.c 
> b/board/matrix_vision/common/mv_common.c
> new file mode 100644
> index 000..284de16
> --- /dev/null
> +++ b/board/matrix_vision/common/mv_common.c
> @@ -0,0 +1,125 @@
> +/*
> + * (C) Copyright 2008
> + * Andre Schwarz, Matrix Vision GmbH, andre.schw...@matrix-vision.de
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static char* entries_to_keep[] = {
> + "serial#", "ethaddr", "eth1addr", "model_info", "sensor_cnt",
> + "fpgadatasize", "ddr_size", "use_dhcp", "use_static_ipaddr",
> + "static_ipaddr", "static_netmask", "static_gateway",
> + "syslog", "watchdog", "netboot", "evo8serialnumber" };
> +
> +#define MV_MAX_ENV_ENTRY_LENGTH  64
> +#define MV_KEEP_ENTRIES  ARRAY_SIZE(entries_to_keep)
> +
> +void mv_reset_environment(void)
> +{
> + int i;
> + char *s[MV_KEEP_ENTRIES];
> + char entries[MV_KEEP_ENTRIES][MV_MAX_ENV_ENTRY_LENGTH];
> +
> + printf("\n*** RESET ENVIRONMENT ***\n");
> +
> + memset(entries, 0, MV_KEEP_ENTRIES * MV_MAX_ENV_ENTRY_LENGTH);
> + for (i = 0; i < MV_KEEP_ENTRIES; i++) {
> + s[i] = getenv(entries_to_keep[i]);
> + if (s[i]) {
> + printf("save '%s' : %s\n", entries_to_keep[i], s[i]);
> + strncpy(entries[i], s[i], MV_MAX_ENV_ENTRY_LENGTH);
> + }
> + }
> +
> + gd->env_valid = 0;
> + env_relocate();
> +
> + for (i = 0; i < MV_KEEP_ENTRIES; i++) {
> + if (s[i]) {
> + printf("restore '%s' : %s\n", entries_to_keep[i], s[

[U-Boot] [[PATCH]] add Matrix Vision specific dir for common code.

[Andre Schwarz]

---
 board/matrix_vision/common/Makefile|   54 ++
 board/matrix_vision/common/mv_common.c |  125 
 board/matrix_vision/common/mv_common.h |   25 +++
 3 files changed, 204 insertions(+), 0 deletions(-)
 create mode 100644 board/matrix_vision/common/Makefile
 create mode 100644 board/matrix_vision/common/mv_common.c
 create mode 100644 board/matrix_vision/common/mv_common.h

diff --git a/board/matrix_vision/common/Makefile 
b/board/matrix_vision/common/Makefile
new file mode 100644
index 000..b496258
--- /dev/null
+++ b/board/matrix_vision/common/Makefile
@@ -0,0 +1,54 @@
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)board/$(VENDOR)/common)
+endif
+
+LIB= $(obj)lib$(VENDOR).a
+
+COBJS-y= mv_common.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/matrix_vision/common/mv_common.c 
b/board/matrix_vision/common/mv_common.c
new file mode 100644
index 000..284de16
--- /dev/null
+++ b/board/matrix_vision/common/mv_common.c
@@ -0,0 +1,125 @@
+/*
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schw...@matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static char* entries_to_keep[] = {
+   "serial#", "ethaddr", "eth1addr", "model_info", "sensor_cnt",
+   "fpgadatasize", "ddr_size", "use_dhcp", "use_static_ipaddr",
+   "static_ipaddr", "static_netmask", "static_gateway",
+   "syslog", "watchdog", "netboot", "evo8serialnumber" };
+
+#define MV_MAX_ENV_ENTRY_LENGTH64
+#define MV_KEEP_ENTRIESARRAY_SIZE(entries_to_keep)
+
+void mv_reset_environment(void)
+{
+   int i;
+   char *s[MV_KEEP_ENTRIES];
+   char entries[MV_KEEP_ENTRIES][MV_MAX_ENV_ENTRY_LENGTH];
+
+   printf("\n*** RESET ENVIRONMENT ***\n");
+
+   memset(entries, 0, MV_KEEP_ENTRIES * MV_MAX_ENV_ENTRY_LENGTH);
+   for (i = 0; i < MV_KEEP_ENTRIES; i++) {
+   s[i] = getenv(entries_to_keep[i]);
+   if (s[i]) {
+   printf("save '%s' : %s\n", entries_to_keep[i], s[i]);
+   strncpy(entries[i], s[i], MV_MAX_ENV_ENTRY_LENGTH);
+   }
+   }
+
+   gd->env_valid = 0;
+   env_relocate();
+
+   for (i = 0; i < MV_KEEP_ENTRIES; i++) {
+   if (s[i]) {
+   printf("restore '%s' : %s\n", entries_to_keep[i], s[i]);
+   setenv(entries_to_keep[i], s[i]);
+   }
+   }
+
+   saveenv();
+}
+
+int mv_load_fpga(void)
+{
+   int result;
+   size_t data_size = 0;
+   void *fpga_data = NULL;
+   char *datastr = getenv("fpgadata");
+   char *sizestr = getenv("fpgadatasize");
+
+   if (get

Re: [U-Boot] [GIT PULL] AVR32: NGW100 fix for 2009.08

[Hans-Christian Egtvedt]

On Mon, 31 Aug 2009 09:44:40 +0200
Haavard Skinnemoen  wrote:

> Hans-Christian Egtvedt  wrote:
> > > Yeah...I'm unsure myself. The system will boot, but the 'saveenv'
> > > command doesn't work...so while I really want to fix this issue
> > > _properly_, I'm not sure if there's enough time to do that before the
> > > next release.
> > >   
> > 
> > Did you test loading something from JFFS2? I have a bad feeling it
> > might still be broken.
> 
> Right. Does anyone have any clue about why it's broken?
> 

Trying to do ls just hangs the bootloader.

U-Boot> ls
Scanning JFFS2 FS:   

I did not dig into the code, but I think the discussion about the same
topic this winter/spring saw the same behavior.

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

Re: [U-Boot] [PATCH 2/3] Reset interrupted i2c slaves (galaxy5200)

[Heiko Schocher]

Hello Detlev,

Detlev Zundel wrote:
>> Reset any i2c devices that may have been interrupted by a system reset.
>> Normally this would be accomplished by clocking the line until SCL and SDA
>> are released and then sending a start condtiion (From an Atmel datasheet).
>> But since there is only write access to these lines on the MPC5200 we can
>> only attempt to reset any slave devices by sending more start commands than
>> bits the slave is attempting to transmit.
> 
> You may want to talk to Heiko (on CC) about this deblocking stuff.
> Heiko implemented an algorithm which seems to work very good for a lot
> of different cpu types.

But this is realized for the bitbang driver, and actual only manufacturer
(keymile) specific. So, if we can use the I2C pins as GPIO, it is maybe
an option, but a fast look in the mpc5200 users manual, didn;t show me
a way for using the I2C pins as GPIO, so, we must implement a CPU
specific (as we did it for the 83xx) way.

> I think it may be worth to reuse what's available there.  And much more,
> the algorithm Heiko has implemented has been thoroughly tested on actual
> hardware whereas from your commit-msg it seems that your implementation
> is more a theoretical one at the moment.

As I understood Eric, there is only write access to the I2C pins, so
we couldn;t use "my" deblocking mechanism. As Erics way is as the
standard deblocking mechanism in the bitbang driver, I think, it is
okay.

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

Re: [U-Boot] [GIT PULL] AVR32: NGW100 fix for 2009.08

[Haavard Skinnemoen]

Hans-Christian Egtvedt  wrote:
> > Yeah...I'm unsure myself. The system will boot, but the 'saveenv'
> > command doesn't work...so while I really want to fix this issue
> > _properly_, I'm not sure if there's enough time to do that before the
> > next release.
> >   
> 
> Did you test loading something from JFFS2? I have a bad feeling it
> might still be broken.

Right. Does anyone have any clue about why it's broken?

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

Re: [U-Boot] [PATCH v6] use common code for Matrix Vision boards

[André Schwarz]

Wolfgang, Kim,

On Fri, 2009-08-28 at 21:19 +0200, Wolfgang Denk wrote:
> Dear Kim Phillips,
> 
> In message <20090828111410.71f92293.kim.phill...@freescale.com> you wrote:
> >
> > and we now have breakage:
> 
> Ah. Situation is normal again :-)

hmpf - it's me again.

> 
> > Configuring for MVBLM7 board...
> > pci.c:35:33: error: ../common/mv_common.h: No such file or directory
> > pci.c:35:33: error: ../common/mv_common.h: No such file or directory
> ...
> > 
> > where did mv_common.h go?  I can't find it.
> 
> Probably a new file that is missing in the patch.

board/matrix_vision/common dir is missing completely :-(
Something's wrong with my local repo ... branched and merged too often.
Looks like I'm missing some (or most) git capabilities.

I'll send a patch against current master in a few minutes.


Regards,
André

> 
> André ???
> 
> Best regards,
> 
> Wolfgang Denk
> 



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

Re: [U-Boot] [RFC] - Relocating i386 Code - Permission to break orphan boards

[Graeme Russ]

On Sun, Aug 30, 2009 at 8:44 PM, Graeme Russ wrote:
> Hi Wolfgang,
>
> I have been playing around with gcc's -fpic and ld's -PIE and I think that
> I can get 'proper' relocation happening on the i386 port. I've get the
> basics down, and I've been looking at /lib_ppc/board.c for how the PPC
> relocation scheme works and would like to replicate it (i.e. board_init_f,
> board_init_r and relocate_code.
>
> Unfortunately this leaves two options:
>
>  1) Tangle the i386 port up in a heap of #ifdefs, or;
>  2) Do a clean re-write for the eNET and break the other i386 boards
>(sc520_cdp and sc520_spunk).
>

Actually, I have a 3rd (better) plan - I'll create new source files for
the relocatable version and conditionally compile based on a new
#define in the board header.

Looking forward to getting into it :)

> The other two i386 boards are OLD and i have my doubts as to if they ever
> did work completely, and have really strong doubts as to them working now
>
> I would really like to just throw all the old code out and do it all
> cleanly, but not without strong support from the community.
>
> What are your thoughts?
>
> Regards,
>
> G
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot