Microprocessor OMAP35x series chip application information

Kaixin micro test

Memory chip

OMAP35x series startup process:
The first step: configure the startup mode of the CPU (sys_boot);
The second step: the bootROM will read the x-loader from the NAND. After the ECC check is passed, it will jump to execute the x-loader.
The third step: x-loader takes over, initializes PLL and DDR, reads u-boot by x-loader, and then executes u-boot.
Step 4: u-boot runs in SDRAM and boots the Linux kernel.

Note:
The bootROM is a program code that has been solidified inside the CPU (112KBROM) and belongs to TI. It is not open.
The x-loader is programmed in the boot device and the development board provides the source code.
Because u-boot is large, the CPU's internal SRAM can't fit, so it runs in DDR, and the development board provides source code.
The Linux development board provides source code.
All of TI's DSPs, such as OMAP and DM644x's ROM, are masked when the chip is shipped from the factory. Customers can only read and cannot wipe. The BOOT code is stored in the ROM, and some DSP ROMs store some math library functions.
At startup, omap35x will map 1M space from 0x40000000 to 0x00000000. The 80k space starting from 0x40000000 stores the code/data used for encryption and decryption. Of course, the first few bytes are the jump vector table of arm. The reset will jump to the bootrom (0x00014000 or 0x40014000 starting 32k code space), and other vectors will jump to the fixed address of sram to execute. When reset, only need to fill in a few jump instructions to the fixed address of sram to allow other vector processing to jump back to the bootrom processing code. For uboot, the bootloader that does not use mmu only needs to change the instructions of those addresses to jump to uboot's own processing code. Linux with mmu enabled will of course not need to do this.
The emulator is mainly chip-level debugging, or DSP algorithm debugging. After running the OS, the emulator is basically useless. You can use CCS to save the content you want, mainly using the emulator to sram the memory. You are used to commenting out the printk serial output, and the printk buffer is very large. All debug information is stored in the memory. Because of the serial port debugging, the serial port itself can not be used in many environments, and it will cause unnecessary trouble. Use a PINtk that only prints to memory and clean it up.
OMAP3 is suitable for embedded applications where ARM9 and 11 have insufficient processing power. Due to the low power consumption, portable applications are strong, and industrial grade versions are also available, which can also be applied in industrial medical applications.
OMAP3 is not a single chip. At present, 4 are fully pin2pin compatible, and there are chips with DSP and 3D respectively, as follows:
omap3503COTEX-A8+ peripherals
omap3515COTEX-A8+ peripheral + 3D acceleration
omap3525COTEX-A8+ peripherals + DSP and video hardware acceleration
omap3530COTEX-A8+ peripherals + DSP and video hardware acceleration + 3D acceleration The same hardware design can cover different levels of product requirements.

ask:
BeagleBoard uses x-loader+u-boot to start the kernel. I looked at the x-loader code, which is a lite version of u-boot. The main function is to initialize the hardware and then boot from nandflash or mmc/. Sd copies the u-boot code into memory and runs it.
my question is:
U-boot also performs hardware initialization, u-boot also supports reading mmc/sd files, so why not use u-boot to boot directly, and add an x-loader in front? Is there any important reason for this? Thank you.
answer:
U-BOOT is too large to plug into the internal RAM of OMAP3. So use x-load.
When OMAP3 is powered up, read x-load to internal RAM and execute it.
X-LOAD initializes the memorycontroller, reads u-boot into external RAM, and then jumps to the external RAM to execute u-boot.
You can download UBOOT directly through CCS and run it. . .
Remember to download the ELF file, don't download .bin and ask:
If nandflash is started, you can do it by modifying u-boot. The problem is that when mmc/sd is started, it needs to read the contents of mmc/sd. This involves the fat file system. This light is difficult to implement with assembly, so it is only necessary to write a simplified version of u-boot (x- Loader), don't know if this is the reason?
The role of Xloader is to load the initialization code into the on-chip ram, to initialize the chip and peripherals, xload is very small, only a few K size, mainly to initialize the PLL, DDR, only initialized DDR, can download uboot to DDR inside So it can be considered as the following level of startup process:
1. On-chip ROM - support UART, USB, NAND, NOR, MMC1, MMC2, OneNAND, etc.
2.xloader, initialize PLL and DDR, download UBOOT
3.uboot/eboot startup
4.linux/wincekernel startup A:
Xloader has nothing to do with the file system, whether it is nand, onenand or mmc/sd, it is xloader, but in fat32 it must be named MLO to identify. If you can reduce uboot to less than 16K, you can use xloader.
Uboot can also be used to get the USB, of course, you can also use the serial port to print, or the serial port to download uboot
In theory, you can also download UBOOT and kernel debugging with USB, but currently there is a lack of debugging tools. The ready-made is to download xloader or mini-uboot to the on-chip RAM via USB: Xloader/uboot can also be debugged with the 510/560 emulator + CCS.
ask:
1. Is the source code of TI's internal bootrom public?
2. Where can I download?
answer:
Bootromcode is not open to the public.
ask:
OMAP3 graphics processing relationship?
answer:
The three cores are completely independent. Generally speaking, the OS and control, GUI, etc. are all videos running directly on the ARM. There are two ways to accelerate the soft decoding directly with ARM or NEON, and the other is to start. DSP and video hard acceleration for media acceleration, we can think that DSP is just a coprocessor, just algorithm processing from memory to memory, how to do it, how the data stream is completely controlled by ARM, for example, it can be directly decoded and put into the final display video driver buf (video0/1) Similarly, the 3D module is also pure hardware acceleration, controlled by ARM. Generally, the 3D direct output to the OSD buffer (graphIC) is finally displayed on the screen or DVI or S-video. You can control how to perform video buf through sysfs. Overlay or translucent effect with OSDbuf.
Based on the OMAP35x series, TI's CODECENG software framework is used. The media processing algorithm can be placed in the ARM or in the DSP. The upper layer calls some interfaces that have been abstracted to a limited extent, such as Ceate(), Control(), Process(), Delete. (), if using DSP acceleration, the algorithm is in the DSP microcode, through these control command interfaces for encoding and decoding processing.
ask:
Where can I download the OMAP35x bare board test program?
answer:
The SDK_utility of the SDK development kit has ITBOK (IstheboardOK?) integrated in the uboot for board-level hardware testing. Q: NAND startup A: nand startup, the first thing to see is whether it is in the supported bootdeviceID (see below)
The boot code needs to be written in 0-4 blocks and then the xloader needs to add 8 bytes to the header. With the signGP tool, it is also worth noting that ECC requires hardware ECC.
And pay attention to xloader's loadaddress and so on, if not, I am afraid you need to use the emulator to debug. . .
Table26-32.SupportedNANDDevices
CaPACityDeviceIDBusWidthPageSizeinKB
64MbE6h8512
128Mb33h8512
128Mb73h8512
128Mb43h16512
128Mb53h16512

Speak roughly about the situation:
1, flash uses Samsung's film: k9f1g08, id is 0xf1, 2kpage, 128Mbyte, can be found in the list of TI support.
2, the startup code is written at 0 block 0 address
3, x-loader added 8 bytes of head (can be started normally on the sd card)
4, used nandecchw (using hardware ECC) when programming
5, according to the chip datasheet introduction, nandfalsh chip selected to cpu CS0, nandflash busy pin received cpu wait0, no problem under u-boot operation.
Meet the above conditions, you can not be nandboot~
The biggest suspicion now is that ecc has a problem, but the u-boot provided by beagleboard is used. The flash driver uses the original one, but only slightly modifies the flash ID and bit width (the flash used by the beagleboard is 16bit, and we use It is 8bit). I don't know if I can locate the problem from the above information. (The TI firmware code does not print any error messages, otherwise it will be easier.)
Switched to 8bit nand, there are several places that need to be modified:
Configuring GPMC_CONFIG1 in xloader, the default is to configure 16bit, here to be modified to 8bit
In the NAND option, the 16-bit macro definition is killed; in the EOC OOBINFO, since 8bitnand only uses one byte to indicate whether it is a bad block, but the default uboot is configured as 16-bit two bytes, that is, the ECC value is to be The second byte starts, not the third byte; the other uses the default code, it should be fine; remember to add x-byte header when burning xloader, and must use hwecc.
The result of ecc under 8bit, but did not pay attention to the location of storage. Modify the ecc storage location, the oscilloscope observes the chip selection, it should be able to determine that part of the code is copied to the internal ram, but still can not be started, it seems that the data is always copied. I don't know if it is because of the .3.3 nand caused by the conversion of cpld. Or tmx film version 2.1, the original document rom I read does not support mlc nand, now the document says it is also supported. Another easy to ignore is the bit width of GPMC. By default, the 16-bit mode is set in the xloader code. If you use 8bit, you need to pay attention to modify the CONFIG1 register of GPMC. "................................. looks like the data is always being copied.", you mean After exiting nandboot (for example, entering uart3boot, you can see serial port printing 40T). Using oscilloscope test, I found that the nandflash chip select pin always has a signal?
There was such a problem before, and it was confirmed that the storage location of hwecc was not correct (TI boot code for the bit position of 8bitnandflash hwecc and 16bit nandflasht just staggered one), also pay attention to the bit width of gpmcbank0 under u-boot To set it up correctly, goodluck.
DJBean, because it is only tested whether it can be started from nand, so it should be understood that the omap rom will copy the entire x-load content to sram, so even if the x-load code is wrong (such as GPMC), it can also start x-load. For example, the serial port sends data, etc., but can't run u-boot anymore, right?
Luofuchong, after nand failed to start using the 560 emulator to observe the copy of the address and data, found that if the x-load is larger than a certain size of the data is wrong, if the code is small, such as 4k, the content is correct, but still can not start .

The current ecCOBb looks like this:
Eccbytes=12,
.eccpos={1,2,3,4,5,6,7,8,
9,10,11,12},
.oobfree={
{.offset=13,
.length=51}}
Why do you need to use hwecc to burn xloader? BOOTROM uses hwecc when loading x-loader, and swecc when x-loaderloaduboot is used.
The problem now is, after the x-loadr is burned into the nandflash with the tool, what information is not printed on the serial port, but the GPMC_cs0 pin has a signal. Using the tool to read the data in the NF and compare it before downloading, it is exactly the same. Is it caused by hwecc? If the download software itself is related to hwecc, it is suspected that there is a problem with the download tool. . . . . .
Now it is the bootloader of wince. Like linux, it is also a two-level boot (x-load and eboot). TI provides a download tool EVMFlash, which can directly load x-loaddownloadNANDFlash. The download was successful. The comparison between the data read from the NF and the download was exactly the same, but I don't know why the program was not executed.

USB problem:
Regarding the USB problem, the default is not to open the hotplug-in, that is, if there is a USB hub when the power is on, the system can detect it. If the USBHub is not plugged in when the power is on, it may be detected after the system is added. To, the method is to execute the following command (can also be placed in rcS):
Echo"S">/proc/driver/musb_HDRc;
This will support the hot plugging of USBHub and USB devices;
As zqdsp said, due to power supply problems, usbhub with external power supply is required;
The beagle's USBOTG cannot be directly connected to peripherals such as a USB flash drive, because the power supply of the OTG interface is directly supplied by the TWL4030, and the maximum supply current is 100mA. Therefore, it is necessary to externally connect the USB hub to the mouse, keyboard, U disk, etc., and this HUB must also be an active HUB with external power supply.
I suggest you not to buy cheaper active USBHUB in the market. A total of 4 HUB, 20, 30, 50, 100 were bought on the market. In the end, it is still easy to use 100. Others plugged in the mouse and so on. The above is personal experience and is for reference only.
The USB virtual serial device is a USB as a serial port gadget. The actual speed is the speed of the USB, not the speed of the serial port.
Q: About the omap3530+tps65930 boot process.
I used the devkit8000 board. Once the power is connected, the code runs. But to do the handheld device should press the power button for 2 seconds before powering on, how should this be achieved??
A: The bootloader determines if there is any GPIO pressed, and the timer starts. Otherwise, the bootloader directly shuts down the power management chip. Ask the master DevKit8000 how to install ubuntu-arm steps, debian can also follow http://elinux.org/BeagleBoardHandhELDsMojo
Did, after loading the kernel to the bootkernel, it was stuck.

OMAP3530 board debugging has some problems. Because it is more complicated, I don't know if I can make some suggestions or help me find relevant personnel to reply. The domestic TI FAE does not seem to be very clear when it comes to these specific problems:
1) Does the OMAP3530 have to be used with the TPS65930? What happens if I remove the TPS65930?
2) According to Ruitai's MINI board design, but found in the welding process TPS65930 board problem, can not be soldered, so only make up the work, mainly including power supply, 26M clock, 32.768K clock changes, now passed JTAG debugging, found that the power supply, two clocks can be, the chip should work, but there is no way to boot from the SD card, is the SD card INS pin connected to the TDS65930 CARDDETECT foot but there is no way to solder TPS65930 caused? If so, can you circumvent it by modifying something, or can you only change the BootROM of the OMAP3530? But BOOTROM I am afraid that only TI can change.
3) If 2) can't be solved, I want to start from the serial port 3 of OMAP3530. I don't know what to do?
4) If 2), 3) still can't be solved, can USB1 and USB2 from OMAP3530 start? How to start? USB0 is on the TPS65930, there is no way to use it.
5) If the above does not work, then only redo the printed board?
Start it from UART3! Find TI's FAE to get the EVMFlash tool! But the serial port can only be downloaded from the bootloader, and the kernel or image is downloaded from the Ethernet.

ARM and DSP coordination:
The DSP can fully access the McBSP, and the same operation of the memorymap register is just fine. In addition to some specially described interfaces, the DSP is accessible, but general-purpose applications are generally not recommended, because the ARM management peripherals and drivers are more standard and suitable, and some special applications can also use DSP to access peripherals.
The same operation memory register can be used, is it said that the DSP side and ARM side are operating the same McBSP register?
The chapter on McBSP on the OMAP3530 datasheet talks about the control register address of McBSP. For example, the base address of McBSP1 is 0x48074000, and the size is 4KBytes. Is it that ARM and DSP both control McBSP1 by accessing the register at 0x48074000? Looking at the datasheet, the rest seems to be the address of the register that is not mapped to McBSP1. Is DSP and ARM sharing the 4G address space? It feels a bit confusing for this dual-core address space distribution, and the concept is unclear.
Also read the chapter on memorymapping, MPU and IVA2.2 have their own 4G address space, of which only a small part of the 2G space has a corresponding part, and the other is completely irrelevant. For example: the address on the ARM side: 0x5C000000~0x5CFFFFFF corresponds to the DSP side: 0x00000000~0x00F17FFFF, this part can access L1RomRam, L2RomRam. But it is not found the register address of McBSP on the DSP side.
Tried with the emulator, the demo with one is running on the arm, one is running on the dsp, it should be two programs can use the same address to access the peripherals (tested UART1, several registers of McBSP1 The read value of the read register is exactly the same as that described on the datasheet. After modifying the program running on the ARM side, the program on the DSP side is started to view the related memory and register values, followed by the ARM side. The consistency of the changes. So dsp is directly accessible to peripherals.

How to write xloader and uboot to the flash of oaMP3530?
In u-boot:
Burn XLoader to NandFlash:
OMAP3Miniboard#mw.b80000000ff80000
OMAP3Miniboard#mmcinit
OMAP3Miniboard#fatloadmmc0x-load.bin.ift
Readingx-load.bin.ift
11412bytesread
OMAP3Miniboard#nandecchw
OMAP3Miniboard#nanderase080000
NANDerase: device0offset0x0, size0x80000
Erasingat0x60000--100%complete.
OK
OMAP3Miniboard#nandwrite80000000080000
NANDwrite: device0offset0x0, size0x80000
524288byteswritten:OK
Burn U-Boot:
OMAP3beagleboard.org#mmcinit
OMAP3beagleboard.org#fatloadmmc0u-boot.bin
Readingu-boot.bin
147424bytesread
OMAP3beagleboard.org#nandunLOCk
(Note-ifyouareusingamorerecentversionofU-Boot,nandunlockismissing
simplyskipthisstep.ieU-boot2009.08)
device0wholeChip
Nand_unlock: start, length!
NANDflashsuccessfullyunlocked
OMAP3beagleboard.org#nandeccsw
OMAP3beagleboard.org#nanderase80000160000
NANDerase: device0offset0x80000, size0x160000
Erasingat0x1c0000--100%complete.
OK
OMAP3beagleboard.org#nandwrite8000000080000160000
NANDwrite: device0offset0x80000, size0x160000
1441792byteswritten:OK
OMAP3beagleboard.org#
This is the best solution in the case where u-boot already exists.
Encountered this situation: no uboot in omap, or u-boot is damaged, how to write. ICETEK-OMAP3530-MINI can be started from the sd card at any time, that is, start u-boot from the sd card and then burn the flash serial port. You need to download the xloader first, then download the ubootmini board in the xloader and restart it every time (the bare metal case). The sequence starts from flash, USB, serial port, and sd card. Each time it starts, it will output a string of characters from the serial port. I use the pseudo in OMAP-U-Boot-Utils tool to download x-loader to flash. The method is as follows: ./pserial -p/dev/ttyS0-f./u-boot.bin, and then start the terminal output content unchanged, what is going on? Whether the download is not successful
In the case of flash all empty, what is the way to download u-boot. The serial port is still the simple JTAG emulator.
Can dsp debugging be done by printing?
Flash empty write can use EVMFlash tool, USB and serial port can be written.
Similar tools are available on Beagle.
Format the SD card into fat32 format, first copy the MLO file to the card, then copy the u-boot.bin to the card, you can start uboot from the SD card, then use uboot to burn xboot to nand
NANDflash has Badblock. If your image file is as large as the partition, it may be because the Badblock is not completely written. Generally, the partition needs to allocate several more blocks for backup.
ES3.1 is the version number of the chip, the version number of the chip is different, and some chip bugs are not the same.

Dual-core communication:
Dual core means that each core is independent and needs to be developed separately. Then the two cores communicate and exchange data. The difference between multi-chips is that the communication methods are different.
So to develop on DSP, use DSP's open-loop tool -- CCS or CGtools
Then you can double-core communication based on DVSDK's software framework. Q: The OMAP3530MINI board is ARM and DSP dual-core. Their hardware is connected through the HPI in the DSP. So what is the instruction to be called by the ARM in the DSP processed data? Or, use the Linux command to achieve!!!!
A: Use DSP/BIOSLINK to provide a set of APIs for ARM side calls, share memory or mailbox communication, and use dsplink to do the underlying communication software. Dual cores need to be developed separately. Communication needs to be strictly unified, and memory avoids conflicts.
Q: D is big, hello, can I use OMAP3's DSP like this:
Run a LINUX system for applications (such as network services) under OMAP's MPU. The DSP is used to poll a GPIO (without interrupts). These two parts are required to be processed in parallel. Once the DSP processing is completed, the MPU is notified (interrupt?) Read the data obtained after DSP processing. May I? How to achieve a specific point?
A: It can be used like this. Don't you think it is too wasteful? General ARM is used to run the operating system, drivers, applications, gui and the like, DSP is to do algorithm acceleration, that is, DSP is basically memory to memory algorithm processing. Q: Linux is using linux multi-tasking operating system How does ARM call and share the memory in dsp? It is not directly addressable like a single-chip. A: The chip can access any physical address space. The user layer of linux accesses the virtual address, so it needs cmem and the like. The driver to access the physical address space, or other drivers must first reserve the DSP running space for the DSP, and then ARM access through the kernel driver, DSP can access any physical space to share a very good code, DirectFB has DSP virtual An example of a peripheral, very good, and there are examples of mutual communication, for reference...
This is not the reason for the MMU, it is caused by the power management of OMAP3. First explain the original intention, JTAG can only do chip-level simulation, if you run the OS, after the JTAG breakpoint processing, the OS will crash, so after the OS is up, it is assumed that the simulator will not be connected; such as Davinci, if After running the OS, even after the emulator, the OS will crash and say OMAP3. The EMU is an independent power domain. It can be completely turned off by the PRCM. After the OS is up, the EMU's power domain will be turned off, including the clock. So I can't connect at this time. When the chip has just started, or the SW1 jumper, EMU0 is pulled down, the EMU is working, and can be connected to the emulator.
How to develop omap3530 under WindowsXP?
How to develop bootloader?
Is there a startup program like Xloader?
Can this X-loader be compiled on CCS? What is the difference between X-loader and Linux?
CCS can't directly compile xloader, because gnugcc's assembly compiler and CCS are not the same. The compiled xloader can be downloaded to the board through CCS+JTAG for debugging.

DSP/BIOS core
The DSP/BIOS core acts as a real-time operating system that supports TIDSP and microprocessor devices and is directly supported by TI and is available for free. The DSP/BIOS core is fully integrated with the CodeComposerStudioTM (CCStudio) integrated development environment (IDE) and supports both single-core and multi-core devices.
â—† DSP/BIOS kernel provides DSP/BIOS5.x and DSP/BIOS6.x versions.
â—† DSP/BIOS5.x is compatible with both CCStudio 3.x and 4.x versions and supports all TIDSPs released before 2010. For complete details on features and device support, see the DSP/BIOS5.x product folder .
â—† DSP/BIOS6.x requires CCStudio4.x; and in addition to newer DSP devices, it also supports ARM and MSP430 microprocessor devices. It also provides a number of extras compared to DSP/BIOS 5.x.

ARM+DSP dual-core architecture development:
For the peripheral interface of the chip, the ARM core and the DSP core can be accessed. Typically, the ARM controls all peripherals and controls and manages them through the driver on the OS. This part is similar to the traditional ARM chip; the DSP mainly performs Algorithm acceleration, just dealing with memory, in order to maintain the consistency of the chip's resource management, try to avoid access to peripherals by the DSP. Of course, according to the specific application requirements, the DSP can also control the peripheral interface for data transmission and reception. At this time, the system management needs to be done to avoid the conflict of dual-core operations.
The application program downloads the DSP program and controls the DSP chip. The external RAM space, that is, the DDR memory area, is shared between the ARM and the DSP. However, in the system design, the strict physical address of the memory used by the ARM and the DSP needs to be separated, and a part of the memory space for interaction is reserved. In general, ARM uses low-end addresses. The DSP allocates high-end addresses through CMD files, and some space is reserved for data interaction. For example, in DVSDK under OMAP3 Linux, 128MB of DDR space is divided into three parts, low-end. The 88MB space from 0x8000000 to 0x85800000-1 is used by the Linux kernel; 16MB from 0x85800000 to 0x86800000-1 is used to drive the CMEM for ARM and DSP bulk data exchange. The 24MB from 0x86800000 to 0x88000000-1 is DSP. Code and data space.
The startup of the chip is also a key issue to be considered. In general, it is an ARM boot. Like the traditional single-core ARM, it supports different boot modes. For example, it can support NAND, NOR, UART, SPI, USB, PCI and other interfaces. The DSP is in the reset state by default, and the DSP can only run after downloading the code through the ARM application and releasing the reset. In some application scenarios, the DSP needs to be started directly from the external power-on. Some chips also support this mode.
Finally, regarding the communication and synchronization of the chip, this is a problem that plagues many engineers. In order to facilitate the development and use of the customer, TI provides DSPLINK, CODECENGINE's DVSDK development kit, which can easily carry out ARM+DSP application development based on DVSDK. The following is a brief introduction to the software architecture of DVSDK and the functions of each software module.
DVSDK is the integration of multiple software modules, including pure DSP-side software modules, ARM software modules and dual-core interactive software modules. The DVSDK software package is based on real-time software module (Real-Time-SOFtware-Component:RTSC). It also needs to install RTSC tool XDC. XDC is a tool of TI open source, which can support cross-platform development, which can maximize the degree. Code reuse; if you need to develop pure ARM, you need ARM compiler tools and Linux kernel or Wince BSP; if you need DSP algorithm development or DSP side execution code generation, you also need to install DSP compiler cgtools and DSP. /BIOS; In order to facilitate the configuration to generate DSP-side executable code, the Codec RTSC package and executable code are generated through the wizard, and ceutils and cg_xml can also be selected.
The core of DVSDK is CodecEngine, and all other software modules are basically around CodecEngine. CodecEngine is a bridge between ARM and DSP. It is a software module between the application layer (the application on the ARM side) and the signal processing layer (the algorithm on the DSP side). When compiling the DSP executable code and the ARM application, , all need CodecEngine support. CodecEngine has two main parts:
The ARM-side application adaptation layer provides a streamlined API and corresponding libraries for use by the application layer.
The algorithmic call layer of DSP provides the interface encapsulation specification of DSP algorithm. All the algorithms can be compiled into the executable program of DSP through simple configuration.
The final application needs to download the DSP code through the API interface of CodecEngine, call the packaged algorithm on the DSP side, and communicate with ARM and DSP.
For an introduction to CodecEngine, you can refer to "Getting Started with CodecEngine for You".
The underlying ARM and DSP communication of CodecEngine is built on top of DSP/BIOSLink. DSP/BIOSLink truly implements the software module for ARM and DSP interaction. Because DSP/BIOSLink is cross-platform, it also has ARM part and DSP part. Among them, on the ARM side, including OS-based driver and supply library files, the DSP side must use DSP/BIOS, DSP executable. The code needs to contain the library files for DSP/BIOSLink. DSP/BIOSLink commonly used are the following software modules:
PROC related, mainly used to control the DSP chip, such as start, stop, etc., download the executable code of the DSP, and directly read and write the memory space of the DSP side, etc.
MSGQ related, ARM and DSP communication is based on MSGQ, MSGQ has polling waiting mode or interrupt mode, MSG is based on shared memory pool. CodecEngine uses MSGQ to interact with some key data, such as controls, and address pointers for some large blocks of data. A large amount of data interaction needs to be implemented by cmem.
On the ARM side, the software modules used with CodecEngine include LinuxUtils or WinceUtils, including cmem, SDMA, etc., cmem is used to allocate contiguous physical memory space outside the OS, physical address to virtual address, and virtual address to physical address space conversion. of. In order to avoid multiple copies of data, it is necessary to open up a data space shared by ARM and DSP. ARM and DSP can directly access this space, which needs to be managed by CMEM. For ARM, CMEM is a driver on the OS that needs to implement memory allocation or address space conversion through IOCTL. Since the DSP can access any physical address space, the pointer passed to the DSP via ARM must be a physical address.
In order to adapt to some player interfaces, DVSDK also provides DMAI (DigitalMediaApplicationInterface), DMAI provides a more streamlined media interface and OS-based audio and video capture, playback and other interfaces, gstreamer under Linux and dshowfiLTEr under Wince It is based on DMAI. And DMAI also provides the most basic test application examples, which can be easily modified and tested.
If you just call the ready-made or third-party algorithm library, you can only understand the ARM-side software module. CodecEngine or DMAI has provided a rich application interface. DSP can be considered as a pure media accelerator, and the ARM+DSP chip is treated as an ASIC. use. If you want to make full use of the performance of the DSP, you need to develop the DSP. CodecEngine's algorithm for DSP only specifies the interface to facilitate the generation of DSP executables with CodecEngine.
The engineers who developed the DSP algorithm are similar to the traditional single-core DSP development mode. They only need to operate the DSP core, develop the algorithm based on CCS, and finally encapsulate the interface into xDM. Specifically how to package the DSP, how to generate the executable program of the DSP, continue to discuss in the following articles.
Some time ago, the design of the omap3530 was completed. The EMIf, dss, cam and other interfaces were all 1.8V. At present, the common LCD screen and coms sensor are 3.3vIO, so they have to add coolrunnercpld for level conversion. But think about omap mainly for handheld platforms, so forget...
Then now I am doing a dm357 thing, 357 is also the same with 1.8v IO, which is a bit puzzling, dm357 was originally for the h264 monitoring system platform, this is also too inappropriate for 1.8V, hanging tvp5146 To convert, hang a large capacity nand also to convert, (1.8v nand is also very difficult to buy). Uart and so on have to be converted, platform costs and PCB space have greatly increased. For example, 1.8V ttl2rs232 is almost 20, and 3.3 of 5 is enough.
Although 1.8 is a trend, why not make an IO voltage that can be selected?
For example, atmel does a good job, the corresponding IOBank has different power pins, and 1.8 is 1.8 IO, 3.3 is also compatible, how good.
TI now has a new LevelShift, low price and good performance, can provide a full range of 1.8V to 3.3V interoperability, please visit
OMAP3530 is ARM+DSP+3D acceleration processing. It is a multi-core processor. It can be considered as a multi-chip synthesis of one chip. That is, the DSP core can be considered as an independent DSP chip for development. The ARM core is pure. ARM OS / application development, 3D can also be considered as ARM control core, the other is accelerated processing. To facilitate multicore development, TI provides a CODECENG software framework for interaction with DSPs.
Before the specific development is involved, the software engineer is divided into divisions. At present, the chip is so complicated that it is impossible for one person to be responsible for all things, and the background of ARM application development and DSP development is different:
First, the algorithm engineer of DSP can completely ignore the ARM processor core. The algorithm of pure DSP can be developed based on CCS. It is the same as the work responsibility of traditional DSP. It should be clear that all algorithms can be considered as processing from memory to memroy. It has nothing to do with peripherals. A peripheral is just a data channel. After the algorithm is implemented, it needs to be packaged into a standard interface of xDM, which is convenient for application integration and multiple DSP algorithm links to generate DSP microcode.
Engineers who do media applications or algorithm calls on ARM need to understand the framework of CODECENG. The DSP side can generate DSP microcodes through several algorithms that configure xDM interfaces. In Linux development, TI provides some software packages, such as: BIOS, XDCtools, CGTools, Framecomponent, etc., can generate DSP microcode. CODECENG provides a limited number of standard interfaces on the ARM side. It is convenient for applications to be ported to different platforms, and can directly call DSP-side algorithms to accelerate upper-layer systems or application engineers. It is to do traditional ARM application development without any consideration of DSP. Or 3D is how to implement the driver is not related to the DSP. If you need 3D, you can download the OpenGLES2.0 SDK (free) from here, on the PC (Windows and Linux support) simulation, and finally Cross-compilation on omap3 is all you need.