yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] Loccy:
Is there any reason why you guys couldn't run RogerMod (or any Magic-specific ROM that includes the extended RAM) by doing the reverse of what we do to convert a Dream ROM?

i.e.

unpack rom zip

unpack boot.img

rename init.sapphire.rc to init.trout.rc (we would do this the other way round)

repack boot.img

repack rom zip

resign rom zip

???

It might be an interesting experiment to try, you'd be using a known good set of extended RAM settings and could see whether the concept can be applied to the Dream at all.
[G1 Android Development] daproy:
The memory map is compiled in the kernel for each separate board. Changing the init scripts won't do anything to the memory.
[G1 Android Development] daproy:
The EBI memory map is very similar on trout (dream/G1) to sapphire meaning biktor_gj's method of extending the linux memory on sapphire should overwrite GPU1 memory too, unless he moved GPU1 to some other memory location?
[G1 Android Development] maxisma:
I have a modded Cyanogen Kernel with this RAM Mod and it works w/o reboots.

Only thing I've noticed is a lag in Hyperspace (3DGame), but I don't know if this is an issue of the kernel, but CM-Experimental itself.
[G1 Android Development] jmon777:
hyper space works ok the 41.111.
[G1 Android Development] dwang:
I wouldn't mind seeing the memory hack applied to the stock 1.6 kernel plus the compcache modules.

the stock 1.6 kernel seems pretty speedy, and its only running at 384mhz by default.
[G1 Android Development] miketaylor00:
That's what I was wondering too. It wouldn't suprise me at all.
[G1 Android Development] Geniusdog254:
Exactly, BFS seems great at first look but it just seems to break other things at the same time. Until it gets ironed out I personally think we should ditch BFS.
[G1 Android Development] dwang:
The stock 1.6 kernel is actually VERY fast once you set the max CPU speed to 528mhz.

I'm not sure if bfs is even needed at all.

If we can get the memory hack with the compcache modules, that would be perfect.
[G1 Android Development] miketaylor00:
I've seen first hand through my testing that BFS has a lot to offer. It allows you to have multiple things running at the same time without it slowing down. I had 5 windows open in my browser, pandora radio playing, was talking on google talk, and had a couple other apps open in the background and my phone barely slowed down. The music never skipped or anything. The first BFS patches for Android didn't do that much but some of the more recent ones have had a huge impact.

I don't think the extra memory hack is really going to help a whole lot and it is going to have issues with stuff like 3d games whether BFS is there or not.
[G1 Android Development] dwang:
I've done quite a bit of testing with bfs as well and I've found that 4.1.11 didn't work as well as previous versions. It slows down quite a bit when apps were running in the background. I've found 4.1.9.2 to be the fastest with multitasking.

And I disagree with you wrt the extra memory hack. It does wonders with keeping the browser in memory and not refreshing so often (much better than compcache w backing swap alone). I actually don't run too many apps in the background, but I hate it when the browser refreshes. The memory hack in conjunction with compcache works beautifully.
[G1 Android Development] miketaylor00:
Did 4.1.11 use BFS 238? That patch sucked. The one I used before that was 220 and it was great for multitasking. I'm guessing those are the 2 that Cyanogen used because I think his tarballs were used to patch it.
[G1 Android Development] sacredsoul:
Anyway to patch the 238 of 4.1.11.1 to 220?
[G1 Android Development] dwang:
Not sure what version of bfs, but I switched between 4.1.11 and 4.1.9.2 quite a few times during my testing and 4.1.9.2 was def much better at multitasking and overall speed.

4.1.10 was just plain slow.
[G1 Android Development] miketaylor00:
You would have to recompile the kernel
[G1 Android Development] dumfuq:
Since I can't handle 4.1.11.1 on a regular basis, I made a boot.img for 4.0.4.

These are the same changes except only to the trout board.

http://www.mediafire.com/?sharekey=e935fab58eba93a6c2b435915e8821d7e04e75f6e8ebb871
[G1 Android Development] ivanmmj:
Anyone ever tried compiling the kernel with the BFS 230 patch?
[G1 Android Development] Sirus20x6:
http://twitter.com/cyrowski

found via cyanogen's twitter
[G1 Android Development] Fabulous691:
Hey Guys

Could somebody say me if this method seems to be good or if there is bugs caused by it...?

I would like have more ram,like everybody, but if it transform my phone into a buggy phone, i will don't use this tutorial..

Thx for informations and Help

excuse my english....he is too poor..:o
[G1 Android Development] mlevin:
Same here.
[G1 Android Development] lbcoder:
It is extremely rude to add a post to the end of a thread asking what the thread was about. I suggest you go back and READ THE THREAD!
[G1 Android Development] Fabulous691:
:confused:

i don't understand you and maybe you've not understood me...Thx for help :D
[G1 Android Development] IConrad01:
Just a Precautionary Warning

For those of you reading this -- if you ever check on your RAM while in recovery mode, the numbers will read the old 97 MB rather than 107 MB free.

I ran into this because I flashed a theme for cm4.1.11.1 -- and wanted to check to make sure the boot.img wasn't changed on me. Imagine my surprise when it wouldn't flash the 10%+ boot.img, but still said 97 MB RAM. :/

Moral here: don't check your RAM while in Recovery. The Recovery lies to us, precious! </gollum>.
[G1 Android Development] Knightsofwar210:
So I see you can do this with CM 4.0.4, so has anyone tried this? does it make it faster?

Because it seems to me that it makes it "buggy'
[G1 Android Development] vixsandlee:
wouldnt the linux kernel boot after recovery ?

hence recovery showing the original amount ?
[G1 Android Development] IConrad01:
Recovery is also Linux. The standard boot.img is a different kernel from the recovery image, though -- hence the separate partitions. Since this is just a software change, and we're only changing the kernel for the standard ROM, the recovery kernel would still be mapped the "old" way.
[G1 Android Development] mlevin:
Yes, it is good.
[G1 Android Development] ei8htohms:
so does anyone know what Cyanogen's concerns are with this patch?

I'm just trying it now so I don't know first hand how it runs, but someone noted in the Cyanogen Current State thread that Steve didn't seem enthusiastic about using it. Maybe he's a got high hopes for 3d games? :)
[G1 Android Development] Boomgawd:
looking forward to you resuls!

Looking forward to your comments!
[G1 Android Development] Johnny Blaze:
I am doing some testing on this issue. I started having the same problem a few days ago. I have been usiing zeroXD or Evil Hero. Both with the same result. 96mb swap 40 swappiness class 6 8g sd

Just purchased a new sd card formatted with recovery to default 32mb swap. Rom is just as fast and no more screen issues.

Did a print on my old sd card. It is partitioned with 100mb ext and 96mb swap. Terminal is only showing 94 available. My problem is my memory card. Check memory card first by trying with a new one and see if problem persists.
[G1 Android Development] jf4888:
I found that this is a bug when uplugging the phone while it is asleep real fast and then it stays stuck like that
[G1 Android Development] jerhoyet:
I've been glancing at this thread for a few days now and I only see a run down of issues associated with using this "hack". Has anyone increased their RAM and had zero issues? I would love to give it a whirl, but from what I'm reading it's just a bag of problems.
[G1 Android Development] Zoide_:
I think there's probably a very good reason why Google didn't use this hack in the first place...
[G1 Android Development] dumfuq:
I've had no issues yet myself that were completely unrelated to the rom. Using the boot.img for 4.1.11.1 I experienced coma issues occasionaly but that was the reason I quit using that build without the hack in the first place. With the 4.0.4 img I have had zero problems. However, I don't play 3d games on my phone so I haven't had that issue.
[G1 Android Development] bob50963:
I started using it last night and no issues. Also, still looking for some one to rewrite the main post on this thread. I have little time to keep up with this. If anyone has any updates let me know. Also, take a look into increasing the ram to 128m. Where is the rest of the hiding?
[G1 Android Development] david1171:
i have used this since the day it was released and have experienced no problems with it. though i do not play 3D games. that it was a xbox 360 for... to play games, i use my phones for modding and well occasionally i call some one.
[G1 Android Development] IConrad01:
I have been using this patched kernel for a few days now. I have actually found that not only does it not impede my 3D graphics gaming (RoboDefense at high levels); but furthermore it has actually improved the performance of my system when coming out of sleep.

Now -- as to the possibility of 3D Graphics problems, would it be possible that perhaps the amount of reclaimed memory could be set up as a shared memory module between the CPU and the GPU? Is this already being done? Furthermore, what would be the ramifications of attempting to set up CompCache as a shared module between the two? Is that just a really bad idea that I'm too ignorant to realize is bad?
[G1 Android Development] Vovan888:
It would be nice if someone post the benchmark, with and without this patch.

For example with this tool - http://www.cyrket.com/package/softweg.hw.performance
[G1 Android Development] Chahk:
Robo Defense is hardly an example of 3D gaming. In fact, it's as 2D as it gets :) Hyperspace or Speed Forge would be better for testing 3D performance.
[G1 Android Development] Chosen_on184:
Someone made a nice cleaned up thread with everything layed out pretty nicely for those who might have a hard time understanding whats happening here

http://xdaforums.com/showthread.php?t=566410:D
[G1 Android Development] jacsonmoore3:
i have the [Recovery] RA-dream-v1.2.2

with DIZZY 1.5.7 ROM

will this work on mines
[G1 Android Development] PaulG1488:
Nevermind...
[G1 Android Development] Gimpeh:
I haven't seen a update on this in quite awhile. Originally people were trying to figure out how to free up even more ram. Has anyone had any luck?
[G1 Android Development] forshao:
it seems it dont work with cyan4.1999

i have flash it ,but my phone cant reboot.......
[G1 Android Development] mrkumquat:
copy that

agreed, nothing but blackscreen after the android loadscreen on cm 4.1.9999
[G1 Android Development] Geniusdog254:
Make sure you flash a version with the 4.1.9999 kernel not the 4.1.999 or 4.1.11.1 or any other versions' kernel.
[G1 Android Development] bonesy:
what wlan.ko works with this patch
[G1 Android Development] HaloTechnology:
is this will work with latest Cyan roms or any version

​
[G1 Android Development] MrBlueEyez:
No it won't. Search the forum, there is another thread. To save you some time, here's the post linking to boot.img for cyanogen latest build (.15)

http://xdaforums.com/showpost.php?p=5783878&postcount=715
[G1 Android Development] HaloTechnology:
thanks man
[G1 Android Development] zamc:
Hello

i would like to ask something, i have cyanogen mod6 on my phone(magic 32b) and i would like to know if this patch works in cyanogen mod6 and where i can find it.

Thanks a lot for your time.
[G1 Android Development] GinoAMelone:
No. No it won't. If you want details, spend time with google and "10mb hack".
[G1 Android Development] zamc:
You mean i dont have to? because its already done in CM6 or it can be done with an other way?

I find a threat in cyanogen forum that says that its no need to do it in CM6

But i can see only 97708KB RAM and i have CM6 (so something is wrong) ?
[G1 Android Development] raven_raven:
CM6 does not include RAM-HACK. Also, additional 10 mb of RAM cannot be obtained due to changed way of addressing memory. So no RAM-Hack on CM5+.
[G1 Android Development] xenogearz87:
can i apply this on cronos ROM in my milestone..?
[G1 Android Development] ionic7:
/facepalm

10char
[G1 Android Development] xenogearz87:
what did u mean..?
[G1 Android Development] sleepyfu:
I thank you for the comedy.
[G1 Android Development] yukkio:
Maxisma, could you share your "patched ram" boot.img please? is the patched boot.img from last cm experimental?

Thanks!
[G1 Android Development] dwang:
You mind sharing your modded cyan boot image with the patch?
[G1 Android Development] daproy:
In order to safely get more linux ram the GPU1 ram needs to be moved.

The GPU gets 7M in SMI (on chip) and 8M in EBI (external). The SMI base is at 0x00000000 EBI memory Base is at 0x10000000. Linux memory is on EBI and in the kernel source the total size is defined as 0x06e00000 = 110M. Looking at the generally available specs for the HTC Dream it lists 192M of ram. I'm not sure if this is including the SMI on chip ram or is indicating the size of the EBI DDR-SDRAM installed in the device. I guess I could take it apart and look. If the total size of EBI is actually 192M then maybe we can push the GPU1 location back? If there is more EBI ram I have no idea if its being used by something else not listed in the kernel memory map?
[G1 Android Development] Geniusdog254:
From what I read about this mod in the Magic forums, most of what appears to be just being eaten by the kernel & such is actually just allocated differently.

I believe that the MSM7200 baseband requires about 30MB ram, maybe 40MB. So knock that down to 152MB already. Then there is shared memory for things like GPU, camera, speaker/headphones. That takes up about the same amount or a little more than the baseband, which say it takes up 42MB then that is the 110MB available to the kernel. I don't understand why if the shared memory includes GPU ram, why does the GPU1 ram have anything initiated.

I tried the alla Rogers mod for the Magic & it while I didn't notice any great improvement (I only ran it for about 30 minutes), I did look in the terminal to see how much ram was available and it had the new amount
[G1 Android Development] daproy:
In the Service Manual it lists 192MB DDR (include 64MB baseband chip), which is probably why its listed some places as 128MB. As far as I know the baseband chip is at a completely different memory base address than the EBI DDR-SDRAM. If the EBI DDR chip is 128M I'm not sure why we are only using 110M. Going to try to move everything back...we'll see what happens
[G1 Android Development] daproy:
Good catch. I downloaded the HTC kernel source for dream and there is no GPU1 ram in EBI its all defined on SMI. It also has alot of added code to deal with 256MB EBI, did the rogers version get a ram upgrade?

Anyways the difference in the location of GPU ram explains why an HTC sourced kernel will work be simply increasing the linux ram bank because the GPU1 is not located directly after it.

Ok, so we can move the GPU1 ram into SMI and increase the size of the Linux ram to a maxium of 0x06D00000 = 109M. Then the ram console memory follows.
[G1 Android Development] daproy:
This works! I moved GPU1 memory to SMI like in HTC sourced kernel giving us 8M more for linux memory on a cyanogen sourced kernel. I will provide a patch to cyanogen. Now I am curious why we are not using the remaining memory in EBI. There should be 128M. Going to try extending it.

# cat /proc/meminfo
MemTotal: 98140 kB
MemFree: 1940 kB
Buffers: 428 kB
Cached: 16864 kB
SwapCached: 7392 kB
Active: 31676 kB
Inactive: 36084 kB
Active(anon): 25324 kB
Inactive(anon): 25448 kB
Active(file): 6352 kB
Inactive(file): 10636 kB
Unevictable: 252 kB
Mlocked: 0 kB
SwapTotal: 96380 kB
SwapFree: 49440 kB
Dirty: 16 kB
Writeback: 0 kB
AnonPages: 50260 kB
Mapped: 11548 kB
Slab: 7432 kB
SReclaimable: 1060 kB
SUnreclaim: 6372 kB
PageTables: 5528 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 145448 kB
Committed_AS: 1477412 kB
VmallocTotal: 811008 kB
VmallocUsed: 60772 kB
VmallocChunk: 662524 kB

# cat /proc/meminfo
MemTotal: 106268 kB
MemFree: 56204 kB
Buffers: 1056 kB
Cached: 29260 kB
SwapCached: 0 kB
Active: 13040 kB
Inactive: 28488 kB
Active(anon): 11244 kB
Inactive(anon): 0 kB
Active(file): 1796 kB
Inactive(file): 28488 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 96380 kB
SwapFree: 96380 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 11228 kB
Mapped: 14792 kB
Slab: 5636 kB
SReclaimable: 1064 kB
SUnreclaim: 4572 kB
PageTables: 768 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 149512 kB
Committed_AS: 82996 kB
VmallocTotal: 802816 kB
VmallocUsed: 46008 kB
VmallocChunk: 729084 kB
[G1 Android Development] :
great work! how much memory will be gained alltogether?
[G1 Android Development] daproy:
Well extending the EBI past 0x06E00000 does not work. It just hangs, no adb. But we can move the RAM_CONSOLE to SMI to get all 110M for Linux I think.
[G1 Android Development] daproy:
Moving the RAM_CONSOLE and making the FB frame buffer slightly smaller as in HTC source give us:

# cat /proc/meminfo
MemTotal: 107292 kB
MemFree: 58608 kB
Buffers: 1056 kB
Cached: 28380 kB
SwapCached: 0 kB
Active: 12624 kB
Inactive: 27604 kB
Active(anon): 10824 kB
Inactive(anon): 0 kB
Active(file): 1800 kB
Inactive(file): 27604 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 96380 kB
SwapFree: 96380 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 10804 kB
Mapped: 14436 kB
Slab: 5576 kB
SReclaimable: 1064 kB
SUnreclaim: 4512 kB
PageTables: 768 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 150024 kB
Committed_AS: 82972 kB
VmallocTotal: 802816 kB
VmallocUsed: 45604 kB
VmallocChunk: 729084 kB

I still don't understand why we can't increase the size of EBI to the full 128M like in the specs. In any case this is still a big improvement with no downside I can see! 9% memory increase. Any ideas how to get at the rest of it?
[G1 Android Development] xitaxuta:
9% im in!! great work daproy!!

now how do we patch?
[G1 Android Development] jokersax11:
finally a decent thread...recently all the google/cyan has been pissing me off.oh well move on and lets keep making people jealous. my projects are almost done and i will start working with android, however this is the kind of real improvements we need right now, not all that lets fight the man stuff. now can anyone provide a baseband dump or memory dump to see if the baseband is moved forward and causing the lack of 128mb.
[G1 Android Development] Geniusdog254:
Ahh very awesome. Another thing is that the Roger's Dream didn't get a RAM upgrade. I'm using it right now & the only thing different is the button layout & the radio chip. Otherwise it is all the same, although I don't understand why Rogers is running a custom kernel if everything is as it seems.
[G1 Android Development] bob50963:
I'm happy to see my thread getting somewhere. 9% more ram is awesome :). Can some one write a tutorial on how to do this and ill edit my first post so people know how. Let's work on getting the full 128m ram recovered! Good work guys!
[G1 Android Development] daproy:
Here's the patch to cyanogen's kernel source. Hopefully he will include it in the next release. I'm still looking at why increasing the EBI size causes it not to boot. There is nothing else in the memory map after it I can see, but all the kernel sources I've seen #define MSM_EBI_SIZE	0x06E00000 or 110M
[G1 Android Development] danieljordanmaddux:
Can this be used with Hero ROMs?
[G1 Android Development] h.nocturna:
I don't think so because we're not using Cyanogen's Kernel, but either JAC, or Drizzy's
[G1 Android Development] danieljordanmaddux:
So this should work with JACHeroSki 2.1? If so once i get the text file what is it renamed to and where do i put it?
[G1 Android Development] jubeh:
rename it to init.sh and put it in your sdcard, then connect your phone and run adb shell rm -r /system

---edit---

Don't, I'm just kidding. If you don't understand what's going on on this thread, stay out of it. This is a kernel patch for kernel cooks and there's nothing here for end-users.
[G1 Android Development] Geniusdog254:
Rotflmao PLEASE PLEASE PLEASE tell me you were joking.

You were joking right?

Lol to the person who asked that, DO NOT DO THAT, it will wipe out your OS ;)

PS: Jubeh you have an awesome sig lol
[G1 Android Development] danieljordanmaddux:
rm -r /system is just going to remove everything under the /system directory isnt it?
[G1 Android Development] andonnguyen:
Double post.
[G1 Android Development] andonnguyen:
Um, don't do it, you'll destroy your phone. lol. Too lazy to recompile the kernel atm, I'll just wait for someone else to do it.
[G1 Android Development] danieljordanmaddux:
yeah i kinda figured that one out. I just wanted to try it out and see what kind of improvements it offered
[G1 Android Development] jubeh:
Sorry about being an ass, but the last two days have brought out a bunch newbie posts. You did identify that the thing was going to wipe your system, so that's cool, a rung above the other guys :D. It's still nothing a fastboot flash system system.img can't fix though :D.

Anyway, I've no idea how to configure kernel settings, but I sure as hell can apply patches. Will this work on the stock 2.6.27 for the cupcake AOSP though? I'll open the file from the AOSP kernel and make the changes myself just to be sure.
[G1 Android Development] IOmega666:
damn you guyz are crazy xd but its rly cool to see this kinda things .

lucky me that i know that rm -r to /system can do xd
[G1 Android Development] daproy:
Not sure how it will behave with source from AOSP. I don't think the memory map has been changed by cyanogen so it should work. Here is an updated patch with the change for sapphire 32b included. I don't have a Magic so I can't test this :o. On both 32b sapphire and dream (trout) should give 107M useable ram on cyanogen's latest kernel source.
[G1 Android Development] Geniusdog254:
Great work Daproy. Now how about an already-compiled boot.img for those of use without a linux box to apply the patch & recompile the kernel ;)

Ahh wishful thinking lol. But seriously it'd be great if you could post up a boot.img with the new RAM mod.
[G1 Android Development] daproy:
Here's a replacement boot.img for cm 4.1.11.1. Only change is the patch shown previously. Can people running 4.1.11.1 test this and let me know how it goes? (cat /proc/meminfo) Especially 32b sapphire users since I can't. This is obviously experimental so if you are not comfortable don't try it. Wifi may not work since the kernel is recompiled.

Make a nandroid backup

fastboot flash boot bootmem.img

fastboot reboot

http://drop.io/mempatch
[G1 Android Development] Geniusdog254:
Great! I'll test this throughout the day tomorrow on my Rogers Dream & let you know how it goes over the long term.

I just flashed it and cat /proc/meminfo reads it as having 107,792 kB total, so all is well there. Also, I can confirm that WiFi IS working with this kernel.

Thanks again!
[G1 Android Development] Nedlinin:
Booting off this image on my G1 now. Seems to be working great, wifi connecting and working fine

EDIT: Will run with this bootimg for the next 48 hours and report any crashing/errors as necessary - Otherwise, amazing work and I hope we can figure out a way to pull the rest of the memory into the available pool.

EDIT2: One thing Ive noticed is by flashing this I end up not getting the T-Mobile boot logo. Any reason for that? By moving the graphics allocation are we not able to get a proper display until after boot or something?
[G1 Android Development] Geniusdog254:
I noticed the same with the Android logo not showing up. I don't think its because of the graphics code not initializing right or else everything would be screwed up not just that logo. Also, as I pointed out earlier, graphics code is stored in the shared memory that is also occupied by the baseband/radio as well as the camera & speaker. Why the GPU1 bank is still there hogging memory is just strange since there are no ill-effects removing it.

Anyway. It works. That is really all that matter to me, since the android logo on non-htc builds is crappy anyway lol.