the address of dm9000 is 0x2800, it should be cs5, but in function
"mini2440_devices_init", it set the cs4 instead, why??
Yi Qingliang
Nanjing Jilong
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listin
On Wed, Dec 05, 2012 at 08:02:47PM +0100, Wolfram Sang wrote:
> It could happen (1 out of 100 times) that NAND did not start up
> correctly after warm rebooting, so barebox could not find its
> environment or DMA timed out due to a stalled BCH. When resetting BCH
> together with GPMI, the issue cou
It could happen (1 out of 100 times) that NAND did not start up
correctly after warm rebooting, so barebox could not find its
environment or DMA timed out due to a stalled BCH. When resetting BCH
together with GPMI, the issue could not be observed anymore. We probably
need the consistent state alre
I applied this series without the patches which allow to pass the /dev/
filename for the mci device for now. I still have the hope to find a
better solution for this. Being able to have persistent names, or at
least a way to specify 'load from this slot' is a worthwile goal, but
what I suggested r
On Wed, Dec 05, 2012 at 09:34:12AM -0500, Robert P. J. Day wrote:
>
> Add and use meaningful macro names for OMAP4 GPIO addresses, and add a
> comment to explain the 0x100 offset for OMAP4.
>
> Signed-off-by: Robert P. J. Day
Applied, thanks
Sascha
>
> ---
>
> diff --git a/arch/arm/mach-oma
On Wed, Dec 05, 2012 at 06:15:39PM +0100, Jan Luebbe wrote:
> Signed-off-by: Jan Luebbe
> ---
>
> This applies to the next branch (for-next/phylib).
Applied, thanks
Sascha
>
> drivers/net/phy/micrel.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ph
On Tue, Dec 04, 2012 at 06:17:30PM -0500, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
>
Applied, thanks
Sascha
> ---
>
> diff --git a/arch/arm/mach-omap/Kconfig b/arch/arm/mach-omap/Kconfig
> index 81f6127..b9f3dff 100644
> --- a/arch/arm/mach-omap/Kconfig
> +++ b/arch/arm/ma
On Tue, Dec 04, 2012 at 04:15:48PM -0500, Robert P. J. Day wrote:
>
> In addition, collapse adjacent comment blocks into one and remove
> extraneous blank lines.
>
> Signed-off-by: Robert P. J. Day
Applied, thanks
Sascha
>
> ---
>
> pretty much based on what nishanth suggested, compile te
On Wed, Dec 05, 2012 at 07:42:10PM +0100, Wolfram Sang wrote:
> On Wed, Dec 05, 2012 at 07:37:32PM +0100, Sascha Hauer wrote:
> > On Wed, Dec 05, 2012 at 03:53:53PM +0100, Wolfram Sang wrote:
> > > It could happen (1 out of 100 times) that NAND did not start up
> > > correctly after warm rebooting,
On Wed, Dec 05, 2012 at 02:39:29PM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> since 9d1bcab50454e06c74dc9fda42a05cd8a43265c6
> debug_ll: Let architectures define PUTC_LL directly
Sorry, missed at91. Applied.
Thanks
Sascha
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> ---
> arc
On Wed, Dec 05, 2012 at 07:37:32PM +0100, Sascha Hauer wrote:
> On Wed, Dec 05, 2012 at 03:53:53PM +0100, Wolfram Sang wrote:
> > It could happen (1 out of 100 times) that NAND did not start up
> > correctly after warm rebooting, so barebox could not find its
> > environment or DMA timed out due to
On Wed, Dec 05, 2012 at 03:53:53PM +0100, Wolfram Sang wrote:
> It could happen (1 out of 100 times) that NAND did not start up
> correctly after warm rebooting, so barebox could not find its
> environment or DMA timed out due to a stalled BCH. When resetting BCH
> together with GPMI, the issue cou
On Wed, Dec 05, 2012 at 03:42:42PM +0100, Wolfram Sang wrote:
> Pinmuxing was wrong and no GPMI device was created.
>
> Signed-off-by: Wolfram Sang
Applied, thanks
Sascha
> ---
> arch/arm/boards/karo-tx28/tx28.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a
On Wed, Dec 05, 2012 at 06:15:20PM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> via cdev we may write unaligned data the code was drop in the commit
> 0a4b1c7e440a81819eb2137f923573a3055dc7a2
> mtd core: call driver write function with complete buffer
>
> which is true for spi flashes but the
via cdev we may write unaligned data the code was drop in the commit
0a4b1c7e440a81819eb2137f923573a3055dc7a2
mtd core: call driver write function with complete buffer
which is true for spi flashes but the code is still mandatory on nand
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
drive
Signed-off-by: Jan Luebbe
---
This applies to the next branch (for-next/phylib).
drivers/net/phy/micrel.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 0c6d43e..ed5abf8 100644
--- a/drivers/net/phy/micrel.c
+++ b
On 20:03 Thu 29 Nov , Sascha Hauer wrote:
> mtd->write is supposed to loop around pages internally, no need
> to do this in mtd_write. This fixes a huge write performance drop
> with the m25p80 driver when it was converted to a mtd driver recently.
> Since mtd->writesize is 1 for this driver mt
It could happen (1 out of 100 times) that NAND did not start up
correctly after warm rebooting, so barebox could not find its
environment or DMA timed out due to a stalled BCH. When resetting BCH
together with GPMI, the issue could not be observed anymore. We probably
need the consistent state alre
Enrico Scholz
writes:
> Patch sets the ARM_NOUNALIGNED option introduced by a previous patch.
just for the record: difference between both aligned/unaligned variants
is
$ bloat-o-meter barebox barebox.unaligned
add/remove: 0/0 grow/shrink: 1/32 up/down: 4/-2648 (-2644)
function
Pinmuxing was wrong and no GPMI device was created.
Signed-off-by: Wolfram Sang
---
arch/arm/boards/karo-tx28/tx28.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boards/karo-tx28/tx28.c b/arch/arm/boards/karo-tx28/tx28.c
index a62cb82..6e8da15 100644
--- a
Add and use meaningful macro names for OMAP4 GPIO addresses, and add a
comment to explain the 0x100 offset for OMAP4.
Signed-off-by: Robert P. J. Day
---
diff --git a/arch/arm/mach-omap/include/mach/omap4-silicon.h
b/arch/arm/mach-omap/include/mach/omap4-silicon.h
index 71ffe39..008eafb 10064
On Wed, 5 Dec 2012, Sascha Hauer wrote:
> On Wed, Dec 05, 2012 at 07:54:51AM -0500, Robert P. J. Day wrote:
> >
> > i was going to submit a patch to replace magic constants for OMAP4
> > with more meaningful names but i ran into an oddity. here's
> > omap4-silicon.h:
> >
> > #define OMAP44XX_L4
since 9d1bcab50454e06c74dc9fda42a05cd8a43265c6
debug_ll: Let architectures define PUTC_LL directly
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
arch/arm/mach-at91/include/mach/debug_ll.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/include/mach
On Wed, 5 Dec 2012, Sascha Hauer wrote:
> On Wed, Dec 05, 2012 at 07:54:51AM -0500, Robert P. J. Day wrote:
> >
> > i was going to submit a patch to replace magic constants for OMAP4
> > with more meaningful names but i ran into an oddity. here's
> > omap4-silicon.h:
> >
> > #define OMAP44XX_L4
Sascha Hauer writes:
>> Coupling the -mno-unaligned-access to the TEXT_BASE and the used processor
>> might be a better solution.
>
> No, unaligned accesses are handled by the cache. They won't work when
> the MMU is disabled, but barebox has to work with MMU disabled.
ok; this stuff seems to be
On 12/04/2012 03:15 PM, Robert P. J. Day wrote:
In addition, collapse adjacent comment blocks into one and remove
extraneous blank lines.
Signed-off-by: Robert P. J. Day
At least for my files,
Acked-by: Nishanth Menon
Regards,
NM
___
barebox mail
On Wed, 5 Dec 2012, Sascha Hauer wrote:
> On Wed, Dec 05, 2012 at 07:54:51AM -0500, Robert P. J. Day wrote:
> >
> > i was going to submit a patch to replace magic constants for OMAP4
> > with more meaningful names but i ran into an oddity. here's
> > omap4-silicon.h:
> >
> > #define OMAP44XX_L4
On Wed, Dec 05, 2012 at 07:54:51AM -0500, Robert P. J. Day wrote:
>
> i was going to submit a patch to replace magic constants for OMAP4
> with more meaningful names but i ran into an oddity. here's
> omap4-silicon.h:
>
> #define OMAP44XX_L4_WKUP_BASE 0x4A30
> #define OMAP44XX_L4
i was going to submit a patch to replace magic constants for OMAP4
with more meaningful names but i ran into an oddity. here's
omap4-silicon.h:
#define OMAP44XX_L4_WKUP_BASE 0x4A30
#define OMAP44XX_L4_PER_BASE0x4800
and here's part of an old posting to the linux-
On Wed, Dec 05, 2012 at 12:33:26PM +0100, Enrico Scholz wrote:
> Sascha Hauer writes:
>
> >> config OMAP_BUILD_IFT
> >>prompt "build ift binary"
> >> + select ARM_NOUNALIGNED
> >
> > This needs more investigation. Coupling this to OMAP_BUILD_IFT does
> > not seem to be correct. Unaligned ac
On 04/12/2012 20:09, Robert Jarzmik wrote:
Renaud Barbier writes:
On 03/12/2012 19:17, Robert Jarzmik wrote:
Hi Renaud,
That's a really huge piece of a patchset.
Please tell me that almost 100% of the code was taken out of the linux
kernel. Even better, are there any patches in there that a
Enrico Scholz writes:
>>> commit b823fd9ba56d56e3cbb5b05e7a4815fb0914204a
>>> Author: Albert ARIBAUD
>>> Date: Tue Oct 9 09:28:15 2012 +
>>> ARM: prevent misaligned array inits
>> ...
>> This patch explicitely mentions char arrays initialized on the stack
>> like this:
>
> I do not kno
On Wed, Dec 05, 2012 at 12:28:45PM +0100, Wolfram Sang wrote:
> The rate is not constant as the comment said, but is hclk. The result
> was that MII clock was often calculated wrong.
Some more prosa would be good here:
The fec has multiple clock inputs:
- 50MHz clock for generating the (R)MII cl
On Wed, Dec 05, 2012 at 11:50:56AM +0100, Enrico Scholz wrote:
> Sascha Hauer writes:
>
> >> - asm volatile ("mrc p15, 0, %0, c6, c0, 0" : "=r" (far) : : "cc");
> >> -
> >> - printf("unable to handle %s at address 0x%08x\n",
> >> - far < PAGE_SIZE ? "NULL pointer dereferenc
Sascha Hauer writes:
>> config OMAP_BUILD_IFT
>> prompt "build ift binary"
>> +select ARM_NOUNALIGNED
>
> This needs more investigation. Coupling this to OMAP_BUILD_IFT does
> not seem to be correct. Unaligned accesses work for cached memory once
> the MMU is enabled,
It depends on the
The rate is not constant as the comment said, but is hclk. The result
was that MII clock was often calculated wrong.
Reported-by: Michael Grzeschik
Signed-off-by: Wolfram Sang
---
arch/arm/mach-mxs/speed-imx28.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/m
Sascha Hauer writes:
>> -asm volatile ("mrc p15, 0, %0, c6, c0, 0" : "=r" (far) : : "cc");
>> -
>> -printf("unable to handle %s at address 0x%08x\n",
>> -far < PAGE_SIZE ? "NULL pointer dereference" :
>> -"paging request", far);
>> +if (!IS_
On Tue, Dec 04, 2012 at 01:02:49PM +0100, Enrico Scholz wrote:
> MLO is located in SRAM and OMAP4 does not allow unaligned access in
> this area:
>
> | :/ md -w 0x4030+2
> | 4030: 9001 ..
> | :/ md -w 0x4031+2
> | unable to handle paging re
On Tue, Dec 04, 2012 at 01:04:03PM +0100, Enrico Scholz wrote:
> It is often very useful to get more details about a data abort. Patch
> decodes the "Data Fault Status Register" (DFSR) and because this
> enlarges barebox a little bit, a Kconfig option was added to disable
> this feature on demand.
On Tue, Dec 04, 2012 at 01:04:25PM +0100, Enrico Scholz wrote:
> due to missing/misplaced boundary check, deleting characters could
> underflow the password buffer.
>
> Signed-off-by: Enrico Scholz
Applied, thanks
Sascha
> ---
> common/password.c | 13 -
> 1 file changed, 8 insert
On Tue, Dec 04, 2012 at 12:54:22PM -0500, Robert P. J. Day wrote:
>
> Based on following lines in omap3-silicon.h:
Applied, thanks
Sascha
>
> #define OMAP_L4_WKUP_BASE 0x4830
> #define OMAP_L4_PER_BASE0x4900
> ... snip ...
> #define OMAP_GPIO1_BASE (OMAP_L4_WKUP_B
41 matches
Mail list logo
