Hi,
I contacted VS support about a problem described here:
http://forum.xda-developers.com/showthread.php?t=933128
They said that they'd rma it, so I should send it to them. They said turnaround was 10-14 days.
I was wondering if anyone has recent experience w them? Are they turning these around in that timeframe, and are the repairs effective?
I can probably be w/o my Gtab, but I'd hate to wait that long and get it back w the same problem!
Thanks,
Jim
Ask if they cross ship?
Did ask, but it wasn't an option.
Jim
Let us know how your experience is. Looks like you get to be the RMA guinea pig.
edit- I'm guessing the RMA is for the flash?
muqali said:
Let us know how your experience is. Looks like you get to be the RMA guinea pig.
edit- I'm guessing the RMA is for the flash?
Click to expand...
Click to collapse
Yes, because of the bad blocks. I'm still debating tho, bcuz I don't have 100% confirmation that the dmesg msg and the inability to nvflash --read partition 11 are correlated, plus my Gtab seems to be running fine so far, other than that ..
Jim
bad blocks in dmesg
So I checked your other thread and decided to dig thru my dmesg since I recently reflashed. I see bad blocks as well allthough most of mine are in cache. I can post those later if you like.
I also have no problems with my tab on vegan but I'm currently running gojimis cm7 so any issues I've been attributing to that.
Could this possibly be the nand controller marking known bad blocks so the os knows not to use them? Kinda like how ssds have an extra amount built in to compensate for wear and
such?
Maybe someone else could check their dmesg and see if they show any errors.
I think later ill try to emulate what you did with nvflash and see what I get.
Nosunshine said:
So I checked your other thread and decided to dig thru my dmesg since I recently reflashed. I see bad blocks as well allthough most of mine are in cache. I can post those later if you like.
I also have no problems with my tab on vegan but I'm currently running gojimis cm7 so any issues I've been attributing to that.
Could this possibly be the nand controller marking known bad blocks so the os knows not to use them? Kinda like how ssds have an extra amount built in to compensate for wear and
such?
Maybe someone else could check their dmesg and see if they show any errors.
I think later ill try to emulate what you did with nvflash and see what I get.
Click to expand...
Click to collapse
My theory is that there are multiple levels of operation, e.g. in Android, the OS has loaded and is looking at the physical media as a yaffs partition, but before that, i.e., when the boot loader is running, it sees the raw media. I don't know enough about Android to know if the bad blocks are visible and at which levels.
Yes, if you have a chance to try nvflash, please post. What I'd be interested in is if you could do --getpartitiontable to get the list of partitions, figure out the part # for CAC, then do --read on that partition, to see if you get read failure.
If you do, you'd be the 3rd person (tcrews and myself), so that would be more evidence that dmesg bad block mags == bad --read.
I have another theory, that maybe some of the 'mysterious' problems that people see like magic # mismatch, etc., may be related.
Jim
Well if im not mistaken cm7 uses ext4 instead of yaffs for atleast the system partition, if thats true then what were seeing is most likely related directly to the hardware.
I'd almost be willing to bet this is the nand controller driver marking blocks that the os cant use, but if its causing problems now or down the road, I don't know.
Its strange that it shows up in the logs if thats the case. I would think this would be obscured from the user and handled by the controller at a hardware level.
I'll post my logs and nvflash findings in your other thread as to not muck this one up to bad, should have them up by tomorrow.
It is why I had earlier wondered if the standard linux command badblocks was available to use before you ran an mkfs. Badblocks will make a log of all the badblocks on a device and that log can be passed to mkfs so that instead of having to wait until you run mkfs to check for bad blocks, you can have already done it(and hopefully gotten your data off too).
http://www.yaffs.net/yaffs-talk-slide-16-ecc
In reading that slide from their site it seems that either the MTD/device or YAFFS can do the ECC. What you're seeing might be the hardware reporting to the YAFFS driver the blocks that are bad so it can do whatever it needs to do to work with it. Of course any disk utility that thinks a reported bad block is a problem will choke.
I'm not aware of any utilities that are like dd but work after the filesystem driver and not on the device itself, but it is quite possible they exist. It is also possible I am completely off base here.
muqali said:
It is why I had earlier wondered if the standard linux command badblocks was available to use before you ran an mkfs. Badblocks will make a log of all the badblocks on a device and that log can be passed to mkfs so that instead of having to wait until you run mkfs to check for bad blocks, you can have already done it(and hopefully gotten your data off too).
http://www.yaffs.net/yaffs-talk-slide-16-ecc
In reading that slide from their site it seems that either the MTD/device or YAFFS can do the ECC. What you're seeing might be the hardware reporting to the YAFFS driver the blocks that are bad so it can do whatever it needs to do to work with it. Of course any disk utility that thinks a reported bad block is a problem will choke.
I'm not aware of any utilities that are like dd but work after the filesystem driver and not on the device itself, but it is quite possible they exist. It is also possible I am completely off base here.
Click to expand...
Click to collapse
I know you suggested running badblocks, but I haven't figured out HOW to do that yet (what command?). Remember that on stock TNT /system is yaffs, and I don't think there's an mkfs.yaffs?
Jim
Oh. badblocks is the command. The syntax you'd want to google the man page. I dont think it is part of busybox, but might ne on the system. If not, the source code is easily compiled.
Nosunshine said:
Well if im not mistaken cm7 uses ext4 instead of yaffs for atleast the system partition, if thats true then what were seeing is most likely related directly to the hardware.
I'd almost be willing to bet this is the nand controller driver marking blocks that the os cant use, but if its causing problems now or down the road, I don't know.
Its strange that it shows up in the logs if thats the case. I would think this would be obscured from the user and handled by the controller at a hardware level.
I'll post my logs and nvflash findings in your other thread as to not muck this one up to bad, should have them up by tomorrow.
Click to expand...
Click to collapse
The thing is, remember I get the failed --read when I do the nvflash --read. At that point, the only things involved are the boot loader code on the gtab end, and nvflash on the pc end, plus I get the same read fail at the same byte count w different nvflash versions (bekit's and nvidia sdk) and both on windows and Linux.
The point is that there is no filesystem involved when the --read fails, so other than some bug in multiple versions of nvflash, or some bug in the boot loader, it has to be a hardware (nand) problem.
Jim
muqali said:
Oh. badblocks is the command. The syntax you'd want to google the man page. I dont think it is part of busybox, but might ne on the system. If not, the source code is easily compiled.
Click to expand...
Click to collapse
Thanks. If 'badblocks' is literally the command name then I don't have it/can't find it, either in TNT or when running CWM (and adb'ing).
If you have a binary that'll work, can you post or PM?
Jim
Yes, a hardware problem was what I was getting at. Usually nand has in hardware remapping but i was thinking since yaffs can also handle it(and all nand has bad blocks), that maybe it was designed to not remap bad blocks. Since nvflash is reading the raw device and not from the yaffs it sees what yaffs itself corrects for when in place. Not sure if i make sense.
Nosunshine said:
Well if im not mistaken cm7 uses ext4 instead of yaffs for atleast the system partition, if thats true then what were seeing is most likely related directly to the hardware.
I'd almost be willing to bet this is the nand controller driver marking blocks that the os cant use, but if its causing problems now or down the road, I don't know.
Its strange that it shows up in the logs if thats the case. I would think this would be obscured from the user and handled by the controller at a hardware level.
I'll post my logs and nvflash findings in your other thread as to not muck this one up to bad, should have them up by tomorrow.
Click to expand...
Click to collapse
You may already know, but you can check what kind of filesystem is used for /system. Just terminal or adb, then type 'mount'. That'll list all the mounts, and show what kind of filesystem is used for each.
Jim
muqali said:
Yes, a hardware problem was what I was getting at. Usually nand has in hardware remapping but i was thinking since yaffs can also handle it(and all nand has bad blocks), that maybe it was designed to not remap bad blocks. Since nvflash is reading the raw device and not from the yaffs it sees what yaffs itself corrects for when in place. Not sure if i make sense.
Click to expand...
Click to collapse
Unfortunately, that makes perfect sense, I.e., that's what I think is going on.
Jim
Badblocks
Yea busybox doesn't have a badblocks, and the android version of busybox has even less apps. I think you can build a version of it from source to add the extra functionality but idk.
I also did a little hunting and found that if i run this from terminal find | grep nand that there are what looks to be drivers for the controller in /sys/devices/platform/tegra_nand and /sys/bus/platform/drivers/tegra_nand. So I think this is definitely the controller telling android what it can't write to because of the bad blocks.
The question is what does this mean? Also go check the other thread im about to post my dmesg.
jimcpl said:
You may already know, but you can check what kind of filesystem is used for /system. Just terminal or adb, then type 'mount'. That'll list all the mounts, and show what kind of filesystem is used for each.
Jim
Click to expand...
Click to collapse
I did not know that, thanks for pointing it out!
Yea it looks like I was wrong, /system and /cache are yaffs2 and /data is ext3.
Sorry for the confusion I was sure I read somewhere that gingerbread was going to be ext4 but maybe cm7 hasnt made it that far yet.
Related
Ok, theres a lot of threads out there on getting Debian working "with" Android side by side. What about getting Debian working primarily and natively? You can easily modify the bootloader to boot into Debian.
No I'm not talking about chrooting into debian from the Android environment.
With this being said there are plenty of possibilities. Debian works natively with ARM, so you can go ahead and install Xorg with touchpad driver etc. and get Debian working up to fullspeed. Believe me, it works a 1000x better than using AndroidVNC and tightvnc server. You can actually use mplayer with ffmpeg to play any type of vidoes off your sdcard at fullspeed.
So anyway, what do you guys think? Maybe theres a way to modify the bootloader so at boot time you can choose to boot into debian or android etc. or maybe it would be possible to lets say "boot debian" and vnc into androids fb to "make a phone call" etc., kind of a like a reverse vnc method we use to get into X on the debian side. Heck - we could maybe even figure out how to access the framework to make calls natively through debian. The possibilities are endless.
Also, I'll edit this post and try to get a guide going here in a couple days on how to get Debian ARM/Xorg working.
I was actually wondering myself if this could be done. Heck, not like I do not enjoy android or anything. It would be great to be able to run a lot of my *nix apps natively on my phone.
I already have Debian runnin off my 8GB sdcard(unfortunately a class 2) and I enjoy it. Problem is having to shut it down and restart it so much to get functionality out of my G1.
Keep me up to date on your progress and let me know the best GUI to use for better performance.
so whats the deal, anyone actually got this working? i have no use for my brothers g1 considering the low call quality/not recieving mms'es, i mean literally if i put them side by side, my excalibur has better service/reception. and id be pretty sweet to have crystal fvwm running on g1. so it doesnt really matter to me if i could get it to make calls, as theres always skype/amsn w.e. so pretty much anyone got any links on getting a native debian install?
dinscurge said:
so whats the deal, anyone actually got this working? i have no use for my brothers g1 considering the low call quality/not recieving mms'es, i mean literally if i put them side by side, my excalibur has better service/reception. and id be pretty sweet to have crystal fvwm running on g1. so it doesnt really matter to me if i could get it to make calls, as theres always skype/amsn w.e. so pretty much anyone got any links on getting a native debian install?
Click to expand...
Click to collapse
Yes they got this working. If you looked at the bible you would've seen this. But I will give you the link enjoy it is very cool. Youtube has some videos also.
http://www.saurik.com/id/10
Royalknight6190 said:
Yes they got this working. If you looked at the bible you would've seen this. But I will give you the link enjoy it is very cool. Youtube has some videos also.
http://www.saurik.com/id/10
Click to expand...
Click to collapse
no you misunderstand . i mean run debian native, as in to replace android
dinscurge said:
no you misunderstand . i mean run debian native, as in to replace android
Click to expand...
Click to collapse
Gotcha Sorry, um let me look around for yeah.
hey...check this out
http://www.youtube.com/watch?v=tX1BOGl8Fnw
and heres another xda thread here
http://forum.xda-developers.com/showthread.php?t=624392
USHERROB said:
hey...check this out
http://www.youtube.com/watch?v=tX1BOGl8Fnw
and heres another xda thread here
http://forum.xda-developers.com/showthread.php?t=624392
Click to expand...
Click to collapse
ahh thx for the link i saw this before but misplaced the bookmark. but im afraid thats not exactly what im looking for but that probably doesnt exist. as this is only set up to have dual boot booting android/debian of 3rd part on sdcard. and as far as i am seeing in the thread it isnt working to well. that im just going to have to wait and see what happens.
This is an old thread, but still a very interesting topic.
Would be *great* to but debian at the bottom of things.
A note about the bootloader: It is ***ALREADY DUALBOOT***. There are TWO boot partitions on the phone: "boot" and "recovery". If you want to set it up to dualboot, but your primary (automated) boot kernel into "boot", and your secondary in "recovery".
As long as you have an engineering SPL, the actual recovery is not required -- in fact, if you WANT to boot into recovery, you can always "fastboot boot recovery.img" without even having to flash the recovery to the phone.
I tell you the thing that really bugs me about android: that it doesn't support existing X.
What I dream of at night is running the ANDROID stuff ON TOP OF X. It would present a little bit of a challenge in terms of having the PHONE app (or whatever) be able to pop up to the top. There would also be some RESOURCE challenges. DREAM may not be the best hardware to implement this on.
Native Xorg
A slight off-topic because I have Samsung Galaxy
I was also fascinated by this possibility of running debian linux, Xorg on the phone.
So I created this project "linux-on-android" (sorry, I am not allowed to post links yet) on the google code where I am going to post instructions and code. Please, join the project if you are interested. It should be completely open.
The idea is to start with something simple but working and move slowly. In order to run X server from the Debian distribution it is enough to just use the Android kernel, with only a little change to the framebuffer driver. I don't change the boot procedure - only turn off the android services and put things like startx instead. Now I am trying to use matchbox+LXDE and they look nice and fast. Wifi and touchpad work. Nothing else does. I thought about what would be the minimal working configuration and decided that power management + telephony would be very good.
With the telephony I plan to leave the android RIL daemon and write a small python program that would communicate with it and act as a dialer. It appears to be not such a problem, at least I am able to communicate with the daemon now and all requests are nicely wrapped in python methods. The next step is to write phone GUI/dialer.
I think it would be already very nice to have Xorg and debian running on top of the android daemons and android kernel replacing this "zygote" stuff. Also if we do something in this way, it would probably work on any android-based phone without big changes.
About dual-boot: I am still using chroot, I don't find anything bad in it. I have two different boot.img files, they only differ by init.rc, one which starts zygote, and one which starts Xorg. In Android I press a button and reboot in debian, in debian I press a button and reboot in android.
klinck said:
A slight off-topic because I have Samsung Galaxy
I was also fascinated by this possibility of running debian linux, Xorg on the phone.
So I created this project "linux-on-android" (sorry, I am not allowed to post links yet) on the google code where I am going to post instructions and code.
Click to expand...
Click to collapse
I'll post it for you in the hope to get something good going here
http://code.google.com/p/linux-on-android/
Wow klinck you really seem to be making awesome progress here man. Just looking through your project page and i see it being updated every day. I just watched the video proof and i must say it's really quite impressive.
What needs to be done now is make a guide for this, so people can easily install this on their G1 and test it.
Also, this will give it more developer attention. I really think this deserves a chance
EDIT: added links for easyness
Jefmeister said:
EDIT: added links for easyness
Click to expand...
Click to collapse
To Jefmeister: thanks for posting the links and your interest.
About G1: As I said, I have Samsung Galaxy, so I don't have a chance to test it on G1. But still I can probably make a "binary distribution" for G1 and somebody else can test it. There are some hardware differences, to summarize, there are 3 things I need to change:
I need a kernel for G1 with ext3 support, and patched framebuffer driver which turns double buffering into single buffering and automatically updates screen at regular intervals
I need to know if tslib driver works with touchscreen from G1 and what is the corresponding device (it is /dev/input/event2 in my case)
I need to know where to put the debian distribution. In Galaxy we have a separate 1Gb ext3 partition on SD card which is normally used for '/data' directory, so there is a plenty of free space there. But I guess it may be different on G1.
klinck said:
To Jefmeister: thanks for posting the links and your interest.
About G1: As I said, I have Samsung Galaxy, so I don't have a chance to test it on G1. But still I can probably make a "binary distribution" for G1 and somebody else can test it. There are some hardware differences, to summarize, there are 3 things I need to change:
I need a kernel for G1 with ext3 support, and patched framebuffer driver which turns double buffering into single buffering and automatically updates screen at regular intervals
I need to know if tslib driver works with touchscreen from G1 and what is the corresponding device (it is /dev/input/event2 in my case)
I need to know where to put the debian distribution. In Galaxy we have a separate 1Gb ext3 partition on SD card which is normally used for '/data' directory, so there is a plenty of free space there. But I guess it may be different on G1.
Click to expand...
Click to collapse
(3): You could certainly put it all on the sdcard in exactly the same way. As long as you have the sdcard driver built into the kernel, the sdcard is just like any other storage device.
I dont know if this is going to be of any help to you, but as I was searching around for a way to nativly install linux on my dream I found this.
http://www.htc-linux.org/wiki/index.php?title=Dream
It may interesting as a point of refrence.
anyway, keep up the good work, once my conract expires this is exactly the kind of thing I would love to do with my old phone
Hi all !
I have actually an Debian NATIVE on my G1, both Debian/OpenMOKO/Android on the SAME phone.
android are into NAND FLASH, OpenMOKO (for tests and few binaries/config files) into SD2 Partition, and Debian with all tools to compilation, into SD3 Partition.
Actualy work on my Debian G1 :
USB NET
Xorg
Keyboard (but one touch not responding)
Touchscreen (but the calibration into Worg not work, into FBCONS it's OK)
Trackball (but the ball not "click")
I trying to make call, with OpenMoko I can ring my phone.
I trying also WiFi : Crash :'(
for bluetooth, I don't have the fu***** firmware ...
For ALL : You can boot debian with fastboot or recovery.
Debian CAN be into SD1/FAT32 parition, into loop file. I make an boot img, who can boot from SD1 part with loop image you don't must repartition SDCARD, or have dedicated SD card.
I'm looking for beta testers for a new App2SD implementation that does not require your MicroSD card to be partitioned which is potentially unsafe and can result in a loss of your data. If you'd like to test this new implementation before it's release here on XDA shoot me an email at [email protected] with what firmware and version you're using.
More information will be released after I get a few positive beta tests out of the way.
loopback device, eh?
I tried that a while back but never could get the loopback driver to load early enough in the boot process reliably.
Hope you have better luck than I did.
As [email protected] pointed out to me a while ago, this is not a good idea for security reasons. If your loopback file sits on the FAT partition, it is accessible by all of the apps, it can be read, overwritten and deleted by a rogue app bypassing the entire android security model. If this is what you intend to do, it's probably not "safer".
Hey, shot you an email. Ready to try it out. But only for beta.
Hit me up, I have no apps to lose.
But security? Idk just let me know whats up.
what happens when you mount the SD card to your computer?
I'd like to try it, but i don't yet have a class6 sd card. Is that necessary?
i'd be willing to give this a shot. I have no data to lose as well.
southsko said:
what happens when you mount the SD card to your computer?
Click to expand...
Click to collapse
That's true. Won't all your apps disappear when you mount the SD?
This smells fishy not many app developers with 1 post can this be someone testing their new exploit/virus?No offense to original poster im just sayin....???
Edit:Sorry to OP clearly not a virus,and good luck on getting it stable I will gladly donate to your cause partitioning is a pain!
don't be a jackass, many people have had great ideas and decided to come to XDA to share them. just because you are a complete idiot who can't program does not mean that the OP is too.
@@OP
you are playing with fire my dear friend. i don't think that mounting your apps on the FAT32 partition is a good idea at all. not only because it would allow any program to access and write without asking android permission first, but because it would allow people to mount the SDcard and steal paid apps even easier. i beg of you please rethink your idea
I imagine the phone would be crashing when the phone is mounted to the computer. lol. just kidding. =]
tubaking182 said:
don't be a jackass, many people have had great ideas and decided to come to XDA to share them. just because you are a complete idiot who can't program does not mean that the OP is too.
Click to expand...
Click to collapse
WTF?Just came back to edit my post and put that its for real cause like I should have done first I found this http://noderat.com/loop2sd/.But as for your insults who the hell are you?How the f**k do you know what I can or can not do?I was posting in the first place to start trying be more active in the forums no reason for you to be a **** anyways,I was tryin to help people not get what I thought may have been a virus was that really that bad?
i'm not sure that is 100% true. when i mount my phone(apps2sd) my phone decides to mount the ext2 partion and the FAT32 partition, i am using ubuntu so my computer is able to read the partition, but my phone doesn't crash(i've yet to try running an app while mounted though)
Android can acces the sdcard while mounted.
Try terminal emulator.
crotalusfreak said:
This smells fishy not many app developers with 1 post can this be someone testing their new exploit/virus?No offense to original poster im just sayin....???
Click to expand...
Click to collapse
Well, take it from someone who has many posts and 15 years of unix experience, it is a bad idea.
Most of the devs here had this same idea, but as I mention in my previous post, this is opening yourself up to many bad security issues. To all those who answer, "I have no data to lose", that's fine as a beta tester. But what's the point in beta testing something that cannot be safely used by anyone who does have data (or apps) to lose?
I should point out to those who perhaps do not realize some the consequences of my original post, that it is not just a potential data loss problem, but a potential arbitrary code execution vulnerability. If an application manages to replace the loopback file with a new loopback file, it could inject altered common applications. If this succeeds, it means that previously trusted applications which have been granted privileges (or root using the various su apps) at install time, could be replaced with trojan versions which can have complete control over your system... steal your passwords... reflash your bootloader and literally install a permanent trojan... brick your phone... <insert other scary things besides data loss here>.
It's your phone, do what you want. I just figured that I would re-post that this not a new idea, but one that has been rejected by those of us with unix experience who realize the consequences. If you are just messing around, go ahead, it's not likely to hurt your phone. But, as a general method to build upon and be depended on, this should not have a future. If this becomes common practice, it is highly likely that exploits will be written to take advantage of this vulnerability.
So, if you are asking yourself if something is fishy, yes something is: it's a logical idea which seems great on the surface, but it has an unfortunate flaw.
Note: I am not suggesting malicious intent on the OP's part, just that they may not have thought of the consequences of suggesting this as a common method to do apps2sd. And if the OP (or someone else) is able to point out a method to avoid the things I warn against I will happily retract my statements (if I agree that this method would indeed work) since this method has some obvious benefits. However sadly, I think that is highly unlikely.
maxisma said:
Android can acces the sdcard while mounted.
Try terminal emulator.
Click to expand...
Click to collapse
No it can't. It can only access the empty mountpoint.
If you want to do this, there IS a way to make it work SAFELY....
Find the functions that control sdcard mounting and unmounting and FIX it so that it will mount an ext2 first partition. Then forget about the whole loopback thing as thats not going to do anyone any good... If you do it like this, then unionfs it, then unmounting the sdcard should safely vanish the apps that are stored on the card (leaving the internally stored apps), might crash the launcher, but that'll restart immediately and won't even error out.
A second step in the right direction would be to find the place where programs are detected from, which currently looks in /data/app, /data/app-private, /system/app, so it can clearly handle loading software from multiple locations -- add in a new path. Or maybe link app-private to /sdcard... A little more challenging would be to allow it look in multiple locations for thing that are ALL currently in /data/data and /data/dalvik-cache.
And then when its done, submit a patch for the source.
Wow what a response. Here's a few key bulletpoints:
I'm not a forum poster, not the kinda person for it but I have been on XDA Dream since I got my pre-launch G1 as a CSR.
There are potential security flaws with the current ext2 method of a2sd, and bypassing root to mount the ext2 partition is possible.
a2sd is not stable in any format, so it's a use at your own risk until android improves kinda deal.
I'm not cool enough to write a virus, but thank you for the ego boost
Anybody using a third-party firmware is not safe nor secure. If you're reading this forum you're not safe nor secure. The idea of homebrew roms is to add extra features that are not in Android to begin with and with that comes security risks. No ROM is ever perfect but I'd trust a Google or T-Mobile rom with my security before any homebrew-anything.So yes it's use at your own risk
This has the same results for mounting on a PC as MarcusMaximus's a2sd.sh
This doesn't really make it any easier to steal paid apps, it's always been easy and always will be but this doesn't change it.
If you guys have other questions shoot me an email, like I said I don't really do much forum-posting (never had much of anything to say, maybe this'll change all that)
[email protected]
JakeEv said:
I'd like to try it, but i don't yet have a class6 sd card. Is that necessary?
Click to expand...
Click to collapse
The faster the better but I've done it with the stock card that came in the G1 as well as a Class 6.
id try it since i can not get apps2sd to work.
[email protected]
using JF 1.51
I was thinking that dual booting on a single device would be a really great thing. A huge step.
Why we cannot do it?
Cannot we "emulate" partitions of the internal memory on the sdcard and then create a modified spl to boot from sdcard?
I was thinking that it is possible to make the sdcard working like internal memory..
Is it so difficult?
blackgin said:
I was thinking that dual booting on a single device would be a really great thing. A huge step.
Why we cannot do it?
Cannot we "emulate" partitions of the internal memory on the sdcard and then create a modified spl to boot from sdcard?
I was thinking that it is possible to make the sdcard working like internal memory..
Is it so difficult?
Click to expand...
Click to collapse
I think this would be a good idea too. have a stable boot partition, then on the second boot have our "testing" partition.
Is this even possible?
Whether or not this is possible, I don't know.
But kinda related, I would like to see a bootloader that made an "image" of the entire phone to sdcard AND would also restore the entire "image" of the phone.
Why?
It would give us an easy way to test out different roms!
You could have your stable build for regular day-to-day use, you could also "image" any other rom you install, then you could switch back and forth without the need for a computer to restore using Fastboot. Using this method, you could "image" any number of builds you wouldn't to try.
There may be a way this could be done right now, I don't know. I haven't found out how. If it's already an option, someone please point me in the right direction!
It would be very difficult cause you would have to find another OS that isn't linux based. Even with a bootloader all the files will be knocked off from the previous flash because everything in these builds are pretty much in the root folder. The OS runs on these references and if you change them the OS will not run. You would have to rework the whole OS to get this to work
Someone delete me
argh xda is so slow
It would be very difficult cause you would have to find another OS that isn't linux based. Even with a bootloader all the files will be knocked off from the previous flash because everything in these builds are pretty much in the root folder. The OS runs on these references and if you change them the OS will not run. You would have to rework the whole OS to get this to work
Booting off the sdcard could be possible but would be pointless to do.
Everytime you mount the sdcard to the computer it would crash the phone. Also, There's not really enough internal space to dual boot. 1 decent ROM barely fits on as it is.
blueheeler said:
Whether or not this is possible, I don't know.
But kinda related, I would like to see a bootloader that made an "image" of the entire phone to sdcard AND would also restore the entire "image" of the phone.
Why?
It would give us an easy way to test out different roms!
You could have your stable build for regular day-to-day use, you could also "image" any other rom you install, then you could switch back and forth without the need for a computer to restore using Fastboot. Using this method, you could "image" any number of builds you wouldn't to try.
There may be a way this could be done right now, I don't know. I haven't found out how. If it's already an option, someone please point me in the right direction!
Click to expand...
Click to collapse
Cyanogen mentioned he was looking into this to try implement it into his recovery image. I don't think anyone's been able to restore a complete nandroid backup outside of fastboot...yet. However people are working on it. I think it's doable.
Meltus said:
Booting off the sdcard could be possible but would be pointless to do.
Everytime you mount the sdcard to the computer it would crash the phone. Also, There's not really enough internal space to dual boot. 1 decent ROM barely fits on as it is.
Click to expand...
Click to collapse
Maybe, maybe not. A second or third EXT partition on the sd card could possibly be used for a dual/tri boot enviornment. Only the FAT32 portion gets mounted when you mount through your phone. And there would be virtually no difference when mounting through ADB. Now would be a good time for those interested in persuing this notion to have a look at the data2sd thread. Sounds very possible to me.
overground said:
Maybe, maybe not. A second or third EXT partition on the sd card could possibly be used for a dual/tri boot enviornment. Only the FAT32 portion gets mounted when you mount through your phone. And there would be virtually no difference when mounting through ADB. Now would be a good time for those interested in persuing this notion to have a look at the data2sd thread. Sounds very possible to me.
Click to expand...
Click to collapse
no, i'm pretty sure all partitions get mounted, they just don't show up on windows.
on linux they all appear for me when i mount the phone.
also, sorry about the triple post, dunno wtf happened there.
Debain As Primarly OS
What Ive Been wishing for is someone to make the Dream Boot straight to Debian, No android running in the background.
Then we could boot into a debian with g1 drivers (if open source) and have gpu accl. x11.
Then maybe dual-booting android.
Im willing to try to get a debian img to boot on my g1 if someone wants to tell me where I would start to even try to attempt it.
lolz
Booting straight to Debian would be cool, except there is really no use for it on our G1's. We are best off running after loading Android, although I'm sure one day we could just boot Debian. What would the point of Debian be on our G1's? I'm running Deb5 on my Dell Mini that has a 9" inch screen and can barely see text.... how in the world would this become useful on a 3" screen???
just my £0.02
there is an old saying in my country. "if you don't believe it can work, then it won't for you". that holds so true for development. yes you will make mistakes on the way. heck i'm on my fourth G1 so far (and i suspect there will be more to come!) I love this phone, and i love the fact that we as a community can build such amazing things as the hero rom for the device.
what would we have done if the first person had said the wheel was impossible? or if the first person had said that fire was impossible. or (shock horror) electricity? or television? or telephone? or GPS? or the internet?
all of those were impossible until someone worked out how to do it.
dual boot would be pheasably posible, as the device is primeraly a computer first, and then a phone second. it boots a linux kernel from the bootloader (if i am correct in my understanding) so all we would need to do is create a bootloader with a choice in it, and then direct the phone to boot a second partition from the SD card.
the phone does mount all partitions - but only if the OS understands all partitions (test it for yourself - if you have windows and apps2sd mount the partitions and then run an app from the card it still works. but it does not under linux).
to answer the what would be the point questions, what would be the point in not doing it? surely development for a device like this is all about trying stuff, and then if it doesn't work not doing the same thing again.
i believe that a second OS would boot quite comfortably on a decent SD card. not that i have this working or anything. to make the screen readable, you just use a lower resolution (320x480). i would probably not want a full-blown GUI linux anyway, what i would want from a dual-boot OS would be a working command-line debian with FULL hardware access - allowing me to really use the phone as a fully-functioning remote terminal for my server.
i recon, though, that one thing that would be absolutely amazing is being able to have a fully-portable totally reliable XDA-Developers OS on my phone.
so, why do we not just try as much as we can to get this working? how do we start?
milestone.it said:
just my £0.02
.....
so, why do we not just try as much as we can to get this working? how do we start?
Click to expand...
Click to collapse
Just hack the spl and flash it, but be cautionous as hell
Okay, I dont claim to know alot but I'll share my thoughts anyway
When you mount the SD all partitions get mounted, if you go into disk management in windows you can see the 'Unknown' partition if you have an ext2 partition.
Secondly, we don't really 'boot' debian, it just mounts an image file on your SD card that contains the debian binaries. As I understand it there is no reason these binaries couldn't be included in android (like busybox).
Thirdly, do we really want debian? What we need is a very light OS, android is the perfect base, take away all the gloss and its linux underneath. I love the idea of having repositories and being able to apt-get and even develop on the device.
Lastly, we're forgettign why android is such a good platform, the reason android is useful is because of the Dalvik VM, it's what allows us to make portable apps that will work on any android phone. I seriously doubt everyday users will be interested enough to learn to compile source on their phone. I've worked programming games for mobiles in J2ME and it was horrible, there was barely any portability between manufacturers, i believe android will be alot better adn from what i've seen (with people porting from other droid devices) this seems to hold true. It will be interesting to see if Android gets bloated with manufacturer specific API's like J2ME.
Also I'll just throw this out there... I'm not a fan of being tied to google, yes google helped along the way, but its not 'google android', its android. Wasn't it strange hoe Gmail worked fine, but the email app didnt? (K9 is perfect though!)
hi guys, i'm not at all a developer of any kind, i suck even at web design, but here's my thoughts expanding on the whole "what if the wheel didn't work" scenario
inventions are created by the need to do something, we need to get from A to B faster, lets make a car. we want to entertain our families in the evening, Hey look, TV. i need to tel my wife to get some milk while she's at the shop, Voila, Mobile Phone.
Basicaly the point i'm trying to make is, if somebody finds a NEED for dual boot on android, then so be it, it shall be done, maybe not today, maybe not tomorrow, but if something is needed, then something shall come from it. we develop technology when we need to do something faster, easier, or just plain do it.
if somebody decides they NEED dual boot, i'm pretty sure they will figure out how to do it, either that or ask haykuro for some tips and alot of help, but i think he's still too busy with regular life at the minute, i'm not so sure, all i know is he's definately a legend, and maybe will want a piece of dual-boot pie
So who is the great man who want to try to do this? ;D
I offer my help, if it could be useful..
re: dual booting
would it be blasphemous to want to try out winmo 6.5 or 7 on these?
personally, i'd love to see WM on here. mainly, just so we know it's possible.
People are always slating Windows but, personally, i don't see whats wrong with it (Linux is my primary OS and always will be ). It would be nice to have say WM for work and Android for play
any news on this? I would really like to run a hero rom one day and then cupcake the next while not losing my settings...
Presenting bmlunlock. Unlocks bml7 for writing to it via dd.
http://github.com/CyanogenMod/android_device_samsung_bmlunlock
What is this for?
Sent from my SPH-D700 using Tapatalk
plmiller0905 said:
What is this for?
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
"After running bmlunlock on the samsung device, one can flash the kernel using the following command:
dd if=/sdcard/zImage of=/dev/block/bml7 bs=4096"
How do you use this?
Sent from my SPH-D700 using Tapatalk
Wait for it to get packaged into a oneclick installer
DanDroidOS said:
"After running bmlunlock on the samsung device, one can flash the kernel using the following command:
dd if=/sdcard/zImage of=/dev/block/bml7 bs=4096"
Click to expand...
Click to collapse
It looks like redbend_ua does 256kB writes, not 4kB writes. 256kB presumably corresponds to the erase block size of the NAND chip. So unless the Linux page cache does a good job coalescing the writes, or the BML driver handles this internally, I would imagine dd here does a read-modify-write operation for each page. In other words, this may potentially burn through flash erase cycles 64x faster than necessary. No?
It would probably be worth stracing redbend_ua to see its exact write behavior. I would't be surprised if it uses O_DIRECT and 256kB write sizes except for the final block.
No, it doesn't. Run an strace against redbend_ua and you'll see it reads 256k at a time, and then does 64 4k write calls. (Coincidentally how I also figured out how redbend works)
You may be right, and that may not be the erase block size. However, but it is the PAGE_SIZE. IIRC, you should generally write in PAGE_SIZE increments, otherwise you risk getting non-contiguous memory, which may cause flashing to fail. At least this is my experience on HTC devices.
Though it is using an ioctl to do the write. So who knows what magic is happening there. I could reverse engineer a "bmlwrite" type thing as well, but I am not too motivated. This should be enough to get people down the right path.
strace:
http://pastebin.com/di6kLXkB
Koush said:
No, it doesn't. Run an strace against redbend_ua and you'll see it reads 256k at a time, and then does 64 4k write calls. (Coincidentally how I also figured out how redbend works)
You may be right, and that may not be the erase block size. However, but it is the PAGE_SIZE. IIRC, you should generally write in PAGE_SIZE increments, otherwise you risk getting non-contiguous memory, which may cause flashing to fail. At least this is my experience on HTC devices.
Though it is using an ioctl to do the write. So who knows what magic is happening there. I could reverse engineer a "bmlwrite" type thing as well, but I am not too motivated. This should be enough to get people down the right path.
strace:
http://pastebin.com/di6kLXkB
Click to expand...
Click to collapse
How much beer would it take to motivate you? lol
Koush said:
IIRC, you should generally write in PAGE_SIZE increments, otherwise you risk getting non-contiguous memory, which may cause flashing to fail. At least this is my experience on HTC devices.
Click to expand...
Click to collapse
In this case it probably doesn't matter, it's not direct I/O, just dirty pages hitting the page cache. Linux should coalesce them before flushing them out, and hopefully the FSR driver will minimize block erases. My thinking was that using direct I/O with a 256kB write size should serve as a "strong hint" to the FSR driver perform only a single erase per block. Physically contiguous memory shouldn't matter unless the driver actually does DMA from the userspace buffer. But yes, it's hard to get 256kB of physically contiguous pages.
Koush said:
Though it is using an ioctl to do the write. So who knows what magic is happening there.
Click to expand...
Click to collapse
It's making BML_RESTORE ioctls to the FSR driver, which is sadly proprietary so we can't see what's going on in there. But since it's a restore function, presumably the driver issues block erases whenever there's a 4k write at the start of an erase block. Since partitions are aligned to (256 kB) erase block boundaries anyways, it's not like it would ever "erase too much".
Koush said:
I could reverse engineer a "bmlwrite" type thing as well, but I am not too motivated.
Click to expand...
Click to collapse
Thanks for the strace. Since we're lack the FSR sources, it's going to take poking at redbend more to figure out the BML_RESTORE interface. Odd that it reopens the device and calls BML_UNLOCK_ALL on every block write though.
Can other bml partitions be unlocked using the same principle?
Context/Resume:
-I´m changing the android platform to create two partitions in a SD Card. I need to do this as early as possible. I´m currently trying at init.rc
-It would be nice to obfuscate the access to one of the partitions. If i could keep ithidden would be better
And...the long story:
I´m trying to create new partitions in a sdcard in a device, and i need to be done as early as possible. I thought that the init.rc should be the best location for this, so i tried to add a script call to perform the task, but i´m unable to create these partitions ( or get information of the reason of fail ) First of all, is this premiss valid? Should i be able to do this?
I call the script by:
service myscript /system/bin/logwrapper /system/bin/myscript.sh
disabled
oneshot
at init-time
And the content´s of the .sh file is
fdisk /dev/sdcard < mykeys.input
where "mykeys.input" is the sequence os keys used to perform the taks of create the partitions.
Well, is this the recommended way to do this?
thanks!
Not to sure bout the boot order and its effect on what you are trying to achieve. What phone and os? You might want to look at your phones logs to see in what order what/which/where is going on when. As that could explain your issues a bit more clearly and possibly even provide the mystery errors. If not try running it in an emulator where you can make the boot up verbose and boot log it.
As for hiding the partition have you tried formatting the sdcard outside the phone environment. The hiding ability should be able to be gotten if you were to format in gparted I.e. Format it how you want size wise and format wise, then for the partition you want hidden flag it lba. Not sure if lba hides from your phone or not, but worth a shot.
*edit* what are you trying to achieve again? Dual booting os on phone? If so, I would take a look more towards the /dev/loop and chmod approach. Also keep in mind if this is what you are aiming at you might want to make 3 partitions as a swap partition would be beneficial.
Sent while wearin my foam helmet ridin the short bus.
Hy blackadept:
What i want: Ensure that there is two partitions in a sdcard as early as possible. ( i must create them if needed ). My focus now is in how to create. The logic of "if/when" todo a will deal later.
Why i want this: Project requirement. Not negotiable.
What will be stored: Part1 : User acessible. Nothinf special. Part2: Special Data user by an apk.
"Phone model": It´s a tablet. STI´s tablet. Android 2.2
Well the partitions will be there just from formatting the card, as to whether or not the init sees that I am not sure. I'm one of them poor simple folk who ain't got no money....aka I don't have the fun fancy toys like a tablet. haha. Only reason I bring that up is for the fact that being as I am not around them, literally haven't even seen one let alone hold lmao, not sure how it's boot up goes.
Have you tried creating a partition and formatting it with various flags such as lba to hide it from the OS? If we are talking small sizes here then I'd think you could hide it within such a flagged partition surrounded by fluff. Throw some encryption into the mix and your gtg. At that point all that's left for you to do would be writing script to navigate the maze and unlock it. If that would work then it would be a fairly easy out.
Otherwise we could go back to the "dual booting" that I brought up in the last post. Being as my phone can't mnt to bin *droid x.....hate u Motorola* I have done all of my dual and triple boots via looping thru /dev. This could work for you as well, tho again I'm not familiar with the tablets. If you did that tho..... well you could hide it in a myriad of ways.... flags, encryption, straight up "Where's Waldo" type shenanigans....
Have you ever put an ARM OS onto an android device before? If so, maybe give it a shot and let me know? Only question I'm wondering, tho, is android's ability to see the flag and be able to handle it. Also as to the level of root that particular device has (regular not-so-super user like my phone or is it completely unlockable?) would determine a game plan too in a way. If you have full access then you could just format the card thrice (sorry always wanted to use that in a sentence and feel all smert), making a special ext3 partition with the flags or encryption, make note in the root mnt's of it's existence thru your init script (tho just giving physical note to it.... not size or content). Write your .apk or specialized script with the UUID or GUID or w/e the *beep* android uses this week, and again you win at android....
Sorry for the long winded verbal response....lately I always seem to post when I ain't slept for 2-3 days as opposed to when I ain't delirious...