Related
Hi chaps,
I've just bought a Galaxy tab with plans to port Meego to the device.
I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).
So, if you'll bear with me, I have a few questions which are probably quite basic.
I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.
So onto the questions:
Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?
Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?
I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?
I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.
Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?
Thanks for your patience!
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
lardman said:
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
Click to expand...
Click to collapse
Samfirmware get their images direct from Samsung insiders. They are not dumps.
If you want to dump from your device search "rotobackup" here in the dev forum.
Sent from my GT-P1000 using Tapatalk
alias_neo said:
Samfirmware get their images direct from Saunaing insiders. They are not dumps.
Click to expand...
Click to collapse
Ok that's reassuring.
alias_neo said:
If you want to dump from your device search "rotobackup" here in the dev forum.
Click to expand...
Click to collapse
Great, just what I was looking for, many thanks
So some more questions:
Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?
What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc
The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.
I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.
Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?
Thanks
lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.
backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.
Thanks for the comprehensive reply
Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.
I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.
Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.
Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/showthread.php?t=870690):
Restoring to factory after using this process (you need using stock images):
heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs
Click to expand...
Click to collapse
Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.
Any thoughts?
Do we trust the partition sizes reported here: http://forum.xda-developers.com/showpost.php?p=9471190&postcount=14
They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)
Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?
Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.
So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
I see from the Nexus S port that including adbd in the image seems to be the way to go for early messages, I'll need to generate a new Meego image and have another go later on.
Interesting, I can't see that I've done anything wrong, and my extra init shell script is not started. I am trying to use the "exec" keyword in recovery.rc to start a shell script which will pass control to the Meego rootfs. At the start of my shell script I start adbd (i.e. still within the initramfs), so I should be able to tell if it has started, and it doesn't appear to do so.
Therefore I did some Googling, and I've seen that in some cases the initramfs init does not implement the "exec" keyword (http://forum.samdroid.net/f9/new-init-exec-import-implemented-3280/). This is troublesome for me as it's what I'm trying to use, but at least would explain why I don't seem to leave the init process
I couldn't see the Samsung specific source for init anywhere, has anyone found any? I'm not happy to replace it using the standard Android source as I'm guessing there's code missing which allows the bootloader to tell init how the device was started so that it knows which of the .rc files to run. Has anyone looked into this?
Thanks
Looking at the code in that link it looks pretty straightforward, just a case of parsing the kernel command line (though I might just reverse engineer the existing init first to make sure I'm not missing anything).
Would still be easier to get the actual source code from Samsung, so I've emailed their Open Source group.
lardman said:
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
Click to expand...
Click to collapse
I get it with CM
Does CM use a compressed initramfs? I'm using one of those and wondering if it's something to do with the (admittedly small) extra time required to move to init.
I don't have my Tab with me here, could someone post the output of /proc/cmdline please? You'll need to be root. Thanks.
Well it's booting you'll all be glad to hear.
More details to follow, but from memory the following were required:
Custom kernel to add btrfs support (as the image I'm booting is a btrfs partition on the external SD); kernel patch to allow compile-time cmdline to be added to the end of the bootloader cmdline (to enable console=tty0); replace Android init with init script to perform some basic setup then pivot_root to the Meego partition.
Next steps are to get the Meego system running usefully (which includes getting a terminal as currently I just have a login prompt but no way of inputting anything!) and also seeing whether I can get dual booting working with an Android system standard boot and Meego replacing the recovery boot.
Poor pic, but still: http://people.bath.ac.uk/enpsgp/Tab/PICT0040.JPG
Good stuff. Thanks for keeping us informed.
After you've got the groundwork for this done, how easy would it be to get Ubuntu running?
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
brilldoctor said:
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
That's using chroot, which I don't want. I want it running natively.
Sent from my Galaxy Tab
http://forum.xda-developers.com/showthread.php?t=1119555
Logically speaking, this application should also work with the Bionic correct?
Just wondering, if its deemed safe in this thread to attempt using, I will try it and post back with results.
---------- Post added at 12:30 AM ---------- Previous post was at 12:08 AM ----------
Okay, so I just backed up everything and tried the app, which won't work due to the fact that it checks the phone model number, Theres a manual guide to get ubuntu running on the atrix, and I'm going to start from scratch there. Probably going to be a couple of days before I do anything since I need a new microhdmi...
I tried the app that comes with it to partition the sdcard but it does a device check then it stops with an error message that the device is not an Olympus (Atrix). Maybe we can get the dev to check on the differences, albeit small, for the Atrix and the Bionic.
Worth a shot. I've been playing around with /osh for a few days but had to reflash to stock due to the lapdock staying on the screensaver.
Hey guys, I am working on the same thing at the moment trying to port over Sogarth's method of unlocking the 10.10 maverick build of Ubuntu on our phones.
http://forum.xda-developers.com/showthread.php?t=1000316
The link here is for his old automated .bat script he made for the Atrix that I believe will work for our phones with a little modification to it to reflect Maverick packages instead of the Jaunty packages for their phones.
Please jump into the irc in my sig because I would like to get this going as well.
I would hop in IRC but I'm about to head out the door.
I'm currently approaching this situation from two directions:
1.) I'm dumping /osh/ (webtop partition) and uploading it to dropbox as soon as I can get a complete dump. (hopefully tonight) and providing it to the original Atrix dev to see if he can hook us up with an app to help do whats needed
2.) I'm also attempting the manual method as soon as I get a new microHDMI cable (I was using a cheap adapter).
You are 100% correct though, you should be able to get that install script working just by changing the packages to reflect the updated Ubuntu. MAKE SURE you backup ANY files before you change them (and preferably a complete backup of /osh/. Since we have SU on our phones we have free reign over the /osh partition, so be careful in there.
OT: I can't wait until we can get on-demand CPU overclocking for this thing... if it clocks as well as past mobile chips... Toggle 1.2-1.4ghz and plug it in the LapDock. You'd have a damned fine netbook...
(Not necessarily talking to any experienced users or noobs, the disclaimer about Linux & SU is for everyone reading this thread - I'm relatively experienced in the Linux world... and I need to be reminded of SU's power sometimes.)
I just realized that their phone's Ubuntu distribution is under the 9.x series versus the 10.x series. A lot of Major changes happened to Ubuntu between 9.x and 10.x that affected the way the operating system talked to devices and booted, they stopped using HAL and moved to a new boot method, I am uncertain whether or not the install script will work or not, though I'm somewhat confident it will, given the nature of webtop (Android does the hardware abstraction, and the booting, we just run a second set of executable's on a different X window session attached to a different display) This should mean that the portions that would normally prevent us from just duplicated the script are omitted from the Ubuntu distribution entirely. As long as we keep a backup we should still be fine.
No worries, just remember to keep FXZ and RSD handy. I've screwed up the /osh partition a couple times but that has saved me from complete disaster so far
Good call on bringing this up. Let me know if you need to test anything for this.
@xaero252
So I modified Sogarth's script to use Maverick build of all the tools it downloads and installs but the problem with the script is that it needs the phone to have the ro.secure=0 so that ADB always launches with root access without manually initiating su each line of code. I am not sure if there is a way around it or if we have to modify the script differently. Anywho, I've upload a copy of the work I've done to the script.
Is it just an sh script? If so and ut doesn't reboot the phone at all you could launch a SU terminal and do "su sh script.sh"
oh i see the issue now... we would have to be able to edit the boot loader for that method... if i'm correct though his android app doesnt use the pc for much... if you change that variable on boot do you think it woukd work?
Hmm, I have an idea, its not as polished as the pc based script, however it should still work presuming you can get a SU terminal to run on the phone ( I happen to have one running right now ) I'm going to see if I can't adapt that to a bash script. probably going to take a while.
Curiously we happen to have a 1.5gb partition for Ubuntu on built in memory, where as the atrix only had a 600 or so mb partition... This is great because we should likely be able to continue to install /, /boot and such to internal memory, and use the sd card (even left as ntfs) for /home...
Couple of things: reading through the script it looks like 100% of the commands he runs could be run on the phone via a bash script run as su. The idea is this: convert the entire script over to bash, copy the script, and the required files to the phone, and execute the script from the phone. The only other concern I can see is the wget package included with the script not being compatible with maverick, which doesn't seem likely.
I'm gonna start working on rewriting the script linux native. My idea is to use a terminal emulator (they are free on the market) and run su script.sh and pray. I need to get a new microHDMI before I do this though, so I can test my results reliably.
xaero252 said:
Is it just an sh script? If so and ut doesn't reboot the phone at all you could launch a SU terminal and do "su sh script.sh"
oh i see the issue now... we would have to be able to edit the boot loader for that method... if i'm correct though his android app doesnt use the pc for much... if you change that variable on boot do you think it woukd work?
Click to expand...
Click to collapse
As far as correcting that, no one has attempted doing custom kernels yet so to do the edit to get root access out of the gate is moot at this point.
Hmm, I have an idea, its not as polished as the pc based script, however it should still work presuming you can get a SU terminal to run on the phone ( I happen to have one running right now ) I'm going to see if I can't adapt that to a bash script. probably going to take a while.
Click to expand...
Click to collapse
Your linux skills are probably 10 folds better than mine but I believe if you convert my modified script, which has all the necessary links to the correct packages for our phone, then it might just work.
Curiously we happen to have a 1.5gb partition for Ubuntu on built in memory, where as the atrix only had a 600 or so mb partition... This is great because we should likely be able to continue to install /, /boot and such to internal memory, and use the sd card (even left as ntfs) for /home...
Couple of things: reading through the script it looks like 100% of the commands he runs could be run on the phone via a bash script run as su. The idea is this: convert the entire script over to bash, copy the script, and the required files to the phone, and execute the script from the phone. The only other concern I can see is the wget package included with the script not being compatible with maverick, which doesn't seem likely.
Click to expand...
Click to collapse
The WGET I packaged in the .zip is the correct for Maverick along with all the files in the \bin directory are corrected to match our phone. If you can convert all this to a bash script, that would be awesome instead having to do each command via ADB Shell. The only problem I had with this is every time I tried to run the DPKG command on the .deb I downloaded manually, it threw up an error saying it could not find the file or destination.
On a side note, you are correct that we have 1.5gb partition opposed to their 700mb so we could honestly forget the part about creating a ubuntu.disk on the /data partition and modify the /osh directly for now until the time we need more space. After that, we can see if Sogarth will incorporate your script into his Webtop2sd app or we could make a 3gb ubuntu.disk on the /data partition since we have plenty of space there.
I'm gonna start working on rewriting the script linux native. My idea is to use a terminal emulator (they are free on the market) and run su script.sh and pray. I need to get a new microHDMI before I do this though, so I can test my results reliably.
Click to expand...
Click to collapse
Make sure you get the adapter as well to trigger Webtop cause at the moment our phone wont do webtop directly over HDMI without the HD Dock, Webtop adapter or Laptop dock. If you want to test the script out for now, hit me with the script and I will test it for ya
So long story short: tried upgrading ICS to JB - fail(missing system apps), tried flashing ICS via fastboot - fail(several images didn't copy due to signature check).
So I have a phone with more files missing than before, causing radio/wireless/bt/camera to fail, and root access only in SS.
I still have use of adb, fastboot, SS, and external-sd.
Q: Requesting data from a functioning ICS to compare with what I have left to discern what was lost. Namely a directory tree with filenames/sizes, output of dmesg and df.
If anyone has a solid lead as how to extract missing files from system.img.ext4, I'm all ears.
t1nk_2 said:
So long story short: tried upgrading ICS to JB - fail(missing system apps), tried flashing ICS via fastboot - fail(several images didn't copy due to signature check).
So I have a phone with more files missing than before, causing radio/wireless/bt/camera to fail, and root access only in SS.
I still have use of adb, fastboot, SS, and external-sd.
Q: Requesting data from a functioning ICS to compare with what I have left to discern what was lost. Namely a directory tree with filenames/sizes, output of dmesg and df.
If anyone has a solid lead as how to extract missing files from system.img.ext4, I'm all ears.
Click to expand...
Click to collapse
Just use rsd lite? It should blow all that away.
Sent from my MotoAHD Maxx
Youngunn2008 said:
Just use rsd lite? It should blow all that away.
Click to expand...
Click to collapse
You would think. However, it doesn't matter whether I use command-line tools or rsdlite5.6/5.7 - there seems to be either a sig check that fails (rsdlite) or file transfer error (command-line). I'm suspecting has something to do with the locked bootloader. It's hard to tell for lack of error code interpretation or lower-level debugging output. It won't even let me install gapps-ics: invalid signature.
I managed to recover root in the OS(cp su to /system/bin), so I can at least modify things outside SS. It may come to the point of manually copying/deleting individual files in /system, as I noticed the official JB update script merely patches what is there and deletes what is deprecated (verifying sigs for everything).
There could be an issue with my linux usb driver, but I never had any problems while taking my mb520 to CM10.
I saw someone offering stock files for those who deleted them, but I also noticed everyone else is nervous about hosting such content anywhere.
I keep noticing a /modem mount, and yet never noticed it while parsing fs. Can anyone verify this exists?
Okay, so just tried fastboot on cmdline again, the max-download-size variable is 31457280 bytes~30Mb. I guess this could be the underlying cause of this mess, since the three files cdrom/system/NON-HLOS are all over that threshold...
I'm going to do some more digging.
...
Here's what led me to the original conclusion:
OKAY [ 2.402s]
writing 'system'...
(bootloader) Preflash validation failed
FAILED (remote failure)
finished. total time: 2.677s
Click to expand...
Click to collapse
[Solved] Broken ICS
Tedious procedure averted! :laugh:
rsd 6.1.4 is the only way to go. 5.6/5.7 are almost worthless with this phone. Back to stock, camera/bt/wireless/radio working!
Going to work on consolidating everything I've learned in the last three weeks...
t1nk_2 said:
Tedious procedure averted! :laugh:
rsd 6.1.4 is the only way to go. 5.6/5.7 are almost worthless with this phone. Back to stock, camera/bt/wireless/radio working!
Going to work on consolidating everything I've learned in the last three weeks...
Click to expand...
Click to collapse
Oh yeah that didn't even register. Yeah have to use 6.1.4
Sent from my MotoAHD Maxx
(I know this thread maybe should belong to Development forum, but I'm posting here since I don't have enough posts to discuss there yet)
I'm in the second year of Computer Science, being a dynamic/interpreted languages programmer for over 6 years now, C/C++ for 2 years.
I have a solid understanding on the x86 PC architecture: interrupts, buses, etc. I'm pretty good at basic x86 assembly... Been studying UEFI for over a month... Whatever.
I've lost the past couple hours searching but didn't find anything on the architecture of our device. Is the "Bootloader" here compared to a BIOS? Or is it like any PC bootloader (MS-DOS, Windows, Linux bootloaders). Is there anything like a BIOS at all or does the OS, once booted, manages all the hardware interrupts by itself? Can I use INT 10H on XT890? Is it ANYTHING close to the PC architecture?
PCI, ISA, (parallel and serial) "ports" managed by a chipset between the peripherals and the x86 core itself?
Ok, it's x86. Once the system has booted, we can call x86 instructions, ok... But what is under that? Is there any reference on this? How can I boot my own code, if it's not Linux?
I really got nowhere trying to learn about the architecture underneath Android and Motorola's Bootloader on Medfield. Found nothing on Intel nor Motorola websites. What am I doing wrong?
Thanks in advance!
I'm studying this myself but there is a lot that i need to learn. Check those to see if helps.
http://bootloader.wikidot.com/android
http://elinux.org/Android_Booting
http://www.ibm.com/developerworks/linux/library/l-linuxboot/
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Using @thiagomtl's links, I was able to understand a little more about the Boot process. XT890 seems to have basically the same mechanics of the ARM ones, but x86 tuned.
However I'm yet to understand the differences between "normal" Linux bootstrapping and the Android Bootloader's one.
On a average legacy Linux box we have GRUB/LILO on the MBR. Making a hell of a simplification here: The user turns the PC on, BIOS does the POST and then loads whatever code is on the MBR. GRUB is a very small program there, which simply loads a driver for the storage device, loads vmlinuz and the f*ing ramdisk on the memory and executes it (effectively by simply pointing the IP to the address where the kernel is on the memory).
Samuelgames said:
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Click to expand...
Click to collapse
But the Boot process is just a part of my original question. Ok, a important one, but a part.
What about the structure of the device? How it's all implemented? Is the display using plain old VESA VBE? Are the input devices PS/2? USB? Is the power implemented using ACPI standards? lol
As far as I'm concerned Atom SoC doesn't respect many industry standards for the architecture, even for those who run Windows 8, buttons on the Razr I should be naturally be defined as GPIO as the notification LED, I don't think the display respects VESA standards (SGX 540 can't even do scaling) but it should fallback to them at some extent depending on how you initialize the framebuffer.
All of this should be in the Motorola kernel, I haven't taken a look at it but I'll surely will once I get my phone
@Hazou, @YaPeL, @Omar-Avelar
you guys know anything about this?
Ok this is all i know about it by searching through the code and internet and by finding out myself (no sources included, just my memory). It's all linux, nothing like Windows.
Kernel:
We indeed are making a x86 kernel, but not for normal PC's. We use the mid-x86 implementation within the x86 code of the kernel. (arch/x86/platform/mid-x86) MID is the intel word for all the socs for mobile platforms intel is using. The normal upstream linux doesn't provide all the necessary code. And is has changed with the new android version 4.4.2 for our device.
Boot sequence:
The android devices use some sort of bootloader. Droidboot. Droidboot includes the fastboot commands and starts the bringup of the android system. You can read about it on the internet. In most devices (ARM) it is the first thing thats get called for.
Our intel device is a little different. Before the droidboot gets loaded the firmware of the device loads another OS. Also called POS (i think preprocessor OS, or something). Those gets updated with the dix and efwi(wrong name) files we got. The POS can be accessed by booting in the medfield download through the camera button, if i am correct. The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
To comment about the JB implementation.
We can build our own kernel and we can, if we want and take the time, upgrade the kernel to the newest version (for android is that 3.10, but we should be able to manage to go fully upstream 3.17). But that takes a lot of time.
I also noticed that, from what i heard, some kernel modules specific for our device has changed and now the kernel that we have can't load the new firmware files in 4.4. So we will need the next kernel from Moto to compile our own when 4.4.2 is released. Those changed are not upstream.
Hazou said:
The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
Click to expand...
Click to collapse
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Flacid Monkey said:
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Click to expand...
Click to collapse
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Hazou said:
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Click to expand...
Click to collapse
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Flacid Monkey said:
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Click to expand...
Click to collapse
I am almost certain it can be fixed as long as it is a software failure (some maybe have a hardware failure). As this seems one of them it should be fixable as long as your BL is unlocked. With a locked bootloader u don't stand any chance (nah, maybe with medfield flasher, but that one is also limited).
Take a look at the acer padphone or something. Dunno how it is called exactly. Is also uses the intel SOC and makes use of the medfield flasher.
I never had a phone thats corrupt so can't say much about it, but i can help with thinking my way through. If u have that problem can u boot in fastboot or is that even impossible? I know we can flash the POS and fastboot through xfstk. So with the right combination it should work. And if not we can try flash the modem as extra if that is possible. But do know it can hard-brick the device (modem, lowest thing of the device) of-course, aldo u don't have much choice now
Another thing, because fastboot (and even recovery) can flash the dix, ifwi and bootloader files. I 'assume' xfstk (that can also flash the ifwi, dix and bootloader) can flash the whole emmc with indeed the right parameters. We have the source code of the fastboot/recovery ifwi, dix and bootloader flasher. Also called update_osip.
So think it out, i will wait and see.
uart console
Has somebody tried to access a uart console on our razr-i? would be nice for debugging.
Intels datasheet says the board has 3 uart ports. http://ark.intel.com/products/70097
I hope one uart port can be accessed via usb or audio jack. Like on this device: http://forum.xda-developers.com/showthread.php?t=1081743
Or is it only possible with opening the phone and looking for jtag pins?
What's the size of system, data and cache partitions for the Xiaomi Mi8?
Could you please show the sizes of its partitions, please?
I haven't bought the mobile yet.
I've had problems with older mobiles because these partitions are too small and many apps complain, specially Google services.
There are some complex tutorials to modify partition sizes with adb commands but are specific to each phone.
What's the best/easiest way to achieve it with the Xiaomi Mi8?
skanskan said:
What's the size of system, data and cache partitions for the Xiaomi Mi8?
Could you please show the sizes of its partitions, please?
I haven't bought the mobile yet.
I've had problems with older mobiles because these partitions are too small and many apps complain, specially Google services.
There are some complex tutorials to modify partition sizes with adb commands but are specific to each phone.
What's the best/easiest way to achieve it with the Xiaomi Mi8?
Click to expand...
Click to collapse
What you're talking about is issues with old budget phones.
Even the modern budget phones have partitions big enough to fit files in without issues.
And the Mi 8 is a flagship so you have nothing to worry about when it comes to partition sizes.
The Marionette said:
What you're talking about is issues with old budget phones.
Even the modern budget phones have partitions big enough to fit files in without issues.
And the Mi 8 is a flagship so you have nothing to worry about when it comes to partition sizes.
Click to expand...
Click to collapse
Anyway, could you please tell me the size of its partitions, please?
Just to know the information.
Thanks
The Marionette said:
What you're talking about is issues with old budget phones.
Even the modern budget phones have partitions big enough to fit files in without issues.
And the Mi 8 is a flagship so you have nothing to worry about when it comes to partition sizes.
Click to expand...
Click to collapse
In another forum somebody has just told me his mobile has this partitions (diskinfo):
Data 52.5 G 3.9 used 48.4GB free
System 2.9G 2.1G used 872MB free
Ram 5.5. GB 2.9GB used 1.6GB free
As you can see the System partition is quite small and almost full, even if the phone is a new model the problem is still there.
We need a method to easily enlarge that system partition, and maybe other not shown there.
skanskan said:
In another forum somebody has just told me his mobile has this partitions (diskinfo):
Data 52.5 G 3.9 used 48.4GB free
System 2.9G 2.1G used 872MB free
Ram 5.5. GB 2.9GB used 1.6GB free
As you can see the System partition is quite small and almost full, even if the phone is a new model the problem is still there.
We need a method to easily enlarge that system partition, and maybe other not shown there.
Click to expand...
Click to collapse
You're the only one who thinks that. Try repartitioning yourself but don't complain when you brick your phone.
skanskan said:
We need a method to easily enlarge that system partition, and maybe other not shown there.
Click to expand...
Click to collapse
I've done this job, in the past, with my Oppo Find 7 (see here - https://forum.xda-developers.com/fi...st-custom-storage-partitions-v1-oppo-t2930576).
I discourage all of you to repeat a job like this - unless you have a tool (usually a MS Windows tool) that recreates all the storage's internal partitions (jn the same way as done in factory) and only if you have a very high-level know-how to face and solve all possible issues and matters - be even ready to say good-bye to your phone !!!
italianquadcore said:
I've done this job, in the past, with my Oppo Find 7 (see here - https://forum.xda-developers.com/fi...st-custom-storage-partitions-v1-oppo-t2930576).
I discourage all of you to repeat a job like this - unless you have a tool (usually a MS Windows tool) that recreates all the storage's internal partitions (jn the same way as done in factory) and only if you have a very high-level know-how to face and solve all possible issues and matters - be even ready to say good-bye to your phone !!!
Click to expand...
Click to collapse
This is the kind of tutorial I've already seen before.
The problem is almost always the same, the rely on a script designed specifically for a phone model.
I could try to translate that script to my phone using generic adb and linux commands but it will be dangerous.
I've also heard that some versions of TWRP can resize the partitions easily. It would be great to get it on the Mi8.
What is the worst thing that can happen if all goes wrong?
Wouldn't I solve it by just wiping everything from a fastboot and resintalling a ROM?
Regards.
skanskan said:
This is the kind of tutorial I've already seen before.
The problem is almost always the same, the rely on a script designed specifically for a phone model.
I could try to translate that script to my phone using generic adb and linux commands but it will be dangerous.
I've also heard that some versions of TWRP can resize the partitions easily. It would be great to get it on the Mi8.
What is the worst thing that can happen if all goes wrong?
Wouldn't I solve it by just wiping everything from a fastboot and resintalling a ROM?
Regards.
Click to expand...
Click to collapse
There is no reason to touch the partitions of modern smartphones, all the most important partitions are big enough to contain all binary codes for the operating system and personal data we need.
Whenever we unlock the bootloader, we have full access of the emmc, so we can even delete/resize/create partitions. The first con is that we could not start the phone anymore, due to the fact that android, recovery and fastboot, reside in three different partitions. If we delete these partitions, there is no way to access the smartphone. In this case an external application for Windows or Linux (created by the manufacturer) must be used to rewrite all the emmc again, recreating the partitions and rewriting them, in the same way as done in factory. This application is the most important piece of software we must have if we want to mod our smartphone.