Hey guys,
while searching around the web I saw this very interesting and hot topic on CAF.
https://www.codeaurora.org/2010/03/02/little-kernel-based-android-bootloader/
Sources:
https://github.com/travisg/lk/commits/master
fixes for 7x30:
https://android.googlesource.com/kernel/lk/+/qcom-dima-7x30-fixes/AndroidBoot.mk
Simlar projects:
http://forum.xda-developers.com/showthread.php?t=2147997
http://rtammekivi.tumblr.com/post/18995217696/working-little-kernel
http://www.pocketpc.ch/htc-hd2-andr...smiths-little-kernel-loader-installation.html
The thing is, I'm not that good to compile it for our device.
I hope someone more advanced than me is able to compile that without hardbricking his phone...
Regards
trapjul
AW: [DEV] MSM7x30 Open Source Bootloader '(L)ittle (K)ernel'
This looks very interesting. But i dont know why you think this will get us dualboot?
But i would really love to.have fastboot. Its very handy and easy to use.
Sent from my GT-I9001 using xda app-developers app
XeLLaR* said:
This looks very interesting. But i dont know why you think this will get us dualboot?
But i would really love to.have fastboot. Its very handy and easy to use.
Sent from my GT-I9001 using xda app-developers app
Click to expand...
Click to collapse
Because the current problem at Dual Boot is the switch between the kernels. With an Open Source Bootloader we could switch between them mich more easy.
trapjul said:
Because the current problem at Dual Boot is the switch between the kernels. With an Open Source Bootloader we could switch between them mich more easy.
Click to expand...
Click to collapse
Dual boot needs some where for storing second rom 's data / cache / & most important thing is BattertState which can cause lots of problem in dual ROM mod !
Another thing :: we have secondary boot loader which made our device harder to brick so do not worry about ! Your device just breaks when you wipe both boots !
Dead thread ? I think LK is a good project !?!
I think this is a good start!
But I'm sorry, I have too less knowledge of Linux/Android :/
I can't help you...
Maybe I can test it
(of course when there is no risk that I break my phone )
I think it's difficult to make it for our device full working, that's the problem.
Harrocan said:
I think it's difficult to make it for our device full working, that's the problem.
Click to expand...
Click to collapse
No !
You need to just make up it for MSM7X30 , boot loader loads up by SoC then loads Boot.img ! It won't need any GPU driver or WiFi driver or can driver ! Just you need to port it to msm7x30 which the LK progect supports it !
I've tried to compile it several times but I couldn't make it work for our board so far.
Also how in earth will we implement this into our system ?
Anyways I think this is a great project. I would love to make a custom bootloader if the information is there.
AW: [DEV] MSM7x30 Open Source Bootloader '(L)ittle (K)ernel'
Maybe a look here is helpful: https://github.com/chirayudesai/android_bootable_bootloader_lk
Sent from my GT-I9100 using xda app-developers app
Isn't it what we need? https://www.codeaurora.org/cgit/ext...sm7630_surf/tree/AndroidBoard.mk?h=jb_2.1.3.7
Tapatalk 4 küldve GT-I9001-ről
czobor said:
Isn't it what we need? https://www.codeaurora.org/cgit/ext...sm7630_surf/tree/AndroidBoard.mk?h=jb_2.1.3.7
Tapatalk 4 küldve GT-I9001-ről
Click to expand...
Click to collapse
what i see the problem in:
your suggestion is for msm7630.
we have/need msm7x30.
Lei M said:
what i see the problem in:
your suggestion is for msm7630.
we have/need msm7x30.
Click to expand...
Click to collapse
That's the same.
Tapatalk 4 küldve GT-I9001-ről
czobor said:
That's the same.
Click to expand...
Click to collapse
do you have a source for your information?
it's very strange:
according to http://en.wikipedia.org/wiki/MSM7000 it could be the same but if you take a look here: http://en.m.wikipedia.org/wiki/Snapdragon_(system_on_chip) you see that the msm7630 only has 800MHz cpu
edit:
http://snapvoip.blogspot.co.at/2009/11/qualcomm-introduces-new-mobile-msm7x30.html?m=1
says that msm7x30 is a family of chipsets.
Before doing any thing we have to establish a UART or JTAG Connection to board
I am a total noob at this, but:
My opinion is that if we can access and modify or divide /system /data and /cache on out like, it would be easy to install 2 ROMs.
For example system is mmcblk08
Divide it in 08 and 09.We have 2x /system.Do this with /data, /cache /ramdisk.
But booting is a prob here.
I may be wrong.I don't know if we can touch those partitions.
Costinutz32 said:
I am a total noob at this, but:
My opinion is that if we can access and modify or divide /system /data and /cache on out like, it would be easy to install 2 ROMs.
For example system is mmcblk08
Divide it in 08 and 09.We have 2x /system.Do this with /data, /cache /ramdisk.
But booting is a prob here.
I may be wrong.I don't know if we can touch those partitions.
Click to expand...
Click to collapse
No. We cannot do that. mmcblk0p9 is the ADSP partition (it deals with encoding and decoding video and things like this). And, we cannot modify the bootloaders either, that would require a direct hardware connection through UART. This CAF project is really not that useful for our device...
What we can do for dual-booting is simply partition the ext-sd like we did with the /data on bricked emmc devices, but I'm not sure the system can be mounted on it....
Anyways, managing two backups of two different ROM's can give the same result, but it takes more time.
educk said:
No. We cannot do that. mmcblk0p9 is the ADSP partition (it deals with encoding and decoding video and things like this). And, we cannot modify the bootloaders either, that would require a direct hardware connection through UART. This CAF project is really not that useful for our device...
What we can do for dual-booting is simply partition the ext-sd like we did with the /data on bricked emmc devices, but I'm not sure the system can be mounted on it....
Anyways, managing two backups of two different ROM's can give the same result, but it takes more time.
Click to expand...
Click to collapse
This was just an example, i didn't even know it mmcblk09 exists.
educk said:
And, we cannot modify the bootloaders either, that would require a direct hardware connection through UART. This CAF project is really not that useful for our device...
Click to expand...
Click to collapse
As far as I know the Xperia T hasnt UART too. Wherefor do you need UART? I would just override the bootloader partitions via command line because in a running system the bootloader shouldnt be mounted or even used.
At all it shouldnt be toooo impossible because it has intial support for 7x30...
trapjul
trapjul said:
As far as I know the Xperia T hasnt UART too. Wherefor do you need UART? I would just override the bootloader partitions via command line because in a running system the bootloader shouldnt be mounted or even used.
At all it shouldnt be toooo impossible because it has intial support for 7x30...
trapjul
Click to expand...
Click to collapse
How can you debug a bootldr if no UART is given? The first compiled LK-bootldr will 100% not work correctly, which means the phone will NOT work at all after that! Then you need a UART connection, to revert to the old bootloader or to debug through UART. The Final WORKING build can be flashed through terminal, but the developer who has to get through all the debugging must have UART.
UART
Related
I know the linux and android kernel are different, but not much if you can already chroot into ubuntu. My question is, how do I make/compile a kernel that can boot with Ubuntu NATIVELY? Not chroot, but flash to the internel memory (maybe have to cut some bloatware out for it to fit). Or could I even just use a kernel from android?
I have wondered the same thing! I would love to turn my old Evo into a dedicated BT5 device! No need for Android OS as it just slows down BT5. I am interested in looking into that but and not sure exactly atm.
I get the impression this would be a 10x greater effort than a build of Cyanogenmod.
How so? To my understanding, TECHNICALLY we could have cyanogenmod 6, correct? Since we have froyo source...but thats not the point. With a stripped down linux distro (768mb if we could merge data and system partitions together), and a kernel built for the phone (linux kernel, not android) it should be COMPLETELY possible. My question atm is, how could I compile a kernel compatible with linux (or will the android one work)?
You mean something like this?
http://forum.xda-developers.com/showthread.php?t=892877
No, thats the chroot+vnc method. Basically that runs android in a vm, which is not what I am talking about. I mean installing linux to the internal memory, completely removing android. That way linux could use all 512mb of ram, the only downside is losing android.
ugothakd said:
No, thats the chroot+vnc method. Basically that runs android in a vm, which is not what I am talking about. I mean installing linux to the internal memory, completely removing android. That way linux could use all 512mb of ram, the only downside is losing android.
Click to expand...
Click to collapse
I think that would run a heavy risk of bricking the device since you'd have to overwrite the entire memory.
Maybe, but if you just flashed the root file system to the system (256mb), you would still have the bootloader recovery etc. partitions. Or I'm not exactly sure, maybe delete the data and system partitions and create a new 768mb partition. The only problem is I cant find anything to handle the partitions, fastboot is the closest, and fastboot doesn't work/isnt supported.
You're delving into an area that already has been delved in before. Considering the fact nobody has gotten this working ever, I would go so far as to say you're wasting your time. By all mean have at it, but keep in mind you will need a linux kernel modified in such a way that it will completely support this hardware or it would be useless. Good luck to you!
Sent from my SPH-D700 using XDA Premium App
http://blogs.sonyericsson.com/wp/2011/05/06/how-to-build-a-linux-kernel/
^^^That is the type of kernel suitable for a distro like Ubuntu, correct? Building a kernel with the samsung sources using that guide, should give me a kernel that can be used with linux, correct? I don't see why it is so hard... If you can port linux to a device such as the hd2 whats so different about running it on the epic? Linux and android are very close... the only problem I'm having is finding a way to get a .img to the device.
thomasskull666 said:
You're delving into an area that already has been delved in before. Considering the fact nobody has gotten this working ever, I would go so far as to say you're wasting your time. By all mean have at it, but keep in mind you will need a linux kernel modified in such a way that it will completely support this hardware or it would be useless. Good luck to you!
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
not to mention a few of the drivers are closed source and aren't likely to be compatible with any other kernel version be it one of samsung's kernels or one from linux.....that isn't to say it is impossible but definitely a hurdle
ugothakd said:
http://blogs.sonyericsson.com/wp/2011/05/06/how-to-build-a-linux-kernel/
^^^That is the type of kernel suitable for a distro like Ubuntu, correct? Building a kernel with the samsung sources using that guide, should give me a kernel that can be used with linux, correct? I don't see why it is so hard... If you can port linux to a device such as the hd2 whats so different about running it on the epic? Linux and android are very close... the only problem I'm having is finding a way to get a .img to the device.
Click to expand...
Click to collapse
the first line of that article..."Since the launch of the unlock boot loader site, we have received a lot of really great feedback."
we do not have a modified boot loader and our bootloader is a 2 stage process...i believe the first one is efuse protected...which unless exploited cannot be modified...i'm not sure what kind of checking is done to the secondary bootloader..but one mistake with either of these files you have yourself an expensive paperweight that odin will not fix (no download mode)
edit: i see that site goes on to talk about rebuilding the kernel but still important to remember that stuff about our bootloaders
So even if the kernel worked, the drivers were perfect (which wouldn't be, I know that) and I somehow got an image to the phone it wouldn't boot because of the bootloader?
http://forum.xda-developers.com/showthread.php?t=933667
It can be done but it's not an easy task. This guy has Ubuntu natively booting on the Galaxy Tab.
He's been working on it for a long time and I still don't think it's anywhere close to fully functional, it probably never will be.
Ubuntu + Mobile Phones just weren't meant to be. However.. as this shows... if you devote enough hours to something, anything is "sorta" possible.
There's a thread in the fascinate forum that's relevant to this, about building jigs.
The issue is, as you mentioned, the bootloader. Apparently, it is much like the BIOS on a PC, where you have the option to boot up from different sources. However, our bootloader has those options removed (it actually might have been disabled by hardware, but I can't remember), and only includes normal bootup, recovery kernel, and the kernel/partition that handles download mode.
Obviously you know all this. The developer there is working on a solution, and it could end up being either a software or hardware hack. I suggest you search for the thread (I would if I wasn't on my app).
However, this is relevant because his goal is different than yours, but will most likely be your solution. Rather than modifying the bootloader to handle a larger partition or a linux kernel, it would be easier to get the bootloader to do something it was intended to do back at the factory: boot from USB. There are unused pin configurations that were meant for this, and if enabled could allow a lot of possibilities. Booting ubuntu would be just the tip of the iceberg.
The developer actually has gotten as far as getting a boot log from the very first, barebone bootloader (whatever the acronym is), and shows it searching for usb host or whatever. I'm gonna see if I can dig up the link.
EDIT: er, maybe not fascinate forum, I'm having trouble finding it
Sent from my SPH-D700 using XDA Premium App
Try searching for the SGS Ubuntu attempts. I know that someonne in #ubuntu-arm has gotten it to a usable state on his SGS. However, be prepared to lose functionality.
Question is why. There won't be an accelerated X server, and if you are looking to target a embedded linux surely there are better systems out there. You'll also have to deal with the keymappings afaik because that's apparently dealt through system_server via keymaps, and not the kernel.
-- Starfox
Starfox said:
Question is why.
-- Starfox
Click to expand...
Click to collapse
Hacker Mantra: Cause you can
Why climb Mt. Everest? Cause you can.
Why put linux on every device out there? Cause you can.
tyl3rdurden said:
Hacker Mantra: Cause you can
Why climb Mt. Everest? Cause you can.
Why put linux on every device out there? Cause you can.
Click to expand...
Click to collapse
True that, it is pretty damn adaptable that's for sure.
Sent from my SPH-D700 using XDA Premium App
haha found it!
relevant http://forum.xda-developers.com/showthread.php?t=1065318
I own a tegra 2 device that can boot BT natively, I know it's nowhere close to our chipset but perhaps it could lead somebody with the right skillset down this road for the Epic; http://forum.xda-developers.com/showthread.php?t=1075054
Warning/disclaimer: This thread is intended for those who already know how to compile a kernel and have a working knowledge of Linux and its derivatives. There shouldn't be a great deal of risk involved, but you are responsible for what happens if you decide to follow these instructions.
Polite request: Please don't post replies to this thread that aren't of a technical nature directly related to compiling, modifying, or testing the kernel.
Introduction:
It appears as if Lenovo have released a buildable and bootable kernel source. I've done some preliminary testing with it. However, it would be better if we could get lots of people building and running the kernel, so that we can spot any remaining problems. This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Kernel source:
Get it from the Github repository at: https://github.com/gmarkall/lenovo_a1_07_kernel
Toolchain:
The Makefile seems to suggest that Codesourcery 2010q1 has been used by Lenovo to compile the kernel. Get it from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1293, and make sure that the arm-none-linux-gnueabi-* binaries are on your path.
Building the source:
You may wish to edit the Makefile around line 192 to set CROSS_COMPILE=arm-none-linux-gnueabi- instead of the hardcoded path that is the default.
Then, to build the kernel:
Code:
make distclean
make a1_07_defconfig
make uImage
Booting the kernel
Normally, Android devices have two boot images that consist of a kernel and a ramdisk. One boot image is for the recovery, and the other is for the Android system. This makes it safe to flash a new boot image containing an untested kernel for the Android system, since the recovery can always boot up using the other boot image. However, the A1, by some bad design decision, only has one kernel - the bootloader always loads the same kernel, and just loads a different ramdisk depending whether it is to boot into recovery or system. As a result, it is not safe to flash a kernel to your A1 unless it's already been tested, since a bad kernel will make it impossible to boot from the internal memory, and you'll need a bootable SD card.
The solution to this problem is to make a bootable SD card for loading the kernel and ramdisk from. A bootable SD card consists of two partitions:
* A small bootable VFAT partition, that holds the X-Loader (MLO), U-Boot (u-boot.bin) and the kernel (uImage).
* An ext2 partition that holds the root filesystem.
In order to create a bootable SD card, use the omap3-mkcard.sh script that is attached below. To invoke it for making /dev/mmcblk0 a bootable SD card:
Code:
sudo omap3-mkcard.sh /dev/mmcblk0
You may need to hack the script if your SD card device isn't a /dev/mmcblk* one, since the script searches for partitions denoted "p1" and "p2" - this may need changing to just "1" and "2" respectively (thanks Xbdesign and Brancaleone for this).
This will create the necessary partitions, set the bootable flag, and format them. You will then need to mount the first partition (e.g. /dev/mmcblk0p1), and copy MLO and u-boot.bin to it (also linked below). Then, copy the uImage that you built from your kernel tree, which will be located in /arch/arm/boot. You can now unmount this partition.
Next, mount the second partition (e.g. /dev/mmcblk0p2). This will need to contain the same set of files that the initial ramdisk contains. There are two different ramdisks that you might want to use - one is from the Cyanogenmod 7 build, and the other one is from the stock system. Download links for these are also below. To extract the ramdisk, copy it onto the SD card second partition, then run the following commands (assuming the ramdisk is called ramdisk.ub):
Code:
dd if=ramdisk.ub of=ramdisk.img.gz bs=64 skip=1 # Strip off the U-Boot header
gunzip ramdisk.img.gz # Unzip
sudo cpio -idmv < ramdisk.img # Extract the cpio archive
Then, unmount the second partition of the SD card.
You should now be able to remove the SD card and insert it into your A1. Power down the A1 and power up again, and it should hopefully boot from the SD card and load your kernel. If it's booted from the SD card and loaded your kernel, you should be able to see that it was compiled on your host by looking in Settings -> About Phone -> Kernel Version.
Troubleshooting:
This is not a comprehensive guide, just a few pointers to where a problem might be - please post replies to the thread to get troubleshooting suggestions.
System boots up, but is not running my kernel - it didn't boot from the SD card. If the A1 is plugged into the charger/USB, you sometimes need to reboot multiple times before it boots off the SD card (I think it doesn't always turn off fully when the charger is plugged in).
The static Lenovo logo flashes up over and over again - it's booted from the SD card, but didn't manage to load your kernel
The static Lenovo logo comes up and stays there/goes to a black screen - it's probably loaded your kernel and mounted the root file system, but failed to mount /system. Try running adb shell to see what happens. If you get something like
Code:
/system/bin/sh: no such file or directory
then your kernel is running but /system isn't mounted.
IRC Channel
Join #ideapad-a1 on irc.freenode.net to discuss the kernel and other A1 development-related topics!
Download Links:
MLO
u-boot.bin
omap3-mkcard.sh
Ramdisk for Cyanogenmod 7
Ramdisk for ROW 2643 stock release
I've added the two ramdisks that I suspect will be most common - if you need another ramdisk, you'll have to extract it from an OTA.
Also, I compiled a tun.ko - www.doc.ic.ac.uk/~grm08/ideapad/tun.ko
Here's a cifs.ko - http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
EDIT: AutobahnA1 and infraredevans have confirmed that tun.ko works on ROW_2643.
EDIT 2/3: Please test out cifs.ko! (It doesn't work - it needs slow-work.ko. Will get that done when I can. Thanks to Ilikecokethree on the Lenovo forums for pointing that one out).
你懂中文吗，大神！
我是中国人 关注你的帖子很久了，我不懂英文，用翻译软件看的大概，我们这里很多人支持你，都在用你的rom 很棒！比联想官方的好多了，谢谢！
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong? Thank you very much.
PS: I'm a chinese too, and my English is not good either
gmarkall said:
This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Click to expand...
Click to collapse
Please do not forget to try the WiFi-based geolocation, which is also missing!
I wish I had the knowledge to work on it myself but I am far from taking over such tasks...do not have the slightest idea about how these things work.
Good luck and please keep us informed!
geoponer said:
Please do not forget to try the WiFi-based geolocation, which is also missing!
Click to expand...
Click to collapse
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Also, it's working in CM7.
hohoxu_hao115 said:
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong?
Click to expand...
Click to collapse
Sounds like it's booting from eMMC instead.
Can you post the partition table of the SD card as listed by fdisk, and also a directory listing of each of the two partitions? I ask this to confirm what's happened - seems like you're the first person to follow these instructions, and it's quite possible I made a mistake somewhere.
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
@Graham: I plan to install the CM7 that you have been working on (with the feedback from other users - I keep an eye on that thread!) but since I use my A1 for professional purposes as well, I would like to make sure that everything is working fine before moving to CM7. Apologies for not being able to contribute to the beta testing of CM7 but I am really looking forward to seeing a version based on the source code provided by Lenovo, which I think will lead to a more stable version of your CM7. I cannot thank you enough for taking the time to work on this, really!
geoponer said:
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
Click to expand...
Click to collapse
I think that whether it works in CM7 or not, it almost certainly isn't a kernel issue. I'll test it by signing up for Foursquare and give it a try out on CM7 to see if it works later on. Will post my findings in the CM7 thread.
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
dusko_m said:
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
Click to expand...
Click to collapse
I do want to implement something that's pretty much as you describe. My biggest motivation is that it's currently not safe to flash a kernel since you can break both system and recovery that way in one go - I really want to make the boot process more robust.
gmarkall said:
Also, I compiled a tun.ko - tun.ko
I haven't tested it yet - is anyone able to try it please?
Click to expand...
Click to collapse
The module loaded without a problem on my 2643_ROW Kernel. Installed "Rooted AnyConnect" from the "Play Place". Now I can connect to my company VPN.
gmarkall: YOU ROCK! THANK YOU!!!
tun.ko
Graham
The tun.ko module works perfectly with openvpn on 2643_ROW.
I can now access my Amahi home server,awsome.
Thanks a lot you are doing a great job.
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Cheers
Infraredevans said:
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Click to expand...
Click to collapse
I'll give it a whirl... give me a few minutes.
gmarkall said:
I'll give it a whirl... give me a few minutes.
Click to expand...
Click to collapse
Here it is: http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
To compile it I had to copy md5.h from another kernel source to fs/cifs in the kernel tree. I also had to edit init/Kconfig so that CONFIG_SLOW_WORK defaulted to yes. I configured the module with the options:
Support Legacy LANMAN servers which use weaker security
CIFS Extended attributes
CIFS POSIX attributes
and without statistics, debugging, or experimental features. Let me know if this is a suitable config - I could always tweak it and build another one.
arm-2010q1-202-arm-none-linux-gnueabi.bin
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
xbdesign said:
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
Click to expand...
Click to collapse
I did - I didn't have any problems, but my random guess about how to solve it could be to install ia32-libs. If installing that doesn't solve it, can you post a bit more detail about the problem?
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
xbdesign said:
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
Click to expand...
Click to collapse
Do you need that to run the installer? I just downloaded the tar version instead and extracted it. I saw there was an installer as well, but I thought it would be more hassle than using the tarball so I just ignored it.
It seems that finally I was able to boot custom kernel with working radio
It's not very stable yet(it stops/crashes at bootanimation quite frequently), and is quite laggy just after boot, but once it boots it seems to be almost usable. Wifi works, sdcard also. Haven't checked bluetooth.
Credits for this goes to:
* milestone1 devs... for sharing 2ndboot source code and providing so much info regarding milestone1/2 phones
* Motorola ... for providing source code(not fully working, but was a great help anyway) for enabling UART over micro usb for debugging purposes(without this I woudn't make any progress)
* tezet... for making quite good roms used by 2ndboot
If you wish to try it(BEWARE THAT IT MIGHT BRICK YOUR PHONE, SO DON'T SAY THAT I HAVEN'T WARNED YOU ), then do as follows:
1. Install tezet's JB10(if you don't have one already).
2. extract 2ndboot.tar(attached) into /data folder, check that /data/2ndboot/hbootuser file has execute permissions.
3. overwrite /system/bootmenu/script/2nd-boot.sh(DON'T TOUCH 2nd-init.sh!!!) with the one from tar(2nd-boot.sh.tar) and check it has execute permissions.
4. reboot into bootmenu
5. change the default boot method to 2ndboot
6. Restart your phone. Most likely it will crash few times at bootlogo, but be patiant, it finally should boot
7. If you wish to get back to 2nd-init, then enter bootmenu again and change default boot method back to 2nd-init, or manually boot 2nd-init
Click to expand...
Click to collapse
Please let me know if someone actually run it and was able to boot(so that to find out if I haven't forgot to include some more files(see changelog for 03.10.2012)
KNOWN LIMITATIONS
Boots very sloooowly
Its' quite laggy just after boot.
GPS does not seem to work yet
Click to expand...
Click to collapse
CHANGELOG
01.10.2012 - corrected battery problems(thanks to Quarx and kabaldan)
03.10.2012 - corrected ramdisk(previous one was calling some script which I forgot to attach to this post, new one has this script inside), so that now you should be able to boot it; updated instructions how to install it; enabled TLS in the kernel(thanks to kabaldan)
04.10.2012 - touch driver updated, now should work with lastest JB(thanks to Eleanor_Ir, Quarx), adb fixed(I hope, stability fix(thanks to Quarx)
Click to expand...
Click to collapse
NOTES for devs
In milestone2(as probably in many others UMTS phones made by Motorola) the BP is somehow very sensible and does not like to be disconnected/reenumerated. The main goal of this 2ndboot is then to not allow it to be disconnected. To do this, in the new kernel I've skipped a few resets(EHCI, TLL, individual port resets), and instead of enumerating BP, I've used the hardcoded usb device address(which for milestone2 seems to be equal to 2).
I attach patch(radio.patch) with the changes I've done to the kernel sources from here:
http://sourceforge.net/projects/milestone.motorola/files/MILS2_U6_4.1-22/
This seems to work(sometime) for both milestone2 and defy.
For other motorola phones:
1. First of all, check with lsusb what's the address and vendor/product id of your BP(for milestone2 it's 0x22b8 and 0x40e6).
2. If the BP usb device address is 2, then just apply the patch(probably it will need some small modifications), and check if it works.
3. If the BP usb device address is not 2, then edit usb/core/hub.c function hub_port_init(providing that it's there for your kernel), and replace 0x02 in the place where usb_control_msg to get descriptors is sent with address of your device
If it does not work, then you can try the following:
Create a procedure to send usb GetDescriptors request using omap3 ehci registers, and call it at different boot stages/usb initialization stages to find out how long the radio remains attached, and comment/change appropriate fragments of kernel code, to preserve this until usb port is initialized. If you wish, I can share the procedure I've written(in the patch file this is that czecho_get_descriptors called in many places) for milestone2, but it probably would need some modification to work with your device).
2ndboot module sources are here:
https://github.com/czechop/2ndboot
Wow, thats perfect This could bring M2 development to another level.
Holding thumbs up and keep it up!
Great news! Thx for your work. I've just bought an OTG cable to start playing with kernel stuff and here's a surprise
Fabulous! That means it starts a new era in the development of our MS2 Roms!
Wonderful job man
Brilliant
Sent from my A953 using Tapatalk 2
I'm gonna try on the Motorola Bravo as soon as PA is done uploading. Hopefully this'll work on Froyo kernels as well :fingers-crossed:
What kernel are you using? A recompiled MS2 GB kernel unmodified?
Awesome job man. This could possibly be the start of a new generation of roms for our common platform if this works on other similar phones like the Defy\Bravo. Only time will tell .
Well good work OP, can this be implemented on other Moto phones like Defy?
Great work !
I see that your work is based on Moto's Linux kernel (2.6 branch as far as I remember...)
Any hope of using another kernel source one day ?
Great News!, Thanks
Waiting for source code
Wow! Tezet and Quarx on the same thread?! I feel like up on the Mount Olypmus lol
Great job, man!...been following your work from General section.
P.S. add Kabaldan to the list Clash of the Moto Titans
skeevy420 said:
I'm gonna try on the Motorola Bravo as soon as PA is done uploading. Hopefully this'll work on Froyo kernels as well :fingers-crossed:
What kernel are you using? A recompiled MS2 GB kernel unmodified?
Awesome job man. This could possibly be the start of a new generation of roms for our common platform if this works on other similar phones like the Defy\Bravo. Only time will tell .
Click to expand...
Click to collapse
Yes, I use MS2 GB U6_4.1-22(http://sourceforge.net/projects/milestone.motorola/files/MILS2_U6_4.1-22/) kernel... but with modified usb host driver.
nidhish91 said:
Well good work OP, can this be implemented on other Moto phones like Defy?
Click to expand...
Click to collapse
I think it can be.
With defy it probably should be easy, as I've seen there was 2ndboot(without radio) already build for it, so most likely only new kernel would need some tuning
czechop said:
I think it can be.
With defy it probably should be easy, as I've seen there was 2ndboot(without radio) already build for it, so most likely only new kernel would need some tuning
Click to expand...
Click to collapse
XT720 users also waiting for instructions for new kernel tuning, cause we have working 2ndboot without radio. =)
boorce.com said:
Great work !
I see that your work is based on Moto's Linux kernel (2.6 branch as far as I remember...)
Any hope of using another kernel source one day ?
Click to expand...
Click to collapse
It should be easy to apply some(perhaps most) 2.6.32 upstream patches to the motorola kernel sources.
Don't know however how difficult it would be to start from another kernel version. Don't know also how motorola proprietary modules/libs would behave with newever kernel version. But, as they say, impossible is nothing
czechop said:
I think it can be.
With defy it probably should be easy, as I've seen there was 2ndboot(without radio) already build for it, so most likely only new kernel would need some tuning
Click to expand...
Click to collapse
In kernel only modified usb driver or some more changes for boot?
fjfalcon said:
XT720 users also waiting for instructions for new kernel tuning, cause we have working 2ndboot without radio. =)
Click to expand...
Click to collapse
Will share source code probably early next week(currently am at work, and during weekend most likely won't be sober enough
Quarx said:
In kernel only modified usb driver or some more changes for boot?
Click to expand...
Click to collapse
In 2ndboot module I've added code to disable lcd before starting new kernel(otherwise new kernel could not initialise properly dss), and in new kernel I've only modified usb driver(perhaps more things will need to be modified, as I'm facing problem with BATTD sayins something about power ic fail, BTW, does someone know what that could mean?), so that it skips restaring EHCI, TLL and don't start enumeration, but just used the old usb device address(assigned by the original kernel), which for M2 is always 2(at least during my tests).
I2c Fail can be caused by wrong permissions for /dev/cpp*
I tried your prebuilt binaries on defy http://pastebin.com/jKjQ2ykn
Black screen + buttons lights and reboot after ~20sec
Quarx said:
I2c Fail can be caused by wrong permissions for /dev/cpp*
I tried your prebuilt binaries on defy http://pastebin.com/jKjQ2ykn
Black screen + buttons lights and reboot after ~20sec
Click to expand...
Click to collapse
Thanks for hint regarding permissions...will check that
Regarding prebuilt binaries on defy, hard to say what's wrong(not sure how much the phones differ). Anyway, you probably would need to use devtree from your device. Also you could unpack ramdisk, and check the init.*.rc scripts if they are ok(e.g. I mount system partion using p21, not sure if that's the same for defy, and staff like that).
Hey guys. As the title states, we need to destroy SBOOT to leave the device in an otherwise "hard-bricked" state. This would open the door to loading an insecure bootloader. Currently our option is to perform a hardware hack to brick the device which is obviously not optimal...
So, the question is, how can I write some garbage like a Justin Beiber MP3 over the SBOOT?
If you've come up with a way to hard-brick this device, it would be very helpful if you share.
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
AdamOutler said:
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
Click to expand...
Click to collapse
i can link u to a kernel but from what i know no one has looked into kexec yet.. also did u mean to put this in international forum or verizon one cause were in international now not verizon
AdamOutler said:
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
Click to expand...
Click to collapse
Add me on gtalk I have a guy on my team that's a kernel guru I'm sure he can get done anything you need, I'll reply with his gtalk info
Sent from my SCH-I605 using xda app-developers app
beanstown106 said:
cause were in international now not verizon
Click to expand...
Click to collapse
There's currently only one dev discussion section shared among all the Note2 devices.
Adam, I haven't messed with kexec, and my schedule is a bit nightmarish until the new year... If no one has come up with something by then, I'll (try to remember to) work on it then.
take care
Gary
bbedward is building a kernel right now. Adam i will PM you his gtalk
http://goo.im/devs/bbedward/vzwnote2_image.zip
There's a stock note 2 kernel build, it includes this and is stock otherwise except for some gcc 4.7 fixes https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0
Maybe it'll help somebody if they get kexec working :good:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
iamsamiam said:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
Click to expand...
Click to collapse
yes
invisiblek said:
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
yes
Click to expand...
Click to collapse
this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.
droidstyle said:
this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.
Click to expand...
Click to collapse
probably out of my scope but..... sboot checks the recovery partition at STARTUP (i would guess its the first thing checked, since when i soft bricked mine it wouldnt do ANYTHING but tell me the software is not genuine, any way we could inject(probably not the right word) it after the check?
invisiblek said:
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
Click to expand...
Click to collapse
FYI guys this didn't work
Error was something about "exports duplicate symbol....(owned by kernel)"
Found it funny I got "owned by the kernel", but w/e...
Here's the module in case anyone wants to mess around with it, dmesg is where the error appears
http://invisiblek.chickenkiller.com/mmc_block.ko
Pretty sure there is no way to get this loaded, but the steps to do so would be:
- throw it in /lib/modules (this is non-persistent)
- chmod it to at least 644
- busybox modprobe -f mmc_block
While this is mostly specific to the Verizon variant, being able to kill SBOOT to force SD-card boot is a technique that would be usable on multiple devices in the future.
Pretty much it's that the VZW Note2 NEEDS the ability to kill SBOOT starting from a stock kernel without anything beyond root, but it may be useful on other devices too.
And if people are wondering why we're TRYING to hardbrick a device - if you hardbrick by killing SBOOT, the device falls back to booting from the SD. Samsung's "official" hardbrick recovery technique does this by shorting a resistor to disable the eMMC.
The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.
Entropy512 said:
...The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.
Click to expand...
Click to collapse
I don't understand what prevents access to mmcblk0boot0 (and like) partitions, in the first place. (?) Any insight you care to share? Only thing I could suggest is to have a look at these mmc tools, in various repositories, although very similar, if not identical.
http://patches.linaro.org/project/linux-mmc/
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=summary
https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils/
In fact, the problem of being able to fully access eMMC devices, is understated. It would have great benefits for the developer community to things ranging from removing partition write protections to unbricking TV sets...
Found in:
[linux/kernel/git/cjb/mmc.git] / Documentation / mmc / mmc-dev-parts.txt
from first link:
Code:
SD and MMC Device Partitions
============================
Device partitions are additional logical block devices present on the
SD/MMC device.
As of this writing, MMC boot partitions as supported and exposed as
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
parent /dev/mmcblkX.
MMC Boot Partitions
===================
Read and write access is provided to the two MMC boot partitions. Due to
the sensitive nature of the boot partition contents, which often store
a bootloader or bootloader configuration tables crucial to booting the
platform, write access is disabled by default to reduce the chance of
accidental bricking.
To enable write access to /dev/mmcblkXbootY, disable the forced read-only
access with:
[B]echo 0 > /sys/block/mmcblkXbootY/force_ro[/B]
To re-enable read-only access:
[B]echo 1 > /sys/block/mmcblkXbootY/force_ro[/B]
The boot partitions can also be locked read only until the next power on,
with:
[B]echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
[/B]
This is a feature of the card and not of the kernel. If the card does
not support boot partition locking, the file will not exist. If the
feature has been disabled on the card, the file will be read-only.
The boot partitions can also be locked permanently, but this feature is
not accessible through sysfs in order to avoid accidental or malicious
bricking.
The code we need to modify is probably that of the 3rd link (above), in mmc_cmds.c (and related). But I'm not sure it's possible to use this to disable write protect, although it seem like here:
Code:
[SIZE=2]...
/*
* EXT_CSD field definitions
*/
#define EXT_CSD_HPI_SUPP (1<<0)
#define EXT_CSD_HPI_IMPL (1<<1)
#define EXT_CSD_CMD_SET_NORMAL (1<<0)
[COLOR=Red][B]#define EXT_CSD_BOOT_WP_B_PWR_WP_DIS (0x40)
#define EXT_CSD_BOOT_WP_B_PERM_WP_DIS (0x10)[/B][/COLOR]
#define EXT_CSD_BOOT_WP_B_PERM_WP_EN (0x04)
#define EXT_CSD_BOOT_WP_B_PWR_WP_EN (0x01)
#define EXT_CSD_BOOT_INFO_HS_MODE (1<<2)
#define EXT_CSD_BOOT_INFO_DDR_DDR (1<<1)
#define EXT_CSD_BOOT_INFO_ALT (1<<0)
#define EXT_CSD_BOOT_CFG_ACK (1<<6)
#define EXT_CSD_BOOT_CFG_EN (0x38)
#define EXT_CSD_BOOT_CFG_ACC (0x03)
#define EXT_CSD_RST_N_EN_MASK (0x03)
#define EXT_CSD_HW_RESET_EN (0x01)
#define EXT_CSD_HW_RESET_DIS (0x02)
#define EXT_CSD_PART_CONFIG_ACC_MASK (0x7)
#define EXT_CSD_PART_CONFIG_ACC_BOOT0 (0x1)
#define EXT_CSD_PART_CONFIG_ACC_BOOT1 (0x2)
#define EXT_CSD_PART_CONFIG_ACC_USER_AREA (0x7)
#define EXT_CSD_PART_CONFIG_ACC_ACK (0x40)
[SIZE=2]...[/SIZE]
[/SIZE]
[mmc.h]
_Dennis_ said:
I have a t-mobile Note 2 and I was messing around with the *#197328649# menu and found these in UMTS, Version Information, secure boot status.
Secure VAL: 4369
SEC_BOOT:1
OEM_PK_HASH:1
SEC_HW_KEY:1
OEM_CONFIG:1
Like I said may or may not help but seeing secure boot made me think of you guys.
Sent from my handheld Android 'PC', NOTE II
Click to expand...
Click to collapse
guy posted this in the rom thread, posting it here to.. i also have no idea what it is but cant hurt right? lol
invisiblek said:
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
yes
Click to expand...
Click to collapse
So I think people have a misconception of what kexec is.
kexec is a system call that enables you to load and boot into another kernel from the currently running kernel.
Click to expand...
Click to collapse
Here
Yes there was orignally a kexec for the SGSIII that was issued in the recovery partition but this is not what kexec does. IT LOAD A KERNEL DIRECTLY ONTOP OF THE CURRENT. It does not access memory. It does not change any of the partitions, and it does not make it so that phone will not be "secure" for booting. It does not require any access to the recovery partition and does not need kexec-enabled in the kernel necessarily. When you enable kexec in the kernel, all you do is provide a handle for the actual binary so it knows where in the stack to replace the kernel. Without this you must write in your own kexec injection vectors, and this can be difficult, but has been done for devices before (see nook tablet). There's no doubt in my mind that this would be an incredibly daunting task, however if someone did it, it might prove usefull for every device in existence that has a locked bootloader.
As for the topic at hand. To what I have scene and read here it sounds like the default kernel does not allow you to access the mmcblk0, which is kinda a pain. Though it might only not allow you to do this by name. I wonder if you overloaded partition table if it would start to bleed into the first block. Or if we can write a program that references the memory by location instead of by pointer, aka 0x81000000 instead of mmcblk0. Also you might want to dump the system kernel in the recovery or any other bootable mode. It is possible that its only on the system image kernel that it blocks this. IE boot into recover mode and or download mode and see if that subspace can be accessed. As a last resort adam you might be able to boot it into panic mode with the boot pins. I havent been able to find a diagram, but it is always possable to brick the device with pins, which ones are beyond me though i found this. Unfortunately no mention of boot conditions anywhere there.
I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.
Sent from my Amazon Kindle Fire using xda app-developers app
times_infinity said:
I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.
Sent from my Amazon Kindle Fire using xda app-developers app
Click to expand...
Click to collapse
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
chayes627 said:
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
Click to expand...
Click to collapse
Exactly who i was thinking of when i wrote that post.
Sent from my Galaxy Nexus using xda app-developers app
I hit up hash on gtalk today and pointed him to this thread.. Seems at least we should be able to get a hacked recovery working like safe-strap. Then again I am no recovery nor kernel dev
Title says it all.
Basically, I'm gonna need help on this, I don't know how much, but I will need it. I'm pushing all my changes to my GitHub repo regularly, but so far I'm simply trying to get the grouper board files set up. Here's how I'm going about that:
cherry-pick Google's commits which added grouper support to 3.1.10 kernel
Fix conflicts
Compile
Inspect errors
Update grouper board files against kai board files commits from here (from the k3.3: kai: Updates to board files commit onwards
Recompile
etc.
Beyond this I'm not really too knowledgeable in al the device tree stuff. Sure, I've read up on alot of stuff, but have no practical experience. Therefore once I've got the board files how I think they should be, if things still don't work then I will need help. Luckily, it looks like the kai board and grouper are extremely similar. So with any luck it'll work without too much hassle.
Beyond this stuff will probably be broken anyway, so I will need help with that.
Feel free to discuss anything relevant, and to offer anything you think might be useful. There are some real devs here who would make a big impact on this, as there's only so much blind tinkering I can do.
Thanks
Here's an updated link https://github.com/enssorcel/Grouper-3.4
The first on doesn't seem to be working
USBhost said:
Here's an updated link https://github.com/enssorcel/Grouper-3.4
The first on doesn't seem to be working
Click to expand...
Click to collapse
Woops sorry, I linked to my testing branch so I had deleted it already. For whoever's following this, you want to go here to see what I've merged into the master branch i.e. what I've fixed, and click the branch pulldown and go here to see what we've been working on, the names are self-explanatory.
Thanks to @sgt. meow 's help we've made quite a bit of progress, we've fixed the errors for the majority of the grouper files so we're getting close to a successful compilation. Beyond that, who knows.
EDIT: Just fixed board-grouper-power.c. sensors will be the next focus, hopefully fixed soon.
EDIT1: All board files are fixed! (well, the compilation errors are gone, but we don't know if they work yet)
Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
I don't suppose anyone has a serial cable and access to UART or anything similar?
HTCDreamOn said:
Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
I don't suppose anyone has a serial cable and access to UART or anything similar?
Click to expand...
Click to collapse
have you used a grouper boot.img for repacking zImage?
HTCDreamOn said:
Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
I don't suppose anyone has a serial cable and access to UART or anything similar?
Click to expand...
Click to collapse
Yeah, it doesn't boot on my tilapia. But I'm glad you use agnostic-kernel
lupohirp said:
have you used a grouper boot.img for repacking zImage?
Click to expand...
Click to collapse
Of course I used the stock boot.img from 4.4.3 unpacked it with unmkbootimg, replaced the zImage, repacked with mkbootimg then replace the boot.img in the agnostic kernel with the new one.
frantisek.nesveda said:
Yeah, it doesn't boot on my tilapia. But I'm glad you use agnostic-kernel
Click to expand...
Click to collapse
I don't know if it would boot on tilapia anyway, I think they use the same board files so maybe. Yeah its especially awesome for stuff like this cause I don't need to worry about making a different version for everyone who wants to test it on different file systems :victory: that said it'd be great if someone can test this on ext4 to make sure.
So can anyone help? Even it you can just be a guinea pig with a serial cable
Will test now
Edit: stuck on Google screen
Edit: I am All-F2FS Carbon ROM
USBhost said:
Will test now
Edit: stuck on Google screen
Edit: I am All-F2FS Carbon ROM
Click to expand...
Click to collapse
This is either because we have more work to do to get it booting, or because the defconfig is being stupid, I remember I couldn't get franco kernel to boot unless I used cyanogenmod's defconfig although of course that's for 3.1.10 so that's not really an option.
HTCDreamOn said:
This is either because we have more work to do to get it booting, or because the defconfig is being stupid, I remember I couldn't get franco kernel to boot unless I used cyanogenmod's defconfig although of course that's for 3.1.10 so that's not really an option.
Click to expand...
Click to collapse
you can use 3.1 kernel config. BTW i saw your config and you don't have added F2FS drivers, so on F2FS roms will not boot. We must test on ext4 rom......otherwise seems a good base for start.
HTCDreamOn said:
It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
Click to expand...
Click to collapse
Hangs at Google logo
Grouper, SlimKat 4.4.4 build 5.2, (all ext4).
lupohirp said:
you can use 3.1 kernel config. BTW i saw your config and you don't have added F2FS drivers, so on F2FS roms will not boot. We must test on ext4 rom......otherwise seems a good base for start.
Click to expand...
Click to collapse
OK I'll try cyanogen's defconfig and see what happens. Will I have to regen for 3.4 or can I just use it straight off? I've added f2fs support in my f2fs-testing branch and enabled it now, thanks for the tip
Lar5 said:
Hangs at Google logo
Grouper, SlimKat 4.4.4 build 5.2, (all ext4).
Click to expand...
Click to collapse
Thanks, now we know it'd definitely not an fs problem :good:
Don't give up your doing great
Remember I'm here to help test and i may even reformat my nexus 7 back to
All-EXT4 to help test
USBhost said:
Don't give up your doing great
Remember I'm here to help test and i may even reformat my nexus 7 back to
All-EXT4 to help test
Click to expand...
Click to collapse
Don't worry, not giving up, just thinking. We Ideally need someone with a serial cable because we're kinda stuck without debuuging unless we can find someone who can spot the problems from the code.
HTCDreamOn said:
Don't worry, not giving up, just thinking. We Ideally need someone with a serial cable because we're kinda stuck without debuuging unless we can find someone who can spot the problems from the code.
Click to expand...
Click to collapse
where can one get such a cable
USBhost said:
where can one get such a cable
Click to expand...
Click to collapse
You need to make one, basically the N7 has a UART port in the headphone jack but you need to make an adapter: http://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ it's widely assumed the process is the same for all Nexus devices but I haven't found anyone testing it with the N7 do there's no confirming it would work. Hopefully if it didn't then it'd must be a case of enabling stuff in the kernel (there may have been some commits disabling it for release). If you wanna help out then this would be invaluable though
HTCDreamOn said:
You need to make one, basically the N7 has a UART port in the headphone jack but you need to make an adapter: http://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ it's widely assumed the process is the same for all Nexus devices but I haven't found anyone testing it with the N7 do there's no confirming it would work. Hopefully if it didn't then it'd must be a case of enabling stuff in the kernel (there may have been some commits disabling it for release). If you wanna help out then this would be invaluable though
Click to expand...
Click to collapse
interesting I'll see what I can do
Not making any promises
Edit: it shouldn't be too hard to make
Just need $17.17 to make it
Will see
I'm not sure you'll have much luck with the UART cable. An RD (now retired) got his device to recognise the UART board, but failed to receive any output.
As you all probably know, even after updating the board files against KAI from the nvidia source, we couldn't get it to boot. So we applied a few commits from Google, and guess what, still doesn't boot. If anyone wants to join in the chat at hangouts, drop in your gmail here. We need all the help we can get.
Maybe the kernel boots far enough to leave some traces in last_kmsg. The only problem is that the contents are lost if the device is powered off. If you're lucky the contents survive a short time without power. But usually if the kernel boots far enough it will panic and restart itself.