Related
There's been a few ROMs based on the stock kernel--one of them is mine--but nothing more in-depth. I'm setting out to change that, but I could use some help from more experienced folks.
What I've found so far:
- It uses the MSM7227_Surf Qualcomm System-on-chip (verified by disassembling a broken phone)
- which also has the Adreno200 GPU (built into MSM7227_Surf)
- It has 512MB flash partitioned very similarly to the Samsung Gio, with most partitions being at least the same if not sightly larger (with the exception of /system and /data being split differently such that /system is bigger than on the Gio and /data is smaller)
- Unlike the Ace/Gio, it uses a Broadcomm wifi chipset instead of the atheros at6000
What I'm stuck on at the moment is the partition map. How do I get the precise partition sizes when /proc/mtd doesn't exist?
I was able to figure it out. Since the partitions are nearly identical to the Samsung Galaxy Ace, I took a look at that phone's BoardConfig.mk and figured out the formula:
1) Get the partition list from 'cat /proc/partitions'
2) Multiply the reported # of blocks by 1024 to get the size in bytes
3) Convert the result from #2 to hexadecimal
Results:
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00A00000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00A00000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x0DD00000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x09800000
BOARD_FLASH_BLOCK_SIZE := 4096
EDIT: I just found where this phone puts the equivalent of /proc/mtd. It's in /proc/LinuStoreIII/bmlinfo:
Code:
FSR VERSION: FSR_1.2.1p1_b139_RTM
minor position size units id
1: 0x00000000-0x00180000 0x00180000 6 1
2: 0x00180000-0x00200000 0x00080000 2 2
3: 0x00200000-0x002c0000 0x000c0000 3 3
4: 0x002c0000-0x01bc0000 0x01900000 100 4
5: 0x01bc0000-0x024c0000 0x00900000 36 23
6: 0x024c0000-0x029c0000 0x00500000 20 25
7: 0x029c0000-0x02bc0000 0x00200000 8 5
8: 0x02bc0000-0x035c0000 0x00a00000 40 6
9: 0x035c0000-0x03fc0000 0x00a00000 40 7
10: 0x03fc0000-0x04080000 0x000c0000 3 8
11: 0x04080000-0x05980000 0x01900000 100 9
12: 0x05980000-0x13e00000 0x0e480000 914 21
13: 0x13e00000-0x1dc00000 0x09e00000 632 22
14: 0x1dc00000-0x1f500000 0x01900000 100 24
I just signed up a few minutes ago with this account to say thanks for doing this, from another guy who has just gotten this phone! (Well the Canadian version, same thing basically called the "Samsung Galaxy Q"/SGH-T589R) Not sure if I can do much, the closest thing I do compared to this is using Linux. I'll be rooting for you.
My initial goal was to get a Gingerbread kernel that a) supports the Galaxy Ace (the Gravity SMART's more popular cousin) and b) actually compiles, but I didn't have much luck. The kernel I wanted to use was built against some long-deprecated kernel source that I couldn't dig up--and applying the diff against the Samsung stock source tree failed to compile.
So, I've gotten a copy of the source to the ICS kernel developed by Maclaw & others [still too newb to post links] for the Samsung Gio and Samsung Ace.
Next step: finding the stuff unique to the Gravity SMART.
Fun fact: The Gravity SMART was originally code named the Gravity Touch 2, and this is reflected in the source code where the model's config flag is named CONFIG_MACH_GT2 (as opposed to CONFIG_MACH_COOPER for the Ace).
My initial suspicions are proving to be pretty spot-on. Quite a few of the changes involve simply adding "|| defined(CONFIG_MACH_GT2)" into an existing chain that typically includes the CONFIG_MACH_COOPER or CONFIG_MACH_GIO. However, there are a number of notable exceptions. Thanks to the power of a recursive grep, I've got a list of files and I'm slowly but surely getting the changes ported over.
I have a ways to go before I get a compiling kernel, but there's still one big hurdle to jump after I get all the changes brought in: Wifi.
The stock kernel uses a kernel module, dhd.ko, which appears to be a Broadcom driver. However, I suspect it may be customized/proprietary because the kernel config flag (CONFIG_BROADCOM_WIFI) isn't used anywhere in the source tree. Both the ICS and FroYo kernel sources have code for -other- broadcom drivers, but there may be compatibility issues. I also found a Broadcom driver on googlesource which I suspect was Samsung's starting point for the aforementioned kernel module, but it doesn't come with any instructions for compiling it so I'm not quite sure what to do with it. I'll probably start by just trying to use the kernel's built-in driver and poach the firmware file from the googlesource package, and see what happens.
OK, so a status update--
Using the list of files containing the CONFIG_MACH_GT2 tag as a guide, I went through and modified/ported the code as best seemed to make sense from the Samsung code into the ICS kernel.
Then began the fun of trying to compile the kernel.
The configuration routine wanted to eat my own CONFIG_MACH_GT2 flag, so I had to do a little more hacking to figure out how to modify the kernel configuration files to recognize it as a valid configuration option. For the benefit of others, I'll post the results of my research:
1) Edit arch/arm/tools/mach-types to add the machine type
2) Edit arch/arm/mach-msm/Kconfig to add the configuration option
3) run 'make distclean' to make sure that all the generated stuff gets regenerated properly.
Now it's recognizing the CONFIG_MACH_GT2 option, but one of the modules is failing to build. But, I'm too tired to tackle it right now so it will wait until another day.
It compiles!
... which of course doesn't mean it actually works.. I haven't had a chance to test it yet. Fortunately I have the ODIN files to restore ifwhen something goes horribly wrong.
gblues said:
It compiles!
... which of course doesn't mean it actually works.. I haven't had a chance to test it yet. Fortunately I have the ODIN files to restore ifwhen something goes horribly wrong.
Click to expand...
Click to collapse
Hoorah! Here's hoping it works!
Well, no dice. Stuck at "SAMSUNG" which, admittedly, is better than previous attempts at flashing a custom boot/recovery image (just got a blank screen on those attempts..)
In the process, though, I learned a few important things:
1) To flash any custom firmware, you need Odin 4.40 USA. Newer versions do not work.
2) How you make the .tar.md5 file matters! The files have to be added to the archive in the right order. I determined the order by extracting the stock firmware I acquired from samfirmware.com (using 'tar xvf') and then made sure that I added them in the same order when I created my version. If the files aren't in the correct order, Odin will crash when attempting to flash the phone.
Thank you!
I have been waiting for so long for someone to start something with this phone. I will help in any way I can, if you would like. I am a bit of a newb, but I have done a few things with a Dell streak 7 and an Optimus One, as well as interop unlocking my LG Quantum (a windows phone, but w/e )
I'm another step closer!
After the spectacular failure of my first attempts, I decided to try a smaller step--unpacking the stock boot image, making a useless change (putting "Hello, World!" at the top of /init.rc), packing it back up, and flashing it. When this also failed, I thought perhaps I was working against a locked bootloader.
After finding absolutely no information about the presence of a locked bootloader, and with similar phones not needing any special unlocking, I went a little more basic: what if I unpacked and repacked the boot.img without any changes? I did this, and I was surprised to find that the repacked file didn't match the original at all.
I did a little more research and playing around with mkbootimg, and successfully disassembled and re-assembled the original boot.img file (verified by comparing md5 checksums). I used the same settings to retry my "Hello World" test--and lo and behold, it WORKS!
Nicely done, I knew you could do it!
Awesome job! I can't wait to see how this works out!
Well, unfortunately, it hasn't. While I've been able to modify the contents of the ramdisk cpio, my kernels aren't booting. Or if they are, they're failing before anything useful happens.
Anyway, the trick to creating the boot.img and recovery.img:
The images are in the standard Android format, as documented here. In fact, the unpack-bootimg.pl from that page works brilliantly. However, to re-pack the image, it's best to use mkbootimg directly.
Let's say you've got your gzipped kernel named 'kernel.gz' and the gzipped cpio archive of your ramdisk named 'ramdisk.cpio.gz', and let's say you want your resulting image file to be named 'yourboot.img'. Then you'd use the following command:
Code:
mkbootimg --kernel kernel.gz --ramdisk ramdisk.cpio.gz --base 0x13600000 --pagesize 4096 -o yourboot.img
From further research, it appears that in order to boot a newer kernel than what shipped with it, the boot loaders need to be modified to accommodate it. The reason is that the access to the internal memory partitions is handled by a proprietary Samsung kernel module, which only exists for the kernel the phone shipped with. Even if I had the source for the Samsung module, the boot loader needs to support the newer version of the Samsung module.
So, what I'm going to try next is hacking the kernel to force it to report the same version as the phone expects, and see how spectacularly it fails well it works.
Well, fudging the kernel version in my 2.6.35.7 build didn't work, although just doing a straight compile of Samsung's kernel sources _did_ give me a booting kernel.
Well, the result of my extensive research is thus: there's no hope of getting Gingerbread on this phone without Samsung creating an official release. Here's why, from what I've gathered:
The bootloader does not appear to be locked; however, it does provide some key services that Samsung's proprietary kernel modules use to provide access to the flash partitions on the phone, kind of like the BIOS in your PC. The bootloader expects a specific kernel version (more specifically--and I apologize if the terminology is wrong--a specific kernel ABI). Simply faking the kernel version is not enough--it has to have exactly the same driver interface and kernel entrypoints as it expects. So even though I tried compiling the 2.6.35 kernel with a fake version number, the ABI is still wrong so the phone doesn't boot.
Hacking the boot loader is waaay outside of my skillset, although I did successfully dump it from my wife's busted phone. Judging from the results of my research, it's not something anyone's actually attempted. And given that screwing up the bootloader will hard-brick the phone, I'm not in a mood to experiment.
So basically, since Samsung is the only one with the code for the bootloader and the RFS drivers, it's up to them to create a GB release. Once they actually do so, then possibilities open up quite a bit.
Well you gave it your best shot so thank you! Maybe someone on here will come up with a way to get a non-Froyo version. Hell or even maybe if we're nice enough we'll get upcoming Jumping Jellybean available for this phone.
Thanks so much even for trying. I wish I could try and do something, but I would have no hope.
My sister's likely getting a Galaxy Q tomorrow, so I'll be following dev work on this device a bit.
Skip the RFS format. It's a pain in the neck to work with, and pretty much every benchmark out there shows it's not as fast as ext4 anyway.
Edit: Got another idea: try using the GB RFS kernel modules from the Gio/Ace/Fit/Mini...
If you want to try converting to ext4, make sure you have RFS format dumps of the /data and /cache partitions you can dd back into place in order to restore to stock.
Consider contacting Phiexz (who's sort of left XDA, but should be reachable at his own forum), Delanoister, Maclaw and the rest of the GalaxyICS team. Hyriand too. What they've done for the Gio is nothing short of outstanding.
Good luck,
Darkshado
gblues said:
my kernels aren't booting. Or if they are, they're failing before anything useful happens.
Click to expand...
Click to collapse
No ddms/logcat output, nothing?
Hello.
I noticed that kernels for ubuntu seem a bit old. I was thinking that maybe someone could modify cm10(or 3.0.21) kernel to support ubuntu/teach me how to add ubuntu support to android kernel. I did a bit googling, but results were filled with those loop ubuntus, not native.
I am also thankful if someone can point me to right direction.
(Trevd, i am counting on you )
Sent from my GT-I9100 using xda app-developers app
julle131 said:
Hello.
I noticed that kernels for ubuntu seem a bit old. I was thinking that maybe someone could modify cm10(or 3.0.21) kernel to support ubuntu/teach me how to add ubuntu support to android kernel. I did a bit googling, but results were filled with those loop ubuntus, not native.
I am also thankful if someone can point me to right direction.
(Trevd, i am counting on you )
Sent from my GT-I9100 using xda app-developers app
Click to expand...
Click to collapse
Well as seeing as you ask so nicely, I'm far from an expert however especially in the ways of ubuntu kernels, A1Pha got the original ubuntu image going but ubuntu have done an official arm release now so that changes things ( probably ) I can only point you in the direction of more, hopefully better resources.
The Blaze Tablet seems to have have been the Development Platform for the G9 so you'll probably get some purchase from following that route.
Here's some links for you.
http://omappedia.org/wiki/Source_Trees
http://omappedia.org/wiki/OMAP_Ubuntu_Main
My days on the G9 could well be numbered, I foolishly overwrote the bootlloader in one of my more Laissez-faire moments. meh! That's what I get for having a caliver approach to consumer electronics.
trevd said:
Well as seeing as you ask so nicely, I'm far from an expert however especially in the ways of ubuntu kernels, A1Pha got the original ubuntu image going but ubuntu have done an official arm release now so that changes things ( probably ) I can only point you in the direction of more, hopefully better resources.
The Blaze Tablet seems to have have been the Development Platform for the G9 so you'll probably get some purchase from following that route.
Here's some links for you.
http://omappedia.org/wiki/Source_Trees
http://omappedia.org/wiki/OMAP_Ubuntu_Main
My days on the G9 could well be numbered, I foolishly overwrote the bootlloader in one of my more Laissez-faire moments. meh! That's what I get for having a caliver approach to consumer electronics.
Click to expand...
Click to collapse
Thanks for answering. I'm out of thanks for today, so i press that button when i have more.
Now to business.
After doing some research, and asking few questions on #ubuntu-arm, this seems a bit hard project because there are no sources. There is no source for CM10 kernel(Or i can't read the github) nor Ubuntu kernel, so i can't just apply tweaks of them both to archos 3.0.8+ kernel. A way to unpack the zimage from ubuntu kernel and cm10 kernel would help, but atleast the script i tried couldn't unpack the zimage of ubuntu. Lets see what i figure out next.
julle131 said:
After doing some research, and asking few questions on #ubuntu-arm, this seems a bit hard project because there are no sources. There is no source for CM10 kernel(Or i can't read the github) nor Ubuntu kernel, so i can't just apply tweaks of them both to archos 3.0.8+ kernel. A way to unpack the zimage from ubuntu kernel and cm10 kernel would help, but atleast the script i tried couldn't unpack the zimage of ubuntu. Lets see what i figure out next.
Click to expand...
Click to collapse
Not sure what you mean by the CM10 Kernel, I don't think CM have any different settings from what is required by JellyBean itself. Plus the Kernel we originally used for the Archos CM10 is an ICS kernel with IPV6 Mangling adding, we got away with that because the Init.rc used to boot the Rom is a mashed up ICS Version. After thinking about it let me add the bit of knowledge I think I do know.
The kernels on arm platforms, to paraphrase Linus Tovalds was a complete mess, something which Linaro are working hard to fix, and are unique to the SOC vendor.
You need to get the Archos specific sources which are located on GItorious @ git://gitorious.org/archos/archos-gpl-gen9-kernel-ics.git, clone the 3.0.21 branch, in the directory there's a file called linux.config.g9 ( or something similar ). that's the config file. I just copy that to .config, change the settings I need to (if any) compile. That should setup an archos kernel which should run android
Code:
git clone git://gitorious.org/archos/archos-gpl-gen9-kernel-ics.git -b linux-icc-3.0.21
cp linux.config.g9 .config
make menuconfig
make -j8
Like I say I was thinking about it and the main difference between a standard kernel and android kernels is the binder, the switch class support and the log driver ( this is things I've noticed when building an android x86 Kernel )
When doing menuconfig the Android Driver settings are found in devices/staging/android, I suppose a place to start is to turn them off then switch on SYSV IPC ( i think that's in genral kernel settings ), from what I understand this is the sysv binder and should create a node at /dev/binder, standard kernel switch class support is set in Device Drivers ( Switch Class Support ).
I'm not sure about logging , It basically breaks down like this. The Android Kernel has a specific logging driver this creates device node at /dev/log/main /dev/log/system etc , Ubunutu ( on x86 at least ) has a single log device node which is created at /dev/log, I don't know weather this is something created by the kernel or something created in userspace by syslogd or something similar. I also don't know whether the Android Logs are compatible with ubuntu, or the android binder for that matter. I'll try and boot my x86 ubuntu with my Android Kernel later on , I suspect It won't work but speculation is one thing, knowing for sure is better
With regards to unpacking the zImage, I'll say this , Not all zImages are created equal , I notice you are using a samsung mobile ( galaxy s, if I'm not mistaken ) , so you're probably using the samsung zImage as a frame of reference... How I understand it Samsung pack the initramfs into the zImage, similar, but not same to the way android AOSP pack a boot.img. Samsung however do this in kernel itself, this is why Samsung zImage a) can be unpacked and b) require different tools than the standard tools used for unpacking boot images which work on just about every other device ( expect Archos of course ) . So you generally don't unpack zImage because It's just a binary blob that contains all the kernel functions, this is in the assembly language of whatever architecture you built your kernel for.
Given all that info you should now be able to build a working archos android kernel ( I assume you using linux etc and your not stupid ) , You now need the Ubuntu side of things..... Have you asked in the Archos G9 Ubuntu Development thread, they may be able to shed light on the changes to the config you need to make or alternativaly you could download the Ubuntu for Arm OMAP Image from https://wiki.ubuntu.com/ARM/OMAP , unpack/mount it and see if there is the kernel .config file, It is normally packaged somehow with the distro for example x86 lubuntu has .configs in /lib/modules/3.5.0-19-generic/build/.config, the arm distro may have something similar. Then it's a case of see what configuration options are different, You can't just copy the config whole sale however because there are Archos Specific board settings in the Archos Kernel. Failing that the kernel sources will be somewhere as it is a legal requirement under the GPL and Cannonical are compliant, at least I've not read anywhere to the contrary.
This is just really how I understand it at the minute, Some of it could be inaccurate or just plain BS but hopefully should give you something to run with, there is a bit of a barrier to entry on the whole subject kernels/android kernels as the information is in little pieces all over the internet, when I was first getting to grips with it, it did feel like a bit a of treasure hunt for knowledge. Also knowing the Keywords to search for in the first place can be difficult It sounds quite an interesting challenge, shame about my brick!!
If you want to understand more about the kernel generally ( and lets face it, who doesn't ) then Linux Kernel in a nutshell ( http://www.kroah.com/lkn/ ) is a free e-book written by one of the kernel maintainers a should be a useful reference.
JUST IN CASE: Don't forget prefixing a filename with a fullstop (.) makes that file hidden and won't display in normal file listings, using ls -a to display all file in a directory
The CM10 kernel i was refering to is the CM10 in dev section. I thought there were other "hacks" than just a IPv6 addon, and that's why i counsidered it as a totally diferent kernel.
I think i need to download the kernel source as soons as i get to my laptop then. I have some experience on it, because i have made a few builds of B2G, but that was mainly just: download source, choose the device and build.
For the differences, that is what i consider as the hardest part. Merging them and then getting the kernel to build might take some time. Luckily I have plenty of time.
For the zImage, I was trying to unpack the ubuntu zImage one, because I'm working on archos device . Unpacking Galaxy S2 kernel wouldn't make any sense. atleast to me . I was trying to use a general unpacker, but it didn't work, just as you wrote.
For the OS & Knowledge, i am using linux indeed. Backbox, which is based on ubuntu 11.04 to be precise. I didn't even think about unpacking the IMG file... Maybe i am stupid . I think i am able to mount it to folder, so it is easy to explore.
I think I know the basics, and folders starting with . is part of them
Lets see what happens the next time i pick my laptop, boot it and start fooling around :good:.
Edit: Well, after the menuconfig, i can't fand anything related to ipv6 mangling. There was a file on the root of cloned folder called linux.config, but it was the default config for kernel, not archos specific.
julle131 said:
The CM10 kernel i was refering to is the CM10 in dev section. I thought there were other "hacks" than just a IPv6 addon, and that's why i counsidered it as a totally diferent kernel.
I think i need to download the kernel source as soons as i get to my laptop then. I have some experience on it, because i have made a few builds of B2G, but that was mainly just: download source, choose the device and build.
For the differences, that is what i consider as the hardest part. Merging them and then getting the kernel to build might take some time. Luckily I have plenty of time.
For the zImage, I was trying to unpack the ubuntu zImage one, because I'm working on archos device . Unpacking Galaxy S2 kernel wouldn't make any sense. atleast to me . I was trying to use a general unpacker, but it didn't work, just as you wrote.
For the OS & Knowledge, i am using linux indeed. Backbox, which is based on ubuntu 11.04 to be precise. I didn't even think about unpacking the IMG file... Maybe i am stupid . I think i am able to mount it to folder, so it is easy to explore.
I think I know the basics, and folders starting with . is part of them
Lets see what happens the next time i pick my laptop, boot it and start fooling around :good:.
Click to expand...
Click to collapse
The 3.0.31 Kernel started by Quallenauge in the dev section is an Highly Expirimental effort. this was started before Archos released the 3.0.21 Kernel with their 4.0.2x roms which covered what was trying to be achieved by this development, It's best left alone unless you really want to get you're hands dirty with device bring up code, There's a version on my github which I think boots the G9A101's as well as the 80's......... anyway
You shouldn't have to do any merging of code, more a case of selecting the right options in the config, Thinking back, I've have booted Ubuntu using mainline kernel sources from kernel.org that I built myself so that kinda of suggests there's nothing special about ubuntu's kernels per se' .
Your main problem won't be with building , more booting, It should compile fine but I wouldn't be surprised to be looking at a blank screen then your problem is monitoring the output....There's an option in the archos config to get early debug output over USB, I think there's some modification you need to make to the USB Cable, Quallenauge knows about that, he did it , I was ghetto and used adb for my debugging. which can be probably made to work when booting ubuntu but I'd go the correct route , I just have my wierd ways of doing things.
Another thing that spring to mind with android "specialisms". Android runs /init in the root directory ubuntu normally likes /sbin/init. This is something that is specified again in the kernel config using the kernel cmdline option , just something to be aware of... If anything else springs to mind I'll let you know.
So I suppose as you say, Just fool around and see what happens. :good:
I think I know the basics, and folders starting with . is part of them
Click to expand...
Click to collapse
Just Checking LOL.
trevd said:
The 3.0.31 Kernel started by Quallenauge in the dev section is an Highly Expirimental effort. this was started before Archos released the 3.0.21 Kernel with their 4.0.2x roms which covered what was trying to be achieved by this development, It's best left alone unless you really want to get you're hands dirty with device bring up code, There's a version on my github which I think boots the G9A101's as well as the 80's......... anyway
You shouldn't have to do any merging of code, more a case of selecting the right options in the config, Thinking back, I've have booted Ubuntu using mainline kernel sources from kernel.org that I built myself so that kinda of suggests there's nothing special about ubuntu's kernels per se' .
Your main problem won't be with building , more booting, It should compile fine but I wouldn't be surprised to be looking at a blank screen then your problem is monitoring the output....There's an option in the archos config to get early debug output over USB, I think there's some modification you need to make to the USB Cable, Quallenauge knows about that, he did it , I was ghetto and used adb for my debugging. which can be probably made to work when booting ubuntu but I'd go the correct route , I just have my wierd ways of doing things.
Another thing that spring to mind with android "specialisms". Android runs /init in the root directory ubuntu normally likes /sbin/init. This is something that is specified again in the kernel config using the kernel cmdline option , just something to be aware of... If anything else springs to mind I'll let you know.
So I suppose as you say, Just fool around and see what happens. :good:
Just Checking LOL.
Click to expand...
Click to collapse
At the moment i'm trying to find the archos config file. there is a defcon file, which looks like a config file in arch/arm/configs called android_archos_defcon. It sounds correct. Next thing for me to do is to find the right place to put it. I guess the root of the project is correct, and rename it to .config and linux.config. After building I need to test it. [email protected] or 4.0.26 root will suffice, right? I also need to figure out if there is a way to force adb on through kernel. And the IPv6 Mangling is nowhere to be found
julle131 said:
At the moment i'm trying to find the archos config file. there is a defcon file, which looks like a config file in arch/arm/configs called android_archos_defcon. It sounds correct. Next thing for me to do is to find the right place to put it. I guess the root of the project is correct, and rename it to .config and linux.config. After building I need to test it. [email protected] or 4.0.26 root will suffice, right? I also need to figure out if there is a way to force adb on through kernel. And the IPv6 Mangling is nowhere to be found
Click to expand...
Click to collapse
The config file " linux.config.g9" should be in the root kernel directory, if it's not there then your on the wrong branch and you need to checkout the 3.0.21 branch explicitly using
Code:
git checkout linux-ics-3.0.21
If your using ICS builds to check with, which I probably recommend then don't worry about IPV6 managling , I don't think It's named that exactly but something like that!, For reference , I've just had a check the option is "Networking support/Networking options/Network packet filtering framework (Netfilter)/IPv6: Netfilter Configuration /Packet Managling"
You have to look pretty deep on some of these settings
As a test. Boot with a normal kernel configure your android debug options , then swap the kernels out , that should give you adb while booting, when I've tried to force adb on an uncofigured rom it got a bit confused with itself
If your struggling a bit with git, http://gitimmersion.com/ has a great tutorial you can step through in about 10 minutes to get the basics and get it configured a bit better
---------- Post added at 09:31 PM ---------- Previous post was at 09:20 PM ----------
EDIT: Make sure you building for arm as well
Code:
$ export ARCH=arm
$ export SUBARCH=arm
$ export CROSS_COMPILE=arm-eabi-
Reference: http://source.android.com/source/building-kernels.html
Huuuh i'm late... most had been pointed out already.
Just to add this...
As you might know Android is put on top of a Linux base system more or less.
In most cases a kernel built for Android will suit most linux distributions as well.
Trevd already highlighted the main aspects.
The other way round is more evil... unmodified linux kernel (or a kernel set up to run well with Ubuntu) will refuse to boot up an Android system.
Some addon's on the default config may be nice though, depends on how the whole rootfs stuff is arranged in the end and if your system heavily depends on udev and stuff.
Keep track of the startup scripts at /etc/init.d.
It's good to have an extensive look at the /etc directory of your distribution image... to much to point at here.
The kernel may handle to boot into a lot of different scenarios.
On the Archos tablets initramfs plays an important role.
You may even tweak this jumpboard and locate your final rootfs on an USB stick if you like.
It's all about handling mounts, chroot and similar during start up.
There are limits on the Archos with stock loader though, because you might need to influence the kernel command line at a certain point.
I'm aware that this is not very specific but there are so many ways to set things up.
Just follow the useful links trevd gave already... these are good starting points :fingers-crossed:
...and just to add this:
I don't speak of fine tune the system in the end. This is another story and sometimes very hard stuff, where you may need to reverse engineer some proprietary libs or executables.
Best regards,
scholbert
Well, I have now built my first kernel... And it was 3.0.8+... I think I downloaded wrong source . I have ipv6 mangling enabled on it, so I should try it with CM10 now. I think I should search the 3.0.21 source, and download it.
Edit: Well, my 3.0.8+ Kernel image can boot CM10, AOKP and 4.0.7 roms... Now i have to figure out why i downloaded 3.0.8+ kernel and not 3.0.21 kernel. Maybe i had wrong branch.
Edit:Yep, wrong branch. I did realize when i downloaded the srce that it informed that the branch does not exists. i had icc instead of ics
Do you have any tips where i can find info about kernel modifications, like adding governors? I tried adding few, but all i got was bunch of errors. I propably forgot something.
Sent from my GT-I9100 using xda app-developers app
mer
Still working on this? I have been using Mer kernels with Ubuntu and they seem to be working fine.
Archos Gen9 Mer Adaptation Kernel --> http://gitorious.org/archos-gen9-mer-adaptation-kernel/
Archos Gen9 Mer Adaptation Kernel ICS --> https://gitorious.org/archos-gen9-mer-adaptation-kernel/archos-gen9-mer-adaptation-kernel-ics
I am using the 3.08 kernel from a Plasma Active distribution. --> http://share.basyskom.com/plasma-active/archos_gen9.html
Just mount the data partion in linux and convert it to ext4, write the linux image to it. Then cp the files from mer /boot /lib/modules to new rom, modules file in etc to load your modules, modify fstab, cp mtev.so to /usr/lib/xorg/modules/input, change or add a few other files.
/etc
modules
Code:
cypress_tma340
tr16c0_i2c
hso
compat
cfg80211
mac80211
wl12xx
wl12xx_sdio
cpt_i2c_tsp
pixcir_i2c_tsp
hci_uart
fstab
Code:
/swap none swap sw 0 0
/dev/mmcblk0p2 /media/system ext4 ro,noauto,users,uid=1000,gid=0,noatime 0 0
/dev/mmcblk0p4 /media/data ext4 ro,noauto,users,uid=1000,gid=0,noatime 0 0
none /proc proc rw,relatime,noexec,nosuid,nodev 0 0
none /sys sysfs rw,relatime,noexec,nosuid,nodev 0 0
none /dev devtmpfs rw,mode=0755 0 0
none /dev/pts devpts rw,relatime,gid=5,mode=0620,ptmxmode=0666 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
binfmt_misc /proc/sys/fs/binfmt_misc rw,noexec,nosuid,nodev 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /dev/shm tmpfs nodev,nosuid,noexec 0 0
none /dev/bus/usb usbdevfs defaults 0 0
none /sys/kernel/security securityfs (rw) 0 0
/etc/udev/rules.d
70-persistent-net.rules
Code:
# net device ()
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:28:90:64:31", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
# USB device 0x9710:0x7830 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:3b:04:02:6c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
70-touchscreen.rules
Code:
KERNEL=="event*", SUBSYSTEM=="input", SUBSYSTEMS=="input", ATTRS{name}=="cypress-tma340", SYMLINK="input/touchscreen"
/usr/share/X11/xorg.conf.d
Add to the end of 10-evdev.conf, cypress-tma340 is the touchscreen on my G9.
Code:
Section "InputClass"
Identifier "Archos Touchscreen"
MatchProduct "cypress-tma340"
Option "Ignore" "off"
Option "CorePointer" "on"
Driver "mtev""
EndSection
openSUSE --> http://en.opensuse.org/openSUSE:eek:penSUSE_on_your_ARM_board
Ubuntu --> https://wiki.ubuntu.com/ARM/OMAP
Kubuntu 12.10 --> http://cdimage.ubuntu.com/kubuntu/releases/12.10/release/kubuntu-12.10-desktop-armhf+omap4.img
Please i am using Backbox Linux Distribution (Dual booted ) wit my windows 7....... now i wish to use a dail up connection on my modem !! PLEASE HOW DO I GO ABOUT IT ...
Sent from my L3 using XDA Free mobile app
I just went through the process of compiling a custom ROM and they used a stock kernel. I would like to incorporate a different kernel when I compile and instead of the stock. I know I could compile them separately and have them flash together but I want one zip to flash. Just would like to go through the process to learn.
Any help on how to do this or what I have to do when compiling?'
Thanks.
MAXGEN said:
I just went through the process of compiling a custom ROM and they used a stock kernel. I would like to incorporate a different kernel when I compile and instead of the stock. I know I could compile them separately and have them flash together but I want one zip to flash. Just would like to go through the process to learn.
Any help on how to do this or what I have to do when compiling?'
Thanks.
Click to expand...
Click to collapse
One of the easiest ways of doing this would be to take the boot.img thats contains the custom kernel you want and deleting the stock boot.img containing the stock kernel in your .zip file and replacing that with the boot.img of the custom kernel. Essentially you are just swapping the boot.img file in the .zip files with the one containing the custom kernel rather then the stock kernel. Let me know if you need me to explain things further or have any other questions I'll be happy to help you out.
shimp208 said:
One of the easiest ways of doing this would be to take the boot.img thats contains the custom kernel you want and deleting the stock boot.img containing the stock kernel in your .zip file and replacing that with the boot.img of the custom kernel. Essentially you are just swapping the boot.img file in the .zip files with the one containing the custom kernel rather then the stock kernel. Let me know if you need me to explain things further or have any other questions I'll be happy to help you out.
Click to expand...
Click to collapse
Thanks for the response.
I have to first compile the custom kernel then it seems like an easy process after that. I'm going to try to compile Franco kernel for nexus 5 if u heard of it. Its been pretty good for me.
Any tips for compiling another project or Franco kernel would be great!? I will make a separate folder for that kernel git project and compile it there.
I also want to use tool chain like Linaro and maybe Sabermod but those are for nexus 4, maybe I can port it over.
MAXGEN said:
Thanks for the response.
I have to first compile the custom kernel then it seems like an easy process after that. I'm going to try to compile Franco kernel for nexus 5 if u heard of it. Its been pretty good for me.
Any tips for compiling another project or Franco kernel would be great!? I will make a separate folder for that kernel git project and compile it there.
I also want to use tool chain like Linaro and maybe Sabermod but those are for nexus 4, maybe I can port it over.
Click to expand...
Click to collapse
Franco kernel is an excellent kernel can't really go wrong with it. On your other note, Linaro is not Android device specific it can be used to compile kernels for a plethora of devices, I would recommend taking a look at this great guide on how to use Linaro to compile your kernel and how to customize the Linaro toolchain to suit your needs.
shimp208 said:
Franco kernel is an excellent kernel can't really go wrong with it. On your other note, Linaro is not Android device specific it can be used to compile kernels for a plethora of devices, I would recommend taking a look at this great guide on how to use Linaro to compile your kernel and how to customize the Linaro toolchain to suit your needs.
Click to expand...
Click to collapse
So I tried following the post. Just not sure about a lot of things and got confused and couldn't compile.
So what I'm trying first before I use the LInaro tool chain is to try to compile the Franco kernel without it. I clone Franco hammerhead git and link the arm-eabi-4.6 toolkit
make hammerhead_defconf
make -j7
Seem to compile with no errors, took a minute though which seems quick but not sure where it exported to.
Tried looking in the arch/arm/boot/ but no look.
I want compile a boot.img as well.
MAXGEN said:
So I tried following the post. Just not sure about a lot of things and got confused and couldn't compile.
So what I'm trying first before I use the LInaro tool chain is to try to compile the Franco kernel without it. I clone Franco hammerhead git and link the arm-eabi-4.6 toolkit
make hammerhead_defconf
make -j7
Seem to compile with no errors, took a minute though which seems quick but not sure where it exported to.
Tried looking in the arch/arm/boot/ but no look.
I want compile a boot.img as well.
Click to expand...
Click to collapse
I would recommend trying the following procedure:
Code:
mkdir franco
cd franco
git clone https://github.com/franciscofranco/hammerhead.git
After the clone operation completes rename the cloned folder to hammerhead or make sure it named hammerhead.
Now make sure your are in the franco folder you created and run the following commands:
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
export PATH=$(pwd)/arm-eabi-4.6/bin:$PATH
export ARCH=arm
export SUBARCH=arm
export CROSS_COMPILE=arm-eabi-
cd hammerhead
make hammerhead_defconfig
make -j4
Once it finishes this you should now have a zimage outputted in the path arch/arm/boot/zImage. To make the process of putting your zimage and module together run the following commands:
Code:
mkdir ~/franco/kernel_output
cp ~/franco/hammerhead/arch/arm/boot/zImage ~/franco/kernel_output/zImage
find ~/franco/hammerhead -name "*.ko" -exec cp {} ~/franco/kernel_output \; (You may have to run the command without the ";")
You should now have everything you need to make a boot.img. Let me know how it goes and if you still have questions.
Thanks for your help, W-XC (curious what that means and you have flying shoe is it because you run? You running in the next Boston Marathon?)
The kernel is actually using 4.7 so I just used the right git. I also found out it wasn't compiling because there was any error in that specific driver for CPU governor. The dev actually was about to push a fix and supposedly it will be push tomorrow but shared the commit so I was able to make the fix manually. Either case it compiles now. Working on step 2 which is to compile into the ROM.
I was curious you seem to know your stuff. Are you kernel dev? How did you gain your knowledge? I wanna learn more about Android OS and linux kernel? I taken basic OS classes in college so a lot of introduction to concepts but nothing on coding it though. Any books or anything you can recommend on any of these areas or anything closely related worth knowing? Thanks again.
For making a boot.img I tried the following. What would you suggest for mkbootimg?
I used this script to get my ramdisk.
http://www.enck.org/tools.html
But I'm little confused on where do you get the script for mkbootimg?
Is it from the android source or is it generated when you build the kernel or is it some script that someone made?
I found this posting for building a kernel with mkbootimg but the dilemmaI"m no having is what is correct commands for building.
http://www.droidforums.net/forum/rescue-squad-guides/31452-how-compile-your-own-kernel.html
The dev mention some commands in a posting several months ago.
http://forum.xda-developers.com/showpost.php?p=47167725&postcount=291
That might be a way to go but the argument doesn't take with the mkbootimg from the droid forums. Syntax is not right so it makes me think that mkbootimg is unique.
MAXGEN said:
Thanks for your help, W-XC (curious what that means and you have flying shoe is it because you run? You running in the next Boston Marathon?)
The kernel is actually using 4.7 so I just used the right git. I also found out it wasn't compiling because there was any error in that specific driver for CPU governor. The dev actually was about to push a fix and supposedly it will be push tomorrow but shared the commit so I was able to make the fix manually. Either case it compiles now. Working on step 2 which is to compile into the ROM.
I was curious you seem to know your stuff. Are you kernel dev? How did you gain your knowledge? I wanna learn more about Android OS and linux kernel? I taken basic OS classes in college so a lot of introduction to concepts but nothing on coding it though. Any books or anything you can recommend on any of these areas or anything closely related worth knowing? Thanks again.
Click to expand...
Click to collapse
MAXGEN said:
For making a boot.img I tried the following. What would you suggest for mkbootimg?
I used this script to get my ramdisk.
http://www.enck.org/tools.html
But I'm little confused on where do you get the script for mkbootimg?
Is it from the android source or is it generated when you build the kernel or is it some script that someone made?
I found this posting for building a kernel with mkbootimg but the dilemmaI"m no having is what is correct commands for building.
http://www.droidforums.net/forum/rescue-squad-guides/31452-how-compile-your-own-kernel.html
The dev mention some commands in a posting several months ago.
http://forum.xda-developers.com/showpost.php?p=47167725&postcount=291
That might be a way to go but the argument doesn't take with the mkbootimg from the droid forums. Syntax is not right so it makes me think that mkbootimg is unique.
Click to expand...
Click to collapse
The W-XC in my avatar stands for Watertown Cross-Country which is the team I used to run on and the flying shoe with the track wings represents our track team, as I love to run I thought it was a fitting avatar. As far as running the Boston marathon I am not running this year but I would love to someday, I am unfortunately not in good enough form to run a marathon right now due to a prolonged battle with an injury I sustained last spring, but I'll keep training and keeping running!
I'm glad you were able to make the fix on the kernel, often times errors that seem to pop out of nowhere are related to fixes not being pushed to the repository you were syncing and using to build at the time. Thank you for the nice compliment it is greatly appreciated, I am not a kernel developer just an overall aspiring developer who loves everything Android related and trying to contribute and help others however I can. I would say 99% of my knowledge of everything Android related has come from XDA and hours upon hours of Googling things related to kernel development, reading about something not understanding something then Googling the parts I didn't understand, piecing together things then Googling more things to help me understand, after a while you slowly start putting the pieces of knowledge together as you learn more and then you still keep learning. For resources on learning kernel development I would recommend learning the C programming language as it is the building block of kernel development. A great resource for learning C is the free online e-book Learn C The Hard Way. Another critical element of understanding Android kernel development is the Linux Kernel and it's drivers which is why I would recommend taking a look at Linux Device Driver's Third Edition, while parts of it are outdated the fundamental concepts are still very much applicable. As far as pure Android Kernel aspects and Linux Kernel aspects go the free-electrons group has some invaluable presentations that cover these subjects as well as other critical areas of embedded development that relate to kernels.
For the mkbootimg binary I would recommend downloading these unpack, repack, ramdisk tools. They have proven invaluable for me when working with img files and kernels. Download the scripts and binaries and put them in your ~/bin folder and make sure to give them the proper permissions that way they will be in your path and you can use them properly. Once you have them installed I would recommend obtaining a copy of the Nexus 5's latest boot.img (The factory images Google Provides should have it in the images .zip file included in the factory image). After doing that decompile the stock boot.img file using the umkbootimg binary, this should present you with an output of a ramdisk and a zimage. Next, take the zimage you compiled with the franco kernel source and replace the stock boot.img zimage with the zimage you compiled from franco kernel. Then run the mkbootimg binary with command (In terminal it should give you the command to easily re-pack the boot.img) to re-pack your new boot.img. The output of the new boot.img will have the default name new_boot.img or similar name. Re-name this file to boot.img and delete the old boot.img from your .zip file of your ROM and swap in the boot.img file you just created. You have now included the custom kernel you wanted in your ROM.
As always let me know if you still have questions I'll be happy to answer them :good:.
Thank you so much!!! Probably going to have to take some time to digest everything but definitely will have more questions when I'm done.
Quick question, do you have see "C" being replace? I have read some C code but haven't not yet coded anything in C. I been told that low level access you get with C is not comparable with other languages. I guess you would have to go to ASM to get even more access. ASM personally I run from it, probably should do more of it for practice. We do a lot of high level language C++, java, python and some others in school but no C. I probably can't avoid not being comfortable in it? C is not going to be replace by anything in future??
MAXGEN said:
Thank you so much!!! Probably going to have to take some time to digest everything but definitely will have more questions when I'm done.
Quick question, do you have see "C" being replace? I have read some C code but haven't not yet coded anything in C. I been told that low level access you get with C is not comparable with other languages. I guess you would have to go to ASM to get even more access. ASM personally I run from it, probably should do more of it for practice. We do a lot of high level language C++, java, python and some others in school but no C. I probably can't avoid not being comfortable in it? C is not going to be replace by anything in future??
Click to expand...
Click to collapse
You are correct in that to get even more low level access you start getting into assembly territory. What makes assembly difficult and what makes people from run form it is unlike very high level languages such as Python, Java, etc. it is much less human readable and a lot closer to machine language (Binary code), however like anything practice makes perfect the more you practice with a language the easier things get and the more confidence you have in programming things with it. If you really want to customize and develop kernels C is a must there is no getting around that unfortunately. As far as C being replaced with anything in the future, will it ever be replaced, probably as is the case with technology, but as far as it being replaced with anything equivalent or better in the next 10-20 years I doubt it, as it would take years to develop a new standard and even longer to be adopted and standardized to the point C is used and accepted today.
I have a few devices lying around; Optimus One-KitKat, Nexus 4-Lollipop 5.1.1, Nexus 5-N/A(waiting on digitizer) and a Zenpad 10-Lollipop 5.0.1.
I'm looking to add wifi driver(s) to the kernel of one, or all of them.. but I'm not sure where even to start.
I have Android Studio installed on Windows, I've got a Kali Boot laptop.
I can install anything on either that are required, I'm assuming the Kali would be best suited.
If you guys could get me started with something base.. like source files? I'm more than willing to attempt this mission myself...
Maybe come back here with small questions or "Ohshi- I broke it, what do I do?!"(honestly don't think that'd happen, but you never know)
Right now, all I'm looking for is what I need to install, and where I can find source files and such.
Please and thank you guys.
Edit: Currently my mission is to take a driver's .bin from linux and change it to .ko or equivalent for android so I can insert it in and have my external dongle work... any ideas?
Edit2: Turns out I can't do it that way, But now I've got the Source for both Kernels. My Tablet, and the Linux I'm running with the drivers built into it. So I have access to the drivers themselves. I'm just trying to figure out how to recompile them for Android.
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
lionclaw said:
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
Click to expand...
Click to collapse
Wayyyy out of my area of expertise, but here's my (completely novice) best guess.
>All Chromebooks are write-protected with a screw on the motherboard
>Putting a Chromebook in developer mode allows for some tinkering ie things like chroots, and on the asus flip, the ability to install apks from unknown sources.
>Unscrewing the write-protect screw allows for the ability to completely install a new operating system or dual boot setup.
>Maybe you need to do that before you're able to accomplish root access?
My other idea would be to try and figure out a way of doing a systemless root?
Also, total aside but since this is the only thread I've found on XDA about this device, I think chroots are theoretically possible now without the need to be in developer mode via Android apps (even without root on Android). Download the GIMP port from the Play Store to see what I'm talking about. Playing around with that for a few minutes really made me wish that it didn't use emulated mouse/keyboard in it's implementation. Also, it appears that apt-get is broken, but regardless it might interest someone out there looking for a project.
back from the dead, any progress on this?
I have been able to successfully root the Android image on my Asus Flip.
I built a blank image with dd in /usr/local, formatted it with mkfs, mounted it to a folder, mounted the original system.raw.img to a folder, copied the files across, placed *all* the SuperSU files listed as 'required' in the SuperSU update-binary in the relevant places in /system in my new image, set permissions & contexts for those files, edited arc-system-mount.conf and arc-ureadahead.conf to point to the new image and, finally, patched /etc/selinux/arc/policy/policy.30 with the SuperSU sepolicy patching tool in order to boot my rooted Android instance with selinux set to enforcing.
I have created a couple of scripts which more-or-less fully automate this procedure, which can be downloaded from nolirium.blogspot.com. Please feel free to download, open the scripts in a text editor to check them out, and try them out if you like. Only tested on Asus Flip, though.
I seem to be unable to post attachments at the moment so I will just add the descriptions here, I could probably post the entire scripts here too if anyone wants. Feel free to let me know what you think.
DESCRIPTIONS:
1-3.sh
Combines the first three scripts listed below.
01Makecontainer.sh
Creates an 900MB filesystem image in /usr/local/Android_Images, formats it, then copies Android system files therein.
02Editconf.sh
Modifies two system files: arc-system-mount.conf - changing the mount-as-read-only flag and replacing the Android system image location with a new location; and arc-ureadahead.conf - again replacing the Android system image location. Originals are renamed .old - copies of which are also placed in /usr/local/Backup.
03Androidroot.sh
Mounts the previously created Android filesystem image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary.
04SEpatch.sh
Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location. A copy of the original policy.30 is saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old
Uninstall.sh
Removes the folder /usr/local/Android_Images and attempts to restore the modified system files arc-system-mount.conf and arc-ureadahead.conf.
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
keithkaaos said:
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
Click to expand...
Click to collapse
The R13 has a 64-bit Mediatek processor, right?
I have added a version for ARM64, but I haven't tested it.
You can find the instructions and scripts at nolirium.blogspot.com
ya, its a mediatek. and thanks ill go see if i can find it
---------- Post added at 03:31 AM ---------- Previous post was at 02:58 AM ----------
wow, ok. i can do this but im not sure i want to.. after reading the possible problems i may run into. Im going to be getting the G. Home in a couple weeks and i gotta keep things running smooth. This seems like going a tad too far then i need to. The other day i had action launcher going and it looked pretty damn good but i really want to try and get the action3.apk that i have put into the pri-app folder or whatever the chromebook uses i found the syst folder but cant access it. Im wondering if i make the machine writable it would work but im afraid of losing my updates, as long as i could do them manualy, i guess that would be cool. Also since im already going on... has anyone found a way to disable the dev boot screen without tinkering with the physical chromebook yet?
SuperSU on Chromebook
Hey there I love this post but unfortunately im on the mediatek (well not unfortunately cause i love it) but i do really want super su .. But i found this other post that i tried out but i am having a problem executing the scripts. When i go to run the first one, it says can not open "name of script" but the dev takes a pretty cool approach. Im still new to Chrome OS but thanks for the post and if you have any advice on executing scripts id love to hear it!! http://nolirium.blogspot.com/
I'm guessing the above post was moved from another thread...
Anyway, it turns out that zipping/unzipping the files in Chrome OS's file manager sets all the permissions to read-only. Apologies! sudo chmod+x *scriptname* should fix it...
Regarding OS updates, I actually haven't had a problem receiving auto-updates with software write-protect switched off; the main possible potential issue I could imagine arising from the procedure I outlined would involve restoring the original conf files if both sets of backups get deleted/overwritten. This seems unlikely, but in that case either manually editing the files to insert the original string (/opt/google/containers/android/system.raw.img), or doing a powerwash with forced update might be necessary in order to get the original Android container booting again.
I don't think anyone's found a way to shorten/disable the dev boot screen without removing the hardware write-protect screw - from what I've read, the flags are set in a part of the firmware which is essentially read-only unless the screw is removed. Perhaps at some point the Chrome OS devs will get fed up of reading reports from users whose relatives accidentally reset the device by pressing spacebar, and change the setup. Here's hoping.
Hey just jumpig in the thread right quick to see if these instructions are old or what-- got a chromebook pro and the notion of having to update a squashed filesystem every timeto install su seems like a pain..
Is there any kind of authoritative documentation/breakdown regarding what Chromeos is mounting where before I start breaking things? Also anyone happen to know if there's a write-protect screw anywhere in the chromebook plus/pro?
Other questions:
* adbd is running, but is not accessible from adb in the (linux) shell, which shows no devices. Do I need to access adb from another device (i'm short a usb c cable right now) or can I use adb (which is there!) on the chrome side to access adbd on the android side?
* Anyone know if adb via tcp/ip is available? Don't see it in the android settings.
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
I'll attach them to this post in case anyone wants to take a look. There's a readme in the zip, some more details can also be found here and below
EDIT: Fixed the SE Linux issue occurring with the previous version I uploaded (it was launching daemonsu from u:r:init:s0 instead of u:r:supersu:s0).
Anyone considering giving them a spin should bear in mind that the method does involve creating a fairly large file on the device as a rooted copy of the android rootfs. (1GB for arm, 1.4GB for Intel). There's a readme in the zip but the other couple of important points are that:
a) The SuperSU 2.82 SR1 zip also needs to be downloaded and extracted to ~/Downloads on the Chromebook.
b) Rootfs verification needs to be off. The command to force this is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
or the regular command to do it is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
c) If, subsequent to running the scripts, there's a problem loading Android apps (e.g. after a powerwash or failed install), the command to restore the original rootfs image is:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Hey this is a great response.. thanks!
Nolirum said:
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
Click to expand...
Click to collapse
verity
Yeah playing with it now, I'm looking at these /etc/init/arc-*-conf files... I see that the /dev/loop# files are being set up... (more below)
Nolirum said:
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
Click to expand...
Click to collapse
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is? (update: I guess that's what rootfs verification does, and we can turn it off....)
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Nolirum said:
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
Click to expand...
Click to collapse
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Nolirum said:
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Click to expand...
Click to collapse
Heh.. not gonna be me..
Nolirum said:
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
Click to expand...
Click to collapse
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon... btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example... would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default witho no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Nolirum said:
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
Click to expand...
Click to collapse
Cool I'll take a look at these scripts.
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
fattire said:
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
Click to expand...
Click to collapse
Oh, the arc-setup-env thing is intentional. There does appear to be another issue with the x86 version though. I've written up a detailed response to your previous post; it's in a text file at the moment so I'll copy it over and format it for posting here with quotes etc now - should only take a few minutes. Yeah, sticking them on github might be a good idea; I've been meaning to create an account over there anyway.
Yeah, so... Regarding the scripts, since I've put them up here for people to download - I should mention that the first person to test them (aside from me) has reported that something's not working right (I'm waiting for confirmation but I think he tried out the x86 version). It's likely either an error on my part when copying across from my Arm version, or perhaps something not working right with conditionals, meant to deal with the various OS versions ('if; then' statements, I mean). Once I find out more, I'll edit my earlier post...
fattire said:
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is?
Click to expand...
Click to collapse
Oh, sorry for being a bit vague - I just mean perhaps implementing a kind of systemless root à la Magisk/SuperSU (from what I understand of how these work) - avoiding the need to actually replace files in /system. Since I'm mainly just using su for the privileges rather than actually wanting to write to /system, I had the idea that perhaps a sort of overlay on e.g. xbin and a few other locations, rather than actually rebuilding the whole of /system, might be an interesting approach....
Yep, I've been replacing /opt/google/containers/android/system.raw.img with a symlink to my modified image lately. Works fine... I think they've been focused on just getting the apps working properly, maybe something like dm-verity is still to come.
Although, one of the cool things with Chromebooks IMO is that once the Developer Mode (virtual) switch has been flipped, the system's pretty open to being hacked around with. I think a large part of the much-trumpeted "security" of the system is thanks to the regular mode/Dev mode feature, once in Dev Mode with verified boot disabled on the rootfs, we can pretty much do what we want (I like the message that comes up in the shell when entering the first command I posted under the spoiler - it literally says "YOU ARE ON YOUR OWN!").
So yeah, with Dev Mode switched off, verified boot switched on, we can't even get into the shell (just the walled-off 'crosh' prompt), making the system indeed rather secure (but, for some of us, rather limited).
fattire said:
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Click to expand...
Click to collapse
That's what I mean by a moving target, lol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61. Problems with being on the more 'bleeding edge' channels include:
#Sometimes stuff gets broken as they commit experimental changes.
#Any updates sometimes overwrite rootfs customizations; the higher the channel - the more frequent the updates occur.
#Some of the stuff that gets updated, may later get reverted.
And so on...
fattire said:
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Click to expand...
Click to collapse
Yeah you'd think so. Honestly, the more I use CrOS the more it seems like a (very polished) work-in-progress to me. Though, I guess most modern OSs are also works-in-progress though. (I don't mean the former statement in a critical way; I'm very happy that new features keep getting added to the OS - Android app support being a perfect case in point, that was a lovely surprise, greatly extending the functionality of my Chromebook).
fattire said:
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon...
Click to expand...
Click to collapse
Netcat's not there but socat, which I haven't any experience with but have seen described as a "more advanced version of netcat", is listed in /etc/portage/make.profile/package.installable, meaning that adding it to CrOS is supported, and as simple as:
Code:
sudo su -
dev_install #(sets up portage in /usr/local)
emerge socat
I tried socat out and it seems to work, might be interesting to play around with.
fattire said:
btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example...
Click to expand...
Click to collapse
Theres a question. I forget some of the exact details now (gleaned from browsing the developer mailing lists and the documentation on chromium.org), but from what I do remember and my experiences tinkering, I can say:
The auto-update model uses kernel/rootfs pairs, e.g. at the moment my device is booting from partition 2 (KERN-A) with the rootfs being partition 3 (ROOTFS-B). My understanding is that with the next OS update pushed to my device, CrOS will download the deltas of the files to be changed, and apply the changes to partitions 4 and 5 (KERN-B and ROOTS-B), setting new kernel GPT flags (priority=, tries=, successful=), which will, post-reboot, let the BIOS know that 4 and 5 will form the new working kernel/rootfs pair. Then the following update will do the same, but with partitions 2 and 3, and so on and so forth, alternating pairs each time. It's a pretty nifty system, and I think something similar might be happening with new Android devices from version O onward (?).
So partitions 2,3,4,5 are fair game for being overwritten (from the perspective of the CrOS updater program). Partition 1, the 'stateful partition') is a bit special, in addition to a big old encrypted file containing all of the userdata (/home/chronos/ dir?), it also has some extra dirs which get overlaid on the rootfs at boot. If you have a look in /mnt/stateful/, there should also be a dir called 'dev_image', which (on a device in Dev mode) gets mounted up over /usr/local/ at boot. As I mentioned above, if you do
Code:
sudo su -
dev_install
you can then emerge anything listed in /etc/portage/make.profile/package.installable (not a great deal of stuff admittedly, compared to Gentoo), which gets installed to subdirs in /usr/local/. So I think stuff in partition 1; /mnt/stateful/, should be safe from being overwritten with an OS update. I think crouton chroots get put there by default.
Most of the other partitions don't really get used, and shouldn't get touched by the updater, here's a design doc on the disk format, and here's a Reddit post (from a Google/Chromium employee) mentioning dual booting from partitions 6 and 7.
fattire said:
would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
Click to expand...
Click to collapse
It's not too hard to mess up the system and get it into an unbootable state, lol. The "powerwash" just seems to remove user data, mainly. If you change up (the contents of) some files in /etc, or /opt, for example, then powerwash, normally they won't get restored to their original state (unless you also change release channel).
But, as long as the write-protect screw's not been removed and the original BIOS overwritten, it's always possible to make a recovery USB in Chrome's Recovery Utility on another device, and then restore the entire disk image fresh (this does overwrite all partitions). Another thing that I did was make a usb to boot into Kali; I was experimenting with the cgpt flags on my internal drive and got it into an unbootable state, but was still able to boot into Kali with Ctrl+U, and restore the flags manually from there. (To successfully boot from USB, it was essential to have previously run the enable_dev_usb_boot or crossystem dev_boot_usb=1 command in CrOS). I understand also that the BIOS type varies with device release date and CPU architecture, and that Intel devices may have some extra potential BIOS options ('legacy boot').
fattire said:
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default with no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Click to expand...
Click to collapse
I think I saw something related to this on the bug tracker. If I come across any info, I'll let you know...
fattire said:
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Click to expand...
Click to collapse
Yeah, I haven't built Chromium OS or anything, but apparently, there's an option to create a 'private' overlay for the build, which doesn't get synced with the public stuff.
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
"That article is a little misleading in terms of open source. While the wayland-server and services that communicate with the ARC++ container are open source, the actual ARC++ container is not."
Perhaps they're waiting to see how similar implementations of Android within a larger Linux setup (e.g. Anbox) fare.
There doesn't seem to be too much that differs from AOSP in the ARC++ container - a few binaries and bits and pieces linking the hardware to the container (e.g. the camera etc), maybe some stuff related to running in a container with the graphics being piped out to Wayland?, and so on.
Oh, I was searching the bug tracker for something else, and just saw this (quoted below). Looks like it might be possible to run AOSP based images on CrOS soon!
arc: Implement android settings link for AOSP image
Reported by [email protected], Today (72 minutes ago)
Status: Started
Pri: 1
Type: Bug
M-60
When ARC started without the Play Store support there is no way for user to activate Android settings. We need implement corresponded section that has
Title: Android settings:
Link: Manage android preferences:
Inner bug: b/62945384
Click to expand...
Click to collapse
Great response! I read it once and I'll read it again in more detail then will probably have questions For whatever it may be worth, my only experience with chromiumos was building the whole thing maybe 4 years ago for my original 2011 Samsung "snow" Chromebook-- and making a bootable USB (or was it an SDcard?) to run it on (with a modified firmware that did... something I can't remember.. i think it was basically a stripped down uboot and I remember adding a simple menu or something-- I think I was trying to bypass that white startupscreen or something..). However, after doing this a few times to play with it, I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
I did have it re-partitioned to run linux as a dual boot from the SD slot or something-- I remember using that cgpt thing to select the different boot modes and vaguely recall the way it would A/B the updates (which "O" is now doing)... but anyhoo I was using the armhf ubuntu releases with the native kernel and ran into all kinds of sound issues and framebuffer only was a little crappy so...
I'm gonna re-read in more detail soon and I'm sure I'll have questions-- one of which will be-- assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
ol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61.
Click to expand...
Click to collapse
This is the -env file I'm missing, I presume?
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
Click to expand...
Click to collapse
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
* what else... I dunno watch this space.
An update from a couple of guys that have tested out the scripts on Intel: It seems to be that while they are able to launch daemonsu manually (with daemonsu --auto-daemon), it apparently does not seem to be getting launched at boot.
I am waiting for some more information on this. Previously, for Marshmallow, the script was setting up the app_process hijack method in order to to launch daemonsu at boot; to support Nougat I changed it to instead create an .rc file with a service for daemonsu, and add a line to init.rc importing it. This works for me, and from what I can gather, it copied/created all files successfully on the testers devices, too, so I'm not sure at this point what the issue is there.
Edit: Fixed the issue. I updated my previous post with further details.
fattire said:
I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
Click to expand...
Click to collapse
lol yeah. True, that.
fattire said:
...assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
Click to expand...
Click to collapse
It's literally just two things that differ: the few lines where we copy the su binary over e.g.
/x86/su.pie → /system/xbin/su, daemonsu, sugote
vs
/armv7/su → /system/xbin/su, daemonsu, sugote
...and also the size of the created container. The x86 container is about 30 percent larger than the Arm one.
I had a little look at how to determine the CPU architecture programmatically on Chrome OS a while back, but couldn't seem to find a reliable way of doing this, at least not without maybe getting a bunch of people with different CrOS devices to run something like, as you mentioned, uname -i (which returns 'Rockchip' on my device, uname -m (which returns 'armv7'), or such similar, and collating the results. It was just easier to do separate versions for x86/arm, rather than introduce more conditionals (with potential for errors). I'm certainly not averse to adding a check for $ARCH, and thus standardizing the script, as long as it's reliable.
fattire said:
This is the -env file I'm missing, I presume?
Click to expand...
Click to collapse
Yep! It's just the same few envs as in the .confs, moved into a new file. I'm fairly confident that the script's conditionals deals with them OK.
fattire said:
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Click to expand...
Click to collapse
Yeah, although the respondant there perhaps doesn't seem to realise that he's talking to a Google/Chromium dev, the way he responds. Not that that makes anything he says in his post is necessarily less valid, though.
fattire said:
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
Click to expand...
Click to collapse
Interesting... I agree, those would both be useful additions to the functionality of ARC++...
Quick question-- has Samsung provided the source for the GPL components (including the kernel, obviously)? I looked here but didn't see anything...? Previously the kernel was included along with the chromium source and there was like a kernel and kernel-next repository.. but this was like five years ago. I think the codename for the samsung chromebook pro is called caroline... let me quickly see if I can find a defconfig in the chromium source...
Back.. nothing here in the chromeos-4.4 branch. Nothing here either in the master branch. Maybe I'm looking in the wrong branches-- master is probably mainline kernel. Also the directories.. it took me five minutes to realize it wasn't going to be in arch/arm - force of habit I guess. I'll keep looking unless anyone knows. This "chromium-container-vm-x86" one seems to have dm_verity as an unused option. Ah, this is looking promising.
...and... here!
So it would seem that this would be built as part of the chromiumos build system, which seemed to be half gentoo five years ago building out of a chroot and was kind of a pain to set up... still, I'm guessing that since it's got that weird script to make the defconfig, what you could do is use google's chromiumos build script to make the kernel image (with whatever changes you want), then, assuming that it doesn't care if you replace the kernel, just throw it over the right Kernel A/B partition and see if it boots and starts up chromeos... it's weird cuz the kernel has to do double-duty for chromeos and android.. but I bet you can just replace it and it would work fine...
I had a cursory go at building a couple of kernel modules for my Flip C100 a while back - I didn't get too far though, lol. People do seem to have had success building their own kernels and running them with Chrome OS though, as with most things I suppose it's just how much time/effort you're willing to put in.
I think I used this and maybe this, from the crouton project to guide me.
From what I remember, I just got fed up of all the arcane errors/config choices. I remember that even though I'd imported my current device config from modprobe configs, there were then such an incredibly long string of hoops/config choices to have to go through one by one, to then be confronted with various errors (different every time ISTR) that I think I just thought "screw this". I think there were some other issue with the Ubuntu version I was using at the time as well. I know that sort of stuff's kind of par for the course with kernel compilation, but I was mainly only doing it so I could edit xpad in order to get my joypad working, in the end I found a different solution.
It shouldn't be too much hassle though, in theory I guess.... Oh, also, in order to get a freshly built kernel booting up with the CrOS rootfs, in addition to the gpt flags, I think you might have to sign it, too? (just with the devkeys & vbutil_kernel tool provided on the rootfs), some info here, and here.
From what I remember, the build system would do whatever key signing was necessary.... although I do now remember you're right there was some manual step when I was building the kernel, but I can't remember if that's because of MY changes or that was just part of the build process.
I I just dug out the old VM (Xubuntu) I was using to build and, well, let's just say I'll be doing a LOT of ubuntu updates before I can even realistically look at this. I do kinda recall setting up the environment was a huge pain so I'm going to see if I can just update the 5 year old source, target the pro and just build the kernel image and see what pops out the other end. At least I won't have to deal with the cross compiler, though I think it should hopefully take care of that itself.
Interesting to see that those crouton projects have emerged (no pun intended) so I'll check them out too while ubuntu updates itself
Thanks for the github links.. I'm going to go read that wiki.
Update: Looked at it-- funny they just stripped out the chromeos-specific parts they needed rather than emerge everything which is smart. My only question is now that Android is involved, there's that script I linked to earlier that seems to say "if you want Android support you'll need these bits too"-- wonder if the same config scripts apply, and if there are any other device tree considerations as well...
I may play a bit and see how smoothly it goes.. Unfortunately I don't have unlimited time either :/
Also, please do let me know if you put the scripts on github and I can send you pull requests if I come up with anything.
Update: Finally updated like 3 major versions of ubuntu... the "depot_tools" repo had its last commit in 2013, so I updated that. Wow, this is so much clearer than previous docs... it looks like something called gclient is used now, which I configured with:
gclient config --spec 'solutions = [
{
"url": "https://chromium.googlesource.com/chromium/src.git",
"managed": False,
"name": "src",
"deps_file": ".DEPS.git",
"custom_deps": {},
},
]
'
that let me do gclient sync --nohooks --no-history ...which i think is updating the ancient source. I probably should have just started over, but anyway... we'll see what happens.
Update again: After updating with this new gclinet tool, it appears that the old repo sync method is still required as described here. That hasn't changed after all, so now I'm going to go through this old method, which will probably completely overwhelm my storage as it's downloading with history.. but anyway, in case anyone is trying this-- looks like the whole chroot/repo sync thing may still be how it's done... the /src directory described above may only be for building just the browser, not the whole OS...
...and here it is. I will have zero room to actually build anything tho, but hey.
* [new branch] release-R58-9334.B-caroline-chromeos-3.18 -> cros/release-R58-9334.B-caroline-chromeos-3.18
Note to self: use cros_sdk --enter to actually get in the chroot. Then:
~/trunk/src/scripts $ ./setup_board --board=caroline
to set up the build for caroline. Then to build:
./build_packages --board=caroline --nowithdebug
Useful links:
* Building ChromiumOS
* [URL="http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq"]eBuild FAQ
[/URL]