I read the BSP code.In the bsp directory ,there is a main.c file.In the main.c file,a main() routine exist. But in the bootloader/ramimage directory,there is a file name customize.c which has a main() routine too. Or in the bootloader/romimage directory,there is a file name rommain.c which has a main() routine too. I think there are some conflict with two main() routines. Can anybody explain it for me?
Firstly with earlier versions of Net+Os v4.0 and v5.0 there are three ways to run as I described below: ramimagezip rom romzip Boot Execution RAM* ROM ROM Application Execution RAM ROM RAM Please note that boot execution for ramimagezip applies only when executable downloaded with Debugger. All in all romzip is the small bootloader that will reside at beginning of Flash, uncompressed. It is also the parent project of ramimagezip.bld. With Net+Os v5.1 we have the bootloader feature that removes the need for romzip and all example applications have been updated to work with the bootloader. When an application is built it creates an image that can both be debugged with the MULTI debugger, and be stored into flash and loaded by the bootloader. So at this juncture I strongly recommend that you don’t take romzip as a prototype for them but proceed with the bootloader The romzip application that is referred here has been added only to demonstrate how to create the equivalent of the ROMZIP applications from Net+Os v4.0 and v5.0. Accordingly Support for ROMZIP builds have been removed from the example applications. Image.bld will build debugger image and image.bin to use with bootloader, keep in mind that debugger image and unzipped application code start at the same location. The main() call in root.c file of the application is not identical to the one in the main. file of the bsp directory, it decompresses application to RAM and executes it. Special linker scripts are used with this application to prevent variables in the ROM portion of the code from colliding with the RAM application image. In addition, the following files in the BSP directory are built as part of this application reset.s and appconf_api.c. When you build the image you would see that you don’t hit any errors and that you don’t need to rebuild the bsp - keep in mind that you don’t need to un define anything. If ENABLE_FLASH_COMPRESSION is defined in the build file, then the decompress routine expands the zipped code in the flash into RAM, and start from RAM, control will not return to caller. We strongly suggest that customers use the bootloader. The bootloader provides a built in mechanism to recover if the firmware in flash is corrupted. This ROMZIP example DOES NOT have this ability and if you do decide to create a ROMZIP application, then you should make sure that as little as possible runs out of ROM. This is for two reasons: First, the RAM portion is compressed, while the ROM portion is not. So, putting code in the ROM portion uses more ROM space than putting it into the RAM portion. Secondly, the flash API cannot be used by code that is executing from flash. For example, if your application uses the last sector of flash as NVRAM, then the ROM portion will not be able to access NVRAM. Now also keep in mind that the user would have to comment #define BSP_USE_FLASH_FOR_NVRAM in bspconf.h and rebuild the bsp and then the romzip image before he burns that into flash provided that he doesn’t have nvram on his board which is the case for the NS7520 boards.