[Motorola Photon Q 4G LTE] mbecroft:
Hi,

Great to see everyone contributing...I will take this opportunity to clear things up and focus on what actually needs to be done to get this working.

1. Those who mentioned getting hold of a BSP and SoC manuals are on the right track, but it is very difficult to get these from Qualcomm. It could only be through some back-channel via a dev at a big company that used the MSM8960. Getting access to this would be *huge*. Alternatively, a knowledgable person who has worked on an MSM8960 or similar Qualcomm SoC design.

2. boofus is correct in that the bootloader ordinarily passes memory map (and other) info to the kernel via devicetree. Either the bootloader needs modifying to pass a new memory map, or this has to be overridden in the platform code in the kernel (not difficult).

3. Changing commandline arges to the kernel is trivial (don't even need to rebuild anything, just extract the boot.img partition, edit and reflash--I have done this many times to tweak kernel args), but saying mem=2GB on the kernel commandline is unlikely to have any effect, because the kernel doesn't have a memory map describing at which physical address additional RAM is present.

4. Moreover, the DDR2 memory controller in the SoC has to be programmed to enable the 2nd chip select for the upper half of RAM. If this is not done, then the RAM is not even in the physical memory map. So any attempt to get this working must start here.

Currently, both nadlabak and I have 2 GB modded boards for testing. I'm stretched for time at the moment to look into this--much as I would *love* to have 2 GB--as someone else noted, 2 GB on the Photon Q would bring it back up to a usable level.

We would be *very* lucky if the Moto-supplied bootloader senses attached memory and configures the DDR2 controller accordingly, and even more lucky if this mapping was added to the device tree. It also has to be taken into account the baseband memory. This will fall somewhere in the physical memory map, and the memory made available to the kernel has to be outside the areas used by the baseband.

IF the xt897 bootloader is highly generic and used on other Moto phones with differing amounts of RAM, it *may* automatically detect and set everything up. If it does we would be *very* lucky. It's easy to see if this is being passed to the kernel via the devicetree, and presumably, in this case, the bootloader would also print the found memory size when booting into one or more of the bootloader stages using the key combos. Once I get my modded board into a phone I can at least check these trivial points. I have a handy comandline tool for probing physical memory, so I can easily get the existing memory map, and from that infer location of added memory. Then it is easy to attempt reading and writing where the extra memory would be if the DDR2 controller were appropriately configured, and see if memory is actually present.

More likely, the bootloader is hard-coded with the 1 GB memory map and programs the DDR2 controller accordingly. If so, to get additional RAM working requires:

1. Reprogram the DDR2 controller to enable 2nd CS. If we had the MSM8960 SoC manual and ability to extract and disassemble the relevant loader and replace it with a modified one, this would be almost trivial. However, I understand there may be encryption or signature verification preventing us from modifying early stage loaders. (This is also a fast way to permanently brick a phone, so we'd have to test changes on throwaway boards first.) If loader is protected, then we'd have to reprogram the controller on-the-fly. This probably can be done, possibly even within the kernel, if we don't have the ability to change the early loader(s), but may be a little complex, since reconfiguring the DDR2 controller may make memory temporarily inaccessible. Hence techniques such as locking the controller re-programming code into cache and waiting for the controller to come up again may be needed. However, this may crash the baseband. If the controller supports reprogramming without interruption, this would make things vastly simpler. All we need is the MSM8960 manual and specifically, the sections describing the memory map and DDR2 controller.

2. Once memory controller is reprogrammed, it's trivial to hack the new memory map into the kernel, whether or not we can change the devicetree passed from the loader.

TL;DR: yes we all want to get 2 GB working; it's almost certainly not trivial; it probably can be done, but likely requires extensive effort and knowledge from someone who has designed a product using the MSM8960, or access to manuals, or extensive reverse-engineering effort.

If anyone would like to step up please say so. I'll work on it myself as I have time and hope nadlabak will too. I personally can't wait to get a working 2 GB xt897.

---------- Post added at 04:19 AM ---------- Previous post was at 04:11 AM ----------

In sum, if anyone has access to any of the following, *please* let us know:

- MSM8960 SoC manuals;

- Knows someone who has developed MSM8960-based products or otherwise has knowledge of the MSM8960 architecture and especially the memory controller;

- Knows something about the xt897 or typical Moto bootloader structure, whether Moto often shares bootloaders across devices, and most importantly what loader stages there are, and whether each of these is encrypted/signature-verified, precluding making changes, or whether we can change it.