Does AM335x WEC 7 BSP EBOOT support reading and writing on FAT formatted NAND?

You need not to worry about this.. When u will dump your nk.bin image in NAND  and select the boot option as NAND after removing the SD card and certain jumper settings and reboot the board. It will start booting from the NAND.. There is pTOC table it contains the starting address of your nk.bin with length... and after kernel booting it swaps the Virtual address to Physical address and start copy from and copy to operation for R/W. I copies the data from virtual address and copy to physical address in RAM... 

This way, when the NK.EXE starts it can reference this variable to know where the TOC is. Using the TOC, the program can find all the other pieces of the operating system image.

ROMIMAGE uses the configuration .BIB files to know where the image is supposed to go and where RAM is. There are two important parts of the CONFIG.BIB file – the RAMIMAGE and the RAM lines. Here is an example from the Device Emulator’s CONFIG.BIB:

    NK 0x80070000 0x02000000 RAMIMAGE
    RAM 0x82070000 0x01E7F000 RAM

These entries tell ROMIMAGE what to do. It knows to place the OS image file at 0x80070000, and that it can start using read/write memory at 0x82070000. With this information it can place modules such as NK.EXE and KERNEL.DLL into virtual memory, and then build a TOC and put that into the image as well. To help the kernel start, the TOC also contains information on where RAM is

Thanks.
I understand the concept you have here. And actually we're already using this.
However, we are trying to be backward compatible with our upgrade applications.

Our upgrade apps store the NK.bin in the FAT formatted partition of the NAND.
The TI BSP stores the NK.bin in the "raw" NAND partition. However, we found out that the TI BSP already have a simple file system in the EBOOT.
This FAT filesystem is used to read the NK.bin from the FAT-formatted SD card.

Now our aim to port this capability to NAND so that the EBOOT can read a FAT-formatted NAND partition as well and which contains our NK.bin

This is part I'm looking for advice on. Tnx

Yes, as i already said you can do and R/W operation in NAND but the for performing the R/W operations you have to allocate next address space in the NAND... Do not worry, it will be done..

Sorry. But I'm not sure if you know the difference of a raw NAND partition and a FAT-formatted NAND partition.

AFAIC, you're simply describing here the R/W on a raw partition. I don't expect that addresses are fixed in a file system formatted partition.

Thanks for the reply, anyway.

Sorry, for correcting my self. You can perform any r/w operation in NAND. but the NAND memory supports only one file system i.e YAFFS- Yet another Flash File System. If you want to proceed with YAFFS then you have to look the bootloader code for r/w the image in NAND Flash memory ......

In the TI CE 7 BSP for AM335x, there is function named BLSDCardDownload. This is called to load the NK.bin from FAT formatted in SDCard...Code snippet below.

I think I need to create an equivalent of this function for NAND handling. But I'm doubtful if there is anything I can re-use in the available BSP or should I need to create new functions myself(but where to start?)

========================================================================
// This function is called after MMC/SD image download is selected in menu or config
pFile = &File;

OALMSGX(OAL_INFo, (L"BLSDCardDownload: Filename %s\r\n", filename));

if (!bFileIoInit)
{
// set up data structure used by file system driver
fileio_ops.init = &SDCardInit;
fileio_ops.identify = &SDCardIdentify;
fileio_ops.read_sector = &SDCardReadSector;
fileio_ops.read_multi_sectors = &SDCardReadMultiSectors;
fileio_ops.drive_info = (PVOID)&Disk;

// initialize file system driver
if (FileIoInit(&fileio_ops) != FILEIO_STATUS_OK)
{
OALMSG(OAL_ERROR, (L"BLSDCardDownload: fileio init failed\r\n"));
return (UINT32) BL_ERROR;
}

bFileIoInit = TRUE;
}

Marlon,

My suggestion would be to store the nk.bin in "raw" flash rather than try to implement FAT/NAND read/write support in the bootloader. The latter would be a lot of work, could potentially impact the boot time of your device, and I'm not sure what you would gain from it other than the convenience of being able to store nk.bin as a file in firmware update scenarios.

Anyhow, if you want to go down that route, you would need to look at:

• The FMD, or Flash Media Driver, which is a library that typically gets built in different versions for the bootloader and Windows CE, respectively. Take a look in your drivers\block directory and see what you find.
• The FAL, or Flash Abstraction Layer, which goes on top of the FMD and implements block mapping. Note that the bootloader version of the FAL needs to be compatible with the version that Windows CE uses. I've noticed there's a "fallite" sample implementation under platform\common\... but I don't have any practical experience with this so would be unable to offer advice. Do note that fallite does not implement write operations, so if you require this, you will need to port the relevant parts from the Windows CE FAL located somewhere under the private\... sources. Another potential issue is that during initialisation, the FAL needs to create a map of physical and logical sectors in flash, and doing so requires reading the spare area of all sectors that are in use. Depending on the size of your flash disk, this can be a lengthy operation; for instance, an OMAP3 platform with a 512 MB disk that I've worked on took anywhere between one and ten seconds to do this, depending on how much data was stored on the disk.
• And then you need to add a file system and possibly partitioning support, depending on what your disk layout looks like. Note that the FAT libraries used with SD cards and the like probably do not support any of the transaction features that you would want to use in an embedded device to avoid data corruption in the event of sudden power loss, watchdog reboot, etc. You get these for free with the TFAT/TexFAT file system support in Windows CE, but to my knowledge nothing of the sort exists for the bootloader environment.

Best regards,
Carsten

Thanks Carsten.

We don't need write operation on this as all we want is to read NK.bin from FAT-partition and load it RAM. The writing of the NK.bin will be taken care through the explorer once the full OS is up.

OK then, I only mentioned it because you talked about read/write support in your original post.

That makes it a bit easier, but I'd still go for a raw storage implementation due to the amount of work required otherwise. All you would need to do is reserve a portion of flash for the raw image, and implement an ioctl in the Windows CE block driver to store the image, taking care to handle bad blocks correctly (by skipping and marking as bad) and mark all blocks in the reserved portion as, well, reserved in order to prevent the FAL from using those as a generic disk/block device.

Just out of interest, do you have FAT/NAND read support running on your PXA platform?

Our new platform is TI's AM335x and the BSP release by Adeneo for this already includes support to boot NK.bin from a raw nand partition. This will be our fallback if we can't make this work booting to a FAT formatted partition. However, we don't want to give on that yet. :)

Anyway, our old PXA BSP has a proprietary bootloader. It sure have a support to boot from FAT formatted NAND. But we don't have any source reference on that since we only have its binaries.

So one thing we know is that , this is doable based on our old system. But we need to understand how to start with this on the Adeneo release EBOOT for AM335x