Related
Here's an idea, maybe something else can contribute or confirm it might works..
the Nook honeycomb image is actually running on top of a 2.6.29-omap kernel, which indicate that only some parts might require 2.6.36.3 functions.
I know that the main problem for me porting it, was the libc.so which uses kernel calls not found in our existing 2.6.32.9 kernel. so it crashed due to some cache functions not implemented.
- could the missing cache functions be implemented into our 2.6.32 kernel?
- can the Nook edition with a working libc.so (hopefully without FPU function compiled) be used to replace our xoom image libc.so which crashes?
So to make an early edition can we merge the ARMv5 libs (i assume it is from the emu) and use this with xoom edition and then keep our libnv* environment which is compatible without our nvrm_daemon (which no one can fix, although a proper kernel work for booting 2.6.36.3)
ideas.. but if its possible to put into "real life" is another story.
and how many can do experiments?
Artem wrote he is on the 2.6.36.3 kernel, but since we might have an option to go around, maybe also worth considering, if display driver lacks nvrm_daemon support.
re
I'm not a developer but I can do some beta tests for you if you want.
julio77 said:
I'm not a developer but I can do some beta tests for you if you want.
Click to expand...
Click to collapse
obviously...same here...;-)
I am able to write basic scripts, xml etc.. and have a brain...
Jp
i tries all this out now.. and got passed some link references between libs but the "libc.so" issue came coming back..
so it did not work..
im closing the idea here :-( not worth spending time on, so only the solution with updating kernel and rewriting drivers must be the way forward.
May be I should wait for ubuntu 11.04 or some other linux OS for folio 100
Toshiba &Google is not so kindness. Are they only want to earn more money, right?
Dexter_nlb said:
i tries all this out now.. and got passed some link references between libs but the "libc.so" issue came coming back..
so it did not work..
im closing the idea here :-( not worth spending time on, so only the solution with updating kernel and rewriting drivers must be the way forward.
Click to expand...
Click to collapse
Yup, I also think that waiting for updated kernel + drivers from the new Toshiba folio 200 is a more feasible approach...
xitrumch said:
Yup, I also think that waiting for updated kernel + drivers from the new Toshiba folio 200 is a more feasible approach...
Click to expand...
Click to collapse
If, and its a big if, the 200 has the same hardware.
ma1999 said:
If, and its a big if, the 200 has the same hardware.
Click to expand...
Click to collapse
correct,
we already know it has different resolution . and probably better display now, and no hardware buttons on the side, so no I2C used for this..
i think its very different, as it probably also got 802.11n wifi now, which we dont have and need different ar6000 driver.
i think its a long road downhill for folio100 if the 200 edition should be anything close as source for porting.
Dexter_nlb said:
correct,
we already know it has different resolution . and probably better display now, and no hardware buttons on the side, so no I2C used for this..
i think its very different, as it probably also got 802.11n wifi now, which we dont have and need different ar6000 driver.
i think its a long road downhill for folio100 if the 200 edition should be anything close as source for porting.
Click to expand...
Click to collapse
Please, I'm no expert in this, so bare with me for asking questions.
Honeycomb uses a different kernel than Froyo ok.
For Froyo we have the source for all (hardware) drivers ?
Can the "android" part of Honeycomb (from for example Xoom) be put on
a kernel with required hardware drivers or are there stuff in the "android"
stuff that is hardware dependant ?
Is it hard to port drivers between kernel versions ?
Just trying to understand the many tasks need to get Honeycomb on Folio.
/Martin
The problem in this case is there is no honeycomb kernel sources out there.
Sent from my GT-I9000 using XDA App
Cpasjuste said:
The problem in this case is there is no honeycomb kernel sources out there.
Click to expand...
Click to collapse
xoom kernel source is available, koush used it to make his clockworkmod work , and it works fine, and its also used for oc'ing.
but its pretty much the tegra2 source we can get from nvidia. but alot of porting to do.
So, What we are still missing is?
ibila said:
So, What we are still missing is?
Click to expand...
Click to collapse
all of it!
Lol, guess all we can do now is wait for some ice-cream or get us a native honeycomb tablet.
Sent from my HTC Desire using XDA App
Hey, Asus just released his kernel honeycomb version:
http://www.asus.com/product.aspx?P_ID=gHh4q7I8dvWJzhdV
Choose Download and then Android.
I have started porting the kernel:
https://github.com/DerArtem/android-tegra-2.6.36-honeycomb-folio-nvidia
great news
i dont know how to compile or port stuff but i can say that i love my folio and i love all the devs that are working hard to port honeycomb on our device! THANK YOU SO MUCH!!!
DerArtem said:
I have started porting the kernel:
https://github.com/DerArtem/android-tegra-2.6.36-honeycomb-folio-nvidia
Click to expand...
Click to collapse
really great news!!!
thank you!!!
Thanks a lot!
Thank you a lot !!!
I hope you do 3G Modem Support to !
nothing for linux hack webtop for Razr!?
I click this thread with such high hope... T_T
Just wait a couple of hrs......
I hope this means what I think it means...!!
!!!!!
YES.
Waiting for good news..
I am stinky with anticipation on this!
I've started to work on it. I should release a preliminary version tonight or tomorrow, it depends on my dear ****ty ADSL connection
Okay, I said "just wait a couple of hours" making you all think it would have been out today, but I was working on the overclock module so I've been a lil' bit late. I've posted it so that some other dev will examinate the situation and write the needed few lines of code for making it to work as expected.
Sounds very good Kholk, don't overrush... Your already working so much on custom tooling for the RAZR!!!
But you made me very curious!
b.o.n.s said:
Sounds very good Kholk, don't overrush... Your already working so much on custom tooling for the RAZR!!!
But you made me very curious!
Click to expand...
Click to collapse
Right? Both his o/c and his webtop app!
Wait, does that make me bi-curious??
Opening a thread for Webtop Mod, I wanna know what do you expect from it prior giving it to you, so I can set it as you all want.
is possible to have a dump of original webtop!?
some one have try the hack for Atrix/photon?
If you want a dump of the original webtop, download the Fastboot ROM in the ROMs thread.
The WebTopMODs for ATRIX/Photon shouldn't work as expected as they're meant to be used with Tegra2 (VFP), not with OMAP4. They're different.
Mine is meant to be used on OMAP4, its binaries are compiled with full OMAP4 support.
Chromium on Razr Webtop?
I've gone through your Netty enhancement (very impressive results, I might add!) and am thrilled with the results so far... BUT, upon installing Chromium using the apt-get functionality, I'm running into errors - something along the line of the application not properly reporting the timestamp back to the system. End result is that the application runs perfect for about a minute or two - then the system kills the app.
Have you had any success in getting Chromium running? That's by far my #1 want at the moment.
(And note - I'd post this in your development thread for the mod, but the system won't let me do so until I reach 10 posts... I think that's a feature.)
>>>> 22Jan2012: linboothkvc v1.0 source released in my linboothkvc thread. It works successfully on Omap3 and Omap4 based devices including NookTab. And with minimal changes/love can work with any rooted arm based linux device <<<<
>>>> 17Jan2012: Kernel module SUCCEEDS on NookTab to reboot into NIRVANA - NO NEED to BREAK the default SECURE BOOT CHAIN and NOTE THAT EVEN THIS CAN WORK ON ANY ROOTED DEVICE and not just NT, with minimal love so ENJOY <<<<
>>>> 16Jan2012: My kernel module based path (linboothkvc) to running custom kernels and roms is almost done, except for a __small part__ to get it running on NT now - IF ONLY PEOPLE HAD WAITED ...., we could have reaped the potential benefit in future, Why not !!!! why not ....WHY NOT !?!?. NOTE that it can allow one to run custom kernel/roms WITH OUT MODIFYING ANY CRITICAL PARTITIONS provided one sets it up properly/appropriately. Source for beta version available in my linboothkvc thread, for the interested developers/experimenters for now ... <<<<
>>>> I may not respond to the posts on this thread currently, because I am trying to get a alternate option called linboothkvc using kernel modules up and running (which will occupy my free time), which AVOIDS the NEED for this flaw in the first place for most of the people out there (i.e Custom ROMS with different kernels). However over the weekends, I will go thro all the posts on this thread <<<<
>>>> 14Jan2012: Initial pre-alpha version of kernel module path based source code uploaded to my linboothkvc thread for those still interested to experiment
http://forum.xda-developers.com/showthread.php?t=1427610
<<<<
Hi All,
If you have been following my posts over the last few days
NOTE: To people frustrated with UART requirement - I understand the restrictions of UART access, but a lot of ROMS can be done with 2ndihkvc or equivalent methods and with out needing a Custom kernel. If someone is talking about Custom/New kernel for Android 4.0 (ICS). Then do note my statement (in NOP BYPASS thread) on POWER of KERNEL MODULES in Linux, IT CAN BE USED TO ACHIEVE what you want to achieve, only that it requires bit more effort, which I or some one else has not put currently... thats all. AND THAT By holding off now, we can _potentially_(Risk is always there) reap the benifit with next years NEXT GEN Nook Tab+ or what ever they call it.
a) I have implemented 2ndihkvc, which follows the same fundamental concept as 2nd-init, but achieves it in a simpler way (Needed because some of the calls used in original 2nd-init doesn't work on NookTab, or have unnecessary dependencies (in this given context, otherwise they are good in them selves) which can be avoided with my simpler method)
b) I have provided the NOP Bypass method of running a modified Ramdisk and also 90% a modified kernel, provided UART access is there.
c) There is still the power of linux KERNEL MODULES to EXPLOIT. (Haven't had time on that yet).
If you ask me, this should cover all category of people. Be it people who want to run custom Roms, or people who want to experiment with Kernel and or other low level stuff for the fun of it.
There is a 4th method which will allow one to achieve (b) above with out requiring UART access or even uSD (potentially . If one reads between the lines from all my posts till date, the answer is hidden in there. Only that I haven't spelt it out directly or in the face. The reason is because It is a fundament flaw (rather there are potentially two at two different levels - one relatively simple and one relatively bit more involved - One I know for sure, another I have to dig bit more) in the way things are done currently in the secure boot chain on this device as well as potentially other devices with same or similar SOC (and or different SOC but with similar boot chain s/w components.
SHOULD WE BE WASTING i.e providing a solution which uses it, when there is already 2ndihkvc and NOP Bypass over UART and also the Linux KERNLE MODULE ROUTE to cater to most peoples needs.
Because if we do, then even the Device manufacturers and their partners will come to know about it and can easily fix it in their Newer/NextGen devices. While if we withhold it for now, we may be able to get access to it on their Next generation Devices with hopefully Arm A15 core or .... (NOTE: Depending on the boot sequence ROOT access may or may not be required for this).
The reason I am asking now is because, few people are asking my help on certain things and the reality is I know that the concept for which they want my inputs/guidance, can be applied at a more fundamental level here (or even at the same level), but that I have not ventured into it because of my delimma above.
NOTE: People who wanted my inputs/guidance wrt uSD, you all know who you are, I know the flaw to achieve what you want to achieve, but it is more powerful than what you all are currently thinking of doing/ ristricting yourselves to (You all have one input/... in there wrt devices . Unless let me think thro further and see if something can be done differently, with out exposing the flaw I have in mind to help you achieve what you want, otherwise i.e if there is nothing else I can come up with, and in turn if you people experiment further and are able to come up with the solution on your own, I would suggest that hold off on it for few days, think thro all the implications keeping what I have mentioned in this thread, and then take a call one way or the other.
Please provide your thoughts on this after thinking thro the options already available on NookTab (root access, kernel modules, UART UBoot access and inturn 2ndihkvc and NOP Bypass or equivalents)
Based on all the feedbacks as well as bit more thinking from my side, I will take a call on this.
Forum moderators I know this is the development portion of the forum, but I wanted feedback from Developers also that is the reason why I have posted here. But beyond that I leave it to you, whether you want this to continue here or move it out.
UART access is not sufficient, as it is required during every reboot of the device if we wanted to have a custom kernel and ROM. This is simply an unacceptable state of affairs. (Say, my tablet turns off while on holiday, or at the airport. What then am I to do? Let is sit and wait off until I can get back home to my UART equipment in order to reboot?
The idea that the UART work around is sufficient is a nice one, however it is wrong.
---
Oh also, it's just a matter of time before they patch the u-boot in the Nook Tablet anyways... so it's not like this UART method is going to stick around forever anyways.
cfoesch said:
UART access is not sufficient, as it is required during every reboot of the device if we wanted to have a custom kernel and ROM. This is simply an unacceptable state of affairs. (Say, my tablet turns off while on holiday, or at the airport. What then am I to do? Let is sit and wait off until I can get back home to my UART equipment in order to reboot?
The idea that the UART work around is sufficient is a nice one, however it is wrong.
---
Oh also, it's just a matter of time before they patch the u-boot in the Nook Tablet anyways... so it's not like this UART method is going to stick around forever anyways.
Click to expand...
Click to collapse
Hi
I understand the restrictions of UART access, but a lot of ROMS can be done with 2ndihkvc or equivalent methods and with out needing a Custom kernel. If someone is talking about Custom/New kernel for Android 4.0 (ICS). Then note my statement (in NOP BYPASS thread) on POWER of KERNEL MODULES in Linux, IT CAN BE USED TO ACHIEVE what you want to achieve, only that it requires bit more effort, which I or some one else has not put currently... thats all.
By holding off now, we can potentially reap the benifit with next years Nook Tab+ or what ever they call it.
Im not a Developer but I've got a few questions. NOP requires to open up your device, so I think probably 95% won't open their device for ICS and I think since the device had a dual core CPU we should get ICS roms. Now my actual question how does your 2init work or how do you install it on our device? But great work so far keep on.
Sent from my SGH-T989
Just out the flaw now. Someone else might reveal it and you won't get the credit.
Don't you want a Wikipedia entry saying that you found this flaw? lol.
PM me about the flaw, I'll see if we should have it outed yet or not (sorry guys, but if it's a decent exploitable flaw and we have other methods, I'm pretty sure I'm with hkvc on it.)
xdahgary said:
Just out the flaw now. Someone else might reveal it and you won't get the credit.
Don't you want a Wikipedia entry saying that you found this flaw? lol.
Click to expand...
Click to collapse
Not worried for 2 reasons,
a) It doesn't bother if my name comes or not. I am exploring just for the fun of exploring.
AND MORE IMPORTANTLY,
b) Actually I have already revealed the flaw in my NOP Bypass thread, indirectly, if only, one reads carefully all my lines as well as between them. Only that I have just replaced one or two of the steps with a different steps thats all for now.
If someone else find the same flaw, he will realise the same, if he reads my posts once again with his new knowledge.
What an awesome idea, we can have a root for the Nook Tablet+ or whatever else in a years time!
...
So, um... what do I do now with my Nook Tablet? It's a piece of garbage now, I guess, so, I'll just return it since it's still within the Holiday return period? I suppose I'll just have to wait for the Nook Tablet+ to have a custom ROM running on my Nook... ("But you can UART hack it!" ... *sigh* I've already explain that that is not sufficient. The UART hack is a stop gap, and should only be stopped at if that is the absolute only option available.)
And I mean no disrespect to xIndirect, but why should he be the lone gatekeeper of what exploits and hacks are out there for the Nook Tablet? I would rather see this exploit before making a decision as well, but I don't think it fair that someone should have privileged access to the exploit. Either release it to everyone or DON'T SAY ANYTHING IN THE FIRST PLACE.
cfoesch, I have no plans to be using the exploit shown for myself. I am not going to be the "lone gatekeeper" I just want to know what it is before I give my full opinion. Chill.
Motorola Defy was locked bootloader too, may be to try and run port Defy bootmenu for Nook Tablet?
source: github.com/CyanogenDefy/android_external_bootmenu
Indirect said:
cfoesch, I have no plans to be using the exploit shown for myself. I am not going to be the "lone gatekeeper" I just want to know what it is before I give my full opinion. Chill.
Click to expand...
Click to collapse
If you buy a plot of land and the seller has accidentally left seeds there and isn't coming back for them, do you grow a garden on your current plot of land, or do you decide not to plant them and hope that the next time you buy a plot of land they might forget some seeds again?
I would rather tend the garden I own than hope for a better plot of land with seeds I may never have.
Cheers!
-M
XDA member since 2007
Sorry if my post is offtopic, I just want to help with development.
My SE Xperia x10 came worh a locked bootloader and devs figured out how to make a bootable recovery (xrecovery) based on CWM, may be with an adaptation for the NT we can get the world of custom roms, even with locked bootloader this crappy phone got cuatom kernels by bypassing the bootloader, hope this give little ligth to you guys the real Developers.
If this post is garbage mods please delate it.
Sent from my BNTV250 using xda premium
Hello, I beleive if there is a software way to get ICS + maybe overclocking it should be tried first as this IS what most people are waiting for. That's the big dream they got. If someone knows how to implement that, then please by all means do so ..
P.S. you said so much where to look for the flaw in your posts that if I was a programmer from B&N I'd know where to look like everybody else. Assuming they are not complete morons they can already figure it out too. Can they plug the hole or not? Is it oversight or permanent design flaw ? We'll see. Best way to keep a secret is to " keep it secret " , ie not talk about it at all. Especially if soft mod ICS, hw acceleration and overclocking already available.
Sent from my LG-P500 using Much Love
First of all hkvc +1 for your efforts.
I voted yes, the NT developers can read between the lines in your posts as well.
Whats life without risks once in a while
Hi All,
I understand very well that even BN devs will be looking and potentially can figure out and fix it. That is the risk, but at one level I don't mind taking the risk and see if it works out to my/our advantage (i.e the bug being still open in a new device (From BN or any other Vendor)) or disadvantage(the bug is either way fixed).
Also the flaw can affect ANY DEVICE (Not just NOOK TAB) using similar secure boot chain not just NookTab, that is also one reason why I am bit wary of releasing the info or a implementation which uses it just like that.
I will share my finding with few people on the forum/outside in few days time so that even If I loose interest in this, there will be few people with the required knowledge (i.e if they haven't already figured out on their own by then (and released something or not ...)).
Also I haven't taken a final call on this yet. I am in a delima, so getting all your opinions also before I decide.
Time permitting I will also attack/explore the KERNEL MODULE PATH in a few days time, so that people don't have to depend on this flaw in the first place, but use the wonderful world of Linux Kernel Modules to achieve what they want.
LexS007 said:
Motorola Defy was locked bootloader too, may be to try and run port Defy bootmenu for Nook Tablet?
source: github.com/CyanogenDefy/android_external_bootmenu
Click to expand...
Click to collapse
Hi,
With my modified 2nd-init (2ndihkvc), you can run bootmenu or any other user space mechanisms already on NookTab
absolutely YES, we r all xdaers, right hehehe. Thanks all devs especially hkvc for the efforts
hkvc said:
Hi,
With my modified 2nd-init (2ndihkvc), you can run bootmenu or any other user space mechanisms already on NookTab
Click to expand...
Click to collapse
It's very good. Thanks!!!
First off, not a dev but read religiously.
2nd, release it if the people who would take advantage of it agree. The rest of us say "great,woohoo!" But I must admit, I can't take advantage of it. But I certainly don't want to make a hardware uart to boot custom roms.
That being said, if its more complicated to install with a different method, that's fine. As long as it doesn't include a soldering iron.
But if it were easier to make a custom rom, or open up more capabilities of the kernal or whathaveyou, well that would attract more developers to make roms, etc. and so on and so forth.
Btw. Yes, exploit may exist if outedin a later tablet, but you found this one.... I have faith the next flaw will be found in the next one too.
A bird in the hand is worth two in the bush.
Posted from my B&N Nook Tablet... rooted of course!
jotekman said:
A bird in the hand is worth two in the bush.
Click to expand...
Click to collapse
I would say this summarizes everything I want to say on the topic.
Hi there,
I'm a programmer and formerly worked for one of the major Android handset developers as a platform engineer. When we developed the devices, we had separate build configurations and tools for kernel and platform, and built them separately... I rarely had any issue in building a new kernel for a platform, or building a new platform and using it with an old kernel.
That being said, what is the present difficulty that is being run into with using what should be a fully-functional GB kernel (incl. graphics drivers) with the ICS or JB platform? I am genuinely curious on this mark - if you are using the original kernel and drivers, I would imagine you should have full functionality (as they expose at least OpenGL ES in a consistent manner).
If you reply, please don't water down your comments - I'm a kernel developer myself (though not for Linux), so I appreciate and look forward to technical jargon.
"GPU Acceleration" (Hardware Acceleration) I'd imagine would be handled via the OpenGL interface libraries that come with the driver... that's what I'm asking: why can't the Gingerbread ones be used? What specifically prevents it from working? What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
As I said, I used to do this professionally, and am a professional programmer, so I'm looking for specifics.
AmeiseMike said:
What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
Click to expand...
Click to collapse
Nothing. And that's exactly what the devs have been doing so far. The result is well known to everyone - an almost perfect system that's lacking true HW acceleration in certain areas. Modifying and adapting can only get you so far.
I'm no expert so I won't pretend to be one, but as far as I know it has something to do with the newer nvidia drivers (that support proper HWA) which are proprietary binary blobs and have only been released for kernels newer than what we have. So we have a working kernel with semi-working adapted drivers, or true proper drivers with no kernel to use them on. And that's exactly where all the current porting efforts are directed - making a working kernel for the Atrix that's recent enough to make video drivers useful. In fact, since you say you have quite some experience with kernel development, you might consider joining the team, I'm sure they can always use any help they can get.
You could theoretically use existing drivers from kernel space, but they are not compatible with ICS.
Another option would be to ask nVidia nicely for drivers then build a new kernel, not forgetting two dozen other neccessary drivers, too.
OR, you could use a newer kernel with drivers that are compatible with ICS and which includes better handling of resources.
Option one will be adequate for Honeycomb. Hardware acceleration was first introduced in API level 11 (Honeycomb) and the XOOM was horribly buggy and slow with the old kernel.
Option two will never happen for various (obvious) reasons. For hardware acceleration to work properly you need nVidia drivers which require a 3.0 kernel.
Option 3 is something that a few in the Atrix community are working on.
My question, though, is why are said drivers incompatible with ICS/JB? What has changed that has rendered the platform incompatible with the previous drivers? If 3d Hardware Acceleration worked in GB, why can it not be used within ICS/JB (which should only care about GL ES, which hasn't changed)? If a feature of some sort has been added in ICS/JB that has caused the incompatibility, why not disable it? Features that had worked shouldn't be rendered inoperable unless a binary-level incompatibility exists, and I can't fathom why one would when you have platform source (via AOSP).
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
integraletotale said:
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
Click to expand...
Click to collapse
OpenGL ES 1 and 2 fully function on Gingerbread (and are accelerated, that is, not rasterized by something like Mesa). These are components of the GPU driver, more specifically the GLES interface libraries. I don't see why those are rendered incompatible.
That stretches beyond my knowledge of what is made available by the driver, so, I really don't know. I'd greatly appreciate you taking a minute to review progress being made on github. Links in the development section of this forum in the thread mentioned earlier.
To put it into a different context (approaching it a different way), have any other OSen such as Ubuntu been ported to the Atrix, using the kernel, and having 3d HWA?
Not sure if it's useful information or..... but from what I've read even the GB kernel used by Motorola for the Atrix was just a cobbled up rush job based on a Froyo kernel..
So the ROM developers here have a steeper hill to climb than you thought.... Making ICS/JB ROM's operational from basically a patched Froyo kernel
I once got Honeycomb working on a Froyo device (don't ask), including HWA... without any kernel changes.
My suspicion is that maybe people are unwilling to hack up the platform to work with the drivers as they are? So long as there are drivers that have supported HWA, there's no reason that they shouldn't be able to continue to do so, you have to alter the platform so that it can. ICS/JB internally will look a bit more like GB afterwards, but many of ICS/JB's improvements were in the realm of expanding what used HWA (which already existed) and improvements in their multithreading code, neither of which should require anything that's not already there.
EDIT: I'd point out that I'm speaking hypothetically. I don't know what the actual issue is, hence why I'm probing for specifics .
Are there any developers around who might be able to shed light upon this for me?
Hi,
What eaxctly do you need this information for? Are you working on porting Ubuntu Touch on the Atrix?
AmeiseMike said:
Are there any developers around who might be able to shed light upon this for me?
Click to expand...
Click to collapse
here's a link http://forum.xda-developers.com/showthread.php?t=2016837 , maybe you'll get your answer there
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
AmeiseMike said:
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
Click to expand...
Click to collapse
You asked are there any developers around who might 'shed some light' on your question. There's only a handful of developers left and the link takes you to some of the most current ones. You can also check out the others in the Development section.
What exactly do you need this information for?
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
AmeiseMike said:
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
Click to expand...
Click to collapse
Instead of asking, why not try and do it and see for yourself.:good:
Because I'm not interested in potentially bricking / rendering unusable my phone if there's a known good reason why it can't be done.
just a odd idea I thought I would share
I wonder if its possible to patch a kernel on load using safestrap
I am wondering if maby we can hex-patch the DVFS table at execute to at least gain some overclocking
I read the kexec thread but the consensus there is that development is stalled waiting for a breakthrough
thoughts :fingers-crossed:
Legitsu said:
just a odd idea I thought I would share
I wonder if its possible to patch a kernel on load using safestrap
I am wondering if maby we can hex-patch the DVFS table at execute to at least gain some overclocking
I read the kexec thread but the consensus there is that development is stalled waiting for a breakthrough
thoughts :fingers-crossed:
Click to expand...
Click to collapse
You can overclock via module sure, hex patch prob not needed.
Surge1223 said:
You can overclock via module sure, hex patch prob not needed.
Click to expand...
Click to collapse
hrmmm.... you talking about patching the dvfs kernel module or writing a custom module ...
if so I am surprised nobody has done that yet ..
is hex-patching from safestrap at all feasible ... it would grant you the 'keys' to all manner of "doors"
I used to fiddle with it on my cheap mk808 tv stick before we had kernel sources
I am surprised nobody has used kmodule's as a "attack vector" people seem to be chipping away and the Mountain that is kexec instead of just focusing on patching the issues we have with the stock kernel .. . a few years ago somebody was doing hex patches to implement kernel changes on the first generation of rockchip powered "tv sticks" the same logic should apply here
then again maby I have just been out of the game for way to long ....
*continues pondering*
Legitsu said:
hrmmm.... you talking about patching the dvfs kernel module or writing a custom module ...
if so I am surprised nobody has done that yet ..
is hex-patching from safestrap at all feasible ... it would grant you the 'keys' to all manner of door if it was
I used to fiddle with it on my cheap mk808 tv stick before we had kernel sources
I am surprised nobody has used kmodule's as a "attack vector" people seem to be chipping away and the Mountain that is kexec instead of just focusing on patching the issues we have with the stock kernel .. . a few years ago somebody was doing hex patches to implement kernel changes on the first generation of rockchip powered "tv sticks" the same logic should apply here
Click to expand...
Click to collapse
I have dabbled with this, using a custom module based on the 8660 overclock module I found source for somewhere. The reason kexec is so much more desired then fixing the current kernel is because patching the current kernel might give us more io schedulers, overclock, custom governors etc, but at the end of the day all that crap isn't worth much on the poor excuse for android ui known as touchwiz.
Idk about you but I can tell you I for sure would not want to post a thread on overclocking or modifying cpu via modules in this day and age of 'the entitled xda user'. Maybe that's why you don't see any threads.
You bring up a good point about how people don't understand the various uses kernel modules can provide including but not limited to being attack vectors (though to some degree this is being done with kexec).
Surge1223 said:
I have dabbled with this, using a custom module based on the 8660 overclock module I found source for somewhere. The reason kexec is so much more desired then fixing the current kernel is because patching the current kernel might give us more io schedulers, overclock, custom governors etc, but at the end of the day all that crap isn't worth much on the poor excuse for android ui known as touchwiz.
Idk about you but I can tell you I for sure would not want to post a thread on overclocking or modifying cpu via modules in this day and age of 'the entitled xda user'. Maybe that's why you don't see any threads.
You bring up a good point about how people don't understand the various uses kernel modules can provide including but not limited to being attack vectors (though to some degree this is being done with kexec).
Click to expand...
Click to collapse
ill be the first one to admit I haven't keept up on this stuff simply because the effort started outweighing the gain
it just seems to me that people are chasing clouds ... with kexec the possibility of getting it working is basically nill due to lack of debugging information so why not attack something you can debug such as a kernel module hell in theory it should be possible to add io schedulers and governors via a module hell with a properly 'crafted' module we may even get kexec(kgraft?) as a result if you could create a exploit you could use to the proper effect ..
I agree that touchwizz is utter poo and should be stabbed with white hot knives and buried under 12ft of cement but the phrase "if life gives you lemons ... make lemonade" rings to mind ...
I am sure somebody will give me the usual speech about "if you are so smart do it your self" but sometimes people just need to step back and look at it another way .. + I am fighting insomnia and am on my third shot of jack ...
wow did I really write all that jesus ... no more jack for me at 12 am...
Legitsu said:
wow did I really write all that jesus ... no more jack for me at 12 am...
Click to expand...
Click to collapse
Lol. At least your question is a good topic of debate. Most questions and posts in our forum are boring to me but this isn't, so there's that I guess.
Surge1223 said:
Lol. At least your question is a good topic of debate. Most questions and posts in our forum are boring to me but this isn't, so there's that I guess.
Click to expand...
Click to collapse
realistically you probably could't alter to much but adding overclocking a variety of minor tweaks could be done in hex
on a personal note I would be content with figuring out how to get some overclocking/undervolting done
Legitsu said:
realistically you probably could't alter to much but adding overclocking a variety of minor tweaks could be done in hex
on a personal note I would be content with figuring out how to get some overclocking/undervolting done
Click to expand...
Click to collapse
When you reply to me, you realize you are actually continuing your thoughts and not actually replying to me right?
Surge1223 said:
When you reply to me, you realize you are actually continuing your thoughts and not actually replying to me right?
Click to expand...
Click to collapse
Lol I am just rambling feel free to ignore me lol
board software here is a bit odd
*deleted tired*