[myTouch 3G, Magic Android Development] biktor_gj:
@wire103: The way I see it, and the way it behaves so far, If I take a single byte reserved for the baseband, the kernel doesn't finish booting. It's easy to understand why, the kernel writes to a reserved address, then the baseband or a) gets corrupt and reboots or b) writes to the reserved address corrupting the data the kernel has written, so the kernel gets corrupt and reboots. In the end, if the phone ends up booting it means it all worked quite well. At the end of the reserved memory space, on other msm's at least, resides the audio tables (audioparam*.csv) the baseband uses to change between profiles (headset, earcouple and speaker). If I overwrite that, boom! the phone reboots, and start over again, or, in the best case scenario, it will break audio and reboot just the baseband losing phone connectivity, wich is obvious to see and to debug :)

On the kernel side, I can't mark anything as read only, I'm telling it that there IS more RAM so it can handle it, and that it's work in the end. And as I cannot get access to /dev/mem (since it's not there) I haven't found an easy fix to dump the entire memory.

@bcrook: I think it's not the radio what makes you loose ram, but the kernel itself. But without the HTC patches I cannot be sure until I see it. Although I can try to prepare some custom kernel with a little declared Ram to see if it helps booting a 32b kernel with a 32A radio.

In any case, 32A's original radio is version 3.22.20.17 and 32B radio is 2.22.19.26I so there might be some other things we don't know about.

And, so you all know what I know so far, 32A's kernel reports not 288 Mb of RAM as HTC Specification's page shows, but 198 Mb:

<6>[ 0.020000] Memory: 198MB = 198MB total

<5>[ 0.020000] Memory: 196608KB available (2824K code, 941K data, 104K init)

(taken from a dmesg some collaborative user posted on another thread)

So it seems in both cases, there's only one mapped bank, and it's eating about 80 mb of ram in both cases. Maybe these msm basebands need more ram to operate than previous models (I'm talking here about msm7201 vs msm7200). That's something I still don't know and I still have to test, but what I do know is that radios designed for both msm7200 and 7201 take more or less the same amount of space on flash (about 20mb), and on 7200 the needed ram for the baseband is 30mb, wich is way less than 80 mb wich is what this thing is eating.

EDIT: hmmm... I think I found the hole... shared memory (for gpu, camera...)

After looking at the code for the Diamond, Raphael and Blackstone, and after checking again the header files for the sapphire, I've seen that, apart from the baseband memory, wich will probably be 30 Mb more or less, other things are eating the ram. The most usable memory without corruption I can get is 109 Mb (11 mb more than stock kernels) without noticeable changes or problems (not that I've done a lot of debugging, but using the phone functions and opengl didn't give any problems of any kind)

So, we can take a little more RAM but not nearly as much as I thought.

For the code, in case anyone is interested, here you have:

if (smi_sz == 32) {
mi->bank[0].size = (84*1024*1024);
} else if (smi_sz == 64) {
mi->bank[0].size = (108*1024*1024);
} else {
printk(KERN_ERR "can not get smi size\n");

Or, if you want to tune it to the most you can get:

if (smi_sz == 32) {
mi->bank[0].size = (84*1024*1024);
} else if (smi_sz == 64) {
mi->bank[0].size = 0x06d00000;
} else {
printk(KERN_ERR "can not get smi size\n");

Almost anything above 0x06d00000 will make the phone reboot endlessly, and this will give you 109Mb of RAM. You can tune it further by altering the reserved memory addresses for the SMI, but I don't think that's a good idea (if they have those values it's for a reason, and you might end up seeing green lines on the screen, lockups, or other kind of errors by reducing the space for the framebuffer, adsp etc)