On Sat, 08 Mar 2008 02:03:02 +0100
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > but these are the filenames in linux' device tree directory -
> > arch/powerpc/boot/dts, and I'm assuming people do something sane like
> > dtc -I $file.dts -O $file.dtb.
On 3/6/08 9:30 AM, Grant Erickson wrote:
> I am continuing some experiments in booting Linux w/ a flattened device tree
> via u-boot (1.3.2-rc3) from JFFS2 on NAND on an AMCC "Haleakala" board and am
> curious if anyone has come up with some quantitative performance
> characterizations of the vario
In message <[EMAIL PROTECTED]> you wrote:
>
> I'm with Kim & Timur on this one. The kernel is in the driver's seat on
> the .dts, and thus the .dtb file names for these targets.
That does not necessarily mean that the kernel is always right and
that U-Boot must always follow it's errors.
Bes
In message <[EMAIL PROTECTED]> you wrote:
>
> but these are the filenames in linux' device tree directory -
> arch/powerpc/boot/dts, and I'm assuming people do something sane like
> dtc -I $file.dts -O $file.dtb.
Argh... what a mess.
> are you suggesting we rename u-boot's config files too?
Well
In message <[EMAIL PROTECTED]> you wrote:
>
> > I don't think this is a good idea. File names and board config names
> > should match as far as possible, and here is no good reason to
> > deviate from this rule.
>
> But the DTS files have already been renamed. The DTS for the MPC832xE-MDS
When rtl_recv() of rtl8169 is called, OWNbit of status register
is not enable occasionally.
rtl_recv() doesn't work normally when the driver doesn't do
appropriate processing.
This patch fix this problem.
Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
---
drivers/net/rtl8169.c | 18 ++
Hello, Mark.
On Fri, 7 Mar 2008 23:05:16 +0100
"Mark Jonas" <[EMAIL PROTECTED]> wrote:
> Hello Nobuhiro,
>
> > > the attached patch adds support for the Renesas SH7720 based board MPR2.
> >
> > Please transmit the patch by the text without settling with tar. Could you
> > send it again?
>
>
All,
I just upgraded U-Boot from 1.1.6 to 1.3.2-rc3 on a MPC8555CDS
and it seems TSEC isn't working. I see the same on another one,
but only after rebooting from FreeBSD. In that case a reset
from U-Boot resolves the problem. This board however always has
a link problem.
Is this a know issue?
Has
Hello Nobuhiro,
> > the attached patch adds support for the Renesas SH7720 based board MPR2.
>
> Please transmit the patch by the text without settling with tar. Could you
> send it again?
Attached you'll find the uncompressed patch this time. In my previous
post the patch was not tared but co
Hi Ben,
> Your intentions are good, but you have to know that there's no way this
> driver is going into U-boot unless it meets the coding standards. There
> are many reasons for this policy, but suffice to say it just ain't gonna
> happen.
OK, I somehow thought so but isn't there this claus
> Have you checked out the new AT91SAM9XE512?
> Basically the same chip as the AT91SAM9260 and has 512 kB flash
> and 32 kB SRAM. Only big difference is that the SAM9XE has
> 2 x TWI instead of one, and only 6 serial ports instead of 7.
>
> I think it would be much easier to get U-boot running
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> OK, here is a simulation of what I will create tonight. I think this is
>> both workable, very effective, and meets Wolfgang's constraints.
>
> I like it.
>
>> > ./dots 99
>> Writing to Flash... 0123456
Kim Phillips wrote:
> On Fri, 07 Mar 2008 20:38:31 +0100
> Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>
>> In message <[EMAIL PROTECTED]> you wrote:
>>> the dts file basenames were updated in linux - this helps avoid
>>> inadvertently loading any old dtbs laying around.
>>>
>>> Signed-off-by: Kim Ph
On Fri, 07 Mar 2008 20:38:31 +0100
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > the dts file basenames were updated in linux - this helps avoid
> > inadvertently loading any old dtbs laying around.
> >
> > Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Wolfgang Denk wrote:
>> - "fdtfile=mpc832xemds.dtb\0"
>> \
>> + "fdtfile=mpc832x_mds.dtb\0"
>> \
>
> I don't think this is a good idea. File names and board config names
> should match as far as
In message <[EMAIL PROTECTED]> you wrote:
>
> > In message <[EMAIL PROTECTED]> you wrote:
> > >
> > > There is no way to add an end marker without using a new line (or use
> > > '\r' which is really unacceptable, and more justifiably so). Since we
> > > are settling in on having 50 (?probably wa
In message <[EMAIL PROTECTED]> you wrote:
> the dts file basenames were updated in linux - this helps avoid
> inadvertently loading any old dtbs laying around.
>
> Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
> ---
> include/configs/MPC832XEMDS.h |2 +-
> include/configs/MPC8360EMDS.h |
In message <[EMAIL PROTECTED]> you wrote:
>
> OK, here is a simulation of what I will create tonight. I think this is
> both workable, very effective, and meets Wolfgang's constraints.
I like it.
> > ./dots 99
> Writing to Flash... 0123456789 Done
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulf Samuelsson wrote:
> - Original Message -
> From: "Cory T. Tusar" <[EMAIL PROTECTED]>
> To:
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, March 06, 2008 10:05 PM
> Subject: [U-Boot-Users] arm920t RAM relocation broken?
>
>
>> -BEGIN PGP
Wolfgang,
Please pull mpc83xx; it has a patch you missed that was posted here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/37339
and the dtb rename patch I just posted:
The following changes since commit bd4458cb47abecabd406b1210457be96c69fc49d:
Dave Liu (1):
837xEMDS: Impr
On Fri, 07 Mar 2008 17:33:34 +0100
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > There is no way to add an end marker without using a new line (or use
> > '\r' which is really unacceptable, and more justifiably so). Since we
> > are settling in on
the dts file basenames were updated in linux - this helps avoid
inadvertently loading any old dtbs laying around.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
include/configs/MPC832XEMDS.h |2 +-
include/configs/MPC8360EMDS.h |2 +-
include/configs/MPC837XEMDS.h |2 +-
include/
Andy Pont wrote:
> Hello,
>
> I am trying to get MontaVista Linux Pro 5.0 to run on
> the Freescale MPC8349-mITX-GP reference platform using
> U-Boot 1.3.2-rc2. When I try to start my kernel I get
> the following output:
>
> MPC8349E-mITX-GP> bootm $loadaddr - $fdtaddr
> ## Booting image at 00a0
On Fri, Mar 07, 2008 at 05:13:32PM +, Andy Pont wrote:
> WARNING: could not create /chosen FDT_ERR_NOSPACE.
> ERROR: /chosen node create failed - must RESET the
> board to recover.
> Resetting the board.
>
> Is this error a problem with the way that U-Boot is
> setting up the FDT or is it a pr
Hello,
I am trying to get MontaVista Linux Pro 5.0 to run on
the Freescale MPC8349-mITX-GP reference platform using
U-Boot 1.3.2-rc2. When I try to start my kernel I get
the following output:
MPC8349E-mITX-GP> bootm $loadaddr - $fdtaddr
## Booting image at 00a0 ...
Image Name: Linux-2.6
Wolfgang Denk wrote:
[snip]
> But there is also a few other things to consider: keeping the output
> terse and efficient; keeping the same look and feel acrross different
> boards and platforms, etc. If you add such code to the CFI driver,
> users might request that such code also gets added
On Fri, Mar 07, 2008 at 10:26:09AM -0600, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 06:04:54PM +0300, Anton Vorontsov wrote:
> > +#define CFG_OR1_PRELIM (0x8000 | /* length 32K
> > */ \
> > +OR_FCM_CSCT | \
> > +OR
On Fri, 2008-03-07 at 00:38, Stefan Roese wrote:
> I insist on nothing. I'm just pointing out, that the current implementation
> can be enhanced.
How about adding a CONFIG_CFI_SHOW_PROGRESS option
that enable/disables this feature as well?
jdl
In message <[EMAIL PROTECTED]> you wrote:
>
> There is no way to add an end marker without using a new line (or use
> '\r' which is really unacceptable, and more justifiably so). Since we
> are settling in on having 50 (?probably want to use a #define) dots
> unless there are fewer than 50 unit
Hi,
> I would like to know this for my 64MB RAM.Is there any place in any
> config file or somewhere in uboot code where this address range is
> defined?
have a look at relocate_code, should be in start.S (assembly). Some config
values are used for the calculation of the address. As far as I rem
In message <[EMAIL PROTECTED]> you wrote:
>
> I would like to know at what address range of RAM uboot runs?
>
> I would like to know this for my 64MB RAM.Is there any place in any
> config file or somewhere in uboot code where this address range is
> defined?
It is considered extremely bad manner
On Fri, Mar 07, 2008 at 06:04:54PM +0300, Anton Vorontsov wrote:
> +#define CFG_OR1_PRELIM (0x8000 | /* length 32K
> */ \
> + OR_FCM_CSCT | \
> + OR_FCM_CST | \
> + OR_FCM_CHT | \
> +
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> I was too terse. The problem is that I added a progress bar.
>> Previously, the printout sequence was:
>>Writing to Flash...
>> followed by an indeterminate wait, followed by the string "done." which
>> formed the composite:
On 07/03/2008, Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> wrote:
>
> Hi Richard,
>
> Thanks for your answer.
>
> On ven, 2008-03-07 at 14:58 +, Richard Danter wrote:
> On 07/03/2008, Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> wrote:
> > How I can load (and start) an EST Flat Bin image?
Hi All,
I would like to know at what address range of RAM uboot runs?
I would like to know this for my 64MB RAM.Is there any place in any
config file or somewhere in uboot code where this address range is
defined?
Regards
--
Thanks & Regards
Harsh
---
MPC8377ERDB is special, second serdes should be configured
for PEX (x1).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Makefile |7 +++
board/freescale/mpc837xerdb/mpc837xerdb.c |2 ++
include/configs/MPC837XERDB.h | 19 +
This patch adds few routines to configure serdes on 837x targets.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
cpu/mpc83xx/Makefile |2 +-
cpu/mpc83xx/serdes.c | 161 ++
include/fsl_serdes.h | 25
3 files changed, 187 inser
Hi Richard,
Thanks for your answer.
On ven, 2008-03-07 at 14:58 +, Richard Danter wrote:
> On 07/03/2008, Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> wrote:
> > How I can load (and start) an EST Flat Bin image? My supplier gives me
> > this image and I don't know how run it from u-boot (f
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
include/configs/MPC837XERDB.h | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index 2da4f29..7c19d1e 100644
--- a/include/configs/M
In message <[EMAIL PROTECTED]> you wrote:
>
> I was too terse. The problem is that I added a progress bar.
> Previously, the printout sequence was:
>Writing to Flash...
> followed by an indeterminate wait, followed by the string "done." which
> formed the composite:
>Writing to Flash...
On 07/03/2008, Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> wrote:
> How I can load (and start) an EST Flat Bin image? My supplier gives me
> this image and I don't know how run it from u-boot (from git).
> Can someone help me?
The EST flat binary is a pure binary file with a 32-byte header. Yo
Hi Mark,
Mark Jonas wrote:
> Hello,
>
> the attached patch adds a driver for the SMSC LAN911x and LAN921x
> family of Ethernet controllers. The patch also
> enables the use of this driver on the SH7720 based MPR2 board.
>
> Please note that the network driver does not obey the U-Boot coding
> styl
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> The saveenv also looks funky. I only mucked with the cmd_mem.c command
>> to make it display better with the progress dots, obviously the saveenv
>> command needs to have the same changes
>>s/"Writing to Flash... "/"Writing
In message <[EMAIL PROTECTED]> you wrote:
>
> The saveenv also looks funky. I only mucked with the cmd_mem.c command
> to make it display better with the progress dots, obviously the saveenv
> command needs to have the same changes
>s/"Writing to Flash... "/"Writing to Flash\n"/
Please don'
On Friday 07 March 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > I already have enough "glory" in U-Boot history. ;) I leave this for
> > somebody else for now. Let's see, if somebody steps up...
>
> Indeed: since v1.3.1:
>
> Developers with the most changesets
> Stefan
On Mar 7, 2008, at 8:15 AM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> I already have enough "glory" in U-Boot history. ;) I leave this
>> for somebody
>> else for now. Let's see, if somebody steps up...
>
> Indeed: since v1.3.1:
>
> Developers with the most changese
In message <[EMAIL PROTECTED]> you wrote:
>
> I already have enough "glory" in U-Boot history. ;) I leave this for somebody
> else for now. Let's see, if somebody steps up...
Indeed: since v1.3.1:
Developers with the most changesets
Stefan Roese 109 (13.2%)
Kumar Gala
In message <[EMAIL PROTECTED]> you wrote:
>
> I don't think printing the programming time/speed at beginning of the
> operation is doable. At least not without bigger changes. But an output at
> end of the operation like:
>
> Wrote 512kB in 5.4 seconds (94,8 kB/s)
U-Boot output shall be terse.
In message <[EMAIL PROTECTED]> you wrote:
>
> a) Crashes upon flashing 16MBytes
Nice :-(
> b) Strange output upon "saveenv" with redundant env sectors:
...
> It seems we have to restrict the output length somehow for this 16MByte
> problem. Or perhaps use a fixed length for all sizes.
The impor
On Friday 07 March 2008, Jerry Van Baren wrote:
> Odd, I didn't see your reply, saying "[EMAIL PROTECTED]" must trigger our mail
> filter, it's built on Microsoft technology. ;-) I can read your reply
> in gmane.org, now that I know to look. :-/
Understood. :)
> The crash is undoubtedly due to
Stefan Roese wrote:
> On Friday 07 March 2008, Jerry Van Baren wrote:
>>> would be nice. This way the developer could see, if the interface to the
>>> FLASH chips is optimized. But I think this is overkill too. Let's
>>> concentrate on a clean progress bar with a fixed length.
>>>
>>> Patches welco
On Friday 07 March 2008, Jerry Van Baren wrote:
> > would be nice. This way the developer could see, if the interface to the
> > FLASH chips is optimized. But I think this is overkill too. Let's
> > concentrate on a clean progress bar with a fixed length.
> >
> > Patches welcome. :)
> >
> > Best re
Jerry Van Baren wrote:
> Clemens Koller wrote:
[snip]
> Here is a revised command line example that autoscales to 50 dots:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int k;
> int cnt;
> int scale;
>
> if(sscanf(argv[1], "%d", &cnt)
Stefan Roese wrote:
> On Friday 07 March 2008, Clemens Koller wrote:
>> ACK from my side to Jerry's version. Maybe a quite long fixed length (~40
>> characters) bar would also be reasonable and the dot-time scaled to fit the
>> progress.
>>
>> A progress bar needs IMO two informations:
>> - that it
Clemens Koller wrote:
> Jerry Van Baren schrieb:
>> Michael Schwingen wrote:
>>> Wolfgang Denk wrote:
Please let's stay terse. Printing a dot is a single character on the
console. I dislike funny stuff which requires output of non-printing
characters or (weven worse!) terminal spec
HI Folks,
How I can load (and start) an EST Flat Bin image? My supplier gives me
this image and I don't know how run it from u-boot (from git).
Can someone help me?
thanks a lot.
luigi
--
__ Luigi Mantellini
.'__'. R&D - Software
(.' '.)Industrie Dial Face S
On Friday 07 March 2008, Clemens Koller wrote:
> ACK from my side to Jerry's version. Maybe a quite long fixed length (~40
> characters) bar would also be reasonable and the dot-time scaled to fit the
> progress.
>
> A progress bar needs IMO two informations:
> - that it's still working... so a qui
Jerry Van Baren schrieb:
> Michael Schwingen wrote:
>> Wolfgang Denk wrote:
>>> Please let's stay terse. Printing a dot is a single character on the
>>> console. I dislike funny stuff which requires output of non-printing
>>> characters or (weven worse!) terminal specific escape sequences.
>>>
Hi,
in 2006 you released a patch to support Lattice ECP FPGA programming via
JTAG interface in U-Boot. I'm wondering if this patch supports new XP2
(flash-based) family too. If not, can you address me about how to change
the sources in order to add xp2 support?
Thanks in advance,
llandre
DAV
Hello, Mark.
On Fri, 7 Mar 2008 10:23:35 +0100
"Mark Jonas" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> the attached patch adds support for the Renesas SH7720 based board MPR2.
>
Please transmit the patch by the text without settling with tar. Could you
send it again?
Please do not send it to th
Hello,
the attached patch adds a driver for the SMSC LAN911x and LAN921x
family of Ethernet controllers. The patch also
enables the use of this driver on the SH7720 based MPR2 board.
Please note that the network driver does not obey the U-Boot coding
style at all. The reason is that the driver is
Hello,
the attached patch adds support for the Renesas SH7720 based board MPR2.
Regards,
Mark Jonas
CHANGELOG:
--
sh: Added support for SH7720 based board MPR2.
Signed-off-by: Mark Jonas <[EMAIL PROTECTED]>
u-boot_mpr2_20080307.patch.bz2
Description: BZip2 compressed data
TÜM SEKTÖRLER GELECEĞE HAZIRMISINIZ
X
Normal
x
7
189
2007-07-25T13:10:00Z
2007-07-25T13:20:00Z
1
421
2406
Milli Eğitim Bakanlığı
20
5
2822
10.2625
21
MicrosoftInternetExplorer4
/* Style Definitions */
table.MsoNormal
The following changes since commit 848e03110c0facf3800ea15fdc38e505248ee282:
Stefan Roese (1):
Merge branch 'master' of /home/stefan/git/u-boot/u-boot
are available in the git repository at:
git://www.denx.de/git/u-boot-ppc4xx.git master
Markus Brunner (1):
fix taihu soft spi_r
On Wednesday 05 March 2008, Markus Brunner wrote:
> The taihu board used gpio_read_out_bit which reads the output register and
> not the pin state.
Applied to u-boot-ppc4xx custodian repository. Will get pulled into 1.3.2
release. Thanks.
Best regards,
Stefan
===
65 matches
Mail list logo
