2004 to 2020 Mazda 3 Forum and Mazdaspeed 3 Forums banner

The Infotainment Project

3 reading
4.2M views 6.6K replies 1.1K participants last post by  bsliv  
Thanks!

For anyone interested in development: I used the Freescale "ltib" stuff as the starting point:



I've never used ltib for building applications, but I assume it's pretty straightforward. I think it's RPM based - you need to create a ".spec" for your package. Sorry I don't know all of the details - I don't know much about building RPMs.

With this ltib-based SDK, you build a kernel and root filesystem (apps/etc). It's obviously not targeted at the CMU (it's for Freescale iMX6 development board), but it's a starting point. I think that writing applications using the SDK should result in runnable binaries.

As I said, it was really difficult building a kernel module that's compatible with the CMU kernel. As a kernel developer, I still really didn't think about all of the issues involved. For example, one of the first things the "aufs" driver does is index a bitmap using the kernel global variable "current->pid" (the current process's pid).

"current" is a pointer to a "struct task_struct". The size of a task_struct, as well as the offsets to different elements (like "pid") varies based on kernel config. So, the default config (from Freescale) had a vastly different "task_struct" - I had to (via trial and error and hexdumps of the CMU's "current" struct) figure out which config options would result in a "task_struct" that's exactly 0x3a8 bytes long with various elements at very specific offsets.

There are several other structures used by "aufs" that had similar issues. I'm not sure that I've found them all (that's why I said there's a lot more testing to be done).

On top of that, "aufs" requires some functions/variables to be "exported" from the kernel that it's built with. Obviously, we can't do that on the CMU kernel. So, I had to figure out the addresses for all of these things and make "wrappers" to directly access the CMU kernel functions.


It's a lot of work, but very interesting :) Hopefully, there'll be some good results from this work.

- Paulb

Why not just copy the firmware binaries and libraries on a sabre board installed with the same linux kernel version ?
 
Thanks!

For anyone interested in development: I used the Freescale "ltib" stuff as the starting point:


I've never used ltib for building applications, but I assume it's pretty straightforward. I think it's RPM based - you need to create a ".spec" for your package. Sorry I don't know all of the details - I don't know much about building RPMs.

With this ltib-based SDK, you build a kernel and root filesystem (apps/etc). It's obviously not targeted at the CMU (it's for Freescale iMX6 development board), but it's a starting point. I think that writing applications using the SDK should result in runnable binaries.

As I said, it was really difficult building a kernel module that's compatible with the CMU kernel. As a kernel developer, I still really didn't think about all of the issues involved. For example, one of the first things the "aufs" driver does is index a bitmap using the kernel global variable "current->pid" (the current process's pid).

"current" is a pointer to a "struct task_struct". The size of a task_struct, as well as the offsets to different elements (like "pid") varies based on kernel config. So, the default config (from Freescale) had a vastly different "task_struct" - I had to (via trial and error and hexdumps of the CMU's "current" struct) figure out which config options would result in a "task_struct" that's exactly 0x3a8 bytes long with various elements at very specific offsets.

There are several other structures used by "aufs" that had similar issues. I'm not sure that I've found them all (that's why I said there's a lot more testing to be done).

On top of that, "aufs" requires some functions/variables to be "exported" from the kernel that it's built with. Obviously, we can't do that on the CMU kernel. So, I had to figure out the addresses for all of these things and make "wrappers" to directly access the CMU kernel functions.


It's a lot of work, but very interesting :) Hopefully, there'll be some good results from this work.

- Paulb
why not use the default linux image of a freescale board and just copy the binaries ? Assuming the same kernel version and the same set of libraries are used... This should work right ?
 
There is no config file yet. But when you are playing the file with gstreamer you can use the sink mfw_audio_pp in the audio pipeline similar to this:

gst-launch playbin2 uri=file://$FILE audio-sink="mfw_audio_pp enable=true eqmode=2 attenuation=-40 ! alsasink"

this will work for an mp3 file. It will apply the "bass booster" equalizer mode, values come from 0 (disabled) up to 22 (user preset). If you want you can only use the eqmode parameter as it has already a default value for attenuation in each preset.

There is this file made by freescale (the one that made the core chipset inside the cmu) with some guidance, but no all that appears in this file applies to our cars. Our car uses gstreamer 0.10 which has some limitations. Try to avoid the first parts as this is for a linux version later that ours
This is good news. Is this possible to execute on a Sabre Lite board ?