On 22:55 Thu 06 Nov , Stelian Pop wrote:
> Le jeudi 06 novembre 2008 à 20:29 +0100, Jean-Christophe
> PLAGNIOL-VILLARD a écrit :
> > On 18:07 Tue 21 Oct , Stelian Pop wrote:
> > > Introduce AT91_CPU_CLOCK and use it for displaying the CPU
> > > speed in the LCD driver.
> > >
> > > Also mak
On 22:55 Thu 06 Nov , Stelian Pop wrote:
> Le jeudi 06 novembre 2008 à 20:27 +0100, Jean-Christophe
> PLAGNIOL-VILLARD a écrit :
> > On 18:07 Tue 21 Oct , Stelian Pop wrote:
> > > At least some (old ?) versions of the AT91Bootstrap do not set up the
> > > PLLB correctly to 48 MHz in order t
> Dear Jens Scharsig,
>
> In message <[EMAIL PROTECTED]> you wrote:
>> the board speaks to me.
>
> A patch, a patch - submit a patch, please.
>
> Best regards,
>
> Wolfgang Denk
>
Dear Wolfgang Denk,
I can do this in few weeks. But I have only our costum board. So I can't
test the interaktio
Hi , I'm using ppc440EP and using u-boot( git version )
I have a ploblem in using usb 1.1 host , in my board(has not CPLD)
I wanna using USB1.1 Host , and not using USB2.2
But usb1.1 Host is not working , when usb device is connected Kernel prints
-62 err messages
How can I Slove it?
Best Regar
On Tue, 4 Nov 2008 16:37:45 -0800
Ron Madrid <[EMAIL PROTECTED]> wrote:
> This patch will create a new board, SIMPC8313, from Sheldon Instruments. This
> board boots from NAND devices and is configurable for either a large page or
> small page device.
>
> Signed-off-by: Ron Madrid <[EMAIL PROTE
On Nov 6, 2008, at 2:04 PM, Jon Loeliger wrote:
> On Wed, 2008-11-05 at 14:55 -0600, Becky Bruce wrote:
>> The memory map on the 8641hpcn is modified to look more like
>> the 85xx boards; this is a step towards a more standardized
>> layout going forward. As part of this change, we now relocate
>
This patch creates a memory map with all the devices
in 36-bit physical space, in addition to the 32-bit map.
The CCSR relocation is moved (again, sorry) to
allow for the physical address to be 36 bits - this
requires translation to be enabled. With 36-bit physical
addressing enabled, we are no lo
The memory map on the 8641hpcn is modified to look more like
the 85xx boards; this is a step towards a more standardized
layout going forward. As part of this change, we now relocate
the flash.
The regions for some of the mappings were far larger than they
needed to be. I have reduced the mapping
On Nov 6, 2008, at 4:30 PM, Jon Loeliger wrote:
> On Thu, 2008-11-06 at 16:16 -0600, Scott Wood wrote:
>> Becky Bruce wrote:
>>> We *do* need a comment in the release notes for this revision of u-
>>> boot
>>> that the map for 8641 has changed so it doesn't catch anyone by
>>> surprise.
>>
>>
On Thu, 2008-11-06 at 16:16 -0600, Scott Wood wrote:
> Becky Bruce wrote:
> > We *do* need a comment in the release notes for this revision of u-boot
> > that the map for 8641 has changed so it doesn't catch anyone by surprise.
>
> How about a runtime check in the board fdt code to print a warnin
Becky Bruce wrote:
> On Nov 6, 2008, at 4:16 PM, Scott Wood wrote:
>> How about a runtime check in the board fdt code to print a warning if
>> it finds an old device tree? Unfortunately, using new dts with old
>> u-boot isn't as easy to detect.
>
> Where exactly were you thinking this would go?
On Nov 6, 2008, at 4:16 PM, Scott Wood wrote:
> Becky Bruce wrote:
>> We *do* need a comment in the release notes for this revision of u-
>> boot that the map for 8641 has changed so it doesn't catch anyone
>> by surprise.
>
> How about a runtime check in the board fdt code to print a warning
Becky Bruce wrote:
> We *do* need a comment in the release notes for this revision of u-boot
> that the map for 8641 has changed so it doesn't catch anyone by surprise.
How about a runtime check in the board fdt code to print a warning if it
finds an old device tree? Unfortunately, using new dt
On Nov 6, 2008, at 2:04 PM, Jon Loeliger wrote:
> On Wed, 2008-11-05 at 14:55 -0600, Becky Bruce wrote:
>> The memory map on the 8641hpcn is modified to look more like
>> the 85xx boards; this is a step towards a more standardized
>> layout going forward. As part of this change, we now relocate
>
On Nov 6, 2008, at 1:28 PM, Scott Wood wrote:
> Becky Bruce wrote:
>> The memory map on the 8641hpcn is modified to look more like
>> the 85xx boards; this is a step towards a more standardized
>> layout going forward. As part of this change, we now relocate
>> the flash.
>> The regions for some
On Nov 6, 2008, at 3:59 PM, Scott Wood wrote:
> Becky Bruce wrote:
>> We don't want PHYS_64BIT on unconditionally. It has the effect of
>> moving all the devices into high physical memory, which means you
>> need a different Linux/dts.
>
> Another reason we should really be packaging the dev
Becky Bruce wrote:
> We don't want PHYS_64BIT on unconditionally. It has the effect of
> moving all the devices into high physical memory, which means you need a
> different Linux/dts.
Another reason we should really be packaging the device trees with u-boot.
> I expect the normal case to be
Le jeudi 06 novembre 2008 à 20:27 +0100, Jean-Christophe
PLAGNIOL-VILLARD a écrit :
> On 18:07 Tue 21 Oct , Stelian Pop wrote:
> > At least some (old ?) versions of the AT91Bootstrap do not set up the
> > PLLB correctly to 48 MHz in order to make USB host function correctly.
> >
> > This patch
Le jeudi 06 novembre 2008 à 20:29 +0100, Jean-Christophe
PLAGNIOL-VILLARD a écrit :
> On 18:07 Tue 21 Oct , Stelian Pop wrote:
> > Introduce AT91_CPU_CLOCK and use it for displaying the CPU
> > speed in the LCD driver.
> >
> > Also make AT91_MAIN_CLOCK and AT91_MASTER_CLOCK reflect the
> > cor
On Nov 6, 2008, at 3:06 PM, Scott Wood wrote:
> Becky Bruce wrote:
>> This will enable CONFIG_PHYS_36BIT for MPC8641HPCN.
>> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
>> ---
>> Makefile |8 +++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>> diff --git a/Makefile b/Makefile
>>
Becky Bruce wrote:
> This will enable CONFIG_PHYS_36BIT for MPC8641HPCN.
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
> ---
> Makefile |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 983a3cd..09e671d 100644
> --- a/Makefile
>
On 12:48 Wed 05 Nov , Juergen Schoew wrote:
> Hi U-Boot mailling list,
>
> This patchset adds a new ARM board with the NXP PNX8181 cpu to u-boot.
> The PNX8181 is an ARM926ej with an internal DSP (mostly used for Audio
> processing and VOIP codecs) and a baseband processor (used for DECT). The
On Wed, 2008-11-05 at 14:55 -0600, Becky Bruce wrote:
> The memory map on the 8641hpcn is modified to look more like
> the 85xx boards; this is a step towards a more standardized
> layout going forward. As part of this change, we now relocate
> the flash.
>
> The regions for some of the mappings w
Hi Wolfgang,
Please pull the following changes since commit
3ec53148eb68ddfb0c3311fb4c06cd2bd0ef3eeb:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-nand-flash
are available in the git repository at:
git://git.denx.de/u-boot-at91.git master
Jean-Christ
On 18:07 Tue 21 Oct , Stelian Pop wrote:
> Introduce AT91_CPU_CLOCK and use it for displaying the CPU
> speed in the LCD driver.
>
> Also make AT91_MAIN_CLOCK and AT91_MASTER_CLOCK reflect the
> corresponding board clocks.
>
> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
> ---
> common/lcd
On 18:08 Tue 21 Oct , Stelian Pop wrote:
> AT91_BASE_EMAC is never used outside the board specific files,
> so replace its usage by the board specific AT91xxx_BASE_EMAC.
>
> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
> ---
> board/atmel/at91cap9adk/at91cap9adk.c |2 +-
> board/atm
On 18:08 Tue 21 Oct , Stelian Pop wrote:
> AT91_ID_US0 / AT91_ID_US1 / AT91_ID_US2 were used but never defined.
> Since they are never used outside the board specific files, they can
> be replaced by the board specific AT91xxx_ID_US0 / AT91xxx_ID_US1 /
> AT91xxx_ID_US2.
>
> Bug spotted by Jesu
Becky Bruce wrote:
> The memory map on the 8641hpcn is modified to look more like
> the 85xx boards; this is a step towards a more standardized
> layout going forward. As part of this change, we now relocate
> the flash.
>
> The regions for some of the mappings were far larger than they
> needed t
On 18:07 Tue 21 Oct , Stelian Pop wrote:
> At least some (old ?) versions of the AT91Bootstrap do not set up the
> PLLB correctly to 48 MHz in order to make USB host function correctly.
>
> This patch sets up the PLLB to the same values Linux uses, and makes USB
> work ok on the following CPUs
Dear Jens Scharsig,
In message <[EMAIL PROTECTED]> you wrote:
>
> the board speaks to me.
A patch, a patch - submit a patch, please.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzel
Dear Jens Scharsig,
In message <[EMAIL PROTECTED]> you wrote:
>
> I am a little bit confused. We have designed a new AT91RM9200 based
> board. It should boot from 16-bit NOR Flash. I have read many relevant
> article in the forum, but I don't know , which board should I use as a
> base. I have lo
Corrected endian order printing for compact flash serial number.
Signed-off-by: Richard Retanubun <[EMAIL PROTECTED]>
---
common/cmd_ide.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 2564c2b..db05f76 100644
--- a/common/
This will enable CONFIG_PHYS_36BIT for MPC8641HPCN.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
Makefile |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 983a3cd..09e671d 100644
--- a/Makefile
+++ b/Makefile
@@ -2436,8 +2436,14 @@ TQ
On 17:52 Tue 04 Nov , [EMAIL PROTECTED] wrote:
> Subject: [PATCH-OMAP3] OMAP3: Introduce CONFIG_OMAP3_MMC
>
> From: Dirk Behme <[EMAIL PROTECTED]>
>
> Introduce CONFIG_OMAP3_MMC as proposed by Kyungmin Park.
>
> Signed-off-by: Dirk Behme <[EMAIL PROTECTED]>
>
> ---
> drivers/mmc/Makefile
This patch adds support for the PM9263 board of Ronetix GmbH (www.ronetix.at)
Signed-off-by: Ilko Iliev <[EMAIL PROTECTED]>
---
MAKEALL |1 +
Makefile|3 +
board/ronetix/pm9263/Makefile | 60
boar
On Thu, Nov 06, 2008 at 08:59:06AM +0530, Amit Kumar Sharma wrote:
> We can provide two device registration for SLC and MLC are
> but I don't know how useful it is because FlexOneNand
> provides boundary settings and user can configure SLC and
> MLC area and other point is still device registra
On Thu, 6 Nov 2008 15:30:38 +0100
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote:
> On 15:04 Thu 06 Nov , Gary Jennejohn wrote:
> >
> > Modifications to support console multiplexing. This is controlled using
> > CONFIG_SYS_CONSOLE_MUX in the board configuration file.
> >
> > Thi
Dear Jean,
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:29 Wed 05 Nov , Ilko Iliev wrote:
>
>> Dear Jean,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>
>>> On 12:45 Tue 28 Oct , Ilko Iliev wrote:
>>>
>>>
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-
Dear Jean,
Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:29 Wed 05 Nov , Ilko Iliev wrote:
>
>> Dear Jean,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>
>>> On 12:45 Tue 28 Oct , Ilko Iliev wrote:
>>>
>>>
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-
On 15:04 Thu 06 Nov , Gary Jennejohn wrote:
>
> Modifications to support console multiplexing. This is controlled using
> CONFIG_SYS_CONSOLE_MUX in the board configuration file.
>
> This allows a user to specify multiple console devices in the environment
> with a command like this: setenv s
Modifications to support console multiplexing. This is controlled using
CONFIG_SYS_CONSOLE_MUX in the board configuration file.
This allows a user to specify multiple console devices in the environment
with a command like this: setenv stdin serial,nc. As a result, the user can
enter text on bot
As space expands, so does the software. Today the kernel with built-in
initramfs image is likely to not fit into 8MB limit. It feels safe to
increase BOOTMAPSZ to 16MB, since the Linux actually maps 16MB on 6xx
PPCs (two BATs, 8MB each).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
p.s.
> for your own) You can resolve this by editing two lines in the start.S
> file of the ARM920T cpu specific directory. In version 2008.10 its line
> 181 you can delete this, or change to ifdef, and again in line 264 you
> can either delete the if statement, or just make it branch to the
> lowle
Jens Scharsig wrote:
> Hello,
>
> I am a little bit confused. We have designed a new AT91RM9200 based
> board. It should boot from 16-bit NOR Flash. I have read many relevant
> article in the forum, but I don't know , which board should I use as a
> base. I have look at the actual source (2008.10 a
Hello,
I am a little bit confused. We have designed a new AT91RM9200 based
board. It should boot from 16-bit NOR Flash. I have read many relevant
article in the forum, but I don't know , which board should I use as a
base. I have look at the actual source (2008.10 and git), and I think,
u-boot can
On Thursday 06 November 2008, Kyungmin Park wrote:
> >> > + ret = mtd->read_oob(mtd, ofs, &ops);
> >> > + if (ret) {
> >> > + printk("Read failed 0x%x, %d", (unsigned int) ofs,
> >> > ret); + mtd->block_markbad(mtd, ofs);
> >
> > You are marki
Dear Jared,
In message <[EMAIL PROTECTED]> you wrote:
>
> We are a consulting firm that has produced a product for a client which
> contains at Atmel AT91SAM9263 running linux. I have registed a machine
> type at kernel.org and have ported both u-boot and the kernel to it. I
> have created pat
Dear Pink Boy,
In message <[EMAIL PROTECTED]> you wrote:
>
> Okay then. I was able to compile u-boot 1.3.4 for the AT91RM9200DK
> with changes so that it can handle writing to the flash on my custom
> board base don the AT91RM9200EK.
Great.
> Seems to work but writes to flash are very slow..
49 matches
Mail list logo
