[nchntrman]

Here is how I see this happening.Repartition internal microSD in my case 8G.partition1 - 7G Fat32partition2 - 1G (linux compatible file system, ext2? yaffs?)format accordinglymount the partition under adb shell sumount ext2 /dev/block/mmcblk1p2 /datasd nosuid nodevcopy /data to /datasdmodify the comparable file to init.conf (standard andriod boot file) i believe this to bt init.rc, however after looking at the contents it appears that init.rc might be the initial setup script not one that is run every boot, none the less within the correct file is something similar to:mount yaffs2 [email protected] /data nosuid nodevchange this to mount ext2 /dev/block/mmcblk1p2 /data nosuid nodevmounting root of the internal SD 's 2nd partition at /datathis should essentially remap the /data to a larger area on the internal microSD.I will try this tomorrow, but if anyone with more experience would care to critique or provide suggestions they are more than welcome

 

[nchntrman]

I made a little progress.I am first trying to use the default partitioning/format of the internal SD.After remounting /PD_Novel in adb shell : # mount -w -t vfat /dev/block/mmcblk1p1 /PD_NovelI was able to #mkdir /PD_Novel/dataI knew I would need to copy an entire directory and subs from within adb shell and android does not have the cp command.I followed the thread on busybox and was able to install it and access it from adb shell, this made copying my /data to /PD_Novel/data much easier. #busybox cp -a /data /PD_Novel/dataI am trying to replace the init.rc with a modified one. The file resides in / (root) First I remounted root as rewritable #mount -o remount,rw / /After exiting adb shell I was able to push my new init.rc to root. >adb push init2.rc /init.rcThen I pulled the file to ensure it was the changed file.After rebooting to see if the new init.rc worked, it did not. Pulling the current init.rc and viewing showed it has reverted back to the original file.I suppose that / (root) is restored from an archived version as part of the boot process.Another challenge

 

[clockworx]

I believe that those scripts are all part of ramdisk.img.Rip 64 bytes off the top, gunzip(I think...going from memory here), and cpio to extract. Make your edits, then reverse (cpio, then gzip). push over and do "flash_image ramdisk my_new_image.img"Usual disclaimer, which I'm sure you know.

 

[nchntrman]

can I build an image of ramdisk.img? using mkfs.yaffs and plug it into a firmware flash? or are they the encrypted or otherwise special.img format?will messing up the ramdisk.img affect ability to flashfirmware?

 

[nchntrman]

grr.. so if I only have a Windows box, then how should I strip off header and will Windows binary gpio work (is universal) ?Would it be easier to do on the novel through adb shell?

 

[clockworx]

I used xvi32 to strip it off under windows, (block mark 64 chars, block delete, save). 7zip will open the cpio and gz, the only problem is it won't re-cpio. Depending on how big your change is, you can extract the ramdisk (still in cpio format, don't extract it), open it in xvi32, search for the string of where you want to edit, and edit it in binary form. I did that once before to do some really simple edits to an init script.

 

[nchntrman]

the change will be changing one line mount device and path in the init.rc file. I found a windows binary of cpio, ill try that, what about merging the 64chars back after the re rz?

 

[clockworx]

You don't want the 64 byte header if you use flash_image.

 

[nchntrman]

But: I do if I replace the image in the firmware.zips?

 

[clockworx]

yes. But it has to be rebuilt since it contains CRC's, you can't just C+P it. Alternately, I believe "flash_image" should be available as a command in recovery mode. Not sure.

 

[nchntrman]

crc internal to the file, not for the final ramdisk.img? I did not get my windows version of cpio.exe to unpack the ramdisk.img and 7zip only works readmode. More research to do I suppose. Maybe I will find a way to do the mount/remount another way than with init.rc, maybe after the ramdisk has loaded with a system script.

 

[nchntrman]

What about mounting the actual ramdisk memory location as -rw and updating the init.rc? The on next reboot the new file should be there when ramdisk is mounted to root. Safe until ramdisk.img is reflashed on a firmware update.

 

[nchntrman]

Ok it looks like this is the way to go, I found some examples of others who have it working on a few phones. I will need to track down a few resources including ext2.ko (kernel module) maybe a gparted that can run on the novel, mkfs.arm and a few others.Any opinions as to the best location to put apps? It is either the internal or external SD, I am leaning more towards the internal microSD maybe a 512M-1G partition with the balance as PD_Novel.

 

[HWgeek]

I would suggest the internal microSD, since right now it can't be used for book storage if you don't use PD software, so its essentially open space. Any reason you can't set up the partition as yaffs2 instead of ext2??? why add in another partition style??

 

[clockworx]

I'd say internal as well. Less likelihood that someone will be a moron and accidentally yank the internal SD during normal operation

 

[nchntrman]

[quote name='HWgeek;48637]I would suggest the internal microSD' date=' since right now it can't be used for book storage if you don't use PD software, so its essentially open space. Any reason you can't set up the partition as yaffs2 instead of ext2??? why add in another partition style??[/QUOTE'] I believe that yaffs2 is designed for Flash Memory physical hardware, i.e. pages of memory address. I do not think that you can format SD memory chip like that (if anyone knows otherwise please chime in). Fat32 cannot do the permissions required (as far as I know they are required) that leaves ext2 to ext4 (the later being used in the cell phone mods). From what I have seen the easiest way will be to get unionFS (arm compatable) and mkfs.ext2 (arm compatable) up and running on the Novel. Or without unionFS and remap it to the new location. I like the idea of unionFS it seems to handel problems better than other symlink or remapping methods.

 

[HWgeek]

Yes you are right, I had a moment there... since sd cards have nand in them, but have hardware based wear leveling. duh. But in refreshing and googling there was some good info on xda-developers (google "yaffs2 sdcard" or try "yaffs instead of ext3") : YAFFS instead of Ext2, Ext3, Ext4 - Page 2 - xda-developersThere was some interesting data on fs speeds (xfs vs ext3 vs nilfs etc)