Create an SD card installable version

GoogleCodeExporter commented 9 years ago

It would be useful to have a version of android-on-freerunner that installs 
completely on the SD card, without modifying NAND flash in the phone. This 
would be a script that (optionally) partitions the SD card and copies the 
proper images to the various places. It also probably requires changes to 
init.rc to mount the SD card partitions.

Original issue reported on code.google.com by scarhill on 20 Sep 2009 at 1:32

GoogleCodeExporter commented 9 years ago

you can try this:
the system.img is a jffs2 file, mount that file somewhere and copy it to sd.
try booting it from sd, but I don't know if it works...

Greeting Serdar

Original comment by seder...@googlemail.com on 20 Sep 2009 at 6:21

GoogleCodeExporter commented 9 years ago

I have done that with panickings images time to time before, last time I tested 
it
required some changes to init.rc. This should be possible to fix again but I 
don't
think it will be enough just to take the system and move to the sdcard. Amongst 
other
it won't be able to find the root system.

Original comment by larlin...@gmail.com on 20 Sep 2009 at 6:34

GoogleCodeExporter commented 9 years ago

Until SD release creating may be somebody give some idea how to move existing 
to SD?
Please

Original comment by Alexandr...@gmail.com on 3 Oct 2009 at 5:56

GoogleCodeExporter commented 9 years ago

To make it run from sd direct you need to unpack the file system in system.img,
rename and move the kernel.img to /boot. Then you need to make some changes in
init.rc I don't know exactly what changes but you should be able to look at the 
init
scripts that panicking got in his download area for some hints. Those init 
scripts
may or may not work with the current build as I'm not sure how much of that 
part is
different.

Original comment by larlin...@gmail.com on 3 Oct 2009 at 6:19

GoogleCodeExporter commented 9 years ago

system.img is only a /system dir , but where I able get / part with init.rc. I 
have
play with panicking and sd-version of panicking work for me well. But I could 
not
find the root part for current system.

Original comment by Alexandr...@gmail.com on 3 Oct 2009 at 10:19

GoogleCodeExporter commented 9 years ago

Humm that's odd the files that is taken from the out folder of the android 
build is
kernel.img, userdata.img, ramdisk.img and system.img. So the rootfs must really 
be in
one of those if not the rest of the fs is buildt at first boot in some way.

When flashing directly to ram on the moko I flash the system.img as the rootfs.

Original comment by larlin...@gmail.com on 3 Oct 2009 at 1:04

GoogleCodeExporter commented 9 years ago

I have found where root part is, do looks this:
gzip -dc /tmp/tmp/ramdisk.img | cpio --extract --make-directories
init.rc should be created now

Original comment by Alexandr...@gmail.com on 3 Oct 2009 at 2:41

GoogleCodeExporter commented 9 years ago

My attempt to create SD-based version have success with old ( for example
uImage-v24.bin from panicing ) , but could not work with currect kernel.img. It 
looks
that currect kernel could not work with root on ext2. Could somebody give a 
comment
about?
If somebody interested I could share the version with old kernel.

Original comment by Alexandr...@gmail.com on 10 Oct 2009 at 4:35

GoogleCodeExporter commented 9 years ago

You have to put the root on an ext3 FS, tried it yet?
I don't know if the issue is there or not...
If you manage to do it, tell us! ;)

Original comment by xelasreb...@gmail.com on 16 Oct 2009 at 5:42

GoogleCodeExporter commented 9 years ago

The problem not in ext2 or ext3, problem is in kernel.img, which is different 
from
uImage.bin from previose releases. It looks, that it has some init included, 
which
could work only in NAND. At moment I am tring to make own build to understend 
the
difference. If somebody could explain the difference between kernel.img and
uImage.bin now, I will be glad to hear.

Original comment by Alexandr...@gmail.com on 16 Oct 2009 at 6:24

GoogleCodeExporter commented 9 years ago

The difference between uImage.bin from previose releases and kernel.img is in
included in kernel.img initial ram filesystem/ram disk. So kernel.img does not 
work
with ext3 partition at SD, but only with this included fs. The init, which 
ordinary
start with ram disk and that remount ( or chroot ) to base rootfs does not do 
it as
well.  So no way to create SD-base version without work with source.  There are 
some
way to do this and many problem concerned: simplest way to supply, 
safety/stability
to work and so.
It is subject of special discussion.  
Here is my suggestion how to solve issue:
Include to supply additionl uImage ( uImageSD.bin in attachment1 have build from
current source tree ), which have not include ram disk opposite kernel.img. 
Difference in 4-line of file kernel/arch/arm/configs/
CONFIG_BLK_DEV_INITRD=N
#CONFIG_INITRAMFS_SOURCE="###ROOT_DIR###"
#CONFIG_INITRAMFS_ROOT_UID=###ROOT_UID###
#CONFIG_INITRAMFS_ROOT_GID=###ROOT_GID###
( Looks that Michael do same, but I could not check - do not know the way to 
his git )
The supply of this file is a main topic.
This will be enough to build SD-based version from supply by standart procedure:
http://wiki.openmoko.org/wiki/Android_on_Freerunner.
The logs is in attachment2.
I want to put result for current stable ( -rw-r--r-- 1 root root 32669879 
2009-10-24
11:21 android-on-freerunner-cupcake-0.1.1-sd.tar.gz) in attachment as well, but 
the
limit 10M not allow to do this. It should be restored to partition 2 of 
standart (
fat/sd ) prepared SD for freerunner with qi bootloader. Show the way to put it, 
if
somebody interested in.
Ready to discuss any question concerned

Original comment by Alexandr...@gmail.com on 24 Oct 2009 at 7:33

Attachments:

GoogleCodeExporter commented 9 years ago

To avoid any mistake I put current SD-based version to RapidShare:
http://rapidshare.com/files/311138980/android-on-freerunner-cupcake-week-2009-48
-SD.tar.gz.html

The file should be restored to partition 2 of standart (fat/sd ) prepared SD for
freerunner with qi bootloader.

Original comment by Alexandr...@gmail.com on 23 Nov 2009 at 5:09

GoogleCodeExporter commented 9 years ago

I'm running android from SD since some few days (using the uImage you 
provided), but
I've noticed that it really hangs a lot, and first of all when using new 
installed
applications (Market or other Google apps in primis). It seems that things are 
going
better if the sdcard usage is disabled.

My configuration is: android installed in an ext2 partition and configured to 
use
another (big, about 4Gb) ext2 partion as sdcard which contains some data and 
some
dirs "blacklisted" using a ".nomedia" file (if I don't do that, the MediaScanner
slows down a lot the phone).

I've not tested yet if the nand installation works better.

Original comment by trevi55 on 24 Nov 2009 at 2:38

GoogleCodeExporter commented 9 years ago


> I'm running android from SD since some few days (using the uImage you 
provided), but
> I've noticed that it really hangs a lot, and first of all when using new 
installed
> applications (Market or other Google apps in primis). It seems that things 
are going
> better if the sdcard usage is disabled.
1) about uImage - it is actual now, but you should take in mind that it should 
be
build from actual repo of kernel ( no changes in kernel since 12.10 now )
2) please, send me an example of application, which hang ( I have not access to
Market !? )
3) from my expirience, typical problem, which produce same errors, is incorrect
rights of file in /system. Please, try 
http://rapidshare.com/files/311138980/android-on-freerunner-cupcake-week-2009-48
-SD.tar.gz.html

> My configuration is: android installed in an ext2 partition and configured to 
use
> another (big, about 4Gb) ext2 partion as sdcard which contains some data and 
some
> dirs "blacklisted" using a ".nomedia" file (if I don't do that, the 
MediaScanner
> slows down a lot the phone).
I have not tested "ext2 partion as sdcard", typical is fat/ext2 scheme. So you 
are
ahead in this way.

> I've not tested yet if the nand installation works better.
I do not find any difference yet between SD or NAND based installation, at 
least at
daily use. However I have read at some reports and I think myself, that 
NAND-based
should work a bit faster than SD-based. But this "bit" may be noticed only by 
special
testing.

Original comment by Alexandr...@gmail.com on 24 Nov 2009 at 6:48

GoogleCodeExporter commented 9 years ago

Alexandre,
Thanks for your work on this! I'm trying to reproduce it, so that I can add an 
option
to the build to build a tarball for SSD installation. I followed your 
directions and
was able to successfully boot from SD, but I was seeing crashes and exception 
in the
log that seemed to be caused by permission problems. I plan to do some more 
work this
evening, but I was interested in whether you have to do anything to get the 
proper
ownership/permissions on the SD file system.
Jim

Original comment by scarhill on 24 Nov 2009 at 8:34

GoogleCodeExporter commented 9 years ago

Alexandre:
1) I've been using using your old image, but using the latest one is the same 
(also 
because there are no recent changes in git...)
2) There's no an application that hangs... Any application can hang in some 
particular situations that I neither can understand since the logcat doesn't 
say 
anything about that (the market generally works, at the beginning crashed 
mostly due 
to configuration issues). Sometimes the interface continues to be animated but 
the 
phone doesn't respond to events and in few seconds also the gui freezes at 
all...
3) All my /system file have right righs, I've tried also with a chmod 777 
/system -R.

About the usage of an ext2 partition, I think that this shouldn't be a 
problem... 
It's a kernel work, and linux has no problems with all those filesystems... 
However I 
could try with a vfat too...

Yes I figure too that the NAND version should be faster, also because the 
interface 
(glamo) bus is shared with the SD card, but also in SD it works well from the 
interface speed point of view.

Original comment by trevi55 on 25 Nov 2009 at 4:59

GoogleCodeExporter commented 9 years ago

Hello,

> I plan to do some more work this
> evening, but I was interested in whether you have to do anything to get the 
proper
> ownership/permissions on the SD file system.
Here is not clear for me am moment. As I understend, we lose permission on a 
way:
create image, Mntjffs.sh, cp -R . So right way is to exclude this steps and 
create
tarball directly - I am looking at this possibility now, if you will do this, 
it will
be great. 
However this way require a lot work with source. I would like to find simple 
way to
get SD-based system, without work with source, becouse in this case a lot of 
problems
should be discussed: simplest way to supply, safety/stability
to work and so.
For now I do: chmod -R 777 /system , which is not correct, but usefull. At  
least for
my daily used system.

Original comment by Alexandr...@gmail.com on 25 Nov 2009 at 7:04

GoogleCodeExporter commented 9 years ago

Question for guru!!!!!

Today I have investigate a problem with file permissions. It is very surpise 
for me that:
1) After build a fresh subj from current repository we have a normal set of 
file/dir
permissions ( 755 or 644 .. ) in system directory.
2) After installation current ( NAND ) build we have only 777 for all file/dir 
3) For Michael build we have same.
             So, chmod -R 777 /system is same

Summary:  Our build do not covered by file permission at all.

May be I miss something, but I am surprised.   Could somebody give any 
explanation?

Original comment by Alexandr...@gmail.com on 26 Nov 2009 at 6:10

GoogleCodeExporter commented 9 years ago

Just an example of what happens when the phone freezes:

W/ActivityManager(  869): Timeout of broadcast BroadcastRecord{438e7398
android.intent.action.TIME_TICK} -
receiver=android.app.ActivityThread$PackageInfo$ReceiverDispatcher$InnerReceiver
@436adb30
W/ActivityManager(  869): Receiver during timeout: BroadcastFilter{437274a8
ReceiverList{43729750 869 system/1000 client 436adb30}}
W/WindowManager(  869): Key dispatching timed out sending to
com.android.setupwizard/com.android.setupwizard.SyncIntroActivity
W/WindowManager(  869): Dispatch state: {{KeyEvent{action=1 code=4 repeat=0 
meta=0
scancode=169 mFlags=8} to Window{436ba950
com.android.setupwizard/com.android.setupwizard.LoginActivity paused=false} @
1259420045099 lw=Window{436ba950
com.android.setupwizard/com.android.setupwizard.LoginActivity paused=false}
lb=android.os.BinderProxy@43850b48 fin=false gfw=true ed=true tts=0 wf=false 
fp=false
mcf=Window{4361b4c8 
com.android.setupwizard/com.android.setupwizard.SyncIntroActivity
paused=false}}}
W/WindowManager(  869): Current state:  {{null to Window{4361b4c8
com.android.setupwizard/com.android.setupwizard.SyncIntroActivity paused=false} 
@
1259420178783 lw=Window{4361b4c8
com.android.setupwizard/com.android.setupwizard.SyncIntroActivity paused=false}
lb=android.os.BinderProxy@438f0760 fin=false gfw=true ed=true tts=0 wf=false 
fp=false
mcf=Window{4361b4c8 
com.android.setupwizard/com.android.setupwizard.SyncIntroActivity
paused=false}}}
I/ActivityManager(  869): ANR (application not responding) in process:
com.android.setupwizard
I/ActivityManager(  869): Annotation: keyDispatchingTimedOut
I/ActivityManager(  869): CPU usage:
I/ActivityManager(  869): Load: 8.6 / 3.39 / 1.67
I/ActivityManager(  869): CPU usage from 9177ms to 36ms ago:
I/ActivityManager(  869):   system_server: 0% = 0% user + 0% kernel
I/ActivityManager(  869):   com.levelup.beautifulwidgets: 0% = 0% user + 0% 
kernel
I/ActivityManager(  869):   adbd: 0% = 0% user + 0% kernel
I/ActivityManager(  869):   logcat: 0% = 0% user + 0% kernel
I/ActivityManager(  869): TOTAL: 100% = 0% user + 0% kernel + 98% iowait
I/Process (  869): Sending signal. PID: 869 SIG: 3
I/dalvikvm(  869): threadid=7: reacting to signal 3

As you can see: cpu at 100% due to 98% of iowait... Mhmh

Original comment by trevi55 on 28 Nov 2009 at 3:02

GoogleCodeExporter commented 9 years ago

Are you sure that it is SD-based subj problem?
I have seen a lot of same logs in google search. Please, describe a picture in 
more
detail?

Original comment by Alexandr...@gmail.com on 28 Nov 2009 at 4:47

GoogleCodeExporter commented 9 years ago

Well, right now I've just tried to run Android on SD (I'd prefer not to delete 
my
NAND partition where I've my daily distro), but it seems that NAND users people
aren't affected by this. And I also think that it's mostly a kernel related 
issue
(looking at this)... Some old posts [1] confirms this behavior in certain 
situations,
so I figure there's something wrong here.

By the way, there's nothing to describe exactly: randomly when I'm doing some
operations on screen (like browsing, syncing contacts, twitting, writing in 
forms...
Or also just after that the android launcher screen has booted) suddenly the 
phone
hangs and rests freezed until I remove the battery :(.

A "fun" thing is that the phone really doesn't freezed, it should be alive 
since if
it hangs when I'm writing in a form, for example, the cursor continue blinking 
also
if everything else is completely unresponsive (a similar issue running a game, 
it
continued animating also if slowly, but it was not controllable)... :o

[1] 
http://www.mail-archive.com/android-freerunner@android.koolu.org/msg00547.html

Original comment by trevi55 on 28 Nov 2009 at 7:28

GoogleCodeExporter commented 9 years ago

I can confirm that I see lockups when running from SD but from NAND. It seems 
that ADB 
doesn't work when it locks up, so I haven't yet gotten a stack trace to compare 
with 
the one posted above.

Original comment by scarhill on 28 Nov 2009 at 9:44

GoogleCodeExporter commented 9 years ago

No it doesn't... It's very rare that you can get some informations; I figure 
that
with a debug bouard watching the kernel someone could understand something more.

By the way, have you tried running it on NAND? Is it better (your "but from 
NAND"
isn't enough clear to me :P)?

Original comment by trevi55 on 29 Nov 2009 at 12:38

GoogleCodeExporter commented 9 years ago

Oops, left out a "not". I don't see the lockups when running from NAND.

Original comment by scarhill on 29 Nov 2009 at 1:24

GoogleCodeExporter commented 9 years ago

I can not reproduce "lockup" at my Om. It looks that lockup problem depends of 
SD
model and more exectly of its write speed. Please, look
http://wiki.openmoko.org/wiki/Supported_microSD_cards.
So I would like to split this issue to 2 problems:
1) Possibility to create SD-based subj, which looks solved now ( exept 777 
permissions ) 
and
2) Problematic SD&kernel settings issue, which is critical in case SD-based 
subj, in
case only data on SD and so.

Original comment by Alexandr...@gmail.com on 1 Dec 2009 at 1:14

GoogleCodeExporter commented 9 years ago

Well, this is very strange since I've been running in the very same µSD other 
distros 
(SHR, Qtopia, Qtmoko...) for weeks with no lockups, nor using particular kernel 
boot 
options.

Maybe we/I could try some different configurations for this: any advices?

By the way, the freeze issue rarely happens in a fresh installation with few 
applications installed; When installing more extra applications (and when they 
start 
at boot, first of all) it starts to happen on regular basis (also disabling the 
/sdcard pointing to a different mmc partition), but it's hard to say when.
However this makes me think that it seems to be real that the phone hangs when 
it has 
to perform many read/writes in the SD (and while it does, android doesn't seem 
able 
to wait).

Original comment by trevi55 on 1 Dec 2009 at 7:44

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

FYI, today I switched the SD boot partition from ext2 to ext3, well... Lockups 
continues (again with blinking cursor or battery icon working, but completely 
unresponsive and "offline" for adb) :(

Original comment by trevi55 on 2 Dec 2009 at 5:40

GoogleCodeExporter commented 9 years ago

Well, I think I was partly wrong in my latest message. Today I've fixed a 
little the 
permissions and the database files in my /data partition (which during the ext2 
usage 
were often corrupted by forced reboots) and I noticed really a GREAT stability 
improvement.

So, maybe it's a kernel driver related issue, I don't know, but the ext2 (that 
I chosen not to stress my card) doesn't seem to perform as expected here.
This seems to be also the cause of the lockups I noticed sometimes when 
accessing to 
the /sdcard (which still uses an ext2 partition).

Talking about file systems... Few weeks ago phoronix posted a review/benchmark 
[1] 
where it was underlined that the ext4 file system was the best choice for usb 
flash 
devices; I don't know if this can be applied to a µSD card, but if it can, I 
figure 
that we could move to this FS to get better performances.
I've not tested this yet, since months ago the ext4 fs was disabled in OM 
kernels (I 
don't know / remember / find out why, but if I recall correctly this was done 
to 
avoid the kernel to use it by default [also for ext3 partitions] causing kernel 
crashes), so it should be re-enabled in the gta02-defconfig and tested.

[1] http://www.phoronix.com/scan.php?page=article&item=linux_usb_fs&num=4

Original comment by trevi55 on 2 Dec 2009 at 7:42

GoogleCodeExporter commented 9 years ago

Well, I think I was partly wrong in my latest message. Today I've fixed a 
little the 
permissions and the database files in my /data partition (which during the ext2 
usage 
were often corrupted by forced reboots) and I noticed really a GREAT stability 
improvement.

So, maybe it's a kernel driver related issue, I don't know, but the ext2 (that 
I chosen not to stress my card) doesn't seem to perform as expected here.
This seems to be also the cause of the lockups I noticed sometimes when 
accessing to 
the /sdcard (which still uses an ext2 partition).

Talking about file systems... Few weeks ago phoronix posted a review/benchmark 
[1] 
where it was underlined that the ext4 file system was the best choice for usb 
flash 
devices; I don't know if this can be applied to a µSD card, but if it can, I 
figure 
that we could move to this FS to get better performances.
I've not tested this yet, since months ago the ext4 fs was disabled in OM 
kernels (I 
don't know / remember / find out why, but if I recall correctly this was done 
to 
avoid the kernel to use it by default [also for ext3 partitions] causing kernel 
crashes), so it should be re-enabled in the gta02-defconfig and tested.

[1] http://www.phoronix.com/scan.php?page=article&item=linux_usb_fs&num=4

Original comment by trevi55 on 2 Dec 2009 at 7:46

GoogleCodeExporter commented 9 years ago

Maybe I'm going OT, but since the lockups seems to happen mostly when running 
on SD, 
I'll continue to talk about them here mostly than opening a new issue, sorry...

However I've found something [1] in the official android ML which maybe is 
related to 
this, the effect are the same I have and there they seem to related to the 
number of 
the threads active; who knows... Maybe if they stress the card, then the CPU 
can't 
continue collecting the data at all, uhmhmhmh...

[1] http://groups.google.com/group/android-
developers/browse_thread/thread/d24f1a223f197c3/0f74d6a6dd98ca72

Original comment by trevi55 on 2 Dec 2009 at 10:17

GoogleCodeExporter commented 9 years ago

adding labels

Original comment by larlin...@gmail.com on 16 Jan 2010 at 9:58

Added labels: AndroidVersion-Cupcake, BuildVersion-Weekly, Component-Installer, Priority-Low
Removed labels: Priority-Medium

GoogleCodeExporter commented 9 years ago

Hello

In case that we have a problem with installer I suggest to supply SD based 
version of
subj prepared by manual procedure (
http://wiki.openmoko.org/wiki/Android_on_Freerunner). Find in attachment kernel
image, which is possible to use for creation SDversion of subj ( uImageSD.bin 
have
build from
current source tree, which have not include ram disk opposite normal 
kernel.img). 
 Here is a result:
http://rapidshare.com/files/343719214/android-on-freerunner-cupcake-0.2.0-RC1-SD
.tar.gz.html
 I suggest to put it in download area.
 The subj should be extracted to second ( ext ) partition of
standart ( fat/ext ) prepared SD. It is better to have fat
part empty ( at least first time ). I suppose the qi was
installed, so no other step no need.
Only prepare SD and boot by pressing power button and
wait...
No changes in NAND will be done, subj is working only with
SD.
Good luck!!

Original comment by Alexandr...@gmail.com on 31 Jan 2010 at 7:16

Attachments:

uImageSD.bin

GoogleCodeExporter commented 9 years ago

Great work, it run very well!
Anyway: is it possible to allow ssh access like in the other distros avoiding 
the use
of adb (I'm on freebsd 6.3 which does not support it).
Thank you very much!

Original comment by gia.gio...@gmail.com on 17 Feb 2010 at 4:57

GoogleCodeExporter commented 9 years ago

Any place where this SD image can still be downloaded? The above link does not 
work
anymore :(

Original comment by christia...@gmail.com on 30 Mar 2010 at 4:59

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

Thanks for this but unfortunately this is the NAND installer version and not 
the SD
version I was looking for.

I tried to create an SD version from 
android-on-freerunner-cupcake-0.2.0-RC1.tar.gz
already with instructions from here:
http://wiki.openmoko.org/wiki/Android_on_Freerunner#Installing_Android_on_an_SD_
card
but I get an error message that it cannot find installation files. I do not 
want to
install but run it from SD...

What I did:
extracted /boot ramdisk and jffs2 image contents to a temp dir and modified 
init.rc
to not mount /system /data and /cache

Original comment by christia...@gmail.com on 31 Mar 2010 at 5:26

GoogleCodeExporter commented 9 years ago

Sorry. I put wrong cupcake image, but master is SD-based.
Wait a bit, I will put a correct cupcake link.

Original comment by Alexandr...@gmail.com on 31 Mar 2010 at 5:41

GoogleCodeExporter commented 9 years ago

Try this link:
http://rapidshare.com/files/349016080/cupcakefull.tar.gz

Original comment by Alexandr...@gmail.com on 31 Mar 2010 at 5:47

GoogleCodeExporter commented 9 years ago

Thanks, this one works :)
Can you post instructions how to create this?
My result looked similar but I have not found a clue yet why yours continued 
booting
though ;-)

Original comment by christia...@gmail.com on 31 Mar 2010 at 6:37

GoogleCodeExporter commented 9 years ago

In view of a lot of request and to avoid any problem I repeat creation of 
SD-based
version of android-on-freerunner-cupcake-0.2.0-RC1 and repeat asking to put it 
to
download area. ( I have not any host for that propose)
The way how to create this image and use it was described at comment 11,18 and 
33.
The result you able to find at:
http://rapidshare.com/files/371177250/android-on-freerunner-cupcake-0.2.0-RC1-SD
.tar.gz.html
( it is same as was at comment 33 )

Original comment by Alexandr...@gmail.com on 2 Apr 2010 at 3:18

GoogleCodeExporter commented 9 years ago

The file has been removed from rapidshare. Could you please upload it once 
more? Somebody to put it in download area? Temporary I can put it on my 
server...

Original comment by martinse...@gmail.com on 21 Jun 2010 at 10:35

GoogleCodeExporter commented 9 years ago

http://www.raskon.org/pub/android-on-freerunner-cupcake-0.2.0-RC1-SD.tar.gz

Original comment by bkocherov@gmail.com on 22 Jun 2010 at 12:36

GoogleCodeExporter commented 9 years ago

Find it here:
http://rapidshare.com/files/401650878/android-on-freerunner-cupcake-0.2.0-RC1-SD
.tar.gz.html

Original comment by Alexandr...@gmail.com on 22 Jun 2010 at 12:47

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

[deleted comment]

GoogleCodeExporter commented 9 years ago

Alexandre, could you put together a script that performs the steps neccessary 
to build the SD distribution archive?
Assume that you're starting with a regular build environment and the standard 
build has just been run. I assume you'd need to rebuild the kernel with a 
different .config, copy in a modified init.rc and do a few other things, then 
build an archive from the trees under out/target/product/freerunner/. If you 
can write a script that does that, we can integrate it into the build and 
produce SD and NAND installable versions routinely.

Original comment by scarhill on 20 Aug 2010 at 1:32

GoogleCodeExporter commented 9 years ago

I also would really vote for such a script as I only have it running from SD, 
but would like to be able to build a newer version.

Original comment by christia...@gmail.com on 20 Aug 2010 at 2:23

GoogleCodeExporter commented 9 years ago

Hello
I have publish a way to create SD-based version some time. For example, here: 
http://groups.google.com/group/android-on-freerunner/browse_thread/thread/d1c9dd
db19a39a62/ef433e9f6329c136?lnk=gst&q=mksdimage#ef433e9f6329c136
Here is a double:
  1) Main problem for SD version is a special kernel build - see comment
11 of issue7.
    Kernel should be build from repository. Daily build has not this
special build.
    You have to create this special kernel build yourself!!!!
    In case that kernel change some rarely the version from comment 33
of issue7
    is possible use up to now (but not all time!!!)
2) The way to create SD version build from current daily build with
special kernal
    is decribed at  http://wiki.openmoko.org/wiki/Android_on_Freerunner
and has been
    discussed at issue7.  I have try to create a small command script
to help you.
    May be it give you some idea.:

#!/bin/bash
#
# script to prepare SD-base tar.gz-image from ordinary tar.gz
# image ( arg1 ) using special prepared kernel image ( arg2 )
#
# This script may be distributed, altered, reverse-engineered,
# rebranded or thrown across the room at leisure, as long as
# nobody blames me for it.
#
case "$1" in

--help|-h)
         echo Usage: mksdimage \<tar.gz-image\> \<kernel-image\>
         echo
         echo Script will exit with a return code of 0 in case of success,
         echo return code of 1 indicates UID not 0, return code of 2
         echo indicates sanity check failed, return code of 3 finally
indicates
         echo something went wrong during the mount procedure
         ;;

*)

if [ `id -u` -ne 0 ]; then
  echo "This script needs to be run as root"
  exit 1
fi

# Temporary directories structure
suffix=`mcookie`
temp_dir=/tmp/${suffix:1:5}
mnt_dir=$temp_dir/${suffix:6:5}
new_dir=$temp_dir/${suffix:11:5}
new_name=`basename $1 | sed -e "s/\(.*\).tar.gz/\1-SD/"`
dir_name=`dirname $1`

SANITY_CHECK=0
if [ $(file -b $1 |cut -d ' ' -f1) = "gzip" ] && [ $(file -b $2 |cut -
d ' ' -f1) = "u-boot" ]; then
  SANITY_CHECK=1
  echo Sanity check passed...
fi

#   Mounting and copying
#   probe all the mods, set up the loops, mount the mtds.
#   check first if we are root, if we are not, the probing
#   might be a wee difficult
#
if [ $SANITY_CHECK -eq 1 ]; then
        mkdir $temp_dir
        cd $temp_dir
        gzip -dc $1 | tar xf -
        mkdir $mnt_dir
        export loop=$(losetup -f) && \
        losetup $loop system.img && \
        modprobe block2mtd block2mtd=$loop,131072 && \
        sleep 2 && \
        modprobe jffs2 && \
        sleep 2 && \
        modprobe mtdblock && \
        sleep 2 && \
        mount -t jffs2 -o ro /dev/mtdblock0 $mnt_dir && \
        ( echo -n "Image ";echo -n system.img;echo -n " sucessfully mounted
on ";echo $mnt_dir ) || \
        ( echo mount failed, check dmesg \|tail for pointers ; rm -rf
$temp_dir ; exit 3)
        mkdir $new_dir
        cd $new_dir
        gzip -dc $temp_dir/ramdisk.img | cpio --extract --make-directories
        cp -R $mnt_dir/* system/
        cp init sbin/
        mkdir boot
        cp $2 boot/uImage-GTA02.bin
        sed -i -e"/ mount /s/ mount /# mount /
18i     mount rootfs rootfs / rw remount" init.rc
        chmod -R 777 *
        tar cf $dir_name/$new_name.tar .
        gzip $dir_name/$new_name.tar
        umount $mnt_dir
        rm -rf $temp_dir
        exit 0
else
        echo SANITY CHECK FAILED!
        echo
        echo Something\'s not right here, chummer.
        echo Make sure you have a valid tar.gz image AND a valid kernel
image.
        echo And remember: Think before you type, or bad things may happen --
all sanity
        echo checking of this world will not save your butt if you act
foolishly
        echo
        echo Usage: mksdimage \<tar.gz-image\> \<kernel-image\>
        exit 2
fi
;;

esac

This script is good enouhg for cupcake. For ecliar and for froyo  simple sed 
editions:        sed -i -e"/ mount /s/ mount /# mount /
18i     mount rootfs rootfs / rw remount" init.rc
is not enough, more critical analyse of mount statments should be done. Do not 
forget that special kernel.img should be build

Original comment by Alexandr...@gmail.com on 20 Aug 2010 at 3:53

ghbolivar / android-on-freerunner

Create an SD card installable version #7