Felix,
On Thursday 23 October 2008, Felix Radensky wrote:
> I had the same problem with u-boot-1.3.4 on custom 460EX board with
> registered SODIMM. The SPD code in 4xx_spd_ddr2.c (program_copt1())
> checks two SPD fields to decide whether DIMM is registered: DDRII DIMM
> type (offset 20) and SDR
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/configs/MPC8610HPCD.h |1 +
include/configs/MPC8641HPCN.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h
index 678e1e1..0492274 100644
--- a/include
Hi, Stefan
Stefan Roese wrote:
> Felix,
>
> On Thursday 23 October 2008, Felix Radensky wrote:
>
>> I had the same problem with u-boot-1.3.4 on custom 460EX board with
>> registered SODIMM. The SPD code in 4xx_spd_ddr2.c (program_copt1())
>> checks two SPD fields to decide whether DIMM is regi
On Wed, 22 Oct 2008, Kyungmin Park wrote:
> Move machine specific code to smdk6400.
> Some board use OneNAND instead of NAND.
>
> Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
> ---
> diff --git a/board/samsung/smdk6400/lowlevel_init.S
> b/board/samsung/smdk6400/lowlevel_init.S
> index e0119a
This patch series adds the ability to support 64-bit PCI addresses as well
as refactors the fsl_pci_init code and cleans up its users.
Finally it adds some help functions that the board code calls to set
dma-ranges in device trees.
If the particular maintainers could ack the patches that would be
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/pci/fsl_pci_init.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 564459c..b5d868f 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/dri
Converted ATUM8548, MPC8536DS, MPC8544DS, MPC8548CDS, MPC8568MDS,
MPC8572DS, TQM85xx, and SBC8548 to use fsl_pci_setup_inbound_windows()
and ft_fsl_pci_setup().
With these changes the board code is a bit smaller and we get dma-ranges
set in the device tree for these boards.
Signed-off-by: Kumar G
On Thu, Oct 23, 2008 at 4:39 PM, Guennadi Liakhovetski <[EMAIL PROTECTED]>
wrote:
> On Wed, 22 Oct 2008, Kyungmin Park wrote:
>
>> Move machine specific code to smdk6400.
>> Some board use OneNAND instead of NAND.
>>
>> Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
>> ---
>> diff --git a/board/
Use do_div in TICK_TO_TIME in order to get the code through the
compiler when CONFIG_MX31_CLK32 is 32768.
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
This is a quick patch to get the i.MX31 PDK patch to compile.
If someone has a better solution to this problem please submit a
patch that c
Add support for the Freescale i.MX31 PDK (a.k.a 3DS) board. Ethernet and
MC13873 RTC support is enabled by this patch.
Booting from NAND is not supported yet so U-boot relies on some other
initial boot loader to set up SDRAM and clocks and copying U-boot to SDRAM.
Signed-off-by: Magnus Lilja <[EM
On Thu, 23 Oct 2008, Kyungmin Park wrote:
> > (1 << 0) - ignored, default 0, so, better set it to 0
> > | (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0
> > | (1 << 2) - ignored, default 0, so, better set it to 0
> > | (1 << 3) - set Xm0CSn[3] to SROMC CS3
> >
> > So, we should just write
Dear Tsi-Chung Liew,
In message <[EMAIL PROTECTED]> you wrote:
> From: TsiChung Liew <[EMAIL PROTECTED]>
>
> Will use mcfmii.c driver in drivers/net rather than
> keep creating new mii.c for each future platform.
> Remove EB+MCF-EV123, cobra5272, idmr and M5235EVB's mii.c
>
> Signed-off-by: TsiC
Dear Kyungmin Park,
In message <[EMAIL PROTECTED]> you wrote:
> To give more code at lowlevel_init at each boards
Can you please describe exactly what thgis patch is supposed to do and
what problem it is supposed to fix?
I cannot make heads nor tails from your descritpion, sorry.
Best regards,
> Yes, I confirmed with the schematics. There is a 32768kHz crystal connected
> to the PMIC that drives the MX31 clock.
>
> Regards,
>
> Fabio Estevam
>
>> I haven't tried my new patch on real hardware yet, but
>> I'll do that
>> tomorrow and post a patch (without the do_div() fix though,
>> perha
Dear Guennadi Liakhovetski,
In message <[EMAIL PROTECTED]> you wrote:
>
> 2. While at it, we could fix the value being written to the MEM_SYS_CFG
>register too. Currently it writes 0xd =
>
> (1 << 0) - ignored, default 0, so, better set it to 0
> | (0 << 1) - set Xm0CSn[2] to OneNANDC CS
On Thu, Oct 23, 2008 at 5:00 PM, Guennadi Liakhovetski <[EMAIL PROTECTED]>
wrote:
> On Thu, 23 Oct 2008, Kyungmin Park wrote:
>
>> > (1 << 0) - ignored, default 0, so, better set it to 0
>> > | (0 << 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0
>> > | (1 << 2) - ignored, default 0, so, better
Dear Kumar Gala,
In message <[EMAIL PROTECTED]> you wrote:
> This patch series adds the ability to support 64-bit PCI addresses as well
> as refactors the fsl_pci_init code and cleans up its users.
>
> Finally it adds some help functions that the board code calls to set
> dma-ranges in device tre
On Thursday 23 October 2008, Felix Radensky wrote:
> >> I've changed
> >>
> >> if ((attribute & 0x02) == 0x00)
> >>
> >> to be
> >>
> >> if (((attribute & 0x02) == 0x00) && (attribute != 0x04))
> >
> > Why did you change it this way? Which DDR2 module are you using? And
> > what's the value of SPD
On Thu, Oct 23, 2008 at 5:09 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Kyungmin Park,
>
> In message <[EMAIL PROTECTED]> you wrote:
>> To give more code at lowlevel_init at each boards
>
> Can you please describe exactly what thgis patch is supposed to do and
> what problem it is supposed
On Thu, 23 Oct 2008, Kyungmin Park wrote:
> >> In OneNAND board, it should be set as 0x1002
> >
> > Sorry, do not understand what "it." If you mean the MEM_SYS_CFG then I
> > also don't understand this. As I quoted from the datasheet above, bit 1
> > set to 0 (0 << 1) is for _both_ - NAND or OneNA
On Thu, Oct 23, 2008 at 5:42 PM, Guennadi Liakhovetski <[EMAIL PROTECTED]>
wrote:
> On Thu, 23 Oct 2008, Kyungmin Park wrote:
>
>> >> In OneNAND board, it should be set as 0x1002
>> >
>> > Sorry, do not understand what "it." If you mean the MEM_SYS_CFG then I
>> > also don't understand this. As I
Dear Guennadi Liakhovetski,
In message <[EMAIL PROTECTED]> you wrote:
>
> > > + /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */
> >
> > Right, and also add OneNAND & NFCON is depends on XNANDSEL.
>
> In the datasheet this signal is called XSELNAND. And I don't think we
On Thu, 23 Oct 2008, Kyungmin Park wrote:
> >> S3C64XX_MEM_SYS_CFG_NAND0x0008
> >> S3C64XX_MEM_SYS_CFG_ONENAND 0x1000
> >
> > ? I asked above what the bus width has to do with OneNAND selection,
> > you didn't reply.
>
> OneNAND has always 16-bit butwidth. there's no exception.
Ok, t
On Thu, 23 Oct 2008, Wolfgang Denk wrote:
> Dear Guennadi Liakhovetski,
>
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > > + /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3
> > > > */
> > >
> > > Right, and also add OneNAND & NFCON is depends on XNANDSEL.
> >
> >
The following changes since commit d9d8c7c696dec370ca714c03beb6e79d4c90bd5e:
Wolfgang Denk (1):
Fix strmhz(): avoid printing negative fractions
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Ben Maan (1):
Blackfin: fix port mux defines
Dear "Kyungmin Park",
In message <[EMAIL PROTECTED]> you wrote:
> On Thu, Oct 23, 2008 at 5:09 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> > Dear Kyungmin Park,
> >
> > In message <[EMAIL PROTECTED]> you wrote:
> >> To give more code at lowlevel_init at each boards
> >
> > Can you please descri
Dear Guennadi Liakhovetski,
In message <[EMAIL PROTECTED]> you wrote:
>
> > Hey, actually I do think that describing which hardware configurations
> > the software performs is a Good Thing (TM).
>
> Exactly, "which hardware configurations the software performs", XSELNAND
> is not performed in s
On Thu, 23 Oct 2008, Wolfgang Denk wrote:
> Dear Guennadi Liakhovetski,
>
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > Hey, actually I do think that describing which hardware configurations
> > > the software performs is a Good Thing (TM).
> >
> > Exactly, "which hardware configuration
Hi guys,
I'm facing problems when I try to erase flash memory on my embedded board (it's
a custom Mainstone board, based on PXA270 ).
I'm using u-boot 1.1.4 (since it is the only version with patch for Mainstone),
"Protect off" seems to work ok:
> protect off 1:7
> Un-Protect Flash Sector 7-7
Hi List,
Just updated my kilauea to top of git (2008.10-00092-gd9d8c7c) and am
seeing odd crashes:
- sometimes u-boot comes up normally, but printenv displays random
crap.
- sometimes I get machine checks such as here [1].
- sometimes it resets without any message at all.
The major visib
Dear Francesco,
In message <[EMAIL PROTECTED]> you wrote:
>
> I'm facing problems when I try to erase flash memory on my embedded
> board (it's a custom Mainstone board, based on PXA270 ).
> I'm using u-boot 1.1.4 (since it is the only version with patch for
> Mainstone),
You are using a very o
Replease the "spinning wheel" eye candy by printing a simple row of
dots. This avoids problems with control charactersin log files etc.
Also, it saves a few bytes.
Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
---
board/esd/common/cmd_loadpci.c |4 +---
board/esd/pci405/cmd_pci405.
This time I took a closer look at img2brec.sh. My conclusions are
img2brec.sh was done for development under Windows (probably cygwin), as
it uses a command filesize which is not available as such under Unix. Therefore
I replaced with a functional equivalent (wc --bytes) which should also work
und
Hi Markus,
On Thursday 23 October 2008, Markus Klotzbücher wrote:
> Just updated my kilauea to top of git (2008.10-00092-gd9d8c7c) and am
> seeing odd crashes:
Is this a 600MHz Kilauea? This is a known issue, that the new autocalibration
code has a problem here. I reported this problem a few wee
Replace the "spinning wheel" eye candy by printing a simple row of
dots. This avoids problems with control charactersin log files etc.
Also, it saves a few bytes.
Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
---
This patch version fixes a few typos and also gets rid of a few now
unused vari
Replace the "spinning wheel" eye candy by printing a simple row of
dots. This avoids problems with control charactersin log files etc.
Also, it saves a few bytes.
Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
---
Hey, seems I'm heading for the record of submitting the maximum
number of patch
Dear Stefan,
In message <[EMAIL PROTECTED]> you wrote:
>
> Is this a 600MHz Kilauea? This is a known issue, that the new autocalibration
No, this is a CPU Rev. A board at 400 Mhz.
> code has a problem here. I reported this problem a few weeks ago. AMCC is
> currently working on a fix for this.
Hi Wolfgang,
On Thursday 23 October 2008, Wolfgang Denk wrote:
> Replace the "spinning wheel" eye candy by printing a simple row of
> dots. This avoids problems with control charactersin log files etc.
>
> Also, it saves a few bytes.
>
> Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
> ---
> H
Hi Wolfgang,
On Thursday 23 October 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Is this a 600MHz Kilauea? This is a known issue, that the new
> > autocalibration
>
> No, this is a CPU Rev. A board at 400 Mhz.
Probably with the same DDR2 frequency.
> > code has a pr
Dear Stefan,
In message <[EMAIL PROTECTED]> you wrote:
>
> We need the ACK from esd (Matthias) for this esd specific change. He is on
> vacation right now. I suggest that you split this patch so that we can apply
> the ppc4xx specific part directly.
Let's just wait until he's back from vacatio
Dear Stefan,
In message <[EMAIL PROTECTED]> you wrote:
>
> > Should we not backout the autocalib patches that cause the problem
> > until a stable working solution is found?
>
> Not sure. My hope is that AMCC find a solution quickly. They should receive
> the failing board this week.
>
> And t
Hello,
I'd like to switch to the new FIT image format, but I am at a loss at
how to use it.
Is there a documentation available somewhere or could someone tell me
the steps necessary?
I got as far as compiling a .its and got a .itb file but I do not know
what to do with it, how to append data or l
Hello,
I want to use Uboot on a Gateworks Cambria Board. This board includes an
IXP430 CPU. Uboot is already running, but I have some problems getting
Ethernet to work. All the NPE stuff, in Uboot, is based on IXP400 SW
Release version 2.0 which doesn't support the IXP43X MCU NPEs. So what
do
Bernhard Weirich wrote:
> Hello,
>
> I'd like to switch to the new FIT image format, but I am at a loss at
> how to use it.
> Is there a documentation available somewhere or could someone tell me
> the steps necessary?
Hello Bernhard,
FIT image format usage is documented in the doc/uImage.FIT/ d
Kumar Gala wrote:
> Add helper functions to return top level #size-cell and #address-cell info
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> include/fdt_support.h | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/include/fdt_support.h b/i
On Oct 23, 2008, at 3:35 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <[EMAIL PROTECTED]
> > you wrote:
>> This patch series adds the ability to support 64-bit PCI addresses
>> as well
>> as refactors the fsl_pci_init code and cleans up its users.
>>
>> Finally it adds some help
Hi Wolfgang,
On Thursday 23 October 2008, Wolfgang Denk wrote:
> > > Should we not backout the autocalib patches that cause the problem
> > > until a stable working solution is found?
> >
> > Not sure. My hope is that AMCC find a solution quickly. They should
> > receive the failing board this wee
On Oct 23, 2008, at 6:55 AM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> Add helper functions to return top level #size-cell and #address-
>> cell info
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>> ---
>> include/fdt_support.h | 18 ++
>> 1 files changed, 18 insertions(+
Kumar Gala wrote:
>
> On Oct 23, 2008, at 6:55 AM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> Add helper functions to return top level #size-cell and #address-cell
>>> info
>>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>>> ---
>>> include/fdt_support.h | 18 ++
>>> 1
On 13:42 Thu 23 Oct , Mirko D. wrote:
> Hello,
>
> I want to use Uboot on a Gateworks Cambria Board. This board includes an
> IXP430 CPU. Uboot is already running, but I have some problems getting
> Ethernet to work. All the NPE stuff, in Uboot, is based on IXP400 SW
> Release version 2.0
On Thu, Oct 23, 2008 at 01:30:08PM +0200, Stefan Roese wrote:
> Hi Wolfgang,
>
> On Thursday 23 October 2008, Wolfgang Denk wrote:
> > > > Should we not backout the autocalib patches that cause the problem
> > > > until a stable working solution is found?
> > >
> > > Not sure. My hope is that AMCC
Hi,
This serie of patches was rebased to adds support to iMX31PDK board to
boot directly from NAND.
Notice these patches don't add support to MTD NAND Flash support to U-Boot
(like reading and saving environment parameters in Flash because MTD NAND Flash
driver still needs further revision).
_
iMX31 NAND Flash Controller has a 2KB RAM buffer, but the
current start.S file is too much big to let NAND copy routine
to fit in. This patch will reduce the start.S when booting from
NAND Flash.
Signed-off-by: Alan Carvalho de Assis <[EMAIL PROTECTED]>
---
cpu/arm1136/start.S | 24
This code is executed from internal 2KB NAND Flash Controller RAM buffer
and will copy the remaining U-Boot code from NAND Flash verifying its
bad blocks (case it exists).
Signed-off-by: Alan Carvalho de Assis <[EMAIL PROTECTED]>
---
cpu/arm1136/mx31/Makefile |2 +
cpu/arm1136/mx3
This patch adds support to iMX31PDK board to boot directly from NAND
Flash. In order to it works the previous patches (which reduces start.S
size and copy NAND code to RAM) need be applied first.
Signed-off-by: Alan Carvalho de Assis <[EMAIL PROTECTED]>
---
board/freescale/mx31pdk/lowlevel_init.S
"Ben Warren" <[EMAIL PROTECTED]> wrote:
> > Oh. I was kind of planning to apply this to the avr32 tree after people
> > has had some time to look at it.
> >
> > But thanks for taking the two net patches.
>
>
> Git should figure this out right? If not, I can back them off and add a
> SOB.
I do
On Thursday 23 October 2008, Markus Klotzbücher wrote:
> > Unfortunately it didn't fix all problems. AMCC already provided another
> > patch for testing purposes. Not to the list but to me (and you) directly.
> > Please find it attached again. Would be great if Markus could test it on
> > the faili
Add helper functions to return find a node and return it's property
or a default value.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
common/fdt_support.c | 27 +++
include/fdt_support.h |2 ++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/comm
Added fdt_pci_dma_ranges() that parses the pci_region info from the
struct pci_controller and populates the dma-ranges based on it.
The max # of windws/dma-ranges we support is 3 since on embedded
PowerPC based systems this is the max number of windows.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED
>>>
>>> Hi Kumar,
>>>
>>> What about collapsing the two above into a common function?
>>>
>>>fdt_addrcell(blob);
>>> becomes
>>>fdt_get_prop_u32(blob, "/", "#address-cells", 1);
>>> and
>>>fdt_sizecell(blob);
>>> becomes
>>>fdt_get_prop_u32(blob, "/", "#size-cells", 1);
>>>
>>>
Kumar Gala wrote:
> Add helper functions to return find a node and return it's property
> or a default value.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> common/fdt_support.c | 27 +++
> include/fdt_support.h |2 ++
> 2 files changed, 29 insertions(+),
Copied over the fixed PHY driver as used in pp4xx/4xx_enet.c.
This adds support for PHY-less MAC connections to the UEC.
Signed-off-by: Richard Retanubun <[EMAIL PROTECTED]>
---
drivers/qe/uec_phy.c | 79 ++
1 files changed, 79 insertions(+), 0 de
Kumar Gala wrote:
> Added fdt_pci_dma_ranges() that parses the pci_region info from the
> struct pci_controller and populates the dma-ranges based on it.
>
> The max # of windws/dma-ranges we support is 3 since on embedded
> PowerPC based systems this is the max number of windows.
>
> Signed-off-
Signed-off-by: Dave Liu <[EMAIL PROTECTED]>
---
include/configs/MPC8536DS.h |8
include/configs/MPC8572DS.h | 10 --
2 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 38be10d..dbddb63 100644
--- a/
The 8572 DDR erratum1:
DDR controller may enter an illegal state when operating
in 32-bit bus mode with 4-beat bursts.
Description:
When operating with a 32-bit bus, it is recommended that
DDR_SDRAM_CFG[8_BE] is cleared when DDR2 memories are used.
This forces the DDR controller to use 4-beat burs
Signed-off-by: Dave Liu <[EMAIL PROTECTED]>
---
include/configs/MPC8610HPCD.h |9 -
include/configs/MPC8641HPCN.h | 11 ---
2 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h
index 678e1e1..d92bed9 100
Hi
Looks like there is a buffer allocation error in the packet buffer for the
xilinx emaclite.
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 88cd0f9..0e96ef1 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -70,7 +70,7 @@ typed
Copied over the fixed PHY driver as used in pp4xx/4xx_enet.c.
This adds support for PHY-less MAC connections to the UEC.
Signed-off-by: Richard Retanubun <[EMAIL PROTECTED]>
---
Documentation change only:
Same patch as before, now with a board configuration file example that
actually applies to UE
The patch is following the commit 392438406041415fe64ab8748ec5ab5ad01d1cf7
mpc86xx: use r4 instead of r2 in lock_ram_in_cache and unlock_ram_in_cache
This is needed in unlock_ram_in_cache() because it is called from C and
will corrupt the small data area anchor that is kept in R2.
lock_ram_in_ca
On Oct 23, 2008, at 8:59 AM, Dave Liu wrote:
> The patch is following the commit
> 392438406041415fe64ab8748ec5ab5ad01d1cf7
>
> mpc86xx: use r4 instead of r2 in lock_ram_in_cache and
> unlock_ram_in_cache
>
> This is needed in unlock_ram_in_cache() because it is called from C
> and
> will c
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> On Oct 23, 2008, at 8:59 AM, Dave Liu wrote:
>
> > The patch is following the commit
> > 392438406041415fe64ab8748ec5ab5ad01d1cf7
> >
> > mpc86xx: use r4 instead of r2 in lock_ram_in_cache and
> > unlock_ram_in_cache
> >
> > This is needed in unl
On Thu, Oct 23, 2008 at 07:51:30AM -0700, prodyut hazarika wrote:
> > I tested it and it's still failing. I dare say the patch makes things
> > worse. After about 20 hard resets the board didn't reach the u-boot
> > console a single time.
> >
>
> Markus, have you got access to BDI?
I sure do!
Re
> I tested it and it's still failing. I dare say the patch makes things
> worse. After about 20 hard resets the board didn't reach the u-boot
> console a single time.
>
Markus, have you got access to BDI?
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Hello,
i have U-Boot running on MPC5200B! The U-Boot console output is on display!
Now i activated the splash sreen support, and it works!
But now I`m wondering, if I have a problem and have to do something in the
U-Boot console if I get there!
Because when i press a key (between the 3 seconds of a
On Oct 23, 2008, at 9:20 AM, Liu Dave-R63238 wrote:
>> From: Kumar Gala [mailto:[EMAIL PROTECTED]
>> On Oct 23, 2008, at 8:59 AM, Dave Liu wrote:
>>
>>> The patch is following the commit
>>> 392438406041415fe64ab8748ec5ab5ad01d1cf7
>>>
>>> mpc86xx: use r4 instead of r2 in lock_ram_in_cache and
>>
James,
Please do not use CFG_BOOTSZ for flash size.
Since you have two 32MB flash chips tie to one chip select to use as one
for 32-bit access (addr&data). The sectors listing will become 64KB,
64KB, 64KB, 64KB, 256KB... from 32KB, 32KB, 32KB, 32KB, 128KB... (one
upper 16-bit data for flash 1 and
Wolfgang,
Thanks for bringing up. I will resubmit them (including the
header files and M53017EVB patches) in a single patch.
Regards,
TsiChung
-Original Message-
From: Wolfgang Denk [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2008 3:03 AM
To: Liew Tsi Chung-R5AAHP
Cc:
On Thu, 23 Oct 2008, Alan Carvalho de Assis wrote:
> This code is executed from internal 2KB NAND Flash Controller RAM buffer
> and will copy the remaining U-Boot code from NAND Flash verifying its
> bad blocks (case it exists).
>
> Signed-off-by: Alan Carvalho de Assis <[EMAIL PROTECTED]>
Last
> -Original Message-
> From: Stefan Roese [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 23, 2008 4:15 AM
> To: u-boot@lists.denx.de
> Cc: Wolfgang Denk; Markus Klotzbücher; Adam Graham; Victor Gallardo
> Subject: Re: [U-Boot] amcc kilauea odd crashes
>
> Hi Wolfgang,
>
> On Thur
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Stelian Pop,
>
> In message <[EMAIL PROTECTED]> you wrote:
> > > +#ifndef CONFIG_LCD_LOGO_TEXT1
> > > +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
> > > +#endif
> >
> > Wouldn't it be better if we move this text into
> > include/configs/a
>
> Hi Wolfgang,
>
> On Thursday 23 October 2008, Wolfgang Denk wrote:
> > > > Should we not backout the autocalib patches that cause
> the problem
> > > > until a stable working solution is found?
> > >
> > > Not sure. My hope is that AMCC find a solution quickly.
> They should
> > > receive
> > Unfortunately it didn't fix all problems. AMCC already provided
> > another patch for testing purposes. Not to the list but to me (and
> > you) directly. Please find it attached again. Would be
> great if Markus
> > could test it on the failing Kilauea.
>
> I tested it and it's still fa
On 20:36 Thu 23 Oct , Haavard Skinnemoen wrote:
> Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> > Dear Stelian Pop,
> >
> > In message <[EMAIL PROTECTED]> you wrote:
> > > > +#ifndef CONFIG_LCD_LOGO_TEXT1
> > > > +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
> > > > +#endif
> > >
> > >
On Thu, 23 Oct 2008 20:53:37 +0200
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote:
> > I wish someone would bother looking at
> >
> > http://lists.denx.de/pipermail/u-boot/2008-September/039837.html
> >
>
> I like It
Great!
> Just one think it will be nice if we can merge lcd_pr
Dear Alexander,
In message <[EMAIL PROTECTED]> you wrote:
>
> i have U-Boot running on MPC5200B! The U-Boot console output is on display!
> Now i activated the splash sreen support, and it works!
That's how itiis supposed to be :-)
> But now I`m wondering, if I have a problem and have to do some
Dear Haavard Skinnemoen,
In message <[EMAIL PROTECTED]> you wrote:
>
> > Anatolij, Jean-Christophe - who of you will be taking care of this?
>
> I wish someone would bother looking at
>
> http://lists.denx.de/pipermail/u-boot/2008-September/039837.html
>
> at some point so that we can stop fill
On Fri, Oct 17, 2008 at 01:01:48PM -0400, David George wrote:
> We had a problem where NAND device ID would be corrupted after a
> power-cycle. According to the Micron datasheet it requires a RESET
> after power-up before any commands may be issued. Without this patch
> the manufacturer ID wou
On 21:19 Thu 23 Oct , Wolfgang Denk wrote:
> Dear Haavard Skinnemoen,
>
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > Anatolij, Jean-Christophe - who of you will be taking care of this?
> >
> > I wish someone would bother looking at
> >
> > http://lists.denx.de/pipermail/u-boot/2008-
Hi Clive,
yes. but I think that better will be
static uchar etherrxbuff[PKTSIZE_ALIGN]; /* Receive buffer */
Regards,
Michal
> Hi
>
> Looks like there is a buffer allocation error in the packet buffer for the
> xilinx emaclite.
>
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net
From: TsiChung Liew <[EMAIL PROTECTED]>
Each different build for M54455EVB and M5235EVB will
create a u-boot.lds linker file. It is redundant to
keep the u-boot.lds
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
board/freescale/m5235evb/u-boot.lds | 144 --
From: TsiChung Liew <[EMAIL PROTECTED]>
Place FEC pin assignments in cpu_init.c from platform's
mii.c
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
cpu/mcf523x/cpu_init.c | 24 +++-
cpu/mcf52x2/cpu_init.c | 78 +++
cpu/mcf5
From: TsiChung Liew <[EMAIL PROTECTED]>
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
board/freescale/m5272c3/Makefile |2 +-
board/freescale/m5272c3/flash.c | 378 --
include/configs/M5272C3.h| 14 +-
3 files changed, 11 insertions(+), 3
From: TsiChung Liew <[EMAIL PROTECTED]>
The error was caused by the change for strmhz() in cpu.c.
A few of them were one extra close parenthesis.
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
cpu/mcf5227x/cpu.c | 10 +-
cpu/mcf523x/cpu.c |4 ++--
cpu/mcf532x/cpu.c |4 +
From: TsiChung Liew <[EMAIL PROTECTED]>
All CF platforms' mii.c are consolidated into one
Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
---
drivers/net/Makefile |4 +-
drivers/net/mcffec.c | 18 +---
drivers/net/mcfmii.c | 321 ++
3 files
Hello,
This patch series adds support for the XPedite5370 SBC.
Its an MPC8572-based VPX card with a PMC/XMC site. The
XPedite5370 includes a significant number of I2C GPIO devices (5)
which are used for board configuration. I added support for
2 new I2C gpio devices in a new drivers/gpio director
Initial support for NXP's 4 and 8 bit I2C gpio expanders
(eg pca9537, pca9557, etc). The CONFIG_PCA953X define
enables support for the devices while the CONFIG_CMD_PCA953X
define enables the pca953x command.
Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
---
Makefile |2 +
READM
Initial support for the DS4510, a CPU supervisor with
integrated EEPROM, SRAM, and 4 programmable non-volatile
GPIO pins. The CONFIG_DS4510 define enables support
for the device while the CONFIG_CMD_DS4510 define
enables the ds4510 command.
Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
---
READM
Dear Scott,
In message <[EMAIL PROTECTED]> you wrote:
>
> > Why the heck does flash_is_busy() return 0 when the flashobviously is
> > still busy?
>
> Does this use the toggle bit detection? I saw the same symptoms
> with Nios II. Basically, the memory controller was reading the
> 16-bit flash tw
Hi Guennadi,
On Thu, Oct 23, 2008 at 4:10 PM, Guennadi Liakhovetski <[EMAIL PROTECTED]>
wrote:
>
> Last time Scott Wood suggested to use nand_spl you replied "I think using
> nand_spl is the best approach, but it will needs more effort to complete."
> and "Anyway, right now we can have iMX31PDK b
> Converted MPC8610HCPD, MPC8641HPCN, and SBC8641D to use
> fsl_pci_setup_inbound_windows() and ft_fsl_pci_setup().
>
> With these changes the board code is a bit smaller and we get dma-ranges
> set in the device tree for these boards.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
ACK.
1 - 100 of 109 matches
Mail list logo
