Related
Hi chaps,
I've just bought a Galaxy tab with plans to port Meego to the device.
I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).
So, if you'll bear with me, I have a few questions which are probably quite basic.
I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.
So onto the questions:
Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?
Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?
I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?
I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.
Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?
Thanks for your patience!
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
lardman said:
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
Click to expand...
Click to collapse
Samfirmware get their images direct from Samsung insiders. They are not dumps.
If you want to dump from your device search "rotobackup" here in the dev forum.
Sent from my GT-P1000 using Tapatalk
alias_neo said:
Samfirmware get their images direct from Saunaing insiders. They are not dumps.
Click to expand...
Click to collapse
Ok that's reassuring.
alias_neo said:
If you want to dump from your device search "rotobackup" here in the dev forum.
Click to expand...
Click to collapse
Great, just what I was looking for, many thanks
So some more questions:
Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?
What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc
The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.
I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.
Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?
Thanks
lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.
backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.
Thanks for the comprehensive reply
Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.
I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.
Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.
Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/showthread.php?t=870690):
Restoring to factory after using this process (you need using stock images):
heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs
Click to expand...
Click to collapse
Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.
Any thoughts?
Do we trust the partition sizes reported here: http://forum.xda-developers.com/showpost.php?p=9471190&postcount=14
They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)
Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?
Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.
So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
I see from the Nexus S port that including adbd in the image seems to be the way to go for early messages, I'll need to generate a new Meego image and have another go later on.
Interesting, I can't see that I've done anything wrong, and my extra init shell script is not started. I am trying to use the "exec" keyword in recovery.rc to start a shell script which will pass control to the Meego rootfs. At the start of my shell script I start adbd (i.e. still within the initramfs), so I should be able to tell if it has started, and it doesn't appear to do so.
Therefore I did some Googling, and I've seen that in some cases the initramfs init does not implement the "exec" keyword (http://forum.samdroid.net/f9/new-init-exec-import-implemented-3280/). This is troublesome for me as it's what I'm trying to use, but at least would explain why I don't seem to leave the init process
I couldn't see the Samsung specific source for init anywhere, has anyone found any? I'm not happy to replace it using the standard Android source as I'm guessing there's code missing which allows the bootloader to tell init how the device was started so that it knows which of the .rc files to run. Has anyone looked into this?
Thanks
Looking at the code in that link it looks pretty straightforward, just a case of parsing the kernel command line (though I might just reverse engineer the existing init first to make sure I'm not missing anything).
Would still be easier to get the actual source code from Samsung, so I've emailed their Open Source group.
lardman said:
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
Click to expand...
Click to collapse
I get it with CM
Does CM use a compressed initramfs? I'm using one of those and wondering if it's something to do with the (admittedly small) extra time required to move to init.
I don't have my Tab with me here, could someone post the output of /proc/cmdline please? You'll need to be root. Thanks.
Well it's booting you'll all be glad to hear.
More details to follow, but from memory the following were required:
Custom kernel to add btrfs support (as the image I'm booting is a btrfs partition on the external SD); kernel patch to allow compile-time cmdline to be added to the end of the bootloader cmdline (to enable console=tty0); replace Android init with init script to perform some basic setup then pivot_root to the Meego partition.
Next steps are to get the Meego system running usefully (which includes getting a terminal as currently I just have a login prompt but no way of inputting anything!) and also seeing whether I can get dual booting working with an Android system standard boot and Meego replacing the recovery boot.
Poor pic, but still: http://people.bath.ac.uk/enpsgp/Tab/PICT0040.JPG
Good stuff. Thanks for keeping us informed.
After you've got the groundwork for this done, how easy would it be to get Ubuntu running?
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
brilldoctor said:
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
That's using chroot, which I don't want. I want it running natively.
Sent from my Galaxy Tab
So, I was doing some research on how you can change it and I ended up finding this in initramfs/etc/scripts/init_sde:
Code:
# Show a nice boot image
case "$PRODUCT_NAME" in
A80S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A80H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A101S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
A101H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
esac
$ZCAT $BOOT_IMAGE > /dev/fb0
And at the top of that file:
Code:
BOOT_IMAGE_BASE="/SDE"
Now, if we could either find those gz files and edit them or extract and link the file to the right place, we'd change it
Any ideas?
Well, first idea would be using root explorer to check, if /SDE folder exists. If not, rooting stock rom, like 4.0.5, with universal rooting tools, and check if it's visible in that rom. I mean, root the stock rom which you install with aos.
julle131 said:
Well, first idea would be using root explorer to check, if /SDE folder exists. If not, rooting stock rom, like 4.0.5, with universal rooting tools, and check if it's visible in that rom. I mean, root the stock rom which you install with aos.
Click to expand...
Click to collapse
Hi
I'll save you the trouble as you won't find an SDE directory anywhere on a rom, "SDE" is just the prefix used for the gz file, e.g SDE-1024x768.gz. The script and Image live in the archos gitorious gpl repo.The image is a bitmap so is simple to change.
Archos GPL Code is built using BuildRoot which is a popular build system for embedded devices, but it's kinda of non-standard for Android.
If you want to do anything with it you will need to run the full Build first by running "make" in the buildroot directory, then afterwards run "make sde" which will create the gzipped image files. The full build takes about an hour as you cannot pass an -j modifies to make when using buildroot . However you only need to do the full make once, Obviously if you know what you're doing you can just run the bitmap through whatever conversion process is being run, then gzip it up but for the easy life it's recommended to do the full build first.
I think the bitmap is being converted to a raw argb file, although don't quote me on that! . Once it's been converted you don't even have to gzip it really as you can replace the "zcat" call with a call to "cat" but it makes no odds either way really apart from in size
To get started have a look here [ gitorious archos-gpl-gen9 tree ], read both the readme files, then you can find the image and build script in the buildroot/packages/sde directory.
Thanks
EDIT: I'll also add that this won't change the "power on" splash, I believe that is displayed by avboot which, from what I can gather is the 3rd stage bootloader, If I recall it was possible ( although dangerous ) to change it on earlier archos devices but due to checks in the gen 9 version there is a very real risk of bricking the device. From the various threads I've read, I believe Letama and Scholbert know more about this.
Hi Quinny899!
Quinny899 said:
So, I was doing some research on how you can change it and I ended up finding this in initramfs/etc/scripts/init_sde:
Code:
# Show a nice boot image
case "$PRODUCT_NAME" in
A80S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A80H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A101S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
A101H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
esac
$ZCAT $BOOT_IMAGE > /dev/fb0
And at the top of that file:
Code:
BOOT_IMAGE_BASE="/SDE"
Now, if we could either find those gz files and edit them or extract and link the file to the right place, we'd change it
Any ideas?
Click to expand...
Click to collapse
I'd suggest to read this thread in the Gen8 section completely.
http://forum.xda-developers.com/showthread.php?t=1290242
AFAIK, nothing changed on the Gen9 devices.
To point it out again:
It's risky... if you mix things up in the rawfs, you'll brick your tablet... at least it will stuck in bootloader.
Someday we'll be able to recover
Anyway, please be aware of this!
By wiping the boot logo you're entering low level hacking.
trevd said:
EDIT: I'll also add that this won't change the "power on" splash, I believe that is displayed by avboot which, from what I can gather is the 3rd stage bootloader, If I recall it was possible ( although dangerous ) to change it on earlier archos devices but due to checks in the gen 9 version there is a very real risk of bricking the device. From the various threads I've read, I believe Letama and Scholbert know more about this.
Click to expand...
Click to collapse
Nothing to add here... anyway here i am
Letama wrote a tool to parse the files inside rawfs and tweak them. See the thread i pointed to in my above statement!
Best regards,
scholbert
Hello everyone! Just like others here, I've been somewhat spooked by our inability to enter Ouya's Recovery partition at the earliest stage of booting, meaning a bad flash of the Boot partition would leave the device inoperable. When I heard that Ouya's stock firmware updates were possibly bricking a few units out there, I decided to block updates on mine and see if I could transform the Boot partition such that it would become a logical extension of the bootloader. What I ended up with is something close to the "Ouya Safe Recovery" project, where a user should only need to flash Boot one additional time, along with chain-loading support as well.
Chain-loading in this case refers to the booting of ROM kernel images that reside as regular IMG files under the /sdcard and/or /system filesystems. With this capability it is possible to choose an image to run when the Ouya turns on. As an example, one may wish to set up a 2nd/test kernel+ramdisk image to use with your installed ROM, or he may wish to run Tuomas Kulve's Debian project from time-to-time without having to set up the USB cable for Fastboot mode. When dealing with distinctly different ROMs (not just alternate kernels), only one of them may install to the Ouya's built-in storage (e.g., /system); others must have been designed/created to use external storage.
An image for the Recovery partition is available along with the Boot. The former may be helpful if you wish to try out the boot menu before performing the flash of the Boot partition, or are generally okay with bouncing to Recovery before invoking a chain-load. Either of these may be tested from Fastboot mode, but do note that a successful chain-load requires that the image actually be flashed to the Ouya. (Otherwise it just reboots.) The ClockworkMod (CWM) recovery application is available on both images and is accessible from the boot menu.
Additional Information
There are a few things to consider when deciding if this approach makes sense for you:
- Users of the "Ouya Safe Recovery" project may want to stay put unless the dual-boot aspect is of interest. If so then it would be cleanest to choose my Boot image; the Recovery partition (your ROM image) could be left alone.
- The images here are not compatible with Ouya's stock firmware, due to the auto-update nature of Ouya's ROM. Either your flashed Boot image would get overwritten, or an installed non-Ouya Recovery might cause that update to hang. Therefore, you should be prepared to switch to one of the ROMs here at XDA. If you're currently on stock and don't want to switch right away, that's fine; we'll go over how to block updates for the time being.
- The Ouya CM10 ROM is nice in that it provides the IMG file separately, allowing us to handle it as we wish. However, the other ROMs end up placing their boot.img in the main ZIP. This is standard practice for other devices, but we need to be careful ensuring our Boot partition doesn't get reflashed as part of the ROM installation. Therefore, it would be necessary to investigate repackaging the ROM with an alternate updater-script prior to installation. See my StockPlus post on page 2 for more. (This shouldn't affect those who've opted for my Recovery image.)
This feature is based on CWM's initial ramdisk, and includes a new boot menu application that comes up prior to CWM itself. Basically, CWM shows up later if the menu application exits for any reason. The Ouya stock kernel (561) has also been compiled with HDMI's copy protection turned off, and includes two patch sets:
- KExec-HardBoot is the key to chain-loading on our platform. It overcomes standard KExec's lack of hardware reset (and thus failed execution) by triggering a reboot in the middle of the preparation of the new kernel. This ingenious system has been developed by Tasssadar and others over in the Nexus forums. (Be sure to enable CONFIG_TEGRA_HARDBOOT_RECOVERY if interested in compiling a Recovery kernel.)
- HDMI visual stability has been improved with a little hack of mine: a significant relaxing of a timer in the driver. (The latest Android source has corrected the instability with a significant design change, but my hack seems fine enough for this project.) Also picked up specific Android fixes in the area of Framebuffer double-buffering, as that needs to be working for CWM usability.
Installation
If you're on Ouya's stock firmware, then you should make sure that any future updates do not get applied. There is a project here ("Mod Collection For Ouya") that should help. I personally side-loaded the Baxy custom launcher to avoid Ouya's update environment. It is also likely necessary to stay out of the Ouya/Discover store if going the custom launcher route as I believe the store app can trigger an update.
At this point you can download your chosen image (Boot or Recovery) and unzip to get the IMG file. Boot your Ouya to a working Root/BusyBox environment (ROM or Recovery), and then transfer the IMG to the Ouya. (An example using ADB would be "adb push boot102513.img /sdcard/boot102513.img".)
Bring up the Ouya command prompt (e.g., "adb shell") and run these commands to get started:
su [command not present on CWM - that's okay]
cd /dev/block/platform/sdhci-tegra.3/by-name
ls
You should see the various 3-letter partition names from that last command. Your command prompt should also contain the "#" character to denote root-level access. This next step will save off your current ROM image, both because we may end up overwriting it, and because the saved file will end up as your main bootable kernel for the chain-loader. Run:
cat LNX > /sdcard/kernel.img
(If configured for "Ouya Safe Recovery," then replace the preceding "LNX" with "SOS".)
We are near the flashing stage. Check to make sure your Ouya has a reliable source of power, preferrably from an uninterruptable power supply. Recall that a bad flash of my boot image can leave the device inoperable, but I feel the risk is very low provided the following directions are heeded. Fortunately the flash process only takes a few seconds.
For the Boot image option, verify by running:
md5sum /sdcard/boot102513.img
Do not proceed unless you get "e4b1b1ad553e55ad0b2ce3fb8f5bf623".
Again for the Boot image option, flash to the Ouya by running:
dd if=/sdcard/boot102513.img of=LNX
For the Recovery image option, verify by running:
md5sum /sdcard/rcvy102513.img
Do not proceed unless you get "dda0811a7e8e82a7d4ad3fa4c3ae35e4".
Again for the Recovery image option, flash to the Ouya by running:
dd if=/sdcard/rcvy102513.img of=SOS
You may optionally verify (post-flash) by running "md5sum" on the partition name. Finish up with these commands:
sync
reboot
Usage / Configuration
The menu should come up, defaulting to "kernel.img" for the Boot image and "CWM" for Recovery. That default will then launch after ten seconds of inactivity. You may also briefly press the Ouya power button during the wait to advance through the options. The option list is 1) kernel.img, 2) kernelA1.img, 3) kernelA2.img, 4) CWM, and 5) Recovery Partition.
The defaults from above should be fine for most everyone, but it is possible to fine-tune them. An optional configuration file (/sdcard/bootmenu_b.cfg for Boot, /sdcard/bootmenu_r.cfg for Recovery) may be established to specify the default menu entry as well as the inactivity timeout. As an example, the following command would make Recovery start kernelA1.img after five seconds:
echo "2 5" > /sdcard/bootmenu_r.cfg
It is hoped that the menu would never hang. If it does, then waiting a full minute should allow CWM to start. Otherwise, it may be necessary to attach a wired/USB keyboard and type in the Alt-SysRq-X sequence, similar to Ctrl-Alt-Delete on a PC. The sequence might have to be done early on in the menu startup process, and should blink the Ouya light and place it in Fastboot mode.
The menu may unexpectedly place you in CWM, which would indicate an issue with a chain-load. The reason may be due to a missing or corrupt IMG file. Otherwise you should be able to determine why by checking /tmp/bootmenu.log against the attached source code.
---
I hope this project will be of help to others!
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.
Wow, really great. Thanks a lot for your effort
Gesendet von meinem One X+ mit Tapatalk
nchantmnt said:
Wow, really great. Thanks a lot for your effort
Click to expand...
Click to collapse
My pleasure, nchantmnt. Hope your new Ouya is helping you feel at home!
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Gesendet von meinem One X+ mit Tapatalk
nchantmnt said:
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Click to expand...
Click to collapse
Gosh, I'm very sorry to hear that. Do think ahead to the upcoming holiday season, and may it be a time to reflect and anticipate a fruitful 2014.
@Hal9k+1 - THANK YOU!
I was so nervous flashing CWM and StockPlus as there is no real way to fix things if something goes wrong. This should give people more confidence when flashing their Ouya.
I understand the process using ADB...my question is: can this be used from CWM somehow?
PS. I assume new kernel will always be flashable from CWM, the hack does not require 561 specifically.
Ipse_Tase said:
I understand the process using ADB...my question is: can this be used from CWM somehow?
Click to expand...
Click to collapse
Hi Ipse_Tase - I do hope the feature will be helpful to you and others.
As I think about your question, I suppose I could have have created a ZIP that would have been installed by CWM. Similarly I could have worked through some form of installation shell script. But for an important operation such as flashing, I prefer the one-at-a-time approach of the interactive shell.
Note that CWM does have an ADB service running with it. Your Ouya would show up as a different device while in CWM, so you'd need to enter Device Manager (Windows) and point the unknown device to the same ADB driver as used for the main ROM.
Alternatively you could skip ADB for this Ouya Boot Menu installation and set up an SSH server on your main ROM. I personally have installed "SSH Server" (Ice Cold Apps). I recall two screens to set up (does require the trackpad in cases), where I enabled automatic start on both, and also set the port number to 2222. After an Ouya reboot I had SSH/SCP capability and could use PuTTY/pscp from Windows.
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
For a developer, I'm sure it's easier and more familiar to run ADB commands - for people like me (5%-over-the average-user) a CVM option to flash a zip and do all this would be more in-line with the abilities to hack.
I have rooted 4-5 devices so far and the only time I type any ADB commands is at root/unlock time - sometimes not even then (Nexus 4 and the Root Toolkit).
So if you ever consider creating a recovery flashable file, it would help many. Probably not me, as by then I would have done the ADB trick
Sounds like great work! I was hoping to implement something like this myself, but I haven't made any more time for OUYA-related development in a while (due to positive life events/busyness)
I will definitely take a look at your work when I have time!
~Troop
Ipse_Tase said:
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
Click to expand...
Click to collapse
You got it! You don't need to worry about booting to the other partition prior to flashing. That is a given partition (LNX/SOS) is no longer being accessed once the image is booted. For CWM's ADB, you'd simply point Windows to the same INF file that you originally used. Hope this helps.
StockPlus Installation
Well, I finally retired this old stock 393 ROM I was on, and moved to StockPlus 519r2. I was not able to install it the normal way given my Boot image is in place here. So I ended up modifying "updater-script" under META-INF/com/google/android, and then repackaged prior to running the install procedure. I'm attaching my changed version in case it helps anyone, and please note that it makes StockPlus the main image (kernel.img).
(You'll need to right-click to save the attachment. Once done it will need to be renamed such that it does not include the ".txt" suffix.)
The Windows "7-Zip" utility is helpful for packaging. You may start by right-clicking the downloaded ZIP, then 7-Zip --> Extract to "OUYA_[...]". Enter the newly created directory, get to the updater-script, and replace it with mine. Now back up to the area with META-INF, system, and boot.img, still in the new directory. Select all three under Windows (Ctrl+Click), right click that area, and then 7-Zip --> Add to "OUYA_[...].zip". Be sure this new ZIP is the one that makes it to the Ouya.
Still haven't tried this out yet, but I hope to soon.
I missed out on news over the holidays though and just noticed this:
Announcing Ubuntu and Android dual boot developer preview
http://developer.ubuntu.com/2013/12/announcing-ubuntu-and-android-dual-boot-developer-preview/
I'm curious of their dual boot implementation and how it compares and if we can synergize with their approach, but haven't looked into the details of how theirs works yet (its sounds like it uses a custom recovery image, and they have the ability to trigger it to reboot into Ubuntu from an Android app and vice versa, which is cool)
It'd be awesome to be able to multi-boot an Ouya ROM, an Android ROM (CyanogenMod), and Ubuntu with that kind of ease.
EDIT: This may be more our speed though: (MultiROM)
http://forum.xda-developers.com/showthread.php?t=2011403
(did you pull anything from there? Sounds like they have a modified TWRP that can flash zips to the other ROM slots, which is something I was also hoping to implement)
~Troop
Thanks, Trooper. Good to see Ubuntu moving further along in the mobile world.
I briefly looked at MultiROM since it originated from the KExec-HardBoot work, but decided not to go in that direction. The main reason is that I decided not to pursue the setup/learning of an Android build environment, but also because it wasn't clear how I'd deal with our lack of a touchscreen and lack of volume up/down buttons. I ended up creating a small application that fits within Ouya's CWM framework and starts up before CWM itself; it monitors the power button for click events and writes to the framebuffer memory region using regular Linux calls.
I'm not too concerned about the dual-boot aspect of this new Ubuntu, but the lack of touchscreen could be a hindrance if mouse/keyboard were not a viable substitute. Whether this Ubuntu is designed to work from external storage is another question, since our /system and /data would be occupied by Android. But in general I think we could boot it from my framework, and if my Boot image were selected over the Recovery one, then the Ubuntu kernel could reside in Recovery and also be bootable from the Android side with the "reboot recovery" command.
Best of luck, and hope you'll have a chance to try it all!
accidental post please delete
Hi everybody,
I'm trying to bring back to life a GT-P1000 that had a damaged internal storage. After physically removing the damaged chip, I managed to install CyanogenMod 11 (Android 4.4) on a partitioned external SD card. However, though the device runs fine, I can't save/download any file, as there's no writable partition set up.
I've read many things about modifying a vold.fstab file for that matter… but all those guides/howtos regard previous Android versions. But starting with Android 4.4, such file no longer exists.
From what I've understood, there is now an etc/fstab file that is recreated/generated at boot from "some place", but I've yet to discover where and how to manipulate it.
Any idea ?
Android has different services e.g. vold for managing different storage types. These have also different places where they are configured. E.g in init scripts or storage_list.xml.
And even worse this differs between Android versions.
/etc/fstab is just the result where all this is thrown together. And as you noticed it's regenerated on every reboot.
As a starting point you can find an overview where the configuration is actually coming from depending on the Android version at
https://source.android.com/devices/storage/config.html
https://source.android.com/devices/storage/config-example.html
Hello u42671,
Thank you for those pointers, they are very interesting indeed and I now understand much better how it all wraps up (though there's no storage_list.xml file on my device).
However, I still don't know how/where the different init scripts are generated on reboot. Do you have any idea ?
The init scripts should be stable and not be regenerated in every reboot. Android init system is a bit different to what you might know from other Linux distributions .
See http://elinux.org/Android_Booting
I don't have my Galaxy Tab at hand now in order to check but device specific mounts are probably setup in the init.p1.rc script located directly in the root directory.
Actually the init scripts might also come from boot.img. So you should also check this. See
http://android-dls.com/wiki/index.p..._Images#Structure_of_boot_and_recovery_images
/init.rc calls /init.p1.rc that in turn does "mount_all /fstab.p1"
However, all those 3 files seem to be recreated at boot.
I'm still reading your links and trying to put it all together… but that looks about right so far.
That's why I added the comment about boot.img. boot.img does also contain the init files. After all,
the stuff inside boot.img is supposed to do the basic tasks before filesystems are mounted. I suspect that you have to extract boot.img, change the init scripts there and then repack and reflash boot img if you want the changes to survive a reboot.
Thread necromancy here !
I tried for months to unpack that boot.img, to no avail… I actually think I understood that the GT-P1000 uses zImage, but still : no tool I've found so far managed to unpack the bloody thing. Most seem to be outdated.
So, I'm gonna try feroxxx's CM13 beta (http://forum.xda-developers.com/galaxy-tab/development/rombeta-cyanogenmod-13-0-t3356495) and pray really really hard that it works…
Good news : @feroxxx's CM13 (and TWRP !) both install as intended ! See http://forum.xda-developers.com/showpost.php?p=68697664&postcount=93
Bad news : CM still does not understand to use the FAT32 partition of the external SD card as /sdcard. Needs more work…
I propose a single script that generates images for any android compatible phone. It will (maybe?) require a bootloader unlock, the kernel source, and a cached 'update.zip' or internet connection, but not much else.
Essentially, all you will need to do is plug in your phone and run the script as an admin (sudo sh ubuntuphone-auto.sh). Then, the script will install all of the (cached) dependencies, automatically download (or used the cached one) the system's flash/update zip, and compile ubuntu with the contained images.
It should also do a sideload of a processor test (if compatible) and warn of currently incompatible or too hot/slow hardware while it's compiling on the computer.
This will help clear out that system fragmentation thing where it's hard to develop for all systems. We should add options for a bunch of android app stores to be installed. (Something like 'do you want the play store' and if they press enter it skips it. The generic install without any extras will need you to put a --generic or hold down the enter key)
The script will be just that - a bash or python script that has a comment at the end of each line with a line number and a note briefly explaining what you can change on that line.
We eventually could make it not just for ubuntu, but for every arm based OS like CM13, FireOS, etc.
However, things should start small... Let's just start with Ubuntu.
runed.OS said:
I propose a single script that generates images for any android compatible phone. It will (maybe?) require a bootloader unlock, the kernel source, and a cached 'update.zip' or internet connection, but not much else.
Essentially, all you will need to do is plug in your phone and run the script as an admin (sudo sh ubuntuphone-auto.sh). Then, the script will install all of the (cached) dependencies, automatically download (or used the cached one) the system's flash/update zip, and compile ubuntu with the contained images.
It should also do a sideload of a processor test (if compatible) and warn of currently incompatible or too hot/slow hardware while it's compiling on the computer.
This will help clear out that system fragmentation thing where it's hard to develop for all systems. We should add options for a bunch of android app stores to be installed. (Something like 'do you want the play store' and if they press enter it skips it. The generic install without any extras will need you to put a --generic or hold down the enter key)
The script will be just that - a bash or python script that has a comment at the end of each line with a line number and a note briefly explaining what you can change on that line.
We eventually could make it not just for ubuntu, but for every arm based OS like CM13, FireOS, etc.
However, things should start small... Let's just start with Ubuntu.
Click to expand...
Click to collapse
If that script had existed, we would'nt had a need in developers at all
This script would be a reality only in ideal world with open drivers. Because of rush in smartphone production we have binary blobs with tons of lags and devices with unupgradable kernels at all (that are VERY important for security).
the reality is that not all companies release AOSP sources for their device, this devices need patches in order to provide all functions of phone, and in fact enthuthiasts do a little reverse-engineering work where possible.
This script isn't possible now, maybe in few years when machines will learn reverse-engineering and some logic.
But generally idea is nice, implementation will lack for some time
Haha, look! Ubuntu just made one of these! It only works for their phones, though.
runed.OS said:
Haha, look! Ubuntu just made one of these! It only works for their phones, though.
Click to expand...
Click to collapse
No, it doesn't work as you want.
You still have to download binary drivers and place them manually in corresponding folder. It doesn't automatically port ROM
Plus you have to download precompiled kernel for UT separately.
It's FAR for script you want.