I hope this is the right forum. I have a generic A13 Chinese tablet but I'm having difficulty tracking down the firmware I need to flash it. There are no markings on the back to indicate manufacturer and the space on the board where the ID is supposed to be found is blank. I took some pictures of the main board, maybe you guys will see an identifying marker that I missed.
http://i.imgur.com/YPRnVDx.jpg
http://i.imgur.com/axRkExe.jpg
http://i.imgur.com/YD7a8za.jpg
http://i.imgur.com/fzrzS7s.jpg
CriticalComposer said:
I hope this is the right forum. I have a generic A13 Chinese tablet but I'm having difficulty tracking down the firmware I need to flash it. There are no markings on the back to indicate manufacturer and the space on the board where the ID is supposed to be found is blank. I took some pictures of the main board, maybe you guys will see an identifying marker that I missed.
http://i.imgur.com/YPRnVDx.jpg
http://i.imgur.com/axRkExe.jpg
http://i.imgur.com/YD7a8za.jpg
http://i.imgur.com/fzrzS7s.jpg
Click to expand...
Click to collapse
The issue you will find is that there isn't a way to get the firmware. These types of devices are hacked together devices. Half of them are set up to lie about the hardware and source code and default firmware are almost never released.
Are you experienced at all with TOM building? Perhaps you could start out with the android source code and start from scratch building a ROM that has the drivers necessary for the components that you can find.
Sent from my Super Computer (1976) with Tap Tap Talkolution
This is a bit disheartening to hear. I haven't done any work with TOM building. The closest I've ever done is modifying a stock rom and making it installable in recovery. I have been trying random Q88 firmwares with the Phoenix Card Utility. I have the device booting now at least but none that I have tested thus far have the proper touchscreen driver. I guess I could use one of these firmwares as a starting point. What would be a good resource for learning how to build a ROM and how to discover which drivers I need?
CriticalComposer said:
This is a bit disheartening to hear. I haven't done any work with TOM building. The closest I've ever done is modifying a stock rom and making it installable in recovery. I have been trying random Q88 firmwares with the Phoenix Card Utility. I have the device booting now at least but none that I have tested thus far have the proper touchscreen driver. I guess I could use one of these firmwares as a starting point. What would be a good resource for learning how to build a ROM and how to discover which drivers I need?
Click to expand...
Click to collapse
Google has its own building community and there are some great tut in this site as well.
The issue most roms are facing is that the drivers to these devices are almost never available. They tend to be hacked drivers that violate one copyright or another so they are never available to the public.
You might be able to find something on a China based site where they deal more with knock offs then we do here.
zelendel said:
Google has its own building community and there are some great tut in this site as well.
The issue most roms are facing is that the drivers to these devices are almost never available. They tend to be hacked drivers that violate one copyright or another so they are never available to the public.
You might be able to find something on a China based site where they deal more with knock offs then we do here.
Click to expand...
Click to collapse
Thanks for the quick replies. Guess it's time to do some research.
Related
Hello!
I see all these advices on making a ROM. But these advices and the issues they deal with are IMHO not the real issue. If you have a Nexus One phone and want to modify the Android OS there's nothing stopping you. It's "easy". It's all "there".
But what if you have a new Android phone which has proprietary driver code and made by a company that has NO interest in sharing it's code or make it easy for you to root your phone? Making ROMs for these devices is the interesting thing to talk about. Otherwise you can change the name on this forum part to: "Make ROM = *.android.com"
So these two issues are the most important ones IMHO:
1) Devices DO get rooted. So some people must know how to get there. I assume that there is no "one way" of doing this but it would be nice to discuss this and make some sort of a list on what to THINK about.
Many devices will never get rooted because the brand is despised here. That is why it would be good to have some general knowledge so others that ARE interested in these despised brands can take action.
2) You have a rooted device. You load a standard Android OS ROM. All proprietary drivers are lost and thus many features and maybe whole hardware units are unavailable to you. How do you locate and use unsupported hardware in your ROM?
I understand why many "elite" devs have a Nexus One since there are no propietary driver code in that one and rooting was easy. So the doorway to the Nexus One Kitchen is wide open. But what about the rest of the new Android phones that are out and will come. Why don't you discuss and explain the general thinking in rooting a device and finding/using hardware/features that are lost because of proprietary driver code.
Thanks for your time
BR
Robert
Wow, you really need to do some reading is all I will say.
carz12 said:
Wow, you really need to do some reading is all I will say.
Click to expand...
Click to collapse
+1. i don't even get his problem tbh.
Sorry first off I'm not sure if this is the right forum. Was thinking developers but there was an ominous warning at the top of that one so I decided not to take the chance.
The question is can Linux be installed on an Android based device natively? I'm aware of chroot enviroments and have done those. I also found this http://forum.xda-developers.com/showthread.php?t=981688 which is slightly cooler but it's still an AUFS based chroot mount. I found the same question asked here http://forum.xda-developers.com/showthread.php?t=1272964 but there was no answer and I didn't want to zombie the thread. Google searches didn't turn up anything useful either.
While I'm thinking the question is fairly device agnostic my device is a Droid 2 Global. I'm getting ready to replace it soon but I'm thinking it might make a nice little embedded system. From what I've read about my device in particular it's got some type of "lock" that disallows the use of other kernels but I am not afraid of recompiling the kernel for my device with additional needed modules for file systems or whatever. I have done this in the past.
I'm not super picky on the distro, but given a choice I guess I'd go with Debian (hardly ever changes so I can just check for security updates once a week or so and otherwise forget about it).
I wouldn't expect anyone to be able to answer this directly as I'm sure it'd be a novel. I'm more hoping someone might have a link to a guide or something that I just completely failed to locate.
So I kept digging and I found this: http www dot htc-linux.org forwardslash wiki forwardslash index.php. As the link suggests it's focused towards HTC devices but between it and some other links on there I think I can work with it.
I'll mark the thread as [SOLVED], but since it ended up being fairly useless (sorry) go ahead and delete if it amuses you to do so, any passing admin.
Ubuntu is coming out with an official version for Android soon.
Sent from my ADR6425LVW
I Am Marino said:
Ubuntu is coming out with an official version for Android soon.
Sent from my ADR6425LVW
Click to expand...
Click to collapse
This is probably your best answer. The Ubuntu build that runs on top of Android for webtop/lapdock purposes is running from the same kernel as Android is according to what I've heard. They will be providing the source so we'll see what the community can do with it.
It is possible on some Android devices, such as the Transformer and Desire.
But the Droid 2 Global, having a locked bootloader and the inability to install custom kernels, is not able to use native Linux.
If you want an Android device that is able to use native Linux do some research to find the one that fits you best.
Sent from my DROIDX using Tapatalk
have you seen this? interestiong reading...
http://whiteboard.ping.se/Android/Debian
Itbelikedat said:
have you seen this? interestiong reading...
http://whiteboard.ping.se/Android/Debian
Click to expand...
Click to collapse
I tried it a small time ago. Everything works but zygote and its forks fail to start, perhaps due to mount namespaces implementation on Android, but I'm not sure. Seeking a way out for this but not successful so far due to lack of knowledge.
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
I wish somebody participated in this with you. I need it also /
funkydaemon said:
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
Click to expand...
Click to collapse
Good idea. Although most probably it'll all be native C code compiled into binary form, not amenable to decompiling.
So you'd probably need a very good debugger and a system call tracing facility in strace.
I guess hell might also break loose because SIM encryption(?), voice encoders(?), network locking(?) and god knows how many of those proprietary tidbits may be sitting in there.
SIM encryption broken leading to duplication of SIMs and leading to smartcard encryption and open source tools to reprogram your credit cards with more money.
That's not hell. That's hell in a hand basket with us enjoying the ride
Keep us posted. It's guys like you who think outside the radio that gave us the TV
For Qualcomm based devices you need to decompile Hexagon code.
For other Intel XMM6260 etc based devices suffice IDA (ARM).
In both cases the raw binary blobs may be encrypted, but extractable from running machine.
I'm working on it, in a fashion, and am writing up a document compiling everything that has been done on cellphone radio hacking. I've not found much on baseband firmware; there's a lot of info out there but it's been tough to find amongst all the other hacking that has similar keywords. Currently most quality info around this subject involve an extra (and depending on desired features; expensive) bit of hardware and two open source software packages with their decencies. As the hardware is currently outside my budget ($300 for the best bang for buck) I'll be working on getting the software to recognize the hardware built in my Android devices. Provided that all goes well I should be able to read and write on the frequencies that the in-built hardware supports and hopefully, as I always get an identical device when getting one, read and write with my backup android device. Be warned if you decide to follow me down this path; there are laws restricting what non-licensed persons/companys can do on certain RF frequencies and this depends on where you live, I'm no expert only a person capable of reading lots of dry informative documents, provided I do achieve direct contact between devices this hack could (and likely will) fry one of my antennas so be warned you'll likely do the same :banghead: so do this on an old device that you don't care about before ever trying on something you use daily. With the warning out of the way lets get down to the quick version.
~~~~~~~~~~~~
Currently all the developing I've found educational has involved the before mentioned "expensive hardware" known as software defined radio, shortened to SDR, go a head and pop open a new tab and Google search either. You'll eventually find that cellphone manufacturers have likely already put these into many devices. You'll also hopefully find the two kickstarters, HackRF ~$300 and bladeRF ~$400, these are likely what I'll be saving up for; HackRF for sure as the next release will likely be able to send and receive at the same time instead of switching quickly between modes. If you dig deep enough you'll find a blog post from a hacker that plugged an Android into a much more expensive SDR and was able to place calls and send/receive text; the blog poster stated something to the effect that this was not a useful hack but I believe that it's a great proof of concept and totally worth another look. However, this hacker has also almost been sewed for some of the demonstrations with this kind of technology involving the capture and description of calls and texts so tread carefully.
The software I mentioned before boil down to GNU Radio and Open BTS; there's dependencies for each but all seem to be installable on Linux running on top of Android. Furthermore I see that someone (I'll edit your name in in a sec Edit: idcrisis ) previous mentioned wanting c or c++ support, GNU Radio uses these languages perhaps I can ask for some help when I get a little further in porting this to run without Linux in the middle so much? I think if we use the GPS to set the time then the signal shouldn't drift to much.
I'm using an app called Debian Kit to give me a flavor of Linux called Squeeze for testing the software. If you choose to try what I'm doing then make use of the readme that the developer wrote or the guide I wrote for general Linux on Android installation and interaction fund in my sig to get started. If you want access to the document I'm compiling then you'll want to PM me at this moment as the chances of hardware frying is high and I'll share a link to Google docs; I'll be releasing a full guide when I've figured out how to avoid damage.
Eventually I hope to port many of the functions in GNU Radio into an app that makes use of internal hardware. Currently I've found a few that make use of hardware plugged into Android through USB "on the go" or "host mode" just search "RTL SDR" in the app store and you'll see'em, but, currently nothing making use of internal hardware. If any are interested in joining forces and helping figure out how to do all this I'd be glad to offer any support I can.
Other things related to cellular antenna hacking other than the above mentioned software and hardware that I'm compiling into the same document. Well this is where we get into the parts I'm hitting the wall on. It looks like I'll have to get into Kernel modification as this is one of the things used to communicate between software and hardware. There's also the flashable files known as radios and I'll be digging further in how these files are modified.
Basically this is a very tough question to answer and has taken many months of reading, searching, and more reading to get this close bit if we all work together I know that we'll be able to modify how the antennas in our devices work.
Edit 01142014- Found a guide on reverse engineering embedded device firmware, the guide is on a router but as the chips in our phones are embedded perhaps the steps are similar
http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/
Sent from either my SPH-D700 or myTouch3gs or M470BSA
Guide for running Linux on Android that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
^^ NO! The embedded chips in the Linksys routers are MIPS based and not ARM like all our Androids. Very different, although technique is the same.
But thanks, for taking time to check up on all this.
Any updates ?
Hey Guys,
I'm looking into this, I've successfully extracted files from the OnePlus One's baseband, its running RtOS called REX, QC calls it AMSS.
Have a look at the thread here: http://forum.xda-developers.com/oneplus-one/general/discussion-hlos-reverse-engineering-t3292829
Waiting for the OsmocomBB update it projects
QCOM modem leaked sources.
Type in google/bing: "AU_LINUX_ANDROID_JB_MR1_RB1.04.02.02.050.116_msm8974_JB_MR1_RB1_CL3904528_release_AU"
My Atrix got it's case cracked and the touch-screen display died, and given I already got a replacement phone I feel a bit adventurous. I wanted to see if I could build my own computer with what remains, so I wanted to run Linux natively (no Android). Given that there's a Linux 4 Tegra from Nvidia:
Is there a chance that I could build my own distro based on that?
Should I use another kernel (like the one currently used in gingerbread or CM7)?
Please note that I'm not trying to do webtop.
I thought of building my own handheld with the Atrix, or what remains of it. So any tips on how to get started would be great.
Cheers!
wrong section
ovitz said:
wrong section
Click to expand...
Click to collapse
Umm... what section would you suggest other than Q&A?
It was moved. Sorry 'bout that. I was under the impression that development questions were on the other forum...
"Android development" is in the description. I think they keep that forum just for Android-specific things, even though Android is just a flavor of linux.
tonglebeak said:
"Android development" is in the description. I think they keep that forum just for Android-specific things, even though Android is just a flavor of linux.
Click to expand...
Click to collapse
You're being way too literal. It's been used for all sorts of non-Android dev multiple times. Right now, Boot2Gecko is right there. The fact of the matter is that when it pertains to dev questions, this post would most likely be answered there. I'm pretty sure it'll die here on this forum with barely any useful answer, if at all.
The development section is mostly for things that are "in progress", ie. with "something to show". Questions, discussions and ideas go elsewhere.
As for your question, I believe I've seen a thread about this already, and quite recently too.
ravilov said:
The development section is mostly for things that are "in progress", ie. with "something to show". Questions, discussions and ideas go elsewhere.
As for your question, I believe I've seen a thread about this already, and quite recently too.
Click to expand...
Click to collapse
I've checked a few that I've found on the forum, but most had no answer and were about other devices. With regards to the Atrix or the Tegra, I've only found threads about webtop.
Not to argue too much about this too much, but I've seen threads that started with nothing in the dev section. Like the Kernel porting project that started as a mere placeholder for the project. Point is, I've done my research and found no pointers to the questions I have. I made it in case another dev had an idea about it. I may have missed something, but that's why I asked in the first place. If I believed I had covered all grounds by myself, I wouldn't have asked in the first place.
Lugaidster said:
I've checked a few that I've found on the forum, but most had no answer and were about other devices. With regards to the Atrix or the Tegra, I've only found threads about webtop.
Not to argue too much about this too much, but I've seen threads that started with nothing in the dev section. Like the Kernel porting project that started as a mere placeholder for the project. Point is, I've done my research and found no pointers to the questions I have. I made it in case another dev had an idea about it. I may have missed something, but that's why I asked in the first place. If I believed I had covered all grounds by myself, I wouldn't have asked in the first place.
Click to expand...
Click to collapse
What you're looking to do seems similar to this question: http://forum.xda-developers.com/showthread.php?t=2110161
The difference between the webtop and a stand alone installation of Linux won't be that different, mainly it would just be where on the device the OS is installed and how video is handled. That said, I'm not sure about the kernel, specifically the video drivers, since they're intended for Android and may not be compatible with X. AFAIK, Wayland is closer to Android than X is, but Wayland isn't quite ready.
Anyway, assuming you did succeed, what you would end up with would be less like a true desktop (as you'd be pretty much locked into a specific kernel, and therefor any packages limited by it, but it doesn't invalidate the effort), and more like a persistent live CD, since the OS would be installed to an area mounted as read-only (to prevent flash wear), with access to an area that has read/write access, like in Android where you store apps and user files. Overall, it could be fun if you enjoy a challenge and aren't intimidated by soldering and using the JTAG connector.
lehjr said:
What you're looking to do seems similar to this question: http://forum.xda-developers.com/showthread.php?t=2110161
The difference between the webtop and a stand alone installation of Linux won't be that different, mainly it would just be where on the device the OS is installed and how video is handled. That said, I'm not sure about the kernel, specifically the video drivers, since they're intended for Android and may not be compatible with X. AFAIK, Wayland is closer to Android than X is, but Wayland isn't quite ready.
Anyway, assuming you did succeed, what you would end up with would be less like a true desktop (as you'd be pretty much locked into a specific kernel, and therefor any packages limited by it, but it doesn't invalidate the effort), and more like a persistent live CD, since the OS would be installed to an area mounted as read-only (to prevent flash wear), with access to an area that has read/write access, like in Android where you store apps and user files. Overall, it could be fun if you enjoy a challenge and aren't intimidated by soldering and using the JTAG connector.
Click to expand...
Click to collapse
Actually, I might have to do soldering anyway. I'm not really intimidated by it and don't really care all that much for phone functionality and such. I'm not even interested all that much in X as my project is more towards transforming it into a handheld gaming (more like emu) device. I don't mind compiling software specifically for the system. The question is pretty low-level in that regard for me. I want to know if I have to do anything with regards to the kernel since it's specific to Android. Given that most emus I know that would run acceptably in a tegra 2 don't really need the GPU, I don't mind just using framebuffer so HW doesn't really interest me.
Lugaidster said:
Actually, I might have to do soldering anyway. I'm not really intimidated by it and don't really care all that much for phone functionality and such. I'm not even interested all that much in X as my project is more towards transforming it into a handheld gaming (more like emu) device. I don't mind compiling software specifically for the system. The question is pretty low-level in that regard for me. I want to know if I have to do anything with regards to the kernel since it's specific to Android. Given that most emus I know that would run acceptably in a tegra 2 don't really need the GPU, I don't mind just using framebuffer so HW doesn't really interest me.
Click to expand...
Click to collapse
Unfortunately, it's going to be one of those areas where you'll have to make an educated guess, since as far as we know, no one has successfully pulled off a straight Linux implementation on the device.
That said, nVidia does have both Android and Linux images for the Ventana dev kit, so it should be possible. In my case, I would compare the source code for their Linux kernel vs the stock Linux kernel vs their closest Android kernel vs the stock Android kernel. The biggest thing is how the the device specific files translate from one kernel to another, because you'll likely need to translate the device specific files for the Atrix in the same manner. The changes may be subtle or they may be drastic. The main thing is to just be able to set the pins properly so you don't release any "magic smoke". Unfortunately, I see no source code for any of nVidia's kernels.
Anyway, that's how I would do it, but I do suspect that someone with more knowledge could find a much simpler approach and hopefully they'll chime in, but this part of the forums isn't the thriving hub of activity it used to be, so I don't know if that will happen any time soon or at all.
lehjr said:
nVidia does have both Android and Linux images for the Ventana dev kit
Click to expand...
Click to collapse
Atrix is a Whistler, not a Ventana.
http://forum.xda-developers.com/showthread.php?p=33289027#post33289027
ravilov said:
Atrix is a Whistler, not a Ventana.
http://forum.xda-developers.com/showthread.php?p=33289027#post33289027
Click to expand...
Click to collapse
Thanks for the heads up and the link! :highfive:
Why is there such alot more development and forum activity on for example the Xiaomi Redmi phones than on this one? The p9000 got excellent hardware for a great price but the community is really small somehow and the software is still buggy? How come? Do you think its still worth to wait for more activity and responses from developers for this phone or is it a "dead cow" already and better to swap to another brand to get support from developers on for example CM or RR?
furchtlos76 said:
Why is there such alot more development and forum activity on for example the Xiaomi Redmi phones than on this one? The p9000 got excellent hardware for a great price but the community is really small somehow and the software is still buggy? How come? Do you think its still worth to wait for more activity and responses from developers for this phone or is it a "dead cow" already and better to swap to another brand to get support from developers on for example CM or RR?
Click to expand...
Click to collapse
Development for this device is far from dead, we have a stable device tree for building custom ROM's, CM and RR ROM's already released, a fully source built TWRP and work on custom kernels is just beginning. That's a lot more development already than an awful lot of devices see in their entire lifetime.
I would rather say it has just begun. Development for this MTK chip is not a matter of course and the outcome so far is pretty exciting. This opens the way for other devs who work on other devices with the same chipset. It's just that many devs simply prefer Snapdragon which leads to higher dev count on those devices, faster bug fixing etc. I am pretty excited what the future brings not only for our P9000 but MTK devices in general as far as flashing and development goes.
Development is dead? What gave you that impression? For starter this phone already has a working twrp recovery. That is more then some Chinese phones get in their whole lifetime. Kernels is the area of development next and elephone has been kind to release the source code for the phone. Again more then most developers even bother with.
well, it got twrp,root and xposed working. More than some name brand phones that stop official updates after a year.
But i admit it is easier to update my old nexus 4 with cm downloader. Just click the update notification and latest cm gets installed.
It is also getting nougat in November hopefully
mangoman said:
well, it got twrp,root and xposed working. More than some name brand phones that stop official updates after a year.
But i admit it is easier to update my old nexus 4 with cm downloader. Just click the update notification and latest cm gets installed.
Click to expand...
Click to collapse
That's because Nexus 4 is an officially supported device by CM.
It's very difficult for MTK devices in general to get official CM support because we have to patch some things in the framework to make camera, RIL (mobile data) etc working.
The official stance is that these things should be done in device tree as no proprietary code is allowed in CM framework.
Initially when our patches were submitted to CM Gerrit they were rejected because of this, Leskal is working on minimising the patch work needed and getting more of the generic MTK code accepted on Gerrit.
Not helped by the fact that MTK themselves aren't helpful or willing to support developers as it doesn't suit their replace and force upgrade business model. Technically how they operate and their refusal to release official development tools or code is a violation of the open sources nature of Android. But google has yet to do anything serious about it. As far as I know, any code we have is from reverse engineering and leaks.
Android-UK said:
Not helped by the fact that MTK themselves aren't helpful or willing to support developers as it doesn't suit their replace and force upgrade business model. Technically how they operate and their refusal to release official development tools or code is a violation of the open sources nature of Android. But google has yet to do anything serious about it. As far as I know, any code we have is from reverse engineering and leaks.
Click to expand...
Click to collapse
Not true, I've met up with MTK engineers at DevCon and they do actually encourage development, they just seem to lately be wanting to protect their HAL's and drivers which as pointed out on the XDA portal article about this is sort of ridiculous. But then again it's proprietary code and not under the GPL so whilst we can say it's stupid we can't really contest it, it's their choice.
The code we have is completely official and not gotten from reverse engineering.
Jonny said:
Not true, I've met up with MTK engineers at DevCon and they do actually encourage development, they just seem to lately be wanting to protect their HAL's and drivers which as pointed out on the XDA portal article about this is sort of ridiculous. But then again it's proprietary code and not under the GPL so whilst we can say it's stupid we can't really contest ot, it's their choice.
The code we have is completely official and not gotten from reverse engineering.
Click to expand...
Click to collapse
I have seen many a leak before. But OK they support developing but at the same time they don't help provide any decent tools for troubleshooting or development.
Android-UK said:
I have seen many a leak before. But OK they support developing but at the same time they don't help provide any decent tools for troubleshooting or development.
Click to expand...
Click to collapse
Why do they need to? There's already great tools around for that, I know Qualcomm certainly used to provide a package for debugging the lower system levels but it wasn't widely available as the lower levels of the device booting process are not needed to be modified outside of OEM labs and manufacturing.
The lowest level we need is kernel debugging and the kernel already provides that via last_kmsg and desmsg etc, all other tools are already available as part of ADB, logcat etc. There are also a plethora of other tools readily available.
I would call it pretty dead now Well, if not dead then dying.
Let's hope for a Christmas special