tag:blogger.com,1999:blog-65257093822645698742023-12-27T10:48:20.987+01:00E/S and IMy projects with embedded software.eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-6525709382264569874.post-10746980580726401052011-02-10T00:35:00.000+01:002011-02-10T00:35:35.257+01:00New kernel source availableNice. Seems like parrot uploaded a newer version of A.R.Drone's kernel source code.<br />
<br />
See here:<br />
<br />
https://projects.ardrone.org/documents/show/19<br />
<br />
At least the p6_sdhci driver is correct now :-)eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.com5tag:blogger.com,1999:blog-6525709382264569874.post-81189426046392545812011-01-25T20:33:00.001+01:002011-01-25T20:35:19.880+01:00Reading navigation data directly from NavboardOn A.R. Drones navigation board, the following sensors exist:<br />
<br />
<ul><li>IDG-500 (Dual-axis gyroscope)</li>
<li>XV-3500CB (Z-axis gyroscope)</li>
<li>BMA150 (3-axis accelerometer)</li>
<li>Some ultrasonic stuff</li>
</ul><br />
For handling these sensors, a PIC24 is used. This device does the A/D conversion of the gyroscope data and the I2C communication with the BMA150. <br />
Periodically, the sensor data is sent over UART to the mainboard where it is used by program.elf to control the Drone.<br />
<br />
So... how to get this data without using program.elf?<br />
<br />
First, start the sensor acquisition by calling:<br />
<br />
<pre>echo -e -n "\1" > /dev/ttyPA2
</pre><br />
Now, periodically, the nav boards sends a 0x2E sized frame to UART2.. so read it with:<br />
<br />
<pre>dd if=/dev/ttyPA2 count=1 bs=46 | hexdump -C
</pre><br />
The data seems to have the following format:<br />
<br />
<pre>struct nav_data_tag
{
u16 size; /* +0x00 Size of the following data (0x2C) */
u16 sequence; /* +0x02 Sequence number */
u16 raw_accs[3]; /* +0x04 Raw data of the accelerometers*/
u16 raw_gyros[3]; /* +0x0A Raw data for the gyros */
u16 raw_gyros_110[2]; /* +0x10 4.5x Raw data (IDG) */
u16 uk_0x14; /* +0x14 Unkown. Maybe accs temperature */
u16 gyro_temp; /* +0x16 Gyro temperature (IDG) */
u16 vrefEpson; /* +0x18 Gyro v_ref (Epson) */
u16 vrefIDG; /* +0x1A Gyro v_ref (IDG) */
u16 uk_0x1C; /* Unkown */
u16 checksum; /* +0x1E Checksum */
u16 us_debut_echo; /* +0x20 Ultrasonic parameter */
u16 us_fin_echo; /* +0x22 Ultrasonic parameter */
u16 us_association_echo; /* +0x24 Ultrasonic parameter */
u16 us_distance_echo; /* +0x26 Ultrasonic parameter */
u16 us_courbe_temps; /* +0x28 Ultrasonic parameter */
u16 us_courbe_valeur; /* +0x2A Ultrasonic parameter */
u16 us_courbe_ref; /* +0x2C Ultrasonic parameter */
}
</pre><br />
I haven't figured out much yet, but here are my first analysis results:<br />
<br />
<ul><li><b>size:</b> always 0x2C </li>
<li><b>sequence:</b> increases every update </li>
<li><b>raw_accs:</b> seems to contain the BMA values left-shifted by 2</li>
<li><b>raw_gyros:</b> 12-bit A/D converted voltage of the gyros </li>
<li><b>raw_gyros_110:</b> gyro values wieth another resolution (see IDG-500 datasheet)</li>
<li><b>gyro_temp:</b> 12-bit A/D converted voltage of IDG's temperature sensor</li>
<li><b>vrefEpson:</b> 12-bit A/D converted reference voltage of the Epson sensor</li>
<li><b>vrefIDG:</b> as vrefEpson, but for IDG sensor</li>
<li><b>checksum:</b> checksum (have to figure out how to calculate.. </li>
<li><b>all others</b> haven't yet figured out what they mean<br />
</ul>eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.com11tag:blogger.com,1999:blog-6525709382264569874.post-32762585048420875532011-01-19T02:23:00.002+01:002011-01-19T10:31:41.504+01:00Creating, testing (and flashing -- TBD) a custom kernelIn my last post, I announced that creating and uploading a custom kernel works. Now I will explain how this can be done.<br />
<br />
<i>Thanks to MAPGPS from http://www.ardrone-flyers.com for testing my tools.</i><br />
<br />
You need:<br />
<br />
- Linux! I used Ubuntu 10.10<br />
- ARDrone linux kernel source (get it from [1])<br />
- ARDrone linux kernel config (get it from [2])<br />
- The Sourcery G++ toolchain (get it from [3] or [4] )<br />
- My plftool, usb_flash tool (see below)<br />
- The old parrot flash tool (for ardrone_usb_bootloader.bin)<br />
- libusb-0.1 (linux) or libusb-win32 (windows) <br />
- zlib<br />
<br />
<br />
<h2>Getting & Compiling plftool + usb_flash tool</h2><br />
These tools are not yet released. Thus I will not provide binaries for windows, instead you have to compile them by yourself. For windows, you need to use mingw32.<br />
<br />
<b>Getting the sources</b><br />
<br />
The sources are stored at my <a href="http://code.google.com/p/ardrone-tool/source/checkout">google code project</a>. In order to get them, you need to install a svn client. For linux you then call something like this:<br />
<br />
<pre>svn checkout http://ardrone-tool.googlecode.com/svn/projects/libplf/trunk libplf
svn checkout http://ardrone-tool.googlecode.com/svn/projects/usb_flash/trunk usb_flash
svn checkout http://ardrone-tool.googlecode.com/svn/projects/plftool/trunk plftool
</pre><br />
<b>Compiling</b><br />
<br />
Now that you got the sources, you need to compile them. First start with libplf as this is needed by all projects. The library contains the code to read and write .plf files.<br />
<br />
<pre>cd libplf
make
cd ..
</pre><br />
When compiling with mingw32 call "make -f Makefile.w32" instead.<br />
<br />
If libplf was compiled succesfully you should get either a libplf.so or libplf.dll file.<br />
Next compile plftool and usb_flash:<br />
<br />
<pre>cd plftool
make
cd ..
cd usb_flash
make
cd ..
</pre><br />
When compiling with mingw32, call "make -f Makefile.w32" instead.<br />
<br />
This should create plftool(.exe) and usb_flash(.exe).<br />
<br />
For Linux, if you do not want to install the libplf.so file, you need to call plftool and usb_flash with LD_LIBRARY_PATH=<path_to_the_folder_where_libplf.so_is_located> prefix.<br />
<br />
E.g.<br />
<pre>LD_LIBRARY_PATH=/home/scorp2kk/projects/ardrone/tools/libplf plftool
</pre><br />
<br />
For Windows, you need to add the folder where libplf.dll is located to your PATH variable before calling usb_flash or plftool. <br />
<br />
<h2>Patching the kernel</h2><br />
As Parrot's published source code does not match the kernel delivered with firmware > 1.3.3, a patch is required to ensure correct behaviour. This patch mainly affects p6_sdhci.c. <br />
<br />
You can get the patch from <a href="http://ardrone-tool.googlecode.com/svn/wiki/attachments/p6_sdhci-patch1.patch">here</a>. To apply it, just call:<br />
<br />
<pre>cd linux-2.6.27
patch -p1 < p6_sdhci-patch1.patch
</pre><br />
<br />
<h2>Compiling the kernel</h2>Now as the kernel is patched, you should use Parrot's original config [2] and cross-compile the sources with Sourcery G++. Basically you need to do something like this (don't forget to add the Sourcery' bin directory to your PATH):<br />
<br />
<pre>cp ARDrone_Version_20100809_1_2-busybox.config .config
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage </pre><br />
After a few minutes (or hours) make informs you that the zImage file is available:<br />
<br />
<pre>Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
</pre><br />
<h2>Creating a kernel.plf file</h2>If you got your zImage, it is time to build a kernel.plf file from it. This is done by plftool. plftool expects a build-ini file that describes the plf file. A sample ini file can be found at plftool/samples/kernel. Using the sample kernel.ini, you only have to modify the "File=" parameters in section "[zImage]" and "[BootParams]" so they point to the zImage file and to a text file, the boot parameters are located in (e.g. called bootparams.txt).<br />
<br />
To create the kernel.plf from the kernel.ini, just call:<br />
<br />
<pre>plftool -b kernel.ini -o kernel.plf </pre><br />
The tool should output something similar to this and create the kernel.plf file.<br />
<br />
<pre>Creating kernel.plf based on this config:
File [HdrVersion: 11 EntryPoint: 0x40800000; Version: 0.0.0
TargetPlat=4, TargetAppl=78, HwCompat=0, LangZone=0]
zImage @ 0x40800000 (zImage)
initrd @ ---------- (no initrd)
bootparams @ 0x40700000 (bootparams.txt)
*** kernel.plf created ***
</pre><h2>Testing the kernel.plf file</h2>If kernel.plf file was created, it is time to test this file. First inspect it with plftool: <br />
<br />
<pre>plftool -d -i kernel.plf
</pre>Have a look at dwFileType, dwEntryPoint and Section->LoadAddr.<br />
<br />
If it looks okay, it is time to start (not flash!) the kernel:<br />
<ol><li>Copy ardrone_usb_bootloader.bin to the folder of usb_flash</li>
<li>Connect the drone to your PC via USB (the LED should be RED)</li>
<li>Connect the BATTERY to your drone (the LED becomes GREEN) </li>
<li>Check if the device was found (with lsusb)</li>
<li>Start usb_flash in TEST mode:</li>
</ol><pre>usb_flash -t kernel.plf
</pre><br />
This will load (NOT flash) the kernel over USB. In general, it is helpful to observe A.R. Drone's serial port, as the whole boot sequence is shown there. usb_flash outputs on success:<br />
<br />
<br />
<pre>...
Mode: <b>kernel test</b>
*** VERIFICATION ***
Verifying ardrone_usb_bootloader.bin
Verifying test_kernel.plf
*** DOWNLOADING USB BOOTLOADER ***
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
Found a possible device:
- Manufacturer: Parrot SA
- Product: P6 USB Stage1
- Serialnumber: ?
- Number of configurations: 1
Sending bootloader (0x5b20 bytes)
- Send Hello P6 (0xA3)
Success!!!
Checksum returned: 0x5256 Expected: 0x5256 => OK
Starting the bootloader...
*** INSTALLER DOWNLOAD ***
Closing usb connection...
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
Found a possible device:
- Manufacturer: Parrot SA
- Product: P6 USB Stage1
- Serialnumber: ?
- Number of configurations: 1
loading installer
Uploading file: test_kernel.plf
Error Code returned: 0x00000000 ==> OK
<b>*** INSTALLATION DONE ***</b>
</pre><br />
If everything works, the kernel boots up, WiFi ist started and you should be able to connect to the drone with telnet.<br />
<br />
Check the kernel version with<br />
<br />
<pre>uname -a</pre><br />
If the default kernel starts without problems, you can now begin to modify the kernel config.<br />
<br />
Flashing the kernel to NAND works but I still need to modify the plftool.. so stay tuned.<br />
<br />
<br />
Happy hacking :-)<br />
<br />
<br />
[1] https://projects.ardrone.org/documents/show/19<br />
[2] https://projects.ardrone.org/documents/show/18<br />
[3] https://projects.ardrone.org/documents/show/20<br />
[4] http://www.codesourcery.com/sgpp/lite/arm/portal/release858eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.com10tag:blogger.com,1999:blog-6525709382264569874.post-49718367987289843242011-01-11T23:53:00.000+01:002011-01-11T23:53:28.017+01:00Creating + Flashing Custom KernelYeah...<br />
<br />
Creating a kernel.plf file from zImage+initrd --> WORKS!<br />
Booting this kernel.plf file over USB --> WORKS!<br />
Flashing this kernel.plf to NAND --> to be done...<br />
<br />
More will follow soon :-)eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.com1tag:blogger.com,1999:blog-6525709382264569874.post-35702667955756311822011-01-09T02:17:00.001+01:002011-01-09T02:19:20.516+01:00Tools for A.R. DroneI finally released some tools for A.R. Drone: <br />
<ol><li>libplf - A library to read / write plf files</li>
<li>plf_inst_extract - A tool to extract and patch a ardrone_installer.plf from a given ardrone_update.plf</li>
<li>usb_flash - A tool to flash a ardrone_update.plf over USB. This tool requires:</li>
<ol><li>ardrone_update.plf - the firmware to flash </li>
<li>ardrone_installer.plf - can be obtained from ardrone_update.plf with plf_inst_extract</li>
<li>ardrone_usb_bootloader.bin - was delivered with the old flash tool. I will probably write an open-source boot loader sooner or later.</li>
</ol></ol>Have a look at my goolge code project:<br />
<br />
<a href="http://code.google.com/p/ardrone-tool">http://code.google.com/p/ardrone-tool</a>eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.com1tag:blogger.com,1999:blog-6525709382264569874.post-1113935227097495362011-01-09T01:46:00.000+01:002011-01-09T01:46:59.804+01:00A.R. Drone's boot sequenceIn order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:<br />
<ol><li>After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. 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.<br />
<ul><li>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.</li>
<li> Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (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.</li>
</ul><br />
</li>
<li>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. </li>
<li>If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND. </li>
</ol>eshttp://www.blogger.com/profile/13835644932978813824noreply@blogger.com3tag:blogger.com,1999:blog-6525709382264569874.post-29836757622087576792010-12-31T01:00:00.002+01:002011-01-06T17:33:07.236+01:00A.R. Drone USB (Updated)<b>A word of warning: You should not do anything like the following if you do not know what you do. You may ruin your drone.</b><br />
<br />
As A.R. Drone has an <a href="http://en.wikipedia.org/wiki/USB_On-The-Go">USB OTG Port</a>, it should be possible to use this port for extending the functionality of A.R. Drone.<br />
<br />
But sadly Parrot disabled this port and only allows to use it for flashing purpose. Luckily they provide the source code for the driver [1].<br />
<br />
So... let's have a closer look to this USB port..<br />
<br />
First, Parrot defined the port as device only.<br />
<br />
<pre>arch/arm/parrot6/mykonos.c, line 109:
static dwc_otg_info_t usb0_info = {
.ctrl_mode = 2,
.sof_filter = 7,
.reset_pin = -1,
.vbus_detection = 0,
.fiq_enable = 0,
};
</pre><br />
According to dwc_otg driver:<br />
<pre>drivers/parrot/usb/dwc_otg/dwc_otg_cil.h
/**
* Controller mode
* 0 - OTG
* 1 - host only
* 2 - device only
*/
int32_t ctrl_mode;
#define DWC_OTG_HOST_DEVICE 0
#define DWC_OTG_HOST_ONLY 1
#define DWC_OTG_DEVICE_ONLY 2
</pre><br />
In order to enable the USB host mode, it is required to overwrite/ignore the usb0_info defined in mykonos.c.<br />
<br />
This can be achieved by patching dwc_otg_driver.c where the platform data is copied to the local parameter data. This is done by function "dwc_otg_set_specific_param". Also, by default (if not overwritten by platform data) the local parameters are configured as DWC_OTG_HOST_DEVICE. So simply not copying this parameter would prevent the driver from going to DEVICE_ONLY mode.<br />
<br />
Thus the driver is modified and the assignment "params->ctrl_mode = info->ctrl_mode" is removed:<br />
<pre>drivers/parrot/usb/dwc_otg/dwc_otg_driver.c, line 224:
/**
* This function is called to set specific configuration parameters
*/
static void
dwc_otg_set_specific_param
(
dwc_otg_info_t *info,
dwc_otg_core_params_t *params,
int port
)
{
params->sof_filter = info->sof_filter;
params->reset_pin = info->reset_pin;
params->speed = info->speed;
if (port == 0) {
//params->ctrl_mode = info->ctrl_mode;
//params->vbus_detection = info->vbus_detection;
}
if (port == 1 && !usb1_disable_fiq) {
params->fiq_enable = info->fiq_enable;
}
}
</pre><br />
<b>[Update] </b><br />
As noted by MAPGPS [3], there is still an issue with the driver causing Oops. To fix this issue, it is necessary to change the overcurrent_pin from 89 to -1:<br />
<br />
<pre>drivers/parrot/usb/dwc_otg/dwc_otg_driver.c, line 135:
.overcurrent_pin = -1, /* default */
</pre><b>[/Update]</b> <br />
<br />
<br />
<br />
After compiling, ftp-ing the module to the drone and calling<br />
<br />
<pre># insmod dwc_otg.ko
</pre><br />
Oh no! dmesg shows that something gone wrong.. also VBus is still +0 V :-(<br />
<br />
<pre>[ 39.862534] dwc_otg: version 2.70a-parrot 22/03/2009
[ 39.862703] dwc_otg dwc_otg.0: dwc_otg_driver_probe(c034d578)
[ 39.862736] dwc_otg dwc_otg.0: start=0xc0400000
[ 39.862851] dwc_otg dwc_otg.0: base=0xc8e00000
[ 39.862883] dwc_otg dwc_otg.0: specific configuration
[ 39.862914] dwc_otg dwc_otg.0: dwc_otg_device=0xc7a0b6e0
[ 39.873574] DWC_otg: dwc_otg_core_reset() HANG! Soft Reset
GRSTCTL=80000001
[ 39.980233] DWC_otg: dwc_otg_core_reset() HANG! Soft Reset
GRSTCTL=80000001
</pre><br />
Looking at the drivers code, it seems like this HANG! message indicates a communication problem with the PHY. Checking the voltage levels of the PHY, it seems like almost all pins are tri-stated.<br />
<br />
Having a look at the PCB, a SMSC USB3317 can be identified. According to its datasheet there is a pin named RESETB. When this pin is set to low the PHY is suspended and all I/O are tri-stated. <br />
<br />
By monitoring RESETB it can be observed that RESETB is toggled by program.elf. So dumping all GPIO registers before and after starting program.elf the pin can be found.<br />
<br />
And voilá: GPIO_127 is used to enable/disable the PHY. Program.elf sets it to output a high level which then switches a transistor and pulls RESETB to low. <br />
<br />
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:<br />
<br />
<pre># gpio 127 -d i
</pre><br />
After re-inserting dwc_otg.ko, dmesg no longer shows the HANG! message and VBUS has +5V :-)<br />
<br />
Let's try to connect an USB device. The pinout for the USB connector is described in [2]. I use an old USB thumb drive (128MB) for testing. <br />
<br />
dmesg shows:<br />
<br />
<pre>[ 1675.054378] usb-storage: USB Mass Storage device detected
[ 1675.054650] usb-storage: -- associate_dev
[ 1675.054680] usb-storage: Vendor: 0x0ea0, Product: 0x2168,
Revision: 0x0200
[ 1675.054707] usb-storage: Interface Subclass: 0x06, Protocol:
0x50
[ 1675.054741] usb-storage: Transport: Bulk
[ 1675.054761] usb-storage: Protocol: Transparent SCSI
[ 1675.055439] scsi1 : SCSI emulation for USB Mass Storage devices
[...]
[ 1680.071311] scsi 1:0:0:0: Direct-Access 128MB
2.00 PQ: 0 ANSI: 2
</pre><br />
Seems to work :-)<br />
<br />
<br />
[1] https://projects.ardrone.org/documents/show/19<br />
[2] https://projects.ardrone.org/attachments/167/ARDrone-USB-Cable.png<br />
[3] http://www.ardrone-flyers.com/forum/viewtopic.php?p=5823#p5823Unknownnoreply@blogger.com14tag:blogger.com,1999:blog-6525709382264569874.post-6870690418802898992010-12-29T12:49:00.003+01:002010-12-30T14:52:33.063+01:00PLF File FormatA few weeks ago i bought an A.R. Drone from Parrot. This quadcopter is controlled over WLAN and uses an embedded Linux on an ARM chipset.<br />
<br />
Altough it is possible via FTP / Telnet to modify the file system, i was intreseted in the flash file format. So I analyzed the available firmware.<br />
<br />
I was quite successful athough there are still some unkown fields left.<br />
<br />
Fileheader:<br />
<pre>typedef struct sPLFFile
{
u32 dwMagic;
u32 dwHdrVersion;
u32 dwHeaderSize;
u32 dwEntryHeaderSize;
u32 uk_0x10;
u32 uk_0x14;
u32 uk_0x18;
u32 uk_0x1C;
u32 uk_0x20;
u32 dwVersionMajor;
u32 dwVersionMinor;
u32 dwVersionBugfix;
u32 uk_0x30;
u32 dwFileSize;
}
</pre><br />
The fields have the following meaning:<br />
<br />
<ul><li>dwMagic: MagicCode of the file. Must be 0x21464C50</li>
<li>dwHdrVersion: Version of the header struct. Only seen with 0xB or 0xA</li>
<li>dwHeaderSize: Size of the file header. Must be 0x38.</li>
<li>dwEntryHeaderSize: Size of the section header. Must be 0x14.</li>
<li>uk_0x10: Currently unkown. Maybe some Type. Seen with 0x2</li>
<li>uk_0x14: Currently unkown. Maybe an EntryPoint. Seen with 0x0</li>
<li>uk_0x18: Currently unkown. Maybe the Device Type. Seen with 0x4</li>
<li>uk_0x1C: Currently unkown. Maybe the Model Number. Seen with 0x4E</li>
<li>uk_0x20: Currenlty unkown. Seen with 0x20</li>
<li>dwVersionMajor: Major version of this firmware</li>
<li>dwVersionMinor: Minor version of this firmware</li>
<li>dwVersionBugfix: Bugfix version of this firmware</li>
<li>uk_0x30: Curently unkown</li>
<li>dwFileSize: Size of the file.</li>
</ul><br />
<br />
<br />
After the header the sections follow. Each section starts with the following header. <br />
<pre>typedef struct sPLFEntryTag
{
u32 dwSectionType;
u32 dwEntrySize;
u32 dwCRC32;
u32 uk_0x0C;
u32 dwUncompressedSize;
}
</pre><br />
The fields have the following meaning:<br />
<ul><li>dwSectionType: Type of the section. <br />
<br />
0x00: unkown<br />
0x03: probably the bootloader<br />
0x07: unkown<br />
0x09: Filesystem action/content<br />
0x0b: Configuration Data (Mounting, creation of partitions)<br />
0x0c: Installer (contains another PLF file)<br />
</li>
<li>dwEntrySize: Size of the section (excluding header size)</li>
<li>dwCRC32: CRC-32 of the content and EntrySize</li>
<li>uk_0x0C: Currently unkown. Seems to be the address where to load the section to</li>
<li>dwUncompressedSize: If > 0, the content of this entry is compressed with gzip format. The value represents the uncompressed size of the entry.</li>
</ul>The meaning of each section depends on dwSectionType.<br />
<br />
<b>0x09 - File system content</b><br />
Each section represents one entry on the file system. It first starts with the null-terminated filename (variable length). After this name, the following header is placed:<br />
<br />
<pre>typedef struct sFileEntryTag
{
u32 dwFlags;
u32 uk_0x04;
u32 uk_0x08;
} sFileEntry;
</pre><br />
<ul><li>dwFlags: Flags of the file entry. Encodes the type of the entry and the access rights. <br />
<br />
bit00-11: Rights of the file. Its the same as you would use for chmod. E.g. 0755 -> 0x1ED<br />
bit12-15: Type of the file entry:</li>
<ul><li>0x04: mkdir. No more data follows after the header.</li>
<li>0x08: write. The file content follows after the header.</li>
<li>0x0A: symlink. The target of the link follows after the header.<br />
</li>
</ul><li>uk_0x04: Currently unkown. Seems to be either the UID or GID.</li>
<li>uk_0x08: Currently unkown. Seems to be either the UID or GID.</li>
</ul><b>0x0b - Configuration data</b><br />
This section contains informations about mounting, truncating and creating partitions. There is an old and a new version.<br />
<br />
Old version (starts with "/mnt"):<br />
32 bytes unkown. Then a u32 with some unkown_count follows. Then unkown_count*8 bytes follows. Then a u32 with the number of entries follows. Afterwards, the entries follow.<br />
<br />
New version (does not start with "/mnt"):<br />
<pre>typedef struct sPartitionSectionTag
{
u32 dwTblVersion;
u32 dwVersionMajor;
u32 dwVersionMinor;
u32 dwVersionBugfix;
u32 uk_0x10;
u32 uk_0x14;
u32 uk_0x18;
u32 uk_0x1C;
u32 uk_0x20;
u32 dwNumEntries;
} sPartitionSection;
</pre><br />
<ul><li>dwTblVersion: Seems to be the version of this "partition table". </li>
<li>dwVersionMajor: Major version</li>
<li>dwVersionMinor: Minor version</li>
<li>dwVersionBugfix: Bugfix version</li>
<li>uk_0x10 - uk_0x20: Unkown</li>
<li>dwNumEntries number of partition entries</li>
</ul>For both, new and old version, the entries follow directly after the header. Each entries had the following format:<br />
<br />
<pre>typedef struct sPartitionEntryTag
{
u16 wDevice;
u16 wVolumeType;
u16 wVolume;
u16 uk_0x06;
u32 dwVolumeSize;
u32 wVolumeAction;
u8 cVolumeName[32];
u8 cMountName[32];
} sPartitionEntry;
</pre><br />
<ul><li>wDevice: Device number</li>
<li>wVolumeType: Volume type.</li>
<ul><li>0x0: RAW - no file system is available on this device</li>
<li>0x1: STATIC - A filesystem is available but will not change (e.g. for the boot partitions)</li>
<li>0x2: DYNAMIC - A filesystem is availalbe and can be changed </li>
</ul><li>wVolume: Volume number</li>
<li>uk_0x06: Unkown</li>
<li>dwVolumeSize: Size of the volume. Only to be used for wVolumeAction=2</li>
<li>wVolumeAction</li>
<ul><li>0x0: mount. Only for wVolumeType=2! -> mount /dev/ubi_<wdevice>_<wvolume></wvolume></wdevice></li>
<li>0x1: truncate and mount -> Truncates the partition and mounts it afterwards</li>
<li>0x2: create partition -> will call ubimkvol</li>
</ul></ul><br />
... to be continued ...<br />
<br />
Feel free to leave your comments!Unknownnoreply@blogger.com2