Related
hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J
Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1
ETA
depending on problems and developers that will join
from 6 months to NEVER
This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus
I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.
All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?
CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.
Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse
FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page
diff is 5mb on proper tag
pushed on github
nice to see so many developers trying to help
FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes
UnityROM-2 v.2.5.0
*****Discontinued.... No way to test actively till I have a functional build.*****
HTC One M7 Sprint Edition ( m7spr )
Development Section...
Want to contribute to the project or become team member?
Contact Me by PM here or leave a post detailing what you can and are willing to do for the projects' advancement.
My Github: https://github.com/LiquidSmokeX64
All current project sources can be found there .
ALSO MY FOOL-PROOF BUILD GUIDE & SCRIPTS ARE THERE FOR THOSE TOO IMPATIENT TO WAIT FOR MY NEXT RELEASE .
**Sources current as of version 2.5.0**
**10/06/2014**
Direct link to guide:
https://github.com/LiquidSmokeX64/Guides-Scripts
Note: Noob Friendly. If you're new to building ROMs or have never done it at all. I will help for as long as you maintain civility and focus on the project goals.
Installation errors out. Here is a pastebin of log saved after error
http://pastebin.com/fz15gwwn
Edit: I was able to install after removing that set perm line from updater. I will let ya know how it goes.
gruesomewolf said:
Installation errors out. Here is a pastebin of log saved after error
http://pastebin.com/fz15gwwn
Edit: I was able to install after removing that set perm line from updater. I will let ya know how it goes.
Click to expand...
Click to collapse
Ok. I just removed it too. My bad adaptation from Evo LTE. Nothing too bad luckily.
Reuploading the fixed version now.
LiquidSmokeX64 said:
Ok. I just removed it too. My bad adaptation from Evo LTE. Nothing too bad luckily.
Reuploading the fixed version now.
Click to expand...
Click to collapse
Seems to be running very well, once I got past that installation error....
Nice and smooth, especially with my aosp kernel...
gruesomewolf said:
Seems to be running very well, once I got past that installation error....
Nice and smooth, especially with my aosp kernel...
Click to expand...
Click to collapse
So. You're a kernel dev... Got a question for you. How do I add more CFLAGS to the makefile without it not booting or whatever? I've tried adding -O3 to the 2 places I know to put CFLAGS. Same place I put the -w so it would work with GCC 4.8
gruesomewolf said:
Seems to be running very well, once I got past that installation error....
Nice and smooth, especially with my aosp kernel...
Click to expand...
Click to collapse
Will you be releasing this kernel for the Evo 4G? [emoji14] Evo4gnoob here
LiquidSmokeX64 said:
So. You're a kernel dev... Got a question for you. How do I add more CFLAGS to the makefile without it not booting or whatever? I've tried adding -O3 to the 2 places I know to put CFLAGS. Same place I put the -w so it would work with GCC 4.8
Click to expand...
Click to collapse
I wouldn't say Im a kernel dev....more of a dabler...lol. I sent you a pm with my makefile so you can see adjustments I made for my kernels latest build (not yet publicly released)
Notorious said:
Will you be releasing this kernel for the Evo 4G? [emoji14] Evo4gnoob here
Click to expand...
Click to collapse
Umm....no I dont have any plans for that ATM
gruesomewolf said:
I wouldn't say Im a kernel dev....more of a dabler...lol. I sent you a pm with my makefile so you can see adjustments I made for my kernels latest build (not yet publicly released)
Umm....no I dont have any plans for that ATM
Click to expand...
Click to collapse
Was joking lol
Notorious said:
Was joking lol
Click to expand...
Click to collapse
So you're allowing the integration of it? Just to be clear.
So I'm not sure why but the kernel borked again. Maybe I need to go through one flag at a time? Or maybe forgot something....?
gruesomewolf said:
Seems to be running very well, once I got past that installation error....
Nice and smooth, especially with my aosp kernel...
Click to expand...
Click to collapse
Hey. Im having nothing but issues building it in the ROM so I was curious if you could tell me what I need to do after copying the msm8960 folder to a new place and adding in the makefile changes? Ive never built a kernel independently before but would like it to be a boot.img like normal so I can just replace the one in the ROM zip with the new one. Im sure it's pretty easy, just figured I'd ask you rather than comb through 80 guides saying different stuff lol.
LiquidSmokeX64 said:
Hey. Im having nothing but issues building it in the ROM so I was curious if you could tell me what I need to do after copying the msm8960 folder to a new place and adding in the makefile changes? Ive never built a kernel independently before but would like it to be a boot.img like normal so I can just replace the one in the ROM zip with the new one. Im sure it's pretty easy, just figured I'd ask you rather than comb through 80 guides saying different stuff lol.
Click to expand...
Click to collapse
Could you pm me with more info. Exact process of building, errors during build, any changes made to source, etc.
I'm gonna download your source later, together we should be able to figure this out.
gruesomewolf said:
Could you pm me with more info. Exact process of building, errors during build, any changes made to source, etc.
I'm gonna download your source later, together we should be able to figure this out.
Click to expand...
Click to collapse
I'm not seeing errors. Hell I removed everything but the -O3 spots and it still refused to boot. I dont know what the deal is....
Anytim I do ANYTHING to the kernel its dead, no matter how stupid it is.
gruesomewolf said:
Could you pm me with more info. Exact process of building, errors during build, any changes made to source, etc.
I'm gonna download your source later, together we should be able to figure this out.
Click to expand...
Click to collapse
BTW. The makefile is borked. And was curious if you knew how to build AOSP for this device? CM was pretty easy, I'd figure AOSP isn't too different. Then I can try to get Android L running once I have a working Android K to cross-reference to and make the version specific changes in device, kernel, vendor, qcom-common, and s4-common
LiquidSmokeX64 said:
So. You're a kernel dev... Got a question for you. How do I add more CFLAGS to the makefile without it not booting or whatever? I've tried adding -O3 to the 2 places I know to put CFLAGS. Same place I put the -w so it would work with GCC 4.8
Click to expand...
Click to collapse
When certain flags or 03 is added it creates a larger zImage. In order to compensate the boot.img needs needs modified, either by kernel installer or if baked in the rom hex edited. To change the ramdiskaddr.
Sent from my HTCONE using Tapatalk
thicklizard said:
When certain flags or 03 is added it creates a larger zImage. In order to compensate the boot.img needs needs modified, either by kernel installer or if baked in the rom hex edited. To change the ramdiskaddr.
Sent from my HTCONE using Tapatalk
Click to expand...
Click to collapse
Absolutely correct. And to elaborate on this just a bit more. Since your source building here, you can actually adjust the ramdiskadd with the scripts, considering it uses mkbootimg commands to build the boot.img.
An additional line in your devices board config, to give it a new ramdiskaddr size. Then an additional line in the build folder factory_ramdisk.mk , to handle the command for a new ramdiskaddr size should do the trick.
As for your other question about building aosp. I'm afraid that would be beyond my area of expertise. You would have significantly modify aosp code to allow for caf. It would be much harder then building cm, cause cm already has all the adjustments needed for caf devices
thicklizard said:
When certain flags or 03 is added it creates a larger zImage. In order to compensate the boot.img needs needs modified, either by kernel installer or if baked in the rom hex edited. To change the ramdiskaddr.
Sent from my HTCONE using Tapatalk
Click to expand...
Click to collapse
gruesomewolf said:
Absolutely correct. And to elaborate on this just a bit more. Since your source building here, you can actually adjust the ramdiskadd with the scripts, considering it uses mkbootimg commands to build the boot.img.
An additional line in your devices board config, to give it a new ramdiskaddr size. Then an additional line in the build folder factory_ramdisk.mk , to handle the command for a new ramdiskaddr size should do the trick.
As for your other question about building aosp. I'm afraid that would be beyond my area of expertise. You would have significantly modify aosp code to allow for caf. It would be much harder then building cm, cause cm already has all the adjustments needed for caf devices
Click to expand...
Click to collapse
I read this and my eyes glaze over. But you are in good hands with these two helping you. :highfive:
Yeah I'm working on it guys. Read the integrated kernel building guide and trying that. But if I could just get it to build me the boot.IMG and get my ramdisk sizes and whatever I'm looking at where to edit it in the device/BoardConfig changed the defconfig to a custom one I made based off the original one from the working boot.IMG but changed the I/O scheduler & CPU governed defaults. Gave it a local name (UnityKernel-x.x.x) and am fighting its last issues. So if nothing else help building it independently might be the most useful now. So if nothing else I can push a new boot.img
My bad. It just says the boot partition size so I think I might be almost there
Hello there, it's time to get this rolling somewhere.
This is a Development-Thread. Please don't post if you aren't a developer.
What this IS
This is a Development thread, a platform for developers to discuss the development of CyanogenMod for the G925F. It's made so that we can get this working, fix up the problems - because there will be severe ones - and achieve a working official Rom at some point.
At the moment it's @OldDroid and me with help, but it would be awesome if interested devs would join in so that we can make this a team effort.
In short, it's a Dev-Thread in a dev section.
Right now it doesn't work and I'm not sure that it will work.
What this IS NOT
This is NOT a working Rom. Not even close. I can only link you to the kernel repo and soon to device and vendor, as they are almost completed for a first try.
And yes, there is no download link for the Rom. Because there isn't anything you could download yet.
This is also NOT intended as a Q&A thread. Please don't ask if your variant will be supported, I will respond by trolling. Firstand only priority is to get this running, then we'll talk about variants.
And ETA is an evil word with no meaning here. I work slowly, deal with it
Where are we currently?
Much further than a day ago
Thanks to @OldDroid, we've teamed up
All the links you want (minus the download link :angel
device: (soon, almost complete)
https://gitlab.com/mythos234/device_samsung_zeroltexx
vendor:
https://gitlab.com/mythos234/vendor_samsung_zerolte
kernel:
https://gitlab.com/mythos234/zerolte-kernel-CM
Once available, buggy alpha builds will be posted here
///
vendor and device will soon be pushed to my github
Reserved
i'll join you ... also started working on cm12.1 for s6 edge 5 days ago (currently in england with my school class)
vendor is setup
OldDroid said:
i'll join you ... also started working on cm12.1 for s6 edge 5 days ago (currently in england with my school class)
Click to expand...
Click to collapse
Welcome aboard then
vendor is finally setup and good to go!
https://github.com/mythos234/vendor_samsung_zerolte
It's apparently not without some minor casualties, but we got it. Huge thanks to @RaymanFX, he's helping me, since I'm not that much into CM building yet and I'm also basing this project on his CM for the N910C, which's 5433 is darn similar to our 7420, so we got a pretty good base to begin with.
add me as participant to the repos ^^
https://github.com/OldDroid
OldDroid said:
add me as participant to the repos ^^
https://github.com/OldDroid
Click to expand...
Click to collapse
Done for all the 3 of them
Looks like I killed Bluetooth for now (lol). Other than that it's slow but steady progress.
mythos234 said:
Looks like I killed Bluetooth for now (lol). Other than that it's slow but steady progress.
Click to expand...
Click to collapse
What do you mean "killed"? Killed the chip or wiped the MAC addr. or something?
nasko_spasko said:
What do you mean "killed"? Killed the chip or wiped the MAC addr. or something?
Click to expand...
Click to collapse
I'm currently building the Rom with completely removed Bluetooth support
First Build is compiled and ready for a test.. But I can't install the zip. This would be hillarious if it wasn't so annoying
mythos234 said:
Besides I said it can't be installed Hard to test something you can't even install
Click to expand...
Click to collapse
I think that there was a mistake in the partition sizes.. /system was declared as 4.1GB, but it's only 3.6GB. Recompiling with a new value, should be able to flash it then
Good luck develop without documentation for exynos chipset.
But can you tell us more in details how porting works and what are the challenges with it.
Is it hard to develop a rom without samsung binary files and drivers? I know they are proprietary and closed soruce.
If just Samsung could be more developer friendly like Sony.
We can request source for closed binaries here, http://opensource.samsung.com/reception/receptionSub.do?method=inquiryView, most likely they wont answer
Aircondition said:
Good luck develop without documentation for exynos chipset.
Click to expand...
Click to collapse
The lack of drivers makes this a fun exercise almost Where's be the challenge if everything was easy...?
Aircondition said:
Good luck develop without documentation for exynos chipset.
But can you tell us more in details how porting works and what are the challenges with it.
Is it hard to develop a rom without samsung binary files and drivers? I know they are proprietary and closed soruce.
If just Samsung could be more developer friendly like Sony.
We can request source for closed binaries here, http://opensource.samsung.com/reception/receptionSub.do?method=inquiryView, most likely they wont answer
Click to expand...
Click to collapse
I can't say what the challenges here will be, since I couldn't manage to even flash it yet - Second build is compiling since hours now. For now it's using all the proprietrary stuff we managed to grab and some additional stuff from the 5433 CM. But without booting it's hard to tell what won't work and might present a challenge ^^ From what I saw it'll be tough to just get the modem running. The hard part is to write the drivers yourself
mythos234 said:
I can't say what the challenges here will be, since I couldn't manage to even flash it yet - Second build is compiling since hours now. For now it's using all the proprietrary stuff we managed to grab and some additional stuff from the 5433 CM. But without booting it's hard to tell what won't work and might present a challenge ^^ From what I saw it'll be tough to just get the modem running. The hard part is to write the drivers yourself
Click to expand...
Click to collapse
It's interesting that you can use drivers from 5433, which is a 32bit platform. Most drivers are not compatible when you switch from 32bit to 64bit if I am right?
Sent from my SM-G920F using Tapatalk
lch920619x said:
It's interesting that you can use drivers from 5433, which is a 32bit platform. Most drivers are not compatible when you switch from 32bit to 64bit if I am right?
Sent from my SM-G920F using Tapatalk
Click to expand...
Click to collapse
As a base to know how to do it, obviously we can't just use drivers for a different chipset
Updated the /system size in the BoardConfig and at least it flashes. But it doesn't want to boot for some reason yet.
mythos234 said:
Updated the /system size in the BoardConfig and at least it flashes. But it doesn't want to boot for some reason yet.
Click to expand...
Click to collapse
If you have the 5.1.1 boot loader and are using 5.0.2 as a base. Sboot will not boot it. As a fyi. It checks Linux versions.
-Mr. X- said:
If you have the 5.1.1 boot loader and are using 5.0.2 as a base. Sboot will not boot it. As a fyi. It checks Linux versions.
Click to expand...
Click to collapse
Both is 5.1.1 and Sboot seems to clear the boot as well, everything seems to go fine, it just doesn't boot. :/ Trying with building the kernel during the build itself instead of using a prebuilt one and see how that goes
mythos234 said:
Both is 5.1.1 and Sboot seems to clear the boot as well, everything seems to go fine, it just doesn't boot. :/ Trying with building the kernel during the build itself instead of using a prebuilt one and see how that goes
Click to expand...
Click to collapse
I would personally flash an Engineering boot loader while doing this, to ensure version checking is not the issue.
Hello, everyone.
I noticed, there are many custom roms, but not that many for the SM-T505. Is it because it's newly released, or are there other reasons?
Yes, this is a new device and many people are probably waiting for the Black Friday/Cyber Monday deals to grab one. I just grabbed one for $150 on Amazon, a steal compared to something like a Fire tablet IMO. This is a low-end tablet, so there won't be as much focus on it as say a flagship phone. But thankfully it's already been unlocked and rooted, so the next step will be to get TWRP on it, and then custom ROM development can start to pick up on it. Don't expect any updates before the end of the year for custom ROMs though, it will likely take time to have TWRP up and running on it, but I am hopeful that we will see good things on this tablet in 2021
Without kernel sources it won't happen. See https://opensource.samsung.com/uploadSearch?searchValue=sm-t505 and https://opensource.samsung.com/uploadSearch?searchValue=sm-t500.
You can request them on that page. I did it a few times but no response so far.
paziusss said:
Without kernel sources it won't happen. See https://opensource.samsung.com/uploadSearch?searchValue=sm-t505 and https://opensource.samsung.com/uploadSearch?searchValue=sm-t500.
You can request them on that page. I did it a few times but no response so far.
Click to expand...
Click to collapse
Interesting... is it just me or is there no button to start an inquiry?
EDIT: Found it... just posted an Inquiry.
Watching!! I just bought the T500.
jlang11 said:
Watching!! I just bought the T500.
Click to expand...
Click to collapse
Just got an answer from Samsung, but don't get to excited. It was just an automated answer, that they received my inquiry. So stay tuned...
https://opensource.samsung.com/uploadSearch?searchValue=t500 gives you a 514mb file with kernel and vencor files.
Maybe both 505 and 500 are similiar enough to get you started
Sources are available: https://opensource.samsung.com/uploadSearch?searchValue=sm-t500
They include a toolchain in kernel tree, broken KConfigs and a lot of junk. I will try to clean a bit a mess and update a lean kernel tree to github
paziusss said:
Sources are available: https://opensource.samsung.com/uploadSearch?searchValue=sm-t500
They include a toolchain in kernel tree, broken KConfigs and a lot of junk. I will try to clean a bit a mess and update a lean kernel tree to github
Click to expand...
Click to collapse
Will you also do a diff against the upstream version so we can see what they changed?
selemine said:
Will you also do a diff against the upstream version so we can see what they changed?
Click to expand...
Click to collapse
Sure, but I'm going to remove the toolchain from the kernel tree since the beginning. It takes About 1GB alone and I don't want to have it on git refs because it will still take a lot of space even if removed.
The rest of changes will be available on github.
paziusss said:
Sure, but I'm going to remove the toolchain from the kernel tree since the beginning. It takes About 1GB alone and I don't want to have it on git refs because it will still take a lot of space even if removed.
The rest of changes will be available on github.
Click to expand...
Click to collapse
It's been a long time, since i took up building custom roms and forgot about it for a while... if the kernel is cleansed from all the BS no one needs, that would be awesome.
There are a lot of small changes to comments and changes of 2 characters in a line. Wonder if they backported stuff there.
Kernel of the SM-T505 was just released...
If this is of any relevance, the download is 'just' 200MB... i wonder why.
The Platform Archive is mostly identical, just a few text files with notes and copyright were missing.
The Kernel Package as well, just small changes to netfilter and
a new defconfig file.
Defconfig for both devices also is more or less the same
gta4lwifi_eur_open_defconfig is missing one line compared to gta4l_eur_open_defconfig
CONFIG_SAMSUNG_FREECESS=y
Guess the difference comes from the toolchain mentioned above.
@paziusss
How far have you come?
Would be great if we had something clean to start a twrp and easier rooting
selemine said:
@paziusss
How far have you come?
Would be great if we had something clean to start a twrp and easier rooting
Click to expand...
Click to collapse
Sorry, I have a very bad internet connection (uplink it is ~50-100KiB/s)
I created the repo a month ago: https://github.com/pazos/android_kernel_samsung_gta4lwifi
,tried to push and failed. Never tried again until now, but it is still failing.
So, if somebody is nice enough to dump the contents of the SM-T500 kernel in a github repo, I can fork and submit the patches without having to upload the whole thing myself.
paziusss said:
Sorry, I have a very bad internet connection (uplink it is ~50-100KiB/s)
I created the repo a month ago: https://github.com/pazos/android_kernel_samsung_gta4lwifi
,tried to push and failed. Never tried again until now, but it is still failing.
So, if somebody is nice enough to dump the contents of the SM-T500 kernel in a github repo, I can fork and submit the patches without having to upload the whole thing myself.
Click to expand...
Click to collapse
Here you go
jayzarry84 said:
Here you go
Click to expand...
Click to collapse
Thank you! It helped.
I had to apply the patch manually, so everything is in a single commit, but should be easy for others to understand what each chunk of code does.
Here you go: https://github.com/pazos/android_kernel_samsung_gta4lwifi
paziusss said:
Thank you! It helped.
I had to apply the patch manually, so everything is in a single commit, but should be easy for others to understand what each chunk of code does.
Here you go: https://github.com/pazos/android_kernel_samsung_gta4lwifi
Click to expand...
Click to collapse
Just realized I didn't upload the Platform folder contents. It's uploading as we speak
jayzarry84 said:
Just realized I didn't upload the Platform folder contents. It's uploading as we speak
Click to expand...
Click to collapse
I really have to ask, can i use this to build a custom rom for the SM-T505 as well?
Does anyone know if there is any custom ROM out yet for Oneplus 10 pro?
batterylifesucks said:
Does anyone know if there is any custom ROM out yet for Oneplus 10 pro?
Click to expand...
Click to collapse
if they don't, buy another phone.
Kosta26 said:
if they don't, buy another phone.
Click to expand...
Click to collapse
HAHHAH, ok thanks
There's potentially a few in development, but it's moving along slowly.
The clear answer is "no" and I don't see any signs of that changing any time soon (if at all). Someone started working on it, but it looks like they lack the expertise to see it through, so don't count on any custom ROMs.
However, this seems to be an issue that is more widespread, not just OnePlus phones are affected. I would actually be interested if there are any new Android phones that have custom ROMs readily available. All the official Lineage OS devices seem to be older.
Too much thing is missing guys.released kernel source has missing scripts and header files.any custom rom group don't have linaro waipo built in sources.Just relax and give time to developers.
metrixx02 said:
Too much thing is missing guys.released kernel source has missing scripts and header files.any custom rom group don't have linaro waipo built in sources.Just relax and give time to developers.
Click to expand...
Click to collapse
hows that coming along?
eviling said:
hows that coming along?
Click to expand...
Click to collapse
Issue is that developers don't have a free and secure way of recovering their devices if it bricks. The MSM tool requires authentication with OnePlus which have deemed the tool as internal use only.
We're stuck until either someone cracks it or OnePlus makes the MSM tool public.