Why does the NAND writer utility require the device config setup to "no boot/EMIF16 boot mode on the EVM " ?
Statement from : C:\ti\mcsdk_2_01_00_03\tools\writer\nand\docs\readme.txt
Thanks !
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Why does the NAND writer utility require the device config setup to "no boot/EMIF16 boot mode on the EVM " ?
Statement from : C:\ti\mcsdk_2_01_00_03\tools\writer\nand\docs\readme.txt
Thanks !
Hi,
No-boot mode will makes sure that there is no device configuration done by ROM bootloader (RBL). This will allow GEL file and NAND writer utility to do all the configurations and there will not be any configuration conflict with previous configurations which would have been done if it is not No-boot mode.
Regards,
Bhavin
I understand your answer like this:
- The ROM boot loader sets up a certain configuration of devices (EMIFS, ...).
- The tools NAND WRITER implements, via the gel files and other means, another configuration of devices (EMIFS, ...)
=> The re-configuration devices can not be dynamic, so the configuration set up by the tool WRITER NAND is not taken into account if an initial configuration has been done before.
Is the above correct?
I have some additional questions that come to mind:
- Do I understand that the ROM bootloader (RBL) is the configuration IBL if I2C boot configuration?
- arent the devices configuration of the NAND writer tools dependent on emulation tool used (loading file content from the PC to the DSP memory)?
If I still want to use the NAND WRITER tools from a boot configuration on I2C, what should I do:
- have the IBL config that allows flashing (I believe this is what happens now, but from your answer I understand the opposite ...)
- Or remove the settings made done by the NAND writer tools that would be conflicting (GEL files, ...) but then which ones ?
- As a more open question that summarize my need: I need a single switch settings between my production and rest of product life: what are your suggestions?
Please help
O'Mellin said:I understand your answer like this:
- The ROM boot loader sets up a certain configuration of devices (EMIFS, ...).
- The tools NAND WRITER implements, via the gel files and other means, another configuration of devices (EMIFS, ...)
=> The re-configuration devices can not be dynamic, so the configuration set up by the tool WRITER NAND is not taken into account if an initial configuration has been done before.
Is the above correct?
Yes, by using the No-boot mode, you start with a clean slate and allow the gels to do the configuration so you don't have to worry about EMIF or PLL config conflicts.
O'Mellin said:- Do I understand that the ROM bootloader (RBL) is the configuration IBL if I2C boot configuration?
Not sure I understand the question. If you select I2C boot via the bootstrap pins, the RBL sets up a basic I2C configuration so that it can access the EEPROM with the most minimal setup and slowest speed. It can then read the preloaded configuration block from within the EEPROM to understand the supported features of that EEPROM and adjust accordingly, for example the I2C access speed.
O'Mellin said:- arent the devices configuration of the NAND writer tools dependent on emulation tool used (loading file content from the PC to the DSP memory)?
The NAND writer tools are just writing the image from the DSP memory into the EEPROM. We use the emulator to get that image into the DSP memory. The emulator interfacing will be handled by the CCS target configuration automatically and overall will only really dictate the speed of the transfer.
O'Mellin said:If I still want to use the NAND WRITER tools from a boot configuration on I2C, what should I do:
- have the IBL config that allows flashing (I believe this is what happens now, but from your answer I understand the opposite ...)
- Or remove the settings made done by the NAND writer tools that would be conflicting (GEL files, ...) but then which ones ?
- As a more open question that summarize my need: I need a single switch settings between my production and rest of product life: what are your suggestions?
We really don't support loading the NAND writer into I2C EEPROM. In theory I suppose you could do this if you modify either the I2C IBL or the NAND writer image itself to include the gel functionality for configuration before loading/running the NAND writer functionality. You also would need a way to preload the image that the NAND writer is going to write to flash, into the DSP memory if you don't plan to use an emulator.
Let me know if I missed your point.
O'Mellin said:I understand your answer like this:
- The ROM boot loader sets up a certain configuration of devices (EMIFS, ...).
- The tools NAND WRITER implements, via the gel files and other means, another configuration of devices (EMIFS, ...)
=> The re-configuration devices can not be dynamic, so the configuration set up by the tool WRITER NAND is not taken into account if an initial configuration has been done before.
Is the above correct?
Yes, by using the No-boot mode, you start with a clean slate and allow the gels to do the configuration so you don't have to worry about EMIF or PLL config conflicts.
>> As a simple summary : I understand that conflicts may arise if we dont start from a blank configuration but : can the boot settings be overwritten by gels?
We really don't support loading the NAND writer into I2C EEPROM. In theory I suppose you could do this if you modify either the I2C IBL or the NAND writer image itself to include the gel functionality for configuration before loading/running the NAND writer functionality. You also would need a way to preload the image that the NAND writer is going to write to flash, into the DSP memory if you don't plan to use an emulator.
Let me know if I missed your point.
> there is a misunderstanding here, i dont want to load nan writer in I2C/ iwant to have the bootswitch in I2C EEPROM position but yet overwrite the RBL settings to allow the host PC to run the nand flasher tool from CCS. The idea is to do this in production or for firmware upgrade later on.
Let me check into it a bit. It may work, just not as clean. I know at one time there were issues when trying to reprogram the PLL because of sequencing issues, but I belive these may be fixed. There may be other issues, so I'll as some other to weigh in here.
Thanks for your clarification on the desired setup, again I'll look into it.
Regards,
Travis
The nand writer application assumes that the core PLL and DDR3 PLL are already configured. Since the gel file execution is the only way you can configure these PLL through CCS and these gel files will configure the PLLS only in no boot mode, we suggest that you set the EVM in no boot mode and run the gel. You can also overwrite the PLL configuration by manually running the global default setup. But as Travis suggest this might have some PLL sequencing issue since the RBL already configures the PLL based on the boot mode setting. But since you are setting in I2C boot(where the PLL is originally bypassed) we might not have any significant issue in running the global default setup. When you run the Global default setup, make sure that full initialization happens without any issues.
Please let me know if you any additional questions.
Thanks,
Arun.
Team,
thanks this is getting clearer, I just have 2 remaining questions:
1/ where can the global default setup be found? it isnt in the AN on boot modes, I didnt see it
2/ by PLL sequencing you mean that PLLs could go loose if we ask them to go to one setting to another one namely if the settings are not set in the appropriate order, correct? as you mentionned it should be a pb if left in I2C boot mode
cheers
Olivier,
1) Once you load the gel file in CCS, you can go to SCRIPTS tab at the top I believe and run the global default setup script. If I haven't already mentioned, grab the latest gel from the Keystone emupack:
http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html
2) Correct, I can't tell you the exact sequence, but the IBL and platform lib and gel are all now fixed with the proper sequence. Yes, I2C leaves it in bypass, then the gel can be used to program it to a given speed.
Regards,
Travis