how to update vmalloc space in SDK 1.7

cancel
Showing results for 
Search instead for 
Did you mean: 

how to update vmalloc space in SDK 1.7

Jump to solution
1,561 Views
tbowen
Contributor II

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

Labels (1)
1 Solution
343 Views
tbowen
Contributor II

Found the problem ... I have to manually perform a "Save" to ".config" during menuconfig.  I'm not accustomed to that extra step.  Also, I'm not sure why part of my config changes are saved ...

View solution in original post

0 Kudos
1 Reply
344 Views
tbowen
Contributor II

Found the problem ... I have to manually perform a "Save" to ".config" during menuconfig.  I'm not accustomed to that extra step.  Also, I'm not sure why part of my config changes are saved ...

View solution in original post

0 Kudos