Is there a tool available for the C674x to generate a secondary bootloader, such as genBootCfg does for the 672x? Specifically we need to boot from parallel NOR flash and use GPIO pins for the higher addresses.
thanks,
Dave
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.
Is there a tool available for the C674x to generate a secondary bootloader, such as genBootCfg does for the 672x? Specifically we need to boot from parallel NOR flash and use GPIO pins for the higher addresses.
thanks,
Dave
Hi David,
The information and the files you need are in this app note:
Please take a look and let me know if you have questions.
Hi Mariana, thanks for the quick reply. The problem with sprab04b and the AIS image generating tool that goes with it is that I can't find any provision for designating gpio pins as upper address pins the way you can for the 672x. We're using a C6745 and we have an aggressive project schedule. When we heard about the intermittant bug in the SPI's and the schedule for fixed silicon, we changed our design to use parallel NOR flash on EMIFA for boot as we cannot afford to either wait for the new silicon rev or lose time chasing down phantom SPI bugs. We had previously been planning to do SPI boot. As there are only 15 address pins on the 6745's EMIFA, it would be a big time saver for us to be able to specify gpio pins as upper address in the bootloader generation tool.
thanks,
Dave
Hi David,
Maybe I'm a little outside of the loop, but I do not know what spi bug you are referring to. I have used spi boot successfully.
Are you saying that you need to use EMIFA with more than 16 bits?
Hi Mariana,
We were advised that there is an intermittant, state-dependant, not-fully-characterized bug with the SPI's on the 674x silicon that's out there right now. Rather than risk having this cause phantom problems in development we took the conservative approach of not using the SPI's at all in our design. This means we are booting from a parallel NOR flash, 8-bit data bus, 15 real address lines. This gives us 32k of code space that can be addressed by hardware. Our application is much bigger than this so we need to have a secondary bootloader that knows about our hardware (which gpio pins to use as addresses) to copy the remainder of the application into RAM. I saw that there was a boot image generating utility for the 672x's that allows you to enter the gpio-as-address pins in the GUI and it generates a boot image automatically. I was hoping there was something similar for the 674x.
thanks,
Dave
Since the C672x ROM boot loader (RBL) has the same basic limitation you could probably use much of the same work around for booting the C674x by generating a secondary boot loader that is aware of GPIO pins for addressing. Though you could not use the C672x utility directly, you could take the secondary boot loader code included with the C672x boot loader documentation that utilizes the GPIOs for address expansion and port that to the C674x for your purposes. I do not know of any such utility for the C647x or plans for such a utility, but I don't see any reason this should not be possible off hand.
The limitation on the C672x was actually more severe (I think for some versions of that device, only 12 address lines were available), so I think there was greater impetus to add such a feature to the boot loader tools. In this case, the first 32K is always available, which should be plenty of room to implement a full secondary bootloader. One reason to not do this in the boot loader is that it assumes a certain mechanism to control the upper address lines (certain pins, used in a certain way, etc.). This could vary widely across hardware designs. For example, on the EVM for the OMAP-L137 (which is the superset version of the C674x chips), this limitation is overcome using an external CPLD through which the upper address lines attached to the NOR flash are controlled.
My recommendation would be to implement a full secondary boot loader that corresponds to the particular hardware and can read the memory device attached to the EMIF by controlling upper address lines in a manner appropriate for your design.