AnsweredAssumed Answered

how to update vmalloc space in SDK 1.7

Question asked by Trevor Bowen on Jan 22, 2015
Latest reply on Jan 22, 2015 by Trevor Bowen

Background:

 

We have recently upgraded our board (similar to the P2020RDB) to use a 256MB NOR flash, up from 64MB NOR.  During boot, the kernel complains about not being able to vmalloc enough space to cover the increased 256MB NOR:

 

Memory: 2005736K/2097152K available (5828K kernel code, 304K rwdata, 1604K rodata, 248K init, 183K bss, 91416K reserved, 1310716K highmem)

Kernel virtual memory layout:

  * 0xfffbf000..0xfffff000  : fixmap

  * 0xff800000..0xffc00000  : highmem PTEs

  * 0xff7fc000..0xff800000  : early ioremap

  * 0xf1000000..0xff7fc000  : vmalloc & ioremap

...

vmap allocation for size 268439552 failed: use vmalloc=<size> to increase size.

of-flash e0000000.nor: Failed to ioremap() flash region

of-flash: probe of e0000000.nor failed with error -12

 

Based on this forum thread:

 

How can I get more vmalloc/ioremap space?

 

We previously (LTIB-era) shifted the page_offset / task_size boundary to allow for more kernel and vmalloc space with the following kernel-config subsection:

 

#

# Advanced setup

#

CONFIG_ADVANCED_OPTIONS=y

CONFIG_LOWMEM_SIZE_BOOL=y

CONFIG_LOWMEM_SIZE=0x30000000

# CONFIG_LOWMEM_CAM_NUM_BOOL is not set

CONFIG_LOWMEM_CAM_NUM=3

# CONFIG_RELOCATABLE is not set

CONFIG_PAGE_OFFSET_BOOL=y

CONFIG_PAGE_OFFSET=0xa0000000

CONFIG_KERNEL_START_BOOL=y

CONFIG_KERNEL_START=0xa0000000

# CONFIG_PHYSICAL_START_BOOL is not set

CONFIG_PHYSICAL_START=0x00000000

CONFIG_PHYSICAL_ALIGN=0x04000000

CONFIG_TASK_SIZE_BOOL=y

CONFIG_TASK_SIZE=0xa0000000

CONFIG_NET=y

 

We recently updated to the latest SDK 1.7, which also exhibits the same VMALLOC era.  So, after a full Yocto/SDK-1.7 build for the P2020RDB, I have tried to modify the kernel config with the above options by following these directions:

 

Linux Kernel

 

Which are in short:

 

$ cd <SDK-V1.7>/poky/build_p2020rdb_release

$ bitbake -c menuconfig virtual/kernel

<... make above changes via Advanced menu ...>

$ bitbake -c compile -f virtual/kernel

$ bitbake virtual/kernel

$ cp -L tmp/deploy/images/p2020rdb/uImage <TFTP server path to test new kernel>

 

Problem:

 

Here's the problem:  Many of my changes persist and are included in the new kernel.  However, several changes - SquashFS, disabling unused file-systems, enable timestamp in printk and most importantly adding the above advanced options - are lost!  If I run menuconfig again, I see that they are missing. ... It appears that specific kernel config options - not all - are overwritten as part of each build.

 

How do I stop this behavior and force my changes to be included in the new kernel?

 

Thanks!

 

Trevor

Outcomes