2008-04-02 09:39:47     Memory allocation problem in uClinux-2007R1-RC3

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

2008-04-02 09:39:47     Memory allocation problem in uClinux-2007R1-RC3

svs k (INDIA)

Message: 53541   

 

Hi all,

 

kindly help.

 

  I m working in a custom bf533 board in uClinux-2007R1 distribution. I have written a custom driver for LCD according to our specifications.I have an User application that has two buffers Buffer 1 of size 153600 and Buffer 2 of size 230400 bytes respectively. One of the buffers (that is of size 230400) is needed to be copied to a Kernel buffer of LCD driver at run time. I m using write() for this.  I observed following things. Before that, My custom board has been enabled for 64M

 

case 1:

 

Buffer 1 address = 0x3080c88  (153600 bytes)

Buffer 2 Address = 0x30A6568(230400 bytes)

 

In this case,  write() (for Buffer 2) call from the user application is not at all entering into kernel write() to which i have mapped in my custom driver. write() in user application returns -1.

 

case 2:

 

Second time, a small change in the code (even asm("nop;")) makes buffer to be allocated as follows.

 

Buffer 1 address = 0x880c88 (153600 bytes)

Buffer 2 Address  = 0x8a6568 (230400 bytes)

 

In this case it is working fine.  write() call is entering into kernel write() function. write() returns the number of bytes written to the kernel.

 

 

 

why the memory allocation affects the kernel call.? Kindly help

 

 

 

I have attached "cat /proc/cplbinfo" result with this message. uImage booting is as follows

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Bytes transferred = 2779641 (2a69f9 hex)

## Booting image at 01200000 ...

   Image Name:   uClinux Kernel and ext2

   Created:      2008-04-02  11:31:10 UTC

   Image Type:   Blackfin Linux Kernel Image (gzip compressed)

   Data Size:    2779577 Bytes =  2.7 MB

   Load Address: 00300000

   Entry Point:  00300000

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

Starting Kernel at = 300000

Linux version 2.6.19.3-ADI-2007R1-svn (xxx@Hteam) (gcc version 4.1.1 (ADI

07R1)) #52 Wed Apr 2 17:00:49 IST 2008

Blackfin support (C) 2004-2006 Analog Devices, Inc.

Compiled for ADSP-BF533 Rev. 0.5

Blackfin uClinux support by http://blackfin.uclinux.org/

Processor Speed: 594 MHz core clock and 118 Mhz System Clock

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

  text      = 0x00300000-0x0040f044

  init      = 0x00410000-0x0041e8a8

  data      = 0x004247bc-0x0045b288

  stack     = 0x00426000-0x00428000

  bss       = 0x0045b290-0x006a905c

  available = 0x006a905c-0x03300000

  rootfs    = 0x03300000-0x03f00000

  DMA Zone  = 0x03f00000-0x04000000

Instruction Cache Enabled

Data Cache Enabled (write-back)

Hardware Trace Enabled

Built 1 zonelists.  Total pages: 12954

Kernel command line: root=/dev/mtdblock0 rw,console=ttyBF0,57600

Configuring Blackfin Priority Driven Interrupts

PID hash table entries: 256 (order: 8, 1024 bytes)

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Physical pages: 3300

Memory available: 44800k/61294k RAM, (58k init code, 1084k kernel code, 2359k da

ta, 1024k dma)

Blackfin Scratchpad data SRAM: 4 KB

Blackfin DATA_A SRAM: 16 KB

Blackfin DATA_B SRAM: 16 KB

Blackfin Instruction SRAM: 64 KB

Security Framework v1.0.0 initialized

Capability LSM initialized

Mount-cache hash table entries: 512

NET: Registered protocol family 16

Blackfin GPIO Controller

Blackfin DMA Controller

ezkit_init(): registering device resources

NET: Registered protocol family 2

IP route cache hash table entries: 512 (order: -1, 2048 bytes)

TCP established hash table entries: 2048 (order: 1, 8192 bytes)

TCP bind hash table entries: 1024 (order: 0, 4096 bytes)

TCP: Hash tables configured (established 2048 bind 1024)

TCP reno registered

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler cfq registered

LCD:Driver enabled

 

Single Core  Loader Module enabled

Dynamic Power Management Controller Driver v0.1: major=10, minor = 254

Serial: Blackfin serial driver

bfin-uart.1: ttyBF0 at MMIO 0xffc00400 (irq = 21) is a BFIN-UART

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

Network interface: "eth0"ret value from smsc911x_drv_probe Func is 0

uclinux[mtd]: RAM probe address=0x3300000 size=0xc00000

Creating 1 MTD partitions on "RAM":

0x00000000-0x00c00000 : "ROMfs"

uclinux[mtd]: set ROMfs:EXT2  to be root filesystem

rtc-bfin rtc-bfin: rtc intf: sysfs

rtc-bfin rtc-bfin: rtc intf: proc

rtc-bfin rtc-bfin: rtc intf: dev (254:0)

rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

rtc-bfin rtc-bfin: setting the system clock to 1997-09-02 18:42:47 (873225767)

VFS: Mounted root (ext2 filesystem) readonly.

Freeing unused kernel memory: 56k freed (0x410000 - 0x41d000)

dma_alloc_init: dma_page @ 0x00419000 - 256 pages at 0x03f00000

 

Welcome to:

       ____ _  _

      /  __| ||_|             _  _

_   _| |  | | _ ____  _   _ \ \/ /

| | | | |  | || |  _ \| | | | \  /

| |_| | |__| || | | | | |_| | /  \

|  ___\____|_||_|_| |_|\____|/_/\_\

|_|

 

For further information see:

http://www.uclinux.org/

http://blackfin.uclinux.org/

 

 

 

BusyBox v1.4.1 (2008-04-02 15:27:36 IST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

 

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

 

 

 

 

 

 

 

 

 

 

 

 

cplbinfo.txt

cplbinfo.txt

QuoteReplyEditDelete

 

 

2008-04-02 11:09:26     Re: Memory allocation problem in uClinux-2007R1-RC3

Mike Frysinger (UNITED STATES)

Message: 53553    you would need to trace the kernel and find out where the -1 is coming from

 

also, it sounds like a lot of wasted overhead of copying buffers.  the lcd driver should be managing the buffers, not user space.  if you need a scratch buffer to do updates in, then you should be using double buffering, not single.

Attachments

Outcomes