[U-Boot-Users] u-boot cp command for at91rm9200
I can't seem to get the CP command to work at all. I want to test it by doing a simple SDRAM copy. I know the SDRAM works and I know where it is because I can use tftp to load a kernel image, and then boot the kernel from RAM. I am using the linuxstamp http://opencircuits.com/Linuxstamp which is based on atmel's at91rm9200. The main version I have been using is a patched version of 1.1.6. I have also tried 1.3.0-rc3. Both versions have the same result. If I do
tftpboot 20100000 uImage
This works. If I do
md 20000000
or
md 20001000
It works, but if I do
cp 20000000 20001000 256
I get the error "Copy to Flash... General Flash Programming Error" Why does it think this is a flash operation? I am using RAM addresses. If I do
protect off all
It doesn't change anything
I feel like I don't understand something important about how CP works. Please help.
thanks, Paul
Hi,
On 10/26/07, Paul Thomas pthomas8589@gmail.com wrote:
It works, but if I do
cp 20000000 20001000 256
I get the error "Copy to Flash... General Flash Programming Error" Why does it think this is a flash operation? I am using RAM addresses.
That's because the 'cp' command copies data from the RAM to the flash and vice versa. Check the function do_mem_cp in the common/cmd_mem.c. For copying within memory, you have memcpy.
-- sughosh
Hi,
On 10/27/07, sughosh ganu urwithsughosh@gmail.com wrote:
On 10/26/07, Paul Thomas pthomas8589@gmail.com wrote:
It works, but if I do
cp 20000000 20001000 256
I get the error "Copy to Flash... General Flash Programming Error" Why does it think this is a flash operation? I am using RAM addresses.
That's because the 'cp' command copies data from the RAM to the flash and vice versa. Check the function do_mem_cp in the common/cmd_mem.c. For copying within memory, you have memcpy.
Oops, think i jumped the gun. The 'cp' command actually copies data between any kind of memory. So probably, as the other post suggested, the address seems to be detected as a part of the Flash.
-- sughosh
Paul Thomas-12 wrote:
I can't seem to get the CP command to work at all. I want to test it by doing a simple SDRAM copy. I know the SDRAM works and I know where it is because I can use tftp to load a kernel image, and then boot the kernel from RAM. I am using the linuxstamp http://opencircuits.com/Linuxstamp which is based on atmel's at91rm9200. The main version I have been using is a patched version of 1.1.6. I have also tried 1.3.0-rc3. Both versions have the same result. If I do
tftpboot 20100000 uImage
This works. If I do
md 20000000
or
md 20001000
It works, but if I do
cp 20000000 20001000 256
I get the error "Copy to Flash... General Flash Programming Error" Why does it think this is a flash operation? I am using RAM addresses. If I do
protect off all
It doesn't change anything
I feel like I don't understand something important about how CP works. Please help.
thanks, Paul
From your board definitions if i understand, the CFG_FLASH_BASE is at
0x10000000 for 2 Megs. Please check with "flinfo" command to see if the sectors are listed out correctly. The problem seems to be that the address 20001000 in "cp" command is detected in the flash region. In case if it is in the RAM region, it should be copied.
Moreover, direct tftp to flash region is possible. So, we cannot conclude from tftp that the address is in RAM region.
Ramasamy C
On 10/28/07, Ramasamy C thedavinci@gmail.com wrote:
Paul Thomas-12 wrote:
I can't seem to get the CP command to work at all. I want to test it by doing a simple SDRAM copy. I know the SDRAM works and I know where it is because I can use tftp to load a kernel image, and then boot the kernel from RAM. I am using the linuxstamp http://opencircuits.com/Linuxstamp
which
is based on atmel's at91rm9200. The main version I have been using is a patched version of 1.1.6. I have also tried 1.3.0-rc3. Both versions have the
same
result. If I do
tftpboot 20100000 uImage
This works. If I do
md 20000000
or
md 20001000
It works, but if I do
cp 20000000 20001000 256
I get the error "Copy to Flash... General Flash Programming Error" Why does it think this is a flash operation? I am using RAM addresses.
If
I do
protect off all
It doesn't change anything
I feel like I don't understand something important about how CP works. Please help.
thanks, Paul
From your board definitions if i understand, the CFG_FLASH_BASE is at
0x10000000 for 2 Megs. Please check with "flinfo" command to see if the sectors are listed out correctly. The problem seems to be that the address 20001000 in "cp" command is detected in the flash region. In case if it is in the RAM region, it should be copied.
Moreover, direct tftp to flash region is possible. So, we cannot conclude from tftp that the address is in RAM region.
The board configurations looks ok. But the 'Copy to Flash' message would print if and only if the destination address is in flash area and not in dataflash area. The 'memcpy' is a function that can be used within u-boot. It is not available as a command in u-boot.
Please cross check with the flash configuration options. In case if you use a Dataflash and disable normal flash, how are you disabling the flash options? If you have access to the u-boot code for modification, check in board/at91rm9200dk/flash.c: You could see an array definition 'flash_info' being used throughout. So, the size values/start addressess are kept at 0 in case of a disabled flash. The function 'addr2info' which is in common/flash.c would check for addresses in the limit: start_address and (start_address + size - 1) which being unsigned would be 0xffffffff and would detect it in the flash region.
To cross check this scenario: Try copying to some other area in the memory. It should again be detected in the flash. Moreover 'cp' should detect 'copy to flash' for any area. To my understanding, i guess this would be a possible scenario.
Quote from board/at91rm9200dk/flash.c: void flash_identification (flash_info_t * info) { ... /* Vendor type */ info->flash_id = ATM_MANUFACT & FLASH_VENDMASK; printf ("Atmel: "); ... }
The vendor type for flash has been directly assigned. This should not be generally done. Check for device ID or some tag bits from the flash and depending on the type detected, assign this ID. The flash_id is one of the keyfield used in the 'addr2info' function which is inturn used by many other functions.
I only have 2 memory chips on the board. A 32MB SDRAM and a 8MB dataflash. Are you saying it could be using the ram when it does the tftpboot, but thinks it is still in flash? Even if u-boot thinks the 0x20000000 range is flash why wouldn't cp work?
On 10/27/07, Ramasamy C thedavinci@gmail.com wrote:
On 10/28/07, Ramasamy C thedavinci@gmail.com wrote:
Paul Thomas-12 wrote:
I can't seem to get the CP command to work at all. I want to test it
by
doing a simple SDRAM copy. I know the SDRAM works and I know where it
is
because I can use tftp to load a kernel image, and then boot the
kernel
from RAM. I am using the linuxstamp http://opencircuits.com/Linuxstamp
which
is based on atmel's at91rm9200. The main version I have been using is a patched version of 1.1.6. I have also tried 1.3.0-rc3. Both versions have the
same
result. If I do
tftpboot 20100000 uImage
This works. If I do
md 20000000
or
md 20001000
It works, but if I do
cp 20000000 20001000 256
I get the error "Copy to Flash... General Flash Programming Error" Why does it think this is a flash operation? I am using RAM addresses.
If
I do
protect off all
It doesn't change anything
I feel like I don't understand something important about how CP works. Please help.
thanks, Paul
From your board definitions if i understand, the CFG_FLASH_BASE is at
0x10000000 for 2 Megs. Please check with "flinfo" command to see if the sectors are listed out correctly. The problem seems to be that the address 20001000 in "cp" command is detected in the flash region. In case if it is in the RAM region, it should be copied.
Moreover, direct tftp to flash region is possible. So, we cannot conclude from tftp that the address is in RAM region.
The board configurations looks ok. But the 'Copy to Flash' message would print if and only if the destination address is in flash area and not in dataflash area. The 'memcpy' is a function that can be used within u-boot. It is not available as a command in u-boot.
Please cross check with the flash configuration options. In case if you use a Dataflash and disable normal flash, how are you disabling the flash options? If you have access to the u-boot code for modification, check in board/at91rm9200dk/flash.c: You could see an array definition 'flash_info' being used throughout. So, the size values/start addressess are kept at 0 in case of a disabled flash. The function 'addr2info' which is in common/flash.c would check for addresses in the limit: start_address and (start_address + size - 1) which being unsigned would be 0xffffffff and would detect it in the flash region.
To cross check this scenario: Try copying to some other area in the memory. It should again be detected in the flash. Moreover 'cp' should detect 'copy to flash' for any area. To my understanding, i guess this would be a possible scenario.
Quote from board/at91rm9200dk/flash.c: void flash_identification (flash_info_t * info) { ... /* Vendor type */ info->flash_id = ATM_MANUFACT & FLASH_VENDMASK; printf ("Atmel: "); ... }
The vendor type for flash has been directly assigned. This should not be generally done. Check for device ID or some tag bits from the flash and depending on the type detected, assign this ID. The flash_id is one of the keyfield used in the 'addr2info' function which is inturn used by many other functions.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
participants (3)
-
Paul Thomas -
Ramasamy C -
sughosh ganu