rjoc

Small update, I completely recovered my HU.. but some some stupid reason my carplay doesn't work, it's gives a 02-60 error on the HU screen (Communication Error during iPod Authentication). 

If carplay is disabled on my iPhone it can authenticate and be used as an ipod so the auth chip works at some level. I am uncertain if this is my phone or my HU. This is running stock firmware.

So this means that I can't test to see if my nag screen patch works! 

Also, it's important to note that carplay is basically just airplay. The phone does _all_ of the work, the HU basically becomes an external screen and buttons - its similar in concept to how third party apps work on the watch. The actual interface for carplay on the HU is basically auth handshake, and then open up a socket to communicate back and forth. 

Carplay apps are just apps on your phone with special features/interface for the different screen.

The only major difference between the NEX-4000 firmware and the SPH-DA120 is the model number and the GPS module stuff.

You can cross flash a SPH-DA120 1.07 with the NEX-4000 1.08 back and forwards. There are very few, if any, other differences in my analysis.

I think because SPH-DA120 is basically the same as the NEX and uses the same base software they just decided to sync the numbers to make manufacturing easier - they didn't push and update because there was no update, just a version number changing - leaving us confused

Sorry for the lack of updates, I've been really busy at work.

* Looks like I got into a test mode that's not actually supposed to be accessed directly. Touch buttons *should* work on my unit in test mode (assuming if accessed correctly).

* I've not yet been able to solder on my JTAG connector because the pitch is super fine and I don't solder fine regularly so I'm not confident yet. I trashed all my connectors in testing, so I've got to get some more in.

In the mean time, I'm confident the software patch will work with a crafted update. I just not sure how user friendly it is.

I'm going to replace the CPU board in my unit which will get me up and running again to finish the software hack then root the "bricked" CPU board properly later.

I also need to identify which of the testmode keys I've reversed boots up the proper factory test mode. I think there are two real ones and around 4 more that just go directly to commands skipping the proper load process (one of the ones is what got me stuck!)

So current status is waiting for that part to arrive.

I'm waiting for a last part to arrive to actually get started, but here's where I'm at:

* I'm still stuck in a TESTMODE_N recovery mode.

* Messing with the file-system and partition table has been basically useless due to Warp!

* I need to change the BSP to get out.

* The most straightforward way to modify the BSP is JTAG.

Instead of soldering on wires to the JTAG pads that I'll need to remove when I put the thing back together I've identified the connector, (it's on the way) and I'll solder this on so that I can leave it in place.

I'll also need to make a adaptor board once I've double checked the JTAG pins to go from the CPU board to my JTAG device.

I haven't yet completed my SD card unlocker, I've got the parts sitting here - I just don't have the SD card password so I can't do anything with it yet! (I can bypass the password, just don't know it).

I did spend a couple of hours one night watching the SD traffic with a logic analyzer but didn't follow through to get the right password yet - the password will be sitting in the BSP so I can read that easily once I've got a dump of the flash via JTAG.

I'm also pretty sure I've worked out how to correctly patch the official update to apply my nag-screen patch to allow just updating through the GUI without any hacks, but can't test this until I've got my system back to normal! (I don't really know what will happen with Warp when this update is applied, it looks like it'll take a new snapshot but I'm not certain).

I'm still stuck. Waiting for a new JTAG debugger, and not looking forward to soldering onto those small surface mount pads.

Having some success with modifying file systems to do some strange things though, I should be able to run code and/or get an ADB console soon enough. Conscious of the weird WARP mode though - that could still get in the way. Once I get console there's potential to read and edit the BSP, this would be far better in my mind the actually modding the device - (till now other than disassembling it all I've done is remove the SD card.) I'd love to find that mythical /dev/ttymxc0 though.. 

Fun fact, the system can boot a SD card (with the right filesystem) without a password but on boot it sets the password - meaning your regular computer/card reader can't read the card again (unless you can unlock the password via Linux). This makes it super slow and annoying to experiment as I have to bypass the password manually each time.

I'm thinking about building a small device, based on http://www.seanet.com/~karllunt/sdlocker.html to unlock and clear the password on a SD card when inserted.

You'd need to know your password but once you've got it then it'd be pretty simple and fast to remove it (after each time you put the card back in the head unit).

This should make iterative testing a bunch faster

Update: 

Lineo Warp!! is a huge pita. I'm going to need a to find that console or go JTAG to recover.

I'm also having SPH DA120. So should i understand that "hardware buttons" on the left side, aren't functionnal because they are part of the touchscreen panel also ?

SPH DA120 has no physical buttons - it's all a touch screen. If you take the front panel apart you'll see it's a glass panel over a piece of black plastic with clear bits in the shape of the "buttons". Underneath them is a light pipe for the single LED that lights them all up. They're just touch targets. 

Some testmodes don't load the drivers so the "buttons" don't work. 

Try wired remote. It very simple, just few resistors. You can build own in just 10 minutes using resistors, jack and two wires.

Thanks - I built one today and had no success, it didn't work at all. I can't be 100% certain what I built was correct as I haven't been able to test it in a working unit but I tried a lot of different resistances for several hours with a POT.

I also tried the steering wheel interface in my car directly and no good.

I disassembled libraries and found this keys and key's content. Yes, there is 3 different contents for testmode_n for three modes (65, 66 and 66 bytes). Testmode_s contains only one digit (1-4) to select mode, testmode_a runs TestMode.apk. I'm owner of AVIC F960BT, European version of AVIC NEX series. In November the radio just stopped working while I driving. When it powered it loads for 3-5 seconds showing logo and reboots. (Boot loop). Then I disassembled libraries and tried this testmode files and without any success, nothing happens, it just reboots. From November to now my radio in Pioneer's authorized services, service workers says that they are waiting for SD card replacement (my SD card failed) from Pioneer.

I missed the mode selector for TESTMODE_S! I'll have to check this when I get booting again.

I pulled two different keys for TESTMODE_A both trigger the system to go in to the test mode but I instantly get an error about it failing to launch and to "Turn ACC power off"

I'm actually using a SPH-DA120 and while it has the same software it's hardware appears different (I haven't seen a 5000NEX). The whole front plate is a touch screen - I took it apart and there are no hardware buttons.

Either Pioneer tech's have a different interface or they've shipped a recovery mode that doesn't work with this hardware! 

rjoc, have you tried TESTMODE_A.KEY, TESTMODE_S.KEY, TESTMODE_N.KEY keys? I have content for this files, but can't enter testmode using this files

Yep, I've got several SD backups. However the mode I'm in is the one in Bushing's photo:

To get here I inserted a USB drive containing a specially crafted TESTMODE_N.KEY, the system automatically picks it up and it flips a bit in the NOR flash ROM to boot to the recovery partition then reboots. So if you boot with any SD card it boots to the recovery partition.

This persists past reboots and SD card changes so the only way to get out is to flip that bit again - (I can't get out the same way I got in either!)

The issue I've got is my touchscreen doesn't work in this mode so I can't change inputs. I'm currently working on the theory that there's another method of controlling it, maybe via the wired remote port.

Tellingly Pioneer's parts website lists a "SERVICE IF UNIT" for these head units, I'm guessing IF means interface.

Quick update. 

I got the head unit and managed to bypass the SD card password to take an image - just opening it up and swapping the powered SD card into a computer to then read the data off - the HU unlocks the card then I whip it out (powered) and the card stays in an unlocked state.

I then started information gathering in the various the filesystem images and discovered how to access several of the TESTMODE's

I've bricked and recovered my unit about 5 times today, the final time it's stuck ironically on a programming screen (but not responding to touchscreen input) and unless I can thinking of something out of left field I'm going to have to follow in bushing's footsteps and get JTAG on the device to reset the BSP boot mode back to normal.

I have not found a non-rooting way of getting ADB console or an access point for /dev/ttymcx0 (that'd be really nice right now).