Anonnie

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. 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. 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 tel

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.

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.

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

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.

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.googl

If I could get a stack dump, I can do a rundown on each of the PIDs and their associated TIDs to see what is tied up in the context. From there we'll know the exact process and thread that is holding any of the ports open, alter the loading order and allow ourselves to load the dependencies to tie it up. Understand that I just picked one of these up a few days ago, so I'm not as familiar as others with the hardware. If it has a serial port (that we can tap) we can try to enable kernel debugging and from there the sky is the limit. I can do pretty much anything with it and trap every Psxxx

My reason was because I have a Z130, and would rather write a UI replacement and make it open source for people to use. Mainly because I believe MioPocket is not open, so you are limited to the scripting and if it crashes, you are out of luck. Hopefully, this way we can also take advantage of the android protocols (communicating to CE) as well as some of the open source apps that work great and would be excellent for the head unit. Has anyone gotten a kernel debugger running to pick up any loose RETAILMSG or DEBUGMSG (in case pioneer left any debug code in there)? Many drivers tend to spi

Just to confirm... Right now one of the problems related to running homebrew executables, is that any of them linked to coredll.dll or ceshell.dll will not work?