Guest t0mm13b Posted June 19, 2011 Report Share Posted June 19, 2011 Heads up everyone, The CM7 rom uses the kernel with memory management set to vmsplit of 3g (3 Gb user memory space and 1Gb kernel memory). The leaked GB rom that someone posted, is built with memory management set to vmsplit of 2g (2Gb user memory space and 2Gb kernel memory). So please stop asking us to mix and match, take bits of libraries here and there (in the hope it will cure/fix some cm7 deficiencies) and put into the cm7 rom - quite frankly it will not work! This is frustrating to some devs on irc channel, asking about it, and some still think you can - you cannot - technically on how the layout of memory is and also on how the cm7 rom is built as that is greatly influenced by the kernel memory management itself. Link to comment Share on other sites More sharing options...
Guest Phoenix Silver Posted June 19, 2011 Report Share Posted June 19, 2011 Heads up everyone, The CM7 rom uses the kernel with memory management set to vmsplit of 3g (3 Gb user memory space and 1Gb kernel memory). The leaked GB rom that someone posted, is built with memory management set to vmsplit of 2g (2Gb user memory space and 2Gb kernel memory). So please stop asking us to mix and match, take bits of libraries here and there (in the hope it will cure/fix some cm7 deficiencies) and put into the cm7 rom - quite frankly it will not work! This is frustrating to some devs on irc channel, asking about it, and some still think you can - you cannot - technically on how the layout of memory is and also on how the cm7 rom is built as that is greatly influenced by the kernel memory management itself. It's exact. The memory management is not the same. You can't use the kernel of one rom in another. Link to comment Share on other sites More sharing options...
Guest jurrasstoil Posted June 19, 2011 Report Share Posted June 19, 2011 If ZTE releases the source (hopefully and hopefully soon), it will be possible to get a working .35 kernel for cm7 tho, right? I really like a lot of the features that CM7 adds, which is why i'm staying with CM for now, but would also like to enjoy some/most/all of the benefits from the new leak. Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted June 19, 2011 Report Share Posted June 19, 2011 If ZTE releases the source (hopefully and hopefully soon), it will be possible to get a working .35 kernel for cm7 tho, right? I really like a lot of the features that CM7 adds, which is why i'm staying with CM for now, but would also like to enjoy some/most/all of the benefits from the new leak. There's a snowballs chance in hell that it will happen soon, one thing certain though - its a very munged and hacked up source like what ZTE did to .32 sources .... that's guaranteed! Have extracted the kernel config from the leaked rom and tried to build it and it failed due to something missing or hacked up.... Link to comment Share on other sites More sharing options...
Guest unrandomsam Posted June 19, 2011 Report Share Posted June 19, 2011 It 100% can be done KK's CM7 rom (For the V9 tablet) is built with 2G VMSPLIT Link to comment Share on other sites More sharing options...
Guest targetbsp Posted June 19, 2011 Report Share Posted June 19, 2011 It 100% can be done KK's CM7 rom (For the V9 tablet) is built with 2G VMSPLIT I'm no expert... but that's surely the opposite of what this thread is about? This thread is saying you can't take bits of the GB leak into CM7. Because we don't have the source of GB to make it compatible. It's not saying you can't take bits of CM7 and make them compatible with anything else - but the Cm team obviously aren't going to do that... Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted June 19, 2011 Report Share Posted June 19, 2011 It 100% can be done KK's CM7 rom (For the V9 tablet) is built with 2G VMSPLIT You've obviously misunderstood the thread Read it again and I'll recap it Taking a lib from the leaked gb rom, and shoving it into cm7's nightly is not going to work.... KK's own rom is vmsplit2g so that works fine no problem and can mix match okay no problemo... what part of that have you misunderstood? Link to comment Share on other sites More sharing options...
Guest unrandomsam Posted June 19, 2011 Report Share Posted June 19, 2011 I'm no expert... but that's surely the opposite of what this thread is about? This thread is saying you can't take bits of the GB leak into CM7. Because we don't have the source of GB to make it compatible. It's not saying you can't take bits of CM7 and make them compatible with anything else - but the Cm team obviously aren't going to do that... Look into the codeaura froyo_almond branch Basically you need a new linker map and very minor patches to get the source compatible then you can use the new kernel and GL libs with CM7 (which is the current best of all worlds). unless you want to bother getting the armv6 optimizations another way. commit 4da066f118994deefbde02b1a6097c6bd945d081 Author: kallt_kaffe <[email protected]> Date: Sun May 1 20:42:19 2011 +0200 Added VMSPLIT_2G support. diff --git a/core/combo/select.mk b/core/combo/select.mk index 797c573..91b0711 100644 --- a/core/combo/select.mk +++ b/core/combo/select.mk @@ -55,7 +55,11 @@ $(combo_target)SHLIB_SUFFIX := .so $(combo_target)JNILIB_SUFFIX := $($(combo_target)SHLIB_SUFFIX) $(combo_target)STATIC_LIB_SUFFIX := .a +ifneq ($(TARGET_USES_2G_VM_SPLIT),true) $(combo_target)PRELINKER_MAP := $(BUILD_SYSTEM)/prelink-$(combo_os_arch).map +else +$(combo_target)PRELINKER_MAP := $(BUILD_SYSTEM)/prelink-$(combo_os_arch)-2G.map +endif # Now include the combo for this specific target. include $(BUILD_COMBOS)/$(combo_target)$(combo_os_arch).mk diff --git a/core/prelink-linux-arm-2G.map b/core/prelink-linux-arm-2G.map new file mode 100755 index 0000000..874ae62 --- /dev/null +++ b/core/prelink-linux-arm-2G.map @@ -0,0 +1,213 @@ +# 0x80000000 - 0xFFFFFFFF Kernel +# 0x70100000 - 0x7FFFFFFF Thread 0 Stack +# 0x70000000 - 0x700FFFFF Linker +# 0x60000000 - 0x6FFFFFFF Prelinked System Libraries +# 0x50000000 - 0x5FFFFFFF Prelinked App Libraries +# 0x40000000 - 0x4FFFFFFF Non-prelinked Libraries +# 0x2AAAAAAA - 0x3FFFFFFF mmap'd stuff +# 0x10000000 - 0x2AAAAAA9 Thread Stacks +# 0x00000000 - 0x0FFFFFFF .text / .data / heap + +# Note: The general rule is that libraries should be aligned on 1MB +# boundaries. For ease of updating this file, you will find a comment +# on each line, indicating the observed size of the library, which is +# one of: +# +# [<64K] observed to be less than 64K +# [~1M] rounded up, one megabyte (similarly for other sizes) +# [???] no size observed, assumed to be one megabyte +# +# note: look at the LOAD sections in the library header: +# +# arm-eabi-objdump -x <lib> +# + +# core system libraries +libdl.so 0x6FF00000 # [<64K] +libc.so 0x6FD00000 # [~2M] +libstdc++.so 0x6FC00000 # [<64K] +libm.so 0x6FB00000 # [~1M] +liblog.so 0x6FA00000 # [<64K] +libcutils.so 0x6F900000 # [~1M] +libthread_db.so 0x6F800000 # [<64K] +libz.so 0x6F700000 # [~1M] +libevent.so 0x6F600000 # [???] +libssl.so 0x6F400000 # [~2M] +libcrypto.so 0x6F000000 # [~4M] +libsysutils.so 0x6EF00000 # [~1M] + +# bluetooth +liba2dp.so 0x6EE00000 # [~1M] +audio.so 0x6ED00000 # [~1M] +input.so 0x6EC00000 # [~1M] +libbluetoothd.so 0x6EA00000 # [~2M] +libbluedroid.so 0x6E900000 # [<64K] +libbluetooth.so 0x6E800000 # [~1M] +libdbus.so 0x6E700000 # [~1M] + +# extended system libraries +libril.so 0x6E600000 # [~1M] +libreference-ril.so 0x6E500000 # [~1M] +libwpa_client.so 0x6E400000 # [<64K] +libnetutils.so 0x6E300000 # [~1M] + +# core dalvik runtime support +libandroid_servers.so 0x6E200000 # [~1M] +libicuuc.so 0x6DE00000 # [~4M] +libicui18n.so 0x6D900000 # [~5M] +libandroid_runtime.so 0x6D300000 # [~6M] +libnativehelper.so 0x6D100000 # [~2M] +libdvm-ARM.so 0x6D000000 # [???] +libdvm.so 0x6CA00000 # [~6M] +# Note: libicudata.so intentionally omitted + +# graphics +libpixelflinger.so 0x6C900000 # [~1M] +# libcorecg is for backward-compatibility with donut +libcorecg.so 0x6C800000 # [???] +libsurfaceflinger_client.so 0x6C700000 # [~1M] +libsurfaceflinger.so 0x6C500000 # [~2M] +libGLES_android.so 0x6C400000 # [~1M] +libagl.so 0x6C300000 # [???] + +libGLESv1_CM.so 0x6C200000 # [~1M] +libGLESv2.so 0x6C100000 # [~1M] +libOpenVG_CM.so 0x6C000000 # [???] +libOpenVGU_CM.so 0x6BF00000 # [???] +libEGL.so 0x6BE00000 # [~1M] +libETC1.so 0x6BD00000 # [<64K] + +libacc.so 0x6BC00000 # [~1M] + +libexif.so 0x6BB00000 # [~1M] +libcamera_client.so 0x6BA80000 # [~1M] +libui.so 0x6B900000 # [~1M] +libgui.so 0x6B800000 # [~1M] +libskia.so 0x6B100000 # [~2M] +librs_jni.so 0x6B000000 # [~1M] +libRS.so 0x69E00000 # [~2M] +libandroid.so 0x69D80000 # [<64K] +libjnigraphics.so 0x69D00000 # [<64K] +libskiagl.so 0x69C00000 # [~1M] + +# audio +libFLAC.so 0x69B00000 # [???] +libaudiopolicy.so 0x69A00000 # [~1M] +libeffects.so 0x69980000 # [<64K] +libaudioeffect_jni.so 0x69900000 # [<64K] +libsoundpool.so 0x69800000 # [~1M] +libaudio.so 0x69700000 # [~1M] +libspeech.so 0x69600000 # [~1M] +libsonivox.so 0x69500000 # [~1M] +libvorbisidec.so 0x69400000 # [~1M] +libmedia_jni.so 0x69300000 # [~1M] +libmediaplayerservice.so 0x69200000 # [~1M] +libmedia.so 0x69000000 # [~2M] +libFFTEm.so 0x68F00000 # [~1M] +libSR_AudioIn.so 0x68E00000 # [~1M] for external/srec +libaudioflinger.so 0x68D00000 # [~1M] + +# assorted system libraries +libsqlite.so 0x68B00000 # [~2M] +libexpat.so 0x68A00000 # [~1M] +libwebcore.so 0x68300000 # [~7M] +libbinder.so 0x68200000 # [~1M] +libutils.so 0x68100000 # [~1M] +libcameraservice.so 0x68000000 # [~1M] +libhardware.so 0x67F00000 # [<64K] +libhardware_legacy.so 0x67E00000 # [~1M] +libapp_process.so 0x67D00000 # [???] +libsystem_server.so 0x67C00000 # [~1M] +libime.so 0x67B00000 # [???] +libgps.so 0x67A00000 # [~1M] +libcamera.so 0x67900000 # [~1M] +liboemcamera.so 0x67700000 # [~2M] +libdiskconfig.so 0x67600000 # [<64K] +libemoji.so 0x67500000 # [<64K] +libjni_latinime.so 0x67400000 # [~1M] +libjni_pinyinime.so 0x67300000 # [~1M] +libttssynthproxy.so 0x67200000 # [~1M] for frameworks/base +libttspico.so 0x67000000 # [~2M] for external/svox + +# pv libraries +libpvasf.so 0x66F00000 # [???] +libpvasfreg.so 0x66E00000 # [???] +libomx_sharedlibrary.so 0x66D00000 # [~1M] +libopencore_download.so 0x66C00000 # [~1M] +libopencore_downloadreg.so 0x66B00000 # [~1M] +libopencore_net_support.so 0x66800000 # [~3M] +libopencore_rtsp.so 0x66200000 # [~6M] +libopencore_rtspreg.so 0x66100000 # [~1M] +libopencore_author.so 0x65D00000 # [~4M] +libomx_aacdec_sharedlibrary.so 0x65B00000 # [~2M] +libomx_amrdec_sharedlibrary.so 0x65A00000 # [~1M] +libomx_amrenc_sharedlibrary.so 0x65900000 # [~1M] +libomx_avcdec_sharedlibrary.so 0x65800000 # [~1M] +libomx_avcenc_sharedlibrary.so 0x65700000 # [???] +libomx_m4vdec_sharedlibrary.so 0x65600000 # [~1M] +libomx_m4venc_sharedlibrary.so 0x65500000 # [???] +libomx_mp3dec_sharedlibrary.so 0x65400000 # [~1M] +libopencore_mp4local.so 0x65200000 # [~2M] +libopencore_mp4localreg.so 0x65100000 # [~1M] +libopencore_player.so 0x64800000 # [~9M] + +# opencore hardware support +libmm-adspsvc.so 0x64700000 # [<64K] +libOmxCore.so 0x64600000 # [<64K] +libOmxMpeg4Dec.so 0x64500000 # [~1M] +libOmxH264Dec.so 0x64400000 # [~1M] +libOmxVidEnc.so 0x64300000 # [~1M] +libopencorehw.so 0x64200000 # [~1M] +libOmxVdec.so 0x64100000 # [~1M] +libmm-omxcore.so 0x64000000 # [<64K] + +# pv libraries +libopencore_common.so 0x63900000 # [~7M] +libqcomm_omx.so 0x63800000 # [<64K] + +# stagefright libraries +libstagefright_amrnb_common.so 0x63700000 # [~1M] +libstagefright_avc_common.so 0x63600000 # [~1M] +libstagefright_color_conversion.so 0x63500000 # [<64K] +libstagefright_omx.so 0x63400000 # [~1M] +libstagefrighthw.so 0x63300000 # [~1M] +libstagefright.so 0x62F00000 # [~4M] + +# libraries for specific hardware +libgsl.so 0x62E00000 # [~1M] +libhtc_acoustic.so 0x62D00000 # [<64K] +libhtc_ril.so 0x62C00000 # [~1M] +liblvmxipc.so 0x62B00000 # [~1M] for vendor/nxp +libreference-cdma-sms.so 0x62A00000 # [<64K] for hardware/ril + +# libraries for specific apps or temporary libraries +libcam_ipl.so 0x5F000000 # [???] +libwbxml.so 0x5EF00000 # [???] +libwbxml_jni.so 0x5EE00000 # [~1M] +libxml2wbxml.so 0x5EB00000 # [~1M] +libdrm1.so 0x5EA00000 # [~1M] +libdrm1_jni.so 0x5E900000 # [<64K] +libwapcore.so 0x5E800000 # [???] +libstreetview.so 0x5E700000 # [???] +libwapbrowsertest.so 0x5E600000 # [???] +libminiglobe.so 0x5E500000 # [???] +libearth.so 0x5E400000 # [???] +libembunit.so 0x5E300000 # [<64K] +libneon.so 0x5E200000 # [???] +libjni_example.so 0x5E100000 # [???] +libjni_load_test.so 0x5E000000 # [???] +libjni_lib_test.so 0x5DF00000 # [???] +librunperf.so 0x5DE00000 # [???] +libctest.so 0x5DD00000 # [<64K] +libUAPI_jni.so 0x5DC00000 # [???] +librpc.so 0x5DB00000 # [~1M] +libtrace_test.so 0x5DA00000 # [???] +libsrec_jni.so 0x5D800000 # [~2M] +libjpeg.so 0x5D700000 # [~1M] +libiprouteutil.so 0x5D600000 # [~1M] for external/iproute2 +libnetlink.so 0x5D500000 # [<64K] for external/iproute2 +libpagemap.so 0x5D400000 # [<64K] for system/extras/libpagemap +libstlport.so 0x5D100000 # [~3M] for external/stlport +libzxing.so 0x5D000000 # [<64K] for goggles +libinterstitial.so 0x5CF00000 # [<64K] for goggles +liblept.so 0x5CA00000 # [~5M] for external/leptonica diff --git a/tools/apriori/Android.mk b/tools/apriori/Android.mk index 79ecf7f..04d099f 100644 --- a/tools/apriori/Android.mk +++ b/tools/apriori/Android.mk @@ -29,7 +29,9 @@ LOCAL_CFLAGS += -DFSCANF_IS_BROKEN LOCAL_LDLIBS += -lintl endif - +ifeq ($(TARGET_USES_2G_VM_SPLIT),true) +LOCAL_CFLAGS += -DVM_SPLIT_2G +endif LOCAL_SRC_FILES := \ apriori.c \ diff --git a/tools/apriori/prelinkmap.c b/tools/apriori/prelinkmap.c index 9fb00e4..0ab506c 100644 --- a/tools/apriori/prelinkmap.c +++ b/tools/apriori/prelinkmap.c @@ -24,8 +24,13 @@ static mapentry *maplist = 0; prelink map, or the prelink step will fail. */ +#ifdef VM_SPLIT_2G +#define PRELINK_MIN 0x50000000 +#define PRELINK_MAX 0x6FFFFFFF +#else #define PRELINK_MIN 0x90000000 #define PRELINK_MAX 0xBFFFFFFF +#endif void pm_init(const char *file) { All credit goes to KK for the patch (Presuming he did write it). I was going to do the same thing knowing its possible. The reason for no VM_SPLIT_2G is not technical.vmsplit_2g_patch.zip Link to comment Share on other sites More sharing options...
Guest unrandomsam Posted June 19, 2011 Report Share Posted June 19, 2011 Actually I missed a bit (its in bionic as well) commit c0419feb8c6e43e7decdb87ae3fdb79091791f81 Author: kallt_kaffe <[email protected]> Date: Sun May 1 20:43:38 2011 +0200 Added VMSPLIT_2G support. diff --git a/linker/Android.mk b/linker/Android.mk index c4447bb..b6388c6 100644 --- a/linker/Android.mk +++ b/linker/Android.mk @@ -14,12 +14,17 @@ ifeq ($(TARGET_ARCH),sh) # SH-4A series virtual address range from 0x00000000 to 0x7FFFFFFF. LINKER_TEXT_BASE := 0x70000100 else + ifneq ($(TARGET_USES_2G_VM_SPLIT),true) # This is aligned to 4K page boundary so that both GNU ld and gold work. Gold # actually produces a correct binary with starting address 0xB0000100 but the # extra objcopy step to rename symbols causes the resulting binary to be misaligned # and unloadable. Increasing the alignment adds an extra 3840 bytes in padding # but switching to gold saves about 1M of space. -LINKER_TEXT_BASE := 0xB0001000 + LINKER_TEXT_BASE := 0xB0001000 + else + LINKER_TEXT_BASE := 0x70001000 + LOCAL_CFLAGS += -DVM_SPLIT_2G + endif endif # The maximum size set aside for the linker, from diff --git a/linker/linker.h b/linker/linker.h index 68ac275..8596973 100644 --- a/linker/linker.h +++ b/linker/linker.h @@ -159,6 +159,10 @@ extern soinfo libdl_info; #define LIBBASE 0x60000000 #define LIBLAST 0x70000000 #define LIBINC 0x00100000 +#elif defined(VM_SPLIT_2G) +#define LIBBASE 0x40000000 +#define LIBLAST 0x50000000 +#define LIBINC 0x00100000 #else #define LIBBASE 0x80000000 #define LIBLAST 0x90000000vmsplit2g_2_patch.zip Link to comment Share on other sites More sharing options...
Guest unrandomsam Posted June 19, 2011 Report Share Posted June 19, 2011 Then put TARGET_USES_2G_VM_SPLIT := true into the board config Link to comment Share on other sites More sharing options...
Guest Simon O Posted June 19, 2011 Report Share Posted June 19, 2011 If you want to build CyanogenMod 7 from source with those changes then you are most welcome to do that yourself. The whole point of this thread is to inform people that mixing and matching parts of the ZTE leak with the official blade CM7 will not work. At all. The ZTE gingerbread leak is not the magic fix everyone thinks it is. For the CM7 developers it's practically useless. For you guys, it has some uses if you want to hack things about in your own time. I'm locking this thread before things get out of hand. Link to comment Share on other sites More sharing options...
Recommended Posts