I was talking with people on #android and they mentioned that stock kernels are not working on sapphire 32A boards. I went poking through google's repository and didn't see any code specific to sapphire at all. But I did find some in codeaurora's fork. I don't have a sapphire device so I can't test any of this, but perhaps it would be a useful starting point for someone trying to build kernels for the Magic.
https://www.codeaurora.org/
A list of projects in their git repository:
https://www.codeaurora.org/gitweb/quic/la/
here's a more direct link to the sapphire-related setup.
I notice that linux/arch/arm/mach-msm/board-sapphire.h has a header which lists Thomas Tsai <[email protected]> as the author, which seems authoritative enough.
Nevermind. That fork appears to be missing patches that HTC is using in their kernels too. Sorry.
That repo just looks like a clone from Google with some added stuff for more Qualcomm MSM boards.
If you look closely in the Google tree you will see the same board-sapphire stuff in the exactly same place, ie kernel/arch/arm/mach-msm
I'll give a try with this one:
https://www.codeaurora.org/gitweb/quic/le/
on my sapphire 32A board.
Maybe ?
gboddina said:
I'll give a try with this one:
https://www.codeaurora.org/gitweb/quic/le/
on my sapphire 32A board.
Maybe ?
Click to expand...
Click to collapse
Those changes are pretty recent, give it a try and report back man =D
Damn! It don't want to compile !
I used HEAD code... I'll try another release later...
BTW, in this version seems to have a lot of qualcomm specific configuration. I guess if we find the right values (and we compile it), maybe we can boot it .
Kernel builds without any problem, will give it a try to see if it boots.
edit: seems i was to quick about the build. complains on some damn halibut file, will remove from config and try again.
Yes exactly the same problem.
Changing it into the config don't change anything, the build process include it anyway.
I blanked the files (board-trout.c will give the same result) but then, there is a problem in board-sapphire.c ...
Related
Just learnt something that to my knowledge isn't documented anywhere that I know of and thought I'd share it - I'm not the greatest kernel hacker, but I'm okay at documenting sh*t - the wiki is proof of that
For anyone who's ever built a 32a kernel using TigerTael's patches - well it turns out we've been doing it all wrong and Zinx (from #android) has finally set me straight on it all.
Firstly, we've kinda missed the boat a bit with our existing kernel patches and it's had one casualty so far - Rogers Dream users. These users use the same Radio as HTC Magic 32a
Instead of using that 32a/32b as an discerning factor for kernels what we should really be using is RADIO VERSION.
Phones with radios with 1.xxx or 2.xxx versions are EBI0 - or what we think of as 32b - these are limited to 128MB ram.
Phones with radios with 3.xxx versions require EBI1 - this has a special fix to allow up to 256MB ram.
HTC actually released code in their kernels allowing us to switch between EBI0 and EBI1 with a single kernel config option while using the same codebase - unfortunately it was in the 2.6.27 kernel and since most of us have switched to 2.6.29 we stuck with TigerTael's patch.
TigerTael's patch doesn't work for Rogers Dream users though!
Zinx has extracted a HTC's code and it can now be applied to any kernel tree quite easily - and since its implemented as a kernel config option you're not breaking your code by including it.
You can download Zinx's kernel patch here:
http://zenthought.org/tmp/MSM_AMSS_SUPPORT_256MB_EBI1.diff
You can apply this to your source tree the same way TT's patch was done:
cd kernel_dir
patch -p1 < MSM_AMSS_SUPPORT_256MB_EBI1.diff
Click to expand...
Click to collapse
And then you enable MSM_AMSS_SUPPORT_256MB_EBI1 in your kernel config if you want to build for all EBI1 phones (or disable if you want EBI0 for older Dreams and 32B sapphires).
I'm thinking this should replace the 32a/32b stuff we've named everything up until now - and instead of getting people to check that in the wiki we should be just going by radio versions.. but it depends what you all think really.
I'll be doing all my CyanogenMod ports this way from now on - and hope to get this patch put directly in his github repo to make it easier in future.
If you use this patch - I think it should be specified as EBI1 and EBI0 from now on - perhaps that's expecting too much, but it will let everyone know.
I hope that the rest of you who build your own kernels can do the same!
Awesome - Looks like Cyanogen's going to update his github source to include the MSM_AMSS_SUPPORT_256MB_EBI1 patch according to his latest tweet:
Cyanogen: @Radix999 yes ill patch it in tomorrow
Click to expand...
Click to collapse
This should make it veeeery simple to build a EBI1 compatible kernel in future - just one kernel config option!
Radix999 said:
Just learnt something that to my knowledge isn't documented anywhere that I know of and thought I'd share it - I'm not the greatest kernel hacker, but I'm okay at documenting sh*t - the wiki is proof of that
For anyone who's ever built a 32a kernel using TigerTael's patches - well it turns out we've been doing it all wrong and Zinx (from #android) has finally set me straight on it all.
Firstly, we've kinda missed the boat a bit with our existing kernel patches and it's had one casualty so far - Rogers Dream users. These users use the same Radio as HTC Magic 32a
Instead of using that 32a/32b as an discerning factor for kernels what we should really be using is RADIO VERSION.
Phones with radios with 1.xxx or 2.xxx versions are EBI0 - or what we think of as 32b - these are limited to 128MB ram.
Phones with radios with 3.xxx versions require EBI1 - this has a special fix to allow up to 256MB ram.
HTC actually released code in their kernels allowing us to switch between EBI0 and EBI1 with a single kernel config option while using the same codebase - unfortunately it was in the 2.6.27 kernel and since most of us have switched to 2.6.29 we stuck with TigerTael's patch.
TigerTael's patch doesn't work for Rogers Dream users though!
Zinx has extracted a HTC's code and it can now be applied to any kernel tree quite easily - and since its implemented as a kernel config option you're not breaking your code by including it.
You can download Zinx's kernel patch here:
http://zenthought.org/tmp/MSM_AMSS_SUPPORT_256MB_EBI1.diff
You can apply this to your source tree the same way TT's patch was done:
And then you enable MSM_AMSS_SUPPORT_256MB_EBI1 in your kernel config if you want to build for all EBI1 phones (or disable if you want EBI0 for older Dreams and 32B sapphires).
I'm thinking this should replace the 32a/32b stuff we've named everything up until now - and instead of getting people to check that in the wiki we should be just going by radio versions.. but it depends what you all think really.
I'll be doing all my CyanogenMod ports this way from now on - and hope to get this patch put directly in his github repo to make it easier in future.
If you use this patch - I think it should be specified as EBI1 and EBI0 from now on - perhaps that's expecting too much, but it will let everyone know.
I hope that the rest of you who build your own kernels can do the same!
Click to expand...
Click to collapse
how will all this help out the end user?
We can use the kernel that the rom devs use for their rom, instead of using a 32A kernel from a 32A rom, which may not be 100% compatible
The biggest change will be that all Rogers Dream users will be able to start using our kernels without having to rebuild their own all the time.
Previously they were unable to use G1/Dream/32B kernels, nor our hacked TT-32a kernels because of the way we were doing it.
Very little change for anyone else - though for kernel developers it will instantly mean we can have a single unified kernel source for all kernel builds (still not unified roms yet, but we'll get there!).
One boot.img for Dream/32b magic
One boot.img for Rogers Dream/32a Magic
Thanks for all these doc although I'm not a developer hence don't understand it fully
however anyone implemented this on 32A kernel for Hero ROM?? Am very eagerly expecting it
Hey that's a good question.. what does the Hero use?
Anyone willing to try my cyanogenmod port to see if it works for Hero too?
It may well mean Hero roms can use the same boot kernel as 32a too.
Edit: Bleh.. I worded that really badly. I mean HERO Owners.. ie. actual Hero hardware. Not people using Hero roms on their magic or dream.
This code comes from the HTC release kernel source. It's been around for a while.
It think it's a little misleading to say that the patches prepared by TigerTael were doing it all wrong. His patches did essentially the same thing without giving the option to switch in .config
I don't see what this has to do with the radio version? The memory map depends on two things. The size of the SMI memory (32 or 64) and the size of the EBI1 memory (128 or 256).
As far as I know:
Dream (classic) SMI = 64 EBI1 = 128 TOTAL = 192
Dream (rogers) SMI = 32 ? EBI1 = 256 TOTAL = 288 ?
Magic/Sapphire 32a SMI = 32 EBI1 = 256 TOTAL = 288
Magic/Sapphire 32b SMI = 64 EBI1 = 128 TOTAL = 192
Radix999 said:
J...
Zinx has extracted a HTC's code and it can now be applied to any kernel tree quite easily - and since its implemented as a kernel config option you're not breaking your code by including it.
...
Click to expand...
Click to collapse
When you say "any kernel tree", does this mean we are no longer restricted to 2.6.29? Not that I'm aware of any exciting newer kernel features for embedded devices (but there very well could be), but does this make it easier to try out Android with 2.6.31.x? Is there any value in doing so?
Raydicks I love you
Hi,
could you please give us a more detailed guide about the patch use?
You wrote:
cd kernel_dir
patch -p1 < MSM_AMSS_SUPPORT_256MB_EBI1.diff
Which is the kernel dir?
Thanks
If you're not a kernel developer then this doesn't apply to you and you're just cluttering up this thread.
You apply it only if you're actually BUILDING a kernel - ie from Android's git or Cyanogen's github source tree (though as Cyanogen is applying it tomorrow you won't need to soon).
If you are a kernel developer, then you should know where your kernel source is.. sheesh!
Thanks for the info and patch, will definitely try!
TheStrider said:
Hey Radix. Just trying to understand what it actually means to enable this config option in the kernel (well I know what that means but what's the outcome).
Does the config option allow you to build a kernel that supports both 32a and 32b devices?
From your comments I understood that it will help Rogers 32b users out, but does nothing really for us 32a users (Rogers). So tomorrow if Cyanogen adds the option it doesn't mean I can go and flash his ROM without doing a kernerl port first....
Can you set me straight..
Cheers.
Click to expand...
Click to collapse
Yeah, unless Cyanogen's new trick for the new release is 'detecting radio version at runtime and installing appropriate boot.img' then no - You're still going to need a kernel port - there's no unified kernel (yet anyway).
But on the upside, the kernel port will be:
a hell of a lot simpler as it's the same code base, just a EBI0/EBI1 toggle - and Cyanogen may himself provide the port because he can.
now support Rogers Dream users as well with all EBI1 ports
not so hacky
daproy said:
This code comes from the HTC release kernel source. It's been around for a while.
It think it's a little misleading to say that the patches prepared by TigerTael were doing it all wrong. His patches did essentially the same thing without giving the option to switch in .config
Click to expand...
Click to collapse
Unfortunately this is not true, TigerTael's patches were NOT working for other EBI1 handsets - namely Rogers Dream. His code was a quick hack to get things working for 32a only.
Zinx's patch adds HTC's own code which does it properly for all EBI1 handsets.
Does anyone has a EBI1 kernel I could test on Hero please?
Lox_Dev: I can package one up for you, but I'll need the ramdisk from whatever rom/kernel you're currently using. If you have an existing boot.img - let me know where it is and I can package one up for you to try.
No guarantees it'll work on a Hero, but you never know!
Radix999 said:
J
HTC actually released code in their kernels allowing us to switch between EBI0 and EBI1 with a single kernel config option while using the same codebase - unfortunately it was in the 2.6.27
Click to expand...
Click to collapse
The developers from HTC were probably laughing at our efforts to develop the 32A kernels. Now, if they had just released a patch for the AOSP code, then everything would have been much easier.
This sound interesting, has anybody been able to get it to work?
I'm using it for my cyanogenmod port already... After checking out the Hero kernel dump that htc just did I'm not so sure about it actually working on Hero hardware tho.
I'm trying to compile the source (from the Sapphire link), but am running into compile errors in the iptables/netfilter subsystem
Seems there are filename case issues.. Which I resolved, but now getting an undefined symbol IPT_DSCP_MASK
It's not defined anywhere in the kernel source.
----
Subsequently tried the hero source and get
http://member.america.htc.com/download/RomCode/Source_and_Binaries/kernel_hero_0078c992.tar.bz2
This fails on undefd:
CC arch/arm/mach-msm/htc_battery.o
arch/arm/mach-msm/htc_battery.c: In function 'htc_set_smem_cable_type':
arch/arm/mach-msm/htc_battery.c:405: error: 'ENOTSUP' undeclared (first use in this function)
----
Can HTC really say that they released the source when it won't compile out of the box?
Anyone else have these issues?
Apparently, no one ever compiled the 2.6.27 kernel... simply amazing! (well, also, everybody is doing their stuff for their specific device, so you'll have to ask around in multiple forums like Dream, Hero, Nexus, etc.)
I didn't either.. but here is a nice starter guide.
The errors you get are probably due to missing files (they are available from your device).
In that starter guide he is building android itself, not the kernel...
I've been through every kernel build doc that google can reference...
The errors could be due to missing files... Why they are a missing is a mystery; as the kernel sources were those officially released by HTC for the device...
I even replaced the .config with that from my device.
Will try to pull a 2.6.27 kernel from the git this weekend and go at it again...
magicdroid said:
Apparently, no one ever compiled the 2.6.27 kernel... simply amazing! (well, also, everybody is doing their stuff for their specific device, so you'll have to ask around in multiple forums like Dream, Hero, Nexus, etc.)
I didn't either.. but here is a nice starter guide.
The errors you get are probably due to missing files (they are available from your device).
Click to expand...
Click to collapse
Stupid HTC kernel source...
I tried dozens of times to get it to compile and it never wanted to work.
Try this kernel source. Works for HTC Magic 6.35 radio and the HTC Hero (different .config)
http://github.com/cursordroid/HTC-CCR-Kernel
Thanks CD,
I was trying to compile for the old radio/SPL... There is an interlacing issue we are running into with this 32A on 2.6.29 so I want to build s 2.6.27 as it is supposed to be ok there, then figure out what has changed; or what is the difference with the board/chip variant in this version of the Rogers 32A...
Thx!
Kernels 32A
Questions for the enlightened:
1) If I want to build a Donut rom for the 32A, I need to compile a 2.6.29 kernel?
2) And if I want to build an Eclair rom for the 32A, I need to compile a 2.6.30+ kernel?
3) And these specific kernels need to be configured (forward-ported) for the 32A?
I think I'm getting there.. or not?
magicdroid said:
Questions for the enlightened:
1) If I want to build a Donut rom for the 32A, I need to compile a 2.6.29 kernel?
2) And if I want to build an Eclair rom for the 32A, I need to compile a 2.6.30+ kernel?
3) And these specific kernels need to be configured (forward-ported) for the 32A?
I think I'm getting there.. or not?
Click to expand...
Click to collapse
Donut and Eclair both require 2.6.29 kernels.
Eclair can run on a 2.6.30+ kernel
And you're right, we need specific kernel source for the 32A to get 2.6.29 or higher kernels.
Thanks for the input Cursor!
Maybe I'm wrong, but it seems to me that Magic kernel development is something that is mostly done solo. I know there are custom kernel sources available, but you have like a dozen to choose from, there doesn't seem to be any (community) effort to build one single kernel that could be used for all roms.
Wouldn't it help getting more result if people just would share their precious little spare-time and work together?
I'm thinking of starting an xda-msm-2.6.29 branch based on android-msm-2.6.29-donut..
Wait.. that would be yet another branch
Allrighty,
My goal was to produce a Froyo rom as "naked" as possible.
Only the AOSP itself and Market (to download everything you want).
Today I finaly got a working compilation but I have some Issues I want to resolve first.
I wanted to include the nl_BE locales for myself and everything you guy's will request later on. This worked out fine "but" the word hinting isn't.
What I did was the following: in device/htc/sapphire/device_sapphire.mk
Add the following line: PRODUCT_LOCALES := nl_BE fr_BE en_GB
an other issue that I can't seem to resolv: if I pull in carz-kernel and copy the root of the folder to the msm folder, it compiles, produces the image, .... but It doesn't go past the provider splashscreen and offcourse, no output in adb logcat. Seems like it can't load the kernel.
Do I need to adjust an offset somewhere for the 32a, to locate the kernel?
When I got those figured out, I will post it right away.
I would like to thank a few people who inspired me to do this:
dferreira for documenting a lot of stuff on compiling froyo!
carz12 for the nice kernel he forked!
The people over @ cyanogen for all the efforts!
Sanpei for his kernel work as well!
The nice community we have here @ XDA!
Everyone else who contributes in writing code, who is willing to test roms, and everyone else I might forget!
reserved for future use
Hey,
Can you post some screens?
I'm a bit of a graphical man
I can't get you. Where can it be downloaded?
Switch's is pretty "naked", no? You trying to strip it down further?
Hi there,
Now, I understand that there's a thread or two and a few web pages directed at compiling Android and its kernel from source.
However, the thread in question is months old, and didn't fully explain the process.
As for the web pages, they are mostly outdated and don't include enough information, not to mention desire specific instructions.
I think that, properly explained, building Android shouldn't be daunting, and everyone should be able to attempt it, if they wanted to.
So, I hope to compose a comprehensive guide on how to do just that.
The problem is that I myself have not been able to put enough instructions together to be able to complete a build. And there is no point digging up old threads.
So, If anyone who knows the ropes (that is, compiling android and a kernel from source) would be willing to lead the way, I'd happily turn it into an easy to understand guide.
Josh.
fllash said:
Hi there,
Now, I understand that there's a thread or two and a few web pages directed at compiling Android and its kernel from source.
However, the thread in question is months old, and didn't fully explain the process.
As for the web pages, they are mostly outdated and don't include enough information, not to mention desire specific instructions.
I think that, properly explained, building Android shouldn't be daunting, and everyone should be able to attempt it, if they wanted to.
So, I hope to compose a comprehensive guide on how to do just that.
The problem is that I myself have not been able to put enough instructions together to be able to complete a build. And there is no point digging up old threads.
So, If anyone who knows the ropes (that is, compiling android and a kernel from source) would be willing to lead the way, I'd happily turn it into an easy to understand guide.
Josh.
Click to expand...
Click to collapse
I followed this guide here and successfully compiled a modified HTC Kernel and I had very little Linux and Android experience.
Obviously instead of cloning the Cyanogen git, you just use the gits you wish to compile
Mekrel said:
I followed this guide here and successfully compiled a modified HTC Kernel and I had very little Linux and Android experience.
Obviously instead of cloning the Cyanogen git, you just use the gits you wish to compile
Click to expand...
Click to collapse
Thanks for the link
Though i don't fully understand the whole 'git' thing. Where do i find them? And how to i know which ones are the ones i want to use?
Josh
EDIT: Also, how do you 'edit' the kernel (i imagine it is somewhat like make menuconfig?). Also:
- Are these sense kernels?
- How do you add modules like OC and UV?
fllash said:
Thanks for the link
Though i don't fully understand the whole 'git' thing. Where do i find them? And how to i know which ones are the ones i want to use?
Josh
EDIT: Also, how do you 'edit' the kernel (i imagine it is somewhat like make menuconfig?). Also:
- Are these sense kernels?
- How do you add modules like OC and UV?
Click to expand...
Click to collapse
A git is a repository for source code, developers upload their source code there and can commit changes. The commit can allow descriptions of what was changed and also details the files changed.
The git system allows other people to add to the source if they have permission, or allows others to read the changes and download the source code.
Git links are usually posted by people who release software, as Android is GPL licensed so people have to release their source code if they're distributing their work.
Editing the kernel, take a look into the git and the commits and it will show you which files were changed and how exactly they were changed. That will give you the best understanding.
UV/OC is done by changing the acpu table in the architectures files and changing the minimum/maximum voltage figures in the board_bravo.c file.
The Cyanogen kernels are not Sense kernels no, it's a modified Google Kernel.
Thanks for the explanation. I followed the guide and built the rom, and it works (always a plus )
Now, the next thing is the kernel. How do I build a kernel with the CM tweaks integrated? I understand that all i would be doing is rebuilding the same one that is already installed, but im doing it to learn.
So, if i synced the GIT, does that include the CyanogenMOD kernel source? If it does, where is it and how do i rebuild it. If not, where do i find it?
Thanks,
Josh.
The developer site is still listing KitKat as the newest build, so here are the links to the instructions to build Lollipop using the official source:
Lollipop 5.0: http://nv-tegra.nvidia.com/gitweb/?...a=blob_plain;f=README;hb=rel-st8-l-r1-partner
Lollipop 5.0.1: http://nv-tegra.nvidia.com/gitweb/?...a=blob_plain;f=README;hb=rel-st8-l-r2-partner
Cheers mate. It is still listing the 1.2.1 OTA as the latest but just by changing the branch url i was able to find the newest.
Lets hope for some more development on this device. I'm going to PM you soon - I will be building my own ROM and/or Kernel.
berryman13 said:
Cheers mate. It is still listing the 1.2.1 OTA as the latest but just by changing the branch url i was able to find the newest.
Lets hope for some more development on this device. I'm going to PM you soon - I will be building my own ROM and/or Kernel.
Click to expand...
Click to collapse
You do realize those are the links posted above. There is no need to switch branch names or search for the current files. Just click the one you want.
twistedumbrella said:
You do realize those are the links posted above. There is no need to switch branch names or search for the current files. Just click the one you want.
Click to expand...
Click to collapse
Of course, mate!
I was saying that I found the proper page by changing the URL to hb=rel-st8-l-r2-partner, before this thread was posted. So I appreciate you enlightening other folks about it!
berryman13 said:
Of course, mate!
I was saying that I found the proper page by changing the URL to hb=rel-st8-l-r2-partner, before this thread was posted. So I appreciate you enlightening other folks about it!
Click to expand...
Click to collapse
Even without already having the branch name, it's just a matter of going to http://nv-tegra.nvidia.com/gitweb/?p=manifest/android/binary.git;a=summary to find it
Hi, @twistedumbrella could you please spare a second to help (or point me in the right direction) I've successfully built Lollipop for my Oneplus One using Ubuntu, but when I try to set up first repo sync; well see below:
When I run: repo init -u git://nv-tegra.nvidia.com/manifest/android/binary.git -b rel-st8-l-r2-partner -m tlk/shieldtablet.xml
I get: fatal: manifest 'tlk/shieldtablet.xml' not available
fatal: remote github not defined in /home/diigimatrix/.repo/manifests/tlk/shieldtablet.xml
Please could you get me on my way. I love all your work and hope to gain further knowledge through your support.
Thanks in advance
Phil from Blackpool
diigibio said:
Hi, @twistedumbrella could you please spare a second to help (or point me in the right direction) I've successfully built Lollipop for my Oneplus One using Ubuntu, but when I try to set up first repo sync; well see below:
When I run: repo init -u git://nv-tegra.nvidia.com/manifest/android/binary.git -b rel-st8-l-r2-partner -m tlk/shieldtablet.xml
I get: fatal: manifest 'tlk/shieldtablet.xml' not available
fatal: remote github not defined in /home/diigimatrix/.repo/manifests/tlk/shieldtablet.xml
Please could you get me on my way. I love all your work and hope to gain further knowledge through your support.
Thanks in advance
Phil from Blackpool
Click to expand...
Click to collapse
I'm trying to figure out what's up with it now. I know when I synced it was r1, and tlk/shieldtablet.xml was valid.
Hopefully I can track down why it is coming back invalid in r2.
Thanks @twistedumbrella, glad in a way its not just me. Thought I was running the wrong command. . Happy New Year!
diigibio said:
Thanks @twistedumbrella, glad in a way its not just me. Thought I was running the wrong command. . Happy New Year!
Click to expand...
Click to collapse
Same to you. It updated ok but now I have to see if it'll re-init. It may be a delay on their end. The readme for the portable was up a week before the source.
Cool. I'll give it another try once I've finished work. Been a member for years and helped a lot in the old windows phone days. But thought enough of just relying on other people, time to start getting my hands dirty again. But new to building Android. Need to read up on manipulation of ROMs rather than just building a stock ROM. Any tips on tools to manipulate ROMs? Am i right by merging commits then build, then manipulate ROM? I will read up on it but just thought you might have some pointers. Thanks
diigibio said:
Cool. I'll give it another try once I've finished work. Been a member for years and helped a lot in the old windows phone days. But thought enough of just relying on other people, time to start getting my hands dirty again. But new to building Android. Need to read up on manipulation of ROMs rather than just building a stock ROM. Any tips on tools to manipulate ROMs? Am i right by merging commits then build, then manipulate ROM? I will read up on it but just thought you might have some pointers. Thanks
Click to expand...
Click to collapse
Best bet is to either find something you like and merge it or try to find something similar and recreate it to start. Once you get comfortable, then start coming up with your own.
Building from source is mostly Java for modifying with some C for drivers and such. Usually when you have a device configuration already set up, though, the C part is already done.
Just wanna say a big thanks to @twistedumbrella. I set up a new ubuntu build environment and I'm now compiling my first Android build for Nvidia Shield Tablet EU-LTE. No mods yet other than stock, but hopefully with time.
diigibio said:
Just wanna say a big thanks to @twistedumbrella. I set up a new ubuntu build environment and I'm now compiling my first Android build for Nvidia Shield Tablet EU-LTE. No mods yet other than stock, but hopefully with time.
Click to expand...
Click to collapse
Glad to hear it's all up and running. Best of luck!
twistedumbrella said:
Glad to hear it's all up and running. Best of luck!
Click to expand...
Click to collapse
Hi! I'm trying to compile but get error trying no find:
./packages/apps/UnifiedEmail/src
After repo sync, I don't have "src" directory for this package.
Thnx in advance.
entelekia said:
Hi! I'm trying to compile but get error trying no find:
./packages/apps/UnifiedEmail/src
After repo sync, I don't have "src" directory for this package.
Thnx in advance.
Click to expand...
Click to collapse
It looks like they are still working out a few issues with new updates. I don't maintain the source, so the only advice I can provide is to keep on eye on nvidia's gitweb for when they publish a solution (or occasionally sync and try over), or attempt to fix it yourself (which usually only works if there is an issue with the code, not code missing altogether).
Compiled! I have resynchronized all the project from scratch from git repository.
I'm going to test the compiled ROM in my tablet, but I suppose, I have to provide almost the essential pack of Google apps (basic providers and play services).
I think to flash *.img files, except recovery.img (I'm on TWRP), and then install from TWRP PA Gapps. Is this approach correct?
Thnx in advance and regards.
EDIT: No luck booting custom rom (TWRP nor stock recovery...)
Seem's like there's a new source three version out:
repo init -u git://nv-tegra.nvidia.com/manifest/android/binary.git -b rel-st8-l-r3-partner -m tlk/shieldtablet.xml
GethPrime said:
Seem's like there's a new source three version out:
repo init -u git://nv-tegra.nvidia.com/manifest/android/binary.git -b rel-st8-l-r3-partner -m tlk/shieldtablet.xml
Click to expand...
Click to collapse
Anyone managed to build this one yet? Its not working for me..