Database Develop

[DEVS] You too can build a CM-based AOSP ROM

Obviously, I am going to be cleaning up some bugs with the CM7 build...
But, for those of you who might be inclined to develop a CM-based AOSP ROM, feel free to check out my github source to see what's involved:
https://github.com/Hashcode
Or you can:
repo init -u https://[email protected]/Hashcode/cm4D3.git
repo sync
To pull the entire set of android files that I use for compiling the current build.
Please note that the Board Config is currently setup to generate Safestrap .zip files.

Great job
Thank you for everything you have done for the droid 3!

Is there a kitchen for DROID 3 roms. Running windows 7
Sent from my DROID3 using xda premium

You need to be running Linux to do this hardcore kind of stuff.

Like Ubuntu I had it set up in VB and detain. Was just wondering if there was some thing for Motorola roms out there. I have had HTC phones this my first moto with android on it.
Sent from my DROID3 using xda premium

I'm starting to tinker with building (learning, actually) ROMs. I'm running Linux Mint Debian - has there been a kitchen built for D3?

Hashcode said:
repo init https://[email protected]/Hashcode/cm4D3.git
Click to expand...
Click to collapse
That should be
Code:
repo init -u git://github.com/Hashcode/cm4D3.git -b gingerbread
or whatever URL you want to use from the access URL box at https://github.com/Hashcode/cm4D3.
And of course "gingerbread" could be "ics" if your excitement about being on the bleeding edge overrides what should be a fairly sensible fear reaction to the term "bleeding edge".
@Hashcode: You don't use your own ALSA repos? (Comparing with my own generated manifest for your project...)
Also, are you planning on pulling newer Gingerbread manifest changes into your tree? I noticed CyanogenMod have gained a u8150 device tree, and I happen to have one of those, but your manifest doesn't list it...
Ooops. I have a u8510. >_< But the question stands...

TBBle said:
That should be
Code:
repo init -u git://github.com/Hashcode/cm4D3.git -b gingerbread
or whatever URL you want to use from the access URL box at https://github.com/Hashcode/cm4D3.
And of course "gingerbread" could be "ics" if your excitement about being on the bleeding edge overrides what should be a fairly sensible fear reaction to the term "bleeding edge".
@Hashcode: You don't use your own ALSA repos? (Comparing with my own generated manifest for your project...)
Also, are you planning on pulling newer Gingerbread manifest changes into your tree? I noticed CyanogenMod have gained a u8150 device tree, and I happen to have one of those, but your manifest doesn't list it...
Ooops. I have a u8510. >_< But the question stands...
Click to expand...
Click to collapse
Thank you for pointing out that my repo init line was wrong. I fixed it for those that were having issues.
Also, for those watching my manifest for ICS, I'm getting an error when syncing:
error: revision refs/heads/master in manifests not found
I'm trying to fix that. Correction: Fixed it and double-checked with a repo sync.
Some quick answers:
- I tried to customize the alsa source to fix some of the audio issues. But it ended up being a bit more complex than just changing ALSA. Motorola added a layer into the audio system for handling HDMI audio and in call audio volume.
When you build stock AOSP Gingerbread using the alsa drivers, the libaudio.so file ends up being all of the ALSA calls. If you examine the libaudio from the D3, you'll see that it is nothing of the sort. It's the customized mixer lib for RDS voice and HDMI audio. There's another lib from the phone: libaudio_ext.so which ends up being the alsa calls.
All of which made customizing just the alsa code risky at best as the further away from the version of alsa that was used on the phone, the less likely that the custom libaudio would work.
I probably still have the unfinished hardware_alsa git out on github, but it's not active in the current build.
- I can occasionally check for updates to the CM7 manifest and add them, or if you fork the manifest and add it in there that works as well.
Side Note: I may need to pick your brain on an EGL 0x0500 erorr I'm getting in the ICS code. I'm fairly certain it's an enum value that our version of the PowerVR drivers aren't set to handle, but I'd like to confirm that for my troubleshooting. And it seems that you might have some knowledge in that area

Where/how does someone begin working on building a ROM once they've downloaded these files? I'd rather dive into code and learn Android rather than using a menu driven wizard. Is there a tutorial somewhere? What tools are needed?
Sent from my DROID3 using XDA App

Phibernaut said:
Where/how does someone begin working on building a ROM once they've downloaded these files? I'd rather dive into code and learn Android rather than using a menu driven wizard. Is there a tutorial somewhere? What tools are needed?
Sent from my DROID3 using XDA App
Click to expand...
Click to collapse
This would be the starting point that you're looking for:
http://source.android.com/

Hashcode said:
Side Note: I may need to pick your brain on an EGL 0x0500 erorr I'm getting in the ICS code. I'm fairly certain it's an enum value that our version of the PowerVR drivers aren't set to handle, but I'd like to confirm that for my troubleshooting. And it seems that you might have some knowledge in that area
Click to expand...
Click to collapse
Some, but probably not enough. I'm happy to look, but I'm actually moving internationally tomorrow so I may not have 'net access for a week or so. >_< (That's why I've been trying so hard to get backup working. ^_^)
Once I'm settled in I will probably use fdisk to repartition my device or have a poke at hacking sd-ext support into safestrap, so I can start playing with custom ROMs.
Did you see my safestrap-ME863 nandroid patch in the Safestrap thread, BTW? It's got a couple of TODOs, but seems safe and roughly correct to me. http://forum.xda-developers.com/showpost.php?p=19683372&postcount=249
It could also form the basis for detecting when /preinstall can't be used as safe-system although I didn't look to see if there's already code to do that.

Does anyone know of a site where I can peek at reference code for random things (Apps, Kernal etc.)? It'll make it easier to understand how the code works. I haven't look at any code yet so I don't even know what language apps and the os are programmed in. (Java, C, C++, Ruby)
Sent from my D3-CM7-SS using xda premium

tenchi19134 said:
Does anyone know of a site where I can peek at reference code for random things (Apps, Kernal etc.)? It'll make it easier to understand how the code works. I haven't look at any code yet so I don't even know what language apps and the os are programmed in. (Java, C, C++, Ruby)
Click to expand...
Click to collapse
Just pull down the repo as Hashcode describes in this thread - you'll have all of the Android source. To the best of my knowledge, it comprises of mostly C, C++, and Java, but there is probably a smathering of some other things like ASM, perl, BASH, etc.
And to those who are asking if there is a kitchen, there is, it's called make

MultiROM for Nexus 7 - interest survey

UPDATE: released - http://forum.xda-developers.com/showthread.php?t=2011403
Hi,
I am recognized developer here on XDA, and my "main" creation is multi-boot solution for LG Optimus One, MultiROM: http://forum.xda-developers.com/showthread.php?t=1304656.
The thread is kinda chaotic, so let me explain: the main ROM is in internal memory of the phone, while the other ROM(s) are on the ext partition of the sd-card. ROM on sd-card are installed via modified recovery, you just select the ZIP file and it is installed to the sd-card. During boot, a simple boot manager appears, which allows you to choose which ROM to boot (see attachments).
I've recently got my very own Nexus 7, one of the only like 2k which arrived to Czech Republic so far, so the question is following:
Do you think that it is worth it to port MultiROM to Nexus 7?
There are of course some differences between N7 and Optimus One, mainly the lack of sd-card, I can imagine having multiple ROMs in internal memory and/or booting from USB flash drive, though.
Another thing is that there are other systems than Android available on N7, I believe(?). MultiROM would need some work to support those, because the boot manager runs after the kernel is loaded, so it cannot change it, unless some workaround is used, maybe reflashing the kernel after selection of the ROM and then silent reboot, or kexec (anybody has it running on N7?).
So, what do you think?

I would be very interested in this, especially if you can dualboot between Ubuntu/ChromeOS and Android.

+1
Sent from my Nexus 7 using xda app-developers app

We have the same question on the French forum???? : http://forum.frandroid.com/topic/125722-dualboot-sur-nexus-7/

I would say “no". But then again, I doubt a lot of people would comment just to say no like me. I would think most who comment here would say yes.
Sent from my iPhone using Tapatalk

i was just sitting back talking with sblood86 about this, if you create multirom support, cannibalopentouch can be properly ported to support multiboot.
i would find this very useful when ubuntu comes around to being more stable and usable. bouncing between ubuntu and jellybean would be awesome. especially for us 32gb users!

+1
#Galaxy Nexus HSPA+

I gotta be honest, this seems like a great idea and could be very fun, but that seems to be the limit: fun. I personally don't feel there's enough development on the N7 to warrant the need to toggle between builds for more than a novelty sake.
That being said, I would like to see this come to fruition for the hope that it inspires more development on the N7. You got my vote, good luck!

Sharpen3d said:
I gotta be honest, this seems like a great idea and could be very fun, but that seems to be the limit: fun. I personally don't feel there's enough development on the N7 to warrant the need to toggle between builds for more than a novelty sake.
That being said, I would like to see this come to fruition for the hope that it inspires more development on the N7. You got my vote, good luck!
Click to expand...
Click to collapse
it is fun, development and testing is fun. being able to flash new roms to try them out and not have to keep backing up/wiping/restoring would be great. having bone stock on one partition and super custom aokp or whatever on the other would also be great. a lot of custom add ons leads to new oem features n the long run.
Sent from my Nexus 7 using xda premium

Sounds very interesting would love to see this on the nexus 7
Sent from my LT18i

+1
Dual boot android/ubuntu

I think dual boot would be extremely useful, especially if it could be made to boot to a rom on otg devices. Ext hdds, thumbdrives, etc.
Sent from my Nexus 7 using xda premium

Shut up and take my nexus
Haha yeah I love dual boot on my s3, it will be pretty awesome to have it on the n7.
Don't forget the OTG charging patch.
Sent from my GT-I9300 using xda premium

I'd say "why not?"

I'd give this a go, as another user stated it would be pretty nice to not have to backup, flash, restore to try out a new rom and then if you don't like it restore. This would probably only be useful for people that have 32 GB (like me, i have a ton of games installed and still have about 20 GB free ) and possibly those with 16 GBs. I remember I tried a multi-boot manager on my Incredible about a year ago and it didn't work that well, but then again that was about 2 years ago.
Multi-booting Android, ChromeOS and Ubuntu via this would be EPIC

+1 more..
Would be awesome to have a rom that you could play with and not Bork your device every time . For rom Developers and moders this could be a invaluable tool..
Would love to have total stock experience and still be able to use the bleeding edge rom development features...
Please please .

Okay, so the main reason seems to be dual-booting ubuntu. That looks cool to me, and should be possible from what I can tell. But there is one problem - it would require kexec, and it does not work for me. It just freezes the device.
I just enabled kexec in kernel (CONFIG_KEXEC=y) and tried some kexec binaries for other devices, and the one from debian, but result is the same, just freeze (or nothing happens on the screen, adb or anything for a long time). /proc/last_kmesg looks like this:
Code:
[ 187.155128] CFG80211-ERROR) wl_cfg80211_disconnect : Reason 3
[ 187.163564] cpu_up(2)+
[ 187.165085] CPU2: Booted secondary processor
[ 187.165742] cpu_up(2)-
[ 187.170464] cfg80211: Calling CRDA for country: CN
[ 187.173526] Switched to NOHz mode on CPU #2
[ 187.173858] wl_android_wifi_off in
[ 187.174192] Wake32 for irq=340
[ 187.174332] Disabling wake32
[ 187.174407] gpio bank wake found: wake32 for irq=67
[ 187.174481] Disabling wake32
[ 187.174670] wifi_set_power = 0
[ 187.174807] Powering off wifi
[ 187.475191] =========== WLAN placed in RESET ========
[ 187.479449] max77663-rtc max77663-rtc.0: rtc_shutdown: clean alarm
[ 187.479692] wl_android_priv_cmd: Ignore private cmd "BTCOEXMODE 2" - iface wlan0 is down
[ 187.482678] dhd_prot_ioctl : bus is down. we have nothing to do
[ 187.482765] dhd_aoe_hostip_clr failed code -1
[ 187.482899] dhd_prot_ioctl : bus is down. we have nothing to do
[ 187.482972] dhd_aoe_arp_clr failed code 1
[ 187.509574] smb347_shutdown+
[ 187.511945] smb347_shutdown-
[ 187.512152] Starting new kernel
[ 187.512239] Bye!
Problem is, I have no idea how to debug what is wrong. Anybody tried kexec on N7? Or am I just doing something wrong with the parametrs, I did this:
Code:
kexec -l ./zImage --initrd=./boot.img-ramdisk.cpio.gz --command-line="$(cat /proc/cmdline)"
kexec -e

If we are already talking about a vote (one more), mine is definitely positive. I want to keep my Android Devices on genuine Google Rom:angel:, but I really want to try alternative Rom at the same time, or even install a linux distribution, so ...

Would it be possible to boot from USB?
It would be absolutely amazing to have the ability to boot USB if an image is detected. 8/16/32 is IMO pretty limited if the goal is to have multiple functional boots.
Ubuntu + Kaos Droid + Stock (as backup) would be amazing.

+∞

Moto X ROM on Razr M

The project is pretty much dead as it was a more or less a proof-of-concept, and our touchscreen drivers aren't built into the kernel, and I can't get past the device encryption screen, but I've got a Moto X stock image "booting" on my Razr M I'll upload it sometime today or tomorrow in the form of a TWRP backup in case anybody wants to tinker around with it and try to get this thing booting 100%
Hopefully if I get some free time, I can tinker around with it and maybe rebuild the boot.img and remove the encryption flag in the fstab, and see if there's something I missed regarding the touch screen. The Razr HD guys might have a better shot at as their touchscreen isn't like ours, and could potentially work.
It appears as if this 3.4 kernel on the X might make it into our 4.2 ROM (whenever that will come out), and that's why Motorola's taking a long time to get from 4.1 to 4.2
[email protected]:/ # cat /proc/version
Linux version 3.4.42-xline-gfd1a699-00157-gfb2f8fc ([email protected]) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Thu Jul 18 20:25:42 CDT 2013
Here's some images I've got of the goods: http://imgur.com/a/MfIRQ
Update: the touch issue is due to an invalid devtree, which is proprietary. Once kernel source drops, I might be able to manually override the kernel source to not detect the touchscreen via the devtree, but rather, hardcode it to use our touchscreen
Update 2: Boots! http://imgur.com/j9dMtR7
Still no touchscreen and probably won't happen anytime soon now we wait for kernel source

Source should be out soon ... then CM will get it
And there are some annoyances anyway, such as checking SHA1 checksum for modules.
As for the ROM, use devtree from RAZR M! You'll also need to update a few XMLs in the framework.

Skrilax_CZ said:
Source should be out soon ... then CM will get it
And there are some annoyances anyway, such as checking SHA1 checksum for modules.
As for the ROM, use devtree from RAZR M! You'll also need to update a few XMLs in the framework.
Click to expand...
Click to collapse
I never changed the devtree so it's still the Razr M's one. I got an error in the dmesg saying invalid header in the devtree or something like that. Do you think we will need a new devtree for this 3.4 kernel?
Here's a dmesg output: http://pastebin.com/dpHwBddu
That line 34 is where I feel that the current 3.0.31 devtree for the Razr M might be incompatible with the 3.4 kernel
Sent from my XT907 using xda app-developers app

Ah I see. So we'll have to use our own devtree. Not a real problem, but it's easier to wait for the source and adapt our platform.

@JackpotClavin: Kernel source is out: http://sourceforge.net/projects/ultra.motorola/files/XT1080-XT1030/
btw. did you extract the defconfig from the kernel?

Skrilax_CZ said:
@JackpotClavin: Kernel source is out: http://sourceforge.net/projects/ultra.motorola/files/XT1080-XT1030/
btw. did you extract the defconfig from the kernel?
Click to expand...
Click to collapse
http://pastebin.com/kWqaWyB1
I literally just checked the opensource website like a half hour ago and it wasn't up then
That's from the Roger's sbf on your sbf website (thanks for that btw!)

Making progress on the device tree. I've got it to load up so far (it wasn't recognizing it before)

Hmm, the command to decompile devtree is "dtc -I dtb -O dts devtree.dtb > devtree.dts." right? It somewhat kicks me on bad magic when I extract devtree from the FXZ and also cut the first x bytes (so the magic is first).

I've never decompiled a devtree before. Is the one you're trying to decompile for the Moto X or the Razr M?
Originally, the devtree wasn't being read at all by the processor, then the only change I made to the kernel was for endianess format for compatability for the older devtrees (like the one the Razr M still has from the 3.0.31 kernel). Perhaps once the 4.2 upgrade comes around, they will update the devtree to be compatible with the 3.4 kernel, which will probably use big endian format like the Moto X does.
https://github.com/epinter/android_...mmit/8033dcc5ed05cb5ab52539acfd0cbee65a518863 (cherry-pick)
https://github.com/epinter/android_...mmit/c6dfc183e9ad497384ce5d99f088255a572c9193 (cherry-pick)
https://github.com/epinter/android_...n/blob/cm-10.1/arch/arm/mach-msm/Kconfig#L687 (add line #687)
It will get the 3.4 kernel to recognize a 3.0 kernel devtree

It's for Photon Q (same series as Razr HD / M etc.) and I think not all the phones from the Razr HD / Razr M / Photon Q / Atrix HD will get a 4.2 upgrade (somewhat looks to me that only Razr HD will get it). Besides we're not waiting just for that, are we

Skrilax_CZ said:
It's for Photon Q (same series as Razr HD / M etc.) and I think not all the phones from the Razr HD / Razr M / Photon Q / Atrix HD will get a 4.2 upgrade (somewhat looks to me that only Razr HD will get it). Besides we're not waiting just for that, are we
Click to expand...
Click to collapse
I think you know more than you are letting go
BTW do you think the sources for the x will help you guys with the work for the 3.4.y kernel and the other moto q com phones in CM?

It appears as if the devtree is written in a different structure from what the 3.0 kernel used which is making it annoying to direct the kernel to certain branches of the devtree. Things like parsing the devtree for the tdat filename which is needed for our touch interface is mapped out differently from 3.0 and I'm trying to put them together to work with the 3.0 devtree until we get one that's actually meant for the 3.4 kernel
Sent from my XT907 using xda app-developers app

@Skrilax_CZ Did you happen to see the devtree source files in the MotoX kernel source?
In arch/arm/boot/dts there's the source to make device trees.
make -j1 CROSS_COMPILE=arm-eabi- ARCH=arm msm8960ab-sasquatch-p2.dtb yields a .dtb file in arch/arm/boot that's supposed to be a devtree, but when I flash it on my device, the devtree still isn't recognized and there's no filesystem generated at /proc/device-tree. Do you think there might have to be an offset or something?

In devtree partitions, there are 5 interger values at the beginnig and the devtree is in little endian, instead of big endian.

How is this going guys?
Sent from my SCH-I535 using Tapatalk 4

Is there anything that we amateurs can help out with?
Sent from my XT907 using XDA Premium 4 mobile app

I'm definitely interested in this project. Touchless control, active display (!!!), assist, trusted devices, and motorola connect!

There isn't really anything we can do until the devtree is sorted out. I think we will have to wait until there's an official build with a 3.4 kernel and 4.2 from Motorola. I'm sure it isn't too far away
Sent from my XT907 using xda app-developers app

JackpotClavin said:
There isn't really anything we can do until the devtree is sorted out. I think we will have to wait until there's an official build with a 3.4 kernel and 4.2 from Motorola. I'm sure it isn't too far away
Sent from my XT907 using xda app-developers app
Click to expand...
Click to collapse
Since the touchscreen isn't currently working, you should use an OTG cable w/a mouse so you can navigate throughout the phone and see just how much of the rom actually works

I'll give it a try... Any new news on this project? I went to a vzw suite and their X is running 4.2.2...
Sent from my XT907 using XDA Premium 4 mobile app

[DEV-ONLY] Development related Discussions

Hey guys
First: THIS THREAD IS DEV-ONLY! All not development related posts will be deleted!
Now, working on AOSP last night, i found a derp in the device tree. This derp seems to be present in all device trees i have found for our device. So i thought it would be good to have one thread where such things can have an appropriate place, without making new threads over and over again. Also it is big advantage to have everything bundeled in one thread IMO.
I have registered a channel on freenode called "#p880-dev", so we can discuss everything in there
Feel free to join in
As already mentioned, I found a (most likely) typo in the device tree. Our battery's capacity is 2150mAh, but all device trees got 2050mAh.
See HERE
Now, to make it public, let's call some ppl in here
@Adam77Root, @Demetris, @arararagi, @kholk, @Rudjgaard, @dcos
(no particular order, just ROM devs i found in the section, building from source)

Good catch. Does anyone know what effect this has though?
The kernel directly reports the battery % through /sys/class/power_supply/battery/capacity

http://forum.xda-developers.com/showpost.php?p=46361993&postcount=344

Will push to Omni device tree.
BT tethering is also derped. The needed value in overlay is "bt-pan" instead of "bnep\\d".
Sent from my OmniROM-powered LG Optimus 4X HD

laufersteppenwolf said:
Hey guys
First: THIS THREAD IS DEV-ONLY! All not development related posts will be deleted!
Now, working on AOSP last night, i found a derp in the device tree. This derp seems to be present in all device trees i have found for our device. So i thought it would be good to have one thread where such things can have an appropriate place, without making new threads over and over again. Also it is big advantage to have everything bundeled in one thread IMO.
As already mentioned, I found a (most likely) typo in the device tree. Our battery's capacity is 2150mAh, but all device trees got 2050mAh.
See HERE
Click to expand...
Click to collapse
Thanks for the heads up and let me just say, great idea opening this thread. :good:
arararagi said:
Good catch. Does anyone know what effect this has though?
The kernel directly reports the battery % through /sys/class/power_supply/battery/capacity
Click to expand...
Click to collapse
Well I believe this mostly reflects on battery usage statistics, but maybe I'm wrong.
Reference: https://source.android.com/devices/tech/power.html#

In our kernel source there is a emc bw efficiency name error in
arch/arm/mach-tegra/tegra3_clocks.c line 3141 + 3142
bw = emc_bw_efficiency ?
(bw / emc_bw_efficiency) : bus->max_rate;
In arch/arm/mach-tegra/tegra3_emc.c is looking for u8 tegra_emc_bw_efficiency = 35;
and also same thing in arch/arm/mach-tegra/tegra3_emc.h extern u8 tegra_emc_bw_efficiency;

Demetris said:
In our kernel source there is a emc bw efficiency name error in
arch/arm/mach-tegra/tegra3_clocks.c line 3141 + 3142
bw = emc_bw_efficiency ?
(bw / emc_bw_efficiency) : bus->max_rate;
In arch/arm/mach-tegra/tegra3_emc.c is looking for u8 tegra_emc_bw_efficiency = 35;
and also same thing in arch/arm/mach-tegra/tegra3_emc.h extern u8 tegra_emc_bw_efficiency;
Click to expand...
Click to collapse
I think that's intentional. Maybe an LGE change. In the beginning of the tegra3_clk_shared_bus_update function, the emc_bw_efficiency is defined. It's initialized to tegra_emc_bw_efficiency_boost and is set to tegra_emc_bw_efficiency if the clock name is "3d.emc" and shared bus mode is enabled and set to ceiling mode.

Sometimes my laziness is beyond compare
Never bothered to look good into tegra3_clocks.c
Thanks adam huge derp from me
Could you care have a look into my mount options for a cherry-pick
Here they are:
HTML:
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,noatime,barrier=0,noauto_da_alloc,data=writeback wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 discard,noatime,nosuid,nodev,nomblk_io_submit,noauto_da_alloc,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 discard,noatime,nosuid,nodev,nomblk_io_submit,noauto_da_alloc,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/CAL /cal ext4 nosuid,nodev,barrier=1 wait
/dev/block/platform/sdhci-tegra.3/by-name/DRM /persist-lg ext4 nosuid,nodev,barrier=1 wait
/dev/block/platform/sdhci-tegra.3/by-name/MLT /mpt ext4 nosuid,nodev,barrier=1,data=ordered wait
/devices/platform/sdhci-tegra.2/mmc_host/mmc2 /storage/sdcard1 auto defaults voldmanaged=sdcard:auto
/dev/block/platform/sdhci-tegra.2/by-num/p1 /external_sd auto defaults recoveryonly
I find them to perform better than stock ones

Looks good to me.

Something we really lack are full SELinux policies. I'm calling out to you since I have little to no knowledge in this field. We should really fix this before the KitKat release. The audit2allow tool might help analysing the needed rules. What do you say?

Adam77Root said:
Something we really lack are full SELinux policies. I'm calling out to you since I have little to no knowledge in this field. We should really fix this before the KitKat release. The audit2allow tool might help analysing the needed rules. What do you say?
Click to expand...
Click to collapse
Well, I have the same problem as you do.... I have no idea about SELinux
Never been actually working on/with it. Let's hope @Demetris can help us out

Guys, I could use some help on the camera for AOSP... It's driving me crazy Whatever I try, it keeps FC'ing
Here's the logcat
It'd be great for someone having an Idea to "start" from
Thanks in advance

laufersteppenwolf said:
Guys, I could use some help on the camera for AOSP... It's driving me crazy Whatever I try, it keeps FC'ing
Here's the logcat
It'd be great for someone having an Idea to "start" from
Thanks in advance
Click to expand...
Click to collapse
I am not sure if this is it https://github.com/SlimRoms/frameworks_av/commit/3c2c4f8f8a4abdc61aa2321640b0b03a3a2661b7 but whatever it is it should be on frameworks_av .
I would look on the commits and see if there is anything else relevant there.

ezet said:
I am not sure if this is it https://github.com/SlimRoms/frameworks_av/commit/3c2c4f8f8a4abdc61aa2321640b0b03a3a2661b7 but whatever it is it should be on frameworks_av .
I would look on the commits and see if there is anything else relevant there.
Click to expand...
Click to collapse
no, already checked, it's neither frameworks/av, nor hardware/libhardware, nor hardware/libhardware_legacy...

laufersteppenwolf said:
no, already checked, it's neither frameworks/av, nor hardware/libhardware, nor hardware/libhardware_legacy...
Click to expand...
Click to collapse
frameworks/native? and frameworks/av? maybe, take them from cm?

penguin449 said:
frameworks/native? and frameworks/av? maybe, take them from cm?
Click to expand...
Click to collapse
I cannot just take another repo and replace it. But i sure did cherry-pick from it
laufersteppenwolf said:
Guys, I could use some help on the camera for AOSP... It's driving me crazy Whatever I try, it keeps FC'ing
Here's the logcat
It'd be great for someone having an Idea to "start" from
Thanks in advance
Click to expand...
Click to collapse
Little update to the problem: Whatever I do, I can't get around the SIGSEGV... Any ideas?
And the according logcat of course

Hmm ive spent some time investigating, but with a lack of understanding of the android camera implementation, its hard to narrow it down. I did find a post that at least gives us some leads
Have been doing some work on trying to get the camera to work... sadly no good news for now
I have fixed the HAL methods ( new camera HAL had some minor changes ), but still getting the same errors on load:
07-20 00:09:24.500: E/NvOmxCamera(162): createCameraObjects: graph creation failed! [0x80001005]
07-20 00:09:24.500: E/NvOmxCamera(162): createCameraObjects: Fail! [0x80001005]
07-20 00:09:24.500: E/NvOmxCamera(162): NvOmxCamera::createObjects :::: FAIL ::::::::::::::::: [0x80001005]
And on usage of the camera a segfault on PowerOnSensor.
The reason that it segfaults is basically because they forgot to add a check in cameraservice if the HAL module actually returned any working cameras. I have added logging to the cameraservice and manually called get_number_of_cameras on the HAL module.
07-20 00:09:24.500: D/CameraService(162): reported number of cameras: 0
So basically after graph creation fails the entire camera initializations stalls, but libcameraservice is also happy to work with 0 cameras aslong as there is a module ( oops ). Then calling a HAL method on some uninitialized pointer will not do much besides give a nice segfault of course.
Just to be sure the HAL module was working correctly i did call get_camera_info which should return the camera info defined in nvcamera.conf.
07-20 00:09:24.510: D/CameraService(162): camera info for camera 0 = 0 90
The entire graph creation process depends on omx and the graph error (0x80001005) is actually OMX_ErrorBadParameter.
So either our implementation of OpenMax is broken or there are other compatibility issues...
Click to expand...
Click to collapse
http://www.icsforums.com/comment/1315991#comment-1315991
Could there be a problem with the Openmax DL in aosp?

JoinTheRealms said:
Hmm ive spent some time investigating, but with a lack of understanding of the android camera implementation, its hard to narrow it down. I did find a post that at least gives us some leads
http://www.icsforums.com/comment/1315991#comment-1315991
Could there be a problem with the Openmax DL in aosp?
Click to expand...
Click to collapse
I thinks so, too, but I just cannot figure out what exactly the problem is...
Been cherry-picking most frameworks/av commits, but still no success...

Let's start a discussion about the new Android, a.k.a. KitKat. I compiled Omni 4.4 today, there were only a few build errors, those are trivial to fix. First it didn't boot, because now SELinux is set to enforcing mode by default. This can be fixed by modifying 'selinux_is_enforcing()' function in init.c to return always false or by setting 'ro.boot.selinux' property to 'permissive'. I had some errors with SurfaceFlinger (0x3 device version, need to revert only new blobs support.) and with sensors.tegra.so, it's complaining about a missing function.

Adam77Root said:
Let's start a discussion about the new Android, a.k.a. KitKat. I compiled Omni 4.4 today, there were only a few build errors, those are trivial to fix. First it didn't boot, because now SELinux is set to enforcing mode by default. This can be fixed by modifying 'selinux_is_enforcing()' function in init.c to return always false or by setting 'ro.boot.selinux' property to 'permissive'. I had some errors with SurfaceFlinger (0x3 device version, need to revert only new blobs support.) and with sensors.tegra.so, it's complaining about a missing function.
Click to expand...
Click to collapse
You may laugh, but I'm still trying to compile AOSP 4.4 I somehow had a broken source, so even pure AOSP for mako/hammerhead did not compile
But it is now, so would you mind sharing the commits you reverted in order to get SurfaceFlinger working? The same as in 4.3 I suppose, right?
And about SELinux, let's hope for CM to bring a proper SELinux for our device with CM11

Arch Linux running natively on Pixel C

Hi Guys, i'm there again,
https://www.youtube.com/watch?v=WQMGkCT9yy0&t=6s
On some free time, i could have run Archlinux natively on Pixel C,
Here are my instructions to play a bit with your device in order to have it working on your device too !
First some warnings :
- You have no warrantly it will work on your device, maybe it can break your device
- This is in a prealpha state, reserved for developpers :
- Wifi is not working, you will have to have an OTG adapter and an USB ethernet card in order to be connected
- GPU is not working (so yes the UI is very slow, consequence of the great resolution of the screen)
- DRM drivers of the google kernel are bugged as hell, for example the cursor won't be visible on the screen if you use an USB mouse.
- No sound
Working things :
- boot
- Touchscreen
- Display
- Gnome Desktop (but quite slow due to no harware acceleration)
How to make this work (Developpers only):
- Format your Data partition on your Pixel C in order to disable the default encryption of Data partition.
USE WITH CAUTION !
Code:
fastboot format userdata
- Install a stock kernel on your pixel C that disable forced data encryption, otherwise as soon as you will reboot to android, you will have to format your data partition again ! (you can flash superSu that will modify your stock kernel and will do that for you)
- Download the rootfs here : https://drive.google.com/open?id=0BzWwMqZZvtXSTDhZWTA0RUhrTjg
- Untar the rootfs in your data partition in /data (so that the directories bin,etc... are in /data/Arch). You can use TWRP and a comandline for this (tar -xzpvf Arch.tar.gz )
- Download the kernel here : https://drive.google.com/open?id=0BzWwMqZZvtXScUsyYXBwaXpoRm8
Now enter fastboot mode and run :
Code:
fastboot boot boot_Data.img
if you want to flash it on your boot partition :
DO THIS WITH CAUTION !
Code:
fastboot flash boot boot_Data.img
Your Arch sytem will boot
user : alarm
password :alarm
Note that a sshd deamon is running and accessible on the network !
Good luck !
If you're happy of this work and you want to have more detailed instructions please pay me a beer ! Because developing for Pixel C is time consuming
http://paypal.me/MathieuTournier

Reserved

Download links are now available

Great work Samt434!!!!
Finally a desktop linux distro for our beloved pixel c.

:Q______

Wow, this is amazing! I'm interested in the modifications to 'stock' Arch you did to achieve this. Is it running a modified recent Arch kernel or what? Great work!

Arch linux domining the world! <3
GREAT JOB!!!

clixer said:
Wow, this is amazing! I'm interested in the modifications to 'stock' Arch you did to achieve this. Is it running a modified recent Arch kernel or what? Great work!
Click to expand...
Click to collapse
From the video I can see he runs "alarm" (Arch Linux Arm)

I'm not a Pixel C owner, but as an Arch Linux user, i find this news great
Does bluetooth works?

If they can get ubuntu running natively I'm in

Did you compile the kernel yourself? How did you figure out what modules to include? Do you have a (menu)config file you could share?
This is incredible, wondering how hard it is to repeat on other tablets/devices

This is great
I wish someone could port it for HP Slate 21

@Samt434 interesting, can you go into more detail about how you built the data partition image?

@Samt434 , hi Archlinux friend
Really good job
I have a similar project for Xperia S with working GPU acceleration. Maybe we can share some stuff. I already pushed some package like libhybris into AUR.
https://forum.xda-developers.com/xp...om-archlinux-phone-gnu-linux-android-t3398769

H0lmEd said:
Did you compile the kernel yourself? How did you figure out what modules to include? Do you have a (menu)config file you could share?
This is incredible, wondering how hard it is to repeat on other tablets/devices
Click to expand...
Click to collapse
Yes I will share more details soon !
The current state is not usable yet, but I know it's possible to run a mainline kernel on this device (thanks to Nvidia guys ). There is still a lot of work to do and I am very busy too with other projects I hope my work will give ideas to some Linux kernel developpers so that they can help us to have mainline kernel running on Pixel C more quickly.
Not sure the hybris approach can work here as Pixel C is using nouveau and tegra DRM + Nvidia blob for GPU acceleration.
I will share some code soon so that people can contribute.
Pixel C has great hardware, and we are approaching to run something on it that will be able to benefit of all its capabilities.
Beware that I cannot garranty any improvements as I'm doing this on my free time,
Stay stunned !
Samt434

Bray90820 said:
If they can get ubuntu running natively I'm in
Click to expand...
Click to collapse
Well.... I supposed if we run something like Ubuntu's netinstaller initrd http://ports.ubuntu.com/dists/zesty...urrent/images/netboot/ubuntu-installer/arm64/ on boot.img then we can install it and run it natively with some few more manual modification to boot.img, I've done these on raspberry pi and it worked perfectly well
Just as long as you don't delete all the partition, install / to /system

Teltarif.de a German website about telecommunication published an article: Pixel C: Richtiges Linux statt Android

Guys i have some good news about this project,
I could finally boot and run Arch on a mainline kernel (4.9) on the pixel C. (Yeah !)
Unfortunatly, DRM is not initialising correctly yet... so no display yet with the 4.9 kernel...
[ 3.622872] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.629493] [drm] No driver support for vblank timestamp query.
[ 3.635453] drm drm: failed to allocate buffer of size 18432000
[ 3.641375] drm drm: failed to set initial configuration: -12
It seems there is still some work to do to initialise the display correctly,
but I think we will have soon Arch with GPU accelerated UI soon
Samt434

Thanks for your efforts and the time you dedicate to this! I've been dreaming with something like this since I decided to buy this tablet! Keep it up!

Samt434 said:
Guys i have some good news about this project,
I could finally boot and run Arch on a mainline kernel (4.9) on the pixel C. (Yeah !)
Unfortunatly, DRM is not initialising correctly yet... so no display yet with the 4.9 kernel...
[ 3.622872] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 3.629493] [drm] No driver support for vblank timestamp query.
[ 3.635453] drm drm: failed to allocate buffer of size 18432000
[ 3.641375] drm drm: failed to set initial configuration: -12
It seems there is still some work to do to initialise the display correctly,
but I think we will have soon Arch with GPU accelerated UI soon
Samt434
Click to expand...
Click to collapse
Can you provide more instructions on how did you compiled the kernel?