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
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
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
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
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
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 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
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
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 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,
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 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, 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/
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, 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
>
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
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
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
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
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 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
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
>>
>>> 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
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
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 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, '.');
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 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 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: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 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 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
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):
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
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
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
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
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
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
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 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(-)
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
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 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,
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
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 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
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
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
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 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"
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
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
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
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
> -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
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
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
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.
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
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>
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
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
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
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
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):
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
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
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
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
71 matches
Mail list logo
