USB Disk on AR.Drone

[MAPGPS]

AR.Drone comes with a USB port, it is USB OTG and can force to work as USB Host.
Thus can attach a USB Disk for on-drone HD Video storage.

My initial work was done at this thread (3G Modem):
http://www.ardrone-flyers.com/forum/vie ... 0&start=14" onclick="window.open(this.href);return false;
But stuck there.

Thanks the author of this Blog:
http://embedded-software.blogspot.com/" onclick="window.open(this.href);return false;

From the Blog: The PHY has been disabled by "program.elf". In order to activate the USB as Host, GPIO_127 needs to be set to input level. This can be done either by ioctl or by the gpio command:
# gpio 127 -d i

Based on above info, I continued my work from the stuck point.
Modules need to be compiled and loaded:

Code: Select all

# lsmod
Module                  Size  Used by    Tainted: G
vfat                   10432  1
dwc_otg                71820  0
sd_mod                 23508  2
fat                    46364  1 vfat
nls_iso8859_1           4096  1
nls_cp437               5760  1
nls_utf8                1888  0
nls_base                7040  5 vfat,fat,nls_iso8859_1,nls_cp437,nls_utf8
p6_sdhci                3588  0

Access 2GB USB Disk, and copy a file from it into /data on AR.Drone:

Code: Select all

# fdisk -l
Disk /dev/sda: 2063 MB, 2063597568 bytes
16 heads, 32 sectors/track, 7872 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1        7872     2015216   b Win95 FAT32
# mount /dev/sda1 /mnt
# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi1:system              12268      6224      5380  54% /
tmp                      63036       348     62688   1% /tmp
dev                      63036         0     63036   0% /dev
ubi0:factory              4928        40      4600   1% /factory
ubi2:update              13532        28     12780   0% /update
ubi2:data                69152     53348     12236  81% /data
/dev/sda1              2011268   1873252    138016  93% /mnt
# cd /mnt
# ls -l
drwxr-xr-x    4 root     root         4096 Dec 21  2010 - BACKUP -
drwxr-xr-x    2 root     root         4096 Mar  9  2009 - HOMEWORK -
drwxr-xr-x    2 root     root         4096 Jun  4  2009 - MUSIC -
drwxr-xr-x    2 root     root         4096 Mar 14  2008 - VIDEO -
-rwxr-xr-x    1 root     root        49288 Dec 14  2010 NORBOTE_V2.jpg
-rwxr-xr-x    1 root     root      2568594 May 29  2010 packets.pcap
-rwxr-xr-x    1 root     root      1993186 Jun  6  2010 packets2.pcap
drwxr-xr-x    3 root     root         4096 Sep 29  2010 recycler
-rwxr-xr-x    1 root     root        40484 Sep 18  2010 theV.jpg
# cp packets.pcap /data
# ls -l /data/p*
-rwxr-xr-x    1 root     root      2568594 Jan  1 00:20 /data/packets.pcap

[CdRsKuLL]

awesome work fella.. take my hat off to you! I'm sure if could to a lot more than save video once enabled as a usb host. Would it be possible to connect this upto an arduino and have it read info off the drone ?

Thanks

[MAPGPS]

awesome work fella.. take my hat off to you! I'm sure if could to a lot more than save video once enabled as a usb host. Would it be possible to connect this upto an arduino and have it read info off the drone ?

Thanks

Yes, with USB Host on AR.drone, we can attach any USB devices onto AR.Drone, as long as there is Linux driver source code for a device.

For arduino, it can connect to AR.drone via the serial port. Need to write apps:
- On arduino, an app to read/write data with the serial port
- On AR.Drone, an app to read/write data with the serial port /dev/ttyPA0

[CdRsKuLL]

Would you happen to have the pin out of the port? Thinking about buying a yellow jacket to convert it over to RC.. would be handy powering it directly off this port.

Many thanks,

[MAPGPS]

Would you happen to have the pin out of the port? Thinking about buying a yellow jacket to convert it over to RC.. would be handy powering it directly off this port.

Many thanks,

Pin 1: VBUS +5V (enabled after module dwc_otg.ko loaded)

Refer to:
http://www.ardrone-flyers.com/forum/vie ... =11&p=2595" onclick="window.open(this.href);return false;

[CdRsKuLL]

Many thanks for the quick reply. Will go and have a read .

Just wondering if it's possible to boot from the usb drive ? Might be interesting.. maybe parrot uses this port to program the drone..

Steve

[MAPGPS]

To boot AR.Drone from the usb drive, we need to look into the bootloader of it.
It's possible. But not know how at this moment.

So there are three ways to flash the firmware of AR.Drone:
1) WiFi to FTP a firmware file under /update
2) USB cable
3) USB drive

(2) and (3) could be the backup flash methods for (1), in case of WiFi failure.

[scorpion2k]

To boot AR.Drone from the usb drive, we need to look into the bootloader of it.
It's possible. But not know how at this moment.

So there are three ways to flash the firmware of AR.Drone:
1) WiFi to FTP a firmware file under /update
2) USB cable
3) USB drive

(2) and (3) could be the backup flash methods for (1), in case of WiFi failure.

Nice work for getting USB disks to work!

Regarding your post:

2) Is definitely possible. I already managed to extract the newest installer.plf from the 1.3.3 firmware and install this firmware via USB. To flash a custom kernel, you would just need to modify the kernel section of an ardrone_update.plf file. Using this method, you could also modify the stage1 bootloader.

Best regards

[MAPGPS]

Nice work for getting USB disks to work!

Regarding your post:

2) Is definitely possible. I already managed to extract the newest installer.plf from the 1.3.3 firmware and install this firmware via USB. To flash a custom kernel, you would just need to modify the kernel section of an ardrone_update.plf file. Using this method, you could also modify the stage1 bootloader.

Best regards

scorpion2k,
Thank you for your great finding of GPIO_127 on your Blog:
http://embedded-software.blogspot.com/" onclick="window.open(this.href);return false;

I have been trying to enable USB Host on my AR.Drone, but stuck at “HANG!” when “insmod dwc_otg.ko”.
Your finding of GPIO_127 is the key to this.

One update to dwc_otg_driver.c:
I have to change “.overcurrent_pin = 89” to “.overcurrent_pin = 0”,
Otherwise AR.Drone will get “Oops”.

For USB cable based flashing, there is Flash.ini file:

Code: Select all

[FLASHER SETTINGS]
USB bootloader file path = BINARY\ardrone_usb_bootloader.bin
Installer file path      = BINARY\ardrone_installer.plf
Payload file path        = BINARY\ardrone_beta3.1_hw08.plf

Per your info, we just need to replace file ardrone_installer.plf with your extracted installer.plf from the 1.3.3 firmware, and replace ardrone_beta3.1_hw08.plf with the latest ardrone_update.plf.

Could you share your extracted installer.plf from the 1.3.3 firmware?

[scorpion2k]

One update to dwc_otg_driver.c:
I have to change “.overcurrent_pin = 89” to “.overcurrent_pin = 0”,
Otherwise AR.Drone will get “Oops”.

Big thanks for this. But better use -1 instead of 0, so the pin is ignored (see dwc_otg_hcd.c, line 253 + 315).

Per your info, we just need to replace file ardrone_installer.plf with your extracted installer.plf from the 1.3.3 firmware, and replace ardrone_beta3.1_hw08.plf with the latest ardrone_update.plf.

Could you share your extracted installer.plf from the 1.3.3 firmware?

There is a problem with ardrone_flasher.exe which does not wait long enough after loading the installer. This results in transmission failures..
I wrote an own USB Flash tool (the protocol is quite simple). But basically you can use the latest ardrone_update.plf (or even a custom kernel) with this method.

I think, it will violate Parrot's copyright if I share the extracted installer.plf. Thus I will release the tools to extract and install firmwares over USB within the next few days. Still have to do some clean-ups.

Best regards.

[scorpion2k]

I finally finished the tools. I uploaded them here (the source is also available):

http://code.google.com/p/ardrone-tool/downloads/list" onclick="window.open(this.href);return false;

You need:
- plf_inst_extract-0.1.0-win32-fixed.zip
- usb_flash-0.1.0-win32.zip

WARNING: Only do this if you really know what you do.

Just extract them somewhere. Then call:

Code: Select all

> plf_inst_extract.exe -i ardrone_update.plf -o ardrone_installer.plf

If everything was ok, you should see

Code: Select all

...
*** SUCCESS --> Installer extracted!!! ***
==> DONE <==

Then copy ardrone_installer.plf, ardrone_update.plf and ardrone_usb_bootloader.bin (from the old flash tool) to the directory where usb_flash.exe resides in.

Connect your drone to USB, the battery to the drone and install the drivers from usb_flash. Afterwards just call usb_flash.exe .

You should see something like:

Code: Select all

...
Error Code returned: 0x00000000  ==> OK
 *** INSTALLATION DONE ***

Best regards

[MAPGPS]

I finally finished the tools. I uploaded them here (the source is also available):
http://code.google.com/p/ardrone-tool/downloads/list" onclick="window.open(this.href);return false;

scorpion2k, great work!
I tried to use it to extract ardrone_installer.plf from firmware 1.4.6.
It is OK.

I would like to flash my AR.Drone with my customized kernel image (built file: arch/arm/boot/zImage, size 1.6MB, with USB Disk/USB 3G Modem support), where should I put this image file? Is it part of ardrone_update.plf(or ardrone_installer.plf)? Or need a special tool to flash it into a special partition on AR.Drone?

I also tried to compile your tools under Linux:
libplf and plf_inst_extract are OK to compile with minor changes to Makefile and remove "O_BINARY" in plf.c.
But failed to compile usb_flash due to missing header file "usb.h" --- Could you add it?

Looking into usb_flash.c, it helped me a lot to understand the protocol of USB flash.

One question:
Is it possible to skip the bootloader flash step?
I think keeping the AR.Drone bootloader untouched is a safe way for flash --- a failed bootloader flash may cause AR.Drone as a brick.

[scorpion2k]

I would like to flash my AR.Drone with my customized kernel image (built file: arch/arm/boot/zImage, size 1.6MB, with USB Disk/USB 3G Modem support), where should I put this image file? Is it part of ardrone_update.plf(or ardrone_installer.plf)? Or need a special tool to flash it into a special partition on AR.Drone?

Indeed, the kernel image resides (as executable PLF) in ardrone_update.plf (with sectionType==0x03). I am currently writing a tool to modify plf files.

libplf and plf_inst_extract are OK to compile with minor changes to Makefile and remove "O_BINARY" in plf.c. But failed to compile usb_flash due to missing header file "usb.h" --- Could you add it?

Thanks for this. I need to add some preprocessor switches. The file "usb.h" belongs to libusb (http://libusb.org" onclick="window.open(this.href);return false;) . But thanks, the include statement is not correct here (should be <usb.h> instead of "usb.h").

One question:
Is it possible to skip the bootloader flash step?
I think keeping the AR.Drone bootloader untouched is a safe way for flash --- a failed bootloader flash may cause AR.Drone as a brick.

Let me explain how the boot sequence works:

1. After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates the A* pins and selects the corresponding boot mode (boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral:
a. Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
b. Boot over USB: The pre-bootloader listens to USB and waits for the "0xA3 <len>" command. If received, it replies with 0xA8 and awaits <len> bytes of data (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.

2. Depending on the started bootloader, either the UBI partitions are mounted and the kernel image is read or the bootloader waits until the kernel image is sent over USB (the installer). Common for both: the DDR controller is started.

3. If the installer is booted over USB, the "init" command awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.

Conclusion:
1. The internal ROM (pre-bootloader) is never modified. So it is always possible to install a firmware over USB.
2. ardrone_usb_bootloader.bin is executed only from internal RAM. It is not stored anywhere.
3. ardrone_update.plf contains a bootloader that is stored on NAND, the actual linux kernel (stored in main_boot) and the installer (stored in alt_boot).

--> It is is not be possible to brick the device as internal ROM is never modified.

And as nice feature:
As ardrone_usb_bootloader.bin is executed directly from RAM - even without being checked - you can run every code you want by sending your code after the 0xA3 command

Best regards

[MAPGPS]

scorpion2k, thanks a lot for the detail explanation on how AR.Drone booted/flashed.
"The internal ROM (pre-bootloader) is never modified" is the key to resolve my question.

Looking forward to your PLF Modification Tool.

[CTaddey]

Hi MAPGPS and scorpion2k.
I see you have good experience with firmware upgrades, maybe you can help me with something.
I have a Drone which has some problems, so I used scorpion2k's plf/flash tools to send latest firmware to Done. Since this didn't fixed the problem, I used Parrot's tool (AR_DRONE_FLASHER_v1_00_08_Installer) to send this package's firmware to see if it helped.
With this firmware, the drone SSID changed from ardrone_xxxxx(serial) to ardrone_network. Since I still had problems, I decided to try fw 1.3.3 (drone was good at this version), so again I prep'ed and sent files with usb_flash tool.
For my surprise, drone SSID did not go back to ardrone_xxxxx. I believed that the flashing process overwrites all files when upgrading, but it is not doing so?
Maybe you know which files are left untouched?(Config files unique to each drone)
I think the problem was caused by someone touching the configuration files. Is there a way to replace these by ones coming from a working drone (using usb)?

If you would like to know, the problem is: when starting, the drone goes to all green leds, but after a few seconds motor leds turn red and does not reply to ping anymore (system led stays green). During green leds time I can connect and watch the camera for a few seconds. So I think I could work on a script for sending files using ftp in those few seconds.
Some other times, the system led does not come on at all when connecting the battery (only red motors)...could this indicate motherboard damage? or still may be due bad config files?
Your comments would be greatly appreciated!!