On 21.12.2010 08:21, Albert ARIBAUD wrote:
> Hi Dirk,
>
> Le 21/12/2010 08:11, Dirk Behme a écrit :
>
>> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
>> ldrbr3, [r3]) is still open? Has anybody tried to replace it with
>> a nop in the binary to be sure this is the root c
Dear John Rigby,
In message <1292894871-1436-1-git-send-email-john.ri...@linaro.org> you wrote:
> It can be optimised out by the compiler otherwise resulting
> in obscure errors like a board not booting.
>
> This has been documented in README since 2006 when these were
> first fixed up for GCC 4.
Dear Albert ARIBAUD,
In message <4d104687.4030...@free.fr> you wrote:
> Le 21/12/2010 02:27, John Rigby a =E9crit :
> > It can be optimised out by the compiler otherwise resulting
> > in obscure errors like a board not booting.
> >
> > This has been documented in README since 2006 when these were
Dear Dirk Behme,
In message <4d105fb3.3090...@googlemail.com> you wrote:
>
> Broken:
> ==
...
> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
> uint32_t ctrl)
> {
> register struct nand_chip *this = mtd->priv;
> ...
> if (cmd != -1)
>({ do { } while (0); (*(vo
Le 21/12/2010 09:07, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d104687.4030...@free.fr> you wrote:
>> Le 21/12/2010 02:27, John Rigby a =E9crit :
>>> It can be optimised out by the compiler otherwise resulting
>>> in obscure errors like a board not booting.
>>>
>>> This has be
(Resend with corrected broken example)
On 21.12.2010 08:21, Albert ARIBAUD wrote:
> Hi Dirk,
>
> Le 21/12/2010 08:11, Dirk Behme a écrit :
>
>> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
>> ldrbr3, [r3]) is still open? Has anybody tried to replace it with
>> a nop in
On 21.12.2010 09:17, Wolfgang Denk wrote:
> Dear Dirk Behme,
>
> In message<4d105fb3.3090...@googlemail.com> you wrote:
>>
>> Broken:
>> ==
> ...
>> static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
>> uint32_t ctrl)
>> {
>>register struct nand_chip *this = mtd->priv
Hi,
Someone configured u-boot with mtd support for Karo tx25 board? Config file
don't configure it.
best regard
Davide Doninelli
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Tue, Dec 21, 2010 at 1:35 AM, Dirk Behme wrote:
>
> (Resend with corrected broken example)
>
> On 21.12.2010 08:21, Albert ARIBAUD wrote:
>> Hi Dirk,
>>
>> Le 21/12/2010 08:11, Dirk Behme a écrit :
>>
>>> But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
>>> ldrb r3, [r3])
Hi Wolfgang,
I have just found that your patch (in subject) break gd/bd pointer for
Microblaze. I have done patch which fix it but not sure if is correct.
Microblaze uses small space at the end of ram for gd and bd.
For example:
end of ram 0xd7ff
bd 0xd7ff ffc0
gd 0xd
Add Faraday's ftgmac100 (gigabit ethernet)
MAC controller's driver.
Signed-off-by: Macpaul Lin
---
Changes for v2:
- Coding Style cleanup
- Makefile Order sorted
- Volatile statement eliminated
- Error handling added
- Autonegotiation timeout value rechecked
- Link speed detecti
Signed-off-by: David Mueller
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 223fb71..da8c9b1 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -41,6 +41,7 @@
#define AM29DL800BB0x22CB
#define AM29DL800BT0x224A
+#define AM29F400BB 0
This patch brings the VCMA9 port in sync with the latest U-Boot
version by doing the following:
- do the necessary adjustments to support the ARM relocation feature
- use the CFI flash driver (and removing the old one)
- various cleanups and coding style fixes
Signed-off-by: David Mueller
di
Le 21/12/2010 09:46, John Rigby a écrit :
> On Tue, Dec 21, 2010 at 1:35 AM, Dirk Behme wrote:
>>
>> (Resend with corrected broken example)
>>
>> On 21.12.2010 08:21, Albert ARIBAUD wrote:
>>> Hi Dirk,
>>>
>>> Le 21/12/2010 08:11, Dirk Behme a écrit :
>>>
But the issue with drivers/mtd/nand/o
Dear Michal,
In message <4d106994.10...@monstr.eu> you wrote:
>
> Maybe will be worth to take a look at monitor,malloc area and stack.
>
> Microblaze uses:
> end of ram
> bd 0x40
> gd 0x40
> monitor area
> malloc area
> stack (grows down)
>
> Is it OK to use this scheme?
Sure. You can basicly
Dear Albert ARIBAUD,
In message <4d1083b4.2060...@free.fr> you wrote:
>
> > And I at your suggestion tried modifying the binary changing the extra
> > ldrb to a nop and it works.
>
> Seems like a compiler issue to me, as the preprocessed C source is the
> same for the register access and does not
Microblaze implement enable/disable interrupts through MSR
that's why disable_interrupts function should return 1.
Signed-off-by: John Linn
Signed-off-by: Michal Simek
---
arch/microblaze/cpu/interrupts.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/microblaze/
Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
(sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
(currently 0x40).
Microblaze configs used 0x40(128) because this place also contained
board info structure which lies on t
Hi Wolfgang,
I am sending two patches for review. I don't expect that someone will
have any compains about that's why I have create fix branch in my custodian repo
and you can pull them.
Both patches are fixes and if possible, I would like to add them
to your branch. I have looked at schedule a
Dear Michal Simek,
In message <1292933384-3032-2-git-send-email-mon...@monstr.eu> you wrote:
> Microblaze implement enable/disable interrupts through MSR
> that's why disable_interrupts function should return 1.
>
> Signed-off-by: John Linn
> Signed-off-by: Michal Simek
> ---
> arch/microblaze
Dear Michal Simek,
In message <1292933384-3032-3-git-send-email-mon...@monstr.eu> you wrote:
> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
> introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
> (currently 0x40).
>
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Michal,
>
> In message <4d106994.10...@monstr.eu> you wrote:
>> Maybe will be worth to take a look at monitor,malloc area and stack.
>>
>> Microblaze uses:
>> end of ram
>> bd 0x40
>> gd 0x40
>> monitor area
>> malloc area
>> stack (grows down)
>>
>> Is
Am 21.12.2010 11:53, schrieb Wolfgang Denk:
> Dear Albert ARIBAUD,
>
> In message<4d1083b4.2060...@free.fr> you wrote:
>>
>>> And I at your suggestion tried modifying the binary changing the extra
>>> ldrb to a nop and it works.
>>
>> Seems like a compiler issue to me, as the preprocessed C source
Le 21/12/2010 13:35, Alexander Holler a écrit :
> Hmm, is there actual somethinbg which should forbid the compiler to
> generate such code which rereads something? It might not be nice, but I
> don't think that it is forbidden for a compiler to do so. So the proper
> way to handle such, might be t
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <1292933384-3032-3-git-send-email-mon...@monstr.eu> you wrote:
>> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
>> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
>> introduce GENERATED_GBL_DATA_SIZE which is sizeof align
Microblaze implement enable/disable interrupts through MSR
that's why disable_interrupts function should return 1 when interrupt
was enabled. Return 0 when interrupt was disabled.
Signed-off-by: John Linn
Signed-off-by: Michal Simek
---
arch/microblaze/cpu/interrupts.c |4 +++-
1 files chan
Be more than you can be as an at-home worker , I found something thats
reces$ion proof, make up to one thousand a day with this article news site i
found: http://bit.ly/hq5aMX";>View this article heree
___
U-Boot mailing list
U-Boot@lists.denx.de
http:
Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
> Le 21/12/2010 13:35, Alexander Holler a écrit :
>
>> Hmm, is there actual somethinbg which should forbid the compiler to
>> generate such code which rereads something? It might not be nice, but I
>> don't think that it is forbidden for a compiler to do
Hello.
On 21-12-2010 16:02, Michal Simek wrote:
> Microblaze implement enable/disable interrupts through MSR
> that's why disable_interrupts function should return 1 when interrupt
> was enabled. Return 0 when interrupt was disabled.
> Signed-off-by: John Linn
> Signed-off-by: Michal Simek
[...]
Hello.
On 19-12-2010 1:21, Wolfgang Denk wrote:
>> Print a message when a RDIMM is detected.
> ...
>> +} else
>> printf("ERROR: Mix of registered buffered and unbuffered "
>> "DIMMs detected!\n");
>> -}
> Mutli-line statement needs braces.
Hello,
Am 21.12.2010 01:25, schrieb John Rigby:
> On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler
> wrote:
>
>> There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
...
> Yes, you are correct, I see the same here with 4.5.2. I noticed that
> bd did not have correct values
Dear Michal Simek,
In message <4d10a473.2030...@monstr.eu> you wrote:
>
> I would like to do it but it is not easy to use sizeof because there are
> some dependencies in macros in common.h(lines 193-201) because I am
> using CONFIG_SYS_GBL_DATA_OFFSET for monitor/malloc areas.
>
> The best will
Dear Michal Simek,
In message <1292936565-24677-1-git-send-email-mon...@monstr.eu> you wrote:
> Microblaze implement enable/disable interrupts through MSR
> that's why disable_interrupts function should return 1 when interrupt
> was enabled. Return 0 when interrupt was disabled.
>
> Signed-off-by
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <4d10a473.2030...@monstr.eu> you wrote:
>> I would like to do it but it is not easy to use sizeof because there are
>> some dependencies in macros in common.h(lines 193-201) because I am
>> using CONFIG_SYS_GBL_DATA_OFFSET for monitor/mall
Hi Alexander,
> may I ask again for opinions about enabling that feature?
I also would like to see it. Wolfgang, is there anything that you
don't like about this option?
Cheers
Detlev
--
5.7: Practically speaking, what is the difference between arrays and pointers?
About the difference betw
Hi Vijay,
> I am bit new to this field and my query here is understandably a
> bit vague. I am particularly interested in how any of you, who have had
> experience with uBoot and a JTAG debugger (like a Lauterbach), have gone
> about tackling and resolving an issue within uBoot.
>
> Speci
Le 21/12/2010 14:30, Alexander Holler a écrit :
> Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
>> Le 21/12/2010 13:35, Alexander Holler a écrit :
>>
>>> Hmm, is there actual somethinbg which should forbid the compiler to
>>> generate such code which rereads something? It might not be nice, but I
>>
Am 22.08.2009 23:41, schrieb Wolfgang Denk:
> Hi everybody...
>
> v2009.08-rc3 has just been released.
>
> Please help testing, and submit fixes to the remaining problems.
>
Hello,
I have tested the EB+CPUx9K2 Board. It can be compiled with gcc 4.2.2 (ELDK)
and gcc 4.5.1 (buildroot 2010.1
Dear Detlev Zundel,
In message you wrote:
>
> > may I ask again for opinions about enabling that feature?
>
> I also would like to see it. Wolfgang, is there anything that you
> don't like about this option?
There is two things that make me hesitate:
1) I wonder if it might have negative sid
Hello,
I'm trying to write an U-Boot command to ping the other interface on my
platform. This is to test the hardware at production, the ping must hit the
wire. I got deeply inspired from this patch:
http://lists.denx.de/pipermail/u-boot/2005-March/009317.html
What changes is that I really want
Dear Jens Scharsig,
In message <4d10bb60.9020...@scharsoft.de> you wrote:
>
> I have tested the EB+CPUx9K2 Board. It can be compiled with gcc 4.2.2 (ELDK)
> and gcc 4.5.1 (buildroot 2010.11).
Thanks for testing.
> But it runs only , if I use the newer 4.5.1 toolchain. I think, there are
> toolc
Dear Wolfgang Denk,
I'm Abraham Yu, here is my first time write to you, I feel so happy to join
the U-Boot team.
I was porting arm926ejs SoC to our new SoC call "AVT2210", OK! Here is some
basically questions below:
(u-boot.1010.12.rc2 is what I am using.)
1). First, I am useing JTAG to
Dear Guy Morand,
please restrict your line length to approx 70 characters or so.
In message
you wrote:
>
> I'm trying to write an U-Boot command to ping the other interface on my pla
> tform. This is to test the hardware at production, the ping must hit the wi
> re. I got deeply inspired from t
Dear =?GBK?B?09q74Q==?=,
Please do not hijack existing mail threads!!
Start a new thread, and make sure to chose a proper subject.
Please make sure to use a line length of 70 characters or so.
And never post HTML to that list.
In message <7eb125f4.fad0.12d0964185c.coremail.henrybe...@163.com>
Hi Wolfgang,
> Dear Detlev Zundel,
>
> In message you wrote:
>>
>> > may I ask again for opinions about enabling that feature?
>>
>> I also would like to see it. Wolfgang, is there anything that you
>> don't like about this option?
>
> There is two things that make me hesitate:
>
> 1) I wonder
Hi List.
I am working on porting U-Boot to arm1176-based SoC. It works in
general, but I had to cut off relocation because of a problem
described below. In short: Looks like u-boot fails to link correctly
with some CONFIG_SYS_TEXT_BASE values.
Board name: uemd
Compiler: arm-none-linux-gnueabi-gcc
Dear Sergey Mironov,
In message you
wrote:
>
> Compiler: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72)
> 4.3.2 -- I also tried a couple of other versions without difference.
Did these include more recent versions? GCC 4.3.x is not exactly what
I can recommend for ARM systems...
>
> In message you
> wrote:
>>
>> Compiler: arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72)
>> 4.3.2 -- I also tried a couple of other versions without difference.
>
> Did these include more recent versions? GCC 4.3.x is not exactly what
> I can recommend for ARM systems...
Well, the n
The LL TEMAC h/w changed at some point quite some time ago such that
the length field in the BD is used for other stuff also such that the
length needs to be masked correctly. This change is backward
compatible with older h/w also.
This change was tested on the 12.2 EDK system on the SP605 board.
Hi John,
John Linn wrote:
> The LL TEMAC h/w changed at some point quite some time ago such that
> the length field in the BD is used for other stuff also such that the
> length needs to be masked correctly. This change is backward
> compatible with older h/w also.
>
> This change was tested on
On Dec 20, 2010, at 10:49 AM, Peter Tyser wrote:
> Thanks for the cleanup. What branch should this series be applied to?
> And are there prerequisites? I'm having issues applying them to test
> and review.
>
> On Fri, 2010-12-17 at 17:50 -0600, Kumar Gala wrote:
>> Remove duplicated code in MP
On Dec 18, 2010, at 3:27 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message you
> wrote:
>> [ a few minor bug fixes for v2010.12 ]
>>
>> The following changes since commit 3ac45988ab1605baaf83bd3acb80a197c9a208c2:
>>
>> Prepare v2010.12-rc3 (2010-12-17 10:15:38 +0100)
>>
>> are ava
On Dec 17, 2010, at 5:17 PM, Becky Bruce wrote:
> Also, change this code to use phys_size_t instead of long int.
> Using common naming for this function will enable us to use the common
> initdram() for 85xx going forward. Other than the type change,
> this is just a code rearrange.
>
> Signed-
Dear Wolfgang Denk:
>
>> But it runs only , if I use the newer 4.5.1 toolchain. I think, there are
>> toolchain issues with relocation
>
> Can you please try and investigate the issue?
I found out, that the board hangs if there u-boot access to non SDRAM
memory like NAND or frambuffer. I try to
PCI is not used at all on lwmon5. So lets remove it. It saves space and
reduces boot time a bit (approx. 50ms).
Signed-off-by: Stefan Roese
---
include/configs/lwmon5.h | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/include/configs/lwmon5.h b/include/co
Clear coding style issues.
Signed-off-by: Michal Simek
---
lib/asm-offsets.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
index 2209561..f1af7e2 100644
--- a/lib/asm-offsets.c
+++ b/lib/asm-offsets.c
@@ -19,11 +19,11 @@
#i
GENERATED_BD_INFO_SIZE represent sizeof bd_info structure
which is used across architectures.
This value can be used in assembler files and macros.
Signed-off-by: Michal Simek
---
lib/asm-offsets.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/asm-offsets.c b/lib/a
Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
(sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
(currently 0x40).
Microblaze configs used 0x40(128) because this place also contained
board info structure which lies on t
Dear Sergey Mironov,
In message you
wrote:
>
> Well, the newest one I've tried was arm-none-linux-gnueabi-gcc (Gentoo
> 4.4.4-r1 p1.1, pie-0.4.5) 4.4.4. But I found it broken since it messed
> up relocation-related sections for some reason. What compiler you
> think I should try?
I don't know
Dear Michal Simek,
In message <1292955178-13018-1-git-send-email-mon...@monstr.eu> you wrote:
> Clear coding style issues.
>
> Signed-off-by: Michal Simek
> ---
> lib/asm-offsets.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/asm-offsets.c b/lib/asm-of
Dear Michal Simek,
In message <1292955178-13018-2-git-send-email-mon...@monstr.eu> you wrote:
> GENERATED_BD_INFO_SIZE represent sizeof bd_info structure
> which is used across architectures.
> This value can be used in assembler files and macros.
>
> Signed-off-by: Michal Simek
> ---
> lib/asm
Dear Michal Simek,
In message <1292955178-13018-3-git-send-email-mon...@monstr.eu> you wrote:
> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
> introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
> (currently 0x40).
>
Rather than keep the load_addr definition with the bootm code (which
just happens to use this), move it to the common env code. This way
we can disable bootm support completely while retaining load_addr
usage with many other commands.
Signed-off-by: Mike Frysinger
---
common/cmd_bootm.c |1
Dear John Rigby,
In message <1292894871-1436-1-git-send-email-john.ri...@linaro.org> you wrote:
> It can be optimised out by the compiler otherwise resulting
> in obscure errors like a board not booting.
>
> This has been documented in README since 2006 when these were
> first fixed up for GCC 4.
Dear Albert & friends,
what is your opinion? Should we include the memory barrier patch into
the upcoming release (and eventually delay it for further testing), or
release as is and solve this issue in the next release?
I tend to leave it as is, as I expect that most people will disappear
in the
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <1292955178-13018-1-git-send-email-mon...@monstr.eu> you wrote:
>> Clear coding style issues.
>>
>> Signed-off-by: Michal Simek
>> ---
>> lib/asm-offsets.c |6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git
On 21.12.2010 20:52, Wolfgang Denk wrote:
> Dear Albert& friends,
>
> what is your opinion? Should we include the memory barrier patch into
> the upcoming release (and eventually delay it for further testing), or
> release as is and solve this issue in the next release?
>
> I tend to leave it as
On Tue, 2010-12-21 at 11:49 -0600, Kumar Gala wrote:
> On Dec 20, 2010, at 10:49 AM, Peter Tyser wrote:
>
> > Thanks for the cleanup. What branch should this series be applied to?
> > And are there prerequisites? I'm having issues applying them to test
> > and review.
Any direction on how these
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <1292955178-13018-3-git-send-email-mon...@monstr.eu> you wrote:
>> Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
>> (sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
>> introduce GENERATED_GBL_DATA_SIZE which is sizeof alig
Patch "Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value"
(sha1: 25ddd1fb0a2281b182529afbc8fda5de2dc16d96)
introduce GENERATED_GBL_DATA_SIZE which is sizeof aligned gd_t
(currently 0x40).
Microblaze configs used 0x40(128) because this place also contained
board info structure which lies on t
Dear Michal Simek,
In message <4d1107d2.7070...@monstr.eu> you wrote:
>
> > These changes are to the worse. All. Why do you think this would be
> > better?
>
> It is what intend suggest to do.
> intend -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 -pcs
Please omit the "-pcs" part. It has always
Dear Michal Simek,
In message <4dcf.5090...@monstr.eu> you wrote:
>
> >> @@ -91,15 +91,16 @@ void board_init (void)
> >>bd_t *bd;
> >>init_fnc_t **init_fnc_ptr;
> >>gd = (gd_t *) CONFIG_SYS_GBL_DATA_OFFSET;
> >> + bd = (bd_t *) CONFIG_SYS_GBL_DATA_OFFSET - GENERATED_BD_INFO_SIZE;
Le 21/12/2010 21:04, Dirk Behme a écrit :
> I somehow tend to leave it as is, too.
Agree.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Am 21.12.2010 21:04, schrieb Dirk Behme:
> On 21.12.2010 20:52, Wolfgang Denk wrote:
>> Dear Albert& friends,
>>
>> what is your opinion? Should we include the memory barrier patch into
>> the upcoming release (and eventually delay it for further testing), or
>> release as is and solve this issu
Dear Ender Dai,
On 10 May 2010 15:26, Ender Dai wrote:
> .bss section should be zeroed out after relocat to ram.
>
> Signed-off-by: Ender Dai
> ---
> arch/arm/cpu/s3c44b0/start.S | 9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/s3c44b0/start.S b
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <4d1107d2.7070...@monstr.eu> you wrote:
>>> These changes are to the worse. All. Why do you think this would be
>>> better?
>> It is what intend suggest to do.
>> intend -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 -pcs
>
> Please omit the
Dear Michal Simek,
In message <4d119d06.2010...@monstr.eu> you wrote:
>
> > Please omit the "-pcs" part. It has always been my personal
> > preference, but I've been overruled, and we use plain Lindent these
> > days.
>
> Ok. Would it be possible to remove it from coding style page.
> http://www
Le 22/12/2010 01:11, Alexander Holler a écrit :
> Am 21.12.2010 21:04, schrieb Dirk Behme:
>> On 21.12.2010 20:52, Wolfgang Denk wrote:
>>> Dear Albert&friends,
>>>
>>> what is your opinion? Should we include the memory barrier patch into
>>> the upcoming release (and eventually delay it for f
On 22.12.2010 08:02, Albert ARIBAUD wrote:
> Le 22/12/2010 01:11, Alexander Holler a écrit :
>> Am 21.12.2010 21:04, schrieb Dirk Behme:
>>> On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albert& friends,
what is your opinion? Should we include the memory barrier patch into
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <4d119d06.2010...@monstr.eu> you wrote:
>>> Please omit the "-pcs" part. It has always been my personal
>>> preference, but I've been overruled, and we use plain Lindent these
>>> days.
>> Ok. Would it be possible to remove it from coding s
Dear Dirk Behme,
In message <4d11a65e.8040...@googlemail.com> you wrote:
>
> Btw, I tried to send a summary of our issues to the Codesourcery =
>
> mailing list:
>
> http://www.codesourcery.com/archives/arm-gnu/msg03989.html
>
> Let's see if we get an answer.
You got one:
http://www.codesource
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: mardi 21 décembre 2010 16:04
> To: Guy Morand
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] Ethernet HW loopack test
>
> Dear Guy Morand,
>
> please restrict your line length to approx 70 characters or so.
Yes
82 matches
Mail list logo
