On Tuesday 25 September 2007, Troy Kisky wrote:
> First segment fixes a typo
> Second segment fixes a bug where oob data may be copied incorrectly.
> Third segment adds an error message when exiting due to write protect.
> Forth segment fixes a bug where oobavail may be set incorrectly.
>
> All seg
Yep! The ppcboot is very ancient. hehe.
Actually, my board is DHT-walnut: http://elinux.org/DHT-Walnut_U_Boot
The web provides a pre-compiled bin uboot 1.1.4 for my board. The size is
256KB.
I downloaded it, and burn this bin into flash. But the board is still not
work.
Well, you point out a very
On Monday 21 April 2008, 甜瓜 wrote:
> I'm a beginner of embedded system. I'm working on a board of Walnut
> PPC405GP which use PPCBOOT 1.1.2.
Wow, that's ancient. I suggest to update to the current version.
Please find some comments below.
> One day I tried to write some data into unused area
Howdy,
I'm a beginner of embedded system. I'm working on a board of Walnut
PPC405GP which use PPCBOOT 1.1.2.
One day I tried to write some data into unused area of the flash:
>> fli
Bank # 1: AMD AM29F040 (512 Kbit, uniform sector size)
Size: 512 KB in 8 Sectors
Sector Start Addresses:
On Monday 21 April 2008, Wolfgang Denk wrote:
> > This would result in bigger changes to common code currently using those
> > functions (especially dcache_disable). Probably by using more #ifdefs
> > there which I would really like not to see.
>
> I don't like to see these either, but it's better
On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> > > not overwrite (or otherwise meddle with) any U-Boot code.
> > >
> > > I think you should not change cache status for "go".
> >
>
In message <[EMAIL PROTECTED]> you wrote:
>
> So what do you suggest instead? Removing these functions completely for 440?
Please let's either proviude real, working implementations, or remove
the functions.
> This would result in bigger changes to common code currently using those
> functions
In message <[EMAIL PROTECTED]> you wrote:
>
> > Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> > not overwrite (or otherwise meddle with) any U-Boot code.
> >
> > I think you should not change cache status for "go".
>
> reality is that people often times use go to execute t
On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > dcache_enable() was missing for 440 and the patch
> > 017e9b7925f74878d0e9475388cca9bda5ef9482 ["allow ports to override
> > bootelf "] behavior uses this function.
> >
> > Note: Currently the cache handli
Hi,
I am using an at91rm9200dk custom board.I want to boot kernel and
ram disk from the usb stick.for that i tried to enable the usb support
in the uboot.but now i am getting a message like no storage devices
found .
i gave the configurations in include/configs/at91rm9200dk.h
like follows
#de
On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > Does "nand write" support the "+${filesize}" notation (yet)?
> >
> > I don't think so.
> >
> > > If not, how about adding it?
> >
> > Yes, would be great. Patches welcome. :)
>
> How about you adding it?
On Sun, Apr 20, 2008 at 05:04:14PM +0100, Jamie Lokier wrote:
> I was thinking this:
>
> Hamish Moffatt wrote (Message-ID: <[EMAIL PROTECTED]>):
> > Sorry I should've said 512MiB perhaps: 512 megabytes.
> > UBI attach time appears to be about 6 seconds.
>
> If 6 seconds is as fast as it can be do
On Sunday 20 April 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Override the default go/boote handlers as we want to disable both data
> > and instruction cache before executing external programs (since Blackfin
> > cache handling requires a software handler in U-Boot
In message <[EMAIL PROTECTED]> you wrote:
> This patch adds a configurable flash auto protection list that can be used
> to make U-Boot protect flash regions in flash_init().
>
> The idea has been discussed on the u-boot mailing list starting
> on Nov 18th, 2007.
>
> Even this patch brings a new
In message <[EMAIL PROTECTED]> you wrote:
>
> As sugest Wolfgang we could do it like this
I did not suggest to use weak at all here!
> struct apl_s apl* inline init_flash_autoprotect()
> {
> struct apl_s a[] = {
> {1, 3},
> {4, 5},
> };
>
> return a;
> }
Are you su
In message <[EMAIL PROTECTED]> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
Would you please explain *why* you are doing this?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kir
In message <[EMAIL PROTECTED]> you wrote:
> Override the default go/boote handlers as we want to disable both data and
> instruction cache before executing external programs (since Blackfin cache
> handling requires a software handler in U-Boot which may be overwritten).
Umnmm... no. "go" is suppo
In message <[EMAIL PROTECTED]> you wrote:
> are available in the git repository at:
>
> git://www.denx.de/git/u-boot-mpc85xx.git master
>
> Kumar Gala (2):
> 85xx: Fix size of cpu-release-addr property
> 85xx: Round up frequency calculations to get reasonable output
>
> Timur Tabi
In message <[EMAIL PROTECTED]> you wrote:
> On Fri, Apr 18, 2008 at 4:28 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> > eg. because of rounding error we can get 799Mhz instead of 800Mhz.
> >
> > Signed-off-by: Dejan Minic <[EMAIL PROTECTED]>
> > Signed-off-by: Srikanth Srinivasan <[EMAIL PROTECTED
In message <[EMAIL PROTECTED]> you wrote:
>
> > U-Boot will run only software that has been
> > authenticated to be from the system's producer.
Seems it's time to start a discussion to switch to GPL v3...
> > Any comments or suggestions?
> >
> this patch taps into openssl:
Be careful. Linkin
In message <[EMAIL PROTECTED]> you wrote:
> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>
> Signed-off-by: Dejan Minic <[EMAIL PROTECTED]>
> Signed-off-by: Srikanth Srinivasan <[EMAIL PROTECTED]>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> cpu/mpc85xx/cpu.c |
In message <[EMAIL PROTECTED]> you wrote:
> Add -v for verbose output, "Unlocking flash...", "Done" etc.
> Add -q for quiet operation, do not print error and verbose
> messages.
This seems kind of redundandant to me.
And not printing error messages seems an error to me.
> Add a --help(-help, -?)
In message <[EMAIL PROTECTED]> you wrote:
>
> > Does "nand write" support the "+${filesize}" notation (yet)?
>
> I don't think so.
>
> > If not, how about adding it?
>
> Yes, would be great. Patches welcome. :)
How about you adding it?
Best regards,
Wolfgang Denk
--
DENX Software Engineerin
In message <[EMAIL PROTECTED]> you wrote:
> Recent commit a4986459 adds reference to dcache_enable, thus breaking the
> build on PPC440. This patch adds a stub for dcache_enable, similarly to
> what's being done for other cache operations.
>
> Signed-off-by: Bartlomiej Sieka <[EMAIL PROTECTED]>
>
In message <[EMAIL PROTECTED]> you wrote:
> dcache_enable() was missing for 440 and the patch
> 017e9b7925f74878d0e9475388cca9bda5ef9482 ["allow ports to override bootelf
> "] behavior uses this function.
>
> Note: Currently the cache handling functions like
> d/icache_disable/enable() are NOP's o
In message <[EMAIL PROTECTED]> you wrote:
>
> Wolfgang showed some interest briefly too.[1]
I am definitely interested.
> > The UBI (version 1 :-) initial scan is not
> > fast for large flash, and if the bootloader does it too, that's twice
> > as much time to boot.
We have the same (at at lea
Dear Matthias,
in message <[EMAIL PROTECTED]> you wrote:
>
> even though I like the weak stuff, I agree with you. I also like Stefan's
> idea about removing the #ifdef from the code.
>
> So I will update my patch in this direction.
Thanks.
> The main idea behind my patch is to fix the bootload
This patch adds a configurable flash auto protection list that can be used
to make U-Boot protect flash regions in flash_init().
The idea has been discussed on the u-boot mailing list starting
on Nov 18th, 2007.
Even this patch brings a new feature it is used as a bugfix for 4xx
platforms where f
Josh Boyer wrote:
> > Hamish Moffatt wrote (Message-ID: <[EMAIL PROTECTED]>):
> > > Sorry I should've said 512MiB perhaps: 512 megabytes.
> > > UBI attach time appears to be about 6 seconds.
> >
> > If 6 seconds is as fast as it can be done, annoying but fair enough.
>
> You should read that thre
On Sun, 2008-04-20 at 17:04 +0100, Jamie Lokier wrote:
> Josh Boyer wrote:
> > > Is it even a good idea? The UBI (version 1 :-) initial scan is not
> > > fast for large flash, and if the bootloader does it too, that's twice
> > > as much time to boot.
> >
> > It's a good idea, yes. Particularly
Josh Boyer wrote:
> > Is it even a good idea? The UBI (version 1 :-) initial scan is not
> > fast for large flash, and if the bootloader does it too, that's twice
> > as much time to boot.
>
> It's a good idea, yes. Particularly if you want to boot from NAND
> flash.
>
> Can you define "large d
Hi Wolfgang,
On Sun, Apr 20, 2008 at 2:36 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>
> Dear Ben,
>
> this patch is still on my "open" list. Can you please review and
> apply if it makes sense to you? Thanks.
>
This looks OK to me. Assuming that pci_io_to_phys() is defined on all
relevant
Hi Wolfgang,
On Sun, Apr 20, 2008 at 2:36 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Ben,
>
> this patch is still on my "open" list. Can you please review and
> apply if it makes sense to you? Thanks.
>
I don't have access to my build machine right now, and this looks
harmless. Please
Hi Wolfgang,
even though I like the weak stuff, I agree with you. I also like Stefan's
idea about removing the #ifdef from the code.
So I will update my patch in this direction.
The main idea behind my patch is to fix the bootloader autoprotection
for 4xx. Do you (sr, J., others) think i is also
Hi, all,
I'm tying to porting the kernel (2.6.25) to the mpc8247
platform, use the u-boot (1.3.2)
after run the command:
>tftp 30 uImage; tftp 60 mpc8247.dtb; bootm 30 - 60
the output like this:
[snip]
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x60
th
This patch enables SPI and MC13783/RTC support for the Litekit board.
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
board/imx31_litekit/imx31_litekit.c | 12
include/configs/imx31_litekit.h |8
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a
Use symbolic names instead of hard coded addresses for Litekit membases.
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
include/configs/imx31_litekit.h | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_
Correct the Linux architecture number for i.MX31 Litekit and ADS boards.
Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
board/imx31_litekit/imx31_litekit.c |2 +-
board/mx31ads/mx31ads.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/imx31_l
On Sunday 20 April 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Some Blackfin UARTs are read-to-clear while others are write-to-clear.
> > This can cause problems when we poll the LSR and then later try and
> > handle any errors detected.
> >
> > Signed-off-by: Mike Fr
39 matches
Mail list logo
