> -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
>
> mvsata_ide_in
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-.
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 indee
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
---
Scott's c
On Wed, 8 Sep 2010 22:43:48 +0200
Wolfgang Denk 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 b
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 l
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 co
On Wed, 8 Sep 2010 22:32:56 +0200
Wolfgang Denk 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 j
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-Bo
On Wed, 8 Sep 2010 01:04:39 +0200
Wolfgang Denk 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 any other l
>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
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
---
drivers/net/fec_mxc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
ind
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
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 sp
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 relativel
Dear Daniele Capuano,
In message 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 Angstrom validation
> kernel/rootfs, and it works fine, but
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
>
> 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-b
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 th
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 = eth_get_de
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);
>> +
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
(http://www.beagleboard.
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
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.
__
On Wed, Sep 8, 2010 at 10:07 AM, Mike Frysinger 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 your immediate
>
> On Wed, 8 Sep 2010 05:53:57 -0700
> Steve Sakoman 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 M
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 firs
On Wed, 8 Sep 2010 05:53:57 -0700
Steve Sakoman 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
>
> Signed-off-by:
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->eneta
From: Ricardo Salveti de Araujo
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 signal description
comments.
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 chang
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
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 b
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:
http://old.
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
watchdo
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 cal
Dear Reinhard Meyer,
In message <4c875885.9020...@emk-elektronik.de> you wrote:
>
> Not sure about that. I was thinking of a simple script that reads Linux'
> mach-types.h (or arch/arm/tools/mach-types directly) and generates the
> u-boot's mach-types.h file on the fly. That way only the #define l
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
---
drivers/mtd/nand/nand_base.c |9 ++---
1 files chan
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 Cooper
[...]
> diff --git a/board/Marvell/dockstar/dockstar.c
> b/board/Marvell/dockstar/dockstar.c
> index 13cd347..7788837 100644
>
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 a
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
>> offic
On Wed, Sep 8, 2010 at 5:05 PM, Wolfgang Denk wrote:
> Dear Paul Hsu,
>
> In message 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 h
On Wed, 8 Sep 2010 11:08:49 +0200
Srigopal Kalyanaraman 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 mailing list
U-Boot@lists
use a union to cause necessary alignment per architecture
Signed-off-by: Reinhard Meyer
---
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 20319e6..d0480f5 100644
--- a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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 bey
Dear Paul Hsu,
In message 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 problem manifest?
You did not answer this question. Do
Dear Wolfgang Denk,
> 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-bo
On Wed, Sep 8, 2010 at 4:16 PM, Wolfgang Denk wrote:
> 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
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 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 n
On 08.09.2010 09:48, Wolfgang Denk wrote:
> 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];
+
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
---
Makefile | 15 +++
1 files changed, 15 insertions(+), 0 dele
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];
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 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 sy
56 matches
Mail list logo
