• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

CyanogenMod 9 Development thread, Sources, and Discussions

Status
Not open for further replies.
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.
 
Upvote 0
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
 
  • Like
Reactions: HiiiPowers
Upvote 0
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;
}
}
 
  • Like
Reactions: Deleted User
Upvote 0
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,
},
};
 
Upvote 0
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
 
Upvote 0
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
 
Upvote 0
please explain bro

"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.
 
Upvote 0
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
 
Upvote 0
Status
Not open for further replies.

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones