Remember 32mb minimum is used by the radio image. I havnt seen a general release qualcomm MSN7200A image thats less than about 40mb so thats probably more realistic. There's also a bunch used for surfaces and other buffers. So if linux is seeing 109mb there must be AT LEAST 109 + 32 = 141mb + other buffers, and probably 109mb + 40mb = 149mb + other buffers.
The MSM7200A die's come with 64mb or 32mb ram built in. The radio image can only reside in the internal RAM and not the external one. That means the phone must have at least 128mb + 64mb = 192mb of total ram if the radio image is 40mb.
Last edited by kam187; October 8th, 2009 at 01:52 AM.
Remember 32mb minimum is used by the radio image. I havnt seen a general release qualcomm MSN7200A image thats less than about 40mb so thats probably more realistic. There's also a bunch used for surfaces and other buffers. So if linux is seeing 109mb there must be AT LEAST 109 + 32 = 141mb + other buffers, and probably 109mb + 40mb = 149mb + other buffers.
The MSM7200A die's come with 64mb or 32mb ram built in. The radio image can only reside in the internal RAM and not the external one. That means the phone must have at least 128mb + 64mb = 192mb of total ram if the radio image is 40mb.
It seems very hackish to not tell kernel about memory reserved for the radio, but I can understand the motivation. But as far as other buffers, the kernel would definitely need to know about them since it would have to read/write to them. A frame buffer (or other buffers) isn't very useful if it can't be written to. A 320x480 screen at 32bits per pixel needs to be backed by a mere 600k.
If some Galaxy's have 192MB total and some have 160MB total, I'd certainly like to know about it. Mine says "CPU: ARMv6-compatible processor [4117b362] revision 2 (ARMv6TEJ), cr=00c5387f"
btw, news of the moment, i7500 unlocked on newegg, 589 w/free shipping (newegg claims 128MB ram incidentally)
Last edited by Russ Dill; October 8th, 2009 at 02:02 AM.
Remember the MSM chipset is an all in one app processor. It has baseband, bluetooth, app cpu, wifi baseband etc all built in. (Of course the analogue basebands are external)
The internal memory of the 7200A is used to map various buffers that all these things use. Memory is then attached on an external bus to expand this memory. However the MMU cannot map certain things to this external bus. Its a limitation by design.
When I say framebuffer I am not talking about the buffer exposed to linux but internal buffers used for things like 3d acceleration. For example your 256mb ATI graphics card on your PC doesnt have a 256mb frame buffer
It is highly unlikely that there are 32mb and 64mb revisions out there. They will all either be 32mb or 64mb. I just had a look at a firmware image and amss section is 20mb, but that is most likely compressed.
Its possible they are using the 32mb die, but in my opinion very unlikely.
Remember because of the nature of these integrated APP processors ALL memory is shared by the peripherals. Its not dynamic but staticly allocated by the MMU.
Quote:
Originally Posted by Russ Dill
It seems very hackish to not tell kernel about memory reserved for the radio, but I can understand the motivation. But as far as other buffers, the kernel would definitely need to know about them since it would have to read/write to them. A frame buffer (or other buffers) isn't very useful if it can't be written to. A 320x480 screen at 32bits per pixel needs to be backed by a mere 600k.
If some Galaxy's have 192MB total and some have 160MB total, I'd certainly like to know about it. Mine says "CPU: ARMv6-compatible processor [4117b362] revision 2 (ARMv6TEJ), cr=00c5387f"
btw, news of the moment, i7500 unlocked on newegg, 589 w/free shipping (newegg claims 128MB ram incidentally)
Last edited by kam187; October 8th, 2009 at 11:13 AM.
Remember the MSM chipset is an all in one app processor. It has baseband, bluetooth, app cpu, wifi baseband etc all built in. (Of course the analogue basebands are external)
The internal memory of the 7200A is used to map various buffers that all these things use. Memory is then attached on an external bus to expand this memory. However the MMU cannot map certain things to this external bus. Its a limitation by design.
When I say framebuffer I am not talking about the buffer exposed to linux but internal buffers used for things like 3d acceleration. For example your 256mb ATI graphics card on your PC doesnt have a 256mb frame buffer
It is highly unlikely that there are 32mb and 64mb revisions out there. They will all either be 32mb or 64mb. I just had a look at a firmware image and amss section is 20mb, but that is most likely compressed.
Its possible they are using the 32mb die, but in my opinion very unlikely.
Remember because of the nature of these integrated APP processors ALL memory is shared by the peripherals. Its not dynamic but staticly allocated by the MMU.
Still confused though, I'd think that the processor would need a window to read/write to that memory. I suppose I'll have to look more closely at how the msm video driver works. It seems surprising that the platform needs 83MB of memory that the kernel never sees.
Still confused though, I'd think that the processor would need a window to read/write to that memory. I suppose I'll have to look more closely at how the msm video driver works. It seems surprising that the platform needs 83MB of memory that the kernel never sees.
The kernel doesn't see it because the integrated devices take that memory for them selves at start and the kernel has no business mapping out anything there. Everything that is integrated has to use the in-die RAM to function. And there are a lot of integrated parts in the galaxy
You don't want to chose whether you want to use GPS and Camera or GPS and Compass. But not all of the 3 together, since there isn't enough free RAM in the die for the components to operate. Galaxy most probably has 192mb of ram.
Last edited by tisti; October 8th, 2009 at 06:00 PM.
Is RAM really that expensive in mobile phones? I'd be willing to pay
extra for a phone with plenty of RAM, say 512 MB. I think I once
saw an article about how much each component of iPhone costs...
screen was most expensive I think, and I don't think RAM was in the
first three.
It doesnt cost that much but ever penny counts when they design phones. A few cents builds up. Remember alot of the final cost includes money to pay for development, marketing, packaging, construction, tax. Also things like RAM and Flash don't have static prices, they fluctuate alot with demand and supply. That makes it extremely dificult, especially when you consider the price of the phone will drop by upto 30% in the first year.
The other thing is after a certain amount of ram you need more address lines to be able to reference it all. This adds routing complexity when you're routing out the PCB.
I think android requires a great deal more RAM than previous Samsung mobile phones. Maybe the person who spec'd this didn't quite understand android?
Or maybe the parts were not available in the design stage. The largest mobile LPDDR part Micron has in production is 2Gb (256MB). I'm not sure if the chip they use is just a single chip, a POP chip, an MCP chip, or an MCP POP chip, but going with those combinations can reduce availability even further.
A quick search of samsungsemi.com clears up the problem. They are not even sampling 2Gb mobile DDR parts. Micron is currently sampling 4Gb parts. I'm guessing that Samsung electronics did not have the options of going with Micron, and thus we are stuck with a 1Gb part.
Yeah, the problem with cutting edge devices that strive to be thiner and thiner is that you have to pick the package at design time. You can't usually footprint multiple parts onto the PCB and then use whatever is available at production time because there just isnt enough space. Its usually easy to say "why didnt they use this part?" and pick some obscure new part. But in reality if that part isnt in mass production, making millions of units of the phone could get very very expensive.
Thats the nice thing about DDR though, the DRAM manufacturers understand this and make pinouts quite stable. Micron's 512Mb part and 4Gb have the same pinout and same number of address lines (13). I think this is just a case of the creators of the Galaxy being tied to a single DRAM manufacturer and that manufacturer not producing a 2Gb part.
So next question, when I order my 4Gb sample from Micron, who is doing reasonably priced BGA re-work and where is the bootloader source so that I can modify it?
Last edited by Russ Dill; October 9th, 2009 at 01:42 PM.
lol you're brave I havnt seen the inside of the phone, but be very very carefull with reworking on something so small, multi layer and double sided. Make sure you go to someone who works on mobile phones or similar electronics.
I've heard many horror stories where components fall off the other side :P
I don't expect the bootloader source is open source.
lol you're brave I havnt seen the inside of the phone, but be very very carefull with reworking on something so small, multi layer and double sided. Make sure you go to someone who works on mobile phones or similar electronics.
I've heard many horror stories where components fall off the other side :P
I don't expect the bootloader source is open source.
Its of course tongue in check. I would like to get some high res pics of the innards to satisfy my curiosity though.
Just to clarify this now that I have checked exactly how/where everything is mapped -
There are 3 memories in the Samsung.
- SMI, 8 Mb on-die stacked memory. When present this memory bank is used for a high speed shared memory interface. When not present regular RAM is used. This is currently ALL allocated to GPU0
Its unclear what is in the lower 32 Mb, but it is almost certainly the Radio Bootloader and the AMSS (Baseband)
- EBI, 128 Mb of RAM externally connected to the MSM7200A.
Code:
EBI (External RAM)
10000000->10028000 Kernel
10028000->1040ffff : Kernel text
10410000->105611fb : Kernel data
105611fb->10700000 Kernel (+some free space to make page boundry)
10700000->10F00000 GPU1 (8 Mb)
10F00000->11000000 FB (1 Mb)
11000000->16D00000 FREE
16D00000->16E00000 SHARED? (1Mb)
16E00000->18000000 AMSS ?(18mb)
The top 1 + 18mb of the EBI are not usable. I think there is another copy of the AMSS here (why?!??!!). So the total usable memory is 0x6D00000 or 109Mb. 8Mb gets allocated to GPU1 and 1Mb to the Framebuffer. 7Mb is used for the kernel, and approx another Mb for Kernel panic buffer, console buffer etc. This leaves us with about 96 Mb of free memory for the Androind syste.
We (Me and Drakaz) are working on rearanging this memory to give us 105Mb of memory available for the system
Short answer
The Samsung has 192Mb of Memory + 8Mb of fast memory.
8Mb fast memory is allocated to graphics GPU0
8Mb RAM is allocated to graphics GPU1
32Mb RAM is allocated for Camera, Media processor etc
1 Mb is allocated to the framebuffer (screen buffer)
2 Mb is mapped to be shared
19 + 32Mb is used by the baseband (AMSS)
7 Mb is used by the kernel
96Mb is left usable in android.
All from the kernel sources, cat /proc/iomem, devmem and looking in the AMSS.
The wierd thing is that on other MSM implementations the AMSS is EITHER loaded into low 31Mb SMI64 _OR_ upper EBI. Samsung seem to have done both. I have no idea why!
We should really be able to use all of the 128Mb, and use the lower 31Mb of SMI64 for the baseband. We should also be able to use 2Mb of that 31Mb that is empty because the baseband size is only 19mb + 10mb for bootloaders.
Unfortunatly the kernel can't seem to read the EBI above the 109Mb boundry or the Lower 31Mb of SMI. This might take some findling with the MPU/MMU
MDP - This handles stuff like video playback, MPEG4 playback etc. Decreasing it too much will affect video decoding
ADSP - This will handle digital signal processing, audio etc
CAMERA - I assume this is mostly used for buffering while recording video
We can change these values around and increase GPU memory. We did a few tests and just rough values
I think whats happened is the bootloader and AMSS have 'protected' the SMI and upper EBI memory. The kernel isnt allowed to read it. We can 'deprotect' it and reuse one of the copies of AMSS, whichever they are not using.
I think you're right, they have used some stock/sample AMSS/bootloader/kernel files and modded them till it 'works'. Crazy!
No it is. The AMSS is stored on the NAND in a partition. It gets loaded into RAM and executed from there.
So Samsung copy it to SMI (0 to 31Mb space), AND also to the top 18mb of EBI. Obviously only one is being executed. We can rellocate one of these areas of RAM as 'free', and see if the radio crashes :P If it does we picked the running copy! We can then use the other copy instead.
The bootloader does the copying, so by the time the kernel gets run, that area is totally unused. However its still left protected because the MPU is still on.
If we configure the kernel to turn off the MPU at start we have access to all RAM again.
Last edited by kam187; October 31st, 2009 at 01:48 AM.
I think you're right, they have used some stock/sample AMSS/bootloader/kernel files and modded them till it 'works'. Crazy!
As I understand, most engineer are add HW/Coding in system till it work. than Sales STARTED since marketing request. that is init version of product.
later update HW/coding may cost-down or spec-up. the platform than will stable.
So, the init product may have loaded HW but poor coding. that is why i place bet on galaxy as my first android phone, and great mod can help us a lots.
I love the possibility of open platform so much.
Don't you think that 1GHz ARM is too over & heavy in portable device that needs to running all day, at least?
As I understand, most engineer are add HW/Coding in system till it work. than Sales STARTED since marketing request. that is init version of product.
later update HW/coding may cost-down or spec-up. the platform than will stable.
So, the init product may have loaded HW but poor coding. that is why i place bet on galaxy as my first android phone, and great mod can help us a lots.
I love the possibility of open platform so much.
Don't you think that 1GHz ARM is too over & heavy in portable device that needs to running all day, at least?
Device(s): HTC EVO 3D (GSM)
Orange San Francisco CM7
Thanks: 1
Thanked 2 Times in 1 Post
i7500 only shows 93mb of memory
Hi,
I've just installed Eray on my Galaxy, and it tells me I have 93mb of memory of that the most I can get free is 40mb.
Is that correct?
I've been having a few programs telling me that I do not have enough memory to perform a certain task and iDracula runs painfully slow.
Please could someone give me some advice.
So actually, the baseband uses 18Mb of the lower SMI, and the remainder is taken up by the bootloader, and overlapping GPU0 stacked memory. There is 2mb left. Its pretty tricky to get this 2Mb back as you'd have to use the MMU to remap a couple of pages. Its not worth the work just for 2mb!
The baseband also uses 13.2 Mb of the upper EBI. It probably uses the remaining 5Mb as working RAM. I personally suspect that the 13.2mb is the working RAM and 5Mb is left over for a possibly bigger baseband in the future. This is consistant with other phones which are able to leave 115mb free.
Thank you for signing up to receive updates for the 4
An email has been dispatched to confirm your signup. Please click the link in the email.
Buy the Samsung i7500
Sign up for instant notification when the Samsung i7500 goes on sale!
When Samsung joined the Open Handset Alliance, excitement and anticipation engulfed the mobile world. With industry leading mobile phones such as the Samsung Instinct and Samsung Omnia already on the market, expectations soared. The speculation can f... Read More
Galaxy; How much RAM? 96MB, 109MB, 128MB, 192MB?
