yashsingh1/xdaforums huggingface dataset:
[Eee Pad Transformer Android Development] braernoch:
I've given up trying to compile the sound support as modules. After a week of un-resolvable module dependency loops that prevent them from being depmodded and mapped (and therefore unable to be modprobed or insmodded), I've gone back to the standard kernel as configured by Roach, lilstevie, and others.

The Ubuntu kernel is just a tweaked version of the Prime! Android kernel in which the sound works perfectly. So to see what's changed and is going wrong, I copied out the /sys/kernel/debug folder from Android while it was running, then booted Ubuntu and did the same. I pulled what seemed to be the pertinent registry files from that folder and from the "asoc" sub-folder of each instance and diffed them. The source and result are compressed in the attached "compare.tar.gz" folder. As you can see, the registers are set differently between the instances, and I can't yet tell why. I'll dive into this now, but maybe you'll actually know what you're doing.

Let me know what you come up with.
[Eee Pad Transformer Android Development] Jhinta:
I have compiled the cros kernel for asus bootloader but how to boot ubuntu from mmc.

I can only see /dev/mmcblk0

Verstuurd van mijn HTC Desire HD met Tapatalk
[Eee Pad Transformer Android Development] 3n1g:
I've seen so many ways of installing ubuntu (and with different distros as well) that now I really don't know about wich one is best/latest/more stable to use... -_-''
[Eee Pad Transformer Android Development] rdnetto:
This thread is for development work only. Please ask in the Q&A thread.

You pointed out something that I'd missed - the kernels are pretty much identical, so the problem can't be in there. Since the state of the registers alone doesn't tell us much by itself (certain sequences of writes correspond to certain operations), I went one step further and modified the kernels (both Linux and Android) to output logging information whenever they changed a register. I haven't had time to take a close look at it, but from a superficial comparison it looks like ALSA/Pulseaudio is performing a lot of additional writes, as well as some subtler differences.

I'll post again once I've gone through it in detail.
[Eee Pad Transformer Android Development] braernoch:
This ties in with what I've been looking at the last week.

static void lineout_work_queue(struct work_struct *work)
{
msleep(300);

if (gpio_get_value(LINEOUT_GPIO) == 0){
printk("LINEOUT: LineOut inserted\n");
lineout_alive = true;
snd_soc_write(global_codec, 0x10, 0x0000); /* MIXSPK Disable*/
snd_soc_write(global_codec, 0x11, 0x0000); /* SPK Disable*/
snd_soc_write(global_codec, 0x76, 0x0000); /* Mute the speaker */

}else if(gpio_get_value(LINEOUT_GPIO)){
printk("LINEOUT: LineOut removed\n");
lineout_alive = false;
snd_soc_write(global_codec, 0x10, 0x0003); /* MIXSPK Enable*/
if(PRJ_ID == 101){
snd_soc_write(global_codec, 0x3E, audio_params[EP101].analog_speaker_volume | 0x80); /* SPKL Volume: 4dB*/
snd_soc_write(global_codec, 0x3F, audio_params[EP101].analog_speaker_volume | 0x80); /* SPKR Volume: 4dB*/
}else if(PRJ_ID == 102){
snd_soc_write(global_codec, 0x3E, audio_params[EP102].analog_speaker_volume | 0x80); /* SPKL Volume: 0dB*/
snd_soc_write(global_codec, 0x3F,audio_params[EP102].analog_speaker_volume | 0x80); /* SPKR Volume: 0dB*/
}
snd_soc_write(global_codec, 0x11, 0x0003); /* SPK Enable*/
snd_soc_write(global_codec, 0x76, 0x0033); /* GPIO3 configure: EN_SPK*/
}

}

That code is from $source/sound/soc/tegra/headset.c. It specifies registers 10h, 11h, and 76h as the muting and unmuting registers for the speakers. I initially assumed that the jack detection function was not working properly, but reading the value of the switch-state device h2w shows a correct change from 0 to 2 as I connect and disconnect my headphones. I don't know how to read the value of the "jack_alive" or "lineout_alive" symbols at runtime to see if the code recognizes the h2w state change.

Looking at android.txt and linux.txt, both toggle 10h and 11h between 0x00 and 0x03. Major difference: Android toggles 76h between 0x00 and 0x33, but Linux sets it to 0x00 and keeps it there the whole time.

Also of note: using the command "alsamixer", you can mute/unmute individual controls. If you mute the headphone output here, it completely mutes the PulseAudio system tray icon - regardless of speaker output status. This supports the theory that the problem is Ubuntu-specific (PulseAudio) rather than kernel-based. For some reason, PulseAudio regards the headphones as the only or primary sound device and does not configure the Speaker GPIO (76h).

I'll keep digging.
[Eee Pad Transformer Android Development] braernoch:
@rdnetto Another difference between Android and Linux: Android generates an etc/asound.conf to configure three primary pcm devices from Alsa for use by the audio software (music, voice, and aux). I don't know what software in Android is actually interpreting this, but Linux doesn't have this file, and Pulse doesn't respond to this configuration.

I tried bypassing Pulse completely using the Alsa (aplay -l && aplay -D hw:0,0 <.wav file>). Even specifying the speaker device of the tegra card (hw:0,0) routes output through headphones only. Devices :0,1 and :0,2 (mic and lineout) do not work with speakers either.

It now appears as though, for whatever reason, the initial configuration of the tegra card and its devices is flawed. I believe this takes place at the kernel level in function tegra_audio_route() (called by tegra_play_route_put() from structure tegra_play_route_control) in $source/sound/soc/tegra/tegra_soc_controls.c. In this hypothesis, when device 0,0 is passed to this function as play_device_new, it evaluates to true only for the bitwise AND operation against Headphone, not Speaker or both.

This is baffling because, as we both stated, the kernel's sound files in our source are straight from Asus (and working in Android). As always, I'll keep looking. Any thoughts from your side?

EDIT: This reference might help some - http://rudd-o.com/linux-and-free-software/how-pulseaudio-works
[Eee Pad Transformer Android Development] rdnetto:
I've done some work on comparing the log files (thank god for Kdiff) and noting the differences between the two. Of particular interest is GPIO 3, which is enabled for short periods during the initialization under Android. Given that it's disabled under normal use, I assume it has some relevance, though I don't know how much. Another point of note is that the LINEOUT registers may be red herrings - there are some separate registers for the speakers under power management.

Also notable is that the codec only has the speakers/headphones enabled while music is playing - the rest of the time they're powered down (presumably to save power), which means any comparison of the registers has to be done while playing music.

The attached logs also include dumps of the stack, which may be useful in determining which function is writing to a register.

I think you might be on to something. Under Android, speakers are device 4 and headphones are device 1 (but for some reason headphones trigger both 'routing to Headphone output' and 'routing to unknown output' messages from printk). However, under Linux this function isn't called at all. This may have something to do with the fact audio_codec_ioctl() isn't called either (under Android it's used to turn the codec on and off shortly before and after playing music. dump_stack() indicates that the call originates with sys_ioctl(), so I presume ALSA is responsible. Exactly why it calls it is less clear - it may be necessary to get a copy of the Android source code to see how it's version of ALSA works.
[Eee Pad Transformer Android Development] braernoch:
Great minds think alike. I was looking at audio_codec_ioctl() last night and woke up to this comment. =) Thank you for the logs and commentary! I didn't know about dump_stack(), so I seeded the important functions and variables with printk() messages and sorted through dmesg after recompile/booting and playing music with and without headphones. If I find that any of those add something new to what you've done, I'll come back and post them here.

I see three main directions we can go with this (three uncalled functions in Linux that should toggle 76h - GPIO 3):

1) audio_codec_ioctl() from wm8903.c

------- AFAICT, should be triggered from userspace and would route the audio correctly at playback when the sound file is chosen.

------- Called from ioctl() in AudioFlinger in Android. No code to call it from alsa-lib in Linux. Confirmed working speakers when forced.

2) tegra_audio_route() from tegra_soc_controls.c

------- AFAICT, would allow us to correctly set up the audio route for the primary device at its creation.

------- If this isn't getting called, how is sound from headphones even working?

------- Ultimately from ALSA kcontrol, "tegra_play_route_control."

------- Must see why Android calls this and Linux doesn't. <--- See attached debug files.

3) lineout_work_queue() from headset.c

------- AFAICT, if working this would provide a constant, dynamic mute/unmute of the speakers with insertion and removal of headphones.

------- Of the three gpios monitored in this file (jack, hook, and lineout), only this one establishes the speaker output enable/disable. Jack detection just enables/disables headphone audio. Because of this, I feel like this should be working and not just a red herring. Although it is alternately possible that instead of requiring speaker mute through this function with headphone insertion, the system could instead switch to a separate audio device whose settings also reconfigure the registers (spdif?). In which case this function might only trigger on HDMI connection or some such.

------- printk() shows lineout_alive is always false in my testing, even with jack_alive == true.

------- This is registered in the kernel work queue through INIT_WORK(). This may not be working. Conversely, the jack gpio detection work is registered with the workqueue a different way. Consult this document for the difference.

------- Does Android ever call this? If not, how else are speakers muted for jack connection?

Let me know if I'm missing anything.
[Eee Pad Transformer Android Development] braernoch:
audio_codec_ioctl Notes

**UPDATE**: Some interesting notes here. The 'pure' ALSA drivers from alsa-project.org do not have audio_codec_ioctl() in wm8903.c, nor do they include any tegra_soc_controls.c file. Searches show Nvidia devs with patches for these files. Further, the ALSA drivers in our kernel report version 1.0.23, but 'pure' ALSA drivers of that version don't include *any* tegra soc files beyond the simple codec. I believe Nvidia customized an ALSA 1.0.23 driver (or early 1.0.24) specifically for use with Android's AudioFlinger libraries as implemented by Asus or Nvidia itself. Meanwhile ALSA moved on, integrating ALSA-standardized tegra support for further driver releases.

As stated before, alsa-lib is the package that handles ioctl() calls in Linux userpsace. Given ioctl(fd, cmd, arg), _all_ "cmd"s in the alsa library are predefined as "SNDRV_<class>_IOCTL_<function>". These are all listed in the attached file, and they follow a very different format than the one we know to work.

It is now my belief that instead of forcing Linux to send the calls the kernel recognizes, it might be easier and will be more forward-compatible to restructure the kernel ALSA drivers to expect the calls userspace-based alsa-lib sends.

I'll keep this and the previous post updated as I learn more.
[Eee Pad Transformer Android Development] rdnetto:
I've written a simple program that will let us perform calls to audio_codec_ioctl() from the terminal. It should be useful for testing. Arguments can be either the names of constants or decimal values.

Example usage: ./ioctl /dev/WM8903 AUDIO_DUMP 0

The OUTPUT_POWER_CONTROL section of audio_codec_ioctl() depends on the state of need_spk, which is set by tegra_audio_route(). i.e. tegra_audio_route() is at the centre of everything.

In tegra_play_route_put(), the device fields are always zero. Exactly why this is the case will require further inspection.

I suspect the headphones are working because that's the default configuration.

Given that lineout_alive is always false under Android, I believe it is for HDMI. It may be relevant that a comment in lineout_work_queue() refers to GPIO3 as SPK_EN.

I've only just read this post so I haven't had time to go over it in detail, but I came across some tegra UCM files earlier. Not sure if they're relevant or not though.
[Eee Pad Transformer Android Development] braernoch:
**NOTE: Sound is not "fixed" for the TF101 yet. This is for debug purposes only. **

We have success on speaker output with register 76h toggled by use of your program. I eliminated all references to "need_spk" from kernel sources some time ago, so as shown below, the commands executed successfully.

root@braer-tf101:/home/braer/ioctl# ./ioctl /dev/WM8903 OUTPUT_POWER_CONTROL 1
ioctl(/dev/WM8903, 1074067203 (0x4004F703), 1 (0x1));
ERROR: 0 Success
root@braer-tf101:/home/braer/ioctl# dmesg
---
[12331.109976] DEBUG: audio_codec_ioctl
[12331.110013] AUDIO_CODEC: Power On
---
[12818.500534] DEBUG: audio_codec_ioctl
[12818.500570] AUDIO_CODEC: AUDIO_DUMP
[12818.501523] Read 0X10 = 0X0003
[12818.501545] Read 0X11 = 0X0003
[12818.504029] Read 0X76 = 0X0033

In addition to setting the registers, we must also use command "alsamixer" and unmute (by pressing "m"):

-Left Speaker Mixer DACL

-Right Speaker Mixer DACR

Then "aplay -D hw:0,0 <file.wav>" makes the silent speakers sing.
[Eee Pad Transformer Android Development] rdnetto:
Confirmed. I think it would be trivial to modify insert_headset() and remove_headset() to toggle the registers in question and include a call to audio_codec_ioctl in the initialization sequence, though you're probably right that using a 'clean' version of ALSA would be more elegant. I think that support for audio over HDMI would be easier to achieve with the kernel as is since that likely involves more than just the WM8903, but given that we have neither video over HDMI nor hardware acceleration working yet, it's probably not relevant.

If it is in fact relatively easy to copy in a clean copy of ALSA, then we should just do that. But if that's not the case, I'd much rather just clean up the current workaround a bit (so that it uses jack detection) and release it.

Nice pick-up. Do you have any idea how to do that? I tried to 'install' a clean copy of ALSA 1.0.0.23 into the kernel using setup-alsa-kernel, but building crashes with:

make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
[Eee Pad Transformer Android Development] braernoch:
It will not be easy. Ultimately, I would like to find 'some' more elegant solution in order to preserve the DAPM structure and minimize power usage. Forcing POWER_MANAGEMENT registers 10h and 11h will work for immediate usability but may cost on battery life.

But, "Done is better than perfect." I say go for it. Let me know if you need anything.

I started "making" with the latest alsa driver kernel source, and - lo! - it has no support for ventana board. It turns out all TF101 ALSA drivers were indeed written by Nvidia (based on Wolfson Micro. code). I'll have to stare at Nvidia's and ALSA's soc/tegra files and piece together a working driver. If I ever finish, you'll be the first to know.
[Eee Pad Transformer Android Development] rdnetto:
OK, I've gotten sound working. Just apply the patch with 'patch -p1 -i sound.patch' to a clean copy of the kernel and compile.

@lilstevie, if you could update the repo with this I'd appreciate it.

KNOWN BUGS:

-a 'click' sound may be heard when the codec turns on/off

-any mic plugged into the jack will probably be ignored (I didn't have the hardware to test this)
[Eee Pad Transformer Android Development] rdnetto:
Trying to get Kexec working

The git includes a patch for the kernel which can be applied to ours with a little work. I have CONFIG_KEXEC=y, CONFIG_ATAGS_PROC=y, CONFIG_SMP=n, CONFIG_ARM_THUMB=y, CONFIG_ARM_THUMBEE=n,

CONFIG_THUMB2_KERNEL=n, CONFIG_PM=n (this one requires a little work in order to compile), but the system still crashes when trying to execute the new kernel. Any ideas?

Alternatively, does anyone know why it freezes when shutting down? (I think the mmc or fm drivers are to blame.)
[Eee Pad Transformer Android Development] belzebub40k:
If we get this working this will be a killing feature. How do you start the load and start the kernel via kexec?
[Eee Pad Transformer Android Development] lilstevie:
disable symmetric multiprocessing to get kexec? no, not happening
[Eee Pad Transformer Android Development] belzebub40k:
I think the SMP only needs to be disabled for the kernel which plays the bootloader and the kernels which are loaded by kexec can have it (hopefully) enabled. :confused:
[Eee Pad Transformer Android Development] rdnetto:
kexec -l zimage --initrd=initrd.img --append="$(cat /proc/cmdline)"

kexec -e

Technically, you should switch to runlevel 1 with telinit, unmount all filesystems and remount root as read only first, but that's the important bit. Also 'sudo telinit 1' causes it to freeze.

That's the idea. Even if we have to disable SMP to get kexec, it means we can still use a separate build of the kernel for the bootloader and get multiboot that way. (This is what the AC100 guys did.)

It won't be as convenient as having kexec available from within Ubuntu, but it'll still achieve the main objective (multiboot).
[Eee Pad Transformer Android Development] Jhinta:
what do you think http://comments.gmane.org/gmane.linux.ports.arm.kernel/75711
[Eee Pad Transformer Android Development] rdnetto:
The code in the first patch doesn't match our kernel. I tried manually changing it to do the same thing, but it doesn't seem to be working. On the plus side, I did see the TF successfully reboot (normally, not kexec) without freezing before, but I can't remember which version of the code achieved that, and it could have just been a fluke. On the other hand, I seem to be having some intermittent issues hitting the max no. of child processes (the error is 'bash: fork: retry: No child processes'). Not sure if this is due to the changes I've made or something else.

There's a line in proc-v7.S:cpu_v7_proc_fin commented out - does anyone know what it does?

I also found an idea for using kexec with SMP enabled, but that's probably getting ahead of ourselves.

There's a ton of stuff out there if you google 'armv7 kexec' - hopefully some of it is relevant.

Resources on ARM Assembly:

http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf

http://simplemachines.it/doc/arm_inst.pdf
[Eee Pad Transformer Android Development] nuovodna:
CrOS Kernel

Hi, what is the situation of CrOS Kernel?? I'd like to install Plasma Active on EEE Pad but without hw acceleration it's quite unusable. Any chance to get a fully working CrOS kernel?

thanks in advance
[Eee Pad Transformer Android Development] Jhinta:
Use uboot or tf bootloader with rootfs on sd change the abootimg cfg to mmcblk1p1 or p2 for partition 2 ans so on

Verstuurd van mijn Transformer TF101 met Tapatalk
[Eee Pad Transformer Android Development] ssciberras:
Finally managed to get ubuntu booting from an image file on the eMMC:

http://xdaforums.com/showthread.php?t=1537566

Still some issues, need to update ernel to the last one with everything working, but I used lilstevie's oLife kernel for now.

This means anyone, even sbk2 can boot into ubuntu, as I am currently doing. The image file allows for less risk as I see it.

However, I understand that hw acceleration and the CrOS kernel would not fit in bootloader as they are too big... Am I correct?
[Eee Pad Transformer Android Development] Jhinta:
Incorrect kernel only is about 3,1 mb its the initrd provided that is big just change the kernel and your oke

Verstuurd van mijn Transformer TF101 met Tapatalk
[Eee Pad Transformer Android Development] ssciberras:
as per prvious post, I have installed ubuntu using a loop image on the emmc. Wors nicely for most things, except that I really need to update kernel to get bluetooth etc working.

My main issue is that of course binaries for the x86 architecture will not work. I am trying to get some wor thru qemu, but it is throwing segmentation faults each time. I would appreciate if anyone could replicate this issue.

I am installing qemu-kvm, qemu-user, and getting the x86 libraries from two sources: the test libraries from qemu website ( http://wiki.qemu.org/Testing ) and from another ubuntu machine.

each time I try: qemu-i386 path to 386/bin/ls, it first complains that ld-linux.so.2 is not present. If i try qemu-i386 ld-linux.so.2 it faults.

Am not sure if qemu-i386 on ARM ubuntu is broken, or if I have a problem.

I hear that ubuntu 12.04 will be easier on ARM builds, what would the differences be?
[Eee Pad Transformer Android Development] belzebub40k:
Use the the crosscompiler from codesourcery

This script will download and install the crosstoolchain

wget http://dev.shyd.de/dockstar/setup_codesourcery.sh
chmod +x setup_codesourcery.sh
./setup_codesourcery.sh

After that execute the following command which will set the necessary variables for the compiler

codesourcery-arm-2009q3.sh

Now you can proceed with the build process as you whould do it for a x86/amd64 machine.

Last step you need to do is pack the compiled image into an android-compatible boot.img. Best way to do that is abootimg which is included in most linux distributions.
[Eee Pad Transformer Android Development] Sni:
kernel 3.1

Hi there,

I'm interested in having GNU LINUX with hardware acceleration on my transformer pad.

Now I'm trying to get working build of Paul Burton kernel http://xdaforums.com/showthread.php?t=1430447

(This kernel based on lastest nvidia 3.1 branch and includes transformer drivers, so ICS boots right with it)

I used lilstevie .config as base, but cant get it to work. I see no framebuffer messages - device just reboots after black screen.

I have no idea why can it fail and how to debug it - give me the direction, please

P.S. i use:

lilstevie's bootloader in dualboot mode (with android first)

codesourcery toolchain arm-2010q1

kernel config attached
[Eee Pad Transformer Android Development] rdnetto:
I've been trying to boot the CrOS kernel, but for some reason it isn't reading the partition table. I have tried with different combinations of GPT and Tegra partition support enabled, but only mmcblk0 appears under /dev. Any idea what I'm doing wrong?

@Jhinta, I think you had the same problem in January, did you you manage to work it out?

For hardware acceleration, you'll need to use the CrOS kernel. Once I have it working, I'll post a how to in the Q&A thread.

If you have no idea how to debug it, then I'd suggest you stick to one of the kernels everyone else is working on.
[Eee Pad Transformer Android Development] Jhinta:
Fb patch is needed for any new android kernel ! Android uses overlay and not fb thats why,its not realy needed but helps with debugging for booting.
[Eee Pad Transformer Android Development] stonerhino28:
Want to install Ubuntu but nothing works

I have tried the one click windows installer and the way written up buy lilstevie, and neither works. I cannot get the SBK detect tool to work and would like some help with getting ubuntu on my transformer.

Thanks
[Eee Pad Transformer Android Development] rdnetto:
Please ask in the Q&A thread.
[Eee Pad Transformer Android Development] ssciberras:
I had the same problem when using loop image file. I added a sleep 3 in the initrd file, as it sometimes it takes some time to poplate dev.

As an example, i added ls before and after sleep, and then the kernel could find the necessary partitions.

or is it a different prob?

Has anyone tried the Tegra drivers on the 2.36 kernel? from the AC100 ubuntu wii site, I am trying to use the nvidia-tegra pacage, but Xorg is complaining it is not finding the screen.

And what about the new 3.2 kernel? it should be including android stuff - would it be compatible?