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.

Booting from NOR flash

Hi all

I'm trying to find the best way to boot my TMDSVDP6437 dev kit from flash. I have the flashburn utility from Software Design Solutions, and this bootloads the demo application that came with it easily. I now have to extend this such that I may boot my own DSP/BIOS application.

As I understand this, the necessary steps should be:

1) Set my DSP/BIOS application to have different load and run addresses, so that I may boot from FLASH but run from DDR. I'm not too sure how to do this. I've seen the settings in the .tcf, but I haven't found documentation on this. Everything I've found relates to editing the .cmd file, which seems to me to be an outdated way of doing this, as the BIOS setup will overide any changes I make anyway?

2) Modify the .asm assembler bootloader that came with flashburn utility, and include in my project.

3) Convert the application to a .hex file using hexAIS.exe. This seems straightforward once my .out is generated with the correct addressing.

4) Load the application with flashburn.

I've read spra999a, which describes this process. It doesn't seem to be quite right for what I want to do though.

Is this the correct way of going about bootloading from flash? What documents/examples can I read to gain a better understanding of how I need to do this.

I'd really appreciate any advice/input.

 

 

  • Leon de Wit said:
    Everything I've found relates to editing the .cmd file, which seems to me to be an outdated way of doing this, as the BIOS setup will overide any changes I make anyway?

    That is right, SPRA999 is a bit out of date for a modern boot loading like on DM6437, it is a bit easier with the DM6437 than these docs would have you believe, at least for a simple standard boot.

    I believe you can just go through the steps in C:\dvsdk_1_01_00_15\flashburn_files\DM643x Flashing Instructions.pdf and substitute your own .out file though it has been a while since I tried this, the scripts discussed there will do the conversions for you so that the ROM boot loader built into the DM6437 will reconstitute your code just like if it was loaded from JTAG.

  • As Bernie mentioned spra999a was for devices pre-dating the DM6437 as the bootloading process has changed significantly with newer AIS-enabled devices. To answer some specific questions...

    Leon de Wit said:
    1) Set my DSP/BIOS application to have different load and run addresses, so that I may boot from FLASH but run from DDR. I'm not too sure how to do this. I've seen the settings in the .tcf, but I haven't found documentation on this. Everything I've found relates to editing the .cmd file, which seems to me to be an outdated way of doing this, as the BIOS setup will overide any changes I make anyway?
    This is correct. The BIOS GUI allows you to specify load addresses via drop-down. If you have not already done so create a memory segment for your Flash range, then specify the Flash as the load-time address in the GUI. This will generate something similar to the LOAD/RUN scheme you mentioned.

    Leon de Wit said:
    2) Modify the .asm assembler bootloader that came with flashburn utility, and include in my project.
    As Bernie mentioned you should just be able to use the flash writer stuff that came with the DVSDK. This .asm file was necessary for the older devices as they did not have dynamic bootloading built into the ROM (this is what AIS enables).

  • Hi Bernie, Tim

    Thanks very much for your input. This is a whole lot easier than I thought! By simply converting the .out using hexAIS.exe things worked very easily.

    TimHarron said:

    The BIOS GUI allows you to specify load addresses via drop-down. If you have not already done so create a memory segment for your Flash range, then specify the Flash as the load-time address in the GUI. This will generate something similar to the LOAD/RUN scheme you mentioned.

    After I got some DSP/BIOS code loaded and running from flash, I tried experimenting with this.

    I added a flash section in the memory, specifying this as 'code' space. Next I initialised all the sections that could be set to load from flash to do so. Exceptions were .gblinit, .trcdata, .switch, .cinit, .pinit, .printf, .hwi_vec and .rtdx_text, which I suppose cannot be in ROM as this is really working memory being initialised rather than code being loaded. I left these to be initialised from DDR2. This does not boot. I'm curious to know how this should work?

    Thanks again for your help

    Leon

     

  • Leon de Wit said:
    I added a flash section in the memory, specifying this as 'code' space. Next I initialised all the sections that could be set to load from flash to do so. Exceptions were .gblinit, .trcdata, .switch, .cinit, .pinit, .printf, .hwi_vec and .rtdx_text, which I suppose cannot be in ROM as this is really working memory being initialised rather than code being loaded. I left these to be initialised from DDR2. This does not boot. I'm curious to know how this should work?

    I think I should have mentioned in the previous thread that the Load/Run statements are not usually necessary. I am not sure that this directly has anything to do with the failing boot - this would require a bit more debugging to figure out for sure. In either case if you already have a working bootable project I would just stick with it rather than debugging something you shouldn't need [:)]

  • Hi guys

    Tim, you are right of course. 'If it aint broken, don't fix it!' [:)] I do have another complication on my own hardware though, but, as this is really a separate question altogether, I'll post as a separate thread.

    Tim and Bernie, thanks again for your help.

    Leon

  • Hi guys

    Nearly a year from wrapping up this issue originally, it's come back to byte me. I've recently upgraded my toolset to C6000.7.0.3, and now I don't seem to be able to get the hex conversion to work any more. In my linker command file, I specify:

    MEMORY {
        BOOT_FLASH:     o = 0x42000000   l = 0x00040000
    }

    SECTIONS {
        .bld {
            *(.bootload)
            *(.crctable)
        } > BOOT_FLASH       
    }


    -l oculusFirmwarecfg.cmd

    The bootload and crctable sections being the assembly code responsible for loading my application from flash to DDR (defined with the .sect  directive in the assembly source). The linker runs without a hitch, and in my map file I see:

    .bld       0    42000000    00000ec0    
                      42000000    00000cc0     bootDM6437.obj (.bootload)
                      42000cc0    00000200     bootDM6437.obj (.crctable)

    which seems to indicate that the linker successfully placed the code where I wanted it. Next I run the hex6x tool with the option

    -bootsection .bld 0x42000000

    This complains about not being able to find the .bld section:

    warning: section .bld not found in ()

    Looking at the hex map file I can see the bld section was in fact found, but placed in the copy table:

       CONTENTS: 42000000..4203ffff   FILL = 00000000
                 42040000..420b1663   BOOT TABLE
                                 .bld : btad=42040000  dest=42000000 size=00000ec0

    I've been playing around with the syntax for both the linker and hex6x, but I've not been able to clear this up. I'd appreciate any thoughts you might have.

    Regards

    Leon de Wit

  • Hi everyone

    I've resolved this by speaking to TI support. In the hex6x command file, specify the file name the boot section comes from explicitly:

    -bootsection Debug\myTestProject.out(.bld) 0x42000000

    This is a workaround, and I've been promised that it would be fixed in C6000.7.0.4 (SDSCM37480)

    Many thanks to Anthony Berthet at the European Customer Support Center for his help.


    Regards


    Leon de Wit