Related
I saw this product mentioned on infosync, and it got me thinking that with your growing knowledge of the Phone Edition's inner workings that something like this might be possible on the XDA:
PsiLOC+ miniGPS
(in case you don't want to visit the page)... Basically they are using information about which cell towers are in range to trigger events. They give some nice examples, like having an alarm go off when you get close to your train stop (that way even if the train's delayed and you're asleep you still get the "wake-up call" when you're near your destination.) Or how about having the phone turn the volume down (and switch to vibrate) automatically whenever you're in church or your favorite movie theater.
You could do the XDA a great service just making details of how to get at the relevant information (area ID and cell ID) public, if they aren't already...
CellID and other network info
At the lowest layer, there seem to be no AT commands to get network-related information. And at the TAPI layer (the only one an application can easily get to), this information is, as far as we know, unavailable.
We're working on understanding the modem better, and one of the aims of this endavour is precisely this: getting the CellID for location-based stuff.
Stay tuned (but don't hold your breath)
Surely not?
Surely the only communication with the radio stack isn't via AT commands. Is there no low level api, IO ports, DMA, interrupts etc? How, for example, is the voice stream delivered to the radio stack?
Would it be possible to write a kernel mode driver for these services?
I won't teach you to suck eggs, but maybe a few ideas.
Well... As we see it now all communication with the modem may well be multiplexed in one serial 115.200 bps serial stream. We're working on it...
On my Nokia 6210 I've installed Network-monitor. It shows easily this kind of information.
see this:
http://www.logomanager.co.uk/help/Tools/NetMonMenus.html
localization??? it's already there!
look:
http://www1.o2.ie/products_services/location_services
Re: localization??? it's already there!
kimmie said:
http://www1.o2.ie/products_services/location_services
Click to expand...
Click to collapse
These services are network based: i.e. the network knowing where the phone is. This is different than the phone autonomously figuring out where it is, without help from the network.
Depending on the provider, maps with cellIDs may be available.
serial stream.
XDA Developer, I'd like to be involved in the investigation of the modem. This interests me a great deal.
Not hot on hardware, but I can do some dissassembly and stuff like that.
[email protected]
Disassembly would be a lot easier if you set yourself up with a dev system for ATI Nucleus (which I'm told is the embedded OS for the radio stack).
I have a Nucleus setup here but it's geared toward PowerPC as the target. Anybody know what kind of processor is in the radio module? Is the DSP ("TI HERCROM") what's running Nucleus? According to ATI's site all of the dev tools for that port are maintained by TI. The chip has a JTAG interface, so that would make emulation a possibility, and might help. TI's tools for these things are historically free (they want you to buy chips, after all) but I haven't dug any deeper than this right now.
A 4 meg code space is quite a lot to have to wade through, and it's looks like they're using most of it.
Anyone who upgraded their T-Mobile device using the latest update has easy access to the radio stack ROM image, since it lives in the Windows directory after the CE OS upgrade and never gets deleted. There's a file called rsupgrade.cp64 (3.83 MB) which contains the code being squirted into the radio module's ROM by rsupgrade.exe after the first soft-reset.
Hi all,
I've learned that the StarTrek is able to boot the current kernel from the Linwizard project without any modifications. I've posted a video of this at http://vimeo.com/2114567. Before you get too excited, however, there's a few things to keep in mind:
The buttons aren't mapped correctly by default.
You need a networked computer to log in and do anything fun, for now.
If you're wondering about Android, the answer is "not yet".
I will do my best to address the important things here; what works, what needs tweaks to work, and (most of all) what needs attention. I will also, over the next day or two, try to post my findings regarding the button GPIOs collected from HaRET, kernel modifications necessary to fix a few things. etc.
Consider this post a call for help. I'm hoping this will encourage others to contribute toward more complete linux support on the phone. I personally am driven by the opportunity to dual-boot Android on the device, but I have much to learn and can't do this alone. So, if you have kernel experience and a StarTrek, here's your motivation to get hacking! (If you'd like to help, but don't have a device to test kernels on, I'm often in #xda-devs.)
Status (Let me know if there's anything missing here.)
Internal LCD - YES - Seems to work great.
External LCD - ? - Shows the device's default image. Not sure how to control this in linux.
Backlight - ? - Unsure. As far as I can tell, Linux will retain the brightness level being used when HaRET finished loading the kernel.
USB Networking - YES - Works like a charm.
Audio - ? - No idea. I don't know how to test this.
Cellular - ? - No idea, but I don't think it will necessarily come easily.
Buttons/Keypad - SOME - By default, the keys and buttons are mapped either incorrectly or not at all. The phone keypad and some of the special buttons type random keystrokes, since we are using the mappings for the Wizard. I have a modified board-htcwizard.c with correct mappings for the StarTrek I'll post really soon, as well as a list of the GPIO readings for many of the buttons. Unfortunately, the Up/Down/Left/Right/Select/End buttons function differently than the other, matrix-based keys. I have yet to discover how to configure them.
Camera - ? - No idea, but they don't even have this working on the Wizard (Linwizard's primary target device).
Light Sensor - ? - I wouldn't know where to begin. It barely works in WM, anyway.
MicroSD - YES - I can mount the MicroSD with no issues, full read/write. Even managed to open my photos in the GPE photo gallery on the device (launched over telnet).
X[\B] - YES - I am able to start X, by calling startx over the telnet connection. However, X will try to run a touch screen calibration before doing anything else, and this is a bit of a problem for us! Fortunately, on newer Linwizard versions, you can disable this by passing tslib=0 to the kernel (in the defaults.txt file you give to HaRET). GPE also seems to be running perfectly after X starts.
Problems - After a few idle minutes in linux, the screen likes to black itself out automatically, as per the design of Linwizard. Unfortunately, on the Star Trek, there seems to be no way to make the screen wake up. Telnet still works in this situation.
I promise to keep this post updated, and get my data together and uploaded soon. Please share your own results and tricks as they come along, and join me (and some talented people) in #xda-xevs and #htc-linux on irc.freenode.net. Happy hacking!
Attached:
arch/arm/mach-omap1/board-htcwizard.c - Contains key matrix mappings modified for StarTrek. Be sure to remove the ".txt" from the file extension before using.
default.txt - Used with HaRET to make Linux boot. The only thing unusual in here is the TSLIB=0 option that's passed to the kernel, telling linux to skip touchscreen-related tasks.
great work! but you need some advanced startrek owners to test linux - that's a big problem
Fantastic news! I' would really try it out. Unfortunatly my startrek's connector is damaged. I can charge the device, but I cannot connect with the pc. If I can use the micro sd card to install it(I think is possible) I will try it.
Thanks for the great job.
dancer_69 said:
Fantastic news! I' would really try it out. Unfortunatly my startrek's connector is damaged. I can charge the device, but I cannot connect with the pc. If I can use the micro sd card to install it(I think is possible) I will try it.
Thanks for the great job.
Click to expand...
Click to collapse
You can, by dropping Haret+default.txt+zImage+initrd onto the SD card. Unfortunately, without a USB connection, you won't be able to telnet into the device and run commands.
very interesting! Ive been waiting to hear this kind of news Unfortunately, I still use my StarTrek as my primary phone, so I can't test it out until it moves along a little further. I'll be sure to keep an eye on this thread, as this is good news!
gigawatts said:
very interesting! Ive been waiting to hear this kind of news Unfortunately, I still use my StarTrek as my primary phone, so I can't test it out until it moves along a little further. I'll be sure to keep an eye on this thread, as this is good news!
Click to expand...
Click to collapse
Linux actually boots directly from a Windows Mobile program called HaRET; When you're done playing with Linux, you can just reset the phone and you're back to normal. No permanent changes.
awesome! I'll give it a go right now, thanks!
BHSPitMonkey said:
You can, by dropping Haret+default.txt+zImage+initrd onto the SD card. Unfortunately, without a USB connection, you won't be able to telnet into the device and run commands.
Click to expand...
Click to collapse
I already did it, and works. Thanks anyway.
Why not combine the effort to get Android on it?
Kwen said:
Why not combine the effort to get Android on it?
Click to expand...
Click to collapse
Are you volunteering your expertise on the subject?
The point of this post was to accomplish just that: to attract the interest of more people who can contribute. I'm in the process of setting up a repository of changes right now, so the patches I've made so far are kind of scattered about my hard drive for the moment. If you're interested, you can try catch me in #htc-linux or #xda-devs on irc.freenode.com. Otherwise, I'm trying to keep the post at the top of this thread up-to-date.
Unfortunatly Android cant work, it needs 128 ram.
http://source.android.com/release-features
BHSPitMonkey said:
Cellular - ? - No idea, but I don't think it will necessarily come easily.
Click to expand...
Click to collapse
from linwizard wiki page :
What we need
Right now we need people with experience with GSM and WiFI to help get linwizard connectivity up!
Click to expand...
Click to collapse
about two years ago , another linux project ran that called Xanadux. why you don't use from Xanadux ?
sorry for my english !
I have linux booting
it up booting to the point correctly then sit conclusion cannot one yet start?
sorry for my bad english my german are better
Oh.......I think HTC Phone can do that ADIDAS ' AD "impossible is nothing"
Been a few months since ive been on the scene, any news here? My Cingular 3125 is nearing the end of its life, and I figured I can play a bit more with it
P.S. Whats new BHSP?
autologin on linwizard
hi
http://wlcrck.wl.funpic.org/wlcrck-elf-linux/autologin
to solve the problem i develop a simple aplication to automatic login but dont have any security autologin in root mode
to use this have to make a couple of things
you need decompress the inirtd and add this app to /bin and set suid and modify
/etc/inittab file and compress the initrd again.
change this line
tty1::respawn:/sbin/getty 38400 tty1
for
tty1::respawn:/sbin/getty -l /bin/autlogin 38400 tty1
sorry for my english
thanks for the code of htc board
Hey guys,
I've done some dev on *NIX before, including writing ways to sign my own packages using encrypted hashes and the like. Does anyone know the method that HTC is using to sign the zip files?
The reason that I ask is because I'm interested in trying my hand at reverse-engineering the signature. I am sure some of you guys have already done some work in that area, and I'd rather not repeat someone else's effort if y'all have already taken steps to break the signature. My CSI teacher told me to never start from scratch if someone else has already done good work. It's insulting to them, and makes more work for you.
Where are you folks at with breaking the signature? Is the method known (i.e., is it based on files inside the zip, is based on the bits of the zip, is an additional hash or added metadata, etc)? I would really appreciate any feedback on this if you have the time.
EDIT: For those of you who are leakers or users et. al. DO NOT get any hopes up about this thread. I'm just getting started and this idea could fizzle within minutes of you reading this particular sentence. Anyone posting, please focus on practical suggestions or comments such as sickbox's initial comment below. Thank you!
I've wondered about this since the beginning.
I understand just how complex signing can be (to some degree, I'm not a math guy but I understand scale).
My thought though is we can utilize several tools to make this process possible - though I have no idea how to implement most of this to make this possible. Maybe I'm nuts, but here goes...?
- We now have what, three or four different HTC signed images in the wild with another on the way (OTA). Would it be possible when trying to reverse the sig to utlize the differences between the packages to narrow the cope a bit?
And next
- Using GPUs to process data like this has been shown to be exponentially more efficient and effective than CPUs. What would it take to use some of our awesome GPU power ( a la CUDA) to attempt this task?
Lastly:
- Can we break up the processing required among several of us to speed things further?
I know this has probably been thought of before and discarded for good reason, but I guess the more ideas the merrier.
I'm no CS guy, but I would love to help! I'm one of those unfortunate leakers but rather than whine I'm looking for ways to help. Reversing the HTC key would make life sooo easy. Who knows, maybe they'll use the same key on the next few phones?
Pretty much why I'm asking NOW is because I have enough packages for me to examine and compare and test against. I'm not the best or the most experienced at it, but this kind of thing is fun for me and fits into my spare time. When I have spare time.
It's not the signing we need to know how to do its the cryptographic key that they use to sign their packages that we need. The private key changed with the last bootloader so even if we cracked the key before the couple hundred years it would have taken us to crack the one used for 1.5 we would have to do it again now for 2.1 stuff.
Just look around for test signing and such and you can find the test key that people use to sign stuff as well as the method used to sign the package.
As far as getting the key... you will have to know someone from HTC who would risk their job to get you a copy of their private key.
Greetings Sickbox,
I guess my intention isn't clear. I want to be able to sign packages regardless of what key HTC uses. We have a signature, and we have keyhole. I've noted that the behavior on my Eris is that the signed packages check out just fine each time no matter what version I'm trying to flash (obviously, cannot downgrade, I know, but trying to downgrade still passes the signature and it is the version that fails). So what I would like to do is reverse engineer the signature not necessarily to find the key, but to discover how to create keys. I have 4 different packages, and two test keys that I can examine.
I'm only wanting to know if someone knows how the packages are signed so that I can eliminate looking at all the signing methods. In my research so far, I haven't been able to google, bing, or yahoo anyone who knows what method is used to sign the HTC official packages.
That help, Sickbox? Thanks for your input, I really appreciate it.
So the intent is to reverse engineer the key correct? Then we can sign whatever we want...
Or are you trying something else?
Just want to see if we're on the same page.
1234567ten
I don't necessarily want to reverse engineer the specific key that HTC used to sign any one package, but rather the template for the keys. A prime example of this kind of key decryption would be DeCSS written by DVDJon. He quit trying to reverse engineer the keys used to encrypt DVDs and reverse engineered the decryption of DVD signatures.
I'm not using technical terms for the following, but basically when you sign or encrypt something, the key used is not found within the package or signature, nor is it in the program used to verify the signature or decrypt the package.
If I can do nothing with the signatures of the Eris roms, it's no waste to me. I have fun with this because I want to design an open source DRM system someday. *Sigh* dreams.
Try these. I'm still not sure if I fully understand your question but this as much as I could come up with.
Found by searching "android signing" & "android sign rom" on google if you wanna see what else might come up.
http://developer.android.com/guide/publishing/app-signing.html
http://androidforums.com/developer-101/8665-how-signing-roms.html
sickbox said:
Try these. I'm still not sure if I fully understand your question but this as much as I could come up with.
Found by searching "android signing" & "android sign rom" on google if you wanna see what else might come up.
developer.android.com/guide/publishing/app-signing.html
androidforums.com/developer-101/8665-how-signing-roms.html
Click to expand...
Click to collapse
Hmm... maybe I was being too specific when looking for "htc sign rom" and "eris htc sign rom," etc. I'll see what I can cull from those broader searches. Thanks for the tip, sickbox.
np
34567ten
You might have noticed that there is a little bit of confusion in the posts here when "signing" is brought up; there are two completely different signing methods in use.
The first applies to applications (.apk bundles), "update.zip" files (which could be used with Amon_RA's recovery), and OTA-delivered update files. The distinguishing feature of these .zip files are: 1. They have a META-INF folder in them with two Manifest files and a RSA public key file, and 2. there is nothing "unusual" about the zip file itself. (The contents of the zip file are signed, but the whole zip file is not.)
The second type is the "rom.zip" files buried inside the MR1/MR2 " RUU" updates. These files, when renamed to PB00IMG.ZIP, can be used with the bootloader to update the phone. The distinguishing feature of this type of file is that: it has a mystery blob of binary data at the front of the zip file - 256 bytes. The rest of the file is an ordinary .zip file, and if you unpack it you will find that there are no manifests, no META-INF file, and no public key certs. (In this case, the entire zip is signed, but none of the individual content files are.) I think it is this second type of signing you were referring to in your posts, but honestly I am not certain.
The first form of signing is perfomed with a java tool called "jarsigner", and its behavior is well understood: it creates the first manifest file by computing SHA-1 hashes for every file to be included in the .zip archive. Then, it creates a second manifest file which shadows the first one, and for each SHA-1 hash value, it "signs" them using the signer's private key. In this 2nd file, it also computes the hash for the complete (1st) manifest file, and signs that hash. In any event, what I mean by " well understood" is that this is just a standard use of RSA public key cryptography, using widely deployed Sun Java tools. Break it and you will have made quite a name for yourself.
Now, as for the 2nd type of file - rom.zip/PB00IMG.ZIP, I have not seen anyone (yet) describe the format of that MIC (Message Integrity Check) 256-byte blob. I poked at it a little, but certainly not exhaustively.
If you want to add to the knowledge here, try and discover what the "format" of that MIC is. I suspect that even if you do that, you will find that the sig uses exactly the same PK tools that are already built in to the bootloader - from the standpoint of practicality, it really doesn't make any sense why HTC would " roll their own" when they already went to the effort of coding RSA tools into their botloader(s).
bftb0
Hey bftb0,
You answered my question PERFECTLY. Nobody I've spoken with elsewhere has yet brought up the RSA encryption that's already built into it. You're probably only second guy to mention it, beyond some dude in an IRC somewhere (and I think he was drunk at the time).
Knowing that it is just additional bits on the zip, has anyone thought off hacking it off and paring it to another zip in an attempt to "sign" the zip (I've done this successfully with various signed ISOs)? Also, the public key could be arrived at, given two factors, 1. The same key was used for all Eris 2.1 packages; and 2. The "blobs" of data can be sufficiently compared and I have enough computing power.
Thank God I may be getting an intel I7.
Or I'll just borrow my friend's PC.
I hope I'm not just blowing steam, because it would suck to get working on this and then find it's impossible. But they say that about a lot of key encryption schemes. LIKE RSA on Blu-Ray.
Thank you so much bftb0
Don't read too much "encouragement" into my post; I responded in order to shed some light on the way that HTC is doing things, and that's about all.
If you think about it carefully, you will understand that the manifest-signing operation gives you hundreds, if not thousands, of individual plaintext/crypt-text pairs that are all signed with the same private key. That doesn't mean that a known-plaintext attack is easy, though.
The EFF commissioned a project a couple of years back where they built custom hardware that would brute-force key searches for short keys- 256 bit keys IIRC. The machine they built was a parallel processor built from fpgas/DSPs, and it could recover keys in a few days. Their budget for that was in the low 100,000s. Offhand, I don't know what key length HTC is using, but I doubt it is 256 bits.
I don't recommend you spend any cycles trying to brute force a key recovery.
bftb0
bftb0 said:
Don't read too much "encouragement" into my post; I responded in order to shed some light on the way that HTC is doing things, and that's about all.
I don't recommend you spend any cycles trying to brute force a key recovery.
Click to expand...
Click to collapse
Dude, I was so encouraged that I want to rip open my PS3 and put it to work RIGHT NOW.
Not really. I'm too lazy-assed to spend much time brute forcing it. I'd rather pick it apart and see if there's anyway to mimic the signature. Your advice that it may be RSA based is more exciting in that it helps me know what I may be dealing with. I hope to pick at the binary data appended to the signed roms either tomorrow or next weekend.
And thats what I appreciate.
I'm not sure what you're trying to do. You either brute force the private key, using various bits of super-math (e.g. elliptic curve cryptography?), or you give up and move on -- perhaps looking at patching the subsystem responsible for validating signatures (dangerous for production use).
There are no "mimicing" possibilities and swapping blobs/zips around is just silly. You should spend your time elsewhere, like reading up on how public-key cryptography works.
Thanks WithinRafael,
I think some of what I've written above shows I'm researching public-key cryptography. I really appreciate your thoughts, and it became clear by the end of sunday that the signature is specific to the package. Without me doing much work, mostly research. RSA is a load of work and I do not want to mess with trying to crack that.
I recently became interested in trying to turn S-off. Someone recently gained RW access to NVRAM, and I'm hoping this weekend to move on as you mentioned. Thanks for the good discussion, guys!
with a pen....duh j/k
Anyone have a supercomputer? ...lets brute force it.
Is there a way to check if a rom passes the signature test without trying to load into the phone? Can we check if the signature passes on a computer?
If so we could sign it with all possible keys and see which one passes.
Is this frowned upon and shouldn't even be discussed? or would it just take too long to do? ... or is it just not possible to check the signature on a computer?
... or all of the above?
DarthMowzy said:
Anyone have a supercomputer? ...lets brute force it.
Is there a way to check if a rom passes the signature test without trying to load into the phone? Can we check if the signature passes on a computer?
If so we could sign it with all possible keys and see which one passes.
Is this frowned upon and shouldn't even be discussed? or would it just take too long to do? ... or is it just not possible to check the signature on a computer?
... or all of the above?
Click to expand...
Click to collapse
We can check the signatures based on what is stored in the Manifest file inside the PB00IMG.zip file.
It is possible to brute-force it but it would take years to do so it isn't really worth the effort.
UPDATE:
So it seems as though i have solved that problem, and now i just away the kernel modules. Thanks for all your help guys.
Code:
adb shell /data/local/kexec /data/local/uImage
MSTART= 12668952828585181184 MEND=18014435486466048 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
MSTART= 12668952829122052096 MEND=18014435822010368 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
MSTART= 12668952829390487552 MEND=18014436090445824 MEMTYPE=0 NR_SEGMENTS=0 ULONG_MAX= 4294967295
start= AFD1297980000000 mem_min= 0 hole_min=0 end=4000089C000000 mem_max =FFFFFFFF hole_max=FFFFFFFF
Cannot open /proc/atags: No such file or directory (Doesnt really matter from what ive read)
kexec_load failed: Function not implemented (The module)
entry = 0x80008000 flags = 280000
nr_segments = 2
segment[0].buf = 0x2e4e8
segment[0].bufsz = 10
segment[0].mem = 0x80001000
segment[0].memsz = 1000
segment[1].buf = 0x403ff048
segment[1].bufsz = 2c4214
segment[1].mem = 0x80008000
segment[1].memsz = 2c5000
So hears the deal myself and gameman73 have been working our a**es off trying to get this KEXEC to compile and work. The problem is the current memory will not allow for certain calls to the iomem.
We need to find a way to have this line of code compile and be true on our devices. If someone could sift through the code alittle that be well appreciated:
Code:
kexec/kexec.c 230: while ((j < info->nr_segments) && (([B](unsigned long)info->segment[j].mem) <= mend[/B]))
Apparently it thinks info->segment[j].mem is a const * void
Here's the source http://horms.net/projects/kexec/kexec-tools/kexec-tools-2.0.2.tar.bz2
When I work on something, I often find that having a complete understanding of the problem makes the solution clear. Perhaps this will help you understand the problem better:
SEE ATTACHED FILE, FIRST LINK*
Related. Looks like you aren't the first person to have a problem with the way memory is called in kexec. You might be able to work something out from this discussion, however old it may be.
SEE ATTACHED FILE, SECOND LINK*
This is something else about disabling kexec from executing. A workaround is discussed, but I am by no means a developer and I can't make any sense of it. Just giving you what I find.
I don't mean to spam, and I don't want to be the typical noob getting in the way, but I do want to help. Research, it seems, is about all I can do until my unit arrives (hopefully tomorrow).
*edit: since this is my first post, please excuse the attached file. It is only because with less than 8 posts I cannot put the links in the body of my message.
twodollaz: research is awesome. digging that crap up is a giant pita.
loglud: did you guys get kexec-mod compiling and loading? i haven't had time to look at it much, but all the sources i've found require a huge amount of work to compile, let alone load and run. do y'all have more information on that? i'd look at why the line you mentioned isn't working but i have no frame of reference if i can't reproduce it myself :-/
Actually you really don't need the module to reproduce the error that I am talking about. But gameman73 does have a fully compiled module loading into insmod. And it is showing as installed. You can ask him.
As for you links twodollaz there actually very useful, however not for our problem. The problem that they are incurring is that of the memory not being malloced, or assigned to the process. Our problem is that according to the program there is no memory existing, (the page is there but the lines are not). I think i might have found a solution last night while sleeping ironically, however i am in work and cant test till I get home.
You've gotta love it when your subconscious does the work for you.
If you guys need more help with this I would be glad to join in. I have literally no experience with kernels, hardware, etc though so I will need some hand holding to get kexec loaded and testing. Once I have the build/run setup I might be able to help. I am a programmer by trade, mostly java based, but can write c/c++ when pressed. Alot of what I do on a day to day basis is pull apart other people's code and fix it, optimize it, etc - mostly in a JVM but I have done this some for system cores.
zambien said:
You've gotta love it when your subconscious does the work for you.
If you guys need more help with this I would be glad to join in. I have literally no experience with kernels, hardware, etc though so I will need some hand holding to get kexec loaded and testing. Once I have the build/run setup I might be able to help. I am a programmer by trade, mostly java based, but can write c/c++ when pressed. Alot of what I do on a day to day basis is pull apart other people's code and fix it, optimize it, etc - mostly in a JVM but I have done this some for system cores.
Click to expand...
Click to collapse
zambien you are my new best friend. If you could take a look at what are valid memory locations in the locate_holes function that would be amazing. So far when i do an
Code:
fprintf(stderr, "mem= %li...",(unsigned long)info->segment[j].mem))
i always get nothing. I think this might be because j needs to start at 1 but idk. if you could find a way to iterate through
Code:
info->segment[j].mem
and find where it is valid, we might be on our way.
Forgive me if I'm way off, but how does this sound? I don't know if this device is EFI compliant, but if it is - and apparently some ARMv7 devices are - then it could allow kexec to reference a more complete memory map provided by EFI. The patch behind the link is for x86, but perhaps there are some ideas it might provide.
Just trying to help.
See attached for link..
twodollaz said:
Forgive me if I'm way off, but how does this sound? I don't know if this device is EFI compliant, but if it is - and apparently some ARMv7 devices are - then it could allow kexec to reference a more complete memory map provided by EFI. The patch behind the link is for x86, but perhaps there are some ideas it might provide.
Just trying to help.
See attached for link..
Click to expand...
Click to collapse
Hmm thats very interesing... Ill try this when i get home. Im looking though it more and im starting to think that this could be our problem. Im going to pull one of the patched files down tonight and try seeing what happens.
Has anyone had any luck find the source code for the MTCB MCU? I'd like to mod the shutdown timer such that it leaves the device fully operational for the timer duration. Or if anyone has info on the instruction set used, I could perhaps made the mod using assembly or bitbanging.
This may help. It uses an 8051 instruction set
KLD2-v277 "source"
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
dhmsjs said:
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
Click to expand...
Click to collapse
Great work! Thank you! I'm not profound in this MCU programming but I really believe that it is of great importance to hack that code and mod it in order to squeeze more from these units. A applause you and hope other will join your effort.
Open source implementation could be interesting down the road
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
webdude12 said:
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
Click to expand...
Click to collapse
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
dhmsjs said:
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
Click to expand...
Click to collapse
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
webdude12 said:
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
Click to expand...
Click to collapse
While it is by no means complete, I've worked through enough of this MCU code that I think I have a pretty good high-level understanding of how and what the MCU does. As I said above, what I'm missing now is much of the hardware context (for example which MCU pins connect to what, some of the peripheral chip #s, etc), and also the Android software context -- specifically the code that sends commands through SPI to the MCU. I have looked briefly at some of the Android code (for example MTCManager.apk) but didn't find anything useful there. It seems like the SPI interface is lower level -- perhaps as in a device driver??
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
DRidilla said:
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
Click to expand...
Click to collapse
Sound processor yes since that is just sending different commands to the sound processor. Mic mod no since that is a hardware mod only (as far as I can see it anyway).
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
Click to expand...
Click to collapse
My understanding of the mic hardware interconnection is not good enough to say one way or the other. Probably varies from model to model as well (I don't seem to have a big problem with my external mic).
Control radio before Android boots might be tough since most all of the radio user interface comes through Android anyway. Might be possible to restore previous radio config before Android is up, but that might also not be such a great thing for many users. Not sure I'd want my radio to come up blasting away if I don't also have a way to silence it.
Then again with an open source solution, all you would really need is the will to make it so. I guess we all have our own dream lists, no?
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal?
Click to expand...
Click to collapse
Both microphones are hardwired together. It is not possible to "shut off" one with software. There's also a modification to improve the radio's frequency response by replacing some capacitors. Again, not possible with software.
dhmsjs said:
...
Click to expand...
Click to collapse
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Aaaron16 said:
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Click to expand...
Click to collapse
Thanks! Really appreciate the photos. Difficult to read the chip #s though.
I know the radio device is similar to a TEF6624 - maybe a TEF6686?
Pretty sure the sound processor is a BD37531 or BD37534.
Not sure what the video matrix switch is -- FMS6502 maybe?
These all connect to the MCU via I2C. Interested in identifying the other devices that connect via I2C too. I can see the I2C addresses they use to communicate with the chips, but I can't generally look up a chip # by its I2C address. The goal is to find the data sheets for each device so that I can understand exactly what the I2C comm is doing. I have data sheets for the devices listed above.
Also as an update: I stated above that the MCU is controlled by Android through an SPI channel. I've been studying this more closely and it is clear that it is not actually SPI. Looks more like a custom 3 wire interface. Uses pins 1, 2 and 3 of the MCU (the IAP15F2K61S2 device).
Pin 1 (P0.5) is data (or ACK) to Android from MCU, driven by MCU
Pin 2 (P0.6) is the clock, which can be driven by either side (open collector with pullup?)
Pin 3 (P0.7) is data (or ACK) to MCU from Android, driven by the Android CPU
It would be helpful to know which pins these connect to on the Android CPU.
Each bit sent must be acknowledged by the receiver before the next bit is clocked out. There is debouncing and timeouts applied to the signals and the transfer is aborted if either fails. Maximum bit rate is around 1MHz I think, and probably slower in actual use. If anyone recognizes this as a particular comm standard, let me know! Otherwise it must be custom for these HUs.
Component Listing (KGL Mainboard)
I noticed the KGL devices use different radio modules even across the same model. I have some units with TEF6624 modules and others with TDA7786 modules. The following are the IC part numbers for the newer 1024x600px KGL main board (date code 2014-07-20):
1. AU6258J61-JES-GR (USB 2.0 Controller)
2. 15L2K61S2 (MCU)
3. FMS6502MTC (Video Sw Matrix)
4. BD37033FV (Sound Processor)
5. GM8283C (? - 10+ traces going to 50-something pin IDC display connector)
6. T132BT (TFT Video Controller)
7. WM8751L (Stereo DAC) - markings rubbed off. See attached photo.
I couldn't find an I/O expander chip on the main board, so I'm guessing the MCU drives most of the I/O lines directly (aside from those handled by their respective audio/video controllers).
Possibly related, I found this document which seems to include many of the same components:
http://p.globalsources.com/IMAGES/PDT/SPEC/216/K1127159216.pdf
MCU Memory Map/Resource Use
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Could Malaysk make modified MCU with redisigned sound processor and sleep mod fo MTCB-MD-V2.67:angel:. I cant post download link
drive.google.com/file/d/0B9-2UI8L0wScel92bUFlaExkWnc/view?usp=sharing
dhmsjs said:
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Click to expand...
Click to collapse
How is this progressing @dhmsjs ?