On Friday 16 May 2008, 甜瓜 wrote:
All Walnut boards have 512k of NOR FLASH. Do you really have an original
IBM/AMCC Walnut or a different custom 405GP board?
Yes, my board is a custom board DHT-Walut with 32MB SDRAM and
512k of boot flash AMD 29LV040B. Details are listed in:
2008/5/16 Wolfgang Denk [EMAIL PROTECTED]:
In message [EMAIL PROTECTED] you wrote:
1. Both default config of u-boot and a DHT-Walut-patched config
generate 256KB bin,
but the flash on board is 512KB. So I think I should get a 512KB bin
for flash writing.
Why?
Do you think on devices with
Hello,
Kindly refer code at path UBOOT / u-boot / cpu / pxa / start.S
Code:
.macro irq_save_user_regs
sub sp, sp, #S_FRAME_SIZE
stmia sp, {r0 - r12}/* Calling r0-r12 */
add r8, sp, #S_PC
stmdb r8, {sp, lr}^
Our board is reference with the mpc8313erdb,and its design is to link CS0 to
the NAND FLASH, so I have to boot from NAND other than NOR.In
/board/mpc8313erdb I can find some files, such as nand_boot.c, nand.c and
nand_ecc.c, which I think are related with booting from NAND.What I want to
know
This adds a new command, sf which can be used to manipulate SPI
flash. Currently, initialization, reading, writing and erasing is
supported.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
common/Makefile |1 +
common/cmd_sf.c | 191
This is pretty incomplete...it doesn't handle reading the environment
before relocation, it doesn't support redundant environment, and it
doesn't support embedded environment. But apart from that, it does
seem to work.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
common/Makefile |
This adds a new SPI flash subsystem.
Currently, only AT45 DataFlash in non-power-of-two mode is supported,
but some preliminary support for other flash types is in place as
well.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
Makefile |2 +
On AD7414 the first value upon bootup is not read correctly.
This is most likely because of the 800ms update time of the
temp register in normal update mode. To get current values
each time we issue the dtt command including upon powerup
we switch into one-short mode.
This patch fixes the problem
All,
This is not specific to U-boot, but can definitely be addressed within
U-boot drivers network drivers, in the Freescale 83xx crowd. If anyone has
suggestions as to a better list to post this in, let me know.
I have a working driver for 100BaseT with a National DP83763 GigE Phyter V
On 12:14 Fri 16 May , Amit Kumar wrote:
Hello,
Kindly refer code at path UBOOT / u-boot / cpu / pxa /
start.S
Code:
.macro irq_save_user_regs
sub sp, sp, #S_FRAME_SIZE
stmia sp, {r0 - r12}
AVR32 and AT91SAM9 both have their own identical definitions of
container_of() taken from the Linux kernel. Move it to common.h so
that all architectures can use it.
container_of() is already used by some drivers, and will be used
extensively by the new and improved SPI API.
Signed-off-by:
Spotted by Dean Capindale.
Systems that support open-drain GPIO properly are allowed provide an
empty I2C_TRISTATE define. However, this means that we need to be
careful not to drive SDA low when the slave is expected to respond.
This patch adds a missing I2C_SDA(1) to read_byte() required to
From: Hans-Christian Egtvedt [EMAIL PROTECTED]
This adds a driver for the SPI controller found on most AT91 and AVR32
chips, implementing the new SPI API.
Changed in v4:
- Update to new API
- Handle zero-length transfers appropriately. The user may send a
zero-length SPI transfer with
On 11:10 Fri 16 May , Haavard Skinnemoen wrote:
AVR32 and AT91SAM9 both have their own identical definitions of
container_of() taken from the Linux kernel. Move it to common.h so
that all architectures can use it.
container_of() is already used by some drivers, and will be used
On Fri, 16 May 2008, Haavard Skinnemoen wrote:
From: Haavard Skinnemoen [EMAIL PROTECTED]
This patch gets rid of the spi_chipsel table and adds a handful of new
functions that makes the SPI layer cleaner and more flexible.
Ok, this looks good to me now. And it works too. Just one question:
Hi.
As you might have noticed, there was a big problem discovered in the
Debian OpenSSL packages that caused generated SSL keys to be very weak.
Among others this affects keys generated for SSH authentication.
For more information see the security advisories for
Debian OpenSSL:
This patch fixes an error when reporting the NAND erase
progress as in this example:
U-Boot nand erase 800
NAND erase: device 0 offset 0x0, size 0x800
Erasing at 0x0 -- 6400% complete.
Signed-off-by: Hugo Villeneuve [EMAIL PROTECTED]
---
drivers/mtd/nand/nand_util.c | 11
Hi,
in the smc911x U-Boot driver the call of eth_halt() causes a reset of
the ethernet controller. This also resets the MAC address in the
according chip registers. This makes it impossible to pass the MAC
address to an ARM kernel because the smc911x linux driver reads the MAC
address from
Hi Matthias,
Matthias Fuchs [EMAIL PROTECTED] writes:
On Thursday 15 May 2008 10:37:04 Markus Klotzbücher wrote:
Could you suggest me how to solve the problem?
Is there any specific part of USB driver that requires cache handling?
None that I'm aware of, but I could imagine that enabling
Hi Jason,
Jason McMullan wrote:
diff --git a/lib_mips/board.c b/lib_mips/board.c
index 1645f2c..e33070d 100644
--- a/lib_mips/board.c
+++ b/lib_mips/board.c
@@ -28,6 +28,7 @@
#include version.h
#include net.h
#include environment.h
+#include nand.h
This will break build. According to
In message [EMAIL PROTECTED] you wrote:
in the smc911x U-Boot driver the call of eth_halt() causes a reset of
the ethernet controller. This also resets the MAC address in the
according chip registers. This makes it impossible to pass the MAC
address to an ARM kernel because the smc911x
Morten Ebbell Hestnes wrote:
+ nand read[.jffs2, .i] addr off|partition size\n
+ nand write[.jffs2, .i] addr off|partition size\n
What about .e? Is it just for backwards compatibility that we have
three commands that mean the same thing? Do we want to document all
three?
When SATA is selected (via jumper J6) we need to disable the first PCIe
node in the device tree, so that Linux doesn't initialize it. Otherwise
the Linux SATA driver will fail to detect the devices.
The same goes the other way around too. So if PCIe is selected we need
to disable the SATA node in
On Sat, 2008-05-17 at 01:26 +0900, Shinya Kuribayashi wrote:
Jason McMullan wrote:
+#include nand.h
This will break build. According to the blackfin, we can't even include
nand.h if it's not configured.
That is, of course, why I originally just had 'extern int
nand_init(void)' instead of
On Fri, May 16, 2008 at 02:54:34PM +0800, jiale.Yin wrote:
Our board is reference with the mpc8313erdb,and its design is to link CS0
to the NAND FLASH, so I have to boot from NAND other than NOR.In
/board/mpc8313erdb I can find some files, such as nand_boot.c, nand.c and
nand_ecc.c,
I assume
On Fri, May 16, 2008 at 02:39:17PM -0400, Hugo Villeneuve wrote:
This patch fixes an error when reporting the NAND erase
progress as in this example:
U-Boot nand erase 800
NAND erase: device 0 offset 0x0, size 0x800
Erasing at 0x0 -- 6400% complete.
So the problem is when trying
Scott Wood wrote:
On Fri, May 16, 2008 at 02:39:17PM -0400, Hugo Villeneuve wrote:
This patch fixes an error when reporting the NAND erase progress as
in this example: U-Boot nand erase 800
NAND erase: device 0 offset 0x0, size 0x800
Erasing at 0x0 -- 6400% complete.
So the
Hugo Villeneuve wrote:
Scott Wood wrote:
That should be an error.
What should be an error, the fact that 6400% is displayed, or the fact
that the user is trying to erase less than a block? :)
The latter. It should tell the user what the erase block size is, and
abort.
-Scott
Scott Wood wrote:
Hugo Villeneuve wrote:
Scott Wood wrote:
That should be an error.
What should be an error, the fact that 6400% is displayed, or the
fact that the user is trying to erase less than a block? :)
The latter. It should tell the user what the erase block size is, and
abort.
Hugo Villeneuve wrote:
I would be perfectly happy if the mtd driver reported a warning when the
requested erase size is not an exact multiple of the block size, and
allow the whole block erase to proceed. Then my patch would make sense.
That's what the mtd-2.6.22.1 branch in the NAND
Scott Wood wrote:
Hugo Villeneuve wrote:
I would be perfectly happy if the mtd driver reported a warning when
the requested erase size is not an exact multiple of the block size,
and allow the whole block erase to proceed. Then my patch would make
sense.
That's what the mtd-2.6.22.1
Hugo Villeneuve wrote:
Scott Wood wrote:
Hugo Villeneuve wrote:
I would be perfectly happy if the mtd driver reported a warning when
the requested erase size is not an exact multiple of the block size,
and allow the whole block erase to proceed. Then my patch would make
sense.
That's what
Scott Wood wrote:
Hugo Villeneuve wrote:
Scott Wood wrote:
Hugo Villeneuve wrote:
I would be perfectly happy if the mtd driver reported a warning
when the requested erase size is not an exact multiple of the
block size, and allow the whole block erase to proceed. Then my
patch would make
This patch lays the ground work for moving out-of-assembly and unifying the
SDRAM initialization code for PowerPC 405EX[r]-based boards.
include/ppc405.h:
Wrapped casts in EBC mnemonics with a macro such that the mnemonics can be
used from assembly as well as from C.
cpu/ppc4xx/start.S:
This patch continues laying the ground work for moving out-of-assembly
and unifying the SDRAM initialization code for PowerPC 405EX[r]-based
boards.
To do so, this deduces by one the number of nearly-identical DRAM ECC
initialization implementations for PowerPC 4xx processors utilizing a
DDR/DDR2
Hugo Villeneuve wrote:
Either way, I think my patch, or a variation of it, should need to be
applied to get rid of that ugly 6400%.
Agreed -- the patch in mtd-2.6.22.1 takes care of the percentage issue
at the same time as issuing the warning.
-Scott
36 matches
Mail list logo
