X86 Atom Android tablet BLISS ROM. Kernel source & HALS, is tha enough to get going?
I have a TX201LA tablet runs Android 4.2. Its a dual device 2 systems in 1. The tablet half is what i am focusing on. NOT the dock as I have windows 10 running fine on that half. The tablet is nearly useless as it is on android 4.2. I've been exploring a few options for getting an android update. My tablet runs an atom x86 cpu with 2GB of ram and is quad core cloevertrail CPU x2560. Plenty of power to run a newer android or even chromeOS, cloudready, or remixOS. I've explored those options but Bliss is the most straight forward as there are already x86 builds of Bliss. I think support should be relatively easy to add for my device.
There are a few caveats however I know ways to overcome them if I can get a rom to load.
1. I dont have a unlocked bootloader but I maybe able to unlock using zenfone 5 unlock method. Still no custom rom has ever been made for my tablet, only for similar devices like zenfone 5, galaxy tab 3 10.1, & dell venue 7.
2. Once I get it unlocked, I can load CWM or use flashfire. My tablet boots with Droidboot, which I can replace with CWN via again a zenfone 5 exploit that I have confirmed works with my tablet.
3. Would bliss load things like my LCD driver, touch screen etc? That is possibly the biggest issue. I have the kernel code here, UPDATED: http://support.asus.com.cn/Download....1LAF&p=3&s=587 OR here original: http://support.asus.com.cn/Download....01LA&p=3&s=587
3A. If the kernel code has all the HALS isnt it possible to build a Bliss rom that would be loaded via CWM/Flashfire and then boot-able?
3B. Could the Bliss team build a rom with the kernel code listed above, that I could then test? Or would the bliss team need to the device (I would think not, i hope). If a rom could be created I would GLADLY donate to BLISS.
Love to find out if this is possible. THANKS
madhits45 said:
I have a TX201LA tablet runs Android 4.2. Its a dual device 2 systems in 1. The tablet half is what i am focusing on. NOT the dock as I have windows 10 running fine on that half. The tablet is nearly useless as it is on android 4.2. I've been exploring a few options for getting an android update. My tablet runs an atom x86 cpu with 2GB of ram and is quad core cloevertrail CPU x2560. Plenty of power to run a newer android or even chromeOS, cloudready, or remixOS. I've explored those options but Bliss is the most straight forward as there are already x86 builds of Bliss. I think support should be relatively easy to add for my device.
There are a few caveats however I know ways to overcome them if I can get a rom to load.
1. I dont have a unlocked bootloader but I maybe able to unlock using zenfone 5 unlock method. Still no custom rom has ever been made for my tablet, only for similar devices like zenfone 5, galaxy tab 3 10.1, & dell venue 7.
2. Once I get it unlocked, I can load CWM or use flashfire. My tablet boots with Droidboot, which I can replace with CWN via again a zenfone 5 exploit that I have confirmed works with my tablet.
3. Would bliss load things like my LCD driver, touch screen etc? That is possibly the biggest issue. I have the kernel code here, UPDATED: http://support.asus.com.cn/Download....1LAF&p=3&s=587 OR here original: http://support.asus.com.cn/Download....01LA&p=3&s=587
3A. If the kernel code has all the HALS isnt it possible to build a Bliss rom that would be loaded via CWM/Flashfire and then boot-able?
3B. Could the Bliss team build a rom with the kernel code listed above, that I could then test? Or would the bliss team need to the device (I would think not, i hope). If a rom could be created I would GLADLY donate to BLISS.
Love to find out if this is possible. THANKS
Click to expand...
Click to collapse
For one, you should ask Bliss OS (x86) related questions in the Bliss OS thread: https://forum.xda-developers.com/bliss-roms/bliss-roms-development/x86-bliss-x86-pc-s-t3534657
Second, I tend to only use source dumps that maintain proper commit attribution. This is our way of giving credit where it is due (the original developers) Most of the source dumps I come across are a bunch of source code, with one commit at best titled, "initial commit" or "dump", and this to me says that there is something not trustworthy about it. I would like to see all the individual commits and changes made throughout the commit history, as this allows us to easily target changes that were made for that specific device.
If others want to go through the trouble of picking out those differences and creating a pull request with the proper attribution attached, we have no issues merging into our releases after testing.
electrikjesus said:
For one, you should ask Bliss OS (x86) related questions in the Bliss OS thread: https://forum.xda-developers.com/bliss-roms/bliss-roms-development/x86-bliss-x86-pc-s-t3534657
Second, I tend to only use source dumps that maintain proper commit attribution. This is our way of giving credit where it is due (the original developers) Most of the source dumps I come across are a bunch of source code, with one commit at best titled, "initial commit" or "dump", and this to me says that there is something not trustworthy about it. I would like to see all the individual commits and changes made throughout the commit history, as this allows us to easily target changes that were made for that specific device.
If others want to go through the trouble of picking out those differences and creating a pull request with the proper attribution attached, we have no issues merging into our releases after testing.
Click to expand...
Click to collapse
Did you look at my source to see if this is a problem? I'm not exactly sure how it needs to look but is this something you have found to be the case with other asus sources in the past? I'd be surprised if it was. I'd love to get a bliss rom for my tablet but I figured this would not be so easy even with x86 support being its base.
madhits45 said:
Did you look at my source to see if this is a problem? I'm not exactly sure how it needs to look but is this something you have found to be the case with other asus sources in the past? I'd be surprised if it was. I'd love to get a bliss rom for my tablet but I figured this would not be so easy even with x86 support being its base.
Click to expand...
Click to collapse
By the time I read your post, the links didn't work. And of the Asus source dumps I've seen in the past, they haven't included any git history
electrikjesus said:
By the time I read your post, the links didn't work. And of the Asus source dumps I've seen in the past, they haven't included any git history
Click to expand...
Click to collapse
Hey Electrik jesus, Here is the new link: https://www.asus.com/2-in-1-PCs/ASUS_Transformer_Book_Trio_TX201LA/HelpDesk_Download/
I'm from Michigan to.. So hopefully you can help another Michigander lol with a bliss build. Asus recently changed up there whole support site and the source code used to only be available on the international site now it seems its also on there US site. The Tx201LA was sold more overseas then in the US. It so similar to about 50 other devices (same Soc) asus made but mostly a lot of them are phones.
madhits45 said:
Hey Electrik jesus, Here is the new link: https://www.asus.com/2-in-1-PCs/ASUS_Transformer_Book_Trio_TX201LA/HelpDesk_Download/
I'm from Michigan to.. So hopefully you can help another Michigander lol with a bliss build. Asus recently changed up there whole support site and the source code used to only be available on the international site now it seems its also on there US site. The Tx201LA was sold more overseas then in the US. It so similar to about 50 other devices (same Soc) asus made but mostly a lot of them are phones.
Click to expand...
Click to collapse
I checked it out, and it is just as I was expecting. no .git folder or anything to show what commits were made on top of the standard kernel source. I guess the only thing we can do about it though is set an example of how to do it...
Example of how a kernel commit history could look: https://github.com/BlissRoms-x86/platform_kernel_common/commits/k4.15.10-ipts
electrikjesus said:
I checked it out, and it is just as I was expecting. no .git folder or anything to show what commits were made on top of the standard kernel source. I guess the only thing we can do about it though is set an example of how to do it...
Example of how a kernel commit history could look: https://github.com/BlissRoms-x86/platform_kernel_common/commits/k4.15.10-ipts
Click to expand...
Click to collapse
So if I understand you correctly the source code needs to be gone through to be pick out the comments etc and then it can be pulled into the bliss x86 source for merging? I think this is above my skill set, what can I do if I dont have the skills to do this?
madhits45 said:
So if I understand you correctly the source code needs to be gone through to be pick out the comments etc and then it can be pulled into the bliss x86 source for merging? I think this is above my skill set, what can I do if I dont have the skills to do this?
Click to expand...
Click to collapse
It's more of a prevention on our end from not giving attribution to the original author. Let's say that someone who worked on a linux project, got the GPU to finally work right with the chipsets in your ASUS. I would like to see that one guy's additions, but even moreso, I would like to see ASUS show that they used his work. Because for all we know, there are hundreds of commits in there that were added, and some of that could be work that someone else deserves to be reimbursed for. The fact that they removed the .git folder shows that they have something to hide. Calling it "trade secrets" shouldn't be allowed when it comes to kernel code.
electrikjesus said:
It's more of a prevention on our end from not giving attribution to the original author. Let's say that someone who worked on a linux project, got the GPU to finally work right with the chipsets in your ASUS. I would like to see that one guy's additions, but even moreso, I would like to see ASUS show that they used his work. Because for all we know, there are hundreds of commits in there that were added, and some of that could be work that someone else deserves to be reimbursed for. The fact that they removed the .git folder shows that they have something to hide. Calling it "trade secrets" shouldn't be allowed when it comes to kernel code.
Click to expand...
Click to collapse
So its about credit and royalties? I understand being upset at asus because they did not or have not credited someone but what can i do about that? Am I stuck at not being able to have my device supported because asus is a bad actor? Is there any way I can get support?
madhits45 said:
So its about credit and royalties? I understand being upset at asus because they did not or have not credited someone but what can i do about that? Am I stuck at not being able to have my device supported because asus is a bad actor? Is there any way I can get support?
Click to expand...
Click to collapse
There is, you could take the route Jakeday has for the Surface line. Since we don't know the author, he created patches to add the support needed to the kernel. It's far from the easy road, but this is what helps developers far more than any source dump
https://github.com/jakeday/linux-surface
electrikjesus said:
There is, you could take the route Jakeday has for the Surface line. Since we don't know the author, he created patches to add the support needed to the kernel. It's far from the easy road, but this is what helps developers far more than any source dump
https://github.com/jakeday/linux-surface
Click to expand...
Click to collapse
What I am confused about is this.
1. Is it a protocol thing? IE asus did not give credit and thus bliss refuses to add support unless they do.
OR
2. Is it an actual road block? IE we cant use the source code as is because it needs more information or reformatting?
Or is it both with more weight on #2?
If its #1 then can we make an exception? and if it is #2 why isnt there some sort of code AI that can redo the code to make it conform to the needed edits, seems like that should be possible. I would hope that if it is #1 only that you would admit that is all it is and help more people instead of forcing people to work around the bureaucracy brought onto them by bad actors like asus.
madhits45 said:
What I am confused about is this.
1. Is it a protocol thing? IE asus did not give credit and thus bliss refuses to add support unless they do.
OR
2. Is it an actual road block? IE we cant use the source code as is because it needs more information or reformatting?
Or is it both with more weight on #2?
If its #1 then can we make an exception? and if it is #2 why isnt there some sort of code AI that can redo the code to make it conform to the needed edits, seems like that should be possible. I would hope that if it is #1 only that you would admit that is all it is and help more people instead of forcing people to work around the bureaucracy brought onto them by bad actors like asus.
Click to expand...
Click to collapse
It's the third option, I'm too busy to do the work for something that is more important to you than it is to me.
electrikjesus said:
It's the third option, I'm too busy to do the work for something that is more important to you than it is to me.
Click to expand...
Click to collapse
LOL.. Pretty PLEASE, with big traverse city cherrys on top.
I have also emailed asus to see if they will look at the source code again to properly format it, not likely but worth a shot.
Does this help: https://proandroiddev.com/ooga-chaka-git-hooks-to-enforce-code-quality-11ce8d0d23cb
Is the process of going through the code very time consuming? So even if using git hooks it will take time? Im still trying to understand why there is no AI that can go through it.
electrikjesus said:
It's the third option, I'm too busy to do the work for something that is more important to you than it is to me.
Click to expand...
Click to collapse
It is important for several people. I hope at some point you have enough time to be able to help us. please help.
I am revisiting this conversation after a few months, and for starters, I would like to say I'm sorry for being rude. Secondly, I would like to use this conversation to start change where we need it. Innovation is the key point here. and if any of us are to build off of one another, we must work together to make it all possible. The lack of commit attribution by OEMs is a blatant disregard for GPL and Open Source licensing. As a ROM team, I would love to work with any OEM to help them through the process of adding a proper commit history. As Bliss, we are open to taking on any new device work, and we have in the past with Udoo-x86 & PINE64, but one of our requirements is that we can release full source, commit history, etc. Everything anyone could need to build off our work.
Too many OEM's are using patents as a way to stab eachother in the back, or use it as a "competitive" road block to stop the sale other devices that may have a similar method or feature. We don't agree with this practice and believe it is driven by greed and the wants of a few, not the needs of the majority. We as Bliss will continue to do what we can to act as an example of what should be done to best facilitate the rapid development of mobile technology and software for all parties involved.
Related
So, since HTC is now almost 3 months past due releasing the kernel sources, I've been trying to adapt the GSM kernel to compile and work with our devices, by disassembling the stock kernel and going through line-by-line of the source to see what needs changing.
I started by copying all the '*hero*' files to be '*heroc*', and renamed all the symbols to be heroc as well. Then pulled /proc/config.gz to use as a base config. Also had to fix up the Kconfig's and Makefile's, as needed, to be able to support HEROC-specific stuff. That more or less gets it to a point where you can compile the kernel successfully, although it's still just a GSM kernel with the name and mtype of heroc.
Then I imported the stock kernel (extracted from boot.img, then decompressed) into IDA as a ROM, setup the CONST segment of string data, imported the symbols from /proc/kallsyms using an ida .idc script, and analyzed the remaining areas of the ROM. At that point, I had a virtually fully analyzed binary ROM in ida, complete with symbols. Then went through and renamed the important symbols from the board-heroc* segments as needed to match what is in the source. I also set up some of the more complicated structures/arrays to make them easier to identify.
I found several differences between the stock heroc ROM, and the make-shift hero-turned-heroc source code, and fixed most of what I came across, or just left notes for things to investigate later. What I have now is a hybrid GSM/CDMA kernel that will likely not boot on either device But I figure since I've put as much time into as I have, and I'm sure there are people more familiar with IDA and ARM than I am, I'm putting my IDA file out there for people to start from. If you're not familiar with ARM assembly, this is absolutely useless to you, so you probably shouldn't bother.
I've spent 2 sleepless nights on it already, and still can't get anything to boot. I also tried to get htc_fb_console working so that I could at least see where and why it was dying, but that hasn't worked out well either.
So, by all means, have fun: http://madcoder.binti.ehpg.net/~madcoder/stock_kernel_heroc.i64
It was created using IDA 5.2, 64-bit, but I don't know how well other versions are with compatibility. Oh yeah, it's 35MB
And if you make some breakthroughs, please post about it here. When I get some time, I'll make a patch set to go from the released GSM kernel, to what I have now, and put that up here too.
Thank you, sad but true
I just wanted to say thank you for this work and express how sad it makes me to see the necessity of reverse-engineering in an OPEN SOURCE kernel. I never thought I would see the day.
I would be very curious to hear from you about the specific differences your disassembling unearthed. Can you say with certainty that the Linux kernel code has indeed been changed to work on the CDMA Hero? I mean it's not simply a matter of some missing driver code or other userspace stuff? If so, this would be pretty damning for HTC.
Thanks again, it's amazing to watch the XDA developers' progress in spite of the barriers put in front of their work.
The majority of differences I found were in things like heroc_fixup() where it doesn't check for engineerid/skuid/etc; different camera driver (s5k3e2fx, vs cy8c); fewer checks for multiple pieces of hardware (which is weird considering the stock phone's kernel supports 4 devices) based on system_rev; wrong vreg_get() strings; etc.
The source that HTC released *does* appear to have all the support we need. With modifications to Kconfig and Makefile, and ignoring the missing board files, you *can* compile the kernel directly, using the stock /proc/config.gz, which means all the necessary drivers are already in the GSM source. It's quite obvious that they had a working kernel tree that supported the GSM phone, plus our 4 CDMA phones, and they simply yanked out the CDMA board files and Kconfig changes, before releasing the source code.
What worries me is that I can't get a console, so it's incredibly difficult to find out where it's dying at. If I could get even a serial console to work, it would make this task so much easier. I think my next step is going to be to load up my hacked kernel into ida, and see how different the two are -- that might be easier than translating asm into C and comparing that way. If I can just compare the assembly for the two, it'd probably be easier.
maejrep said:
plus our 4 CDMA phones
Click to expand...
Click to collapse
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
markachee said:
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
Click to expand...
Click to collapse
MACH_HEROC (sprint hero)
MACH_DESIREC (vzw droid eris)
MACH_HEROCT (not entirely sure, maybe bell south hero?)
MACH_NEONC (neon is supposed to be the touch dual, which afaik has never been planned as an android phone, so I'm not sure what's up with this name either)
You can see those in the /proc/config.gz on the phone (ungzip or zcat it first ), and just search for "CONFIG_MACH_".
Also in the htc_wifi.c source, you can see references to espresso, and many others.
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Mr. Biggz said:
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Click to expand...
Click to collapse
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Keep up the amazing work mad man.
travo1 said:
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Click to expand...
Click to collapse
Yeah, my fiance went through 2 moments, and they were so buggy she switched to the Hero. No problems since.
flipzmode said:
Keep up the amazing work mad man.
Click to expand...
Click to collapse
+1 for keeping up the good work!
:beer: (Does that emote work on this forum? I hope so...)
bumping this so it doesnt get buried 3 pages again
toastcfh said:
bumping this so it doesnt get buried 3 pages again
Click to expand...
Click to collapse
I thought you said you were going to bed
gu1dry said:
I thought you said you were going to bed
Click to expand...
Click to collapse
i was till i had to refresh again
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
maejrep said:
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
Click to expand...
Click to collapse
Honestly, I would continue it. Nobody's sure that HTC will release the source code (HTC said they would release the source for the "Gero"...we're hoping that was a mistype).
I have a feeling they won't release it anytime soon and you'll probably solve the entire issue with the cameras and more before that source is released.
bump.... its on the second page
Yea def keep the good work up HTC said over the weekends tht came and went so now all we got is you my good man
man we gotta get this thread stickied!!!!
toastcfh said:
man we gotta get this thread stickied!!!!
Click to expand...
Click to collapse
agreed... lol
anyhow i think this will work out before the htc hope does. bumped to the top
So, with some inspiration from NetRipper, I started trying to find a way that I could see how far it gets in the kernel booting before it stops, since I still don't have a console. Unfortunately, his suggests were LED-related (particularly gpio-enabled), and we don't have any of those. Did find one reaction that is very hard to miss, and luckily very easy to trigger: reboot via gpio
So now I'm stepping through the code, trying to find at what point in execution it stops rebooting and just hangs. So far I'm in init level 4 (of 6). I'm really hoping this leads me to something that will at least tell me "well THERE'S your problem!", and I can reverse the stock kernel asm to figure out what is different.
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
chuckhriczko said:
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
Click to expand...
Click to collapse
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Kcarpenter said:
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Click to expand...
Click to collapse
If someone has made a github project please let me know. I havent made a 2.6.29 github project yet. I am currently doing one for 2.6.27.
I created a 2.6.27 repo this morning when the source was released. And I've checked out 2.6.29, just haven't set it up in github.
Really?
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
It's not that simple. For starters we have to copy over the drivers for our phone and make sure they compile correctly. On top of that HTC modified quite a bit of the kernel. Porting it over will happen but it may take some time. Like I said before I am new to the linux kernel deal but I do know it is more difficult than it seems.
I'd say a completely functional port will take roughly 2 weeks time for a hobbyist. I'm not sure though as I'm still new to messing with linux kernels. I'm looking into a port of my own. Debating 2.6.29 or porting the android specific bits to a newer linux kernel. Chances are porting the hero specific stuff to the android 2.6.29 kernel source will be much simpler. It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight. I wish I was a bit more profficient with C programming too. I guess now I have a good reason to do just that.
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
edit: didnt release chuckriczko answered your question..
obelisk79 said:
It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight.
Click to expand...
Click to collapse
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
gu1dry said:
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
Click to expand...
Click to collapse
no kidding... I wasn't expecting to wake up to a new release. Of course I could just run linux on my laptop and call it a day
Yeah, the reason it's better to start with .29 than jump to .32, because a lot of the work has already been done for us in .29. In fact, if you really investigate the kernel source they released, vs the kernel on our phones, you'll notice that HTC has already backported some of the .29 changes in the android-msm-2.6.29 branch into the source they released, which was *not* initially the case in the kernel that they shipped.
What we need to do to get .29 actually working, is the opposite: forward-port the HTC changes for hero/c into the .29 source.
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
maejrep said:
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
Click to expand...
Click to collapse
Great work! As I said before I am new to this linux kernel stuff and don't think I can help but I am cloning the repo so I can take a look anyway.
Any progress with getting it to boot?
Any update on this project?
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
theoottesen said:
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
Click to expand...
Click to collapse
I checked the githup out. still doesn't boot
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
maejrep said:
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
Click to expand...
Click to collapse
So if I understand correctly, the devs that worked on the kernel for the Nexus One got lazy and never tried to see if it compiled on the Sapphire?
If they were developing the kernel for the nexus id hardly call them lazy for not taking the time to check it on other devices.
After a month of back and forth with Barnes and Noble support and numerous references to the GPL, I think I've managed to acquire a copy of the kernel source for this tablet. It's published as a ZIP on Barnes and Noble's website. I haven't spend a whole lot of time with it, as I currently do not have the resources to build it, but from a cursory glance it seems to be reasonable, if in a weird format. I've also mirrored the source on GitLab (unfortunately, GitHub doesn't work with files over 100 MB nicely) for you guys to play with in case the Barnes and Noble link goes down or you'd like a faster download. If you see anything crucial missing, let me know and I'll try to get it fixed by pestering them to give it to me!
saagarjha said:
After a month of back and forth with Barnes and Noble support and numerous references to the GPL, I think I've managed to acquire a copy of the kernel source for this tablet. It's published as a ZIP on Barnes and Noble's website. I haven't spend a whole lot of time with it, as I currently do not have the resources to build it, but from a cursory glance it seems to be reasonable, if in a weird format. I've also mirrored the source on GitLab (unfortunately, GitHub doesn't work with files over 100 MB nicely) for you guys to play with in case the Barnes and Noble link goes down or you'd like a faster download. If you see anything crucial missing, let me know and I'll try to get it fixed by pestering them to give it to me!
Click to expand...
Click to collapse
What resources do you need. I picked up the new bn 7 tablet the other day. It's the 650 model. I have Ubuntu and superr kitchen
Edit: screen smashed...will donate the board to someone for Dev...
I have no idea what to do with it, actually. How can I do something useful with this?
saagarjha said:
I have no idea what to do with it, actually. How can I do something useful with this?
Click to expand...
Click to collapse
If we had a build of twrp, we could probably start building custom roms with this kernel I bet. I'm gonna ask B&N about getting the source for BNTV460 since that is the one I have.
A big issue that i'm having with this source is I can't figure out which defconfig to use for this device
I have recently built LineageOS 15.1 for the Nook Tablet 7" (Only st18c7bnn/bntv460) and have looked over the kernel source and found that this source code is essentially useless because it is missing the lcm code, which controls screen and touchscreen. I do not see them releasing full kernel source for this device or for the oreo model in the future as every time I've called I have had no luck getting anything from them. If anyone else is willing to try to ask for kernel source from them, please do since it is not only their legal obligation to give it with all of their modifications, but also a huge help for development. The st16c7bnn & st18c7bnn both use the same LCM, although for some reason, st16c7bnn(the marshmallow device) is 64bit while st18c7bnn(oreo) is 32bit only.
turtleletortue said:
I have recently built LineageOS 15.1 for the Nook Tablet 7" (Only st18c7bnn/bntv460) and have looked over the kernel source and found that this source code is essentially useless because it is missing the lcm code
Click to expand...
Click to collapse
So, if I'm understanding correctly you have a non-functional LineageOS? Or is it that the st18c7bnn is the only one that needs the LCM code, and it already works on st18c7bnn (if so, would you mind sharing the build)?
I'd be happy to contact them again (maybe they'll see my old ticket and redirect it to the person who handled that issue), but I would have to know exactly what to ask for because otherwise they are really slow and ask a bunch of questions.
saagarjha said:
So, if I'm understanding correctly you have a non-functional LineageOS? Or is it that the st18c7bnn is the only one that needs the LCM code, and it already works on st18c7bnn (if so, would you mind sharing the build)?
I'd be happy to contact them again (maybe they'll see my old ticket and redirect it to the person who handled that issue), but I would have to know exactly what to ask for because otherwise they are really slow and ask a bunch of questions.
Click to expand...
Click to collapse
Sorry for the long delay in response. Basically, I have an almost perfectly functioning build of LineageOS for st18c7bnn (Nook Tablet 7" 2018 Android Go Edition only), but I wanted the kernel source so I could rebuild the kernel and attempt to merge in security fixes for it. If you have the 2018 model of the device, I'll gladly send the TWRP zip of the rom to you. Seems to work fine, and imo is better than using a gsi. I still have to do more testing, but I'm currently busy with another device. I just want to have the full kernel source (which would include necessary dtb and lcm drivers) for the st18c7bnn and st18c10bnn (Nook Tablet 10.1) like the license the kernel is under should force B&N to do. Since the devices have been discontinued, I figure it's now or never for that, since the longer we wait, the more likely that Emdoor deleted the kernel source off of their machines. But any help is appreciated. Thanks
Hoping this is the right section since its not device specific.
Experienced or not, it doesn't matter. I've been on XDA for a number of years. And am noticing things from my own experience and talking to others. Its hard to get help sometimes. Not all devs want to talk. Teach. Or help people all the time. Devices are being dropped from support. Maintainers are leaving the scene. Currently I have an Oreo and pie ROM for s6e+ and note 5. With the list of devices being dropped, and surprising amount of people reaching out to me for support, I decided it may be beneficial to recruit a few people who want to develop ROMs. This is a great chance to learn. I would like to pick up at least partial support for several more devices, and need some help to do it. My goal in this endeavor is to continue to provide ROMs to people who need them, while teaching other users to develop. This will help to bring fresh life to the scene, and allow support for more devices to be added. If you are interested reply below or inbox me. There is a google hangouts set up, and other methods of team communication will follow. I also have a home server with a 24/7 connection and no data limits on my internet, and an ftp set up to host files directly and not need third party sites.
so basically you have good intentions, no plan and a home server )
what we really need is a unification of all the different but not really different roms and their devs,
then its possible to see a future for long term support for all devices, or at least many.
anyhting else is jsut another project that will or will not die, based on good will and free time of the maintainer, mostly not even reckognized
due to the chaos of fragmented android and even more fragmented custom rom scene.
godkingofcanada said:
Hoping this is the right section since its not device specific.
Experienced or not, it doesn't matter. I've been on XDA for a number of years. And am noticing things from my own experience and talking to others. Its hard to get help sometimes. Not all devs want to talk. Teach. Or help people all the time. Devices are being dropped from support. Maintainers are leaving the scene. Currently I have an Oreo and pie ROM for s6e+ and note 5. With the list of devices being dropped, and surprising amount of people reaching out to me for support, I decided it may be beneficial to recruit a few people who want to develop ROMs. This is a great chance to learn. I would like to pick up at least partial support for several more devices, and need some help to do it. My goal in this endeavor is to continue to provide ROMs to people who need them, while teaching other users to develop. This will help to bring fresh life to the scene, and allow support for more devices to be added. If you are interested reply below or inbox me. There is a google hangouts set up, and other methods of team communication will follow. I also have a home server with a 24/7 connection and no data limits on my internet, and an ftp set up to host files directly and not need third party sites.
Click to expand...
Click to collapse
I respect your Idea but I don't think something like this is required.You see I had been using linux for 4+ years and was pretty adapted to it when I switched to a Note 3.Recently I discovered the Modding part of it and the huge development of custom roms and kernels.and despite having no clue what I was doing I could easily develop a Kernel without a hassle.I went even one step further and made a halium port for it.Sure it didn't boot the first time but by using methods on xda already discussed in detail I was able to make it work.So,the main thing is that someone like me who has no experience could make a ROM in 3 hours without any complications(Except those who could be solved by googling).Then anybody could do it.Currently there isn't a ROM bug or a issue that hasn't been discussed on either xda or other android development sites.But that doesn't mean we shouldn't help newcomers.But it is rare for someone to look on the other side of development and there is enough documentations for him to do it.Maybe too much.qq
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
I respect your Idea but I don't think something like this is required.You see I had been using linux for 4+ years and was pretty adapted to it when I switched to a Note 3.Recently I discovered the Modding part of it and the huge development of custom roms and kernels.and despite having no clue what I was doing I could easily develop a Kernel without a hassle.I went even one step further and made a halium port for it.Sure it didn't boot the first time but by using methods on xda already discussed in detail I was able to make it work.So,the main thing is that someone like me who has no experience could make a ROM in 3 hours without any complications(Except those who could be solved by googling).Then anybody could do it.Currently there isn't a ROM bug or a issue that hasn't been discussed on either xda or other android development sites.But that doesn't mean we shouldn't help newcomers.But it is rare for someone to look on the other side of development and there is enough documentations for him to do it.Maybe too much.qq
Click to expand...
Click to collapse
You can't just make a ROM for any device is 3 hours. It doesn't always work that way. Especially not if building from source
godkingofcanada said:
You can't just make a ROM for any device is 3 hours. It doesn't always work that way. Especially not if building from source
Click to expand...
Click to collapse
I just followed a guide.On an XL VPS. With maybe 22GB ram and 16 xeon cores
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
I just followed a guide.On an XL VPS. With maybe 22GB ram and 16 xeon cores
Click to expand...
Click to collapse
I don't disagree sometimes it is easy. But what if lineage or GitHub don't have all necessary files for the build? And then you need to extract them from your phone manually, or if build won't boot up and needs modifications to the kernel.. fixing drivers that do not work. It's not always so simple as build, flash and finish.
godkingofcanada said:
I don't disagree sometimes it is easy. But what if lineage or GitHub don't have all necessary files for the build? And then you need to extract them from your phone manually, or if build won't boot up and needs modifications to the kernel.. fixing drivers that do not work. It's not always so simple as build, flash and finish.
Click to expand...
Click to collapse
I did face issues.The End of the guide covered the basics of logging stuff and finding things.They were just as same as debugging a linux OS but yeah you're right as I did face the extracting files(dunno what was supposed to do).So I wrote "extract proprietary vendor code from ROM" and boom lineage gave it to me.Also the guide was only for devices that exist on lineage and sometimes we need to start from scratch.And maybe We both are,Who knows what the future might bring,BTW have you heard about Google's new Boy Fuchisa or something like that.I wanted to talk someone in the field of development about this but nobody was bringing up the non-linux version of Google's OS for smartphones.
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
I did face issues.The End of the guide covered the basics of logging stuff and finding things.They were just as same as debugging a linux OS but yeah you're right as I did face the extracting files(dunno what was supposed to do).So I wrote "extract proprietary vendor code from ROM" and boom lineage gave it to me.Also the guide was only for devices that exist on lineage and sometimes we need to start from scratch.And maybe We both are,Who knows what the future might bring,BTW have you heard about Google's new Boy Fuchisa or something like that.I wanted to talk someone in the field of development about this but nobody was bringing up the non-linux version of Google's OS for smartphones.
Click to expand...
Click to collapse
Yes I heard about it. I stumbled across it by accident looking for a way to shim the s6 edge plus cam on my pie rom. It lead me to reading about vulkan, which showed me a new Google os. It looks nice
godkingofcanada said:
Yes I heard about it. I stumbled across it by accident looking for a way to shim the s6 edge plus cam on my pie rom. It lead me to reading about vulkan, which showed me a new Google os. It looks nice
Click to expand...
Click to collapse
Well It seems that it uses a Different type of kernel "microkernel".For someone as stupid as me I don't get it what was the difference between a microkernel and monolithic one on an android device(or a low powered arm processor based board that has a screen attached to it)Will it be performance,Faster loading,Efficiency.I can find a million articles on microkernel vs monolithic but they are in latin for me.But you can just give me the crash course in maybe 3-4 lines.
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
Well It seems that it uses a Different type of kernel "microkernel".For someone as stupid as me I don't get it what was the difference between a microkernel and monolithic one on an android device(or a low powered arm processor based board that has a screen attached to it)Will it be performance,Faster loading,Efficiency.I can find a million articles on microkernel vs monolithic but they are in latin for me.But you can just give me the crash course in maybe 3-4 lines.
Click to expand...
Click to collapse
Device drivers, protocol, file systems moved from kernel to user. It's got less code, more lightweight. And it was created with embedded systems in mind. In theory it should be faster, and more suited to small devices like phones with embedded systems. Giving devices their own dedicated kernel finally instead of butchering a Linux kernel to suit their device needs. It's also universal in terms of cross platform
godkingofcanada said:
Device drivers, protocol, file systems moved from kernel to user. It's got less code, more lightweight. And it was created with embedded systems in mind. In theory it should be faster, and more suited to small devices like phones with embedded systems. Giving devices their own dedicated kernel finally instead of butchering a Linux kernel to suit their device needs. It's also universal in terms of cross platform
Click to expand...
Click to collapse
Now that's more like it.I was afraid that android was finally going to commit close source(or suicicde).But since it's open source and I hear good things from you and 4 other guys who have experience in doing stuff I think,Hope and Pray that it might be a good change.Also thanks for using plain English and being a Open guy.Currently I am thinking that 5 years from now someone gonna run into this post and have a little smirk on his face for you who is reading this,Quote and tell me was it good?Was we good?
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
Now that's more like it.I was afraid that android was finally going to commit close source(or suicicde).But since it's open source and I hear good things from you and 4 other guys who have experience in doing stuff I think,Hope and Pray that it might be a good change.Also thanks for using plain English and being a Open guy.Currently I am thinking that 5 years from now someone gonna run into this post and have a little smirk on his face for you who is reading this,Quote and tell me was it good?Was we good?
Click to expand...
Click to collapse
I think the changes appear good. Less stuff locked away in private, more easily accessible to all. Treble has the vendor stuff available to roms that aren't stock, this will make the kernel tiny and easy to build. One by one the barriers people have to overcome to build their own roms are being taken away.
Hi everyone,
I bugged HMD about not releasing more recent source code for the Nokia 8 and a few days ago they updated their site with links to code for the Android 9 builds. Note they still haven't published the latest build (5.150) nor and 4.88 builds nor any Android 7.1x builds.
I checked the archives and they are different from the previous 4.84 release, but I've no idea if they are buildable. They still look like they might be missing some useful bits, from my limited knowledge. Those of you who know what to do with this can test it and see if it's useful to you.
Let me know if you would like me to keep bugging them about the 4.88 build's code, or even any earlier 3.x builds.
Have fun!
Cheers
Thanks for bugging them!
Sadly it still contains the same device tree typos that the previous NB1 and even A1N sources contained, so without fixing them those trees do build but won't work correctly as the display won't be accessed correctly (half the screen will be white IIRC).
To be clear, this is what I mean: https://github.com/resident-nokia/u...f68ad2f#diff-6ea71fa79b281dd80cbab0bea96d9472
Also, as a funfact: A quick diff I did showed that the 5140 source is identical to the 4120 kernel source from Nokia 8 Sirocco that was released around December if I am not mistaken (minus the device tree files and some places where device names were hardcoded). That would mean that our kernel hasn't seen an update since December (actually even September, since thats the first CAF tag (Qualcomm upstream) that has changes you can find in those sources). Customer service I guess ¯\_(ツ)_/¯
Hi @THMSP!
Thanks for checking it out, shame it's still got errors in it. That's very interesting about the comparison with the Sirocco and the last change being in September. I suppose a new build doesn't automatically mean a new kernel though.
Since both the Android 8 and 9 source contain errors my only wonder is if the Android 7 source would also have errors, or if it might actually work?! I will ask them for it.
Cheers
EDIT: So the device tree is there after all? I had obviously misunderstood some of the other conversations I'd read, I had always thought it was missing. So it seems the device tree is there, but broken? Or only partially there, and what is there is broken?
The device tree files are all there, but they contain four serious typos that cause them to not actually work when you boot your compiled kernel. The rest of the source code does work. Correcting those typos is not much of a deal, but it is annoying (and personally I wonder how on earth they even maintain these sources).
The other annyoing issue is that for any custom or mismatching kernel the wifi driver won't load (because of signature enforcement for kernel modules), so if you want to make a kernel that doesn't break wifi, you need to add the Qualcomm wifi driver yourself (which then requires additional patches to actually work as well).
When you do those two things, the kernel will work just like the one that Nokia is shipping. For example, my TWRP builds for NB1 actually use the kernel source code for Sirocco, but with the (corrected) device tree files from NB1, and a patched version of the qualcomm wifi driver compiled into the kernel directly.
I am not sure if the nougat sources would help that much to be honest. It's not like those sources are broken because HMD / FIH don't know how to fix them, I bet they break them on purpose (or they get broken by the tool they use to package them). So any further release by them will probably contain the same stupid errors.
Wow! That's a lot to do to make them usable. I agree that I have many questions about QC and QA in the software for these phones, not only because of the source code releases.
You did very well making the device tree for the NB1 then and getting TWRP running, well done! And thanks
Like many I'm interested in the possibility of running other OSes on the NB1, particularly /e/ and any that run on Halium. I presume it will still take a lot of work to get another OS running on the NB1, but is it doable? I think in all cases these projects start from a LOS base.
Cheers
madb1lly said:
Wow! That's a lot to do to make them usable. I agree that I have many questions about QC and QA in the software for these phones, not only because of the source code releases.
You did very well making the device tree for the NB1 then and getting TWRP running, well done! And thanks
Like many I'm interested in the possibility of running other OSes on the NB1, particularly /e/ and any that run on Halium. I presume it will still take a lot of work to get another OS running on the NB1, but is it doable? I think in all cases these projects start from a LOS base.
Cheers
Click to expand...
Click to collapse
Most of the work regarding TWRP and the kernel was actually done by @dg28gadhavi - I just tried to update everything a bit and adapt it to all the new bootloader bugs features that were introduced over time. He deserves all the credit, otherwise I would've had nothing to learn all this stuff from.
Regarding custom ROMs: Sure it is possible. But it is a huge amount of work, that requires you to risk your device (Snapdragon chips are unbrickable, but you couldn't use it as a daily driver), with potentially very few people actually caring (or even donating etc.). When you reached the point where you are able to port a ROM, you have the knowledge to make the changes that you need yourself with Magisk as well. So the only real reason to port a ROM is to give something to the community. And the Nokia 8 community simply isn't big enough that anyone would do that, imo.
Well thanks for @dg28gadhavi as well then!
Yes, I have read that Magisk can do most of what a custom Android ROM might have done. I have some reservations about Magisk, since it's not open source I don't know if I fully trust it, but that could also be the case for most of the software I use! Personally I'm interested most in /e/, which is currently built of a LOS base, but I don't know if all the customisations they've done (mainly to remove any communication with Google services) can be done with Magisk.
As for Halium-relate OSes (Ubuntu Touch, Plasma Mobile, Sailfish OS, LuneOS... some others too), Magisk can't recreate those as they're basically completely different from Android, they just run off the Android kernel and use libhybris to interface with the Bionic library drivers; the rest of Android is not used.
Anyway, this is all beyond my available time at present, so I will just have to carry on with stock Android maybe with some Magisk customisations until my phone breaks!
Cheers
madb1lly said:
I have some reservations about Magisk, since it's not open source I don't know if I fully trust it
Click to expand...
Click to collapse
Magisk is completely opensource, it has always been: https://github.com/topjohnwu/Magisk
You might be thinking about SuperSU which was / is indeed closed source