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
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
---
Makefile | 15 +++
1 files changed, 15 insertions(+), 0 dele
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];
+
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
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
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 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
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 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
___
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
---
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
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
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
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
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
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
>
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
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
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
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
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.
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
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 chang
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.
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
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 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 M
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 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
(http://www.beagleboard.
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 = eth_get_de
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
>
> 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
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 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",
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 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
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
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
>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
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
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 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 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
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
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
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, 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
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-.
> -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
56 matches
Mail list logo
