Would anyone be interested in helping me rip apart a radio image?
I've googled around looking for any instances of extracting the radio firmware from radio.img and have come up with nothing.
More information for those who know less about the baseband:
What is it?
AMSS is the name Qualcomm gives the software that runs the phones modem. When the modem software is compiled, it is encrypted and stored in a file called amss.bin. There is a small entry point in amss.bin which decrypts the image into the phones memory during boot and then executes it.
What does it do?
Its job is to find, connect, and decode cell phone signals and convert them to usable data. In most older cell phones the phones operating system was a part of this as well, but with android the modem runs along side android (Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?)
This software reads settings that were set either by the phone itself (2G/3G or 4G data, PRL on cdma, APN settings, and other radio related things.) or by the carrier/manufacturer (NVRAM) and changes its behavior accordingly.
It then accepts commands and gives responses to another piece of software (In this case android) which does something useful with the phones modem. (Dials a phone number, connects to a data service, etc) and lets the software know when events happen (Text messages, incoming calls, etc)
The modem firmware (amss.bin) is inside radio.img for the nexus s 4g, This much should be blatantly obvious. However, the phones EFS filesystem (FAT12 IIRC) is also located here as well. radio.img may be encrypted or compressed, (Why it takes so long to flash a radio update to the nexus s 4g)
Why?
With access to amss.bin it can be decrypted and disassembled to show the phones true inner workings, and I may be able to develop a solution to the absolutely terrible data speeds for the nexus s 4g (No matter where I go, with 3 different D720's now, I get 56k dialup speeds and once in a great while it will go up to 3g, unless I'm sitting right next to my airave.) or at least have an insight as to why this phones data is so slow.
How do you know all of this?
I originally tried to get android running on a Samsung Eternity, I was able to decode the first part of AMSS.BIN but then realized that writing the radio interface layer for android was going to be a real challenge, not to mention that the phones hardware was barely capable of running 1.5 (And by barely I mean not really capable at all). But I learned an awful lot about the internals of Qualcomm phones along the way, and even wrote a small utility to edit the boot images and EFS filesystem (In this case, EFS also held the OS itself, not just the radio stuff)
Very good read, and useful info. Have you tried mounting the radio.img in Linux, yet? I don't know exactly how to do it, but you should be able to. I run Linux dual booted with Windows, and have mounted the system.img no problem. I tried with the recovery.img, but no luck. I think you have to mount it as another filesystem.
I doubt that radio.img would mount, Android is based on linux and uses linux filesystems. The radio is different, its more the same class as a bootloader (or rather, somewhere between). It does have a filesystem in that radio.img, but its likely encrypted.
Mar 15 17:45:28 localhost kernel: EXT3-fs (loop0): error: can't find ext3 filesystem on dev loop0. Mar 15 17:45:28 localhost kernel: EXT2-fs (loop0): error: can't find an ext2 filesystem on dev loop0. Mar 15 17:45:28 localhost kernel: EXT4-fs (loop0): VFS: Can't find ext4 filesystem Mar 15 17:45:28 localhost kernel: SQUASHFS error: Can't find a SQUASHFS superblock on loop0 Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): bogus number of reserved sectors Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): Can't find a valid FAT filesystem Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): bogus number of reserved sectors Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): Can't find a valid FAT filesystem Mar 15 17:45:28 localhost kernel: ISOFS: Unable to identify CD-ROM format. Mar 15 17:45:28 localhost kernel: hfs: unable to find HFS+ superblock Mar 15 17:45:28 localhost kernel: hfs: can't find a HFS filesystem on dev loop0. Mar 15 17:45:28 localhost kernel: ufs was compiled with read-only support, can't be mounted as read-write Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_load_vrs: No VRS found Mar 15 17:45:28 localhost kernel: UDF-fs: Rescanning with blocksize 2048 Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_load_vrs: No VRS found Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_fill_super: No partition found (1)
Unfortunately a lot of your work is out of my league. However, Deep Idle (and the Sleep state, and even the idle state) all have proven benefits in various ways. Deep Idle shuts off the processor for, generally (for music), 19ms out of 20ms if i remember correctly. Idle would clock the processor at zero in much the same way, however i don't understand exactly what benefit (or process) there is to it aside from effectively minimizing power consumption (estimating CPU power consumption relies on the frequency, turning this to 0 in a perfect system would eliminate power use with the processor "on".. in theory). Either way, even Idle has shown power savings - while idle is used there is a far lower power draw. Without it, the results are much more believable and expected for the frequency, showing that it saves power by clocking the cpu to 0.
Further, i havn't tried this myself, but isn't Android perfectly capable to run without a radio at all? Because of this i highly doubt the radio is a hypervisor of any sort aside from anything radio-specific. I'm fairly certain the Radio acts more like a WoL chip, invoking the rest of the system as soon as it is triggered. Some reading material, maybe those two links add some insight too.
There is evidence of my argument here. Maybe you have confused Deep Idle and Sleep, but either way the two have proven benefits.
One thing to note, all of this is done on GSM Nexus S'. It could very well be different for the 4G CDMA radio, and even for the i9020A variant (i have the i9023 and think bedalus has a i9020T - ONLY difference is the screen). I have no experience with either the i9020A or 4G so it's all hearsay if it comes from me.
Quite the opposite, I was saying that because android and the RTOS (Real time os, for the radio) run under a "Microvisor" which is much like XEN, Android can halt the CPU all it wants, but the underlying OS that is virtualizing android wont really allow it. There are others that say the opposite of deep idle. I myself have noticed no benefit from it.
This is the results of a real study about battery life, specifically stating that deep idle does nothing, and indeed, as I noted above, I myself have also noticed no benefit. (But it SHOULD give a MAJOR benefit, which is why its so puzzling)
You can read it here.
I'll go into a bit more detail to clarify:
The phones basic startup process is:
Hardcoded Cryptographically secure bootloader -> NICTOKL4 (OS Hypervisor, or as OKL calls it, Microvisor)
NICTOKL4 Starts up the RTOS, and FASTBOOT
Fastboot then loads either the battery charging screen, Android, or Recovery (Or boots into fastboot mode) depending on the state of the phone.
(I could be wrong about what launches what, and may be missing, but I know that RTOS and Androids boot code are started at the same time by the microvisor)
RTOS Is running at all times after the phone is first powered on after having the battery removed, However it will disconnect from the cell network and sleep if told to, or if it has nothing to talk to. (Airplane mode and "off")
This is very similar to say, Linode. Where BIOS/EFI Loads an OS (The hypervisor Dom-0) and that OS Launches multiple guest OS's (Dom-U)
NICTOKL4 Is the only part of the phone that has true access to the hardware, and marshalls requests (usually blocking requests) to modify other OS Memory space, or access hardware.
The radio itself is actually just another guest OS, running under NICTOKL4. Android is entirely capable of running without a radio, but not on a phone without replacing the radio with android boot code.
Back to Deep Idle and Sleep. Sleep can be done and should provide benefit, because the microvisor can sleep too. Guest Sleeps, Microvisor sees all guests sleeping, so it sleeps too.
However, the radio software absolutely requires realtime communication with the hardware and network, or else synchronization would be lost. So halting the CPU (As deep idle does) cannot be allowed by the radio, and therefore cannot be allowed by the microvisor.
The information about the microvisor is fact by the way, I've found it in the radio.img for both my phone, and the i90xx radios.
I'm not trying to outright reject what you're saying Harbb, I just feel like I'm having trouble translating what I know into words others can understand.
You can learn more about the microvisor and its capabilities here
Good thing my phones smarter than me then, but it would've made a damn pretty paperweight
By the way, my suspicions seem to be correct, The Nexus S does have an integrated Baseband Processor, it can be found in step 10 of that page. Courtesy of iFixIt, of course.
After a quick look i couldn't find a radio for the Tegra 3s but i'm sure they'll pop up soon in the HTC One forums soon, even though it may not mean much now.
Thats not a processor, Its an antenna selector and noise filter. SPI is too slow to handle GSM/UMTS/CDMA traffic.
Its purpose is to select the frequency band, detect if there is a signal, and select an antenna (Low gain, hi gain, etc) and connect the antenna to something else with the correct frequency. Thats all it really does.
You can see for yourself in the functional diagram located in this PDF: http://www.skyworksinc.com/uploads/d...ts/201206b.pdf
The radio of the Tegra would me most interesting to me, and but certainly not relevant to this project.
EDIT: Apologies, I missed the Infineon chip. I'll have to see if i can find a data sheet for it to see what it can do. I'll get back to you as soon as I know more.
EDIT2:
I found this PCI-Express card that uses the same baseband processor, The PDF has a pinout of the same baseband chip.
http://module.amod.com.tw/files/Prod...2215113150.pdf
It seems to me that this does most of the protocol/baseband processing, and makes me curious as to why they multiplex the application CPU At all in this case? This makes no sense to me. I mean, I know they do, and I know AMSS.BIN is supposed to run the radio, but it seems like it may be more of a driver between RIL and that chip in this case. Question is, why not write the RIL to use the chip directly using GPIO pins on the CPU? Puzzling...
More questions than answers. But in this case, WoL/WoR functionality is possible at least on GSM Models. Although it's more likely a hardware event (Interrupt) that would wake the processor anyway. Perhaps the seperate modem software is to implement extra AT commands for the modem, and hide the interrupts from Android's RIL? I wonder if we can send random AT Commands to that chip... I'll see what I can figure out with my phone.
0 件のコメント:
コメントを投稿