-
Notifications
You must be signed in to change notification settings - Fork 458
Firmware m0800
Target
Purpose
Versions
Structure
OS and Libraries
Flashing
Interfaces
The module programs the TMS320DM365 firmware. Location of this chip:
- in P3X, it is on WM320 Gimbal top board
- in OSMO, the location is unknown
Complementary DM36x chip exists within the Remote Controller; the ground part is programmed by module m1300 or m1301 depending on RC version.
Since the camera requires full capabilities of the Ambarella chip for transcoding 4K video, 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 Lightbridge. This also allows higher bitrates of FPV transmission than the ones P3S can achieve via shared Ambarella processing.
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:
openssl des3 -d -k Dji123456 -in P3X_FW_V01.11.0020_mi15.bin -out P3X_FW_V01.11.0020_mi15_decrypted.tar.gz
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 images dji/data/*.img with sfh_DM36x or other chip manufacturers tools, first 0x800 bytes of the files have to be removed.
The firmware consists of U-Boot boot loader and DaVinci Linux as OS.
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 bootloader must be in working order. The firmware module file needs to be unencrypted - flashing a dji-encrypted firmware this way will cause the updated device to crash during startup, and the only way to bring it back to life will be to hook to it directly and flash it using a hardware programmer stick. Note that this applies to Dji 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.
It is also possible to boot the chip into a mode which allows programming it via serial port. Since the board requires 3.3V serial interface, you will need USB to TTL converter (aka FTDI adapter) which supports this voltage.
To switch the boot mode, short the BT01 and BT02 service pads to 3.3V. Connect your 3.3V TTL converter to service pads 368_U0_RXP, 368_U0_TXP and GND. Don't worry about connecting RX and TX incorrectly, switching them will not damage anything, it just won't work. Use TI utilities on connected PC to try flash your new image:
sfh_DM36x -nandflash -v -p "COM21" ubl1.img u-boot.img
If you typed the correct port name, and BT0x pads are shorted properly, you should see Target: BOOTME message. You may to press Ctrl+C to get back to a prompt, and then run the command again. The second time it will work, resulting in message Target: DONE Target: DONE Operation completed successfully..
You will need the unencrypted images of TI DaVinci Linux and the U-boot bootloader to do the flashing.
You can look at the description of the flashing procedure for Lightbridge for some details. There is also a P3P-specific tutorial created by SunsetCatcher; you should be able to find links to his ph3pns.zip archive on PhantomPilots.
This method is based on Serial Boot and Flash Loading Utility provided by Texas Instruments.
Texas Instruments maintains 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.
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 : -WM610-SUPER-UBL-1.0-rc0(2014-09-19) UBL Version: 1.51(Sep 19 2014 - 17:22:26) 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 : -WM610-Uboot-1.0-rc4(2014-08-13) U-Boot 2010.12-rc2-svn- (Aug 13 2014 - 10:55:23) Cores: ARM 486 MHz DDR: 360 MHz I2C: ready DRAM: 128 MiB NAND: 128 MiB Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x000003900000 nand_read_bbt: Bad block at 0x000003920000 *** 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: 2014-11-27 10:20:54 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4032928 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 ## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.32.17-davinci1 Created: 2014-11-27 10:20:54 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4032928 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Kernel Product Vesion : -WM610-Kernel-1.0-rc7(2014-11-27) [ 0.000000] Linux version 2.6.32.17-davinci1 (root@dji) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #5 PREEMPT Thu Nov 27 18:20:50 HKT 2014 [ 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: 44448KB available (3644K code, 452K data, 116K 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.090000] bio: create slab at 0 ...
Transmission configuration is 115200 8N1.
TODO
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).