It would still make sense to see if there is /dev/block/mmcblk1 device node. Seeing mmcblk1 in kernel log is not enough, there needs to be device node in filesystem too.
[WIP] Booting NST from the sd card
- Thread starter probbiethe1
- Start date
It would still make sense to see if there is /dev/block/mmcblk1 device node. Seeing mmcblk1 in kernel log is not enough, there needs to be device node in filesystem too.
I have been messing around with stuff just seeing what I could find out and I might be going crazy but it looks to me like cwm recovery runs off the sd card http://xdaforums.com/showthread.php?t=1360994 If that is the case i wonder if the files from cwm could be modded to run a full rom from the sd card
I have been doing some of my own testing and using klausef words of advice I made a complete back up image of my nook simple touch. I then wrote it to an sd card and changed the booting images so I could tell if the nook was booting from the card. Well it appears that my nook boots from the sd card through the boot images but then after that it starts up the internal memory. The way i tested this is I changed my background with the sd card out and then when I put the sd card back in it the background was changed to what it was with out the sd card.
Does any one have any tips/ideas on how to get the nook simple touch to boot all the way from the sd card?
Does any one have any tips/ideas on how to get the nook simple touch to boot all the way from the sd card?
Ok bolakes and boardeys:
There is some reason that the device does not want to boot to any userland, save the one on the embedded MMC.
We can see that the kernel detects the external MicroSD card very early on in the boot process [See my dmesg paste]. Through what fanoush mentioned, I assume that the issue is because the SD cards' device nodes don't get created in /dev/block/. (This is a conjecture).
To alleviate this, we must investigate how the Nook's kernel creates device nodes. There's a number of ways the kernel could do this:
1) udev -- We know the kernel probably doesn't use the udev subsystem because it hardly shows up anywhere
2) MAKEDEV script -- Before udev existed, people used a script called 'MAKEDEV' that called the 'mknod' command to manually create device nodes. It was ugly and hacky, which was why udev was eventually developed. This script is nonexistent, as far as I know, in the uRamdisk which is all the kernel has access to initially after booting.
3) Device nodes are 'hardcoded in the kernel' -- It's looking to me that this is the most likely method the Nook is using. Wow, I have no idea why they would have done something this inelegant.
Check out the file: kernel/drivers/mmc/card/block.c
Also interesting: Documentation/emmc_fat_boot.txt (Basically describes how to modify kernels so that they boot from internal MMC, this may be the guide the Nook team followed)
At any rate, this little train of thought led me to find a config option 'MMC_OMAP_CONSISTENT_NAMES' documented in 'kernel/arch/arm/mach-omap2/Kconfig':
Lo and behold, checking the config we've been compiling with (omap3621_gossamer_evt1 or whatever) has this option set to Y. Changing it to 'n' and compiling the kernel changes the SD card's device name to mmcblk0, and the nook ends up booting to it instead. Just like we want.
I'm trying it right now.
---
EDIT: looks like it trys to boot from the uRecImage and uRecRam now since it shows the 'Install Failed' screen...
There is some reason that the device does not want to boot to any userland, save the one on the embedded MMC.
We can see that the kernel detects the external MicroSD card very early on in the boot process [See my dmesg paste]. Through what fanoush mentioned, I assume that the issue is because the SD cards' device nodes don't get created in /dev/block/. (This is a conjecture).
To alleviate this, we must investigate how the Nook's kernel creates device nodes. There's a number of ways the kernel could do this:
1) udev -- We know the kernel probably doesn't use the udev subsystem because it hardly shows up anywhere
2) MAKEDEV script -- Before udev existed, people used a script called 'MAKEDEV' that called the 'mknod' command to manually create device nodes. It was ugly and hacky, which was why udev was eventually developed. This script is nonexistent, as far as I know, in the uRamdisk which is all the kernel has access to initially after booting.
3) Device nodes are 'hardcoded in the kernel' -- It's looking to me that this is the most likely method the Nook is using. Wow, I have no idea why they would have done something this inelegant.
Check out the file: kernel/drivers/mmc/card/block.c
Also interesting: Documentation/emmc_fat_boot.txt (Basically describes how to modify kernels so that they boot from internal MMC, this may be the guide the Nook team followed)
At any rate, this little train of thought led me to find a config option 'MMC_OMAP_CONSISTENT_NAMES' documented in 'kernel/arch/arm/mach-omap2/Kconfig':
Code:
config MMC_OMAP_CONSISTENT_NAMES
bool "Consistent naming of MMC devices"
depends on MMC_OMAP || MMC_OMAP_MODULE || MMC_OMAP_HS || MMC_OMAP_HS_MODULE
default "n"
help
Say Y here if you want the internal and external SD/MMC devices to
have dependable device names on every boot. When N, the internal MMC
will be called either mmcblk0 or mmcblk1 depending on whether or not
an external card is present. If unsure, say Y.Lo and behold, checking the config we've been compiling with (omap3621_gossamer_evt1 or whatever) has this option set to Y. Changing it to 'n' and compiling the kernel changes the SD card's device name to mmcblk0, and the nook ends up booting to it instead. Just like we want.
I'm trying it right now.
---
EDIT: looks like it trys to boot from the uRecImage and uRecRam now since it shows the 'Install Failed' screen...
Last edited:
If I get it right (from bool "Consistent naming of MMC devices")
N:
1. No external present during boot:
Internal - mmcblk0
2. External present during boot:
external mmcblk0, internal - mmcblk0
Y:
Internal - mmcblk0, external mmcblk1 always
"N" behavior works just fine to boot from SD.
But for "Y" in your experiments, you don’t see external as mmcblk1 during boot, correct?
N:
1. No external present during boot:
Internal - mmcblk0
2. External present during boot:
external mmcblk0, internal - mmcblk0
Y:
Internal - mmcblk0, external mmcblk1 always
"N" behavior works just fine to boot from SD.
But for "Y" in your experiments, you don’t see external as mmcblk1 during boot, correct?
Did it work?
Actually yes, I do see the external as mmcblk1 using 'Y'
I tried it and for some reason it wants to boot to the recovery image (it shows the 'install failed' screen). Renaming the new image uRecImg hangs the boot process (surprise!) but further experimentation is required. I also tried varying the init.rc in the uRamdisk to mount mmcblk1, to no avail. (Not sure why that would have worked, anyway...)
---
Mmkay it works now. I burned an image of the internal memory onto the SD card, then replaced the kernel with the one with that one flag set differently. I used the stock uRamdisk. I copied all of the .bin files from the nooter image, overwriting the old u-boot configurations. Attached are my uImage and all the things I copied over. Just paste all that into your SD card's boot partition and it should work.
When it boots, it displays the nooter instructions screen, then switches to the nook boot animation. Clearly this is not ideal and I or someone else down the road will have to bite the bullet and actually remake uBoot. (^;
Performance is horrible; it made me somewhat depressed. Immediately after booting you are greeted with a boatload of 'Not responding' notifications. If you choose 'wait' on too many of these then the nook will freeze (or something?) and you will be thrown back to the boot animation for a brief period before the screen locks. Unlocking the screen also takes quite a while longer than it normally would.
At any rate, I left the system up just long enough so that I could establish some checks to show us that it was indeed running completely off the SD card, and it was.
I guess there are two major things we can do to improve our current situation:
1) Make the system less dependent on swap and whatnot so it doesn't hit the disk as hard, make more stuff run off of what little RAM we have.
2) Rebuild U Boot for this usage case.
If that didn't make sense to you I'll write up a guide on how to do it start to finish Here
I tried it and for some reason it wants to boot to the recovery image (it shows the 'install failed' screen). Renaming the new image uRecImg hangs the boot process (surprise!) but further experimentation is required. I also tried varying the init.rc in the uRamdisk to mount mmcblk1, to no avail. (Not sure why that would have worked, anyway...)
---
Mmkay it works now. I burned an image of the internal memory onto the SD card, then replaced the kernel with the one with that one flag set differently. I used the stock uRamdisk. I copied all of the .bin files from the nooter image, overwriting the old u-boot configurations. Attached are my uImage and all the things I copied over. Just paste all that into your SD card's boot partition and it should work.
When it boots, it displays the nooter instructions screen, then switches to the nook boot animation. Clearly this is not ideal and I or someone else down the road will have to bite the bullet and actually remake uBoot. (^;
Performance is horrible; it made me somewhat depressed. Immediately after booting you are greeted with a boatload of 'Not responding' notifications. If you choose 'wait' on too many of these then the nook will freeze (or something?) and you will be thrown back to the boot animation for a brief period before the screen locks. Unlocking the screen also takes quite a while longer than it normally would.
At any rate, I left the system up just long enough so that I could establish some checks to show us that it was indeed running completely off the SD card, and it was.
I guess there are two major things we can do to improve our current situation:
1) Make the system less dependent on swap and whatnot so it doesn't hit the disk as hard, make more stuff run off of what little RAM we have.
2) Rebuild U Boot for this usage case.
If that didn't make sense to you I'll write up a guide on how to do it start to finish Here
Last edited:
Nice, will try it when I find some time.
The nooter instrunctions should just be the booting.pgm picture. If you keep the one from the boot partition it should be fine.
Afaik there is no swap enabled.
I followed klausef steps and made a backup img then copied over the files that we so kindly shared and my simple touch is now running off the sd card!!
I havent seen any lag like klausef but I have changed the background and added some app shortcuts to the home screen and when I take the card out it is different so I know it is running off the sd card.
Thanks klausef for all your work and helping me with this. It is great I cant wait to see how far it goes.
I havent seen any lag like klausef but I have changed the background and added some app shortcuts to the home screen and when I take the card out it is different so I know it is running off the sd card.
Thanks klausef for all your work and helping me with this. It is great I cant wait to see how far it goes.
This thread may die if it is moved to the general discussion forum.
Please look this thread over and consider moving it back to the development forum; it has clearly evolved into a development thread.
Cheers
Last edited:
I am loving my bootable sd card and having been messing around with it most of the day.
One thing though is there a way to partition the sd card so the nook will see the partition as the sd card? Right now when i try to download something it doesnt see an sd card.
One thing though is there a way to partition the sd card so the nook will see the partition as the sd card? Right now when i try to download something it doesnt see an sd card.
Yeah I am loving my bootable sd card but still cant figure out how to partition the sd card so part of it will show up as an sd card to the nook. Also I have been trying to change the booting.pgm to a different boot image but just copying and pasting over another pgm is not working for me.
Oh, so there isn't; `free` returns 0 bytes dedicated to swap. I need to source my comments a bit more thoroughly
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.
2. Are you able to mount the new partition in nook?
3. If yes, mount setting for sdcard seems to be stored in /system/etc/vold.conf
Code:
## vold configuration file for zoom2
# modified for encore
volume_sdcard {
## This is the direct uevent device path to the SD slot on the device
media_path /devices/platform/mmci-omap-hs.1/mmc_host/mmc0
partition 6
media_type mmc
##mount_point /sdcard
mount_point /media
ums_path /devices/platform/usb_mass_storage/lun0
}
volume_sdcard2 {
## Currently points to internal eMMC, assumes eMMC is formatted as FAT32
media_path /devices/platform/mmci-omap-hs.0/mmc_host/mmc1
media_type mmc
##mount_point /media
mount_point /sdcard
ums_path /devices/platform/usb_mass_storage/lun1
}Thats because the mounted sdcard is mounted as
Code:
/dev/block//vold/179:17 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0Maybe it would be possible to update vold.conf with correct patch to new partition and let him mount it.
Wow, this seems to have gone really far. Awesome! I just got a new Sandisk 16GB uSD, and my Nook has a broken screen, so if anyone wants to send me experimental kernels or anything that might possibly brick the thing entirely for the sake of experimentation, I'd be happy to sacrifice my already useless Nook. Only the top 1/4 of the screen actually updates, but I can use ADB to get a look at the screen. Now time to try this for myself...
Renate
Recognized Contributor / Inactive Recognized Dev
Have you tried editing /system/build.prop?
Code:
ro.sf.widthpixels=600
ro.sf.heightpixels=800Maybe changing the height to 200 pixels would get you a functioning 1/4 screen?
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
2
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...1Forgive 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
You can easily unpack/edit/pack URamdisk
mali100 explained everything and posted scripts here. I’m reposting his scripts below:
Unpack (xuramdisk)
pack (mkuramdisk)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
Code:#!/bin/bash find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk1I 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
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.
