Related
Hello-
I am new to the boards as a poster, i've been reading for a while now and I must thank everyone especially in the development section of the forum for their incredible amount of help and expertise.
It has officially come time for my first noob question-
Can anyone help me out or lead me to a guide perhaps that will allow me to use OpenOffice on my webtop? This is really what I bought the lapdock for-it just came in yesterday.
I managed to get webtop2sd working on my own, lxterminal is functional. That's all I've got so far in fear of ruining anything else.
I'm not at all well-versed in any linux script or anything of the sort. I know windows like the back of my hand.. just so happens that my windows PC totally bit the dust(motherboard) last night and I'm forced into learning this stuff a little quicker. Why not, right?
I have done some searching, all of it leads me to a bunch of lingo and commands I don't understand yet. If anyone can point me in the direction of some help or provide me with a little one-on-one that would be awesome. I'm looking forward to helping others with these kinds of issues down the road.
Thank you!
---------- Post added at 11:06 AM ---------- Previous post was at 10:58 AM ----------
Also, I'm not sure if it's any help, but i'm running GB on Alien #4 with faux123's undefined 1.3ghz kernel.
See "EASY METHOD" in the original thread: http://forum.xda-developers.com/showthread.php?t=1093790
Assuming you have webtop2sd and the linux addon installed properly
(with the linux image on your external SD), do the following:
1) Click the Penguin. You will get a window that says it has found an image in you external SD card.
2) Simply press "okay" on that window.
3) Once it shows the Pdmenu, select DebianMenus>Applications>Shells>Bash. it will bring up an xterm script which reads "[email protected]:/#"
4) To get open office, you must type "apt-get install openoffice.org" without the quotes.
5) Agree to install/update, and it will read "[email protected]:/#" once it is done.
6) At this point, and from now on, you can do steps 1-3 and simply type "openoffice.org" into xterm. It will take a second, but it will load a fully functional OpenOffice.
Basically you just need to know the package names to use this same structure for other programs. I use "openoffice.org", "iceweasel" (a firefox alternative, since my firefox keeps breaking), and "geany" (a C++ IDE for my programming classes). These are installed using "apt-get install packagename" and run using "packagename" in the bash script as well.
Good luck, and PM me if you have any problems because I likely will forget to return to this thread. Hit that thanks button!
-omni
Follow the guide in Alex's thread in the dev forum. I just installed open office yesterday haha.
Sent from my MB860 using XDA Premium App
+1 to both of you, I'll get started on that and hopefully that will open doors for the rest of the stuff. Thanks a ton
Hello again all-
I didn't want to be that guy posting 95823094820394 threads about the same thing so I just figured I'd bump the one i created with some explanation:
I have webtop2sd properly(i believe, anyway) installed. LXterminal is functional. I also have linuxdisk in sdcard(-ext)/WebTopMOD . I'm not sure what to do from here. the help given above gave instructions to click the penguin while in webtop and run certain commands, but the penguin only brings up the webtop configurator. i have no other icons to click.
My goal, again, is just to get open office running on my webtop, for now. That's really it, the rest i'm sure will come with time. Thank you again for any help.
I seem to have figured it out for the most part using Alex's guide. However, the installation threw a couple errors, couldn't really tell you what they were because they were epic and I'm clueless as far as linux for the time being. However, my educated guess and deduction points towards insufficient memory. I set up my webtop partition to be 1GB, because I'm using a 16GB sd card that's virtually full of music. Is 1GB skimping it if I want to install openoffice/other linux packages? What size partition is recommended?
Thank you!
4GB is recommended, though I would think based on the package sizes that openoffice.org would squeeze into a 1gb partition. With this phone I would definitely recommend an external SD. My 32GB holds my webtopmod, music, and every hack, mod, bootanimation, theme, kernel, radio, and zip I've ever flashed. Do it.
Also openoffice worked, But i think it dosent match the atrix ubuntu core perfectly.
An error name:"openoffice Writer2laterx dose not configured" happened again and again.
omni_angel7 said:
4GB is recommended, though I would think based on the package sizes that openoffice.org would squeeze into a 1gb partition. With this phone I would definitely recommend an external SD. My 32GB holds my webtopmod, music, and every hack, mod, bootanimation, theme, kernel, radio, and zip I've ever flashed. Do it.
Click to expand...
Click to collapse
i am using an external SD, a 16 GB one. i'm about to make a 4GB partition and start from scratch. eventually, i'm picking up a 32 no doubt.
After making a full re-installation of everything I can't get open office to install? I tried both via terminal and Synaptic both fail with error messages.
"dpkg error processing tzdata" Error code (1) error in package
Any ideas?
Cheers
pederb said:
After making a full re-installation of everything I can't get open office to install? I tried both via terminal and Synaptic both fail with error messages.
"dpkg error processing tzdata" Error code (1) error in package
Any ideas?
Cheers
Click to expand...
Click to collapse
my guide links a fix for that, but I use a different method than the one previously posted
http://forum.xda-developers.com/showthread.php?t=1397583&highlight=guide+webtop
Thxs, I will check it out
Cheers
Cant open files from sdcard
Hello, I finally got openoffice installed, but I dont know how I can open files located in my sdcard. Can anyone please help me with this?
Hey guys.
So in the last couple months I ported the encore u-boot menu/console/configuration stuff over to acclaim (Nook Tablet). The acclaim really needed the menu plus had a ton of "2nd bootloader" issues that needed to be addressed to fix the locked bootloader bug. On nemith's suggestion, the u-boot really isn't just for cm7/9 (it can be used with any OS), so I called the newer bootloader, "CyanoBoot". Kind of a working title until I think of something better.
In the process of the acclaim port, the UI menuing interface was rewritten and some small features were added.
Anyhoo... Last night on a whim I decided to port the improvements back to encore's u-boot. So there's a version now for encore as well so that NC can enjoy the UI benefits.
It's similar to the acclaim version, minus fastboot (which we don't need, since encore doesn't use dedicated boot and recovery partitions) and minus a 'clear bootcount' setting since, well, development is up to speed w/NC that such a feature seems not necessary.
That said, here's the new stuff:
new exciting splash
Indicator in top left. "E" means u-boot is loading from emmc. "S" means it's loading from Sdcard.
Additionally you can now see the system's "boot count" - the number after the indicator described above. If this count goes up, your boot count is not being cleared as it should be.
Instruction to "hold down "n" for menu"
boot menu is way easier to use, clearer, and uncluttered.
all the old stuff is there (Nook Color Tweaks' boot settings), combo keys, etc.
If you feel bold and are willing to risk everything, give it a try and let me know if you run into issues. Think of this as an alpha. If people like it, I'll push it to the repo as the default.
To install: It's just "u-boot.bin", and it goes in the first partition of your SD or EMMC. Make sure you have a good backup in case things screw up.
NOTICE: CYANOBOOT (WORKING TITLE) IS HIGHLY EXPERIMENTAL AND IS NOT INTENDED TO BE USED BY NON-DEVELOPERS AND/OR THOSE UNWILLING TO ACCEPT FULL RESPONSIBILITY FOR ANY UNTOWARD CONSEQUENCES OF USING (OR ATTEMPTING TO USE) THE SOFTWARE. ALL SUCH ACTIVITY MUST OCCUR *ENTIRELY AT YOUR OWN RISK* AND YOU ACCEPT ALL CONSEQUENCES FOR DOING SO. THE USE OR ATTEMPTED USE MAY HAVE UNINTENDED RESULTS, INCLUDING BUT NOT LIMITED TO LOSS OF DATA, DAMAGE TO HARDWARE, AND/OR EXPLOSIVE DIARRHEA. CYANOBOOT IS NOT ENDORSED, AFFILIATED, SPONSORED, NOR ASSOCIATED WITH THE "DAS U-BOOT" PROJECT, GOOGLE, BARNES AND NOBLE LLC, TEXAS INSTRUMENTS, DENX., NOR ANY OF THEIR PARTNERS, OWNERS, EMPLOYERS, AFFILIATES, CLIENTS, SUBCONTRACTORS, OFFICERS, DIRECTORS, ADMINSTRATORS, INFORMATION PROVIDERS, ETC. EXCEPT INSOFAR AS THEY HAVE PROVIDED AND LICENSED SOURCE CODE TO BE FURTHER MODIFIED AND DISTRIBUTED. SEE THE RELEVANT GNU PUBLIC LICENSE FOR LICENSING DETAILS AND OTHER DISCLAIMERS. THIS SOFTWARE IS OBVIOUSLY INTENDED FOR USE ONLY BY THOSE WHO ARE AUTHORIZED TO DO SO.
Aside from thanks mentioned in the acclaim thread, I want to add thanks to hacdan and racks for testing for me on emmc and sd.
Seriously though, as opposed to the acclaim version that was in development for weeks, this has been tested for like an hour. On the other hand I actually have a device to try it.
Update March 28, 2012
So thanks to some hard work from tonsofquestions, we've got a new version with some very cool improvements!!!
New Stuff
* The UI now dims out any option in the menu that isn't available
* some nice code refactoring that I was too lazy to do
* the "altboot" button combo (up and down volume keys) will now choose regular boot if altboot is set as default (and vice versa)
* You can now enable a previously "hidden" menu option (plus a second configuration menu) by doing the following commands:
adb shell echo "0" > /rom/u-boot.altboot
adb shell echo "0" > /rom/u-boot.device
This unlocks a "built-in" default menu, effectively doing the same thing as the Tablet Tweaks build options, only right from u-boot itself!
Please test from various configurations (emmc/sdcard/normalboot/altboot/etc/etc)... I haven't tested this one as thoroughly.. or really thoroughly at all. And thanks to tonsofquestions for the contribution!
updates:
9/20/12: Two minor fixes...
9/19/12: Moved to a new repository at nookiedevs.
3/28/12: New features from tonsofquestions. See update notice above.
3/16/12: Clear the "Push n for menu" message on screen once boot has been determined.
cyanoboot-12-9-20.tar.gz
(source)
Another post.
Dumb question, I don't see a u-boot.bin using Root Explorer looking in root. Shouldn't there be one there that I am replacing with this new one? Or just copy it in there and reboot?
911jason said:
Dumb question, I don't see a u-boot.bin using Root Explorer looking in root. Shouldn't there be one there that I am replacing with this new one? Or just copy it in there and reboot?
Click to expand...
Click to collapse
It would go in /boot-- or partition 1. On emmc it looks like: /dev/block/mmcblk0p1 on SD it's /dev/block/mmcblk1p1.
There should indeed be one there already. Along with uImage, uRamdisk, etc...
it's not usually mounted by default. One way to access it is to use these commands from your computer:
$ adb shell mkdir /data/mnt
$ adb shell mount -t vfat /dev/block/mmcblk0p1 /data/mnt
$ adb shell cp /data/mnt/u-boot.bin /data/mnt/u-boot.bin.old
$ adb push u-boot.bin /data/mnt/
$ adb reboot
$ is the prompt, of course. Here's what they do:
1. make a "mount point" (a directory) at /data/mnt so that you can
2. mount the vfat boot partition (p1) at that mount point. Then,
3. backup your old u-boot.bin in case this one is deeply flawed
3. push your local copy of u-boot.bin (CyanoBoot) on top of the old one, and
4. reboot and hope it doesn't crash.
Good luck, and my apologies in advance if/when this screws up. Remember, you are assuming all risk here
(you can also do it by loading clockworkmod, mounting boot to /boot and then backing up and/or pushing u-boot.bin to /boot)
911jason said:
Dumb question, I don't see a u-boot.bin using Root Explorer looking in root. Shouldn't there be one there that I am replacing with this new one? Or just copy it in there and reboot?
Click to expand...
Click to collapse
its in the boot partition
Works like a charm! Very nice!
thanks fattire, this in my opinion is much nicer then the other menu we have available to us. hope to see you polish this off
ehh, the possibilities of running 4 OS's with this makes me smile
Dropped it into one of Eyeballer's nightly opengl zips (http://forum.xda-developers.com/showthread.php?t=1526115) and it works great! Thanks fattire!
Excellent work, Thanks
Been following your development on the NT even though I don't have one. I was hoping this would be ported sooner or later.
Can someone please drop this into a normal ZIP file and put it somewhere where it can be downloaded?
Thanks....
I think the whole purpose of it being compressed in the gz format is to prevent people thinking it was an installable zip file... but I could be wrong...
To use this file google search for win-gz... a simple free gzip windows utility.
If fattire gives the ok... I will upload a rar file containing the bin file.
Additionally:
@ fattire... is it ok if I include this in my file for customizing ROM's in this post instead of the cyanogen u-boot.bin?
DizzyDen said:
I think the whole purpose of it being compressed in the gz format is to prevent people thinking it was an installable zip file... but I could be wrong...
To use this file google search for win-gz... a simple free gzip windows utility.
If fattire gives the ok... I will upload a rar file containing the bin file.
Additionally:
@ fattire... is it ok if I include this in my file for customizing ROM's in this post instead of the cyanogen u-boot.bin?
Click to expand...
Click to collapse
Sure and sure. Be sure to include the GPL notice.
CyanoBoot in RAR
Thanks to fattire for all the hard work put in for our devices... and with his ok... here is the CyanoBoot in RAR format for those that have difficulties with gz files.
I will keep this updated and named to coincide with development.
DizzyDen said:
I think the whole purpose of it being compressed in the gz format is to prevent people thinking it was an installable zip file... but I could be wrong...
To use this file google search for win-gz... a simple free gzip windows utility.
If fattire gives the ok... I will upload a rar file containing the bin file.
Click to expand...
Click to collapse
Thx Dizzy....I'll find the win-gz and use that.
---------- Post added at 02:21 PM ---------- Previous post was at 02:09 PM ----------
Works great on an SD card using CM7
Thanks Fattire!
Good to go in my opinion, great work as always fattire.. my nook and tp would be collecting dust if it wasn't for your hard work
Just since we're chiming in here, yeah looks ready to me too. I've been testing several types of software this last week, some of which require flashing and rebooting for what seems to be all day. No joke, I have probably rebooted 60+ times since I downloaded this yesterday. Multiple installations, multiple configurations. No dual-emmc, but everything else has worked great.
It has been kind of bittersweet to lose the little green box though, even to such an obvious upgrade. Despite all the crap I've tried on this thing, once that logo showed up, I knew it was gonna be okay, ya know?
I have had a totally different relationship with technology since the very first time I laid eyes on it.
Good of time as any to thank the commenters on this thread in particular.
Heh. I know what you mean re that green logo (from drakknar, btw). For me it was a HUGE battle to get a multi-colored logo to appear in the first place ...This commit and this one took many, many cycles of booting and rebooting... and trying to figure out how to get the pallette to work, etc. Before it, the u-boot could only do black and white logos (does anyone remember the "Loading..." text?) and it looked pretty awful. But nemith made a good case that for the next revision, the newer u-boot might be rebranded since it's not the start up for only CM... Still, I kept the "cyano" part in the name as a tribute...
Thanks for testing, and I'm glad y'all are having success. Maybe tomorrow I'll push to the repo.
mateorod said:
It has been kind of bittersweet to lose the little green box though, even to such an obvious upgrade. Despite all the crap I've tried on this thing, once that logo showed up, I knew it was gonna be okay, ya know?
I have had a totally different relationship with technology since the very first time I laid eyes on it.
Click to expand...
Click to collapse
Just curious: Tell me about your relationship with technology and how it's changed? I feel like the NC in the last year has really helped me to learn a LOT.
OFF-TOPIC (spoiler alert).
I got a replacement nook for the one my wife got me at Christmas last October. I was absolutely flabbergasted that they has changed the storage so that it couldn't hold the books and music I had sideloaded on the original. I looked to see what I could do, and followed directions to repartition the emmc.Flashing the ROM was an afterthought.
I didn't know before finding the info that the reader had external storage. I didn't know what an sdcard was. I had to sign up for Gmail. My last computer died because of the Love Bug.
Yes.
The only reason I registered here was because I couldn't understand why every time I tried to install the Google Music Manager .exe, it wouldn't work.
Today I decompiled a services file and edited it, so I could share it with others. I spent this evening testing a package distro system. I posted in the forum and some of the words are in color!
My wife bought me an e-reader, you know? These things you've made have had a big impact and it can't only happening to me.
Thanks fattire! Have it on my SD and it works great!
I'm not sure if this is a bug or just a user common sense issue, but if you select an Alternate boot from the menu without actually having an alternate image, the Nook freezes on "Loading AltBoot from"... requiring a hard reset.
Obviously, if you don't have an Alternate boot, you wouldn't be selecting it. But I wasn't sure if there could be a potential improvement, like if Cyanoboot doesn't detect an uAltImg, it wouldn't give it as an option?
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.
Drawing from the impressive work of CrashXXL in rooting our phones, jahrule in simplifying the process, and Sabissimo in developing a tutorial to bake in apps for those of us with locked bootloaders and write protected systems, I have with great effort arrived at this glorious day. I present to thee: Suicide Flash.
What is Suicide Flash? It is a collection of Bash scripts and other files which streamline and automate the process of using the Qualcomm emergency download mode (Qualcomm HS-USB QDLoader) to write to the system partition on Moto phones using MSM8960 processors. It applies the method used to root these devices (see here, for example) to the task of arbitrary system modification. In other words: Suicide Flash makes it easy(ish) to modify system files for those of us who can't use traditional methods.
Code:
DISCLAIMER: This is obviously a dangerous tool. I mean, it
flashes your phone by bricking it first. Be smart. I shan't be held
responsible if your phone melts, explodes, loses all of its data,
or cheats on you with a hula dancer.
Who Can Use It?
Suicide Flash is for sure compatible with most Moto X variants. The testing has been done primarily with an XT1049, the Republic Wireless model, but has also included the XT1060 (Verizon) and should work on most/all of them. However, in theory any phone, or at least any Moto phone, using the MSM8960 chip could be compatible, such as the Droid Turbo. So to simplify:
XT1049 (Moto X Republic Wireless): Tested and working
XT1060 (Moto X Verizon): Tested and working
XT1058 (Moto X AT&T): Untested, highly likely to work
XT10XX (Any other Moto X): Untested, likely to work
Others: Untested, may work as long as they use MSM8960
How Do I Use It?
Suicide Flash (SF) consists of three main scripts: a flashing script, a package creation script, and a pushing script. Details:
suicideflash.sh: Flashes SF packages to the phone in bricked (QDLoader) mode
pkgmaker.sh: For developers. Creates SF packages from system images.
suicidepush.sh: Uses the SF system to "push" system files in an ADB-like way
To use these scripts, simply extract them to a place of your convenience. All scripts must be run from the root Suicide Flash folder. Do not run any of them from within the "scripts" folder. Also, while it may not strictly be necessary, it is best (if you are developer) to include any relevant system images in the root Suicide Flash folder, as well.
As an end user, you can download SF packages created by developers and flash them using the main Suicide Flash script. As a developer, you can pull system images and use them to create SF packages with the pkgmaker.sh script. Anyone can feel free to use the Suicide Push script to push files to their device. For more information, here are the help pages for each.
Suicide Flash:
Code:
Usage: suicideflash.sh PACKAGE
Flashes PACKAGE to the system parition of a Moto phone using Qualcomm
emergency download mode.
Options:
-h, --help displays this help message
-s, --skip skips all prompts and runs without user interaction
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
Package Maker:
Code:
Usage: pkgmaker.sh [OPTION]... ORIGINALSYSTEM TARGETDEVICE REQUIREMENTS
SYSTEMOFFSET OUTPUTFILE
Creates a Suicide Flash package for writing to Moto phones via the emergency
Qualcomm download mode.
Arguments:
ORIGINALSYSTEM provides the original system image to be modded
TARGETDEVICE specifies the model of phone for the package to flash
REQUIREMENTS notes any important requirements for the phone state
prior to flashing
examples: "Stock", "Rooted", or "Rooted+Xposed"
SYSTEMOFFSET the address of the system partition on the target device
should be in hex format (i.e. 0x6420000 or 6420000)
can use value ADB to pull the offset over ABD
OUTPUTFILE the name of the Suicide Flash zip package to be created
Options:
-h, --help returns this help message
-m MODDEDSYSTEM specifies an existing modded system image
if not given, will mount original for modification
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
Suicide Push:
Code:
Usage: suicidepush.sh LOCALFILE REMOTEFILE
Uses Suicide Flash to push LOCALFILE to a phone system at REMOTEFILE.
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
What Do I Need to Use It?
A Linux installation
ADB
Fastboot
Rhino
Python
A package called python-serial
VirtualBox
ADB Insecure (if developing or using Suicide Push)
If you don't have some of these (except, obviously, the first one and the last one), you can run the included script install-tools.sh. It will automatically install anything you're missing.
Okay, Give Me Step-By-Step Instructions
For End Users:
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Download an SF package from a developer for your device
Flash the package with the command:
Code:
./suicideflash.sh DOWNLOADEDPACKAGE.zip
Profit!
For Developers:
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Pull a system image from your phone
Run pkgmaker.sh to create an SF package
Upload the package for the benefit of others
For Anyone, to Use Suicide Push
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Push files to your phone's system partition with this command:
Code:
./suicidepush.sh LOCAL_SOURCE /system/PUSH_DESTINATION
So, What Can I Do with It Right Now?
If you're a developer, you can get to work creating SF packages for your device. If you're just a plain ol' user, there's not much to be done until others chip in. I have uploaded one package as a sample and for the convenience of anyone looking to root their XT1049 and install Xposed. I will maintain a master list of uploaded packages as people make them.
XDA:DevDB Information
Suicide Flash for Moto, Tool/Utility for the Moto X
Contributors
Nicene Nerd, CrashXXL, Sabissimo
Version Information
Status: Testing
Created 2015-08-07
Last Updated 2015-08-07
Master Package List
XT1049: Republic Wireless Moto X
- root-xposed-xt1049-4.4.4.zip: Root and Xposed for XT1049. Requires stock 4.4.4 from SBF, not OTA.
- busybox-xt1049-rooted-xposed-4.4.4.zip: BusyBox for XT1049. Requires 4.4.4 rooted w/ Xposed.
XT1058: AT&T Moto X
- root-xt1058-4.4.4.zip: Root for XT1058 KitKat. Requires stock 4.4.4 from SBF, not OTA.
- xposed-xt1058-rooted-4.4.4.zip: Xposed for XT1058 KitKat. Requires rooted 4.4.4.
- root-xt1058-5.1.zip: Root for XT1058 Lollipop. Requires stock 5.1 from SBF, not OTA.
XT1060: Verizon Wireless Moto X
- root-xt1060-4.4.4.zip: Root for XT1060. Requires stock 4.4.4 from SBF, not OTA.
- xposed-xt1060-rooted-4.4.4.zip: Xposed for XT1060. Required rooted 4.4.4.
Changelogs:
08/07/2015 - v0.2
- suicideflash.sh: Increased wait period before giving error on not finding phone in emergency mode
- mountimg.sh: Fixed issue which would cause errors preventing images from mounting
- pkgmaker.sh: Added option to pull system image over ADB, improved error handling
Developer pkgmaker.sh Tutorial: Creating an Xposed Framework Package
Say you want to make a package that installs the Xposed framework, since that requires writing to /system. Here's how you would do it with Suicide Flash (assuming you have already rooted the phone):
Open a terminal window to your Suicide Flash root folder. Then sudo su.
Pull a system image. One way to do that:
Code:
adb root
adb shell dd if=/dev/block/platform/msm_sdcc.1/by-name/system /sdcard/originalsystem.img bs=1024
adb pull /sdcard/originalsystem.img
Run the pkgmaker script like this, assuming you're using a rooted XT1049 on 4.4.4, but you don't know the offset of the system partition, so you want to pull it via ADB. The script will be placed in output/xposed-flash-package.zip.
Code:
./pkgmaker.sh originalsystem.img XT1049 "Stock 4.4.4" ADB xposed-flash-package.zip
The script will pause when originalsystem.img is mounted for writing. As root, copy the Xposed app_process file (which you can extract from the APK if you need it) to "mnt-originalsystem.img/bin/app_process". Then press enter.
The script will continue executing, hopefully without errors.
Voila! Your package xposed-flash-package.zip is ready to upload and/or flash.
Finally!
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Also, if you have it tested and everything with Republic, I would appreciate a torrent or hosted file somewhere. If there isn't one before I finish, I'll post it.
---------- Post added at 09:42 PM ---------- Previous post was at 09:38 PM ----------
Cindex said:
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Also, if you have it tested and everything with Republic, I would appreciate a torrent or hosted file somewhere. If there isn't one before I finish, I'll post it.
Click to expand...
Click to collapse
Sorry for the double post but I can't edit yet, just realized that the zip file there is all that's needed for Republic. I was going to post the ADB/USB driver setup link for linux, but I'm not allowed yet.
Cindex said:
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Click to expand...
Click to collapse
You shouldn't need to do anything special for Linux drivers. It works straightforwardly as long as you have fastboot and ADB. The flashed file that creates the softbrick is included by the package maker script in every Suicide Flash package, so it is easy to unbrick. In fact, I can upload another package just for unbricking if you'd like.
Added a BusyBox package for XT1049, and added root and Xposed packages for XT1060.
Edit: also added root packages for XT1058 on both KitKat and Lollipop, plus Xposed for XT1058 KitKat.
Nicene Nerd said:
You shouldn't need to do anything special for Linux drivers. It works straightforwardly as long as you have fastboot and ADB. The flashed file that creates the softbrick is included by the package maker script in every Suicide Flash package, so it is easy to unbrick. In fact, I can upload another package just for unbricking if you'd like.
Click to expand...
Click to collapse
That's good to know, I looked around and couldn't find anything on the driver for the Qualcomm Emergency Download mode. I suppose not needing one would be why. Actually some kind of emergency package to unbrick might be good. Now that I see the script in there I don't have a problem, but someone might like it.
So now I'm wondering if I actually have to do a factory reset again, or if I can just flash the SBF file itself and not have to wipe. I'm not sure how big of a difference there is, because I did the factory restore recently and the OTA update was like 6MB or something. I wouldn't think there's be an issue flashing it rather than factory restore. Any ideas?
Also, if anyone knows a good way to do this with Virtualbox it would be a nice addition. I'm personally not going to bother since I already have a bootable Ubuntu USB, but it seems that most people would rather set up a VM with a small linux distro. If it had the tools baked in, it would make it an easy process.
Cindex said:
That's good to know, I looked around and couldn't find anything on the driver for the Qualcomm Emergency Download mode. I suppose not needing one would be why. Actually some kind of emergency package to unbrick might be good. Now that I see the script in there I don't have a problem, but someone might like it.
So now I'm wondering if I actually have to do a factory reset again, or if I can just flash the SBF file itself and not have to wipe. I'm not sure how big of a difference there is, because I did the factory restore recently and the OTA update was like 6MB or something. I wouldn't think there's be an issue flashing it rather than factory restore. Any ideas?
Also, if anyone knows a good way to do this with Virtualbox it would be a nice addition. I'm personally not going to bother since I already have a bootable Ubuntu USB, but it seems that most people would rather set up a VM with a small linux distro. If it had the tools baked in, it would make it an easy process.
Click to expand...
Click to collapse
Technically, the only reason for the SBF is because when you install OTA updates, files may end up in slightly different positions depending on the circumstances. For this to work, you must start with an identical system partition to the one used for making the package. So all you need to really do is extract the system.img and flash it, if you wish. No data loss necessary.
Also, I'll look into a minimal VM. I thought about actually trying to make a Windows version of Suicide Flash. I'm not sure which I'll end up with.
So I tried this on my Ubuntu 12.04.5 last night, and it didn't recognize the device in fastboot. I'm going to try on Ubuntu 15.04 soon here. Another question for you though, which sdk do I use for XPosed? I don't seem to be able to figure it out searching all over. I would think 16, but maybe it's for Lollipop?
I think I'm going to get some of these with the OTA, it'll make it easier for the average Republic user once it's gotten going.
Cindex said:
So I tried this on my Ubuntu 12.04.5 last night, and it didn't recognize the device in fastboot. I'm going to try on Ubuntu 15.04 soon here. Another question for you though, which sdk do I use for XPosed? I don't seem to be able to figure it out searching all over. I would think 16, but maybe it's for Lollipop?
I think I'm going to get some of these with the OTA, it'll make it easier for the average Republic user once it's gotten going.
Click to expand...
Click to collapse
I can't answer your Xposed Lollipop question. I was wondering the same thing, but I ended up simply pulling the file from an existing Xposed installation. I suppose you could do the same and then diff the files to find out which is correct.
As for the OTA, that's not possible. Every time an OTA is installed, the files can end up in different places on the flash memory, and this utility requires knowing the exact locations for making changes. You'd have to make separate packages for every phone. Otherwise you'll end up with bootloops.
Has anyone tried using Suicide Push? It's slow, but I thought it would be the more celebrated part of this since it lets you do basically the same as an ADB push to the system partition. You could even install Xposed that way:
Code:
./suicidepush.sh local_app_process_file /system/bin/app_process
Nicene Nerd said:
Has anyone tried using Suicide Push? It's slow, but I thought it would be the more celebrated part of this since it lets you do basically the same as an ADB push to the system partition. You could even install Xposed that way:
Code:
./suicidepush.sh local_app_process_file /system/bin/app_process
Click to expand...
Click to collapse
I'm still working on getting it to root. I was going to a few days ago, but my flash drive burned out. I'm going to try Ubuntu 14.04.3.
What linux distro did you use?
---------- Post added 14th August 2015 at 12:41 AM ---------- Previous post was 13th August 2015 at 11:47 PM ----------
Sorry to double post again, but I can't edit yet and have a few more things. I can't seem to be able to find a RW SBF file. I'm thinking restore from factory sounds like a good solution, but I don't know if that's the same thing.
How can I pull a system image if I'm not root? Without an SBF file, I need to package it for myself. Without root, I can't pull the system.img. I'm sure others on networks not covered yet would like to know also. Where did you get your system.img?
Also, if we can get this deep, and you can modify the bootloader, couldn't you just flash the old bootloader image and then the rest of the ROM? Then we could unlock the bootloader using older methods. We might have to flash block by block, but it should work?
Cindex said:
I'm still working on getting it to root. I was going to a few days ago, but my flash drive burned out. I'm going to try Ubuntu 14.04.3.
What linux distro did you use?
---------- Post added 14th August 2015 at 12:41 AM ---------- Previous post was 13th August 2015 at 11:47 PM ----------
Sorry to double post again, but I can't edit yet and have a few more things. I can't seem to be able to find a RW SBF file. I'm thinking restore from factory sounds like a good solution, but I don't know if that's the same thing.
How can I pull a system image if I'm not root? Without an SBF file, I need to package it for myself. Without root, I can't pull the system.img. I'm sure others on networks not covered yet would like to know also. Where did you get your system.img?
Also, if we can get this deep, and you can modify the bootloader, couldn't you just flash the old bootloader image and then the rest of the ROM? Then we could unlock the bootloader using older methods. We might have to flash block by block, but it should work?
Click to expand...
Click to collapse
I used Ubuntu 14.04.
The RW 4.4.4 SBF can be found here or here. It does not appear possible to pull a system image without root. But even without permanent root, KingRoot can get you temp root long enough to pull a system image.
As for the bootloader, there's certainly a chance that this could be done. It's just so risky that I won't try it myself. If there was a single variable missed, it could easily mean hard-brick. But in theory, as far as I understand, it might work. The biggest obstacle might be partition changes. If you got the bootloader to get into fastboot mode, though, you could presumably fix that with an old SBF.
Flashing the olderer bootloader will not work (I have tried and confirmed it does not work). It is because the efuses verify the bootloader.
Wow! That's hell of a tool you've created here Awesome job! I haven't tried it myself yet, but, judging by source code, it should get the work done. More of a developer tool, ofc, but it's more then impressive Maaan, I wish there was a normal way to work with ext4 partitions to make it available on Windows))
Since you've made "push" version of it (and that's the most interesting part, longest though), the next step in future development should be doing the same with TWRP flashable zips. Some of them just put apk-s in system folder, some of them have shell scripts inside, I've yet to figure out the pattern But that would be awesome next step to this awesome project
download link not found )
theres a tool bar at top crash with download links next to discussions and screenshots
Sabissimo said:
Wow! That's hell of a tool you've created here Awesome job! I haven't tried it myself yet, but, judging by source code, it should get the work done. More of a developer tool, ofc, but it's more then impressive Maaan, I wish there was a normal way to work with ext4 partitions to make it available on Windows))
Since you've made "push" version of it (and that's the most interesting part, longest though), the next step in future development should be doing the same with TWRP flashable zips. Some of them just put apk-s in system folder, some of them have shell scripts inside, I've yet to figure out the pattern But that would be awesome next step to this awesome project
Click to expand...
Click to collapse
I've actually started work on a Windows version, but it's on back burner because school just started. Here's a hint, though: with OSFMount and Ext2Fsd, you can mount Moto system images (pulled from the phone, not SBF ones) as hard drives or removable disks. Suicide Flash for Windows will rely on them.
So what are the chances I could use this to pull a system.img, and actually go in and delete some apps out of my XT1058? I had some success but it pulled the image as a mbn and I'm hesitant to try flashing it.
lpjunior999 said:
So what are the chances I could use this to pull a system.img, and actually go in and delete some apps out of my XT1058? I had some success but it pulled the image as a mbn and I'm hesitant to try flashing it.
Click to expand...
Click to collapse
Here's what you'll want to do:
Create the system image on the phone with
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/oldsystem.img bs=1024
ADB pull or MTP copy the image to your PC.
Run pkgmaker.sh like so:
Code:
./pkgmaker.sh oldsystem.img XT1058 "My System" 4B000000 modded-system.zip
When prompted, you can delete apps as root from the mounted system image under mnt-oldsystem.img/app or mnt-oldsystem.img/priv-app
Continue and finish the script.
Flash with
Code:
./suicideflash.sh -s output/modded-system.zip
After further developments we have realised making a whole new kernel is not worth it as all functions we could want can be just made into a custom ROM
This Project is now currently about how to make android wear darker, basically a theme for it. Since android wear those not contain any theme engine all ui mods must be done by hand ie apk modding. Anyone willing to mod the ui is welcome to do so as I do not have time but I will compile it into a system.img
For everyone to enjoy here are all the apks contained in the system ie everything with a GUI.
modify at your will and upload fully working signed apk if you would like to test it
XDA:DevDB Information
Make Android Wear Great , ROM for the LG G Watch
Contributors
Xmaster24, invisiblek
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.10.x
ROM Firmware Required: 6.0.1 bootloader
Based On: Stock
Version Information
Status: Testing
Created 2016-02-24
Last Updated 2016-04-08
Reserved
Latest changelog will be kept here find rest HERE
24/02/2016: 0.2
Removed Files (can all be found HERE)
/etc/NOTICE.html.gz
/recovery-from-boot.p
/framework/wifi-service.jar
/bin
applypatch
install-recovery.sh
/lib/wifi-service
(See post below for all explanations)
Added Files:
/priv-app/LgeWatchFace (for fall back on factory reset)
23/02/2016: 0.1
/app
LGeWorldClock
PreBuiltWearFit
/priv-app
MinModWatchfaces
PrebuiltWearsky (might cause breakage)
WristGesturesTutorial (same as ^)
LgeWatchFace
Nice job! We would probably prefer not crippling fresh installs, so getting at least one watch face back in would be ideal.
Check out `the fonts/ directory, I bet some of those can be tossed out. Looks like you might gain a nice chunk of space by doing that. May need to look at/tweak etc/fonts.xml and etc/system_fonts.xml though, they reference the ttf files.
recovery-from-boot.p can definitely go. We don't need that.
These hals can probably go since they should be overridden by their msm8226/dory counterparts in the same dir. (Not saving much room at all by doing so, but it might get to the point where every kb counts)
lib/hw/power.default.so
lib/hw/audio.primary.default.so
lib/hw/gralloc.default.so
Others that should be fine:
etc/NOTICE.html.gz
Might cause some breakage, but since we don't have wifi you could try removing these:
lib/libwifi-service.so
framework/wifi-service.jar
Some other ideas I had if it came down to it would be to move some of the apps to /data/. Maybe creating a flashable zip or something to do so?
Another idea would be to ship one or several "mini" squashfs images and mount them right after we mount /system/. For instance a fonts.img that's just the fonts/ directory, we could mount it during init right after system gets mounted. Not sure how much extra compression would be needed or space gained, and really this would probably be a last resort hack, but might just do the trick.
Yet another idea is to shove more things into ramdisk, we have some room there still.
EDIT:
These can go too:
bin/install-recovery.sh (this is what clobbers twrp every boot, service is disabled in my ramdisk, but we should kill it anyway)
bin/applypatch (only install-recovery.sh needs this)
invisiblek said:
Nice job! We would probably prefer not crippling fresh installs, so getting at least one watch face back in would be ideal.
Check out `the fonts/ directory, I bet some of those can be tossed out. Looks like you might gain a nice chunk of space by doing that. May need to look at/tweak etc/fonts.xml and etc/system_fonts.xml though, they reference the ttf files.
recovery-from-boot.p can definitely go. We don't need that.
These hals can probably go since they should be overridden by their msm8226/dory counterparts in the same dir. (Not saving much room at all by doing so, but it might get to the point where every kb counts)
lib/hw/power.default.so
lib/hw/audio.primary.default.so
lib/hw/gralloc.default.so
Others that should be fine:
etc/NOTICE.html.gz
Might cause some breakage, but since we don't have wifi you could try removing these:
lib/libwifi-service.so
framework/wifi-service.jar
Some other ideas I had if it came down to it would be to move some of the apps to /data/. Maybe creating a flashable zip or something to do so?
Another idea would be to ship one or several "mini" squashfs images and mount them right after we mount /system/. For instance a fonts.img that's just the fonts/ directory, we could mount it during init right after system gets mounted. Not sure how much extra compression would be needed or space gained, and really this would probably be a last resort hack, but might just do the trick.
Yet another idea is to shove more things into ramdisk, we have some room there still.
EDIT:
These can go too:
bin/install-recovery.sh (this is what clobbers twrp every boot, service is disabled in my ramdisk, but we should kill it anyway)
bin/applypatch (only install-recovery.sh needs this)
Click to expand...
Click to collapse
I looked through the fonts and yes a lot of the non-English ones can go but that would destroy international support
Was going to create installer for removed watchfaces as they really don't require system access,fit could also be installed on /data not sure if step counting will still work, main reason to have the app at all. Thanks for suggestions will add smallest watchface back and delete the suggested files tomorrow
@invisiblek could you also create a recovery with the ability to wipe the new system as @rbox 's build cannot do so for future updates when we create a recovery package so the new system can actually be flashed PS. I gave you edit permissions for the files
Do you know what prebuiltwearsky.apk does?
Phonesky.apk is the Phone's Play Store
Sent from my Nexus 10 using Tapatalk
drewski_1 said:
Do you know what prebuiltwearsky.apk does?
Phonesky.apk is the Phone's Play Store
Sent from my Nexus 10 using Tapatalk
Click to expand...
Click to collapse
Thanks for pointing that out but seeing as Android wear has no playstore I assumed it was the sky watchface
Edit; just checked, yes it's package id is com.android.vending so it must be some playstore for wear. Wonder what it's purpose is as all apps regardless of source can communicate to wear and install apps. Hopefully after @invisiblek s changes it will be able to fit whatever functionality it serves. Never thought I would say this in 2016 but it's quite large at 2.95 MB will hope it fits
edit edit: now that I think about it it might just be a residual app from wifi enabled watches as you are able to install apps to those while they are connected to wifi and not the phone by bluetooth. Can someone test it to be sure? thanks
Thinking of calling this freedom rom as it gives us the freedom to R/W to system. Looks like someone already beat me to it http://forum.xda-developers.com/verizon-galaxy-s5/development/wip-aosp-themed-rom-t3098153 thread seems dead thought won't mind if we use it
Edit even better idea Freedom ROwM (Read Or write) as I kinda pun because ROM = read only memory but this whole project is to make it Read Write
Bad news everyone just tested build and @invisiblek 's kernel cannot boot the system. Will update soon hopefully
Xmaster24 said:
invisiblek could you also create a recovery with the ability to wipe the new system as rbox's build cannot do so for future updates when we create a recovery package so the new system can actually be flashed PS. I gave you edit permissions for the files
Click to expand...
Click to collapse
Well, twrp inherently auto-detects the filesystem before wiping it. It look like there are options in there to change the filesystem though. I could mess around with adding squashfs formatting support, but that really doesn't do much for us.
Xmaster24 said:
Bad news everyone just tested build and @invisiblek 's kernel cannot boot the system. Will update soon hopefully
Click to expand...
Click to collapse
Any chance of getting a kernel log from this?
invisiblek said:
Well, twrp inherently auto-detects the filesystem before wiping it. It look like there are options in there to change the filesystem though. I could mess around with adding squashfs formatting support, but that really doesn't do much for us.
Any chance of getting a kernel log from this?
Click to expand...
Click to collapse
Device is completely undetected by pc and is essentially bricked so yeah don't have a jtag or anything
It's up for grabs if you wanna try it. It did no damage to my device maybe to my pants because I could not boot to bootloader but managed to anyway. Will send you stock squashfs image if you don't already have it
I am watching and waiting to test.
---------- Post added at 02:46 PM ---------- Previous post was at 02:44 PM ----------
Could we use a Linux kernel that supports healthy honey? And more so towards slimsaber ROM for the LG G2?I am wondering if marshmallow os might conflict with my current daily driver ROM . I think a Linux kernel will make this ROM more compatible for different roms.
Crumplet said:
I am watching and waiting to test.
---------- Post added at 02:46 PM ---------- Previous post was at 02:44 PM ----------
Could we use a Linux kernel that supports healthy honey? And more so towards slimsaber ROM for the LG G2?I am wondering if marshmallow os might conflict with my current daily driver ROM . I think a Linux kernel will make this ROM more compatible for different roms.
Click to expand...
Click to collapse
I think you are on the wrong forum this is for the LG G watch not LG G2
Just to add ; all android devices run off a Linux kernel, Literally all of them even the x86 ones and what in the hell is healthy honey? All google shows is some Honeypot distro for pc. You seem to be trolling me cause you must be high when you wrote this
what are the possible benefits in switching to EX4 filesystem?
Just curious here on one thing.... how hard would it be to remove the tutorial stuff that you have to always go through upon doing a factory reset and G Watch setup? This ROM looks promising for sure.
Also a few name ideas:
FreedomG ROM
LibertyG Watch
SleekWatch ROM
MarshSlimmed ROM
SlimmedG ROM
SleekG ROM
GWatch Slimmed ROM
AngryManMLS said:
Just curious here on one thing.... how hard would it be to remove the tutorial stuff that you have to always go through upon doing a factory reset and G Watch setup? This ROM looks promising for sure.
Also a few name ideas:
FreedomG ROM
LibertyG Watch
SleekWatch ROM
MarshSlimmed ROM
SlimmedG ROM
SleekG ROM
GWatch Slimmed ROM
Click to expand...
Click to collapse
I have removed the gesture tutorials apk which should get rid of all those tutorials. Thanks for the name suggestions
Jaocagomez said:
what are the possible benefits in switching to EX4 filesystem?
Click to expand...
Click to collapse
Ext4 is R/W while the current SquashFS is R/O