[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 at gmail.com> wrote:
>
> On 10/28/07, Ramasamy C <thedavinci at 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