OK, I am starting this thread for a general discussion related to some development work I am currently doing. It involves some fairly low level components of the Android architecture.
I am basing this on CM9, CM being my preferred flavour of Android, but it applies to other flavours too. It will be developed first for an Allwinner A10 tablet (A Momo9 clone) as this is the least important Android device I have lying around, the one which I am least bothered about breaking, but I plan to make these updates as generic as possible to allow easy porting.
OK, on to my objectives:
Make a flexible boot environment system, allowing a device to be booted into different ROMs/configurations, using LVM as a base. This would also allow more flexible use of internal memory, snapshots, and non-persistent data configurations.
*EDIT* By the way, the first part of this (getting LVM2 onto Android) has been completed already by steven676 (see his github repo)
Make additions to CWM recovery to allow management of LVM volumes and boot environments. I have no idea where to start on this one, seeing as I can't even find the source for CWM, but it is necessary to make the project work well.
Make additions to vold and the Android storage settings to allow management of volumes and boot environments from within Android, and to recognise logical volumes for use as internal "SD card". This will probably have to be accomplished using an additional daemon due to license incompatibilities between vold (Apache) and LVM (GPL), but I would like the main interface to my work to be within vold as it is the logical place.
The idea would be that you create an LVM volume group using your internal storage (probably system, data, cache and internal SD partitions), and then define your sys/data/cache/sd etc. as logical volumes within this group. As stated above in objective 1, this gives you flexibility (you can size them as you wish) and access to the snapshot functionality. Snapshots would be great in testing software (you can easily get your device back to a known good config), and would also allow a non-persistent configuration (all changes discarded on reboot, great for handing a device to another person e.g. your kids).
The reason I wish to do this is as a base for my next project, which needs the kind of flexibility this will bring, but I want to keep this discussion on track, so I wont muddy the waters with the details of it yet. However, it will also aid those with small system partitions, developers, and those with small children (or partners... ) who install loadsa rubbish and screw up your device.
The mods I plan to make in CWM should also make it much easier to make update packages for different devices, as I plan to include methods for the updater-script to determine where things should be going (where the system/data/boot etc. devices live), rather than having to hard code them in the script.
So: Thoughts? Advice? Please don't just leave comments of "This is a good/bad idea", I am looking for a constructive discussion.
Thanks in advance
Mouse
I'm not quite following you. Are you planing to boot from an LVM volume? If so, you'll more or less require GRUB2, and does GRUB2 support ATAGS? I believe you'll need 'em both for this to succeed.
Hi
Not quite.
The plan is to use the standard Android boot mechanism to load the kernel and initrd. Within this initrd, the mounting of filesystems (system/data/cache etc) is moved into a separate daemon which chooses them from LVM (or anywhere really). This is limitted, of course, to using just one kernel & initrd (unless kexec can be used, which is beyond the scope of what I need for this project), but it allows much greater flexibility.
drmouse81 said:
The plan is to use the standard Android boot mechanism to load the kernel and initrd. Within this initrd, the mounting of filesystems (system/data/cache etc) is moved into a separate daemon which chooses them from LVM (or anywhere really). This is limitted, of course, to using just one kernel & initrd (unless kexec can be used, which is beyond the scope of what I need for this project), but it allows much greater flexibility.
Click to expand...
Click to collapse
Ah, ok, you are making it easy for you. I do something similar myself. After I boot my custom initramfs, it performs a switchroot to the SDcard, continuing the execution of the real init there. This gives about the same flexibility you are seeking, but also with the same limitation the kernel must stay the same for all systems. This way I can change the system by replacing the SDcard, without the need of LVM.
Yes, this is very similar to what I am in the process of doing. I just think that, especially in devices with large amounts of internal storage (my tab has 16GB) as well as an SD card slot, LVM is a much more flexible solution. Snapshots are the main benefit, but I also plan to use LVM for another project.
Really, the LVM part is pretty simple. The project mentioned on github has the majority of the work done, I am simply extending it at the moment to include some additional features. The majority of the work involved here will be integrating it more closely with both Android and CWM (I expect a steep learing curve: I already develop in both C/C++ and Java, but am not very familliar with the internal workings of Android, and can't even find the sources for CWM).
I do believe it is worth the effort, however. Who knows, it may even make it into CM, or even official Android, at some point... Doubt it, but it is possible
Android ABC
I've gathered some info for newcomers to the Android world.
Copied over from my thread at androidforums...
I've tried to keep it relatively simple. So if you want more info, follow the links!
And please if you want anything added, do post!
I hope this helps someone....
Inventory:
Bootloader
Kernel
CWM
Firmware
Flashing
Rooting
Custom ROMs
ADB
Baseband
Dalvik
init.d
What's A Bootloader?
Taken from: Android 101: What is a bootloader? | Android-Does.com
In literal terms, the bootloader is code that is executed before any Operating System starts to run. Bootloaders basically package the instructions to boot operating system kernel and most of them also have their own debugging or modification environment. Think of the bootloader as a security checkpoint for all those partitions. Because if you’re able to swap out what’s on those partitions, you’re able to break things if you don’t know what you’re doing.
As the bootloader kicks off before any piece of software on your device, it makes it extremely processor specific and every motherboard has it’s own bootloader. This is one reason that all Android phones have different custom ROMS developed due to high variance of processing hardware present on the device.
Android Bootloader
Every Android phone has a bootloader that instructs the operating system kernel to boot normally. But you need to understand one thing here that as Android OS is an open source OS and is available on a variety of different hardware, every manufacturer has their own version of bootloader specific for the hardware present in it’s environment. At its most basic level, your Android smartphone is like a hard drive, made of up several partitions. One of those partitions holds the Android system files, another holds all the app data you accumulate (which is how you’re usually able to update without losing all your stuff), and others to do more behind-the scenes stuff.
A lot has been said about bootloaders being “locked” and even the developer-friendly Nexus devices shipped with a locked bootloader (Nexus devices and a couple tablets are easily unlocked with a single command).In fact, a lot bootloaders are locked and encrypted, meaning simple commands like “fastboot oem unlock”, won’t do a thing.
Why are Bootloaders Locked?
A bootloader is usually locked on an Android device because although it’s an open source OS, still the manufacturers want you to stick to their Android OS version specifically designed for the device. In order to apply this concept, manufacturers lock the bootloader. With a locked bootloader on Android devices, it is virtually impossible to flash a Custom ROM and forced attempts void warranty as well as usually end up in bricks. Therefore, the first step is to always unlock the bootloader.
Why keep a bootloader out of reach? One of the biggest reasons is that the carriers and manufacturers don’t want to have to support hacked phones. The other is that a lot of time and money is spent developing these things. HTC Sense ain’t cheap. Neither is TouchWiz. But Samsung and HTC both have managed to find a middle ground with the modding community, and pressure is on other companies to do so as well.
Also a very good read about bootloaders: http://www.tested.com/news/feature/1879-know-your-android-bootloaderwhat-it-is-and-why-it-matters/
---------------------------------------------------------------------------
What's a kernel?
Taken from: Android A to Z: What is a kernel? | Android Central
A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
---------------------------------------------------------------------------
What's CWM?
Taken from: AddictiveTips » Blog ArchiveWhat Is ClockworkMod Recovery And How To Use It On Android [Complete Guide]
ClockworkMod, abbreviated as CWM, is a popular custom recovery for Android phones and tablets developed by Koushik Dutta (Koush), a well-known name in the Android dev community. ClockworkMod recovery allows you to perform several advanced recovery, restoration, installation and maintenance operations on your Android device that aren’t possible with the stock recovery, and is one of the most common ways used to gain root access, back up device data, install a custom ROMs, kernels, themes, mods and more. However, for anyone new to Android customization and hacking, some of its options might prove to be a tad confusing. In what follows, we will cover all that this recovery is capable of doing, and how to do it.
About Android Recovery
All Android devices ship with a recovery console that is basically a partition on the device’s internal memory and can be booted into. The stock recovery of almost all Android devices provides a few basic yet handy options that allow you to factory reset your device and also to recover its operating system using an official ROM in zip format, but that’s all you can do with it. That’s where a custom recovery comes handy.
A custom Android recovery basically replaces the stock recovery with one that lets you do all you can do with the stock recovery, plus a plethora of more options to give you a lot more control on your device. With a custom recovery, you can install official and unofficial ROMs as well as other updates including apps, themes, kernels etc. using zip files, wipe not just user data but pretty much every partition on your device, mount the storage card for USB mass storage access without leaving recovery, partition your SD card, wipe Dalvik cache and battery stats, fix permissions, perform, manage and restore backups and so on.
Introduction To ClockworkMod
ClockworkMod recovery is one of the most widely used custom Android recoveries that is available for most mainstream Android devices. It is our custom recovery of choice here at AddictiveTips and almost every custom ROM that we install on our devices is done using this recovery.
ClockworkMod recovery has been developed by Koushik Dutta (also known as Koush) – the same guy who brought us the Android ROM Manager. He can be found at his blog hacking away at Android devices and at Twitter.
CWM options explained:
[REF] CWM - Clockworkmode menu options & Partitions– GENERAL KNOWLEDGE - xda-developers
---------------------------------------------------------------------------
What's Firmware?
Taken from: What is Firmware, Rom and Firmware Flashing ? - I Teach Android
What the heck is this firmware? Definition of firmware is permanent software programmed into a read-only memory
In Simple words, you can understand it like windows for pc , in case of android we are going to do same thing – installing firmware (Froyo,Gingerbread, ICS, Jelly Bean etc.) on your phone. All phones have their different firmwares and installing tools regard less to the Andriod version (Froyo,Gingerbred). So never think that we can install any firmware on any android phone like we do in PCs.
Wiki link for even more info: Firmware - Wikipedia, the free encyclopedia
---------------------------------------------------------------------------
What's Flashing?
Flashing refers to the overwriting of existing data on ROM modules present in an electronic device with new data. This can be done to upgrade a device or to change the provider of a service associated with the function of the device, such as changing from one mobile phone service provider to another or installing a new operating system.
In simple words flashing is called installing firmware on your phone.
---------------------------------------------------------------------------
What's Rooting?
Taken from: Rooting for Android: What, why and how? | Ubergizmo
WiKi link: https://en.wikipedia.org/wiki/Rooting_(Android_OS)
When carriers and manufacturers sell you your device, it is almost certain that the device would come with certain software restrictions in place. There are a variety of different reasons why they might do that – some claim that this is done to protect the user, preserve the device’s warranty (this policy will vary from manufacturer to manufacturer), prevent users from getting rid of carrier bloatware apps or simply because the manufacturer would prefer if your device was distinguishable from the competition based purely on its user interface (i.e. Samsung’s TouchWiz, HTC Sense UI, etc).
Whatever their reasoning may be, chances are if you are looking to customize your device on a deeper level, you’d be out of luck and this is where rooting comes into play.
Rooting is essentially a process that allows users of smartphones, tablets or other devices running on Android to gain “superuser” access to the software. This will allow the user to perform administrative tasks such as writing to locations normally restricted by the system which in turn will allow for deeper customization. For iOS users, rooting on Android devices could be thought of as a close equivalent to jailbreaking your device.
---------------------------------------------------------------------------
What are custom ROMs?
Taken from: Custom ROMs For Android Explained - Here Is Why You Want Them
A stock ROM is the version of the phone's operating system that comes with your phone when you buy it.
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way.
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, strip them of garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow.
---------------------------------------------------------------------------
What is ADB?
Taken from: Android 201: What is adb? | Android Central
According to Google "Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device." That certainly sounds like Google, doesn't it? To put it simply, adb is two different applications -- one running on your computer (Windows, Linux or Mac) and one running on your phone. When your phone is connected, and USB debugging is enabled, you can issue commands and communicate with the phone using your computer screen and keyboard.
Your Android phone uses a modified Linux kernel and tools as a base. This means that quite a few Linux commands can be sent via the adb server (the one running on your computer) to the adb client (the one running on your phone) and they will be executed. In our example picture, I've sent the "top" command over the wire to my phone, and my phone sent me back the information and printed it to my terminal.
This can be awfully handy for debugging things that aren't going right, as well sending those weird commands you need when you're hacking away in the middle of the night. Chances are, if you aren't actively debugging something or trying to break hack at your phone, you won't have much use for adb. And that's OK -- there's more than one way to have fun with an Android device.
----------------------------------------------------------------------------
What's baseband?
Baseband is the Radio or Modem version depending upon the Phone Model, Carrier and Android Software Stack version. The Radio/Modem file is flashed via Recovery tool (other options are ADB/ODIN). The mismatched Radio/Modem and ROM will lead to things not working. You need to find the matching Radio/Modem for the particular ROM you are running.
The radio firmware controls basic low-level functions like network connectivity, Wi-Fi, and GPS. Upgrading Radio firmware will fix connectivity issues, increase range or performance, decrease battery usage, etc. Incorrec tRadio frimeware can disable some functions in your phone such as MMS, 3G Data, VM Notifications, etc. Network operators/carriers select the correct version of the Radio firmware that is suitable for the phone, network and bandwidth.
There is also Modem and Baseband Radio Processor chipsets in Mobile phones. Usually, Google, Phone Manufacturers and carriers develop various types of modem firmware/software that controls the functions of these chipsets.
Firmware is the overall version of the Android system on your phone. Baseband version is the version of the radio embedded in the device. Since Android is based on the Linux operating system, they show you the current version of the Kernel used in the heart of the system. The Build number is just an indicator of which numerical version of the current overall system was built by developers for your device.
You cannot update any of these from the official web site. Updates to the Android system are pushed to the phone over-the-air by the manufacturer or the cell phone carrier. The only other way to update or change an Android phone it to install custom modified ROMs in place of the existing system firmware. That usually requires rooting the phone and a fairly considerable knowledge of how to hack hardware.
----------------------------------------------------------------------------
What's Dalvik?
http://www.techopedia.com/definition/4262/dalvik
http://butterflydroid.wordpress.com/2011/09/22/what-is-dalvik-vm-heapsize-benefits-and-downfalls/
Dalvik is named after a fishing village in Iceland where ancestors of Dan Bornstein, the person who wrote the VM’s original code, lived. Dalvik is designed for fast execution speeds and operatation in resource-constrained environments like those in mobile devices (with limited memory, CPU and battery power). A Dalvik VM is designed to run multiple instances of itself with each instance hosted on its own separate process and running one application each. When one instance crashes, other concurrently running applications don’t suffer.
Although Android apps are written in Java, they are first compiled into the Dalvik Executable (DEX) format to make them run on the Dalvik VM. DEX files are generally smaller than compressed .JAR (Java Archive) files, making them suitable for mobile devices.
The main difference between Dalvik and a typical Java VM is that the former is register-based while the latter is stack-based. Register-based VMs require fewer instructions than their stack-based counterparts. Although the register-based VMs also require more code, they are generally considered to exhibit faster startups and have better performance than stack-based VMs.
The Dalvik source code license is based on the Apache license. That means, it is free to modify and hence attractive to mobile phone carriers.
What's init.d?
init.d is a folder located at /system/etc
To keep it simple, it allows the user to run scripts at system startup/ boot.
You can adjust many different things/settings with scripts. You can tweak system settings, prolong battery life etc.
To enable init.d and to get some scripts, go here: http://forum.xda-developers.com/showthread.php?t=1881401
----------------------------------------------------------------------------
great job brother, do much to newcomers become familiar with android and they need to know :highfive:
woooow , thats nice and great thread ...... thx ..... but between that , can u continue explain many things like what each android device need to boot up and what the most commen partitions in android devics , and getting deeper in android world ad then give some tut about adb using
thx so much
Good stuff, thanks!
Great guide for android noobie who want to learn how to root
add CID and MID ... ?
Hey -- a really great resource. great work.
could be nice to include CID, MID, etc.
also, would like to understand why ROM has to be built for specific carrier variant of phone.
Example: HTC ONE M8 has multiple different ROM threads -- ATT, Tmobile, Verizon, etc. While I understand there are some small frequencies support differences between an M8_tmobile and M8_Verison, why doesn't a Rooted with S-off M8 care whether it's a ATT or Verizon model?
thx
Thanks iONEx, this post helped me some. I already have 20 years of experience with Linux on PCs and Macs, so I already understood concepts like Bootloader, Kernel, Rooting, Flashing, Firmware, and init.d. I've had to flash a new BIOS on several PC motherboards, so I understand the difference between nonvolatile storage in firmware mounted on an integrated circuit of the motherboard versus nonvolatile storage in a physical spinning magnetic hard drive connected to the motherboard via a SCSI or SATA bus and controller. I rooted my first Android (a Motorola Atrix) a year ago, so I also understand CWM, Custom ROMs, and ADB. But your explanation of Baseband and Dalvik was new and helpful to me.
Right now I'm running Paranoid Android on my Oneplus One and using the Settings app in it, I see that I have Android version 4.4.4, ParanoidAndroid version 4.6-BETA6, Baseband version MPSS.DI.2.0.1..., Kernel version 3.4.0-ParanoidAndroid (Mon Nov 3 21:55:14 UTC 2014), Build number pa_bacon-userdebug...).
I found your post while trying to understand more about my OPO that I rooted a few days ago. I installed TWRP, F-Droid, Busybox, MultiROM, and a few other major customizations on it, but I feel like there's still a whole lot that I don't understand at all. For example, in this thread [forums.oneplus.net/threads/unofficial-beanstalk-rom-for-bacon-lollipop-5-02-r1.247146/#post-9394373] I commented that I was unable to get Beanstalk 5.0.2 to function reliably on my OPO.
From chineel's reply "The Steps To Have Better Experience With OnePlus One With Lollipop ROMs" though, I realized that I must still be missing some important concepts, so I started searching for a comprehensive picture of my OPO and of Android phones in general, and although your post helped some, I'm still looking for a much more comprehensive understanding of this device.
I do understand that the nonvolatile storage in my phone must be partitioned into several mutually exclusive sections and that's how it's possible for me to wipe (using TWRP) all of the partitions (Dalvik Cache, System, Data, and Cache) except Internal Storage and flash a new ROM like Beanstalk and yet I still have the contents of /sdcard/ as they were before I wiped and flashed. Obviously, /sdcard/ as mounted in ParanoidAndroid and Beanstalk must be on the Internal Storage partition that did not get wiped.
But when chineel wrote that I should download latest “Cm Nightly” and “(CM Nightly Is for Modem and firmware Update only ) you can Just Flash Firm ware Update [s.basketbuild.com/filedl/devs?dev=chineel&dl=chineel/BeanStalk/bacon/Full-CM-12.01.18-modem-flashable.zip] Instead of...”, that's when I realized that when I flashed a new ROM, I was apparently still leaving something aside from the Internal Storage partition untouched: the modem/baseband/radio?
And so if I flash the latest CM nightly from [download.cyanogenmod.org/?device=bacon&type=] then I'll end up doing what I have not been doing before which is to also change the modem/baseband/radio. Is that right?
So then if I flash a new ROM (like Beanstalk) AFTER flashing the CM Nightly, then I'll be replacing the ROM (from the CM Nightly to Beanstalk), but I won't be changing again the modem/baseband/radio that was changed when I flashed the CM Nightly. Is that right?
If so, then where in this partition system is the modem/baseband/radio firmware (which is apparently separate from the whole ROM) stored in nonvolatile storage? Is it also on Internal Storage? Or is it stored on a separate integrated circuit (like the BIOS is on a PC) or on some other hidden partition?
And what about flashing the kernel? When I flashed my PA ROM, I got a new kernel with it, without explicitly installing from TWRP a new kernel. So sometimes flashing a ROM gives you a new kernel and sometimes flashing a ROM does not change the existing kernel? Is that right? And so is it also possible to flash a ROM and then subsequently flash a kernel and that second flash replaces the kernel that was part of the ROM of the first flash?
I just need to understand where all of this information is getting stored (in which partitions). I know I flash a ROM, then I flash GAPPS, then I flash a kernel, then I flash a modem/radio/baseband. But I can't tell; is all that software going to the System partition? If so, then why don't all the later flashes completely write over all the earlier flashes?
TL;DR
My real question here is what to read for a comprehensive explanation of all these pieces and how they fit together and why flashing sometimes replaces something that was there before, but it doesn't replace everything (like the modem/radio/baseband)? I think I need a book or something. Can you recommend one?
Thanks, and sorry for the long post.
iONEx said:
Android ABC
I've gathered some info for newcomers to the Android world.
Copied over from my thread at androidforums...
I've tried to keep it relatively simple. So if you want more info, follow the links!
And please if you want anything added, do post!
I hope this helps someone....
Inventory:
Bootloader
Kernel
CWM
Firmware
Flashing
Rooting
Custom ROMs
ADB
Baseband
Dalvik
init.d
What's A Bootloader?
Taken from: Android 101: What is a bootloader? | Android-Does.com
In literal terms, the bootloader is code that is executed before any Operating System starts to run. Bootloaders basically package the instructions to boot operating system kernel and most of them also have their own debugging or modification environment. Think of the bootloader as a security checkpoint for all those partitions. Because if you’re able to swap out what’s on those partitions, you’re able to break things if you don’t know what you’re doing.
As the bootloader kicks off before any piece of software on your device, it makes it extremely processor specific and every motherboard has it’s own bootloader. This is one reason that all Android phones have different custom ROMS developed due to high variance of processing hardware present on the device.
Android Bootloader
Every Android phone has a bootloader that instructs the operating system kernel to boot normally. But you need to understand one thing here that as Android OS is an open source OS and is available on a variety of different hardware, every manufacturer has their own version of bootloader specific for the hardware present in it’s environment. At its most basic level, your Android smartphone is like a hard drive, made of up several partitions. One of those partitions holds the Android system files, another holds all the app data you accumulate (which is how you’re usually able to update without losing all your stuff), and others to do more behind-the scenes stuff.
A lot has been said about bootloaders being “locked” and even the developer-friendly Nexus devices shipped with a locked bootloader (Nexus devices and a couple tablets are easily unlocked with a single command).In fact, a lot bootloaders are locked and encrypted, meaning simple commands like “fastboot oem unlock”, won’t do a thing.
Why are Bootloaders Locked?
A bootloader is usually locked on an Android device because although it’s an open source OS, still the manufacturers want you to stick to their Android OS version specifically designed for the device. In order to apply this concept, manufacturers lock the bootloader. With a locked bootloader on Android devices, it is virtually impossible to flash a Custom ROM and forced attempts void warranty as well as usually end up in bricks. Therefore, the first step is to always unlock the bootloader.
Why keep a bootloader out of reach? One of the biggest reasons is that the carriers and manufacturers don’t want to have to support hacked phones. The other is that a lot of time and money is spent developing these things. HTC Sense ain’t cheap. Neither is TouchWiz. But Samsung and HTC both have managed to find a middle ground with the modding community, and pressure is on other companies to do so as well.
Also a very good read about bootloaders: http://www.tested.com/news/feature/1879-know-your-android-bootloaderwhat-it-is-and-why-it-matters/
---------------------------------------------------------------------------
What's a kernel?
Taken from: Android A to Z: What is a kernel? | Android Central
A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
---------------------------------------------------------------------------
What's CWM?
Taken from: AddictiveTips » Blog ArchiveWhat Is ClockworkMod Recovery And How To Use It On Android [Complete Guide]
ClockworkMod, abbreviated as CWM, is a popular custom recovery for Android phones and tablets developed by Koushik Dutta (Koush), a well-known name in the Android dev community. ClockworkMod recovery allows you to perform several advanced recovery, restoration, installation and maintenance operations on your Android device that aren’t possible with the stock recovery, and is one of the most common ways used to gain root access, back up device data, install a custom ROMs, kernels, themes, mods and more. However, for anyone new to Android customization and hacking, some of its options might prove to be a tad confusing. In what follows, we will cover all that this recovery is capable of doing, and how to do it.
About Android Recovery
All Android devices ship with a recovery console that is basically a partition on the device’s internal memory and can be booted into. The stock recovery of almost all Android devices provides a few basic yet handy options that allow you to factory reset your device and also to recover its operating system using an official ROM in zip format, but that’s all you can do with it. That’s where a custom recovery comes handy.
A custom Android recovery basically replaces the stock recovery with one that lets you do all you can do with the stock recovery, plus a plethora of more options to give you a lot more control on your device. With a custom recovery, you can install official and unofficial ROMs as well as other updates including apps, themes, kernels etc. using zip files, wipe not just user data but pretty much every partition on your device, mount the storage card for USB mass storage access without leaving recovery, partition your SD card, wipe Dalvik cache and battery stats, fix permissions, perform, manage and restore backups and so on.
Introduction To ClockworkMod
ClockworkMod recovery is one of the most widely used custom Android recoveries that is available for most mainstream Android devices. It is our custom recovery of choice here at AddictiveTips and almost every custom ROM that we install on our devices is done using this recovery.
ClockworkMod recovery has been developed by Koushik Dutta (also known as Koush) – the same guy who brought us the Android ROM Manager. He can be found at his blog hacking away at Android devices and at Twitter.
CWM options explained:
[REF] CWM - Clockworkmode menu options & Partitions– GENERAL KNOWLEDGE - xda-developers
---------------------------------------------------------------------------
What's Firmware?
Taken from: What is Firmware, Rom and Firmware Flashing ? - I Teach Android
What the heck is this firmware? Definition of firmware is permanent software programmed into a read-only memory
In Simple words, you can understand it like windows for pc , in case of android we are going to do same thing – installing firmware (Froyo,Gingerbread, ICS, Jelly Bean etc.) on your phone. All phones have their different firmwares and installing tools regard less to the Andriod version (Froyo,Gingerbred). So never think that we can install any firmware on any android phone like we do in PCs.
Wiki link for even more info: Firmware - Wikipedia, the free encyclopedia
---------------------------------------------------------------------------
What's Flashing?
Flashing refers to the overwriting of existing data on ROM modules present in an electronic device with new data. This can be done to upgrade a device or to change the provider of a service associated with the function of the device, such as changing from one mobile phone service provider to another or installing a new operating system.
In simple words flashing is called installing firmware on your phone.
---------------------------------------------------------------------------
What's Rooting?
Taken from: Rooting for Android: What, why and how? | Ubergizmo
WiKi link: https://en.wikipedia.org/wiki/Rooting_(Android_OS)
When carriers and manufacturers sell you your device, it is almost certain that the device would come with certain software restrictions in place. There are a variety of different reasons why they might do that – some claim that this is done to protect the user, preserve the device’s warranty (this policy will vary from manufacturer to manufacturer), prevent users from getting rid of carrier bloatware apps or simply because the manufacturer would prefer if your device was distinguishable from the competition based purely on its user interface (i.e. Samsung’s TouchWiz, HTC Sense UI, etc).
Whatever their reasoning may be, chances are if you are looking to customize your device on a deeper level, you’d be out of luck and this is where rooting comes into play.
Rooting is essentially a process that allows users of smartphones, tablets or other devices running on Android to gain “superuser” access to the software. This will allow the user to perform administrative tasks such as writing to locations normally restricted by the system which in turn will allow for deeper customization. For iOS users, rooting on Android devices could be thought of as a close equivalent to jailbreaking your device.
---------------------------------------------------------------------------
What are custom ROMs?
Taken from: Custom ROMs For Android Explained - Here Is Why You Want Them
A stock ROM is the version of the phone's operating system that comes with your phone when you buy it.
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way.
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, strip them of garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow.
---------------------------------------------------------------------------
What is ADB?
Taken from: Android 201: What is adb? | Android Central
According to Google "Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device." That certainly sounds like Google, doesn't it? To put it simply, adb is two different applications -- one running on your computer (Windows, Linux or Mac) and one running on your phone. When your phone is connected, and USB debugging is enabled, you can issue commands and communicate with the phone using your computer screen and keyboard.
Your Android phone uses a modified Linux kernel and tools as a base. This means that quite a few Linux commands can be sent via the adb server (the one running on your computer) to the adb client (the one running on your phone) and they will be executed. In our example picture, I've sent the "top" command over the wire to my phone, and my phone sent me back the information and printed it to my terminal.
This can be awfully handy for debugging things that aren't going right, as well sending those weird commands you need when you're hacking away in the middle of the night. Chances are, if you aren't actively debugging something or trying to break hack at your phone, you won't have much use for adb. And that's OK -- there's more than one way to have fun with an Android device.
----------------------------------------------------------------------------
What's baseband?
Baseband is the Radio or Modem version depending upon the Phone Model, Carrier and Android Software Stack version. The Radio/Modem file is flashed via Recovery tool (other options are ADB/ODIN). The mismatched Radio/Modem and ROM will lead to things not working. You need to find the matching Radio/Modem for the particular ROM you are running.
The radio firmware controls basic low-level functions like network connectivity, Wi-Fi, and GPS. Upgrading Radio firmware will fix connectivity issues, increase range or performance, decrease battery usage, etc. Incorrec tRadio frimeware can disable some functions in your phone such as MMS, 3G Data, VM Notifications, etc. Network operators/carriers select the correct version of the Radio firmware that is suitable for the phone, network and bandwidth.
There is also Modem and Baseband Radio Processor chipsets in Mobile phones. Usually, Google, Phone Manufacturers and carriers develop various types of modem firmware/software that controls the functions of these chipsets.
Firmware is the overall version of the Android system on your phone. Baseband version is the version of the radio embedded in the device. Since Android is based on the Linux operating system, they show you the current version of the Kernel used in the heart of the system. The Build number is just an indicator of which numerical version of the current overall system was built by developers for your device.
You cannot update any of these from the official web site. Updates to the Android system are pushed to the phone over-the-air by the manufacturer or the cell phone carrier. The only other way to update or change an Android phone it to install custom modified ROMs in place of the existing system firmware. That usually requires rooting the phone and a fairly considerable knowledge of how to hack hardware.
----------------------------------------------------------------------------
What's Dalvik?
http://www.techopedia.com/definition/4262/dalvik
http://butterflydroid.wordpress.com/2011/09/22/what-is-dalvik-vm-heapsize-benefits-and-downfalls/
Dalvik is named after a fishing village in Iceland where ancestors of Dan Bornstein, the person who wrote the VM’s original code, lived. Dalvik is designed for fast execution speeds and operatation in resource-constrained environments like those in mobile devices (with limited memory, CPU and battery power). A Dalvik VM is designed to run multiple instances of itself with each instance hosted on its own separate process and running one application each. When one instance crashes, other concurrently running applications don’t suffer.
Although Android apps are written in Java, they are first compiled into the Dalvik Executable (DEX) format to make them run on the Dalvik VM. DEX files are generally smaller than compressed .JAR (Java Archive) files, making them suitable for mobile devices.
The main difference between Dalvik and a typical Java VM is that the former is register-based while the latter is stack-based. Register-based VMs require fewer instructions than their stack-based counterparts. Although the register-based VMs also require more code, they are generally considered to exhibit faster startups and have better performance than stack-based VMs.
The Dalvik source code license is based on the Apache license. That means, it is free to modify and hence attractive to mobile phone carriers.
What's init.d?
init.d is a folder located at /system/etc
To keep it simple, it allows the user to run scripts at system startup/ boot.
You can adjust many different things/settings with scripts. You can tweak system settings, prolong battery life etc.
To enable init.d and to get some scripts, go here: http://forum.xda-developers.com/showthread.php?t=1881401
----------------------------------------------------------------------------
Click to expand...
Click to collapse
Thanks, good info
teejbee said:
Thanks, good info
Click to expand...
Click to collapse
Strewth! Not only did you quote the ENTIRE OP post in order to reply with a 3 word thank you but 2 people actually thanked you for it. I might print that out and hang it on my wall. :laugh:
Hi, what does the "Allow bootloader unlock" (or similar) mean in advanced settings on s7 and some other devices? My phablet also has this option and I turned it on without any changes after typing oem unlock. With selfmade cwm I can root my phone, if its allowed to unlock or not.. is this setting only a placeholder or did someone get the real function? M a ybe this is important for nexus devices only, or not. I do not know.
Gesendet von meinem SM-G900F mit Tapatalk
Edit: sorry for asking in xperia forums.. used tapatalk and saw the title is matching my purposes.. did not see the xperia section, but my question you can answer, too. Sry
louiscar said:
Strewth! Not only did you quote the ENTIRE OP post in order to reply with a 3 word thank you but 2 people actually thanked you for it. I might print that out and hang it on my wall. :laugh:
Click to expand...
Click to collapse
hahahahahahaha :laugh:
Dear, Can I make a custom ROM for my Android TV that can use the TV remote and IR key?
I mean, after installing a custom ROM like Lineage OS, do the remote and inputs work properly?
UPDATE: See second post for initial downloads of AOSP, CM , Arndale and Linaro/Arndale builds. These are very much a work in progress and may not even work. I am putting them forth for testing for the dev community to try out on their chromebooks.
These builds will be based on the latest JB builds. There is still alot of work to be done here. The AOSP builds initially have been put up. The other builds will go up as they are completed. I am working on the documentation for putting this together as a repeatable process is doable. In time there will be an installer and other goodies, but for now this will just be a very vanilla and manual process.
My goal is to get a working port of JB on the Samsung Chromebook. There has been no significant work on this front AFAIK. So I am taking it on myself to learn and try this out. Any community input would be helpful in making this work. I am fairly n00b at this but am looking to make this work.
I found some promising information. I might be able to build this using the binaries from arndaleboard which appears to mostly use the same hardware.
FYI for anyone experimenting to make this work please note that the following MUST be done for any chance of these root files to boot from SD.
SD/MMC boot
vold.fstab
* Change the sdcard0 and sdcard1 lines so that the first line is sdcard1 and the second is sdcard0.
fstab.arndale
* Change all references to mmcblk0px to mmcblk1px.
init.arndale.rc
* Change the 2 references to mmcblk0px to mmcblk1px.
mountd.conf
* Change the reference to mmcblk0 to mmcblk1
http://www.arndaleboard.org/wiki/index.php/Main_Page
http://forum.insignal.co.kr/viewtopic.php?f=6&t=62
http://forum.insignal.co.kr/viewtopic.php?f=6&t=63
Now that the rootfs part is addressed I am tackling the booting issues. Current uboot methods focus mainly on linux distro booting. Android appears to require its own ramdisk (which is in the links below) there will be some extra downloads such as a working uboot.
Once there are working versions of all the needed components working. An installer or installer script will be put together along with documentation. I may release this to a separate thread which I will post here.
Additional info on flashing the actual arndale. http://www.arndaleboard.org/wiki/ind...Flash_a_Device
Arndale is the base hardware also used on a Samsung series 3 Chromebook. Most if not all the components will work.
Additionally MANTA aka nexus 10 hardware is similarly identical and can be used with some success. I am working on compiling base builds based on CM10, AOSP, Linaro and Arndale's git.
Some more info on the bootloader
http://www.denx.de/wiki/U-Boot
http://www.chromium.org/chromium-os/...arm-chromebook
Im using this post to keep notes on what I find and build. I might edit some more to update as I find stuff. I will create a separate post if I have any success. I got two of these. I can live with bricking one if it happens. And I imagine there is a way to restore the system if needed. I figure I will figure that part out first. To avoid any mishaps and have a brick.
CREDITS: Musical_chairs for his invaluable input and resources he has linked in this post. I will update credits for other contributors once I get through the whole thread and credit all those obviously who build the original code these builds will be based on.
DISCLAIMER: For advanced users ONLY!! Not responsible if your chromebook gets bricked, struck by lightning or eaten by a pack of wild boars or attacked by crab people! Anything you do strongly recommended it be done on an SDcard to ensure easy rollbacks and no destruction of firmware.
Here are the first downloads of the rootfs and ramdisk (both of which are needed for a working android install on chromebook) These are based on AOSP. More files will be coming as I am compiling. Basic instructions on how to set up uboot will be posted above as well as how to properly flash an SDcard. This assumes you know how to get your chromebook into dev-mode. Please note this is strictly for anyone with android system experience. The system may not even boot properly at this point. This is pre-pre-alpha at this point. There is alot of work to do before it even comes close to being usable. But if you get it working, please make a DD image (instructions above) and post it for all to use and work from. FOSS means sharing and sharing means caring. This will speed up the work needed to make this work for all of us.
aosp-ramdisk.img
https://mega.co.nz/#!sZgVmIQY!M9ANXXEJYAWR0TlRxV_mC3CdEXkTKC_Tgr1PdOD0Hxo
aosp-rootfs.tar.bz2
https://mega.co.nz/#!ZNgAFYqR!HkXcLxead3Zgm7lNcUzjb0YlfzEbbogTL5CnZDuUtIA
arndale-kernel
https://mega.co.nz/#!gIQXVLRC!U_L0WSutAXdGzdqhFrlzD1ij750Q8lTlKwHVoC28C14
arndale-ramdisk.img.ub
https://mega.co.nz/#!RB4XBAjS!JtNgciYJrLL_TDmjXjnZkTouPKwAhva26b7U9zvBYA0
arndale-rootfs.tar.bz2
https://mega.co.nz/#!xJwBVALa!QnwJRjQzhC218tcjMtKnimKZE2kn73sGs8XgeC75fDU
I'm super excited that you're working on this Opieum. This would be absolute dream come true. I'd love to help out but I can't be a tester lol. After I get my next few paychecks I'd love to send a donation to you sir!
Im still working on it. Its a bit tricker than I thought to get it working. Not impossible tho. I just lack the experience and knowledge to get this up and running. I figured I could do it over the weekend lol. Humbling experience. Once I have something working that is moderatly usable I figure I will take some donations to support other types of chromebooks, for now tho I will just do this cause I want to get android working on the samsung chromebook series 3.
opieum said:
Im still working on it. Its a bit tricker than I thought to get it working. Not impossible tho. I just lack the experience and knowledge to get this up and running. I figured I could do it over the weekend lol. Humbling experience. Once I have something working that is moderatly usable I figure I will take some donations to support other types of chromebooks, for now tho I will just do this cause I want to get android working on the samsung chromebook series 3.
Click to expand...
Click to collapse
May want to wait for IO until after if Chrome and Android get close enough to jump from one to the other.
Also, I guess you could try and use the Cyanogen Mod port tool to try and get Android on it. It's what I used to try and get Ubuntu-Phone on my Nook. Nearly have it, but got the black screen of doom.
Thanks moocow, I appreciate the advice. I had not considered the Cyanogen tool. I know google IO is right around the corner but I want to see if I can get it working. Part of it is as much a technical exercise to see if I can do it as much as it is just doing it.
Do you have a link for this porting tool? I was looking for one. If its just porting from the git I guess I can do that too. I was just wondering if there was a specific tool do this with. I was not aware there actually was a tool.
I'm so excited someone is trying to make this work! I'm no dev, but I'd love to help in anyway. Subbing now.
http://wiki.cyanogenmod.org/w/Doc:_porting_intro
This might help also.
http://wiki.cyanogenmod.org/w/Development
Amazing! I wish you the best of luck on this
I've seen some great development for the ARM Chromebook over on the Linux side, so anything is possible
Hope your efforts will be fruitful
Thanks!
I'm excited to see some effort being put into this!
I don't think you need to worry about flashing procedures just yet, and I certainly would forget about messing with uboot until way later in the game. It's pretty easy to get a dual-boot setup on the chromebook, getting the files in place is way easier than it is on a typical Android device because you can write them to an sdcard from inside ChromeOS, then reboot to the sdcard. We can worry about booting Android from the internal storage later, shouldn't be too hard. And to do anything with uboot, you're going to need to physically disassemble the chromebook and remove the write protect screw/sticker, IMO it would be best to avoid that.
Maybe we should start by adapting this procedure, but putting an Android filesystem and kernel on the sdcard instead of Linux?
http://blogs.arm.com/software-enablement/848-running-linux-on-the-series-3-chromebook/
Thanks. I have been hitting wall after wall with u-boot so yea I am working on the dualboot method for now. That post is great! I had not seen it before. Bookmarked among many. Hopefully I can find the issues keeping me from making this work.
The first obstacle I am seeing is that while ChromeOS uses a pretty standard Linux kernel and no ramdisk (and that is what uboot will be looking for), Android uses a kernel and ramdisk on a /boot partition. I don't know enough about Android to know if it's possible to boot it with a different configuration, but I've got a hunch that if we're going to get Android to boot on this thing, we're going to need to do it a lot more like the Android x86 people do it than like a typical Android ROM.
Two exercises that I think will be very helpful here:
1. Install a Linux (Ubuntu, Debian, Arch, Fedora, whatever) on the sdcard of a chromebook without using a script like chrubuntu
2. Install Android x86 on a 'normal' computer.
I have almost done the first (I cheated and ended up using a script to install Ubuntu), the second I may eventually do if I can find the time.
...and like I said, I think the best approach here is going to be a x86 style Android installation, but with an arm build.
---------- Post added at 01:42 PM ---------- Previous post was at 01:27 PM ----------
...or maybe this is what we need - chainload uboot:
https://plus.google.com/117557107585466185396/posts/hVWc5EE9EK6
---------- Post added at 02:09 PM ---------- Previous post was at 01:42 PM ----------
Okay, this looks to be the official documentation on using nv-U-boot (chainloading uboot):
http://www.chromium.org/chromium-os...using-nv-u-boot-on-the-samsung-arm-chromebook
Upon further reading, I believe that this is the correct method:
1. Pack nv-U-boot as a signed kernel and dd it to a chromeos kernel partition.
2. nv-U-boot then boots Android using a typical Android boot command.
For the time being, I'm pretty sure it will be better to keep nv-U-boot and all the Android partitions on an sdcard, as it is no harder to boot from there than from the eMMc, and it's a whole lot safer to test stuff this way. Once we've got it working, we can repartition the eMMc and install everything there so it's faster and all that good stuff.
Bear in mind this is pretty much just academic at this point, I tried to chainload nv-U-boot but haven't actually gotten it to work. I'm pretty comfortable mucking around in Linux systems, but this uboot stuff is all new to me.
What I've done so far:
1. Set up partitions on my sdcard (including two kernel partitons) as per the first link I posted.
2. Got a working Lubuntu installation on the sdcard (cheated and used a chrubuntu-derived script).
3. Got a working Crouton (chrooted) Lubuntu setup on the internal storage (doesn't really apply here, though it comes in handy for some of the tools needed for manipulating files and stuff)
4. Tried the nv-U-boot image from opensuse:
http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM:/Contrib:/Chromebook/standard/armv7hl/
5. Tried the nv-U-boot image from the Chromium Projects:
http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow.kpart.bz2
In both cases, the process is the same. Pack nv-U-boot as a signed kernel, something like this (both commands are run in a shell from within ChromeOS, in dev mode):
Code:
vbutil_kernel --pack newkernel --keyblock /usr/share/vboot/devkeys/kernel.keyblock --version 1 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --vmlinuz u-boot.img --arch arm
write it to the sdcard with dd, something like this (remember you can hose almost anything with dd if you point it at the wrong place, so use with care:
Code:
sudo dd if=newkernel of=/dev/mmcblk1p2
(this writes it to partiton 2 of my sdcard, partition 1 is my good Ubuntu kernel.)
I haven't seen nv-U-boot yet but I think I'm close.
musical_chairs said:
Upon further reading, I believe that this is the correct method:
1. Pack nv-U-boot as a signed kernel and dd it to a chromeos kernel partition.
2. nv-U-boot then boots Android using a typical Android boot command.
For the time being, I'm pretty sure it will be better to keep nv-U-boot and all the Android partitions on an sdcard, as it is no harder to boot from there than from the eMMc, and it's a whole lot safer to test stuff this way. Once we've got it working, we can repartition the eMMc and install everything there so it's faster and all that good stuff.
Bear in mind this is pretty much just academic at this point, I tried to chainload nv-U-boot but haven't actually gotten it to work. I'm pretty comfortable mucking around in Linux systems, but this uboot stuff is all new to me.
What I've done so far:
1. Set up partitions on my sdcard (including two kernel partitons) as per the first link I posted.
2. Got a working Lubuntu installation on the sdcard (cheated and used a chrubuntu-derived script).
3. Got a working Crouton (chrooted) Lubuntu setup on the internal storage (doesn't really apply here, though it comes in handy for some of the tools needed for manipulating files and stuff)
4. Tried the nv-U-boot image from opensuse:
http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM:/Contrib:/Chromebook/standard/armv7hl/
5. Tried the nv-U-boot image from the Chromium Projects:
http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow.kpart.bz2
In both cases, the process is the same. Pack nv-U-boot as a signed kernel, something like this (both commands are run in a shell from within ChromeOS, in dev mode):
Code:
vbutil_kernel --pack newkernel --keyblock /usr/share/vboot/devkeys/kernel.keyblock --version 1 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --vmlinuz u-boot.img --arch arm
write it to the sdcard with dd, something like this (remember you can hose almost anything with dd if you point it at the wrong place, so use with care:
Code:
sudo dd if=newkernel of=/dev/mmcblk1p2
(this writes it to partiton 2 of my sdcard, partition 1 is my good Ubuntu kernel.)
I haven't seen nv-U-boot yet but I think I'm close.
Click to expand...
Click to collapse
Yea the u-boot stuff is real new to me. I have no issues either with linux its the bootloader stuff with android I am struggling with. I'm going to look at the arndale instructions as it uses similar hardware on how to load it from SDcard. The documentation there seems to show how to load the system. I already built and compiled the code from arndale seeing as it uses the exact specs needed. Since we have the ability to boot from SDcard on a chromebook this should be easily doable. The build will be the hard part. I am going to see what i can do with that method, I'm adapting from various sources. Ideally if I can come up with a simple image that can just be DDed over to a 32GB SD card that would be best for all to start and test with until a much easier method can be adapted. I had read elsewhere that the android method had been tried using the linux methods and it did not work. Hence why I havent looked as deeply into it. But I think at this point it seems like looking at this with a mixed methods might be the better approach. I'll post my results tomorrow as I am trying this out now.
UPDATE: I got some promising news. I am following this guide I have built android according to those instructions. http://www.arndaleboard.org/wiki/index.php/WiKi#How_to_Flash_a_Device (ignore the dipswitch references here as we got the ctrl-U option to boot and devmode)
The uboot install part is automated via a script which saves some time. Easy enough to break down the script to see how its done manually. The build will have 4.1.1 That said arndale provides pretty much all the tools to do this simpler. I think if we get this working then all we need to do is further automate the process OR provide an image with a simple script to image an SDcard with. Additionally I suspect (I have not confirmed) that the wifi and other components on the arndale are also the same on the chromebook.
Hmm, I wonder if the uboot from the arndale board will work on the chromebook? The chromebook's uboot doesn't have fastboot, and there's no way to interrupt it either (as in, hold down a key to access the uboot menu). BUT, if we put the arndale's uboot on the sdcard, as in, this:
http://www.arndaleboard.org/wiki/index.php/WiKi#Prepared_micro_SD.2FMMC_for_ARNDALE_bootable.
...that looks rather promising.
Yea that was the idea and portion I was looking at. I'm trying it out now to see if this will work.
I thought something similar might be done with Plop, the most awesomest boot loader in the world when Chrubuntu was first finding it's feet. Booting into a bootloader might be the answer for not just Android, but Windows 7.
But this is booting on ARM. So Win7 would not work here as there is no ARM capable version. The work now is being done for the Samsung Chromebook ARM version (series 3) which would also work on the Acer version that is also ARM based as well.
Nuh uh, Acer C7 is x86 based. RT can play on ARM, but a Chrome bootloader might be worth it.
You are correct sir on the Acer being intel. That being said. This project is to get android on the samsung chromebook (series 3) which is an arm EXYNOS 5xxx series CPU. The methods developed here would also likley apply to any other arm based books on the market.