Thanks Mike,
On Mon, May 10, 2010 at 11:43 PM, Mike Frysinger 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 tomorrow.
regard
Hi Mike,
On Wed, May 19, 2010 at 7:25 PM, Mike Frysinger 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 forward,
> should w
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 wrote:
> On 18/05/10 08:11,
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
t
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
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
> > Sub
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 ] &&
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
>
Disclaimer: I'm workmate of Mark's
Wolfgang Denk 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
> > fff
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
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 input}
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
---
include/libfdt.h| 20
lib/libfdt/fdt_ro.c
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 privil
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 som
commit c7190f028fa950d4d36b6d0b4bb3fc72602ec54c "mpc83xx:
retain POR values of non-configured ACR, SPCR, SCCR, and LCRR
bitfields" incorrectly shifted _ (e.g.
ACR_PIPE_DEP) values that were preshifted by their
definition in mpc83xx.h.
this patch removes the unnecessary shifting for the newly
utili
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 incr
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
Descr
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
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 CONFIG_SYS_FDT
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 ve
Your email client cannot read this email.
To view it online, please go here:
http://entourage-group.com/Marketing/display.php?M=77065&C=e39d6aea7c75dea17561e294f3c5c716&S=20&L=12&N=17
To stop receiving these
emails:http://entourage-group.com/Marketing/unsubscribe.php?M=77065&C=e39d6aea7c75dea175
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. A
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
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 a
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
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 ha
Dear Timur Tabi,
In message <4bf3fc6d.4000...@freescale.com> you wrote:
>
> 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
> area. The same rules apply to functions like strcat(), so I don't
> understan
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
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 a
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 0xfe
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
---
arch/arm/include/asm/io.h |7 +++
1 files cha
The following changes since commit a2a0a7171303de5d8ce099344efde2e29ee36eb0:
Makefile: fix out-of-tree building of "u-boot.img" target (2010-05-16
02:18:38 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-ubi.git master
Stefan Roese (2):
UBI: Ensure that "ba
Current PHY Software Reset operation in guruplug does not
poll reset bit in control register to go to 0(auto clearing)
for making sure reset was successful.This patch uses standard
miiphy call miiphy_reset to make sure proper PHY reset operation.
Signed-off-by: Mahavir Jain
---
board/Marvell/gur
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 Gm
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. Bu
> -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
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 '
37 matches
Mail list logo
