Related
I didn't think it belonged in Dream Android Development, so I'm putting it here. If it needs to be moved, move it.
Is it possible to boot anything other than Android on the Dream?
I've seen the Nokia N900 and its Maemo 5 firmware, and I'm absolutely drawn to it, thanks to its debian-based OS (sudo apt-get install anything), it's X-based graphics system (REAL linux GUI programs), and all the apps it already has (Native Gizmo > Hacky Sipdroid).
I've also taken a look at other Linux-based open phone firmwares.
What is keeping us from doing this? If it's drivers, do they exist for another similar Linux-based firmware?
Could we dual-boot Android and this other OS using a third-stage bootloader which loads as a kernel from within the BOOT: partition?
I've seen the (albeit extremely hackish) method of getting Debian on the G1, chrooting into a loop-mounted FS and using a loopback VNC to spring into a KDE/Gnome/LXDE UI, but it's slow, still has Android and its apps loaded into memory, and very hackish and unstable.
I'm more than willing to test anything firmware-wise on my phone as long as it doesn't mess with my SPL.
The possibilities are nearly limitless - WINE under Linux means true "Windows Mobile" without the WinCE kernel.
Or perhaps WinMo/WinCE can be booted on the Dream?
It's more of a question of whether or not it's possible right now than a concept or implementation, but once that's answered, I'll either throw some time into testing and porting, or kick back and enjoy the Android as it is.
For starters:
- How does the SPL hand off to the BOOT: partition and its kernel/initrd?
- What devices need what drivers? What should be thrown into the kernel?
- Do things need reverse-engineering or is it all straightforward and documented?
- How can we use the space provided without messing with the SPL? (use cache partition for OS? Modified recovery that doesn't depend on cache partition?)
- Is dual-booting between Android possible? Can this be switched and launched before Dalvik and the Android stuff loads on the Android kernel?
- Can this be done with other Android-powered, rooted devices?
Have you seen wiki.openmoko.org/wiki/OpenMoko_on_HTC-Dream or lists.openmoko.org/pipermail/community/2009-August/052529.html? (Crap, I can't post links) Looks promising since Angstrom is a very powerful embedded distro, but it's a one-man project now. I hope some people will join it or start a similar project.
G1 is a great device, however, I can see only a few people hacking on OS alternatives for it. You always got to have either an active community or a company in order to complete such a project.
The Android hackers community is very vibrant, however, people are not really interested in bringing a fully-featured Linux distro to G1 or other Android phones. Android is too trendy itself
The Debian/Ubuntu opportunity that we have now is nice, but it looks like an addition to the Android which takes a lot of memory and CPU.
I have just set up a small Ubuntu environment booting on my G1 together with Android. I combined the userspace prepared by Paolo Sammicheli (xdatap1.wordpress.com/2009/05/03/jaunty-under-android/) with Bayle Shanks's instructions (bayleshanks.com/wiki.pl?tips-computer-android-g1_debian_cyanogenMod). I am going to use it for mutt, vim, some coding. X11/VNC experience has been frustrating so far.
I am pretty sure though that there will be more people wanting to use alternative OSes on their phones: Moto Droid and Nexus are powerful enough for a full desktop environment.
vaskas said:
Have you seen wiki.openmoko.org/wiki/OpenMoko_on_HTC-Dream or lists.openmoko.org/pipermail/community/2009-August/052529.html? (Crap, I can't post links) Looks promising since Angstrom is a very powerful embedded distro, but it's a one-man project now. I hope some people will join it or start a similar project.
G1 is a great device, however, I can see only a few people hacking on OS alternatives for it. You always got to have either an active community or a company in order to complete such a project.
The Android hackers community is very vibrant, however, people are not really interested in bringing a fully-featured Linux distro to G1 or other Android phones. Android is too trendy itself
The Debian/Ubuntu opportunity that we have now is nice, but it looks like an addition to the Android which takes a lot of memory and CPU.
I have just set up a small Ubuntu environment booting on my G1 together with Android. I combined the userspace prepared by Paolo Sammicheli (xdatap1.wordpress.com/2009/05/03/jaunty-under-android/) with Bayle Shanks's instructions (bayleshanks.com/wiki.pl?tips-computer-android-g1_debian_cyanogenMod). I am going to use it for mutt, vim, some coding. X11/VNC experience has been frustrating so far.
I am pretty sure though that there will be more people wanting to use alternative OSes on their phones: Moto Droid and Nexus are powerful enough for a full desktop environment.
Click to expand...
Click to collapse
i really think it lies in what you want from your phone... i know you say you use your ubuntu env for things such as vim and mutt, but everything that vim and mutt can do, can already be done under android..
the biggest challenge is getting people to latch on to an alternate distro which offers MORE than android, which has yet to come to surface... ultimately this is a phone.. not a netbook...and for a phone android is pretty dam sweet...
although in terms of geek work, running ANY other os on non native hardware is cool....albeit not really worth it
anybody were successful by using the internal-memory-image from the openmoko wiki?
I always get kernel panic, when booting it. I flashed it with flash_image boot/system, does this matter? In the wiki they use fastboot.
scheich, I only tried the SD-card way (see my post in http://forum.xda-developers.com/showthread.php?t=624392)
It shouldn't really matter whether you use fastboot or flash the image. The kernel panic could occur due to the inability to find the root filesystem. Try reflashing the yaffs2.
By the way, why did you choose to put OpenMoko in the internal memory? Are you going to use it exclusively or as the primary OS on the device?
Some of what you suggest can be done, but not recommended.
1) Nokia/Maemo is a bad fit for a phone. It is a real HOG. It is also shoehorning (with a sledge hammer) a desktop OS into a phone. It just doesn't work right. Android exists because a totally new UI model was needed to work optimally with a phone's physical form.
2) WINE will NEVER work since the CPU in the phone is ARM and not x86. If you want to run windonkey programs (can't imagine why you would), you would have to run a PROCESSOR EMULATOR, and this will be REALLY REALLY REALLY slow and memory intense.
TylTru said:
I didn't think it belonged in Dream Android Development, so I'm putting it here. If it needs to be moved, move it.
Is it possible to boot anything other than Android on the Dream?
I've seen the Nokia N900 and its Maemo 5 firmware, and I'm absolutely drawn to it, thanks to its debian-based OS (sudo apt-get install anything), it's X-based graphics system (REAL linux GUI programs), and all the apps it already has (Native Gizmo > Hacky Sipdroid).
I've also taken a look at other Linux-based open phone firmwares.
What is keeping us from doing this? If it's drivers, do they exist for another similar Linux-based firmware?
Could we dual-boot Android and this other OS using a third-stage bootloader which loads as a kernel from within the BOOT: partition?
I've seen the (albeit extremely hackish) method of getting Debian on the G1, chrooting into a loop-mounted FS and using a loopback VNC to spring into a KDE/Gnome/LXDE UI, but it's slow, still has Android and its apps loaded into memory, and very hackish and unstable.
I'm more than willing to test anything firmware-wise on my phone as long as it doesn't mess with my SPL.
The possibilities are nearly limitless - WINE under Linux means true "Windows Mobile" without the WinCE kernel.
Or perhaps WinMo/WinCE can be booted on the Dream?
It's more of a question of whether or not it's possible right now than a concept or implementation, but once that's answered, I'll either throw some time into testing and porting, or kick back and enjoy the Android as it is.
For starters:
- How does the SPL hand off to the BOOT: partition and its kernel/initrd?
- What devices need what drivers? What should be thrown into the kernel?
- Do things need reverse-engineering or is it all straightforward and documented?
- How can we use the space provided without messing with the SPL? (use cache partition for OS? Modified recovery that doesn't depend on cache partition?)
- Is dual-booting between Android possible? Can this be switched and launched before Dalvik and the Android stuff loads on the Android kernel?
- Can this be done with other Android-powered, rooted devices?
Click to expand...
Click to collapse
vaskas said:
scheich, I only tried the SD-card way (see my post in http://forum.xda-developers.com/showthread.php?t=624392)
It shouldn't really matter whether you use fastboot or flash the image. The kernel panic could occur due to the inability to find the root filesystem. Try reflashing the yaffs2.
Click to expand...
Click to collapse
Tried reflashing the system image. Also the older image on the ftpserver. The same. I will try the sdcard installation.
vaskas said:
By the way, why did you choose to put OpenMoko in the internal memory? Are you going to use it exclusively or as the primary OS on the device?
Click to expand...
Click to collapse
Two reasons:
1. Thought that would be the faster way to get it work. I used BART to backup my android installation.
2. Thougt, I would get a bit more perfomance in using the internal memory.
I really would like to use SHR(or other) as primary OS, because I had an GTA02, depends on what is(could) work(ing) on the dream.
would it be possible to boot ubuntu netbook remix? it uses far less resources.
zenstitution said:
would it be possible to boot ubuntu netbook remix? it uses far less resources.
Click to expand...
Click to collapse
NBR is targeted at x86, but Ubuntu MID edition is installable. It's similar to the netbook remix. We'll have to wait before we have a proven/stable installation method though.
I would really like to see another OS on my Dream as well - just in addition to android
Che123 said:
I would really like to see another OS on my Dream as well - just in addition to android
Click to expand...
Click to collapse
Well, you can try the OpenMoko port (it's in the alpha stage now): http://forum.xda-developers.com/showthread.php?p=5521417
The more people get interested in the alternative OS, the sooner we'll get one.
vaskas said:
Well, you can try the OpenMoko port (it's in the alpha stage now): http://forum.xda-developers.com/showthread.php?p=5521417
The more people get interested in the alternative OS, the sooner we'll get one.
Click to expand...
Click to collapse
Really hot stuff - but i don't want to loose my recovery
But i will definetly keep an eye on it!
edit: Adding a bootmngr like grub for selecting boot OS (android/openmoko/recovery) would be really nice Or adding bootoptions to the current amon_ra Recovery would be a soloution too. But I'm no dev, so I don't even know if it is possible.
This distro was created with all the tools needed for android development. After you install this os, you're ready to start developing for Android.
GreenRom Dev Kt is now available. It has Android SDK/NDK, Eclipse, ADB(from any location!), ThemerStudio, all required dependencies for compiling roms, repo init for pulling source code from github, and Gimp for theming/editing graphics.
Q:Why is this important?
A:Because all you need to do is install this OS, plug in your phone, and begin having fun as you dev. There's no need to try and download and install ANYTHING for Android development because it's all been done for you. Do you need to run ADB Logcat? Go ahead. Now there's no need to make sure you're in a certain directory because you can run ADB from anywhere.
Some common questions might be:
Q:Do I have to install GRPdevkit to my HDD?
A:No, you can run it from live mode and store your progress on a pen drive. Alternately, you can install it on a pen/usb drive and run it from that if your bios detects usb drives.
Q:Will I be able to install this alongside another OS?
A:Possibly, although LivLogik and I haven't had any luck with dual booting this nor Ubuntu.
Q:Will this screw up my computer?
A:As with any Linux OS that's experimental, the possibility is there, although LivLogik and I have been testing this OS extensively to ensure all the bugs have been work out before making it available to you. Nevertheless, we are in no way responsible for your actions!
Q:What if I don't want to dev and just want to use this for an every day system?
A:That's quite fine as this OS is built from Linux Mint 11 and has all the stuff you probably use such as Brasero, X-Chat, Transmission, Libre Office, Movie Player, Calculator, Pidgin, G-Thumb, and much more!
Q:What if I can't burn an installation disk?
A:As with the majority of mainstream Linux Distros, we will be offering an installation disk for a small fee + s&h. LivLogik and I have to come up with a design for the cd decal as I have access to a cd printer. We will post the availability when we come up with it.
Q:How do I use the tools that are in this?
A:There is a get started guide on the desktop that you can move to your home folder or delete that explains briefly how to use the tools, however, I didn't include instructions on Eclipse as I've never used it. For Eclipse just go to it's website here: http://eclipsetutorial.sourceforge.net/totalbeginner.html and learn how to use it. Eclipse is used to make programs for Android.
LivLogik will be making a video so that you can see it in action. Enjoy!!
Note: you may need to right click on the desktop and change the wallpaper mode setting from zoom to whatever fits your screen best. -Fixed in update
**EDIT** if you have problems signing in to gtalk on the messanger... go to software manager and in the search box type in gtalk and download that plugin and it should work and if you have problems with anymore accounts like facebook do the same and it should work fine -Fixed in update
CLICK HERE TO VIEW THE VIDEO !!!! (it shows a run through of it and also sorta where everything is and a little how to - livlogik
Video #2 Updates For v1.1
============> grpdevkit.iso - 2.0 GB <============
MIRROR >>>---------------> http://dev-host.org/fj1lh8zu4g60/grpdevkit.iso <-----------------<<<
Code:
[color=green]Change Log: [/color]
(07-22-11 v1.1) :
~Added Chrome Browser
~Added plugin for Gtalk
~Shortcut for SDK/NDK in home folder
~Added shortcut for GRP forum
~Added different wallpaper([color=blue]thanks LivLogik[/color])
(6-?-11 v1) :
~Linux Mint 11(Katya) as Distro base [URL=http://www.linuxmint.com/]Linux Mint11[/URL]
~Remastersys(for building the distro [url]http://remastersys.sourceforge.net/[/url])
~Added GRP custom default wallpaper([color=blue]thanks LivLogik[/color])
~Added Android NDK
~Added Android SDK
~Added all required dependencies for compiling Android OS as follows:
git-core, gnupg, flex bison, gperf, libsdl1.2-dev, libesd0-dev, libwxgtk2.6-dev, squashfs-tools, build-essential zip curl, libncurses5-dev, zlib1g-dev,
sun-java6-jdk, pngcrush, schedtool, lib32z1-dev, lib32ncurses5-dev, lib32readline5-dev
~Added ADB( thanks to Tahl:[URL=http://www.rootzwiki.com/showthread.php?589-Android-SDK-NDK-Eclipse-and-ADB-Auto-Installer-(Ubuntu-Linux-Mint)]Tahl's tread[/URL])
~Added Gimp
~Added ThemerStudio(thanks to CorCor67:[URL=http://corcor67.blogspot.com/p/themer-studio.html]CorCor's blog[/URL])
~Added Repo Init to home directory
[color=red]Testers:[/color]
LivLogik
SlashDW
whoever else has tested or is running the Dev Kit let me know so I can include you in the testers credits. ;-)
epic!? I think so.
Treken said:
This distro was created with all the tools needed for android development. After you install this os, you're ready to start developing for Android. Check it out here: http://greenromproject.com/showthread.php?188-GreenRom-Dev-Kit-is-here!!-64bit(updated-7-23-11)
And, of course, enjoy!
Click to expand...
Click to collapse
Nice! This should save a ton of setup time when I install a new distro
Sent from my ADR6300 using XDA App
AWESOME! Finally, I can run Linux simply. Expect ROM's from me!
EASY Set-up! Now to figure out how to do everything else..... :/
Smokeey said:
EASY Set-up! Now to figure out how to do everything else..... :/
Click to expand...
Click to collapse
If you need some help with anything just let me know.
Wow. downloaded.
vassskk said:
Wow. downloaded.
Click to expand...
Click to collapse
how was the download speed? The server will be getting a make-over tomorrow and should beef up the download speed.
I'm assuming I can make this into a persistent usb and take it anywhere and work on it? Regardless I'm going to give it a shot.
DL started at 700 and dropped 1kB/s every 2 seconds continuously, then dropped out. I thought it was an artifact of the averaging done by Google Chrome; except it was linear, 2 seconds every time.
bogwurm said:
I'm assuming I can make this into a persistent usb and take it anywhere and work on it? Regardless I'm going to give it a shot.
Click to expand...
Click to collapse
Please see #2
Q: Do I have to install GRPdevkit to my HDD?
A: No, you can run it from live mode and store your progress on a pen drive. Alternately, you can install it on a pen/usb drive and run it from that if your bios detects usb drives.
vassskk said:
Please see #2
Q: Do I have to install GRPdevkit to my HDD?
A: No, you can run it from live mode and store your progress on a pen drive. Alternately, you can install it on a pen/usb drive and run it from that if your bios detects usb drives.
Click to expand...
Click to collapse
And boom goes the dynamite
/Dinc
Very nice work. Thanks for this.
Sent from my ADR6300 using XDA App
vassskk said:
DL started at 700 and dropped 1kB/s every 2 seconds continuously, then dropped out. I thought it was an artifact of the averaging done by Google Chrome; except it was linear, 2 seconds every time.
Click to expand...
Click to collapse
The server went down for a little bit. They beefed up the server speeds so it should download faster now. It should be up and running now
Great.. now I have to stop & get more DVDs. My old laptop doesn't boot from usb. Looking forward to trying it out. Thanks!
OP,
You said you were having trouble paralleling it with other os's? Any ideas why? i was very much hoping to throw it alongside joulicloud (ubuntu based) on my ssd.
vassskk said:
OP,
You said you were having trouble paralleling it with other os's? Any ideas why? i was very much hoping to throw it alongside joulicloud (ubuntu based) on my ssd.
Click to expand...
Click to collapse
I wasn't having any luck dual booting Linux Mint or Ubuntu. I have Windows 7 Ultra that I wanted to dual boot but couldn't get it worked out and just gave up since I have to have Linux for most of the development I do.
beard0 said:
And boom goes the dynamite
/Dinc
Click to expand...
Click to collapse
Dino-mite? Faq said run live and store on usb. Assumption was run live from dvd. Second part of answer was run from usb if BIOS allowed it. That's why I assumed I could run a live usb with a dedicated partition on the same usb. If we didn't have questions then we wouldn't have Devs. But thanx for your input Mr Dynamite.
bogwurm said:
Dino-mite? Faq said run live and store on usb. Assumption was run live from dvd. Second part of answer was run from usb if BIOS allowed it. That's why I assumed I could run a live usb with a dedicated partition on the same usb. If we didn't have questions then we wouldn't have Devs. But thanx for your input Mr Dynamite.
Click to expand...
Click to collapse
You should be able to install on a usb pen drive and save your files on a dedicated partition. Just make sure you have enough room on your pen drive. Look here: Link and see the requirements for doing so. I've never actually installed on a pen drive myself but theoretically speaking it's plausible. Let me know if it works out for you.
Will do thanx for the reply. I know how to set up a persistent live distro but some of them are tricky. I like this idea because all I need is the flash drive to do work on any computer.
"Here and now, boys, here and now."-Aldous Huxley
Hello! I've been just a reader for some months, my questions have been always already answered here for basic things (rooting, performance tips etc) but now it's the time to register and start participating I am a professional programmer, just have been "out" of the development world for the last 1+ year, so I'm a bit untrained now...
I was thinking on buying a BeagleBoard for trying some programming in it, just wanted to see what's the power of that board when doing image processing stuff (namely playing with OpenCV). But, before spending those $130 in one, I realised that my Archos A101IT has almost the same board (SoC), well actually even a bit faster (BeagleBoard comes with OMAP3530 while A101IT comes with OMAP3630).
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Hope you can give me some orientation...
juannm said:
Hello! I've been just a reader for some months, my questions have been always already answered here for basic things (rooting, performance tips etc) but now it's the time to register and start participating I am a professional programmer, just have been "out" of the development world for the last 1+ year, so I'm a bit untrained now...
I was thinking on buying a BeagleBoard for trying some programming in it, just wanted to see what's the power of that board when doing image processing stuff (namely playing with OpenCV). But, before spending those $130 in one, I realised that my Archos A101IT has almost the same board (SoC), well actually even a bit faster (BeagleBoard comes with OMAP3530 while A101IT comes with OMAP3630).
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Hope you can give me some orientation...
Click to expand...
Click to collapse
That isn't anything particaly solid but the best you can do is either install one of the os from here http://forum.xda-developers.com/showthread.php?t=1198389
or look at archos sde http://www.archos.com/support/support_tech/updates_dev.html?country=gb&lang=en
juannm said:
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Click to expand...
Click to collapse
I'm not sure about what really you want to know, but would note the following:
It's possible to run a Linux kernel on Archos, and Ubuntu on it will be "Ubuntu over Linux kernel". The problem is that Archos needs an Archos-friendly kernel, and it's so tweaked that I don't know at what point Linux ends there and Android starts. So here is another problem: it seems rather hard to make the mainline kernel running on Archos. This means that you'll stay with 2.6.29 till the end of your Archos' days... But if you're happy with custom-made GPL'ed 2.6.29 by Archos -- installing "Debian with the lightest Desktop" on it should be no problem. On Archos-Debian.org they've already made a few rootfs images.
Question: justo out of curiosity, do you know if the Debian compilation from (www .debian-archos.com) is made by following this (dev. openaos.org/wiki/Debian%20gen8) ??
In the other hand, I have just installed Urukdroid 1.6 over my previous system (letting the installer to wipe my previous partitions and creating new ones), and now I'm going to try the Angstrom "rootfs.img" option (that I copied somewhere before installing Urukdroid) and also the Debian beta2 one (altough its a wooping 3,8 GB file... I wonder what did this people install in it? KDE? hahah).
Then for cross-compiling from my desktop computer, I guess all I need is the ARM Gcc version, right? I'm in Kubuntu 11.10 so that would be the g++-4.6-arm-linux-gnueabi package (just tell me if this is not the right direction...)
I guess compiling and copying some "hello world" binary file to the Debian or Angstrom in the tablet would be enough for running it, am I right?
Probably, it's better to send an email to OpenAOS people about how they made their package. Also I think it's not a "compilation", but an "installation": standard Debian binaries installed over Archos-specific 2.6.29 kernel. I don't think they recompiled the kernel or built Debian from stratch. The way shown at http://dev.openaos.org/wiki/Debian gen8 is a working one (at least, in general: I don't know about the goodies like wifi, I didn't get that far).
3.8Gb -- it includes free space too: rootfs.img is like a virtual HDD, it contains the system, user data, and free space.
For cross-compilation you need a toolchain: a cross-compiler plus some other tools. Look for Mentor (Codesourcery), Emdebian, OpenEmbedded, Buildroot, etc. Here is a ready-made custom built one: http://forum.xda-developers.com/showthread.php?t=1328027 . Maybe Kubuntu has their own build-in toolchain too, I don't know. Which one is better for you, and how to install and use it -- it depends on many things, actually. Generally: yes, g++-arm-linux-gnueabi looks like a cross-compiler for ARM. And yes, if you cross-compile a "Hello, world!" correctly -- it will run on Archos.
Hi juannm,
welcome to XDA-Developers
juannm said:
I was thinking on buying a BeagleBoard for trying some programming in it, just wanted to see what's the power of that board when doing image processing stuff (namely playing with OpenCV). But, before spending those $130 in one, I realised that my Archos A101IT has almost the same board (SoC), well actually even a bit faster (BeagleBoard comes with OMAP3530 while A101IT comes with OMAP3630).
Click to expand...
Click to collapse
I was able to buy an A101it with was a brick few weeks ago and merely had the same intent. Thought of getting an OMAP3 platform to fiddle around with.
I started to collect some information of the hardware in use.
Luckily i was able to repair it.
For information about that look here:
http://forum.xda-developers.com/showthread.php?t=1199450
The design of the board is pretty clean and apart form running Android OS, Archos offers the SDE as people already pointed out.
You might also start from scratch and build up Ubuntu or Debian images for this device.
In fact i consider it nearly perfect for such experiments.
juannm said:
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
Click to expand...
Click to collapse
What exactly do you mean?
It's too much to built up rootfs from scratch...
Need a starting point?
So basically you'll need to know how the boot process works on these devices, how rootfs is stored and how the rootfs gets mounted during boot up.
First i recommend to install SDE from Archos to get the alternate bootloader installed.
This way you might use bootmenu to load custom kernels and install your own rootfs on top of this.
It's too much to explain it all, so look around and read first.
Just in short:
Stock OS uses squashfs images as rootfs, which are mounted ro if you don't tweak anything.
SDE uses uncompressed EXT2 image, as far as i remember.
It might be a good idea to install UrukDroid (this will wipe out SDE, but leaves Stock OS untouched).
Afterwards you got true EXT4 filesystem, which is still Android but offers a lot of useful tools.
You'll need some background of course and it might be useful to tweak the bootloader to accept the first kernel to be unsigned as well.
http://forum.xda-developers.com/showthread.php?t=1018260
juannm said:
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Click to expand...
Click to collapse
As already pointed out the kernel needs hardware specific tweaks to run on the Archos devices.
So does the Beagleboard kernel.
The vanilla kernel won't do it on these platforms.
Anyway there are some projects which use standard ARM distributions (e.g. Ubuntu, Debian) to get a working Linux on top of a custom kernel, which is based on stock kernel sources (2.6.29-omap1).
If you intent to change to a newer kernel version, there's more work to do.
There'd been some progress for 2.6.35 recently.
It really depends on what you expect to have working on the device.
I might even write more on this, but i guess you'll need to get a better overview yourself.
All i might say is, that Archos give good support for the open development (at least compared to other manufacturers).
They keep their git repo up to date and try to fix bugs as well.
So start hacking and have fun!!
scholbert
Hi there,
Just wanted to add few tidbits on top of what Scholbert said which I agree with 100%:
If you want to tweak the bootloader like Scholbert said to have three different bootable kernels (main android, sde, recovery), contact me first, I have few resources that could help you and add extra safety.
However, I believe that it's not needed at first and safer to get a hold on the platform to go sde route first.
Compared to beagleboard, you won't loose much with the a101, the thing I miss the most is a serial port to help with kernel dev, but even this is possible if you're comfortable with opening the a101 and soldering.
DERP (Device Environment Replacement Program)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
initial pre-alpha version 0.001
(Aug 3, 2013)
by fattire (twitter: @fat__tire)
tldr?
Derp is a general-purpose, platform-independent installer, written in python with wxpython, that executes .derp XML-based scripts to walk the user step-by-step through a ROM installation (or do whatever you want.) The idea is to replace text-based walkthroughs, howtos, and installation instructions by requiring a user to do almost nothing but run a .derp script and sit back. Derp walks through a series of scripted steps (as in, say, a ROM installation) and automatically does all the file downloading/adb/fastboot stuff while the user waits and maybe reads what's happening (at the script author's discretion). Derp also pre-installs and keeps Google's Android SDK tools up to date and even gives adb & fastboot a simple UI. .derp scripts are human-readable XML. Embedding bash and python is also supported in Derp, as is restricting scripts or even script parts to certain platforms. Derp runs as root on the local computer (it's an installer after all), and is open source/GPLv3 licensed. It also comes with sample scripts and a built-in tutorial for creating your own.
Still tldr? It's a script-runner thing!
-----
LONGER DISCUSSION...
WARNING: RIGHT NOW, DEVELOPER TYPES ONLY! This is not for end users...yet. Hopefully people will find bugs and help fix them before an end user uses this on a “live” computer with an actual device. Again, because this is a software installer, DERP AND ITS SCRIPTS RUNS AS ROOT. Never run random .derp or .xml scripts you find on the Internet. This could screw up your device AND your computer, so... treat it just like any other script you’d (not) run as root. Also, the discussion in this forum is how Derp is supposed to work, but of course, there may be (probably are?) bugs.
THE "PROBLEM" AS I SEE IT
Working on the CM wiki, I've grown to appreciate how varied firmware install methods can be. Some devices need rooting. Some need firmware downgrades. Sometimes you can use fastboot. Other times you can’t. Some systems need to unlock the bootloader, etc. etc.
Installing this stuff can be hard. Okay, maybe not for you, but how about your mom or dad? Could your grandparents buy a device today and put CM on it themselves? There's been some chatter on the interwebs about how to make rooting and replacing firmwares easier... some kind of graphical installer seems to be the answer. But there are a million devices out there...
So people have been using text-based HOWTOs, walkthroughs, step-by-step instructions, and/or shell scripts and batch-type files to do this. I thought maybe a generic, unified scripting method might work better that gives the users readable instructions but optionally automatically does technical steps for them.
Hoping to avoid creating yet-another-standard-way-to-do-something, back in February, I searched online for generic installation solutions. But they all seemed to be platform-dependent, or weren’t licensed for general use, or looked really ridiculously complicated....
So (and big caveat here-- I'm not a programmer!) I whipped up a proof-of-concept for developers to play with to start thinking about how to address the issue. It took me a few weeks to get going, but ended up sitting collecting dust for months as I worked on other things and occasionally bothered friends to test the latest version.
Derp is not necessarily intended as any kind of final solution per se-- it’s just for further discussion/testing. A totally legit question to be answered: is this in any way even a good idea?
Let's find out.
SO WHAT IS DERP?
It's a general-purpose installer, written in python with wxpython, that executes .derp XML-based scripts to walk the user step-by-step through a ROM installation, optionally doing all the "technical stuff" like downloading files and running commands in the background. Ideally, you wouldn't have to write a long tutorial for every platform on how to do stuff-- a .derp script could BE the walkthrough.
The first thing Derp does is install the latest adb and fastboot from Google. That looks like this:
(Mac version)
Next, when you run a .derp script, it can automatically download and verify ROM files like CyanogenMod or tools or whatever from the Internet, and then install them.
(Linux version)
(Mac version)
As it does all this, the script can provides information and/or feedback to the user via a UI that hopefully looks like a normal installer. What the user sees is written by the script author in simple HTML. As the .derp script runs, the user simply ftaps "Continue" to proceed through the scripted steps.
As mentioned, .derp scripts are written in XML, which is platform-generic and easy for a human to read. The .derp script syntax, explained below, is also very simple. The script author is also free to embed bash shell scripts or python (or both) if advanced stuff is needed.
Worth mentioning too-- sections, steps, text, actions, or entire scripts can be restricted by the type of computer its running on (ie, don't run certain python commands on Mac, but do run them in Linux, or whatever).
And finally-- while my initial thought was to use this for installations of ROMS like CyanogenMod to a device, I'd think Derp can be used for many kind of installations or scripted operations-- even to wrap a UI around a bash or python script to make it easier for users to run without having to open a Terminal and start typing. Derp scripts don't even have to have to be used for anything to do with mobile devices, though it does pre-set up the Google SDK tools for that purpose.
In fact, a Derp script can do NO actions-- simply serve as a click-through set of HTML-based instructional steps for a user to follow by hand. Conversely, it can say nothing to the user but "Stand by, doing everything." and that's it.
FEATURES:
Easy to install. Debian-based Linux just uses sudo dpkg -i derp_0.001-1_all.deb and it's ready to go. Mac users: it’s Derp.app. Done and done.
Derp is GPLv3-licensed and source code is available now. Read license for terms, conditions, and more disclaimers.
Automatically downloads/updates all SDK tools (primarily adb and fastboot) directly from Google at every launch. So the user is always up to date. (also requires users to agree to Google's T&C...)
Uses an XML-based, OS-neutral installation script format that is easy to write and understand. Just about anything you want the user to do-- restart in bootloader mode, unlock the device, etc-- the derp script should be able to do. Even run bash or python scripts from within the script.
XML Tags:
<derp> - the main tag for a derp script.
<section> - a major category for individual steps.
<step> - Put as many of these in a section as you want.
<info> - The stuff the user sees as the script runs. You can add HTML tags to make it look good.
<file> - tell derp a file’s URL, MD5/SHA hash, and local filename. Derp will grab it and verify it for you automatically. These files can be roms, scripts, recovery images, etc. whatever your script needs to do its job.
<action> - valid “action” types include “adb”, “fastboot”, “python”, and “bash”. Future versions of Derp can add more. <action> allows your script to do stuff. Never worry about whether the user installed and set up the latest versions of adb or fastboot properly. They should "just work".
Using the above tags, you can not only have your scripts automatically do full installations, rooting, bootloader unlocks, etc, but simultaneously tell the user what’s happening behind the scenes if you choose. The user feedback is written in standard HTML-formatted text. The user just hits “Continue” whenever you want to move from one step to the next.
Included are example scripts to install CyanogenMod 10.1.2 on stock Nexus 7, Nexus 4, Galaxy Nexus, and HTC One. The latter script, written by Cowmix, demonstrates how to embed python to interact with the user, and they all include bootloader unlocking.
The only things I can think of that can’t be done automatically are steps that requires hands-on (ie, holding down buttons during power-on) or where, say, debugging mode needs to be manually turned on, or the slider needs to be physically unlocked. In the few cases where user involvement can’t be avoided, the <info> tag can be used to walk them in “real time” through that step.
A built-in tutorial on how to write your own .derp scripts explain how the tags work. (The tutorial itself is a .derp script.)
A console window helps you see what derp is doing in real-time...
Also included: a quick-access adb and fastboot text-entry in the console. This lets you start up Derp and type quick adb or fastboot commands without needing a terminal (or to deal with PATH issues)
“Debug Mode” lets you go through the script without invoking the <action> tags. Makes writing scripts easy.
Derp should automatically detect when a device is connected via adb or fastboot and let you know.
You may filter any Derp tag (including <action> tags) by operating system. This means that using a single script, the user can see different text or the script may behave differently depending on the platform. In fact, you can restrict the entire script to a particular operating system(s).
The script doesn’t actually have to “do” anything. It can be used simply to create walkthroughs or tutorials in a much nicer format than a step-by-step text file. Just link to a .derp file and let it walk the user through whatever. Easy to convert a text walkthrough to an interactive click-through just by adding <section> and <step> tags.
WHY MUST DERP RUN AS ROOT?
Remember, Derp is an installer. It needs to do important stuff, and as such it runs as root. I had considered trying to sandbox the parts that "needed" root and only enable it there and ask for permission for a single operation via an "enter your password" type of dialog box. But because the .derp format is so flexible, there were a million potential places where a script author could do varying kinds of trickery-- by breaking out of Derp to execute python code, spoofing directory paths, abusing the embeddable bash scripts, etc. It just didn't seem to make sense to try to anticipate and counteract all that. Playing cat-and-mouse endlessly is pointless. Again, Derp is an installer. Installers get administration permissions. Just like any installation script you'd run with "sudo" would get. Just like the package installer on OS X. Also, it is much easier to run adb and fastboot with root permission-- you can easily kill all running versions of adb for example, and fastboot seems to prefer it. Plus, it avoids the need for playing with udev configuration stuff in Linux.
This means that, like pretty much every other type of installer, .derp scripts will have full access not only to your mobile device, but to the computer Derp is running on. This seems to make the most sense to me, but I invite others to chime in on improving the design if you disagree.
All caveats and considerations apply. Do not run untrusted scripts, and do not run Derp on a "sensitive" computer (however you wish to define that).
WHAT IS MEANT BY "CROSS-PLATFORM"? (IN OTHER WORDS, WHERE'S THE WINDOWS VERSION?!)
I don't have/use Windows. Right now, Mac & Linux builds are currently available. Derp still needs to be ported to Windows, but since it’s wxpython, and I tried to make as little dependent on the underlying operating system, 95% of the work is hopefully done. Anyone with Windows who’d like to help, let me know.
I think it should be some minor changes to the setup.py file and a few definitions. Also, not sure if Windows supports the “bash” shell...
ANYTHING ELSE?
Ummm... That’s it. Remember, this is a work in progress and a proof of concept... Again, I dunno if anyone will see the value here, and maybe it will need a complete rethink. There are likely to be bugs, maybe even really bad ones. But after a few months of playing around, I kinda feel it’s ready for other developers to at least see and even try in a secure environment (as suggested, maybe a VM or something).
SHOW ME THE CODE!
The code is on github-- please submit commits-- fixes, new features, whatever-- as well as bug reports there. And again, figure there will be tons of bugs to be squashed.
Enjoy.
fattire (@fat__tire)
THANKS TO...
Big thanks for helping me test w/different devices: cowmix, hashcode, kornyone, ciwrl, utkanos, verygreen, and jeagoss
DOWNLOADS:
Debian-based Linux (Debian, Ubuntu, Mint)
derp_0.001-1_all.deb
MD5: 6e8eabe94cdfdba649ea41198211bb64
SHA512: 307aed0ad79de17793bb445d2b588388bf66b42716de36a055227f555bfc12ab3e61d5f0e3de804eb4c0c560f140a6318ea6dd1608cc78ee84b50336895cdfc2
Mac OS X (Tested on: Snow Leopard, Lion, Mountain Lion)
Derp-v0.001-mac.zip
MD5: b738e0a270f53d274baec0ce121577fb
SHA512: 3cf7d438c4dfd0c5c5d7c2f29fe19a76dcbb728acfe73a24e28cdb3f21624510c94f1c4224ad31118851f17205e4d7152619c15281c98189cb33ccac82c1505a
Source code on GITHUB is here.
SAMPLE DERP SCRIPTS
Nexus 7 stock to CM 10.1.2 installer - included (written by me)
Nexus 4 stock to CM 10.1.2 installer - included (written by me)
HTC One stock to CM 10.1 nightly installer - included (written by cowmix)
Galaxy Nexus stock to CM 10.1.2 installer - included (written by cowmix)
EXTERNAL SCRIPTS BY OTHERS
None yet...?
DONATIONS?
Not to me, please. If you feel the need to give someone money, consider donating to the EFF or the Software Freedom Law Center. It's really a donation to your digital rights. (I'm not affiliated with them except as a huge fan and occasional donor.)
REMEMBER, DERP IS EXPERIMENTAL AND YOU RUN IT AT THE RISK OF YOUR COMPUTER, YOUR DEVICE, AND YOUR VERY EXISTENCE AS A HUMAN BEING. I TAKE NO RESPONSIBILITY FOR WHAT DOES OR DOESN'T HAPPEN. DON'T RUN DERP SCRIPTS YOU DON'T TRUST COMPLETELY. YOU ARE ADVISED, JUST IN CASE, TO ONLY RUN SCRIPTS IN A SANDBOXED VIRTUAL COMPUTER. And let me know what y'all think.
Script Syntax (Tutorial)
SCRIPT SYNTAX
So you want to write a Derp installation script? It's easier than you might think. Derp isn't too complicated-- it doesn't have a lot of "logic". It just follows a script and does what you tell it.
To start a script file, just get out any text editor (or XML editor) and name it something with the .derp file extension, such as:
sample.derp
Once you write up a sample script, you can load the file with Derp to see if it works.
The <derp> tag
Every script starts with the <derp> tag and ends with the </derp> tag. Within the "<derp>" tag, at least for this pre-alpha version, you need to put at least one required attribute, app_version:
<derp app_version="0.001">
</derp>
This is to identify the version of Derp that your script is for. Future versions may not support your script. You can put other attributes that might be used in the future:
<derp device_codename="mako" os="Linux Darwin" title="CM10.1-M1 for Mako" device_name="Nexus 4" device_vendor="lge" app_version="0.001" script_version=".5" author = "fattire" author_email="[email protected]" author_twitter="@fat__tire" license="GPLv2">
These additional tags may be required in future versions of Derp, so if you are able to supply 'em, it's recommended. They'll simply be ignored if they're not needed.
The title="CM10.1-M1 for Mako" is a general title for the script. VERY briefly explain what it does. It's not required, but recommended.
The one other important attribute, os="Linux Darwin", will be explained later. For now, just know that it is optional, but you can use it to restrict the whole script to only run only in certain operating systems.
The <section> tag
Every set of instructions should be divided into logical sections, such as the ones on the left. The section has its own required attribute, the name:
<derp app_version="0.001" os="Linux Darwin" script_version=".5">
<section name="This is the first section"></section>
</derp>
Notice the name attribute is used with a section to identify what the section is for.
There's not much more to say about sections. It's easy. Let's move on.
The <step> tag
Each Section can be made of (at least one but) an unlimited number of individual steps. And the tag for that is called <step>. Here's how it's used:
<derp app_version="0.001" script_version=".5">
<section name="This is the first section">
<step name="This is step one"></step>
<step name="This is step two"></step>
</section>
<section name="This is the second section">
<step name="This is step three"></step>
<step name="This is step four"></step>
</section>
</derp>
Notice that steps, like sections, need to have a designated name attribute so that Derp knows what to display. The step name will appear to the user at the top on the right as the centered step heading.
The <info> tag
The stuff that appears in the main info area should be wrapped in info tags.
Example:
<derp app_version="0.001" script_version=".5">
<section name="This is the first section">
<step name="This is step one">
<info>This is the text you'll see! It explains what's going on to the user. <b>I'm bolding this part because it's really important for the user to see.</b></info>
</step>
</section>
</derp>
Note: The stuff that you put between the <info> and </info> tags is...HTML!
So you can format it however you want. You can even include images from the Internet.
Here is the list of HTML tags that are recognized:
A NAME=[string]
HREF=
TARGET=[target window spec]
ADDRES... can add os="Linux Darwin" to the <derp> tag.
RESERVED
RESERVED
Derp
Derp is a pretty slick interface for scripting not only device installation, but resources needed for modifications on Android devices (namely the Android SDK). A developer can create a custom script to automate the installation, decreasing one off bad installs, and ensuring the process is completed as intended.
People new to Android customization or developers could find this of use. I am excited to see where it goes.
kornyone said:
Derp is a pretty slick interface for scripting not only device installation, but resources needed for modifications on Android devices (namely the Android SDK). A developer can create a custom script to automate the installation, decreasing one off bad installs, and ensuring the process is completed as intended.
People new to Android customization or developers could find this of use. I am excited to see where it goes.
Click to expand...
Click to collapse
Thanks.. BTW for those asking about the Windows port (in IRC)...
I simply don't have windows, but it was written to be as platform generic as possible. Anyone with a tiny amount of programming skills (again, I have zero myself) should be able to add Windows compatibility pretty quickly... I think it's a matter of just fixing that setup.py file to work with py2exe. See here for more info.
fattire said:
Thanks.. BTW for those asking about the Windows port (in IRC)...
I simply don't have windows, but it was written to be as platform generic as possible. Anyone with a tiny amount of programming skills (again, I have zero myself) should be able to add Windows compatibility pretty quickly... I think it's a matter of just fixing that setup.py file to work with py2exe. See here for more info.
Click to expand...
Click to collapse
Windows dev here, I may be able to help. Also, any interest in a Mono version? Looking for an excuse...
fattire said:
Thanks.. BTW for those asking about the Windows port (in IRC)...
I simply don't have windows, but it was written to be as platform generic as possible. Anyone with a tiny amount of programming skills (again, I have zero myself) should be able to add Windows compatibility pretty quickly... I think it's a matter of just fixing that setup.py file to work with py2exe. See here for more info.
Click to expand...
Click to collapse
Grats BTW, great idea...
I've come across several usages of Linux only Python functions so far and I don't see drop-in alternatives for Windows, so I've just commented out that particular section (line 1183). I managed to get the tool download working. Suggestion, maybe sticking with MD5 hashes would be simpler as the script receives updates to match Android SDK download updates. I can understand why you would want to use SHA512, but google offers MD5 on the site next the downloads for simple copy/paste replacement. There's the potential for lots of hard-coded configuration and for those configurations to be platform specific, such as the download folders for tool updates. I'll see if I can finish up the first bit of win compat this afternoon, but my Android device is at work and is a Dell Streak at that, so my test options are a bit limited.
http://docs.python.org/2/library/platform.html
1183 - os.geteuid()
1196 - os.uname()
fork:
https://github.com/strvmarv/derp
screen:
Windows... already?!!
Holy crap! I don't think it's been 12 hours and there's an early windows port.. amazing job!
The unix-only stuff was from a last second addition I did when I realized that dero would try to run on ARM-based linux machines. The easy fix is to simply indent everything past:
if platform.system() == "Linux"
so that the if not os.geteuid() == 0: and testarch = os.uname() stuff is conditional on it running Linux. (Unless there's a windows ARM version, in which case it also won't work).
In both cases it would work except for the fact that Google doesn't provide libraries for ARM. Interestingly though, debian does. So if we REALLY wanted, we could just apt-get install the tools for ARM Linux users. But that would (1) require a debian-based version of Linux, and (2) we wouldn't know that adb/fastboot/etc are the very latest from Google. But it might be a good version .002 feature, with a preference to turn it on or something.
Again, amazing work. Keep it up!
strvmarv said:
http://docs.python.org/2/library/platform.html
1183 - os.geteuid()
1196 - os.uname()
Click to expand...
Click to collapse
fattire said:
Holy crap! I don't think it's been 12 hours and there's an early windows port.. amazing job!
The unix-only stuff was from a last second addition I did when I realized that dero would try to run on ARM-based linux machines. The easy fix is to simply indent everything past:
if platform.system() == "Linux"
so that the if not os.geteuid() == 0: and testarch = os.uname() stuff is conditional on it running Linux. (Unless there's a windows ARM version, in which case it also won't work).
In both cases it would work except for the fact that Google doesn't provide libraries for ARM. Interestingly though, debian does. So if we REALLY wanted, we could just apt-get install the tools for ARM Linux users. But that would (1) require a debian-based version of Linux, and (2) we wouldn't know that adb/fastboot/etc are the very latest from Google. But it might be a good version .002 feature, with a preference to turn it on or something.
Again, amazing work. Keep it up!
Click to expand...
Click to collapse
Good deal, glad I could help. If you ever want to give a Mono/GTK# port a try just give me a shout. I could do the majority of the leg work code in C# very quickly, lightweight app, which is excellent these days.
I just pushed up my initial changes for the setup.py. I haven't figured it out yet, there are some imports, specifically in derp.py line 23 (platform) that aren't getting consolidated into the build with py2exe. It's most definitely how I've setup the options in the setup.py, hopefully someone is more familiar with py2exe than I and can provide some insight.
strvmarv said:
Good deal, glad I could help. If you ever want to give a Mono/GTK# port a try just give me a shout. I could do the majority of the leg work code in C# very quickly, lightweight app, which is excellent these days.
I just pushed up my initial changes for the setup.py. I haven't figured it out yet, there are some imports, specifically in derp.py line 23 (platform) that aren't getting consolidated into the build with py2exe. It's most definitely how I've setup the options in the setup.py, hopefully someone is more familiar with py2exe than I and can provide some insight.
Click to expand...
Click to collapse
Okay, let me take a second and fix the bug I described above... then-- damn, I wish I could try the setup.py myself. So you're saying that the platform stuff doesn't get imported into the build for some reason?
Standby for the fix.. just gotta test it and stuff.
Update: Pushed. Also added /build, /dist, and one other mac build-related directory to .gitignore to make things a little easier to see...
strvmarv said:
I haven't figured it out yet, there are some imports, specifically in derp.py line 23 (platform) that aren't getting consolidated into the build with py2exe. It's most definitely how I've setup the options in the setup.py, hopefully someone is more familiar with py2exe than I and can provide some insight.
Click to expand...
Click to collapse
Question, would doing something like this on line 52 do anything:
options = {'py2exe': {'bundle_files': 1, 'optimize': 2, 'compressed': 1,}},
I think you can also do something like:
includeList=["a list", "of modules", "to include"]
first, and then replace the line above with something like...
options = {'py2exe': {'bundle_files': 1, 'compressed': 1, 'optimize': 2, 'includes': includeList}},
see more info here and let me know if the above gets those modules in there! I see some option called "unbuffered".. dunno if that needs to be set to true.
bundle_files to 1 means that it hopefully will end up being a self-contained .exe
Let me know! Thanks!
Suggestion, maybe sticking with MD5 hashes would be simpler as the script receives updates to match Android SDK download updates. I can understand why you would want to use SHA512, but google offers MD5 on the site next the downloads for simple copy/paste replacement.
Click to expand...
Click to collapse
Forgot to answer this. You're totally right that MD5 is the one Google provides, and at first I used MD5 for everything-- then sluo reprimanded me, told me how MD5 can't be taken seriously any more, that it's really really easy for anyone to create a MD5 spoofed file these days... So I figured, since this runs as root, it's better to be very extra super-cautious and make absolutely sure the right file is downloaded
Of course, in a user-provided script, you can use md5s or whatever the author wants, but for the Android tools themselves I figured it was better practice to use SHA512 to be more forward/future looking and make sluo (a *real* programmer) happy
More work done by hashcode on a windows port
Okay strvmarv and other windows folk--
Hashcode helped me out by testing on his machine that has Windows.. we did a little debugging, and the result are these two commits:
Pull Request #1
He was able to run derp successfully and do adb/fastboot commands from the Console interface.
But because he's using win64, he couldn't build (apparently only win32 supports building .exe files) all the way.
So, if you have a win32 system-- after applying these, does python setup.py py2exe build an .exe?
Questions:
* on win32 does it build into an .exe?
* If so, does the .exe run properly as the administrator-- right-click and select "Run as Administrator" I am told
* if so, does it install the android tools and ask you to agree to the License?
* if so, does it download/detect your devices?
* if so, can you run scripts (does it work?)
Note: You may also need to manually install Java, since the android sdk updater uses java.
I'm wondering too if the installer installs any drivers, and/or if any were needed.
Thanks!
fattire said:
Okay, let me take a second and fix the bug I described above... then-- damn, I wish I could try the setup.py myself. So you're saying that the platform stuff doesn't get imported into the build for some reason?
Standby for the fix.. just gotta test it and stuff.
Update: Pushed. Also added /build, /dist, and one other mac build-related directory to .gitignore to make things a little easier to see...
Click to expand...
Click to collapse
Awesome, will take a look tonight. It's very likely I'm just not setting the options in the setup.py correctly.
You're running snow leopard, correct? You could grab a copy of the Windows 8.1 Preview (free until Jan something I believe - http://preview.windows.com) and dual-boot, or even just run a VM...if you wanted. I had to install Python 2.7 x86, wxPython x86, python2exe x86, and then run derp.py from source directly (powershell or cmd) to get where I'm at now.
strvmarv said:
Awesome, will take a look tonight. It's very likely I'm just not setting the options in the setup.py correctly.
You're running snow leopard, correct? You could grab a copy of the Windows 8.1 Preview (free until Jan something I believe - http://preview.windows.com) and dual-boot, or even just run a VM...if you wanted. I had to install Python 2.7 x86, wxPython x86, python2exe x86, and then run derp.py from source directly (powershell or cmd) to get where I'm at now.
Click to expand...
Click to collapse
Ideally I'd like to test it on a win32 system because that's the one that py2exe will make a .exe for. But that said, hashcode has it running and adb installs and works and such. It's now a matter of getting it packaged up properly I think. If you can double-check that it works for you, that would be a good start. Then hopefully the .exe can be made. It should also check to make sure java is installed (which is needed by the Google updater) and if not, maybe help the user do it (or even do it for them)...
Also, his version of windows already had drivers on them, so we're not sure whether derp (well, the android tools installer from Google) will take care of that or not.
One last note-- you may have had problems with the looping downloads because the sha512sum seemed to have been off. I did my own sha and it was different.. The new one worked for hashcode.. it's in his commit linked above..
Thanks!
fattire said:
Okay strvmarv and other windows folk--
Hashcode helped me out by testing on his machine that has Windows.. we did a little debugging, and the result are these two commits:
Pull Request #1
He was able to run derp successfully and do adb/fastboot commands from the Console interface.
But because he's using win64, he couldn't build (apparently only win32 supports building .exe files) all the way.
So, if you have a win32 system-- after applying these, does python setup.py py2exe build an .exe?
Questions:
* on win32 does it build into an .exe?
* If so, does the .exe run properly as the administrator-- right-click and select "Run as Administrator" I am told
* if so, does it install the android tools and ask you to agree to the License?
* if so, does it download/detect your devices?
* if so, can you run scripts (does it work?)
Note: You may also need to manually install Java, since the android sdk updater uses java.
I'm wondering too if the installer installs any drivers, and/or if any were needed.
Thanks!
Click to expand...
Click to collapse
* on win32 does it build into an .exe?
- I'm not win32, I'm running 8.1 x64, but it builds/executes just fine if you're using the 32 bit versions of Python, wxPython, and py2exe due to WOW64, long story
- It does build into an exe, see screen
Output
View attachment output.txt
Screen of dist folder
* If so, does the .exe run properly as the administrator-- right-click and select "Run as Administrator" I am told
- I'm running it with Run as Administrator, no, it still seems to blow up and stop running when it get's to __init__, it appears it can't find it for some reason when built with py2exe, likely the need for inclusion, not exactly sure yet...hard to capture error since it flashes by very quickly and then the console closes
* if so, does it install the android tools and ask you to agree to the License?
- If I run derp.py directly in Python it works just fine, android tools, etc...I haven't tried a script yet
* if so, does it download/detect your devices?
- I haven't tried a script yet
* if so, can you run scripts (does it work?)
- Ditto
Note: You may also need to manually install Java, since the android sdk updater uses java.
- Java SDK already installed, I dabble in Android
These missing modules indicated in build output worry me, not certain how to install them...
The following modules appear to be missing
['Carbon', 'Carbon.Files', 'ElementC14N', '_scproxy', '_sysconfigdata', 'win32api', 'win32con', 'win32pipe']
I've pulled a fresh copy of your repo, added Hashcodes changes, and tweaked the setup.py according to what I've found so far. Still blowing up as indicated above, but still moving in the right direction. If you want to go ahead and merge Hashcode's pull and ignore mine I'll reapply my changes so things don't get weird.
Pull request 2: https://github.com/fat-tire/derp/pull/2
I'll look over py2exe documentation and see if I can figure out what we need to change.
Ah, now we're getting somewhere, I changed console=["src/derp.py"] to windows=["src/derp.py"] as indicated here http://www.py2exe.org/index.cgi/ListOfOptions , get an error on execute, which is dumped into a text file, and looks like this...
Traceback (most recent call last):
File "derp.py", line 48, in <module>
NameError: name '__file__' is not defined
Any ideas?
scriptFolder = os.path.join(os.path.dirname(os.path.realpath(__file__)), "..", "scripts/")
UPDATE:
This may help...
http://stackoverflow.com/questions/...e-path-of-the-current-executed-file-in-python
Nice.. thanks!
strvmarv said:
* on win32 does it build into an .exe?
- I'm not win32, I'm running 8.1 x64, but it builds/executes just fine if you're using the 32 bit versions of Python, wxPython, and py2exe due to WOW64, long story
Click to expand...
Click to collapse
Ah, cool.
- It does build into an exe, see screen
Output
View attachment 2167579
Screen of dist folder
View attachment 2167586
* If so, does the .exe run properly as the administrator-- right-click and select "Run as Administrator" I am told
- I'm running it with Run as Administrator, no, it still seems to blow up and stop running when it get's to __init__, it appears it can't find it for some reason when built with py2exe, likely the need for inclusion, not exactly sure yet...hard to capture error since it flashes by very quickly and then the console closes
Click to expand...
Click to collapse
The file size looks tiny... it looks like it doesn't build into it all the stuff it needs...
* if so, does it install the android tools and ask you to agree to the License?
- If I run derp.py directly in Python it works just fine, android tools, etc...I haven't tried a script yet
Click to expand...
Click to collapse
^ This is awesome and a good sign for this working once we get the build finished.
* if so, does it download/detect your devices?
- I haven't tried a script yet
* if so, can you run scripts (does it work?)
- Ditto
Click to expand...
Click to collapse
Now that I think about it-- the "welcome" stuff and auto-download of the tools are all a running .derp script (welcome.derp) so yes, you are running them
These missing modules indicated in build output worry me, not certain how to install them...
The following modules appear to be missing
['Carbon', 'Carbon.Files', 'ElementC14N', '_scproxy', '_sysconfigdata', 'win32api', 'win32con', 'win32pipe']
Click to expand...
Click to collapse
Hmm.. Did you try adding them explicitly in the optionList as I suggested above?
And another way to do it is to use the -p and -i paremeters when you do python setup.py py2exe
Also maybe try adding:
import win32com
after "import py2exe" in setup.py I saw some reference to that somewhere...
What else...
looks like elementc14n is something related to the elementree module of python... win32api is here I think... but I think it would be installed when you installed python to begin with.
I've pulled a fresh copy of your repo, added Hashcodes changes, and tweaked the setup.py according to what I've found so far. Still blowing up as indicated above, but still moving in the right direction. If you want to go ahead and merge Hashcode's pull and ignore mine I'll reapply my changes so things don't get weird.
Pull request 2: https://github.com/fat-tire/derp/pull/2
I'll look over py2exe documentation and see if I can figure out what we need to change.
Click to expand...
Click to collapse
I'm looking too... See this?
For py2exe to work with packages loaded during runtime, the main thing seems to be that u explicitly import the modules needed by your app somewhere in your app. And then give py2exe in setup.py with moudlefinder.AddPackagePath( , ) the hint, where to search for modules it couldn't find by std. introspection. in the app
I won't do a full-on pull to the repo until everything is working and tested against linux/mac just to make sure we're only fixing stuff and not breaking the other platforms in the process
strvmarv said:
Ah, now we're getting somewhere..
UPDATE:
This may help...
http://stackoverflow.com/questions/...e-path-of-the-current-executed-file-in-python
Click to expand...
Click to collapse
Ah yes-- does this help as recommended in the link above..?
http://www.py2exe.org/index.cgi/WhereAmI
fattire said:
Ah yes-- does this help as recommended in the link above..?
http://www.py2exe.org/index.cgi/WhereAmI
Click to expand...
Click to collapse
jpath wouldn't pull in for some reason, despite installing via pip and having an import, so I resorted to logic to assign "." as the path (very hacky)...
So, here it is...running from derp.exe compiled with py2exe...when I get a moment I'll put together a quick summary of how to get a local win environment going..
Here's another pull:
https://github.com/fat-tire/derp/pull/3
UPDATE:
Ack, storing sdk tools in Program Files\Common Files is great and everything, but it needs to be store in Program Files (x86)\Common Files since it's x86 compiled. Pretty sure things may go wrong at some point as it is...
I've been trying different ways of entering bios and/or disabling secure boot, but can't figure out exactly if it has a BIOS menu at all.
Connected a keyboard to it and tries different keys during boot but I can't find the right combination.
Does anyone know how to enter the BIOS menu, or how do we go about disabling secure boot?
Thank you,
cocacola2015 said:
I've been trying different ways of entering bios and/or disabling secure boot, but can't figure out exactly if it has a BIOS menu at all.
Connected a keyboard to it and tries different keys during boot but I can't find the right combination.
Does anyone know how to enter the BIOS menu, or how do we go about disabling secure boot?
Thank you,
Click to expand...
Click to collapse
Keyboard is disabled(no driver installed, thanks Lenovo). Bios is usless.
From my LG-G4, Rooted running Stock 5.1
I was afraid that this would be the case. There seems to be no way to circumvent it either to boot a linux kernel.
http ://i.imgur.com/Tfd9U3i.jpg
Am I right to assume that the only thing we have that are signed are the stock Lenovo Yoga kernels, making them the only thing we can boot?
Also, does anyone know if these are the Microsoft keys, or some Lenovo keys, that they use for secure-boot. http ://i.imgur.com/dm1i16B.jpg
I'm wondering, because linux grub distributions do have a signed grub "shim" with the Microsoft key, maybe making us able to execute that at boot.
Ok, I've found out that it does have the microsoft keys, among other keys, which means it should in theory be possible, in theory. Will be looking into this more.
cocacola2015 said:
I was afraid that this would be the case. There seems to be no way to circumvent it either to boot a linux kernel.
http ://i.imgur.com/Tfd9U3i.jpg
Am I right to assume that the only thing we have that are signed are the stock Lenovo Yoga kernels, making them the only thing we can boot?
Also, does anyone know if these are the Microsoft keys, or some Lenovo keys, that they use for secure-boot. http ://i.imgur.com/dm1i16B.jpg
I'm wondering, because linux grub distributions do have a signed grub "shim" with the Microsoft key, maybe making us able to execute that at boot.
Click to expand...
Click to collapse
actually the problem is not in the unlocking but in making a working kernel for this tablet... because you see... Lenovo released the "source code" so they won't risk being sued for breaking the opensource (kernel) licenses, yet what they released is crap, broken drivers (i had to download all the source packages from all the YT2 models because they didn't even un-tarred crap and each one was 400MB and move things around and still it wont do the job as it should) they intentionally crippled the mk files, removed others, stupid and not working configs and so on... driver files missing... you get the picture and this was intentionally (not to say that this is only the kernel, not a chance to see in their source whats even more interesting: the code for the libraries, binaries etc) i am not saying it cannot be done but the amount of work it requires... hmm does it justify? in the end there are few people on this tablets and even lesser with the knowledge/available time to try and do something that will look like a custom rom
i thought at some point in making a rom but the hassle and time required don't justify it (what would i have? except that it's trendy to have a costom rom) so i for one will stay on my Android+Linux combo but who want to go further has my help
a better approach would be to build a custom rom based on the stock kernel/initramfs, this way you will start having the drivers in order and do your custom system (while no longer used in these days still it was cyanogenmod's way of making custom roms in the past) yet this one too is difficult and requires lots of work (and again for what? what's the gain?) but this one is much more acceptable than the rebuilding all previous one
the secure boot is passed (pm and you will understand) but to what end? see... the problem isn't so much in opening the door but in what you will do once inside (and i am inside that room for some time now yet no better bed than my Linux+Android combo) but feel free to continue on the road..
this is not to discourage you but to warn you about issues others (me) had on the road you're stepping now.
Thank you for the reply.
You're right, going the route of compiling whatever Lenovo has put out, is not the most streight forward option, but I disagree on not putting Linux on this tablet. This is the biggest and highest resolution tablet I've seen, and having Android on it instead of a full-blown Linux distribution, is a waste. Things like X forwarding to use it as a thin clinet, does not work well, I've tried all options. The only viable thing for using this as a thin client, is to run Linux on it, with its native input methods on the display server.
The gain is not having to pay twice as much for a Microsoft Surface tablet to install linux on, with it even being lower resolution and smaller screen.
well in this area @workdowg can give you more details as he is the one who loves X on this tab me i'm more like an Y type (aka windows gui/y) (i am happy with my openvpn and sshd) but again consider the unlocking part done and start collecting stuff for making your kernel
ionioni said:
well in this area @workdowg can give you more details as he is the one who loves X on this tab me i'm more like an Y type (aka windows gui/y) (i am happy with my openvpn and sshd) but again consider the unlocking part done and start collecting stuff for making your kernel
Click to expand...
Click to collapse
Very exciting. Need to boot a compatible kernel with the provided drivers, as you also suggested, and eventually get a full fedora distribution up and running.
Since this is an x86 tablet, no cross-compilation will be needed so it will allow for more flexibility with getting tools into initramfs to make it bootstrap systemd, and eventually run a full distribution from the system partition.
Would be very interested if workdowg can also provide some input on the issue.
cocacola2015 said:
Thank you for the reply.
You're right, going the route of compiling whatever Lenovo has put out, is not the most streight forward option, but I disagree on not putting Linux on this tablet. This is the biggest and highest resolution tablet I've seen, and having Android on it instead of a full-blown Linux distribution, is a waste. Things like X forwarding to use it as a thin clinet, does not work well, I've tried all options. The only viable thing for using this as a thin client, is to run Linux on it, with its native input methods on the display server.
The gain is not having to pay twice as much for a Microsoft Surface tablet to install linux on, with it even being lower resolution and smaller screen.
Click to expand...
Click to collapse
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
cocacola2015 said:
Very exciting. Need to boot a compatible kernel with the provided drivers, as you also suggested, and eventually get a full fedora distribution up and running.
Since this is an x86 tablet, no cross-compilation will be needed so it will allow for more flexibility with getting tools into initramfs to make it bootstrap systemd, and eventually run a full distribution from the system partition.
Would be very interested if workdowg can also provide some input on the issue.
Click to expand...
Click to collapse
ionioni said:
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the (huge)work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
Click to expand...
Click to collapse
I purchased my tablet with intention of dual booting Linux and Android and eventually going with Linux alone (being x86 I thought this would be a piece of cake). Now after getting Linux running (with Android in a chroot).... My vision has changed. TTY Linux is great, I have so much I can get done when not home. Using Xsdl, X runs well enough ( I had wine installed to run a Windows app) and I don't think it would be all that much better on the framebuffer.
The problem ends up being.... (and it has been stated before).... Touch still sucks on a small screen! Android just excels at it. So for me, if someone were to develop kexecboot or such I would definitely play with it (proof of concept) but I'm positive I'd go right back to my current setup.... ssh and the Xsdl for X as needed are perfect.
ionioni said:
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
Click to expand...
Click to collapse
Oh I see. The highest priority for me at least, is to get any linux distribution to boot.
workdowg said:
I purchased my tablet with intention of dual booting Linux and Android and eventually going with Linux alone (being x86 I thought this would be a piece of cake). Now after getting Linux running (with Android in a chroot).... My vision has changed. TTY Linux is great, I have so much I can get done when not home. Using Xsdl, X runs well enough ( I had wine installed to run a Windows app) and I don't think it would be all that much better on the framebuffer.
The problem ends up being.... (and it has been stated before).... Touch still sucks on a small screen! Android just excels at it. So for me, if someone were to develop kexecboot or such I would definitely play with it (proof of concept) but I'm positive I'd go right back to my current setup.... ssh and the Xsdl for X as needed are perfect.
Click to expand...
Click to collapse
Touch will probably work better on the larger screens, I've got the 13inch one.
---------------
So I got the latest kernel from kernel.org to boot but I'm not sure why it doesn't find the initramfs, I assume it has to do with it not existing on a partition, but being built into the boot.img.
http://i.imgur.com/IxdwXre.jpg
I'm trying to make it boot a live OS directly from USB, without initramfs. It's a bit difficult because I don't know how the block devices are named, maybe if anyone knows the kernel command line for booting the live linux using the custom kernel, using sdhci or normal usb.
Basically, instead of the normal LiveUSB sequence:
grub from USB -> kernel from USB -> root filesystem from USB
I want
custom kernel with android boot.img -> root file system from USB/SD card
cocacola2015 said:
I want
custom kernel with android boot.img -> root file system from USB/SD card
Click to expand...
Click to collapse
there's something wrong with your boot.img, and from the image there not enogh info
link the boot.img you make
ionioni said:
there's something wrong with your boot.img, and from the image there not enogh info
link the boot.img you make
Click to expand...
Click to collapse
What's wrong is you need the root= kernel argument, and I'm not sure how the block devices are named (For example, it doesn't have /dev/block/ like on the android kernels). The initramfs isn't modified yet, it's a custom compiled kernel with the source at kernel.org.
Created a boot.img that one can add root= kernel arguments to, to test booting from other media:
https://anonfiles.com/file/177753c2344c3c64c200cdb3803236bd
It has these kernel command line arguments built into the kernel:
Code:
oops=panic panic=360 vmalloc=172M debug_locks=0 bootboost=1 vga=ask i915.modeset=0 drm.vblankoffdelay=1 selinux=0 nomodeset ro debug noinitrd
Another one with UHCI (USB2.0) driver, instead of xHCI (USB3.0), because it might not reach init sometimes otherwise when plugged in, for some reason.
https://anonfiles.com/file/d41f495d118ab1e5ccef961baeb1bcce
No command line arguments built into the kernel, all in boot.img, boot_delay= disabled
Code:
oops=panic panic=360 vmalloc=172M debug_locks=0 bootboost=1 vga=ask i915.modeset=0 drm.vblankoffdelay=1 selinux=0 nomodeset ro debug noinitrd root=/dev/mmcblk0