• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root ICS/CM9-JB/CM10 Development Thread

@Bloodawn: Another fun thing to try if you've got a keen eye and a lot of patience is to instrument musb_write() to show all of the commands being sent to the musb controller, and compare between the two kernels. I think I'll do that tomorrow.
 
Looking through some debug output from good vs. bad runs.

On the good 2.6.35 run, musb_writeb() is not called from early on until after a few irqs have happened (including setup and reset).

On the bad 3.0.8 run, it looks like musb_restore_context() is being called immediately after the cable is plugged in (after twl4030_usb detects the link, but before the first irq). I'm thinking maybe this is screwing things up. This is done from musb_otg_notifier_work(), which is in omap2430.c.

Recall that omap2430.c the file I tried to hack up to look like 2.6.35 a couple days ago but couldn't because it had changed so much. So perhaps either the changes there are not compatible with the code I've tossed in from 2.6.35, or perhaps there's an issue with omap2430.c (incorrect config or an actual bug). It's kinda hard to distinguish between those possibilities because I don't know much about this code or the hardware, but at least now I have something to run with...
 
I was poking around the init files looking for clues and started wondering about the androidboot.hardware differences with the 3.0.8 kernel. Among other things, this affects the file naming for the various rc-files that init reads, so that init reads eg. init.black.rc instead of init.lgesniperboard.rc. Here's what I found:

The kernel commandline parameter androidboot.hardware=black is actually hardcoded in arch/arm/mach-omap2/lge_cmdline.c, which was authored by rmcc. Prior to that, they were using a hardcoded CONFIG_CMDLINE with androidboot.hardware=blackg (note the "g"), which is reminiscent of the thunder board (p500/Optimus One) which used thunderg for GSM and thunderc for CDMA.

The hardware line "LGE Hub board" in /proc/cpuinfo is from arch/arm/mach-omap2/board-hub.c, which was added in an rmcc commit that says "Add hub support from the KU5900 drop". In our LS855 sources, this says "LGE Sniper board".

Now you know! :)
 
tdm said:
I was poking around the init files looking for clues and started wondering about the androidboot.hardware differences with the 3.0.8 kernel. Among other things, this affects the file naming for the various rc-files that init reads, so that init reads eg. init.black.rc instead of init.lgesniperboard.rc. Here's what I found:

The kernel commandline parameter androidboot.hardware=black is actually hardcoded in arch/arm/mach-omap2/lge_cmdline.c, which was authored by rmcc. Prior to that, they were using a hardcoded CONFIG_CMDLINE with androidboot.hardware=blackg (note the "g"), which is reminiscent of the thunder board (p500/Optimus One) which used thunderg for GSM and thunderc for CDMA.

The hardware line "LGE Hub board" in /proc/cpuinfo is from arch/arm/mach-omap2/board-hub.c, which was added in an rmcc commit that says "Add hub support from the KU5900 drop". In our LS855 sources, this says "LGE Sniper board".

Now you know! :)
Click to expand...

glad your figuring this stuff out. I've been to busy with work the last few weeks to try anything.
 
I got the DevCtl to be the expected value by tweaking musb_platform_save_context() and musb_platform_restore_context(). Unfortunately that didn't fix it. Also tried several other things but no luck yet...
 
It's amazing what you and blood have accomplished in such a short amount of time. I Am amazed each time I visit this thread.
 
I thought that perhaps the usb troubles were caused by the musb rework in the 3.0.8 kernel. So I nuked drivers/usb/musb and copied over the 2.6.35 version, then fixed up the resulting breakage. There were a few issues, as there always are when you rip out an entire subsystem and replace it. But it wasn't too bad, really. I did need to do a fair amount of fixup in omap2430.c to get the driver to register properly and rename the clock in arch/arm/mach-omap2/clock3xxx_data.c, as the clock name had changed.

Sooooo ... when I got it all done, I have the exact same result. There is a suspend interrupt and no subsequent reset interrupt.

That tells me the issue is almost surely in arch/arm somewhere. I'm guessing it's in arch/arm/mach-omap2/usb-musb.c. I'll be poking around that next.
 
Went all through the arch/arm code and it looks good. Even fixed a couple remaining issues I was having with the forward ported drivers/usb/musb. Still no usb connectivity though.

Looking through the kernel logs between 2.6.35 and my frankenkernel, I see one thing that stands out. My kernel sees a call to musb_pullup() with "is_on" set to 0, followed by musb_stop(). The 2.6.35 kernel doesn't seem to do that. This is potentially the issue, but I'll need to dig some more, as subsequent messages indicate that the musb controller should be put back into its normal operational state with musb_start() in both cases.
 
jloca2010 said:
How's it going tdm? Hope its good thanks
Click to expand...

Hey J-LOCA(heyGurl!)! TDM wanted me to let you know that all is going well, & he appreciates your concern.

With that in mind, help is always welcomed, & to sort of further answer your question, maybe you can assist with the following to speed things along :

If you could double check the arch/arm code & make sure all is in order, that would be great. Same for the kernal log, please.

When your done with that, you can start working on the port forwarding issue, try not to overlook the drivers, usb & musb.

That is good for now, & when your done, please come back to check on this post for further instruction & more work-arounds for you to complete for the greater good of this project !

Thanks again for your concern & inquiry, NOW GET TO WORK, silly!! !:smokingsomb:
 
Currently I suspect that the composite driver is not getting enabled properly. I'm not familiar with all this stuff, but my understanding is that the USB gadget driver has "endpoints" -- each corresponding to a particular function, such as adb, mass storage, etc., and each endpoint is assigned an interrupt. Or something like that. Anyway, there is this function usb_ep_autoconfig that seems to tell the hardware to enable/disable interrupts for each endpoint. And it looks like this isn't being called, which is why the interrupts aren't being generated.

I'm cross checking with my Spectrum ICS kernel to see what's going on. I hope to have this finally nailed later this week. It's been one of the toughest issues I've had to deal with in a kernel, and I've had to deal with quite a few kernel issues in the past.
 
Are there still issues with the camera with the development of a 4.1 ROM for the Marquee?? I think I heard at one time the issue might reside with the drivers?? Does having the Nexus 4/Optimus G being manufactured by LG help at all bridge that gap with the camera??? Just curious how that all works....
 
wpmetts said:
Are there still issues with the camera with the development of a 4.1 ROM for the Marquee?? I think I heard at one time the issue might reside with the drivers?? Does having the Nexus 4/Optimus G being manufactured by LG help at all bridge that gap with the camera??? Just curious how that all works....
Click to expand...

Both cameras work beautifully with the 3.0.8 kernel and CM10. That's one of the reasons I'm so insistent on getting it working, even though it has sucked up weeks of my life..... :p
 
I can only unlock the screen when i first boot the phone,but once I lock the phone and try to unlock it again it wont let me swipe to unlock. I tried to switch it to pin unlock but it also does the same thing. Someone please help
 
jswizz said:
I can only unlock the screen when i first boot the phone,but once I lock the phone and try to unlock it again it wont let me swipe to unlock. I tried to switch it to pin unlock but it also does the same thing. Someone please help
Click to expand...

Could be a bad flash I guess. You're best off just running CTMod until CM10 is released in the coming week(s) and is fully functional. It will be much easier for people to help troubleshoot problems once we're all running the same ROM and have a more finalized kernel.
 
Okay finally made some progress. I am getting interrupts from the usb controller now.

But the current problem is that hardware exceptions are being thrown. This means the chipset on the phone is complaining that the kernel is not driving it correctly. Again, I'm not familiar with all the details, just the basic concept.

I have very little clue what exactly got the interrupts enabled, as I've hacked up everything that might be related to the usb controller to look as much like the 2.6.35 kernel as possible. I think the latest round of changes was in drivers/mfd but I think there was also some arch/arm changes as well.

Anyway here's what is happening, in case anyone can read this (Bloodawn?). The things to note are that multiple "IRQ peripheral" lines are shown, and of course the "Exception stack" stuff.

At boot, whether the usb cable is plugged in or not, this happens (this particular trace is with the usb cable unplugged):

Code: 
<4>[    0.526153] [charging_msg] set_external_power_detect, ext_pwr status 0 
<6>[    0.526153] lge_battery_fet_onoff, On 1 - GPIO LOW 
<4>[    0.526184] ------------[ cut here ]------------
<4>[    0.526214] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq+0x11c/0x168()
<4>[    0.526245] In-band Error seen by MPU  at address 0
<4>[    0.526245] Modules linked in:
<4>[    0.526306] [<c0046904>] (unwind_backtrace+0x0/0xec) from [<c0073094>] (warn_slowpath_common+0x4c/0x64)
<4>[    0.526336] [<c0073094>] (warn_slowpath_common+0x4c/0x64) from [<c007312c>] (warn_slowpath_fmt+0x2c/0x3c)
<4>[    0.526367] [<c007312c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005c0e0>] (omap3_l3_app_irq+0x11c/0x168)
<4>[    0.526397] [<c005c0e0>] (omap3_l3_app_irq+0x11c/0x168) from [<c00ab33c>] (handle_irq_event_percpu+0x30/0x17c)
<4>[    0.526428] [<c00ab33c>] (handle_irq_event_percpu+0x30/0x17c) from [<c00ab4dc>] (handle_irq_event+0x54/0x74)
<4>[    0.526458] [<c00ab4dc>] (handle_irq_event+0x54/0x74) from [<c00ad648>] (handle_level_irq+0xc0/0x10c)
<4>[    0.526489] [<c00ad648>] (handle_level_irq+0xc0/0x10c) from [<c00ab024>] (generic_handle_irq+0x28/0x30)
<4>[    0.526519] [<c00ab024>] (generic_handle_irq+0x28/0x30) from [<c003c060>] (asm_do_IRQ+0x60/0x84)
<4>[    0.526550] [<c003c060>] (asm_do_IRQ+0x60/0x84) from [<c0041448>] (__irq_svc+0x48/0xa8)
<4>[    0.526580] Exception stack(0xdbc2db60 to 0xdbc2dba8)
<4>[    0.526611] db60: 00000001 00000005 00000020 00000020 40000013 dbc54c00 00000000 00000005
<4>[    0.526641] db80: c0813928 00000000 00000002 0000017a dbc18500 dbc2dba8 c01f9e88 c006b468
<4>[    0.526641] dba0: 80000013 ffffffff
<4>[    0.526672] [<c0041448>] (__irq_svc+0x48/0xa8) from [<c006b468>] (sub_preempt_count+0x0/0xbc)
<4>[    0.526702] ---[ end trace 1b75b31a2719ed1c ]---

Then a bunch of other stuff happens, and then:

Code: 
<3>[   45.474487] twl: i2c_read failed to transfer all messages
<3>[   45.474517] twl4030: power SIH, read ISR error -121
<3>[   46.470214] omap_i2c omap_i2c.1: controller timed out
<4>[   47.485839] omap_i2c omap_i2c.1: timeout waiting for bus ready
<3>[   47.485870] twl: i2c_read failed to transfer all messages
<4>[   47.485900] twl4030: I2C error -110 reading PIH ISR
<3>[   48.485778] omap_i2c omap_i2c.1: controller timed out
<4>[   49.501464] omap_i2c omap_i2c.1: timeout waiting for bus ready
<3>[   49.501525] twl: i2c_read failed to transfer all messages
<4>[   49.501525] twl4030: I2C error -110 reading PIH ISR
<4>[   50.517211] omap_i2c omap_i2c.1: timeout waiting for bus ready
<3>[   51.532714] omap_i2c omap_i2c.1: controller timed out
<3>[   51.532775] twl: i2c_read failed to transfer all messages
<4>[   51.532775] twl4030: I2C error -110 reading PIH ISR
<6>[   51.571563] twl4030_usb_irq: enter
<6>[   51.752288] ** IRQ peripheral usb0001 tx0000 rx0000
<6>[   51.752319] <== Power=e0, DevCtl=99, int_usb=0x1
<6>[   51.780944] ** IRQ peripheral usb0004 tx0000 rx0000
<6>[   51.780944] <== Power=e0, DevCtl=99, int_usb=0x4
<4>[   51.780975] <== B-Device addr=0 driver 'android_usb'
<4>[   51.780975] USB OTG_STATE_B_PERIPHERAL
<6>[   51.783935] ** IRQ peripheral usb0001 tx0000 rx0000
<6>[   51.783935] <== Power=e0, DevCtl=99, int_usb=0x1
<7>[   51.783966] android_usb gadget: suspend
<6>[   51.783966] [ED_MC]1-2.<INT>USB_SUSPEND
<6>[   51.878173] ** IRQ peripheral usb0004 tx0000 rx0000
<6>[   51.878173] <== Power=e0, DevCtl=99, int_usb=0x4
<4>[   51.878204] <== B-Device addr=0 driver 'android_usb'
<6>[   51.878204] musb_writeb: MUSB_DEVCTL=1
<6>[   51.878204] android_usb: android_disconnect: enter
<4>[   51.878265] [<c0046904>] (unwind_backtrace+0x0/0xec) from [<c02bb988>] (android_disconnect+0x2
4/0x80)
<4>[   51.878265] [<c02bb988>] (android_disconnect+0x24/0x80) from [<c02acbe8>] (musb_g_disconnect+0
xb4/0xf4)
<4>[   51.878295] [<c02acbe8>] (musb_g_disconnect+0xb4/0xf4) from [<c02acc74>] (musb_g_reset+0x4c/0x
120)
<4>[   51.878326] [<c02acc74>] (musb_g_reset+0x4c/0x120) from [<c02ab734>] (musb_interrupt+0x434/0x5
98)
<4>[   51.878356] [<c02ab734>] (musb_interrupt+0x434/0x598) from [<c02ab8f0>] (generic_interrupt+0x5
8/0x8c)
<4>[   51.878356] [<c02ab8f0>] (generic_interrupt+0x58/0x8c) from [<c00ab33c>] (handle_irq_event_per
cpu+0x30/0x17c)
<4>[   51.878387] [<c00ab33c>] (handle_irq_event_percpu+0x30/0x17c) from [<c00ab4dc>] (handle_irq_event+0x54/0x74)
<4>[   51.878417] [<c00ab4dc>] (handle_irq_event+0x54/0x74) from [<c00ad648>] (handle_level_irq+0xc0/0x10c)
<4>[   51.878448] [<c00ad648>] (handle_level_irq+0xc0/0x10c) from [<c00ab024>] (generic_handle_irq+0x28/0x30)
<4>[   51.878448] [<c00ab024>] (generic_handle_irq+0x28/0x30) from [<c003c060>] (asm_do_IRQ+0x60/0x84)
<4>[   51.878479] [<c003c060>] (asm_do_IRQ+0x60/0x84) from [<c0041448>] (__irq_svc+0x48/0xa8)
<4>[   51.878509] Exception stack(0xdbc31f48 to 0xdbc31f90)
<4>[   51.878509] 1f40:                   00000001 00000000 000400ab 0000cba1 dbc16640 dbc30000
<4>[   51.878540] 1f60: c04c71b0 dbc167c4 c06a0340 00000000 00000000 dbc31fb4 c06b3ab0 dbc31f90
<4>[   51.878540] 1f80: c00694c8 c04c1454 00030013 ffffffff
<4>[   51.878570] [<c0041448>] (__irq_svc+0x48/0xa8) from [<c04c1454>] (__schedule+0x250/0x388)
<4>[   51.878601] [<c04c1454>] (__schedule+0x250/0x388) from [<c0078820>] (run_ksoftirqd+0x50/0x178)
<4>[   51.878601] [<c0078820>] (run_ksoftirqd+0x50/0x178) from [<c008b064>] (kthread+0x84/0x8c)
<4>[   51.878631] [<c008b064>] (kthread+0x84/0x8c) from [<c0042150>] (kernel_thread_exit+0x0/0x8)
<4>[   51.878662] USB OTG_STATE_B_PERIPHERAL
<6>[   51.878662] android_usb: android_work: enter
<4>[   51.878692] [<c0046904>] (unwind_backtrace+0x0/0xec) from [<c02bbbb0>] (android_work+0x44/0x134)
<4>[   51.878723] [<c02bbbb0>] (android_work+0x44/0x134) from [<c0085974>] (process_one_work+0x208/0x33c)
<4>[   51.878753] [<c0085974>] (process_one_work+0x208/0x33c) from [<c0087d1c>] (worker_thread+0x1d8/0x2e8)
<4>[   51.878753] [<c0087d1c>] (worker_thread+0x1d8/0x2e8) from [<c008b064>] (kthread+0x84/0x8c)
<4>[   51.878784] [<c008b064>] (kthread+0x84/0x8c) from [<c0042150>] (kernel_thread_exit+0x0/0x8)
<6>[   51.878784] android_work: did not send uevent (0 0   (null))
<7>[   51.994079] lge_usb_dp_dm_check: D+ and D- lines are open
<4>[   51.994110] [charging_msg] set_external_power_detect, ext_pwr status 1 
<6>[   51.994110] lge_battery_fet_onoff, On 1 - GPIO LOW 
<6>[   51.994140] twl4030_usb twl4030_usb: HW_CONDITIONS 0xd0/208; link 1
<6>[   51.994140] twl4030_phy_resume: enter
<6>[   51.994201] [charging_msg] twl_usb_ext_pwr_work: ext_pwr 
<4>[   51.994232] [charging_msg] lge_usb_acc_detect, start
<6>[   52.013702] twl4030_usb twl4030_usb: HW_CONDITIONS 0xd0/208; link 1
<3>[   52.013732] twl4030_phy_power: on=1
<3>[   52.033355] twl4030_phy_power + : PHY_PWR_CTRL=1 ====^^==== (twl4030-usb.c)
<3>[   52.053070] twl4030_phy_power + : PHY_CLK_CTRL=7 ====^^==== (twl4030-usb.c)
<3>[   52.072784] twl4030_phy_power + : PHY_CLK_CTRL_STS=0 ====^^==== (twl4030-usb.c)
<3>[   52.283416] twl4030_phy_power - : PHY_PWR_CTRL=0 ====^^==== (twl4030-usb.c)
<3>[   52.303070] twl4030_phy_power - : PHY_CLK_CTRL=7 ====^^==== (twl4030-usb.c)
<3>[   52.322906] twl4030_phy_power - : PHY_CLK_CTRL_STS=1 ====^^==== (twl4030-usb.c)
<6>[   52.513580] [charging_msg] twl4030_usb_irq: status 1
<4>[   52.513610] [twl4030-usb] wake_lock_on=1 (locked)
<6>[   52.705596] voice_configure_path(at twl4030).....path = 0, cur_twl_mode = 0
<4>[   52.705627] [wm9093.c] func:[wm9093_configure_path()], line:(1223), mode( 1)
<4>[   52.813903] [charging_msg] lge_usb_acc_detect: USB ID level = 1813 mV (0x2E6)
<7>[   52.813903] [charging_msg] lge_usb_acc_detect: Cable ID is un-valid.
<7>[   52.813903] lge_usb_acc_detect: D+ and D- lines are open
<7>[   52.813934] lge_usb_acc_detect: Connected to an USB.
<4>[   52.813934] [charging_msg] charging_ic_active_default: Start 1
<4>[   52.813964] [charging_msg] set_charging_current_sub, External Power Type 4, charging_ic_status 1 
<4>[   53.110900] [LUCKYJUN77] headset_ramp
<4>[   53.207550] [charging_msg] charging_ic_active_default: Start 1
<4>[   53.207580] [charging_msg] set_charging_current_sub, External Power Type 4, charging_ic_status 1 
<6>[   53.207580] lge_battery_fet_onoff, On 1 - GPIO LOW 
<6>[   53.207611] battery_too_hot_or_too_cold: *********** Batt Thrm State (Normal)
<6>[   53.207611] [charging_msg] set_battery_charging: Charging Status :(Charging), Voltage 4200, capacity 100, Endof Charging 0
 
As an addendum, I think this is functional to the point where usb would be functional if the hardware exceptions weren't being thrown -- that is, if the kernel drove the hardware properly.

So next, I'm going to start backing out changes, making sure to keep the interrupts flowing at each point, and see if I can get the exceptions to go away.
 
You are definitely making progress. I think you're right about things being where they should be. That loop you're getting caught in looks like it's not engaging something. Do you have the source uploaded anywhere? When I get some time I could try to dig through some of the trees and see if there is anything that jumps out. Maybe a mismatched or bad address is being called?
 
You must log in or register to reply here.
Back
Top Bottom