Embedded Linux Encounters

A peek in to the world of Embedded Linux and stuff

  • Linux is addictive, I'm hooked!

         Geek@WastingTime>
Showing posts with label porting. Show all posts
Showing posts with label porting. Show all posts

Android Audio

Posted by Vaisakh P S On 10:54 PM 0 comments

Phew... this one was one major headache for me...
It was my first experience in linux and ALSA. So didn't have a single clue about how to configure audio ALSA. But finally I was able to do it.

The first daunting task was to bring up the audio interface for my board (as it was fresh porting of linux on to this hardware). About the audio hardware, the board is having a WM9713L IC which is used to interface Speaker and touch screen to the PXA270 processor. So I added the definition for the same under ' sound/soc/pxa/myboard.c' under my linux source tree and enabled the same in my build configuration.

After doing this, the Codec IC was detected from kernel. I tested it using mplayer which I built using buildroot. But still there was no audio output. So I started to dig into ALSA configuration. There I stumbled in to new useful utility programs:
  • amixer
  • alsamixer
Using these tools and the board schematics (especially the audio routing layout), I was to enable and route the audio with the following commands in my buildroot environment:
amixer set 'Speaker Mixer Aux Playback Swit' on
amixer set 'Speaker Mixer PC Beep Playback ' on
amixer set 'Speaker Mixer PCM Playback Swit' on
amixer set 'Left Speaker Out Mux' 'Speaker'
amixer set 'Out4' 100% on
amixer set 'Speaker' 100% on
amixer set 'PCM' 100%
amixer set 'PC Beep Playback Speaker' 100%
After this mplayer was able play audio files and the sound was clearly audible in Speaker.

Now moving on to Android, the original build tree will not contain the ALSA utils in it. So I modified the local_manifest.xml under .repo directory and added the following:

Along with that in my vendor definition file, I added the following lines (thanks many discussion in Google groups), so that Alsa Utils gets included on to the system image.

HAVE_HTC_AUDIO_DRIVER := false
BOARD_USES_GENERIC_AUDIO := false
BOARD_USES_ALSA_AUDIO := true
BUILD_WITH_ALSA_UTILS := true
Once the build was completed, I booted up Android with the kernel and new system image. After booting, in shell issued the same commands(but this time the name is alsa_amixer), and audio started working in Android too...

After this, my next aim was to automatically route the audio. On further investigation, I found that there needs to be a configuration file(/etc/asound.conf) for doing this. Also in the file, there needs be entries for 'pcm.AndroidPlayback' , 'pcm.AndroidPlayback_Speaker' etc which will be like profiles used by Android for routing Audio.

I tried putting the same "Audio Control" names that I used in alsa_amixer command. But didn't work out. Got stuck again...

I analyzed the output for various options alsa_amixer command. With one particular option - alsa_amixer -contents, I got the names of the controls and used them in asound.conf

# #
# # Mixer devices
# #

ctl.AndroidOut {
type hw
card 0
}

ctl.AndroidIn {
type hw
card 0
}

ctl.AndroidPlayback {
type hw
card 0 # Can replace with drivers name from /proc/asound/cards
}
ctl.AndroidCapture {
type hw
card 0
}

# #
# # Playback devices
# #
pcm.AndroidPlayback {
type hooks
slave.pcm {
type hw
card 0
device 0
}
hooks.0 {
type ctl_elems
hook_args [
{ name 'Speaker Mixer Aux Playback Swit' value on }
{ name 'Speaker Mixer PC Beep Playback ' value on }
{ name 'Speaker Mixer PCM Playback Swit' value on }
{ name 'Left Speaker Out Mux' value 'Speaker' }
{ name 'Out4 Playback Switch' value on }
{ name 'PC Beep Playback Speaker Volume' value 7 }
]
}
}
There you have it... Audio is working like a charm in Android. :)

Hope this helps someone... :)

Screen Shots - Android Ported on to PXA27x

Posted by Vaisakh P S On 10:19 PM 0 comments





Making Android gadget work on PXA270

Posted by Vaisakh P S On 10:33 PM 1 comments

Hi Everyone,

Was busy in some other work (other than Linux), so my Android porting activity got stalled for few months. Now I am back in to it.

Back to the topic, I was able to make Android Gadget and ADB work in my PXA270 board. Here are the changes that needs to made:
  1. Modified drivers/usb/gadget/android.c , to move usb_configuration structure from init data section to bss. Previously this used to create a fatal crash as this configuration is getting added in to linked list which will be later traversed during endpoint configuration setup phase, at which this will show up as a NULL reference.

diff --git a/drivers/usb/gadget/android.c b/drivers/usb/gadget/android.c

index c431131..f14fedf 100644

--- a/drivers/usb/gadget/android.c

+++ b/drivers/usb/gadget/android.c

@@ -113,7 +113,7 @@ static int __init android_bind_config(struct usb_configuration *c)

return adb_function_add(c);

}

-static struct usb_configuration android_config __initdata = {

+static struct usb_configuration android_config = {

.label = "android",

.bind = android_bind_config,

.bConfigurationValue = 1,


  1. Change the USB Endpoint setup array in drivers/usb/gadget/pxa27x_udc.c, to make two sets of Bulk Endpoints(IN and out) available to android gadget driver. (I removed rest of the configurations, just because only I didn't need them)

diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c

index 7cbc78a..037e435 100644

--- a/drivers/usb/gadget/pxa27x_udc.c

+++ b/drivers/usb/gadget/pxa27x_udc.c

@@ -2171,36 +2171,19 @@ static struct pxa_udc memory = {

USB_EP_CTRL,

USB_EP_OUT_BULK(1),

USB_EP_IN_BULK(2),

- USB_EP_IN_ISO(3),

- USB_EP_OUT_ISO(4),

- USB_EP_IN_INT(5),

+ USB_EP_OUT_BULK(3),

+ USB_EP_IN_BULK(4),

+

},

.pxa_ep = {

PXA_EP_CTRL,

/* Endpoints for gadget zero */

- PXA_EP_OUT_BULK(1, 1, 3, 0, 0),

- PXA_EP_IN_BULK(2, 2, 3, 0, 0),

+ PXA_EP_OUT_BULK(1, 1, 1, 0, 0),

+ PXA_EP_IN_BULK(2, 2, 1, 0, 0),

/* Endpoints for ether gadget, file storage gadget */

- PXA_EP_OUT_BULK(3, 1, 1, 0, 0),

- PXA_EP_IN_BULK(4, 2, 1, 0, 0),

- PXA_EP_IN_ISO(5, 3, 1, 0, 0),

- PXA_EP_OUT_ISO(6, 4, 1, 0, 0),

- PXA_EP_IN_INT(7, 5, 1, 0, 0),

- /* Endpoints for RNDIS, serial */

- PXA_EP_OUT_BULK(8, 1, 2, 0, 0),

- PXA_EP_IN_BULK(9, 2, 2, 0, 0),

- PXA_EP_IN_INT(10, 5, 2, 0, 0),

- /*

- * All the following endpoints are only for completion. They

- * won't never work, as multiple interfaces are really broken on

- * the pxa.

- */

- PXA_EP_OUT_BULK(11, 1, 2, 1, 0),

- PXA_EP_IN_BULK(12, 2, 2, 1, 0),

- /* Endpoint for CDC Ether */

- PXA_EP_OUT_BULK(13, 1, 1, 1, 1),

- PXA_EP_IN_BULK(14, 2, 1, 1, 1),

+ PXA_EP_OUT_BULK(3, 3, 1, 0, 0),

+ PXA_EP_IN_BULK(4, 4, 1, 0, 0),

}

};


diff --git a/drivers/usb/gadget/pxa27x_udc.h b/drivers/usb/gadget/pxa27x_udc.h

index 1d1b793..7a42932 100644

--- a/drivers/usb/gadget/pxa27x_udc.h

+++ b/drivers/usb/gadget/pxa27x_udc.h

@@ -409,8 +409,8 @@ struct udc_stats {

unsigned long irqs_reconfig;

};

-#define NR_USB_ENDPOINTS (1 + 5) /* ep0 + ep1in-bulk + .. + ep3in-iso */

-#define NR_PXA_ENDPOINTS (1 + 14) /* ep0 + epA + epB + .. + epX */

+#define NR_USB_ENDPOINTS (1 + 4) /* ep0 + ep1in-bulk + .. + ep3in-iso */

+#define NR_PXA_ENDPOINTS (1 + 4) /* ep0 + epA + epB + .. + epX */


  1. After these two steps, your PXA gadget will be recognized by PC. Now change the INF file in Android Windows USB Driver (available along with SDK), to recognize your device.
  2. Now I am facing some crashes because of NULL reference in Mass Storage profile of android. For recognizing in Windows, both ADB and Storage profile of Android gadget needs to be active. For development in Linux, you need not have Storage. That can be commented off in android.c
  3. Make sure that you have "UNIX PTY Support" enabled in kernel, as ADB client and server makes use of those devices for process creation and some other operations.

Linux Kernel Booting FEP - Frequently Encountered Problems

Posted by Vaisakh P S On 8:06 PM 0 comments

During booting of kernel, these are the possible error messages that may show. Here are the reasons for the same:

Kernel completely up but console is not shown
  • This could have been because of various reasons. Either the console device specified in boot arguments would be different
  • There might not be a device instance corresponding to the specified device under /dev directory.

Init not found or Failure in executing init
  • Init program might not be given execution privileges or root might not be the owner of the init executable.
  • If BusyBox is not compiled as a static binary, then failure in loading the dynamic libraries can also result this error.


Failed in mounting root file system
  • The device such as MMC card or USB will require certain amount time to be made accessible or mounted. So use the 'rootdelay' boot argument to introduce a delay before kernel tries to mount the file system.
  • If the file system is corrupted then also this error would come up. So it is advisable to maintain a back up file system image to re-flash your storage if this happens.
  • Periodically run a fsck command on the file systems used including root file system.

Porting Android

Posted by Vaisakh P S On 7:54 PM 1 comments

Android build system by default generates few YAFF2 File system Images, which can be flashed on devices running in NAND flash. Since the platform which I was working on did not have a NAND flash on board. The images had be made available to Kernel in some other storage devices like NOR flash, SDCARD or USB Memory Stick.


There will be three out put images of the build process:
  • Root - A small image in order kilo bytes, with basic utilities and init script to bring rest of the system up.
  • System - Contains the Android specific programs and related libraries. The size will be some where around 40 to 50 Mega Bytes (for default configuration) depending on the build configuration.
  • Data - Will be a blank file system initially, but as system boots up, relevant information will added.
Like every other Linux Root file system image, there is an init script, (format is different from standard init script). Here comment out of the portion of script which mounts the yaffs2 file system like this:
#mount yaffs2 mtd@system /system
#mount yaffs2 mtd@system /system ro remount
#mount yaffs2 mtd@userdata /data nosuid nodev

For bringing up the required file system, an SDCARD base storage system was decided. The sdcard was partitioned in to four ext2 partitions. Here is the partition layout
Partition #1 : Root file system generated from BuildRoot
Partition #2 : Root file system generated from Android
Partition #3 : System partitions generated from Android
Partition #4 : Data partition to be used to Android.

The Linux system was be booted up with Partition#1 as root. Then Partitions 2, 3 and 4 are mounted like this
mount /dev/mmcblk0p2 /media/mmc
mount /dev/mmcblk0p3 /media/mmc/system
mount /dev/mmcblk0p4 /media/mmc/data
Using the 'chroot' command the root will be changed to Partition#2 hence initiating startup of Android:
chroot /media/mmc /init
NOTE

  • Ensure that the system and data directories are given global read, write and execute permission.
  • To interface touch screen with Android, make use modifications in Android Input System code to make use of the calibration corrections obtained using TsLib. (Refer previous post)

Boot loader Porting

Posted by Vaisakh P S On 6:13 AM 0 comments

In comparison to Windows CE, in Linux, we have many choices of boot loaders available today. U-Boot [V] is one of most commonly used boot loader in development phase, as it provides with a wide array of features which a developer can make use of. Before starting off with kernel porting these are the features that needs to bring up in U-boot.

· Debug Consoles – Preferably a serial UART. In u-boot configuration header, the stdin, stdout and stderr need to be specified. In case of our platform, the debug console has been directed to FFUART. Also baud rate of the serial UART connection needs to be configured.

· Ethernet connection – In initial stages of porting, the kernel image can be transferred over Ethernet instead of flashing on to a ROM. In case of our platform, Ethernet connectivity is provided through the debug card. Enable the use of SMC911X driver in configuration header and set the associated configurations such as Ethernet MAC, Base address, 16-bit or 32-bit Bus mode etc too.

· Initialization of Memory System – Both boot loader and operating system will be executing in RAM. So RAM needs to initialized to proper timings and U-Boot should be made aware of available RAM though the configuration header.

· TFTP Server Settings – The IP address of TFTP server along needs to be specified to fetch the kernel image.

· Kernel Boot arguments – All information of hardware like available RAM, MTD partitions etc are passed on to the kernel as ATAG list. Some of the major arguments that needs to be passed on the kernel are:

◦ Kernel default console

◦ Root file system path

◦ Initrd to use (optional)

◦ Display

◦ Init Path

The purpose of each of these arguments will be explained in subsequent sections.

Notes

· While loading OS Image and other File system images over Ethernet or any other medium, pay attention to the load address, make sure that they are not over lapping.

· It is advisable to make the root file system as Read-only while mounting or in Bootargs to avoid corruption. This will enable bringing up the system with a basic environment.

Subscribe to: Posts (Atom)