Related
Here is the kernel with yaffs2 and MTD block support, I am missing some mtd util tools like nandwrite so i cannot continue. Those that have the tools like mkyaffs2image, nandwrite, flash_eraseall can try to create an image and mount it
here are the steps that i think should work:
# mknod /dev/mtd0 c 90 0
# flash_eraseall /dev/mtd0
# mkyaffs2image /data/data yaffs2.img
# nandwrite -p /dev/mtd0 yaffs2.img
# mkdir /data/data2
# mount -t yaffs2 /dev/mtdblock0 /data/data2
If you have the tools, please attach so we can continue.. Its getting late so I am going to bed, have fun
Download
yaffs2_support.tar
Oh my god! I was just about to post similar findings, what a coincidence!
I just had compiled a kernel with yaffs2 support. My idea was to modify /init.rc in the kernel to mount the partitions with yaffs2 instead of rfs. Problem: we can't just change the filesystem without backing up and restoring all the files inside. My idea was to do that inside the recovery. Mount a mountpoint, backup with tar to /sdcard, unmount, format with dd (in theory a partition filled with 0's is ok for yaffs2), mount again with yaffs2 and restore from tar.
I'm stuck at the point that I can't seem able to mount any partition with yaffs2 previously formatted (with /system/xbin/busybox dd if=/dev/zero of=/dev/block/stl10). If I mount (/system/xbin/busybox mount -t yaffs2 /dev/block/stl10 /dbdata) there is always an "Invalid argument" error. It happens with /dev/block/stl*, /dev/block/bml* and /dev/block/mmcblk*
I'm no kernel expert, neither I know a lot about yaffs2, but I think I read you can't mount a yaffs2 partition anywhere, it has to be an MTD flash device.
Anyway, I'm going to try with the tools you said. Wish me luck.
Thanks for your work rasdeep! Is it only YAFFS2 and MTD support that you added? Because the kernel already had support for EXT2 and EXT3.
darksnarfer said:
I think I read you can't mount a yaffs2 partition anywhere, it has to be an MTD flash device.
Click to expand...
Click to collapse
Does the kernel that rasdeep posted load the existng flash devices/partitions as MTD devices?
I think as a start you only have to worry about formatting the /dev/block/mmcblk0p2 device which is mapped to the /data directory. With the new lag fix we are only moving directories stored in /data and that is what gives a big performance improvement. RyanZA did tests and found that the /dbdata partition was already quite fast and I don't think we have to worry about the /system partition etc. because we don't really write to them.
I think after a new firmware flash the /dev/block/mmcblk0p2 (mounted as /data) will be safe to format into YAFFS2 without loosing anything important.
I think these are the steps we can do:
1. Flash new firmware with repartition option on to erase everything.
2. Boot into recovery and format /dev/block/mmcblk0p2 as YAFFS2 filesystem.
3. Copy on new a init.rc script which will mount /dev/block/mmcblk0p2 to /data as a YAFFS2 filesystem and not a RFS filesytem to get much faster speeds.
bub181 said:
Does the kernel that rasdeep posted load the existng flash devices/partitions as MTD devices?
Click to expand...
Click to collapse
Just checked, there isn't any /dev/block/mtd* so I guess the kernel still can't see them as mtd.
/data is on the internal SD not in NAND so will we be able to use yaffs2 at all? I was working on formatting to EXT4 and adding the init.rc to match as well as compiling with EXT4 support, but if yaffs2 works, I'm fine with that.
modifying the init.rc is secondary because that is easy.. the main problem now is to be able to manually setup yaffs2 to mount properly.. if everything works like it should, init.rc can be change in matter of seconds
its funny now u said mtd not found.. i know we can mknod /dev/mtd* but there should be /dev/mtdblock* when booting with kernel right? hmm.. something to investigate further..
keep suggestions and finding coming, we may hit something that i've missed
problem is im lacking those tools that will do write to flash directly.. for example nandwrite.. anyone has that can share so i can try more stuff?
also, are my steps for "preparing" yaffs2 partitions/image correct? if anyone familiar with yaffs, please give some insight
raspdeep said:
modifying the init.rc is secondary because that is easy..
Click to expand...
Click to collapse
Do you need to recompile the kernel to modify the init.rc? If not could you post some instructions on how to do it please? I would like to try some things in there before /data gets mounted as a RFS filesystem.
bub181 said:
Do you need to recompile the kernel to modify the init.rc? If not could you post some instructions on how to do it please? I would like to try some things in there before /data gets mounted as a RFS filesystem.
Click to expand...
Click to collapse
i'm afraid so for now until someone found a way to extract the initramfs from later kernel and restore it back after modification..
I think it would be easier to start out with EXT2 since we can easily format that. Just as a proof of concept. I'm planning to do so tonight. Then I'll add support for EXT4 formatting and try that.
raspdeep said:
problem is im lacking those tools that will do write to flash directly.. for example nandwrite.. anyone has that can share so i can try more stuff?
Click to expand...
Click to collapse
Have you seen these pages rasdeep? They seem to describe how to create the YAFFS filesystem. Also, are there any /dev/mtdblock* devices using the kernel that you created? According to what I read elsewhere it is supposed to create both /dev/mtd* and /dev/mtdblock*. I think we have to use /dev/mtdblock* to create the new filesystem.
http://processors.wiki.ti.com/index.php/Create_a_YAFFS_Target_Image
http://processors.wiki.ti.com/index.php/MTD_Utilities
http://processors.wiki.ti.com/index.php/Put_YAFFS_Image_to_Flash
Also, I know that the Nexus One uses YAFFS2 for its internal filesystem. Maybe someone has worked out a way to write a new image file for that and we can use what they have learnt?
Can we potentially use this kernal (with the right tools) to format the NAND in YAFFS2 instead of RFS? Then still have way of flashing firmware onto it?
If so, that would be awesome and it would seem to have the least draw backs.
Currently the A2SD lag fix requires an external microsd card, and the one click lag fix, mounts a EXT2 image ontop of the RFS NAND, and that could drastically affect NAND life.
This is great !!!
Thank you raspdeep and all the devs here, this is one step closer to a stable kernel and a permanent genuine solution for the lag problem as far as a n00b like me understands
cheers !
Daemos said:
Can we potentially use this kernal (with the right tools) to format the NAND in YAFFS2 instead of RFS? Then still have way of flashing firmware onto it?
If so, that would be awesome and it would seem to have the least draw backs.
Click to expand...
Click to collapse
Not if we can't mount the NAND as a MTD-device instead of STL-device.
Daemos said:
Currently the A2SD lag fix requires an external microsd card, and the one click lag fix, mounts a EXT2 image ontop of the RFS NAND, and that could drastically affect NAND life.
Click to expand...
Click to collapse
Say what? /data/ is mounted on the internal SSD, not the NAND. /dbdata/ is however mounted on the NAND. Just do a df -h and you can see all the mountpoints.
Also, mounting and using a ext2-image that reside on an rfs-partition will not damage your drive. The rfs filesystem is still the one used to store the image itself (the ones and the zeros), even though you write it inside an image that uses another filesystem.
I stumbled upon these documents while Googling for STL-devices:
http://www.samsung.com/global/busin...y/downloads/LinuStoreII_GPL Compliance_10.pdf
http://www.samsung.com/global/busin...ionmemory/downloads/RFS_130_Porting_Guide.pdf
I haven't had the time to read them through yet. But if there's a porting guide, there must be a way to reverse it
Go go reverse engineers!
Is it really necessary to format the NAND with another filesystem? /dbdata seems fast enough as it is. Wouldn't it be enough (and easier?) to only convert the internal SD to yaffs2?
Quote from someone that knows a lot more than I do:
yaffs2 won't work on a sdcard
Click to expand...
Click to collapse
http://twitter.com/wesgarner/status/20805997718
So right now we have /data that is mounted in the second partition of the internal sdcard (mmcblk0p2), where all the critical files are stored (data, dalvik-cache, etc..) but we can't use yaffs2 there because it's not MTD.
We could, however, format and mount the other partitions (/system, /dbdata, /cache, etc...) with yaffs2, but that might not help because there isn't many heavy read/write there. And we should figure out how to make the kernel see them as /dev/block/mtdblock* instead of /dev/block/stl*.
rasdeep, can you share the .config for the kernel you used? I managed to get some mtd devices (atleast in /proc/mtd) but they were virtual devices. Maybe we need some more options enabled in the kernel.
Also, anybody knows why there are /dev/block/stl* and /dev/block/bml* they seem the same though.
darksnarfer said:
Also, anybody knows why there are /dev/block/stl* and /dev/block/bml* they seem the same though.
Click to expand...
Click to collapse
According to http://www.samsung.com/global/busin...ducts/fusionmemory/Products_XSR_Brochure.html
STL and BML are independent layers for managing I/O to the NAND devices
STL manages the sector translations while BML manages the invalid blocks (whatever that means)
Did any of you notice that in init.rc there are many references to yaffs2 ? Perhaps in engineering Samsung did use it ?
Chainfire said:
Did any of you notice that in init.rc there are many references to yaffs2 ? Perhaps in engineering Samsung did use it ?
Click to expand...
Click to collapse
Yeah, I think they are just android standard (maybe they took them from a template) and commented to use their better(?) filesystem.
darksnarfer said:
Quote from someone that knows a lot more than I do:
http://twitter.com/wesgarner/status/20805997718
So right now we have /data that is mounted in the second partition of the internal sdcard (mmcblk0p2), where all the critical files are stored (data, dalvik-cache, etc..) but we can't use yaffs2 there because it's not MTD.
We could, however, format and mount the other partitions (/system, /dbdata, /cache, etc...) with yaffs2, but that might not help because there isn't many heavy read/write there. And we should figure out how to make the kernel see them as /dev/block/mtdblock* instead of /dev/block/stl*.
rasdeep, can you share the .config for the kernel you used? I managed to get some mtd devices (atleast in /proc/mtd) but they were virtual devices. Maybe we need some more options enabled in the kernel.
Also, anybody knows why there are /dev/block/stl* and /dev/block/bml* they seem the same though.
Click to expand...
Click to collapse
Ok, so what filesystem does the internal SD use currently? Would it help if we change that to EXT4? That would emulate the current mimocan fix, but without having to use an external SD card.
I'm trying to figure out what format / partitions my sdhc card(s) should be in.
Does the stock firmware require specific partitioning? 1 FAT32 seems
like it would have huge waste due to the FAT clustering system. Would one
say 2gb FAT32 partition for the firmware to use + some sort of ext2/3/4
or other Linux type filesystem for the rest to better use the space work?
Would a linux swap partitition help / be used at all? I have a 2gb (already
formated as a single fat32 filesystem), a 16gb class 2 and a 32gb class 2
to work with.
I figured on partitioning / formatting the large cards with gparted on a
card reader device, then putting the card in the phone.
How does the incredible see the internal user flash space, as a 'second' SD type device?
Do I understand correctly, the system flash is logically treated as a number of filesystems
so they can be 'fixed' / 'updated' seperately?
Like the boot partition, kernal partition, recovery partition, system / root partition etc.
I'm trying to understand how the system a works vs a regular
unix / linux / bsd OS would. Like booting into recovery is kinda like booting into single user
to fix the boot or root partition.
Does nandroid backup the user (internal) flash or just the various
system flash partitions?
Thanks
Mine is just formatted fat32.
Sent from my ADR6300 using XDA App
fuzzynco said:
I'm trying to figure out what format / partitions my sdhc card(s) should be in.
Does the stock firmware require specific partitioning? 1 FAT32 seems
like it would have huge waste due to the FAT clustering system. Would one
say 2gb FAT32 partition for the firmware to use + some sort of ext2/3/4
or other Linux type filesystem for the rest to better use the space work?
Would a linux swap partitition help / be used at all? I have a 2gb (already
formated as a single fat32 filesystem), a 16gb class 2 and a 32gb class 2
to work with.
I figured on partitioning / formatting the large cards with gparted on a
card reader device, then putting the card in the phone.
How does the incredible see the internal user flash space, as a 'second' SD type device?
Do I understand correctly, the system flash is logically treated as a number of filesystems
so they can be 'fixed' / 'updated' seperately?
Like the boot partition, kernal partition, recovery partition, system / root partition etc.
I'm trying to understand how the system a works vs a regular
unix / linux / bsd OS would. Like booting into recovery is kinda like booting into single user
to fix the boot or root partition.
Does nandroid backup the user (internal) flash or just the various
system flash partitions?
Thanks
Click to expand...
Click to collapse
I believe the stock firmware won't be able to see the card if you reformat it in anything besides fat32, but this is just speculation.
You bring up a good question though. ext2 contains less read/write overhead than FAT32, and thus it would seem better to store certain read/write intensive files (i.e. music) on an ext2 partition rather than FAT32.
You could always root, install a stock-like kernel (Skyraider, Virtuous, etc.) and play around with fstab to see if you can get something usable.
Has anyone successfully reformatted either /sdcard or /sdcard/external_sd/ /emmc as ext3? I'm not talking about an Apps2SD partition, I'm talking about reformatting the whole volume as one partition, transparent to apps. I do not use Windows so I do not need interoperability, I am fine with ext filesystems.
My goal is to be able to use symlinks (not to mention a more robust filesystem) to redirect certain hard-coded items to store on a different storage volume than it defaults to, but symlinks are not permitted on vfat (FAT32) filesystems.
Thanks!
Anything that I look an answer for, is just not answered. :-(
I am looking for the same information. Wonder why the native ext file systems are not allowed, given that its a Linux kernel running.
You could format it to ext3 and see how it works. Worst case scenario is your phone will tell that sdcard to fu*k off. Given that our phones can and do read the ext format I'm sure you can do it. I'm just not sure how well it will work as far as mounting and such.
On top of that, Windows can read ext formats. You just need a program to do it. I use it all the time.
Thanks for reviving this thread. Surely there must be someone out there who has tried this, and I was hoping to hear from them before I gave it a go, but looks like I'll just have to give it a shot myself.
When I find the time to backup & wipe my sdcard to try and reformat & mount it, I'll report back here.
With my Galaxy Note N7000 I can format a USB Stick to EXT3, and the phone uses it perfectly well as USB Storage...
(rooted, w/w SpeedMod kernel)
I'm currently compiling Android (CM10.1 to be specific) for my ODROID to finish this mod, but it's 90% working and I'll give you details on what I have done.
Basically, the current partition layout on the ODROID is fine, but it's an old fashioned way of handling things, and it's awkward to update kernels (you have to use dd to a set position on the eMMC/SD card to flash it onto the eMMC). What I wanted to do was make the ODROID either have dedicated kernel/ramdisk partitions (similar to Android phones), or alternatively use a boot partition (similar to Linux desktops with /boot containing vmlinuz and initrd etc). It's really not that hard at all to pull this off with the ODROID being so easy to work with (eMMC removable, boot from SD, U-Boot, etc), but I'll run you through what I've had to do and try to go through it in further detail once I've finished the process, and probably upload some binaries so people can try it on their own device.
Note, I'm doing this on an SD card rather than my eMMC so I don't mess with my main Android system on it. I recommend you do this as well until you have it sorted. Also note I am doing this under Linux as Windows requires cygwin to do all this, and cygwin is a pain to tell people how to set it up. Basically, if you don't have Linux, then use Virtual Box and Ubuntu in it or something. It'll be way easier in the long run.
Delete all the partitions on the SD card. Use fdisk /dev/sdb (or whatever the device is for your SD card - I did this on my laptop which has an SD card reader and also a USB SD card reader and they both detect as sdb. Do cat /proc/partitions to see which is your SD card (obviously if you have a 4GB card, then it'll be the device that's 4GB in size).
Prepare your SD card with the ODROIDs bootloaders (BL1/2, U-Boot and Trustzone). I got this in the BSP that Hardkernel provides on their download page, but I'll put it in a smaller package when I make it.
The script flashes BL1, then BL2 at the end of it, then U-Boot, then Trustzone all appended after each other and it will do this with dd if=x.img of=/dev/sdb skip=x, etc.
Create your new partition table on the SD card. This part is awkward because we have the bootloaders at the start of the device, and I'm pretty sure U-Boot wants some space left at the end where it can save its environment settings/variables, so I left 5-10MB at the start of the card for U-Boot. The rest of the space is entirely up to you on how you want it to work, but I did a 50MB boot partition in FAT32 (you could do EXT2, U-Boot should support that too), 512MB for /system (that's about the size of it on my Galaxy S2 and my Nexus 7), 128MB for cache and the rest of the 4GB SD card for data, so 3ish GB for data and media. On a 16GB eMMC you'd effectively have 14-15GB of space for applications and media rather than having it split into 2GB and 12GB or something.
If you really want you can do an SD card partition and do it the old fashioned way, and it won't require a new version of Android, but I wanted to do more work.
When I made the partition table, I made the 50MB boot partition as a primary partition (sdb1) and then made a logical partition (sdb4) in which I made 3 logical partitions (sdb5/6/7) for system/cache/data. I did it that way so that I'm not at the limit of what the MBR partition table supports.
Make the filesystems on the partitions, so mkfs.vfat /dev/sdb1, mkfs.ext4 /dev/sdb5 etc.
Copy your kernel in its raw zImage format and ramdisk image to the boot partition, can call them kernel and ramdisk.img respectively (or whatever you like, I don't care)
Put the SD card in the device with your eMMC in there as well and boot the ODROID, or put the eMMC in your computer with your SD card
Mount the SD card and eMMC
Copy the system partition from the eMMC to the SD card (so if you do this on the ODROID, you will do cp -prf /system/* /mnt/tmp (assuming you mounted the SD card on /mnt/tmp)
Turn off the ODROID and remove the eMMC
Connect the ODROID to UART and turn it on. Provided you haven't mucked up the bootloader by not skipping the first 10MB of the card it should start to boot to U-Boot. You want to stop it and get to the prompt on U-Boot.
In the prompt, we need to change the default_bootcmd. This is the command that U-Boot falls back to if it can't find any boot scripts. You can edit bootcmd, but I don't recommend it. It's best to leave the bootscript functionality there for future endeavours. I changed it to this: "fatload mmc 0:1 40008000 kernel;fatload mmc 0:1 41000000 ramdisk.img;bootm 40008000 41000000". That will load the kernel from partition 1 (boot partition) on MMC 0 and then load ramdisk.img from it. You can change those filenames if you changed the filenames when putting them on the device.
Save the environment in U-Boot (saveenv) and reset the device (reset).
Provided all goes well, the device should load the two images and start booting Android.
You'll need to edit the ramdisk (the fstab specifically) to make it work with the new partitions, and if you went with a /data/media partition like I suggested, you will need to modify the storage_list.xml in the framework overlay in the Android source code and recompile it. As I said, I'll make binaries if you don't know how to do that.
Hopefully my information is clear enough for other people to understand what I'm doing here. If not then ask and I'll try to clarify it.
On a side note: will XDA ever have an ODROID U2 section? It has a Ras Pi section, so I feel that an ODROID U/U2 section is in order.
Would this work for creating a dedicated recovery partition also?
brando56894 said:
Would this work for creating a dedicated recovery partition also?
Click to expand...
Click to collapse
You can just put a recovery image on the boot partition, so yes.
I know I'm late to the party and this was probably already discussed, but I couldn't find it with search. Has anyone considered converting the inc to a data media device (http://www.xda-developers.com/android/what-is-a-data-media-device/)? I've seen this done with other devices (e.g. hp touchpad). I'd be nice to be able to use the EMMC partition for storage and data. I know there is ext4all but I still seem to run out of space quickly since dalvik-cache is half of /data.
Not sure if hboot will let you combine partitions to do what you want; however, lvm can probably accomplish what you're hoping to achieve but it takes quite a bit of effort to setup.
Sent from my One using Tapatalk
I wasn't necessarily thinking we need to combine any partitions. Just don't mount the existing /data and /data/data partitions, and mount the EMMC partition as /data with an emulated sdcard at /data/media. I think this is how the Samsung phones work; you have both "internal" and "external" sdcards. Seems like it should just be some config changes and maybe a recovery that is datamedia aware so you don't erase the emulated sdcard when wiping data.
Smells like a project. I'll see if I will get around to this but this sounds doable.
No promises but my Inc could get bricked and I wouldn't cry over it so I can take a few risks.
Sent from my One using Tapatalk
I've only done a little research so far, but it seems like you'd only need to change a few configuration files. I don't think you could truly brick your Inc, could you? I'm tempted to try and get it working myself but I can't risk bricking my dd.
Sent from my ADR6300 using Tapatalk
ive got 2 incs so I dont mind messing with it, I have a touchpad tho and from what I know (I am decent friends with invisiblek and he does work on the touchpad) the only real difference, is re-partitioning your internal and setting the device tree to mount data as data/media instead of for say /data or /data/data
I have a TouchPad too. Finally made the leap to kk and datamedia there which is what got me thinking about the Inc. The repartioning done for the TouchPad was too make the data partition larger since it now holds both apps and sdcard data. We shouldn't have to do that for the Inc since we already have a partition with 6.6 gig available. Nothing is mounted at /data/media, it's just another directory on the main /data partition. That's why you need a special recovery that "wipes" data instead of formatting...
I've been looking at the changes milaq made. I assume invisiblek did something similar if not the same.
Sent from my ADR6300 using Tapatalk
natediggity said:
I have a TouchPad too. Finally made the leap to kk and datamedia there which is what got me thinking about the Inc. The repartioning done for the TouchPad was too make the data partition larger since it now holds both apps and sdcard data. We shouldn't have to do that for the Inc since we already have a partition with 6.6 gig available. Nothing is mounted at /data/media, it's just another directory on the main /data partition. That's why you need a special recovery that "wipes" data instead of formatting...
I've been looking at the changes milaq made. I assume invisiblek did something similar if not the same.
Sent from my ADR6300 using Tapatalk
Click to expand...
Click to collapse
A fancy flashable script to convert your boot.img to use /data/media should be possible. So far I told it to switch to mmcblk03 from 01 for /data so it's 6.6GB. The other part is relocating fuse to use /data/media for the internal storage instead of /emmc. That should be somewhat easy to change but a bit harder to script.
/data/media was designed for devices that don't have an sdcard slot which the Inc does have so this is more of a proof of concept idea for me than actual utility.
Ok, the last part is recovery and the current recovery images appear to be large enough to make the recovery build part fail. I'm not sure the actual recovery partition size on the inc but the images come to be about 4.5 MB and fail.
zachf714 said:
ive got 2 incs so I dont mind messing with it, I have a touchpad tho and from what I know (I am decent friends with invisiblek and he does work on the touchpad) the only real difference, is re-partitioning your internal and setting the device tree to mount data as data/media instead of for say /data or /data/data
Click to expand...
Click to collapse
/data/media uses fuse on an existing ext4 partition so the recovery as nate said has to be told to wipe /data instead of format (in other words, using an rm command and excluding /data/media).
This makes filesystem corruption harder to fix since the partition can't be wiped from recovery normally unless it's a format which TWRP does have an option to format /data.
tiny4579 said:
A fancy flashable script to convert your boot.img to use /data/media should be possible. So far I told it to switch to mmcblk03 from 01 for /data so it's 6.6GB. The other part is relocating fuse to use /data/media for the internal storage instead of /emmc. That should be somewhat easy to change but a bit harder to script.
/data/media was designed for devices that don't have an sdcard slot which the Inc does have so this is more of a proof of concept idea for me than actual utility.
Ok, the last part is recovery and the current recovery images appear to be large enough to make the recovery build part fail. I'm not sure the actual recovery partition size on the inc but the images come to be about 4.5 MB and fail.
Click to expand...
Click to collapse
Check my device tree, I have a commit on omni that compresses recovery a bit more and I use it to build
Sent from my SCH-I535 using Tapatalk
tiny4579 said:
A fancy flashable script to convert your boot.img to use /data/media should be possible. So far I told it to switch to mmcblk03 from 01 for /data so it's 6.6GB. The other part is relocating fuse to use /data/media for the internal storage instead of /emmc. That should be somewhat easy to change but a bit harder to script.
Click to expand...
Click to collapse
I don't need a flashable script unless it's required. Personally, I'm fine just building a new system image and flashing that.
tiny4579 said:
/data/media was designed for devices that don't have an sdcard slot which the Inc does have so this is more of a proof of concept idea for me than actual utility.
Click to expand...
Click to collapse
datamedia can be used in conjunction with sdcards. This is what the new samsung phones do. I thought the HTC One did as well, but I just remembered it doesn't have a sdcard slot. If you haven't already, check out this page: https://source.android.com/devices/tech/storage/config-example.html. Our config would be similar to the Xoom's.