[Xperia Arc General] CTCaer:
Shame that I learned about this thread now..

But still great job all of you!

I was searching for a tool that can read specific memory addresses, so here's my little contribution.

I dumped many parts at the first 512mb but the most important were the memory holes in RAM.

So dumping the whole 0x04000000 - 0x07000000 had great info. This one is supposedly the RAM used by baseband apps and other components. (Also the 1st 2mb from 0x0 have a lot of bootloader info.)

It's a whole 48mb area and was always searching ways to get that back and also is the reason I made my 1st kernel.

So I tried more than 30 different configuration in the past. But then I didn't have all this info.

Many of them worked, and some crashed ARM9 at android boot. Other were complete fail and crashed at bootlogo and some not even kernel boot. But some recovered chunks of 8mb and a fully working phone (only thing broken was shutdown. It crashed at the last bit of shutdown, cause again of power management app in baseband). Another try was at 0x60000000 (if I remember correctly, 1year passed since then) with a 2mb recovering, cause of virtual memory map kick in.

Here's the good part:

All area between 0x04000000 and 0x04500000 is filled with data. Then at 0x0696A000 till the start of the 3rd ram bank (0x07000000) is again data (and fully with drm stuff and other baseband things).

Notice that both of them have also s1boot info

Also @ 0x0697C8C6 found this:

OP_ID="436"
OP_NAME="Customized"
CDA_NR="1252-0948"
ROOTING_ALLOWED="1"
RCK_H="706BCA641EDD60B388F779C233319511B66E56E92CB75264F473D0F9DECBD831"
CSERVERID="bmcsecs02"
AUTHCERT="UNKNOWN"
TIMESTAMP="120201 08:40:13"

Root config and the hash look interesting. Dunno more though.

So the important thing, now that we know more about the memory hole is:

Is that between 0x04500000 and 0x0696A000 is completely empty RAM. Maybe that is used by GPU but don't have time to check now.

So again to the orginal idea. This one is more than 36mb ram (HEX: 0x0246A000).

We have the jump at code thingy in bootloader, so 0x04700000 is probably used.

For starters let's make it a safe 0x05500000 and let's recover 8mb ram.

Now find the static void __init msm7x30_fixup function in board-semc_mogami.c

and put that there

static void __init msm7x30_fixup(struct machine_desc *desc, struct tag *tags,
char **cmdline, struct meminfo *mi)
{
#define MSM_BANK0_BASE	PHYS_OFFSET
#define MSM_BANK0_SIZE	0x03C00000

#define MSM_BANK3_BASE	0x05500000
#define MSM_BANK3_SIZE	0x05D00000

#define MSM_BANK1_BASE	0x07000000
#define MSM_BANK1_SIZE	0x09000000

#define MSM_BANK2_BASE	0x40000000
#define MSM_BANK2_SIZE	0x10000000

mi->nr_banks = 4;
mi->bank[0].start = MSM_BANK0_BASE;
mi->bank[0].node = PHYS_TO_NID(MSM_BANK0_BASE);
mi->bank[0].size = MSM_BANK0_SIZE;

mi->bank[1].start = MSM_BANK3_BASE;
mi->bank[1].node = PHYS_TO_NID(mi->bank[1].start);
mi->bank[1].size = MSM_BANK3_SIZE;

mi->bank[2].start = MSM_BANK1_BASE;
mi->bank[2].node = PHYS_TO_NID(mi->bank[2].start);
mi->bank[2].size = MSM_BANK1_SIZE;

mi->bank[3].start = MSM_BANK2_BASE;
mi->bank[3].size = MSM_BANK2_SIZE;
mi->bank[3].node = PHYS_TO_NID(mi->bank[3].start);
}

Compile kernel and flash.

Rinse and repeat maybe with other boundaries, now that you know the absolute max ones (#define MSM_BANK3_BASE 0x04500000 , #define MSM_BANK3_SIZE 0x0246A000)

For now can't test myself, no dev machine and uni exam period.

As for UART, I hope I can get my hands on that serial interface some time.