Hi Wolfgang,
On Tuesday 28 April 2009, Wolfgang Denk wrote:
I took a quick look at the flash driver. The main functions
lpc24xx_flash_erase() and lpc24xx_write_buff() are not even referenced
somewhere in this patch. They seem to be used in the 2nd patch (2/2)
though. It's hard to really
From: Wolfgang Denk w...@denx.de
Get rid of these warnings:
cmd_ext2.c:247: warning: format '%ld' expects type 'long int', but argument 2
has type 'int'
cmd_ext2.c:248: warning: format '%lX' expects type 'long unsigned int', but
argument 3 has type 'int'
Signed-off-by: Wolfgang Denk
2009/4/28 Wolfgang Denk w...@denx.de:
Dear Marco,
In message 49e61f99.50...@gmail.com you wrote:
From: Marco Stornelli marco.storne...@gmail.com
This patch adds, under tools folder, a new command called imls. Its
goal is the same of UBoot's imls but it can be used as Linux shell
command.
Hi
2009/4/27 alfred steele alfred.jaq...@gmail.com:
Dear Magnus,
Thanks for the reply!
And we need to know which U-boot patches you're using to boot the PDK
board.
I am using the internal git tree code supplied to me by freescale. The
tarball is called uboot-imx-imx_v2009.01.tar.gz. I can
Fix some issues introduced from commit:
2f70c49e5b9813635ad73666aa30f304c7fdeda9
suggested by Mike Frysinger.
- added some comment for the env_id variable in common_cmd_nvedit.c
- moved some variables in fn scope instead of file scope
- NetInitLoop now static void
Signed-off-by: Heiko Schocher
Signed-off-by: Heiko Schocher h...@denx.de
---
MAKEALL |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index e4eb42b..e9bcf92 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -284,6 +284,7 @@ LIST_824x= \
debris \
eXalion \
Hi Wolfgang,
On Tuesday 28 April 2009, Wolfgang Denk wrote:
Into drivers/mtd? Even if it's not a MTD driver? This doesn't make
mnuch sense to me.
In the end this driver will be used by the common FLASH user interface
(cmd_flash.c, cmd_mem.c). So I prefer to have the driver for this
Hi Heiko,
Heiko Schocher wrote:
Fix some issues introduced from commit:
2f70c49e5b9813635ad73666aa30f304c7fdeda9
suggested by Mike Frysinger.
- added some comment for the env_id variable in common_cmd_nvedit.c
- moved some variables in fn scope instead of file scope
- NetInitLoop now
Dear Mike Frysinger,
In message 200904271955.08919.vap...@gentoo.org you wrote:
Should we not rather use 0xFF for padding - given that the envrionment
is frequently stored in NOR flash?
i would love to (and with the Blackfin stuff, i do just that), but the
problem
is that there is no
Hi Stefan (and anybody else that can answer),
I'm trying to understand why some 4xx boards use CONFIG_NET_MULTI and a
few don't. Is there a technical reason why these few can't (limited
storage or something else) or are they just older? There are 47 boards
in-tree that use CONFIG_PPC4xx_EMAC
Hi Ben,
On Tuesday 28 April 2009, Ben Warren wrote:
Hi Stefan (and anybody else that can answer),
I'm trying to understand why some 4xx boards use CONFIG_NET_MULTI and a
few don't. Is there a technical reason why these few can't (limited
storage or something else) or are they just older?
Hello Ben,
Ben Warren wrote:
Heiko Schocher wrote:
Fix some issues introduced from commit:
2f70c49e5b9813635ad73666aa30f304c7fdeda9
suggested by Mike Frysinger.
- added some comment for the env_id variable in common_cmd_nvedit.c
- moved some variables in fn scope instead of file scope
-
Hello
What is the situation now? We apply this patch and then make lzo
parameter compatible? I am a bit lost
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
U-Boot mailing list
U-Boot@lists.denx.de
Fix some issues introduced from commit:
2f70c49e5b9813635ad73666aa30f304c7fdeda9
suggested by Mike Frysinger.
- added some comment for the env_id variable in common_cmd_nvedit.c
- moved some variables in fn scope instead of file scope
- NetInitLoop now static void
Signed-off-by: Heiko Schocher
On Mon, Apr 27, 2009 at 03:28:28PM -0400, Mike Frysinger wrote:
if you want your points to have any meaning/usage, then they have to be on
the
mailing list. irc is useless for people trying to search for background
information to a problem.
I agree here, but I already gave up. And if the
Hi Ben, Hi Stefan,
I will prepare a patch for these boards on thursday:
AR405.h
CPCIISER4.h
HUB405.h
OCRTC.h
ORSG.h
WUH405.h
I have a cleanup patch ready for DP405 by today :-)
DP405.h
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
Hi Wolfgang,
And if we want to make it perfect, each -rc could get a similar
announcement, too.
Would ne not just add a lot of noise to the ML, without any real new
information?
If you want detailed information about each action, please feel free
and register a RSS feed on the
Hi Steven,
Yes, I do see what U-boot is doing. I looked at bmp_logo.c and its output.
It seems that the color palette entries are all 16 bits (unsigned short).
To synch up - you are trying to use the 'logo_plot' code from
drivers/video/cfb_console.c, right?
For my application, I have 24 bit
On Tuesday 28 April 2009, Matthias Fuchs wrote:
I will prepare a patch for these boards on thursday:
AR405.h
CPCIISER4.h
HUB405.h
OCRTC.h
ORSG.h
WUH405.h
I have a cleanup patch ready for DP405 by today :-)
DP405.h
Thanks. :)
Best regards,
Stefan
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
It now also includes support for the ethernet interface.
It does not include any changes to flash related code, until it's known
where to put it. Stefan was
Hi Heiko,
On Tue, Apr 28, 2009 at 09:36:46AM +0200, Heiko Schocher wrote:
Hello Sascha,
I actually looked in the u-boot-v2.git in the i2c branch,
because I wanted to look how things in v2 work, specially
I2C Subsystem ... and I have a first question:
Note that the I2C branch is out of date
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does
that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
I don't
On Tue, Apr 28, 2009 at 11:37:14AM +0200, Daniel Stenberg wrote:
I'm currently working with a Toradex board featuring a Colibri PXA270 module,
and I noticed this attempt to get a Colibri PXA270 patch applied
http://lists.denx.de/pipermail/u-boot/2009-April/050634.html
... which
Hello Sascha,
Sascha Hauer wrote:
On Tue, Apr 28, 2009 at 09:36:46AM +0200, Heiko Schocher wrote:
Hello Sascha,
I actually looked in the u-boot-v2.git in the i2c branch,
because I wanted to look how things in v2 work, specially
I2C Subsystem ... and I have a first question:
Note that the
On Tue, 28 Apr 2009, Daniel Mack wrote:
In case you do that, please call the board 'colibri-pxa270' in folder and
config file names, not just 'colibri' like in the version you referred to
above. There are versions of that modules with pxa3[012]0 CPUs which are
entirely different and need
Dear Detlev,
In message m2iqkpp49c@ohwell.denx.de you wrote:
And if we want to make it perfect, each -rc could get a similar
announcement, too.
^^^
No, I meant exactly what I wrote - the RSS feed on the git repo
Hello u-booters,
I'm currently working with a Toradex board featuring a Colibri PXA270 module,
and I noticed this attempt to get a Colibri PXA270 patch applied
http://lists.denx.de/pipermail/u-boot/2009-April/050634.html
... which seems it didn't get anywhere further than so.
The
Hello Sascha,
I actually looked in the u-boot-v2.git in the i2c branch,
because I wanted to look how things in v2 work, specially
I2C Subsystem ... and I have a first question:
- In ppc area, we start running from flash and have to relocate
code. Before setting up RAM, we maybe have to read
On Tuesday 28 April 2009 03:42:30 Ricardo Ribalda Delgado wrote:
What is the situation now? We apply this patch and then make lzo
parameter compatible? I am a bit lost
i think so ... your latest patch looked OK to me
-mike
signature.asc
Description: This is a digitally signed message
On Tuesday 28 April 2009 06:08:06 Ladislav Michl wrote:
On Mon, Apr 27, 2009 at 03:28:28PM -0400, Mike Frysinger wrote:
if you want your points to have any meaning/usage, then they have to be
on the mailing list. irc is useless for people trying to search for
background information to a
Dear Wolfgang,
The following changes since commit 28afe0160f87ff74574150d703055a965f91422a:
Heiko Schocher (1):
ids8247: Remove legacy NAND defines
are available in the git repository at:
git://git.denx.de/u-boot-video.git master
Anatolij Gustschin (1):
video: fix bug in
On Tuesday 28 April 2009 03:13:05 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
Should we not rather use 0xFF for padding - given that the envrionment
is frequently stored in NOR flash?
i would love to (and with the Blackfin stuff, i do just that), but the
problem is that
On Tuesday 28 April 2009 05:11:01 Detlev Zundel wrote:
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does
that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain;
Dear Mike Frysinger,
In message 200904280848.14109.vap...@gentoo.org you wrote:
i too would prefer a POST case that can be classified as a mathematically
sound proof. did i miss something, or was such a case proposed ?
No.
And I think it's actually difficult to implement, as it's
Dear Mike Frysinger,
In message 200904280854.53669.vap...@gentoo.org you wrote:
You mean in the code? Well, if you're using a separate section for it
(like the ppcenv section) this should be straightforward using the
`=FILLEXP' output section attribute for the linker.
hmm, a quick
Added example board for LPC2468 processor
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
From ab9ef1e9c2bd8f04612429461baa5c24dbc52266 Mon Sep 17 00:00:00 2001
From: Remco Poelstra remco.poels...@duran-audio.com
Date: Tue, 28 Apr 2009 15:04:33 +0200
Subject: [PATCH]
Dear Wolfgang,
Wolfgang Denk wrote:
Dear Dirk,
In message 49f5c746.6040...@googlemail.com you wrote:
Short status update after recent merges and patch updates. As usual,
please correct if anything is wrong or missing.
Thanks for the summary.
Dirk Behme wrote:
To avoid loosing the
Hi Magnus,
Thanks!
Here's a 'snapshot' function in git-web
(http://git.denx.de/?p=u-boot.git;a=tree) which will produce a tarball
of the current tree.
Before that, i actually managed to git clone to a windows machine(at
my home) and export the u-boot tarball to my office linux host where
its
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does
that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
I
Here is the changes to Zoom2 to rebase onto the arm/next branch
Patch set to follow.
Tom
1.
omap gpio changed to apply
Makefile change
Whitespace in docs
Jean-Christophe Zoom2 base 4/24
2.
Divisor field is called PTV not PVT.
This change is needed because of earlier OMAP commit
Zoom2 is a new board from Texas Instruments and LogicPD
The logicpd web site is a good source for general information on this board.
Please start looking here if the below links are broken.
http://www.logicpd.com
This is a pdf of the product
The logicpd web site is a good source for general information on this board.
Please start looking here if the below links are broken.
http://www.logicpd.com
This is a pdf of the product
http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf
This is a pdf of the product
Zoom2 serial is in general supplied by one of the 4 UARTS on the debug board.
The default serial is from the USB connector on left side of the debug board.
The USB connector will produce 2 of the 4 UARTS. On your host pick the first
enumeration.
The serial port set up is the same with Zoom1.
This patch controls the large LED on the top left of the zoom2.
Signed-off-by: Tom Rix tom@windriver.com
---
board/omap3/zoom2/Makefile|8 ++-
board/omap3/zoom2/led.c | 125 +
board/omap3/zoom2/zoom2.c |4 +-
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does
that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset=utf-8
Hi Magnus and all,
Should i do a mx31pdk_nand_config instead of the regular
mx31pdk_config to get the nand boot working on the PDK board.
I can make that out from the lowlevel_init.S code, but i am not
completely sure though.
Thanks.
___
U-Boot
On Tuesday 28 April 2009 09:41:07 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
i too would prefer a POST case that can be classified as a mathematically
sound proof. did i miss something, or was such a case proposed ?
No.
And I think it's actually difficult to implement, as
Hi
2009/4/28 alfred steele alfred.jaq...@gmail.com:
Hi Magnus,
Thanks!
But then on doing make mx31_pdk_config, i got the following:
$ make mx31ads_config
: invalid option
make: *** [mx31ads_config] Error 1
So looks like somewhere out there , some file has some weird windows
inherited
Hi Magnus,
No, but it seems that the problem is in the patched Makefile since it
says mx31ads_config instead of mx31_pdk_config.
I tried this on all the RULES as i was getting the same results for
the rule mx31_pdk_config. Apologize for for posting the wrong one.
This problem got resolved when
Hi Remco,
Remco Poelstra wrote:
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
It now also includes support for the ethernet interface.
It does not include any changes to flash related code, until it's
Hi Magnus,
So , in order to boot out of NAND, all i need to do is use the image
generated out mx31pdk_nand_config instead of the regular
mx31_pdk_config. Right?
Another thing which confuses me is the file nand_boot_mx31.c . Is it
a symbolik link which points to the genric nand_boot.c or is it
So , in order to boot out of NAND, all i need to do is use the image
generated out mx31pdk_nand_config instead of the regular
mx31_pdk_config. Right?
Yes.
/Magnus
___
U-Boot mailing list
U-Boot@lists.denx.de
Hi
2009/4/28 alfred steele alfred.jaq...@gmail.com:
Hi Magnus,
So , in order to boot out of NAND, all i need to do is use the image
generated out mx31pdk_nand_config instead of the regular
mx31_pdk_config. Right?
Another thing which confuses me is the file nand_boot_mx31.c . Is it
a
On Tuesday 28 April 2009 11:57:37 Peter Tyser wrote:
On Tue, 2009-04-28 at 11:49 -0400, Mike Frysinger wrote:
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
You just don't see it.
I (think I) see base64 coming from denx.de, but not from our mail
server.
The headers
please ignore ...
test.c:1: warning: implicit declaration of function ‘foo’
/tmp/ccelkAwh.o: In function `main':
test.c:(.text+0x12): undefined reference to `foo'
collect2: ld returned 1 exit status
moo
---
foo |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644
Hi Mike,
On Tuesday 28 April 2009 05:11:01 Detlev Zundel wrote:
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does
that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type:
From: Marco Stornelli marco.storne...@gmail.com
This patch adds, under tools folder, a new command called imls. Its
goal is the same of UBoot's imls but it can be used as Linux shell
command. It reads from raw mtd partition and prints the list of the
stored images.
Signed-off-by: Marco Stornelli
Hello,
This patch set is an untested attempt at cleaning up the Davinci Ethernet
driver. Since I don't have any real hardware, I've tried to keep the logical
flow as similar to the original as possible and haven't touched any of the
hardware access code. If anybody's able to test it, please do
The driver has been renamed dm644x_emac.c
Signed-off-by: Ben Warren biggerbadder...@gmail.com
---
cpu/arm926ejs/davinci/Makefile |2 +-
drivers/net/Makefile |1 +
.../davinci/ether.c = drivers/net/dm644x_emac.c |0
3 files
Removed pointless #ifdefs
Moved functions around in file in preparation for switch to newer API
Signed-off-by: Ben Warren biggerbadder...@gmail.com
---
drivers/net/dm644x_emac.c | 146 +
1 files changed, 69 insertions(+), 77 deletions(-)
diff --git
Added CONFIG_NET_MULTI to all Davinci boards
Removed all calls to Davinci network driver from board code
Added cpu_eth_init() to cpu/arm926ejs/cpu.c
Signed-off-by: Ben Warren biggerbadder...@gmail.com
---
board/davinci/common/misc.h |1 -
board/davinci/dvevm/dvevm.c |3
On Tuesday 28 April 2009 13:06:00 Detlev Zundel wrote:
On Tuesday 28 April 2009 05:11:01 Detlev Zundel wrote:
The copies cc-ed to myself come through just fine as utf-8 fwiw.
Does that imply the denx.de servers convert unicode messages to
base64?
This is in the headers of your
Hi Magnus,
Thanks again!
The nand_spl/nand_boot_mx31.c is a regular file if that's the one you mean.
The reason i am asking is I am getting a build error related to this
file after i apply your patches. When i do a ll(ls -l) on the file, i
get
$ll
Wolfgang,
Heiko Schocher wrote:
Fix some issues introduced from commit:
2f70c49e5b9813635ad73666aa30f304c7fdeda9
suggested by Mike Frysinger.
- added some comment for the env_id variable in common_cmd_nvedit.c
- moved some variables in fn scope instead of file scope
- NetInitLoop now
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
I (think I) see base64 coming from denx.de, but not from our mail
server.
blah, this seems to be all mailman's fault. apparently, it can only be
changed by disabling the msg_footer/msg_header options.
2009/4/28 alfred steele alfred.jaq...@gmail.com:
Hi Magnus,
Thanks again!
The nand_spl/nand_boot_mx31.c is a regular file if that's the one you mean.
The reason i am asking is I am getting a build error related to this
file after i apply your patches. When i do a ll(ls -l) on the file, i
Dear Ladislav Michl,
In message 20090428151147.ga19...@linux-mips.org you wrote:
a lot of changes are entering arm tree, many without any commit message.
And now we have some special cases which needs some special care for yet
unclear reason. OMAP3 timer precission was discussed to death and
On Tue, 2009-04-28 at 13:22 -0400, Mike Frysinger wrote:
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
I (think I) see base64 coming from denx.de, but not from our mail
server.
blah, this seems to be all mailman's fault. apparently, it can only be
changed by disabling the
Dear Magnus,
Yes, that's the latest one I've posted (I've done minor updates
locally but haven't tested those yet).
I guess that's there are two patches for NAND_SPL, one which just adds
the SPL framework and the other which creates the mx31pdk_nand.c and
changes to start.S.
Please correct me
Or you suggest sticking to the latest and greatest mainline.
Alternatively, will use the .rej to generate the new lot of patches.
That seems the best route.
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
Hi
2009/4/28 alfred steele alfred.jaq...@gmail.com:
Dear Magnus,
Yes, that's the latest one I've posted (I've done minor updates
locally but haven't tested those yet).
I guess that's there are two patches for NAND_SPL, one which just adds
the SPL framework and the other which creates the
On Tuesday 28 April 2009, Ben Warren wrote:
The driver has been renamed dm644x_emac.c
Let me suggest davinci_emac.c ... the same controller
is in some non-dm644x DaVinci silicon (like dm365), and
a gigabit flavor is in the dm6467 chip.
-COBJS = timer.o ether.o lxt972.o dp83848.o
+COBJS
David Brownell wrote:
On Tuesday 28 April 2009, Ben Warren wrote:
The driver has been renamed dm644x_emac.c
Let me suggest davinci_emac.c ... the same controller
is in some non-dm644x DaVinci silicon (like dm365), and
a gigabit flavor is in the dm6467 chip.
OK. I named it
From: David Brownell dbrown...@users.sourceforge.net
Minor cleanup for DaVinci NAND code:
- Use I/O addresses from nand_chip; CONFIG_SYS_NAND_BASE won't
be defined when there are multiple chipselect lines in use
(as with common 2 GByte chips).
- Cleanup handling of EMIF control
Please correct me if i am wrong. Since the cpu/arm1136/start.S has
changed in a major way since April 02, since this is a generic file, i
am getting a BIG .rej file for the HUNKS which failed. I can hand edit
start.S as i have done for the rest of the HUNK failures which were
minor. But is
From: David Brownell dbrown...@users.sourceforge.net
Remove CONFIG_SYS_DAVINCI_BROKEN_ECC option. It's not just nasty;
it's also unused by any current boards, and doesn't even match the
main U-Boot distributions from TI (which use soft ECC, or 4-bit ECC
on newer chips that support it).
DaVinci
The CLE and ALE for DaVinci DM644x is not the same as DM646x. This patch
adds 2 CONFIG_ options to the config.h header files to all the DM6446 based
boards. These values are then used by the driver. This has been tested on the
DM644x, DM355, DM357 and DM365. Support for the latter 3 will be added
Patch adds support for DaVinci DM357. This SOC is very similar to the DM644x.
The DM357 EVM has 2 NANDs, one small page NAND and another large page NAND.
But the device can only boot of the small page NAND. It does not have NOR
support. This patch has been tested on the DM357 EVM.
Signed-off-by:
Hi Magnus,
I just applied the patch series to the current u-boot tip and the only
problem was the top Makefile but that was easy to fix. No warnings
from start.S.
I was able to build successfully after hand editing some of the hunks
in start.S. Even after using the commit snapshot you had
Steve,
My intention was to change that when I add the DM6467 Support which I am
working on even as we speak.
I am aware of it.
Thanks,
Sandeep
-Original Message-
From: Steve Chen [mailto:sc...@mvista.com]
Sent: Tuesday, April 28, 2009 4:54 PM
To: Paulraj, Sandeep
Cc:
On Tue, Apr 28, 2009 at 04:33:14PM -0400, s-paul...@ti.com wrote:
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index fae430b..1fe3e19 100644
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -128,6 +128,8 @@
#define
On Tue, 2009-04-28 at 16:33 -0400, s-paul...@ti.com wrote:
The CLE and ALE for DaVinci DM644x is not the same as DM646x. This patch
adds 2 CONFIG_ options to the config.h header files to all the DM6446 based
boards. These values are then used by the driver. This has been tested on the
DM644x,
On Tuesday 28 April 2009, s-paul...@ti.com wrote:
The CLE and ALE for DaVinci DM644x is not the same as DM646x. This patch
adds 2 CONFIG_ options to the config.h header files to all the DM6446 based
boards. These values are then used by the driver.
I had been thinking that the davinci_nand
On Tuesday 28 April 2009, s-paul...@ti.com wrote:
Patch adds support for DaVinci DM357. This SOC is very similar to the DM644x.
The DM357 EVM has 2 NANDs, one small page NAND and another large page NAND.
But the device can only boot of the small page NAND. It does not have NOR
support. This
On Tuesday 28 April 2009, s-paul...@ti.com wrote:
Makefile | 3 +
include/configs/davinci_dm357_evm.h | 159
+++
2 files changed, 162 insertions(+), 0 deletions(-)
I believe that will be insufficient with the current
U-Boot
On Tue, Apr 28, 2009 at 01:19:50PM -0700, David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
Minor cleanup for DaVinci NAND code:
Applied 1-2 to u-boot-nand-flash/next.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
Hi Matthias,
Matthias Fuchs wrote:
Hi Ben, Hi Stefan,
I will prepare a patch for these boards on thursday:
AR405.h
CPCIISER4.h
HUB405.h
OCRTC.h
ORSG.h
WUH405.h
I have a cleanup patch ready for DP405 by today :-)
DP405.h
Matthias
I appreciate your help here!
Hello,
This patch set switches all remaining PPC4xx boards to use CONFIG_NET_MULTI.
I haven't been able to test any of the boards, but MAKEALL 4xx ran OK. I
remember that some of the 4xx linker scripts specified 'ppc_4xx_eth_initialize',
so maybe that's necessary in some cases?
regards,
Ben
All in-tree PPC4xx boards now use CONFIG_NET_MULTI
Signed-off-by: Ben Warren biggerbadder...@gmail.com
---
include/configs/AR405.h |1 +
include/configs/CPCIISER4.h |1 +
include/configs/CRAYL1.h |1 +
include/configs/DP405.h |1 +
Signed-off-by: Ben Warren biggerbadder...@gmail.com
---
drivers/net/4xx_enet.c | 54
net/eth.c |4 ---
2 files changed, 0 insertions(+), 58 deletions(-)
diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c
index
Scott,
I will resubmit after i take care of your comments.
Thanks,
Sandeep
From: Scott Wood [scottw...@freescale.com]
Sent: Tuesday, April 28, 2009 5:22 PM
To: Paulraj, Sandeep
Cc: u-boot@lists.denx.de; davinci-linux-open-sou...@linux.davincidsp.com
This will make CONFIG_NET_MULTI the only net driver configuration and
we'll be able to remove this option.
Signed-off-by: Ben Warren biggerbadder...@gmail.com
---
doc/feature-removal-schedule.txt | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git
Dave,
What I have done is sufficient. A 'dm357.c' file will not be required as
the dm644x.c file will take care of everything. AS long as your patches ensure
that dm644x works, the DM357 will work. This is because DM357 is very similar
to the DM644x. If you want me to put a dm357 file
Dave,
We can add such support/enhancements later. The patch as such will work
for sure.
In our LSPs we can use only one NAND at a time. We do not at this point of time
have support even in the kernel where both NANDs can be used at the same time.
Its only either of the 2.
Thanks,
Dave,
Please see inline.
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Tuesday, April 28, 2009 5:51 PM
To: Paulraj, Sandeep; u-boot@lists.denx.de
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH] ARM DaVinci: Adding CONFIG options
On Tuesday 28 April 2009, Paulraj, Sandeep wrote:
Dave,
We can add such support/enhancements later. The
patch as such will work for sure.
OK, I can understand that. This board seems to have
the most complex NAND config of the DaVinci EVMs.
In our LSPs we can use
only one NAND at a
Hi Sandeep,
On Tuesday 28 April 2009, Paulraj, Sandeep wrote:
I had been thinking that the davinci_nand driver should
probably change to let board_nand_init() really become a
board-specific function...
It would call a driver routine to init the callback functions
and set up
From: David Brownell dbrown...@users.sourceforge.net
Initial U-Boot support for the DaVinci DM355 EVM. This is a board
from Spectrum Digital. Board docs include schematic and firmware
for its microcontroller:
http://c6000.spectrumdigital.com/evmdm355/
Most of the DM355 chip is fully
98 matches
Mail list logo
