Samsung recently announced the new F2FS file system https://lwn.net/Articles/518718/, Im going to get the ball rolling on this, i have compiled a kernel that supports the new file system based off of fauxs source. im only posting the zimage for people who know what they are doing. For this to be usable a new recovery needs to be built to support formatting to F2FS. and possible the bootloader(not currently possible). so the best approach at this point is to build a new recovery and format only system and data to f2fs leaving boot as ext4. Im looking into it but im not very famlier with recovery. modifications need to be made to the android build system but they are trivial. Im ataching a compiled zimage and the patch files to add to any kernel. patches 01 and 16 dont apply so they will need to be done by hand. everything else applies clean.
This looks very intriguing, I haven't heard of it until now and it looks like it could bring some definite speed advantages. I can't wait to give this a whirl on my Android devices and my Arch Linux install which runs off of an SSD.
its going to be a challenge to get it runnig under android, its going to take some collaboration and time
Looks interesting. I may try to help when I get time but I haven't built an n7 kernel. Shouldn't be hard. Also need to add kernel support for the filesystem and at least add the mkfs tool to recovery so it can be formatted via adb shell.
Sent from my Galaxy Nexus using Tapatalk 2
tiny4579 said:
Looks interesting. I may try to help when I get time but I haven't built an n7 kernel. Shouldn't be hard. Also need to add kernel support for the filesystem and at least add the mkfs tool to recovery so it can be formatted via adb shell.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
The largest change that needs to happen right now is recovery, which I'm not very familiar with
Sent from my PG86100 using Tapatalk 2
The bootloader doesn't need to know anything about the filesystem, it loads the kernel directly a preset offset.
That's why you flash a kernel, and not mount the boot partition and unzip it.
So, all that's needed to support a new filesystem is adding the code to the kernel, and enabling it in the defconfig, and then you can use userspace utilities to format partitions to that new filesystem.
F2FS is still immature, they haven't released a fsck tool for it yet, and the mkfs binary they provided is probably x86, so there's no way you can use it on the Nexus 7 now.
Just checked out their sourceforge project, check below post, they have provided source for mkfs.
Also, the recovery needs to be modified only if the default format of the partitions is being changed, and that'll need changes in the fstab as well to mount the filesystem as something other than what it was set to by default.
Nothing will need to be changed in the Android Build System as well, unless you wan't to generate f2fs system images.
f2fs-tools-1.0.0.tar.gz includes source, not binaries.
http://lkml.indiana.edu/hypermail/linux/kernel/1210.2/00005.html 1.5 to 2 times faster, Im going to look into this again it seems very worthwhile
I don't know much about this stuff, more of a user over here, but I sure know when to get excited about something. :victory:
I've read a few things about the new file system and was particularly impressed with the benchmark performance. I really hope to see this becoming a standard feature of android. Please keep up the work. You've found yourself an early adopter.
Thanks again and kudos!
aaronpoweruser said:
http://lkml.indiana.edu/hypermail/linux/kernel/1210.2/00005.html 1.5 to 2 times faster, Im going to look into this again it seems very worthwhile
Click to expand...
Click to collapse
Hi, I also think this seems very worthwhile, maybe even porting it to maguro. This thread was a nice start, I've created a thread on my device's general section, but no replies pushing forward yet.
I looked into it the best option for now would be to format an external SDcard, but that would make it un mountable by a pc. In order to make it work with an internal storage the android build tools will need to be reverted reworked as well as recovery
Sent from my Nexus 7 using Tapatalk HD
aaronpoweruser said:
I looked into it the best option for now would be to format an external SDcard, but that would make it un mountable by a pc. In order to make it work with an internal storage the android build tools will need to be reverted reworked as well as recovery
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
thanks, that's what i thought too, build tools/recovery, a few touches here and there xD
f2fs would be unreadable by a pc... by a Windows pc.
Related
This is a patch to the stock 4.2.2 kernel that allows the phone to become a virtual CD drive.
Often, due to being the resident 'expert' around here I carry around an iOdd so I can install things like Windows from CD without having a bag full of windows CDs around. I thought it would be great if my phone could do this.. this is the result.
This functionality already exists in part the in kernel, but wasn't enabled and a bit buggy.
This patch only affects a single file (that doesn't look like it's changed for years) so should apply to just about any kernel, in theory.
1. Bring the cdrom flag into userspace via sysfs.
2. Implement the raw READ CD command
3. Implement raw READ TOC commands & respond to the old sff8020i request format.
I've built a boot.img from the stock 4.2.2 - there are no other changes to the kernel (I'm not really planning on maintaining another kernel - there's better people than me doing that already).
Also I've provided a GUI app to handle the mount/unmount. That will also support hard drive images (those work on unpatched kernels, so an image of a USB thumb drive should work).
Known bugs:
1. Sometimes Windows loses track of MTP after you unmount the disk (I disable it during emulation as the Win drivers really hate them being enabled at the same time). Toggling between PTP/MTP again resets it.
2. The currently mounted image doesn't always show in the app. This appears to be a kernel bug (it loses the name randomly) but is harmless.
boot-cdrom-4.2.2.img -- Compiled boot.img
cdrom.diff -- Diff file
VirtualDrive.apk -- GUI app
thank you gonna try
This looks like a really cool feature to have.
Thanks man! Now if the N4 only came with larger storage..
Is this the same thing as drive droid on the play store essentially? I've been using that to boot from my phone flawlessly so far.
Sent from my Nexus 4 using xda app-developers app
Can I just switch out the file and reboot and keep my current kernel... I see no reason why not but wanted to make sure
Sent from my Nexus 4 using xda premium
I'm the developer of DriveDroid and I was also working on something similar for a i9000 based on CyanogenMods kernel:
* cdrom option for each lun: http s://github.com/FrozenCow/android_kernel_samsung_aries/commit/a66d37b4ce5c8e1dd9231f478575a22a6c3294a4
* 2048 blocksize for cdrom luns (based on a patched from mailinglist in 2009): http s://github.com/FrozenCow/android_kernel_samsung_aries/commit/7f43f35bc6fd2b7eeee9e4051c1acf3f25462379
I see you have solved the problem a fair bit more sophisticated and likely more correct than what I did. I don't have much experience with kernel development, so could you explain your solution in a bit more detail?
I'd really like this (or similar) patch to be in the kernels of the most popular devices, so everyone can have cdrom support on their phone and DriveDroid can make use of that. Best would be to try to apply it to CyanogenMod kernels or even the official Android kernel.
(I may not post external links :-/, sorry for that)
Very useful patch, indeed!
I even ported an ancient mkisofs for that matter, to make iso images from /sdcard subdirs on the fly. Here's the trivial app I use, complete with the sources if somebody would care to write a non-hellowordish one (mkisofs itself is in libs/armeabi/libmkisofs.so to make everything simple).
Wonder why the kernel mainline is lacking such code for years?
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.
This is not an Android project so I don't feel that posting it in the Android Development forum would be appropriate.
ArchLinuxARM for the manta (Samsung/Google Nexus 10) - Native Boot
Working:
Wi-Fi (with NetworkManager)
Audio (requires manual intervention)
Not Working:
Bluetooth
2D & 3D Accelerated Graphics
Installation (to a subfolder of the /data partition)
You will need a Terminal Emulator or ADB Shell to install.
This assumes that arch_manta_20141210_root.tar.gz is in the root of your internal storage (/data/media/0).
Code:
su
mkdir /data/local/arch
tar -C /data/local/arch -xpzvf /data/media/0/arch_manta_20141210_root.tar.gz
Booting
Since there is no workable multiboot solution for the Nexus 10 yet, you can take one of two routes to boot this thing:
Option 1: Flash the arch_boot.img to either the recovery or the boot partition of the internal flash chip. Due to risk of BRICKING if you flash to the wrong partition, I will not provide instructions here. I might make a flashable zip later on. Note that this removes access to Android.
Option 2: Use Fastboot to tethered boot the provided kernel from another computer where it is installed:
Code:
fastboot boot boot_arch_manta.img
Logging in
The username is "arch" and the password is "archlinux". Change the password ASAP.
For root, the username is "root" and the password is also "root". CHANGE THE PASSWORD ASAP!
You'll probably want to enable the On-Screen Keyboard (onboard) and set your Session to "MATE" up in the top right corner.
To make audio work after booting and logging in, run "fix_audio.sh" in a terminal.
Read Me
If you WIPE DATA, it will also WIPE OUT THIS PORT, all its applications, and any files you may have stored within it!
Downloads
root filesystem archive: https://drive.google.com/file/d/0B4WUjKii92l2Qkd6S3c3M2tDcTQ/view?usp=sharing
kernel for fastboot or flashing: https://drive.google.com/file/d/0B4WUjKii92l2UGhIWTlVam5vSk0/view?usp=sharing
Kernel Source: https://github.com/willcast/kernel_manta
Also available for:
Nexus 7 2013: http://forum.xda-developers.com/nex...fficial-archlinuxarm-release-n7-2013-t2969301
Galaxy S3 LTE: http://forum.xda-developers.com/gal...unofficial-port-archlinuxarm-release-t2969290
HP TouchPad: http://forum.xda-developers.com/hp-touchpad/other/unofficial-archlinuxarm-release-hp-t2969310
HTC HD2: http://forum.xda-developers.com/hd2-ubuntu/development/unofficial-archlinuxarm-htc-hd2-t2970483
Free space required?
Started with 5GB+ before downloading the 1.5 tar.gz, thought it will be enough but I'm supposed it wasn't cuz I'm getting "No space left in the device" although I still have 537MB free left.
Hmm, shouldn't do that. The archive itself is 4,060 MB uncompressed according to gzip -l.
Try booting it anyway, maybe? Also, perhaps I uploaded a truncated archive. I'll have to check.
Edit: Wait, you'd need upwards of 5.5 GB free to have both the archive and the extracted files on /data.
So, I deleted my nandroid backup and was able to install it. Actually it runs very well, I think even better than when ubuntu was being officially developed by canonical for the nexus 7. Of course it was easier to run because of the MultiRom solution, always wonder why Nexus 10 it's not supported, like Nexus 4, 5, 7 and even som non-nexus devices.
tavocabe said:
So, I deleted my nandroid backup and was able to install it. Actually it runs very well, I think even better than when ubuntu was being officially developed by canonical for the nexus 7. Of course it was easier to run because of the MultiRom solution, always wonder why Nexus 10 it's not supported, like Nexus 4, 5, 7 and even som non-nexus devices.
Click to expand...
Click to collapse
I don't know, honestly. After I'm done with the HD2 flash-image port of this, I'm looking at porting kexec hardboot from a random old Epic 4G kernel to my kernel_manta on github, because that's the only ready-made Exynos hardboot patch I can find through google. Then, we could boot this with a script similar to the Galaxy S III LTE port, and someone could theoretically port MultiROM, though that someone is probably not going to be me.
Thank you, Castwilliam! It run good , with some gitch on screen, but better than ubuntu phone devReview .
But when I run pacman -Syu ( update packages), reboot and it become blackscreen, try many taps in middle touch screen, intensity light of screen is something change. What wrong when update packages in pacman ?_?.
Is the booting option 2 temporary? Can I just turn off nexus and boot back to android? Can I unplug the nexus from PC while running linux?
I have no idea what I am doing here (and you probably dislike dealing with noobs flooding forums with questions right? :silly: )
Dri0m said:
Is the booting option 2 temporary? Can I just turn off nexus and boot back to android? Can I unplug the nexus from PC while running linux?
I have no idea what I am doing here (and you probably dislike dealing with noobs flooding forums with questions right? :silly: )
Click to expand...
Click to collapse
Yes, yes and yes
Hello,
This is awesome work! It booted properly, connected to a network, and programs run just fine. But as the tablet's pixel density is pretty high, it isn't too comfortable to use. I tried adding a new resolution using xrandr, but it throws something along the lines of "failed to get gamma size for display default". I've tried googling for it, but nothing worked. What can I do to resolve this?
Thanks,
Vedanth
This thread is for development updates, and an eventual release of testing candidates for the future of dual booting CM12 android roms on the Amazon Fire TV. At this time I am not planing on supporting the Fire TV stick since my development platform is based off USB3 booting.
There currently isn't even a stable branch in CM12 upstream so things are quite tricky right now.
I may eventually setup public nightlies once the core is stable.
IN PROGRESS FORM HERE: https://t.co/TXp9z7htDx
The goals for development are in this order:
Wifi [working]
Bluetooth [crashing]
Stable core [random resets possibly storage related]
Audio [possibly needs hacking to default to hdmi]
Recovery system [rom boots using the recovery partition currently]
Hardware Acceleration [untested]
Android TV addons [require stable core]
USB Formating and install app [apparently not everyone knows what gparted is]
Modified version of Rbox's bootloader [I'd like to add recovery to the loader then have stock and custom boot options]
Also, if you want to be ready for possible nightly testing, I highly recommend going to walmart and buying one of the playstation USB3 hubs. It's about $20 but allows you to plug in a USB3 drive and keyboard and mouse until bluetooth is working.
SETTING UP USB BOOTING:
Code:
#include <std_disclaimer.h>
/* * Your warranty is now void. *
* I am not responsible for bricked devices, dead USB drives,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in these files
* before flashing them! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you. */
PART ONE [Preparing the drive]:
This process will eventually be streamlined but for now I'll explain the process and how it relates to testing builds during development. Since the Fire TV only has an 8gb flash chip and has no hardware recovery trigger, it is quite the unforgiving device to develop on. The current boot method for my CM12 builds involves flashing over the recovery partition and using it as a sort of dualboot partition. The modified recovery partition then searches for ext4 partitions on and external (USB3 preferred) flash drive. Currently each build generates its own boot image to be flashed over recovery, but I'm currently in the process of exploring the possibility of following Rbox's method of loading a boot image from a system folder instead making only one flash to the actual device necessary going forward.
For USB3 booting during the development process I highly recommend using a USB3 hub for a keyboard and mouse while bluetooth pairing and control mapping is being worked on. I also recommend a USB3 drive.
1) Turn on a Linux machine or boot a Live CD
2) Open Gparted
3) Delete any partitions on the usb drive
4) Create three ext4 partitions, the first partion is system and should be about 1GB, the THIRD partition is cache, and should be about 768mb with 0mb following, you should then have the middle portion empty in the display, in this SECOND partition make your data partition fill the rest of the space.
PART TWO [Preparing the bootloader]:
WARNING this process currently involves replacing your recovery partition, remember kids dd and root is like holding a grenade, make sure you don't throw it at something you care about.
Also, if you are testing a build and it does not load using the previous bootloader, try flashing the latest one from the nightlies (and vise versa) as I am still in the process of stream lining the boot process as far as what should take place before system bring up on our device. If a different boot image loads the system with noticeably more stability let me know asap so I can track the causes of my current issues.
Code:
adb connect <STOCK FIRE TV IP>
adb push boot-<DATE>.img /sdcard
adb shell
cd /sdcard
su
dd if=boot-<DATE>.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery
Next I recommend side loading this apk to make rebooting into USB boot easier.
The three most recent "boot" images have been added to the downloads section, remember these should be flashed to recovery. Although they would work in boot, that would disable Rbox's loader and prevent you from loading stock OS.
PART THREE [Playing with instability]:
Great so now you have a USB3 booting image flashed to your recovery partition and you have an empty flash drive. This is where the tinkering begins. In the download section you will find a .tar.gz archive with a somewhat booting system with the aforementioned issues. Inside this archive is a system.img file which you will use dd to flash to the first partition of the flash drive you formated. After the system image is flashed you can plug your flash drive into your hub and reboot into recovery. Things will be great, wifi will show up and if you're quick enough you can complete setup and make it to the launcher. (the issue I'm currently working on is an odd timed reset that may be kernel or storage related oddly if you make it to the launcher and don't touch anything, it takes longer to reset)
If you made it this far, welcome to development. You can help by "kanging" (replacing system apk's and files with other versions to find more stable matches, or remove apks until things don't die then report back to me) Also if you make it to this point go ahead and fill out the form I mentioned earlier. Eventually any hotfix builds I do between nightly builds will be accessible to those users to play with.
Overhauling the boot system next and working on the reset debugging.
XDA:DevDB Information
TechVendetta ROM Development, ROM for the Amazon Fire TV
Contributors
TechVendetta, rbox
Source Code: https://github.com/TechV/android_device_amazon_bueller
ROM OS Version: 5.0.x Lollipop
Based On: CyanogenMod
Version Information
Status: Testing
Created 2015-01-29
Last Updated 2015-01-29
Reserved
UPDATE: I'm pretty much settled in to my new job/home now so I'm going to resume this project shortly. The first order of business is to see what sort of driver improvements we got from Amazon and whether their modifications help resolve the issues I was having. I only have the original FireTV so I'll be only testing on that. Not sure if the new one has an unlocked bootloader or recovery system so that will be up to whichever brave soul wants to test that. Hopefully tomorrow I can resync my repos and get a look at whats changed.
Reserved
Thanks for the update! Looking forward to seeing how this progresses.
Thanks for your work!
It would be nice run a CM12 build in Fire TV
So far the main system seems promising, I feel like the reset issue, which is the primary major roadblock is either in the kernel, or in the storage management/selinux services. Selinux should be disabled in this build so I'm looking into the other two options right now.
TechVendetta said:
So far the main system seems promising, I feel like the reset issue, which is the primary major roadblock is either in the kernel, or in the storage management/selinux services. Selinux should be disabled in this build so I'm looking into the other two options right now.
Click to expand...
Click to collapse
Thank you for keeping us updated!
[email protected] said:
Thank you for keeping us updated!
Click to expand...
Click to collapse
I'll link this here for now, while I finish looking into the logs for bluetooth/wifi/audio before uploading a rough copy here. I think I'm going to use the individuals who filled out the form to test the installer and recovery apps I'll be doing after fixing the above three things.
:victory:| TEASERS |:victory:
TechVendetta said:
I'll link this here for now, while I finish looking into the logs for bluetooth/wifi/audio before uploading a rough copy here. I think I'm going to use the individuals who filled out the form to test the installer and recovery apps I'll be doing after fixing the above three things.
:victory:| TEASERS |:victory:
Click to expand...
Click to collapse
Hey,
i've got one question for the installation:
you use the recovery as boot partition (because you dont want to mess with the actual boot partition where the bootmenu is).
is there a reason we cant use rbox's bootmenu, add another entry "usb boot" which will boot from /system/boot/usbboot.img ?
Or is the only reason that this just hasnt been added by rbox so we have to use another way?
I think this would be the most brick safe version and shouldnt be a big problem for rbox to implement....
Chris
[edit]
i'm really looking forward to this
aHcVolle said:
Hey,
i've got one question for the installation:
you use the recovery as boot partition (because you dont want to mess with the actual boot partition where the bootmenu is).
is there a reason we cant use rbox's bootmenu, add another entry "usb boot" which will boot from /system/boot/usbboot.img ?
Or is the only reason that this just hasnt been added by rbox so we have to use another way?
I think this would be the most brick safe version and shouldnt be a big problem for rbox to implement....
Chris
[edit]
i'm really looking forward to this
Click to expand...
Click to collapse
Thats one of the goals I put up there, just unlike rboxs current loader I know a way to make it remote controlled. ;D I started a bit on it. The "friendly user release" will have a root installer app that will handle multiboot, formating flash drives, recovery options, updates etc.
Really looking forward to a CM12 Android TV ROM. It would be nice to know that Amazon would not be able to kill a rooted Fire TV when this becomes reality. Peace of Mind regarding the Fire TV would be Priceless!
Xposed too http://forum.xda-developers.com/showthread.php?t=3030118
hhairplane said:
Xposed too http://forum.xda-developers.com/showthread.php?t=3030118
Click to expand...
Click to collapse
I'm a big fan of exposed, I'll have to add that to my testing list. I get a bit more free time tonight so I'll be getting back to looking at WiFi and Bluetooth and the installer. I still have two possible routes for both installing and updating i have to consider.
Sent from my LG-VM670 using XDA Free mobile app
TechVendetta said:
I'll link this here for now, while I finish looking into the logs for bluetooth/wifi/audio before uploading a rough copy here. I think I'm going to use the individuals who filled out the form to test the installer and recovery apps I'll be doing after fixing the above three things.
:victory:| TEASERS |:victory:
Click to expand...
Click to collapse
Any luck with the video acceleration, eg for Kodi or others such as Netflix, etc? How about hdmi audio?
Thanks for the update!
Video acceleration appears to be working, haven't got to audio. Had a death in the family this morning so i haven't had time to test my latest build.
Sent from my LG-VM670 using XDA Free mobile app
Sorry to hear that, Family is first! Although, maybe working on this will help take your mind away from that. Feel better!
TechVendetta said:
Video acceleration appears to be working, haven't got to audio. Had a death in the family this morning so i haven't had time to test my latest build.
Sent from my LG-VM670 using XDA Free mobile app
Click to expand...
Click to collapse
Sorry to hear that.
I recently installed CM 12 on a 2012 kfhd and wow!--it really brought that device to life! Performance/OC options are built right into the OS and another Dev made a custom kernel to oc to 1.7 ghz. But I have limited experience with CM and Android TV. Can we expect a similar UI and performance options with this? Or is it different for the set top boxes?
BTW--I think it's really great you're doing this. Lots of people are excited and it's very appreciated!!!
KLit75 said:
I recently installed CM 12 on a 2012 kfhd and wow!--it really brought that device to life! Performance/OC options are built right into the OS and another Dev made a custom kernel to oc to 1.7 ghz. But I have limited experience with CM and Android TV. Can we expect a similar UI and performance options with this? Or is it different for the set top boxes?
BTW--I think it's really great you're doing this. Lots of people are excited and it's very appreciated!!!
Click to expand...
Click to collapse
I can overclock the kernel but I'm not sure if it will be necessary yet. As for the features, CM12 doesn't even have a "stable" build yet. (they call them M builds now) They are still porting customizations like that in. That rom may use some stuff pulled in by the dev from other projects like paranoid, aokp etc. I'm listening to what people are asking for and I'll be taking it into consideration once I get to tweaking release candidates.
TechVendetta said:
I can overclock the kernel but I'm not sure if it will be necessary yet. As for the features, CM12 doesn't even have a "stable" build yet. (they call them M builds now) They are still porting customizations like that in. That rom may use some stuff pulled in by the dev from other projects like paranoid, aokp etc. I'm listening to what people are asking for and I'll be taking it into consideration once I get to tweaking release candidates.
Click to expand...
Click to collapse
Sounds great. Thinking now...an OC kernel probably isn't necessary since it's already real fast. But this rom I have works well on a relatively low end/older device. So I'm super excited about your project. Thanks again!
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