1. In regards to recently combined carrier specific root forums, if your device forum was affected, please see this poll/thread!

CyanogenMod 9 Development thread, Sources, and Discussions


  1. Dm47021

    Dm47021 Well-Known Member Developer

    This thread is to be used for CyanogenMod 9 for Zte Warp Development.

    Advertisement
  2. Dm47021

    Dm47021 Well-Known Member Developer

    I have been messing with the pmem alot today and yesterday, this is where i am at

    #define MSM_PMEM_SF_SIZE 0xE10000 Gives 122MB ????
    0xB00000 Gives 148MB
    0x0B0000 Gives 135MB
    0xB50000 Unusable / Extremly Slow even w Swap
    0xA????? Wont Boot Any A values
    0xC00000 Gives 147MB
    0xD00000 Gives 146MB
    0xE00000 Gives 145MB
    0xF00000 Gives 144MB
    0xBAAAAA NO BOOT / RED LIGHT
    0xF NO BOOT / Odd Loop
    0x8B0000 Gives 118MB
    0XBBBBBB NO BOOT / RED LIGHT


    B seems to be the maximum Value we can use, in most cases F is larger than B, but of course with zte, B is actually Larger than F... it also appears to be reading it backwards. correct me if iam wrong.
  3. downthemachine

    downthemachine Developer Incognito VIP Member

    I still stand by the thought that its the rom
  4. Dm47021

    Dm47021 Well-Known Member Developer

    iam really really leaning that direction myself, or its in our device tree under /includes/linux there is pmem.h and ashmem there
  5. downthemachine

    downthemachine Developer Incognito VIP Member

    Pretty sure its how the is sees the ram.
  6. Dm47021

    Dm47021 Well-Known Member Developer

    i did try something, and now it boots alot faster, instead of waiting 30 seconds on a black screen before boot animation, now its instant.

    Copy the android_pmem.h from the kernel you use into /device/zte/arthur/include/ replacing the android_pmem.h that came with CyanogenMod.

    i was able to get up to 152mb, thats the most before it wont boot

    *****Edit******
    Well, looks like our speculation is correct, I just read that CM9/CM10 have a massive Memory leak, reading how to possibly fix it now
    HiiiPowers likes this.
  7. Dm47021

    Dm47021 Well-Known Member Developer

    Found this in the Board-msm7x30.c of the 3.0.8 Kernel

    Just After

    static void __init msm7x30_init_early(void)
    {
    msm7x30_allocate_memory_regions();
    }

    THIS IS WHAT ZTE ADDED

    #if defined(CONFIG_ZTE_PLATFORM) && defined(CONFIG_F3_LOG)
    unsigned int len = 0;
    smem_global *global_tmp = (smem_global *)(MSM_RAM_LOG_BASE + PAGE_SIZE) ;

    len = global_tmp->f3log;

    pr_info("length for f3 log is %d ++ \n", len);

    if (len > 12)
    {
    len = 12;
    }
    else
    {
    len = len/2*2;
    }

    pr_info("length = %d -- \n", len);
    size = len;

    if (size)
    {
    reserve_bootmem(SDLOG_MEM_BASE, size * 0x100000, BOOTMEM_DEFAULT);
    }

    addr = phys_to_virt(SDLOG_MEM_BASE);
    pr_info("allocating %lu M at %p (%lx physical) for F3\n",size, addr, __pa(addr));

    #endif

    #ifdef CONFIG_ZTE_PLATFORM
    #define ATAG_ZTEFTM 0x5d53cd73
    static int parse_tag_zteftm(const struct tag *tags)
    {
    int flag = 0, find = 0;
    struct tag *t = (struct tag *)tags;

    for (; t->hdr.size; t = tag_next(t)) {
    if (t->hdr.tag == ATAG_ZTEFTM) {
    printk(KERN_DEBUG "find the zte ftm tag\n");
    find = 1;
    break;
    }
    }

    if (find)
    flag = t->u.revision.rev;
    printk(KERN_INFO "jiangfeng:parse_tag_zteftm: zte FTM %s !\n", flag?"enable":"disable");
    return flag;
    }

    static void __init zte_fixup(struct machine_desc *desc, struct tag *tags,
    char **cmdline, struct meminfo *mi)
    {
    g_zte_ftm_flag_fixup = parse_tag_zteftm((const struct tag *)tags);
    }

    int get_ftm_from_tag(void)
    {
    return g_zte_ftm_flag_fixup;
    }
    EXPORT_SYMBOL(get_ftm_from_tag);

    #endif

    static void __init msm7x30_fixup(struct machine_desc *desc, struct tag *tags,
    char **cmdline, struct meminfo *mi)
    {
    #if 0

    JUST BEFORE

    for (; tags->hdr.size; tags = tag_next(tags)) {
    if (tags->hdr.tag == ATAG_MEM && tags->u.mem.start ==
    DDR1_BANK_BASE) {
    ebi1_phys_offset = DDR1_BANK_BASE;
    phys_add = DDR1_BANK_BASE;
    break;
    }
    }
    downthemachine likes this.
  8. Dm47021

    Dm47021 Well-Known Member Developer

    JUST AFTER
    define DDR1_BANK_BASE 0X20000000
    #define DDR2_BANK_BASE 0X40000000

    static unsigned int phys_add = DDR2_BANK_BASE;
    unsigned long ebi1_phys_offset = DDR2_BANK_BASE;
    EXPORT_SYMBOL(ebi1_phys_offset);

    struct pm8xxx_gpio_init_info {
    unsigned gpio;
    struct pm_gpio config;
    };

    ZTE ADDED

    #if defined(CONFIG_ZTE_PLATFORM)
    static smem_global *global;

    static int g_zte_ftm_flag_fixup;
    static int g_zte_board_id_type;
    int get_zte_board_id_type(void);
    extern void sync_sysfs_board_id(int flag);

    #if defined(CONFIG_F3_LOG)
    #define SDLOG_MEM_BASE 0x8D00000
    #endif

    #endif

    #ifdef CONFIG_ANDROID_RAM_CONSOLE
    #define MSM_RAM_CONSOLE_PHYS 0x3D00000
    #define MSM_RAM_CONSOLE_SIZE SZ_1M
    static struct resource ram_console_resource[] = {
    {
    .start = MSM_RAM_CONSOLE_PHYS,
    .end = MSM_RAM_CONSOLE_PHYS + MSM_RAM_CONSOLE_SIZE - 1,
    .flags = IORESOURCE_MEM,
    },
    };

    static struct platform_device ram_console_device = {
    .name = "ram_console",
    .id = -1,
    .num_resources = ARRAY_SIZE(ram_console_resource),
    .resource = ram_console_resource,
    };
    #endif

    JUST BEFORE

    static int pm8058_gpios_init(void)
    {
    int rc;

    struct pm8xxx_gpio_init_info sdc4_en = {
    PM8058_GPIO_PM_TO_SYS(PMIC_GPIO_SDC4_EN_N),
    {
    .direction = PM_GPIO_DIR_OUT,
    .pull = PM_GPIO_PULL_NO,
    .vin_sel = PM8058_GPIO_VIN_L5,
    .function = PM_GPIO_FUNC_NORMAL,
    .inv_int_pol = 0,
    .out_strength = PM_GPIO_STRENGTH_LOW,
    .output_value = 0,
    },
    };
  9. mercury0x000d

    mercury0x000d The ultra-modern operator Guide

    I don't suppose the memory issue has anything to do with the endianess of the processor? I haven't yet reviewed the source thoroughly, but it's just a thought. In my experience that is a common occurance when porting from one platform to another, and it sometimes causes the symptoms you're seeing here.
  10. Dm47021

    Dm47021 Well-Known Member Developer

    please explain bro
  11. downthemachine

    downthemachine Developer Incognito VIP Member

    Why wouldn't the HTC thunderbolt, Motorola triumph, etc have those issue when they built cm9?
  12. Dm47021

    Dm47021 Well-Known Member Developer

    Well iam working on a 3.4 Kernel strait from Code Aurora Forums.
    none of that zte sh**..
    iam still deciding if iam going to keep the ZTE logo.bmp format, or use the standard rle format.
    i specify that in /drivers/video/msm/mdp4

    the board is much cleaner, the kernel is overall 99% free of any zte code, except touch screen
  13. Dm47021

    Dm47021 Well-Known Member Developer

    in /arch/arm/mach-msm/kconfig

    # ZTE_PLATFORM
    config ZTE_3_CHANNEL_6G_DDR_CFG1
    depends on ARCH_MSM7X30
    depends on !MSM_STACKED_MEMORY
    default y
    bool "ZTE make a little 3 ch 6G DDR revise."
    help
    Support for ZTE 3 ch 6G DDR revice.

    config ZTE_PLATFORM
    depends on ARCH_MSM7X30
    depends on !MSM_STACKED_MEMORY
    default y
    bool "ZTE Platform."
    help
    Support for the ZTE Platform.


    Apparently the DDR memory is running in Tripple Channel Mode
  14. mercury0x000d

    mercury0x000d The ultra-modern operator Guide

    "Endianness" refers to the order in which data is stored in memory - and therefore viewed by the processor. For example, on the Intel architecture, if you store the 32 bit value 0x01020304 at the address 0xE10B, you would have:

    04 stored at address 0xE10B
    03 stored at address 0xE10C
    02 stored at address 0xE10D
    01 stored at address 0xE10E

    This is called "little-endian." Now, the same thing on a Motorola processor (which is "big-endian") would yield:

    01 stored at address 0xE10B
    02 stored at address 0xE10C
    03 stored at address 0xE10D
    04 stored at address 0xE10E

    Since the two are diametrically opposed to each other, the data order must be reversed when porting across platforms. For most simple variables defined in the source, this won't apply, since the compiler will handle the difference automatically. But in places where the programmer has explicitly laid the data out in the pattern expected by the processor, this can be an issue since the compiler most likely won't know any better and will do zero endian modification on it. I know the ARM architecture is bi-endian, but defaults to little unless told otherwise. Again, not sure if this is in fact the issue, but maybe just something to keep in mind.
  15. Dm47021

    Dm47021 Well-Known Member Developer

    thats a good theory, but i dont think it runs that deep lol, ive been digging and the problem starts and ends with ZTE. theres alot of #ifdef ZTE_PLATFORM, and
    ddr and memory things... its something they did to the board file.
  16. downthemachine

    downthemachine Developer Incognito VIP Member

    Honestly I think its ion. Android 4.0 and up has been using ion instead of qualcomms pmem.
  17. Dm47021

    Dm47021 Well-Known Member Developer

    i almost have ion running now, i have to fully implement it into the board, or we can use the 3.4 caf board, if you can help me solve the error with ldo_sensors_init. compiles in 3.4 fine

    added into the device files, it boots, it says android updating, then reboots and loops forever..cuz libGralloc using ION but its not set up all the way on the board
  18. downthemachine

    downthemachine Developer Incognito VIP Member

    It will be awhile before I'm back. Just got a ps3, and I'm in the middle of a huge investigation on af
  19. Dm47021

    Dm47021 Well-Known Member Developer

    what do you mean huge investigation?
  20. mercury0x000d

    mercury0x000d The ultra-modern operator Guide

    I agree, and if that were the case, why didn't it happen on other platforms, too? Hmm...

Share This Page