[U-Boot-Users] u-boot cp command for at91rm9200

[U-Boot-Users] u-boot cp command for at91rm9200

[Paul Thomas]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071026/21ec514c/attachment.htm 

[U-Boot-Users] u-boot cp command for at91rm9200

[sughosh ganu]

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

[U-Boot-Users] u-boot cp command for at91rm9200

[sughosh ganu]

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

[U-Boot-Users] u-boot cp command for at91rm9200

[Ramasamy C]

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
-- 
View this message in context: http://www.nabble.com/u-boot-cp-command-for-at91rm9200-tf4698848.html#a13446834
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot-Users] u-boot cp command for at91rm9200

[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071028/3fede17c/attachment.htm 

[U-Boot-Users] u-boot cp command for at91rm9200

[Paul Thomas]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071027/cccdbff1/attachment.htm