Jump to content


Photo

The AVIC Development Mod

bsp avic development developer dev xda android auto android linux kernel boot

  • Please log in to reply
575 replies to this topic

#1 bass_rock

bass_rock

    Member

  • Members
  • 166 posts

Posted 10 August 2015 - 11:02 PM

Introduction

WhatIsBypass, AdamOutler and myself present
The AVIC Development Mod

We have eliminated the barriers to development on all AVIC units including Android Auto. You can now create your own ROM on an SDCard and boot directly into it. We've broken all the security and obfuscations, and we've delivered it to you in a nice, easy-to-use web user interface. This has essentially turned the Pioneer line of units into Nexus devices, that boot off SD Cards.

We now have the ability to change the NEX BSP Settings which allow us to unlock the SD Card and change the boot settings that are in the Pioneer NEX. We are asking all ROM developers with a NEX step and help us create our own ROM to run on all versions on the NEX System.

With the help of all you we can begin to add USB Wifi Drivers, a custom app launcher, the play store, interface skins, more radio presets, radio station data augmented by the internet, Android Auto, iDatalink Gauges, and much more only limited by what we can develop.

 

NEVER ENTER COPY DEVICE MODE, YOU WILL BRICK YOUR DEVICE!

It is fixable though but a pain as described by WhatIsWhat

Overview
Here's a quick overview of what we will do in this post.

Overview Steps:
1. Backup your current BSP and Nor Flash
2. Backup your current internal SD Card, or obtain a backup SD Card Image.
3. Navigate to https://jenkins.adam...uild?delay=0sec and select the options you want
4. Remember your build number and download your package.
5. Extract to USB stick
6. Put it into USB Port 1
7. Run Script.
8. If you removed the SD Card password you need to insert a new internal SD Card with a backup image.
9. Done!


How To
Let's talk about the details, now.

Run Copy Script Mode:

1. Insert the USB Stick to USB Port 1 on the device.
2. Start the deck, it will then reboot into Technical TestMode. You must use the keys to navigate the menus. BE VERY CAREFUL AS SOME OPTIONS CAN BRICK YOUR UNIT.

 

IMG_0947.JPG

3. Use the Vol - button to navigate to "Write Programs Forcibly"

 

IMG_0948.JPG

4. Press the Home Button to select this menu

 

IMG_0949.JPG

5. Use the Vol - button to navigate to "Copy Script"

 

IMG_0950.JPG

 

6. Press the Home Button to select this menu
7. Take note of the Values on the right hand side of the screen, THESE WILL BE ERASED. (It is currently unknown if these will be needed in the future). If you really want to keep these values though, you can write them down and place them in the corresponding SDCardCWWVersion.txt before you continue.

 

IMG_0951.JPG

8. Press the Home Button to run the script.
9. After it says 100% press the Home Button to reset the unit and remove the USB stick.

 

 

Full Steps to get to a development state:

1. Backup your current BSP and Nor Flash.

 

See http://avic411.com/i...ckup/ for this.

2. Backup your Internal SD Card (Skip to 3 if you have an unlocked image you want to use)
 

See http://avic411.com/i...-device-backup/ for this.

 

3.Install a Customized BSP

A. Navigate to https://jenkins.casu...uild?delay=0sec
B. Select the options that you want to enable. The currently known defaults are already selected. For development select debugSwitch: Debug On Console On, subBootMode: Disable Warp, choicePassword: Remove the Password
C. Click Build and note the build number that was started on the left.
D. Navigate to https://jenkins.casu..._HERE/artifact/ where INSERT_BUILD_NUMBER_HERE is your build number.
E. Click the (all files in zip)
F. Extract the contents of the download to a USB Stick. (FAT32 or NTFS)
G. Follow the "Copy Script Mode" steps.
H. The unit when it reboots should error out because you removed the SD Card Password lock.

4. Insert an Unlocked Internal SD Card Image

A. dd the AVIC.img you backed up to an SD Card of the appropriate size.
B. Insert the new SD Card into the Internal SD Card slot.
C. Start up the unit. NOTE: It will take a bit for the device to boot since you have disabled WARP above.

5. Congrats!!!! You can now remove the internal SD Card at will and modify the items in the partition and put it back into the Deck. Good luck on your Custom Rom Development and be sure to share your creations!!

 

What we are now asking of the ROM Community:

1. Help us by developing custom roms using the steps above and sharing your creations.
2. Once we have a custom rom we want to share easily, we will get to the steps where we start Creating a new WARP snapshot, and recompiling them back into PRG Update Files.
3. Find a way to enable ADB, One option would be to add a Network Bluetooth Profile, Another option is figuring out USB OTG properly.
4. Lets create an app launcher.
5. Figure out how to modify the maps.
6. Figure out Android Auto/Bluetooth Audio on older models with the new software.



Additional Reading
Repo of the PRG recompile and TestMode Scripts: https://github.com/bassrock/AVIC-NEX
Pioneer 5100 Sources: http://www.oss-pione...0nex/index.html
Pioneer 5000 Sources: http://www.oss-pione...0nex/index.html

 

 

Update 8/13/15: ​We have found a new Developer debug mode that can be discussed and spend by following the steps here: http://avic411.com/i...per-debug-menu/

Attached Files



#2 bass_rock

bass_rock

    Member

  • Members
  • 166 posts

Posted 10 August 2015 - 11:02 PM

Below are some development notes that we have taken:

Links to source code for 60-series and x000-series:
http://www.oss-pione...0nex/index.html
For 70-series and x100-series:
http://www.oss-pione...0nex/index.html

Source code links contains pioneer's modified sources of U-Boot. This uboot_imx.zip contains most useful code, for example:
uboot_imx/src/common/cmd_bootconfigs.c - bsp logic: configuration, initialization and settings, including command-line interface (U-Boot cmd line), also this file contains description of BSP struct in NOR memory
uboot_imx/src/common/cmd_model.c - pioneer's device model logic: configuration, initialization, reading from nor and model structure description
uboot_imx/src/drivers/mmc/mmc.c - internal SD card mmc logic: password initialization, password setting code (for new sd cards), password checking
uboot_imx/src/common/main.c - contais main function called during startup: device initialization, checking and executing BSP startup options, logic for fallback to easyrecovery if sd card init failed, warp logic (clear, use, normal), kernel debug logic

==============
Nor Regions

Device's NOR flash memory (8 MB) mapped to three different devices:

/dev/mtd/mtd0
/dev/mtd/mtd1
/dev/mtd/mtd2

mtd0 flash region map:
 

Address Size
0x000000, 0x0FFE00 // bootloader code
0x0FFE00, 0x000200 // looks like bootloader 512-byte header from fimrware PRG file
0x100000, 0x010000 // model info side A
0x110000, 0x010000 // model info side B
0x120000, 0x010000 // part of opening data PRG file header
0x130000, 0x120000 // opening data
0x250000, 0x010000 // bsp side a
0x260000, 0x010000 // bsp side b

mtd1 contains unknown data (mostly 0xFF's)
mtd2 contains EasyRecovery image (linux kernel + additional files + EasyRecovery executable + android toolbox)
==============
NOR reflashing

To write to NOR memory you can use simple dd command, for example:

dd if=/mnt/udisk/new.img of=/dev/block/mtdblock0 seek=2424832 count=84 bs=1

but before you can write you must erase NOR flash region using ioctl command:

/system/bin/ioctl -l 8 -a 4 /dev/mtd/mtd0 1074285826 2424832 65536

Where 2424832 is start address, 65536 is memory erase block size. Looks like both this values must be multiple of 0x10000 (Address is aligned to 0x10000 boundary, size is multiple of 0x10000), at least original firmware uses this alignment.
=============
U-Boot init

At startup U-Boot checks availability (valid signature and valid crc32 checksum) of both sides of BSP.
If Side A is invalid, U-Boot copies Side B to Side A. If Side B is invalid, U-Boot copes Side A to Side B.
If both sides is invalid, U-Boot creates default BSP (W/O password) and writes this BSP to both sides.

After this main function tries to initialize sd card and set password. If initialization of sd card (or password) is failed, U-Boot enters EasyRecovery stage.
During SD card initialization U-Boot tries to unlock SD card with password stored in BSP. If SD card isn't password locked, U-Boot sets (locks) SD card with password from BSP.
If password contains 16 '*' chars or 16 0xFF chars then U-Boot does not use password at all and does not tries to set password on unlocked sd card.
So to use SDCard w/o password you need to remove password from BSP (fill with *) and after this insert new unlocked SD card into device.
=============
U-Boot start

After initialization, U-Boot reads BSP startup information and tries to boot using BSP settings.
If debug option is specified, U-Boot sets debug environment variables (console_kernel, console_android, printk.time, printk.console)
For normal boot (ulbootmode var = NORMAL) it is possible to specify WARP setting (ulsubbootmode setting: do not use WARP, use WARP, clear WARP cache). WARP can boot from two sides (a/b, ulwarpboot variable) Also, ulbootimageflag is used to specify normal kernel side ( A or B ) which used to boot system.
For recovery boot (ulbootmode var = RECVOERY_BOOT, yes, exactly RECVOERY) ulrecoveryimageflag contains info wich side (A or B from two sides on SD card) is use to boot recovery kernel.
For all other modes there is fallback to EasyRecovery boot. U-Boot setups debugging environment variables for kernel and android and boots up EasyRecovery image from NOR flash
If something wrong occures, U-Boot tries to start EasyRecovery kernel from NOR flash.
=============
BSP struct

BSP is 84-byte structure containing signature (A5 5A 5A A5, used for struct validation), 76 bytes of data and 4 bytes of CRC32 field.
CRC32 field can be calculated using following PHP code:
 

$file = file_get_contents("bsp_block_wo_crc"); // must be 80 bytes length
$file_original_with_crc32 = $file . pack("V", crc32($file));
file_put_contents("bsp_block_with_crc_original_from_php", $file_original_with_crc32); // 84 bytes

BSP fields:

struct bsp_data_info
{
ulong ulSignature; // 0
ulong ulbootmode; // 4
ulong ullaunchmode; // 8
ulong ultestsubmode; // 12
ulong ulbootimageflag; // 16
ulong ulrecoveryimageflag; // 20
ulong uldebugswitch; // 24
ulong ulusbotgswitch; // 28
ulong ulmemchkflag; // 32
ulong ulwarpboot; // 36
ulong ulsubbootmode; // 40
ulong ulupdateflag; // 44
ulong ulupdatesubflag; // 48
char passwd[MMC_SET_PASSWD_MAX_LEN]; // 52
ulong uluiupdateflag; // 68
ulong ulreserved1; // 72
ulong ulreserved2; // 74
    ulong ulcrc32; // 80
};

All fields are unsigned 32-bit integers (4 bytes, except password) and stored in Little-endian form. So value 0x12345678 is storead as 0x78 0x56 0x34 0x12 (order of bytes is reversed)

Real-world BSP structure example:

A5 5A 5A A5 // ulSignature; // 0 //
00 00 00 00 // ulbootmode; // 4 // normal boot
00 00 00 00 // ullaunchmode; // 8 // APL
00 00 00 00 // ultestsubmode; // 12 // TestMode.apk
00 00 00 00 // ulbootimageflag; // 16 // side a
00 00 00 00 // ulrecoveryimageflag; // 20 // side a
00 00 00 00 // uldebugswitch; // 24 // debugging disabled
00 00 00 00 // ulusbotgswitch; // 28 // usb otg disabled
00 00 00 00 // ulmemchkflag; // 32 // do not check memory at startup
00 00 00 00 // ulwarpboot; // 36 // warp boot side A
02 00 00 00 // ulsubbootmode; // 40 // enable warp boot
00 00 00 00 // ulupdateflag; // 44 // recovery-update
02 00 00 00 // ulupdatesubflag; // 48 // USB2
4C 4B 50 46 65 44 34 42 63 56 7A 45 53 52 32 59 // password: LKPFeD4BcVzESR2Y
00 00 00 00 // uluiupdateflag; // 68 // non-updating
FF FF FF FF // ulreserved1; // 72
FF FF FF FF // ulreserved2; // 74
96 8D 6E 12 // ulcrc32; // 80 crc32 of all previous data including signature

=============
Model info struct:

struct model_data_info

{
ulong ul_Signature;
char c_serialnum[4]; // model serial number (available in product information testmode menu as two last groups of digits
    char c_reserve1[12];
    char c_serialnumccks[4];
    char c_reserve2[12];
    char c_productnum[2]; // product number (available in product information testmode menu as first group of digits)
    char c_reserve3[14];
    char c_productnumcks[2];
    char c_reserve4[14];
    char c_productdate[2]; // model year stored in BCD encoding (available in product information testmode menu as second group of digits)
    char c_reserve5[14];
    char c_productdatecks[2];
    char c_reserve6[14];
    char c_reserve7[160];
char c_cwwinfo[16]; // NOR memory factory code (contains CWW7906- for AVIC F960BT and AVIC F960DAB), this string is also available on NOR flash memory chip body on daughter PCB
    char c_reserve8[240];
    ulong ul_checksum;
} __attribute__ ((packed));

All this values (except CWW Info) is freely available for edit in testmode menu Write Product Information (manual). Changing device serial number isn't affected iGo (iGo still working as expected after serial number change)
=============
iGo device IDs

iGo device id contains three strings, ',' delimeted. For example:

2c9b382df1de42c0,744A45534443202010300012DC00DC00,74300012DC

Where 2c9b382df1de42c0 is android_id setting (http://developer.and...html#ANDROID_ID) this setting is the same for different devices of same model. For example, both F960BT and F960DAB contains 2bd9ce6e1af1bc81 device id. For 8100NEX device id is 7d15307dcf66e17c. Also this ID can be freely modified.

744A45534443202010300012DC00DC00 is sd card id (format isn't yet known but I belive it based only on sd card info).
This id contains following groups of digits (I hope someone can help us decipher java (smali) code of sdcard id data acquisition):

0123456789012345 67 89012345 67 8901 << positions
744A455344432020 02 020007D6 00 E800 << 8100NEX
744A455344432020 10 300012DC 00 DC00 << 5000NEX

First group is "tJESDC " in text and unchanged, second group is unknown, third group looks like sd serial and unique for different (not cloned) devices, last two groups is unknown
Third part of iGo device id contains first two chars of second group and third part of second group, so for ID
744A45534443202010300012DC00DC00 third part will be 74300012DC

Also, iGo works great on cloned devices, so licensing information (data for device identification) and so on is exists only on sd card.



#3 bass_rock

bass_rock

    Member

  • Members
  • 166 posts

Posted 10 August 2015 - 11:02 PM

FAQs

What does this mean?

1. WARP can be disabled
2. Internal SD Password Lock can be removed (Requires a new sd card afterward)
3. Debug can be enabled.
4. We can modify the Internal SD Card by inserting it into the computer with the above turned on.
5. Custom ROM development can truly begin.

What the heck is warp?

A: It's the hibernate function.  At the factory, they hibernate the device and every time it turns on it uses this information. This prevents us from loading custom firmware because the deck chooses this memory loaded information over the filesystem changes that we create.

What is the BSP?

A: The BSP is a special are in the NOR Memory (different from the SD Card), where U-Boot, EasyRecovery and all the low-level U-Boot settings are located. It is 84 bytes in size and has two copies in case one fails.

What is NOR Memory?

A: The NOR Memory is an area separate of the SD Card that contains, boot settings, recovery partitions and the boot loader.

Why do we need to remove the SD Card Password?

A: The Pioneer dev's decided to put a hardcoded password lock onto the Internal System SD Card that prevents you from just putting it into your computer. By removing it we allow the ability to remove the internal SD and to put it into any computer to modify the Platform files, without having to run an Update.

What is the SD Card password?

A: LKPFeD4BcVzESR2Y

Can't we just unlock the password on a computer and not change the BSP?

A: Yes, and no. In order to unlock the SD card you need to have the ability to run CMD42 on the SDCard which most linux distributions and os’s do not have.

What is Debug mode?

A: The Debug mode outputs more logs and turns on a console port somewhere on the device. We still do not know where that is. NOTE: It is most likely possible to patch the kernel to use the iDataLink port as a UART console for ADB.

 

What are the device paths if I want to change the backup or restore locations?

A: 

/mnt/udisk/ for USB1
/mnt/udisk1/ for USB2
/sdcard/ for external sdcard

What is the Partition Map look like?

A: For a 8GB internal SD Card (AVIC 5000) it looks like this:

Disk /dev/mmcblk1: 8069MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system                          MY Findings:
 1      538MB   548MB   10.5MB  primary   android      boot A                  BOOT/BOT.PRG
 2      548MB   559MB   10.5MB  primary   android      boot B            
 3      559MB   1830MB  1271MB  extended
 5      559MB   590MB   31.5MB  logical   android      recovery A              RECOVERY/REC.PRG
 6      590MB   622MB   31.5MB  logical   android      recovery B              RECOVERYEASY/ERY.PRG ?
 7      622MB   1159MB  537MB   logical   ext4         /system                 PLATFORM/PLT.PRG
 8      1159MB  1293MB  134MB   logical   ext4         /cache
 9      1293MB  1830MB  537MB   logical   ext4         /data                   USERDATA/DAT.PRG 
 4      1830MB  7702MB  5872MB  primary   ext4         /extdata

How can I unlock my SD Card?

A: Follow the following steps:

1. Set SDCard password in BSP

2. Place Test Key N3 on USB stick
3. Power on unit
4. When screen goes black turn unit off and back on
5.  When unit shows Mode Change OK screen, remove the SDCard and power off the unit.

 

 

Update 8/16/2015: Added how to unlock an SD Card.



#4 AdamOutler

AdamOutler

    Member

  • Members
  • 70 posts

Posted 10 August 2015 - 11:03 PM

Due to contractual obligations, I did nothing. I watched. I like watching. ;)
Flash your Samsung with Odin on Windows, Linux and Mac. Use JOdin3, Available in a web browser or offline
Check out my developer pages. Add me to your circles on Google Plus.
Wanna see the longest Linux BASH script ever made? click here.
newsig-2.png

#5 gotofbi

gotofbi
  • Members
  • 9 posts

Posted 10 August 2015 - 11:29 PM

Great work guys!



#6 LeshyLeshy

LeshyLeshy
  • Members
  • 13 posts

Posted 11 August 2015 - 12:17 AM

@Adam

 

developers don't sleep tonight :)

 

you should insert  just another point in to the FAQ

 

what is bypass ? :)



#7 WhatIsWhatIsWhatIsWhat

WhatIsWhatIsWhatIsWhat

    Member

  • Members
  • 234 posts

Posted 11 August 2015 - 12:22 AM

Great work guys, subscribing to the topic.


Please join our Pioneer-related groupchat to get help. Sorry, I do not read or respond to private messages. Please contact me via groupchat.

#8 whitestormy

whitestormy
  • Members
  • 7 posts

Posted 11 August 2015 - 02:17 AM

congrats guys. this is huge. thank you for kicking the door open on this.



#9 nolarola

nolarola

    Member

  • Members
  • 158 posts

Posted 11 August 2015 - 12:05 PM

Very well done, all. Maybe we can start off slow and get the x000 devices to work with the x100 firmware? I don't have a jtag device, knowledge, etc, so I'd be very concerned.

#10 Lucca

Lucca

    Member

  • Members
  • 53 posts

Posted 11 August 2015 - 01:00 PM

Well done! Now - simply root your devices & have fun with iGO & other stuff... 8)



#11 JhonnyB

JhonnyB

    Member

  • Members
  • 65 posts

Posted 11 August 2015 - 04:16 PM

Nice, maybe we get an modded AVIC-F70DAB firmware? :)



#12 Lucca

Lucca

    Member

  • Members
  • 53 posts

Posted 11 August 2015 - 04:55 PM

Nice, maybe we get an modded AVIC-F70DAB firmware? :)

Course friend,even modded AVIC-F77DAB...

Spoiler



#13 JohnnyCanuck

JohnnyCanuck
  • Members
  • 9 posts

Posted 11 August 2015 - 06:31 PM

Just to confirm the very first sentence "We have eliminated the barriers to development on all AVIC units including Android Auto." Does this mean what I think (and hope) it does? That it will work on non-NEX units as well (like my X940BT)?



#14 Lucca

Lucca

    Member

  • Members
  • 53 posts

Posted 11 August 2015 - 06:45 PM

Just to confirm the very first sentence "We have eliminated the barriers to development on all AVIC units including Android Auto." Does this mean what I think (and hope) it does? That it will work on non-NEX units as well (like my X940BT)?

Ye,seems they achieved CWW9971 0.14 ...as well... ;)



#15 JohnnyCanuck

JohnnyCanuck
  • Members
  • 9 posts

Posted 11 August 2015 - 06:52 PM

Awesome ... can't wait to see some compiled ROMs and run Android on it!







Also tagged with one or more of these keywords: bsp, avic, development, developer, dev, xda, android auto, android, linux, kernel boot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users