Related
Perhaps a dumb question, but my brain is hurting from all the learning here:
I have modified my phone as I want it, including rooted deodexed stock eb01, swapping .apks, running all the mods through cwm, removing apps,etc. (I guess I themed it the hard way).
Question: Can I create a .tar file from the device while it is running, basically a 'snapshot' of the system exactly as it is ? That way I can odin to current setup if I dork up my phone.
my apologies if this is a stupid question
Sent from my SCH-I500 using XDA App
THAT IS TOTALLY NOT A STUPID QUESTION...I actually believe its a great idea right now.
Well, the long answer is, you shell into the phone and make images of the various sectors of the phone, name them properly, and heimdall them. If you use odin, take an extra step to tar it together.
Here its a guide for doing that on a continuum:
http://androidforums.com/continuum-all-things-root/263953-how-make-custom-odin-images.html
Note it glosses over dividing out the kernel binaries and RAMdisk, mentioned in the more comprehensive guide for the Behold:
http://androidforums.com/behold-2-all-things-root/54424-creating-custom-roms- odin.html
I haven't seen anyone post a cute little listing of the actual partitions and cutoffs specific to the fascinate, but I haven't looked very hard either.
UPDATE #2: (it is L: bml7, not bm17 & not bmI7)
So theoretically it's really simple (from an adb shell):
dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
dd if=/dev/block/stl10 of=/sdcard/dbdata.rfs bs=4096
dd if=/dev/block/stl11 of=/sdcard/cache.rfs bs=4096(copy zImage and factoryfs.rfs to your local computer)
tar -H ustar -c zImage factoryfs.rfs dbdata.rfs cache.rfs > odinTAR.tarThese two commands append an md5 checksum to your package, and then rename the file. This finishes the process.
md5sum -t odinTAR.tar >> odinTAR.tar
mv odinTAR.tar odin_package.tar.md5NOTE: I did not include the modem, but you can flash that separately. This tar includes your personal data, so consider this before distributing any file you make this way. I haven't tested these instructions myself in any way.
Short answer:
Backup (everything but kernel) with nandroid and use that to restore. So long as you have a happy recovery setup, that is the path of least effort.
Swyped w/ XDA App. A clean tie attracts the soup of the day.
thanks for the response; certainly more involved than just a " create .tar" option somewhere. (Though that would be cool to develop for CWM or something)
Looks like some more learning for me. Always appreciate the info.
The next time there is a worthwhile update from VZW, I'd like to put together a not-stock, stripped-down-as-possible (small file) odin tar that is just enough to be a launchpad for flashing ROMs on whatever the next official modem is. So I'm doing my reading ahead of time.
Actually this looks like a great "What is where" link:
http://forum.xda-developers.com/showthread.php?t=850359
To paraphrase the link I posted above:
These are found in /dev/block. BML stands for Block Management Layer. STL is Sector Translation Layer. RFS is Samsung's Robust File System.
bml7 zImage (kernel)
stl9 factoryfs.rfs (system)
modem:
bml12 modem.bin
personal data:
stl10 dbdata.rfs
stl11 cache.rfs
other:
stl6 param.lfs
bml2 pit.pit
bml3 efs.rfs
NEVER:
bml1 boot.bin
bml4 Sbl.bin
unknown:
bml8 recovery.bin
You may use dd (and apparertly cat) to copy these partitions to your SD card:
adb shell su -c "dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096"
adb shell cat /dev/block/stl9 > /sdcard/factoryfs.rfs
You may reflash them individually with heimdall, or tar to flash as a group in Odin.
I followed these instructions Enable/Disable USB MASS STORAGE mode (UMS) and everything works fine.
Currently if I reboot the device the persist.service.mount.umsauto goes back to 1.
How do I make it always stay at 0? I don't want this mode to be ever enabled again until I explicitly set it to 0 from command line.
Thanks
You'd have to change the init.rc in uRamdisk in the boot partition.
Step 1: Make sure that you have a good backup of the entire Nook.
You need to change:
Code:
# Enable auto-mounting of USB mass storage
setprop persist.service.mount.umsauto 1
If you care to use bootutil.exe in my signature, you can:
Code:
bootutil /x uRamdisk init.rc
[i]edit init.rc and change the one to a zero[/i]
bootutil /r uRamdisk init.rc
Of course you have to mount the boot partition and ADB pull uRamdisk.
Thanks for reply Renate.
To highlight my ignorance let me ask the followup question:
How do I do pull the uRamdisk?
Renate NST said:
...
Of course you have to mount the boot partition and ADB pull uRamdisk.
Click to expand...
Click to collapse
If I do the "adb shell ls /" I see bunch of files in the root folder including init.rc, but not the uRamdisk. I guess what I see is the content of uRamdisk.
Probably the keyword is "mount the boot partition". How do I mount the boot partition?
Thanks a lot.
I sorted it out:
Code:
$adb shell mount -r -t vfat /dev/block/mmcblk0p1 /data/local/tmp/boot/
$adb shell ls -l /data/local/tmp/boot/uRamdisk
-rwxrwxrwx root root 185116 2012-10-11 21:05 uRamdisk
I recently upgraded a Galaxy S2 to Cyanogenmod 12.1 / android 5.1. I also wanted to use full disk encryption with the device and being able to access the internal memory via MTP instead of having a mass storage device. The removable sd card may be accessed via MTP, too, but will not be encrypted. Updating the recovery images to reflect the changes in the storage configuration (in case this is necessary) is not in scope, either.
Cyanogenmod by default only encrypts the /data partition. Newer models emulate the sdcard storage and save the data to /data/media, so everything gets encrypted. However, being an older phone there is still a separate sdcard-partition on the phone which is physically and directly mounted and which will not be touched by encryption.
In order to achieve the goal of full disk encryption two steps are necessary:
1. Change storage configuration to emulated media
2. Shrink old /sdcard partition and grow /data partition
= Change storage configuration to emulated media =
Emulating the sdcard in /data/media instead of physically mounting it directly requires changes to fstab.hardware (fstab.smdk4210), storage_list.xml and init.hardware.rc (init.smdk4210.rc). These files have to be changed in the Cyanogenmod source code and compiled to a new image. The configuration is based on the "Emulated primary, physical secondary" example given in h t t p s : / / source . android . com / devices / storage / config-example.html (cannot properly post URL due to new user restriction).
Here are the relevant changes in init.hardware.rc (init.smdk4210.rc):
Code:
--- init.smdk4210.rc.bak 2015-11-22 23:01:49.259579157 +0000
+++ init.smdk4210.rc.final 2015-11-30 20:21:37.977943177 +0000
@@ -2,35 +2,47 @@
import init.gps.rc
on init
- export EXTERNAL_STORAGE /storage/sdcard0
+ export EXTERNAL_STORAGE /storage/emulated/legacy
+ export EMULATED_STORAGE_SOURCE /mnt/shell/emulated
+ export EMULATED_STORAGE_TARGET /storage/emulated
export SECONDARY_STORAGE /storage/sdcard1
- mkdir /mnt/media_rw/sdcard0 0700 media_rw media_rw
- mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw
mkdir /mnt/media_rw/usbdisk0 0700 media_rw media_rw
- mkdir /storage/sdcard0 0770 root root
- mkdir /storage/sdcard1 0770 root root
+ mkdir /mnt/shell/emulated 0700 shell shell
+ mkdir /storage/emulated 0555 root root
+ mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw
+ mkdir /storage/sdcard1 0700 root root
+
mkdir /storage/usbdisk0 0770 root root
+ mkdir /storage/sdcard1 0775 system system
+
mkdir /efs 0771 radio system
mkdir /preload 0771 system system
mkdir /mnt 0775 root system
mkdir /mnt/.lfs 0755 root root
# for backwards compatibility
- symlink /storage/sdcard0 /sdcard
- symlink /storage/sdcard0 /mnt/sdcard
- symlink /storage/sdcard1 /extSdCard
- symlink /storage/sdcard1 /mnt/extSdCard
symlink /storage/usbdisk0 /usbdisk0
symlink /storage/usbdisk0 /mnt/usbdisk0
+ symlink /storage/emulated/legacy /sdcard
+ symlink /storage/emulated/legacy /mnt/sdcard
+ symlink /storage/emulated/legacy /storage/sdcard0
+ symlink /mnt/shell/emulated/0 /storage/emulated/legacy
+ symlink /storage/sdcard1 /ext_card
+ symlink /storage/sdcard1 /mnt/ext_card
+
+
+
# Disable CFQ slice idle delay
write /sys/block/mmcblk0/queue/iosched/slice_idle 0
on fs
mount_all /fstab.smdk4210
+ setprop ro.crypto.fuse_sdcard true
+
swapon_all /fstab.smdk4210
mkdir /efs/bluetooth
@@ -428,11 +440,10 @@
oneshot
keycodes 114 115 116
-service fuse_sdcard0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard0
+service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated
class late_start
- disabled
-service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
+service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
class late_start
disabled
Here are the relevant changes in fstab.hardware (fstab.smdk4210):
Code:
--- fstab.smdk4210.bak 2015-11-29 23:52:30.652913883 +0000
+++ fstab.smdk4210.final 2015-11-30 20:20:23.513945994 +0000
@@ -11,8 +11,8 @@
/dev/block/mmcblk0p12 /preload ext4 noatime,nosuid,nodev,journal_async_commit wait
# vold-managed volumes ("block device" is actually a sysfs devpath)
-/devices/platform/dw_mmc/mmc_host/mmc0/mmc0* auto auto defaults wait,voldmanaged=sdcard0:11,nonremovable,noemulatedsd
-/devices/platform/s3c-sdhci.2/mmc_host/mmc1* auto auto defaults wait,voldmanaged=sdcard1:auto,noemulatedsd
+/devices/platform/dw_mmc/mmc_host/mmc0/mmc0* auto auto defaults wait,voldmanaged=sdcard0:11,nonremovable
+/devices/platform/s3c-sdhci.2/mmc_host/mmc1* auto auto defaults wait,voldmanaged=sdcard1:auto
/devices/platform/s3c_otghcd/usb* auto auto defaults voldmanaged=usbdisk0:auto
# recovery
Here are the relevant changes in storage_list.xml:
Code:
--- storage_list.xml.bak2 2015-11-30 21:38:14.565769302 +0000
+++ storage_list.xml.final 2015-11-30 21:43:21.697757684 +0000
@@ -1,16 +1,13 @@
<?xml version="1.0" encoding="utf-8"?>
<StorageList xmlns:android="h t t p : / / schemas . android . com / apk / res / android "(cannot properly post URL due to new user restriction)>
- <storage android:mountPoint="/storage/sdcard0"
- android:storageDescription="@string/storage_internal"
- android:primary="true"
- android:removable="false"
- android:allowMassStorage="true" />
+ <storage android:storageDescription="@string/storage_internal"
+ android:emulated="true"
+ android:mtpReserve="100" />
<storage android:mountPoint="/storage/sdcard1"
android:storageDescription="@string/storage_sd_card"
- android:primary="false"
android:removable="true"
- android:allowMassStorage="true" />
+ android:maxFileSize="4096" />
<storage android:mountPoint="/storage/usbdisk0"
android:storageDescription="@string/storage_usb"
@@ -18,3 +15,4 @@
android:removable="true" />
</StorageList>
Compile Cyanogenmod and flash your phone. It should boot, but the amount of available storage should be significantly lower as the sdcard is emulated on the /data partition which has not been grown, yet.
= Shrink old /sdcard partition and grow /data partition =
Use PIT Magic to resize the partitions to an appropriate size. For a stock i9100 having 16GB of internal memory my configuration was as follows (according to the backup .pit-file downloaded via heimdall):
Code:
DATAFS:
start: 1,392,640
block count: 4,194,304
end: 5,586,943
UMS:
start: 5,586,944
block count: 24,133,632
end: 29,720,575
Hidden:
start: 29,720,576
block count: 1,048,576
end: 30,769,151
I changed the partition layout to the following sizes:
Code:
DATAFS:
start: 1,392,640
block count: 28,295,167
end: 29,687,807
UMS:
start: 29,687,808
block count: 32,768
end: 29,720,575
Hidden:
start: 29,720,576
block count: 1,048,576
end: 30,769,151
Deleting the UMS or hidden partitions or shrinking the hidden led to Cyanogenmod not booting. Upload the new .pit-file using heimdall and boot the modified Cyanogenmod. Reboot to Cyanogenmod recovery and wipe data. Formatting again using the Cyanogenmod recovery was required as apparently only this recovery honours the "encryptable=footer,length=-16384" option for the /data partition in fstab.hardware which directs the formatting tools to leave 16 kiB of space at the end of the partition for in-place encryption.
Is there a way to achieve emulated SD, without changing source code and recompiling?
Like editing fstab and other config files?
I run CM13 at the moment and would like to achieve full encryption through emulated SD.
I was playing around with the idea that i would resize the sdcard partition to 8mb and resize the /data partition (~14gb), so that applications have a hefty space and i would use the external sdcard (sdcard1) for storing data and media files. Would that be possible to with an emulated sdcard ? I was hoping that with the introduction of Android 6.0 it would allow me to merge (LVM?) the /sdcard0 and /sdcard1 but instead it merges /data and /sdcard1.
fireburner-de said:
Is there a way to achieve emulated SD, without changing source code and recompiling?
Like editing fstab and other config files?
Click to expand...
Click to collapse
I cannot prove that there is no way without having to recompile. However, I couldn't find storage_list.xml in the filesystem on my phone, so I assume that this file is only used during image compilation and therefore it's probably hard/impossible to achieve emulated SD without recompiling.
Maybe this configuration is easier to achieve using Cyanogenmod 13 / Android 6 as the storage_list.xml resource overlay has been removed.
PelzigesOhr, thank you sharing and documenting your experience so well, it has inspired me to try the same on Replicant 4.2 (distro based on CyanogenMod 10).
https:// github . com / GrimKriegor / replicant42-device_samsung_galaxys2-common / commit / 84c5a91a45b059a147921d0ea32367534904b314
However it seems the best way to create a partition table is using PitMagic, which seems to be proprietary software. Would you consider sharing your PIT file please?
Thank you for your time, all of this is greatly appreciated!
EDIT:
If you still have memory of the heimdall parameters used to flash this partition table, please do share as well.
EDIT2:
Managed to create a PIT file similar to yours, thanks for documenting it.
The following thread also includes a patch compatible with Replicant/Android 4.2.
Best of luck!
redmine . replicant . us / boards / 39 / topics / 13707
GrimKriegor said:
Would you consider sharing your PIT file please?
Thank you for your time, all of this is greatly appreciated!
EDIT:
If you still have memory of the heimdall parameters used to flash this partition table, please do share as well.
EDIT2:
Managed to create a PIT file similar to yours, thanks for documenting it.
The following thread also includes a patch compatible with Replicant/Android 4.2.
Click to expand...
Click to collapse
Thanks for the praise, I'm happy that the instructions are of use to someone else. Good to know that you managed everything yourself, I'll answer anyway: This forum doesn't seem to support attachments, so I haven't attached the .pit-file. Feeding the parameters I provided to PIT Magic should yield a good result, though. PIT Magic is indeed a proprietary Windows binary, but it runs fine using wine (at least that's the way I use it).
All the flashing has been done by loading clockworkmodrecovery (
Code:
heimdall flash --KERNEL clockworkmodrecovery.6050.i9100.touch.img
) and afterwards sideloading the compiled ROM.
PelzigesOhr said:
Thanks for the praise, I'm happy that the instructions are of use to someone else. Good to know that you managed everything yourself, I'll answer anyway: This forum doesn't seem to support attachments, so I haven't attached the .pit-file. Feeding the parameters I provided to PIT Magic should yield a good result, though. PIT Magic is indeed a proprietary Windows binary, but it runs fine using wine (at least that's the way I use it).
All the flashing has been done by loading clockworkmodrecovery (
Code:
heimdall flash --KERNEL clockworkmodrecovery.6050.i9100.touch.img
) and afterwards sideloading the compiled ROM.
Click to expand...
Click to collapse
Thanks for the reply sir.
Which partitions did you upload via Heimdall when you flashed the PIT file? I believe repartitioning could delete the contents of important partitions such as BOOT and MODEM, but I am unsure. Do you think maintaining their block boundaries would preserve the data in the respective partitions?
guy i can't mount /storage/sdcard0
i use Cyanogenmod 12.1 android 5.1.1
i need help guy
GrimKriegor said:
Which partitions did you upload via Heimdall when you flashed the PIT file? I believe repartitioning could delete the contents of important partitions such as BOOT and MODEM, but I am unsure. Do you think maintaining their block boundaries would preserve the data in the respective partitions?
Click to expand...
Click to collapse
The exact command I used for repartitioning with Heimdall-1.3.1 was as follows:
Code:
heimdall flash --repartition --pit <filename>
Data should be preserved and if you don't mess with the boundaries of partitions other than DATAFS, UMS and HIDDEN you should be fine. Before repartitioning I backed up all partitions as a precautionary measure, but I didn't have to restore any of them. See also http://forum.xda-developers.com/galaxy-s2/orig-development/guide-enlarge-datafs-partition-rid-t2353551
PelzigesOhr said:
The exact command I used for repartitioning with Heimdall-1.3.1 was as follows:
Code:
heimdall flash --repartition --pit <filename>
Data should be preserved and if you don't mess with the boundaries of partitions other than DATAFS, UMS and HIDDEN you should be fine. Before repartitioning I backed up all partitions as a precautionary measure, but I didn't have to restore any of them. See also http://forum.xda-developers.com/galaxy-s2/orig-development/guide-enlarge-datafs-partition-rid-t2353551
Click to expand...
Click to collapse
Ah! This is excellent, thanks for clarifying this! Just one last question if I may, how did you backup the partitions? Did you use Heimdall to download their contents as image files, did you use DD or maybe even ADB?
Thank you for your time!
GrimKriegor said:
Just one last question if I may, how did you backup the partitions? Did you use Heimdall to download their contents as image files, did you use DD or maybe even ADB?
Click to expand...
Click to collapse
Good guess, I used dd and adb. Get a shell on the phone with adb and dump the partitions to files using dd:
Code:
dd if=/dev/block/mmcblk0pX of=/sdcard/mmcblk0pX.bin bs=512
And then copy the files to your computer using adb pull. You may want to get the mountpoints of the partitions (e.g. using mount) so that you can associate them easily.
Read here for an easy way to switch to emulated storage. Thanks to @Lanchon
https://forum.xda-developers.com/galaxy-s2/orig-development/mod-switch-emulated-to-emulated-t3539651
So here's my issue. I transfered an epub file to my Nook Glowlight 3 using calibre, but when i ejected the device and started using the Nook. Not only did it not recognize my Epub file, the device slowed to a crawl! I restarted my Nook to see if this would fix the issue and now it's stuck at an infinite loading screen. I have tried hard resetting by holding the power button, but it keeps rebooting to an infinite loading screen. Could my device be possibly bricked? I think the issue might have been that I transfered a wrong type of epub file into the nook (the file was imported using calibre), which is incompatible with the nook software.
Any help would be appreciated, how do i get out of this infinite loading screen! I just want to be able to use my device again :/
Thanks.
No, it sounds like you did something else.
Do you have ADB working? Do:
Code:
# ps|grep u0 [color="red"]<- that's a zero[/color]
Do you see a bunch of processes?
That means that the Android subsystem is mostly running ok.
Is your launcher listed?
Code:
# getprop|grep bootanim
What does bn.bootanim.exit and service.bootanim.exit say?
You can disable the bootanimation entirely:
Code:
# mount -o rw,remount /system
# cd /system/bin
# mv bootanimation bootanimation.bak
# reboot
Can you start stuff?
Code:
# am start -n com.android.settings/.Settings
I'm actually having a *very* similar problem *only* when i have a 'real' launcher installed. In this case i'm using ReLaunchX, a launcher/file manager built for epaper devices. During boot the screen seems to be stuck on the boot animation. Here are some of the values from the commands you've reccomended to the OP:
Code:
[email protected]_6sl:/ $ ps|grep u0
u0_a2 2501 2080 321148 24152 ffffffff 00000000 S com.android.systemui
u0_a3 2517 2080 449348 87660 ffffffff 00000000 S com.nook.partner
u0_a0 2588 2080 319964 24852 ffffffff 00000000 S android.process.media
[email protected]_6sl:/ $ getprop|grep bootanim
[init.svc.bootanim]: [running]
[service.bootanim.exit]: [1]
[email protected]_6sl:/ $ am start -n com.android.settings/.Settings
Starting: Intent { cmp=com.android.settings/.Settings }
I have gone through the process of installing the launcher, rebooting, waiting for boot anim to finish (for up to 15-20 minutes), removing my launcher through adb, rebooting then re-installing the launcher. The launcher is the only thing that i've been chaning and it gets stuck on reboot *everytime* with the launcher installed.
P.S. I don't have root and i'm not interested in root, just the launcher and my safari queue app
If you have something taking over the Home intent, then the B&N stuff doesn't run.
The B&N stuff has the bootanimation termination hijacked.
Therefore the bootanimation will run for ever.
This will stop the bootanimation (just as a test).
Code:
$ setprop bn.bootanim.exit 1
You could write an app to do this.
You could modify the Glow3 bootanimation.
You could replace the Glow3 bootanimation with the Glow2 bootanimation.
You could delete the bootanimation.
You could write an app to do this.
You could modify the Glow3 bootanimation.
You could replace the Glow3 bootanimation with the Glow2 bootanimation.
You could delete the bootanimation.
Click to expand...
Click to collapse
Wouldn't these options require root?
Well, writing an app wouldn't need any special privilege, but it would be a round-about way to do it.
There's root & root & root. There's different degrees:
Disable all security on your normal boot image
Install a "superuser" app on your normal boot image to allow some apps to run as root
Set ro.secure to 0 to allow root ADB access
Set ro.debuggable to 1 to allow ADB to reconnect as root
Use a rooted recovery image to allow modification of your normal boot image
Load a rooted image over fastboot to allow modification of your normal boot image
Use the hardware root console that's already inside the Nook case
I wouldn't do #1, #2.
The other options don't really undermine security.
#7 requires opening the case.
Renate NST said:
[*]Set ro.secure to 0 to allow root ADB access
[*]Set ro.debuggable to 1 to allow ADB to reconnect as root
Click to expand...
Click to collapse
Hi Renate! I've tried to set these settings on a Glowlight 3, but as they don't seem to have effect might they require a pre-existing root to run them?
Code:
DESKTOP:~$ adb shell
[email protected]_6sl:/ $ setprop ro.secure 0
[email protected]_6sl:/ $ setprop ro.debuggable 1
[email protected]_6sl:/ $ mount -o rw,remount /system
mount: Operation not permitted
255|[email protected]_6sl:/ $
And just for good measure:
Code:
DESKTOP:~$ adb shell
[email protected]_6sl:/ $ su
/system/bin/sh: su: not found
Thank you for pointing me in any direction.
dotancohen said:
I've tried to set these settings on a Glowlight 3, but as they don't seem to have effect...
Click to expand...
Click to collapse
All the "ro.whatever" properties are read-only. They can only be set once.
They are usually already set in init.rc, default.prop or /system/build.prop.
ro.secure is in default.prop which is packed in the ramdisk of the image.
To modify it manually (vs. whatever scripts some people use), you need to pull the image, extract default.prop, text edit it, replace it, push the image.
Renate NST said:
To modify it manually (vs. whatever scripts some people use), you need to pull the image, extract default.prop, text edit it, replace it, push the image.
Click to expand...
Click to collapse
Thank you, I will try to pull and push the files directly. Have a great week!
This all started out in a Glowlight 4 (7.8", 2019) thread: https://forum.xda-developers.com/nook-touch/general/glowlight-plus-7-8-2019-t3934677
An SD card was soldered to test points on the circuit board of a Glow4 to allow for extra storage.
Since it looks like this same technique should work on Glow2 & Glow3 I've broken the thread out here.
The Glow4 has test points labelled by function and has been tested and proven to work with SD cards.
http://www.temblast.com/blogs/glow4/blog.htm#sdcard
The Glow3 has test points labelled by function and has not yet been tested.
The Glow2 has test points, but they are not labelled by function.
I will try to "wiggle" out the pinout soon.
Since the only difference between the models will only be wiring, I suspect that the bulk of this thread will be on configuration and use.
I wiggled the Glow2, the pinout for SD2 is:
TP159 D0
TP160 D1
TP161 D2
TP162 D3
TP163 Cmd
TP164 Clk
TP165 /CD
TP165 VDD
TP167 Gnd
The Glow3, while it's labelled, seems to be on SD3, which is not configured.
I'm still looking at this.
Thanks! I look forward learning more about mounting the sdcard and editing fstab etc.
One more question: Does this method have any restriction on the size of the sdcard and how it's formated? Many old(er) android devices with external storage can only take sdcard of size up to 32Gb, and (independent of that) sometimes people are told to format the sdcard using the device itself, but other times we're suppose to format it in advance (fat32? ext4?).
THANKS!
case-sensitive said:
Does this method have any restriction on the size of the sdcard and how it's formated?
Click to expand...
Click to collapse
This is not so much a method as simply putting in an option that they couldn't be bothered with.
I don't have anything bigger than 16GB on hand.
32GB is the limit for SD 2.0 spec.
Most of the 4GB to 16 GB cards that I have tried are SD 3.0 spec.
You can see this with mmcinfo in uboot.
Formatting things VFAT is only useful if you want to use UMS.
I wouldn't recommend that, VFAT is old and stupid and there are issues with timezones on timestamps.
ext2 is kind of the logical choice.
mkfs.ext2 is included in busybox for formatting.
TLDR: This works on the Glow2 & Glow4 relatively easily.
On the Glow3 you'd need to sacrifice the WiFi to make it work. This works on the Glow3, but you need a modified kernel and a hwcfg change.
http://www.temblast.com/blogs/glow2/blog.htm
http://www.temblast.com/blogs/glow3/blog.htm
http://www.temblast.com/blogs/glow4/blog.htm
Apparently there is already a default place for external SD cards: /mnt/media_rw/extsd
This has a link from /storage/extsd
Since the directory already exists you don't need to modify /init.rc
If you want to use vfat formatted disks and have them hot swappable you don't even have to modify /fstab.E70Q50
My choice is to use an ext2 formatted disk and since it will be internal and not swappable, I don't need or want vold, the volume daemon.
You need to tweak /fstab.E70Q50 (get rid of any line that mentions "extsd").
Code:
/dev/block/mmcblk1p1 /mnt/media_rw/extsd ext2 defaults defaults
You can split the SD card into separate partitions if you want.
You'd have to add some more entries in /fstab.E70Q50 and some mkdirs in /init.rc
For partitioning/formatting cards:
Code:
# busybox fdisk /dev/block/mmcblk1
d [color=red]<-- delete partition[/color]
n [color=red]<-- new partition[/color]
w [color=red]<-- actually write the changes[/color]
#busybox mkfs.ext2 /dev/block/mmcblk1p1
Be very careful when you are talking about mmcblk? and mmcblk?p?
case-sensitive said:
Many old(er) android devices with external storage can only take sdcard of size up to 32Gb...
Click to expand...
Click to collapse
Code:
[email protected]_6sl:/ # df
Filesystem Size Used Free Blksize
...
/mnt/media_rw/extsd 114.4G 20.0K 114.4G 4096
...
[email protected]_6sl:/ # mount
...
/dev/block/mmcblk1p1 /mnt/media_rw/extsd ext2 rw,relatime,errors=continue 0 0
On the Glow2 I ran into a hiccup.
I soldered some 30 gauge wire directly to the micro SD card.
The SD2 is there and fine, but the NtxHwCfg (at least on mine) had to be patched.
Code:
# dd if=/dev/block/mmcblk0 of=/sdcard/hwcfg skip=1024 count=1
This will get you a 512 byte file.
Look at the byte at hex address 0x4f
For the SD card to work this value must be 0x02 (it was 0x00 on mine)
Be very careful modifying the file and writing it back to the internal SD:
Code:
# dd if=/sdcard/hwcfg of=/dev/block/mmcblk0 seek=1024 count=1
Hey! It says "skip" in the first example and "seek" in the second. I warned you!
Well, more sloppiness on NTX/B&N's part.
*.rc files are organized by board names
Usually they shovel the files into the ramdisk.
This means that you have bunches of useless files that aren't used by your hardware.
The Glow2 is a E60QD0 board, the Glow3 is a E60QQ0 board, the Glow4 is a E70Q50 board.
The init.<board>.rc file should load the fstab.<sameboard> file.
On the Glow2 (at least mine) they did sloppy copy/paste and the init.E60QD0.rc loads fstab.E60Q50
I edited init.E60QD0.rc to load fstab.E60QD0
(Then made sure that fstab.E60QD0 had the correct contents.)
Likewise, init.<board>.usb.rc is sloppy.
They don't use the approved syntax of ${ro.serialno}, but instead use $ro.serialno
I get tired of the warnings in the console log.
Also, a lot of redundant junk (the VID/PID stuff can be moved to the "on boot" section).
If you are using a Glow2 and you just installed the 5.0 update and you had previously modified the hwcfg,
then you will have to set it back to the original version to allow the added SD card to work properly.
See: https://forum.xda-developers.com/showpost.php?p=80114208&postcount=623
I had previously said that an SD card and WiFi were not compatible on the Glow3.
It turns out that it's a bit more complicated.
SD2 is the WiFi interface.
SD3 goes to the test points.
The software currently has the WiFi enable/disable switching the SD3 interface, which is wrong.
I've got the hardware itself working
Code:
eBR-1A # mmcinfo
Device: FSL_USDHC
Manufacturer ID: 27
OEM: 5048
Name: SD32G
Tran Speed: 25000000
Rd Block Len: 512
SD version 3.0
Clock: 50000000
High Capacity: Yes
Capacity: 31104958464 Bytes
Bus Width: 4-bit
Boot Partition for boot: No boot partition available
Now I just have to fix the software.
Ok, so I've patched the kernel to make this work on the Glow3.
This also needs a change to the ntxcfg. You can do that with dd or some other tool.
Is anybody ready for this? Do you have the soldering iron warmed up?
Code:
/mnt/media_rw/extsd 28.5G 20.0K 28.5G 4096
I've got to make a version of the image without my stuff in it.
I usually don't like heavily modded images.
The one thing I put in is a rooted adbd.
So, who's ready for the glow3?
You need a new kernel.
If you have access to fastboot you can test drive it with "fastboot boot p1mod.img".
Later you can "fastboot flash boot p1mod.img" to make it permanent.
If you don't (and you're brave and have a good recovery) you can "dd if=p1mod.img of=/dev/block/mmcblk0p1"
You will need to patch the NTX hwcfg.
If this is patched but you are still running the old kernel the WiFi will probably not work, but the glow3 will still be functional.
Code:
# dd if=/dev/block/mmcblk0 skip=1024 count=1 of=/sdcard/hwcfg
[color=red]Use your favorite hex file editor either on of off the glow3 to change address 0x4f from 0x02 to 0x00.
modfile hwcfg 4f 00[/color]
# dd if=/sdcard/hwcfg seek=1024 count=1 of=/dev/block/mmcblk0
If you have access to the u-boot command line you can do it there instead:
Code:
eBR-1A # mmc read 910000 400 1
MMC read: dev # 0, block # 1024, count 1 ... 1 blocks read: OK
eBR-1A # mm.b 91004f
0091004f: 02 ? 00
00910050: 01 ? q
eBR-1A # mmc write 910000 400 1
MMC write: dev # 0, block # 1024, count 1 ... 1 blocks write: OK
eBR-1A #
So, if you get through with all this and reboot it should boot up just fine.
There is a rooted adbd in there so that should not be a problem.
The fstab has been modified to mount your new SD card.
Since that is probably still the original filesystem it will not mount correctly.
You can do an "ls -l /dev/block" and see both mmcblk1 and mmcblk1p1.
You probably noticed that your old /sdcard is empty.
This is an artifact of the fstab not finishing and therefore the nonencrypted is not triggered nor the late_start.
Just do a "start sdcard" and the /sdcard will populate.
So now, just do a "busybox fdisk /dev/block/mmcblk1" to repartition and a "busybox mke2fs /dev/block/mmcblk1p1".
The fstab presumes ext2, a reasonable choice for something used as big storage. If not, just change it.
Reboot and everything should be good.
Good luck.
I've been talking about the NTX hardware configuration, but I don't think that I mentioned or released the utility that I use to dump it.
Availible in the signature, there is NtxHwCfg which can dump or compare NTX configurations.
There is a version for Win32 and one for Android.
http://www.temblast.com/android.htm
It's interesting that the B&N updates don't modify the NTX config.
The Glow2 has version 2.5 vs. the Glow3 with 2.8 vs. the Glow4 with 3.1!
So that means that the u-boots all have to be different.
Code:
C:\>ntxhwcfg hwcfg3 hwcfg4
0b Version 2.8 3.1
0f Size 65 70
10 PCB E60QQ0 (69) E70Q50 (84)
12 AudioCodec No (0) ALC5672 (6)
14 Wifi RTL8189 (8) RTL8723DS (14)
15 BT No (0) RTL8723DS (8)
17 TouchCtrl neonode_v2 (8) ektf2132 (9)
...