• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 625 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.

D800K001 and D800K003 bootloaders

Louis Dupont
Intellectual 480 points
Other Parts Discussed in Thread: AM1707, OMAP-L137, DA8XX

I've been looking into the boot sequence strategy of the OMAP L137 EVM and find it rather strange. Basically, here's my understanding of how it works (assuming SPI0 Flash boot mode).

The D800K001 bootloader (executing on the DSP I assume) will first look for an Application Image Script (AIS) at address 0 within the SPI0 Flash.

Through the execution of the script, the DSP will basically place dspubl (DSP executable placed immediately after the AIS) into an abitrary RAM specified by the linker script first used when generating the DSP executable (dspubl) before running AISGen.

The DSP execution will then jump into that arbitrary RAM and run dspubl.

dspubl will simply look into the SPI Memory at address 0x2000 (where the ARM executable armubl has been placed) and transfert the next 16Kb within the SPI Flash to a shared RAM at address 0x80000000. It will then wake up the arm and instruct it to start its execution there. 

armubl will start its execution by shutting down the DSP then proceed with some hardware initialisation before transferring the arm executable (u-boot) to the external SDRAM at the adress specified within its own header (Load Address : 0xC1080000) before jumping to an entry point which is the same as the load address.

Now as far as I can see, u-boot is compiled specifically for the OMAP L137 EVM.

Basically my question is why bother with armubl? Why not simply proceed to the required hardware initialization within dspubl and jump directly to u-boot (which appear to proceed to the some hardware initilisation anyway and could easely shut down the DSP as far as I can see)?

Now I have my own board running the latest bootloader (D800K003) which can directly boot on the ARM, initialize PINMUX, PLL, Power and SDRAM. Would it make more sense to simply boot on u-boot (through AIS of course)?

Thanks.

  • 0
    TI__Mastermind 27585 points

    You are correct, the only reason an ARM UBL is needed is in order to shut down the DSP. I dont believe theres a way to have UBOOT turn off the DSP, but let me know if you know otherwise.

    On your own board are you using an OMAP-L137 or an AM1707? The OMAP-L137 always boots from the DSP even with the latest bootloader.

    Jeff

  • 0 in reply to jc-ti
    Intellectual 480 points

    Thanks Jeff,

    I'm using the OMAP L137. I agree that D800K003 is targetted at the DSP. So the DSP will execute the commands dictated by the AIS script. But AISGen for D800K003 now appear to give the option to jump on either the DSP or the ARM next (it wasn't an option with D800K001). So I assume that if I choose the ARM option the AIS script will instruct the DSP to place an ARM executable (rather than a DSP one) at a specific memory location and start the ARM with that memory location as an entry point.

    Now u-boot is an ARM executable as is armubl. I'm not sure I see why it wouldn't be able to shut down the DSP the same way armubl does :

          #define PSC0_MDCTL15 (*(volatile unsigned int*)(0x01C10A3C))

          #define PSC0_PTSTAT (*(volatile unsigned int*)(0x01C10128))

          #define PSC0_MDSTAT15 (*(volatile unsigned int*)(0x01C1083C))

          #define PSC0_PTCMD (*(volatile unsigned int*)(0x01C10120))

    ...

          void ShutDownDSP(){

                PSC0_MDCTL15 &= ~0x00000100; // assert DSP local reset

                //Turn off DSP

                // Wait for any outstanding transition to complete

                while ( PSC0_PTSTAT & 0x00000002 );  

                // If already in that state, return

                if ((PSC0_MDSTAT15 & 0x0000001F) == 0) return; 

                // Perform transition

                PSC0_MDCTL15 &= 0xFFFFFFE0;

                PSC0_PTCMD |= 0x00000002;

                // Wait for transition to complete

                while ( PSC0_PTSTAT & 0x00000002 );

                // Wait and verify the state

                while ((PSC0_MDSTAT15 & 0x0000001F) != 0);

          }

    The beginning of board_init within /board/da8xx/da8xx-evm/dv_board.c would seem like the appropriate place to call this. As far as I know it would also suit the TMS320DA830 and TMS320DA828.

    Louis