Hi all.
Please check this mail and try to avoid these kind of fake mails.
Regards,
Kishore.
-- Forwarded message --
From: Online-notification care...@toshiba-india.com
Date: Mon, Oct 19, 2009 at 4:19 AM
Subject: [U-Boot] Confirmed Recipient
To: i...@msc.co.uk
Your email
--
Software Developer
General Satellite Corp.
---BeginMessage---
I have not board with NAND, working with OneNAND only.
But I think NAND support have not been removed. Maybe omap3_evm_config
configures U-Boot to be built without NAND support. But you can reconfigure
it, so NAND support will be
I am using a recent version of u-boot (git from the past couple of
weeks) and have an LSI SAS adapter on a canyonlands board.
What I see happening is that u-boot reads the bist bit, then does
numerous bar accesses, then sets the bist fail and latency words.
Once the bist is set to fail, the lsi
2009/10/16 Wolfgang Denk w...@denx.de:
Dear Javier Martin,
In message eedb5540910160633o81b1ae3sf37b2a00a5474...@mail.gmail.com you
wrote:
I could finally test this in an original LogicPD i.mx27 litekit board
and found the same problems.
System gets stuck when issuing a ping command.
-
There were two patches submitted to add support for SMSC LAN9220 and
LAN9221.
The latter (more recent one) has been applied but the former hasn't yet.
Refer to the
following and check please.
Regards,
Seunghyeon Rhee
Thu Apr 23 07:36:25 CEST 2009
Daniel Mack wrote:
Signed-off-by: Daniel Mack
Fix compile error:
include/configs/mcc200.h:401:6: error: #elif with no expression
Signed-off-by: Wolfgang Denk w...@denx.de
---
include/configs/mcc200.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/mcc200.h b/include/configs/mcc200.h
index
Dear Ayman El-Khashab,
In message 4adc055c.6080...@elkhashab.com you wrote:
I am using a recent version of u-boot (git from the past couple of
weeks) and have an LSI SAS adapter on a canyonlands board.
What I see happening is that u-boot reads the bist bit, then does
numerous bar accesses,
In message 1255937317-30777-1-git-send-email...@denx.de you wrote:
Fix compile error:
include/configs/mcc200.h:401:6: error: #elif with no expression
Signed-off-by: Wolfgang Denk w...@denx.de
---
include/configs/mcc200.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Dear Sandeep,
In message 0554bef07d437848af01b9c9b5f0bc5d93521...@dlee01.ent.ti.com you
wrote:
There were some issues with Overo Tobi ethernet support.
I am aware of these.
There was a follow up patch that was actually inline in an e-mail rather than
formally being a patch.
Thus I had
Thanks!
I didn't edit anything when I cloned this but after changing it it
built, flashed and ran just fine.
2009/10/18 Paulraj, Sandeep s-paul...@ti.com:
Hi all
The u-boot ti git source code (u-boot-ti) does not seem to build for
the dm355evm.
I am using an image from that source on my
Dear Ben Warren,
In message f8328f7c0910181853t3f8c305ai62841e6d7b487...@mail.gmail.com you
wrote:
I'm still OK with it, but let's try to clean up our workflow next release...
I know you guys had quite a mess to clean up with ARM, so to some extent
this chaos is understandable.
Thanks for
Ben Warren wrote:
Hi Tom,
On Sun, Oct 18, 2009 at 10:26 AM, Tom tom@windriver.com
mailto:tom@windriver.com wrote:
Thompson, Nick (GE EntSol, Intelligent Platforms) wrote:
Add a driver for the DA830 EMAC.
This is very similar to the davinci_emac driver. It
Dear Mike Frysinger,
In message 1255912994-4500-1-git-send-email-vap...@gentoo.org you wrote:
Newer toolchains will often complain about unchecked fwrite():
envcrc.c:117: warning: ignoring return value of `fwrite´, declared
with attribute warn_unused_result
So check
Can U-boot support platform Flash XL memories?
When we tried it, u-boot crashed just before reading the size of the
memory.
Platform Flash XL by default supports synchronous reads. The memory
controller that drives it however supports asynchronous read (there is
no clock output).
So the
Dear Mike Frysinger,
In message 200910182055.01744.vap...@gentoo.org you wrote:
This patch seems to break a *lot* of boards:
i'm attaching two patches here. since we're past the merge window but before
rc1, i dont know how invasive you want to get.
the first one restores
The portmux peripheral pin selection code used when setting up
the MACB1 ethernet port has a small (but critical !!) typo.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
cpu/at32ap/at32ap700x/portmux.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Hans-Christian Egtvedt wrote:
On Mon, 19 Oct 2009 10:49:00 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
The portmux peripheral pin selection code used when setting up
the MACB1 ethernet port has a small (but critical !!) typo.
It does? Where is this fixed in the patch?
Not sure what
On Mon, 19 Oct 2009 10:49:00 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
The portmux peripheral pin selection code used when setting up
the MACB1 ethernet port has a small (but critical !!) typo.
It does? Where is this fixed in the patch?
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
On Mon, 19 Oct 2009 11:35:40 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Hans-Christian Egtvedt wrote:
On Mon, 19 Oct 2009 10:49:00 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
The portmux peripheral pin selection code used when setting up
the MACB1 ethernet port has a small (but
Hans-Christian Egtvedt wrote:
On Mon, 19 Oct 2009 11:35:40 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Hans-Christian Egtvedt wrote:
On Mon, 19 Oct 2009 10:49:00 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
The portmux peripheral pin selection code used when setting up
the MACB1
In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words
for D32 accesses due to the diffferent connecting to the GDC bus. This
patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP,
which should be set for all board using the mb862xx in 16 bpp mode. For
the IPEK01,
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL,
which is enabled for the lwmon5 and the socrates board for backward
compatibility.
Hello,
this patch add support for the IPEK01 MPC5200 based board.
It requires two patchs for the Fujitsu MB862xx driver:
[PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB
mode
[PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
[PATCH 3/3]
This patch adds support for the board IPEK01 based on the MPC5200.
The Futjitsu Lime graphics controller is configured in 16 bpp mode.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
Makefile|3
board/ipek01/Makefile | 50
Dear Wolfgang Grandegger,
In message 20091019111913.427445...@denx.de you wrote:
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL,
which is
Dear Wolfgang Grandegger,
In message 20091019111913.621578...@denx.de you wrote:
In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words
for D32 accesses due to the diffferent connecting to the GDC bus. This
patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP,
Wolfgang Denk wrote:
Dear Wolfgang Grandegger,
In message 20091019111913.427445...@denx.de you wrote:
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via
Wolfgang Denk wrote:
Dear Wolfgang Grandegger,
In message 20091019111913.621578...@denx.de you wrote:
In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words
for D32 accesses due to the diffferent connecting to the GDC bus. This
patch introduces the configuration option
This patch fixes erroneous access to the ethernet PHY which broke the driver.
1. Selector field in the auto-negotiation register must be 0x1 for
using 802.3, not 0x0 which is reseved.
2. Access to the PHY address specified by CONFIG_FEC_MXC_PHYADDR, not
0x0 fixed address.
This has been
If a free() call is used on an already freed pointer we run into
stability problems.
Put all pointers to NULL after freeing to avoid this problem.
Tested on i.MX27 Litekit board with eldk-2.0 toolchain.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
--
diff --git
Dear Wolfgang Grandegger,
In message 20091019111913.802418...@denx.de you wrote:
This patch adds support for the board IPEK01 based on the MPC5200.
The Futjitsu Lime graphics controller is configured in 16 bpp mode.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
Makefile
Dear Wolfgang,
In message 4adc5661.7050...@grandegger.com you wrote:
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL,
which is
Dear Wolfgang Grandegger,
In message 4adc56e4.40...@grandegger.com you wrote:
In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words
for D32 accesses due to the diffferent connecting to the GDC bus. This
patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP,
Nick Thompson wrote:
Ben Warren wrote:
Hi Tom,
On Sun, Oct 18, 2009 at 10:26 AM, Tom tom@windriver.com
mailto:tom@windriver.com wrote:
Thompson, Nick (GE EntSol, Intelligent Platforms) wrote:
Add a driver for the DA830 EMAC.
This is very similar to the
Dear javier Martin,
In message eedb5540910190519l4551493eoc595ca39f0335...@mail.gmail.com you
wrote:
If a free() call is used on an already freed pointer we run into
stability problems.
Is this actually the case anywhere in the code? If so, that code
should be fixed, as thisis obviously a bug
2009/10/19 Wolfgang Denk w...@denx.de:
Dear javier Martin,
In message eedb5540910190519l4551493eoc595ca39f0335...@mail.gmail.com you
wrote:
If a free() call is used on an already freed pointer we run into
stability problems.
Is this actually the case anywhere in the code? If so, that code
After further reviewing the code I now see getting the PXA working
with the GENERIC_MMC interface is more complex than I thought. From
what I can tell reading through the code I really need to re-write the
driver/pxa_mmc.c to support the mmc structure (include/mmc.h). It
needs to have an
Wolfgang Denk wrote:
Dear Wolfgang,
In message 4adc5661.7050...@grandegger.com you wrote:
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via
eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update to
use CONFIG_NET_MULTI
Signed-off-by: Shinya Kuribayashi skuri...@pobox.com
---
I have a few concerns about this fix:
First. I'm not sure why CONFIG_NET_MULTI is undefed for qemu_mips,
while CONFIG_DRIVER_NE2000
The SheevaPlug DevKit is shipped with 4x8 by 1Gb DDR devices in
two banks for a total of 512MB of RAM. Based on this configuration
the existing values for SDRAM address control register are incorrect
and result in random kernel oops as memory is incorrectly accessed
(while for example extracting a
Wolfgang Denk wrote:
Dear Wolfgang Grandegger,
In message 20091019111913.802418...@denx.de you wrote:
This patch adds support for the board IPEK01 based on the MPC5200.
The Futjitsu Lime graphics controller is configured in 16 bpp mode.
Signed-off-by: Wolfgang Grandegger
Dear Wolfgang Grandegger,
In message 4adc6cc3.6040...@grandegger.com you wrote:
+#ifndef CONFIG_SYS_RAMBOOT
Is RAM-Boot actually a asupported mode of operation on this board, or
are you just copuy pasting dead code here?
If it's really dead code I'm going to prepare and send a patch
PPC440EP(x)/PPC440GR(x):
In asynchronous PCI mode, the synchronous PCI clock must meet
certain requirements. The following equation describes the
relationship that must be maintained between the asynchronous PCI
clock and synchronous PCI clock. Select an appropriate PCI:PLB
ratio to maintain the
Some 4xx variants (e.g. 440EP(x)/GR(x)) have an internal
synchronous PCI clock. Knowledge about the currently configured
value might be helpful. So let's print it out upon bootup.
Signed-off-by: Stefan Roese s...@denx.de
---
cpu/ppc4xx/cpu.c |9 -
1 files changed, 8 insertions(+), 1
This patch now uses the 440EP(x)/GR(x) function to check and dynamically
reconfigure the PCI sync clock.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/sequoia/sequoia.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git
This patch now uses the 440EP(x)/GR(x) function to check and dynamically
reconfigure the PCI sync clock.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/yosemite/yosemite.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git
This patch removes the Sequoia bootstrap command and replaces it
with the now common command chip_config.
Please note that the patches with the dynamic PCI sync clock
configuration have to be applied, before this one should go in.
This is because Sequoia has 2 different bootstrap EEPROMs, and
the
Tom wrote:
This is what has changed since v2
10,12c10,12
CPU9260 : fix machine ID when using a CPU9G20.
fix CPU9260/CPU9G20 compile warnings
main.c: In function 'abortboot':
---
AT91 CPU9260 Fix machine ID when using a CPU9G20.
AT91 CPU9260 CPU9G20
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/
immap_85xx.h index 4194295..6c9baac 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1932,4 +1932,14 @@ typedef struct ccsr_gur { #define
CONFIG_SYS_MPC85xx_USB_ADDR \
(CONFIG_SYS_IMMR +
On Mon, Oct 19, 2009 at 7:55 AM, Dirk Behme dirk.be...@googlemail.com wrote:
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix
On Mon, Oct 19, 2009 at 09:35:54AM +0200, Wolfgang Denk wrote:
Did you try setting the pciscandelay variable? Try setting it to 5
(or 10) [seconds]. See also
snip
Thanks Wolfgang,
Per your suggestion, we tried setting the delay (and observed a delay),
but the outcome did not change. The
Hi Shinya,
Shinya Kuribayashi wrote:
eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update
to use CONFIG_NET_MULTI
Signed-off-by: Shinya Kuribayashi skuri...@pobox.com
---
I have a few concerns about this fix:
First. I'm not sure why CONFIG_NET_MULTI is undefed
Hi!
I'm trying to get root-filesystem over NFS running. I'm a bit confused about
all the new stuff and I don't know where I shall start searching for the
problem :-(
I have:
Board: Artila M501 board with AT91RM9200
U-Boot: 1.1.2
Linux: 2.6
Flash: 16MB
SDRAM: 64MB
My U-Boot configuration is:
I'm sorry, somehow the log.txt in my last e-mail got corrupted
Here it is:
Uncompressing
Linux...
done, booting the kernel.
Linux version 2.6.14-M5 (a...@ace-yang) (gcc version 3.3.2) #837 Tue
Dear Michael Schmid,
In message 20091019165934.319...@gmx.net you wrote:
I'm trying to get root-filesystem over NFS running. I'm a bit
confused about all the new stuff and I don't know where I shall start
searching for the problem :-(
I have:
Board: Artila M501 board with AT91RM9200
On Wed, Sep 30, 2009 at 02:22:09PM -0500, Tom wrote:
John Rigby wrote:
@@ -494,13 +600,16 @@ U_BOOT_CMD(nand, CONFIG_SYS_MAXARGS, 1, do_nand,
nand write - addr off|partition size\n
read/write 'size' bytes starting at offset 'off'\n
to/from memory address 'addr',
Wolfgang,
Please pull the net branch (master). This includes a patch that was
somehow lost back in April. It's pretty low-risk.
The following changes since commit f67066b6b0740b826ed862615c5ab022aaf4779a:
Mike Frysinger (1):
envcrc: check return value of fwrite()
are available in
Seunghyeon,
Seunghyeon Rhee (이승현) wrote:
There were two patches submitted to add support for SMSC LAN9220 and
LAN9221.
The latter (more recent one) has been applied but the former hasn't yet.
Refer to the
following and check please.
Regards,
Seunghyeon Rhee
Nice catch! I honestly
On Wed, Oct 07, 2009 at 12:12:16PM +0900, Kyungmin Park wrote:
Sorry, there's typo.
Here's fixed patch.
Please resend the amended patch, complete with changelog, without trailing
quoted material, so that I can just apply one e-mail.
-Scott
___
The override keyword is needed for make to take our version over the one
specified on the command line, and remove it from the list of command line
overrides that are passed to submakes. IMHO, the combination of export
and override ought to do this automatically, but oh well.
Signed-off-by:
If the user has specified a CC or similar on the command line, that is the
cross compiler, not the host compiler. Override is needed to keep these
assignments from being ignored in that case.
Signed-off-by: Scott Wood scottw...@freescale.com
---
tools/Makefile | 10 +-
On Thu, Oct 15, 2009 at 10:48:17AM -0500, Peter Tyser wrote:
Also remove vague, unnecessary comment
Signed-off-by: Peter Tyser pty...@xes-inc.com
Applied both patches to u-boot-nand-flash/next
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
Ben,
I was taking a closer look at the DM9000 driver by trying it on the DM355 EVM.
And it behaving a little different from before, i.e before we moved to the
NET_MULTI stuff.
When the board comes after I reflash with a new U-boot image, I no longer see
the ethaddr being set. But when I do a
On Monday 19 October 2009 05:31:36 Wolfgang Denk wrote:
Mike Frysinger wrote:
diff --git a/board/tqc/tqm8xx/u-boot.lds b/board/tqc/tqm8xx/u-boot.lds
index 2df8d84..8207b2c 100644
--- a/board/tqc/tqm8xx/u-boot.lds
+++ b/board/tqc/tqm8xx/u-boot.lds
@@ -21,6 +21,8 @@
* MA 02111-1307
On Monday 19 October 2009 17:24:35 Scott Wood wrote:
If the user has specified a CC or similar on the command line, that is the
cross compiler, not the host compiler. Override is needed to keep these
assignments from being ignored in that case.
then again, if we didnt mix host and target
Mike Frysinger wrote:
On Monday 19 October 2009 17:24:35 Scott Wood wrote:
If the user has specified a CC or similar on the command line, that is the
cross compiler, not the host compiler. Override is needed to keep these
assignments from being ignored in that case.
then again, if we didnt
Hello,
I see an issue while trying to save the environment on both the DM355 and DM365.
Here is the dump
DM365 EVM # saveenv
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x3e0004 -- 0% complete.
Writing to Nand... done
DM365 EVM #
If we look at the line, Erasing at
Dear Scott Wood,
In message 20091019212409.ga31...@loki.buserror.net you wrote:
The override keyword is needed for make to take our version over the one
specified on the command line, and remove it from the list of command line
overrides that are passed to submakes. IMHO, the combination of
Dear Scott Wood,
In message 20091019212435.ga31...@loki.buserror.net you wrote:
If the user has specified a CC or similar on the command line, that is the
cross compiler, not the host compiler. Override is needed to keep these
assignments from being ignored in that case.
Signed-off-by:
On Monday 19 October 2009 17:56:37 Scott Wood wrote:
Mike Frysinger wrote:
On Monday 19 October 2009 17:24:35 Scott Wood wrote:
If the user has specified a CC or similar on the command line, that is
the cross compiler, not the host compiler. Override is needed to keep
these assignments
Regarding 512x psc register maps:
The register map for 5125 does not just change the size of the registers.
Some registers change locations. The issue is that the hardware guys
decided to fix the old broken register access. The 5200, 5121, 5123 had
some registers that were:
Function A when
Wolfgang Denk wrote:
Dear Scott Wood,
In message 20091019212409.ga31...@loki.buserror.net you wrote:
The override keyword is needed for make to take our version over the one
specified on the command line, and remove it from the list of command line
overrides that are passed to submakes.
Hi Magnus,
Thanks.
Are you using U-boot v2 or some other customized U-boot? (gitweb at
git.denx.de seems to have some problems at the moment and I don't have
the U-boot v2 tree locally)
Custom u-boot based on v2.
I have ported mxc_nand based on the kernel code(2.6.26) and it uses
2k/4k
Hi Ben,
Ben Warren wrote:
Shinya Kuribayashi wrote:
First. I'm not sure why CONFIG_NET_MULTI is undefed for qemu_mips,
while CONFIG_DRIVER_NE2000 has been enabled for qemu_mips at an early
stage.
I don't follow recent changes around eth.c and CONFIG_NET_MULTI, but
it's probably
Steve Sakoman had written, on 10/19/2009 10:06 AM, the following:
On Mon, Oct 19, 2009 at 7:55 AM, Dirk Behme dirk.be...@googlemail.com wrote:
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the
Sometimes, inside NetLoop, eth_halt() is called before eth_init() has
been called. This is harmless except for free() calls to pointers
which have not been allocated yet. This patch adds two states to
distinguish when it is necessary to call free() and when it is not.
This has been tested in
78 matches
Mail list logo
