Advent Vega kernel source code now available!

[Guest brucelee666]

Eduardo,

Initial test of new patch - sd card mounts wifi re-connected after short sleep, so seems to work so adding that ".cd_gpio_active_high = 1" and any other change seems to have had the desired effect no longer need to remove the code from sdhci.c :) .

re. audio - not looked at it but now sd/wifi seems to be ok will have look and see if I can notice anything it was next on my list (as I think Scanno has said you do get audio through headphone jack with latest 2906 patch just not speakers).

Guess if you have time to implement the hardware audio equalizer and it could improve current audio then it would be worthwhile, sure users would find a use for it.

Edited June 30, 2012 by brucelee666

[Guest Scanno]

The only thing remaining is audio... I am curious on why the original 2802 patches work, but the newer ones do not work... Newer ones are closer to nvidia 3.1 ... So they should be better, but they aren't... And a question for all of you:

The ALC5624 has a hardware audio equalizer and stereo expansion engine that is currently disabled. I have some info on how to enable it... we could add some user configurable setting to let the user pick between no equalization, or some equaliztions. And we can get it nearly for free, without CPU resources used, as everything is done inside the ALC5624 ... I think it could be interesting, specially for the loudspeaker output... Do you think it is worthwhile to implement it ?

If you have time to implement the equalizer that would be a nice addition. But the most important thing is to get the audio working through the speaker. One more addition to audio. I think the volume is set lower then in the old driver. Is that correct ? It seems around 25% lower through headphone and is a little bit distoring as like too much gain.....

I am going to have a look at your latets files.

EDIT:

Are the patches like tegra_clocks.c and tegra_nand.c from 2802 still needed ??

Edited June 30, 2012 by Scanno

[Guest ejtagle]

I think tegra_clocks.c is not needed. tegra_nand.c patch should be required. The reason is that i am not sure of the secondary nand chip id value. What i dod was just to relax a bit the matching of nand device ids ;)

[Guest brucelee666]

Scanno / Eduardo,

Just re-compiled with 3.1 ver of the tegra2-clocks.c and it does not flash correctly so as I found when I first got the 3.1 kernel to boot you do need the 2802 tegra2-clocks.c file (not checked tegra_nand.c to see if that still needs to be 2802 yet).

A few days ago after looking at a diff of the files I tried to merge the differences and this is what I found:-

The "tegra2_pll_clk_set_rate" funtion is changed a bit from 2802 to latest and this is what stops the nvflash process from completing correctly resulting in a non-booting tablet and a pain to get back into nvflash mode, found this by replacing this funtion in 2802 file with the 3.1 version.

Also the other differences are to values in the "tegra_list_periph_clks" and a few if statements when I merged only these into the 2802 it still booted as it had the original function noted above but when it booted it did not recognize that the charger was actually connected.

I had to go and do other things so was unable to look into further to give any more details but will add to the list of things to check and see if I can supply any more details.

edit - ok further info this commitis the one that breaks the nvflash process and results in a non-booting tablet.

edit - and this onebreaks the battery and means android ask to connect charger even when its connected (the -2c-fast does not effect us but changing the NULL to i2c-div breaks it).

All other diffierences between 3.1 and 2802 tegra2-clocks.c file cause no issues I can see.

Edited July 1, 2012 by brucelee666

[Guest Daedric1383]

@ejtagle:

Hardware stereo equalizer AND hardware stereo expansion would be sweet. First, it would not be app dependent, second, no processing lost. If you find the time, and realize the benefits overcome the costs, i believe i speak for the entire community when i say that we would be very thankful. I was reading about the ALC on realtek's website, and found a few interesting facts:

• flexible hardware 5-band equalizer with configurable gain, bandwidth, and center frequency, and enriches the sound experience
  
• Class-AB or Class-D amplifiers are easily swapped via simple register configuration (is this true? if yes, which one are we using?)
  
• Supports digital 5 band equalizer (EQ)
  
• Supports digital spatial sound and pseudo stereo effect
  
• Supports pop noise suppression (can this be enabled?)
  

​For those interested : ftp://209.222.7.36/pc/caudio/ALC5624_DataSheet_1.3.pdf

@ejtagle, scanno, brucelee666 et all:

Having outsiders beta test would be out of the question ? Due to the variety of different devices based on the shuttle, it would probably be profitable having a few...

Edited June 30, 2012 by Daedric1383

[Guest Scanno]

@ejtagle:

Hardware stereo equalizer AND hardware stereo expansion would be sweet. First, it would not be app dependent, second, no processing lost. If you find the time, and realize the benefits overcome the costs, i believe i speak for the entire community when i say that we would be very thankful. I was reading about the ALC on realtek's website, and found a few interesting facts:

• flexible hardware 5-band equalizer with configurable gain, bandwidth, and center frequency, and enriches the sound experience
  
• Class-AB or Class-D amplifiers are easily swapped via simple register configuration (is this true? if yes, which one are we using?)
  
• Supports digital 5 band equalizer (EQ)
  
• Supports digital spatial sound and pseudo stereo effect
  
• Supports pop noise suppression (can this be enabled?)
  

​For those interested : ftp://209.222.7.36/pc/caudio/ALC5624_DataSheet_1.3.pdf

@ejtagle, scanno, brucelee666 et all:

Having outsiders beta test would be out of the question ? Due to the variety of different devices based on the shuttle, it would probably be profitable having a few...

The next VegaCream version will have the 3.1 kernel. As of now the 3.1 kernel is better then the old one at least regarding to wifi stability and suspend/sleep.

I guess that with the latest patches from 30 June combined with the patches from 29 june , the tegra2_clocks.c and tegra_nand.c and the audio files from 2802 we have a pretty good kernel for now.

If Eduardo and brucelee666 do not mind, I could release beta with the 3.1 kernel for testing purposes...

Edited July 1, 2012 by Scanno

[Guest ejtagle]

This should solve the battery status not being read issue... I had no time to test or compile it, will do tomorrow... ;) ... They changed the i2c clock name, so the nvec driver was unable to enable the i2c clock required to make communications with nvec work (nvec is an auxiliary processor in shuttle that monitors the battery level)

nvec.rar

[Guest brucelee666]

Okay not good news for me I am afraid, during my checking the clocks and changing the i2c value from NULL and then trying to get back to flash a working boot image something happened (done this before a few times trying to get 3.1 kernel to work and that this just seems to be one time to many I guess and vega said enough was enough)

Result I could not flash the boot image, i have now been able to flash old 1.10 images and also Cass ICSvega-beta1 to get it working but touchscreen is now dead will need to borrow a USB mouse as I don't have one lying around which I won't get till later today to test out Richard's newly posted touchscreen fix and see if that works.

Due to this I won't be testing anything today and possibly be unable to help in any future kernel/jelly bean work, but I will wait and see hopefully not.

[Guest Scanno]

Okay not good news for me I am afraid, during my checking the clocks and changing the i2c value from NULL and then trying to get back to flash a working boot image something happened (done this before a few times trying to get 3.1 kernel to work and that this just seems to be one time to many I guess and vega said enough was enough)

Result I could not flash the boot image, i have now been able to flash old 1.10 images and also Cass ICSvega-beta1 to get it working but touchscreen is now dead will need to borrow a USB mouse as I don't have one lying around which I won't get till later today to test out Richard's newly posted touchscreen fix and see if that works.

Due to this I won't be testing anything today and possibly be unable to help in any future kernel/jelly bean work, but I will wait and see hopefully not.

I hope the new touchscreen fix from Richard will work for you.

[Guest richardmlea]

Bruce, If you need it I have a reclaimed touchscreen (thanks to the fix) you could have cheap.

Good luck with the fix. But while you wai for a mouse have you tried viewsonic's 1.0.1 stock rom, It has a touchscreen update at first boot that may work if the firmware is still valid. If you get to language selection without the TS update then it didnt work.

Edited July 1, 2012 by richardmlea

[Guest grnunn]

If you have time to implement the equalizer that would be a nice addition. But the most important thing is to get the audio working through the speaker. One more addition to audio. I think the volume is set lower then in the old driver. Is that correct ? It seems around 25% lower through headphone and is a little bit distoring as like too much gain.....

This is from digesting the datasheet so it may not be perfect :) I don't know how this works together with the kernel but these are the registers that need set up.

I assume that the audio for the tegra2 is passed to the codec via the I2S interface?

The path from DAC to HP and Speaker is very similar

DAC -> DAC Gain -> HP Mixer -> HP or SPK Output stage mux -> output stage

The distortion may be from clipping in the headphone mixer (DAC gain too high) they may have then tried to fix the distortion by turning down the HP output, hence quieter but distorted.

HP Mixer / DAC Volume 0x0C : [15] = 0 (Unmute HP) [14] =0 (Unmute SPK) [13] = 1 (Mute Mono) [12:8] = 01000 (0dB) [7:5]= 000 (RSVD) [4:0] = 0_1000 (0dB) === 0010_1000_0000_1000

Path Selector 0x1C - [15:14] = 01 (HPL) [13] = 1 (ClassD) [12:11] = 01 (HPR) [10] = 0 [9:8] = 11 (HPL&R) [7:0] = 0x0 === 0110_1011_0000_0000

If we still don't have audio out of the speaker then it could either be that the speaker is muted or powered down:

Register 0x02 is the speaker volume register, this is 0x8080 by default : this equates to L&R muted. If set to 0x0000 then it will be full volume - we would probably want to lower this while testing :) i.e. 0x4848 (-12dB on both channels with zero cross enabled)

Register 0x26 is the powerdown register the MSB (PR7) shuts down the speaker, the default is 0xEF00 so if we have headphone audio then this will have been set to at least to clear PR6 (bit 14).

Hope this makes some sense. If I could get a dump of the codec registers I would be able to have a better chance of analysing what the setup is.

[Guest ejtagle]

This is from digesting the datasheet so it may not be perfect :) I don't know how this works together with the kernel but these are the registers that need set up.

I assume that the audio for the tegra2 is passed to the codec via the I2S interface?

The path from DAC to HP and Speaker is very similar

DAC -> DAC Gain -> HP Mixer -> HP or SPK Output stage mux -> output stage

The distortion may be from clipping in the headphone mixer (DAC gain too high) they may have then tried to fix the distortion by turning down the HP output, hence quieter but distorted.

HP Mixer / DAC Volume 0x0C : [15] = 0 (Unmute HP) [14] =0 (Unmute SPK) [13] = 1 (Mute Mono) [12:8] = 01000 (0dB) [7:5]= 000 (RSVD) [4:0] = 0_1000 (0dB) === 0010_1000_0000_1000

Path Selector 0x1C - [15:14] = 01 (HPL) [13] = 1 (ClassD) [12:11] = 01 (HPR) [10] = 0 [9:8] = 11 (HPL&R) [7:0] = 0x0 === 0110_1011_0000_0000

If we still don't have audio out of the speaker then it could either be that the speaker is muted or powered down:

Register 0x02 is the speaker volume register, this is 0x8080 by default : this equates to L&R muted. If set to 0x0000 then it will be full volume - we would probably want to lower this while testing :) i.e. 0x4848 (-12dB on both channels with zero cross enabled)

Register 0x26 is the powerdown register the MSB (PR7) shuts down the speaker, the default is 0xEF00 so if we have headphone audio then this will have been set to at least to clear PR6 (bit 14).

Hope this makes some sense. If I could get a dump of the codec registers I would be able to have a better chance of analysing what the setup is.

Of course you can get a dump of the codec registers. And you can also modify them, if you need. It is available from a node of the debugfs

For example::

mkdir /data/d

mount -t debugfs /data/d /data/d

cd /data/d

cd asoc/tegra-alc5624

cd alc5624.0-0018

cat codec_reg

if you need to modify a register value, do

echo 0xREG 0xVAL > codec_reg

[Guest ejtagle]

Okay not good news for me I am afraid, during my checking the clocks and changing the i2c value from NULL and then trying to get back to flash a working boot image something happened (done this before a few times trying to get 3.1 kernel to work and that this just seems to be one time to many I guess and vega said enough was enough)

Result I could not flash the boot image, i have now been able to flash old 1.10 images and also Cass ICSvega-beta1 to get it working but touchscreen is now dead will need to borrow a USB mouse as I don't have one lying around which I won't get till later today to test out Richard's newly posted touchscreen fix and see if that works.

Due to this I won't be testing anything today and possibly be unable to help in any future kernel/jelly bean work, but I will wait and see hopefully not.

I ask myself why is this touchscreen issue happening ? - Perhaps it is the autocalibration done at boot ? ... But the original shuttle rom also did it. and also did a recalibration when you pressed the back button...

I think that it could be a combination between unstable power supplies and a bad designed touchscreen rom... In no case program flash could be corrupted... I guess, perhaps, that the configuration could be corrupted, but not the program itself... Perhaps a bad configuration causes the touchscreen firmware to fail... And this poses a very interesting question... Could we flash a new firmware to the touchscreen ? ... Maybe the touchscreen controller still recognizes reflashing commands... Pretty interesting question...

We could check that if someone with non working touchscreen posts a dmesg... If the touchscreen controller does not acknowledge i2c transactions, then, no hope. But, if the controller is acknowledging communications, perhaps we could reflash the config...

[Guest brucelee666]

Eduardo,

Seeing as I am one of those touchscreen issues people here is a dmesg, and a copy of the relevant messages to save you hunting - this is from a vegaics-beta1 rom so 39 kernel with your old ts driver I think (still to try Richards firmware upgrade solution to see if that works).

<6>[ 2.954924] it7260 touchscreen driver

<6>[ 2.955618] it7260 4-0046: IT7260 touchscreen Driver

<6>[ 2.955958] Enabling touchscreen

<3>[ 13.167336] it7260 4-0046: wait for idle while reinitializing fw

<3>[ 13.167647] it7260 4-0046: not detected or in firmware upgrade mode.

<6>[ 13.167821] Disabling touchscreen

<6>[ 13.181705] eGalax touchscreen driver

<6>[ 13.181923] egalax 4-0004: eGalax touchscreen Driver

<6>[ 13.182091] Enabling touchscreen

<4>[ 13.271699] tegra-i2c tegra-i2c.3: I2c error status 0x0000000a

<4>[ 13.271870] tegra-i2c tegra-i2c.3: no acknowledge from address 0x4

<4>[ 13.272177] tegra-i2c tegra-i2c.3: Packet status 0x00010009

<4>[ 13.273475] tegra-i2c tegra-i2c.3: I2c error status 0x00000008

<4>[ 13.273774] tegra-i2c tegra-i2c.3: no acknowledge from address 0x4

<4>[ 13.273949] tegra-i2c tegra-i2c.3: Packet status 0x00010009

<3>[ 13.275339] egalax 4-0004: The egalax_i2c device does not exist

<3>[ 13.275508] egalax 4-0004: not detected or in firmware upgrade mode.

<6>[ 13.275804] Disabling touchscreen

edit - Maybe nothing but for further info trying to flash and then boot a kernel with the new touchscreen driver basically does not happen when in above state, compile it with the old ts driver and it will flash and boot (tested with the same 3.1 base only ts driver changed, guess the newer ts does some checking at boot that must cause an issue when tablet is in above state).

ts.txt

Edited July 1, 2012 by brucelee666

[Guest richardmlea]

I ask myself why is this touchscreen issue happening ? - Perhaps it is the autocalibration done at boot ? ... But the original shuttle rom also did it. and also did a recalibration when you pressed the back button...

I think that it could be a combination between unstable power supplies and a bad designed touchscreen rom... In no case program flash could be corrupted... I guess, perhaps, that the configuration could be corrupted, but not the program itself... Perhaps a bad configuration causes the touchscreen firmware to fail... And this poses a very interesting question... Could we flash a new firmware to the touchscreen ? ... Maybe the touchscreen controller still recognizes reflashing commands... Pretty interesting question...

We could check that if someone with non working touchscreen posts a dmesg... If the touchscreen controller does not acknowledge i2c transactions, then, no hope. But, if the controller is acknowledging communications, perhaps we could reflash the config...

Hi Ed,

Have you seen my thread here.

The fix uses a factory rom that I believe is spoofing android into thinking the 99 firmware is still valid (or at least different). You can then use a modified TPUtility to flash valid firmware to the controller.

Once the firmware is loaded the original tp utility can be used to update the firmware to later versions (or viewsonic stock rom can be used as it has an update at first boot.

The rom and the TPutility came from a Viewsonic service center in Russia via a russian website.

It doesn't work on all touchscreens showing 99 firmware though.

[Guest Scanno]

This is weird. I am getting messages from pppd that the kernel does not support ppp. But in the config ppp is enabled...

#

# CAIF transport drivers

#

# CONFIG_FDDI is not set

# CONFIG_HIPPI is not set

CONFIG_PPP=y

# CONFIG_PPP_MULTILINK is not set

CONFIG_PPP_FILTER=y

CONFIG_PPP_ASYNC=y

CONFIG_PPP_SYNC_TTY=y

CONFIG_PPP_DEFLATE=y

CONFIG_PPP_BSDCOMP=y

CONFIG_PPP_MPPE=y

# CONFIG_PPPOE is not set

CONFIG_PPPOLAC=y

CONFIG_PPPOPNS=y

# CONFIG_SLIP is not set

CONFIG_SLHC=y

# CONFIG_NET_FC is not set

# CONFIG_NETCONSOLE is not set

# CONFIG_NETPOLL is not set

# CONFIG_NET_POLL_CONTROLLER is not set

# CONFIG_VMXNET3 is not set

# CONFIG_ISDN is not set

# CONFIG_PHONE is not set

Edited July 1, 2012 by Scanno

[Guest ejtagle]

Eduardo,

Seeing as I am one of those touchscreen issues people here is a dmesg, and a copy of the relevant messages to save you hunting - this is from a vegaics-beta1 rom so 39 kernel with your old ts driver I think (still to try Richards firmware upgrade solution to see if that works).

<6>[ 2.954924] it7260 touchscreen driver

<6>[ 2.955618] it7260 4-0046: IT7260 touchscreen Driver

<6>[ 2.955958] Enabling touchscreen

<3>[ 13.167336] it7260 4-0046: wait for idle while reinitializing fw

<3>[ 13.167647] it7260 4-0046: not detected or in firmware upgrade mode.

<6>[ 13.167821] Disabling touchscreen

<6>[ 13.181705] eGalax touchscreen driver

<6>[ 13.181923] egalax 4-0004: eGalax touchscreen Driver

<6>[ 13.182091] Enabling touchscreen

<4>[ 13.271699] tegra-i2c tegra-i2c.3: I2c error status 0x0000000a

<4>[ 13.271870] tegra-i2c tegra-i2c.3: no acknowledge from address 0x4

<4>[ 13.272177] tegra-i2c tegra-i2c.3: Packet status 0x00010009

<4>[ 13.273475] tegra-i2c tegra-i2c.3: I2c error status 0x00000008

<4>[ 13.273774] tegra-i2c tegra-i2c.3: no acknowledge from address 0x4

<4>[ 13.273949] tegra-i2c tegra-i2c.3: Packet status 0x00010009

<3>[ 13.275339] egalax 4-0004: The egalax_i2c device does not exist

<3>[ 13.275508] egalax 4-0004: not detected or in firmware upgrade mode.

<6>[ 13.275804] Disabling touchscreen

the i2c address of the it7260 is 0x46. The non acks are from the second touchscreen driver, the eGalax touchscreen that i suspect is not used at all in the Shuttle... So, yes, the it7260 is acknowledging commands... But not all of them. The fact you are getting "wait for idle while reinitializing fw" means that the driver is sending the read status command, and the status is returning busy all the time. So, the touchscreen driver refuses to load, But the cause is not the non acking of commands, rather than, the cause is that the touchscreen firmware refuses to returno touchscreen data (expected, as fw configuration is corrupted). And, because of that, the driver refuses to load (it thinks that there is a i2c chip, but that it is not a touchscreen chip)

Without the driver, the firmware update utility is unable to update the firmware itself, as it uses the driver as a proxy to communicate with the touchscreen controller...

Note that the original 2.2 driver has an even worse flaw: If the controller fails to return a valid status , there is a loop in the driver sources that just prevents the kernel to end the boot process... :o

EDIT1> I modified the it7260 driver to allow it to load even if no valid status is returned. In such case, the driver is loaded in an special firmware update mode, and implements the IOCTLs required to allow the original TPUtility to work and flash a working firmware... Maybe that could be useful to someone... ;)

EDIT2> Also added the equalizer implementation for the ALC5624... Untested

nv3.1-01-jul.rar

Edited July 1, 2012 by ejtagle

[Guest grnunn]

Of course you can get a dump of the codec registers. And you can also modify them, if you need. It is available from a node of the debugfs

For example::

mkdir /data/d

mount -t debugfs /data/d /data/d

cd /data/d

cd asoc/tegra-alc5624

cd alc5624.0-0018

cat codec_reg

if you need to modify a register value, do

echo 0xREG 0xVAL > codec_reg

That works nicely! Could someone point me at a compiled build with broken audio?

Or would it be easier if I started looking at the driver code directly?

[Guest ejtagle]

Hi Ed,

Have you seen my thread here. http://www.modaco.co...view-mobii-ect/

The fix uses a factory rom that I believe is spoofing android into thinking the 99 firmware is still valid (or at least different). You can then use a modified TPUtility to flash valid firmware to the controller.

Once the firmware is loaded the original tp utility can be used to update the firmware to later versions (or viewsonic stock rom can be used as it has an update at first boot.

The rom and the TPutility came from a Viewsonic service center in Russia via a russian website.

It doesn't work on all touchscreens showing 99 firmware though.

Probably right, Richard. I presume the corruptin is in the config section of the FLASH of the touchscreen controller, so seems somehow a new flash can be sent to the controller...

[Guest brucelee666]

OK while I have a moment, touchscreen not fully working but with a mixture of the touch input it has and mouse and rotating the tablet to avoid the area that does not process touches correctly I can workaround it.

Have compiled a new kernel with latest patch 0107 patch change to nvec seems to have fixed not recognizing charger, ts seems to operate as before, still need amended clocks file (see below) and probably still need 2802 tegra_nand file not compared with patch yet so maybe not - and it still does not output sound through the speakers, sound via headphones works fine will look at and try to provide any logs or info that may help.

Have attached a modified tegra2_clocks file that is a merge between 2802 and the original 3.1, this will work with the new nvec in the 0107 patch as it has the i2c-div value set (not done in 2802 file but need due to change in nvec) the original file still does not boot as I said before due to this commit I think as its the only thing not merged into this new file and when it is results in a non-flashing boot image.

Eduardo hopefully you can see something that may be causing this as I am sure you would rather use the original file rather than another workaround.

edit - attached a zip of logcat and dmesg from latest build, going to look through and see if anything stands out but may be worth checking over to see if anyone else sees something - put tablet to sleep a couple of times to give that info and listened to audio (I don't have 3g so wi-fi only also newer version of the nvidia libs used) did notice also that when mtp connected it did display the sd-card and the dirs but not the content of those dirs ?

edit2 - Attached my latest config just for info, first impressions of my latest build are so far good seems more stable

tegra2_clocks666ver.rar

Lumberjack.zip

.config0207_666.rar

Edited July 2, 2012 by brucelee666

[Guest Scanno]

OK while I have a moment, touchscreen not fully working but with a mixture of the touch input it has and mouse and rotating the tablet to avoid the area that does not process touches correctly I can workaround it.

Have compiled a new kernel with latest patch 0107 patch change to nvec seems to have fixed not recognizing charger, ts seems to operate as before, still need amended clocks file (see below) and probably still need 2802 tegra_nand file not compared with patch yet so maybe not - and it still does not output sound through the speakers, sound via headphones works fine will look at and try to provide any logs or info that may help.

Have attached a modified tegra2_clocks file that is a merge between 2802 and the original 3.1, this will work with the new nvec in the 0107 patch as it has the i2c-div value set (not done in 2802 file but need due to change in nvec) the original file still does not boot as I said before due to this commit I think as its the only thing not merged into this new file and when it is results in a non-flashing boot image.

Eduardo hopefully you can see something that may be causing this as I am sure you would rather use the original file rather than another workaround.

edit - attached a zip of logcat and dmesg from latest build, going to look through and see if anything stands out but may be worth checking over to see if anyone else sees something - put tablet to sleep a couple of times to give that info and listened to audio (I don't have 3g so wi-fi only also newer version of the nvidia libs used) did notice also that when mtp connected it did display the sd-card and the dirs but not the content of those dirs ?

Will try to build the kernel with the nvec and your tegra2_clocks.c. (and the tegra_nand from 2802).

Hopefully I can tackle the ppp problem I am having (only with my 3g dongle). Also I have wifi lockups when disabling wifi when I have the 3g single inserted in USB host mode (driver cannot be loaded after it has been disabled). Anyway I will see tonight.

P.s. It would be nice to have the old USB mass_storage back :-)

[Guest Daedric1383]

Hello Scanno

i tried your B4 with 3.1 kernel, and even in peripheral mode, my EM770W would not work (same ppp error)

Also, had a few cases of the tablet shuting down after screen off...

[Guest richardmlea]

Hello Scanno

i tried your B4 with 3.1 kernel, and even in peripheral mode, my EM770W would not work (same ppp error)

Also, had a few cases of the tablet shuting down after screen off...

I am getting the odd random reboots too, me it seems to happen while there is a lot of SD card activity (installing or restoring apps with link2sd auto-moving to the SD card has crashed it a couple of times.

The EM770w connects and registers on my mobile network while the wifi is on but as soon as wifi is turned off the signal bar on the notification bar goes grey and 3 network disappears from quick settings, no connection. GPS if still working as beta 3. Still bad SNR and reboots if you power off GPS as beta 1,2,3. but working.

I will try to do a logs of these issues if I get a chance.

[Guest Scanno]

Eduardo, Brucelee666

I am at a loss... 3g os not working with the new kernel with the latest patches (also not with the old). Logcat keeps saying that the kernel does not support ppp. It is configured. I compared my config with the config from BruceLee666 and the lines regarding PPP are te same. Perhaps there are config changes that need to be applied with the 3.1 kernel that i am missing.

With regard to HDMI... this is not working. Logcat shows messages about gralloc not available. This with both the old prop. files as with the new ones...

Do not have time now for logcats because its late here and have to get to work in 6 hours... so need sleep.

EDIT:

Ok here is the dmesg: https://dl.dropbox.com/u/15203478/logs/dmesg.txt

Here is the logcat: https://dl.dropbox.com/u/15203478/logs/logcat.txt

This is with the HDMI problem.

Edited July 2, 2012 by Scanno

[Guest Daedric1383]

Eduardo, Brucelee666

I am at a loss... 3g os not working with the new kernel with the latest patches (also not with the old). Logcat keeps saying that the kernel does not support ppp. It is configured. I compared my config with the config from BruceLee666 and the lines regarding PPP are te same. Perhaps there are config changes that need to be applied with the 3.1 kernel that i am missing.

With regard to HDMI... this is not working. Logcat shows messages about gralloc not available. This with both the old prop. files as with the new ones...

Do not have time now for logcats because its late here and have to get to work in 6 hours... so need sleep.

Let's do this by the numbers: How does pppd check for ppp support in the kernel ??

Update: there's a file, in /etc : init.gprs-pppd, chmod 755 it (you must remount /system as rw), and run it.

You'll see that pppd actually works ok.

Your problem, is permissions.

Also, i HATE clockworkmod. Every time i flash anything through there, and reboot, it works ok on 1st boot, but after i reboot from within android, black screen.

Would you be so kind to release a nvflash version ?

Edited July 2, 2012 by Daedric1383