• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 835 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Can't rebuild OMAP-L138_FlashAndBootUtils_2_36 - Source Files Missing!

Brian Boorman
Guru 25210 points
Other Parts Discussed in Thread: OMAP-L138

I am trying to rebuild the Flash utils for a custom board. Unfortunately, the archive available from TI won't build, as some source files are missing.

1. I obtained the latest archive from: http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/v2.36/

2. I unzipped the tarball to a "golden" directory location.

3. I copied the source tree to a location to make modifications from.

4. (Ignore. Misread directions on .NET tools)

5. Looks like the boot.asm file is missing in several of the CCS project src folders...

This is the error I get:

[boot.asm] "C:\Program Files\Texas Instruments\TMS470 Code Generation Tools 4.6.6\bin\cl470" -g -fr"C:/TVP/Builds/C6748_Utils/OMAP-L138/CCS/NANDWriter/Debug" -i"C:/TVP/Builds/C6748_Utils/OMAP-L138/CCS/NANDWriter/include" -i"C:/TVP/Builds/C6748_Utils/OMAP-L138/CCS/NANDWriter/../../Common/include" -i"C:/TVP/Builds/C6748_Utils/OMAP-L138/CCS/NANDWriter/../../../Common/include" -i"C:/TVP/Builds/C6748_Utils/OMAP-L138/CCS/NANDWriter/../../../Common/ccs/include" -i"C:/TVP/Builds/C6748_Utils/OMAP-L138/CCS/NANDWriter/../../../Common/drivers/include" -d"_DEBUG" -d"SKIP_LOW_LEVEL_INIT" -me -mv5e --abi=eabi -@"../Debug.lkf" "boot.asm"

"boot.asm", ERROR! : [E1000] Cannot open source file boot.asm: No such file or directory

>> Compilation failure

6. I see that there is a boot.asm in the SDMMCWriter\src subfolder. Is this file the same for all projects? Can I just copy this to the other folders?

  • 0
    Guru 25210 points

     

    Additional notes: I originally extracted the tarball using WinZip in the Windows environment.

    I just extracted using tar under Cygwin to a separate folder, and the boot.asm files ARE STILL MISSING.

  • 0 in reply to Brian Boorman
    TI__Genius 12790 points

    Brian,

    Not sure why boot.asm is not in the package you downloaded.  I found reference to it on the forum @

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/147933.aspx

    which then points to source on this wiki page:

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138

    under: Obtain the SW here, the .zip file contains the boot.asm

    Regards,

    Marc

  • 0 in reply to pathfinder
    Guru 25210 points

    Marc,

    It contains _a single_ boot.asm

    The problem is that each of the sub projects require a boot.asm in each of their source trees, which they don't have.

    Solution is to either:

    a - include boot.asm in the src folder for each output program that requires it, or

    b - fix the project makefiles to point to the single boot.asm correctly.

    As it stands, anyone downloading the package off the web cannot simply follow the instructions to rebuild the software.

    Also, there are some backwards dependencies, that cause HexAIS program to not get built until after other nakefile which assume it's already there. You cannot do a "make clean" followed by a "make". You first have to make the HexAIS utility (which got deleted by the clean). This is not documented in the instructions.

    ~Brian

  • 0 in reply to Brian Boorman
    TI__Genius 17355 points

    A new release is now available online, here:

    http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/v2.40/

    This should fix the issue you saw with the Make dependencies and it of course adds in the missing boot.asm file.  Please note that a few things changed with the build procedures, in that we centralized the location information for the ARM and DSP compilers into one file, called Common/build.mak.  We are trying to move away from the instructions to add everything you your path.  The rebuilding instructions on the wiki will be updated shortly.  Also note that the CCSv3 projects are not prebuilt in the package.  Future updates will likely add CCSv5 projects (or maybe replace the CCSv3 ones), but the included CCSv3 projects can be easily imported into newer versions of CCS

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Guru 25210 points

    Daniel,

    Thanks for the reply. Just a couple quick questions before I hit "Verify" on this thread....

    1. Are there other changes between 2.36 and 2.40 besides build environment, eg source code changes?

    2. I have also noticed (but not yet submitted to TI formally) that the NOR driver has issues with Neumonyx 65nm "P30" flash devices. Specifically the Buffer Write mode didn't work, and left the flash in a bad state when then trying to call single-word programming mode, causing that to also fail (when it really worked). I ended up commenting out the buffer mode and inserting the Intel "Clear Status" command to get things working. What is the preferred method of feeding this back to the correct dev team at TI?

    Thanks,

    Brian

  • 0 in reply to Brian Boorman
    TI__Genius 17355 points

    Brian Boorman said:
    1. Are there other changes between 2.36 and 2.40 besides build environment, eg source code changes?

    Here is the list of changes from the changelog:

      * Included missing boot.asm file in CCS flashing tools
      * Updated build requirements to use file Common\build.mak to define
          ARM and DSP tool locations and prefixes
      * Fixed starting block number in NANDWriter program
      * Fix ELF handling (based on xdc.meta section in ARM9 executable)
      * Updated makefiles to better handle dependencies from other parts
          of the tree (e.g. HexAIS required for SFT/UBL builds)

    There are some source changes to address the ELF parsing issue, but that's really it.

    Regarding the NOR flash support, I have heard something similar previously, but unfortunately we can't test that code with every NOR flash on the market, though, as you can see by looking at it, it was written with the intention to be generic for many devices. I think the only guarantee we could make with respect to NOR flash, would be supporting what device comes on the standard EVM/board offerings. 

    For reporting issues like this, you could maybe use the issue tracker on the sourceforge site, though we primarily just use it for external hosting.  And you can certainly post patches or suggestions here.

    Regards, Daniel