[WIP] Booting NST from the sd card

Search This thread

Googie2149

Senior Member
Jan 6, 2012
291
54
Have you tried editing /system/build.prop?

Code:
ro.sf.widthpixels=600
ro.sf.heightpixels=800

Maybe changing the height to 200 pixels would get you a functioning 1/4 screen?

Maybe. Now I just need to remember how to get to that... Doesn't CWR have USB ADB? Also, I attached a picture of my Nook.

Edit: I can't seem to find any of my old uSD cards that I always used. Would it cause any problems to use a new Sandisk 16GB Class 6?
 
Last edited:

Googie2149

Senior Member
Jan 6, 2012
291
54
Oops, you really busticated your screen.
How about trying to get a USB VGA adapter going?

Meh, maybe some day. Currently I'm planning on replacing this with a Nook Color, but I'll probably work on that at some point. These things are fun to toy with! Also, if I could somehow get a VGA adapter working, I think we also need to get a mouse working just to make this a bit more viable.
 

GabrialDestruir

Senior Member
Nov 12, 2009
650
514
California
I haven't really looked through all this, but felt I'd cover the basics of fully booting from SD. I have done this before (not on the touch specifically).

The basics is, only uRamdisk matters initially. You have to unpack it and modify the mount points, which seems to have been figured out already.

The second part is the vold.conf it needs to be modified to mount your "media" partition on the SDCard and also your "Media" on your emmc (if you want both).
(Seems this is covered a few posts back)



However if you mount the emmc as the sdcard as opposed to the "built-in" media, there's a chance you might end up formatting your emmc if you ever use the Format for SDCard, I remember I had this done for the Nook Color and the format button and it completely wiped the SDCard, so that might be hard coded and unaffected by vold.conf, it'd be something to test if you're willing to risk it.

A few other things to keep in mind when doing this, if you deregister either the sdcard or the actual emmc, the other one will end up forcefully deregistered if it syncs with BN. This may deregister both if you by chance deregistered and reregistered then tried to use it... so basically, always keep a clone of such changes you make to one so you can apply it to both.

Anyways I think that's about it, have fun.
 
Last edited:

probbiethe1

Senior Member
Mar 22, 2010
320
8
Hi, unfortunately I do not have sdcard that would let me to fit whole system but let me know it following would work (only assumptions baseod on my observations of the system:

1. Are you able to create additional FAT32 partition on sdcard after flashing the nook image? I believe this should be possible but I am not sure whether the nook would still be able to boot and work properly.

I was able to make another fat32 partition that was about 5gb on an 8gb card but i wasnt able to get it to mount but it still booted from the sdcard just fine.
 

probbiethe1

Senior Member
Mar 22, 2010
320
8
I was able to deregister my sd card with out it having any affect on the internal memory of the nook.

I am still trying to figure out a way to mount a partition as the sd card so things can be saved but I havent had anhy success yet.
 

GabrialDestruir

Senior Member
Nov 12, 2009
650
514
California
I was able to deregister my sd card with out it having any affect on the internal memory of the nook.

I am still trying to figure out a way to mount a partition as the sd card so things can be saved but I havent had anhy success yet.

Have you tried syncing with B&N on the internal after deregistering? This is usually the cause of forced deregistering because B&N's servers no longer have the device in their records, or/and because the device's registration number changed.
 

probbiethe1

Senior Member
Mar 22, 2010
320
8
Have you tried syncing with B&N on the internal after deregistering? This is usually the cause of forced deregistering because B&N's servers no longer have the device in their records, or/and because the device's registration number changed.

No i havent tried reregistoring the card and to tell you the truth I dont know how to. I dont use barnes and noble for anything so once its passed the initial setup and i deregistor I dont know how to reregistor.
 

probbiethe1

Senior Member
Mar 22, 2010
320
8
I am still working on trying to get the NST to see one of the partitions as the sd card. Here is what I have tried so far.

I have created a new fat32 partition to be the sd card I then try to change the mount point through linux but I must not have the right program or something because I can never get it to work.

I have also tried using rom toolbox to edit the void file and I can edit it but it never saves the changes. It says the changes are saved but when I go back in and check the settings are back to normal.

So any suggestions on how to change the mount point for a partition would be great. And thanks for all of the help so far
 

klausef

Senior Member
Jul 17, 2011
57
31
Raleigh
Want to know a silly hack?

'Mount' the personal files directory to where the SD card would go:

Code:
mount -o bind /media /sdcard
 

probbiethe1

Senior Member
Mar 22, 2010
320
8
I am still trying to get the NST to see a partition as a sdcard but I am having tons of issues with it. I got it to mount one of the partitions at /media/sdcard_ but I dont know where the underscore came from. Any ideas would be greatly appreciated.
 

probbiethe1

Senior Member
Mar 22, 2010
320
8
I am also trying to do this same thing for the NST Glow Light but am running into an issue with editing the boot sequence.
 

klausef

Senior Member
Jul 17, 2011
57
31
Raleigh
Want to know a silly hack?

'Mount' the personal files directory to where the SD card would go:

Code:
mount -o bind /media /sdcard

The hack for mounting a fake SD card from a booted SD card system is really fake, some programs like Opera see through it by checking an environmental var. This could be avoided if someone wrote an app to set the environmental variable
Code:
'EXTERNAL_STORAGE_STATE'
to 'MEDIA_MOUNTED' or something, possibly using:
Code:
System.setProperty('property_name', 'value');

Once I get time I might hash up a simple app that toggles faking the SD card by `mount -o bind` in conjunction with this. Feel free to beat me to doing this, anyone; Java is not my forte...
 

yumbrad

Member
Jan 24, 2012
13
5
The hack for mounting a fake SD card from a booted SD card system is really fake, some programs like Opera see through it by checking an environmental var. This could be avoided if someone wrote an app to set the environmental variable
Code:
'EXTERNAL_STORAGE_STATE'
to 'MEDIA_MOUNTED' or something, possibly using:
Code:
System.setProperty('property_name', 'value');

Once I get time I might hash up a simple app that toggles faking the SD card by `mount -o bind` in conjunction with this. Feel free to beat me to doing this, anyone; Java is not my forte...

I found programs saw through the bind mount as well... This worked for me, though:

1. mount -o bind /media /sdcard
2. setprop EXTERNAL_STORAGE_STATE mounted
3. am broadcast -a android.intent.action.MEDIA_MOUNTED --ez read-write false -d file:///sdcard

You could put this in your init.rc or rc.local if you'd like it to happen at start up...
 

klausef

Senior Member
Jul 17, 2011
57
31
Raleigh
I found programs saw through the bind mount as well... This worked for me, though:

1. mount -o bind /media /sdcard
2. setprop EXTERNAL_STORAGE_STATE mounted
3. am broadcast -a android.intent.action.MEDIA_MOUNTED --ez read-write false -d file:///sdcard

You could put this in your init.rc or rc.local if you'd like it to happen at start up...

Yumbrad, brilliant! Thanks for the posting this. For some reason I was trying to do this through modifying Android's source. It may still be possible but there is not really a need.

If a real SD card is inserted and removed, the last two commands might need to be run again, but that is no issue. If someone has time, they could make an app to solve this. For now you could also install SManager and make a script containing these commands, put the script as a widget on your launcher, and run the script/app as needed.
 
  • Like
Reactions: P3TR

probbiethe1

Senior Member
Mar 22, 2010
320
8
I pretty much have my NST card up and running but one thing I noticed with my Glow Light card is that the mac address is always the same no matter what device i put the card into. This is not the case with my originall NST card. So I was wondering if anyone has any tips on how I could fix the mac address always being the same.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    The hack for mounting a fake SD card from a booted SD card system is really fake, some programs like Opera see through it by checking an environmental var. This could be avoided if someone wrote an app to set the environmental variable
    Code:
    'EXTERNAL_STORAGE_STATE'
    to 'MEDIA_MOUNTED' or something, possibly using:
    Code:
    System.setProperty('property_name', 'value');

    Once I get time I might hash up a simple app that toggles faking the SD card by `mount -o bind` in conjunction with this. Feel free to beat me to doing this, anyone; Java is not my forte...

    I found programs saw through the bind mount as well... This worked for me, though:

    1. mount -o bind /media /sdcard
    2. setprop EXTERNAL_STORAGE_STATE mounted
    3. am broadcast -a android.intent.action.MEDIA_MOUNTED --ez read-write false -d file:///sdcard

    You could put this in your init.rc or rc.local if you'd like it to happen at start up...
    1
    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.
    1
    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.
    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
    1
    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.
    1
    I found programs saw through the bind mount as well... This worked for me, though:

    1. mount -o bind /media /sdcard
    2. setprop EXTERNAL_STORAGE_STATE mounted
    3. am broadcast -a android.intent.action.MEDIA_MOUNTED --ez read-write false -d file:///sdcard

    You could put this in your init.rc or rc.local if you'd like it to happen at start up...

    Yumbrad, brilliant! Thanks for the posting this. For some reason I was trying to do this through modifying Android's source. It may still be possible but there is not really a need.

    If a real SD card is inserted and removed, the last two commands might need to be run again, but that is no issue. If someone has time, they could make an app to solve this. For now you could also install SManager and make a script containing these commands, put the script as a widget on your launcher, and run the script/app as needed.