-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Wednesday, September 08, 2010 2:55 AM
To: Prafulla Wadaskar
Cc: Tom Rix; u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare
Subject: Re: Pull request u-boot-marvell.git
Dear Prafulla Wadaskar,
In
Dear Prafulla Wadaskar,
In message f766e4f80769bd478052fb6533fa745d19a6879...@sc-vexch4.marvell.com
you wrote:
Hm... when pulling as instructed I also got this commit which you do
not mention here:
I am sorry about this, I added it after sending this request.
No problem.
As this is
Dear all,
#define MACH_TYPE_WLAN_COMPUTER2966
+#define MACH_TYPE_DOCKSTAR 2998
NAK. We don't edit mach-types.h manually.
If you need it updated, please send a request to do so to the acting
ARM custodian (ahem).
But also note that we always sync against
On Wednesday, September 08, 2010 01:43:20 Wolfgang Denk wrote:
Mike Frysinger wrote:
which bug ? the logic is:
for (...)
if (...)
... = ...;
you want the for loop to have explicit braces ?
for (...) {
Dear Reinhard Meyer,
In message 4c87065a.5050...@emk-elektronik.de you wrote:
Dear Wolfgang Denk,
+ /* linebuf as a union causes proper alignment */
+ union linebuf {
+ uint32_t ui[MAX_LINE_LENGTH_BYTES/4 + 1];
+ uint16_t us[MAX_LINE_LENGTH_BYTES/2 + 1];
+
If we use $(CC -print-libgcc-file-name) without option -march=armv4t,
we will link the wrong version libgcc.a(for ARMv5).
That causes cpu core raising excptions when u-boot running on the board.
Signed-off-by:Paul Hsu pochun@gmail.com
---
Makefile | 15 +++
1 files changed, 15
On 08.09.2010 09:48, Wolfgang Denk wrote:
Dear Reinhard Meyer,
In message4c87065a.5050...@emk-elektronik.de you wrote:
Dear Wolfgang Denk,
+ /* linebuf as a union causes proper alignment */
+ union linebuf {
+ uint32_t ui[MAX_LINE_LENGTH_BYTES/4 + 1];
+ uint16_t
Dear Reinhard Meyer,
In message 4c873717.6000...@emk-elektronik.de you wrote:
Since it apparently takes roughly two months for additions to the database
at http://www.arm.linux.org.uk/developer/machines/ (last entry: 3061 right
now)
to trickle to the u-boot file, there seems to be a need
Dear Paul Hsu,
In message 1283932498-8989-1-git-send-email-pochun@gmail.com you wrote:
If we use $(CC -print-libgcc-file-name) without option -march=armv4t,
we will link the wrong version libgcc.a(for ARMv5).
That causes cpu core raising excptions when u-boot running on the board.
On
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message4c873717.6000...@emk-elektronik.de you wrote:
Since it apparently takes roughly two months for additions to the database
at http://www.arm.linux.org.uk/developer/machines/ (last entry: 3061 right
now)
to trickle to the u-boot file, there
Dear Paul Hsu,
In message aanlktin=dbkihngho2w+knxac3mk9tfjacqd9d8bw...@mail.gmail.com you
wrote:
On which tool chain is this causing problems?
I use toolchain released by code sourcery(Sourcery G++ Lite 2010q1-202
for ARM GNU/Linux).
Thanks for the information.
And how does this
Dear Reinhard Meyer,
In message 4c874c02.9030...@emk-elektronik.de you wrote:
I'm open to suggestions.
I'd allow manual adding of a #define MACH_TYPE_ at the end of the list
provided its value is higher than the last official entry. Once the official
list reaches or goes beyond that
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
use a union to cause necessary alignment per architecture
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
lib/display_options.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index
On Wed, 8 Sep 2010 11:08:49 +0200
Srigopal Kalyanaraman ksrigo...@gmail.com wrote:
This is something you supposed to do yourself. Please see [1]
for more details.
Best regards,
Anatolij
[1] http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot
On Wed, Sep 8, 2010 at 5:05 PM, Wolfgang Denk w...@denx.de wrote:
Dear Paul Hsu,
In message aanlktin=dbkihngho2w+knxac3mk9tfjacqd9d8bw...@mail.gmail.com you
wrote:
On which tool chain is this causing problems?
I use toolchain released by code sourcery(Sourcery G++ Lite 2010q1-202
for
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4c874c02.9030...@emk-elektronik.de you wrote:
I'm open to suggestions.
I'd allow manual adding of a #define MACH_TYPE_ at the end of the list
provided its value is higher than the last official entry. Once the
official
list
Dear Eric Cooper,
please keep the mailing list on Cc:
In message 20100908010601.gg8...@localhost you wrote:
Also, please rebase your code on top of Heiko's ARM rework patches
(enable caches, add relocation). These will go in before your board
support.
Thanks for your comments and your
Hello.
On 07-09-2010 18:28, Eric Cooper wrote:
derived from patches posted by Jeff Doozan
in the uBoot forum at http://forum.doozan.com
Signed-off-by: Eric Coopere...@cmu.edu
[...]
diff --git a/board/Marvell/dockstar/dockstar.c
b/board/Marvell/dockstar/dockstar.c
index 13cd347..7788837
This printk was added recently and results in ugly output on systems
with no NAND:
NAND: nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00, Chip
ID: 0x00 0 MiB
instead of:
NAND: 0 MiB
Signed-off-by: Steve Sakoman st...@sakoman.com
---
drivers/mtd/nand/nand_base.c |9
As usually done in U-Boot, the watchdog_reset code is called via a
macro (WATCHDOG_RESET). In zlib.c this was done differently, by using
a function pointer which is initialized with WATCHDOG_RESET upon watchdog
usage or with NULL otherwise. This patch now uses the plain
WATCHDOG_RESET macros to
Patch 253cb831 [zlib: add watchdog reset call] added already a few
watchdog reset calls to the new zlib U-Boot port. But on some boards
this is not enough. Additional calls are needed on boards with
short watchdog timeouts.
This was detected and tested on the lwmon5 board with a very short
Hi
Im new to u-boot. Right now im in the process of customizing P4080DS(RDB) to
my board.
My doubt is, for P4080 the reset vec address is 0x0__fffc.
1) But in the config.mk file it is mentioned as 0xefff_fffc wat it mean?.
Regards
M.Arunkumar
--
View this message in context:
On Sep 8, 2010, at 8:48 AM, MArunKumar wrote:
Hi
Im new to u-boot. Right now im in the process of customizing P4080DS(RDB) to
my board.
My doubt is, for P4080 the reset vec address is 0x0__fffc.
1) But in the config.mk file it is mentioned as 0xefff_fffc wat it mean?.
This is
The U-Boot code has the following bugs related to the processing of Long File
Name (LFN) entries scattered across several clusters/sectors :
1) get_vfatname() function is designed to gather scattered LFN entries by
cluster chain processing - that doesn't work for FAT12/16 root directory.
In other
The case I am personally dealing with is one where there is no
persistent storage
for ethaddr. Booting from and SD card and a script is run that sets
the ethaddr.
Currently eth_init updates dev-enetaddr for each device but does not call
dev-write_hwaddr. This seems like a bug not a policy
From: Ricardo Salveti de Araujo ricardo.salv...@canonical.com
Correctly set PAD1_FREF_CLK4_REQ and PAD0_FREF_CLK4_OUT to enable and
activate both LEDs while setting pad mux.
Since this increases the line length, this patch also adjusts the white
space in this section of code to align the pad mux
On Wednesday, September 08, 2010 11:06:54 John Rigby wrote:
please do not top post
The case I am personally dealing with is one where there is no
persistent storage
for ethaddr. Booting from and SD card and a script is run that sets
the ethaddr.
Currently eth_init updates dev-enetaddr
On Wed, 8 Sep 2010 05:53:57 -0700
Steve Sakoman st...@sakoman.com wrote:
This printk was added recently and results in ugly output on systems
with no NAND:
NAND: nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00, Chip
ID: 0x00 0 MiB
instead of:
NAND: 0 MiB
On Wednesday, September 08, 2010 04:04:37 Reinhard Meyer wrote:
I am working with too many (non-gnu) C compilers and have seen too many
ways for attribute, #pragma, etc. So I prefer to do things
within the standard C language ;)
which is entirely why linux/compiler.h exists in the first place
On Wed, 8 Sep 2010 05:53:57 -0700
Steve Sakoman st...@sakoman.com wrote:
This printk was added recently and results in ugly output on systems
with no NAND:
NAND: nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00,
Chip ID: 0x00 0 MiB
instead of:
NAND: 0 MiB
On Wed, Sep 8, 2010 at 10:07 AM, Mike Frysinger vap...@gentoo.org wrote:
and if you read the doumentation, you'll see that you're mistaken. whatever
device you're dealing with (today) is missing a call to its own write_hwaaddr
function inside of its own init function.
if you want to fix
On Wednesday, September 08, 2010 13:11:14 John Rigby wrote:
One more question however, why does eth_initialize call dev-write_hwaddr?
as part of the debate program the MAC without actually using the network
-mike
signature.asc
Description: This is a digitally signed message part.
mvsata_ide_initialize_port(): adjust init sequence (SStatus
should be checked only after all writes to SControl) and
return success/failure to ide_preinit().
Also, as some tests showed init durations in the hundreds
of us, raise the time-out to 01 ms to be on the safe side.
Signed-off-by: Albert
I have a similar issue: I have a beagleboard rev C4 and I'm trying to use a
custom kernel instead of Angstrom. I downloaded the last u-boot using git
from git://gitorious.org/beagleboard-validation/u-boot.git
I compiled this u-boot and then I compiled the MontaVista kernel
Dear Mike Frysinger,
On Monday, September 06, 2010 10:59:16 Reinhard Meyer wrote:
+int enc_miiphy_read(const char *devname, u8 phy_adr, u8 reg, u16 *value)
+{
+struct eth_device *dev = eth_get_dev_by_name(devname);
+if (dev) {
+enc_dev_t *enc = to_enc(dev);
+
+
Dear Reinhard Meyer,
In message 4c87cfe8.8010...@emk-elektronik.de you wrote:
Dear Mike Frysinger,
On Monday, September 06, 2010 10:59:16 Reinhard Meyer wrote:
+int enc_miiphy_read(const char *devname, u8 phy_adr, u8 reg, u16 *value)
+{
+ struct eth_device *dev =
Hello,
I have a BeagleBoard revC4 and I'm trying to use the MontaVista kernel
found at http://www.beagleboard.org/~arago/esc-boston-2009/mvista/.
I've already tryed to boot the board with the Angstrom validation
kernel/rootfs, and it works fine, but I need the RT capability, thus
Angstrom is not
No. This will quicklly result in a maze of merge conflicts.
We will always only update the file as a whole. THe only option I'm
willing to discuss is where to get the file from.
One catch remains, of course: I someone changed their entry at the
database,
compilation of u-boot for
Dear Paulraj, Sandeep,
We are in sync with the latest in linux kernel
Take a look at
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=arch/arm/tools/mach-types;h=48cbdcb6bbd4288929f31bef94da3691b160a489;hb=917977d107c9640dbb29ce85542735ad56e3aa5a
Please read the
Dear Daniele Capuano,
In message aanlktimavfemmmtgqiym0tsao=xtkolz=4rvpunwc...@mail.gmail.com you
wrote:
I have a BeagleBoard revC4 and I'm trying to use the MontaVista kernel
found at http://www.beagleboard.org/~arago/esc-boston-2009/mvista/.
I've already tryed to boot the board with the
Dear Paulraj, Sandeep,
In message 0554bef07d437848af01b9c9b5f0bc5da8aa8...@dlee01.ent.ti.com you
wrote:
We are in sync with the latest in linux kernel
Yes, I know.
The problem we're discussing is that the version of mach-types.h as
included in the mainline LInux kernel tree is relatively old
Dear Wolfgang Denk,
Yes, error handling blows up the code. But it helpos a lot to make
programs reliable and robust.
Of course I will add that.
And in theory it could help.
In reality no SPI drivers check for conflicting
claims - and therefore notoriously return ZERO.
A nice example:
int
In message 1282170453-16794-1-git-send-email...@denx.de you wrote:
commit 47e26b1b cmd_usage(): simplify return code handling caused
the following compile warnings:
bedbug_860.c: In function 'bedbug860_do_break':
bedbug_860.c:73: warning: 'return' with a value, in function returning void
call fec_set_hwaddr in init routine to setup MAC address
so when ethaddr is set late the change will propagate to the hw
Signed-off-by: John Rigby john.ri...@linaro.org
---
drivers/net/fec_mxc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fec_mxc.c
Yes, I know.
The problem we're discussing is that the version of mach-types.h as
included in the mainline LInux kernel tree is relatively old when
compared to the current state of the ARM machine registry. The
question was if we should risk using something else as reference.
There is no need
On Wed, 8 Sep 2010 01:04:39 +0200
Wolfgang Denk w...@denx.de wrote:
Or should u-boot just gain a new image type for zImage?
Why not use uImage like we do with other architectures?
Whereas they'd say why can't U-Boot accept a simple binary, and just
run it in place without copying, like
Dear Scott Wood,
In message 20100908152335.6d280...@schlenkerla.am.freescale.net you wrote:
Why not use uImage like we do with other architectures?
Whereas they'd say why can't U-Boot accept a simple binary, and just
run it in place without copying, like any other loader can?
U-Boot can
On Wed, 8 Sep 2010 22:32:56 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Scott Wood,
In message 20100908152335.6d280...@schlenkerla.am.freescale.net you wrote:
Why not use uImage like we do with other architectures?
Whereas they'd say why can't U-Boot accept a simple binary, and
Dear Kumar Gala,
In message 032f2ee7-6c88-4c83-af81-55874220f...@kernel.crashing.org you wrote:
Can you retry w/top of tree and let me know results. I tried this w/o
seeing any issues. The build failures I'm getting are with:
P2020DS_36BIT
This gives just a harmless (but pretty common)
Dear Scott Wood,
In message 20100908153455.527fc...@schlenkerla.am.freescale.net you wrote:
Why not use uImage like we do with other architectures?
Whereas they'd say why can't U-Boot accept a simple binary, and just
run it in place without copying, like any other loader can?
On Wed, 8 Sep 2010 22:43:48 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Scott Wood,
In message 20100908153455.527fc...@schlenkerla.am.freescale.net you wrote:
Why not use uImage like we do with other architectures?
Whereas they'd say why can't U-Boot accept a simple binary,
This patch provides support for MPC8308 P1M board with the following
set of features:
Dual UART is supported
NOR flash is supported
Both TSEC Ethernet controllers are supported
PCI Express initialization is supported
Both I2C controllers are supported
Signed-off-by: Ilya Yanok
On Wed, Sep 08, 2010, Wolfgang Denk wrote:
zImage does not contain any visible information about what it is,
when it was build, etc. It is not checksum protected so you cannot
verify if the image you just downloaded is good enough to erase what
you have in flash, etc. etc.
These are indeed
On Sep 8, 2010, at 3:41 PM, Wolfgang Denk wrote:
Ah, I see - this happens when building with a generic PPC toolchain
like ELDK's ppc_6xx-; when using ppc_85xxDP- instead the build
succeeds.
Does this give you a hint how to fix this?
Not terribly, but I was using ppc_85xxDP-. Will try
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
Sent: Wednesday, September 08, 2010 11:01 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3] mvsata_ide: adjust port init sequence
56 matches
Mail list logo
