Rather than hijacking the General forum's "Official 3.0 Status" topic I figured forking it to a new one was in order... It's sort of a rant, so feel free to ignore it. Or please provide any insightful comments and maybe we can get a Todo list created in the Wiki and start checking items off it...

The on-board processor is ARM if i'm not mistaken running at 500mhz, I wouldn't know much on the programming aspect of it, but I am sure there is a reason why it hasn't been done already so before I jump into conclusions which I have, I am going to go check and read up on some of the attempts made already to get the AVIC into a new system altogether, I am sure it can be easy for it to run linux, the problem will lay to make everything work including XM, buttons, touch screen etc.

 

Should of just made a car computer...darn it.

You're correct, the processor is a 600 MHz System on a Chip (SoC) with an ARM core. What's really keeping us from going full carputer at the moment is we don't have an intimate understanding of the way the core communicates with the different parts of the audio board like the uCOM or IP Bus. Without that understanding, you can't switch audio sources, change the master volume of the AV board (just the Navi input to the e-Volume chip) and other audio tasks. What really needs to happen first is a physical "snoop" of the UART between the Navi and AV board so we can see what commands get sent to the uCOM for these events (i.e. "change audio source to FM", "tune station X", "send command to XM radio over IP Bus", etc). I had planned to tear down my dev system to do this over my holiday, but travel and 3.01 got in the way and I don't have a protocol/logic analyzer handy at home.

Then there's the problem of the low-level software support and lack of a board support package for the development environment. I'm assuming we'd need to modify or re-write eBoot to set up whatever informational data structures Linux or another alternative OS expects to be present when the "BIOS" (eBoot) hands off execution to it. Without some of those data structures present where the Linux kernel expects them to be, it won't know how much memory it has, what the memory map looks like, or what devices it has available. I would hope eBoot already does this for the WinCE kernel, but a lack of experience with WinCE makes me list it as a requirement anyway. Another option would be using HaRET to bootstrap Linux after WinCE has already booted (see handhelds.org for some discussion on how this was done for some PDAs). Then there's actual BSP support. Last time I checked for Centrality/SiRF Titan support in the Linux kernel the machine ID had been defined, but I couldn't find any actual code for bootstrapping the system in the usual locations. QNX has a board support package already defined for the Titan development kit, so it's a little ways closer to being able to run on the AVIC-F/X than Linux in that area. Not to say we couldn't port some of that BSP over to Linux, as long as the QNX license it's released under is compatible (IANAL).

As you can see, it's a lot easier to work within the framework Pioneer's already given us (WinCE) at the moment, since some of the hardware tasks are already implemented in their DLLs under the APL folder (we just have to figure out their APIs through code inspection).

Otherwise the short list of tasks is:

• [*:3j1pg8wd]Create a board support package
  [*:3j1pg8wd]Add Linux bootloader support by either:
  
  • [*:3j1pg8wd]Script HaRET to bootstrap Linux kernel -OR-
    [*:3j1pg8wd]Modify/rewrite eBoot to support Linux

[*:3j1pg8wd]Low-level tasks:

• [*:3j1pg8wd]Add machine-type and arch support to the Linux kernel for the Titan
  [*:3j1pg8wd]Implement kernel modules to support the Titan character devices (TTY, etc)
  [*:3j1pg8wd]Implement kernel modules to support the Titan block devices (NAND Flash, SDIO, etc)
  [*:3j1pg8wd]Implement kernel modules to support the Titan audio device (AC97)
  [*:3j1pg8wd]Implement kernel modules to support the Titan UART controller
  [*:3j1pg8wd]Implement kernel modules to support the Titan USB controller
  [*:3j1pg8wd]Implement kernel modules to support the Titan I2C controller

[*:3j1pg8wd]GUI tasks:

• [*:3j1pg8wd]Implement an X-windows screen driver for the SiRF Titan framebuffer device
  [*:3j1pg8wd]Implement an X-windows input driver for the touchscreen device

Simple, right?

Huh?

Do you know of any decent navigation software that runs on Linux, and can be actually licensed to run on AVIC?

Developing a better main menu app and integrating in more generic iGO 8.3 (or Navigon etc.) and better media player(s) would be easier and more productive, IMHO.

Developing a better main menu app and integrating in more generic iGO 8.3 (or Navigon etc.) and better media player(s) would be easier and more productive, IMHO.

No arguments there, I'd prefer to just replace the majority of what's inside the "My Flash Disk/APL/" folder. Hell, half the reason I'm hacking on my system is the screwed up UI (I have fingers that are taller than 32 pixels, Pioneer!). I'm new to dis-assembly, debug and trace on ARM cores (most of my time is spent in x86/x86-64) so that's where my learning curve's being spent right now (thank god for carver and the XDA Developer Forum). I'm using the work MioPocket's done on my iPaq 310 as a baseline, trying to get the ActiveSync USB mode working so it will talk to Dev Studio for further process debug.

I guess my first post to this topic was meant to illustrate just how much of an undertaking porting Linux to the AVIC-F/X would be, in answer to folks asking the question on "why not just port Linux?".

No arguments there, I'd prefer to just replace the majority of what's inside the "My Flash Disk/APL/" folder. Hell, half the reason I'm hacking on my system is the screwed up UI (I have fingers that are taller than 32 pixels, Pioneer!). I'm new to dis-assembly, debug and trace on ARM cores (most of my time is spent in x86/x86-64) so that's where my learning curve's being spent right now (thank god for carver and the XDA Developer Forum). I'm using the work MioPocket's done on my iPaq 310 as a baseline, trying to get the ActiveSync USB mode working so it will talk to Dev Studio for further process debug.

 

I guess my first post to this topic was meant to illustrate just how much of an undertaking porting Linux to the AVIC-F/X would be, in answer to folks asking the question on "why not just port Linux?".

Right. Quite a bit of the issues would be resolved if we could understand the format for RES files completely and rewrite the UI outside of iGO (make buttons as big as you want them).

Getting Linux on this thing is possible but far less efficient than hacking something working with existing plumbing...