[HTC Wildfire S] no.human.being:
No 0x00480828 physical NAND address. But it's not assigned to any "partition" (mtd device). It isn't even assigned an "aARM pseudo-physical-but-actually-virtual NAND address" so you won't even find it in the "high security" or "unmapped memory area". It's even more hidden. You can let aARM read the entire NAND address space from 0x00000000 to 0x1fffffff and you won't find the page that matches 0x00480800 - 0x00481000 physical (pages are 2048 = 0x200 bytes size and it's the page where 0x00480828 is in). This is the reason why we couldn't find any clear difference between the memory dump of an S-ON and an S-OFF phone. It's not in the address space that aARM sees as "physical". However, what aARM sees as "physical" isn't the actual physical address space.

With Qualcomm chips I don't know. I think you can do so in large quantities (commercial customer), but I don't know whether they will ship in small quantities to private customers. I've found exactly ONE distributor that shipped me a JTAG interface for ARM. There are lots of distributors, but they only ship in large quantities and to commercial customers. In my country you pay lower taxes when selling to commercial customers so that's probably one of the main reasons. But you can get for example development boards for TI OMAP very easily (they're very expensive though and demand seems very high so it takes a loooong time until they can ship it to you - at least that's what TI says).

No, memory is virtualized (therefore my "class one hypervisor" theory). When you read the Radio area via software running on the chip, you get different results than when reading it via JTAG. JTAG probably reveals the "true" physical NAND content. What software sees is just what a lower-level firmware pretends to be physical NAND. It's a bit like the VMDK image of a VMware virtual machine. To the guest operating system it looks like a physical disk, but in fact it isn't. JTAG access is like reading the disk of the host, while NAND access by code running on the processor is like reading the disk of the guest.

But protecting IP is about more than preventing reverse engineering. Imagine a competitor (say nVidia with their Tegra chip - sorry nVidia, it's nothing personal - I'm just picking our a random processor manufacturer here :D ) buying ten thousand Qualcomm chips (probably not too big an investment for a company this size) via various distributors (so that Qualcomm cannot track it down so easily), modifying the low-level firmware (say Radio or even the processor's micro-program as long as it's not in one-time-programmable memory) so that it fails after 6 months of operation, then pay some distributors to put them back onto the market. OEMs buy these chips, not knowing that they have been modified and put them into devices. Devices pass testing and get on the market. After 6 months, mass failure of products using Qualcomm chips. Analysis reveals that it's actually the processor failing. Qualcomm gets LOTS of claims from various companies and reputation is damaged as their products are now considered "unreliable". Manufacturers move away from Qualcomm chips seeking for alternatives. Many will move to TI OMAP (it just seems to be incredibly popular at the moment :D ), some may move to nVidia Tegra. Mission accomplished.

Or other possibility. I could imagine that different chips in different price regions share common silicon but the lower-priced chips are "restricted" in their firmware - say the GSM transmitters are disabled and only WiFi is allowed. Or take the OMAP4460 in the Samsung Galaxy Nexus for example. Samsung Galaxy Nexus does not have an FM radio. However, people have found that there actually is an FM receiver (and even an FM transmitter!!) on the OMAP4460 silicon. If you could easily replace firmware on these chips, customers would buy ONE high-priced chip, dump its firmware, then buy LOTS of low-priced chips, put the firmware of the high-priced ones on them and put these into their products, getting the feature sets of the top-range processors while buying mid- or low-end ones. Understand? It's all marketing.

Why would a phone manufacturer want to restrict you from modifying the firmware? Because they don't want their low-end devices to become too powerful. Or their older devices upgradable to that cool feature only the new ones have. It's not about SIM locks and stuff. The one that's interested in SIM locks is the carrier. Vodafone is interested that you're SIM-locked when they subsidize your handset, not HTC. HTC is interested in selling phones. They want to prevent their "mid range" devices from being modded until they rival their stock "high end" devices because that would cut into their revenue. I could imagine that the component suppliers have similar motivations. What's funny though is that Qualcomm's competitors offer processors that are a lot better, yet most have less "protection" on their chips. So the company offering the worst product has the highest investment in protection of their IP or something like that. :D :D :D :D

The Radio for me is the address space that doesn't have a partition assigned. The partition with the lowest physical NAND address on our devices is the "boot" partition (or "mtd1"). Where "boot" starts depends on some factor we don't know but it either starts at 0x02bc0000 or 0x034c0000 physical. So in that case the Radio is the (btw monolithic - it doesn't have a file system - it's a "raw partition" which means that it's loaded as a single huge physical chunk and then executed on "mARM" even though there are separate "sections" in it that probably serve different tasks - modules that were probably compiled separately and then linked together - something like that) executable image that lies at 0x00000000 - 0x02bbffff (45.875.200 bytes = 44.800 KiB = 43.75 MiB) or 0x00000000 - 0x034bffff (55.312.384 bytes = 54.016 KiB = 52.75 MiB) physical NAND address (different firmware builds have different Radio sizes.

When you write to "fastboot flash radio", you write only a certain module (probably the "main module"), not all. But that part is definitely entirely contained within the "big, entire" Radio. You can flash other parts as well. For example "hboot", "mfg", "sp1", "wifi" also belong to the "big, entire" Radio. Yes, you've read that right. Concerning the NAND layout, HBOOT is part of the Radio even though it executes on the other processor. When dumping the NAND sequentially, there is "Radio code" before and after the HBOOT code so HBOOT is in a sense "embedded in the Radio", which is also why you cannot write there (the Radio protects its own code area and that includes HBOOT). Apart from these sections it's very very "monolithic", so you cannot for example separate REX from AMSS. The (proprietary) codebase is quite bad and it's all intermixed. That's why you hear the term "Radio" so often. You often cannot make a sensible distinction. What's interesting is that you can "talk" to the Radio via a virtual RS232 device after you issue "fastboot oem rtask C" command to the phone.