Related
Hi, I´ve been modding my sgs for a year or so, I have tried hardcore speedmod and from there I later moved on to the cyanogenmod 7.1 nightlies.
I am familiar with odin, used it a lot and had a couple of panic flashes, once because nandroid restore failed. This seems unlikely, but it might have been because the rom was the stock 2.3.5.
Now I was thinking about all the partitions that are supposed to be on the internal memory (not the sdcard right?) and why wiping boot or recovery is tremendously fatal.
On a pc there is always the bios, and the bootloader can be installed in the mbr of the partition. Are the android bootloaders all similar regardless of the manufactor, and do they work like lilo and grub do? Could you boot with grub/lilo on a android device?
Sent from my GT-I9000 using XDA App
I doubt it very much.. Been asking myself this same question many times, but even without firing up my debugger and disassembler, an obviosu answer comes to mind : on IBM-PC compatibles (and, like it or not, even your brand-new kickass rig based on the latest 1500$-worth core i7 is still considered a IBM-PC compatible, it still carries the stigmas and limitations of the good old 8086 architecture from 30 years ago), you always have a common denominator : the BIOS (or EFI for the newer machines. But it's basically the same modus operandi, or principle of operation if you will), which passes control to the 'bootstrapper' (the part which launches the bootloader. In turn, the bootloader will be tasked with finding a launchable kernel on one of the partitions of the disks it can 'see') once the POST (or power-on self-test) is completed, and hands over control to the actual bootloader (LILO or GRUB, whichever you happen to be using), which will finish the boot sequence and load the rest of the whole circus...
On mobile devices the situation is entirely different, what with different device manufacturers using different processors (even if they're mostly all based on a basic common architecture, like the ARM specification that's so dear to our Andro-devices) and whatnot, all of which probably use very different bootloaders -which for the most part are incompatible and not interchangeable. It'd be too easy, and manufacturers would sell less hardware if we could all swap parts too easily
Hence the need for a specific bootloader (or more accurately 'bootstrapper', since the crucial part is when the chipset hands over control to the initramfs. The bootloader is the next step) for each device -or at least for each family of devices that are based on the same chipset (heck, even among the Samsung Galaxy family of devices, you got a truckload of different bootloaders which are not interchangeable. Try flashing the bootloader of a SGS2 on a i9003, and you'll most certainly earn a free trip to the nearest Samsung service centre)..
Those devices are just too "cutting-edge" (and the manufacturers too busy shooting at each other's feet to even think about consumers interests, let alone actually working towards satisfying the end-user) to be standardized like the PC architecture has been standardized (and looking back, even this has taken years to accomplish and countless -and endless- meetings among the representatives of the different corporations, who all had to work together to accomplish that, and all this in spite of their conflicting interests... Just see what happened with the HD-DVD and the Blu-ray standards to get an idea of the mess it can be, and how it always winds up taking the consumer hostage, caught in the crossfire)... :/
But to answer the basic question : booting an Android via GRUB *should* be doable -provided that GRUB is compiled with the specific optimizations and adresses needed by the host architecture (it'd probably be different whether your device is based on a Exynos CPU or a Qualcomm-based ARM clone, for example)- but this kinda makes the point moot, since you'd still be needing the specific libraries that the chipset needs in order to make it work, otherwise GRUB wouldn't know how to "talk to" the device in order to tell it to 'boot this kernel out of this partition, with such and such extra parameter'.. :/
When you read some applications that says they "may not work with all devices"
Is things like this only because the phone doesn't have all the same built in things, or do phone makers add specific things to the android phone that only their device has?
Processor and ram and version of android are the big ones i'd say
gamax92 said:
When you read some applications that says they "may not work with all devices"
Is things like this only because the phone doesn't have all the same built in things, or do phone makers add specific things to the android phone that only their device has?
Click to expand...
Click to collapse
Its because different versions of android added new features and as a result apps that use them won't work on earlier versions.
But also because some phones have features the app needs that other phones don't such as gps or 1 gigabyte ram.
Dave
( http://www.google.com/producer/editions/CAownKXmAQ/bigfatuniverse )
Sent from my LG P920 using Tapatalk
gamax92 said:
When you read some applications that says they "may not work with all devices"
Is things like this only because the phone doesn't have all the same built in things, or do phone makers add specific things to the android phone that only their device has?
Click to expand...
Click to collapse
Comes down to the fact that android devices range so much in spec from quad core with 1GB ram to like 500mhz single core with 256mb ram, plus a host of other things like front facing cameras, and other senses, and thats before you start on the changes each version of android bring.
The fact is for quite a few things they will only work on certain version of android with enough ram/processing power
It has come to light that the GPe Moto G uses EXT4 for the userdata partition, rather than F2FS like other models. Something worth considering if you plan to buy this version, or flash it's ROM.
What's the big deal about F2FS?
Well, in a nutshell, it appears that it performs tremendously better than other traditional file systems, like EXT4, which (most) Android devices currently use.
Notably, the Moto G uses F2FS, and performs much better than other high-end devices, including the Moto X, the HTC One and One Max, the Nexus 4, etc. In fact, the Moto G is nearly as fast as the Nexus 5.
This is made even more significant because the Moto G does not have traditional NAND, but rather is using nothing more than the eMMC used in MicroSD cards.
This means that the Moto G's performance should be inferior to many devices, but instead is incredibly good, based upon how well F2FS operates.
Click to expand...
Click to collapse
http://www.reddit.com/r/GalaxyNexus/comments/1t7a17/can_we_discuss_f2fs_on_the_galaxy_nexus_seems
It does appear to F2FS does offer about a 30% I/O perf improvement across the board, but in some cases, it can be as much as 300%, which is insane.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=48843902&postcount=3
F2FS (Flash-Friendly File System)
One reason ANDROID become slow over time is the lack of instructions TRIMM before version 4.0.
The MotoG has the TRIMM and F2FS that allow a very good performance, lack of F2FS in GOOGLE version is bad news
Ps Moto x has f2fs too and f2fs was developed by samsung
I wonder why they choose EXT4 for the GPE :/
At this time; it looks like they deliberately reduced the performance of the GPe version. Unless they have changed from using eMMC to NAND for internal memory, tests should reflect the downgrade. Perhaps they have deliberately done this to minimize sales cannibalization of other GPe devices.
lost101 said:
Perhaps they have deliberately done this to minimize sales cannibalization of other GPe devices.
Click to expand...
Click to collapse
I cant' see many people checking what file-system the phone uses before deciding on which one to choose
I'm thinking/guessing it's maybe more a technology and/or developer reason,
But hey who knows
I flashed the GPE ROM today to my UK Moto G, and although i do like that it uses less RAM,
I think i have decided to go back to the UK Kitkat.
I was thinking more from the perspective that the GPe Moto G may now be clearly slower than the other devices in the range, whereas before (using f2fs) the difference wasn't so obvious. That would influence sales.
hrownar legisla
There is no difference in antutu. Both reach about 16850-17000 points.
I have used the normal one for 2 month, now after google sold Motorola to Lenovo i decided to flash it into a GP-edition.
( All Custom roms I tried, don't work well )
The Phone has about 300mb more space on sd and the feel is that it is faster than the normal version. Mayby because of about 60mb more free ram when it operates.
I'm running Nexus G+ which is based on GPE and the data/userdata partitions are still F2FS according to mount.
lmulli said:
I'm running Nexus G+ which is based on GPE and the data/userdata partitions are still F2FS according to mount.
Click to expand...
Click to collapse
That Means Best of Both worlds
Ran 4.4.2 ROM for a few weeks, now on GPE, performance wise it feels exactly the same. More storage and RAM though.
It should be easy enough to format the GPe's userdata partition to F2FS.
Well, I can tell after reading the drivel quoted in the OP that it's complete bull****.
1) eMMC smokes NAND in performance and has done so for years.
2) Every device on the market has used eMMC for years. The last time I saw a device with dedicated NAND instead of eMMC was the original Samsung Aries (Galaxy S1) family. The last Nexus to use NAND was the Nexus S. Galaxy S2 and all newer devices have been eMMC. (In the case of Nexus devices - the Galaxy Nexus was eMMC as have all Nexus devices since it. Galaxy Nexus was particularly notorious for the fact that Google first discovered the infamous "Samsung Superbrick" bug during prototype development. Google forced Samsung to fix their defective eMMC for the GNex, but Samsung continued to use the defective flash for months in their own devices and also provided it to other manufacturers.)
3) eMMC is far more than just a soldered-on MicroSD. While there is a common subset of functionality, eMMC supports transfer speeds and bus widths significantly wider/faster than MicroSD. (e.g. eMMC will always be SIGNIFICANTLY faster than MicroSD, unless possibly you compare 3-year-old eMMC against brand new MicroSD.)
It's questionable as to whether f2fs really provides that much benefit over ext4. It seems to depend partly on the performance of the underlying device - on MicroSDs it provides a performance benefit. On SATA SSDs it provides little to no performance benefit in most cases, and is slower in some. eMMC is somewhere in between these. In the one benchmark in http://www.phoronix.com/scan.php?page=article&item=linux_f2fs_benchmarks&num=1 where f2fs significantly outperformed everything else, there was clear evidence it was doing so by sacrificing data integrity. (Think along the lines of that horrific per-file fsync disable patch some kernels have. It's awesome for benchmark epeen but horrible for data integrity.)
Some more information:
Beyond the anecdotal evidence above that f2fs has data integrity issues, I can now personally confirm that f2fs is far poorer than ext4 at data integrity.
In the process of bringing up omni, a bug was causing frequent reboots of the device during bootup. This caused a large number of "ghost files" on the filesystem. They would appear if you did "ls *" but spit out an error that they didn't exist. Not good when that happens on your dalvik cache.
These files couldn't be created, nor could their directory entries be deleted. An attempt to run fsck.f2fs would just crash with an assertion error. To fix the issue I had to completely reformat the /data partition. (Not just a typical wipe/factory reset which leaves the "sdcard" contents in /data/media)
With ext4, those files would have been deletable and fsck would've actually done something.
I thought I would lose performance with gpe but no. Can't feel that. I like seeing more free ram but there is no feelable performance change
Gesendet von meinem XT1032 mit Tapatalk
Will it be more difficult to get CM11 running on the GPE version with the ext4 filesystem on /data? Flashing a ROM alone won't change the filesystem on /data (afaik), but will there be an option for format to ext4 on any of the recoveries?
I'd rather buy the GPE version, but my ultimate goal is to get CM11 running on it, so I hope it won't be a problem.
F2FS Put to the Test Against EXT4
F2FS proved to be faster on the Z1 than EXT4 in the vast majority of cases.
Storage write speeds were improved to an even greater degree for sequential and random writes in this synthetic benchmark, with both being greater than two orders of magnitude faster on F2FS.
Click to expand...
Click to collapse
www.xda-developers.com/android/f2fs-put-to-the-test-against-ext4
Two things.
1) fsck.f2fs is currently more of a debug tool than a repair tool. It makes no attempt to fix errors that it finds and typically bails on the first major problem it sees.
2) The F2FS driver in the G and X has a number of differences compared to the upstream kernel. They are available in our git hub. The problems that you encountered would be expected with the upstream driver.
Russ
Entropy512 said:
1) eMMC smokes NAND in performance and has done so for years.
Click to expand...
Click to collapse
eMMC is NAND. A specific, particular implementation of NAND flash, but NAND nonetheless. I don't think any smartphone, to this date, has used NOR flash memory.
rknize said:
Two things.
1) fsck.f2fs is currently more of a debug tool than a repair tool. It makes no attempt to fix errors that it finds and typically bails on the first major problem it sees.
2) The F2FS driver in the G and X has a number of differences compared to the upstream kernel. They are available in our git hub. The problems that you encountered would be expected with the upstream driver.
Russ
Click to expand...
Click to collapse
Adding a reference the github russ mentions : https://github.com/MotorolaMobilityLLC , just in case the Omni folks want to have a look.
Photon Q - Upgrade ram to 2GB
I have yesterday upgraded on one xt897 mainboard original Elpida 1GB LPDDR2 to new Samsung 2GB LPDDR2 K3PE0E000A-XGC2.
I have first carefully desoldered old ram from msm8960 SOC, then i make all balls on cpu flat, then cleaning and then soldering new RAM.
Phone boots normally without problem. BUT problem is, that is still visible only 1GB.
I am sure, that MSM8960 can support 2GB RAM (for example Blackberry Q5).
If anyone have idea , how to use full 2GB RAM, then please let me know
...tomorrow i will post some pictures
this would be really great.
maybe its all about the BSP?
https://en.wikipedia.org/wiki/Board_support_package
http://www.ti.com/devnet/docs/catalog/embeddedsoftwarefulldetails.tsp?productId=22800
Wow! I'd buy this if you can get it to work...
Does it need a kernel mod or something?
boofus said:
Wow! I'd buy this if you can get it to work...
Does it need a kernel mod or something?
Click to expand...
Click to collapse
I'm guessing you didn't read the entire post (which you also quoted...)
CornholioGSM said:
Phone boots normally without problem. BUT problem is, that is still visible only 1GB.
Click to expand...
Click to collapse
arrrghhh said:
I'm guessing you didn't read the entire post (which you also quoted...)
Click to expand...
Click to collapse
I read the whole post.
It might be that a kernel mod or boot option is needed to detect all the RAM. Some old linux systems had to have the kernel re-built for different amounts of RAM. That isn't likely here I'd guess, but it's possible that it is hard coded or need a menuconfig change or a boot option. I don't know anything about the kernel on the photon Q, so thought I'd ask.
CornholioGSM said:
Photon Q - Upgrade ram to 2GB
I have yesterday upgraded on one xt897 mainboard original Elpida 1GB LPDDR2 to new Samsung 2GB LPDDR2 K3PE0E000A-XGC2.
I have first carefully desoldered old ram from msm8960 SOC, then i make all balls on cpu flat, then cleaning and then soldering new RAM.
Phone boots normally without problem. BUT problem is, that is still visible only 1GB.
I am sure, that MSM8960 can support 2GB RAM (for example Blackberry Q5).
If anyone have idea , how to use full 2GB RAM, then please let me know
...tomorrow i will post some pictures
Click to expand...
Click to collapse
Do you have any news regarding 2GB mod? Have you tried contacting kabaldan?
---UFO--- said:
Do you have any news regarding 2GB mod? Have you tried contacting kabaldan?
Click to expand...
Click to collapse
Hello, still waiting for updates
Nadlabak heve one 2gb unit from me
Cornholio, if this works out, you're my hero - again. If I'm ever in CZ again I'll try to find you and buy you a keg. [I'd say a beer, but that doesn't express enough appreciation - even tho the Budweiser there is better than the US "beer" with the same name.] You already figured out the sim slot (and modded a couple phones for me), which allowed me to use PQ when I worked for a company (in US) that gave me free AT&T phone & sim (for which I move the sim to PQ). But, after many years arguing PQ is the best and can do it all, I'm finally getting to the point I was thinking about getting a new phone (moto z with keyboard mod)., not cuz I want a bigger screen or even cuz I want LTE (which I now have with freedompop anyway), but because of the limited memory (and desire to run new apps and switch between them faster). So more TP you to my friend.
Hi all,
If adding RAM is possible, my XT897 could work perfectly. I'm daily using it as the best phone ever for IT supporting with qwerty keyboard.
As someone mentioned above,
(1) In case of Kernel built with 1GB RAM option. It would not easy to get the kernel source to rebulit it.
(2) Boot option problem. In my understanding, linux kernel would auto recognize RAM size at boot. It might not the cause of issue.
(3) My guess some circuit modification is needed. such as address bus for the RAM chip A0...A19 for 1GB RAM and A0....A20 for 2GB RAM. Is there anything like jumper to ensure connecting the new A20 pin correctly?
Sorry for my English and hope this help
Ric
-------------------
Motorola Photon Q XT897 with Sim Mod , LineageOS 14.1
Thank You
i mean , that it is problem inside bootloader - bl is preprogrammed for 1gb ram.
i am able to solder to SOC processor new 2gb ram and it works without problem.
BUT .... visible is only 1GB.
I am only stupid HW technician, but this is "sw" problem and i dont know how to solve this problem
@CornholioGSM
Likely all you need is to pass a simple command to the kernel on the very early boot phase.
Probably something like mem=2G would be enough.
So pretty simple in theory and also pretty simple in linux on a PC (all you have to do is to add that command to grub.cfg assuming you use grub as bootloader).
In android is a bit more complicate because (I guess) you have to unpack and repack the boot.img and possibly the zimage (the kernel) which is inside the boot image.
And that procedure is slightly different across various devices, so experimentation and some work will be needed.
I could look in to that, but obviously a modded logic board in my hands would help a lot the process.
Did you try seeing if the bootloader can see it from fastboot with the "mfastboot getvar all" command?
Follow this guide: http://www.hardreset.info/devices/motorola/motorola-xt897-photon-q-4g-lte/faq/read-info-fastboot/
Also: I don't know about the bootloader in the XT897, but most ARM bootloaders use devicetree to tell the kernel about things like RAM configuration. I suspect that this will take priority over boot parameters, but I don't know for sure. What might be needed is a kernel that forces a specific RAM configuration.
Hi,
Great to see everyone contributing...I will take this opportunity to clear things up and focus on what actually needs to be done to get this working.
1. Those who mentioned getting hold of a BSP and SoC manuals are on the right track, but it is very difficult to get these from Qualcomm. It could only be through some back-channel via a dev at a big company that used the MSM8960. Getting access to this would be *huge*. Alternatively, a knowledgable person who has worked on an MSM8960 or similar Qualcomm SoC design.
2. boofus is correct in that the bootloader ordinarily passes memory map (and other) info to the kernel via devicetree. Either the bootloader needs modifying to pass a new memory map, or this has to be overridden in the platform code in the kernel (not difficult).
3. Changing commandline arges to the kernel is trivial (don't even need to rebuild anything, just extract the boot.img partition, edit and reflash--I have done this many times to tweak kernel args), but saying mem=2GB on the kernel commandline is unlikely to have any effect, because the kernel doesn't have a memory map describing at which physical address additional RAM is present.
4. Moreover, the DDR2 memory controller in the SoC has to be programmed to enable the 2nd chip select for the upper half of RAM. If this is not done, then the RAM is not even in the physical memory map. So any attempt to get this working must start here.
Currently, both nadlabak and I have 2 GB modded boards for testing. I'm stretched for time at the moment to look into this--much as I would *love* to have 2 GB--as someone else noted, 2 GB on the Photon Q would bring it back up to a usable level.
We would be *very* lucky if the Moto-supplied bootloader senses attached memory and configures the DDR2 controller accordingly, and even more lucky if this mapping was added to the device tree. It also has to be taken into account the baseband memory. This will fall somewhere in the physical memory map, and the memory made available to the kernel has to be outside the areas used by the baseband.
IF the xt897 bootloader is highly generic and used on other Moto phones with differing amounts of RAM, it *may* automatically detect and set everything up. If it does we would be *very* lucky. It's easy to see if this is being passed to the kernel via the devicetree, and presumably, in this case, the bootloader would also print the found memory size when booting into one or more of the bootloader stages using the key combos. Once I get my modded board into a phone I can at least check these trivial points. I have a handy comandline tool for probing physical memory, so I can easily get the existing memory map, and from that infer location of added memory. Then it is easy to attempt reading and writing where the extra memory would be if the DDR2 controller were appropriately configured, and see if memory is actually present.
More likely, the bootloader is hard-coded with the 1 GB memory map and programs the DDR2 controller accordingly. If so, to get additional RAM working requires:
1. Reprogram the DDR2 controller to enable 2nd CS. If we had the MSM8960 SoC manual and ability to extract and disassemble the relevant loader and replace it with a modified one, this would be almost trivial. However, I understand there may be encryption or signature verification preventing us from modifying early stage loaders. (This is also a fast way to permanently brick a phone, so we'd have to test changes on throwaway boards first.) If loader is protected, then we'd have to reprogram the controller on-the-fly. This probably can be done, possibly even within the kernel, if we don't have the ability to change the early loader(s), but may be a little complex, since reconfiguring the DDR2 controller may make memory temporarily inaccessible. Hence techniques such as locking the controller re-programming code into cache and waiting for the controller to come up again may be needed. However, this may crash the baseband. If the controller supports reprogramming without interruption, this would make things vastly simpler. All we need is the MSM8960 manual and specifically, the sections describing the memory map and DDR2 controller.
2. Once memory controller is reprogrammed, it's trivial to hack the new memory map into the kernel, whether or not we can change the devicetree passed from the loader.
TL;DR: yes we all want to get 2 GB working; it's almost certainly not trivial; it probably can be done, but likely requires extensive effort and knowledge from someone who has designed a product using the MSM8960, or access to manuals, or extensive reverse-engineering effort.
If anyone would like to step up please say so. I'll work on it myself as I have time and hope nadlabak will too. I personally can't wait to get a working 2 GB xt897.
---------- Post added at 04:19 AM ---------- Previous post was at 04:11 AM ----------
In sum, if anyone has access to any of the following, *please* let us know:
- MSM8960 SoC manuals;
- Knows someone who has developed MSM8960-based products or otherwise has knowledge of the MSM8960 architecture and especially the memory controller;
- Knows something about the xt897 or typical Moto bootloader structure, whether Moto often shares bootloaders across devices, and most importantly what loader stages there are, and whether each of these is encrypted/signature-verified, precluding making changes, or whether we can change it.
CornholioGSM said:
Photon Q - Upgrade ram to 2GB
I have yesterday upgraded on one xt897 mainboard original Elpida 1GB LPDDR2 to new Samsung 2GB LPDDR2 K3PE0E000A-XGC2.
I have first carefully desoldered old ram from msm8960 SOC, then i make all balls on cpu flat, then cleaning and then soldering new RAM.
Phone boots normally without problem. BUT problem is, that is still visible only 1GB.
I am sure, that MSM8960 can support 2GB RAM (for example Blackberry Q5).
If anyone have idea , how to use full 2GB RAM, then please let me know
...tomorrow i will post some pictures
Click to expand...
Click to collapse
You will need to make custom software to support this mod. I recently purchased this phone and the amount of hardware mods i has blows me away. I am excited and scared to do all these things, I spent 150$ USD on this sim modded Photon Q to replace my Droid 4 and the idea of losing it all freaks me out BAD.
Back to the software, the problem is that all the device/kernel configurations are built around 1GB ram, so they will only utilize 1GB of the 2GB of ram, assuming the system even detects it at all! Its neat that you have done this, now that you have modded the hardware, its time for you to mod the software
Once again, the main problem is that I need the MSM8960 application processor developer manual. Someone who has worked on this SoC could make the manual available to me (anonymously due to NDA).
I hope someone can help me here!
CornholioGSM said:
Thank You
i mean , that it is problem inside bootloader - bl is preprogrammed for 1gb ram.
i am able to solder to SOC processor new 2gb ram and it works without problem.
BUT .... visible is only 1GB.
I am only stupid HW technician, but this is "sw" problem and i dont know how to solve this problem
Click to expand...
Click to collapse
If we could grab a bootloader file and edit it (probably with hex edit grrr) we might be able to see if it just lists the hardware values, and in that case simply add 1024 to the ram value
Surprised no one has given this a peak. I'll give it a shot if I have any time but if I **** it up someone is getting their phone bricked.
CornholioGSM said:
Photon Q - Upgrade ram to 2GB
I have yesterday upgraded on one xt897 mainboard original Elpida 1GB LPDDR2 to new Samsung 2GB LPDDR2 K3PE0E000A-XGC2.
I have first carefully desoldered old ram from msm8960 SOC, then i make all balls on cpu flat, then cleaning and then soldering new RAM.
Phone boots normally without problem. BUT problem is, that is still visible only 1GB.
I am sure, that MSM8960 can support 2GB RAM (for example Blackberry Q5).
If anyone have idea , how to use full 2GB RAM, then please let me know
...tomorrow i will post some pictures
Click to expand...
Click to collapse
Have you solved this problem? I also encountered the same problem. The 2GB running memory chip I replaced was BA164B1PF. And the eSIM chip was removed, and the mini SIM card slot was installed. In addition, I replaced the CPU at the same time, and now the status code number has become 1.So it is became an engineering machine, and the BootLoader lock is completely invalid.
not solved...and i am now on fxtec phone. I have not changed whole cpu (why) i have changed only ram...whole problem is, that data on one emmc partition are paired with cpu...same problem happens if you change emmc from another mainboard.
CornholioGSM said:
not solved...and i am now on fxtec phone. I have not changed whole cpu (why) i have changed only ram...whole problem is, that data on one emmc partition are paired with cpu...same problem happens if you change emmc from another mainboard.
Click to expand...
Click to collapse
Very old mobile phones do not have the problem you mentioned. The reason I did this is that my technique is very poor and I cannot repaint the upper layer of the CPU with tin. I am just an DIY amateur. In addition, I tested other mobile phones using the same CPU and found that Motorola not only limits the RAM capacity, but also the speed, which is only about half of normal.
I replaced the emmc chip, and the test proved that 64GB of storage space can be successfully used, and faster, except for games. I have some additional questions that I need your help, and I have already emailed you.
Disclaimer: This is an open discussion thread for How to do virtualization on Android! It's not a reference or guide! But hope this thread can lead us towards making a way to do it!
Intro: Once phones was a tiny piece of electronic device which was mainly used to talk and sending text messages! (I am talking about mobile phones off course! )
Then here comes smartphones like the symbian one and then iphones and Android!
They opened a lot more way to do on a device rather than only talking or texting!
But still we needed to rely on laptops or desktops to do extensive tasks which we couldn't do (yet) on smartphones!
The main reason was the lack of technology or the memory and processing power limitations on these device!
I remember I bought my first Redmi 2 at a cost of 200$ back in April 2015 which featured quadcore Qualcomm processor, 1GB of RAM and 8 GB of internal storage space!
But now the time has changed! Technology advanced exponentially! After 3 years of my first Xiaomi device, I bought another one (Mi A1) with almost the same price! Whuch features double (on the basis of cores) processors and 4X RAM and 8X internal spaces!
In the mean time on the mainstream computing counterpart, virtualization technology becomes so popular that if not all but most of the servers runs based on it! We have also docker now!
We can now use or test any software/OS on any device (mainstream computers off course) by the grace of virtualization!
On the other hand, Android devs still needs to do the hard work to port ROMs let the OS itself! And yet we can't run Windows on a Android device!
But wait! Android is also a Linux! Isn't it?
So, if Linux can run QUEMU/KVM, why not Android?
And most of the Android SOCs now are 64bit!
So, can't we just make it happen? Can't we just find a way to do virtualization and run any OS on a virtual environment right in our hand?
May be!
I don't know if any guys working on this or not!
But here's how to:
1) Enable virtualization support on kernel
2) Make an apps for Android for manging the virtual machines (like VirtualBox, VMWare etc.)
I think the Android kernels (most of them) supports virtualization already!
The hardest part is to make it compatible with the frontend Android! Which brings the apps and interfaces!
I know there's wine exist for Android! But that's just a complete different thing what I am talking about!
And I wasnt able to run wine on my tissot (Xiaomi Mi A1)!
Thanks everyone who is reading!
Give your valuable opinion and ideas!
Hope someone like @CosmicDan can make it!
ARMv8 (every phone) doesn't have hardware virtualisation extensions, so it would be as slow as emulation.
For that, we already have QEMU and KVM. But it's too slow to be of any practical use.
If you want proper virtualisation, you need ARMv8.1, which no phone has.
CosmicDan said:
ARMv8 (every phone) doesn't have hardware virtualisation extensions, so it would be as slow as emulation.
For that, we already have QEMU and KVM. But it's too slow to be of any practical use.
If you want proper virtualisation, you need ARMv8.1, which no phone has.
Click to expand...
Click to collapse
Hmm! I just realised the hardest part: it's ARM and not x86_64!
ProttoyX said:
Hmm! I just realised the hardest part: it's ARM and not x86_64!
Click to expand...
Click to collapse
That's emulation, not virtualisation.
You can use QEMU, Bochs or DOSBox to emulate x86 (x86_64 is probably impossible, idk but it's pointless to try). But it's dog slow and always will be.
CosmicDan said:
That's emulation, not virtualisation.
You can use QEMU, Bochs or DOSBox to emulate x86 (x86_64 is probably impossible, idk but it's pointless to try). But it's dog slow and always will be.
Click to expand...
Click to collapse
Hmm! Got it! This thing came into my mind when I was reading about servers based on ARM! Wondered if they provides virtualization/container service or not! And ARM provides more cores than x86_64! I guess it's it's related to RISC/CISC thing! Not sure though!
ARM servers uses ARMv8.1?
AND PLEASE DON'T MIND ABOUT ENDING EVERY SENTENCE WITH (!)! PLEASE!
No one can always be rude! ?
I am surely not!
Again thanks for what you’ve done for the tissot and other staffs! You are genius! ?
ProttoyX said:
Hmm! Got it! This thing came into my mind when I was reading about servers based on ARM! Wondered if they provides virtualization/container service or not! And ARM provides more cores than x86_64! I guess it's it's related to RISC/CISC thing! Not sure though!
ARM servers uses ARMv8.1?
AND PLEASE DON'T MIND ABOUT ENDING EVERY SENTENCE WITH (!)! PLEASE!
No one can always be rude! ?
I am surely not!
Again thanks for what you’ve done for the tissot and other staffs! You are genius! ?
Click to expand...
Click to collapse
Yes those ARM servers would be 8.1. It's not so much a RISC vs CISC thing but more an SoC vs CPU thing. Our devices are SoC's - sure they have many GHz and cores but they're still a lot slower that a proper CPU which has countless of extensions designed for accelerating tasks, and have more IPC capability and other such things (in short GHz/core count is comparable across different platforms or architectures, it's more relative than that). Our SoC's simply don't have those extensions that would make this feasible.
CosmicDan said:
ARMv8 (every phone) doesn't have hardware virtualisation extensions, so it would be as slow as emulation.
For that, we already have QEMU and KVM. But it's too slow to be of any practical use.
If you want proper virtualisation, you need ARMv8.1, which no phone has.
Click to expand...
Click to collapse
Every ARMv8,and even ARMv7 has.On v8 it's called EL2 while on v7 it's HYP mode.However the biggest headache is that most SoC vendors do not allow users to enter it even with bootloader unlock.
On Qualcomm there are no way except a low level powerful exploit. On Exynos it is possible,needs a specific SMC to trustzone,and can be done only with an unlocked bootloader with custom kernel.
fxsheep said:
Every ARMv8,and even ARMv7 has.On v8 it's called EL2 while on v7 it's HYP mode.However the biggest headache is that most SoC vendors do not allow users to enter it even with bootloader unlock.
On Qualcomm there are no way except a low level powerful exploit. On Exynos it is possible,needs a specific SMC to trustzone,and can be done only with an unlocked bootloader with custom kernel.
Click to expand...
Click to collapse
do you have any references links on this? maybe a cve for the qualcomm exploit?