-
Notifications
You must be signed in to change notification settings - Fork 426
Firmware m1300
Target
Purpose
Versions
Structure
OS and Libraries
Flashing
Interfaces
The module programs the TMS320DM368 firmware. Location of this chip is GL300 Interface board.
Complementary DM36x chip exists within the drone gimbal; the air part is programmed by module m0800.
The firmware is used on all boards with HDMI output, and on GL300a boards even if no HDMI output is present. Other RC models have the DM368 chip removed, so the firmware is not used.
The DaVinci firmware handles video transcoding between Lightbridge compression and the compression for mobile app. In the boards with HDMI output, it also prepares the uncompressed video signal for that output.
There are multiple versions, always unencrypted.
| Marking | Packages | Timestamp | Overview |
|---|---|---|---|
| 02.12.0000 | P3X_FW_V01.01.0006 P3X_FW_V01.01.1003 | 2015-04-30 ... 2015-05-01 | |
| 02.13.0000 | P3S_FW_V01.01.0008 P3S_FW_V01.01.0009 P3S_FW_V01.02.0007 P3S_FW_V01.02.0008 P3X_FW_V01.01.0008 P3X_FW_V01.01.0009 P3X_FW_V01.01.1007 P3X_FW_V01.02.0006 | 2015-05-06 ... 2015-07-10 | |
| 02.18.0001 | C1_FW_V01.03.0020 P3S_FW_V01.03.0020 P3XS_FW_RC_V01.03.0020 P3X_FW_V01.03.0020 | 2015-07-24 ... 2015-08-04 | |
| 02.18.0002 | C1_FW_V01.02.0021 C1_FW_V01.03.00.21 C1_FW_V01.04.0030 | 2015-07-28 ... 2015-09-29 | |
| 02.24.0000 | C1_FW_V01.05.0070 C1_FW_v01.05.0071 | 2015-11-24 ... 2016-02-01 | |
| 02.26.0000 | C1_FW_V01.01.0020 C1_FW_V01.01.0092 C1_FW_V01.05.0080 C1_FW_V01.06.0000 C1_FW_v01.01.0030 C1_FW_v01.01.0035 C1_FW_v01.01.0040 C1_FW_v01.01.0050 C1_FW_v01.01.0051 C1_FW_v01.01.0053 C1_FW_v01.01.0054 C1_FW_v01.01.0055 C1_FW_v01.01.0060 C1_FW_v01.01.0080 C1_FW_v01.01.0090 C1_FW_v01.07.0002 C1_FW_v01.07.0030 C1_FW_v01.07.0040 | 2016-03-15 ... 2016-12-08 | |
| 02.29.0000 | C1_FW_v01.06.0001 C1_FW_v01.07.0000 C1_FW_v01.08.0000 | 2016-08-13 ... 2016-09-12 | |
| 02.31.0000 | C1_FW_v01.09.0000 | 2016-11-08 | |
| 02.32.0000 | C1_FW_V01.01.0093 C1_FW_v01.07.0060 | 2016-11-10 ... 2016-12-29 |
The module is encrypted using OpenSSL salted format. Password is "Dji123456". Here is an example decryption command:
openssl des3 -d -k Dji123456 -in C1_FW_V01.06.0000_m1300.bin -out C1_FW_V01.06.0000_m1300_decrypted.tar.gz
Unencrypted firmware is a TAR GZip archive containing some Linux tools compiled for ARM, 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/ubl1.img of=ubl1_prop.img bs=2048 skip=1
The files included in firmware update are written in appropriate places of the 128MB NAND flash memory. Map of the flash memory 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 |
| 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 |
This memory map corresponds to the u-boot environment configuration which can be set and then displayed with the following commands in u-boot console:
env set mtdids 'nand0=davinci_nand.0' env set mtdparts 'mtdparts=davinci_nand.0:4736k(bootloader)ro,4480k(kernel),4480k(kernel_recv),640k(secret),114m(filesystem)' mtdparts
The firmware consists of U-Boot boot loader and DaVinci Linux as OS.
Additional Kernel Modules and User Mode Applications are providing communication to Cypress USB Controller and video transcode functions.
Here are the known ways to flash the U-Boot bootloader and DaVinci Linux. Some of the flashing methods may not be listed here.
The official way of flashing the firmware is by selecting upgrade (or downgrade) in the mobile app. The app will download the firmware, extract modules from the package and distribute them to proper target components. In older versions of the firmware, it was also possible to update by inserting a flash drive containing new firmware to the USB port. In order to use this method, the DaVinci Linux system has to be functional. This means boot loader must work, at least one kernel image must work, UbiFS must be a valid root file system and encrypted partition must have valid data.
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.
Connect your 3.3V TTL converter to service pads. Don't worry about connecting RX and TX incorrectly, switching them will not damage anything, it just won't work. The pad names depend on the board you have:
- in GL300a board, the names are UART_RX, UART_TX and GND.
- in HDMI board, the names are 368_RX, 368_TX and GND.
If after tapping to the serial interface, you see no message, or booting does not get to loading kernel, then you should reflash u-boot images. When u-boot is good, it will display the message Loading from nand0, offset 0x??????.
To reflash u-boot, you should boot the chip into a mode which allows programming it via serial port.
To switch the boot mode, short the Boot Select service pad to 3.3V. Then, use TI utilities on connected PC to flash your new image:
sfh_DM36x -nandflash -v -p "COM21" ubl1.img u-boot.img
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.
This method is based on Serial Boot and Flash Loading Utility provided by Texas Instruments.
If at the serial interface you see kernel boot error, or Recovery Kernel is booted, or kernel stops booting - you should reflash the kernel image. For example, this is how booting Recovery Kernel looks like:
U-Boot Product Vesion : DJI-DEC-Uboot-1.0-rc0(2015-11-02) U-Boot 2010.12-rc2-svn3214-Dji (Nov 02 2015 - 19:39:56) 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 *** 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 ** Unknown image type Wrong Image Format for bootm command ERROR: can't get kernel image! . Loading from nand0, offset 0x900000 Image Name: Linux-2.6.32.17-davinci1 Created: 2015-02-12 3:09:59 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3665856 Bytes = 3.5 MiB Load Address: 80008000 Entry Point: 80008000 ## Booting kernel from Legacy Image at 80700000 ... Image Name: Linux-2.6.32.17-davinci1 Created: 2015-02-12 3:09:59 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3665856 Bytes = 3.5 MiB Load Address: 80008000 Entry Point: 80008000 Loading Kernel Image ... OK OK . Starting kernel ... . [ 0.000000] Kernel Product Vesion : DJI-GRC-Kernel-1.0-rc8(2014-11-21) [ 0.000000] Linux version 2.6.32.17-davinci1 (u@dji) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 PREEMPT Thu Feb 12 11:09:57 HKT 2015 [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Usually you will want to flash the primary kernel, uImage, which you can get from any firmware update. But if your Recovery Kernel is also damaged, you may also flash the special recovery image uImage_recovery. Get it here.
To reflash the kernel, you need to press the ESC key just when your board gets power, so that you end up in u-boot console. Next press Enter to get rid of any additional ESCs left in input buffer:
Press ESC to abort autoboot in 1 seconds Dji-Pro # Unknown command '' - try 'help' Dji-Pro #
Now, you need to load a new kernel image to DRAM, and from there, flash it to NAND memory.
Let's start by cleaning a portion of DRAM which we will use:
Dji-Pro # mw.b 0x80008000 0xFF 0x460000
Now we need to put our kernel image into that location. There are two ways:
The transfer over serial is very slow and cumbersome. It requires compatible terminal client. On Windows, you can use ExtraPuTTY. On Linux, Minicom can support it.
First, initiate the transfer on DaVinci side:
Dji-Pro # loady 0x80008000 115200 ## Ready for binary (ymodem) download to 0x80008000 at 115200 bps...
Then, use proper function in your terminal to select the target file. The transfer will last some time. After it finishes, you will see:
xyzModem - CRC mode, 1(SOH)/3971(STX)/0(CAN) packets, 4 retries ## Total Size = 0x003e09c0 = 4065728 Bytes Dji-Pro #
This is the method I'd suggest. It is fast and reliable. It was tested with 2GB sd-card formatted to FAT32 and inserted into USB Card Reader.
Copy the kernel image on your USB stick, and put it into USB slot of your board. Then, execute the following:
Dji-Pro # usb start Dji-Pro # usb storage
The second command isn't really needed, but it will show you your USB device, so that you know it is functioning. Now, start the loading process:
Dji-Pro # fatload usb 0 0x80008000 uImage
On success, you should see something like:
reading uImage . 4065728 bytes read Dji-Pro #
Be careful, you are now going to make changes to your NAND memory.
To write Primary Kernel, execute the following commands:
Dji-Pro # nand erase 0x04a0000 0x460000 Dji-Pro # nand write 0x80008000 0x04a0000 0x460000
In case you are writing Recovery Kernel, run the commands below instead:
Dji-Pro # nand erase 0x0900000 0x460000 Dji-Pro # nand write 0x80008000 0x0900000 0x460000
Do NOT write the same kernel image over the two locations! Having different kernels is beneficial.
If the encrypted partition gets damaged, Linux will stop booting - kernel module responsible for encryption will freeze. If this happens, you may want to reflash this partition. Get the image here.
Note: this partition is different for every board; do not reflash it unless you are having issues you know are related to it!
The procedure is almost the same as for flashing kernel, so it will not be explained in detail. Commands:
mw.b 0x80008000 0xFF 0xa0000 usb start usb storage fatload usb 0 0x80008000 dm365_secret.bin nand erase 0x0d60000 0xa0000 nand write 0x80008000 0x0d60000 0xa0000
The Ubi File System is able to correct its errors and mark would-be bad sectors in advance, so it is unusual for it to get corrupted. It is also the hardest component to recover. Do not flash the UbiFS unless error messages explicitly say it is damaged!
The UbiFS partitions cannot be just written by nand write as all the others, because it contains EC blocks supported by NAND hardware. Writing them this way would make them possible to read only once, after that EC block would be damaged.
While u-boot has UbiFS support, it is unfinished in the old version provided in firmwares. Do not use it - it will damage your UbiFS even further.
The only viable option is to flash the new UbiFS image from Linux. To run Linux independently of the UbiFS Root Filesystem, will need another root - Recovery Root Filesystem. It needs to be as small as possible, but still have all the tools required to work with UBI partitions. You can get it here.
You will also need a valid UbiFS Root Filesystem image, like this one.
Since we have no unused space on the disk to fit our partition, we will have to temporarily sacrifice our primary kernel. To overwrite the primary kernel with our Recovery Root Filesystem, insert USB stick with the partition image, boot to u-boot Console and execute:
mw.b 0x82000000 0xFF 0x400000 usb start usb storage fatload usb 0 0x82000000 dm365_recovery_rootfs.bin nand erase 0x04a0000 0x400000 nand write 0x82000000 0x04a0000 0x400000
Now we are able to boot our Recovery Kernel, pointing it to our Primary Kernel partition for Root Filesystem location.
To do that, boot to u-boot Console and execute:
env set bootargs 'console=ttyS0,115200n8 rw dm365_imp.oper_mode=0 video=davincifb:vid0=0,10K:vid1=0,10K:osd0=1920x1080X16,8100K mem=96MB davinci_enc_mngr.ch0_output=COMPOSITE loglevel=8 davinci_enc_mngr.ch0_mode=pal root=/dev/mtdblock1 rootfstype=cramfs ip=off lpj=1077248' nboot 80700000 0 900000 bootm 80700000
When the Linux is started, you can format the UbiFS partition with new image:
cd /tmp; mkdir sdcard mount /dev/sda sdcard ubiformat /dev/mtd2 --sub-page-size=512 --vid-hdr-offset=2048 -f sdcard/dm365_root_ubifs.ubi
To check whether the filesystem is functional, try:
ubiattach -m 2 --vid-hdr-offset=2048
If this resulted in details on file system blocks and no error information, UbiFS is restored! Now, booting from Recovery Kernel should work without using our Recovery Root Filesystem. Restart the board; since the Primary Kernel does not contain a valid Kernel, u-boot will boot Recovery kernel automatically.
If the Linux system boots properly, we can restore the Primary Kernel to finish the process. Follow the instructions above to do that.
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 DaVinci Linux kernel loads additional modules which provide communication to CY7C68013 module on the GL300 Main board. Video stream is transmitted from there.
The external USB connector is managed by the DM368 chip. It is normally used to connect mobile device, but if USB stick is connected, it also becomes available in Linux. Old firmwares allowed to update RC firmware via this interface; this function was later disabled, to keep consistency with GL300b and later, where such capability is not possible.
The serial interface can be used to access shell on the DaVinci Linux. It allows both input and output. Service pads which allow access to it are named as follows:
- in GL300a board, the names are UART_RX, UART_TX and GND.
- in HDMI board, the names are 368_RX, 368_TX and GND.
A typical boot sequence which can be seen on the 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.
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).