Access data + Nand Falsh

Hot snow said:

* How can I load a file in the NAND Flash?

Since NAND flash multiplexes its address bus on to the data bus it cannot be read or written directly like most memory, there needs to be a software layer that performs the reads and writes with the NAND. This being said, to load data into NAND you would have to have some code running on the DSP to perform the accesses. Typically one just loads the application image to NAND where it will boot out of and run stand alone, there are tools to do this within the DVSDK install, if you want to access the NAND at run time from your application you will need some software to perform the NAND access routines, which you may be able to take out of existing test code, at least for an example. 

Hot snow said:

* Can I use the commands fopen() and fread() with a file already loaded in the NAND Flash?

Unfortunately this is not possible, at least not with the out of the box run time support library, you would have to modify fopen and fread to perform this kind of operation. By default on a device like DM6437 fopen and fread will access files on the host PC through JTAG/CCS.

I didn't well understand:

*What you mean by you have to modify fopen and fread ( is this possible to make them similar to fopen and fread).

In fact when I load a file other than the application image can I make commands similar to fopen() and fread(), to access the file from the Flash NAND.

One more question:

*What's exactly the role of ubl (user boot loader) (what's the relationship between the application image and ubl) ?

Hot snow said:

*What you mean by you have to modify fopen and fread ( is this possible to make them similar to fopen and fread).

In fact when I load a file other than the application image can I make commands similar to fopen() and fread(), to access the file from the Flash NAND.

I don't have an 'out of the box' example of this being done, so it would not necessarily be easy to accomplish, but it is a possibility. What I was suggesting is that you modify the run time support (RTS) library code itself to be able to perform the fopen and fread commands with data in flash, the sources for the RTS are included in CCS with the code generation tools, so they could be modified to do whatever you want them to do.

If you have a large code base that is dependent on calling fopen and fread than modifying the RTS may be an option, however in general for an embedded system like this it would probably be easier to write your own custom flash accessing functions separate from fopen and fread to access data stored in NAND. In either case you would have to write code to handle the NAND reads and writes, as well as any 'file system' structures you use to organize individual files in the NAND.

Hot snow said:

*What's exactly the role of ubl (user boot loader) (what's the relationship between the application image and ubl) ?

In general you do not need a UBL with the DM6437, as you can boot a DSP image in AIS (Application Image Script) format directly from the RBL (ROM Boot Loader), so I am somewhat curious where you are seeing UBL associated with DM6437?

The UBL is typically the second stage boot loader in the higher end TI processor systems, it is a small and simple application that is loaded by the RBL as the first piece of code to run on the device from an external source. The goal of the UBL is typically to configure the low level portions of the device (primarily the external DDR/SDRAM interface, and PLL) and than load up an application image of some sort to execute.

Though outside the scope of DM6437, typically UBL is seen in systems that boot high level OSes like Linux, where a boot process goes something like: reset is released --> RBL --> UBL --> U-Boot --> uImage (Linux kernel) --> user application. In the DM6437 case the boot process can be simplified since you can make an executable image that can be called directly by the RBL using the AIS format so you end up with a boot process without UBL: reset is released --> RBL --> AIS application image.