> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: Tuesday, June 14, 2011 12:42 PM
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher
> Subject: [PATCH 2/2] arm/km: fix u-boot.kwb build breakage
>
> com
> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: Tuesday, June 14, 2011 12:42 PM
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher
> Subject: [PATCH 1/2] arm/kirkwood: if CONFIG_SOFT_I2C is set don't
Hi Prafulla,
On 06/15/2011 09:18 AM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>> Sent: Tuesday, June 14, 2011 12:42 PM
>> To: u-boot@lists.denx.de
>> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schoch
Hi,
x-loader has the following comment and if statement for all boards supporting
omap36xx SoC:
--cut
/*
* On OMAP3630, DDR data corruption has been observed on OFF mode
* exit if the sys clock was lower than 26M. As a
commit 010a958b
(arm/km: remove CONFIG_SYS_KWD_CONFIG from keymile-common.h)
breaks building keymile arm targets, when u-boot.kwb tries to
generate the binary with mkimage. A simple make or MAKEALL
succeeded because it don't try to build the kirwood binary at the end.
Due this commit we use the C
Some boards e.g. keymile arm boards have CONFIG_CMD_I2C switched on
but they use soft i2c on kirkwood. So don't switch CONFIG_I2C_MVTWSI
on in this case.
Signed-off-by: Holger Brunck
cc: Valentin Longchamp
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
changes for v2:
- nothing
arch/arm/inc
Tested-by: Jaehoon Chung
But Mr.Kang mentioned missing arch/arm/include/asm/arch-s5pc1xx/cpu.h
Need the below patch..
(s5pc2xx and s5pc1xx are working well)
diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
b/arch/arm/include/asm/arch-s5pc1xx/cpu.h
index e74959f..86b7bd2 100644
--- a/arch/ar
On 15 June 2011 17:12, Jaehoon Chung wrote:
> Tested-by: Jaehoon Chung
>
> But Mr.Kang mentioned missing arch/arm/include/asm/arch-s5pc1xx/cpu.h
> Need the below patch..
> (s5pc2xx and s5pc1xx are working well)
>
> diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
> b/arch/arm/include/asm/arc
Minkyu Kang wrote:
> On 15 June 2011 17:12, Jaehoon Chung wrote:
>> Tested-by: Jaehoon Chung
>>
>> But Mr.Kang mentioned missing arch/arm/include/asm/arch-s5pc1xx/cpu.h
>> Need the below patch..
>> (s5pc2xx and s5pc1xx are working well)
>>
>> diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
Dear Wolfgang,
On Tuesday 14 June 2011 07:23 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4df7488a.6000...@ti.com> you wrote:
>>
>> Yes. I have seen those macros. But more often than not the bit field is
>> more than 1 bit wide and the value to be set is not necessarily all 0's
>> or
Hi Graeme,
Setting r8 to gd was the solution. I now set it right before the first
access to gd then it works like a charm:
asm("ldr r8, [%[value]]"::[value] "r" (&gd):"r8"); /* Set r8 to gd */
Thanks for your help!
Simon
2011/6/14 Simon Schwarz :
> Ok. It seems I (or more precise a college) have
Dear Albert,
In message <4df853c3.9080...@discworld.dascon.de> Michael Schwingen wrote:
>
> what about the IXP patches?
>
> Marek sent a pull request on 2011-05-27, but I can't find them in a
> freshly pulled master.
Could you please comment? Thanks!
Best regards,
Wolfgang Denk
--
DENX Soft
Dear Aneesh V,
In message <4df871e3.8080...@ti.com> you wrote:
>
> So, the shift information is embedded in this mask and can be extracted
> by finding the first set bit. But in reality my get_bit_field()
> function indeed takes both arguments. So it's something like this:
As stated before, I wi
Hi Albert,
please pull from u-boot-imx. There are only fix for a couple of still
broken boards.
The following changes since commit 9571865e0d32b1bcf8a6625497d1cd5d4bbad354:
Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-08
23:29:04 +0200)
are available in the git repository at
Dear Aneesh V,
In message <4dde54e5.7080...@ti.com> you wrote:
>
> >> And how do you distinguish between the two cases at the top level
> >> Makefile? Using a CONFIG flag or on a per platform basis?
> >
> > The decision should not be make in the top level makefile, but in
> > spl/Makefile. And th
Dear Aneesh V,
In message <4dde5afe.9000...@ti.com> you wrote:
>
> I do not have any issue in having media specific files in their
> respective directories. However, I would like to see the 'Makefile's
> coming from the same directory tree irrespective of the media. So, how
> about something li
Dear Aneesh V,
In message <4decbc5c.10...@ti.com> you wrote:
> Hi Wolfgang,
>
> On Tuesday 17 May 2011 04:39 PM, Wolfgang Denk wrote:
> > Dear Aneesh V,
> >
> > In message<4dd24715.4010...@ti.com> you wrote:
> >>
> >>> Please fix all these names.
> >>
> >> Ok. Including the existing CONFIG_SYS_N
Dear Aneesh V,
In message <4df617c2.6070...@ti.com> you wrote:
>
> > Console should _always_ be enabled as early as possible,
>
> Unfortunately this is not the case with U-Boot today. Console
> initialization happens in board_init_f(). Before board_init_f()
> typically a lot of(in fact most of)
Hi,
I need one clarification regarding load address, entry point inside the Kernel
image & the address to where we load the image.
Assume, the image header is as below.
Image Name: Linux-2.6.38-10700-g846a497
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2064396 B
Hi,
I've been trying to get a version of u-boot for OpenRD Ultimate that is
willing to boot from all of NAND, USB, SD and SATA, and find that SD &
SATA is still not possible with -rc1 as packaged for Debian (and it
seems that nothing in the subsequent work in the master git would help,
but if peop
Dear Wolfgang,
On Wednesday 15 June 2011 03:43 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dde5afe.9000...@ti.com> you wrote:
>>
>> I do not have any issue in having media specific files in their
>> respective directories. However, I would like to see the 'Makefile's
>> coming from
Dear Wolfgang,
On Wednesday 15 June 2011 02:50 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4df871e3.8080...@ti.com> you wrote:
>>
>> So, the shift information is embedded in this mask and can be extracted
>> by finding the first set bit. But in reality my get_bit_field()
>> function
From: Helmut Raiger
Signed-off-by: Helmut Raiger
---
drivers/spi/mxc_spi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index f909e07..698e726 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -31,7 +31,
Hi Stefano,
On 6/15/2011 2:29 AM, Stefano Babic wrote:
...
>
> Why is the new output better as we have now ? You drop the output of
> the srev register, and then we cannot get which strange silicon version
> is running without patching the code.
Let me try to explain the problem I see with the c
Dear "Hebbar, Gururaja",
In message you
wrote:
>
>Image Name: Linux-2.6.38-10700-g846a497
>Image Type: ARM Linux Kernel Image (uncompressed)
>Data Size:2064396 Bytes = 2 MiB
>Load Address: 80008000
>Entry Point: 80008000
>Verifying Checksum ... OK
>
> And I load
Dear Aneesh,
In message <4df88f45.9090...@ti.com> you wrote:
>
> > I don't get this. Why don't we just pass the required make target
> > from the top level Makefile? If we want to build "onenand-ipl-2k.bin"
> > then this would result in running "make onenand-ipl-2k.bin" in the
> > respective dir
Dear Aneesh V,
In message <4df89102.9040...@ti.com> you wrote:
>
> Will you accept something like this?
>
> a_val = (reg & a_mask) >> a_shift;
Yes, of course (that's what seems most natural to me).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev
Hi Fabio,
On 15/06/11 21:50, Fabio Estevam wrote:
> Hi Stefano,
>
> On 6/15/2011 2:29 AM, Stefano Babic wrote:
> ...
>>
>> Why is the new output better as we have now ? You drop the output of
>> the srev register, and then we cannot get which strange silicon version
>> is running without patching
Dear Fabio Estevam,
In message <4df89c84.7090...@freescale.com> you wrote:
...
> CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG
...
> When the chip version is not valid, then we print:
>
> CPU: Freescale i.MX31 (unknown rev, srev=0x20) at 531 MHz.Reset cause: WDOG
Compare
Dear Wolfgang,
On Wednesday 15 June 2011 05:34 PM, Wolfgang Denk wrote:
> Dear Aneesh,
>
> In message<4df88f45.9090...@ti.com> you wrote:
>>
>>> I don't get this. Why don't we just pass the required make target
>>> from the top level Makefile? If we want to build "onenand-ipl-2k.bin"
>>> then t
Hi Graeme,
On 6/15/2011 9:08 AM, Graeme Russ wrote:
...
> Does 'srev' have a more plain language description? or would somebody
> reading that instantly know what 'srev' meant?
Yes, srev is the exact term that is found on the MX31 Reference Manual - Table
13-2
Reading Wolfgang´s message he thin
On 06/15/2011 01:50 PM, Fabio Estevam wrote:
> Hi Stefano,
>
Hi Fabio,
> Let me try to explain the problem I see with the current silicon
> detection mechanism:
>
> On my board (srev=0x28), which is a TO2.0 silicon I get:
>
> CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG
>
> On
Hi Wolfgang,
On 15/06/11 22:12, Wolfgang Denk wrote:
> Dear Fabio Estevam,
>
> In message <4df89c84.7090...@freescale.com> you wrote:
> ...
>> CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG
> ...
>> When the chip version is not valid, then we print:
>>
>> CPU: Freescale i.
On 15/06/11 22:04, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message <4df89102.9040...@ti.com> you wrote:
>>
>> Will you accept something like this?
>>
>> a_val = (reg & a_mask) >> a_shift;
>
> Yes, of course (that's what seems most natural to me).
>
Me too - The code is obvious - the desire
Dear Aneesh V,
In message <4df8a0c0.2040...@ti.com> you wrote:
>
> >> Of course, this is assuming the existing Makefile structure. With the
> >> new Makefile structure you are suggesting this may not hold good.
> >
> > Why not?
>
> I was saying that my suggestion of delegating everything to boar
Dear Stefano Babic,
In message <4df8a2de.3040...@denx.de> you wrote:
>
> > Reading rev 2.0 on Felix=B4s case is misleading IMHO as we tend to
> > think that we have a TO2.0 silicon on his board even though we get a
> > "unknown" string.
>
> Ok, so only reading the code we can know that version nu
Dear Graeme Russ,
In message <4df8a694.3030...@gmail.com> you wrote:
>
> But as Fabio has pointed out, the '2.0' in 'rev 2.0' is not srev - This
> highlights the root of the problem - (srev == 0x20) != (rev 2.0)
But everybody who spends half a minute on the problem can easily
determine this, wit
Dear Graeme Russ,
In message <4df8a8cf.5000...@gmail.com> you wrote:
>
> And to set the value then you have:
>
> reg &= ~a_mask; /* Clear a_val */
> reg |= (a_val << a_shift) & a_mask; /* Set new a_val */
This could be done using
clrsetbits_le32(®
On 15/06/11 22:49, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4df8a694.3030...@gmail.com> you wrote:
>>
>> But as Fabio has pointed out, the '2.0' in 'rev 2.0' is not srev - This
>> highlights the root of the problem - (srev == 0x20) != (rev 2.0)
>
> But everybody who spends half a
On 06/15/2011 02:47 PM, Wolfgang Denk wrote:
> Dear Stefano Babic,
>
Hi Wolfgang,
>
> Given that this is an exotic error case that happens only on a very
> small number of chips that are actually not supposed to exist at all,
Right, it can happen with some pre-production chips, as I understood
Hi Wolfgang,
On 15/06/11 22:51, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4df8a8cf.5000...@gmail.com> you wrote:
>>
>> And to set the value then you have:
>>
>> reg &= ~a_mask; /* Clear a_val */
>> reg |= (a_val << a_shift) & a_mask; /* Set new
Hi Wolfgang,
Since discussion seems to have died down, I have assumed pseudo consensus
and have started hitting the timer cleanup in earnest. All I can say is:
Wow! What a mess ;)
> We could also design a more complicated API like this one, but I doubt
> this is needed:
Well, it is needed if yo
On 06/14/2011 04:02 PM, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam
> ---
Hi Fabio,
> include/configs/mx31pdk.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
> index ba1e187..77e93ab 100644
> --- a
Signed-off-by: Fabio Estevam
---
include/configs/mx31pdk.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index ba1e187..5f70023 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -88,6 +88,7 @@
Hi Prafulla,
It appears that this v10 patch is also wrong. The specified email
encoding is UTF-8. It should be ISO-8859-1 which is the MAINTAINERS file
encoding. It is the reason why the patch is discarded by patchwork.
Please note that the patch diff is correct. The patch applies correctly
using
This is the third version of the patch serie. This patch serie was rebased on
top
of the two posted patches:
http://lists.denx.de/pipermail/u-boot/2011-June/094432.html
http://lists.denx.de/pipermail/u-boot/2011-June/094433.html
Initial cover letter message:
Beside the board support some small
CONFIG_ENV_SIZE for NAND was later in this file overwritten
because we have the environment in i2c eeprom, so remove
this define.
Signed-off-by: Holger Brunck
Signed-off-by: Valentin Longchamp
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
Changes for v3:
- rebased
Changes for v2:
- noth
From: Valentin Longchamp
This is defined for all km_kirkwood boards and was not used up to now.
This value was the same for all boards but it could be changed for some
boards (and thus needs to be defined for every board).
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
cc: Praf
From: Valentin Longchamp
The phy is also configured with "RGMII clock transitions when data
stable" and "Class A driver for the direct backplane connection".
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
Changes for v3:
- reba
From: Valentin Longchamp
This adds support for the keymile Kirkwood BEC portl2 board. This board
relies on the km_arm (km_kirkwood) BEC.
The egiga driver is configured for a 100M full-duplex, A/N off connnection
to the backplane. This board has always ethernet present, because it is
connected to
suen3 and suen8 were in first HW version quite different, but
now they are from a u-boot point of view similar. So these
two boards can use the same header file. Other keymile boards
differ only in the usage of the PCI interface. Therefore
a target km_kirkwood_pci was introduced. All targets use
th
On Tue, Jun 14, 2011 at 11:54 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
>>
>> > Looking closer, the "FIELD_VAL" macro alone will probably not suffice,
>> > as you need both shift directions, like that:
>> >
>> > #define FIELD_SHIFT 16
>> > #define FI
myfrends,
I am porting a boot from sequoia.
I have use the BDI3000 to load the u-boot.bin and flash to norflash.
I can trace the codes by BDI3000 and receive the u-boot info from uart as
following.
but when I try to power on and run the codes itself but not use BDI3000 to send
"go".
there are
Hi Graeme,
On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ wrote:
> Hi Wolfgang,
...
>>
>> /*
>> * round - used to control rounding:
>> * <0 : round down, return time that has passed AT LEAST
>> * =0 : don't round, provide raw time difference
>> * >0 : round up, ret
==
Message composé et expédié avec la version d'évaluation gratuite de
Sarbacane®, le logiciel d'e-mailing professionnel pour Windows de
GOTO Softw
Hi all,
I've got an interesting issue with a MIPS board I'm working on. The
uncompressed uImage has been created with a Load Address of 0x8050
and an Entry Point of 0x80504590. This gets TFTP's into RAM at
0x8055b728. When I run a "bootm 0x8055b728" this image fails to run.
Tracing through the
On 16/06/11 02:03, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ wrote:
>> Hi Wolfgang,
> ...
>>>
>>> /*
>>>* round - used to control rounding:
>>>* <0 : round down, return time that has passed AT LEAST
>>>* =0 : don't round, provid
Dear David Peverley,
In message you wrote:
>
> I've got an interesting issue with a MIPS board I'm working on. The
> uncompressed uImage has been created with a Load Address of 0x8050
> and an Entry Point of 0x80504590. This gets TFTP's into RAM at
> 0x8055b728. When I run a "bootm 0x8055b72
On Tue, Mar 01, 2011 at 02:40:55PM -0800, Ira W. Snyder wrote:
> Commit 359ec4931944adb885882deb9b781e4095eabc94 broke support for the
> Freescale DMA engine on the 83xx parts. This is due to using registers
> which do not exist on 83xx. Remove the attribute register accesses from
> the 83xx build.
Sometimes we want to build common tools without configuring for specific
target. Currently top Makefile has some support for this but it doesn't
work. This patch tries to fix this.
Things changed:
- config.mk disable 'ld script not found error' in case if we are
building tools only.
- Makefile
Hi Graeme,
On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ wrote:
> On 16/06/11 02:03, Simon Glass wrote:
>> - the common case is min I think, so let's get rid of the min prefix
>> so everyone will use it without question or needing to read screeds of
>> doc
>
> I don't like this idea - Extrapolate
On Tue, Jun 14, 2011 at 04:35:04PM -0400, Ben Gardiner wrote:
> This series adds a nand write variant which implements the procedure
> reccomended in the UBI FAQ [1] of dropping trailing pages of eraseblocks
> containing entirely 0xff's.
>
> [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_fl
Hi Simon,
On Thu, Jun 16, 2011 at 7:58 AM, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ wrote:
>> On 16/06/11 02:03, Simon Glass wrote:
>
>>> - the common case is min I think, so let's get rid of the min prefix
>>> so everyone will use it without question or n
Without this fix, the following statement erroneously echoed "true" (at least
on the microblaze architecture):
if itest.l 0 == 1; then echo "true"; else echo "false"; fi
(using itest.w or itest.b worked as expected even without this change)
Signed-off-by: Josh Radel
---
common/cmd_itest.c |
On Jun 10, 2011, at 4:57 AM, Kumar Gala wrote:
> The following changes since commit 9571865e0d32b1bcf8a6625497d1cd5d4bbad354:
>
> Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-08 23:29:04
> +0200)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-mpc8
Win $500,000 in Coca Cola Company @West Africa new year promo.To qualify,Email
the correct answer to the question given below to Mr. Frank Morris via
email:(mrfrankmorri...@live.com)
Question: Who won the 2010 FIFA World Cup in South Africa? (A)England (B)Spain
(C)Germany (D)Brazil.If you are su
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Philip Hands
> Sent: Wednesday, June 15, 2011 3:24 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] OpenRD Ultimate SATA & SD
>
> Hi,
Hi Phil
Thanks for the feedback.
>
> I'
Hi Grame,
On Wednesday 15 June 2011 06:12 PM, Graeme Russ wrote:
> On 15/06/11 22:04, Wolfgang Denk wrote:
>> Dear Aneesh V,
>>
>> In message<4df89102.9040...@ti.com> you wrote:
>>>
>>> Will you accept something like this?
>>>
>>> a_val = (reg& a_mask)>> a_shift;
>>
>> Yes, of course (that's wh
Hi Graeme,
On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote:
[snip]
>>
>> BTW should the deltas return a signed value?
>
> No - times are unsigned utilising the entire range of the u32 so (to -
> from) will always returned the unsigned delta, even if there is a wrap
> between them. I cannot ima
Hi Aneesh,
On Thu, Jun 16, 2011 at 3:39 PM, Aneesh V wrote:
> Hi Grame,
>
> On Wednesday 15 June 2011 06:12 PM, Graeme Russ wrote:
>>
>> On 15/06/11 22:04, Wolfgang Denk wrote:
>>>
>>> Dear Aneesh V,
>>>
>>> In message<4df89102.9040...@ti.com> you wrote:
Will you accept something like
Hi Simon,
On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote:
> [snip]
>>>
>>> BTW should the deltas return a signed value?
>>
>> No - times are unsigned utilising the entire range of the u32 so (to -
>> from) will always retur
71 matches
Mail list logo
