hi,
it is commonly known that wm5 compaction problems in hx4700
are due to very slow ROM type which use NOR gates instead NAND.
does anyone here tried to find another ROM chip which could
suit hx4700 and be NAND type?
could it be possible or due to hardware architecture or any software
reason it is hopeless?
ok, i've found this: link
[cut]
Okay, so let's talk about NAND and NOR. These are the two main types of ROM. They're largely used the same way, and everything I've said about ROM is true of both of them. So, for the most part, you don't need to care which kind you've got. But I'll tell you about them anyway.
NOR: Faster to read, slower to write.
NAND: Slower to read, faster to write.
This is all relative. Both are considerably slower than RAM. There's one very important difference in these technologies. NOR lets you do something we call "execute in place" (XIP). Remember what I said before. To run a program, you first load it into RAM, and then you run it from there. NOR lets you run the program directly from the ROM without loading it into RAM first. This means that you can have a system with less RAM. Note that this only works for programs. You can't XIP a picture or an audio file. NAND typically compensates for not being able to XIP with price. (NAND tends to be cheaper.)
Because NAND is faster to write, and NOR is faster to read. The ideal system would have 64M of NOR and 64M of NAND. It would store all the programs in NOR and store all the user data in NAND. Since it would XIP all of the programs, it wouldn't need 64M of RAM and would drop back down to 32M, thus saving power. XIPing also means faster application load times, since you don't have to load the program into RAM before running it. A device like that would rock.
[cut]
and as i remember XIP has sth to do with cooking. does it means that change of ROM from NOR to NAND would require to patch XIP or do
some engineering on bootloader/kernel/whatever?
regards
piotr
dzebrys said:
(...) does anyone here tried to find another ROM chip which could
suit hx4700 and be NAND type? (...)
Click to expand...
Click to collapse
Peter, do you have a bug in my house? Today I told my wife if someone to think up a chip you talk about then it will be bought by thousands of hx4700's users
[Update]
The explanation is in the answer of Mike Calligaro (Microsoft's guy):
"As for having a single image for both the x50v and the x51v. If one has NAND and the other NOR, that won't work. The filesystem drivers need to be different for NAND and NOR devices, so an image for one won't work on the other."
So we can forget it. Unless someone will write a proper drivers which would be miracle equal
regards
piotr
Click to expand...
Click to collapse
Regards,
Piotr
Ps. Are you another Peter or it is me, Mr. Hide? - Hehehe.
what about disconchip
Umpal said:
The explanation is in the answer of Mike Calligaro (Microsoft's guy):
"As for having a single image for both the x50v and the x51v. If one has NAND and the other NOR, that won't work. The filesystem drivers need to be different for NAND and NOR devices, so an image for one won't work on the other."
So we can forget it. Unless someone will write a proper drivers which would be miracle equal
Click to expand...
Click to collapse
further in comments there is also sth like:
"Most of WM5 smartphones now use diskonchip as ROM. However, diskonchip is actually a NAND-based flash memory with NOR-like interface."
now i have my board at RAM upgrade. the donor is mb from qtec 9090.
as i remember there is diskonchip ROM. at hx4700 there is 198MB of ROM
and it is formed by 2 intel's chips. maybe it's worth of digging...
/piotr
The real killer for NOR flash devices is the erase time - the relative read and write times are not really significant.
According the Mike Calligaro blogs neither the hx4700 or the X50V was doing XIP in WM5 as this requires Intel Storage Manager which he claimed was not present.
His analysis was the block size was larger than the MS recommendation. The erase time is crucial as flash has no rewrite function so if a block is changed it is written to a new block and the old block marked for erasure. The erase operation prevents access to the memory for the time of the erase.
The smaller block size means that the filesys thread needs to run (especially "emergency" runs when spare blocks get critically short).
In his analysis he never said that there was any good reason why WM5 devices should not use NOR flash.
And everyone tends to assume that filesys does not exist on NAND flash devices - it does but the erase operations are faster.
Just thought this might be useful to some of the newer users, a list of what I see as the most commonly asked questions, and some misunderstood terms.
What is the difference between Nand, Haret and SD:
Nand; refers to the devices internal memory, which is NAND Flash memory, and is used to hold what is commonly called 'a ROM'. It is this memory which holds the Operating System, and can be 'Flashed' to change the data on it, once flashed it is persistent in memory, meaning that if you remove all power sources it will not lose this data, this is also known as 'Non-volatile Memory'. Nand Flash refers to a specific type of Flash memory, and gets it's name from the way the memory cells are constructed.
SD; Refers to the MicroSD cards we use in our devices, these are also Nand Flash but typically have slower transfer rates than the Nand Flash we have inside the device. typically used to store data, they can also be used to store the Android OS when used with Haret installs.
Haret; often confused with SD. It actually refers to Haret.exe, which is a program used to launch Linux systems from within another OS, such as Windows Mobile, think of it as a Virtual machine system, which allows users to run another OS. In our case, Haret refers to running Android within WM, it does not replace WM in Nand ROM, it does replace it in RAM however, but only until powered down, after that WM will boot from Nand next time the device is powered on.
What is my Panel Type?:
Panel; This refers to the actual LCD panel hardware, there are 3 types in use on Kaiser, and although Type2 seems most common, there are also Types 1 and 3. When running WM the panel type is autodetected and the correct settings are used for the display, however Android has no autodetect, so we must tell the OS which type we are using at boot, in Haret installs this is done with a line in Default.txt, in Nand it is set in the NBH we use to flash the kernel and other boot files needed to run Android. Display issues such as odd pixel colouration, streaks or lines on the display, white screen when exiting sleep, and other noticeable display issues can usually be cured by changing the panel type.
Other useful terms:
NBH; This is the file extension of a file intended for flashing to Nand, most commonly used to flash WM or Android, it can also be used to flash radio or splash screen.
Bootloader/tricolour screen; Both are the same, it refers to the screen display you get if you hold the camera button, and press power, on this screen are a few useful pieces of information, device type, (e.g KAIS130), SPL version, (e.g SPL-3.29.Hard), in the bottom white area it will say 'serial' or if connected to a PC, 'usb'. Remember to remove the SD card before entering Bootloader mode, as the bootloader also scans the SD for a file called KASIimg.nbh, and will run the updater utility if one is found.
HardSPL; This is a specially designed SPL that allows us to flash the Nand with an NBH file that was not signed by HTC, it also prevents itself from being overwritten, so that it is usually possible to reflash as long as we can get into Bootloader mode, this means we can, ( usually ), recover from a bad/corrupt flash.
Build and ROM; In WM terms, a ROM usually refers to a complete, ready to install, single file NBH, custom version of WM. However with Android we do not use the single file approach, and therefore we do not usually use the term ROM. Build is what we usually call a custom Android install. This is roughly equivalent to the WM 'cooked ROM', since each build is designed and built in a particular way, and may be any of the different android 'flavours'.
Flavours; Mostly used to describe the versions of android, these are, in historical order
1.1 - un-named, released feb 2009
1.5 - Cupcake, released april 2009
1.6 - Donut, released sept 2009
2.0/2.1 - Eclair, released as 2.0, oct 2009, and as 2.1, Jan 2010
2.2 - Froyo, released may 2010
3.0 - Gingerbread, scheduled release date, sep-dec 2010.
Odex'ed: As stock, android builds are odex'ed. Odexing involves generating an odex file for each app, which slightly lowers the memory used by the system, and may also speed up execution of apps, the downside is that it is difficult to modify odexed builds in order to tweak or theme them.
DeOdex'ed: a deodexed build is one in which the odex files are moved into the apk's, which slightly increases the memory used by /system, but allows modifications and tweaks to be used.
Deodex Vs Odex: Odex uses less space in /system, boots quicker, especially the initial boot after installation, however themeing is impossible, and various tweaks and modifications probably won't work. Deodexed uses more space in /system, has a slower initial boot, subsequent boots are much quicker, but may be a little slower than odexed, theming is a lot easier, as are modifications and tweaking of the build. ( most custom builds are deodexed due to the ease of theming and modifying ).
Bootsplash/Bootanimation:
The bootsplash is the static picture that appears as soon as you boot the device, usually is stays for 20 seconds or so before being replaced by the scrolling text showing Linux is booting.
The Bootanimation is the animated screen you see after Linux has booted, and usually loops until Android is loaded.
Sim Pin/SIM lock:
SIM Pin is often confused with the SIM lock, the SIM pin is the code you have to enter before using the phone when you start it up, this code is stored on the SIM card itself, and until recently caused a lot of problems, since Android could not decode it properly, this has been fixed in some flavours, Eclair and Froyo, but is still an issue in older flavours, such as Donut.
Sim lock also known as provider lock is a method used my phone service providers to ensure that you only use their service by locking the phone so that it only accepts that providers SIM cards, this lock code is stored on the phone, and may be unlocked by entering a code, or by bypassing it using unlocking software, once unlocked the phone will accept any other providers SIM card.
PUK the PUK is the Personal Unlock Code, and is a code that unblocks a SIM that has been blocked by too many unsuccessful attempts to enter the Sim Pin code, ( usually 3 attempts), this code must be entered to unblock the SIM card, usually the PUK is provided with the SIM Card, however if it is lost then some providers may give you the code, if the SIM has been registered by you.
Please feel free to add to this
Back to Windows Mobile:
If you need to reflash Windows Mobile, for whatever reason, these are my preferred methods:
I recommend using a Card Reader and MicroSD adaptor for working with SD cards, it makes life so much easier than relying on the kaiser to transfer and rename files, since most of us are used to handling files in Windows.
Method 1
1. Download a Stock shipped ROM, do not go crazy getting the latest custom 6.5 ROM, in my experience these often cause problems, if you want to go to Custom ROM's then flash stock first.
2. Extract the RUU_Signed.NBH file from the .exe, ( I use 7zip for this, but other archive utilities my work, winzip, winrar etc), rename the file to KAISimg.nbh and copy to the root of a freshly formatted SD card.
3. Insert the SD card in your Kaiser, pres and hold camera button while pressing power, ( you only need to press power briefly, but keep the camera button pressed until you see the tricoloured screen).
4. Once you get the tricolour screen, ( bootloader ), it should change to a grey screen with blue instructions, basically, press the power button and let it flash.
5. Once flashed, simply pull the battery/press reset and let it go through the first boot process.
Troubleshooting
Common problems with this method are that it will just not recognise the flash file, leaving you at the bootloader screen, this is usually caused by wrongly formatted sd cards, the card must be formatted FAT32. Other reasons are file name issues, make sure you have not accidentally mistyped the filename, or renamed it as kaisimg.nbh.nbh.
Method 2:
If Method 1 fails then the alternative method is USB flashing:
1. Disable Activesync, by unchecking the 'USB' option in Connection settings.
2. Remove the SD and SIM cards from the Kaiser.
3. Press Camera+Power to enter Bootloader.
4 Connect the usb cable, ensure that is says 'USB' at the bottom of the screen.
5. Flash the Stock ROM, usually by double clicking the downloaded stock ROM exe file, allow it to flash, and wait until it is finished before removing the USB Cable.
Troubleshooting
There are a few potential issues with this method also, if this method fails try another stock rom, the last shipped ROM from HTC was Kaiser_HTC_ASIA_HK_WWE_3.34.721.2, this is a generic stock 6.1 rom and should be compatible with most if not all kaiser variants.
Useful Links:
ThoughtlessKyle's Why my Wifi doesn't Work Invaluable Information on recent WiFi Issues, A 'Must Read'......
LCD Panel Information
Tinboot thread ( the thread that launched Nand flashing on kaiser ).
SuperJMN's Android Issues roundup thread ( common problems, as yet unsolved )
Adding language support
Miscellaneous Notes.
Radio Version
Just as in Windows Mobile, Radio Version seems to play as vital a role on Android.
There are a number of problems that may be related to radio version, and just as in WM, the effects are sometimes surprising.
Audio: yes, just like WM the wrong radio version can cause audio issues, ranging from no audio, to more subtle issues such as call audio not working, even though all other audio events work fine.
Wifi: no surprise really, the radio stack controls wifi as well as the more common phone/network activities.
Data/Network: Obvious one, but there are a number of complicating factors here too, geographical location seems to affect radio version, for instance, in the USA, 1.71 radios may offer the best signal, and data rates, while in Europe, using 1.71 may cause a lot of 'No Signal' issues, where the phone seems to drop off the network, the solution is usually an older radio version, in the UK 1.65 seems the best choice for most users, I have also had reports of 1.65 being the best for South Africa, Asis, while Australia seems to do better on 1.70 or 1.71. This may be due to the technology in use in those countries.
GPS Maybe, not sure about this one, had at least one report that a radio downgrade from 1.71 to 1.65 seemed to help with GPS, as far as I am aware the GPS and the Radio stack are not related, but who knows for sure?
Great guide! I was thinking about making similar one myself, but couldn't find free time
I'll maybe try to add something this weekend
hello maybe a stupid question
what is the differents between odex and unodex
sorry for my bad english
kisses
Rose
Not sure if this is a general dumb newbie question but I'm having it across different Android builds. Occasionally I have to reset the phone without shutting Android down. When I restart, any apps that were running at the time have to be uninstalled and re-installed because they now crash on startup (with a "program has stopped working" error.) Is there anything I can do about this?
CassandraN said:
Not sure if this is a general dumb newbie question but I'm having it across different Android builds. Occasionally I have to reset the phone without shutting Android down. When I restart, any apps that were running at the time have to be uninstalled and re-installed because they now crash on startup (with a "program has stopped working" error.) Is there anything I can do about this?
Click to expand...
Click to collapse
Not really a dumb question, however it depends how you are resetting, the reset button is a bad idea, Battery Pull is the preferred method, ( say it with me class, 'Battery Pull Good, Reset Button Bad' ).
However, why do you have to reset without shutdown? This often leads to data corruption, since the OS does not get a chance to synchronise properly before it closes, ( not that a battery pull should be any better, but for some reason it seems to cause fewer problems than resets).
Thanks for the FAQ, it is extremely useful to noob or semi-noob like I am.
Thanks, that's why I decided to start it, and if one person finds it useful, it was worth it
say it with me class
Click to expand...
Click to collapse
This is just hilarious
BTW, I tried some of the reboot apps in the market, non of them seemed to work (on 2.1)
the original reboot menu that you get when you hold the power button did not work at all. it just hangs on the loading circle.
In Froyo however, things are a bit different. the reboot option shuts downs the device instead, I did not try any reboot app yet
Any ideas about this zenity?
zenity said:
Not really a dumb question, however it depends how you are resetting, the reset button is a bad idea, Battery Pull is the preferred method, ( say it with me class, 'Battery Pull Good, Reset Button Bad' ).
However, why do you have to reset without shutdown? This often leads to data corruption, since the OS does not get a chance to synchronise properly before it closes, ( not that a battery pull should be any better, but for some reason it seems to cause fewer problems than resets).
Click to expand...
Click to collapse
I usually battery pull (I lost my stylus and the cheap replacement won't fit in the reset hole ), but I still seem to have problems.
I think my problems are due to a rogue app eating all the CPU. My suspicions are Twitter or Swiftkey. The phone becomes so unresponsive that sometimes a hard reset is the only way to make it useable again. I'll try to avoid it in future if I possibly can.
Tried taskiller? Useful for watching your memory, and killing tasks if needed, osmonitor is also useful for, well monitoring the os
I have noticed that the system does get very unresponsive at times, and it usually means low memory, try an eclair build if you are using a CM6 based one, I usually get about 30+Mb free in normal conditions, and if things start to get too slow, well a tap on the taskiller widget sorts that out
@Duke911:
As far as I am aware there is no real reboot option, in any build, I think it's a kernel issue, or perhaps just not implemented correctly, the safest option is a power off, which performs a proper shutdown, I do know there have been a few issues with data corruption that may be associated with using reboot, or the reset button, since these may cause the system to shutdown to rapidly to sync any data that may be cached, it's similar to pulling an SD card out of the computer, there may be data left unwritten in cache, which is why there is a nice safe removal option
This is a cool wiki for Kaiser Android users! Thank you!
By OP request, I am making this thread a sticky and making some adjustments to the forum. Please PM me if you have any requests. Thanks.
Precious work, Zenity!!!
video call anyone?
Is there any chance of getting a build to support video calling?
Video calling will need working front camera driver at least, which is not supported yet, I do not know if anyone is actively working on this, however, at some time, someone will take up this challenge, just as they have with other things which did not work previously
Sent from my HTC Dream using Tapatalk
hello..
I just want to ask about polymod and cyanogenmod.
what is the function, are they different from eclair or froyo?
thanks ^^
CyanogenMod builds are all Modifications of base android releases, these are complete rebuilds of the system, and include many improvements over the original release.
Polymod is an Eclair Mod based on OpenEclair 1.3 and is modded in a different way to Cyanogen's methods and style.
Most Eclair and Froyo builds are ports and modifications of Cyanogen bases, ( in fact I don't think there are any Froyo builds that are not CM6 based).
For Donut things are different, most builds are modifications and ports of official releases, such as Myn's Warm Donut.
I have been following the xda-developer website for awhile now, as I have a KIN 2m of my own and I have been interested in finding a way to root or replace the current OS with a new one. Since I haven't seen anymore progress with the phone itself, I decided to do some digging and see what I could do myself (I am a programmer and IT Specialist). What I found might be helpful.
According to other posts, and what is floating around the internet, the KIN 2m flash memory is based on the Samsung MoviNAND 8G architecture. The chip itself is the Samsung MoviNAND KLM8G4DEDD-B101 which supplies 8GB of flash memory to the phone. Since this is also a Flash based NAND memory, I decided to investigate into the actual filesystem (FS) which makes up the chip and which WindowsCE 6.0 is based.
Apparently, this particular NAND memory is based on the YAFFS2 (Yet Another Flash File System rev2.0) which supports both little- and big-endian (32 and 64-bit architecture and some 16-bit systems), respectively. Also, the operating systems that are built on this particular FS are WindowsCE, Android, Linux, pSOS, eCos, and ThreadX.
Going off what I had found, I discovered that with regard to WindowsCE in particular, there are four different parts to the KIN NAND set-up: A Portable YAFFS "Core", a YAFFS Direct Interface, the WindowsCE wrapper, and then of course the WindowsCE OS itself. For WindowsCE, the WindowsCE wrapper accesses the YAFFS Direct Interface, not the core directly. In order to write instructions to the NAND and the "core", a set of instructions in three different types are necessary. These types are a POSIX Application Interface, an RTOS Integration Interface, and finally Flash Configuration and Access Interface. I have attached (and pasted) below a diagram of the above description and I have attached a document which was provided by yaffs.net which also covers some of these details.
View attachment 1461518
The POSIX Application Interface allows execution of application code to access the filesystem. These commands that are executed are typically open, close, read, write, etc. The RTOS Integration Interface consists of functions which allows for YAFFS to access the RTOS system resources. The commands are things like lock, unlock, initialize, get time, set error, etc.. Finally, we have a Flash Configuration and Access Interface which allows YAFFS to access the NAND directly and it executes commands such as initialize, read chunk, erase block, etc.)
So this is what I have discovered so far, and I am currently working on seeing where I go from here. I am currently trying to mount my KIN and browse it as a YAFFS filesystem on my computer, and once I do that, I am thinking that I might be able to execute instructions to access the ROM and NAND chip. On the YAFFS.net website there are a lot of good documents on how this FS works and how commands are executed. I am currently trying to read all I can and see if there is anything I can do.
And the plus side is, after all of this digging and experimenting...my KIN still works!!
very interesting.
wouldn't instructions be executed on the ARM?
http://en.wikipedia.org/wiki/ARM_architecture#Instruction_set
the trick would just be getting something on there and running...
Edits:
actually we may have already found a way to execute. it involves XNA or Silverlight and its on these forums somewhere. now compiling something...
must note that this could probably end very poorly.
so how we write android to NAND?
http://source.android.com/
BOOM
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0290g/DDI0290G_arm1156t2fs_r0p4_trm.pdf
if we can access a console on the actual kin device we can compile code. now, how exactly we could do that is a mystery to me. the kinOS is running on top of windows CE kernel, so there may be one in there...
that console would be "run23"
http://support.microsoft.com/kb/194302
http://developer.download.nvidia.com/tegra/docs/tegra_250_hw_setup.pdf
check out page 12. to put the kin in recovery mode, you hold u+s+b+power.
also relevant
http://forum.xda-developers.com/showthread.php?t=894130&page=2
BOOM
infocenter.arm.com/help/topic/com.arm.doc.ddi0290g/DDI0290G_arm1156t2fs_r0p4_trm.pdf
if we can access a console on the actual kin device we can compile code. now, how exactly we could do that is a mystery to me. the kinOS is running on top of windows CE kernel, so there may be one in there...
that console would be "run23"
support.microsoft.com/kb/194302
Click to expand...
Click to collapse
That is a good thought. However, according to what I have found, there is no reason to go looking for a console on the device itself with which to compile/execute code. What I have found, to date, is that because the device is a YAFFS filesystem, if we have the correct drivers installed on our host machine (which can be gained from the internet), we can mount the device as a drive and using Command Prompt on the host machine we can compile and execute the code from there. We can use the commands NVFlash, mount, write, flash_eraseall, etc.
Sorry if this doesn't seem to make an sense at the moment...I am trying to multitask, and I believe I am failing miserably. I will hopefully have more information later.
IT_Tech said:
we can mount the device as a drive and using Command Prompt on the host machine we can compile and execute the code from there. We can use the commands NVFlash, mount, write, flash_eraseall, etc.
Click to expand...
Click to collapse
ooh, that's a good one. i think JohnKussak was doing something like that using the NVidia tegra toolkit, but he was not able to connect for some reason.
http://forum.xda-developers.com/showthread.php?t=894130&page=2
now, from what i understand of YAFFS (which is admittedly very little) it's just a partition of the memory right? or is the YAFFS system on a completely separate piece of memory?
i was reading about the MPU (memory protection unit) in the ARM manual and it described the layout of memory. basically it supports up to 16 blocks, all with 32 bit addresses (4294967295 bytes = 4gb). since there's 8 gb of storage on the kin, it can probably be assumed that 2 of those blocks are used for storage. another block is probably for RAM (256mb). now, the YAFFS system has to be accessible to the ARM somehow (maybe), so there are several possibilities.
1) the YAFFS file system is on a partition of the 8gb storage space
2) the YAFFS file system is on a partition of the 256mb RAM (pretty sure this isn't the case)
3) the YAFFS file system has its own block of memory
regardless, the MPU can be disabled. when it's disabled, no permissions are checked (ever) and we can read/write anywhere we please, including the YAFFS, wherever it may be. i'm not totally sure this is necessary, but i know we've had problems accessing system folders in the past. i suspect disabling the MPU could fix that, if we could manage.
i also suspect that the YAFFS is accessible when the phone is in recovery mode (u+s+b+power), we just need the correct drivers to flash a Tegra 2600 APX chip. i believe i read on the tegra thread that somebody couldn't find that particular driver. it may need to be written.
edit:
just found this https://developer.nvidia.com/tegra-2-technical-reference-manual
you have to apply for access and it can take up to a month i guess. i'm working on that right now. the main item of interest is "16.0 NAND Flash Controller". i'm gonna try looking in some shady places and see if i can't dig that up...
double edit:
just realized that tegra 2 is different than tegra APX, NVidia does not offer an APX manual anymore, if they ever did.
triple edit:
ooooookay. http://viewsonic-gtablet-for-dummies.webs.com/nvflash.htm
just grabbed source for drivers. unfortunately, NVflash does not run on 64 bit systems, which is causing a bit of problems for me...
slimeq said:
now, from what i understand of YAFFS (which is admittedly very little) it's just a partition of the memory right? or is the YAFFS system on a completely separate piece of memory?
Click to expand...
Click to collapse
From what I understand, YAFFS is a partitioning system. It does not need to be stored as a separate system on a separate piece of memory. However, it does also have the capabilities to be partially RAM based... Which may end up confounding things. If you get a chance, you may have done this already I don't know, but read up on the YAFFS file system on the yaffs.net website--it has a ton of documents on how the system works and the commands it executes, its architecture, etc.
slimeq said:
i was reading about the MPU (memory protection unit) in the ARM manual and it described the layout of memory. basically it supports up to 16 blocks, all with 32 bit addresses (4294967295 bytes = 4gb). since there's 8 gb of storage on the kin, it can probably be assumed that 2 of those blocks are used for storage. another block is probably for RAM (256mb). now, the YAFFS system has to be accessible to the ARM somehow (maybe), so there are several possibilities.
1) the YAFFS file system is on a partition of the 8gb storage space
2) the YAFFS file system is on a partition of the 256mb RAM (pretty sure this isn't the case)
3) the YAFFS file system has its own block of memory
Click to expand...
Click to collapse
Let me begin here and differentiate between YAFFS types...there are two types of YAFFS formatting--YAFFS1 and YAFFS2. The KIN is formatted using YAFFS2 because it has 8g of space. Yaffs2 is different from Yaffs1 in the fact that it allows for memory sizes greater than 4GB because it supports 4KB pages rather than 512byte pages (Yaffs1). I will spare all the details as they are lengthy, but check out:
yaffs.net/documents/how-yaffs-works and yaffs.net/yaffs-original-specification (paying attention to Yaffs2 and how it relates to it foundation off of Yaffs1). Also, since Yaffs only uses a RAM based system for emulation purposes when the kernel is not being run on a true NAND (or NOR) storage, we can eliminate Option 2. Option 3, may be viable, but I am not sure as to how. Option 1 seems to make the most logical sense (pun intended), because of how the YDI (YAFFS Direct Interface) works with the YAFFS kernel and filesystem, as well as the WindowsCE Wrapper, etc.
Now as for the MPU. Yaffs has a built in code to handle MPU and a way to disable it through a console session on a host machine, but I don't remember where I read it, I believe it was on the yaffs.net website in one of the technical documents... I will work to remember where I found it.
I hope we can get some more people on-board helping with this YAFFS thing. If we could, it might make this go a bit faster, and have more heads working on it. Plus they might see something we don't.
P.S: These are the HARDEST captchas I have ever seen in my entire life!
kin
Hopefully you get access to the filesystem with this IT_Tech :fingers-crossed:
Every once in a while, it's fun to revisit Dev on the Kin
I remember going through the Tegra 2500 APX links on the wayback machine:
http://web.archive.org/web/20100813070722/http://www.nvidia.com/object/product_tegra_apx_us.html
If you click the Specifications tab, you can see that the 2600 and 2500 are virtually identical, aside from some video features.
Also, the ZuneHD is the only other product listed as using the 2500 chip. I don't have one, so I wouldn't know for sure, but I wonder if its drivers could be tweaked to allow access to the Kin, in the same way as the Zune. I remember trying to hack into other Windows Mobile drivers (for other WinMo 6.x devices I have) but never getting anything further, even when in other USB modes on the device.
Hi
Before someone say it, yes, i know that in a nand doesnt matter if the files are or not fragmented. But i had read in some other places in the internet that it actually comes to a decrease in performance when its fragmented... If its a fact or not i dont know...
But i have a lot of apps that havent been updated in a while, and im concerned about my phone become slow...
So my question is:
if a make a nandroid backup and flash and restore (in case it become slow), this restore puts all the files defragmented? Or it just do an exact image of all the things including their location (some parts here other there...)?
Thanks
According to http://www.wizcode.com/articles/comments/flash_memory_fragmentation_myths_and_facts/:
Myth: Flash cards unlike hard drives do not have movable parts so defragmentation is useless.
On theory, since a flash drive does not have moving parts, its access time is independent on where the data is stored, which is why supposedly flash drives don't need defragmenting.
The fact is that flash memory is physically organized in blocks (or pages) of data, usually 128K or 256K large. Things get even worse from the fact that in order to change even one single byte, the entire page has to be first erased and then re-written with its contents again. In our example the time needed to change one byte of information is calculated the following way:
T = R + E + W
T is the total time, R is the time needed to read the entire flash page containing the byte we wish to change, E is the time required to erase the page and W is the time it takes for the data to be written back to the empty page. Not only we had to read 128KB in order to change a single byte but we also had to erase the entire block (which is very slow) and then write 128KB over again.
To complicate matters even further, it must be noted that there are additional layers between the flash card controller and the file system that cache pages being read and written to. The cache serves for improving performance. It is a simple trade-off between read/write performance and some RAM being used to cache the pages. It is most effective to read or write entire flash pages performance wise. When the operating system instructs the controller to read a particular sector on the card the cache normally retrieves the entire block and stores it internally. What this means is that information that is stored in a contiguous matter is more likely to be found in the cache than non-contiguous information.
Suppose we have a file that is 263892 bytes large and is fragmented. On a FAT32 file system using 1K cluster the file will occupy 260 clusters. In the worst case scenario the clusters will be dispersed across 260 different flash pages. If the file is contiguous all 260 clusters will fit inside 3 flash pages. Caching of the fragmented file will be impossible as it won't fit in the cache (260 pages will require 33MB of RAM to cache) while the defragmented file will fit in just 384K.
And finally the FAT file system stores folders the same way files are being stored - in cluster chains. A large folder that is fragmented and is not cached represents a huge performance penalty for standard file operations like listing the files in that folder, renaming or even deleting a file.
Conclusion: Fragmentation has a serious impact on flash card performance especially during write operations and when the file system is heavily fragmented across many different flash pages.
Click to expand...
Click to collapse
Now, about your question. It would seem logical, as at that time, every partition is written in order, thereby it should be defragmented. During normal usage, you change this here, change that there, thereby different blocks are edited, causing fragmentation.
^^
Hey thanks!!
I supose that this is why explore an album or images cause some lag.
Also, i had noted that not even putting all images in order (contiguous), the cache always creates a lot of chunks...
Using this thread...
I just formatted the sd-ext, and it appears in link2sd as ext2, but i had it as ext4.
Could it lead to problems? Do i need to reformat my sd card with an external reader? Or from the cwm?
Ive restored all my apps and they work, but im not sure...
Thanks