Advent Vega kernel source code now available!

[Guest a_appleby]

ZRAM is very good at keeping compressed swap in memory. Make sure to have plenty of total RAM memory or this will hang the system (like it does for me).

When we have the working set of boot args, we can also use ZRAM as storage for swap.

To use it, you have to do the following:

Apply the patch I attached, enable swap in the config and enable drivers / staging / compressed ram disk

For a 64MB ramdisk used as swap:

echo $((64*1024*1024)) > /sys/block/zram0/disksize

mkswap /dev/block/zram0

swapon /dev/block/zram0

To remove the swap from the system and free memory:

swapoff /dev/block/zram0

echo 1 > /sys/block/zram0/reset

30-50MB of memory swap takes up about 10-20MB of real memory inside a zram disk.

http://pastebin.com/7w3YrPxQ

update:

A zram swap disk of 80MB eats up 25MB of RAM.

Edited August 1, 2011 by a_appleby

[Guest wooshy1]

Please upload the changed files.

I couldn't boot it with the changes you recommended.

Are you talking about booting the system.img from rebel1 on the Vega from the nand? If so, I can help you with that if you wish.

I will update this post with some goodies in a short while.

do not FLASH a kernel produced with these settings as my current wip has several other issues including no sdcard support, bluetooth, wlan, recovery etc etc

Here is my .config file : http://pastebin.com/0WYc5Bii

diff file on my .config vs rebel1 git config : http://pastebin.com/PBXSwwk7

Here is the board-shuttle.h : http://pastebin.com/37RDWLTz

Here is my boot.img : http://www.megaupload.com/?d=Z0OFTLZM

You can fastboot the above boot image with :

./fastboot -i 0x955 -b 0x10000000 -c "mem=512M@0M vmalloc=64M video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 tegraboot=nand mtdparts=tegra_nand:2048K@6784K(misc),5120K@9344K(recovery),8192K@14976K(boot),151808K@23680K system),32768K@176000K(cache),4096K@209408K(staging),309760K@214016K(userdata)" boot boot.img

Edited August 1, 2011 by wooshy1

[Guest Cass67]

do not FLASH a kernel produced with these settings as my current wip has several other issues including no sdcard support, bluetooth, wlan, recovery etc etc

Here is my .config file : http://pastebin.com/0WYc5Bii

diff file on my .config vs rebel1 git config : http://pastebin.com/PBXSwwk7

Here is the board-shuttle.h : http://pastebin.com/37RDWLTz

Here is my boot.img : http://www.megaupload.com/?d=Z0OFTLZM

You can fastboot the above boot image with :g

./fastboot -i 0x955 -b 0x10000000 -c "mem=512M@0M vmalloc=64M video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 tegraboot=nand mtdparts=tegra_nand:2048K@6784K(misc),5120K@9344K(recovery),8192K@14976K(boot),151808K@23680K system),32768K@176000K(cache),4096K@209408K(staging),309760K@214016K(userdata)" boot boot.img

Hi woosh...

There seems to be a lot of diffs between the stock .config and your own... Can you explain some of the required and some of the hacked.. its just working from the stock we seem to have hit a balance of usefulness as some of your config is just not there on what we are using... And I'm not sure ever will be...

Cheers

Cass

[Guest Cass67]

Woosh,

Didn't mean that to sound harsh but I'm trying to get to the bottom of all the info we have... What you posted is good infox I'm just not sure what I'm missing from it..

Tx

Cass

[Guest a_appleby]

Hi woosh...

There seems to be a lot of diffs between the stock .config and your own... Can you explain some of the required and some of the hacked.. its just working from the stock we seem to have hit a balance of usefulness as some of your config is just not there on what we are using... And I'm not sure ever will be...

Cheers

Cass

Woosh,

Didn't mean that to sound harsh but I'm trying to get to the bottom of all the info we have... What you posted is good infox I'm just not sure what I'm missing from it..

Tx

Cass

Here's what seems to be safe to use:

# CONFIG_HIGHMEM is not set

CONFIG_NVMAP_CARVEOUT_KILLER=y

CONFIG_NVMAP_CARVEOUT_COMPACTOR=y

CONFIG_NVMAP_SEARCH_GLOBAL_HANDLES=y

Edited August 2, 2011 by a_appleby

[Guest Cass67]

CONFIG_NVMAP_SEARCH_GLOBAL_HANDLES=y

You think we need this one ?

[Guest a_appleby]

You think we need this one ?

It doesn't make any difference for memory usage patterns.

That kernel booted via fastboot still eats up the memory and gets to a point where it has about 100-140 MB of free memory.

Since all applications were purged from memory when I saw it was at 100-140 MB of free memory, it rose up to 260-290 and then went quickly back down to 160-200. Something is still going on with the video RAM memory. It just doesn't free it like it should.

Switching to the latest nvidia kernel seems like a pretty good idea. What do you folks think?

[Guest Cass67]

Switching to the latest nvidia kernel seems like a pretty good idea. What do you folks think?

Sounds like more work to port vega specific stuff to that kernel when we are in ok shape with this one ... One for Eduardo to talk to id guess as he has done the majority of the porting...

Edited August 2, 2011 by Cass67

[Guest ejtagle]

Sounds like more work to port vega specific stuff to that kernel when we are in ok shape with this one ... One for Eduardo to talk to id guess as he has done the majority of the porting...

Going to .38+ will be a problem, specially the sound subsystem, that changed quite a bit. And Nvidia hasn't updated the sound layer in that kernel (some drivers that are required for sound to work, specially the mixer and DAS (digital audio switch, were removed from the .38 kernel, probably in the hopes of being rewritten.. something that didn't happen until now...), so, even if it could be done, i fear Android will not like that .38+ sound subsystem.

But, the problem with GPU memory semms mostly related to the user space libraries. There was a bug with the first .36 GPU libraries, that unfortunately affects us: When a process crashes (probably , by running out of memory), the GPU memory used by that process was NOT freed. Eventually, leading to an unrecoverable system out of memory crash.

That is why i'd suggest, trying to use the latest GPU libraries (/lib/* and (/bin/*) ), even if we have to use them with an older image. We could also use part of the new .38+ kernel (specifically, the GPU memory allocator .. as suggested and tried by a_appleby when he was trying this.

Regards

Eduardo

PS: Still trying to figure out why reboot does not work... Everything seems fine ... Perhaps the bootloader ...

[Guest a_appleby]

Going to .38+ will be a problem, specially the sound subsystem, that changed quite a bit. And Nvidia hasn't updated the sound layer in that kernel (some drivers that are required for sound to work, specially the mixer and DAS (digital audio switch, were removed from the .38 kernel, probably in the hopes of being rewritten.. something that didn't happen until now...), so, even if it could be done, i fear Android will not like that .38+ sound subsystem.

But, the problem with GPU memory semms mostly related to the user space libraries. There was a bug with the first .36 GPU libraries, that unfortunately affects us: When a process crashes (probably , by running out of memory), the GPU memory used by that process was NOT freed. Eventually, leading to an unrecoverable system out of memory crash.

That is why i'd suggest, trying to use the latest GPU libraries (/lib/* and (/bin/*) ), even if we have to use them with an older image. We could also use part of the new .38+ kernel (specifically, the GPU memory allocator .. as suggested and tried by a_appleby when he was trying this.

Regards

Eduardo

PS: Still trying to figure out why reboot does not work... Everything seems fine ... Perhaps the bootloader ...

Eduardo, I didn't mean to say we should port everything to .38 or anything else newer than .36. Our problem is I have tried to apply some patches nvidia applied to their 11.2.x tree and it wasn't even booting. I can't tell if the patches themselves were breaking the kernel or if the device itself is damaged somehow.

Can you recommend some other version of the gpu drivers we should try, 3,1, 3.2 or some other drivers? Can you offer some hints for porting the allocator from something newer?

[Guest ejtagle]

Eduardo, I didn't mean to say we should port everything to .38 or anything else newer than .36. Our problem is I have tried to apply some patches nvidia applied to their 11.2.x tree and it wasn't even booting. I can't tell if the patches themselves were breaking the kernel or if the device itself is damaged somehow.

Can you recommend some other version of the gpu drivers we should try, 3,1, 3.2 or some other drivers? Can you offer some hints for porting the allocator from something newer?

I will try to backport the newest allocator to the .36 kernel. I assume it should not be hard to do ... probably replacing the files in /drivers/video/tegra with the newest ones would be enough ... Will try it later myself

Eduardo

[Guest Cass67]

The autorotation can easily be solved. The accelerometer driver exports its data as an standard linux device input event.. All we need is a library that reads them. And that library is present inside the epad-US8445.zip file, as system\lib\hw\sensors.tegra.so . The only difference is that the library expects the device to be called 'accelerometer_tegra' but the current accelerometer driver is exporting it as 'accelerometer' . So, either we could binary edit the library and rename 'accelerometer_tegra' to just 'accelerometer' or we could change the accelerometer to export its name as 'accelerometer_tegra' ... You choose ;) --

Hi Eduardo,

Where exactly in the kernel would i look to change the name of this export? I grepped everything i could find in there and nothing obvious stood out ... Editing the library seems not to work either..

Cheers

Cass

[Guest brucelee666]

Hi Eduardo,

Where exactly in the kernel would i look to change the name of this export? I grepped everything i could find in there and nothing obvious stood out ... Editing the library seems not to work either..

Cheers

Cass

Cass67 try "drivers/input/misc/bma150.c"

[Guest a_appleby]

I will try to backport the newest allocator to the .36 kernel. I assume it should not be hard to do ... probably replacing the files in /drivers/video/tegra with the newest ones would be enough ... Will try it later myself

Eduardo

Let us know how it went. Thanks!

Hi Eduardo,

Where exactly in the kernel would i look to change the name of this export? I grepped everything i could find in there and nothing obvious stood out ... Editing the library seems not to work either..

Cheers

Cass

I think it's not being exported properly right now. That's only a guess because I didn't find anything either.

[Guest BillyBobJoe]

Cass67 try "drivers/input/misc/bma150.c"

Far too quick for me Bruce, I had just gone for the /arch/arm/mach-tegra/board-shuttle-sensors.c and worked my way back.

I'm thinking that the init just need a simple change and no need to edit any other files.(correct me if I’m wrong)

This will also help with any porting in the future or if we need up switching to a different ROM base or to version 3.1 or 3.2 of honeycomb. As we will forget that we edited that sensor.so.

Billy..

[Guest Cass67]

Cass67 try "drivers/input/misc/bma150.c"

Yeah ive looked there .. it makes no sense to me to have something defined in there as tegra_accelerometer .. bma150 is the module for this.. i could be wrong but that file looks ok to me compared to all others ive checked it against ..

Cheers

Cass

Edited August 3, 2011 by Cass67

[Guest Cass67]

Cass67 try "drivers/input/misc/bma150.c"

Yeah ive looked there .. it makes no sense to me to have something defined in there are tegra_accelerometer .. bma150 is the module for this.. i could be wrong but that file looks ok to me compared to all others ive checked it against ..

EDIT :- In the .32 kernel we seem to have this referenced in board-nvodm.c

#ifdef CONFIG_INPUT_TEGRA_ODM_ACCEL

static struct platform_device tegra_accelerometer_device = {

.name = "tegra_accelerometer",

.id = -1,

};

But the new kernel appears not to have this structure ... It may just be a matter of finding out where to define this and add it to the shuttle board file ....

Cheers

Cass

[Guest ejtagle]

Yeah ive looked there .. it makes no sense to me to have something defined in there are tegra_accelerometer .. bma150 is the module for this.. i could be wrong but that file looks ok to me compared to all others ive checked it against ..

EDIT :- In the .32 kernel we seem to have this referenced in board-nvodm.c

#ifdef CONFIG_INPUT_TEGRA_ODM_ACCEL

static struct platform_device tegra_accelerometer_device = {

.name = "tegra_accelerometer",

.id = -1,

};

But the new kernel appears not to have this structure ... It may just be a matter of finding out where to define this and add it to the shuttle board file ....

Cheers

Cass

look into bma150.c, for

ctx->input->name = "bma150"

Instead of "bma150", it should be "accelerometer_tegra" if you want sensors.tegra.so to recognize the accelerometer automatically ..

Or edit the library replacing "accelerometer_tegra" by "bma150" . Be creful there, as there is a "tegra_accelerometer" that must NOT be changed!

Edited August 3, 2011 by ejtagle

[Guest Cass67]

look into bma150.c, for

ctx->input->name = "bma150"

Instead of "bma150", it should be "accelerometer_tegra" if you want sensors.tegra.so to recognize the accelerometer automatically ..

Or edit the library replacing "accelerometer_tegra" by "bma150" . Be creful there, as there is a "tegra_accelerometer" that must NOT be changed!

Thanks, I think its more prudent to fix this at the kernel level than edit the lib just in case we change builds, we would have to continue to do this for each and every change.. I did try adding bma150 to the lib but I probably got it in the wrong place ;)

Cheers

Cass

[Guest Cass67]

Cass67 try "drivers/input/misc/bma150.c"

Heh, now you've proven your kernel kung fu strong tell me where the it7260 edits need done so as to fix the calibration app for screen as that's next on the list ;)

[Guest ejtagle]

Heh, now you've proven your kernel kung fu strong tell me where the it7260 edits need done so as to fix the calibration app for screen as that's next on the list ;)

The IT7260 calibration app is a lost case. The interfaces that app was using to communicate with the ts were, not only dangerous, but very unstable and not standard at all. They were removed from the driver and i don't plan to port them,as they constitute a huge security hole. To recalibrate the TS, all that is needed is to write any value to the /sysfs/platform/devices// ... well, i promise to tell latel. I cant remember the exact location right now.

[Guest Cass67]

Thanks Eduardo, you have saved me a couple of more days trying to resolve this, should have pinged you first before.I wasted today, no fun in that though ;)

Thanks again

Cass

[Guest wooshy1]

I suspect we may need:

CONFIG_BT_HCIUART_BCSP=y

as bluez csr_tegra support uses HCI_UART_BCSP to talk to vega bluetooth

[Guest newbe5]

Right, just to point out a pretty critical issue. There has been about 4 or 5 users of the new Honeycomb port using this kernel, who have experienced a "Burning Smell" and in one case apparently actual smoke coming from their speakers. One user is claiming that it actually blew one of his speakers.

Obviously this is very worrying, I have used this ROM a LOT and I haven't experienced anything like this yet, but it could be due to variations in the manufacturing quality of the speakers on certain models. I think it may be due to the new "Extremely Loud" audio volume. How easy is it to turn the max volume level down to try and avoid this happening? Or are there voltage controls for the speakers that could also be causing this?

newbe5

Edited August 3, 2011 by newbe5

[Guest a_appleby]

Right, just to point out a pretty critical issue. There has been about 4 or 5 users of the new Honeycomb port using this kernel, who have experienced a "Burning Smell" and in one case apparently actual smoke coming from their speakers. One user is claiming that it actually blew one of his speakers.

Obviously this is very worrying, I have used this ROM a LOT and I haven't experienced anything like this yet, but it could be due to variations in the manufacturing quality of the speakers on certain models. I think it may be due to the new "Extremely Loud" audio volume. How easy is it to turn the max volume level down to try and avoid this happening? Or are there voltage controls for the speakers that could also be causing this?

newbe5

There are some voltages variables for the speakers. Lowering those slightly along with the volume might help.

The default brightness has to be lowered a bit as well.

Volume settings can be found in sound/soc/codecs/alc5624.c.

I am still looking for the specific variables. I forgot where they are and what they were called.

All in all, we must lower all these values to reduce the chance of overheating and damaging more devices.

default brightness:

arch/arm/mach-tegra/board-shuttle-gpu.c:

.max_brightness = 255,

.dft_brightness = 224,

.pwm_period_ns = 1000000,

.dft_brightness should be set to something lower like 200

speaker voltage:

WARNING!!! DON'T INCREASE THIS ABOVE THE DEFAULT OR THE DEVICE WILL DIE!!

.spkvdd_mv = 5000, /* Speaker Vdd in millivolts */

It should be safe to set this to something like 4700-4900.

It's very likely those who had burnt their speakers and saw smoke coming out of them got this issue because of the voltage.

You can easily ruin speakers so that they sound bad with high volume, but it's a bit more difficult to make them smoke. You have to put quite some current through them.

Edited August 3, 2011 by a_appleby