Has anyone been able to extract amss.bin from radio.img? Or the efs filesystem (Not the same as /efs btw.)?
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)
Great read. I have no experience in this, nor any worthwhile software experience so I doubt i can help you, but if you think I can just let me know. I havn't experienced any particular issues on my GSM Nexus though. It's not like I get to use data very often anyway considering how little data i have and the state of Vodas current data network.
Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?
Answer: On phones like the Nexus S where the "Sleep" state (and even "Deep Idle" state) shuts off the CPU entirely, there must be a seperate low-power processor just for decoding and sorting through cell signals. This, in turn, will wake up the main CPU when something happens (call, text message, push notification, etc). That should clear a little up for you.
If I had skills required I would gladly help you, But I don't. It seems like you have done your homework, and done this before, so what exactly do you need help with? Re-writing it?
By the way that was a very interesting read!
Sent from my Nexus S 4G using XDA App
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.
mabry said:
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.
Click to expand...
Click to collapse
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.
Code:
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)
NS4G.John said:
If I had skills required I would gladly help you, But I don't. It seems like you have done your homework, and done this before, so what exactly do you need help with? Re-writing it?
By the way that was a very interesting read!
Sent from my Nexus S 4G using XDA App
Click to expand...
Click to collapse
I need help getting amss.bin out of radio.img. I know how to deal with amss.bin once I have it, but I cannot find it in radio.img by signature (And indeed it would be hard to find anyway, due to how many signatures there are, and the length of the file is unknown.)
I mean, to clarify, I know I'm looking right at it, and I know when I'm in the middle of it. but I don't get where it starts and ends. And that is the important part.
A string dump of radio.img makes it appear as though the radio is un-encrypted. I could be wrong.
Stuff that makes me think its unencrypted:
Code:
desktop crespo4g # strings radio.img | grep amss
amss_start = 0x%x, amss_size = 0x%x
Code:
desktop crespo4g # strings radio.img | grep AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
AMSS
AMSS
AMSS_BOOT
AMSS_FILL_PAD_1
AMSS_EMPTY_PAD_1
AMSS_ZI_REGION
AMSS_EMPTY_PAD_2
AMSS_AUTOGENERATED_CODE_1
AMSS_AUTOGENERATED_CODE_2
AMSS_MODEM_CODE_1
AMSS_FILL_PAD_2
AMSS_MODEM_DATA_2
AMSS_MODEM_DATA_1
AMSS_APP_RAM
AMSS_FILL_PAD_3
AMSS_INTERNAL_BOOT_RAM_1
AMSS_INTERNAL_BOOT_RAM_2
AMSS_FILL_PAD_4
AMSS_MAIN_APP_2
AMSS_MAIN_APP_3
AMSS_MAIN_APP_4
AMSS_MAIN_APP_4_REDBEND
AMSS_FILL_PAD_5
AMSS_MAIN_APP_DATA_1
AMSS_FILL_PAD_6
AMSS_SHARED_RAM
AMSS_EMPTY_PAD_3
AMSS_UNINIT_RAM
AMSS_EMPTY_PAD_4
Harbb said:
Great read. I have no experience in this, nor any worthwhile software experience so I doubt i can help you, but if you think I can just let me know. I havn't experienced any particular issues on my GSM Nexus though. It's not like I get to use data very often anyway considering how little data i have and the state of Vodas current data network.
Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?
Answer: On phones like the Nexus S where the "Sleep" state (and even "Deep Idle" state) shuts off the CPU entirely, there must be a seperate low-power processor just for decoding and sorting through cell signals. This, in turn, will wake up the main CPU when something happens (call, text message, push notification, etc). That should clear a little up for you.
Click to expand...
Click to collapse
If you look at things like XEN, it would be entirely possible that the host os (radio, in this case) is trapping and preventing CPU halting. As a matter of fact I believe that the evidence points in the opposite direction due to the fact that "Deep Idle" produces no measurable battery savings. Its entirely possible, and perhaps likely, that the radio acts as a sort of, hypervisor, that controls Android's access to the underlying hardware. I don't know if this type of virtualization is available on ARM though. It really could go either way. And even in a halt state, interrupts are usually still possible, So the radio may be running inside of a timer even.
The crespo/d720/Nexus S 4G/Whatever else you'd like to call it, has severe issues regarding data speeds. Sprint pretends the issue doesn't exist, Samsung pretends the issues doesn't exist, Google is mostly powerless because its a radio issue that Sprint and Samsung are responsible for fixing. Hacking this radio may be the solution, but I've gotta get amss.bin out of radio.img. Until I do, there is nothing I can do either.
Quick update
Pouring over radio.img I came across the following string
Code:
NICTOKL4 - (provider: Open Kernel Labs) built on May 19 2009 00:21:02 using
gcc version 3.4.4.
What does this mean?
It mean's that AMSS Runs on the same CPU as android, and that it runs as a Hypervisor (Microvisor as Open Kernel Labs calls it). It has control over what the android kernel has access to. This is pure speculation, but I would guess this is why Deep Idle doesn't provide any real tangible benefit when it really should.
Thanks for the informative read. D
plaguethenet said:
If you look at things like XEN, it would be entirely possible that the host os (radio, in this case) is trapping and preventing CPU halting. As a matter of fact I believe that the evidence points in the opposite direction due to the fact that "Deep Idle" produces no measurable battery savings. Its entirely possible, and perhaps likely, that the radio acts as a sort of, hypervisor, that controls Android's access to the underlying hardware. I don't know if this type of virtualization is available on ARM though. It really could go either way. And even in a halt state, interrupts are usually still possible, So the radio may be running inside of a timer even.
The crespo/d720/Nexus S 4G/Whatever else you'd like to call it, has severe issues regarding data speeds. Sprint pretends the issue doesn't exist, Samsung pretends the issues doesn't exist, Google is mostly powerless because its a radio issue that Sprint and Samsung are responsible for fixing. Hacking this radio may be the solution, but I've gotta get amss.bin out of radio.img. Until I do, there is nothing I can do either.
Click to expand...
Click to collapse
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.
Harbb said:
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.
Click to expand...
Click to collapse
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
plaguethenet said:
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.
Click to expand...
Click to collapse
That battery life Portal post was a preliminary finding, which now is FOR deep idle, not against it. The thread that is linked to in it actually takes you to the same thread that i posted above proving my argument on deep idle. Go through the first 5 or so posts in the thread it links to, you'll find my own findings and bedalus' findings, and now even nathanson666's findings which is basically a deep idle experiment under a 1kHz ampmeter which provides proof to the millisecond level (which is where deep idle works). The larger problem with deep idle is that there is very little besides music that can truly benefit from deep idle, aside from it helping the surrounding OS very slightly while awake with the screen off.
Also, do you mind clarifying the bolded part a bit more?
plaguethenet said:
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
Click to expand...
Click to collapse
I am doing much the same, only friendly discussion here I don't have time at the moment but i'll get to reading some more on this soon.
Anyway. I can guarantee that the main CPU can entirely halt and effectively freeze EVERYTHING in the phone so long as the screen is off and nothing is keeping it awake, and likely the exact same thing happens with Deep Idle but while processing something (this runs on the race-to-idle principle, even if slightly lower clocks may be more efficient here - hurry the hell up so i can shut down the CPU). If such a thing can happen, how can you conclude that the CPU must stay awake? This is why i've narrowed it down to another chip that must be aiding the radio.
I'd write more but i must get going. Keen to see where this takes us.
Harbb said:
That battery life Portal post was a preliminary finding, which now is FOR deep idle, not against it. The thread that is linked to in it actually takes you to the same thread that i posted above proving my argument on deep idle. Go through the first 5 or so posts in the thread it links to, you'll find my own findings and bedalus' findings, and now even nathanson666's findings which is basically a deep idle experiment under a 1kHz ampmeter which provides proof to the millisecond level (which is where deep idle works). The larger problem with deep idle is that there is very little besides music that can truly benefit from deep idle, aside from it helping the surrounding OS very slightly while awake with the screen off.
Also, do you mind clarifying the bolded part a bit more?
Click to expand...
Click to collapse
The radio is a real time operating system. I'd imagine that halting the CPU and bringing it back up is too costly for the radio, and therefore would be prevented by the radio. As far as WoL like functionality, I don't see any chip on the board that could provide that for the radio (or indeed anything for that matter). The only thing that has any radio capability is the main Application Processor, which has to be shared.
Harbb said:
I am doing much the same, only friendly discussion here I don't have time at the moment but i'll get to reading some more on this soon.
Click to expand...
Click to collapse
I get a bit excited and tend to get very technical and often miss things or seem like I'm trying to argue when i'm not. I just wanted to clarify that it wasn't intended as such.
Harbb said:
Anyway. I can guarantee that the main CPU can entirely halt and effectively freeze EVERYTHING in the phone so long as the screen is off and nothing is keeping it awake, and likely the exact same thing happens with Deep Idle but while processing something (this runs on the race-to-idle principle, even if slightly lower clocks may be more efficient here - hurry the hell up so i can shut down the CPU). If such a thing can happen, how can you conclude that the CPU must stay awake? This is why i've narrowed it down to another chip that must be aiding the radio.
I'd write more but i must get going. Keen to see where this takes us.
Click to expand...
Click to collapse
The freezing may only be for android though, You can independenly suspened/halt and resume virtualized applications (Either at their request, or preemptively). So its entirly possible for Deep Idle to behave properly in android, but not have the overall effect that one would think it would have. The processor would have much less to do and as such it likely does have some effect but the allowing an OS to execute such a disruptive instruction defeats the purpose of virtualization, if that makes any sense. Indeed the virtualized machine is halted, and nothing else is executing in the virtualized instance during this time. But the radio and Microvisor are very much alive during this. (You wouldn't be able to get an incoming call if they weren't.)
So in summary my argument is this:
Android cannot completely disable the CPU, this would cause NUMEROUS issues with the underlying radio software. WoL/WoR like functionality would be implemented in the radio software, From a development standpoint the complications FAR outweigh the benefits of such a design, It would not be fiscally responsible to design radio software in this way. If the processor were truly off, the microvisor would be unable to run and it would defeat the purpose of having said microvisor in the first place.
It would appear to android that the CPU Was off, and everything would halt (for android only). This should produce some battery savings (As even when idle an android system as some upkeep to do), but no where near the kind of savings you'd see with a truly halted CPU (that is woken by external interrupts). I will admit I was unaware additional testing was done.
If the system was truly halted for any period of time, When it was woken, the radio would be disconnected and would have to reconnect. You'd lose the ability to get notified of an incoming call or text (and to the cell network, your phone would be offline). You'd know if the cpu was TRULY frozen/halted/suspended.
Now, I'm not saying that the CPU Can't be put into a stopped state, just that android itself cannot make this happen. The microvisor would need permission from the radio, and the microvisor itself, would also need to be set to sleep as well. The radio is unlikely to give permisison, and as long as the microvisor, any of its children, or server processes, require the CPU, it will not actually happen. But the OS that halted itself will enter a fake halted state. (In reality, the hyper/microvisor would replace a HLT with a NOOP and stop executing the child. To the child this seems like being halted, but other things are still at work here.)
Another quick thought on deep idle. Perhaps the radio spends alot of time sleeping. Ideally it would know how often to wake up the delay may be as large as 50ms, which would explain the battery savings.
I don't know how often the phone would be polling the tower so can't comment on how often the radio would be sleeping, however i can say that i've had averages of around 50-60ms of deep idle time and possibly more. This is of course with the radio active.
I did try to erase the radio in fastboot, and BOOM! an error. It won't let me erase it to see how far it would boot. I'd rather not flash a bad file purposely, so i can't give any hard evidence on the radio being a primary boot initiator or kernel of sorts.
The minimum frequency of the CPU is 100mhz to my knowledge. Anything below this will likely get more and more inefficient and potentially useless. This is why on the Tegra 3's we now have a quad core main CPU + a little, much weaker (and much more efficient) core dedicated to low loads and the ability to rapidly switch between any setup you can imagine. Couldn't such interfaces such as WoL/WoR be entirely integrated into the radio chip?
Maybe i'm entirely deluded here, but i've yet to find hard evidence on either side and i'm leaning toward the ability to entirely shut off the CPU so far. Right now though, anything's possible.
Harbb said:
I don't know how often the phone would be polling the tower so can't comment on how often the radio would be sleeping, however i can say that i've had averages of around 50-60ms of deep idle time and possibly more. This is of course with the radio active.
I did try to erase the radio in fastboot, and BOOM! an error. It won't let me erase it to see how far it would boot. I'd rather not flash a bad file purposely, so i can't give any hard evidence on the radio being a primary boot initiator or kernel of sorts.
The minimum frequency of the CPU is 100mhz to my knowledge. Anything below this will likely get more and more inefficient and potentially useless. This is why on the Tegra 3's we now have a quad core main CPU + a little, much weaker (and much more efficient) core dedicated to low loads and the ability to rapidly switch between any setup you can imagine. Couldn't such interfaces such as WoL/WoR be entirely integrated into the radio chip?
Maybe i'm entirely deluded here, but i've yet to find hard evidence on either side and i'm leaning toward the ability to entirely shut off the CPU so far. Right now though, anything's possible.
Click to expand...
Click to collapse
I cant comment on tegra's design, I've never played with anything with a Tegra chipset. What I am speaking of is Qualcomm specific, its not a general truth for all phones. The problem with WoR/WoL in the radio chip, is all the radio chip does is pass demodulated data to the radio software, and modulate data thats going out on a requested frequency. ie, the radio hardware is dumb, and does exactly what its name implies, its a radio. It may be possible for it to say "Hey, I have data" but that would happen so frequently it would be pointless.
Erasing the radio would require JTAG to get the phone booted again, At least, I am 90% sure. The flash software for the radio also verifies the cryptographic signature and CRC's, so you won't be able to flash a "bad" radio at all. Only way to simulate this would be to yank the battery during a radio flash. But I believe there are also systems in place to prevent this from bricking the phone as well. If someone has a phone to sacrifice, this would be an interesting experiment and would yield some clues as to the boot process.
Also, On the tegra's, they may use a dedicated baseband processor instead of virtualizing it on the main CPU like the MSM chipsets do. If you want to point me to some tegra radio flash images I can give you some insight.
plaguethenet said:
I cant comment on tegra's design, I've never played with anything with a Tegra chipset. What I am speaking of is Qualcomm specific, its not a general truth for all phones. The problem with WoR/WoL in the radio chip, is all the radio chip does is pass demodulated data to the radio software, and modulate data thats going out on a requested frequency. ie, the radio hardware is dumb, and does exactly what its name implies, its a radio. It may be possible for it to say "Hey, I have data" but that would happen so frequently it would be pointless.
Erasing the radio would require JTAG to get the phone booted again, At least, I am 90% sure. The flash software for the radio also verifies the cryptographic signature and CRC's, so you won't be able to flash a "bad" radio at all. Only way to simulate this would be to yank the battery during a radio flash. But I believe there are also systems in place to prevent this from bricking the phone as well. If someone has a phone to sacrifice, this would be an interesting experiment and would yield some clues as to the boot process.
Also, On the tegra's, they may use a dedicated baseband processor instead of virtualizing it on the main CPU like the MSM chipsets do. If you want to point me to some tegra radio flash images I can give you some insight.
Click to expand...
Click to collapse
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.
Harbb said:
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.
Click to expand...
Click to collapse
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/documents/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/Product/2012215113150.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.
Good luck mate. Let us know your progress.
Reading this conversation is quite intriguing.
Where can I find more information to feebly attempt to gain knowledge of what I've just read (besides Google )?