This is still a work in progress but the Nook Simple Touch can now boot from the sd card. If you would like to learn how view klausef's comments in post number 27 (http://forum.xda-developers.com/showpost.php?p=25325319&postcount=27).
I will continue to update this post when there is new information
Thanks to klausef for working on this and creating a solution to my question.
Thanks to all of those that contribute to nookdevs and thanks to everyone else that has commented on this topic.
I wonder what would happen if I were to write a backup of the Nook onto an SD card and put it in (with the Nook itself wiped so it can't boot from the internal flash)
Nothing, because the mountpoints are wrong.
It should be possible, but I never tried it:
-partition and format the sd in a similiar way like the nook,
-unpack the uRamdisk and edit the mountpoints in the init.rc from mmcblk0 to mmcblk1
Again, I'm not sure if it works, thats what I read somewhere. And even if it works, it will be slow if you don't use a really fast sd-card.
mali100 said:
Nothing, because the mountpoints are wrong.
It should be possible, but I never tried it:
-partition and format the sd in a similiar way like the nook,
-unpack the uRamdisk and edit the mountpoints in the init.rc from mmcblk0 to mmcblk1
Again, I'm not sure if it works, thats what I read somewhere. And even if it works, it will be slow if you don't use a really fast sd-card.
Click to expand...
Click to collapse
Onwards to experimentation!!!!
mali100 said:
And even if it works, it will be slow if you don't use a really fast sd-card.
Click to expand...
Click to collapse
He meant not SD class (sequential I/O speed), but random (SD brand mostly)
Explained here: http://forum.xda-developers.com/showthread.php?t=1102704
So it is possible thats good news. Do we know of any body thats working on it? or can someone instruct me on how to edit the files that need to be edit?
ApokrifX said:
He meant not SD class (sequential I/O speed), but random (SD brand mostly)
Explained here: http://forum.xda-developers.com/showthread.php?t=1102704
Click to expand...
Click to collapse
Yes, I know that. I wasn't planning on using this for day-to-day use, just testing to see if it would boot.
Googie2149 said:
Yes, I know that. I wasn't planning on using this for day-to-day use, just testing to see if it would boot.
Click to expand...
Click to collapse
Have you got anything to boot off the sd card?
probbiethe1 said:
Have you got anything to boot off the sd card?
Click to expand...
Click to collapse
Haven't tried yet, been busy with a school project. I finish it tomorrow, so I'll try then. Maybe. Probably.
Cool good luck with your school project
Forgive me if this explanation goes through too basic of things for you but I am trying to establish context. Basically here's the status:
When you hit the power button on the nook touch, it calls some bootloader software called UBoot, that's kind of like a BIOS for embedded systems. UBoot looks for a file called UImage and a file called URamdisk. These two files contain the kernel and the root filesystem (and maybe a few other things, I've not taken the time to learn too much about UBoot). When UBoot finds these files, it loads them to RAM and starts executing the kernel.
Now the first thing the kernel is going to do when it starts up is to run the program 'init.' Init performs all the necessary stuff to start the system as you know it. Part of what init does is run a script called 'init.rc.' This script does a lot of things, but an important part of what it does is mount all these partitions.
So all we have to do to run the device off an SD card is to get UBoot to use the UImage and URamdisk from the SD card instead of internal memory! It turns out that this has actually been done before. This method is exactly what touchNooter did to root our nooks. Of course, it was created with other things in mind.
What I did was burn an exact copy of the nook's internal memory to an SD card, but then took the files from the touchNooter image that make UBoot work, and copied them over to the boot partition of the SD card. I'm not sure that you have to copy all the files I did, but anyway here's the ones I took from touchNooter:
u-boot.bin
cfg.bin
boot.scr (This is essentially a UBoot script that tells it what to do with UImage and URamdisk to set up the rootfs and start the Kernel)
I also made all of the boot images black so I would be able to tell if the nook was using the SD card.
When I stuck the SD card in and rebooted, lo and behold, the screen went black all the way through the boot process. It worked! The only issue is, it turns out that init and init.rc are somehow loaded into the UImage or URamdisk, so when init runs, it still mounts the partitions that are on the nook's internal storage. From this, we can deduce that the only thing running from the SD card is the kernel, and everything else is as before.
The solution to this is to recompile the UImage and URamdisk using B&N's provided source with an edited init.rc to mount the SD card's partitions. Another way we could do it is to somehow edit 'boot.scr' to make UBoot to pass an argument to the kernel when it gets started to use a different, modified init. (Much like pushing `esc` on a linux bootscreen and typing init=<binary>)
The first solution is harder but more correct, while the second solution is easier but much more hackish.
I am somewhat new to UBoot so I would appreciate it if someone else could correct any inaccuracies I may have made.
klausef said:
The solution to this is to recompile the UImage and URamdisk using B&N's provided source with an edited init.rc to mount the SD card's partitions.
Click to expand...
Click to collapse
You can easily unpack/edit/pack URamdisk
mali100 explained everything and posted scripts here. I’m reposting his scripts below:
Unpack (xuramdisk)
Code:
#!/bin/bash
#if (test $# -eq 1 && -f $1)
if [ -f $1 ]; then
dd if=$1 bs=64 skip=1 of=rdisk.gz
# Uncompress
gunzip rdisk.gz
# Extract
mkdir ramdisk
cd ramdisk
cpio -iv < ../rdisk
else
echo "No Ramdisk found"
fi
pack (mkuramdisk)
Code:
#!/bin/bash
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
klausef said:
-snip-
Click to expand...
Click to collapse
That's great! Even as you have it right now, this could be a great way to test new kernels!
Googie2149 said:
klausef said:
-snip-
Click to expand...
Click to collapse
That's great! Even as you have it right now, this could be a great way to test new kernels!
Click to expand...
Click to collapse
If nook doesn’t boot, but respond to shutdown button still,
you can replace uImage or uRamdisk on nook internal SD by booting from noogie (well known fact)
or removing external SD card.
Otherwise (nook doesn't respond to shutdown button - semi-bricks)
you need to open it and disconnect battery or wait till it got discharged completely
And you may need to pop nook open to start it charging again in some cases
Either way, I don’t see how booting from external SD card helping much with kernel testing.
Am I missing something obvious?
I use my Nook to read textbooks for all my classes so I cannot afford to experiment through the internal memory.
At any rate, digging around the forum it turns out that people have known this for a while (OP even mentioned it in the first post), so I apologize for the bulk of that post.
I tried editing the init.rc to mount the SD card's partitions (replaced all /dev/block/mmcblk0 with /dev/block/mmcblk1) and it seems to just hang. ( I made sure to wait a long time to make sure it wasn't just lagging from the speed of the card reader, although I may not have waited long enough... )
This lead me to believe that the card reader is not initialized yet. To test this hypothesis I edited init.rc back to something that worked, but this time added `ls /dev/block/ > /data/blocks` right after the data partition is mounted, to find out all the block devices the Nook sees at this point. Unfortunately, after the system starts up I found no file named 'blocks' in /data/blocks.
EDIT: Found the culprit! After boot, I looked at dmesg:
Code:
init: /init.rc: 19: invalid command 'ls'
So we can't use `ls` for this. No problemo, I'll just pack busybox into the uRamdisk and use `ls` from there.
klausef said:
I use my Nook to read textbooks for all my classes so I cannot afford to experiment through the internal memory.
At any rate, digging around the forum it turns out that people have known this for a while (OP even mentioned it in the first post), so I apologize for the bulk of that post.
I tried editing the init.rc to mount the SD card's partitions (replaced all /dev/block/mmcblk0 with /dev/block/mmcblk1) and it seems to just hang. ( I made sure to wait a long time to make sure it wasn't just lagging from the speed of the card reader, although I may not have waited long enough... )
This lead me to believe that the card reader is not initialized yet. To test this hypothesis I edited init.rc back to something that worked, but this time added `ls /dev/block/ > /data/blocks` right after the data partition is mounted, to find out all the block devices the Nook sees at this point. Unfortunately, after the system starts up I found no file named 'blocks' in /data/blocks.
EDIT: Found the culprit! After boot, I looked at dmesg:
Code:
init: /init.rc: 19: invalid command 'ls'
So we can't use `ls` for this. No problemo, I'll just pack busybox into the uRamdisk and use `ls` from there.
Click to expand...
Click to collapse
Wow sounds like your really making progress. Let me know if there is anything I can do to help.
klausef said:
So we can't use `ls` for this. No problemo, I'll just pack busybox into the uRamdisk and use `ls` from there.
Click to expand...
Click to collapse
Would it be easier to use cat? (this is not a snarky remark)
Wow sounds like your really making progress. Let me know if there is anything I can do to help.
Click to expand...
Click to collapse
Haha thank you but nah, most of the stuff that I have done is known. I'm mostly just trying to replicate and document what has been done as precisely as possible.
Would it be easier to use cat? (this is not a snarky remark)
Click to expand...
Click to collapse
I am not sure cat would work in this case since we are trying to get a directory listing of the directory /dev/block/, not concatenate or list two files.
Anyhow, it turns out that 'init.rc' is not a bash script, but instead uses the syntax described here: http://www.kandroid.org/online-pdk/guide/bring_up.html (See 'Android Init Language' section)
klausef said:
Anyhow, it turns out that 'init.rc' is not a bash script, but instead uses the syntax described here: http://www.kandroid.org/online-pdk/guide/bring_up.html (See 'Android Init Language' section)
Click to expand...
Click to collapse
Thats correct, but you can call your own bash script from it. Take a look on how clrbootcount.sh is called in the init.rc
Per the documentation I have invoked a script through init.rc. The script is very simple. I included a busybox binary in the uRamdisk at /busybox, so that's what it's based on:
Code:
#/busybox ash
/busybox ls /dev/block/ > /data/blocks;
I have verified that the script works by first running it on an up-and-running nook and it worked properly. (That is, it created a populated file in /data/blocks and then terminated)
The script is called through the init.rc right after it finishes mounting all the partitions:
Code:
service lsdev /lsdev.sh
oneshot
When I start up the nook with this init.rc it hangs on boot. I also tried calling the script using `exec` instead of `service` but it still hangs.
In other news, I noticed dmesg finds mmcblk1 (the SD card) around the same time it finds the internal memory. See this dmesg snippet:
Code:
<6>[ 22.080810] twl4030_rtc twl4030_rtc: setting system clock to 2012-04-15 00:48:42 UTC (1334450922)
<6>[ 22.090759] mmc0: new high speed MMC card at address 0001
<6>[ 22.096801] Freeing init memory: 164K
<6>[ 22.106384] mmcblk0: mmc0:0001 SEM02G 1.82 GiB
<6>[ 22.111450] mmcblk0: p1 p2 p3 p4 < p5 p6 p7 p8 >
<4>[ 22.238494] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
<4>[ 22.321990] mmc1: host does not support reading read-only switch. assuming write-enable.
<6>[ 22.330841] mmc1: new high speed SDHC card at address 1234
[B]<6>[ 22.337280] mmcblk1: mmc1:1234 SA04G 3.67 GiB [/B]
<6>[ 22.342651] mmcblk1: p1 p2 p3 p4 < p5 p6 p7 p8 >
The Nook is failing to boot for some other reason than because it doesn't see the SD card. I previously assumed the opposite, which is why I've been going through this big init.rc exercise to verify it. (I was expecting not to see a /dev/mmcblk1p*)
It is my assumption that this has something to do with how the stock userland is set up, so I'm going to call it a day, then shift my focus to compiling a new kernel and userland instead of just aimlessly trying to get this one to run off the SD card.
Please don't let that doesn't discourage any of you from further contributing to this thread's original goal, because it would still be immensely useful to the development process.
Good day, all. Thanks for the help.
Related
I've made a script that relocates all your apps into an EXT2 filesystem in /sdcard/andboot/apps.img.
Advantages
- Get a LOT of space for apps even if everything else is running in NAND
- Never need to reinstall apps when upgrading (as long as the release has this script)
- Dual boot, for example, Eclair in NAND, Froyo on SD-card, but share the same apps.
- Wipe data (all settings) but keep all the apps stays (but not their settings)
Disadvantages
- Propably a bit slower than keeping everything in NAND
- If you intend to keep apps when when upgradring/switching releases then odex:ing your Market apps is not a good idea when using this.
Attached is an update that should work on any Android build (for our devices). The script in the update is only used once to create /sdcard/andboot/apps.img. Once it exist, the init script in the new initrd.gz (included in the attached NBH for NAND users) will automaticly mount /sdcard/andboot/apps.img to /data/app on boot no matter what Android build you are using.
Instructions
1a. Flash the attached kernel (but configure it first if needed with Loserskaters NBH editor) (NAND Users)
1b. Replace andboot\initrd.gz (HaRET users)
2. Apply attached update (adds relocate_apps.sh to /system/bin)
3. Do this in a terminal:
$su
#relocate_apps.sh 256 (for 256Mb storage, the choice is yours)
<wait until it finishes>
That's it. Upon the next boot your old apps in /data/app will be deleted to free up space.
To uninstall, delete the apps.img file on the SD-card, then wipe your data.
I've done some testing and it seems to work fine. I'm currently dual booting VaniljEclair (NAND) and Fresh Froyo (SD-card instal) and they share the same apps. Works fine for me but I cannot guarantee that it is without bugs.
Known limitations
- Won't work with apps that installs to /data/app-private (like some banking apps) so you have to reinstall them if you switch build or wipe your data.
- You can't remove the SD-card without powering off the phone since your apps are now stored on it.
kallt_kaffe said:
I've made a script that relocates all your apps into EXT2 filesystem in /sdcard/andboot/apps.img.
Advantages
- Get a LOT of space for apps even if everything else is running in NAND
- Never need to reinstall apps when upgrading (as long as the release has this script)
- Dual boot, for example, Eclair in NAND, Froyo on SD-card, but share the same apps.
- Wipe data (all settings) but keep all the apps stays (but not their settings)
Disadvantages
- Propably a bit slower than keeping everything in NAND
- If you intend to keep apps when when upgradring/switching releases then odex:ing your Market apps is not a good idea when using this.
Attached is an update for VaniljEclair RLS10b but it could tweaked into any release if you know what you are doing ("/system/bin/relocate_apps.sh boot" needs to be executed early, could be done either in a userinit.sh if the build has one or set up as a run-once service in sysinit.rc)
Instructions
$su
#relocate_apps.sh 256 (for 256Mb storage, the choice is yours)
<wait until it finishes>
That's it. The final version will delete your old apps on the next reboot to free up space in /data but this experimental version does not do that.
THIS IS AN EXPERIMENTAL SCRIPT. USE IT AT YOUR OWN RISK.
Click to expand...
Click to collapse
Interesting....so to get it work on fresh froyo I need to add this line /system/bin/relocate_apps.sh boot into userinit.sh?
Also when could we expect the version that deletes apps from system after moving them to sd?
-Arturo- said:
Interesting....so to get it work on fresh froyo I need to add this line /system/bin/relocate_apps.sh boot into userinit.sh?
Click to expand...
Click to collapse
Not anymore, the new version has that part in the initrd.gz so it will work in ANY build without modifications once you've relocated your apps.
Also when could we expect the version that deletes apps from system after moving them to sd?
Click to expand...
Click to collapse
Right now.
If this works as well as it seems to do I will push my changes to the bootenv and tinboot repo's so that all new kernels will have support for this. I will also include the relocate_apps.sh script in next VaniljEclair release and push it to Fresh Froyo.
While I have never needed more space on /data I still find this very useful as I now only need to reinstall one single app (my banking app) when I reinstall my phone (which I do quite often).
btw, I'm using a 512Mb image for /data/apps right now I don't think I will ever come close to fill it up.
kaffe, can we put apps (only apps, data still on NAND) on a second ext2 partition instead ext2 filesystem? I think it will be faster.
kallt_kaffe said:
Not anymore, the new version has that part in the initrd.gz so it will work in ANY build without modifications once you've relocated your apps.
Click to expand...
Click to collapse
Just a quick question, i know i could just try it and find out for myself but with the new kernel, does it mount /data/app normally if the apps.img does not exist??
EDIT::
Just realised that it must do this for it to work the first time but i'm guessing at the minute there is no way to revert back to apps on the /data partition without wiping and starting a fresh.
Hi..thanks for the app.
I follow direction unitl the app.img was mounted and saw the msg saying /data will be deleted after reboot, but after reboot the internal memory is still the same. Any idea?
ps. I am running your 2.1 built (on polaris) so I didn't follow your step1, so maybe that is why it didn't work?
Cookiekaikai said:
Hi..thanks for the app.
I follow direction unitl the app.img was mounted and saw the msg saying /data will be deleted after reboot, but after reboot the internal memory is still the same. Any idea?
ps. I am running your 2.1 built (on polaris) so I didn't follow your step1, so maybe that is why it didn't work?
Click to expand...
Click to collapse
Are you saying you didn't flash the kernel provided?? If so the apps.img on the sdcard will not be mounted. You need to modify the kernel NBH with the NBH editor to work with Polaris, flash it and try again. Sorry if i misunderstood and you have already done this.
Can the kernel file you attached be used for vogue at 320x240 res?
edit: actually, if it's not too much trouble...could you explain how to get this working on a vogue froyo nand 320x240? Thanks!
kallt_kaffe said:
Not anymore, the new version has that part in the initrd.gz so it will work in ANY build without modifications once you've relocated your apps.
Right now.
If this works as well as it seems to do I will push my changes to the bootenv and tinboot repo's so that all new kernels will have support for this. I will also include the relocate_apps.sh script in next VaniljEclair release and push it to Fresh Froyo.
While I have never needed more space on /data I still find this very useful as I now only need to reinstall one single app (my banking app) when I reinstall my phone (which I do quite often).
btw, I'm using a 512Mb image for /data/apps right now I don't think I will ever come close to fill it up.
Click to expand...
Click to collapse
Ok seems to be working fine for me with 512 image. Will report back in a few days.
scooter1556 said:
Are you saying you didn't flash the kernel provided?? If so the apps.img on the sdcard will not be mounted. You need to modify the kernel NBH with the NBH editor to work with Polaris, flash it and try again. Sorry if i misunderstood and you have already done this.
Click to expand...
Click to collapse
I didn't flash the kernel because the file name says FROYO but I am running eclair. However I am pretty sure the file was created and mounted as well.
I do know how to use NBH editor but just want to be sure that the kernel is safe even if I am running eclair.
Thanks for the reply
UPDATE: never mind I forgot you can select eclair as type. I will report back once I am done with the rest of the steps. THX!
Cookiekaikai said:
I didn't flash the kernel because the file name says FROYO but I am running eclair. However I am pretty sure the file was created and mounted as well.
I do know how to use NBH editor but just want to be sure that the kernel is safe even if I am running eclair.
Thanks for the reply
Click to expand...
Click to collapse
Yes it's safe.i think Kalt has made all the required changes to make kernel work on both froyo and eclair.
Kalt I'm wondering about something.I've already created the image for apps but I'm not sure what's going to happen when I instal new applications.will they automatically be moved to the image or do I have to run the script after ever installation off apk file?
tuannam said:
kaffe, can we put apps (only apps, data still on NAND) on a second ext2 partition instead ext2 filesystem? I think it will be faster.
Click to expand...
Click to collapse
It would propably be a little bit faster but it will be a lot more complicated to make and perhaps even more complicated to use. We allready have a de facto standard with this partitioning:
part 1 - FAT32
part 2 - system
part 3 - data
part 4 - swap
Now, not many uses swap on SD-card so we could propably say partition 4 should be used for this, right? But then we also would need to now that partition 4 really is ext2 and is having apps on it before we mount it. And it is also quite complicated for most people to partition their SD-cards in the first place.
So basicly, what I'm saying is that it propably could make small difference in performance but I'm not convinced it would be worth it. The way it works now is pretty safe as it won't do anything unless /sdcard/andboot/apps.img exist and setting it up is a simple one-liner in the terminal.
On the other hand an advanced user could set up their own apps on ext2-partition manually and add some lines to userinit.sh that mounts it.
So I don't know, at least I don't have any plans to add it at the moment. Perhaps someone could add it later if the advantages turns out to be big enough to make it worth it.
EDIT: Another aspect is that /data/app is only written to when installing, all other accesses should be only reads. All writing to /data is still in NAND so I really think the performance penalty is minimal. I haven't been able to tell the difference myself.
scooter1556 said:
Just a quick question, i know i could just try it and find out for myself but with the new kernel, does it mount /data/app normally if the apps.img does not exist??
EDIT::
Just realised that it must do this for it to work the first time but i'm guessing at the minute there is no way to revert back to apps on the /data partition without wiping and starting a fresh.
Click to expand...
Click to collapse
Your logic is correct.
Cookiekaikai said:
UPDATE: never mind I forgot you can select eclair as type. I will report back once I am done with the rest of the steps. THX!
Click to expand...
Click to collapse
If you are using the latest VaniljEclair then use a Froyo kernel. With the latest version of the libcamera.so the Froyo kernel can and should be used to get the extra 11Mb of memory.
-Arturo- said:
Yes it's safe.i think Kalt has made all the required changes to make kernel work on both froyo and eclair.
Kalt I'm wondering about something.I've already created the image for apps but I'm not sure what's going to happen when I instal new applications.will they automatically be moved to the image or do I have to run the script after ever installation off apk file?
Click to expand...
Click to collapse
As long as you have the new kernel and have run the script once then everything you install will end up i apps.img.
I must be doing something wrong. I flashed the new kernel, performed the update then ran the script(saw the /data/app copied screen and was told after reboot it would take effect, but internal memory is still going down after reboot).
UPDATE: after doing some PD I found the app.img disappeared from andboot. Not sure what is going on but i am recreating another one now.
Played around with this, and I think it's working on my vogue... ~60mb free on phone. Performance isn't too bad. Thanks!
kallt_kaffe said:
As long as you have the new kernel and have run the script once then everything you install will end up i apps.img.
Click to expand...
Click to collapse
Kalt I have a feeling that the script messes up compcache(it could also be the new cell location patch) My sd card is not recognized after restart of the system with compcache enabled. I remember that we had already suffered with this problem and you fixed it by adding 120 s delay to the script. I've notice that with apk image the system takes a bit more time to boot and load widgets in comparison to apks on nand. Could that be the problem? I would like to increase the delay in compcache script to maybe 180 seconds or so to see if it fixes the issue.
What should i change in this script to change the delay time?
Does this 2>&1 stands for 120 seconds?
Code:
#!/system/bin/sh
#
# Compcache manager
#
#
# Change these variables to tweak the compcache
#
opts= # Use default (25% of the avaliable RAM (~23-24Mb))
#opts='disksize_kb=16384' # 16Mb compcache
#opts='disksize_kb=32768' # 32Mb compcache
#opts='backing_swap=/dev/block/mmcblk0p4' # compcache (default size 15% of available RAM) + backing swap (on SD card)
#opts='backing_swap=/dev/block/mmcblk0p4 memlimit_kb=32768' # 32Mb compcache + backing swap (on SD card)
# Swappiness
swappy=30
case "$1" in
start)
sleep 120
insmod /system/lib/modules/lzo_compress.ko >/dev/null 2>&1
insmod /system/lib/modules/lzo_decompress.ko >/dev/null 2>&1
insmod /system/lib/modules/xvmalloc.ko >/dev/null 2>&1
insmod /system/lib/modules/ramzswap.ko $opts >/dev/null 2>&1
swapon /dev/block/ramzswap0
sysctl -w vm.swappiness=$swappy
;;
stop)
swapoff /dev/block/ramzswap0
;;
enable)
setprop persist.service.compcache 1
echo "Compcache will be enabled in 120 seconds."
;;
disable)
setprop persist.service.compcache 0
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
Thanks
-Arturo- said:
Kalt I have a feeling that the script messes up compcache(it could also be the new cell location patch) My sd card is not recognized after restart of the system with compcache enabled. I remember that we had already suffered with this problem and you fixed it by adding 120 s delay to the script. I've notice that with apk image the system takes a bit more time to boot and load widgets in comparison to apks on nand. Could that be the problem? I would like to increase the delay in compcache script to maybe 180 seconds or so to see if it fixes the issue.
What should i change in this script to change the delay time?
Does this 2>&1 stands for 120 seconds?
Code:
#!/system/bin/sh
#
# Compcache manager
#
#
# Change these variables to tweak the compcache
#
opts= # Use default (25% of the avaliable RAM (~23-24Mb))
#opts='disksize_kb=16384' # 16Mb compcache
#opts='disksize_kb=32768' # 32Mb compcache
#opts='backing_swap=/dev/block/mmcblk0p4' # compcache (default size 15% of available RAM) + backing swap (on SD card)
#opts='backing_swap=/dev/block/mmcblk0p4 memlimit_kb=32768' # 32Mb compcache + backing swap (on SD card)
# Swappiness
swappy=30
case "$1" in
start)
sleep 120
insmod /system/lib/modules/lzo_compress.ko >/dev/null 2>&1
insmod /system/lib/modules/lzo_decompress.ko >/dev/null 2>&1
insmod /system/lib/modules/xvmalloc.ko >/dev/null 2>&1
insmod /system/lib/modules/ramzswap.ko $opts >/dev/null 2>&1
swapon /dev/block/ramzswap0
sysctl -w vm.swappiness=$swappy
;;
stop)
swapoff /dev/block/ramzswap0
;;
enable)
setprop persist.service.compcache 1
echo "Compcache will be enabled in 120 seconds."
;;
disable)
setprop persist.service.compcache 0
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
Thanks
Click to expand...
Click to collapse
How about the line "sleep 120".
I've experienced some strange things with this so far. I installed a new app this morning. Some hours later I got a freeze and pin-reset my phone. The new app was gone... The .apk is no longer in apps.img, not even in lost+found. The system however believes it is still installed and I cannot reinstall it.
I have now added the "sync" flag when mounting the sdcard in /init and I'll give it another try. With a little luck it might prevent it from happening again.
I attached the new NBH and initrd.gz here if anyone else experienced the same problem and want to give it another try.
**** EXT4 for DATA (SD) install on second post *****
I've been slowly working on our Kaiser Kernel hoping to get extra life from it. Here are the changes I made so far.
1. Updated to the latest initrd and made a few changed in the init file
2. Changed the default I/O scheduler to noop.
3. Added block data integrity support and v4 support
4. Updated the latest yaffs2 filesupport up to changes dated 1/14/2011
5. Added PM module for Qualcomm 7500 chip
Will try to add BFQ I/O scheduler and see how the performance is compared to noop.
1/29/11 ** UPDATED KERNEL for better YAFFS2 best suited for Kaiser Samsung Memory chip **
Here is the nbh. This is type2 screen and keyboard1.
Will release my latest changes and update to git (need help on this one) when stable.
Please reinstall ROM and wipe data after flashing the kernel. The changes in yaffs2 code might cause issues. You can restore your data from BACKUP after installing the ROM.
************ TO FORCE CHECKPOINT IN DATA PARTITION PLEASE DO THIS IN TERMINAL *******************
su
echo 6 > /sys/module/yaffs/parameters/yaffs_auto_checkpoint
sync
This will change auto checkpointing to 2 and create a checkpoint.
This is just temporary, the checkpoint is deleted in reboot so the commands have to be done before every reboot.
One solution is to use Gscript.apk and type the commands in Gscripts. Execute via Gscript before reboot
**** To verify if you have checkpoint in Data Partition Please do in Terminal ******
To verify if you have yaffs2 checkpoint in the data partition Type the following in terminal
su
cat /proc/yaffs
Scroll down to Device 2 "userdata"
scroll down and look for "blocks_in_checkpt" should be 1 or 2 (not 0, if it is zero then you have no checkpoint in data partition)
Update 2/7/2011
******************EXT4 FILESYSTEM FOR SD INSTALL***************
Because of bad blocks on my Kaiser, I have to give all NAND partition to install on system while installing data on SD with EXT4 filesystem. Here are the requirements:
1. An SD card with at least class 4
2. A way to partition and format your SD with FAT/ext2/Ext4 (ext2 should be as small as possible), I use Ubuntu for this.
3. Kernel with ext4 support (this will format your whole NAND partition to use system and use EXT4 on SD for Data)
Instructions:
1. FORMAT SD (I use Ubuntu DiskUtil) with FAT/ext2/EXT4, on my 8GB SD I use 7gb for FAT/8mb for ext2/1gb for EXT4 but it's your call. The most important part is that you only give the second partition (ext2) the least amount of size.
2. Download the KAISIMG.zip, extract and you will get a file KAISIMG.NBH
3. use Atools to edit accordingly with your Kaiser's screen type and keyboard (NBH is using screen 2 and keyboard 1)
4. Flash the KAISIMG.NBH
HERE IS WHERE IT GETS TRICKY!!! PLEASE FOLLOW THESE INSTRUCTIONS CAREFULLY!!!!
a. PRESS CENTER D PAD to enter ANDROID Installer
b. Choose (*) Sys on NAND
Choose (*) Data on SDCard Partition
c. Scroll Down to Install System and choose it
d. This will wipe your Existing system! Are you sure CHOOSE (YES)
e. Would you like to clear data too (Suggested) CHOOSE (NO) ***DO NOT CLEAR DATA OR THIS WILL CHANGE YOUR THIRD PARTITION TO EXT2 and will not work.
That's it. After installation reboot and you have an optimized ext4 on your SD for data. The mount options for ext4 in this kernel are:
data=writeback, barrier=0, nobh, noauto_da_alloc
Will use barrier=1 for better data security on next release, just enjoying the speed of barrier=0 for now
clemsyn said:
Will try to update our 2.6.25 kernel too if I get some space for my hard drive.
Click to expand...
Click to collapse
Yes, Clemsyn If it's not a big problem please update 2.6.25 too. Thank you.
updates kernel 2.6.25
clemsyn said:
Will try to update our 2.6.25 kernel too if I get some space for my hard drive.
Click to expand...
Click to collapse
This would be nice. Thank you
mt1976 said:
This would be nice. Thank you
Click to expand...
Click to collapse
It would take awhile though since I have to remove my 2.6.32 kernel to put 2.6.25 since I'm limited in space. Donations for a laptop HD would be appreciated
UPDATE:
1. I think one of the reasons of data failure is that YAFFS refuses to write a checkpoint for our data partition. It writes it in the system partition with no issues. The new yaffs2 (updated 1-27-11 which I will update shortly) allows forcing checkpoint so I'll try that one and see if I can create a checkpoint on our data partition.
Finally got a checkpoint in my userdata partition...instructions posted on first post, no update on yaffs needed
clemsyn said:
It would take awhile though since I have to remove my 2.6.32 kernel to put 2.6.25 since I'm limited in space. Donations for a laptop HD would be appreciated
UPDATE:
1. I think one of the reasons of data failure is that YAFFS refuses to write a checkpoint for our data partition. It writes it in the system partition with no issues. The new yaffs2 (updated 1-27-11 which I will update shortly) allows forcing checkpoint so I'll try that one and see if I can create a checkpoint on our data partition.
Click to expand...
Click to collapse
I have a 20 GB Sata laptop drive I could get to you. Used to be in a 360 and then broke the enclosure open for a hdd when the one in my laptop died. Drive works just fine, just small lol
aceoyame said:
I have a 20 GB Sata laptop drive I could get to you. Used to be in a 360 and then broke the enclosure open for a hdd when the one in my laptop died. Drive works just fine, just small lol
Click to expand...
Click to collapse
Sorry about your phone. I was hoping you could test out my new kernel. ANyways, I think yaffs2 was having issues creating a checkpoint on the data partition since yaffs was only creating a checkpoint on proper unmount (which was not done in our kaiser). The latest yaffs can make us force a checkpoint by simply typing the command in the first post and typing "Sync" on terminal automatically creates a checkpoint in data partition. I'm currently testing it now and seeing how it goes.
BTW, I'll take that donation re:HD since I can use it as an external HD and put the 2.6.25 kernel there and improve it (that is if wife permits).
clemsyn said:
Sorry about your phone. I was hoping you could test out my new kernel. ANyways, I think yaffs2 was having issues creating a checkpoint on the data partition since yaffs was only creating a checkpoint on proper unmount (which was not done in our kaiser). The latest yaffs can make us force a checkpoint by simply typing the command in the first post and typing "Sync" on terminal automatically creates a checkpoint in data partition. I'm currently testing it now and seeing how it goes.
BTW, I'll take that donation re:HD since I can use it as an external HD and put the 2.6.25 kernel there and improve it (that is if wife permits).
Click to expand...
Click to collapse
lol she's really not that strict, she just thinks my development for our devices is a waste of time. Just PM me where to send it and ill get it out to you.
aceoyame said:
lol she's really not that strict, she just thinks my development for our devices is a waste of time. Just PM me where to send it and ill get it out to you.
Click to expand...
Click to collapse
Agreed, that's what my wife thinks too I'll PM you my location
BTW, please make sure that the location of yaffs_auto_checkpoint is in /sys/module/yaffs/parameters (some ROM might have it on modules).
UPDATE:
Checkpointing is working great for me so far. Command on first post has to be executed in every reboot to create a checkpoint so typing the commands in first post before rebooting will create a checkpoint and save data partition (me thinks).
You can install Gscript and run the script before reboot
To verify if you have yaffs2 checkpoint in the data partition Type the following in terminal
su
cat /proc/yaffs
Scroll down to Device 2 "userdata"
blocks_in_checkpt should be 1 or 2 (not 0, if it is zero then you have no checkpoint in data partition)
Can anyone help adding this to the shutdown script?
I've done 5 restarts, 2 battery pulls and 2 resets, made sure data partition was checkpointed before doing so....So far data partition has been OK with no FC's or errors, no lost apps with 18mb's left in data partition The thing that surprises me is that Phone Storage size hardly changes in size in every reboots so it's good news I have a feeling we finally nailed down this data corruption issue, but only time can tell since I will shift to prolong use before doing any restarts...
I have sent a PM to scooter hoping he can help me with a shutdown script so we won't need a Gscript. So far, Gscript is doing it for me. Upong reboot, I run the script and make sure I have a checkpoint in data partiion
clemsyn said:
sent a PM to scooter hoping he can help me with a shutdown script so we won't need a Gscript. So far, Gscript is doing it for me. Upong reboot, I run the script and make sure I have a checkpoint in data partiion
Click to expand...
Click to collapse
I've got it working in a script, i have it in a script which is run on startup and then again on a successful shutdown. I'll upload a couple of updates in a bit
EDIT: I have attached 2 updates to the post, one is for cyanogenMod based builds and the other is for all other builds such as fresh froyo etc.
Clemsyn, i have the latest yaffs source compiled into the kernel, i will commit it to git in a bit. With the latest yaffs a checkpoint is created every time sync is executed which makes scripts easier!
scooter1556 said:
I've got it working in a script, i have it in a script which is run on startup and then again on a successful shutdown. I'll upload a couple of updates in a bit
EDIT: I have attached 2 updates to the post, one is for cyanogenMod based builds and the other is for all other builds such as fresh froyo etc.
Clemsyn, i have the latest yaffs source compiled into the kernel, i will commit it to git in a bit. With the latest yaffs a checkpoint is created every time sync is executed which makes scripts easier!
Click to expand...
Click to collapse
I downloaded the CM update, and it didn't enable the checkpoint, still had to enable it manually through terminal.
Testing the kernel right now however, and so far liking it.
scooter1556 said:
I've got it working in a script, i have it in a script which is run on startup and then again on a successful shutdown. I'll upload a couple of updates in a bit
EDIT: I have attached 2 updates to the post, one is for cyanogenMod based builds and the other is for all other builds such as fresh froyo etc.
Clemsyn, i have the latest yaffs source compiled into the kernel, i will commit it to git in a bit. With the latest yaffs a checkpoint is created every time sync is executed which makes scripts easier!
Click to expand...
Click to collapse
Thanks scooter, I'll try it out. I got stuck on a fake vsync and can't get out of it that I was unable to create a checkpoint and upon reboot without a checkpoint, everything was messed up. This is perfect, getting a checkpoint on startup and another in shutdown Thanks a lot.
Krazy-Killa said:
I downloaded the CM update, and it didn't enable the checkpoint, still had to enable it manually through terminal.
Testing the kernel right now however, and so far liking it.
Click to expand...
Click to collapse
That's weird! So it didn't make a checkpoint on startup? I'm running the same script and init.rc and it works fine. I did push the file with adb though, did you fix permissions after updating?
scooter1556 said:
That's weird! So it didn't make a checkpoint on startup? I'm running the same script and init.rc and it works fine. I did push the file with adb though, did you fix permissions after updating?
Click to expand...
Click to collapse
Ooooooh.... Probably not, lol. I'll do that, and edit this post with my results.
*EDIT* Ok, I feel stupid. I still had an old androidupdate.tgz file in my sdcard andboot folder, and the boot menu used it instead of the correct .tar file... Hm, that explained why my Market stopped working, lmao.
Krazy-Killa said:
Ooooooh.... Probably not, lol. I'll do that, and edit this post with my results.
*EDIT* Ok, I feel stupid. I still had an old androidupdate.tgz file in my sdcard andboot folder, and the boot menu used it instead of the correct .tar file... Hm, that explained why my Market stopped working, lmao.
Click to expand...
Click to collapse
lol, rookie error
OK, it works on boot up since I get a checkpoint 1 every boot not sure about shutdown but if scooter says it works, I bet you it works in shutdown too
Scoot, I'm going to try to do a git diff and post it here so all the changes I've made in the config will be there.
Even with that little debacle, I had 0 corruption of data, or missing apps in my /data partition, and had to reboot 4-5 times, each time I used GScript to execute the command manually before shutdown.
And camera still works. ^.^
Krazy-Killa said:
Even with that little debacle, I had 0 corruption of data, or missing apps in my /data partition, and had to reboot 4-5 times, each time I used GScript to execute the command manually before shutdown.
And camera still works. ^.^
Click to expand...
Click to collapse
That's great news and if my memory serves me right, you easily have data corruption in shutdowns and reboot. IMO, scooter's script is the best option we have for this issue and you don't have to remember to use gscript (especially from an old person like me with slight dementia Anyways, I'll continue on with my testing with this script. If it is still working after a few days, I'll try to add Namespace support, CIFFS, PPOE in our kernel.
BTW, here is my git diff and .config file. Please put it up in GIT. Thanks.
I've tested this and it works. I only have a class 2 SDcard, so my testing shows it's really slow, a faster card would probably help.
With just this class 2 SD card, the boot-from-sd process is really only useful to see if the ROM being tested will straight-up brick your device or not.
Edit!
A class 6 card works fabulous! I'm posting from a tweaked version of mmarz's port of ath3nos' port of cm7 running from my brand-new class 6 card right now.
This process is hacked together from multiple other devices' howtos here on xda, sorry I don't know who to credit for the bits and parts. All of it is pretty generic, actually, and might well be applicable to other devices when tried as a whole.
For the moment, I'm only posting a brief skeleton how-to without specific walkthroughs for the steps, and I don't really want to upload many files until more of the bugs are swatted.
The following info should be enough for you, the savvy dev, to put the ROM of your choice on your SD card and boot it (or watch it fail to boot) without risk of bricking your device!
noobs, don't you dare, bricking is always a risk if you don't know your way around fastboot and adb!
Of course, savvy dev or not, a fresh nandroid backup is MANDATORY before hacking at your phone like this.
Standard disclaimer:
There is always a possibility of bricking your phone when messing with adb and fastboot.
If you're not willing to take that risk, don't try this at home (or at work, or school....)
Here goes:
The basic plan I followed was:
1) make and format 3 extra ext2 partitions after the default fat32 on the SD card, in this order: data (at least 180Mb) , system (170Mb to match stock), and cache (102Mb stock).
2) split up the boot.img from your chosen ROM so you can mod the ramdisk.
edit: turns out this next step in the quote is not required, there is an easier way.
A nifty command called devwait for init.rc
3) compile a modified init, adding a "pause (5);" after the ANDROID text. It goes on line 569 in the gingerbread init.c from a recent repo of google source.
use the newly compiled init in place of the init from the ramdisk.
since getting the android source uses so much time and bandwidth, I'm being nice and attaching a modified gingerbread init. If you test it with a froyo ROM and it doesn't work, don't blame me. If it does work with froyo ROMS, let me know!
Click to expand...
Click to collapse
3) change your init.rc from the ramdisk as follows:
replace the "mount yaffs2 [email protected] /system" , cache, and data lines with
Code:
devwait /dev/block/mmcblk0p3
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime ro
devwait /dev/block/mmcblk0p2
mount ext2 /dev/block/mmcblk0p2 /data nodev nosuid noatime nodiratime
devwait /dev/block/mmcblk0p4
mount ext2 /dev/block/mmcblk0p4 /cache nodev nosuid noatime nodiratime
be sure to comment out any other mounts which go to /system anywhere, like the "mount squashfs [email protected]/system/blahblah/blah.sqf /blah/blah" lines in the aospCmod init.rc
4) repack your boot.img, with the correct cmdline ("mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" works,) etc.
5) prepare the ext2 /system partition with your target ROM /system files.
How to load the ROM:
steps a) to f) done on your PC. step g) is done on the phone.
a) Unzip the ROM on your PC, to get at the files to copy to the new /system directory in adb, and allow you to modify the updater-script.
b) Mod that ./META-INF/com/google/android/updater-script as follows:
As an example, I removed the following from the aospCmodOV-5-16-11 updater-script:
everything except the "ui_print" "symlink" and "set_perm" lines, including the "unmount" line at the end of the script.
I thinned it down because the update-binary wants to write to MTD partition for /system, and I didn't want or need that to happen.
I did need it to install the symlinks and permissions, though.
Without those, the keyboards kept FCing, and the phone couldn't connect to the network.
c) rezip the ROM with the modified updater-script.
d) boot phone into recovery and connect to PC with cable.
e) adb push or otherwise copy the modified ROM.zip to your sdcard.
f) next, copy /system from the unzipped ROM to the new partition with adb
Code:
adb shell
mount -t ext2 /dev/block/mmcblk0p3 /system
exit
adb push /path/to/unzipped/ROM/system /system
g) on phone, in recovery: install .zip from sdcard
select the new ROM.zip you reassembled and pushed to the SD card
select yes, you really want to install the .zip
this should write the /system symlinks and permissions to the new /system partition.
Click to expand...
Click to collapse
6) back on your PC, still connected to phone with cable in recovery;
Code:
adb reboot bootloader
fastboot boot /path/to/boot.img
Step 6 is important!
this will boot from your modified boot.img without actually flashing it into the phone's NAND, so a reboot (or restart after battery pull in case of issues) just goes to your regular installed ROM in the phone.
That's about it for now. It's pretty much a hack as yet, but it's cool in a geeky way to be able to do this.
<reserved for future use>
Thanks! This should be very helpful to devs and those of us who are adventurous with our phones!
Very interesting concept, I'd love to see how many uses this could have!
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
bigsupersquid said:
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
Click to expand...
Click to collapse
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
I personally still have problems recompiling a ramdisk.
mmarz said:
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
Click to expand...
Click to collapse
I can post files one rom at a time, because the ramdisk and kernel will be a bit different for each rom, and so will the permission/symlink updater-script.
first, I'll have to get rom-dev permission, because they get modded, and also cause it's nice to have permission.
I personally still have problems recompiling a ramdisk.
Click to expand...
Click to collapse
fastboot provides a fantastic shortcut for that, if you cpio-gzip the ramdisk together after editing it to your specs
from http://android-dls.com/wiki/index.php
in a command line linux shell, from the directory containing your unpacked ramdisk,
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
will put newramdisk.cpio.gz in the directory above the one containing your ramdisk
Click to expand...
Click to collapse
fastboot can make the boot.img for you and either dump it into the phone (assuming your shell current directory contains your kernel (zImage) and ramdisk (newramdisk.cpio.gz))
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" flash:raw boot zImage newramdisk.cpio.gz
or boot your phone from the assembled image without actually flashing it in.
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" boot zImage newramdisk.cpio.gz
those fastboot lines assume an optimus v (or s.)
looking at all the great work you've posted on the forums, I'm surprised you have trouble handling anything to do with these phones!
I'm slowly working up to a modded recovery to install-to-sd directly and avoid all this hacking.
Nice, thanks for that. I had no idea fastboot could do that.
mmarz said:
Nice, thanks for that. I had no idea fastboot could do that.
Click to expand...
Click to collapse
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
bigsupersquid said:
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
Click to expand...
Click to collapse
Very cool i loved this idea when it was executed in a way over at Ubuntdroid for the intercept when i was doing alpha testing. Very convenient for many of the scarier tests when i wanted to keep my existing system intact. The big difference was that on the intercept the bootable partitions were written into the kernel. Downside you couldn't use it to test kernels but could switch kernels from the phone and flip-flop between completely isolated systems on the go without a computer. Which was great when i wanted to test a new ROM on the way to work but i needed my phone when i got there and had to have a painless method of switching to my usual running system. So i'd flash a "non SD" kernel and i was back up and running in just a minute or so.
I'm excited to play with this when i have some free time.
Thanks dude!
you could easily use an update.zip for each of the sd-boot and regular phone boot.img files and swap between working systems with those in recovery.
before getting the fast sd card, I was looking at this more as for testing foreign roms than two-system operation, but now I see that would work too.
for a second-system option I was looking at a market-enabled rom on sd since I don't use g-apps on my daily driver.
note: the GB rom I'm running on won't 'see' a card with more than four partitions properly, and won't mount the vfat partition with vold, although you can manually mount and access the first four partitions including the vfat. android just won't admit it's there. and I couldn't get at a fifth partition through the phone os, even though my pc could see it fine (to get 5 partitions I had to use an extended partition to contain most of the virtual partitions)
android could read virtual partitions in an extended partition just fine as long as the total number on the card didn't exceed four.
I learned a neat trick today.
going through the init.rc from the stock rom, I noticed a section at the beginning which was labeled 'on emmc' which would imply running from a card if the device hardware lacked nand flash memory.
I'd read on xda while researching this concept of boot-from-sd about an unspecified wait-for-device command in init.rc, but most of the info I've gotten on init scripting language has come from picking apart init scripts, as google has not documented the available commands very well.
long story short, I tried using devwait with the regular init and it worked just fine to mount the ext partitions. yay!
first post edited to reflect the improved method.
I've also been testing a recovery mod. if recovery.fstab is modified in the recovery ramdisk (or a fakeflash recovery) then the recovery will copy a tweaked rom.zip to the ext /system partition with some minimal modifications to the updater-script and a few commands in the adb shell.
the recovery with the modded recovery.fstab can also back up from and restore to the sdcard ext /data and /system partitions.
I will update the first post with more specific instructions as I hammer them into something consistent.
soon I'll be ready to release a modded fakeflash recovery to make experimentation easier, as well.
Y.G. said:
I formated my sd card to Ext4 and when insert it in to my phone, it says that's it's blank and has unsupported files. Any reasons for that?
Sent from my SPH-L710 using xda premium
Click to expand...
Click to collapse
The SPH-L710 Samsung Stock LJ7 TW 4.1.1 Android doesn't understand/support the change to ext4 external SD card (microSD) without a few things being done.
I'm working this out right now. So far I have manually been able to mount the newly created ext4 partition on the microSD card through adb, and after some chown/chmod I was able to go back to "Settings and Storage" and the "Mount SD Card" picked it up, and I was up and running ext4. But this didn't persist after a restart. So I'm looking into: /etc/vold.fstab MODS to keep it after restart right Now !!
If Some one else already has this perfected please chime in. I'm wanting to do most of the devices in the house this way when I get time because better performance, having a file system with a journal, and getting rid of thins like 4 Gig per file limitations is pretty Sweet in my humble opinion *Grin*
0) Assuming you already have your microSD card formatted ext4. I also happened to label mine extSdCard for the volume label within gparted
1) Can mount with:
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard/
2) To get the correct owner and permissions run:
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
3) Should make the extSdCard owner/permissons match the regular internal sdcard you can verify this like so:
cd /storage/ && ls -l
drwxrwxr-x root sdcard_rw 2013-01-12 18:16 extSdCard
drwxrwxr-x root sdcard_rw 2013-01-12 17:05 sdcard0
4) After that you can go to the "Settings and Storage" to run "Mount SD" and you will have ext4 extSdCard Show up and it bring up the File System Status !! --> Until you reboot and it goes to crap because I don't have the vold.fstab edit/MOD complete _yet_ ... So, for now a boot script has been put in place to bring our external SD card back online during restart, so the system will acknowledges it, making the world a better place.
Example of how things look file system wise: mount | grep extSdCard
/dev/block/mmcblk1p1 /storage/extSdCard ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
5) Have not been able to resolve the vold.fstab to make this ext4 extSdCard matter fully Legit (in my opinion), but I did manage to make it remount the card on boot, so its online when the system comes up instead of having to manually mount it. Did this by -->
Added the following lines to the very bottom of: /etc/init.qcom.post_fs.sh
## sponix MOD to match with ktoonz kernel for better power management
stop mpdecision
## sponix MOD to mount extSdCard prior to GUI work around to make ext4 function
## read and write extSdCard mount
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
## if you want read only extSdCard mount
## mount -r -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
Still attempting to automate the process so the Stock+root LJ7 can pick up the extSdCard _normally_ without having to do the mount command manually, but so far its kicking my butt. Also this is more a "General, or Question and Answer type Topic" the Kernel(s) obviously support ext4 the system fs uses/requires it *Grin*.. So we might get Our Friendly Neighborhood Moderator to Migrate it to the proper place to help others. Just hoping to get the last few bumps smoothed out, or find someone that already documented the process that I've overlooked *Grin*..
Current Known Issues: If you unmount the card through the "Settings | Storage | Umount SD" or by hand with umount, you will either need to reboot for it to reattach through the /etc/init.qcom.post_fs.sh boot script script addition, or will have to mount it manually if you want to keep the system up and running. Guess you could also probably just run the /etc/init.qcom.post_fs.sh as root from a terminal emulator (or adb).
Still searching for vold.fstab bits of wisdom but that will have to continue next weekend -->
Sexy and You Know it,
Keep on Flashing,
sponix2ipfw (sponix
:fingers-crossed:
Ha! Sorry. Deleted: Didn't understand that you had it running on boot (can't read properly )
Great idea
Am I really the only one who also thinks this idea is the nuts?
Am I the only one who longs to transform the mess that passes for a filing system on the internal sd using symbolic links into a beautifully organized, encrypted and cloud synced system on my external sd?
Is it just me and a few others that want to be able to achieve the above so that we can move from one ROM to another or recover from a lost phone with the minimum of fuss?
Are we freaks? :cyclops:
Say it isn't so XDA!! :crying:
I'm gonna try this on my international S3 running Null_ Rom 25 JB 4.1.2
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?
emp111 said:
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?
Click to expand...
Click to collapse
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share
Insane ideas are the best lol
CNexus said:
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share
Click to expand...
Click to collapse
Thank you for your prompt reply, yes it is asking a lot I know but I think that it can be done.
Now if you really thought that idea was insane......check this out:
Imagine that we asked every Android app developer to submit the various paths used for their config (and config backup) files to a central database and had the ability to add or own custom paths (which could be added to the central database once approved).
We could build an script/app that would retrieve a list of currently installed apps on your phone then automatically build a symbolically linked file system (and/or backup file system) in the location of your choice that you could either encrypt and/or sync using your current tools or even incorporate this functionality into the app itself along with the ability to choose what was encrypted/backed up and how i.e. either synced to the Cloud or (S)FTP or SMB as either a dd copy or even a cwm flashable zip.
Could I dare hope for a Tasker module or the ability to add custom scripts?
I wish I could do this myself but my coding skills are non existent
Anyway the LUKS manager app won't automatically mount a file system, but I really like it anyways, thank you for pointing me to it!
And on the Ext4 front, the mount command (yes the 1st one ) failed, maybe the op could offer a suggestion. :angel:
BTW is there a place for people to suggest ideas for apps here?
Wait really it wont? I couldve sworn I remembering that it did
But dude....
You need to learn yourself some java and start whipping stuff up
Idk about the whole central database thing, but the rest could definitely be done with root access
I think the main problem with that is the proprietary aspects...i mean even here on XDA where binaries released are supposed to be GPL compliant, many of them arent and its sad because it deteriorates the overall quality of work thats released afterward
This whole thing is just hard work!
CNexus said:
Wait really it wont? I couldve sworn I remembering that it did
Click to expand...
Click to collapse
Doesn't seem to unfortunately
But dude....
You need to learn yourself some java and start whipping stuff up :D :D[/QUOTE said:
You make it sound soooo easy lol, and at another point in my life maybe it would have been but right now I'm operating at a reduced level due to some unforeseen circumstances that have left me lacking focus, motivation etc
You know all the things you need to be creative, learn etc lol
Anyway back to the matter at hand, I have got my ext4 SD card to the stage where I have to manually mount it from within the Settings/Storage as I'm using the international S3 and don't have the init.qcom.post_fs.sh, I think the qcom refers to Qualcomm chipset in US S3's.
As for modifying vold.fstab so we can avoid the above workaround it would seem that maybe thats a dead end as according to a German guy on android-hilfe. de, Vold may have been modified by Samsung to only deadl with exFAT on External SD's.
Looks like I'm not gonna be in Android nirvana for a while :crying:
Unless anyone else on XDA fancies getting in on this !!!!
Click to expand...
Click to collapse
Got it working ..... kinda
Got an app called ezymount (by ezynow) that automounts my ext4 64GB microSD at boot time.
I have to wait a few seconds for the boot process to complete but it's automatic, am pretty happy!!
Now gotta get symlinks, encryption and cloud synchronization sorted :/
Noogie was the image to put on the NST so that you could backup or restore the entire internal memory.
It was usually put on the removable SD card.
In fact, it could have been just booted directly through fastboot.
Later, people worked on and succeeded on a way to boot up the NST without any valid internal memory at all.
This made the NST unbrickable.
Neo Noogie is pretty much the same, but updated for the Glow2 & Glow3.
Since these models don't have a removable SD card they need to be able to boot over fastboot.
This means that if you totally wipe out the memory on your Nook (including where fastboot is) you'll be bricked.
(That is, until we get working on a USB bootloader method.) We do have a bootloader, see https://forum.xda-developers.com/nook-touch/general/fix-bricked-glow2-3-4-t4002911
Warning: Windows will offer to format anything it doesn't understand! Do not format!
Code:
C:\>adb reboot fastboot
C:\>fastboot boot nnglow2.img
<use your favorite utility to copy to/from the disk that appears>
C:\>adb reboot
Update
New versions as of 2019-12-18, nnglow2.img, nnglow3.img, nnglow4.img
Download through the signature
Renate NST said:
Noogie was the image to put on the NST so that you could backup or restore the entire internal memory.
It was usually put on the removable SD card.
In fact, it could have been just booted directly through fastboot.
Later, people worked on and succeeded on a way to boot up the NST without any valid internal memory at all.
This made the NST unbrickable.
Neo Noogie is pretty much the same, but updated for the Glow2 & Glow3.
Since these models don't have a removable SD card they need to be able to boot over fastboot.
This means that if you totally wipe out the memory on your Nook (including where fastboot is) you'll be bricked.
(That is, until we get working on a USB bootloader method.)
Warning: Windows will offer to format anything it doesn't understand! Do not format!
Click to expand...
Click to collapse
Can you add md5 sums for the images?
eriol1 said:
Can you add md5 sums for the images?
Click to expand...
Click to collapse
Neo Noogie does four things:
It boots up without mounting any partitions at all
It presents the entire internal SD card as a UMS volume over USB
It supports ADB
It supports the hardware console shell (Ok, most people didn't install a jack in their Nook)
None of this has anything to do with MD5.
But I'm glad you brought it up.
You can get an MD5 of the internal SD card (only when Neo Noogie is running, not when B&N has everything mounted).
Code:
# md5sum /dev/block/mmcblk0
0a1c3941a12abff93b44a2603381ad12 /dev/block/mmcblk0
It reliably generates the same MD5 since nothing is changing.
After you have pulled the 4 or 8 GB over to your host machine, you can likewise calculate the MD5.
Right now I seem to be getting two different MD5's despite the MD5's being repeatable (on either end) and multiple transfers give no differences.
Renate NST said:
Neo Noogie does four things:
It boots up without mounting any partitions at all
It presents the entire internal SD card as a UMS volume over USB
It supports ADB
It supports the hardware console shell (Ok, most people didn't install a jack in their Nook)
None of this has anything to do with MD5.
But I'm glad you brought it up.
You can get an MD5 of the internal SD card (only when Neo Noogie is running, not when B&N has everything mounted).
It reliably generates the same MD5 since nothing is changing.
After you have pulled the 4 or 8 GB over to your host machine, you can likewise calculate the MD5.
Right now I seem to be getting two different MD5's despite the MD5's being repeatable (on either end) and multiple transfers give no differences.
Right now it's a head scratcher.
Click to expand...
Click to collapse
I actually just meant md5 of the bootable img files, so we can make sure the file is intact before booting.
But it seems you hit an interesting issue so I guess we're lucky I didn't explain myself properly
eriol1 said:
I actually just meant md5 of the bootable img files...
Click to expand...
Click to collapse
Oh...
Code:
nnglow2.img
[strike]21ce45fe df9abe3f 882c73fa 4928d091[/strike] [color=red]Obsolete numbers[/color]
nnglow3.img
[strike]1e3975db 5b0a8a3b 7c6cbf60 ef8e2449[/strike] [color=red]Obsolete numbers[/color]
Something strange is going on with the 8G MD5s, but not the files themselves.
I generate 233 MD5s on 32Meg chunks.
All 233 are identical on both sides!
I generate a single MD5 over the entire thing and they are not the same.
Ok, no problem at all.
What I was seeing was an MD5 utility on my Windows box that hadn't anticipated files > 4G.
MD5's of the transferred images (4GB or 8GB) on Nook and host agree.
Renate NST said:
Oh...
Something strange is going on with the 8G MD5s, but not the files themselves.
I generate 233 MD5s on 32Meg chunks.
All 233 are identical on both sides!
I generate a single MD5 over the entire thing and they are not the same.
Ok, no problem at all.
What I was seeing was an MD5 utility on my Windows box that hadn't anticipated files > 4G.
MD5's of the transferred images (4GB or 8GB) on Nook and host agree.
Click to expand...
Click to collapse
I was just about to suggest something along those lines
Good to know there's no deeper issue. Thanks!
Renate NST said:
(That is, until we get working on a USB bootloader method.)
Click to expand...
Click to collapse
Like i.imx6 usb recovery mode?
https://boundarydevices.com/unbricking-nitrogen6x-sabre-lite-i-mx6-board/
But, I don't really think it will be possible without disassembly.
RyogoNA said:
But, I don't really think it will be possible without disassembly.
Click to expand...
Click to collapse
Right, it's not so friendly as the OMAP in the NST.
You have to play with the boot mode jumpers (which don't physically exist on this board).
You might me able to ground an easily accessible test point.
OTOH, if you've gone that far a JTAG interface would work too.
Big oops on my part
I accidentally left the setting in Neo Noogie for the internal SD card in read-only.
It's actually not a big deal (ahem, since no one complained).
Any backups that you made are fine.
It just means that you can't write them back into the Nook this second using that version of Neo Noogie.
Keep on making backups if you like.
I'll put up new versions of Neo Noogie in a bit.
I put new versions of the images in the first post's attachments.
The simple change was just to omit the read-only flag for the internal SD card.
I did a bunch of cleanup that you will probably not notice unless you use the shell.
Rant
Ever see that "__bionic_open_tzdata: couldn't find any tzdata" when running TWRP or other images?
The libc.so wants to get its hands on information about timezones.
Sometimes it's missing and then you get three lines of that gobble-dee-gook error message every time you use any command.
The simple solution is to park the tzdata somewhere (and patch libc.so with the hard-coded path).
All this just to say, "Ok, just use UTC and don't give me the stupid error messages continuously"?
Well, it's stupider. The full tzdata is 0.5 Megs.
Why? So we can have timezones for every podunk village on the globe (576 timezones).
I'm using a modified version of tzdata that includes only UTC and is 194 bytes.
Renate NST said:
Noogie was the image to put on the NST so that you could backup or restore the entire internal memory.
It was usually put on the removable SD card.
In fact, it could have been just booted directly through fastboot.
Later, people worked on and succeeded on a way to boot up the NST without any valid internal memory at all.
This made the NST unbrickable.
Neo Noogie is pretty much the same, but updated for the Glow2 & Glow3.
Since these models don't have a removable SD card they need to be able to boot over fastboot.
This means that if you totally wipe out the memory on your Nook (including where fastboot is) you'll be bricked.
(That is, until we get working on a USB bootloader method.)
Warning: Windows will offer to format anything it doesn't understand! Do not format!
Code:
C:\>adb reboot fastboot
C:\>fastboot boot nnglow2.img
<use your favorite utility to copy to/from the disk that appears>
C:\>adb reboot
Update
New versions as of 2018-05-04
nnglow2.img c52e433e 1340acd8 f4d89f9b fa572334
nnglow3.img 6bf28a03 aaa24b93 584a8c35 09cf3a0c
Click to expand...
Click to collapse
Hello - neewby here - I got the Nook Glowlight Plus -
is this a custom image ?ROM?
Thank you
DanChr79 said:
is this a custom image? ROM?
Click to expand...
Click to collapse
It's not really a ROM because it's doesn't run Android or apps.
It is a custom image because it is a minimal OS.
Its only purpose is to allow you to copy the full internal memory to/from your desktop computer.
There are three ways to boot up an OS:
From the boot partition (normally the regular OS)
From the recovery partition (normally the factory restore routine)
Downloaded over fastboot (normally not used)
Renate NST said:
It's not really a ROM because it's doesn't run Android or apps.
It is a custom image because it is a minimal OS.
Its only purpose is to allow you to copy the full internal memory to/from your desktop computer.
There are three ways to boot up an OS:
From the boot partition (normally the regular OS)
From the recovery partition (normally the factory restore routine)
Downloaded over fastboot (normally not used)
Click to expand...
Click to collapse
Thank you for the reply
Then do you know of a customer rom or how to root the device?
The posts here are super old and I am not sure how to fully use (full android) my new Glowlight Plus?
DanChr79 said:
Then do you know of a customer rom or how to root the device?
Click to expand...
Click to collapse
Well, there's a million ways to root it, but since you're on this thread, we can do it this way.
Code:
C:\>adb reboot fastboot
C:\>fastboot devices
1234567812345678 fastboot
C:\>fastboot boot nnglow2.img [color=red]nnglow2 for Glowlight Plus[/color]
C:\>adb shell
# echo /dev/block/mmcblk0p1 > /sys/devices/platform/fsl-usb2-udc/gadget/lun0/file
# cat /sys/devices/platform/fsl-usb2-udc/gadget/lun0/file [color=red]this is just a check to make sure that it worked[/color]
/dev/block/mmcblk0p1
# ^D
C:\>sdcard /r G p1.img [color=red]might not be G, use File Explorer and see what letter it is[/color]
SD card G, disk #3, 6,258,688 bytes, 512 sector size
C:\p1.img, 0 bytes
Copy SD card G to image (Y or N)? y
Copying SD card G to C:\p1.img
100%
Finished
C:\>imgutil /x p1.img default.prop
[color=red]Use a real text editor (not Notepad!) to change ro.secure=0 and ro.debuggable=1[/color]
C:\>imgutil /r p1.img default.prop
C:\>sdcard /w G p1.img [color=red]we're writing now, make sure everything was correct![/color]
SD card G, disk #3, 6,258,688 bytes, 512 sector size [color=red]make sure that this number is exactly the same as the first time![/color]
C:\p1.img, 4,421,632 bytes [color=red]this number will be somewhere around this, less than the 6.2M[/color]
Copy image to SD card (Y or N)? y
Copying C:\p1.img to SD card G
100%
Finished
C:\>adb reboot
sdcard.exe and imgutil.exe are in the signature, nnglow2.img is in the first post of this thread.
Renate NST said:
Well, there's a million ways to root it, but since you're on this thread, we can do it this way.
Code:
C:\>adb reboot fastboot
C:\>fastboot devices
1234567812345678 fastboot
C:\>fastboot boot nnglow2.img [color=red]nnglow2 for Glowlight Plus[/color]
C:\>adb shell
# echo /dev/block/mmcblk0p1 > /sys/devices/platform/fsl-usb2-udc/gadget/lun0/file
# cat /sys/devices/platform/fsl-usb2-udc/gadget/lun0/file [color=red]this is just a check to make sure that it worked[/color]
/dev/block/mmcblk0p1
# ^D
C:\>sdcard /r G p1.img [color=red]might not be G, use File Explorer and see what letter it is[/color]
SD card G, disk #3, 6,258,688 bytes, 512 sector size
C:\p1.img, 0 bytes
Copy SD card G to image (Y or N)? y
Copying SD card G to C:\p1.img
100%
Finished
C:\>imgutil /x p1.img default.prop
[color=red]Use a real text editor (not Notepad!) to change ro.secure=0 and ro.debuggable=1[/color]
C:\>imgutil /r p1.img default.prop
C:\>sdcard /w G p1.img [color=red]we're writing now, make sure everything was correct![/color]
SD card G, disk #3, 6,258,688 bytes, 512 sector size [color=red]make sure that this number is exactly the same as the first time![/color]
C:\p1.img, 4,421,632 bytes [color=red]this number will be somewhere around this, less than the 6.2M[/color]
Copy image to SD card (Y or N)? y
Copying C:\p1.img to SD card G
100%
Finished
C:\>adb reboot
sdcard.exe and imgutil.exe are in the signature, nnglow2.img is in the first post of this thread.
Click to expand...
Click to collapse
Thank you so much for your time and reply.
This will root the device?
I will still need a custom rom ? android to install on it?
Is there a script available or BAT file since I am a computer noob?
DanChr79 said:
Thank you so much for your time and reply.
This will root the device?
I will still need a custom rom ? android to install on it?
Is there a script available or BAT file since I am a computer noob?
Click to expand...
Click to collapse
This will give you shell root access.
What you want to do with it is another question.
I don't have a script.
There may be other threads on this forum that use different approaches, do a dozen things and have scripts.
I haven't really paid any attention because I just rooted my devices with a hardware root console.
Renate NST said:
This will give you shell root access.
What you want to do with it is another question.
I don't have a script.
There may be other threads on this forum that use different approaches, do a dozen things and have scripts.
I haven't really paid any attention because I just rooted my devices with a hardware root console.
Click to expand...
Click to collapse
Danke Renate....
Usually after rooting, customers image will be applied to phones or tablets no?
So I root it and then.... I am able to use custom apk?
DanChr79 said:
So I root it and then.... I am able to use custom apk?
Click to expand...
Click to collapse
If you just want to install an APK, you can just install an APK without rooting.
Have you tried that yet?
Code:
C:\>adb install whatever.apk
I could be wrong. I've never had an unrooted Nook.
Does anyone has a glow3 backup that can share?
I "managed" to brick mine and I will need images to (hopefully) revive it.
Can anyone point me to a recovery guide via USB?
I suppose I should be able to start u-boot via mfgtool/uuu/imx_usb_loader with fastboot enabled and recover partitions content from there?
Thanks,
C
cipibad said:
I should be able to start u-boot via mfgtool/uuu/imx_usb_loader
Click to expand...
Click to collapse
A late response, but...
I've tried various of the iMX loaders and didn't have much luck, so I wrote my own, imxboot.exe
It's available in the signature.
There are three new Neo Noogie images to download for the Glow2, 3, 4.
There has been a bit of cleanup and a few improvements.
It's easier to mount partions now, no need to do all the parameters yourself.
Code:
# mount system
# mount data
@Renate NST
Please add md5 for images
And update thread name to " & Glow4"
Thank you for all your work!