headers
Po-Yu Chuang | 1 Sep 2009 03:41
Picon

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

Dear Jean-Christophe PLAGNIOL-VILLARD,

2009/8/20 Po-Yu Chuang <ratbert.chuang <at> gmail.com>:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>> From: Po-Yu Chuang <ratbert <at> faraday-tech.com>
>>
>> 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 <ratbert <at> faraday-tech.com>
> 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.chuang <at> gmail.com \
> --to=u-boot <at> lists.denx.de \
> --cc=plagnioj <at> jcrosoft.com \
> --cc=wd <at> denx.de \
> --cc=augulis.darius <at> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dirk Behme | 1 Sep 2009 08:13

Re: ARM preprocessor error generating assembly dependencies

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Wolfgang Denk | 1 Sep 2009 08:38
Picon
Picon
Favicon

Re: ARM preprocessor error generating assembly dependencies

Dear Dirk Behme,

In message <4A9CBB9D.6030502 <at> 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: wd <at> denx.de
If it has syntax, it isn't user friendly.
Permalink | Reply | 3 comments |
headers
Dirk Behme | 1 Sep 2009 08:46

Re: ARM preprocessor error generating assembly dependencies

Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <4A9CBB9D.6030502 <at> 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
Permalink | Reply | 2 comments |
headers
André Schwarz | 1 Sep 2009 09:29
Picon

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

On Mon, 2009-08-31 at 19:48 +0200, Wolfgang Denk wrote:
> Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
> 
> In message <1251722510.4189.67.camel <at> 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).

After following your suggestion (git format-patch) with proper commit
message and "Signed-off-by:" I could omit the "--compose" argument for
git send-mail leading to a single mail, i.e. this is fixed now.

Thanks for your help,
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wolfgang Denk | 1 Sep 2009 09:34
Picon
Picon
Favicon

Re: ARM preprocessor error generating assembly dependencies

Dear Dirk Behme,

In message <4A9CC333.7020403 <at> googlemail.com> you wrote:
>
> >> 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?

Probablky not, as this seems to be bogus and would most probably break
a ton of things.

What I mean is that I am not aware of any __ASSEMBLY__ related issues
with dependency generation in mainline code, so I fail to understand
which exact problem you are trying to solve.

Your original posting mentioned some file include/asm-arm/assembler.h
but this not part of mainline, so 1) I cannot comment on it and 2) if
adding this file causes problems I would tend to assume that there
are problems with that file, but not necessarily with the rest of the
system.

Best regards,

Wolfgang Denk
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wolfgang Denk | 1 Sep 2009 09:36
Picon
Picon
Favicon

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

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

In message <1251790163.4137.2.camel <at> swa-m460> you wrote:
>
> After following your suggestion (git format-patch) with proper commit
> message and "Signed-off-by:" I could omit the "--compose" argument for
> git send-mail leading to a single mail, i.e. this is fixed now.

Hm... but the man page is pretty clear about the fact that --compose
will result in an additional introductory message to be generated:

	Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
	introductory message for the patch series.

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: wd <at> denx.de
"A child is a person who can't understand why someone would give away
a perfectly good kitten."                               - Doug Larson
Permalink | Reply | 0 comments |
headers
André Schwarz | 1 Sep 2009 09:44
Picon

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

Wolfgang,

On Mon, 2009-08-31 at 20:26 +0200, Wolfgang Denk wrote:
> Dear Andre Schwarz,
> 
> In message <1251728304-26888-1-git-send-email-andre.schwarz <at> matrix-vision.de> you wrote:
> > This fixes current build failure.
> > 
> > Signed-off-by: Andre Schwarz <andre.schwarz <at> matrix-vision.de>
> 
> Hm... You did not test your patch, did you?

of course. Both boards compiled cleanly (I thought).

> 
> -> git-am -3 -i -u --whitespace=strip ~/Mail/U-Boot/8023

Sorry - I'm not familiar with this.

> Commit Body is:
> --------------------------
> Add common code dir for Matrix Vision boards.
> 
> This fixes current build failure.
> 
> Signed-off-by: Andre Schwarz <andre.schwarz <at> matrix-vision.de>
> --------------------------
> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Behme | 1 Sep 2009 09:57

Re: ARM preprocessor error generating assembly dependencies

Dear Wolfgang Denk,

Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <4A9CC333.7020403 <at> googlemail.com> you wrote:
>>>> 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?
> 
> Probablky not, as this seems to be bogus and would most probably break
> a ton of things.
> 
> What I mean is that I am not aware of any __ASSEMBLY__ related issues
> with dependency generation in mainline code, so I fail to understand
> which exact problem you are trying to solve.

I think it's not a good idea to calculate dependencies with different 
options than used for compilation. So the exact problem I'm looking 
for is to use same options for (assembly file) dependency generation 
and compilation. Just to be clean here, independent  of a discussion 
whether it might be necessary or not (which would be obsolete then).

Best regards

Dirk
(Continue reading)

Permalink | Reply | 0 comments |
headers
Albin Tonnerre | 1 Sep 2009 10:37
Favicon

[PATCH] AT91: Add SD/MMC controller support

This patch allows to use the atmel_mci SD/MMC driver on the at91 architecture.
It contains:
 - initialization code for the MCI controller for all the supported AT91. It
   allows the use of only one controller even if a SoC has two controllers
   (anyway there's no support for it in atmel_mci as of now)
 - the necessary get_mci_clk_rate function
 - definition of MMCI_BASE for use in atmel_mci
 - the cpu_mmc_init function. As of now this is not used, but will be required
   when atmel_mci is ported to the new generic mmc API.

Signed-off-by: Albin Tonnerre <albin.tonnerre <at> free-electrons.com>
---
 cpu/arm926ejs/at91/at91cap9_devices.c       |   36 ++++++++++++++++++
 cpu/arm926ejs/at91/at91sam9260_devices.c    |   27 +++++++++++++
 cpu/arm926ejs/at91/at91sam9261_devices.c    |   18 +++++++++
 cpu/arm926ejs/at91/at91sam9263_devices.c    |   54 +++++++++++++++++++++++++++
 cpu/arm926ejs/at91/at91sam9m10g45_devices.c |   54 +++++++++++++++++++++++++++
 cpu/arm926ejs/at91/at91sam9rl_devices.c     |   22 +++++++++++
 cpu/arm926ejs/at91/cpu.c                    |    7 +++
 include/asm-arm/arch-at91/at91_common.h     |    2 +
 include/asm-arm/arch-at91/clk.h             |    5 ++
 include/asm-arm/arch-at91/hardware.h        |   18 +++++++++
 include/asm-arm/arch-at91/memory-map.h      |    1 +
 11 files changed, 244 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/at91/at91cap9_devices.c b/cpu/arm926ejs/at91/at91cap9_devices.c
index 39e405f..4486cbb 100644
--- a/cpu/arm926ejs/at91/at91cap9_devices.c
+++ b/cpu/arm926ejs/at91/at91cap9_devices.c
 <at>  <at>  -79,6 +79,42  <at>  <at>  void at91_serial_hw_init(void)
(Continue reading)

Permalink | Reply | 3 comments |

Gmane