I have a problem that I hope some of the code gurus here can help me with. I have an HTC PDA that was codenamed Colorado. The Colorado is actually the Dell Axim X50 series. I have a thread on Aximsite http://www.aximsite.com/boards/showthread.php?t=140071 where I am trying to add a USB host hardware interface to the PDA. I have done quite a bit of hardware reverse engineering of the X50v device (I'm a old-time hardware hacker) and have been able to bring out the PXA270 USB host port1 interface to the outside world via two unused pins on the sync connector.
I originally noticed that the X50v A02 ROM had the OHCI driver included, so I rolled back to that release on my test PDA and have been attempting to get the interface operational. In my quest, I have determined that I need the usbd.dll driver as well as any client device drivers for HID, mass storage, etc.
I've used a number of the great utilities I've found on this site (thank you very much) to grab a copy of the Axim ROM and pull it apart. I consider myself great at working on hardware but my software skills have become rusty over the years (hey - I started by building this system a 'few' years ago: http://www.sol20.org/ )
What do I need?
I would appreciate getting some guidance on how to dissassemble the ohci.dll module so I can see if in fact, it was designed for the X50 or if it was left in by accident by HTC as the later ROM updates for the X50 series had the ohci.dll module replcaed with one named peripheral.dll which was about 1/5th the size.
Also, I'm wondering if either the ohci or usbd drivers require the irq and/or the membase of the PXA270 USB host port1 interface and if so, how do I determine those.
My original idea was to use a simple 2 port hub to bring out the interface. Unfortunately, I recently discovered that a hub requires a hub client driver. Because of that, I will settle on getting a USB flash memory key to interface directly as the drivers are already available. One of the problems I have is interfacing the 3v USB host lines on the PDA to the 5v data signals that may be present on the client device. The PXA270 USB host lines are already terminated on the PCB with 15K resistors. All that is needed is a transient protection chip and/or port driver chip.
I have installed the free Microsoft WinCE dev environments which I thought contained the source for the generic ohci driver, but I can't find it anywhere so I guessing it's not included in the free dev s/w.
Although this is only my 2nd post here, I do hope to be able to contribute technical information going forward. What I'm doing on the Aximsite is quite advanced as far as hardware hacking goes and I hope to be able to simplify it so a few others can 'play'.
Thanks in advance for any help and I wish everyone here a great New Year!
Wow. Well this is a bit over my head, but does sound great.
I will try pointing you toward a couple of useful tools:
1st is IDA probably the most powerful disassembler for ARM code. The free evaluation works fine, but won't save and closes about every 30 min. Still should do the trick if you just want to look at the code.
2nd to get sample driver code, you need Platform Builder. Not sure if that is what you downloaded, but try the provided link. Evaluation version contains all the source code MS is willing to give, it just has some limitations on ROM compilation (which you should not care about).
The only problem is, it's a real b*** to install. Takes hours even if you have a goo internet connection.
Hope this helps.
Thanks for the quick reply.
Do you know if there is anyone who knows a little on how the low level device drivers actually interact with the hardware ports?
Also, I assume that with just the ohci and usbd drivers, if the port is actually activated by pulling one of the data lines high, I should get the popup box asking for the name of the device driver. correct?
how to determine I/O base offset?
In trying to reverse engineer the ohci driver for a couple for the HTC units, I need to figure out where the I/O register base starts.
Are there any memory dump utils, like dumprom, that would indicate that?
I've installed platform builder and want to try compiling the standard ohci driver, but I need to know how to determine the start of the I/O registers on a given WM2003SE platform.
Any assistance would be greatly appreciated.
thanks
Related
Hello all.
Experimental version of custom mode controller for TIACXWLN built-in adapters
is located at http://winm-soft.atspace.com
Who is interested may test it...
Hello AlexB.
I was trying to run your program on hermes with WM6 which according to wiki is equipped with TI chipset, I found references in registry to TIACXWLN drivers but unfortunately your custom mode controller don't want to work all I've got is "Cannot process memory block!........" after choosing yes "Cannot read configuration! It is possible device is off." but the wlan device is actually on. I'll send you my *.dmp files maybe you can manage to make it work on hermes.
I had been toying around with the custom mode driver and have had little success thus far. Another thread was started and I have since taken great interest in trying to achieve promiscuous packet sniffing on my Tytn. I believe the problem may lie within either the custom driver, tiacxwln.dll or the hardware itself.
A little more information...
Mode controller works (attempt) directly with adapter (ACX100, PCMCIA!!!), not with the driver (standard, not patched). Program extracts an address of adapter registers window from TIACXWLN driver (TIACXWLN1 device object) and next it enables some packet filters, executes commands and etc...
I have no new ideas now why it works badly on such built-in adapter (device process commands with success status)...
On Dell I receive all packets but sometimes only...
Alex is it possible for you to patch internal driver to use promiscuous mode and don't bother with custom controller?
The custom mode controller is probably the best way to go about activating promiscuous scanning, since it's affect can be made temporary. If this mode of packet scanning were always enabled, I believe it would not allow one to associate with an access point.
I've attached the dump files that were generated after the unsuccessful execution of tiacxwln_ctrl.. perhaps the author or someone else can derive a solution .
Hi, Alex.
I was looking for your tiacxwln_ctrl custom controller on your web site, http://winm-soft.atspace.com/ but I could only find TNETWLN and WCF-11 files. Has it been moved, or deleted? I'd like to try it on my HTC 8525 with WM6.
Walt
I've received a private request for the file that AlexB developed and had posted on his site winm-soft (it's no longer available) which is mentioned above.. it will not enable promiscuous scanning on the Hermes. I repeat, it is broken, it does not work. AlexB did a great job creating this hack, however I don't believe that it was ever intended to work with the 8525. If AlexB would be so kind as to provide his source then perhaps we would have a decent starting point to enable this feature, however anyone who would be interested in doing this would find 3 perhaps not so obvious hurdles.
1: The TIACXWLN.DLL driver needs to be hacked to enable monitor mode.
2: A program capable of capturing and storing .pcap files would be necessary at this point as the only program that I'm aware of capable of sniffing out weak keys is airsnort which only accepts pcap dumps.
3: The pcap file would be huge. ie - could quite possibly take up 1gb or more of a micro sd card.
Just my $.02. Comments are welcome. Now onto the file. Enjoy!
Hi everybody,
The TIACXWLN controller was developed (beta/gamma...) for Dell X51 PDA and program worked bad and it is discarded! That program got some pointers (parameters) from context parameters of standard tiacxwln driver... Standard driver in Dell and driver in HTCs are different... Some experience of controller development was used to make TNETWLN controller (also TexasInstr adapter)... All controllers try to enable only promiscuous mode (not monitor mode).
As yet there are no TIACXWLN promiscuous mode ideas and devices...
Now some ideas for TNETW1251 (with SDIO) exist.
Thanks for the clarification.
Alex, I don't understand your reluctance to release source code, unless you based it upon "inside knowledge" of someone's copyrighted code, in which case I understand completely. If (and I fit into this category myself from time to time) you are simply embarrassed by code that "worked bad and it is discarded!" then maybe you could release it to a small group of coders who would be able to make it work without a lot of public exposure.
My personal interest is simple. I have a Zaurus C3200 that I use to sniff out rogue access points on the networks I am responsible for. It's big and clunky, and only works on 802.11b networks, so I don't carry it all the time, whereas I *always* have my 8525 with me, and it will work on b/g.
As far as WEP cracking goes, with ARP injection you can get aircrack to find a key with files of around 1-2MB in size, so the pcap files would not be too big. Of course, as I understand it, you *would* need monitor mode for packet injection to work.
IMHO this is a valuable development work that should continue. I just wish I had the skills and time to do more myself!
Walt
About sources
Main idea of contollers is working in special modes in parallel with vendor driver/software (without patching and etc.). All information, command structures and register constants was extracted from: http://acx100.sourceforge.net/
Who is intersted in building of new TIACXWLN driver should analize these sources. There are many commands and constants in these sources but controller used only Packet Filter command. All that the controller needed was address of mapped window of registers (it was stored in vendor driver context)... TIACXWLN adapter on Dell X51v processed these asynchronous commands with success (by response) but vendor driver was as post-processor any commands...
Commands are used by controller (details see in Linux driver (acx_struct.h)):
1) ACX1xx_CMD_INTERROGATE (IE_RXCONFIG)
2) ACX1xx_CMD_CONFIGURE (IE_RXCONFIG, RX_CFG1_RCV_PROMISCUOUS)
...
Hi, thanks to Lancealot for upload this file.
I install this controll driver in my HTC Universal (Universal have Wi-Fi chip from same corporation as TyTN: tiacxwln).
But this controll utility is not work on my UNiversal :-(
That setings promiscous mode, so Universal is freezed :-(
Anybody have any ideas ?
* Please excusive my for my bad english, thanks.
Hi Alex
I hv Sedna and have the discvussed Wi Fi driver..My problem is that it connects to wi fi router (g) but I cannot surf..most of the times I have to on/off and it works, but after long periods it disconnects.I hope this will solve the problem, also if u can suggest any guidance,I will b greatful
AlexB does your sniffer allow you to capture wifi traffic in all channels?
Hi,
Sniffer captures "adapter driver <-> protocols stack" packets...
Standard driver of WiFi adapter returns packets only after connecting to some network therefore sniffer gets traffic from one network on some channel... In promiscuous mode adapter gives user packets with foreign destination address.
Do you know what devices supports USB host?
as far as I know: no ;-)
Athena, flame and shift
USB Host built in... !?
I have read most of the posts related to the USB Host thing...
Everytime i must read such things like that the Tytn has no hardware that supports USB-Host...
But Samsung says, that the CPU and Chipset has built in USB-Host AND USB-Device Ports...
http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=SC32442
So the statement that its hardware cannot do USB-Host is not true.
If the CPU and Chipsets has built in USB-Host Functionality, the Hardware-Ports in the Chips (i think) have to be used at the USB-Interface at bottom of the Tytn.
So at end, it has to be only a Software Problem to support USB-Host Functionality directly at Tytn...
Anyone who can follow my Ideas, or do i have an error in my thinking?
the usb functions of the cpu is not used there is another chip which handle usb for htc devices
even if the cpu support host non of the connections are passed on to any connctor
So is my Question, why should they do such irrational things ?
Why use another additional Hardware (at additional costs!!), if the already existing can do the functions ?
If they really do that, they must be mad... throwing dollars out of the window and make the product more expensive than it can be.
Its like i buy a Ferrari and only drive 130 km/h instead of 250 km/h on our german highways.
not sure the reason but it have been don for many generations of pda's from htc maybe the r&d cost of changing their pcb design is bigger then using their current design
or maybe they dont want to wander into the jungle of getting piles of support calls and mail with people wanting usb drivers for this and that not to mention the issue with having to be forced to substain a .5 mAmp output to usb devices with batt issues
and having to handle correct handling of init'ing connected usb devices after on off
But the Flame, Shift and Athena have USB-Host Funtionality you said.
Especially the Flame is much like the Tytn. So the Thing about Drivers, Batt and Current have to be the same.
I wonder in addition a little bit how it came to the sdhc compatibility that was not given under WM5 but now under WM6. For me that means the Hardware of SD is everytime the same, only the Software changes a bit. So the Tytn must accept cards up to 32gig...
Why they do such things will be a mystery on for the future.
I think with conventional explanation attempts it will not be done.
Maybe i will write a mail to HTC and will do the Question again there.
you should not sure if they will reply or even read it but you should all the same
but flame is not a htc device
I just picked up an HP IPAQ 310 GPS device based on Windows CE 5.0. As far as standalone GPS devices go this one is very highly spec'ed:
http://www.amazon.com/310-Bluetooth-4-3-Inch-Widescreen-Navigator/dp/B000VRYLU2
600Mhz DualCore Centrality Titan Platform with on-chip GPS
300Mhz DSP
128MB RAM
2GB Flash
4.3" 800x480 LCD display
Bluetooth 2.0+EDR
USB 2.0
Windows.CE 5.0
It currently runs a variant of IGO 2008 navigation program and has some onboard games from PDAMill.
This is my first Window.CE project. Does anyone know where I can get the appopriate BSPs etc.. to allow me to build a bootable/working CE Image from Platform Builder 5 or 6 with full driver support?
My dream is to put a Microsoft Automotive software stack on this see how close I can get to a converged device like the Microsoft/Ford Sync. It will also be a learning experience.
In particular my end goal is to enable the following scenarios:
Voice recognition
Bluetooth DUN/PAN
Bluetooth Handsfree and voice dialing
Information Services (via web services interface to online services from Google & Microsoft). Think of movie times/locations, traffic, gas prices,address/phone/poi lookup etc..
Full fidelity video/audio player
Launch native and emulated games
Plug-in framework to extend the features
Navigation
The spec of the HP 310 Travel Companion is very impressive and I like the idea of it being a multi-purpose device. The 4.3 inch display is large enough for use as a GPS as well as watching videos. Seriously I wouldn't need GPS function every day so it is great be able to use it for other purposes. I wish one day it would be able to receive free digital TV signal like those from DVB-T or DVB-H. That would make it a truly Travel Companion.
Wow you really are dreaming if you think you can get a BSP for this device.
Or for any device for that matter.
These are never released and I never even heard of one being leaked! Just like any other proprietary code BSPs are highly guarded.
What you are trying to do is pretty ambitious, but if you want to rebuild OS for something by your self you better get a Linux device.
Sorry.
levenum said:
Wow you really are dreaming if you think you can get a BSP for this device.
Or for any device for that matter.
These are never released and I never even heard of one being leaked! Just like any other proprietary code BSPs are highly guarded.
What you are trying to do is pretty ambitious, but if you want to rebuild OS for something by your self you better get a Linux device.
Sorry.
Click to expand...
Click to collapse
Okay. Does anyone know much about the Microsoft Sync / Microsoft Automative software stack for Windows CE?
Regarding Windows Automotive:
You must be dreaming if you think you can source an Windows Automotive (or is it Microsoft Auto now?) OEM Adaptation Kit to do this!
As I understand, you need to be a huge OEM/ODM or car manufacturer like Ford and sign an NDA to even get any kind of access to it.
Considering its difficult enough to even source a Windows Mobile kit, I'd imagine its even harder to get Windows Automotive considering the circumstances...
However, there may be another way to source the Windows Automotive OS components besides obtaining an official kit...
Perhaps if there are some firmware updates for one of the Windows Automotive devices from Fiat, Ford, Clarion, etc. you can dump the ROM image and extract the files. Now, even if you do that you might still need to fix the relocations of every dll file...but it still might work on your HP after all that. I'd imagine you would also need to manually figure out the skin format of the Windows Automotive apps since you don't have the actual desktop tools to generate them...
I doubt you would really even need to source a BSP and build an image once you get this far. Chances are the apps you extract will run just fine from an SD card or the internal flash disk of your device if configured properly.
Off topic...
I managed to brick one of these today within the first hour. Just testing out Flux Challenge when it threw up a Please Wait screen. Soft-reset and now it sticks at the HP splash screen; had to get it sent back. Thank goodness I was only testing it.
Given this plus its molasses-slow performance, I think I'd choose something else if I really wanted to do any sort of modding...
Hi i have a 314 UK Version and wants to flash it with the german version.
Has anybody tried it ?
modellbobby said:
Hi i have a 314 UK Version and wants to flash it with the german version.
Click to expand...
Click to collapse
Where did you get the ROM ?
some sort of firmware update is on the HP FTP server (also includes newer maps)
Use the engineering mode to dump and restore the ROM.
have an Ipaq 310 running igo8 and finean4, like to get garmin but seems to have a resolution problem, anyboby can help plz"
[8/23/08 21:36:29 67512KB 4.20.50wp]
GFX_buf_alloc: Invalid area (-20048 480)
[8/23/08 21:36:29 67508KB 4.20.50wp]
Failure 87 allocating bitmap of size (-20048,480) 16 bpp (0)
[8/23/08 21:36:29 67448KB 4.20.50wp]
Read Access violation at data address 0xFFFFFFFC.
Program address 0x00058080 in background thread NULL (CSubAppThread::Run Garmin Mobile XT)
[8/23/08 21:36:30 67440KB 4.20.50wp]
CALL STACK:
0x18156EC0
0x182B7104
0x029FC9C4
0x02A03D24
0x93C0A090
0x93C33EA8
0x93C0DEB4
0x93C09FA8
0x18058080
0x18059900
0x180D18B8
0x180D1CEC
0x182B71E0
0x182B7010
0x182B6C54
0x029DDF04
klingklang01 said:
have an Ipaq 310 running igo8 and finean4, like to get garmin but seems to have a resolution problem, anyboby can help plz"
[8/23/08 21:36:29 67512KB 4.20.50wp]
GFX_buf_alloc: Invalid area (-20048 480)
[8/23/08 21:36:29 67508KB 4.20.50wp]
Failure 87 allocating bitmap of size (-20048,480) 16 bpp (0)
[8/23/08 21:36:29 67448KB 4.20.50wp]
Read Access violation at data address 0xFFFFFFFC.
Program address 0x00058080 in background thread NULL (CSubAppThread::Run Garmin Mobile XT)
[8/23/08 21:36:30 67440KB 4.20.50wp]
CALL STACK:
0x18156EC0
0x182B7104
0x029FC9C4
0x02A03D24
0x93C0A090
0x93C33EA8
0x93C0DEB4
0x93C09FA8
0x18058080
0x18059900
0x180D18B8
0x180D1CEC
0x182B71E0
0x182B7010
0x182B6C54
0x029DDF04
Click to expand...
Click to collapse
Is seem to be the resolution problem of our GPS... I'm having the same issue also. We need to find some doc to change the resolution... I'm still searching for the solution, any1 know how to cange it???
Regards,
Jeff
iPAQ 3xx Series
This is an old post but I thought I'd confirm a couple things for the record, should anybody be looking into this kind of info in future although the device is technically EOL.
40th Floor said:
As far as I know, this iPAQ is the only device to have ever even used the (exact) processor it's using.
Click to expand...
Click to collapse
Yes this is the only iPAQ with a dual core processor for that matter.
40th Floor said:
And funny? Funny is that when it's on a charger (any external power at all) it runs at half speed (300 MHz) but when completely on battery it runs at 600 MHz.
Click to expand...
Click to collapse
The original USB 2.0 spec called for no more than 500ma to be pumped through the USB line. Around the time WM5 was being rolled out, HP had to wrestle with the USB klan to convince them that wasn't enough to run a device and charge it. HP was making better use of the standard by doing more with it than the authorities thought was needed. They eventually backed off and HP up through the time I'm writing this ships an AC adapter with each device that has a mini or micro USB connector; obviouisly needed since the 22-pin connector died with the 6900 (Moose) device. The adapters provide up to 1000ma of juice.
Now consider this: Prior to dropping the 22-pin connector HP shipped 2amp chargers which provided enough juice to run the device and charge the battery at the same time. The 22-pin standard came out with the h3800 Series which ran a 400MHz ARM single core and didn't have fancy stuff like WiFi built in, and only had a standard QVGA (320x240) screen.
So how could a device with a GPS, such a larger screen, and a dual core 600MHz CPU be expected to even operate with a 1amp charger, let alone charge the battery?
Playing with the OS - Differences between WinCE platforms
For those who would like to play with the OS, understand this device runs Windows Mobile 5 for devices and NOT the Pocket PC OS. Pocket PC was a platform, just like SmartPhone was a platform. Although Microsoft changes the names to confuse the innocent, we're still talking about a few significant differences.
Consider Pocket PC (or WinMo or WinMo classic depending on the wind and Microsoft's mood), a superset of WinCE that adds a few other things to the core WinCE 5 platform. Search the web for posts by people who have managed to get PocketPC apps to run on their Handheld PC (HPC) such as the MobilePro 900c. The same kind of things would apply to the iPAQ 300. The differences are not all that significant if you know which DLLs need to be added.
In short, the iPAQ 300 Series is closer to a HPC than PocketPC OS-wise. The good news is, this version of Platform Builder can be purchased, whereas the one for WinMo is strictly guarded by Microsoft and released only to OEMs like HP and Dell.
The hardest thing you'll run across is that the digitizer drivers were not optimized for fine work, just for finger use. When you bypass the NavNGo "OS" to run the underlying WinCE OS and try to use a soft keyboard, for example, you'll see the jitter I'm talking about.
The iPAQ 300 Series could have been more but it was designed to compete with other GPS devices and that's really all. The hardware was really pretty great, but the device shipped with significant bugs that were addressed post-release.
If you want a PocketPC that also has GPS, the h5900 Series was a better choice. Not dual core CPU though
Anyone still running this fine device?
I've got mine running Igo8.3, works pretty good.
I'd be interested to hear if anyone is running Primo on it.
Also, anyone know where to get a TMC antenna for this unit?
Cheers
i still have a working one
unfortunately i think it have gone into battery shutdown to little charge in the battery for an extended period of time,
it will however come to life if i plug it into the car
i was thinking tonight it would be cool to hack droid onto it
Hi, all.
Lately I've been trying to build a linux driver to an accelerometer chipset, LIS331DL, embedded to a certain motherboard. System's BIOS has not been updated as to fit current gsensors linux drivers in (communities releases and so). We are positive that the device naturally inputs/outputs info through very specific I/O ports, namely the 0x6C and 0x68 ones. The problem is that I am able to access the device data through those ports in Windows,but not in Linux. Moreover, there's no real datasheet to help us through.
Here I have some few questions:
1) Is there, by any sort, a software kit which could possibly help us into diagnosing the motherboard as to provide more info about the device (LIS331DL accelerometer chip)?
2) Provided that there's already a windows driver that's fully functional and easily gets to send/retrieve data to/from the gsensor, under linux the management of those same I/O ports would end up into same results? In short, is there any difference between Linux and Windows I/O ports access (logical and addressing shifts perhaps)?
Any help would be much appreciated. Thanx in advance.
I managed to successfully get access to the gsensor device. Hope any other won't face the problems I had to, but just in case, I will now provide feedback to my own questions:
1) Is there, by any sort, a software kit which could possibly help us
into diagnosing the motherboard as to provide more info about the
device (LIS331DL accelerometer chip)?
Yes. A very good one called ECTOOL.
It probes the EC-RAM memory, which's quite a good start on taking notice of how bits are behaving and, later on, making decisions on that!
2) Provided that there's already a windows driver that's fully
functional and easily gets to send/retrieve data to/from the gsensor,
under linux, the management of those same I/O would end into same
results? In short, is there any difference between Linux and Windows I/
O ports access (logical and addressing shifts perhaps)?
Yes, same results. No difference. The gsensor got to output the same values (three-axial coordinates) as in windows. Hurray!
I've hit a wall in my quest to improve the Samsung Gravity Smart (SGH-T589). The kernel source that Samsung released for it doesn't quite work right (no wifi, broken touchscreen drivers). I'm trying to do something about it, but my test kernels hang before ADB is able to detect and connect to the phone.
The phone is powered by the Qualcomm MSM 7227 (S1 Snapdragon @800Mhz), which I understand is supposed to have a debug UART. How do I access it?
Reading the Google Nexus i9250 thread, I took a closer look at the system board. I've highlighted what I suspect is the JTAG header (see attachment).
However, I lack both the tools and expertise to determine if that is the header, and what the pinout is (most jtag pinouts I see pictures of online are in 2-column layout).
But, I might not need that. If I understand the discussion in the i9250 thread correctly, what I need is a combination of this miniUSB breakout kit, a 619Kohm resistor, and the FTDI Friend to use to connect the UART to my PC. I'm not quite sure where I go from there, but I expect that Windows will detect the serial port and give me something to connect to via SecureCRT or the like.
Is this correct? I'd kinda like to know before I spend any money on parts
Alternately, if anyone wants to take a crack at wiring up the JTAG port, I have a spare (broken) phone I can ship out. Screen doesn't work, but it still boots which will make it perfect for testing with!
Now, if you had bothered to SEARCH you'd have found THIS post in this thread with this picture!
I actually did come across that thread, however that particular post would not have come up in a search and you'll forgive me for missing a post in a 25-page thread However, I appreciate your help nonetheless.
Next question: I have 2 conflicting schematics for wiring an LPT JTAG cable. One shows TDO wired to pin 13, the other has it wired to pin 11. Which is correct? Or should I just try it both ways?
Try both. Shouldn't happen anything bad until you connect it to 12V or so.
I'm banging my head against a wall here, trying to figure things out but not finding clear instructions.
Is it true that, in order to perform JTAG, I need to use some kind of adapter (i.e. RiffBox), or can I connect it directly to the LPT port of my PC? If I can use my PC, what software do I use to read the debug output? I'm less concerned with recovering from hard brick than I am with getting the early debug output.
I'm thinking a hacked USB approach might be simpler and less expensive. My problem is lack of tools. If anyone else has made such a cable, could I buy it off you for a reasonable price?
Hello, i have a semi bricked Samsung Galaxy S5770 Mini/Pop/Next. It is a Qualcomm MSM7227 board. I have tryied the usb UART approach, but the only thing i can get from it is AST-POWERON, and it repeats (i think it bootloops)
I am trying to find UART on board, there are some little pads around the CPU.
Sent from my GT-I9003 using XDA
Ah my TDO is wired to pin 11. You don't need riffbox if you make a LPT JTAG adapter such as the Wiggler (low voltage variant 3.3V).
There are many softwares that can handle the wiggler, such as H-JTAG, openocd and urjtag.
I used "H-JTAG" and "NoICE for ARM" on windows. It's easy to setup H-JTAG for the wiggler and you don't have to do anything from the command line.
The msm7227 platform is multi-cpu (modem cpu, applications cpu).
With the JTAG port you saw, you can access the modem cpu, which is a ARM926ej-s.
Sent from my GT-I9003 using XDA
tanks for you
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Rebellos said:
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Click to expand...
Click to collapse
The issue here is that I'm trying to backport the MXT224 driver because the driver that's in the Samsung release is butchered beyond repair--the orientation is wrong, the resolution is wrong, the alignment is wrong.
My backported driver either fails to recognize the hardware (which is odd, because the init code uses the exact same kernel calls as the FUBAR driver for the I2C transfers), or locks up the boot process too early to get any useful debug output.
Anyway, I have the parts I need on order, all I need is for the orders to show up and a decent soldering iron and I should be in business.
Ah! The MXT224. I know this one pretty well, aswell as messup that Samsung does, configuring it in hundreds of different ways, with usually same result.
I think you don't need to port anything there. There's parameter table passed to MXT224 during init, that's probably only one thing you need to setup. You might want to reverse driver from some stock kernel, or adjust it experimentally, or simply request Samsung for proper parameter table.
There are many helping examples in various kernel arounds, sometimes it's called MXT224, and sometimes it's QT602240. This is in fact 100% same thing.
I'm not sure if any datasheet is publicily available. Though setup structures explaination should be enough, there it is:
https://bitbucket.org/gokhanmoral/s.../drivers/input/touchscreen/qt602240.h#cl-4848
For example flipping it would be changing "orient" byte in T9 structure. Probably all othere parameters you need to change are also in T9.
Thanks for the link. I managed to figure out the correct "orient" value by trial-and-error, but the screen alignment is screwed up. On a stock kernel, the top-left is 0,0. On a compiled kernel, top-left doesn't even register properly (none of the edges do). I've tried a few experimental things but nothing helped so far. I'll check out that link when I get home and hopefully find something useful.
You might also want to look into mach_aries.c and mach_herring.c files from I9000 and I9020 kernel sources. These shows pretty good how very similiar results can be done in pretty different set of T9 parameters.
I appreciate your input. I'm experimenting with different T9 values. I found a partial datasheet that shed a little light into some of the parameters.
I've managed to strip out the "piggy" (uncompressed vmlinux) from the stock kernel. Is there anything I can do with that to somehow find out what T9 parameters are used by the actual stock kernel (as opposed to what Samsung released)? I did some searching for kernel disassembly but didn't find anything that looked promising.
Can you upload it somewhere? I'd take a look into it.
Sure thing. I'll upload it tonight when I get home. Thanks!
Here it is, gzipped:
http://min.us/mrUKEtr7W
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Rebellos said:
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Click to expand...
Click to collapse
It's not on github at the moment. I'm just working from the kernel sources posted on opensource.samsung.com for the SGH-T589. I'll start an account tonight when I get home and upload what I have. I'll get the map file you're after uploaded too.