Version 8:
- use eeprom_read() instead of i2c_read()
Version 7:
- rebased to the 'next' branch to use new function to manipulate ethaddr
- use setbits_be32 and clrbits_be32
- ide changes move to separate patch
Version 6:
- adjusted kernel console variable to use PSC4
(to reflect recent DTS
Total5200 and digsy MTC use I2C port 2 pins as a ATA chip select.
To avoid adding board-specific ifdefs to cpu/mpc5xxx/ide.c new
define CONFIG_SYS_ATA_CS_ON_I2C2 was introduced. It is used by
Total5200 and will be used by digsy MTC and other boards with
ATA CS on I2C pins.
Signed-off-by: Grzegorz
This is the InterControl custom device based on the MPC5200B chip.
Signed-off-by: Grzegorz Bernacki
---
This patch depends on changes done under first patch in the series,
because it uses define CONFIG_SYS_ATA_CS_ON_I2C2 introduded in there.
MAKEALL |1 +
Makefile
Wolfgang Denk wrote:
> Dear Grzegorz Bernacki,
>
> In message <49ba2c42.5080...@semihalf.com> you wrote:
>>> Is such a scenario (MAC address split across 2 different EEPROM
>>> devices) possible (and supported) on these systems?
>> I think it is possible, cause whole eeprom is threated as a one co
Hi Wolfgang,
please pull a couple of fixes for ppc4xx:
The following changes since commit b3dd629e78870ba2dc9f8032978721c0fa02a856:
Wolfgang Denk (1):
Prepare 2009.03-rc2
are available in the git repository at:
git://www.denx.de/git/u-boot-ppc4xx.git master
Mikhail Zolotaryov (1):
Dear "Pillai, Manikandan",
In message <19f8576c6e063c45be387c64729e73940427cbf...@dbde02.ent.ti.com> you
wrote:
>
> > > - ulong now = readl(&timer_base->tcrr); /* current tick value */
> > > -
> > > - if (now >= lastinc) /* normal mode (non roll) */
> > > - /* move stamp fordward with
On Tue, Mar 17, 2009 at 11:18 AM, Drasko DRASKOVIC <
drasko.drasko...@gmail.com> wrote:
> Actually, I ment U-boot itself. When I said application, I was wrong. I
> ment for example command, which is part of U-Boot. If I want to exit when
> something is wrong within TFTP for example, I cannnot brea
Fix OMAP3 timer handling to 1ms tick and CONFIG_SYS_HZ to 1000.
Clean up macros and comments.
Signed-off-by: Dirk Behme
Signed-off-by: Manikandan Pillai
---
Changes from Mani's original patch which is replaced by this [1]:
* Don't remove overflow handling in get_timer_masked()
* Update omap3_z
Dear Drasko DRASKOVIC,
please keep discussion on the mailing list.
And please don;t top-post / full-quote. Make sure to read
http://www.netmeister.org/news/learn2quote.html
In message <5ec3d7930903170318r76f4786fsdf61ec1e2c11a...@mail.gmail.com> you
wrote:
>
> Actually, I ment U-boot itself. Wh
Dear Jerry Van Baren,
as usual, you are asking a lot of very interesting and important
questions.
The situation is that I already discusses this matte with Jon at
length in private mail, and I have made myu mind up I do not attempt
to register at github.
In message <49bf008f.5090...@gmail.com>
Hello,
Is there a recommended toolchain for building U-Boot on a PowerPC host? I've
used ELDK on x86 hosts in the past for this purpose, and it worked fine, but
now I need to perform it on a PowerPC host. As far as I could see, ELDK wasn't
supported on PowerPC hosts.
My target boards are the MP
David Saada wrote:
> Hello,
> Is there a recommended toolchain for building U-Boot on a PowerPC host? I've
> used ELDK on x86 hosts in the past for this purpose, and it worked fine, but
> now I need to perform it on a PowerPC host. As far as I could see, ELDK
> wasn't supported on PowerPC hosts.
Hi all,
I've finished my port of U-boot 2008.10 to the LPC2468. I've based my
port on code by Embedded Artists, which was based on U-boot 1.1.6.
The LPC2468 is an ARM processor with build in peripherals, so I need to
divide my code into LPC2468 generic part and a part for my board only
(which i
Dear Remco Poelstra,
In message <49bf91d5.2030...@duran-audio.com> you wrote:
>
> I've finished my port of U-boot 2008.10 to the LPC2468. I've based my
> port on code by Embedded Artists, which was based on U-boot 1.1.6.
> The LPC2468 is an ARM processor with build in peripherals, so I need to
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Monday, March 16, 2009 4:56 PM
> To: Hu Mingkai-B21284
> Cc: Fleming Andy-AFLEMING; u-boot@lists.denx.de; Jin Zhengxiong-R64188
> Subject: Re: [U-Boot] [PATCH 5/7] Make a special uboot used
> for booting from SDca
On Mar 17, 2009, at 7:02 AM, Jerry Van Baren wrote:
> David Saada wrote:
>> Hello,
>> Is there a recommended toolchain for building U-Boot on a PowerPC
>> host? I've used ELDK on x86 hosts in the past for this purpose, and
>> it worked fine, but now I need to perform it on a PowerPC host. As
Dear "Hu Mingkai-B21284",
In message
<73839b4a0818e747864426270ac332c303e41...@zmy16exm20.fsl.freescale.net> you
wrote:
>
> > Cannot this be done with U-Boot, or with Linux running on any
> > other system that das a SDCard reader/writer attached to it?
>
> It's hard to do that, in order to supp
Hi Wolfgang,
> When "something is wrong within TFTP", the respective function
> returns an error code, which propagates upward and causes the running
> command to terminate, so you automatically end up back in the U-Boot
> shell.
Yes, I agree but the caller might do something else before
Wolfgang Denk schreef:
> In message <49bf91d5.2030...@duran-audio.com> you wrote:
>> I've finished my port of U-boot 2008.10 to the LPC2468. I've based my
>> port on code by Embedded Artists, which was based on U-boot 1.1.6.
>> The LPC2468 is an ARM processor with build in peripherals, so I need t
Dear Drasko DRASKOVIC,
In message <5ec3d7930903170549sf6337c9l292d9ebef0fdf...@mail.gmail.com> you
wrote:
>
> Quite simple, so I can see where it breaks. Some kind of assert. (Is there
> an assert in U-Boot?)
Instead of vague descriptions like "something is wrong within TFTP"
or "it breaks"
Hello!
I am testing the video display of U-BOOT by using PCI of CANYONLANDS.
I added the following lines.
#ifdef CONFIG_VIDEO
#define CONFIG_BIOSEMU
#define CONFIG_ATI_RADEON_FB
#define VIDEO_IO_OFFSET 0xD800
#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET
#define CONFIG_VIDEO
Dear Remco Poelstra,
In message <49bf9ea5.5040...@duran-audio.com> you wrote:
>
> I fully understand. The problem is that there is a special Ethernet PHY
> on the board which is under a NDA, so I cannot publish code surrounding
> it. I can publish the general part of the ethernet driver.
So you
On Tuesday 17 March 2009, Kazuaki Ichinohe wrote:
> I am testing the video display of U-BOOT by using PCI of CANYONLANDS.
> I added the following lines.
>
> #ifdef CONFIG_VIDEO
> #define CONFIG_BIOSEMU
> #define CONFIG_ATI_RADEON_FB
> #define VIDEO_IO_OFFSET 0xD800
> #define CONFI
Hi Wolfgang,
>Instead of vague descriptions like "something is wrong within TFTP"
>or "it breaks" you could try and post the exact commands you're
>trying and the exact error messages you are seing,
I am sorry for being vague, I hope this example will make it a bit more
clear:
static v
Hi Remco,
Wolfgang Denk wrote:
> Dear Remco Poelstra,
>
> In message <49bf9ea5.5040...@duran-audio.com> you wrote:
>> I fully understand. The problem is that there is a special Ethernet PHY
>> on the board which is under a NDA, so I cannot publish code surrounding
>> it. I can publish the gener
Hi,
While working on cleaning up my LPC2468 port, I was wondering whether
I'm correct in thinking that U-boot has some generic MII interface? My
processor has a MAC which uses (R)MII to communicate with the PHY. Can I
adapt my MAC driver for such interface, so the MAC and PHY code can be
separ
On Tuesday 17 March 2009 10:50:59 Remco Poelstra wrote:
> While working on cleaning up my LPC2468 port, I was wondering whether
> I'm correct in thinking that U-boot has some generic MII interface? My
> processor has a MAC which uses (R)MII to communicate with the PHY. Can I
> adapt my MAC driver f
Hi Wolfgang,
Microblaze code is OK - without build errors.
Thanks,
Michal
Wolfgang Denk wrote:
> Hi Custodians (and everybody else),
>
> can you please check if all urgent patches have been added to the
> U-Boot master branch?
>
> If anything should still be missing, please respond *now*.
>
>
On Mon, Mar 16, 2009 at 04:15:52PM +0100, Ladislav Michl wrote:
> On Sun, Mar 15, 2009 at 05:59:28PM -0400, Mike Frysinger wrote:
> > On Friday 13 March 2009 09:38:19 Ladislav Michl wrote:
> > > nboot command currently does not skip bad blocks and gives read error when
> > > loading image stored ov
From: TsiChung Liew
The serial boot dram extended/standard mode register was not
setup and was using default DRAM setup causing the U-boot was
unstable to boot up in serial mode.
Signed-off-by: TsiChung Liew
---
cpu/mcf5445x/start.S |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
From: TsiChung Liew
Default gzip bootm size is 8MB. Some platforms require
more than 8MB
Signed-off-by: TsiChung Liew
---
include/configs/M52277EVB.h |1 +
include/configs/M5235EVB.h |1 +
include/configs/M5253DEMO.h |1 +
include/configs/M5253EVBE.h |1 +
include/configs/M527
From: TsiChung Liew
The Nand flash was unable to read and write properly
due to Nand Chip Select (nCE) setup was in reverse
order. Also, increase the Nand time out value to 60.
Signed-off-by: TsiChung Liew
---
board/freescale/m5329evb/nand.c |6 --
board/freescale/m5373evb/nand.c |
From: TsiChung Liew
Signed-off-by: TsiChung Liew
---
include/asm-m68k/m5301x.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/asm-m68k/m5301x.h b/include/asm-m68k/m5301x.h
index 52bbb87..80cefc4 100644
--- a/include/asm-m68k/m5301x.h
+++ b/include/asm-m68k/m
From: TsiChung Liew
Update PLATFORM_CPPFLAGS to accept 4.3.x version of
ColdFire compiler.
Signed-off-by: TsiChung Liew
---
cpu/mcf5227x/config.mk |4 ++--
cpu/mcf523x/config.mk|2 +-
cpu/mcf52x2/config.mk|2 +-
cpu/mcf532x/config.mk|2 +-
cpu/mcf5445x/config.mk
Without this, u-boot can crash or print garbage if the original link
address no longer points to a valid string.
Signed-off-by: Scott Wood
---
common/image.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/common/image.c b/common/image.c
index daa68bc..e22c974 100
This board currently sets DBAT6 to cover all of the final 256MiB of
address space; however, not all of this space is covered by a device. In
particular, flash sits at 0xfe00-0xfe7f, and nothing is mapped
at the far end of the address space.
In zlib, there is a loop that references p[-1] i
This was intended to happen before, but a trivial bug prevented it.
Signed-off-by: Scott Wood
---
Applied to u-boot-nand-flash.
common/cmd_nand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index f915fb6..e6623ca 100644
--- a/c
The following changes since commit b3dd629e78870ba2dc9f8032978721c0fa02a856:
Wolfgang Denk (1):
Prepare 2009.03-rc2
are available in the git repository at:
git://git.denx.de/u-boot-nand-flash.git master
Ladislav Michl (1):
NAND: Make nboot skip bad blocks
Scott Wood (1):
On Mon, Mar 16, 2009 at 11:28:24PM +0100, Ladislav Michl wrote:
> Fix NAND support broken during new NAND code merge. Move those few lines of
> code to board/netstar/netstar.c
What was the breakage?
> -/*
> - * hardware specific access to control-lines
> - */
> -#define MASK_CLE0x0
On Fri, Mar 13, 2009 at 06:54:24PM -0500, Peter Tyser wrote:
> This patch series attempts to do 2 things:
> 1. Add support for generating win32 versions of the tools in tools/
> 2. Cleanup tools/Makefile somewhat
>
> In the process of #1 I couldn't help but work on #2 a bit:) Let me
> know if peo
On Tuesday 17 March 2009 13:21:05 Scott Wood wrote:
> On Fri, Mar 13, 2009 at 06:54:24PM -0500, Peter Tyser wrote:
> > This patch series attempts to do 2 things:
> > 1. Add support for generating win32 versions of the tools in tools/
> > 2. Cleanup tools/Makefile somewhat
> >
> > In the process of
On Tuesday 17 March 2009 13:09:31 Scott Wood wrote:
> This board currently sets DBAT6 to cover all of the final 256MiB of
> address space; however, not all of this space is covered by a device. In
> particular, flash sits at 0xfe00-0xfe7f, and nothing is mapped
> at the far end of the addr
On Tuesday 17 March 2009 13:10:15 Scott Wood wrote:
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -502,7 +502,7 @@ static int nand_load_image(cmd_tbl_t *cmdtp,
> nand_info_t *nand,
>
> s = strchr(cmd, '.');
> if (s != NULL &&
> - (strcmp(s, ".jffs2") && !strcmp(s, ".e
On Tue, Mar 17, 2009 at 01:47:04PM -0400, Mike Frysinger wrote:
> On Tuesday 17 March 2009 13:09:31 Scott Wood wrote:
> > This board currently sets DBAT6 to cover all of the final 256MiB of
> > address space; however, not all of this space is covered by a device. In
> > particular, flash sits at 0
On Tue, Mar 17, 2009 at 01:49:20PM -0400, Mike Frysinger wrote:
> On Tuesday 17 March 2009 13:10:15 Scott Wood wrote:
> > --- a/common/cmd_nand.c
> > +++ b/common/cmd_nand.c
> > @@ -502,7 +502,7 @@ static int nand_load_image(cmd_tbl_t *cmdtp,
> > nand_info_t *nand,
> >
> > s = strchr(cmd, '.');
Dear Drasko DRASKOVIC,
In message <5ec3d7930903170638n7769e61anb30f5ce39d704...@mail.gmail.com> you
wrote:
>
> I am sorry for being vague, I hope this example will make it a bit more
> clear:
>
> static void
> TftpTimeout (void)
> {
> if (++TftpTimeoutCount > TIMEOUT_COUNT) {
> puts
On Tuesday 17 March 2009 13:52:27 Scott Wood wrote:
> On Tue, Mar 17, 2009 at 01:47:04PM -0400, Mike Frysinger wrote:
> > On Tuesday 17 March 2009 13:09:31 Scott Wood wrote:
> > > This board currently sets DBAT6 to cover all of the final 256MiB of
> > > address space; however, not all of this space
>>> if C code is doing ptr checks, the compiler should make sure that
>>> pointer is not dereferenced at all if the hardware cannot suffer the
>>> consequences, even speculatively.
>>
>> There is no reasonable way for the compiler to prevent such
>> speculative
>> accesses. Non-memory-like mappi
On Tuesday 17 March 2009 13:55:18 Scott Wood wrote:
> On Tue, Mar 17, 2009 at 01:49:20PM -0400, Mike Frysinger wrote:
> > On Tuesday 17 March 2009 13:10:15 Scott Wood wrote:
> > > --- a/common/cmd_nand.c
> > > +++ b/common/cmd_nand.c
> > > @@ -502,7 +502,7 @@ static int nand_load_image(cmd_tbl_t *c
Mike Frysinger wrote:
>> No. The dereference was on a not-taken side of a conditional branch.
>
> you mean in the shadow ? so something like:
> p = NULL;
> if (p != NULL) {
> /* this is the shadow region */
> }
Yes.
>>> if C code is doing ptr checks, the compiler should make sure that
>>
On Tuesday 17 March 2009 14:13:39 Kumar Gala wrote:
> >>> if C code is doing ptr checks, the compiler should make sure that
> >>> pointer is not dereferenced at all if the hardware cannot suffer the
> >>> consequences, even speculatively.
> >>
> >> There is no reasonable way for the compiler to pre
On Tuesday 17 March 2009 14:18:13 Scott Wood wrote:
> Mike Frysinger wrote:
> >>> if C code is doing ptr checks, the compiler should make sure that
> >>> pointer is not dereferenced at all if the hardware cannot suffer the
> >>> consequences, even speculatively.
> >>
> >> There is no reasonable way
On Tue, Mar 17, 2009 at 12:17:30PM -0500, Scott Wood wrote:
> On Mon, Mar 16, 2009 at 11:28:24PM +0100, Ladislav Michl wrote:
> > Fix NAND support broken during new NAND code merge. Move those few lines of
> > code to board/netstar/netstar.c
>
> What was the breakage?
Blocks being considered bad
Ladislav Michl wrote:
> On Tue, Mar 17, 2009 at 12:17:30PM -0500, Scott Wood wrote:
>> On Mon, Mar 16, 2009 at 11:28:24PM +0100, Ladislav Michl wrote:
>>> Fix NAND support broken during new NAND code merge. Move those few lines of
>>> code to board/netstar/netstar.c
>> What was the breakage?
>
> B
Mike Frysinger wrote:
> the change sounded like you were addressing a specific issue that was
> noticed,
> but other regions could still (in general) cause problems. but i guess that
> isnt the case at all.
I mentioned the specific case mainly to show that it was a problem that
I was actually
Anton Vorontsov wrote:
> On Tue, Mar 17, 2009 at 12:09:31PM -0500, Scott Wood wrote:
>> This board currently sets DBAT6 to cover all of the final 256MiB of
>> address space; however, not all of this space is covered by a device. In
>> particular, flash sits at 0xfe00-0xfe7f, and nothing is
On Tue, Mar 17, 2009 at 02:49:17PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Tue, Mar 17, 2009 at 12:09:31PM -0500, Scott Wood wrote:
>>> This board currently sets DBAT6 to cover all of the final 256MiB of
>>> address space; however, not all of this space is covered by a device. In
>
I'm working on a u-boot port to custom hardware based on the Lite5200B
board, with a MPC5200 processor. u-boot is working great (can boot from 16-bit
flash, SDRAM is working and I can boot linux!) but now I'm working through some
MMU configuration issues, and had a few general questions:
1
On Tue, 2009-03-17 at 13:43 -0400, Mike Frysinger wrote:
> On Tuesday 17 March 2009 13:21:05 Scott Wood wrote:
> > On Fri, Mar 13, 2009 at 06:54:24PM -0500, Peter Tyser wrote:
> > > This patch series attempts to do 2 things:
> > > 1. Add support for generating win32 versions of the tools in tools/
On Tue, Mar 17, 2009 at 12:09:31PM -0500, Scott Wood wrote:
> This board currently sets DBAT6 to cover all of the final 256MiB of
> address space; however, not all of this space is covered by a device. In
> particular, flash sits at 0xfe00-0xfe7f, and nothing is mapped
> at the far end of
On Tue, Mar 17, 2009 at 2:44 PM, SortaSBS Guy wrote:
>
> I'm working on a u-boot port to custom hardware based on the Lite5200B
> board, with a MPC5200 processor. u-boot is working great (can boot from
> 16-bit flash, SDRAM is working and I can boot linux!) but now I'm working
> through some
On Tue, Mar 17, 2009 at 01:44:43PM -0700, SortaSBS Guy wrote:
> 1. Does u-boot/linux make any assumptions about how particular BAT
> registers are used? For example, we're not using PCI, and I was going
> to use those BAT registers to cover some memory-mapped peripheral I/O
> space (ex: icecube.c,
The following changes since commit b3dd629e78870ba2dc9f8032978721c0fa02a856:
Wolfgang Denk (1):
Prepare 2009.03-rc2
are available in the git repository at:
git://git.denx.de/u-boot-coldfire.git master
TsiChung Liew (5):
ColdFire: Fix M54451 serial boot dram setup
Col
On Tuesday 17 March 2009 16:59:39 Peter Tyser wrote:
> On Tue, 2009-03-17 at 13:43 -0400, Mike Frysinger wrote:
> > On Tuesday 17 March 2009 13:21:05 Scott Wood wrote:
> > > On Fri, Mar 13, 2009 at 06:54:24PM -0500, Peter Tyser wrote:
> > > > This patch series attempts to do 2 things:
> > > > 1. Ad
Dear Stefan Roese,
In message <200903171057.28045...@denx.de> you wrote:
> Hi Wolfgang,
>
> please pull a couple of fixes for ppc4xx:
>
> The following changes since commit b3dd629e78870ba2dc9f8032978721c0fa02a856:
> Wolfgang Denk (1):
> Prepare 2009.03-rc2
>
> are available in the gi
Dear Scott Wood,
In message <20090317171044.ga14...@ld0162-tx32.am.freescale.net> you wrote:
> The following changes since commit b3dd629e78870ba2dc9f8032978721c0fa02a856:
> Wolfgang Denk (1):
> Prepare 2009.03-rc2
>
> are available in the git repository at:
>
> git://git.denx.de/u-b
Dear John Rigby,
In message <49c01e46.8010...@freescale.com> you wrote:
> The following changes since commit b3dd629e78870ba2dc9f8032978721c0fa02a856:
>Wolfgang Denk (1):
> Prepare 2009.03-rc2
>
> are available in the git repository at:
>
>git://git.denx.de/u-boot-coldfire.git m
Hello,
Thank you for the reply.
U-boot version: u-boot-2009.01
boot log is the following.
U-Boot 2009.01 ( 3譛 18 2009 - 09:38:17)
・PU: AMCC PowerPC 460EX Rev. A at 600 MHz (PLB=200, OPB=100, EBC=100 MHz)
Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr
The AT91 Linux kernel patches for versions 2.6.27 or later use a separate
atmel_nand.c driver that implements some OOB and ECC options that are not
exactly the same as those in the standard kernel NAND driver (nand_base.c ,
etc.). AT91 based boards can use the CONFIG_MTD_NAND_ATMEL option to enable
sh_eth_reset is function to reset Ether IP.
The MAC address is stored in IP, but it is initialized by this function.
OS (e.g. Linux Kernel) can not use this device when initialized.
This revises this problem.
Signed-off-by: Nobuhiro Iwamatsu
---
drivers/net/sh_eth.c |2 --
1 files changed, 0
Hi Scott,
>Do you see this going into Linux soon? Unless there's some particular
>obstacle to that (other than the code's readiness) I think I'd rather
>wait for it to be accepted there, with (hopefully) more eyes looking over
>it, and then bring the result into u-boot.
All the review comments a
71 matches
Mail list logo
