Related
In response to d_dan's thread I have decided to start putting together a glossary for android related terms/abbreviations. Feel free to reply with ones you would like added/modified as the list I'm beginning with is rather short. I will monitor the thread regularly and incorporate them into the original post, contributions will be duly credited.
GLOSSARY:
adb : Android Debug Bridge, a command-line application included in the SDK. Allows you to run certan commands on the phone from your computer over USB as well as pull/push files.
BART : Backup And Restore Tool, similar to Nandroid but with more customization options for advanced users.
Cook : To create a ROM for a certain device.
Emulator: A program that pretends its certain hardware/software running on another device.
Flash : To write a ROM/Radio/SPL/etc to a device.
Nandroid: A backup/restore tool that creates an image of your phone's software guts which can be reapplied if something goes wrong.
Radio : Clarification on this requested, I know it has something to do with the connectivity to your provider. WARNING: Mucking around with it can brick your phone in certain situations!
recovery: Booted into by holding the "Home" button while booting the phone, a custom recovery image allows Nandroid backups, console access, wipes and much more.
SDK : Source Developer Kit, Contains tools to create things for Android, also includes adb and an android emulator.
SPL : Secondary Program Loader, loads the android OS. WARNING!: Mucking around with it can brick your phone in certain situations!
Terminal: A way to run certain commands on your phone, like CMD on a windows platform.
Much appreciated.
Thanks
Correct me if im wrong, the radio is the Baseband Firmware, and serves as the IPL, or Initial Program Loader, which initiates the SPL, aka Secondary Program Loader...
-BMFC
Sent from my T-Mobile G1 using the XDA mobile application powered by Tapatalk
spamcakes said:
SDK : Source Developer Kit, Contains tools to create things for Android, also includes adb and an android emulator.
Click to expand...
Click to collapse
SDK traditionally stands for "Software Development Kit". The Android SDK provides the tools necessary to debug various android components, as well as a handful of pre-compiled libraries which are primarily used in developing applications.
Also, the words "Cook", "Chef", "Baked", "Cooking", "Kitchen", and "ChickenWings" should be avoided.
We have SOURCE, we do not need to "cook" anything, we can build the platform the same way the carriers do.
ctso said:
Also, the words "Cook", "Chef", "Baked", "Cooking", "Kitchen", and "ChickenWings" should be avoided.
We have SOURCE, we do not need to "cook" anything, we can build the platform the same way the carriers do.
Click to expand...
Click to collapse
Although ports have some heavy-ass cooking going on
So many htc phones would be better with sense source. (that example of sense because it's the most popular redo of android these days)
Also, a thread like this shouldn't be in "chef central" because people in here should already be chefs, amirite?
But otherwise, I love this concept.
Edit: and honestly, I'm cool with those cheesy terms because they were made and developed on XDA, so thats good stuff.
What about terminal commands or whatever they are called?
Great idea. I've been lurking for quite some time now. Most of these terms I have been able to figure out without this glossary by continuing to read, read, read and search, search, search. The term I have not been able to figure out is odexed/deodexed. Anybody who could help me with these definitions will be greatly appreciated.
Edit: Please disregard my question. I was finally able to find a helpful post on the subject.
Alright, now that Adamoutler finally posted (I was waiting on that) I can now explain what we're going to try to do. You all know the unbrickable mod for a few samsung devices? The guy who did that wants to help us out but he needs a nook tablet. Anyway, what it does is completely disable hardware security and allows the flashing of a new bootloader. That's about as simple as I can make it. I would love to see this happen so hopefully, we can make it.
Question is, who's giving up a tablet?
Note:
Code:
This is not a thread to come in and complain saying that you're going to take it back. That's not our problem nor is it our concern. We need a place where we can have organized information about the bootloader and you telling us "I HATE IT, I need to return it!" doesn't help that.
If someone (me) wanted to get involved in this, how would I go about doing so? I know enough about linux, but nothing about Android programming. Is there somewhere I can start learning? I'd like to contribute to this if I am able.
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
hobbit19 said:
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
Click to expand...
Click to collapse
According to information from TI about the M-Shield security features of this chip, the "secure on-chip keys (E-Fuse) are OEM-specific, one-time-programmable keys accessible only from inside the secure environment for authentication and encryption". Protecting against that kind of key replacement is a big part of how this chip was designed. Finding out the private is likely to be the only way to create valid signed images of our own
Here is the source for that quote.
Indirect said:
Botnets are typically used under illegal reasons / methods. Im not talking about [email protected], im talking about stormworm, etc.
Sent by breaking the sound barrier
Click to expand...
Click to collapse
I know what you mean, but what _I_ mean is that botnets CAN be used for other things than illegal hacking and malicious intent. They can replace a supercomputer, as [email protected] proves. I think I have seen a similar initiatives for cancer research and DNA research, though I don't know the names of those projects.
notes
Hopefully this doesn't lead to any red herrings. I haven't been looking at this stuff very long.
"arm.com" has some info on the processor.
TI licensed the processor design from ARM. It's an ASIC, not really a cpu chip.
You have to agree to a non-disclosure to see the docs on arm.com.
After reading about it, not sure that the dual cpu is actually getting used like folks think. There may be two systems actually running.
The arm docs hint that it may be the hash key that actually gets stored on the asic not a private key and that there may be more than one. TI may have designed in their own protocol which is the M-Shield trademark.
TI doesn't exactly give out much info on it. The ARM site is a lot more informative. It doesn't cost anything to access it other than giving away your email address and agreeing to the nondisclosure.
In particular look for these documents:
DDI0406C_arm_architecture_reference_manual.pdf
DEN0013B_cortex_a_series_PG.pdf (chapter 26)
PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
You can also review the source code for the tablet.
See the following exerpts:
distro\x-loader\lib\board.c
image.image = 2;
image.val = 99;
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK , 1 , &image );
if ( image.val == 0 )
{
/* go run U-Boot and never return */
printf("Starting OS Bootloader from %s ...\n", boot_dev_name);
((init_fnc_t *)CFG_LOADADDR)();
}
distro\u-boot\common\cmd_bootm.c
function do_bootm
...
U32 SEC_ENTRY_Std_Ppa_Call (U32 appl_id, U32 inNbArg, ...);
\x-loader\board\omap4430sdp\omap4430sdp.c
...
There are several calls to the SEC_ENTRY_Std_Ppa_Call function.
One (or two) for each image block being loaded.
I think these are the calls to the security layer..
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK ,...
They took the crc32 validation out in various places in the code. I suspect that if it is a signed key that if the image doesn't process out to the end key, then the crc2 would have failed anyway.
Has anyone actually checked what the "key" is? Could it be a crc or checksum?
The "_BN_" I assume is for barnes and noble.
Looking at "omap4_hs.h", it looks like that function can do a callback into the secure area and execute up to 32 different functions, though I'm guessing from the list in the file that BN only added two - INIT and CHK.
There is also a reference in that file to "Development CEK". Could this be the private key? Not the hash, just one part of the key? I'm by no means up on crypto algorithms.
/*
Defines from MShield-DK 1.2.0 api_ppa_ref.h
Make sure these align with the existing services in PPA.
*/
// Number of APIs
#define NB_MAX_API_HAL 32
// command / api keys
PPA_SERV_HAL_CPAUTOLOAD
PPA_SERV_HAL_CPINIT
PPA_SERV_HAL_CPSWRV
PPA_SERV_HAL_CPMSV
PPA_SERV_HAL_CPREPORT
PPA_SERV_HAL_CPCEK
PPA_SERV_HAL_TEST_API
PPA_SERV_HAL_BN_INIT
PPA_SERV_HAL_BN_CHK
/* Development CEK */
#define CEK_3 0x01234567 //127_96
#define CEK_2 0x89ABCDEF // 95_64
#define CEK_1 0x11121314 // 63_32
#define CEK_0 0x15161718 // 31_0
Another question I have, what level of GPL does android use?
The simple fact that they linked in the M-Shield function calls may be enough to force the release of that source as well. The latest GPL has a pretty nasty copy left. It may be in that archive already too. I haven't gotten through much of it yet.
And is it true that this tablet has a different wifi chip and thus doesn't have the fm and bluetooth available to it?
The brute force idea might work except that you'd have to do it on a nook tablet. You have to validate a data block using that function call.
Figuring out how to automate it through that security layer might be a bit troublesome. If you could call that function directly, maybe, but I suspect that it is only accessible from one side of the architecture. But that might also be why the tablet has so much memory dedicated to B&N and not split evenly. Maybe the bigger chunk of the memory is all in the secure side?
I have to say the OMAP4 is a pretty neat layout. Has a huge potential for corporate ethical abuse but technically it really is cool. They are going through a lot of hoops to keep this tablet locked down. I found one whitepaper on the netflix issue. Netflix apparently has a whole massive requirements list and this was the first tablet to meet it. I'm not sure netflix isn't overvaluing their product. There are other ways they could have done this versus locking the whole tablet down. They could have put the netflix app as a service in the secure side and just signed that part of the application. They could have still allowed the secondary bootloader in the unsecure area to be whatever the user wanted. I don't think they thought through the ethical notions of it all. But maybe they did and they just want to control something like apple is doing. Apple was defeated once by a lower cost, open architecture. History will repeat itself. It's a shame B&N's didn't go that route instead. If it wasn't for this one issue, they would have had a much better platform to work from than the fire.
Asking others for the info / ideas on bootloader isn't related to development. Hence moved to general
cheers,
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Adam, I can try and get you a nook tablet.
Also, I was waiting for you to post that. I wanted to leave this up to the community to see what could be thought of. Surprised hardware modification never came up. :|
AdamOutler said:
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I figured youd be here when the final specs on the Nexus Prime were released, and they used the OMAP4460 which is ironically very simmalir to the OMAP4430.
Thanks for your help and let us know if theres anything we can help you with.
Just for your all's information, Adam will have one in a day or two it has already been shipped.
AdamOutler said:
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
The fast external boot is a special memory booting mode, possible only on GP devices. It consists of a blind jump to a code in an external XIP memory device connected to GPMC CS0. Fast external booting is set up by means of the SYSBOOT configuration pins and lets customers create their own booting code.
Click to expand...
Click to collapse
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Hardware mod
JoeM01 said:
Can this in fact be replicated by someone who is NOT necessarily a dev, but isn't afraid of cracking open a device and going to work with a soldering iron?
Click to expand...
Click to collapse
It depends ...
Assuming for the purpose of discussion that all you need to do is (un)ground an external pin, the difficulty can range from:
Getting access to a ball-grid-array device on a multi-layer board (effectively impossible).
Lifting a pin on a surface-mount chip (easy with the right tools and some skill).
Cutting a trace or soldering a jumper (easy with the right tools and some skill).
(Un)grounding at a solder pad pair (easy).
While the last is not likely, it happens. A case in point:
When IBM released a parallel port board for the original IBM PC, they also released the schematic in the technical reference manual for the PC. The schematic showed that the data buffer buffer chip was bidirectional (74LS374), but its ^OE (output-enable) pin was grounded (active-low logic), in effect making the parallel port output-only.
When the clone-makers replicated the parallel port from the IBM schematic, they all replaced the 74LS374 chip with one that was not bidirectional (a 74LS274, as I recall), saving a tiny bit of money.
However, you you actually had one of IBM's parallel port cards, you noticed that the ground trace on the 74LS374 was not grounded next to the chip (as would normally be expected), but ran a couple inches across the board to a "via", and then grounded in a short trace run. That "via" was exactly 0.1" away from another "via" that was connected to an "unused" bit on the control chip. In other words, a simple trace cut of the final ground run, followed by the installation of standard 0.1' spacing header pins (or a simple jumper) at the "via"s, would convert the parallel port to be bidirectional. Which I did at the time.
Several years later, when IBM modified their BIOS to support bidirectional parallel port operation, they introduced a new parallel port card. The above modification to the old ones worked, but all the clone parallel cards were obsolete.
So, I would not put it outside the realm of possibility that B&N provided a solder pad to be able to disable the signed bootloader feature.
I would also not put it outside the realm of possibility that instead, the hardware modification is very, very difficult, even with the right tools.
Then there is the software issue still to be fixed. Certainly worthy of investigation, but don't get your hopes too high (especially before Christmas).
The best way to think of this hardware unlock, is that the nook is like a building, there are lots of rooms we can get into, but there are also rooms that we cannot. What I assume is adam will get into those rooms, and there might be ways to turn off the power to certain rooms, and or put something in the water. This might allow us to make a software mod that will effect the rooms .
rooms .
pokey9000 said:
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Click to expand...
Click to collapse
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Doing the memory dump now.
Got this error on the first one:
[INFO] Reading 49152 bytes at 0x40030000...
[1] Bus error viewmem 0x40030000 0xC000 >/sdcard/40030000Dump
Only the 2nd one dumped properly.
http://dl.dropbox.com/u/15069134/40028000Dump.zip
AdamOutler said:
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Click to expand...
Click to collapse
Adam,
If no one has done this by the time i get home, I will do it for you. I will be on IRC tonight for some of the night and will be able to do whatever you need.
I just did it loglud, no worries.
I'm seeing the following strings in the boot dumps:
Code:
pGpGpGpG
@ABCDEGKJ
CHMMCSD
CHFLASH
CHRAM
PRIMAPP
X-LOADER
CHSETTINGS
KEYS
ISSW
It's not much to go on, but I'd expect to see something on UART from this.
Both of the files are the same. 49.2kB. http://dl.dropbox.com/u/15069134/40028000Dump.zip
however, those are just the complete strings... there's more..
Code:
Texas Instruments
Nokia
Motorola
OMAP4430
NOKIA USB ROM
BLANK
OMAP4430 N/A
N/A
PCB
PCI
R&D
2nd
CH
HLO
MLO
ULO
This NOKIA USB ROM looks interesting.
That's so strange i wonder what it is pointing to because from what i see there's no a single Nokia part in the entire device. You think its just the rom driver they use to flash the OMAP's Rom?
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.
Hi folks.
I'm an Android firmware developer (you can see my posts here in xda) that got a yoga book yesterday. For me it works at it should (by now) but my hacker soul speak to me and said: "at least take a look to see what you can get from this device". I don't have many time, so I can't spend time doing roms or fixing things by myself, but I can share with you some info I get and help you with my knowledge if someone is interested in "play" with this device.
First of all, I'm not responsable of anything that you can break following these steps. Almost all of them are tested and with some common sense you will not break anything, and if you break anything I will try to help you to fix it (if you are polite), but this is a work in progress and hacking and the possibility of brick the device is always there.
I only have the Android version without LTE, so I only tested in my Book.
So, here we go:
1) Secret codes:
I get this codes decompiling EngineeringCode.apk with apktool. Be carefull with them:
####0000# - Display version info
####7599# - Display hardware info
####8375# - Display baseband info
####1111# - Factory test
####2222# - Display SN
####7777# - Factory Reset???
####5993# - Display internal frameWork version
####7642# - Cut the power off to reload the PMIC - This command shutdowns the device. Just press the power button to reboot.
####5236# - Display LCD name
####2834# - ES close test
####8899# - open the ums mode default for debug
####3333# - offline log
####3334# - offline modem log
####9527# - Mediaplayer setting
####78646# - RunIn test
####6020# - switch country code
####59930# - Display current country code
####8746# - Enter engineering mode
####4227# - Enter engineer test
####357# - DLP_TEST
To use these codes, open the contacts app, press the search button and enter the code in the search bar.
2) OTA Images
You can get OTA images directly from lenovo servers. Just open your browser and paste this url:
http://fus.lenovomm.com/firmware/3....WW06_BP_ROW&action=querynewfirmware&locale=en
Change device model if needed (LenovoYB1-X90F or LenovoYB1-X90L)
Change curfirmwarever to a valid OLD firmware, this way you will get the next one in age.
Change locale if needed.
With this url you will get a download url at the end of the result page. In this case: http://tabdl.ota.lenovomm.com/dls/v...S000426_1705080316_WW06_BP_ROW_WC80C2A0F2.zip
These images are not full ota images, they are diff versions. This means that we can't use them to mod the image, or recover a bricked device, but this is a first step
3) Custom images
We don't have real sources to build a custom image (the lenovo's open source files are useless), but this doesn't mean that we couldn't modify stock images to take out useless apks or get better performance.
We can get this using an Android Kitchen and a full update image for the device.
As Android kitchen you can use SuperR kitchen (https://forum.xda-developers.com/ap...chen-superr-s-kitchen-v1-1-50-v2-1-6-t3597434)
As full image, I only tested the one here (https://easy-firmware.com/index.php?a=browse&b=category&id=19521) because I can't download any newer one.
I tested uncompressing it, deodexing the apks and doing a new image. But I don't test it in the device because I need to install twrp to flash the new image and I don't have time to test. But this should work, I did it many times so if someone is interested I can give steps to do it and support for testing.
If someone can get the latest full images, send then to me and maybe I can get some time to do some tests.
PD: Probably we could use this as a base to get LineageOS 14.1 working: https://github.com/latte-dev/android_device_xiaomi_latte/tree/cm-14.1
So, if you are interested in some hacking with the Yoga Book, contact me and we could team to get the most of this device.
First of all thank you for your post, it´s really useful
if you could somehow manage to boot windows on this machine it´s by far the greatest war we have right now.
Il promise you a lunch or dinner on Lisbon whenevere you want!
joao1979 said:
First of all thank you for your post, it´s really useful
if you could somehow manage to boot windows on this machine it´s by far the greatest war we have right now.
Il promise you a lunch or dinner on Lisbon whenevere you want!
Click to expand...
Click to collapse
Sorry, my knowledge of Windows is only user level . Install it in personal computer to play games .
But I really don't know why people wants to run Windows there, it will go slowly than Android and its less touch oriented... but I suppose that this is a chat for another thread
corvus said:
Sorry, my knowledge of Windows is only user level . Install it in personal computer to play games .
But I really don't know why people wants to run Windows there, it will go slowly than Android and its less touch oriented... but I suppose that this is a chat for another thread
Click to expand...
Click to collapse
in my particular case, i´l admit that is for football manager the touch version
joao1979 said:
in my particular case, i´l admit that is for football manager the touch version
Click to expand...
Click to collapse
Have you tried running it through Crossover? It may be in its infancy but i have got a few apps running OK with it.
I have the full "YB1-X90F_USR_S000196_1611040312_WW06_BP_ROW" I can upload somewhere if anyone can suggest a good site to do so without signing up? The file is about 2.5gb
It will be great if we could get the latest version, because maybe these older versions have older files that we have updated in our tablets.
Mixing files could give unknown problems
The current TWRP is based on the new Yoga Tab 3
I am starting to think they do not do full roms for this in the same way they do for a lot of their other devices.
We know the otas are available from tabdl.ota.lenovomm.com/dls/v6/ and are named according to the 2 builds that it bridges. As easy-firmware had the december full rom under the file name B1-X90F_USR_S000196_1611040312_WW06_BP_ROW-flashfiles.zip I had hoped that I could work out the file path to pull it down.
There were some interesting ideas here, https://forum.xda-developers.com/android/help/how-download-stock-roms-lenovos-ota-t3109507 but it seems there is a difference between phonedl.ota and tabdl.ota
Queries to full roms that work for phones, don't seem to work for the yoga book.
Anyone with more web knowledge able to pick this up? I am not sure the files are there but I feel they should be.
Good luck
Update: the downloads seem to be hosted via CloudFront. An Amazon service, but I can not find out a way of listing the available files. The latest full rom would be
http://tabdl.ota.lenovomm.com/dls/v6/YB1-X90F_USR_S000426_1705080316_WW06_BP_ROW_WC80C2A0F2.zip
But the Last 8 chars are random and we do not know what they are.
So we have two hopes. First work out the right query to the link from fus.lenovomm.com or two find a way of listing files available in tabdl.ota.lenovomm.com/dls/v6
Not sure I have got much further but ill keep trying when I can.
Hey, I should mention that I have some files that you may find helpful; I got them from the easy firmware website. They're all the .img files for each partition in Android (ie. boot.img, cache.img, config.img, factory.img, recovery.img, system.img) as well as: biosupdate.fv, bootloader, firmware.bin and gpt.bin. However, these of course aren't in the normal "flashable .zip ROM" format. So unless you know how to take apart these .img files they aren't very useful. If you need any more help or have any other questions about how far we've come on our own, feel free to ask. danjac also has great knowledge of our efforts.
Yes, I know how to use them, unpack, modify, etc. But what I want is the latest version, no a old version (I hav these files too). If you have them I can do some changes, debloat, etc.
Anyway, I see little interest in custom roms in this forum ( probably because it's not a device with a lot of users or the users are not the techy kind), so I prefer to help others with info than do a custom rom that only 2 or 3 people will use. Doing custom roms is a time hungry task and probably it doesnt worth the effort. Anyway this device is not full of bloatware like samsung ones, so it useable as it is.
As I said in my first post if anyone is interested I can give some hints and support to modify the full image (but only the latest one).
It's so sad that there are only a few interested owners of this tab - it's such a nice device but i fear the day lenovo decides to end their support for it. There will be no custom roms to switch to and keep the device alive - it will be a soon to be bit of old tech garbage BTW. I still use my Asus Transformer Prime because of the nice community
@NiffStipples I fully agree. This device is so powerful and its a suprise that it is invisible to the "market". In my humple opinion the normal ROMs aren't that bad besides missing updates but I would love to see all the power served through a custom rom. unfortunately programming is not my business
Stefan
Broomfundel said:
Have you tried running it through Crossover? It may be in its infancy but i have got a few apps running OK with it.
Click to expand...
Click to collapse
Interesting - is Crossover good (and does it require factory reset)?
Hi, It works well with some things and not others. Often the why and where are not obvious. It is basically "wine" the layer that allows some windows apps to run on a linux install. Tweeked to work with android. Just an install to put crossover on. Then another install (Within crossover), to put you app on crossover. If it doesn't work out of the box, there windows libraries you can switch out and dependencies you can install. (Eg: directx , .net) Even if your not technical. I would say get on the beta program and give it a try.
Hi! what do you mean by "lenovo's open source files are useless"? do you refer to this packet on lenovo's suppport site? download.lenovo.com/consumer/open_source_code/lenovo_yb1_x90f_l_osc_201608.zip
I've entered the Android YogaBook's BIOS and noticed that VT-X is enabled by default! With Limbo x86 we could get a fully working virtualized Windows or Linux, if it wasn't for... KVM. It seems like it's not enabled in Lenovo's default kernel. Could we get to recompile the kernel with this option on? i'm not a big android/ROM expert but i surfed the open_source_code folder from Lenovo and it seemed, to me, that we could rebuild the Kernel at least.
This could really change things!
morrolinux said:
Hi! what do you mean by "lenovo's open source files are useless"? do you refer to this packet on lenovo's suppport site? download.lenovo.com/consumer/open_source_code/lenovo_yb1_x90f_l_osc_201608.zip
I've entered the Android YogaBook's BIOS and noticed that VT-X is enabled by default! With Limbo x86 we could get a fully working virtualized Windows or Linux, if it wasn't for... KVM. It seems like it's not enabled in Lenovo's default kernel. Could we get to recompile the kernel with this option on? i'm not a big android/ROM expert but i surfed the open_source_code folder from Lenovo and it seemed, to me, that we could rebuild the Kernel at least.
This could really change things!
Click to expand...
Click to collapse
How did you enter the bios? Can you boot from usb?
anyone managed to use swiftkey keyboard?
.
Hi forum!
So I own a Project Tango Development Kit Tablet (device name: Yellowstone) which appears to be a Tango-purposed Nvidia Shield K1 tablet. There's just a few threads about the yellowstone in the Shield forum and it's an old device now, that's why I'm posting the question here, in the hopes that the question is not device-related but something more general.
So, I wanted to use this tablet and the stock ROM just made it bootloop ad infinitum. Nothing I did could make it boot. So I went to the Shield forum and I found a TWRP image that would work on it. I rooted it, installed TWRP and I installed a ROM that I found around an old thread. So far so good, the tablet now boots but the audio, microphone and camera doesn't work. I want to use it as an intercom system so, that's the stuff I really want it to be in a working state.
By chance I found a LineageOS 16 ROM for the yellowstone (https://updater.oddsolutions.us/yellowstone) but it's description says "PSCI Repartition ONLY". The author hasn't replied to me to what it means. Googling doesn't give useful results regrettably. So I wonder if anyone around this parts could enlighten me about what is it, and how can it be performed?
Many thanks!
REPARTITION ONLY:
I guess it means that /system and /vendor partitions must get re-partitioned ( increasing their sizes ) what must be done before flashing the ROM.
This usually is done by a "Repartition Pack".
PSCI:
The Power State Coordination Interface (PSCI) is an ARM standard introduced for its new ARMv8 64bit architecture to virtualize CPU power management across exception levels i.e. between software working at different privilege levels: OS kernel, hypervisor and Secure Platform Firmware (SPF).
jwoegerbauer said:
REPARTITION ONLY:
I guess it means that /system and /vendor partitions must get re-partitioned ( increasing their sizes ) what must be done before flashing the ROM.
This usually is done by a "Repartition Pack".
PSCI:
The Power State Coordination Interface (PSCI) is an ARM standard introduced for its new ARMv8 64bit architecture to virtualize CPU power management across exception levels i.e. between software working at different privilege levels: OS kernel, hypervisor and Secure Platform Firmware (SPF).
Click to expand...
Click to collapse
Ahaaa, that's excellent information. I guess they're separated concepts then, not directly related. I'll have to contact the owner then for the repartition pack. Many thanks!
Darius_bd said:
Ahaaa, that's excellent information. I guess they're separated concepts then, not directly related. I'll have to contact the owner then for the repartition pack. Many thanks!
Click to expand...
Click to collapse
Did you ever get a response from npjohnson? I've been folliwing his roms for tango for about a year (if not longer) he did say he was aiming to bring it as an official lineage build......but while i see it's been in development. Nothings been released.
So i am interested to know if you got a response.
Darius_bd said:
Ahaaa, that's excellent information. I guess they're separated concepts then, not directly related. I'll have to contact the owner then for the repartition pack. Many thanks!
Click to expand...
Click to collapse
I also am interested in whether or not you found the PSCI for Android 9. I have a Tango I am wanting to put to use.