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.
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!
Well as far as my point of view as electronics engineer understanding goes.. im bringing you the following scheme.
In conclussion what Samsung told to Entrophy in my opinion was bullshyt because this .. the flash memory chip allows 2 erase methods
1. the regular(slow method) wich works with the CAP_ERASE disabled in the kernel
2. the fast method wich happen to cause damage in some memory sectors.
To make it simple the procedure should be something like this:
User/process performs a wipe (no matter the recovery cwm/stock/from the OS loaded) so
if wipe instruction then
cap_erase (generates a I2C frame to perform a "fast format" serial binary string)
else (if cap_erase dissabled)
slow erase (generates a I2C frame to perform a slow format serial binary string)
end if
As it shows no matter what its loaded in the OS(root or not, cwm or not, stock or not) and no matter what the kernel its the I2C frame needed to perform a format in the flash memory chip gotta be the same no matter what.. it DOES NOT depends on OS/KERNEL/RECOVERY, ITS HARDWARE LEVEL AND PURE BINARY STRINGS(UNIQUES)
Wich i beleave its either if GB kernels has the cap_erase enabled the process itself does not calls the fast format instruction...
As result ICS full stock or not WILL brick because the flash memory chip used by samsung in the Note cant handle the fast format command.. and that said there are 2 ways of making a safe kernel, dissabling cap_erase or not calling it at all in the wipe process..
Samsung wont admit this befcause they gotta replace every Note in the streets(remember Toyota calling all the COROLLAS owners to replace for free the breaking system).. and instead they said all that Bullshyt to entrophy so they wont assume the cost of it.
Just my 2 cents about the issue
it means our note is not fixable from the emmc bug
Sent from my GT-N7000 using xda premium
Don't worry op, some of the ignoramuses amongst us will still believe that Samsung's stock software is safe on ICS. lol.
Blatant blathering won't suffice. Cite some credible information.
Sent from my GT-N7000 using xda premium
abhijit038 said:
Blatant blathering won't suffice. Cite some credible information.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Here comes one......
I actually think that's a good explanation. Understanding a bit of software programming, it makes sense. But of course, I take caution as I don't know software development that much and fear I might do something wrong.....
Sent from my GT-N7000 using Tapatalk 2
Lets just be grateful that we live in a technological age and at least have a Note
As a fellow electronics engineer let me tell you that you are wrong and seeing it way too simple.
The I²C bus, invented in the late 80's, by Philips, is a serial highspeed bus.
You could see it as the grandfather of USB.
So why in heavens name would the 2 binary strings have to be exact the same, and therefore not capable of causing different actions on the memory chip ??
Aren't you able to send multiple and different commands over your usb port ????
Now all the coding and action is done INSIDE the Emmc chip by it's internal algorithms, stored inside it's own firmware. The I²C just tells it 'do your job',
by calling the erase function either in the fast or the slow way.
And the I²C serial string is issued by the kernel driver for the serial bus.
So it is definitely Kernel related..
In GB Google NEVER issued a Format command when wiping, it just cleared the File allocation tables
abhijit038 said:
Blatant blathering won't suffice. Cite some credible information.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Don't need to cite anything.. I'm a electronics engineer with 10 years experience not a random rookie
friedje said:
As a fellow electronics engineer let me tell you that you are wrong and seeing it way too simple.
The I²C bus, invented in the late 80's, by Philips, is a serial highspeed bus.
You could see it as the grandfather of USB.
So why in heavens name would the 2 binary strings have to be exact the same, and therefore not capable of causing different actions on the memory chip ??
Aren't you able to send multiple and different commands over your usb port ????
Now all the coding and action is done INSIDE the Emmc chip by it's internal algorithms, stored inside it's own firmware. The I²C just tells it 'do your job',
by calling the erase function either in the fast or the slow way.
And the I²C serial string is issued by the kernel driver for the serial bus.
So it is definitely Kernel related..
In GB Google NEVER issued a Format command when wiping, it just cleared the File allocation tables
Click to expand...
Click to collapse
I think you don't get the whole picture.. In the main board the processor and periferics communicate each other via I2C data bus they are connected with Cooper vias serialy and the protocol they use to "talk" its I2C and that's has nothing to do with kernel or usb
We got processor architecture Wich means the processor share a serial data bus with all the periferics.. The memory its not embedded as it is not a microcontroller
The kernel tells the processor to send a wipe command to the flash memory chip and kernel CAN NOT talk directly to the chip.. Assambler compilatior translates kernel languages into pure binaries that can be handled by the processor..
Sent from my GT-N7000 using xda premium
msedek said:
Don't need to cite anything.. I'm a electronics engineer with 10 years experience not a random rookie
I think you don't get the whole picture.. In the main board the processor and periferics communicate each other via I2C data bus they are connected with Cooper vias serialy and the protocol they use to "talk" its I2C and that's has nothing to do with kernel or usb
We got processor architecture Wich means the processor share a serial data bus with all the periferics.. The memory its not embedded as it is not a microcontroller
The kernel tells the processor to send a wipe command to the flash memory chip and kernel CAN NOT talk directly to the chip.. Assambler compilatior translates kernel languages into pure binaries that can be handled by the processor..
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Read up a bit : http://www.samsung.com/global/business/semiconductor/product/flash-emmc/overview
it is not just a memory chip, it has it's controller hardware built in controlled by it's own Firmware.
Now let me tell you i engineered microcontroller boards communicating over I²C when you were still in diapers probably. Whether or not the serial bus uses copper , wood , or pigeons is of no interrest.
The Kernel tells the processor to issue a binary string over the I²C to the memory controller telling it what to do. without the Kernel the processor will never tell the I²C anything. Not even that it loves a juicy steak...
Taking your opening post in a nutshell you are saying :
No matter whatever OS, Kernel, Recovery or what is loaded, if you send a fast format command to the Emmc Chip, in some cases it will brick..
Samsung has no way of fixing it, and so they say it is a marginal problem that doesn't need a callback, we will just replace the faulty motherboards.
You are perfectly right, but we already knew that thanks to entropys involvement
friedje said:
Read up a bit : http://www.samsung.com/global/business/semiconductor/product/flash-emmc/overview
it is not just a memory chip, it has it's controller hardware built in controlled by it's own Firmware.
Now let me tell you i engineered microcontroller boards communicating over I²C when you were still in diapers probably. Whether or not the serial bus uses copper , wood , or pigeons is of no interrest.
The Kernel tells the processor to issue a binary string over the I²C to the memory controller telling it what to do. without the Kernel the processor will never tell the I²C anything. Not even that it loves a juicy steak...
Click to expand...
Click to collapse
You are not saying anything new.. I already stated that.. The kernel its who sends the command to the hardware, memory its slave either if it has a embedded processor with its own firmware or not.. The processor it's who gets the message from the kernel and send the command..
The flash memory chip(with its super ultra mega embedded procesor and own firmware) can perform at least (that we know of) 2 kinds of erases cap_erase(faster) and regular(slower) there are differents commands for both.. The kernel as I said it's who sends the type of commands and I already said that the chip CAN NOT handle the fast erase.. So I said the only way I see to get safe its disabling the cap erase command from kernel wich developers already did but the problem it's Samsung won't do it as they won't accept the fact because it implies a lot of money
Sent from my GT-N7000 using xda premium
friedje said:
Taking your opening post in a nutshell you are saying :
No matter whatever OS, Kernel, Recovery or what is loaded, if you send a fast format command to the Emmc Chip, in some cases it will brick..
Samsung has no way of fixing it, and so they say it is a marginal problem that doesn't need a callback, we will just replace the faulty motherboards.
You are perfectly right, but we already knew that thanks to entropys involvement
Click to expand...
Click to collapse
I know but I want to put it in graphical and friendly way so everyone can see what really happens and how it works
Sent from my GT-N7000 using xda premium
Amen
I'm also an EE with quite a bit of experience (10 years since college graduation too), and I can tell that you have zero experience with eMMC since you're talking about I2C. I admit I didn't have much eMMC experience until a few months ago, but since you're trying to talk about eMMC and spouting BS about I2C, it's pretty obvious that you are making random speculation with no specific knowledge of the issue.
NOWHERE in the eMMC interface is I2C used. Some MMC/SD devices can use a basic "fallback" mode where they present a SPI interface, but I believe many eMMC chips don't support this, and I can tell you without a doubt, this is not used in any way by our phones.
I suggest that you read the JEDEC eMMC standard - see http://www.jedec.org/standards-documents/results/taxonomy:2940 . Specifically read the sections governing erase commands.
Secure erase is known to trigger internal bugs in the wear leveller of the chip itself. It is suspected due to reports of damage in stock recovery that non-secure erase/trim can also do damage, however Samsung is certain it won't. I don't think we'll ever know for sure until Samsung releases the update they're planning which will block secure erase but permit non-secure erase.
And there is no "regular slow method" of erase... When MMC_CAP_ERASE is not used, the device simply never erases cells unless it must do so in order to complete a write operation. In this case, the complete system behaves similar to an old-school magnetic disk - if you delete a file or format a partition, the references to content are removed but the content itself remains. On magnetic media, this isn't a problem for performance as it takes the same time to rewrite a previously written sector as one that is blank. With flash, memory can only be written one block at a time - if you want to modify just part of a block, you must read it, modify it, erase the underlying memory, and rewrite the modified data. Most modern flash chips have an internal wear leveler such that a logical block is mapped to different physical blocks (so that if one logical location is written to over and over again, it will get written to multiple physical locations, so one particular block doesn't have too many write cycles.) So the memory is just not erased - yes, having the media full leads to slow write performance over time, but there is no "slow erase" involved.
In kernels where MMC_CAP_ERASE is disabled, the flash is treated in the same manner as legacy magnetic media (don't explicitly erase the chip when deleting/formatting) - this is not optimal as it eventually leads to slower write performance (but the performance degradation will "level off" once all cells on the flash memory are used), but it's also perfectly safe.
BTW, the difference between secure erase and nonsecure erase is whether the erase command deletes ALL copies of the data (see above at the wear leveller - it is possible that when writing to a block, the underlying wear leveller will read one physical block, modify it per the write command, then write it to a free block elsewhere.) ior just the current copy.
Entropy512 said:
I'm also an EE with quite a bit of experience (10 years since college graduation too), and I can tell that you have zero experience with eMMC since you're talking about I2C.
NOWHERE in the eMMC interface is I2C used. Some MMC/SD devices can use a basic "fallback" mode where they present a SPI interface, but I believe many eMMC chips don't support this, and I can tell you without a doubt, this is not used in any way by our phones.
I suggest that you read the JEDEC eMMC standard - see http://www.jedec.org/standards-documents/results/taxonomy:2940 . Specifically read the sections governing erase commands.
Secure erase is known to trigger internal bugs in the wear leveller of the chip itself. It is suspected due to reports of damage in stock recovery that non-secure erase/trim can also do damage, however Samsung is certain it won't. I don't think we'll ever know for sure until Samsung releases the update they're planning which will block secure erase but permit non-secure erase.
And there is no "regular slow method" of erase... When MMC_CAP_ERASE is not used, the device simply never erases cells unless it must do so in order to complete a write operation. In this case, the complete system behaves similar to an old-school magnetic disk - if you delete a file or format a partition, the references to content are removed but the content itself remains. On magnetic media, this isn't a problem for performance as it takes the same time to rewrite a previously written sector as one that is blank. With flash, memory can only be written one block at a time - if you want to modify just part of a block, you must read it, modify it, erase the underlying memory, and rewrite the modified data. Most modern flash chips have an internal wear leveler such that a logical block is mapped to different physical blocks (so that if one logical location is written to over and over again, it will get written to multiple physical locations, so one particular block doesn't have too many write cycles.) So the memory is just not erased - yes, having the media full leads to slow write performance over time, but there is no "slow erase" involved.
In kernels where MMC_CAP_ERASE is disabled, the flash is treated in the same manner as legacy magnetic media (don't explicitly erase the chip when deleting/formatting) - this is not optimal as it eventually leads to slower write performance (but the performance degradation will "level off" once all cells on the flash memory are used), but it's also perfectly safe.
Click to expand...
Click to collapse
Never mentioned I2C its used inside the chip.. It's a Standart to communicate /send commands between processor and peripherals.. I'd be kind from you all to completely read the whole post before spitting your usual You ARE Wrong.. As I said I was making a picture for average user and the processor DOES Indeed talk to every peripherals connected in the bus via I2C unless someone invented a better serial serial hardware protocol to communicate 2 hardware pieces... Gosh
And once again I'm trying to put things simple.. No matter if I can understand what your saying in the end it's a hardware problem and most people can picture what's wrong and General how's everything conected
By the way being polite its a virtue not everyone have.. And being humble makes us better humans I'm not in anyways being rude to anyone here but seems like you can not stop yourself from being such a horrendous person
Sent from my GT-N7000 using xda premium
msedek said:
Never mentioned I2C its used inside the chip.. It's a Standart to communicate /send commands between processor and peripherals.. I'd be kind from you all to completely read the whole post before spitting your usual You ARE Wrong.. As I said I was making a picture for average user and the processor DOES Indeed talk to every peripherals connected in the bus via I2C unless someone invented a better serial serial hardware protocol to communicate 2 hardware pieces... Gosh
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I2C used for every peripheral on the CPU? You've got to be kidding me, it's suited only to low-bandwidth peripherals like sensors. Read the datasheet of any modern mobile CPU - there are a pile of interfaces including, but not limited to, USB Host, MIPI DSI, MIPI CSI, UARTs, and SPI. I2C is used in our devices, but not for ANYTHING related to storage interfaces in any way, shape, or form.
It's pretty clear you're lying about being an EE with 10 years of experience if you think a 400 kilobit/second bus like I2C is capable of supporting storage that typically transfers tens of megabytes/second of data. People who misrepresent themselves like you clearly are do not deserve politeness.
eMMC/MMC/SD uses a dedicated interface designed specifically for storage devices like this. Again - read the JEDEC standard, since it explicitly describes this interface. It describes MMC command 38 (used for all forms of erase) in detail, and how it is supposed to work and be used.
The problem, at its simplest, boils down to our chips not being JEDEC compliant and not properly handling secure erase/trim properly if they are treated as a JEDEC compliant chip. Not only do they implement the command improperly, they suffer permanent damage as a result. This is not new information, and has been known for over two months.
msedek said:
Never mentioned I2C its used inside the chip.. It's a Standart to communicate /send commands between processor and peripherals.. I'd be kind from you all to completely read the whole post before spitting your usual You ARE Wrong.. As I said I was making a picture for average user and the processor DOES Indeed talk to every peripherals connected in the bus via I2C unless someone invented a better serial serial hardware protocol to communicate 2 hardware pieces... Gosh
And once again I'm trying to put things simple.. No matter if I can understand what your saying in the end it's a hardware problem and most people can picture what's wrong and General how's everything conected
By the way being polite its a virtue not everyone have.. And being humble makes us better humans I'm not in anyways being rude to anyone here but seems like you can not stop yourself from being such a horrendous person
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
If you look at the g-note schematics, the memory is connected to the cpu using a normal parallel data and address bus, they are not communicating over I²C.
http://img84.imageshack.us/img84/6856/gnotemem.jpg
(c) Samsung Electronics
friedje said:
If you look at the g-note schematics, the memory is connected to the cpu using a normal parallel data and address bus, they are not communicating over I²C.
Click to expand...
Click to collapse
RAM is connected in this way I think, the flash memory is connected via an MMC/SD interface implemented by a dedicated storage controller in the CPU. (One of at least 3-4 such interfaces - One for internal eMMC, one for external SD, and one SDIO interface for wifi)
Msedek... I think you should leave it there bud... Your picking a fight with the wrong dude. Entropy512 clearly knows what he's talking about... No offense but your making yourself look adolescent
Sent from my GT-N7000 using xda app-developers app
Entropy512 said:
I2C used for every peripheral on the CPU? You've got to be kidding me, it's suited only to low-bandwidth peripherals like sensors. Read the datasheet of any modern mobile CPU - there are a pile of interfaces including, but not limited to, USB Host, MIPI DSI, MIPI CSI, UARTs, and SPI. I2C is used in our devices, but not for ANYTHING related to storage interfaces in any way, shape, or form.
It's pretty clear you're lying about being an EE with 10 years of experience if you think a 400 kilobit/second bus like I2C is capable of supporting storage that typically transfers tens of megabytes/second of data. People who misrepresent themselves like you clearly are do not deserve politeness.
eMMC/MMC/SD uses a dedicated interface designed specifically for storage devices like this. Again - read the JEDEC standard, since it explicitly describes this interface. It describes MMC command 38 (used for all forms of erase) in detail, and how it is supposed to work and be used.
The problem, at its simplest, boils down to our chips not being JEDEC compliant and not properly handling secure erase/trim properly if they are treated as a JEDEC compliant chip. Not only do they implement the command improperly, they suffer permanent damage as a result. This is not new information, and has been known for over two months.
Click to expand...
Click to collapse
I can quote wiki (parts you didnt) too..
Come on dude.. this its not a knowledge war.. you know more things than me in certain fields and i know more than you in others.. any day ill swap everything i know with everything i ignore.. thi its about making things simple for average user
I ² C bus is a serial communications. Its name comes from the Inter-Integrated Circuit (Inter-Integrated Circuit). The 1.0 version dates from 1992 and version 2.1 in 2000, its designer is Philips. Speed is of 100Kbits per second in standard mode, it also allows speeds of 3.4 Mbit / s. A bus is widely used in industry, mainly to communicate microntroladores and peripherals in embedded (Embedded Systems) and generalizing more integrated circuits to communicate with each other that normally reside in the same printed circuit
Hi! First time poster, I think.
So I have this... Probably tedious idea. But I've read up about the hardware and, while I haven't worked extensively with arm assembly before I have on other systems. The intel 8051, gameboy and x86. Oh. And also I really, really like to learn about low level stuff.
I am aware of the unpracticality of this setup, but I'd like to have something to tinker around with, see if I can do something interesting with it. Would be cool to se how good a NES, SNES or N64 emulator could get.
Anyway, I have a few questions. Any help/answers would be appreciated:
1. After some light research it seems like it has a VideoCore IV gpu, VC 4 seem to have support for resolutions up to 1080p, and have a limited instruction set but it's still enough that some applications (in theory) could run on the cores of this GPU. Is this correct? Also does it have 4 cores?
2. How can I extract specific parts of the hardware drivers from the stock rom? In this case I'd like... you know, most of 'em that are specific to the hardware, at least as a reference point. So screen, touch, bluetooth, usb controller, buttons, wifi, speakers, thermal, gyro, sdcard interface, you get the picture.
3. How is cpu and gpu clock speed controlled by the kernel normaly? How is it capped/overclocked?
4. How does a general micro usb type b to hdmi adapter connect the wires? What is the theoretical highest resolution that would be stramable through such a adapter?
5. How exactly is the hdmi protocol defined? What signals goes where at what time?
Edit: The resolution depends on the version of the adapter, with support for up to 1080p. So if anything is the bottleneck for this part it'll be that the cpu doesn't have enough time processing the writes. Also depending on the version it's either "frame" dependant or "packet" dependant, if I understand correctly packets are used to signal when certain bits of information get's transmitted, thus making the window for when the signal can arrive wider.