Related
The SGS2 supports USB OTG which means it can play host to certain low-powered USB devices. Unfortunately the kernel is configured with a whitelist that means it will only connect to HIDs, printers, PTP cameras and mass storage devices.
I wanted to begin developing an application using custom (vendor specific) USB hardware and so started experimenting to see if it was possible. There is a full description of how I went about it on my blog. To summarise, one of the ways to enable vendor specific USB devices is to edit the file "drivers/usb/core/sec_whitelist.h" and add the following to both whitelist tables:
Code:
{ USB_DEVICE_INFO(0xff, 0x0, 0x0) }, /* vendor specific USB devices */
There are two reasons for this post, the first is to provide information to help others that may want to do the same thing. The second is to try and encourage kernel modders to include my changes (or disable the whitelists altogether) thereby providing application developers the means with which to communicate with custom hardware.
Regards,
Dan
Nice idea, I may be completely wrong, but if you remove the white list it, will accept other hardware? or is it dependant on it being there?
Sent from my GT-I9100 using Tapatalk
Does you also test Google ADK ??
Do you know if it would work with the S2 ?
@MacaronyMax: As I mentioned in my blog post, it is possible to disable the whitelist entirely via the kernel options which I assume would allow any device to connect, but I have not tested this and so am unsure.
@xlanhackerx: The ADK relies on accessories that have been designed to act as host and use an Android specific protocol, whereas I am interested in the SGS2 acting as host so that I can connect custom third-party slave devices to it. Therefore I have not looked at the ADK at all and I do not have the hardware available to even play with it.
Regards,
Dan
Thank you. Maybe a custom ROM has it built in?
Thank you so much terranim for this discovery, and for posting it.
I have been struggling on that for a week now, not understanding why my driver was apparently not even called.
I was thinking it could exist a ROM that has this whitelist removed... anyone has a clue? (Lite'ning 6.1 / ninphetamin 2.0.5 or .11 have is using sec_whitelist.h)
I don't think that any kernel developers have disabled this whitelist yet! However there is now another major problem: In the latest ROM from Samsung it is reported that they have removed the USB host related libraries in the Android SDK!
My hack to the kernel will still work and allow devices to be connected, but we will no longer be able to communicate with custom USB devices via an Android application (unless we write a C library to talk to the devices directly or via libusb).
Hopefully developers will restore these libraries in their own custom ROMS.
I guess I am not too far from running this whitelist with your new line on a home compiled version of ninphetamine... see http://forum.xda-developers.com/showpost.php?p=18123923&postcount=2828 and http://forum.xda-developers.com/showpost.php?p=18123923&postcount=2833
I just got to to compile completely a minute ago, and will test it on Thursday.
I think I will stick to custom ROMs / kernel now... and possibly some I compile myself.
Did you read about libftdi? That could help you. Also that Samsung removed USB API might not harm as long as you use a serial port created by the serialusb driver.
edit / ps: nice to work in a team
guys,
is there any chance this USB Host mode could work with a headphones USB DAC/Amp like the FiiO E7?
I really envy the iPod/Pad/Phone users and their ability to have pure sound of their devices while on the go. I know we have HDMI/MHL but sadly there are no headphones amps using this link
I would be interested in this as well.
it is correct that Samsung have removed the USB Host API,
As far as I can tell, they never intended to leave it there to begin with, but I do know that the particular API was introduced in API 11 (Honeycomb).
Sent from my GT-I9100 using Tapatalk
What kernel options are required for this and what is needed to test connectivity? I have an older Galaxy S device and I'm trying to reproduce what you've done here. I just got an ADK for christmas and I've been working with Cyanogenmod kernel source in an attempt to get things operating. From what I can see I need a kernel driver. It would appear that it's begining to recognize that *something* is plugged in, but it's not enumerating.
Anything you can show me would be helpful. What do you see in dmesg when ADK or any other device is connected?
Hi. I know this is an old thread but I want to know if there is some patch to enable USB DACs on the S2. I can not find anything that can enable this like the S3. If some one knows some thing please reply.
Thanks
Alright, now that Adamoutler finally posted (I was waiting on that) I can now explain what we're going to try to do. You all know the unbrickable mod for a few samsung devices? The guy who did that wants to help us out but he needs a nook tablet. Anyway, what it does is completely disable hardware security and allows the flashing of a new bootloader. That's about as simple as I can make it. I would love to see this happen so hopefully, we can make it.
Question is, who's giving up a tablet?
Note:
Code:
This is not a thread to come in and complain saying that you're going to take it back. That's not our problem nor is it our concern. We need a place where we can have organized information about the bootloader and you telling us "I HATE IT, I need to return it!" doesn't help that.
If someone (me) wanted to get involved in this, how would I go about doing so? I know enough about linux, but nothing about Android programming. Is there somewhere I can start learning? I'd like to contribute to this if I am able.
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
hobbit19 said:
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
Click to expand...
Click to collapse
According to information from TI about the M-Shield security features of this chip, the "secure on-chip keys (E-Fuse) are OEM-specific, one-time-programmable keys accessible only from inside the secure environment for authentication and encryption". Protecting against that kind of key replacement is a big part of how this chip was designed. Finding out the private is likely to be the only way to create valid signed images of our own
Here is the source for that quote.
Indirect said:
Botnets are typically used under illegal reasons / methods. Im not talking about [email protected], im talking about stormworm, etc.
Sent by breaking the sound barrier
Click to expand...
Click to collapse
I know what you mean, but what _I_ mean is that botnets CAN be used for other things than illegal hacking and malicious intent. They can replace a supercomputer, as [email protected] proves. I think I have seen a similar initiatives for cancer research and DNA research, though I don't know the names of those projects.
notes
Hopefully this doesn't lead to any red herrings. I haven't been looking at this stuff very long.
"arm.com" has some info on the processor.
TI licensed the processor design from ARM. It's an ASIC, not really a cpu chip.
You have to agree to a non-disclosure to see the docs on arm.com.
After reading about it, not sure that the dual cpu is actually getting used like folks think. There may be two systems actually running.
The arm docs hint that it may be the hash key that actually gets stored on the asic not a private key and that there may be more than one. TI may have designed in their own protocol which is the M-Shield trademark.
TI doesn't exactly give out much info on it. The ARM site is a lot more informative. It doesn't cost anything to access it other than giving away your email address and agreeing to the nondisclosure.
In particular look for these documents:
DDI0406C_arm_architecture_reference_manual.pdf
DEN0013B_cortex_a_series_PG.pdf (chapter 26)
PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
You can also review the source code for the tablet.
See the following exerpts:
distro\x-loader\lib\board.c
image.image = 2;
image.val = 99;
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK , 1 , &image );
if ( image.val == 0 )
{
/* go run U-Boot and never return */
printf("Starting OS Bootloader from %s ...\n", boot_dev_name);
((init_fnc_t *)CFG_LOADADDR)();
}
distro\u-boot\common\cmd_bootm.c
function do_bootm
...
U32 SEC_ENTRY_Std_Ppa_Call (U32 appl_id, U32 inNbArg, ...);
\x-loader\board\omap4430sdp\omap4430sdp.c
...
There are several calls to the SEC_ENTRY_Std_Ppa_Call function.
One (or two) for each image block being loaded.
I think these are the calls to the security layer..
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK ,...
They took the crc32 validation out in various places in the code. I suspect that if it is a signed key that if the image doesn't process out to the end key, then the crc2 would have failed anyway.
Has anyone actually checked what the "key" is? Could it be a crc or checksum?
The "_BN_" I assume is for barnes and noble.
Looking at "omap4_hs.h", it looks like that function can do a callback into the secure area and execute up to 32 different functions, though I'm guessing from the list in the file that BN only added two - INIT and CHK.
There is also a reference in that file to "Development CEK". Could this be the private key? Not the hash, just one part of the key? I'm by no means up on crypto algorithms.
/*
Defines from MShield-DK 1.2.0 api_ppa_ref.h
Make sure these align with the existing services in PPA.
*/
// Number of APIs
#define NB_MAX_API_HAL 32
// command / api keys
PPA_SERV_HAL_CPAUTOLOAD
PPA_SERV_HAL_CPINIT
PPA_SERV_HAL_CPSWRV
PPA_SERV_HAL_CPMSV
PPA_SERV_HAL_CPREPORT
PPA_SERV_HAL_CPCEK
PPA_SERV_HAL_TEST_API
PPA_SERV_HAL_BN_INIT
PPA_SERV_HAL_BN_CHK
/* Development CEK */
#define CEK_3 0x01234567 //127_96
#define CEK_2 0x89ABCDEF // 95_64
#define CEK_1 0x11121314 // 63_32
#define CEK_0 0x15161718 // 31_0
Another question I have, what level of GPL does android use?
The simple fact that they linked in the M-Shield function calls may be enough to force the release of that source as well. The latest GPL has a pretty nasty copy left. It may be in that archive already too. I haven't gotten through much of it yet.
And is it true that this tablet has a different wifi chip and thus doesn't have the fm and bluetooth available to it?
The brute force idea might work except that you'd have to do it on a nook tablet. You have to validate a data block using that function call.
Figuring out how to automate it through that security layer might be a bit troublesome. If you could call that function directly, maybe, but I suspect that it is only accessible from one side of the architecture. But that might also be why the tablet has so much memory dedicated to B&N and not split evenly. Maybe the bigger chunk of the memory is all in the secure side?
I have to say the OMAP4 is a pretty neat layout. Has a huge potential for corporate ethical abuse but technically it really is cool. They are going through a lot of hoops to keep this tablet locked down. I found one whitepaper on the netflix issue. Netflix apparently has a whole massive requirements list and this was the first tablet to meet it. I'm not sure netflix isn't overvaluing their product. There are other ways they could have done this versus locking the whole tablet down. They could have put the netflix app as a service in the secure side and just signed that part of the application. They could have still allowed the secondary bootloader in the unsecure area to be whatever the user wanted. I don't think they thought through the ethical notions of it all. But maybe they did and they just want to control something like apple is doing. Apple was defeated once by a lower cost, open architecture. History will repeat itself. It's a shame B&N's didn't go that route instead. If it wasn't for this one issue, they would have had a much better platform to work from than the fire.
Asking others for the info / ideas on bootloader isn't related to development. Hence moved to general
cheers,
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Adam, I can try and get you a nook tablet.
Also, I was waiting for you to post that. I wanted to leave this up to the community to see what could be thought of. Surprised hardware modification never came up. :|
AdamOutler said:
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I figured youd be here when the final specs on the Nexus Prime were released, and they used the OMAP4460 which is ironically very simmalir to the OMAP4430.
Thanks for your help and let us know if theres anything we can help you with.
Just for your all's information, Adam will have one in a day or two it has already been shipped.
AdamOutler said:
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
The fast external boot is a special memory booting mode, possible only on GP devices. It consists of a blind jump to a code in an external XIP memory device connected to GPMC CS0. Fast external booting is set up by means of the SYSBOOT configuration pins and lets customers create their own booting code.
Click to expand...
Click to collapse
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Hardware mod
JoeM01 said:
Can this in fact be replicated by someone who is NOT necessarily a dev, but isn't afraid of cracking open a device and going to work with a soldering iron?
Click to expand...
Click to collapse
It depends ...
Assuming for the purpose of discussion that all you need to do is (un)ground an external pin, the difficulty can range from:
Getting access to a ball-grid-array device on a multi-layer board (effectively impossible).
Lifting a pin on a surface-mount chip (easy with the right tools and some skill).
Cutting a trace or soldering a jumper (easy with the right tools and some skill).
(Un)grounding at a solder pad pair (easy).
While the last is not likely, it happens. A case in point:
When IBM released a parallel port board for the original IBM PC, they also released the schematic in the technical reference manual for the PC. The schematic showed that the data buffer buffer chip was bidirectional (74LS374), but its ^OE (output-enable) pin was grounded (active-low logic), in effect making the parallel port output-only.
When the clone-makers replicated the parallel port from the IBM schematic, they all replaced the 74LS374 chip with one that was not bidirectional (a 74LS274, as I recall), saving a tiny bit of money.
However, you you actually had one of IBM's parallel port cards, you noticed that the ground trace on the 74LS374 was not grounded next to the chip (as would normally be expected), but ran a couple inches across the board to a "via", and then grounded in a short trace run. That "via" was exactly 0.1" away from another "via" that was connected to an "unused" bit on the control chip. In other words, a simple trace cut of the final ground run, followed by the installation of standard 0.1' spacing header pins (or a simple jumper) at the "via"s, would convert the parallel port to be bidirectional. Which I did at the time.
Several years later, when IBM modified their BIOS to support bidirectional parallel port operation, they introduced a new parallel port card. The above modification to the old ones worked, but all the clone parallel cards were obsolete.
So, I would not put it outside the realm of possibility that B&N provided a solder pad to be able to disable the signed bootloader feature.
I would also not put it outside the realm of possibility that instead, the hardware modification is very, very difficult, even with the right tools.
Then there is the software issue still to be fixed. Certainly worthy of investigation, but don't get your hopes too high (especially before Christmas).
The best way to think of this hardware unlock, is that the nook is like a building, there are lots of rooms we can get into, but there are also rooms that we cannot. What I assume is adam will get into those rooms, and there might be ways to turn off the power to certain rooms, and or put something in the water. This might allow us to make a software mod that will effect the rooms .
rooms .
pokey9000 said:
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Click to expand...
Click to collapse
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Doing the memory dump now.
Got this error on the first one:
[INFO] Reading 49152 bytes at 0x40030000...
[1] Bus error viewmem 0x40030000 0xC000 >/sdcard/40030000Dump
Only the 2nd one dumped properly.
http://dl.dropbox.com/u/15069134/40028000Dump.zip
AdamOutler said:
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Click to expand...
Click to collapse
Adam,
If no one has done this by the time i get home, I will do it for you. I will be on IRC tonight for some of the night and will be able to do whatever you need.
I just did it loglud, no worries.
I'm seeing the following strings in the boot dumps:
Code:
pGpGpGpG
@ABCDEGKJ
CHMMCSD
CHFLASH
CHRAM
PRIMAPP
X-LOADER
CHSETTINGS
KEYS
ISSW
It's not much to go on, but I'd expect to see something on UART from this.
Both of the files are the same. 49.2kB. http://dl.dropbox.com/u/15069134/40028000Dump.zip
however, those are just the complete strings... there's more..
Code:
Texas Instruments
Nokia
Motorola
OMAP4430
NOKIA USB ROM
BLANK
OMAP4430 N/A
N/A
PCB
PCI
R&D
2nd
CH
HLO
MLO
ULO
This NOKIA USB ROM looks interesting.
That's so strange i wonder what it is pointing to because from what i see there's no a single Nokia part in the entire device. You think its just the rom driver they use to flash the OMAP's Rom?
Hi all, I am new to the forums and I think that I need some help with a custom android project.
[Background]
I have bought a Meraki MC74, This phone is a VOIP office desk phone that has a nice 7 inch LCD screen that make for a ballin' custom intercom phone/general android device.
Cisco Meraki has dropped support for this phone, so even if I wanted to pay for a subscription, I couldn't. So custom android it is
[So what I know]
I know that the OEM OS is android 4.X.X with a custom Cisco Meraki dialer to do Meraki's cloud mumbojumbo. I was able to use ADB and Fastboot to flash ClockworkMod, and a custom version of Android 4.1.2 to get the device somewhat working. (it had lots of bugs and problems; but it was running android free of the Cisco Dialer!)
I was able to do this with the help of fellow xdadevelopers forum user "andrewmospak" (If you're reading this; I'm the dude from Ebay. And of course, thanks bro for the help so far!)
The storage is on a 4 GB Kingston EMMC.
[What I wanted for an end goal]
I wanted to have an interesting discontinued Meraki Desk phone that runs android and get all the functions of the phone working within android.
I also wanted to expand the storage from 4GB to 32GB. ( involving de-soldering existing EMMC and solder in the bigger EMMC.)
[What caused me to write this]
I would be fine if I wanted to stop there, but I wanted to try to install a GSI of android 9 in place of 4.1.2.
Again, this wouldn't be a big deal but I had to go and screw this up. I tried to resize some of the partitions (namely system to accommodate the bigger image of the android 9 GSI)but I accidentally completely killed the system,cache, and recovery partitions.
So, as one of the first steps of trouble shooting, I went to the hardest solution. The de-soldering of the EMMC.
I reached out to Andrewmospak again and asked for a full system emmc dump to try to flash his working file system to a spare 4GB EMMC to see an example of the file system of a working android EMMC. I received the image and flashed it to a spare Toshiba chip and soldered that to the phone, but I was unable to get the phone to boot into android right away, only able to load up fastboot.
Interestingly, I know that the EMMC is working because fastboot reports the S/N as the S/N of Andrewmospak's device and not the one written on my device.
[What I don't know]
Should some of the partitions on the EMMC not be recognized by Gparted in Debian? Like the User/System and others are partitioned ext4 while others are just not recognized.
Why when trying to flash partitions using Fastboot, wont fastboot recognise a recovery partition. It would just say that the partition just doesn't exist. same story with boot.
[What needs help]
I would like to know why fastboot wont see flashable volumes when using the EMMC dump flashed to another spare Toshiba EMMC, it is clearly there.
I would like to know how to reconstruct a volume to fix missing ones, and the number of partitions android needs to run.
Would I be able to flash an image of my working device to a 32gb emmc and just expand the system and user partitions into that extra space?
I will appreciate all help given to assist me and others that want a working device instead of a paperweight. ogChamp: :fingers-crossed:
That is an awesome project, and a great idea for an office line. I'll look into this!
Use MC74 for dashboard
I'm really interest to know, if you can have run a web browser on the MC74.
My needs are not fancy, I want to run a web browser on the touch screen, and have network connection with the ethernet jack in the back. I want to use it to interact with a touch dashboard for my home automation trough the webbrowser.
Thank you
Is it possible you didnt get the hidden boot partition in the emmc device? I know it isn't accessible through a sd card reader but can be seen through a SDIO controller interface.
page 15 of this document discusses this:
Google this: "us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader-wp.pdf" first link on blackhat.com
This project interests me as these devices are dirt cheap and i could use a few multipurpose desk phones
Thank you for starting this work. I have been waiting for this day since past couple of years now.
When you get a chance, could you please post the steps up to the point where you decided to swap the emmc?
sasha0413 said:
Hi all, I am new to the forums and I think that I need some help with a custom android project.
[Background]
I have bought a Meraki MC74, This phone is a VOIP office desk phone that has a nice 7 inch LCD screen that make for a ballin' custom intercom phone/general android device.
Cisco Meraki has dropped support for this phone, so even if I wanted to pay for a subscription, I couldn't. So custom android it is
[So what I know]
I know that the OEM OS is android 4.X.X with a custom Cisco Meraki dialer to do Meraki's cloud mumbojumbo. I was able to use ADB and Fastboot to flash ClockworkMod, and a custom version of Android 4.1.2 to get the device somewhat working. (it had lots of bugs and problems; but it was running android free of the Cisco Dialer!)
I was able to do this with the help of fellow xdadevelopers forum user "andrewmospak" (If you're reading this; I'm the dude from Ebay. And of course, thanks bro for the help so far!)
The storage is on a 4 GB Kingston EMMC.
[What I wanted for an end goal]
I wanted to have an interesting discontinued Meraki Desk phone that runs android and get all the functions of the phone working within android.
I also wanted to expand the storage from 4GB to 32GB. ( involving de-soldering existing EMMC and solder in the bigger EMMC.)
[What caused me to write this]
I would be fine if I wanted to stop there, but I wanted to try to install a GSI of android 9 in place of 4.1.2.
Again, this wouldn't be a big deal but I had to go and screw this up. I tried to resize some of the partitions (namely system to accommodate the bigger image of the android 9 GSI)but I accidentally completely killed the system,cache, and recovery partitions.
So, as one of the first steps of trouble shooting, I went to the hardest solution. The de-soldering of the EMMC.
I reached out to Andrewmospak again and asked for a full system emmc dump to try to flash his working file system to a spare 4GB EMMC to see an example of the file system of a working android EMMC. I received the image and flashed it to a spare Toshiba chip and soldered that to the phone, but I was unable to get the phone to boot into android right away, only able to load up fastboot.
Interestingly, I know that the EMMC is working because fastboot reports the S/N as the S/N of Andrewmospak's device and not the one written on my device.
[What I don't know]
Should some of the partitions on the EMMC not be recognized by Gparted in Debian? Like the User/System and others are partitioned ext4 while others are just not recognized.
Why when trying to flash partitions using Fastboot, wont fastboot recognise a recovery partition. It would just say that the partition just doesn't exist. same story with boot.
[What needs help]
I would like to know why fastboot wont see flashable volumes when using the EMMC dump flashed to another spare Toshiba EMMC, it is clearly there.
I would like to know how to reconstruct a volume to fix missing ones, and the number of partitions android needs to run.
Would I be able to flash an image of my working device to a 32gb emmc and just expand the system and user partitions into that extra space?
I will appreciate all help given to assist me and others that want a working device instead of a paperweight. ogChamp: :fingers-crossed:
Click to expand...
Click to collapse
Can't get to recovery mode -- wanna help
I'd like to help and write and app that is a (open) SIP client for the MC74. I bought an apparently new MC74 but I can't get it into recovery mode. Any help in doing this (so I can install a rooted Android)?
Holding down VolUp while connecting the POE ethernet to the WAN port doesn't work. The display remains blank then every several seconds the dislpay backlight flashes for a moment. Holding down Mute and connecting power has no effect, just boot normally to the Meraki logo screens then a minute later the normal keypad and menu display. (VolDn and powerup boots normally). I've tried this with USB flash drive (with some random recovery.img file on it) in the side USB port -- then I get an icon of a broken Android robot (presumably meaning it tried something with booting off the USB.
Has my MC74 been locked down somehow? What can I do to get a rooted Android on it?
ribo said:
I'd like to help and write and app that is a (open) SIP client for the MC74. I bought an apparently new MC74 but I can't get it into recovery mode. Any help in doing this (so I can install a rooted Android)?
Holding down VolUp while connecting the POE ethernet to the WAN port doesn't work. The display remains blank then every several seconds the dislpay backlight flashes for a moment. Holding down Mute and connecting power has no effect, just boot normally to the Meraki logo screens then a minute later the normal keypad and menu display. (VolDn and powerup boots normally). I've tried this with USB flash drive (with some random recovery.img file on it) in the side USB port -- then I get an icon of a broken Android robot (presumably meaning it tried something with booting off the USB.
Has my MC74 been locked down somehow? What can I do to get a rooted Android on it?
Click to expand...
Click to collapse
The way That I was able to boot into recovery was to hold mute and volume down NOT IMMEDIATELY hold the two only after the LCD backlight turns on. Only then you will be in recovery.
realc3blues said:
Is it possible you didnt get the hidden boot partition in the emmc device? I know it isn't accessible through a sd card reader but can be seen through a SDIO controller interface.
page 15 of this document discusses this:
Google this: "us-17-Etemadieh-Hacking-Hardware-With-A-$10-SD-Card-Reader-wp.pdf" first link on blackhat.com
This project interests me as these devices are dirt cheap and i could use a few multipurpose desk phones
Click to expand...
Click to collapse
My linux machine recognizes the mystery partitions but not their contents or partition scheme with some cheap USB to SD adapters. I think it works well. Thanks for the recommendation though!
ribo said:
I'd like to help and write and app that is a (open) SIP client for the MC74. I bought an apparently new MC74 but I can't get it into recovery mode. Any help in doing this (so I can install a rooted Android)?
Holding down VolUp while connecting the POE ethernet to the WAN port doesn't work. The display remains blank then every several seconds the dislpay backlight flashes for a moment. Holding down Mute and connecting power has no effect, just boot normally to the Meraki logo screens then a minute later the normal keypad and menu display. (VolDn and powerup boots normally). I've tried this with USB flash drive (with some random recovery.img file on it) in the side USB port -- then I get an icon of a broken Android robot (presumably meaning it tried something with booting off the USB.
Has my MC74 been locked down somehow? What can I do to get a rooted Android on it?
Click to expand...
Click to collapse
You need to hold down the VOLUME DOWN button before powering on the unit, and then continue to hold it. The phone will go into Fastboot mode. The screen will be blank, but backlit, and usually the LED lights up red. Here, you can flash a custom recovery firmware image (such as the ClockworkMod one that's floating around) that allows you to make changes to the system and user partitions. The thing you're seeing with the Android robot is expected. That's the default recovery firmware. Once you flash custom recovery firmware in Fastboot mode, you then unplug the unit, hold down the MUTE button, plug the device in, and continue to hold the MUTE button. It may take some time for it to get into the recovery firmware, but be patient. FYI, VOLUME UP is used for that feature where you can switch between two "slots" for firmware. I don't really know what that is, but I know that it's a thing with Android. It's pretty much unused on the MC as far as I can tell.
Has anyone considered working backwards with the version of Android running on the MC, rather than installing an entirely new version? So, instead of trying to get new firmware to work on the unit, why not work with whatever's on the device by default and pull out what you don't need? I know that some people have gotten different versions of Android to work on the unit, but this leads to bugs or hiccups. I'd imagine that this is because the kernel for that firmware isn't specifically made for the MC, but don't take my word for it. That's just a guess.
Due to the current pandemic situation that's going on here, I've decided to occupy my time by examining the MC in depth. I've managed to get ADB shell working when the device has booted normally, allowing me to examine the filesystem and pull out whatever Meraki included with the firmware. Even got the rainbow LED to stop obnoxiously glowing! I'm currently working on getting the system UI to work (there's no status bar or app switcher).
Got adbd running on MC74, Sort of got Linphone going
@sasha0413 and @jazzcandle, I got the boot.img updated so I could set 'ro.secure=0' in /default.prop in the boot up ramdisk. So now I can 'adb' into it by TCP or USB. Thanks for the help. (My MC74 calls itself a 'test-phone' so it may be a little different software. The problem was that the 'recovery' mode installed on it was pretty subtle, nothing showed on the screen.
My MC74 runs '4.2.5-meraki' version of JellyBean api 17, because I'm not good at porting newer versions of Android -- and because there may be modifications / drivers that Meraki put in to support the hardware, I'm working on a phone app with the original JellyBean.
I managed to get an old version of 'linphone' working to the extent that I can make a call -- and can be heard -- but I haven't mastered the speakers (Android AudioManager/MediaPlayer, etc) so I can't hear the phone call. I can play audio speakerphone speaker, but can't play it on the handset speaker. Figuring out the Android Audio system for JellyBean is hard, the implementation has change a lot since then.
---------- Post added at 14:11 ---------- Previous post was at 14:04 ----------
[/COLOR @jazzcandle I installed com.teslacoilsw.launcher-4.1.0-41000-minAPI16.apk as a launcher and told use it as the launcher rather than /data/app/com.meraki.dialer2-1.apk
How did you stop the RGB LED from cycling through the colors? Does something like: /system/app/DroidNode.apk or /system/app/DroidNodeSystemSvcs.apk start the led cycling, then perahps com.meraki.dialer2 stop it -- when it initializes?
ribo said:
My MC74 calls itself a 'test-phone' so it may be a little different software. The problem was that the 'recovery' mode installed on it was pretty subtle, nothing showed on the screen.
Click to expand...
Click to collapse
This is something that stumped me early on as well. But have no fear, all MCs run the same firmware, and you're not running different "test" firmware. The "test phone" value you're referring to is only seen in the recovery partition in the "default.prop" file, where "ro.product.model" is set to "BCM28155_TEST_PHONE". When booting normally, this value is set to "Meraki MC74" instead.
ribo said:
I managed to get an old version of 'linphone' working to the extent that I can make a call -- and can be heard -- but I haven't mastered the speakers (Android AudioManager/MediaPlayer, etc) so I can't hear the phone call. I can play audio speakerphone speaker, but can't play it on the handset speaker. Figuring out the Android Audio system for JellyBean is hard, the implementation has change a lot since then.
Click to expand...
Click to collapse
The way audio output works on the MC is a bit strange. In fact, it's not really Android's fault from what I can tell. However, I found that you have to "poke" the audio HAL to get it functioning somewhat normally (ie. getting audio to actually play through the speakers). You can do this by running the following command in the shell:
$ tinymix 1 1
At this point, you should be able to hear audio output through the speakers. Additionally, you should be able to switch between handset and speakerphone mode (so long as the app you're using allows you to do this).
ribo said:
I installed com.teslacoilsw.launcher-4.1.0-41000-minAPI16.apk as a launcher and told use it as the launcher rather than /data/app/com.meraki.dialer2-1.apk
Click to expand...
Click to collapse
You should delete the Dialer apk, you don't need it. In fact, you should delete the DroidNode.apk and DroidNodeSystemSvcs.apk files as well.
ribo said:
How did you stop the RGB LED from cycling through the colors? Does something like: /system/app/DroidNode.apk or /system/app/DroidNodeSystemSvcs.apk start the led cycling, then perahps com.meraki.dialer2 stop it -- when it initializes?
Click to expand...
Click to collapse
You need to modify "init.bcm911130_me1.rc" within "boot.img" and either remove or comment out the following:
Code:
service lightsd /system/bin/lightsd
class main
socket lightsd stream 600 system system
user root
Controlling RGB LED on MC74
Thanks jazzcandle, I'll look into /system/bin/lightsd to see what it does.
lightsd seems to open ANDROID_SOCKET_lightsd and listen to /dev/socket/lightsd
It seems to directly write to these /sys files to change the LEDs through which must be controlled through the SOC's GPIO pins..
/sys/class/leds/red/brightness
/sys/class/leds/green/brightness
/sys/class/leds/blue/brightness
/sys/class/leds/white/delay_off
/sys/class/leds/white/brightness
/sys/class/gpio/export
/sys/class/gpio/gpio11/directionout
/sys/class/gpio/gpio11/value
am broadcast -a com.meraki.LIGHTSD_START
I would be great to know what all the GPIO devices did and their a addresses.
I've left the Dialer2, DroidNode and DroidNodeSystemSvcs apps running at this point to see what they do and how they are used. I agree that eventually they need to be removed because they connect to cisco/meraki web services when they start up.
I noticed that the com.meraki.dialer2.LEDController class is how the dialer controls the LEDs:
public void notifyLeds(LedMode mode, int red, int green, int blue) {
this.r = red;
this.g = green;
this.b = blue;
this.m = mode;
sendLightCommand();
}
class LightCmd implements Consumer {
public void accept(Object o) {
Intent i = (Intent)o;
i.putExtra("red", r);
i.putExtra("green", g);
i.putExtra("blue", b);
Log.i(TAG, String.format("Broadcasting color change to rgb(%d, %d, %d)",
new Object[]{r, Integer.valueOf(g), Integer.valueOf(b)}));
ctx.sendBroadcast(i);
}
}
private void sendLightCommand() {
Consumer cons = new LightCmd();
getIntent().ifPresent(cons);
}
Click to expand...
Click to collapse
Methods ilke 'notifyLeds' takes a mode (Solid, Pulse, or Rainbow) and the R, G, B values and uses the sendLightCommand() method which broadcasts an intent that will probably be handled by something like the /system/bin/lightsd daemon. (I'm trying to document all these things for customizing/developing a SIP app.
I notice that the MC74 app is built on the PJSIP ( org.pjsip.pjua2 package) I was thinking of use the org.linphone SIP package. Anyone have experience with these SIP packages?
ribo said:
(I'm trying to document all these things for customizing/developing a SIP app.
I notice that the MC74 app is built on the PJSIP ( org.pjsip.pjua2 package) I was thinking of use the org.linphone SIP package. Anyone have experience with these SIP packages?
Click to expand...
Click to collapse
Thanks for documenting this, this is awesome info. A while back I built a rudimentary SIP client for MC74 based on the AJVoIP SIP package. I gave up on it once my trial period for that package expired. It was quirky, with flaky audio and no LED control (which both now could be solved by the info in this thread), but I did have hookswitch (hangup/answer by picking up the handset) working.
In the spirit of documentation, the hookswitch is an ambient light sensor that gets covered or uncovered by the handset's earpiece. The original Dialer2 app reads the raw value and compares it to a calibrated set point to determine on/off hook state. Reading the path
Code:
/sys/devices/virtual/input/input0/event0/device/raw_adc
with a FileReader will get you the current value. For my device, off hook (answered) is a value below 110. On hook (hung up) is a value above 110. For my testing I just polled this file every 250ms but you could attach a FileObserver to it or something.
jazzcandle said:
Has anyone considered working backwards with the version of Android running on the MC, rather than installing an entirely new version? So, instead of trying to get new firmware to work on the unit, why not work with whatever's on the device by default and pull out what you don't need?
Click to expand...
Click to collapse
This is actually what I am working on with a unit that I got.
The phone I have (from the build.prop file):
Code:
ro.build.version.release=4.2.3-phone-5068355-southern-userdebug
ro.product.model=Meraki MC 74
ro.product.brand=Meraki
ro.product.name=capri_me1
ro.product.device=capri_me1
ro.product.board=capri
Currently trying to work on getting ADB working from within the phone and not just within the Clockwork recovery that I got loaded on it.
Getting a pretty close stock experience on the MC74 is totally possible with some dedication and work. For reasons I cant get into, I am unable to provide the steps / files that it took to get where I am, but I have a functional MC74 with working handset & speakerphone. The only next thing I need to work on is getting the "IR" sensor to hangup in specific Dialer applications.
https://imgur.com/a/FFVq1sL
I am using Grandstream Softphone dialer.
drraccoon said:
Getting a pretty close stock experience on the MC74 is totally possible with some dedication and work. For reasons I cant get into, I am unable to provide the steps / files that it took to get where I am, but I have a functional MC74 with working handset & speakerphone. The only next thing I need to work on is getting the "IR" sensor to hangup in specific Dialer applications.
Click to expand...
Click to collapse
I was able to achieve the same, except GS dialer is not scaled correctly.
Not able to post link to image, as I don't have 10 messages.
So it is a/6aQYsz6 on imgur
Did not bother to fix it, as my intent is custom PJSIP dialer (someday
Headset sensor, led, mixer - figured out.
The only mystery is "mute" button and the red LED behind it.
sasha0413 said:
Hi all, I am new to the forums and I think that I need some help with a custom android project.
[Background]
I have bought a Meraki MC74, This phone is a VOIP office desk phone that has a nice 7 inch LCD screen that make for a ballin' custom intercom phone/general android device.
Cisco Meraki has dropped support for this phone, so even if I wanted to pay for a subscription, I couldn't. So custom android it is
[So what I know]
I know that the OEM OS is android 4.X.X with a custom Cisco Meraki dialer to do Meraki's cloud mumbojumbo. I was able to use ADB and Fastboot to flash ClockworkMod, and a custom version of Android 4.1.2 to get the device somewhat working. (it had lots of bugs and problems; but it was running android free of the Cisco Dialer!)
I was able to do this with the help of fellow xdadevelopers forum user "andrewmospak" (If you're reading this; I'm the dude from Ebay. And of course, thanks bro for the help so far!)
The storage is on a 4 GB Kingston EMMC.
[What I wanted for an end goal]
I wanted to have an interesting discontinued Meraki Desk phone that runs android and get all the functions of the phone working within android.
I also wanted to expand the storage from 4GB to 32GB. ( involving de-soldering existing EMMC and solder in the bigger EMMC.)
[What caused me to write this]
I would be fine if I wanted to stop there, but I wanted to try to install a GSI of android 9 in place of 4.1.2.
Again, this wouldn't be a big deal but I had to go and screw this up. I tried to resize some of the partitions (namely system to accommodate the bigger image of the android 9 GSI)but I accidentally completely killed the system,cache, and recovery partitions.
So, as one of the first steps of trouble shooting, I went to the hardest solution. The de-soldering of the EMMC.
I reached out to Andrewmospak again and asked for a full system emmc dump to try to flash his working file system to a spare 4GB EMMC to see an example of the file system of a working android EMMC. I received the image and flashed it to a spare Toshiba chip and soldered that to the phone, but I was unable to get the phone to boot into android right away, only able to load up fastboot.
Interestingly, I know that the EMMC is working because fastboot reports the S/N as the S/N of Andrewmospak's device and not the one written on my device.
[What I don't know]
Should some of the partitions on the EMMC not be recognized by Gparted in Debian? Like the User/System and others are partitioned ext4 while others are just not recognized.
Why when trying to flash partitions using Fastboot, wont fastboot recognise a recovery partition. It would just say that the partition just doesn't exist. same story with boot.
[What needs help]
I would like to know why fastboot wont see flashable volumes when using the EMMC dump flashed to another spare Toshiba EMMC, it is clearly there.
I would like to know how to reconstruct a volume to fix missing ones, and the number of partitions android needs to run.
Would I be able to flash an image of my working device to a 32gb emmc and just expand the system and user partitions into that extra space?
I will appreciate all help given to assist me and others that want a working device instead of a paperweight. ogChamp: :fingers-crossed:
Click to expand...
Click to collapse
Hey, I am interested but I don't have the device.
First of all:
I would be fine if I wanted to stop there, but I wanted to try to install a GSI of android 9 in place of 4.1.2.
Click to expand...
Click to collapse
You can install a GSI on a 4.1.2 based device, but you can't without creating a vendor partition, GSI is a part of the Project Treble released with Oreo. It requires a vendor partition to work. On 4.1.2, there's simply no device with a partition called vendor, so you can't flash a GSI.
But, if you have a fully working Android Pie tree, you can make a vendor partition yourself.
alex39wkd said:
I was able to achieve the same, except GS dialer is not scaled correctly.
Not able to post link to image, as I don't have 10 messages.
So it is a/6aQYsz6 on imgur
Did not bother to fix it, as my intent is custom PJSIP dialer (someday
Headset sensor, led, mixer - figured out.
The only mystery is "mute" button and the red LED behind it.
Click to expand...
Click to collapse
As you didn't mention that you couldn't share any information like the reply previous to yours, would it be possible for you to share what you used to get there?
As someone with only linux, networking and voip knowledge and that never played around with Android ROMs/ADB before, that would get me started as I can ATM only get to ADB.
Also, did you use the version of android already on the Phone or Flashed it with a new ROM?
Thank you!
jtthecanadian said:
As you didn't mention that you couldn't share any information like the reply previous to yours, would it be possible for you to share what you used to get there?
As someone with only linux, networking and voip knowledge and that never played around with Android ROMs/ADB before, that would get me started as I can ATM only get to ADB.
Also, did you use the version of android already on the Phone or Flashed it with a new ROM?
Thank you!
Click to expand...
Click to collapse
I have used "adb pull" (in recovery mode) to dump boot partition, just used path to it in /dev/...
Used android tools to decompress and unpack boot.
Changed ro.secure to 0 and something like "meraki usb debug" to 1
Repacked boot partition
Used adb to switch to fastboot
Flashed boot and boot2 with this image
Now it is accessable as normal Android phone, for whatever you might want to do with it.
Is anyone able to provide a working ROM for this device? I'm extremely confused about how to get this working. I would greatly appreciate any advice.
.
Hi forum!
So I own a Project Tango Development Kit Tablet (device name: Yellowstone) which appears to be a Tango-purposed Nvidia Shield K1 tablet. There's just a few threads about the yellowstone in the Shield forum and it's an old device now, that's why I'm posting the question here, in the hopes that the question is not device-related but something more general.
So, I wanted to use this tablet and the stock ROM just made it bootloop ad infinitum. Nothing I did could make it boot. So I went to the Shield forum and I found a TWRP image that would work on it. I rooted it, installed TWRP and I installed a ROM that I found around an old thread. So far so good, the tablet now boots but the audio, microphone and camera doesn't work. I want to use it as an intercom system so, that's the stuff I really want it to be in a working state.
By chance I found a LineageOS 16 ROM for the yellowstone (https://updater.oddsolutions.us/yellowstone) but it's description says "PSCI Repartition ONLY". The author hasn't replied to me to what it means. Googling doesn't give useful results regrettably. So I wonder if anyone around this parts could enlighten me about what is it, and how can it be performed?
Many thanks!
REPARTITION ONLY:
I guess it means that /system and /vendor partitions must get re-partitioned ( increasing their sizes ) what must be done before flashing the ROM.
This usually is done by a "Repartition Pack".
PSCI:
The Power State Coordination Interface (PSCI) is an ARM standard introduced for its new ARMv8 64bit architecture to virtualize CPU power management across exception levels i.e. between software working at different privilege levels: OS kernel, hypervisor and Secure Platform Firmware (SPF).
jwoegerbauer said:
REPARTITION ONLY:
I guess it means that /system and /vendor partitions must get re-partitioned ( increasing their sizes ) what must be done before flashing the ROM.
This usually is done by a "Repartition Pack".
PSCI:
The Power State Coordination Interface (PSCI) is an ARM standard introduced for its new ARMv8 64bit architecture to virtualize CPU power management across exception levels i.e. between software working at different privilege levels: OS kernel, hypervisor and Secure Platform Firmware (SPF).
Click to expand...
Click to collapse
Ahaaa, that's excellent information. I guess they're separated concepts then, not directly related. I'll have to contact the owner then for the repartition pack. Many thanks!
Darius_bd said:
Ahaaa, that's excellent information. I guess they're separated concepts then, not directly related. I'll have to contact the owner then for the repartition pack. Many thanks!
Click to expand...
Click to collapse
Did you ever get a response from npjohnson? I've been folliwing his roms for tango for about a year (if not longer) he did say he was aiming to bring it as an official lineage build......but while i see it's been in development. Nothings been released.
So i am interested to know if you got a response.
Darius_bd said:
Ahaaa, that's excellent information. I guess they're separated concepts then, not directly related. I'll have to contact the owner then for the repartition pack. Many thanks!
Click to expand...
Click to collapse
I also am interested in whether or not you found the PSCI for Android 9. I have a Tango I am wanting to put to use.
I bought a MECOOL KM9 android box from the flea market. The Android on it was something custom from some IPTV service provider. On the bottom it says KM9 so I downloaded firmware from here. Using Aml_Burn_Tool the flashing got stuck at 30%, left it for about two hours didn't budge. After this the computer does not recognize the device (no plug-in sound, tested on two computers) and there is no output on HDMI.
So, I got to method two, which is the SD card burned with Burn Card Maker (multiple versions). Tested several firmware, several SD cards, no luck.
Opened up the device to get the serial output, you can find the output attached. Taking a closer look at the board I saw that is marked as: KM1 X2 DDR3 v1.4. The pcb doesn't look like the KM1's pcb and the SoC is different too. My board has Amlogic S905X2, the KM1 has Amlogic S905X3. Also, the pcb doesn't look like the KM9 board either.
The output log is the same regardless having an SD card or pressing de recovery button. It stops with "sdio read data fail". I don't think the EMMC is broken, earlier in the log it says "Load FIP HDR from eMMC" and there is no error. Also, if I have a bootable SD, shouldn't the EMMC be skipped?
As a last resort I tried shorting pins on the NAND chip, the computer still wouldn't detect it however if i short pins the serial output changes, again file attached.
Any ideas? Can I bring it back to life? At least does anyone have this board and firmware for it?
Thank you,
Alex
fyrewurx said:
I bought a MECOOL KM9 android box from the flea market. The Android on it was something custom from some IPTV service provider.
Click to expand...
Click to collapse
In which country? Do you have the provider information? That information might help identify or locate the original build of the firmware.
fyrewurx said:
Opened up the device to get the serial output, you can find the output attached. Taking a closer look at the board I saw that is marked as: KM1 X2 DDR3 v1.4.
Click to expand...
Click to collapse
It's too late now, but it would have been best to connect the uart and dump the original firmware before flashing anything. I understand that the label on the cover is wrong and that it does not match the board, but if you had a backup you could start over. Now, the drm keys (if any) are probably gone and the wrong dtb seems to have been flashed. Maybe it still can be fixed since the bootloader does still boot somewhat, but that may not be the original bootloader but rather the one that was flashed before the flashing failed.
fyrewurx said:
Also, if I have a bootable SD, shouldn't the EMMC be skipped?
Click to expand...
Click to collapse
There are different types of SD booting. For the lowest level booting, the emmc is skipped only if no bootable bootloader is found on the emmc.
It also will be skipped if the emmc clk resistor is removed. 4R1 may be the emmc clk resistor. Check if it is zero ohms. If it is not zero ohms, check the other side of the board.
Once the device is always booting from the SD card, try various videostrong (not skyworth!) firmware for S905X2 devices, like the KM3 and others (such as the KM9 Pro, which uses the X2). I don't see any information for this KM1 X2 device. It may be a custom variant for OTT providers.
Thank you very much for taking the time to answer.
All I can remember is that it was something Polish. You are right, having the original firmware would have been great. I usually check how much info there is on the internet (mainly xda) about the device I want to flash. If there is a lot, I don't bother with backup. Miiiistake. I didn't knew about the clk resistor and I assume others either because people don't mention on the internet. They recommend shorting the pins which is not a great idea in my mind. I did it with a random 330 ohm resistor to be on the safer side. I will definitely try to get the box to boot from SD and then try firmware from KM1 to KM whatever they got up to with the X2.
From your experience are these devices picky about the SD card? It would be easier if I test only with one card.
The DRM keys you mentioned, would stop the device from booting or the box just wont play Netflix and other streaming services? Even without Netflix I would like to get the box going.
I will have to lookup what a DTB file is, I have no idea. The board looks to be custom as there is one other picture I found about the device here.
Just for my knowledge, the bootloader for these devices is also in the main EMMC? I am used to x86 where you have an external memory to keep first stages of bootloader.
I attached closeups on the EMMC and the back, maybe we need them further on.
Thanks again for the reply,
Alex
fyrewurx said:
The board looks to be custom as there is one other picture I found about the device here.
Click to expand...
Click to collapse
Based on those photos, there is a chance that your board is (or is compatible with the firmware from) the KM9 PRO or the KM9 PRO DELUXE.
If this is the case, the state that your device is in now is probably a result of trying to flash an android 9 firmware image to a device that had an existing installation of android 10. If so, there is a decent chance that you can fix it.
You may be able to get a uart shell prompt by experimenting with shorting the emmc clk at various times, so that the attempt to load the invalid dtb (from the flashed firmware) fails. If you can get a uart shell prompt, you can start burn mode (uart shell command "update"), and then use command line tools to flash the km9 pro or km9 pro deluxe firmware.
Otherwise, remove the emmc clk resistor (once it is located), and raw copy the bootloader (from km9 pro or km9 pro deluxed) to the sd card. It isn't necessary to put the resistor back when you are done, a jumper wire can be used since it is zero ohms.
Functioner said:
Based on those photos, there is a chance that your board is (or is compatible with the firmware from) the KM9 PRO or the KM9 PRO DELUXE.
Click to expand...
Click to collapse
The KM9 devices use DDR4 memory, my board has DDR3. Can the firmware still be compatible?
I don't know. Maybe if the dtb has support for both types of ram. You'd have to check the dtb.
If you flash the dtb while watching the uart output, you'll know if it will work. But first you'd need to be able to start fastboot or have access to the uart shell, in order to flash it.
Support for both types of ram is not uncommon. For example, the sdmc dv8555 (S905x2) has multiple hardware versions, some with ddr3 and some with lpdd4, and both boards use the same firmware.
The original dtb and bootloader on your device are probably gone. They probably were overwritten before the flashing failed at 30%. You don't have much to lose by trying the other firmware, except perhaps a lot of your time.
I will try for sure. As you sad, there's nothing to loose. I probably shouldn't even bother (it was less then 10 dollars), but I hate contributing to e-waste, specially when the hardware is fine, the issue is software. And it's kinda my fault .