Condi's HACKMODE v2.2 - AUTOINSTALL! working also with F40BT, X940BT etc! [updated: 27.09.2012]

[Anonnie]

Unless he has the debugger stub, kdstub.dll in the runtime image, its going to require them to be added with the KITL transport to the core OS image.

 

In the Z110 diagrams, there is a serial port on the Iphone connector, that could be useful.

 

Now we could build a kernel, but that would require either getting the SirfPrima drivers to put into the build to make a new core OS, or extracting the old ones so we can build a debug kernel.

 

And just to confirm.. This is the chip used correct?

 

http://www.csr.com/products/36/sirfprima

 

If so, here are some docs on it:

http://www.google.com/search?rlz=1C1CHKZ_enUS438US438&sourceid=chrome&ie=UTF-8&q=SiRF_Binary_Protocol.pdf

 

Other potentially useful links:

http://w5.nuinternet.com/s660100031/SirfTech.htm

[kttii]

Unless he has the debugger stub, kdstub.dll in the runtime image, its going to require them to be added with the KITL transport to the core OS image.

 

In the Z110 diagrams, there is a serial port on the Iphone connector, that could be useful.

 

Now we could build a kernel, but that would require either getting the SirfPrima drivers to put into the build to make a new core OS, or extracting the old ones so we can build a debug kernel.

 

And just to confirm.. This is the chip used correct?

 

http://www.csr.com/products/36/sirfprima

 

If so, here are some docs on it:

http://www.google.com/search?rlz=1C1CHKZ_enUS438US438&sourceid=chrome&ie=UTF-8&q=SiRF_Binary_Protocol.pdf

 

Other potentially useful links:

http://w5.nuinternet.com/s660100031/SirfTech.htm

 

 

[Anonnie]

I'm inclined to go pick up another one just to throw on my bench (since working out of a car isnt as productive). I think i can get a z120 for like $400.

 

Big question here is this... Does the unit have a control sequence if you blow the image completely up? Think of the hard boot loader that you find on most devices that makes it almost impossible to brick the device since you can completely reflash back.

[kttii]

I THINK Testmode will allow you to fix any image issues. Perhaps someone else can elaborate on/verify that.

[condiczek]

I'm inclined to go pick up another one just to throw on my bench (since working out of a car isnt as productive). I think i can get a z120 for like $400.

 

Big question here is this... Does the unit have a control sequence if you blow the image completely up? Think of the hard boot loader that you find on most devices that makes it almost impossible to brick the device since you can completely reflash back.

I'm so happy to see you here working to free our avics, friend!

We can access testmode, which is loading after the device find testmode.key file on sd/usb.

We don't know if we will modify or even delete EU090PLT/RGD/BOT files we could access service menu via testmode.key.

There is a risk of brick. Some time ago when I was looking through bin (prg) image files - I saw somewhere WINDOWS CE bootloader with blue background , like in any other wince devices/navigations. With options like flashing wince.img etc. But we don't have such images correct for that bootloader.

The question is how to access native wince bootloader? Some gpses which I was working were able to access wince bootloader via shorting a pin of one chip to ground.

We can also flash appriopriate images - PLT, BOT, RGD etc. via testmode.key. There is menu where it can be flashed from sd - another way to do this.

Or we could simple replace RGD file, where was coredll.exe, nk.exe.

If there is a way I could help just ask!

 

RNDIS USB KITL - is this what we need? havent I seen this somewhere in my unit?

[Anonnie]

I'd love to say USB debugging on CE 5 is cake, but MS has never been known to get USB debugging to be worthwhile on any of their kernel dev platforms. To give you a better understanding, there is good, bad, horrible, nightmareish, then there is USB support for kernel debugging from windows. Which is why I was bringing up the serial port path.

 

The main reason is because in windows, you have to bring up the enumeration bus, then the actual device itself (there are a few more steps, but you get the idea, its not just a 'hey wake this 1 device up and we're good!'.

 

That said, I may be able to rip the current image apart and pull the drivers and reg keys from it and rebuild a boosting driver that can be loaded at boot time, but before the debugger attaches.

 

The issue is that we have no ethernet interface to gain a TCP/IP address for remote tools.

 

The old fashioned way to get things rocking on a CE device was to put the image file (nk_ram.nb0 or whatever you want to call the NK bin file) and an autoexec.bat (go figure right?) on a SD card to boot. Then you boot the device and if it still has its basic bootloader, it should pick that up. Now if it DOES boot off the SD, theres a great chance that you will be able to load a custom bootloader in the event you trash the image you upload since you can completely remoteboot off of SD without a care of what is in the device's memory.

 

The autoexec.bat file contains this:

 

 

display

boot mmc nk_ram.nb0 kitl

 

If you have something connected to its com1 @ 384k 8N1, the serial port will show you objects as they come up online.

 

From the TESTMODE and HACKMODE, it seems they have a stubloader that will load up different images. If we could get a dump of that boot stub, we could see some of the different points of access that exist unless the file itself has a portion of code that is executed after the stub has done its basic init.

 

I'll check to see if any of those could be disassembled into something that might run.

 

Update: So the PRG0 and PRG1 are pretty much a mirror image of each other on a stock 3.001 system (Z130).

Something I did see in the threads was the "USBSerialFn.dll" which is very nice and if that emulates COM0 (as you can get the source code for that puppy) then we have a terminal connection with a USB serial cable so we can start doing some light tracing.

 

Now I noticed someone mentioned 4 copies of the rom in a different location in nand. Its quite normal to see multiple copies in a firmware device, especially when you bank them so you can call different banks when you want to perform different tasks. You'll see this in almost any 'scene' from consoles to set tops. Its probably the same here, and the kicker is probably in the bootstrap stub with a jmp to the TESTMODE chunk to switch base load addresses. Now I'm just being theoretical here, but its a decent shot.

 

Edit: I'm doubting the TESTMODE to be code itself. Disassembly in a normal ARM decompiler is ugly. I had a disassembler that had decent instructions, but IDA's says otherwise. So i'll lean toward unicode rotated text or something else.

[rrolff]

I'd love to say USB debugging on CE 5 is cake, but MS has never been known to get USB debugging to be worthwhile on any of their kernel dev platforms. To give you a better understanding, there is good, bad, horrible, nightmareish, then there is USB support for kernel debugging from windows. Which is why I was bringing up the serial port path.

 

The main reason is because in windows, you have to bring up the enumeration bus, then the actual device itself (there are a few more steps, but you get the idea, its not just a 'hey wake this 1 device up and we're good!'.

 

That said, I may be able to rip the current image apart and pull the drivers and reg keys from it and rebuild a boosting driver that can be loaded at boot time, but before the debugger attaches.

 

The issue is that we have no ethernet interface to gain a TCP/IP address for remote tools.

The ARM processor supports both Ethernet and JTAG...

 

Connector/port CN4621 is the JTAG port (though I doubt they populated the actual connector once dev was done - but the pads are still there to solder a connector onto *if* it isn't already there...).

 

Connector/port CN4401 is the Ethernet port. As above - I doubt they populated it - but for debugging/flashing et al, this is the high speed way to go...

 

I'd probably solder a connector and build an external 'plug' if we ever move forward - reflashing at 100mb - mmmmmmmmmmmm

 

Welcome aboard!!!!!!!!!!!!!!!!!!!

[Anonnie]

Unless the Z130 diagram is different than the Z110, that CN4401 connector isnt ethernet, or is going to need a serious mux to bind those 16 lines down into a 2 pair TX/RX set with a little more circuitry. That connector is tied to memory address lines.

 

I'll take a look at that JTAG since OpenOCD doesnt directly support this proc, but as a generic ARM should be good enough.

[Ralpharn]

Unless the Z130 diagram is different than the Z110, that CN4401 connector isnt ethernet, or is going to need a serious mux to bind those 16 lines down into a 2 pair TX/RX set with a little more circuitry. That connector is tied to memory address lines.

 

I'll take a look at that JTAG since OpenOCD doesnt directly support this proc, but as a generic ARM should be good enough.

Here is a part of X930BT diagram for this connector:

[Anonnie]

Yeah, its same as Z110. However I did run into something pretty damn cool..

 

http://www.4shared.com/get/N-tfH5xt/SiRF_ARM4VI_based_BSP_for_the_.html

 

A BSP for the SiRF chip.. imagine that!

 

For those wondering WTF is a BSP, its the driver set and fundamental building block you use to build an image for a particular chipset or chip.

[Ralpharn]

Yeah, its same as Z110. However I did run into something pretty damn cool..

 

http://www.4shared.c...P_for_the_.html

 

A BSP for the SiRF chip.. imagine that!

 

For those wondering WTF is a BSP, its the driver set and fundamental building block you use to build an image for a particular chipset or chip.

ciroalbano has mentioned before (page 28 here) that he managed to run F220 map on F920... and F220 completely hacked now, is it worth to check their hack because they had same issues with GPS port and they solved it somehow. if you need hack for F220 I can post it here or send it to you. here it is

 

+ thay said: driver in F220 gets signal from GPS and turn it to 5 virtual com ports.

[rrolff]

Unless the Z130 diagram is different than the Z110, that CN4401 connector isnt ethernet, or is going to need a serious mux to bind those 16 lines down into a 2 pair TX/RX set with a little more circuitry. That connector is tied to memory address lines.

 

I'll take a look at that JTAG since OpenOCD doesnt directly support this proc, but as a generic ARM should be good enough.

It is the Ethernet port - but would need an adapter board - transformer + chip... Very common thing maybe in the dev world... I'm sure in the ARM JTAG world, ARM is ARM is ARM... I've managed a project in the ARM world (we ran Linux), and if you have some knowledge there - I'm hoping that may be sufficient

 

Pioneer should be putting resources into this (not that it would ever in their world happen). A semi open-source (with proprietary *good* audio) project where people can choose software - would be huge in a car. Even taking out Android etc OS' - you get basically a PC in a car - WiFi streaming, Internet browsing (with live traffic) - heck - Netflix...

 

You will get many a donation if this opens up (as will Condi).

 

The Pioneers/Sony's et al are on the verge of a crazy car thing. China has the basics - but lacks the audio side, the brand and the GUI. I'd predict in the next year we'll see a slew of generic adaptable good hardware from China (not that these aren't made there too)..

 

An Android/Linux project will get a community of support (which sadly WINCE has not done over the last few years) - and I think we are close to a great random Chinese thing. They have the basic audio (which isn't bad) - they lack the audio GUI (which must be upgradeable) and the broad community support...

 

That said, I'd love to see an open WinCE for the now..............

[Anonnie]

It is the Ethernet port - but would need an adapter board - transformer + chip... Very common thing maybe in the dev world...

 

My only point was that you're not going to solder a RJ-45 to it and be on your way, its more involved than going down another path.

 

I'm sure in the ARM JTAG world, ARM is ARM is ARM...

 

Indeed, i've learned in the world of development that many blind assumptions can turn out to be a complete loss. That said, ARM is indeed ARM, and shouldn't make a difference. I tend to post with caution in my verbiage unless I know 100% the statement is to be known and tested correct.

 

Pioneer should be putting resources into this (not that it would ever in their world happen). A semi open-source (with proprietary *good* audio) project where people can choose software - would be huge in a car. Even taking out Android etc OS' - you get basically a PC in a car - WiFi streaming, Internet browsing (with live traffic) - heck - Netflix...

 

If we could get the SiRFPrima build package for linux, we could indeed do it as a grass roots effort. Perhaps a few inquiries and they may consider it, or just tell us to piss off. There have been a few hardware vendors that have benefited from the community creating some excellent scenarios making their hardware superior just because of the options it presented. Hell its the mantra behind Android in the first place. If we couldn't hack and create whatever we wanted, no one would really care.

 

You will get many a donation if this opens up (as will Condi).

Money is nifty, but I'm in it to just have some fun and blow off some steam between coding sessions (sounds a bit odd eh?). This is my form of playing a "game".

 

That said, I'd love to see an open WinCE for the now..............

 

I'm going to get this BSP integrated into my Platform Builder, and see what shakes up. I just want to make sure that if I flash a rom into the system, that I don't kill my unit and dev efforts by soft-bricking it. It would be nice if I could address the 2nd/3rd/4th bank and boot/replace those so if I screw them up, I can boot into the 1st bank and put the stock back and try again.

[rrolff]

I'm going to get this BSP integrated into my Platform Builder, and see what shakes up. I just want to make sure that if I flash a rom into the system, that I don't kill my unit and dev efforts by soft-bricking it. It would be nice if I could address the 2nd/3rd/4th bank and boot/replace those so if I screw them up, I can boot into the 1st bank and put the stock back and try again.

I'm sure there are plenty of people here who would pledge money towards repair I know I'd throw $20 to that cause...

 

I'm wondering if there are any "factory authorized" repair centers that could reflash a brick...

[laci102]

I have Pioneer AVIC 900BT device, I live in Hungary in Europe.

 

4.001000 to upgrade to the latest software or not?

 

If you want what's new in 3.0?