Related
Sources are here:
opensource.motorola.com/sf/frs/do/viewRelease/projects.droidx/frs.droidx_source.shado_x3_1_13_5_10
Hopefully I'll get some time to work on tun.ko for openvpn or vpnc.
But if someone beats me to it, please post it here.
Jeb
Downloading the source and pre-req's now. Will work on the tun.ko when I get back from dinner if no one else has it done.
Droid X source code! What!? Does this mean a bright future could be ahead for us?
XDA App = Pwnage
jebc4 said:
Sources are here:
opensource.motorola.com/sf/frs/do/viewRelease/projects.droidx/frs.droidx_source.shado_x3_1_13_5_10
Hopefully I'll get some time to work on tun.ko for openvpn or vpnc.
But if someone beats me to it, please post it here.
Jeb
Click to expand...
Click to collapse
What exactly is this?
drew630 said:
Downloading the source and pre-req's now. Will work on the tun.ko when I get back from dinner if no one else has it done.
Click to expand...
Click to collapse
Good luck to you and all for any work on this sweet phone. You rock!
Sent from my DROIDX using XDA App
Hi Drew,
Did you have any luck with tun.ko?
Thanks & all the best!
You can click in the bottom right of that that link and download all the files in one zip. SHADO_X3_1.13.5.10.zip is around 275MB.
I have unzipped that, then untarred all the individual archives.
According to the README, you need some files from source.android.com, but their link doesn't work, so that will take some more digging. (maybe I missed something...)
It appears to be the complete build process. I was just hoping to jump in and get a tun.ko modules compiled, but I still can't find the kernel config (I was just quickly looking around).
Anyway, bottom line is that I will have to get up to speed on the android build process, not just the cross compiled kernel process. This will take me some more time.
If anyone gets one before me, please post.
Thanks, Jeb
Anyone had any luck yet?
Sent from my DROIDX using XDA App
hmmm... I think that you should be able to compile the kernel with the default config options, but just enable the tun/tap module... I don't think that the module would really depend too heavily on any of the other config options?
I have compiled the module multiple times with multiple config files but none work. I get a exec failed error which is presumably because i compiled for the wrong architecture.
I have tried all the omap3 configs i found and the defconfig with no luck. I am away today but will look at it again tomorrow.
Sent from my DROIDX using XDA App
I'm no droid expert but it looks like according to the droid readme file you want ARM arch, but the compiler that youo should be using is arm-eabi-gcc (comes from the prebuilt tools from android) - in the Makefile set CROSS_COMPILE to /path/to/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- (or whatever the path to the file is on your build environment)
All the best,
Okay, after a bunch of hours I finally got it compiled
The 'exec format error' that you were probably seeing is not because it was compiled for the wrong architecture. I originally compiled the kernel modules with the default .config file that 'make menuconfig' generated.
When I tried to load it, I got the 'exec format error'. 'dmesg' showed:
<3>[46706.378570] tun: version magic '2.6.29 mod_unload modversions ARMv5 ' should be '2.6.29 preempt mod_unload ARMv7 '
So, that gave me a big hint - after a few hours of customizing I finally got the .config file to a version that will properly compile and load the openvpn module.
I'm attaching the .config file (config.zip) and tun.ko file (tun.ko.zip)
*NOTE* - I have not tested the kernel module yet, so I have no idea if it works. Even if it does work, the .config file is the default one that I manipulated so that the tun module would compile. You probably don't want to use the .config file as it may not match all of the hardware and configs of the droid x. If someone has the actual droid x .config file used by motorola then that would be very helpful.
*update* - the attacked files *do not work*. The working version is available at http://forum.xda-developers.com/showthread.php?p=7417520
Hmm... it looks like tun.ko does compile and install, but is not working properly
# lsmod
tun 11392 0 - Live 0xbf00c000
sec 4808 0 - Live 0xbf000000
# cat /dev/net/tun
/dev/net/tun: No such device
#
The response should be 'cat: /dev/net/tun: File descriptor in bad state'
If we only had the .config file from motorola this would be a lot easier.
mab2 said:
Hmm... it looks like tun.ko does compile and install, but is not working properly
# lsmod
tun 11392 0 - Live 0xbf00c000
sec 4808 0 - Live 0xbf000000
# cat /dev/net/tun
/dev/net/tun: No such device
#
The response should be 'cat: /dev/net/tun: File descriptor in bad state'
If we only had the .config file from motorola this would be a lot easier.
Click to expand...
Click to collapse
I'll post on Motodev board for the running .config (they should have left it in the running kernel at /prog/config.gz ...)
Anyway, thanks trying -- could you post any tips on getting a dev env setup?
I've been using linux for years, but this is my first android setup.
jebc4 said:
I'll post on Motodev board for the running .config (they should have left it in the running kernel at /prog/config.gz ...)
Anyway, thanks trying -- could you post any tips on getting a dev env setup?
I've been using linux for years, but this is my first android setup.
Click to expand...
Click to collapse
I'm in the same boat as you - android newbie, linux veteran.
I started out by getting the whole android environment - http://source.android.com/source/download.html - and ran 'repo init -u git://android.git.kernel.org/platform/manifest.git' - all of that was just so I could get the prebuilt directory with the arm-eabi- files that will be used below.
Then I just downloaded the entire project from opensource.motorola.com - extracted it all, went into the kernel directory and hacked away at the .config file from there.
To compile the kernel I ran:
CROSS_COMPILE=/home/MY_USERNAME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make -j 4 kernel
CROSS_COMPILE=/home/MY_USERNAME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make modules
I spent a few hours with it - playing around with environment variables and modifying some Makefiles so I may have left out a small thing or two
It looks like running 'make mapphone_defconfig' created a functioning .config file and I used that to generate tun.ko.
I've posted the files at http://forum.xda-developers.com/showthread.php?p=7417520
Attachments removed as per OP's request.
mab2 said:
I'm no droid expert but it looks like according to the droid readme file you want ARM arch, but the compiler that youo should be using is arm-eabi-gcc (comes from the prebuilt tools from android) - in the Makefile set CROSS_COMPILE to /path/to/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- (or whatever the path to the file is on your build environment)
All the best,
Click to expand...
Click to collapse
Thanks but I already got that, been compiling kernels for other Android devices for a while...
drew630 said:
Thanks but I already got that, been compiling kernels for other Android devices for a while...
Click to expand...
Click to collapse
didn't know that - no harm intended
All the best,
mab2 said:
Okay, after a bunch of hours I finally got it compiled
The 'exec format error' that you were probably seeing is not because it was compiled for the wrong architecture. I originally compiled the kernel modules with the default .config file that 'make menuconfig' generated.
When I tried to load it, I got the 'exec format error'. 'dmesg' showed:
<3>[46706.378570] tun: version magic '2.6.29 mod_unload modversions ARMv5 ' should be '2.6.29 preempt mod_unload ARMv7 '
So, that gave me a big hint - after a few hours of customizing I finally got the .config file to a version that will properly compile and load the openvpn module.
I'm attaching the .config file (config.zip) and tun.ko file (tun.ko.zip)
*NOTE* - I have not tested the kernel module yet, so I have no idea if it works. Even if it does work, the .config file is the default one that I manipulated so that the tun module would compile. You probably don't want to use the .config file as it may not match all of the hardware and configs of the droid x. If someone has the actual droid x .config file used by motorola then that would be very helpful.
*update* - the attacked files *do not work*. The working version is available at http://forum.xda-developers.com/showthread.php?p=7417520
Click to expand...
Click to collapse
i'm having a similar issue, how did you fix this ARMvX Version problem when compiling a module? Thanks in advance!
Hello, guys!
I guess most of you know about this "magic patch" that significantly boosts Linux speed. It's going to be merged in the 2.6.38 branch and it's shipping with Ubuntu Natty too. But this kernel patch can be applied to a previous kernel as well, just rebuilding it with this 224 magical lines of code.
What I wanted to know is if it's possibile to rebuild our kernels with this patch, if it is already, or if it's possibile but won't have significant boosts on Android devices.
You may read more about this on Phoronix. On the 2nd page there are video demos for lazy ones!
This has been discussed here twice &found not to help because we dont use harddisk.
Sent from my GT-I9000 using XDA App
was it "proven" or "theorized" ?
You can look it up here in dev. Search
Sent from my GT-I9000 using XDA App
ragin said:
This has been discussed here twice &found not to help because we dont use harddisk.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Thank you, but can you please link the thread with this discussion? I can't seem to find it. Also, this patch regards CPU, not hard disks.
this patch will be officially introduced in the 2.6.38 kernel..
also, this kernel will have about 50% more speed increase, due to the 200 lines patch and another issue resolved after it .. in general the upcoming kernel will be blazingly fast !!
there is a script that tries to do the same as the patch for earlier kernels. which I use on my Ubuntu laptop, and yes major performance increase !!
I tried to apply it to my previous phone (HTC Hero), but didn't work. I also asked Cyanogen on his twitter, but didn't care to give me an answer..
finally I gave up, and decided to wait for the next Android version that will have the 2.6.38 in the future..
MaXo64 said:
this patch will be officially introduced in the 2.6.38 kernel..
also, this kernel will have about 50% more speed increase, due to the 200 lines patch and another issue resolved after it .. in general the upcoming kernel will be blazingly fast !!
there is a script that tries to do the same as the patch for earlier kernels. which I use on my Ubuntu laptop, and yes major performance increase !!
I tried to apply it to my previous phone (HTC Hero), but didn't work. I also asked Cyanogen on his twitter, but didn't care to give me an answer..
finally I gave up, and decided to wait for the next Android version that will have the 2.6.38 in the future..
Click to expand...
Click to collapse
I'm using that script too on Maverick! I don't think there should be a significant increase in responsiveness if you apply it on high-end systems, but our SGS might benefit from it (as my old dual core system).
You say it didn't work on your Hero, but were there any errors in dmesg or you didn't find any significant change in speed?
thunderteaser said:
I'm using that script too on Maverick! I don't think there should be a significant increase in responsiveness if you apply it on high-end systems, but our SGS might benefit from it (as my old dual core system).
You say it didn't work on your Hero, but were there any errors in dmesg or you didn't find any significant change in speed?
Click to expand...
Click to collapse
dmesg should no difference. the script just showed a lot of errors.
I tried the "non-Ubuntu" version as described in Webupd8, but still similar errors.
I guess Android place the kernel differently from Linux desktops.
I might be mistaken, but SO kernel uses its. And haven't really noticed any difference with or without it.
MaXo64 said:
this patch will be officially introduced in the 2.6.38 kernel..
also, this kernel will have about 50% more speed increase, due to the 200 lines patch and another issue resolved after it .. in general the upcoming kernel will be blazingly fast !!
there is a script that tries to do the same as the patch for earlier kernels. which I use on my Ubuntu laptop, and yes major performance increase !!
I tried to apply it to my previous phone (HTC Hero), but didn't work. I also asked Cyanogen on his twitter, but didn't care to give me an answer..
finally I gave up, and decided to wait for the next Android version that will have the 2.6.38 in the future..
Click to expand...
Click to collapse
please don't spread incorrect facts:
* the "automated per tty task groups" (or autogroup) patch - by using cgroups (in CFS - the cpu scheduler) and thus isolating several taks from each other, giving them dedicated slices of cpu power - allows the system to be more responsive under load if there is a kind of cpu hog (task producing much load)
* the speed increase is due to Nick Piggin's VFS changes and Andrea Arcangeli & Mel Gorman's Transparent Hugepages (THP) support (and of course lots of other changes)
dupel said:
I might be mistaken, but SO kernel uses its. And haven't really noticed any difference with or without it.
Click to expand...
Click to collapse
that's correct: - "sched patch : automated per tty task groups (system more smooth and responsive) (v3(since 4_3) and v4(since 4_4))"
so you tried SO kernel with the patch applied and once reverted ?
but - yeah, I got you: I'm myself running a heavy patched 2.6.37 kernel with transparent hugepages, CFS autogroup, etc. enabled - and it certainly can play off its advantage most noticably during heavy system load
zacharias.maladroit said:
that's correct: - "sched patch : automated per tty task groups (system more smooth and responsive) (v3(since 4_3) and v4(since 4_4))"
so you tried SO kernel with the patch applied and once reverted ?
but - yeah, I got you: I'm myself running a heavy patched 2.6.37 kernel with transparent hugepages, CFS autogroup, etc. enabled - and it certainly can play off its advantage most noticably during heavy system load
Click to expand...
Click to collapse
So, please, correct my noobiness, isn't Android using TTY shells? If it's not than I understand why this patch can't be applied, but if it is, rebuilding a kernel with just 200 lines more is no big deal and we all could benefit from it. It's not very common for Android to be under heavy load but hey, it's going to be default in 2.6.38, so why not?
There is a better patch :
blog.internetnews.com/skerner/2010/11/forget-200-lines-red-hat-speed.html
But I don't know if android uses shells.
Protocamlann said:
There is a better patch :
blog.internetnews.com/skerner/2010/11/forget-200-lines-red-hat-speed.html
But I don't know if android uses shells.
Click to expand...
Click to collapse
Yes, that's exactly the script I was talking about a few posts ago. On my system running 2.6.35, I did not rebuild the kernel with the "patch of wonders" but applied this script. But as you may have read, it acts in userspace which is slightly different in Android (as far as I know it's not using the same environment variables and I don't know about any ~/.bashrc equivalents, but again correct me if I'm wrong), that's why a kernel-oriented patch would be more suitable.
* well, actually newer revisions of that patch don't make use of ttys but of the task session
so basically it seems to create separate groups for each task (or program for simplicity's sake)
(source)
I'm also not sure if current Android kernel revisions use CFS at all ("Android versus Linux?")
laststufo has the autogroup patch included in his SO Kernel but I don't know how to measure its effect ... (whether it makes any difference)
* other options to improve interactivity would be to use Lennart Poettering's bash-approach (the script), like MaXo64 already posted: link
since Android uses Bourne Shell (sh) instead of BASH the script might need to be rewritten
* if it's stable enough on the SGS - yet another option would be to use Con Kolivas BFS
thunderteaser said:
Yes, that's exactly the script I was talking about a few posts ago. On my system running 2.6.35, I did not rebuild the kernel with the "patch of wonders" but applied this script. But as you may have read, it acts in userspace which is slightly different in Android (as far as I know it's not using the same environment variables and I don't know about any ~/.bashrc equivalents, but again correct me if I'm wrong), that's why a kernel-oriented patch would be more suitable.
Click to expand...
Click to collapse
well, you could rewrite that script that it is run as a init-script (afaik in /system/init.d/ )
besides that:
there are stripped down (smaller) versions of bash 4.1* that are known to work on CM6 and the HTC Hero
so it should be a possibility to use that script on stock roms, too
if you can install busybox & root it, there also should be the possibility to install bash
zacharias.maladroit said:
* well, actually newer revisions of that patch don't make use of ttys but of the task session
so basically it seems to create separate groups for each task (or program for simplicity's sake)
(source)
I'm also not sure if current Android kernel revisions use CFS at all ("Android versus Linux?")
laststufo has the autogroup patch included in his SO Kernel but I don't know how to measure its effect ... (whether it makes any difference)
* other options to improve interactivity would be to use Lennart Poettering's bash-approach (the script), like MaXo64 already posted: link
since Android uses Bourne Shell (sh) instead of BASH the script might need to be rewritten
* if it's stable enough on the SGS - yet another option would be to use Con Kolivas BFS
Click to expand...
Click to collapse
It seems you're very well informed, so thanks for the infos you're posting!
I'm not a coder, though, so I hope a kernel developer could pick this up and go for BFS. You said laststufo already implemented this patch in his kernel, so that's really good! We should just find a way of testing its effectiveness.
zacharias.maladroit said:
well, you could rewrite that script that it is run as a init-script (afaik in /system/init.d/ )
besides that:
there are stripped down (smaller) versions of bash 4.1* that are known to work on CM6 and the HTC Hero
so it should be a possibility to use that script on stock roms, too
if you can install busybox & root it, there also should be the possibility to install bash
Click to expand...
Click to collapse
Yes, I've also seen bash shipping with some ROMs, so it's definitely possibile, though as I said before, I'm no coder...
thunderteaser said:
It seems you're very well informed, so thanks for the infos you're posting!
I'm not a coder, though, so I hope a kernel developer could pick this up and go for BFS. You said laststufo already implemented this patch in his kernel, so that's really good! We should just find a way of testing its effectiveness.
Click to expand...
Click to collapse
I'm a kernel-dev for linux-kernels so I got to know & learned to cherish them
just stumbled over a thread in the Epic 4G forum
for reference: [Q] [REQ] Galbraith Patch worked into kernals?
zacharias.maladroit said:
I'm a kernel-dev for linux-kernels so I got to know & learned to cherish them
Click to expand...
Click to collapse
You really are? That's great! So why don't you join laststufo to try maximizing the impact of his implemented "patch of wonders"? As I try to keep up with your techical chatting it seems I really can't do more than asking you to help!
zacharias.maladroit said:
just stumbled over a thread in the Epic 4G forum
for reference: [Q] [REQ] Galbraith Patch worked into kernals?
Click to expand...
Click to collapse
Uhm, so it seems BFS isn't stable on our hardware, pretty bad.
Hello I'm trying to compile cyanogenmod 7 with subskyper tass device to try to mantain this project update in line with the original philosophy: keep it 100% cyanogenmod without any tweaks
When I compile I face two errors that broke my compilation:
1-
device/samsung/tass/overlay/frameworks/base/core/res/res/values/config.xml:95: error: Resource at swap_volume_keys_orientation appears in overlay but not in the base package; use <add-resource> to add.
make: *** [out/target/common/obj/APPS/framework-res_intermediates/package-export.apk] Errore 1
make: *** Eliminazione del file "out/target/common/obj/APPS/framework-res_intermediates/package-export.apk"
make: *** Attesa per i processi non terminati....
This one I commented out the line reguarding swap_volume_keys_orientation in file
device/samsung/tass/overlay/frameworks/base/core/res/res/values/config.xml
but when i continue...
2-
prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/bin/ld: out/target/product/tass/obj/SHARED_LIBRARIES/libandroid_runtime_intermediates/AndroidRuntime.o: in function android::gRegJNI:AndroidRuntime.cpp(.data.rel.ro+0x148): error: undefined reference to 'register_android_hardware_fm_fmradio(_JNIEnv*)'
collect2: ld returned 1 exit status
make: *** [out/target/product/tass/obj/SHARED_LIBRARIES/libandroid_runtime_intermediates/LINKED/libandroid_runtime.so] Errore 1
make: *** Attesa per i processi non terminati..
Someone faced same problems?
Any ideas?
thanks a lot
Send PM With The Error To Subpsyke
t-r-e said:
Send PM With The Error To Subpsyke
Click to expand...
Click to collapse
done. I hope he will answer me cause I'm able to sync repos in a couple of hours, so it will be easy to mantain pure cyanogenmod 7 for our sgm.
mebitek said:
done. I hope he will answer me cause I'm able to sync repos in a couple of hours, so it will be easy to mantain pure cyanogenmod 7 for our sgm.
Click to expand...
Click to collapse
Best Luck Buddy Don't Give Up Early , We Look Forward To See Your Work As We Need To Keep Subpsyke Project Alive
prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/bin/ld:
Click to expand...
Click to collapse
Are you using 32-bit linux system ?
If yes, then I guess 64-bit is necessary to get things compiled properly without errors.
NB: Just sharing info.
coolsandie said:
Are you using 32-bit linux system ?
If yes, then I guess 64-bit is necessary to get things compiled properly without errors.
NB: Just sharing info.
Click to expand...
Click to collapse
Thanks for the reply but I think that this kind of error is a missing reference for the function register_android_hardware_fm_fmradio that is called from AndroidRuntime.cpp
32 or 64 bit it is no differnce in compile result. just speed....
However I've checked tass configuration and I see that fm radio is set to BCM2049 chip.
I checkd into frameworks/base/core/jni/ cm source tree directory and I found only fm hardware reference for :
bcm4325
si4708
si4709
wl1271
now I'm trying to compile again setting radio to bcm4325 just to see if something appens...
P.S. should be nice to have some tecnical ideas about the code error not only if the host system is well configured
P.P.S. changed values to bcm4325 let me not face errors no more. Now I'm compiling!!!!
I have checked some github projects and I see that a lot of device as sgm with bcm2049 fm chipset set it to bcm4325. I see that just subskype change that value to bcm2049. Should be nice to have some tip and tricks from him to understand well the point of the situation
Now I have a signed zip to flash into my sgm.
It contains subskype cm7.2 tass device configuration and latest cm 7.2 sources update at 31-01-2012.
to check changes:
http://review.cyanogenmod.com/#q,status:open,n,z
It works!!! finally compiled and booting successfully.
Now I'm trying to study the best way to mantain this kind of project (it's first time for me in android dev and I just have an android device by november).
first at all I was thinking to add V6 supercharge by default. what do you think?
mebitek said:
It works!!! finally compiled and booting successfully.
Now I'm trying to study the best way to mantain this kind of project (it's first time for me in android dev and I just have an android device by november).
first at all I was thinking to add V6 supercharge by default. what do you think?
Click to expand...
Click to collapse
Great news. Glückwunsch (don't know the english word at the moment).
Supercharger would be possibly good. Subpsyke said something to it but i don't rember clearly.
Keep up your work.
Sent from my GT-S5570 using xda premium
mebitek said:
It works!!! finally compiled and booting successfully.
Now I'm trying to study the best way to mantain this kind of project (it's first time for me in android dev and I just have an android device by november).
first at all I was thinking to add V6 supercharge by default. what do you think?
Click to expand...
Click to collapse
No not add anything. It s better. Completely clean
Inviato dal mio GT-S5570 usando Tapatalk
mebitek said:
Thanks for the reply but I think that this kind of error is a missing reference for the function register_android_hardware_fm_fmradio that is called from AndroidRuntime.cpp
32 or 64 bit it is no differnce in compile result. just speed....
However I've checked tass configuration and I see that fm radio is set to BCM2049 chip.
I checkd into frameworks/base/core/jni/ cm source tree directory and I found only fm hardware reference for :
bcm4325
si4708
si4709
wl1271
now I'm trying to compile again setting radio to bcm4325 just to see if something appens...
P.S. should be nice to have some tecnical ideas about the code error not only if the host system is well configured
P.P.S. changed values to bcm4325 let me not face errors no more. Now I'm compiling!!!!
I have checked some github projects and I see that a lot of device as sgm with bcm2049 fm chipset set it to bcm4325. I see that just subskype change that value to bcm2049. Should be nice to have some tip and tricks from him to understand well the point of the situation
Click to expand...
Click to collapse
For the radio, I used my patch to add support for the bcm2xxx devices with proper seeking. It's on gerrit here: http://review.cyanogenmod.com/#change,10358
mebitek said:
It works!!! finally compiled and booting successfully.
Now I'm trying to study the best way to mantain this kind of project (it's first time for me in android dev and I just have an android device by november).
first at all I was thinking to add V6 supercharge by default. what do you think?
Click to expand...
Click to collapse
no no...no v6.
Just vanilla cm7...and thanks for the initiative and ABT!
dont add scripts..but maybe something from cm gerrit if u wish..but then it'll not be vanilla.
I tried to boot Ubuntu on tf701t a lot of times. I made something, but i have a lot of problem. I need some help.
So, to boot Ubuntu necessary a few things:
1) Kernel. http://forum.xda-developers.com/showthread.php?t=2520862 I hope it's done.
2) Ramdisk with init. That is the most problematic part. I try to compile initrd same as to tf700 (http://forum.xda-developers.com/showthread.php?t=2026919) but nothing happend.
3) Rootfs. I think the tf700t's one suit. There are not much difference between tf700 and tf701
4) Blobs. I don't know is it necessary. I think, if kernel initialize screen (via framebuffer) and processor, blobs are not needed.
I think, that's all. I'll be glad for any ideas.
Trel725 said:
I tried to boot Ubuntu on tf701t a lot of times. I made something, but i have a lot of problem. I need some help.
So, to boot Ubuntu necessary a few things:
1) Kernel. http://forum.xda-developers.com/showthread.php?t=2520862 I hope it's done.
2) Ramdisk with init. That is the most problematic part. I try to compile initrd same as to tf700 (http://forum.xda-developers.com/showthread.php?t=2026919) but nothing happend.
3) Rootfs. I think the tf700t's one suit. There are not much difference between tf700 and tf701
4) Blobs. I don't know is it necessary. I think, if kernel initialize screen (via framebuffer) and processor, blobs are not needed.
I think, that's all. I'll be glad for any ideas.
Click to expand...
Click to collapse
Someone sent me this. https://developer.nvidia.com/linux-tegra-rel-17 . Says tegra 4 I dunno..Note it says dalmore developer board though.
Is buildroot useful for this? http://buildroot.uclibc.org/
Maybe set up a blog with what you've done step by step etc and someone will fill in the details.
I could not get a buildroot rootfs to boot myself. But I have no clue.
Thanks for your effort.
Have a look here for how they did it on the TF700.
http://forum.xda-developers.com/showthread.php?t=2387133
Thanks, that information useful.
What is "kexec.blob"? Is it kernel with blobs? Are blobs necessary for tf701?
I understood. That is boot.img, kernel+initrd. Initrd from rabits's project and I couldn't build init for tf701. This is main problem.
Trel725 said:
Thanks, that information useful.
What is "kexec.blob"? Is it kernel with blobs? Are blobs necessary for tf701?
I understood. That is boot.img, kernel+initrd. Initrd from rabits's project and I couldn't build init for tf701. This is main problem.
Click to expand...
Click to collapse
I see there in the Dalmore driver package from the first link i showed you there are various .dtb files(including one for macallan). device tree blobs no?
YayYouFixedIt said:
I see there in the Dalmore driver package from the first link i showed you there are various .dtb files(including one for macallan). device tree blobs no?
Click to expand...
Click to collapse
Yep. But that is compiled dtbs and I couldn't use it. Also there are dtbs (including for tf701) in kernel source (I posted link in first msg).
Today I got it! I had ran simple linux on this tablet. I use the fbcon as console output, and dock as keyboard. Keyboard works perfectly. Linux works not bad too. I was testing simple linux features like font changing, seeing images through fbi program, flashing arduino by avrdude, etc. Everything works. Also backlight is controllable. But unfortunately I couldn't run X nevertheless framebuffer output is working. I need help because I don't know how works the Android graphics output and how I can use it in pure linux.
https://source.android.com/devices/graphics/architecture.html
http://keyj.emphy.de/files/linuxgraphics_en.pdf
http://free-electrons.com/doc/training/android/android-slides.pdf
Some links that might offer some ideas to someone idk.
In this post, I would like to explain what kexec-hardboot patch is.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Unlike grouper's kexec-hardboot patch, this one only requires the host kernel to be patched. This is one of the improvements Tasssadar made, and I think it is pretty significant.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Kernel patch: https://gist.github.com/PatrikKT/50faf32e8931d51c0c9a,
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y
CONFIG_ATAGS_PROC=n # This one is turned on automatically, but it is not needed, so you can disable it.
All these options must be enabled.
Userspace kexec binary: https://github.com/Tasssadar/kexec-tools
I had to change some things in kexec userspace binary because of some kernel bugs, complete description is in that repository. You can get statically built binary at https://github.com/Tasssadar/multirom/blob/master/install_zip/prebuilt-installer/multirom/kexec
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --dtb
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - he used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped him out with that, thanks.
For hammerhead, he has improved the patch a bit - only the host needs to be patched now and he has added support for DTB.
This thread was used as a template Credits to @Tasssadar for his Nexus 5 patch
Awesome people helping with our G2's development. Thank YOU!
patrik.KT said:
I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition.
Click to expand...
Click to collapse
What benefit would there be to non-MultiROM users? (Just curious.)
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Any. Just any.
Actually I can't think of anything. It's only to bring the device to a full reboot to load a new kernel.
Odoslané z môjho HTC Desire 601
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Not for common user, in epic4g kexec used by kernel devs to test a new kernel build without replace the existing kernel.
They just load a temporary kernel to test. Then that kernel will gone after a reboot.
Hope to see new kernels that support MultiRom! Great work man!
Would this allow a multiboot with AOSP and Stock roms?
AbdulrahmanAmir said:
it doesnt work while i have stock and the secondary is aosp (dU-dirty.unicorn) when i boot the secondary it works sound only but no display just black screen plzz help
Click to expand...
Click to collapse
The patch is not necessary at the moment, because of the locked bootloader. It's just for devs to be prepared with their kernel when we can unlock the bootloader, so that multirom will work as it should.
Odoslané z môjho HTC Desire 601
Thanks for your great thread. But there is no instruction about how we can add that patch to kernel source. Could you write more details about implanting this patch?
No response??
mohamaadhosein said:
No response??
Click to expand...
Click to collapse
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Hey, some changes need to be made to the patch.
On line 353, change the number from 22 to 21. Also, it has some errors when modifying head.S, which I had to fix manually..
But guys, my kernel is building with the latest multirom. This **** is going to maybe work soon!
I'll keep you all posted.
Thank you man
Guys, I think I've done it. Kexec hardboot patched kernel for 5.1.1 and thus multirom compliant, which I am preparing to build with twrp. this is very exciting.
When will it be ready?
Are you kidding me? No ETAs. I literally haven't even announce it yet and somebody asks for an ETA.... It will be ready once I test everything to boot well on my device.
patrik.KT said:
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Click to expand...
Click to collapse
It says the patch is corrupted on the line 375