• 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

I am curious about the kernel is it similar to a Linux kernel where you insert modules and recompile or totally different? I have heard some Linux people say that Android is nothing like Linux but seeing some of the discussions it seems to share some of it's features.
 
I am curious about the kernel is it similar to a Linux kernel where you insert modules and recompile or totally different? I have heard some Linux people say that Android is nothing like Linux but seeing some of the discussions it seems to share some of it's features.

Android uses the Linux kernel. It shares few other packages with any Linux distro: they even wrote their own libc.
 
Struggled with back porting the ics dsscomp driver to the gb kernel again today. I'm becoming more convinced that it's going to be at least as much work as figuring out the usb issue in the ics kernel. So I think I'm going to shift back to the ics kernel tomorrow.
 
Tracking down the reboot when entering sleep with the ls855 changes. TI boards indicate it's a usb issue. Ugh.
 
You guys are so awesome. i respect and admire what you guys do as developers. keep up the good work. so does 3G and WIFI work on the 'quattrimus-sniper-aokp-alpha3.zip' LG Marquee LS855? What all is broken?
 
You guys are so awesome. i respect and admire what you guys do as developers. keep up the good work. so does 3G and WIFI work on the 'quattrimus-sniper-aokp-alpha3.zip' LG Marquee LS855? What all is broken?
Both 3G and Wifi work on the AOKP ROM, but have basically the same bugs that are listed in the first post of Blood's MIUI thread. Take a look at those and you will know what to generally expect to be problems with any of the ICS ROMs for the Marquee.
 
Tracking down the reboot when entering sleep with the ls855 changes. TI boards indicate it's a usb issue. Ugh.

Tracked down the reboot issue to disabling CONFIG_HUB_MUIC. This is disabled when CONFIG_LGE_LAB3_BOARD is enabled. Same as in the 2.6.35 kernel.

Disabling CONFIG_HUB_MUIC disables compilation of drivers/hub/hub_muic.c and also is referenced in several other source files. I'll need to cross reference with the 2.6.35 kernel to see what's going on. It's likely that LG hasn't compiled a kernel with CONFIG_LGE_LAB3_BOARD set, so there's probably some issue that was missed in the update to 3.0.8.
 
My initial changes weren't complete. I was lazy and only did the parts that looked necessary. I think that's the source of my issues.

So, I'm currently going through the code and painstakingly looking for all instances of CONFIG_LGE_LAB3_BOARD, CONFIG_HUB_MUIC, CONFIG_LGE_OMAP3_EXT_PWR, CONFIG_LGE_USB_SWITCH, and CONFIG_LGE_CHARGE_CONTROL_BATTERY_FET. Each of these need to be updated. I'm probably 2/3 of the way done, so I should be able to finish up and test again tomorrow.
 
I've been trying some stuff but nothings working, anything stand out to you here tdm? this is when plugging it in:

<7>[ 213.556457] lge_usb_dp_dm_check: D+ and D- lines are open
<4>[ 213.556518] [charging_msg] set_external_power_detect, ext_pwr status 1
<3>[ 213.556549] <<<<<<<<<<<<<< LGMUSB_P can not get musb address
<6>[ 213.556701] [charging_msg] twl_usb_ext_pwr_work: ext_pwr
<4>[ 213.556762] [charging_msg] lge_usb_acc_detect, start
<3>[ 213.557250] twl4030_phy_power + : PHY_PWR_CTRL=1 ====^^==== (twl4030-usb.c)
<3>[ 213.557678] twl4030_phy_power + : PHY_CLK_CTRL=6 ====^^==== (twl4030-usb.c)
<3>[ 213.558074] twl4030_phy_power + : PHY_CLK_CTRL_STS=0 ====^^==== (twl4030-usb.c)
<3>[ 213.561523] twl4030_phy_power - : PHY_PWR_CTRL=0 ====^^==== (twl4030-usb.c)
<3>[ 213.561828] twl4030_phy_power - : PHY_CLK_CTRL=6 ====^^==== (twl4030-usb.c)
<3>[ 213.562103] twl4030_phy_power - : PHY_CLK_CTRL_STS=1 ====^^==== (twl4030-usb.c)
<6>[ 213.564636] [charging_msg] twl4030_usb_irq: status 1
<4>[ 213.564697] [twl4030-usb] wake_lock_on=1 (locked)
<4>[ 213.567871] [charging_msg] lge_usb_acc_detect: USB ID level = 1661 mV (0x2A8)
<7>[ 213.567932] [charging_msg] lge_usb_acc_detect: Cable ID is un-valid.
<4>[ 213.567962] [charging_msg] set_charging_current, External Power Type 5
<4>[ 214.340972] ifx_spi_write - timeout!! Can't get SRDY from CP for 10sec. Set MRDY h

this is unplugging:

<6>[ 349.633300] [charging_msg] charging_ic_interrupt_handler: charger ic interrupt occured
<4>[ 349.669769] [charging_msg] set_external_power_detect, ext_pwr status 0
<3>[ 349.669799] <<<<<<<<<<<<<< LGMUSB_P can not get musb address
<6>[ 349.669891] [charging_msg] twl_usb_ext_pwr_work: ext_pwr
<4>[ 349.669891] [charging_msg] lge_usb_acc_detect, start
<4>[ 349.669921] [charging_msg] set_charging_current, External Power Type 8
<3>[ 349.670013] twl4030_phy_power + : PHY_PWR_CTRL=0 ====^^==== (twl4030-usb.c)
<3>[ 349.670288] twl4030_phy_power + : PHY_CLK_CTRL=6 ====^^==== (twl4030-usb.c)
<3>[ 349.670562] twl4030_phy_power + : PHY_CLK_CTRL_STS=1 ====^^==== (twl4030-usb.c)
<3>[ 349.930450] twl4030_phy_power - : PHY_PWR_CTRL=1 ====^^==== (twl4030-usb.c)
<3>[ 349.931030] twl4030_phy_power - : PHY_CLK_CTRL=6 ====^^==== (twl4030-usb.c)
<3>[ 349.931549] twl4030_phy_power - : PHY_CLK_CTRL_STS=0 ====^^==== (twl4030-usb.c)
<6>[ 349.931610] [charging_msg] twl4030_usb_irq: status 0
<6>[ 350.130035] [charging_msg] charging_ic_work_func
<6>[ 350.132873] [Battery] Charging IC - EOC
<4>[ 350.426910] [twl4030-usb] wake_lock_on=0 (unlocked)
 
No that looks like what I see.

I got a pretty complete forward port of the ls855 changes and it won't boot.

Played with fbcon some more but no luck there either.

I guess the next step is to go back to the minimal changes and apply small increments to see what is breaking.
 
Also note I found another config that differs between P970 and LS855:


-CONFIG_LGE_SPI_MASTER=y
+# CONFIG_LGE_SPI_MASTER is not set
+CONFIG_LGE_SPI_SLAVE=y

That's one thing I changed today in the non-booting kernel.

Also, a potential gem in the framebuffer code:

drivers/video/console/fbcon.c has a function lge_hub_display_message_on_screen(). It's used in the LU6800 code (board-justin-debug.c). That means at some point an LG developer had a working fbcon....
 
No that looks like what I see.

I got a pretty complete forward port of the ls855 changes and it won't boot.

Played with fbcon some more but no luck there either.

I guess the next step is to go back to the minimal changes and apply small increments to see what is breaking.

Spent most of the day today trying to get drivers/usb/musb/omap2430.c to look like it did in the 2.6.35 kernel, but no luck. It's changed too much.

I did get CONFIG_SPI_SLAVE set and updated the following to match the 2.6.35 kernel as close as possible:

drivers/spi/omap2_mcspi_slave.c
drivers/usb/otc/twl4030-usb.c
drivers/leds/leds-bd2802.c
drivers/power/max17043_fuelgauge.c
drivers/hub/hub_charging_ic.c

Right now it looks like I'm only getting the reboot-on-sleep when the USB cable is *not* plugged in. That is an improvement, as it was always rebooting before.

Remaining from my previous changes are:

arch/arm/mach-omap2/board-hub-peripherals.c
drivers/hub/hub_modem_ctrl.c
drivers/hub/headset_det.c
sound/soc/codecs/twl4030.c
sound/soc/omap/hub.c

I'll get to those on Monday or before.

@Bloodawn: if you want these changes as I'm doing them, let me know and I'll push to github.
 
Right now it looks like I'm only getting the reboot-on-sleep when the USB cable is *not* plugged in. That is an improvement, as it was always rebooting before.

Finally nailed the reboot-on-sleep issue.

I separate out HUB_MUIC and LGE_LAB3_BOARD and set LGE_LAB3_BOARD only. That worked. Then I reset HUB_MUIC and it failed. Looking through the code for the symbol HUB_MUIC led me to arch/arm/mach-omap2/board-hub-peripherals.c which is slightly different in the 3.0.8 kernel. Apparently the LG developers broke this with their MUIC rework.

Here's the code in 2.6.35:

Code:
    //3. hub muic
    {
        I2C_BOARD_INFO("hub_i2c_muic", 0x88>>1),
    },

Note this entry is always present, regardless of any config settings.

Here's the code in 3.0.8:

Code:
#if defined(CONFIG_HUB_MUIC)
    {
        I2C_BOARD_INFO("hub_i2c_muic", 0x88>>1),
    },
#elif defined(CONFIG_MUIC)
    {
        I2C_BOARD_INFO("hub_i2c_muic", 0x88>>1),
        .irq = OMAP_GPIO_IRQ(MUIC_INT_GPIO),
        .platform_data = &muic_pdata,                   
    },
#endif

Note the entry disappears when neither CONFIG_HUB_MUIC nor CONFIG_MUIC are defined.

Simple fix:

Code:
--- a/arch/arm/mach-omap2/board-hub-peripherals.c
+++ b/arch/arm/mach-omap2/board-hub-peripherals.c
@@ -785,11 +785,11 @@ static struct i2c_board_info __initdata hub_i2c_bus2_info[] = {
         },
 #endif /* CONFIG_AUDIO_AMP_WM9093 */   // 20100625 [email]junyeop.kim@lge.com[/email] wm9093(amp) [END_LGE]
 
-#if defined(CONFIG_HUB_MUIC)
+#if !defined(CONFIG_MUIC)
     {
        I2C_BOARD_INFO("hub_i2c_muic", 0x88>>1),
     },
-#elif defined(CONFIG_MUIC)
+#else
     {
        I2C_BOARD_INFO("hub_i2c_muic", 0x88>>1),
        .irq = OMAP_GPIO_IRQ(MUIC_INT_GPIO),

Remaining from my previous changes are:

arch/arm/mach-omap2/board-hub-peripherals.c
drivers/hub/hub_modem_ctrl.c
drivers/hub/headset_det.c
sound/soc/codecs/twl4030.c
sound/soc/omap/hub.c

I'll get to those on Monday or before.

Got hub_modem_ctrl.c forward ported.

The sound stuff isn't causing serious issues so I'm going to put that aside for now and focus on the USB detection issue.
 
Comparing a working 2.6.35 kernel to a non-working 3.0.8 kernel (with lots of changes, natch), the first substantial difference I see is this:

Working 2.6.35 kernel:

** IRQ peripheral usb0001 tx0000 rx0000
<== Power=e0, DevCtl=91, int_usb=0x1 (SUSPEND )
SUSPEND (b_idle) devctl 91 power e0
** IRQ peripheral usb0004 tx0000 rx0000
<== Power=f0, DevCtl=91, int_usb=0x4 (RESET )
BUS RESET as b_idle

Non-working 3.0.8 kernel:

** IRQ peripheral usb0001 tx0000 rx0000
<== Power=e0, DevCtl=99, int_usb=0x1 (SUSPEND )
SUSPEND (b_idle) devctl 99 power e0

Note that (1) DevCtl is different between the two, and (2) the non-working kernel does not get the reset interrupt.

The DevCtl bits are defined in drivers/usb/musb/musb_core.h:

Code:
/* DEVCTL */
#define MUSB_DEVCTL_BDEVICE     0x80
#define MUSB_DEVCTL_FSDEV       0x40
#define MUSB_DEVCTL_LSDEV       0x20
#define MUSB_DEVCTL_VBUS        0x18
#define MUSB_DEVCTL_VBUS_SHIFT  3
#define MUSB_DEVCTL_HM          0x04
#define MUSB_DEVCTL_HR          0x02
#define MUSB_DEVCTL_SESSION     0x01

Note VBUS seems to be a 2-bit field and the differing bit is part of VBUS.

I'm not familiar with this stuff at all, so I have no clue what a VBUS is or what these bits mean.

So I'm scouring the code trying to figure out why that bit would be set, and if it is relevant.
 
Back
Top Bottom