Hello, hihihi
I am Cotulla, member of DFT team, probably some of you already know me by older projects related with famous HTC HD2 (Leo).
Nowdays HTC Leo become too old , while hardware abilties are growing very fast nowdays
(huh, already phones with 64 bit CPUs and 4 Gb RAM? Wtf my old PC from 2008 has 4 Gb ram too)
So I decided to switch hobby phone, finally I got HTC One 64Gb (thank all contributors),
so I am with you now :highfive:
I am not sure about developement goals,
I am doing it for fun, but probably it will be something like:
1)Oldschool WM61/65 port :laugh:
2)Windows RT and/or Windows Phone 8
3)Own bootloader
Ofcourse I no idea about port quality - things like ultrapixel camera can be impossible to bring up.
But it's hobby, not attempt to do a work instead of a big company.
I am already started to work on MAGLDR for HTC One.
Then I am planning to bring UEFI up.
Will keep community in sync about development status.
Releases are going to be more often.
About different models support: there are many different HTC One revisions around, I will try to support as much as possible of them.
It seems S-OFF is mandatory requirement.
As well as I have question to One Android developers and need some kind of support:
I am going to divide the biggest "userdata" partition to grab a space for another OS.
userdata it seems is EXT4 formatted.
I don't want to modify primary GPT (at eMMC sector 0) to minimize ability to brick device.
My current idea is a hack inside Linux GPT parser to replace userdata partition bounds.
In such scheme Linux kernel must be modifed to use MAGLDR / another OS.
But I don't know how Android will like unformatted userdata partition. Anyone knows?
Or maybe someone can suggest better scheme?
very nice. looking forward to your impressive work. :highfive:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
@ mods: reserved post for future modifications etc.
Maybe kexec can be used for kernel/BL start.
-W_O_L_F- said:
Maybe kexec can be used for kernel/BL start.
Click to expand...
Click to collapse
I am using fastboot boot now for testing MAGLDR. Later MAGLDR should be flashed as boot.img and android kernel will go to another place...
All I can say is I'm proud to own same device as you do , for more info you're looking for i would suggest you to ask flar2 ( kernel dev ) , n3cortX ( also kernel dev ) or tbladen I'm sure they'll be happy to help you out with informations you seek for.
Anyway good luck with your development ! , looking forward to use it and hopefully one day load w8 as dual boot on the one !
Sent from my HTC One using XDA Premium 4 mobile app
That sounds good i trust your "Elite Recognized Developer" thing
Wait but, UEFI? also here on phones?
By the way HTC will hate you, they have big economic issues and from now on nobody will buy new HTCs again LoL
This is awesome, I know it's too early to ask this but do you plan to port this to the HTC MSM8960 series devices (One S, One XL, Evo 4G LTE)? Hardware wise they are almost indentical to the One
Samuelgames said:
This is awesome, I know it's too early to ask this but do you plan to port this to the HTC MSM8960 series devices (One S, One XL, Evo 4G LTE)? Hardware wise they are almost indentical to the One
Click to expand...
Click to collapse
Mate, he need a device for this.
And, personally, the hardware isn't the same, the partition aren't the same so it's a bit impossible port it, above all without device...
Finally, this project require time
@Cotulla
in the partition layout why not start from mmcblk0p34 to mmcblk0p37?
This is fantastic news! I used your work on the HD2 for a LONG time! very excited to see what can be done! WP8 on the HTC One would be excellent! :good:
in the partition layout why not start from mmcblk0p34 to mmcblk0p37?
Click to expand...
Click to collapse
mmcblk0p34: 00fffe00 00000200 "recovery"
mmcblk0p35: 73fffc00 00000200 "system"
mmcblk0p36: 27fffe00 00000200 "cache"
mmcblk0p37: dc8000000 00000200 "userdata"
I am want to grab space from mmcblk0p37 partition,
put MAGLDR into
mmcblk0p33: 01000000 00000200 "boot"
and probably put Linux kernel to one of unused partitions:
mmcblk0p30: 034ffa00 00000200 "reserve_2"
mmcblk0p32: 05fffc00 00000200 "reserve_3"
mmcblk0p29: 06069e00 00000200 "reserve"
If (or when ) we get Windows Phone 8, how do we bypass the activation?
Click to expand...
Click to collapse
Probably by same method by before :laugh:
This is awesome, I know it's too early to ask this but do you plan to port this to the HTC MSM8960 series devices (One S, One XL, Evo 4G LTE)? Hardware wise they are almost indentical to the One
Click to expand...
Click to collapse
And, personally, the hardware isn't the same, the partition aren't the same so it's a bit impossible port it, above all without device...
Finally, this project require time
Click to expand...
Click to collapse
Hardware is not really same, ever newest linux kernel ports sometimes are very complicated.
I got small progress already.
Initial MAGLDR is working, initial UEFI is working,
bootarm.efi boots from USB stick with WRT installation files.
USB stick is connected via USB host.
But it halts in such state - more stuff must be done to continue with installation (like eMMC access, ACPI support and etc).
For now it's double pixeled - works as 960x540 instead of 1920x1080.
A small thought occurred to me...........Is this by any chance inspired by this
Hey @Cotulla, do you have any plan to support the One 802w (GSM/WCDMA dual sim) variant?
@Cotulla are you using LK as a base for MAGLDR? Really interested in UEFI for my S4
Sent from my GT-I9505 using Tapatalk
Just in case any has doubts about what means Cotulla to HTC One ... have a look here ... and admire the achivements of a 4 years old HD2. Good luck! Awaiting for the WM6.5 on SD
Thread cleaned
I am cleaning this thread from all that OT junk atm.
There is no benefit for the community to know how much you look forward to this, whether you will buy a One for this or whatever you feel about this development effort.
This will be a development thread and is meant to provide information about the work cotulla does here.
So it will be best if you all stay out of it if you don't have anything to commit to that development.
Don't get me wrong, we all are amazed that Team DFT/Cotulla will work on this device. It just isn't the purpose of a development thread to voice all that non-development stuff. All the useful information would get lost among that crap.
The thread will end up in "Original Development" the moment anything flashable exists. And there the posting rules are even stricter. So let's live up to that level already now.
We will have this at close guard as it is destined to become a trollfest before even one line of code is released.
Thanks for your understanding.
Cotulla said:
I am using fastboot boot now for testing MAGLDR. Later MAGLDR should be flashed as boot.img and android kernel will go to another place...
Click to expand...
Click to collapse
OK, just some thoughts of mine:
Do you already have something running? As far as I know, the m7's hboot runs a kernel from /boot partition (boot,img). If you want to put the kernel away to a different location, maybe hboot won't like it and reboot into the bootloader screen permanently.
So it might be you have to struggle with the hboot bootloader (or even SBL) to boot up MAGLDR.
Or, you could completely replace hboot by MAGLDR.
Do you already have an idea about the whole architecture ?
theq86 said:
OK, just some thoughts of mine:
Do you already have something running? As far as I know, the m7's hboot runs a kernel from /boot partition (boot,img). If you want to put the kernel away to a different location, maybe hboot won't like it and reboot into the bootloader screen permanently.
So it might be you have to struggle with the hboot bootloader (or even SBL) to boot up MAGLDR.
Or, you could completely replace hboot by MAGLDR.
Do you already have an idea about the whole architecture ?
Click to expand...
Click to collapse
He does hboot->magldr->kernel
most likely
Sent from my GT-I9505G using Tapatalk
Do you already have something running?[/quote[
Yes, MAGLDR and UEFI are already running from RAM. Not full functionality though.
As far as I know, the m7's hboot runs a kernel from /boot partition (boot,img). If you want to put the kernel away to a different location, maybe hboot won't like it and reboot into the bootloader screen permanently.
Click to expand...
Click to collapse
So it might be you have to struggle with the hboot bootloader (or even SBL) to boot up MAGLDR.
Or, you could completely replace hboot by MAGLDR.
Click to expand...
Click to collapse
Well MAGLDR will be in the right boot.img format, so HBOOT will boot it like kernel.
Then MAGLDR will load Linux kernel in case of Android boot.
I think It's not good idea to touch HBOOT at all. So MAGLDR should run after it.
Do you already have an idea about the whole architecture ?
Click to expand...
Click to collapse
1)Android: HBOOT -> MAGLDR -> Linux kernel
2)Windows: HBOOT -> MAGLDR -> UEFI -> Windows kernel
During start up MAGLDR will read stroage config from eMMC and put it into ram.
So Android or UEFI will able to use it for detecting userdata partition bounds.
Related
Edit: This thread has been moved to General since Android Port has been accomplished. ~TheRomMistress
tutorial originally posted by bojan6
Please read this before start asking questions
1.Android is in testing development.
2.Is not working fully.
3.You can't install Android in your phone.
4.You can run Android in your phone with Haret and see how it look but:
5.There are no working wifi, bluetooth,phone calls, battery, usb conection, ac charger connection and many other things....
6.All drivers and kernel are still under construction.
7.Now you know that Android is not working fully in our phone.
8.If you still want help and test build that is OK.
Now to run Android properly in your phone !
1.Download any of the builds we have around here.
2.Do backup on your sdcard or if you have additional one use this one.
3.Extract the file with android in your sdcard.
4. Check all the files are inside (sdcard/Android/AndroidApps"folder", media"folder",root"folder",clrcad"file",rootfs"fil e",startup"file",system"file",zImage"file",initrd" file")
5. If you want you can take everything from Android folder and pest it in root of the sdcard but you have to change default text (set cmdline"rel_path=Android change to set cmdline"rel_path=" or set cmdline"rel_path=sdcard") tri with one if is not working try with the other one. I thing the best is leave all files and folder in default Android folder and just copy this folder to your sdcard.
6.Check your zImage and Startup is for Toshidroid :OP (TG01).
7.First RUN haret without CLRCAD.
8.It take no more than10 min to run for the first time.
9. If it take more time RESTART the phone by pressing the POWER BUTTON for 10/20 sec it will restart and back to windows.
11.Try to do the same one more time.
12.If it still not booting to Android and you receive any error messages. Check your sdcard if there is space left in it. Check error message if it say that it can find some file or it can't create a data.
13. Delete everything from your sdcard and format it to fat32.
14.Start from the beginning.
15. If it still not booting to Android then check if you have all files and all set how it has to be.
16. Don't forget you can broke your phone. And we are not responsible for any damage you cause to your phone.
17.It is all up to you.
19. If I forget something sorry about just ask there are other memebers who will try to help you if they can.
20. Sorry for my English mistakes. I'm trying to fix them. :OP
Thanks to all people who try their best to make that possible: Markinus, Arash18k,Bally3,Endrix,Nyl,Arnookie and all other.
******************************
There are 2 active projects.
Android on TG01
PLEASE FOLLOW MARKINUS THREAD FOR UPDATES
http://forum.xda-developers.com/showthread.php?t=846777
Other resources..
http://gitorious.org/linux-on-wince-htc/linux_on_wince_htc/commits/linux-on-tg01
ToshDroid.
The main man behind the ToshDroid project is Endri Bezati
PLEASE FOLLOW ENDRIX THREAD ""ToshDroid" FOR UPDATES
http://forum.xda-developers.com/showthread.php?t=788860
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The android screen (1.5 cupcake) on Tosh TG01 was taken from intomobile.com
There is no android for HD2 or Acer F1/s200 (and these phones have bigger community) so I don't think someone here will run android on TG01 until it comes for one of these two mentioned above...
you are right..
however I have googled and found these.
http://htcandroid.xland.cz/
http://xdandroid.southcape.org/
I am not into programing but it might give some head start to who want to make it happpen..
I don't know how to go about porting android to TG01, but I'm looking into it... don't know if it will go anywhere but what the hell, it's worth a try.
Source code for the Acer Liquid and the Xperia X10, two Snapdragon phones with both Kernel Source code available
Wyatt said:
I don't know how to go about porting android to TG01, but I'm looking into it... don't know if it will go anywhere but what the hell, it's worth a try.
Source code for the Acer Liquid and the Xperia X10, two Snapdragon phones with both Kernel Source code available
Click to expand...
Click to collapse
Maybe one of the ROM developers can have a look at these and convert the drivers to TG01?!
gamerr120 said:
Maybe one of the ROM developers can have a look at these and convert the drivers to TG01?!
Click to expand...
Click to collapse
I'm downloading 10.04 release of ubuntu, once that is done, i'll compile the kernels and have a go at making android boot with haret on the TG01, tomorrow is my day off so i'll keep you updated if I get anywhere or not
nice on man, that sounds awesome. I'll be at school :/ I wish I could learn how develop like you guys..... maybe this summer?
here is haret for the snapdragon... found it a while back somewhere i don't remember....
thor2002ro said:
here is haret for the snapdragon... found it a while back somewhere i don't remember....
Click to expand...
Click to collapse
Anyone test, i can't now until tomorrow....
Wyatt said:
I'm downloading 10.04 release of ubuntu, once that is done, i'll compile the kernels and have a go at making android boot with haret on the TG01, tomorrow is my day off so i'll keep you updated if I get anywhere or not
Click to expand...
Click to collapse
Good news...
can't wait for the result..
gamerr120 said:
Anyone test, i can't now until tomorrow....
Click to expand...
Click to collapse
Don't know much about Android. But I think Haret is only a bootloader. You still need the Android files to boot.
anon-4 said:
Don't know much about Android. But I think Haret is only a bootloader. You still need the Android files to boot.
Click to expand...
Click to collapse
I have posted a request in android forum. see if any body come here and give us hand,
http://forum.xda-developers.com/showthread.php?p=6341361#post6341361
anon-4 said:
Don't know much about Android. But I think Haret is only a bootloader. You still need the Android files to boot.
Click to expand...
Click to collapse
Yep Haret kills the WinMo kernel to boot another one, i've got the Xperia X10 and Acer Liquid Kernels source code, so i'm going to build them just to see how far it will go and hopefully create a starting point for Android on TG01
Just to keep you updated, i'm not getting anyware for the moment, but i'm not giving up, if anyone has got any info on building a linux kernel for snapdragon please post it
Google Nexus one, acer liquid and many other devices have Snapdragon and Android.
If it's found some info about linux kernel on them, it would be a good starting point, don't you think?
EDIT: I've just google a little and found this:
NEXUS ONE KERNEL POSTED
Cyanogen has developed a web for developing nexus one kernel. So, maybe, you can find something there.
Here you can find a kernel for Nexus One
And here you can find the kernel source for the Acer Liquid
Wyatt said:
Just to keep you updated, i'm not getting anyware for the moment, but i'm not giving up, if anyone has got any info on building a linux kernel for snapdragon please post it
Click to expand...
Click to collapse
Hi, have you installed ubuntu 10.4 yet? Do you like it?
I ask because I am on 9.10 and thinking about upgrade
a_petrov303 said:
Hi, have you installed ubuntu 10.4 yet? Do you like it?
I ask because I am on 9.10 and thinking about upgrade
Click to expand...
Click to collapse
Yep, i've installed the 10.04, and it's pretty cool, on my dell precision m6500, i had a probleme getting the wifi working but other than that it runs like a charm
Has anyone got any idea on how to find the 'RAMADDR' and 'RAMSIZE' for haret ?
these are for HTC diamond witch has 192 mb ram
set RAMSIZE 0x7800000
set RAMADDR 0x10000000
Yeah but it is specific to every phone... so I either somebody already know them, or I need a way to find them..
leepriestenator said:
MODERATOR WARNING!
All of us here are ecstatic that DS is back. This new Build marks the next level in Android Development for WinMo phones. It's a very exciting time but there are a few things we all need to keep in mind.
1) No THANK YOU Posts. Anyone found doing so on high volume threads will be given as infraction. We have implemented a new THANKS button here at XDA. Use that to convey your gratitude.
2) The first few pages of this thread have already informed us of this build being incredibly fast. Everyone knows it now which means NO more "This is so FAST!" posts.
3) There are several issues with this build, which have come to light over the last 30 pages. Check to see if your problem has been listed (Chances are that 999 out of 1000 are already listed). If it is, then you are not allowed to post asking for a solution to the same problem.
4) STRICTLY NO REQUESTS!
Any discussions in this thread have to be limited to the build provided here. No discussions and arguments about the pros and cons of Sense Builds.
5) NO asking for ETA of the next build.
Any deviation from the above will result in an Infraction.
Click to expand...
Click to collapse
---------------------------------------------------------------------------
------------------------------------------------------------
SuperRAM Sense by darkstone1337
Version 0.1
Release: 30-December-2010
Thread: http://forum.xda-developers.com/showthread.php?p=10180198[/SIZE][/U][/B]
------------------------------------------------------------
Click to expand...
Click to collapse
------------------------------------------------------------
If you don't know anything, SEARCH GOOGLE FIRST.
------------------------------------------------------------
What is SuperRAM Sense?
- It is a Sense rom with some modifications added, but kept as close to stock as possible. The only thing that is modified is the keyboard, camera and some icons.
What is special about this build?
- What is special about this build is parts of the Android O/S filesystem are stored in RAM before it is booted.
What does this mean?
- Well, RAM is faster than NAND(ROM) and SD Card which in turn will make the build superfast too! Very fast. Very very fast!
I don't understand what NAND(ROM) or RAM is!
- NAND is a slower memory type (ROM) which is designed to hold data even after the phone is turned off. This is where your Windows Mobile operating system is stored.
- RAM is a much faster memory type which is designed to hold information on a temporary basis. After your phone is turned off, the data in RAM is lost.
- Running Android on your HD2 does not touch your ROM in any way! So when you turn off the phone and turn it back on, Windows Mobile will be loaded. No changes are made to ROM.
Does this mean I'm going to lose the stuff that I put in Android when my phone goes off or crashes?!
- NO. Only the operating system files for this build will be stored in RAM. User data and downloads will be saved to your SD card in a special file called data.img
- Remember if your phone crashes in Android, nothing will affect your Windows Mobile operating system since this build runs off RAM.
What other advantages does this build have?
- Unlike normal builds which are ran from the SD card, this build will not stress your SD card nearly as much. This will allow faster transfer speeds and less chance of data corruption.
- Battery usage will be less than SD card based builds as the operating systems files will be accessed from RAM instead of the SD card.
- Quick android boot!
Something isn't working properly!
- First of all check the build thread by SEARCHING FIRST to see if there is a solution to your problem or if it is already listed as a known issue. If there is no solution and the problem has not been posted by someone else, ONLY THEN should you post here: http://forum.xda-developers.com/showthread.php?p=10180198
- Please include details about the issue, such as how to replicate the problem.
Click to expand...
Click to collapse
------------------------------------------------------------
Installation and Setup:
Make sure that you do not have another Android folder on your SD card. If you do, then either rename the folder or back it up to another location and delete the folder.
Copy the folders named Android and media to the ROOT of your SD card. If you don't know what the root of the SD card is, look here: http://uk.answers.yahoo.com/question/index?qid=20080521052942AAMW3kA
On your HTC HD2, use file explorer to browse to the Android folder on your SD card. Run the program CLRCAD.EXE (nothing is supposed to show up when you run this program.). Then run haret.exe.
You will now see a green HTC logo on a black background for a couple of seconds, then you will see nothing but a blank screen for a couple of seconds.
After this, you will see the HTC Sense unlock screen.
Click to expand...
Click to collapse
------------------------------------------------------------
Notes:
- My own personal thought. I don't know if Sense was worth putting into RAM, I guess I like challanges so I gave it a go. I'm not promising amazing speed with this build.
- Upon booting, your HTC Sense launcher will contain no widgets or icons. It is up to yourself to add widget and icons.
- I have included a 1GB data.img, however you can use any size that you wish if you have your own data.img.
- I highly recommend starting with a new data.img regardless of whether you have used this build previously. There are some changes that may conflict with your current image.
- If you wish to make changes to the build, use the file structure in Android/root/ on your SD card to put your modified files in. They will be copied upon boot. Do not worry if they are not deleted, this is normal.
- Robot voice issue may occur when in a call. If this happens, during the call ENABLE THE LOUDSPEAKER, then DISABLE THE LOUDSPEAKER then END THE CALL. Do this exactly and every call after will no longer have this issue.
- You are left with around 250MB+ free RAM after booting the build. This is enough memory for anything!
- Build.prop is easy to modify, I have included a copy in /Android/root/system on the SD card. Modify this as you with and your changes will be copied over upon the boot of Android. If you mess something up, just delete the file and the changes won't be applied upon next boot. This goes for any file you put in the Android/root/ folder.
- I'm not going to be like other chefs and say "THE BATTERY LIFE IS EXCELLENT I PROMISE" etc. Everyone's setup is different, just test the build for yourself!
- Forget quadrant scores! If you're judging this build by quadrant scores then I pity you. This type of build is different from other builds, yes the quadrant scores may not be in the 2000+ range, but honestly, can you actually say to me that this build is slower than other builds that have a higher score? I sure hope not.
- The base rom is from Lambros Custom Rom r4 Desire rom which has been modified by myself: http://forum.xda-developers.com/showthread.php?t=745447
- The initrd and CSSync updates is based on that from cedesmith. However, I've modified the initrd for my own build.
- The PPP wrapper update is from LeTama's thread, version 0.7
- The HaRet loader is custom made by NetRipper, thanks to him for helping me increase the initial ramdisk size limitation!
- The HTC EVO keyboard is from motoman234 : http://forum.xda-developers.com/showthread.php?t=810338
- The modified HTC EVO Camera is from iamgpc : http://forum.xda-developers.com/showthread.php?t=829534
- Thanks to LeTama for providing a way to create my own htcleo.acdb file!
For developers only:
- The kernel included is hastarin's r8.6 eb kernel, taken from here: http://forum.xda-developers.com/showthread.php?t=787588
- Kernel source: http://www.gitorious.com/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc
Click to expand...
Click to collapse
------------------------------------------------------------
Bugs Fixed in version 0.1:
- No more data corruption. I have enabled sync in initrd.
- Robot voice is very rare now during calls. It should only happen once when you boot for the first time.
- No more high battery drain during sleep! Refer to my post here: http://forum.xda-developers.com/showpost.php?p=10179562&postcount=2293
Bugs Remaining:
- Notification LED's only blink once, use LED me know from market if you want LED notifications. Be warned, power consumption will rise with this.
- Rare robot voice bug
- PPP data should now work correctly for EVERYONE [UPDATE, turns out it's not...]. Thanks to MAsterokki and DutchDanny for pointing out the issue! Take a look here and see if there is a solution to your data problem: http://forum.xda-developers.com/showthread.php?t=892079
------------------------------------------------------------
Thanks to everyone at #htc-linux, #htc-linux-chat and at xda-developers for your help, guidance and support!
Thanks to my beta testers! Thanks to Hastarin for pointing out the toolchain issue which cases high power usage in sleep!
The first boot will take under a minute, subsequent boots will take much less time.
I am running HTC HD2 Stock rom 3.14.405.2.
My radio is 2.15.50.14, I have NO robot noise issue with the combination.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Download: http://www.multiupload.com/UA7FCEFW5T
Screenshots
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
1st time ever being 1st!!!!!!!!!! woot woot partayy nice job
Good news............
woooooo... waited for this .... thanks darkstone ....
Screenhots would be sweet I love the continuing development, but I'm gonna stick to the non-Sense build of DS.
Still, thx for the effort.
Making a good thing even better, greaatt work Darkstone
Can you guys not read, it says big as day no thank you posts
Cool thx good News. I hope the roms for sd card works on cottullas bootloader.
I Hope darkstone has quick internet so this get uploaded quickly cause i can't wait, This is going to be best android build thanks a million for your amazing work and for returning. since i been using your builds from the start.
Edit opps sorry for the "thank you" post just really excited.
what is the defference to SuperRAM_Froyo_1.5?
Patiently waiting for the upload of Awesome Rom on paper..
dratengon said:
what is the defference to SuperRAM_Froyo_1.5?
Click to expand...
Click to collapse
there's a section that says "Bugs Fixed in version 0.1" under that are the changes
dratengon said:
what is the defference to SuperRAM_Froyo_1.5?
Click to expand...
Click to collapse
HTC Sense is included with this build
monx® said:
HTC Sense is included with this build
Click to expand...
Click to collapse
lol the box of worms you've opened will be plentyful
This one come with "SENSE"
dratengon said:
what is the defference to SuperRAM_Froyo_1.5?
Click to expand...
Click to collapse
I think we said that Sense would never be possible? May I ask why it is possible now? Is this a stripped version of sense? What changed?
Lets all wait for to try the build before posting a bunch of nonsense (pun intended). This is supposed to be for feedback and the DL link is not even up so lets not have 5 pages of fluff posts....please...pretty please.
Ok...Except from Sense.... everything should be similair to SuperRAM_Froyo_1.5....right?
Sorry folk... tried so many diff rom.... a bit confuse... maybe too much turkey, ham....
DarkStone1337 said:
which in turn will make the build superfast too! Very fast. Very very fast!
Click to expand...
Click to collapse
DarkStone1337 said:
I'm not promising amazing speed with this build.
Click to expand...
Click to collapse
Haha, I love a guy with a sense of humor. You never cease to entertain (and of course your builds never cease to amaze).
It's interesting you opted to stick with hastarin's EB. That specific (old) driver invariably shuts down my phone at about 9% battery remaining (despite numerous attempts to calibrate and erase entrained charge data), so I was wondering if this build, like many others, can withstand a simple zimage swap with the non-EB kernel. Since this particular thread and build are both so new, I thought it a prime time to ask before ruining something and coming back to complain or whatnot.
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
See Below
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Reserved
Bootstrap-loader (Goal #1)
Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.
Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc
So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This would also allow us to completely replace recovery with CWM.
Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority
CM9 (Goal #2) Inprogress
There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.
There is a number of kernel changes that need to be done:
Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.
This will allow us to a) have revision history b) allow merging up to 3.0 easier
This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
Backport key changes (fattire probably has this already done)
Backport usb gadget
Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
Backport
Current Status:
Teasers:
Wow. Thanks nemith for all the info. I will work with you and 100% will give the donation to them (verbal and writen agreement). From when I was building CWM on the GNex I remeber having to change one of the values in the .mk file to allow for adb.
Hi nemith,
That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions .
I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git
So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:
(cd to u-boot directory and switch to second-uboot branch first, then)
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_irecovery
make
./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size
Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.
There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.
I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
nemith said:
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Click to expand...
Click to collapse
A bit on UI, cleanup, and various boot scenarios
Bauwks.. cool, glad emmc is is a go.
Current Status: Fattire working on a menu for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into
Click to expand...
Click to collapse
UB2 update from me: A fruitful night with lots of fun enhancements, some modest UI feedback, and a sprinkling of safety/sanity fixes and other tweaks. SD and emmc options should be more convenient/consistent now, with recovery selection effectively handled by UB2 not UB1 (though power+n will remain an option obviously). I'll let nemith elucidate.
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Considering I don't have an NT and I'm working blind here with nemith testing... I think this could wind up pretty nifty.
bauwks said:
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
Click to expand...
Click to collapse
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
dhkr234 said:
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
Click to expand...
Click to collapse
Yeah. Or more specifically, everything in those partitions will need to be shoved over by a set amount to make room for UB2.
fattire said:
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Click to expand...
Click to collapse
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
I can't really offer much as I am no android developer. I can modify basics and work thinsg out through educated trial and error but most of what you guys have been on about has been way out of my league. If it makes any difference I have 2 NTs one of which is brand new in a sealed box just sat waiting for the correct time to bother getting it out to play.
I'm quite happy to do testing, tweak things and do what I can where required.
Not sure what happened about the reward thing but as has been said before I think giving it to a good cause is a very decent and honest thing to do.
Doing it and donating the 'winnings' to a good cause is a far better idea and I commend you for following that route. Those that do it solely for the money aren't doing it for the reasons that I think XDA exists and from what I've seen before often get their money out of blatantly using other members hard work to make themselves look good, there always seems to be a lot of sitting on the fence then diving in at the last second and releasing something as their own when most of it isn't.
Anyway, enough babbling from me! Keep up the good work and when you think I can be of any help I will be more than happy to chip in where required.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right? Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...). Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Progress on CM9 from @AndroidNemith http://twitpic.com/86hx6m - Twitter
dhkr234 said:
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right?
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...)
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Click to expand...
Click to collapse
This is not the g2. It's not a write-protected emmc and a power cycle of the emmc will do nothing. I appreciate the enthusiasm, but you're coming to this very late.
More rambling...
If I'm not mistaken, the way you're suggesting is UB2 would be a prepended portion of the boot and recovery images as part of a "package", and this is how we were already discussing doing it in the cm9 build system-- this also matches in effect how Nook Color CM7 distros work-- the bootloader is actually re-installed with every update.zip (to enforce compatibility as newer versions of Android require newer u-boot).
However, I was considering that some people want to swap various u-boots in and out of existing boot or recovery partitions without necessarily having to push aside the rest of the image to make room. So if they're thought of as a unit, it makes total sense to do it as you suggest- but if UB2 is something that can be replaced (or updated) independently, then maybe a standard "buffer" size would be more appropriate.
We've talked about a few ideas- if a simpler boot menu is used to replace UB2, or a redirection to "see other partition for bootloader"... then it could be 512K (or whatever) mostly wasted... which may not be a big deal either.
Anyway, just typin' out loud. Lots of options, and no "right" way to do it.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
aversion of single-point-of-failure
I'd like to recommend, to avert the Single Point of Failure, a manditory and automatic backup of the /ROM/ partition. Since you're developing the first custom kernel, there will be a lot of work based upon yours for this device.
This can be handled in the init scripts. after /ROM/, /system/ and /sdcard/ mount. If the /ROM/ folder is available and there is no backup, make one. This simple step can save alot of grief in the future in case of damage.
Untested code:
Code:
#! /bin/sh
ROMBACKUPDIR="/sdcard/backup/ROM/";
BACKUPFILE=$ROMBACKUPDIR"ROMPARTITION.img";
TESTFILE="/ROM/NAMEOFANYFILE";
ROMPARTITION="/dev/block/***";
busybox test ! -e $ROMBACKUPDIR && mkdir --parents $ROMBACKUPDIR;
#no backup detected, so make one.
busybox test -f /ROM/$TESTFILE && busybox test ! -f $BACKUPFILE && busybox dd if=$ROMPARTITION of=$BACKUPFILE;
where ***=the ROM partition on your kernel and NAMEOFANYFILE=the name of any file on the /ROM/ folder
Whomever is building the AOSP!!!
Be careful with the ICS 4.0.3. There are alot of issues with the way the AOSP market place is working with it. The 4.4.3 Market has a tendancy to crash continually. Might be worth building ICS 4.0.2, and using that to elimitate all the problems whe can.
I have a mac g5 on public ip space and a NT that I can plug in if any dev's want to use that.
other than that, I'm another tester for y'all.
Loglud said:
Adam,
I own the nooktabletdev.org wiki, I will add all of those into it, or allow you an admin account. Then we can just point to there.
Click to expand...
Click to collapse
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Congrats to everyone who cracked it finally
I can say with 90% surity that You can recover a junked ROM partition or for that matter a fully junked eMMC, for the simple fact that it gives other pheriperals a chance before booting into eMMC (cannt say 100 % by myself immidiately now, because have been busy with other stuff at work over the last week, so my memory FIFO wrt my experiments on NookTab is bit blurry now).
AdamOutler said:
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Click to expand...
Click to collapse
Ahhhh, documentation!!!!
But seriously, thanks very much for that.
And FYI: Probably the best place to keep documentation is right here: http://forum.xda-developers.com/wiki/BN_Nook_Tablet -- in the xda device wiki.
Hey guys this just made you famous on the interwebz...
http://www.engadget.com/2012/01/14/nook-tablet-bootloader-bypassed-android-4-0-takes-its-first-ste
Good jorb!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
[ Unofficial CyanogenMod 10 Build on HTC DNA ]
git @ https://github.com/drewx2/android/ (Updated to download all necessary repos)
..CURRENT BUILD NOTES/HISTORY..
03.24.13: CM10 doesn't include support for csd-client enabled phones (which we need). I have built a work around for it to utilize our csd-client lib; hopefully it brings audio one step closer.
My audio changes can be found at a separate git repo @ https://github.com/drewx2/android_hardware_qcom
03.23.13: Current Audio Status
I have some time to look at things, so here just getting started and thought I would post the first strace for those interested. Looks promising and not too difficult.
Code:
writev(4, [{"\4", 1}, {"AudioHardwareALSA\0", 18}, {"ucm instance opened: 1082445752\0", 32}], 3) = 51
writev(4, [{"\6", 1}, {"AudioFlinger\0", 13}, {"int android::load_audio_interfac"..., 103}], 3) = 117
writev(4, [{"\4", 1}, {"AudioFlinger\0", 13}, {"loadHwModule() error -22 loading"..., 49}], 3) = 63
writev(4, [{"\5", 1}, {"AudioPolicyManagerBase\0", 23}, {"could not open HW module primary"..., 33}], 3) = 57
writev(4, [{"\6", 1}, {"AudioPolicyManagerBase\0", 23}, {"Not output found for attached de"..., 47}], 3) = 71
writev(4, [{"\6", 1}, {"AudioPolicyManagerBase\0", 23}, {"Failed to open primary output\0", 30}], 3) = 54
writev(4, [{"\6", 1}, {"AudioPolicyManagerBase\0", 23}, {"getDeviceForStrategy() speaker d"..., 74}], 3) = 98
clock_gettime(CLOCK_MONOTONIC, {205, 684889413}) = 0
writev(4, [{"\6", 1}, {"AudioPolicyManagerBase\0", 23}, {"getDeviceForStrategy() speaker d"..., 74}], 3) = 98
writev(4, [{"\6", 1}, {"AudioPolicyService\0", 19}, {"couldn't init_check the audio po"..., 54}], 3) = 74
ioctl(3, 0xc0186201, 0xbe961a28) = 0
Complete strace available here: http://bit.ly/Xx3M0v
-------------------------------------------------------------------------------------------------------------------------------------
There won't be any builds posted until one of the "not working" items has been fixed. I mostly likely will focus on audio this weekend.
If you have something meaningful to share, please visit http://webchat.freenode.net/?channels=CM10DNA
03.04.13 @ 03:29AM: Wifi *now* really working
03.04.13 @ 03:29AM: Wifi now working.
Enable 3 dot menu: Settings -> Hardware keys -> Show action overflow [check]
Working:
Radio/RIL (no sound, so can't hear yet), SMS / MMS, 3G / 4G Data, Display, Orientation, Sensors, Lights, NFC, Torch, GPS (not tested), Wifi
Not working:
Camera, Audio, Bluetooth
To Do list
I plan to do bionic/kernel optimizations once all features working.
Click to expand...
Click to collapse
..INSTALL INSTRUCTIONS..If you do not have S-OFF, you need to unzip the file and flash the boot.img inside via fastboot.
Install Instructions:
1) Download http://bit.ly/W0RAY8
2) Reboot to recovery of your choosing; wipe system/data/dalvik-cache/cache.
3) Install downloaded zip
4) Reboot.
5) Enjoy.
Google Apps @ http://goo.im/gapps/gapps-jb-20121011-signed.zip
Click to expand...
Click to collapse
Click to expand...
Click to collapse
.SPECIAL THANKS FOR DONATING.
RuinedByMTV, drmp3z
kronikings, danahern, karn101, Majik Mushroomz, Matt P., Matt B., pio_masaki, Droidika, Wheelchairmitch, MrIcky, liquidhaste, jamiethemorris, rainabba
.SPECIAL THANKS.
Flyhalf205, x3demond3x[debugging]
dsb9938 [cmdline boot option]
x3demond3x [egl fix]
Jarocks [resized bootanimation/debugging], pio_masaki [debugging],
jcase [unlock], dees_troy [twrp], beaups, jcase, Dr_Drache, dsb9938 [S-OFF]
.... and of course the CyanogenMod team and those who laid the foundation for the DNA....
..WANT TO HELP? HERE ARE SOME DEBUGGING TIPS..1) Flash boot.img
2) On cmdline do "adb logcat"
Click to expand...
Click to collapse
If you're ever in the mood to donate, don't forget about the others that have helped advance the HTC DNA to new levels (e.g. dsb9938, jcase, Dr_Drache, beaups, CM team, or XDA for bringing us all together!). Although, I may be working on CM and it may seem like a completely different project, in many ways we all rely on each other to help make the DNA better.
Click to expand...
Click to collapse
I can't help you with specifics but the guys over on the nook color forums have great guides on building and may be amenable to questions if no one here gives you anything useful
sent from my unlocked and rooted droid DNA
jamesbra said:
I can't help you with specifics but the guys over on the nook color forums have great guides on building and may be amenable to questions if no one here gives you anything useful
Click to expand...
Click to collapse
Thanks. Brings me back to the days when I was writing some early scripts for the Nook Color... when you had to flash the "harder" way. Anyhow, it reminded me of just mounting each partition separately (/dev/block/mmcblk0pXX). Found kernel/system logs, just what I wanted.
What about radio??
Sent from my HTC6435LVW using xda premium
typeriz said:
What about radio??
Sent from my HTC6435LVW using xda premium
Click to expand...
Click to collapse
That's a whole separate issue. We can have a Rom booting and usable without the ril working. Granted, this booting will most likely help with ril advancement.
Sent from outer space...
drewX2 said:
I've successfully built CM 10 on the DNA, however I'm stuck with debugging after booting in standby (assuming). For those that have built new roms on unsupported devices, how did you debug the boot process? Yes, I understand to use logcat/ddms/etc. I boot into standby with a black screen (no boot loop). Sdcard mounts once I get to black screen, however I built kernel from source as well so no hacks have been applied yet.
Also, when taking any kernel available right now, pulling it apart and remerging with no changes (just verifying process), I go into a boot loop on a working Rom (genome/ukb)
This is what I am doing to recreate boot.img:
Code:
(boot.img taking from DNA cubed kernel, I've renamed kernel and ramdisk)
unbootimg boot.img
mkbootimg --output boot.img --kernel kernel --ramdisk ramdisk.cpio.gz --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=dlx user_debug=31' --board '' --base 80600000 --pagesize 2048
Any tips would be great so I can finish up and share. Seems so silly that I can't even remake a working boot.img after spending 20+ hrs working on CM10. It seems I'm a bit slow to get back into the swing of things since taking a hiatus from programming for several years.
Click to expand...
Click to collapse
I have gotten to the same point as you in my AOSP venture with the DNA. From my findings, without the correct kernel drivers being administered from the gate, the USB (debugging) features are not going to work properly. I am in the process of finding a kernel developer who is familiar with Sense (HTC) devices to build the proper kernel to make this possible. With the help of Dr_Drace I was able to put together a working DLX build tree and have successfully compiled FactoryROM (which is 4.2 AOSP based) but am stuck at the end of the boot process. And like you, I am unable to gather any logs due to the lack of USB access. We need a reliable kernel developer to get us past the hurdle. Unfortunately I am not one of them. As far as RIL, it's anyone's guess as to its functionality once we get things booting correctly. We have all of the drivers, it's just making them work together. :fingers-crossed:
MyComputerDoctor said:
I have gotten to the same point as you in my AOSP venture with the DNA. From my findings, without the correct kernel drivers being administered from the gate, the USB (debugging) features are not going to work properly. I am in the process of finding a kernel developer who is familiar with Sense (HTC) devices to build the proper kernel to make this possible. With the help of Dr_Drace I was able to put together a working DLX build tree and have successfully compiled FactoryROM (which is 4.2 AOSP based) but am stuck at the end of the boot process. And like you, I am unable to gather any logs due to the lack of USB access. We need a reliable kernel developer to get us past the hurdle. Unfortunately I am not one of them. As far as RIL, it's anyone's guess as to its functionality once we get things booting correctly. We have all of the drivers, it's just making them work together. :fingers-crossed:
Click to expand...
Click to collapse
I'm just going to try stripping as much away as I can to boot and then slowly add things back in. On a side note, I've made a working version of touch clockworkmod recovery. I am going to modify it to add some additional options before sharing (unless someone gets around to it before I do).
What I suggest doing is mounting /dev/block/mmcblk0p24 manually via working recovery. This is the log partition; system.log and kernel.log are written to it.
Please keep us updated on your progress. It would be greatly appreciated. And yes you may be part god.
Please try to keep this thread focused on development and free of clutter. The Thanks button still works just fine.
Do either of you have the device/vendor posted to Github by chance? I actually started putting one together but haven't had much time to actually make progress.
Which kernels have you used with source built Rom? Tried the stock kernel by chance? I always feel its a good starting point. Have either of you uploaded the zip? I can flash and take a look... They say two heads are better then one so if we're all working on the same thing I'm sure progress will be made! Lol
Sent from my HTC6435LVW using Tapatalk 2
Ill try to get it up or post a zip tonight (not workable, but see if you can troubleshoot ). I was off for a bit bit but now working four long shifts in a row.
I contacted cayniarb.. most familiar will remember him from all the tiamat htc kernels.. not sure if he will help but i sent him a link to the forum for him to take a look..
---------- Post added at 08:35 PM ---------- Previous post was at 07:53 PM ----------
since i am not versed in helping you guys ill will post cayniarbs comments in hopes something might give you a idea.. we talk breifly and when i say breifly it was only a few lines... " ok this isnt a unexpected problem the devs should try to straight up disabling problem drivers--- turning off usb means no debugging , but it might also make it boot---- as far the actual kernel changes for that it will consist of of rippin gour the sense usb drivers and replacing them with google driver.. by disable i mean just cut the init references out of the ramdisk"
hope this gives someone and idea that maybe they didnt have before.. sorry i can be no help- my skill dont lend to being this early in the project.
leech2082 said:
I contacted cayniarb.. most familiar will remember him from all the tiamat htc kernels.. not sure if he will help but i sent him a link to the forum for him to take a look..
---------- Post added at 08:35 PM ---------- Previous post was at 07:53 PM ----------
since i am not versed in helping you guys ill will post cayniarbs comments in hopes something might give you a idea.. we talk breifly and when i say breifly it was only a few lines... " ok this isnt a unexpected problem the devs should try to straight up disabling problem drivers--- turning off usb means no debugging , but it might also make it boot---- as far the actual kernel changes for that it will consist of of rippin gour the sense usb drivers and replacing them with google driver.. by disable i mean just cut the init references out of the ramdisk"
hope this gives someone and idea that maybe they didnt have before.. sorry i can be no help- my skill dont lend to being this early in the project.
Click to expand...
Click to collapse
Thanks for helping out anyway you can. Now that I've completed my work stretch, I can go back to working on this a bit. What he is saying is essentially what I am doing, however, the simple fact of taking a working boot.img, splitting it up, then remaking with zero changes and it it not working anymore has eluded me.
drewX2 said:
Thanks for helping out anyway you can. Now that I've completed my work stretch, I can go back to working on this a bit. What he is statins is essentially what I am doing, however, the simple fact of taking a working boot.img, splitting it up, then remaking with zero changes and it it not working anymore has eluded me.
Click to expand...
Click to collapse
Wink, wink!
D
.
dsb9938 said:
Wink, wink!
D
.
Click to expand...
Click to collapse
Haha judging by the amount of thanks I think we are all hoping that aosp is coming really soon for xmas and you guys are just playing us, haha. Thank you for your amazing work bringing the world of real android closer to reality
leech2082 said:
I contacted cayniarb.. most familiar will remember him from all the tiamat htc kernels.. not sure if he will help but i sent him a link to the forum for him to take a look..
---------- Post added at 08:35 PM ---------- Previous post was at 07:53 PM ----------
since i am not versed in helping you guys ill will post cayniarbs comments in hopes something might give you a idea.. we talk breifly and when i say breifly it was only a few lines... " ok this isnt a unexpected problem the devs should try to straight up disabling problem drivers--- turning off usb means no debugging , but it might also make it boot---- as far the actual kernel changes for that it will consist of of rippin gour the sense usb drivers and replacing them with google driver.. by disable i mean just cut the init references out of the ramdisk"
hope this gives someone and idea that maybe they didnt have before.. sorry i can be no help- my skill dont lend to being this early in the project.
Click to expand...
Click to collapse
Leech I actually worked with him two weeks ago to build an Tiamat AOSP kernel for the DNA. Since then I've had my birthday and 3 family members birthdays and now Christmas. The zip is still on my system waiting to be flashed We'll get it to work. The dudes built kernels for every single HTC device to date practically. I have faith.
Kernel building no longer issue. I just had one command left out which kept giving me a PITA. Now to find out which things can be eliminated from HTC and still boot.
And now to get the hardware to work properly lol. Battle has just begun. Great work guys. Will be downloading and attempting to fix some things after Xmas.
Sent from my DNA.
When did they add xxhdpi to aosp?
Sent from my SGH-I747 using Tapatalk 2
idkwhothatis123 said:
And now to get the hardware to work properly lol. Battle has just begun. Great work guys. Will be downloading and attempting to fix some things after Xmas.
Sent from my DNA.
Click to expand...
Click to collapse
Do you really have to wait until after Christmas? Come on.
:victory:
So, since the Pixel and newer Nexus devices are now getting their Oreo updates, I think it's time that we, the developers who still own Nexus 6's, to look into porting Oreo to this device. I am looking into the source code as we speak for feasibility. If anything, I will probably do like I have done with most of my devices in the past, forge the path and create a guide, and let everyone else do the creative stuff. I just happen to like stock Android.
There is already one dev who got Oreo to boot on the Xiaomi Mi 3, runs on SD800 (32bit)
konradit said:
There is already one dev who got Oreo to boot on the Xiaomi Mi 3, runs on SD800 (32bit)
Click to expand...
Click to collapse
Looking promising,fingers crossed
Sent from my Nexus 6 using Tapatalk
There ARE people working on Android O port, even back when it was still in developer preview status. You'll see releases whenever they are ready, I'd give it a few weeks or months.
I won't argue if you're a developer or not, I'm sure you are. But you are not a "recognized developer". Your title is member
Dopamin3 said:
There ARE people working on Android O port, even back when it was still in developer preview status. You'll see releases whenever they are ready, I'd give it a few weeks or months.
I won't argue if you're a developer or not, I'm sure you are. But you are not a "recognized developer". Your title is member
Click to expand...
Click to collapse
Getting it to build is easy. Ive already done as much but without updated binaries (which I havent seen for any device) it wont boot. There are likely some kernel changes needed as well though I havent dug to much into that yet. Then there is the whole GApps for Oreo issue. I would say we are definitely a week or so away from anything working.
Things are in the works and if gapps don't work for 32 bit.. I suggest you gentlemen familiarize yourself with microG
I built it from developer preview 2 a couple months ago. Booted and everything, but nothing as far as any of the radios worked. I had to modify franco kernel to get it there, but it did work..
I tried re-building it after the stable source dropped and can't seem to get passed this error:
frameworks/native/include/gui/IGraphicBufferProducer.h:35:10: fatal error: 'hidl/HybridInterface.h' file not found
The file is there and where it should be... So I'm kinda scratching my head as to where the switch is that causes it not to pick up that location.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
So the development for Xiaomi Mi3/Mi4 has gone online: https://forum.xda-developers.com/xiaomi-mi-3/development/8-0-aosp-t3662028
The source code is not available yet but is on it's way. Maybe there might be hints on what's needed for us to make stuff work on the shamu once the source is online(?). I'm aware they are completely different devices but the architecture are closer as they both are 32bit rather than the newer devices running 64bit.
I was able to get a build to complete but it doesn't boot. I don't have the time today to go over it, but if anyone has some free time, feel free to take a look at the logcat and see if anything jumps out immediately.
boot.log
kkozma said:
I was able to get a build to complete but it doesn't boot. I don't have the time today to go over it, but if anyone has some free time, feel free to take a look at the logcat and see if anything jumps out immediately.
boot.log
Click to expand...
Click to collapse
@followmsi build had a similar issue yesterday on the Nexus 7 2013 forums. I tested the build and it would not get to the boot animation and would restart to the bootloader after about a minute. After returning to TWRP the data partition was either corrupted or unreadable. OP said that it was probably the fact of missing SDcardFS support in the recovery/kernel.
https://forum.xda-developers.com/nexus-7-2013/development/rom-t3569067/page60
the struggle continues.
wavedashdoc said:
@followmsi build had a similar issue yesterday on the Nexus 7 2013 forums. I tested the build and it would not get to the boot animation and would restart to the bootloader after about a minute. After returning to TWRP the data partition was either corrupted or unreadable. OP said that it was probably the fact of missing SDcardFS support in the recovery/kernel.
https://forum.xda-developers.com/nexus-7-2013/development/rom-t3569067/page60
the struggle continues.
Click to expand...
Click to collapse
He is wrong. The sdcardfs is a file system for sdcard enabled devices. Nothing to do with the nexus 6. It was even removed in most other builds for the device. The only people that added it were people that didn't understand what they were doing.
wrongway213 said:
Things are in the works and if gapps don't work for 32 bit.. I suggest you gentlemen familiarize yourself with microG
Click to expand...
Click to collapse
Late reply here.
I have tried MicroG before - on a custom Galaxy S4 ROM - and I like MicroG about as much as I like Xposed. If MicroG is required I won't be upgrading.
wrongway213 said:
Things are in the works and if gapps don't work for 32 bit.. I suggest you gentlemen familiarize yourself with microG
Click to expand...
Click to collapse
People are not gonna do that. Microg is known for causing its own issues.
Strephon Alkhalikoi said:
Late reply here.
I have tried MicroG before - on a custom Galaxy S4 ROM - and I like MicroG about as much as I like Xposed. If MicroG is required I won't be upgrading.
Click to expand...
Click to collapse
zelendel said:
People are not gonna do that. Microg is known for causing its own issues.
Click to expand...
Click to collapse
It's been confirmed that gapps for arm are working since I posted that, so it's a moot point now, thankfully.
zelendel said:
He is wrong. The sdcardfs is a file system for sdcard enabled devices. Nothing to do with the nexus 6. It was even removed in most other builds for the device. The only people that added it were people that didn't understand what they were doing.
Click to expand...
Click to collapse
Oh mate, you're so wrong. SDcardFS is a virtual FS for emulating /sdcard/ (/storage/emulated/0) and EVERY android device has it. It's just a replacement for vFAT (virtual FAT). One of the most important fixes is that the file timestaps won't get corrupted anymore (this bug existed in android for years).
Lawstorant said:
Oh mate, you're so wrong. SDcardFS is a virtual FS for emulating /sdcard/ (/storage/emulated/0) and EVERY android device has it. It's just a replacement for vFAT (virtual FAT). One of the most important fixes is that the file timestaps won't get corrupted anymore (this bug existed in android for years).
Click to expand...
Click to collapse
vfat is a real filesystem for block devices. Think of it as being in between FAT and FAT32. What it adds over FAT is a virtual file NAMING convention in order to exceed the standard "8.3" filename format that FAT was stuck with. vfat is also the NAME of the linux implementation of FAT (FAT12, FAT16), VFAT, and FAT32.
What you are thinking of as being present on "EVERY" android device, is this; https://android.googlesource.com/pl...197870433386fb809d34b58b30fc0/sdcard/sdcard.c
You should pay attention to the README section of it starting at line 32.
When Android devices used to have an actual sdcard, it was formatted using vfat (the linux implementation of FAT32), with a mount point of /sdcard.
When they stopped including real sdcards, they started emulating sdcards using that FUSE simulated vfat I linked to above.
Now what sdcardfs is, is (a) a replacement for the FUSE filesystem I linked to above, and (b) a replacement for FUSE itself. Think of it as a scaled back and simplified FUSE+sdcard.c. The problem with FUSE is that it is too complex and with too high of an overhead. It causes performance degradation. And I'm not talking about the general userspace degradation that you would get with, for example, NTFS-3g compared to a native implementation, but rather the sdcard.c adds some problems because it is actually *abusing* FUSE. FUSE isn't designed or intended to wrap one filesystem with a simulation of a different one. FUSE is intended to actually implement a filesystem proper. What that means is that the kernel performs certain filesystem operations on the FUSE filesystem, which calls back to essentially perform the same operations on the base filesystem (ext4). Double the operations. Also double the caching, which is horrendous because it means that you are storing the same cached file in RAM twice. That is the kind of thing that sdcardfs is intended to solve.
Now personally, I completely disagree with this approach. Sdcardfs (as with FUSE+sdcard.c) is a backwards compatibility layer that really should be removed altogether. Instead, access controls to the data really should be by way of ACLs. Yes, this will break some very old software, but its the right way to move forward.
kkozma said:
I was able to get a build to complete but it doesn't boot. I don't have the time today to go over it, but if anyone has some free time, feel free to take a look at the logcat and see if anything jumps out immediately.
boot.log
Click to expand...
Click to collapse
Well, the first thing that stands out is this;
03-13 02:38:08.029 0 263 W VendorServiceManager: failed to open binder driver /dev/vndbinder
Indeed, the factory kernel does not have any such driver. This is probably something related to "Project Treble", which is supposed to make it simpler to update the android platform while leaving the *vendor* platform unchanged. Sounds like this driver will have to be added to the kernel.
https://android-developers.googleblog.com/2017/07/shut-hal-up.html
There is also this, which happens immediately before the SIGABRT for surfaceflinger:
03-13 02:38:09.975 298 298 F Gralloc2: gralloc-mapper must be in passthrough mode
Code:
Mapper::Mapper()
{
mMapper = IMapper::getService();
if (mMapper == nullptr || mMapper->isRemote()) {
LOG_ALWAYS_FATAL("gralloc-mapper must be in passthrough mode");
}
}
That gralloc issue could be a consequence of the vndbinder issue.
Hmm... https://github.com/SiXROM/platform_device_moto_shamu/commit/86ebb7db1b0a23c4d0a09568a6414d3b9f140596
Note that their changes to the BoardConfig.mk are bogus, none actually apply to this hardware. But the additional PRODUCT_PACKAGES are possibly meaningful.
Might try a build using these three projects;
<project path="device/moto/shamu" name="platform_device_moto_shamu" groups="device,shamu,broadcom_pdk,generic_fs,pdk" remote="sixoreo" revision="oreo" />
<project path="kernel/moto/shamu" name="platform_kernel_moto_shamu" groups="device,shamu,broadcom_pdk,generic_fs,pdk" remote="sixoreo" revision="oreo" />
<project path="vendor/moto" name="platform_proprietary_vendor_moto" remote="sixoreo" revision="oreo" />
sixrom has also made a whole lot of other changes, but I suspect that they are more related to customizations rather than actual device functionality.
I had seen the vndbinder thing the other day and added it to the kernel I'm using. I actually had it booting yesterday, but managed to hose it up trying to fix bluetooth and then ended up losing my boardconfig.mk and device.mk so I have to start over on those two.
I actually tried building with that sixrom repo and it wouldn't boot at all. I suspect it's because it's based on Lineage whereas mine is straight from AOSP.
Getting ready to play around with it some more, hopefully I can get back to a booting rom again!
kkozma said:
I had seen the vndbinder thing the other day and added it to the kernel I'm using. I actually had it booting yesterday, but managed to hose it up trying to fix bluetooth and then ended up losing my boardconfig.mk and device.mk so I have to start over on those two.
I actually tried building with that sixrom repo and it wouldn't boot at all. I suspect it's because it's based on Lineage whereas mine is straight from AOSP.
Getting ready to play around with it some more, hopefully I can get back to a booting rom again!
Click to expand...
Click to collapse
How do you lose your make files? Did you forget to commit them to your git?
Commit often, ESPECIALLY when you have things (anything) working.
Then if you bugger it up, just roll it back, of git diff it to see what you changed.
I don't see any evidence of sixrom being based on anything besides aosp (certainly not lineage/cm)
Take a peek at their manifest, there's a few frameworks that they've messed with, a bunch of applications, but its mostly AOSP;
https://github.com/SiXROM/manifest/blob/oreo/default.xml
Yeah, that was a real derpasaurus moment for me there, but I'm back to a bootable situation.
- Bluetooth is still broken
- No Cellular Radio
- WiFi connects but causes a reboot immediately
- Not able to view anything on the SD Card & Camera asks for an SD card to be inserted. Oddly enough I am able to play the music that's on my sdcard.
I'll get everything pushed up to my github later so if anyone else wants to tinker with it...
They probably haven't pushed the working updates to device to get to where they. As I said, I built directly from their repo and it didn't work at all.
Edit: my github is https://github.com/vwmofo
if you want to put together a local manifest and pull it down, feel free.