Alright everyone... future development for the Epic will start moving quickly, and I ask that everyone PLEASE watches this and pays attention to eliminate future questions. This video explains MTD. Please keep discussion going, as I'd like to see this on the first page for everyone.
WATCH THIS:
http://www.youtube.com/watch?v=ds9rwAoI2IQ
Don't be afraid to subscribe and give it a thumbs up
Thanks for this, users are going to be quite confused, and this will help a lot.
For those who might be a bit more interested in the differences:
BML and MTD's main difference is how they access the flash memory. Flash file systems, like YAFFS2, are designed to access the raw memory, without anything particularly fancy sitting in between, while block file systems, like RFS, EXT4, and others, operate on block-level storage devices. This is why your hard drives and SSDs use file systems like EXT4 - they have controllers that expose the block layer. The same applies to your OneNAND device in your Epic.
Samsung's OneNAND product in this device uses what they call XSR - "XSR is a layer between filesystems and NAND devices that uses logical sector relocation to prevent too many overwrites of the same block and to relocate bad blocks." There are two layers to that: "BML (Block Management Layer) are the devices on bottom of XSR exatly on top on NAND low level drivers.", and "STL (Sector Translation Layer) are the logical devices on top of XSR" (for data partitions). In using MTD, XSR is essentially eliminated completely. That's not to say the tech is gone, as Odining back to stock (as QB points out) is plenty possible, but it's no longer in use.
MTD stands for Memory Technology Device, and is "a new type of device file in Linux for interacting with flash memory". It "was created to provide an abstraction layer between the hardware-specific device drivers and higher-level applications". Its purpose is, was to put an end to the translation - flash memory devices like the OneNAND device in our Epics are not block-level devices, so why try to shoehorn them? In combination with the more 'direct', so to speak, access to the memory device that MTD provides, flash file systems like YAFFS2 handle all the optimization required for proper data handling. In a way, they combine the functions of something like Samsung's XSR and a traditional file system.
YAFFS "is a robust log-structured file system that holds data integrity as a high priority", and a "secondary YAFFS goal is high performance". I'm sure some of you will be wondering what read/write performance will look like after the transition - I am too. But that will come.
Don't be afraid of change, folks.
References:
http://movitool.ntd.homelinux.org/trac/movitool/wiki/RFS
http://en.wikipedia.org/wiki/Memory_Technology_Device
http://en.wikipedia.org/wiki/YAFFS
Great video as always qbking77.. This actually gives me a reason to hold off a little longer on getting a new device..
this is incredibly good news so the question is if its possible to run cwm and change the file system like how we already do between rfs and ext4 but now to yaff s? qb king mentioned odin but I would assume it what I mentioned could be possible.
Sent from my SPH-D700 using XDA App
ddrbeastappv1 said:
this is incredibly good news so the question is if its possible to run cwm and change the file system like how we already do between rfs and ext4 but now to yaff s? qb king mentioned odin but I would assume it what I mentioned could be possible.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
I'm sure the awesome devs we have will figure out a way, hell I'd like to contribute if I get some time as well. We might have to start with odin, but we are already able to change file structure by simply flashing a rom. Definitely going to have to do some research.
Semi Nerd Rage! Lol not really (Told you gameboyking24)
Guys, the conversion from RFS to EXT4(vice versa) is not the same way you'd go about getting to YAFFS2. Take it as this way, BML is a race track where only rfs and ext4 can race(in theory) while MTD is a track umpteen miles away where yaffs2 resides racing alone(in theory). BML and MTD both the same as they serve the same purpose but handle it in a different means. They are exactly what they've been explained as but in simpler terms they are partition maps. Not a filesystem. Our filesystems reside on the mapping of a BML or MTD as of recent partition map which allows us to customly resize partitions where we see fit. If and when you decide to make the move to MTD all things BML are restricted to you until you odin and repartition back to BML. So it's at the moment not the matter of a dev making an RFS to YAFFS2 zip, unfortunately there is a lot more involved and put into this whole process.
Sent from my Epic 4G
Thank you Apro. I understand a little better now but I am unfortunately fearful of Odin since i've swapped at least 7 epics at the sprint store because I either fail at the odin process or fail at installing drivers ><
Sent from my SPH-D700 using XDA App
ddrbeastappv1 said:
Thank you Apro. I understand a little better now but I am unfortunately fearful of Odin since i've swapped at least 7 epics at the sprint store because I either fail at the odin process or fail at installing drivers ><
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Oh it's no problem at all man. I would for the meantime stay away from MTD for a bit until there is a lot more going on, so you've a stable failsafe rom over on that format.
It gets 2100 in quadrant.
So when the roms that work on MTD tables come out, will we first have to use Odin to repartition/ flash the roms in odin as opposed to clockwork. I saw mentioned that it would be possible to flash back to stock in odin to get BML back. My question more simply phrased, how will we convert from BML to MTD?
counterfeit187 said:
So when the roms that work on MTD tables come out, will we first have to use Odin to repartition/ flash the roms in odin as opposed to clockwork. I saw mentioned that it would be possible to flash back to stock in odin to get BML back. My question more simply phrased, how will we convert from BML to MTD?
Click to expand...
Click to collapse
flash using an update.zip
And I thought odining back to stock was hard enough XD
Looks like I chose the right phone was very tempted to get the evo ^^
Sent from my OG Epic
I like the part at the beginning where you touch your phone obsessively.
Does a ROM have to support MTD and is it only in the kernel for that? Will the ROM be able to be used on either BML or MTD at that point?
This is some really exciting stuff. I am planning on keeping the epic until the new LTE phone roll out, and this has given me some hope for ICS and CM9.
Thanks to all the devs that put in some serious time on this.
kennyglass123 said:
Does a ROM have to support MTD and is it only in the kernel for that? Will the ROM be able to be used on either BML or MTD at that point?
Click to expand...
Click to collapse
As far as I know not necessarily. However it's likely there will be Roms which are more catered for MTD in the separation of sizes. So if it requires more space in /System for essentials to run, it'll likely be an MTD only thing. But if the size of the System partition isn't needed to change then you can run it on either of the two ,as long as the kernel you're using on BML has what the rom needs to properly boot. If that makes sense?
I was going back and forth a bit lol.
AproSamurai said:
As far as I know not necessarily. However it's likely there will be Roms which are more catered for MTD in the separation of sizes. So if it requires more space in /System for essentials to run, it'll likely be an MTD only thing. But if the size of the System partition isn't needed to change then you can run it on either of the two ,as long as the kernel you're using on BML has what the rom needs to properly boot. If that makes sense?
I was going back and forth a bit lol.
Click to expand...
Click to collapse
So current ROMs would likely work on MTD with the right kernel, but ROMs designed on MTD might not work on BML?
Specialksg1 said:
So current ROMs would likely work on MTD with the right kernel, but ROMs designed on MTD might not work on BML?
Click to expand...
Click to collapse
Kind of. For MTD, ROMs need more than just a new kernel: they need a different updater-script and other mtd scripts (like updater.sh and blm_over_mtd.sh). For example, on my MIUI builds, I port from NS4G and Fascinate which use MTD, but if I delete the MTD files and add our kernel and updater-script, it is now bml. Also, most MTD ROMs will work on BML except for ICS or anything that has too big of a /system folder. And with the right modifications, any BML ROM can work on MTD. Hopefully that answers your questions and other peoples'.
xboxfanj said:
Kind of. For MTD, ROMs need more than just a new kernel: they need a different updater-script and other mtd scripts (like updater.sh and blm_over_mtd.sh). For example, on my MIUI builds, I port from NS4G and Fascinate which use MTD, but if I delete the MTD files and add our kernel and updater-script, it is now bml. Also, most MTD ROMs will work on BML except for ICS or anything that has too big of a /system folder. And with the right modifications, any BML ROM can work on MTD. Hopefully that answers your questions and other peoples'.
Click to expand...
Click to collapse
That clears everything up ... leave it to you guys lol Exciting times, good luck and god speed!
New member piping in for the first time. I love all the information that I've been picking up here! Thanks to everyone who participates...
Related
I want to try developing for the DSTL1 / N21
There are quite a few interesting things we can do...
Success has been been seen by xda-devs such as JesusFreke, Amon_RA, Haykuro, and Cyanogen (yes there others) in the field of Android ROMs. The ground work is there, porting and developing can commence.
Why do this?
Current ROM 1.5 - has many problems...
Unofficial ROM 1.6 - is a GREAT improvement, but makes one hungry for something better...
It would be awesome to have some success in this field. I know this device is capable of so much more, but I believe the implementation of the system is the issue. This is not the phone developers fault, as they have their own company agenda, but we could improve our own performance and satisfaction .
For example, my device (1.6 rooted) lags with having only ~50% CPU utilization and ~50MB RAM free...
Overclocking (i mean forcing full CPU capacity - 624Mhz) the CPU has barely helped and only aided battery drain...
Relevant comparison of G1 vs DSTL1 (N21) are
RAM - G1: 192MB vs DSTL1: 128MB
CPU - G1: 528Mhz vs DSTL1: 624Mhz
These specification comparisons say that G1 can run a better ROM than DSTL1? I don't think so. DSTL1 only loses in RAM, which can be made up for using swap!
Devs had success with techniques using: App2SD, swap, ext3, and BFS (faster file system). I believe we could do something impressive here! There are pros and cons to this.
Developers and Testers would be needed. A team of 5 developers and a few testers should be able to get us on the right track. We would definitely need Linux experience, or the desire and ability to soak up all the info on Google
A Linux kernel is a must for this phone, we would have to compile our own... It would be nice to preserve DUAL SIM, but in reality we might have to give up this luxury, as it is proprietary code, unless a new ROM is made backwards compatible (which is possible).
Cyanogen's Github is available for knowledge osmosis http://github.com/cyanogen
A DSTL1 Recovery by Amon_RA (based on Cyanogen's Recovery) is already in Beta...
Cool things are possible. Could I find some developers willing to donate their free time?
Please limit responses to dev talk.
reserved for later
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
chrismotto said:
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
Click to expand...
Click to collapse
Its a possibility that I'm not going to ignore, so I stated it.
The point is that the current OS is lacking. Initially we would want to port and learn from porting of the quality ROMs available now. Those obviously don't support dual-SIM.
Progress needs to start from somewhere. When someone releases a new port or ROM not all pieces work... look at the Eclair (2.0) port, half the features don't work!
If enough heads came together we could probably retain dual-SIM, common this is linux and I've seen the most amazing development come to realization. I just need the teamwork because it might take me a whole year in my spare time...
Having a kernel working
Hi,
the most important IMHO is having a kernel working, built from sources.
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
My first attempt of booting with a custom kernel was unsucessfull (black screen), which brings to the second point: the lack of some sort of console for kernel debuging.
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Any idea also regarding kernel debugging in the N21/DSTL1?
sfabris
@sfabris
I will try to find info for the questions you have.
My initial work will be to make an emulator so we can test on PC and not our devices (because we need them functional for every day life )
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
sfabris said:
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Click to expand...
Click to collapse
Maybe we have it all wrong???? Maybe its PNX?
PDA DB reports DSTL1 as having Nexperia PNX5209 (ARM946) Phone Controller.
http://pdadb.net/index.php?m=specs&id=1714&view=1&c=general_mobile_dstl1
A similar Android with this phone controller is WayteQ X-Phone (TechFaith Lancer)
http://pdadb.net/index.php?m=specs&id=1801&view=1&c=wayteq_x-phone_android_techfaith_lancer
crzyruski said:
@sfabris
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
Click to expand...
Click to collapse
As I'm forced to HTC G1 until I'll wait the replacement for my N21 I'll go in detail on the kernel boot process on other hardware.
A fast way to test kernel in our every day device is kexec which should work also on ARM.
sfabris said:
A fast way to test kernel in our every day device is kexec which should work also on ARM.
Click to expand...
Click to collapse
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
crzyruski said:
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
Click to expand...
Click to collapse
I've tried it on x86, never on arm.
Support is there also for arm, but this not imply that also the Marvell PXA is supported.
It's basically the same way of booting Android from WM via haret.
Fastest way to boot your new kernel or to crash your machine
I have created an emulator.
FYI, LCD density should be 120.
Edit: Technically the density is 133...
files prevent recovery-RA-DSTL1-v1.2.3 from loading
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
is there any ways to update the firmware of N21
hi,
i'm just buy a sciphone n21 (actually is already in our office for 2 weeks but find it now:-( )
and i've to face myself in a situation that i can't use this phone:-( since i buy this phone because:
- i assume that google apps auto sync contact and calendars. unfortunately this phone has not google apps by default.
- and has dual sim support.
so my question: is there any way to upgrade it to a firmware which support is?
can i do anything to use my phone?
thanks in advance.
regards.
crzyruski said:
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
Click to expand...
Click to collapse
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
andferno said:
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
Click to expand...
Click to collapse
Thank you for that insight.
I am not sure what RA's recovery would have done on its own...
but I have initiated and completed successfully a partition of my SDCard that includes FAT32, swap, and ext2.
Now that I have done this, for experimentation really, I don't know how to use it and what it gives me.
Obviously the swap is useless because I would need a cooked Android ROM that would actually utilize swap.
ext2 is probably for apps2sd... which I tried unsuccessfully - probably because of my own mistake.
I will continue trying and report again later.
As far as Amon_RA, he mentioned he was working on upgrading all the recovery images he has put out to the next version - thus we will be in queue until this comes to pass. Maybe we can just skip this version and go to the next
N21 vs DSTL1: stock comparisons
I have completed the comparison of recovery images of the DSTL1 and N21.
For this test I used an original mtd2.img from my DSTL1 and an original mtd2.img from Slemmen's N21.
The recovery images are identical:
Both mt2.img are 4,194,304 bytes
Both mtd2.img-kernel are 2,141,616 bytes
Both mtd2.img-ramdisk.gz are 386,645 bytes
What is also interesting to note is that the two boot images i inspected were also identical.
The DSTL1 boot image is one that came with the 1502 update from General Mobile (which may or may not be identical to the original).
The original N21 boot image, thanks to ikarishinjisan, is identical to the DSTL1 boot image:
Both mt1.img are 4,194,304 bytes
Both mtd1.img-kernel are 2,141,816 bytes
Both mtd1.img-ramdisk.gz are 148,671 bytes
*Notice how both recovery and boot are the same size... must be padded?
*Notice how boot kernel is 200 bytes more than recovery kernel.... interesting...
On a side note:
Bootloader is identical as expected: both ikarishinjisan's and my mtd0.img are 1,048,576 bytes.
If things are going to go custom, it might make some sense to put ext3 filesystems on these things.. ext3 is just ext2 with journalling, which could be helpful since phones can just die/get dropped/lose connection with battery/whatever.
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
dnfm said:
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
Click to expand...
Click to collapse
Are you referring to the Amon_RA's custom recovery?
I can't get tune2fs onto the recovery without trickery, definitely not noob friendly... until we figure out why.
But great suggestion
I'm guessing the ROM must be coded to make use of ext3, otherwise its worthless?
The kernel would need to be configured to support ext3.
I'm posting this in General as I don't have the knowledge to port this or develop a similar version for the Slide and I don't want to clutter up the Development forum.
Team ADX over in the Droid Eris forum came up with this gem; a dual boot Eclair Sense/2.2 AOSP ROM. http://forum.xda-developers.com/showthread.php?t=824072
I don't know if this can be done on our phones, but I thought it possible as you don't need to flash a custom recovery.
man this would awesome... the best of both worlds, run and "stock" ROM so we can still receive updates and still have CM.
i was actually thinking about dual boot just the other day! i dont feel like id be switching back and forth from 2 roms but itd be a great feature for those who do. unfortunately i dont think we have that much developers :/
I was reading the instructions for it and it looks like we'll have to wait for S-OFF before we can try it.
Part of the scripting is telling the phone how to partition the phone, sizes of those partitions, and so on. The slide is, generally speaking, un-brickable and it's the measures used to give us that luxury that also prevent us from doing so much like R/W on the system while in a non-recovery boot and changes we do make while booted are just wiped on reboot *sigh* man I love that ramdisk image.
Once we get S-OFF let's get this project started
KCRic said:
I was reading the instructions for it and it looks like we'll have to wait for S-OFF before we can try it.
Part of the scripting is telling the phone how to partition the phone, sizes of those partitions, and so on. The slide is, generally speaking, un-brickable and it's the measures used to give us that luxury that also prevent us from doing so much like R/W on the system while in a non-recovery boot and changes we do make while booted are just wiped on reboot *sigh* man I love that ramdisk image.
Once we get S-OFF let's get this project started
Click to expand...
Click to collapse
I don't think S-OFF is the issue. The partitioning instructions only refer to sdcard. This command:
Code:
mkpartfs primary fat32 0 3500 (can be adjusted to your needs. This partition will be used by the 2.1 rom and by recovery)
I think is only for the phone ROM storage and the for the recovery to find the boot scripts. According to the instructions, they're only partitioning the sdcard to run the AOSP ROM in it. They install the 2.1 Sense ROM to the phone, get it set up, run the boottosd script to boot into the 2.2 AOSP ROM on the sdcard, then set that up and run the boottophone script to go back to 2.1 Sense. They're running a ROM on the sdcard!
As I said before, I think something like this can work for our phones because it doesn't require flashing a recovery. The problem is we don't have the devs to do it.
heybobitsme said:
I don't think S-OFF is the issue. The partitioning instructions only refer to sdcard. This command:
Code:
mkpartfs primary fat32 0 3500 (can be adjusted to your needs. This partition will be used by the 2.1 rom and by recovery)
I think is only for the phone ROM storage and the for the recovery to find the boot scripts. According to the instructions, they're only partitioning the sdcard to run the AOSP ROM in it. They install the 2.1 Sense ROM to the phone, get it set up, run the boottosd script to boot into the 2.2 AOSP ROM on the sdcard, then set that up and run the boottophone script to go back to 2.1 Sense. They're running a ROM on the sdcard!
As I said before, I think something like this can work for our phones because it doesn't require flashing a recovery. The problem is we don't have the devs to do it.
Click to expand...
Click to collapse
I'll take a look. No promises as I'm an übernoob but I would love to have this.
Sent from my T-Mobile myTouch 3G Slide using XDA App
migueltherocker said:
I'll take a look. No promises as I'm an übernoob but I would love to have this.
Sent from my T-Mobile myTouch 3G Slide using XDA App
Click to expand...
Click to collapse
You won't be able to do a simple port. I posted about it more of as a proof of concept. Take the same idea, but obviously using our espresso sense and CM6.
heybobitsme said:
I don't think S-OFF is the issue. The partitioning instructions only refer to sdcard. This command:
Code:
mkpartfs primary fat32 0 3500 (can be adjusted to your needs. This partition will be used by the 2.1 rom and by recovery)
I think is only for the phone ROM storage and the for the recovery to find the boot scripts. According to the instructions, they're only partitioning the sdcard to run the AOSP ROM in it. They install the 2.1 Sense ROM to the phone, get it set up, run the boottosd script to boot into the 2.2 AOSP ROM on the sdcard, then set that up and run the boottophone script to go back to 2.1 Sense. They're running a ROM on the sdcard!
As I said before, I think something like this can work for our phones because it doesn't require flashing a recovery. The problem is we don't have the devs to do it.
Click to expand...
Click to collapse
Ok that makes sense. I thought it was pointing to the partitions on the phone telling it to format to a different size for some reason. Then what's preventing us from doing this? Just a lack of a proper script?
I have not poked around with how they are going about doing everything, but I was the one who got the ball rolling with my dual boot linux script. Conap took the basic setup and made some changes to just install them both on the phone and sdcard. Here is the basic of what it is doing....
The init.rc file found in boot.img has been modified for the froyo rom on the sdcard. The lines where it mounts [email protected] , [email protected], and [email protected] have been changed to the partitions on the sdcard (/dev/block/mcblk0px) The updater-script for froyo has been modified to flash the rom to the partitions on the sdcard. There are some gscripts which are ran from the phone that either modify or replace the boot.img for the rom you want to boot into.
The froyo ROM is running completely off the sdcard and the recovery is left untouched. The script that is required if you are using clockworks is because clockworks sbin and folder locations are setup a little different. I was running into some problems with froyo not recognizing the sdcard after making more than 4 partitions. Several had reported to me that their phones also did not recognize the sdcard, but the Eris phones somehow still did. I am working on something that should run from all android phones and allow you the option of installing whatever ROM you want.
One Last Thing..
Anyone is capable of learning how to do some development work. It just takes some patience and "Google". I had no knowledge of linux or any other scripting languages, except windows batch scripts, until 3 months ago.
There is not much activity on my thread, but once I get a working version finished it will be posted there-----Dual Boot Android
When you get it done and own working, post it in development. I only posted the thread in general because I knew I wasn't going to be the one to develop it. I'm a welder by trade and java and linux are a little beyond me. Although I am trying as I'm using Ubuntu as my main OS and starting reading java tutorials.
Sent from my CM6 Slide
heybobitsme said:
You won't be able to do a simple port. I posted about it more of as a proof of concept. Take the same idea, but obviously using our espresso sense and CM6.
Click to expand...
Click to collapse
If there was ever a reason to get a dev started on a project, this would be it. I would reconsider upgrading from the Slide if we had something this awesome.
unCoRrUpTeD said:
I was running into some problems with froyo not recognizing the sdcard after making more than 4 partitions. Several had reported to me that their phones also did not recognize the sdcard, but the Eris phones somehow still did. [/URL]
Click to expand...
Click to collapse
From what I understand, android can not *see* more than 4 partitions so they had to do something a bit different. Somewhere in the thread that's linked it states what they did to get it to work.
s off is tmobs response to....
KCRic said:
I was reading the instructions for it and it looks like we'll have to wait for S-OFF before we can try it.
Part of the scripting is telling the phone how to partition the phone, sizes of those partitions, and so on. The slide is, generally speaking, un-brickable and it's the measures used to give us that luxury that also prevent us from doing so much like R/W on the system while in a non-recovery boot and changes we do make while booted are just wiped on reboot *sigh* man I love that ramdisk image.
Once we get S-OFF let's get this project started
Click to expand...
Click to collapse
The "companies" wanted s-off due to the large number of brix getting returned for handest exchange and assurion claims, just to figure out somebody pooched sumthin up trying to be a HAXOR, if you haven't done anything like this before. Id suggest peeps get a g1 or some other root & rom-o-matic type for and play with it till you take on your brand new handset trying to install some bleenin edge hack...
You gotta learn to wank off before you can try it with somebody else in the room.
I remember my early days at xda, hacking my mda, xcaliber, and esato hacking SonyEricsson fones before they jumped the shark. People who had the ability to read and follow directions (emphasis on the read part) would study till they were sure they would still have a working fone at the end. Hung out and did great stuff with there handsets. And the noobs were wary enough to investigate before they just started mucking about.
So the handset manu. Had to do sumthin and now we have s-off.
the moral of my high and mighty rant an rave, if you don't know how to do sumthing or if you understand what to do but not the why, then keep reading, read more do less
KCRic said:
From what I understand, android can not *see* more than 4 partitions so they had to do something a bit different. Somewhere in the thread that's linked it states what they did to get it to work.
Click to expand...
Click to collapse
In the newest builds they have 2.1 system on the phones system partition and froyo system on the phones data partition. The data is moved to the SD. 2.1 and previous Rome had no problem with extra partitions on the sdcard.froyo changed the way it mounts the sdcard and could only see 4.
I am actually releasing a dual boot method very shortly that should work on any android phone with very little setup required on your part. I am in the process of finalizing it. Anyone interested in testing please let me know as I want to test on as many devices ad possible
Sent from my HERO200 using XDA App
"...the best choice for a custom ROM on the Captivate" - AndroidCentral
Number One In Random And Plausibly Flawed Battery Testing By Random Persons
6.4
Added 2048 SD Card Script
Added Ram Booster Script
Added Permissions Fix Script
Updated Market
UI Tweaks
SERENDIPITY WEBSITE
A few words about the Optional But Totally Awesome Steam Kernel
Ok, so hopefully you read a bit about it in SzutpY's post. I compiled Steam recovery in English and made a kernel utilizing it. The kernel is similar in many ways to the Universal Lagfix Kernel SztupY also created. It has many of the same lagfix schemes, kernel tweaks, etc, again, all with a touchscreen interface. Other than Steam recovery, this kernel is identical to my 12-23 oc/uv kernel, so it's overclocked, and undervolt configurable, and it should be just as stable as that one.
Do not attempt to take the zImage with Steam recovery and place it in a flashable zip. You'll be a sad panda if you do. I'd advise waiting a few minutes after your system has booted to flash with Neldar's app. If you're using Odin, or Heimdall, reboot to download mode and flash like normal. Those are the options, either Neldar's app (AND NOT Tuxility!!) There are issues with flashing this via redbend_ua - the regular kernel can be flashed via redbend_ua, Steam cannot be.)
Steam recovery is based on ClockworkMod, but you have a touchscreen interface at recovery. Steam has many options to lagfix your system. So, you can have an all ext4 system (including /system), an all jfs system (again, including /system) or something in between. Read through sztupy's posts about Steam, or spend some time playing with it. I have to admit I was a little skeptical of it at first, but after using it for the last week or so, I absolutely love it.
If you're doing a filesystem conversion from Steam recovery, the zeroth thing you should do is check to make sure you have enough room on your SD card to copy /system, /data, /dbdata, and /cache. Then, make a backup. Occasionally after a filesystem conversion, the system will bootloop. Performing a three button forced reset and rebooting solves this. (In my experience at least. Like I said, make sure to backup first.)
If you do choose a No-RFS lagfix in Steam - Make sure you disable it before flashing another kernel/ROM. No-RFS uses a fake /efs to get a completely-rfs free ROM (only works if /system is set to be mounted as rw).
If it seems as though you've lost su (root)
So, I don't know why Steam does this, but the reason people were losing su was because it was automatically mounting /system nosuid. So, to fix this, there's probably more than one way to do this, but an easy way is to go into Steam, under boot options, select 'Always run adb as root' or something like that. Then reboot, open a terminal and type
Code:
mount -o remount,suid /dev/block/stl9 /system
. That will remount su access to /system (pretty important ), and then you will have root again, and Steam is finally usable again. Flash another kernel or whatever) I was really hoping I could blame this on something MikeyMike did, hmm...I may still find a way. ( Alternatively, it seems if you do a filesystem conversion on /system, /system will be remounted suid so you won't have to go through this, and I think /system conversions don't end up in boot loops like /data and /dbdata.
Credits
Xcaliburinhand - without whom we'd all be on JJ4 and JI6. *shudder*
SztupY - Steam recovery is the shiz.
raspdeep, neldar, xan
I'll probably edit this a few more times as there will be things that I want to add but have slipped my mind for the moment.
Ok - I uploaded a copy of the Steam kernel here. It deserves its own thread and it will get one, just don't feel like doing it right now. Read through this post, realize there are some errors with filesystem conversion. Make sure you do backups, if you get into a boot loops, do a hard reset and reboot normally, you should be good. This is meant to be flashed via Neldar's SGS Kernel Flasher app, or something like Heimdall or Odin.
Alright...lets get started
Sent from my liberated Captivate via XDA App.
Just when I think I've finally found a ROM to stick with (Phoenix 1.0) after flashing just about every ROM I see on XDA.......along come some new candy!
yes!!!! definetely gonna donate thanks so much for the hard work mikey!!
Am I the only one that prefers the original clock/alarm that was on the phone? Select custom ringtone is nice and it seems easier than the car/home.
Sent from my SGH-I897 using XDA App
gdbusby said:
Am I the only one that prefers the original clock/alarm that was on the phone? Select custom ringtone is nice and it seems easier than the car/home.
Sent from my SGH-I897 using XDA App
Click to expand...
Click to collapse
i love the original too. :/
Weeee!!! Finally!!!! Let see the awesomeness!!!
Running Assonance 5.0 - SpeedMod 256hz K12H - JL2
Mikey, does this contain the jpa wifi fix and external SD mount fix? Thanks.
Sent from my liberated Captivate via XDA App.
This post is no longer relevant. STOP LOOKING AT IT
I have two kernels in this, why do I have to keep hitting F5?
I guess my first post got deleted so I will do another one. This looks like it is going to be good.i actually enjoy the simplistic look.
Sent from my SGH-I897 using XDA App
Download's up.
Trying it out. Thank you.
Sent from my GT-I9000 using XDA App
and I was about to download your other rom.
madjsp said:
and I was about to download your other rom.
Click to expand...
Click to collapse
I was waiting for you to be about to download the other one so I could release this one.
just when i thought i would stop flashing today i see another rom come out.. life of a rom addict
Does this have the AOSP MMS App as well?
How is your Guy's battery life with this
Sent from my SAMSUNG-SGH-I897 using XDA App
Hi. Maybe few words about me first. I'm not a developer, I don't know how to do it and I have to ask more experienced users. Ok that's it, to the point now. Ah, and I didn't know if this thread was proper to be posted in Development sub-forum, so it's here. If it was possible, if the thread meets requirements to be there, maybe it's possible to move it there? I'm not sure how many devs visit those section, so obviously there is greater chance for finding an answer there, but again, I wasn't sure if it was right.
While I was a G1 user one genius known as "Firerat" created very nasty script - it allowed users to manually, by simply creating a .txt file on sdcard with proper values and running a .zip from recovery, resize partitions like /system, /data and /cache on the phone. I don't know if you're familiar with G1 stuff, but previous there was only one way to chage partitions and it was achieved by custom SPL called Haykuro SPL. This modification (MTD part hack) was created because of need for even more space on /data and allowed to shrink /system and /cache to smallest value possible, so /data took up as much space as it was possible. Here is source thread in G1 Development section:
http://forum.xda-developers.com/showthread.php?t=717874
There you can dive in details, because my knowledge and understanding in this things end very quickly .
On HD2, we have come a great way. From pure Windows Mobile, it was possible to run Linux kernel from sdcard by HaRET.exe, then run Android. After few month team of gods gave us MAGLDR, a tool that allows us to replace Windows Mobile from NAND with Android system. Then after few more weeks someone made Clockworkmod Recovery possible, giving us posibilty to create partitions on sdcard, do a nandroid backup/restore. But one MAJOR thing wasn't done as it should. Recovery in theory should give us possibility to flash ROMs from sdcard without need of computer. And theoretically it's possible, but... Yes, you have to have proper partition configuration flashed by DAF.exe with PC before. Imagine what a great obstacle it is for diagnosed with ORD!
Now you realise what I'm talking about? Combine these two things and bam! I'm just asking, just giving you an idea. Maybe it is possible to adapt those scripts to HD2 and replace old habits (flashing recovery by DAF.exe on PC) with simple script and one .txt file!
Again, maybe it's not possible since we are still using old SPL from WM times. Maybe MAGLDR is build in such way that those scripts are not possible. Maybe there is a thousand reasons... but I've never seen such an idea.
So please, is there one person who are good in this stuff and can explain me wether it's possible or not?
So maybe I can rest assured that I have to cure my ORD
OR
we can move on to work on making this idea reality .
cure for ORD....
I DON'T THINK SO.
Flashed from my fingers to your face
On a serious note, though, have you looked at clk? It is supposed to be useable without a pc. Therefore you can configure the partition on your phone. Is my understanding of that correct?
Maybe T-Macgnolia can explain this better than I .
I'm still trying to get my head round it, before I commit to changing over to clk...
Flashed from my fingers to your face
raven_raven said:
Hi. Maybe few words about me first. I'm not a developer, I don't know how to do it and I have to ask more experienced users. Ok that's it, to the point now. Ah, and I didn't know if this thread was proper to be posted in Development sub-forum, so it's here. If it was possible, if the thread meets requirements to be there, maybe it's possible to move it there? I'm not sure how many devs visit those section, so obviously there is greater chance for finding an answer there, but again, I wasn't sure if it was right.
While I was a G1 user one genius known as "Firerat" created very nasty script - it allowed users to manually, by simply creating a .txt file on sdcard with proper values and running a .zip from recovery, resize partitions like /system, /data and /cache on the phone. I don't know if you're familiar with G1 stuff, but previous there was only one way to chage partitions and it was achieved by custom SPL called Haykuro SPL. This modification (MTD part hack) was created because of need for even more space on /data and allowed to shrink /system and /cache to smallest value possible, so /data took up as much space as it was possible. Here is source thread in G1 Development section:
http://forum.xda-developers.com/showthread.php?t=717874
There you can dive in details, because my knowledge and understanding in this things end very quickly .
On HD2, we have come a great way. From pure Windows Mobile, it was possible to run Linux kernel from sdcard by HaRET.exe, then run Android. After few month team of gods gave us MAGLDR, a tool that allows us to replace Windows Mobile from NAND with Android system. Then after few more weeks someone made Clockworkmod Recovery possible, giving us posibilty to create partitions on sdcard, do a nandroid backup/restore. But one MAJOR thing wasn't done as it should. Recovery in theory should give us possibility to flash ROMs from sdcard without need of computer. And theoretically it's possible, but... Yes, you have to have proper partition configuration flashed by DAF.exe with PC before. Imagine what a great obstacle it is for diagnosed with ORD!
Now you realise what I'm talking about? Combine these two things and bam! I'm just asking, just giving you an idea. Maybe it is possible to adapt those scripts to HD2 and replace old habits (flashing recovery by DAF.exe on PC) with simple script and one .txt file!
Again, maybe it's not possible since we are still using old SPL from WM times. Maybe MAGLDR is build in such way that those scripts are not possible. Maybe there is a thousand reasons... but I've never seen such an idea.
So please, is there one person who are good in this stuff and can explain me wether it's possible or not?
So maybe I can rest assured that I have to cure my ORD
OR
we can move on to work on making this idea reality .
Click to expand...
Click to collapse
Hello raven_raven,
This is indeed a good idea and can make our HD2 PC independable. I will support you as much I can.
Though I have some questions for you.
Q1: Is it possible for this script to brick our device?
Q2: Can we choose the partitions which we resize (for example I would like to resize only /system, /userdata and /cache and leave the others as is) and if yes the other partitions /boot, /recovery will be formated or data will be kept as is?
Q3: What the bootloader has to do with it?
Q4: What SPL has to do with it?
For your knowledge in HD2 their are 2 bootloaders, MAGLDR and cLK (cedesmith's Little Kernel) which makes HD2 a native android device.
In MAGLDR partitions are made along with the flashing of CWM with the help of DAF.exe
In cLK partitions are directly managed by the bootloader when flashed.
malybru said:
On a serious note, though, have you looked at clk? It is supposed to be useable without a pc. Therefore you can configure the partition on your phone. Is my understanding of that correct?
Maybe T-Macgnolia can explain this better than I .
I'm still trying to get my head round it, before I commit to changing over to clk...
Flashed from my fingers to your face
Click to expand...
Click to collapse
Tried cLK, but it can't change partitions as you would like it to, you can't change it on the go without PC.
zach.antre said:
Hello raven_raven,
This is indeed a good idea and can make our HD2 PC independable. I will support you as much I can.
Though I have some questions for you.
Q1: Is it possible for this script to brick our device?
Q2: Can we choose the partitions which we resize (for example I would like to resize only /system, /userdata and /cache and leave the others as is) and if yes the other partitions /boot, /recovery will be formated or data will be kept as is?
Q3: What the bootloader has to do with it?
Q4: What SPL has to do with it?
For your knowledge in HD2 their are 2 bootloaders, MAGLDR and cLK (cedesmith's Little Kernel) which makes HD2 a native android device.
In MAGLDR partitions are made along with the flashing of CWM with the help of DAF.exe
In cLK partitions are directly managed by the bootloader when flashed.
Click to expand...
Click to collapse
A1: No, it is not possible. Firerat is genius and he does masterpiece of scripting, those scripts are 100% safe. It will of course break you ROM, but simple nandroid backup/flashing a new ROM will fix it.
A2: We resize /system, /data and /cache. You simply put two values in text files, i.e.:
Code:
mtd 130 2
First number is how many mb you want to spend on /system, second on /cache. Rest of internal memory is used by /data. /boot and /recovery are not touched by this script.
A3: I don't know for sure, just connected it to Haykuro SPL, which also changed partitions back then.
A4: Don't know for sure, I'm simply intermediate in this stuff, just wanted to pass an idea, I don't have required knowledge and experience to make this idea come true.
I know that there are 2 bootloaders, but I don't know how they work and how far you can modify partitions from recovery by using each of them. HD2 obviously isn't a native Android phone and regarding that either this idea may be impossible to implement or has to be completely redesigned. I really don't know .
Just wanted to pass an idea, but I'm terribly dissapointed how little response I received...
Well you would have more people responsed if you were posting in development forum under the label [call for development].
cLK is modified "little kernel" for HD2...
since there is no danger of bricking our device I am going to test it and report.
Sent from my Nexus One using XDA App
zach.antre said:
Well you would have more people responsed if you were posting in development forum under the label [call for development].
cLK is modified "little kernel" for HD2...
since there is no danger of bricking our device I am going to test it and report.
Sent from my Nexus One using XDA App
Click to expand...
Click to collapse
Great thing to see that someone tries. Be warned though, I'm not responsible for any data loss and damages or whatever, as always . Please be sure that you read original thread and understood how this script is working.
Maybe I'll ask a mod to move this thread to Development section...
raven_raven said:
Great thing to see that someone tries. Be warned though, I'm not responsible for any data loss and damages or whatever, as always . Please be sure that you read original thread and understood how this script is working.
Maybe I'll ask a mod to move this thread to Development section...
Click to expand...
Click to collapse
Yeah i did, don't worry about it.
I have read the original thread, i have compared the different devices mount points (as much i could) and conclude that is the same.
What i have also noticed is that kernel must be patch in order for this script to work and the script checks for a specific bootloader? I'm not sure, i need to restudy that thread.
Anyway, I tried using the script but didn't happen anything.
I formated all partitions except /boot and /recovery
I first created the mtdpartmap.txt in SD root and flashed via CWM the script FR-recovery-v1.5.8-CustomMTD_S.zip
Then reboot and again to recovery
Flashed ROM and then flashed FR-boot-v1.5.8-CustomMTD_S.zip
Reboot to ROM worked fine.
I run terminal
#df
Sizes where the same as before
Exactly, first you apply new partition map to recovery, next you install ROM in those new partitions either by flashing or nandroid backup-ing, then patch kernel to work with this new layout.
Huh, it would be too easy to simply run it and bam! it works. Even Firerat made different scripts for different devices. I'm curious what's the problem. Is recovery on a different level than those in native Android devices, which means that it can't change partition size? Or is it just problem of adjusting script to HD2 like it was done for Hero or Evo? I wonder if Firerat would like to investigate, but it would be impossible to achieve it without HD2, and from what I know he does not have one.
What person should I ask to move my thread to another section?
raven_raven said:
Exactly, first you apply new partition map to recovery, next you install ROM in those new partitions either by flashing or nandroid backup-ing, then patch kernel to work with this new layout.
Huh, it would be too easy to simply run it and bam! it works. Even Firerat made different scripts for different devices. I'm curious what's the problem. Is recovery on a different level than those in native Android devices, which means that it can't change partition size? Or is it just problem of adjusting script to HD2 like it was done for Hero or Evo? I wonder if Firerat would like to investigate, but it would be impossible to achieve it without HD2, and from what I know he does not have one.
What person should I ask to move my thread to another section?
Click to expand...
Click to collapse
Well, I guess Firerat need to come by and post a thread in HD2 Dev forum since it is his work.
He could ask what info he needs for the HD2 such as partition layout and filesystem in each partition etc... I am sure many people are willing to help with that.
I also think that SPL is locking the partition tables (not sure) and the way we are flashing just overcome that. Else when i used the script should have f**cked up my partitioning.
You can ask an HD2 moderator to move this thread but first ask for Firerat permission.
So I found this interesting read. I don't recommend attempting doing any of this until you get a full grasp and I am even hesitant on my Dinc as I've read that messing with partition sizes will lead the bootloader overriding it. I could be wrong though and this is still worth a read.
Basically you can use Linux Volume Manager to use the existing partitions and make a pool to share among partitions. Not sure if it can add /data/data to the pool. If it can then I found a true fix to the /data/data issue. If not at least system could be resized and avoid symlinks or cache could be shrunk and added to /data. It looks complicated but read the link below if you feel technically inclined but a warning not to try anything on this device just yet.
http://forum.xda-developers.com/showthread.php?t=1656794
Jeebus, that's brilliant!
For anyone thinking about tinkering with this: This requires a replacement boot/kernel and recovery with LVM support compiled in. If you're not already comfortable building kernels and recovery images, don't do anything for now.
It makes perfect sense though, especially if all the phone's flash is homogenous. According to this, the Galaxy S used different flash for /data/data than the rest of the phone for speed. With heterogeneous flash it'd still be doable, but it would require some fine-tuning to prevent performance problems.
Beyond that though, I can't see why /data/data and /cache couldn't be added to the pool. Heck, /emmc could be added to the pool too!
This doesn't alter the original partition layout -- it merely allows for pooling all the storage and repartitioning out of that pool.
ardax said:
/emmc could be added to the pool too!
Click to expand...
Click to collapse
Now THAT would be amazing. Talka about really solving 'low on space' problems!
musical_chairs said:
Now THAT would be amazing. Talka about really solving 'low on space' problems!
Click to expand...
Click to collapse
Yeah
Sent from my 1st Gen Droid Inc on Pons CM10 using xda app-developers app