-
Notifications
You must be signed in to change notification settings - Fork 410
Firmware m0800
Target
Purpose
Versions
Structure
Boot process
OS and Libraries
Flashing
Interfaces
The module programs a DM36x Media Processor firmware. Location of this chip:
- in WM610, TMS320DM368 is on WM610 X5 Camera Live View Encoder board
- in P3X, TMS320DM365 is on WM320 Gimbal top board
- in P2VP, TMS320DM36x is on WM301 Live View Encoder board
- in P2V, TMS320DM36x is on FC200 Live View Encoder board
- in OSMO, the location is unknown
Complementary DM36x chip exists within some of Remote Controllers; the ground part is programmed by module m1300 or m1301 depending on RC version. The chip in ground part is really only neccessary for transcoding the video for HDMI output, so not all devices have it.
Since the camera requires full capabilities of the Ambarella chip for transcoding high resolution video (4K video in case of P3P and Inspire), the secondary video encoding channel (for FPV) is processed by a separate hardware. The firmware contains video encoder which prepares video for FPV transmission through radio channel (WiFi in P2 drones, Lightbridge in other). This also allows higher bitrates of FPV transmission than the lower tier platforms can achieve via shared Ambarella processing (ie P3C).
There are multiple versions, encrypted, but not by the usual Dji method.
| Marking | Packages | Timestamp | Overview |
|---|---|---|---|
| 00.10.0004 | P3X_FW_V01.01.1003 | 2015-04-30 | |
| 00.11.0004 | P3X_FW_V01.01.0006 P3X_FW_V01.01.0008 P3X_FW_V01.01.0009 P3X_FW_V01.01.1007 P3X_FW_V01.02.0006 | 2015-05-01 ... 2015-07-10 | |
| 00.12.0004 | P3X_FW_V01.03.0020 P3X_FW_V01.04.0005 P3X_FW_V01.04.0010 | 2015-07-24 ... 2015-09-02 | |
| 00.13.0007 | P3X_FW_V01.05.0030 P3X_FW_V01.06.0040 P3X_FW_V01.07.0043_beta P3X_FW_V01.07.0060 P3X_FW_V01.08.0080 P3X_FW_V01.09.0060 P3X_FW_V01.10.0090 | 2015-11-23 ... 2016-11-07 | |
| 02.14.2330 | OSMO_FW_V01.00.01.19 WM610_FC550_FW_V01.08.00.92 | 2015-10-15 ... 2016-03-24 | |
| 02.14.2341 | OSMO_FW_V01.04.01.80 | 2015-12-26 | |
| 02.14.2345 | OSMO_FC550_FW_V01.01.00.02 | 2016-01-19 | |
| 02.14.2346 | OSMO_FC550R_FW_V01.01.00.01 OSMO_FC550R_FW_V01.01.00.03 OSMO_FC550R_FW_V01.01.00.04 OSMO_FC550R_FW_V01.01.00.10 OSMO_FC550R_FW_V01.02.00.11 OSMO_FC550R_FW_V01.03.00.30 OSMO_FC550R_FW_V01.03.00.40 OSMO_FC550_FW_V01.01.00.03 OSMO_FC550_FW_V01.01.00.04 OSMO_FC550_FW_V01.01.00.05 OSMO_FC550_FW_V01.01.00.07 OSMO_FC550_FW_V01.01.00.08 OSMO_FC550_FW_V01.01.00.09 OSMO_FC550_FW_V01.01.00.11 OSMO_FC550_FW_V01.01.00.13 OSMO_FC550_FW_V01.03.00.30 OSMO_FC550_FW_V01.03.00.40 OSMO_FW_V01.05.01.88 OSMO_FW_V01.05.01.89 OSMO_FW_V01.05.01.92 OSMO_FW_V01.05.01.93 OSMO_FW_V01.05.01.94 OSMO_FW_V01.05.01.95 OSMO_FW_V01.05.01.96 OSMO_FW_V01.05.01.97 OSMO_FW_V01.05.02.00 OSMO_FW_V01.06.02.10 OSMO_FW_V01.08.02.30 OSMO_FW_V01.08.02.35 OSMO_FW_V01.08.02.36 OSMO_FW_V01.08.02.40 WM610_FW_V01.08.00.92 | 2016-01-31 ... 2016-09-26 |
The module is encrypted using OpenSSL salted format. Password is "Dji123456". Here is an example decryption command (using openssl 1.1.0):
openssl des3 -md md5 -d -k Dji123456 -in P3X_FW_V01.11.0020_m0800.bin -out P3X_FW_V01.11.0020_m0800_decrypted.tar.gz
In drones from P2 family, firmware updates do not include any update for the DM36x chip and there is no official way to reflash them.
Unencrypted firmware is a TAR GZip archive containing some Linux tools, boot configuration and kernel modules. It also contains partition images which can be flashed.
In order to use the decrypted bootloader images dji/data/*.img with sfh_DM36x or other chip manufacturers tools, first 0x800 bytes of the files have to be removed, ie.:
dd if=dji/data/u-boot.img of=u-boot_prop.img bs=2048 skip=1 dd if=dji/data/ubl_297m_1.img of=ubl_297m_1_prop.img bs=2048 skip=1 dd if=dji/data/ubl_432m_1.img of=ubl_432m_1_prop.img bs=2048 skip=1 dd if=dji/data/ubl_486m_1.img of=ubl_486m_1_prop.img bs=2048 skip=1
Note that instead of one ubl1 image, there are 3 variants. The specific variant to use depends on the board variant (CPU frequency) you have, though only the 297MHz boards are known to exist. To see how the ubl1 image is selected, look at dji/etc/updatefinish script. Usually your max frequency can be easily determined by chip markings:
- DM365 chip can only use 297MHz clock
- DM368 can go up to 432MHz
- DM368E has the max frequency of 486MHz
The files included in firmware update are written in appropriate places of the 128MB NAND flash memory.
Map of the flash memory in P2VP and all newer products is as follows:
| Offset | Description | Content |
|---|---|---|
| 0020000 | U-boot init | ubl?.img, a copy every 0x20000 bytes; initial startup code for u-boot |
| 0320000 | U-boot app | u-boot.img, a copy every 0x60000 bytes; main part of the u-boot bootloader |
| 0420000 | U-boot env | environment variables for the u-boot bootloader; usually not set |
| 04a0000 | Primary kernel | uImage; the Linux Kernel normally used for booting |
| 0900000 | Recovery kernel | uImage_recovery, not included in FW updates; the Linux Kernel which is used when primary kernel gets corrupted |
| 0d60000 | Encrypted data | Hardware-encrypted partition |
| 0e00000 | Root Filesystem | ubifs-partition.ubi; Linux Root Filesystem, using UbiFS; contains kernel modules, tools and applications |
| 7f00000 | End of flash | also end of Root Filesystem partition |
Map of the flash memory in oldest product, FC200 camera from P2V:
| Offset | Description | Content |
|---|---|---|
| 0020000 | U-boot init | ubl?.img, a copy every 0x20000 bytes; initial startup code for u-boot |
| 0320000 | U-boot app | u-boot.img, a copy every 0x60000 bytes, 8 copies total; main part of the u-boot bootloader |
| 0640000 | U-boot env | environment variables for the u-boot bootloader; usually not set |
| 0680000 | Primary kernel | uImage; the Linux Kernel normally used for booting |
| 0980000 | Recovery kernel | uImage_recovery; the Linux Kernel which is used when primary kernel gets corrupted |
| 0be0000 | Old filesystem | Part of old, damaged UbiFS filesystem |
| 1280000 | Root Filesystem | ubifs-partition.ubi; Linux Root Filesystem, using UbiFS; contains kernel modules, tools and applications |
| 7f00000 | End of flash | also end of Root Filesystem partition |
After reset signal pulls to zero, control is given to embedded bootrom (referred to as ROM Boot Loader in TI docs). The bootrom decides of boot method based on BTSEL[2:0] pins configuration. By default, these pins are pulled down, triggering NAND Boot. In NAND Boot mode, bootrom copies a User Boot Loader from NAND flash to ARM internal RAM, and transfers control to that user-defined bootloader. The bootrom also makes sure to update boot status (PASS/FAIL) in MISC register bits 8 and 9 in System control module.
The details and list of possible selections for boot process are available within TMS320DM365 Digital Media System-on-Chip (DMSoC) document, provided by TI as sprs457e.pdf.
The bootloader used by DJI is U-Boot (actually, that is the default bootloader proposed by TI in their DaVinci Linux). The bootloader loads primary kernel from NAND to memory, verifies it, and executes with hard-coded parameters (custom boot parameters area is clean, so u-boot goes with defaults). In case primary kernel fails verification, a secondary kernel is loaded instead.
The Linux kernel then starts booting. Besides normal operations, it also initializes some additional kernel mode drivers - in particular, there is AT88/ATSHA204 module compiled into the kernel, which reads and decrypts hidden partition stored on the NAND. If the decrypted data in incorrect, initialization of that module may end in infinite loop.
Next, Linux kernel mounts the Roof Filesystem, and continues with the boot. It uses UbiFS filesystem, allowing to utilize error check capabilities of the NAND chip. Some non-standard kernel modules are loaded from the root filesystem as well, in particular one for Cypress chip. Probing the Cypress module does not require connection to the actual chip.
When kernel startup is done, console-based user space is initialized. The video transcoding application is loaded automatically, and starts retrieving video from Ambarella and transferring it over USB to Cypress chip. If connection to Cypress cannot be established after a few retries, some boards will trigger reset.
If everything succeeds, the transcoding application continues to run, periodically displaying statistics of video data transferred on the serial console.
The firmware consists of U-Boot boot loader and DaVinci Linux as OS.
The DaVinci Linux kernel in Lightbridge-capable devices has additional modules compiled into it, and can use some additional non-standard .ko modules. These include Atmel AT88 cryptoflash support, and Cypress USB controller driver.
Since this firmware is used on many various products, some of the flashing methods may not be listed here. Some methods may also not apply to a specific platform.
This method requires a working communication between the chips on camera module. Ambarella FW and DM365 bootloader must be in working order.
See Flashing firmware via SD-card by official package in camera for details.
This method requires a working communication between the chips on camera module. Ambarella FW and DM365 Linux must be in working order. The firmware module file needs to be unencrypted - otherwise the update will fail. Note that this applies to Dji package encryption - the firmware can be OpenSSL-salted, as dealing with this is implemented on a different level.
See Flashing firmware via SD-card by firmware module in camera for details.
This is a very reliable method of fixing a board with damaged firmware. Requires removing target board from the device and basic soldering skill. It is explained in detail on the page Flashing firmware on DaVinci media processors.
Texas Instruments maintained an extensive Wiki with information about ways of Writing Image to NAND Flash for their processors.
What they propose as primary method is to update the firmware via Ethernet controller by using U-Boot boot loader functionalities. The wiki also discusses flashing the U-Boot itself, and contains links to descriptions of other flashing methods.
Applies only to lightbridge-capable products.
The software sends encoded video data to USB Controller on the OFDM board, which is controlled by Firmware m1500. It provides the only interface between the camera and the Cypress USB Controller - if there is an issue in the DM368 chip or software, it will not be possible for camera to contact the USB Controller. This leads to a common issue when a firmware update cannot reach two modules:
[timestmp]Version checking[3]... [timestmp][15 00][00] device not detected. [timestmp][08 00][00] device not detected.
Such issue is always caused by the m0800 module.
The serial interface can be used to access shell on the DaVinci Linux. It allows both input and output.
A typical boot sequence which can be seen on the 368_U0 interface is as follows:
DM36x initialization passed! UBL Product Vesion : DJI-297M-UBL-1.0-rc0(2015-10-30) Dji UBL Version: 1.51(Nov 2 2015 - 15:45:39) Booting Catalog Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x00000019. DONE Jumping to entry point at 0x81080000. U-Boot Product Vesion : DJI-ENC-Uboot-1.0-rc0(2015-11-02) U-Boot 2010.12-rc2-svn3205-Dji (Nov 02 2015 - 19:07:26) Cores: ARM 297 MHz DDR: 270 MHz I2C: ready DRAM: 128 MiB NAND: 128 MiB MMC: davinci: 0 Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 *** Warning - bad CRC, using default environment Net: Ethernet PHY: GENERIC @ 0xff DaVinci-EMAC Press ESC to abort autoboot in 1 seconds Loading from nand0, offset 0x4a0000 Image Name: Linux-2.6.32.17-davinci1 Created: 2015-11-02 7:28:36 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4050848 Bytes = 3.9 MiB Load Address: 80008000 Entry Point: 80008000 ## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.32.17-davinci1 Created: 2015-11-02 7:28:36 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4050848 Bytes = 3.9 MiB Load Address: 80008000 Entry Point: 80008000 Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Kernel Product Vesion : DJI-WIFI-WM610-Kernel-1.0-rc4(Nov 2 2015-15:24:51) [ 0.000000] Linux version 2.6.32.17-davinci1 (root@xueb-VirtualBox) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 PREEMPT Mon Nov 2 15:28:34 CST 2015 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] Machine: DaVinci DM36x EVM [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] DaVinci dm36x_rev1.2 variant 0x8 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 12192 [ 0.000000] Kernel command line: console=ttyS0,115200n8 rw dm365_imp.oper_mode=0 video=davincifb:vid0=0,0:vid1=0,0:osd0=0,0:osd1=0,0 mem=48MB davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=pal ubi.mtd=2,2048 root=ubi0:rootfs rootfstype=ubifs ip=off lpj=1077248 [ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes) [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Memory: 48MB = 48MB total [ 0.000000] Memory: 44432KB available (3652K code, 453K data, 120K init, 0K highmem) [ 0.000000] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:245 [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Calibrating delay loop (skipped) preset value.. 215.44 BogoMIPS (lpj=1077248) [ 0.000000] Mount-cache hash table entries: 512 [ 0.000000] CPU: Testing write buffer coherency: ok [ 0.000000] DaVinci: 8 gpio irqs [ 0.000000] NET: Registered protocol family 16 [ 0.130000] bio: create slab at 0 [ 0.140000] DM365 IPIPE initialized in Continuous mode ...
Transmission configuration is 115200 8N1. It uses 3.3V logic.
If you can't see any message, it is possible that the DaVinci chip cannot boot from NAND memory. To be sure, short BT00 and BT01 to 3.3V - this will cause it boot from internal ROM, and you should see continuous stream of "BOOTME" messages at serial console. If you can't see these, either your FTDI setup does not work or your DaVinci chip is dead.
The DaVinci chip features Ethernet interface. In Lightbridge-capable products the interface is normally not configured, but firmware contains a script to bring it up: eth0config. The script will configure DaVinci IP to 192.168.1.10.
The DaVinci chip receives video from Ambarella SoC. The video is transmitted as HDMI YUV signal to DaVinci HDMI input.
This page is created by drone enthusiasts for drone enthusiasts.
If you see a mistake, or you know more about specific subject, or you see an area for improvement for the wiki - create an issue in this project and attach your patch (or describe the change you propose).