Hi Matthias,
Hi Thirumalai
Am 18.05.2010 08:29, schrieb Thirumalai:
Hi Matthias,
I am going to use u-boot alone for my development. Which debugger
is
suitable for debugging u-boot and initial board bringup activity?
My choice is BDI2000. Is it ok.
Yes. As I said. But I never
Dear Timur Tabi,
In message aanlktimff-mm8jlicndervkwwrvpmqeeeuvd_rntm...@mail.gmail.com you
wrote:
And again, the point *I* am trying to make is that it's okay to put the
onus
of that check on the *caller* of fdt_increase_size(), and not on
fdt_increase_size() itself.
OK. I have
Wolfgang,
could you pull u-boot-imx in the time Tom is not available ? Tom has
already merged most of the patches in u-boot-arm, I resend you the
pull-request for completeness:
The following changes since commit ab92d0fd9abd0d4726878a80c6baf3a0f94770b8:
Wolfgang Denk (1):
Merge branch
-Original Message-
From: Mahavir Jain [mailto:mj...@marvell.com]
Sent: Wednesday, May 19, 2010 10:50 AM
To: Prafulla Wadaskar
Cc: Prabhanjan Sarnaik; Ashish Karkare; u-boot@lists.denx.de;
Mahavir Jain
Subject: [PATCH] bugfix: Guruplug: Use standard miiphy call
to reset PHY
On Monday 17 May 2010 10:00:51 Stefan Roese wrote:
The current U-Boot UBI implementation is copied from Linux. In this
porting the UBI background thread was not handled correctly. Upon write
operations ubi_wl_flush() makes sure, that all queued operations, like
page-erase, are completed. But
On Monday 17 May 2010 10:01:05 Stefan Roese wrote:
down_write_trylock needs to return 1 instead of 0 for success.
Otherwise copying a block with a read error (e.g. bit-flip on read)
won't work correctly.
Applied to u-boot-ubi/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH,
This patch adds __io() macro to enable {in|out}[bwl] macros in
arch/arm/asm/io.h
Commit a45dde2293c816138e53c26eca6fd0322583f9a6 uses {in|out}[bwl] macros in
DM9000x and breaks compilation for arm devices.
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
arch/arm/include/asm/io.h |
Mark,
On Tuesday 18 May 2010 22:10:51 mark tomlinson wrote:
Yes we do have 2 flash chips. Here's the mapping:
#define CONFIG_SYS_FLASH_BASE 0xf800 /* 2 chips*16M */
Hmmm. 2 * 16MByte, thats 32MByte == 0x200. So you should have one chip
at base address 0xff00 and one at
Hello,
there is a typo in comment - earlier.
Am 19.05.2010 10:57, schrieb Andreas Bießmann:
This patch adds __io() macro to enable {in|out}[bwl] macros in
arch/arm/asm/io.h
Commit a45dde2293c816138e53c26eca6fd0322583f9a6 uses {in|out}[bwl] macros in
DM9000x and breaks compilation for arm
Wolfgang Denk wrote:
I reject your patch because it introduces the risk of crashing the
system and it appears you do not want to be bothered fixing this.
But I believe I have already fixed it by stating that any users of
fdt_increase_size() must ensure that the new size fits in the allocated
On 18/05/10 08:11, anup behare wrote:
Hi,
While using u-boot for ppc440 based board we are getting *** Warning - bad
CRC, using default environment message.
On denx site we came to know that message is printed because the flash
sector or ERPROM containing the environment variables has never
Wolfgang Denk wrote:
I think the places where strcat() is used actually try and make sure
to have enough room in the target buffer; also, almost all of themn
appent static strigs with well-known sizes only.
You talked about inserting user-supplied data of unknown size.
Yes and no. The
Dear Timur Tabi,
In message 4bf4051a.1090...@freescale.com you wrote:
You make a lot of statements saying that I can do this and I can do
that, but you provide no examples. Have you even looked at the code
to see what such a change would require?
No, I haven't. I don't have to look at that
Hi:
PLS check the ddr2 timing configuration. The function name maybe is
fako_spd(), and there is a data array which stores the ddr2 timing
configuration. About the configuration data, U can find on web.The JEDEC
website may help.
PS: the timing configuration data may be read from an EEPROM
Hi list
I need help and pointers, to get rootfs on ramdisk. I've build kernel and
ram image and when the kernel try to boot, the kernel always want to load
rootfs from NFS. Please see attached output. And I'm not sure how kernel
know here to find ramdisk etc.. Please help with the following:
1.
Your email client cannot read this email.
To view it online, please go here:
http://entourage-group.com/Marketing/display.php?M=77065C=e39d6aea7c75dea17561e294f3c5c716S=20L=12N=17
To stop receiving these
Sorry, no. The flash chips are 0xf800-0xf9ff (32MB). (Actually we have
twice this area reserved for 64MB flash in the future). The flash chip from
0xf800 is also mirrored at 0xfff0 at boot time. I don't know if you
consider this a hardware bug to not have all the flash at the
So I tried to read this whole thread and got lost in the discussion. I'm
wondering of something along the following lines would address your concerns:
#define CONFIG_SYS_FDT_PAD 0x3000
/* Allow for arch specific config before we boot */
int __fdt_board_size(void)
{
return
Dear mark tomlinson,
Please restrict your line length to some 70 characters or so, and stop
posting HTML!
In message 4bf4fc5e02b800012...@gwia.alliedtelesyn.co.nz you wrote:
Sorry, no. The flash chips are 0xf800-0xf9ff (32MB). (Actually we
have twice this area reserved for 64MB
the subject line is incorrect. you dont credit people via summary/changelogs,
you do it via the tags. so if Magnus wrote this patch, he should be credited
with authorship (so use --author when committing). if he gave tips or
something, then perhaps use Reported-by.
-mike
signature.asc
Dear Kumar Gala,
In message 52e9d06a-e721-4907-9024-11bdc8d00...@kernel.crashing.org you wrote:
So I tried to read this whole thread and got lost in the discussion.
I'm wondering of something along the following lines would address your
concerns:
My concerns are simple: if we need to increase
commit c7190f028fa950d4d36b6d0b4bb3fc72602ec54c mpc83xx:
retain POR values of non-configured ACR, SPCR, SCCR, and LCRR
bitfields incorrectly shifted register_bitfield (e.g.
ACR_PIPE_DEP) values that were preshifted by their
definition in mpc83xx.h.
this patch removes the unnecessary shifting for
Wolfgang Denk wrote:
Why would this in any way be a board specific implementation? This
makes no sense to me. The feature to include some binary data into the
DTB is IMO in no way dependent on or specific to a certain board.
The data I'm trying to embed is firmware for various devices on some
On Tuesday 18 May 2010 01:26:35 Mark Tomlinson wrote:
Some calls to flash_protect() do not check that info is not
NULL. This change prevents this from causing random memory to
be stomped on.
---
any patches need a s-o-b tag before they'll be accepted
NOTICE: This message contains privileged
Introduce function fdt_get_max_phandle(), which returns the largest value
of all phandles in a device tree. This is useful for allocating a new phandle
property, since all phandles must be unique.
Signed-off-by: Timur Tabi ti...@freescale.com
---
include/libfdt.h| 20
Hi,
I have a question about watchdog support for PPC_4xx. When I define
CONFIG_WATCHDOG in canyonlands.h, I get an error when building
cpu_init.c. The error code reads:
{standard input}: Assembler messages:
{standard input}:133: Error: unsupported relocation against tcr
{standard
On Friday 14 May 2010 18:00:04 Thomas Chou wrote:
The -ffixed-r15 option doesn't work well for gcc4. Since we
don't use gp for small data with option -G0, we can use gp
as global data pointer. This allows compiler to use r15. It
is necessary for gcc4 to work properly.
Signed-off-by: Thomas
Disclaimer: I'm workmate of Mark's
Wolfgang Denk wd at denx.de writes:
It's not a hardware bug, but a configuration error.
f800-fbff 64M Flash
fe00-fe0f1M Battery-backed RAM
ff00-ff00 64K On-board logic
ff70-ff7f1M CCSR
On Wed, 2010-05-19 at 01:38 -0700, Prafulla Wadaskar wrote:
-Original Message-
From: Mahavir Jain [mailto:mj...@marvell.com]
Sent: Wednesday, May 19, 2010 10:50 AM
To: Prafulla Wadaskar
Cc: Prabhanjan Sarnaik; Ashish Karkare; u-boot@lists.denx.de;
Mahavir Jain
Subject:
On Saturday 15 May 2010 20:35:32 Wolfgang Denk wrote:
--- a/mkconfig
+++ b/mkconfig
@@ -22,7 +22,7 @@ while [ $# -gt 0 ] ; do
esac
done
-[ ${BOARD_NAME} ] || BOARD_NAME=$1
+[ ${BOARD_NAME} ] || BOARD_NAME=${1%%_config}
[ $# -lt 4 ] exit 1
[ $# -gt 6 ] exit 1
@@ -102,7
On Wednesday 19 May 2010 04:38:41 Prafulla Wadaskar wrote:
-Original Message-
From: Mahavir Jain [mailto:mj...@marvell.com]
Sent: Wednesday, May 19, 2010 10:50 AM
To: Prafulla Wadaskar
Cc: Prabhanjan Sarnaik; Ashish Karkare; u-boot@lists.denx.de;
Mahavir Jain
Subject: [PATCH]
Mike Frysinger wrote:
On Friday 14 May 2010 18:00:04 Thomas Chou wrote:
The -ffixed-r15 option doesn't work well for gcc4. Since we
don't use gp for small data with option -G0, we can use gp
as global data pointer. This allows compiler to use r15. It
is necessary for gcc4 to work properly.
in reviewing some phy code i noticed that there's quite a good bit of
duplication between miiphy.h and linux/mii.h. i imagine this is largely
historical as miiphy.h dates back quite a long time, but moving forward,
should we just do a mass conversion from the u-boot specific miiphy.h defines
Hi Nick,
I observed that when i used saveenv the warning never occurred, but when i
used to erase the flash and burn the u-boot that warning comes again hence I
will have to use saveenv on u-boot command prompt.
~Anup
On Wed, May 19, 2010 at 8:54 PM, Nick Thompson nick.thomp...@ge.com wrote:
Hi Mike,
On Wed, May 19, 2010 at 7:25 PM, Mike Frysinger vap...@gentoo.org wrote:
in reviewing some phy code i noticed that there's quite a good bit of
duplication between miiphy.h and linux/mii.h. i imagine this is largely
historical as miiphy.h dates back quite a long time, but moving
Thanks Mike,
On Mon, May 10, 2010 at 11:43 PM, Mike Frysinger vap...@gentoo.org wrote:
Ben: ive pushed all these AX88180 patches to here so you can pull them in
order easier:
git://git.denx.de/u-boot-blackfin.git for-net
-mike
Sorry for the delay. I'll try to take care of this
36 matches
Mail list logo
