Dear Bob Furber,
please keep the mailing list on cc:
In message 4a832c44.3060...@steroidmicros.com you wrote:
You failed to mention some really important fects, like for example
which version of U-Boot you are using.
ftp://ftp.denx.de/pub/u-boot/ -- u-boot-2009.08-rc2.tar.bz2, which
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090812212651.ga11...@game.jcrosoft.org you wrote:
While I'm not completely opposed to the idea of tracking indices,
it's simply not true that you don't know the indices of the
controllers on your board. They're all instantiated in
Dear Tom Rix,
In message 1250091750-1525-2-git-send-email-tom@windriver.com you wrote:
v7_flush_dcache_all, because it depends on omap ROM code is not
generic. Rename the function to 'invalidate_dcache' and move it
to the omap cpu directory.
Collect the other omap cache routines
Dear Ben Warren,
In message 1250050332-15531-2-git-send-email-biggerbadder...@gmail.com you
wrote:
All in-tree boards that use this controller have CONFIG_NET_MULTI
added
Also:
- changed CONFIG_DRIVER_CS8900 to CONFIG_CS8900
- changed CS8900_BASE to CONFIG_CS8900_BASE
- changed
Wolfgang Denk wrote:
Dear Tom Rix,
In message 1250091750-1525-2-git-send-email-tom@windriver.com you wrote:
v7_flush_dcache_all, because it depends on omap ROM code is not
generic. Rename the function to 'invalidate_dcache' and move it
to the omap cpu directory.
Collect the other
Hi Wolfgang,
Wolfgang Denk wrote:
Dear Ben Warren,
In message 1250050332-15531-2-git-send-email-biggerbadder...@gmail.com you
wrote:
All in-tree boards that use this controller have CONFIG_NET_MULTI
added
Also:
- changed CONFIG_DRIVER_CS8900 to CONFIG_CS8900
- changed
The TRAB board references local libgcc helper routines
(lib_arm/div0.o and lib_arm/_umodsi3.o) which cause build problems
when we try to use the normal, compiler provided libgcc instead.
Removing these references allows to build both with and without the
local libgcc helper routines.
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:42 Wed 12 Aug , Tom Rix wrote:
v7_flush_dcache_all, because it depends on omap ROM code is not
generic. Rename the function to 'invalidate_dcache' and move it
to the omap cpu directory.
snip
for the l2 cache ACK
for the
Dear Ben Warren,
In message 4a8342be.7050...@gmail.com you wrote:
It looks like the 'trab' board uses 16-bit accesses
(CONFIG_CS8900_BUS16). The function 'get_reg_init_bus()' does some
funny initialization to get the chip into 16-bit mode. I wonder if
maybe that's not working the same
Dear Ben Warren,
I wrote:
Note however that your modification was probably not the (only)
culprit. With current mainline version I get this:
TRAB # run load
TFTP from server 192.168.1.1; our IP address is 192.168.3.68
Filename 'trab/u-boot.bin-wd'.
Load address: 0xc10
Loading: T T T
Wolfgang Denk wrote:
Dear Ben Warren,
I wrote:
snip
Please ignore me:
U-Boot 2009.08-rc2-00016-g253cb83-dirty (Aug 13 2009 - 00:42:59)
I2C: ready
DRAM: 32 MB
Flash: 8 MB
USB: scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Enter password -
Thanks for your tip and sorry for my ambiguit question.
When I read the relocate_code function in cpu/mpc8xx/start.S, I found
the code below:
=
512 sub r15, r10, r4
513
514 /* First our own GOT */
515
I am trying to run a standalone program from flash but I keep receiving **
Invalid boot device ** when I attempt to load it into memory. I think I'm
just using the wrong device number. I was wondering if there was any way to
print the devices that U-boot can see, so I can figure out dev:part
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 14:15 Wed 12 Aug , Ben Warren wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 20:50 Wed 12 Aug , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message
Add support for the DEKA Research and Development galaxy5200 board.
Amended with comments from Wolfgang.
Make change to top level makefile per Wolfgang's suggestion.
Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
---
MAINTAINERS |4 +
MAKEALL
Just realised that i dis reply instead of reply all.
We have been using 2009.1 based version.. We have been using nand
read.e/write.e. Is that fine? After skimming through the u-boot code,
it seems though.
Please confirm.
Apart from this, what does the CONFIG_JFFS2_NAND do?
Thanks, Alfred.
On Monday 03 August 2009 10:39:10 Wolfgang Denk wrote:
In message J.C. Wren wrote:
Scott pointed me at this patch (
http://git.denx.de/?p=u-boot/u-boot-blackfin.git;a=commitdiff;h=44f07de8c
c94836cd3b0fd2fb0cf8b8651461087) that's in the Blackfin branch.
Would it be possible to make this
On Thursday 06 August 2009 20:11:14 Kumar Gala wrote:
We seem to set CPPFLAGS to include RELFLAGS but I'm wondering how
PLATFORM_ RELFLAGS is suppose to differ from PLATFORM_CPPFLAGS.
my understanding is that REL is short for release, and so you put flags in
there that arent preprocessor flags
On Monday 10 August 2009 16:26:20 Robin Getz wrote:
From bca49fb5e3045bc175e924999a4015804c39c5c6 Mon Sep 17 00:00:00 2001
From: Robin Getz rg...@blackfin.uclinux.org
I was using this when I was looking at some other recent tftp performance,
and thought I would share. I really don't think it
On Wednesday 12 August 2009 08:04:40 Wolfgang Denk wrote:
Ulf Samuelsson wrote:
If I build u-boot from the u-boot dir outside the buildsystem,
it also means a lot of typing - If I remember to do it...
Why not make it a default mode?
Because the default mode is to assume you are using a
On Tuesday 28 July 2009 11:44:27 Albin Tonnerre wrote:
When CONFIG_NET_MULTI is defined, the NetLoop code looks in
eth_get_device()-enetaddr for the MAC address. However, this value may
not be set. In fact, it will not be if ethaddr was not present in the
environment when uboot was started.
The local board-specific spi_init() function conflicts with the common SPI
layer, so rename it to something board-specific.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
Note: i've only semi-compile tested this because building for arm results
in common math build/link failures related to
On Tuesday 11 August 2009 15:36:26 Robin Getz wrote:
On Tue 11 Aug 2009 15:21, Wolfgang Denk pondered:
Robin Getz wrote:
Now that we have sha1 and md5 in lib_generic, allow people to use
them on the command line, for checking downloaded files
Signed-off-by: Robin Getz
On Tuesday 04 August 2009 12:07:17 J.C. Wren wrote:
All fair points.
please do not top post in your replies
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
On Friday 07 August 2009 05:59:11 fluke56512 wrote:
Hi everyone~
I am a beginner for u-boot~
I am using 1.3.4 version
time to upgrade
now I want to debug() print out information.
so use it and add #define DEBUG to the top of the file before any #include
I see in /tools/Mkimage.h have:
On Friday 07 August 2009 15:22:15 Scott Wood wrote:
On Fri, Aug 07, 2009 at 09:03:03AM -0500, Kumar Gala wrote:
while [ $# -gt 0 ] ; do
case $1 in
--) shift ; break ;;
-a) shift ; APPEND=yes ;;
-n) shift ; BOARD_NAME=${1%%_config} ; shift ;;
+ -D) shift ;
On Friday 07 August 2009 17:37:51 Ben Warren wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 22:17 Fri 07 Aug , Prafulla Wadaskar wrote:
eth_setenv_enetaddr is avaible by upper layer
using this saves 204 bytes on total image size
Signed-off-by: Prafulla Wadaskar
On Wednesday 05 August 2009 17:26:50 Ben Warren wrote:
Wolfgang Denk wrote:
Mike Frysinger wrote:
In the previous enetaddr refactoring, the assumption with commit
56b555a644 was that the eth layer would handle the env - device
enetaddr syncing. This was not the case as eth_initialize() is
Hi Eric,
The subject of your email should be [PATCH V2] Add support for
galaxy5200. As is, the V2 would be included in the commit title.
Support also doesn't need to be capitalized.
Add support for the DEKA Research and Development galaxy5200 board.
Amended with comments from Wolfgang.
Make
Dear Jerry Van Baren,
In message 4a837625.6010...@gmail.com you wrote:
= fdt set /chosen bootargs console=ttyUL\ root=/dev/mtdblock0
Why not simply
= fdt set /chosen bootargs console=ttyUL root=/dev/mtdblock0
?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH,
Dear Mike Frysinger,
In message 200908122253.13067.vap...@gentoo.org you wrote:
Actually if should not have been added to the BF custoidian repository,
either.
what a custodian chooses to do in their branches is their own business
Agreed - as long as it's in branches you never submit in
101 - 131 of 131 matches
Mail list logo
