在这一帖子 http://www.deyisupport.com/question_answer/dsp_arm/omap_l1x/f/54/t/25609.aspx 中看到:
OMAP-L138的boot sequence如下.
- When the device is powered on, it starts execution from DSP ROM. ARM is in in the disable state at this moment. The DSP ROM code will
- Read certain registers to know that ARM is present. (Otherwise it will be a DSP-only boot)
- Program PDSP0 to prepare for ARM reset vector.
- Bring ARM out of reset and let ARM starts execution from its ROM. (Yes, that's the main difference from OMAPL137 silicon 1.x. ARM has its own ROM and will master the boot process afterwards)
- DSP stills in the idle loop.
- ARM starts execution from its ROM. It will
- Put DSP into disable state (probably local reset).
- Initialize HW, i.e. PSC, PLL, external memory etc.
- Read bootcfg registers to decide what boot mode it will be and load and run ARM UBL from appropriate boot media, i.e. SPI flash, NAND, NOR etc.
- ARM UBL starts running. Its behavior is totally defined by the SW. For example,
- TI provided ARM UBL will load and run UBOOT which will further load and run Linux. The Linux application can load and run DSP .out via DSPLINK. This model is the same as DaVinci model.
- Industrial customers can choose to load and run a DSP AIS image in certain boot media. Meanwhile ARM UBL also starts booting UBOOT and Linux. In that way, DSP can start processing data before Linux finishing boot.
我是不是可以这样理解:
在不使用linux等系统的裸机开发中,用户所编写的main()函数是在 “ARM UBL starts running” 时才开始执行的;
而在此之前,芯片的行为并不受用户编写的程序 控制, 其执行的代码是早已固化好的,无法改变?
Shine:
建议看一下下的wiki网站关于omap-l138 bootloader.http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader里面有裸机的boot例程。
Zhihua Ge:
回复 Shine:
亲,你说的例程具体在哪啊? 没找到啊。
Zhihua Ge:
回复 Shine:
谢谢, 我看一下哈