[U-Boot-Users] latest u-boot (1.3.2-rc2) and dataflash vs CFG_NO_FLASH
Hi, again,
OK, I've got a NAND flash, SPI Dataflash, and no "real" flash (NOR, I suppose).
If I try to copy from Ram to dataflash, u-boot says "Copy to Flash..." and the CPU pukes; it's detecting what it thinks is flash.
If I #define CFG_NO_FLASH, other stuff breaks. If I fix that by changing include/flash.h to remove the #ifndef CFG_NO_FLASH, then everything compiles, but on the link, all of the flash stuff that I DO need (flash_info, flash_erase, etc) isn't defined because of CFG_NO_FLASH.
Has this been fixed ANYWHERE in someone's branch?
Wolfgang, I know you don't really care much about non-memory flash "devices" but is there some vision as to where all this is supposed to go?
Thanks in advance,
Matt Gessner mgessner@avidyne.com Avidyne Corp Safety Systems Group Columbus, OH
If I try to copy from Ram to dataflash, u-boot says "Copy to Flash..." and the CPU pukes; it's detecting what it thinks is flash.
This simple patch (for old 1.3.0) fixed this problem for me on DataFlash only system.
In message 47C79DFB.3050808@bluegiga.com you wrote:
If I try to copy from Ram to dataflash, u-boot says "Copy to Flash..." and the CPU pukes; it's detecting what it thinks is flash.
This simple patch (for old 1.3.0) fixed this problem for me on DataFlash only system.
Could you please submit this as a regular patch, i. e. inline instead of attachment, with a proper patch description (Subject line) and your Signed-off-by: line? Thanks in advance.
Best regards,
Wolfgang Denk
If I try to "cp.b <ram> <dataflash>", u-boot selects normal flash routines instead of dataflash. This is because it checks "if source address is not dataflash" instead of target address.
Signed-off-by: Kim B. Heino Kim.Heino@bluegiga.com
--- u-boot-1.3.2-rc3/common/cmd_mem.c.foo 2008-03-03 10:17:50.000000000 +0200 +++ u-boot-1.3.2-rc3/common/cmd_mem.c 2008-03-03 10:18:19.000000000 +0200 @@ -417,7 +417,7 @@ int do_mem_cp ( cmd_tbl_t *cmdtp, int fl /* check if we are copying to Flash */ if ( (addr2info(dest) != NULL) #ifdef CONFIG_HAS_DATAFLASH - && (!addr_dataflash(addr)) + && (!addr_dataflash(dest)) #endif ) { int rc;
In message 47CBB931.6070604@bluegiga.com you wrote:
If I try to "cp.b <ram> <dataflash>", u-boot selects normal flash routines instead of dataflash. This is because it checks "if source address is not dataflash" instead of target address.
Signed-off-by: Kim B. Heino Kim.Heino@bluegiga.com
Applied, thanks.
Best regards,
Wolfgang Denk
Thanks; I did something similar to this in my u-boot 1.2.0.
I sort of thought that this was an issue that was being hashed out a while back because of the conflict over all of the different devices vs flash memory.
I guess not.
Is there an effort under way to clean up or standardize all these things? Or was it deemed to be not useful enough?
Regards,
Matt
-----Original Message----- From: Kim B. Heino [mailto:Kim.Heino@bluegiga.com] Sent: Friday, February 29, 2008 12:54 AM To: Matt Gessner Cc: U-Boot-Users@lists.sourceforge.net Subject: Re: [U-Boot-Users] latest u-boot (1.3.2-rc2) and dataflash vs CFG_NO_FLASH
If I try to copy from Ram to dataflash, u-boot says "Copy to
Flash..."
and the CPU pukes; it's detecting what it thinks is flash.
This simple patch (for old 1.3.0) fixed this problem for me on
DataFlash
only system.
Dear Matt,
in message 4697729899C81C4388059CC380C71745011BABED@xchg-lma-01.Avidyne.com you wrote:
If I try to copy from Ram to dataflash, u-boot says "Copy to Flash..." and the CPU pukes; it's detecting what it thinks is flash.
If I #define CFG_NO_FLASH, other stuff breaks. If I fix that by changing include/flash.h to remove the #ifndef CFG_NO_FLASH, then everything compiles, but on the link, all of the flash stuff that I DO need (flash_info, flash_erase, etc) isn't defined because of CFG_NO_FLASH.
The current dataflash implementation really needs to be cleaned up.
Has this been fixed ANYWHERE in someone's branch?
Wolfgang, I know you don't really care much about non-memory flash "devices" but is there some vision as to where all this is supposed to go?
It's not exactly correct that I don't care. The situation is that we have no such hardware in our lab. That means I cannot even test it.
The "vision" is to add some proper device interface (similar to and/or unified with NAND, for example). But AFAIK no such work has been started yet.
Best regards,
Wolfgang Denk
participants (3)
-
Kim B. Heino -
Matt Gessner -
Wolfgang Denk