Hi Amit, Thanks for the prompt and detailed explanation.
I had the same understanding, but now I have experienced a different behavior with Pandaboard ES (OMAP- 4460). I have declared a global static variable as (in my project) :- static char utcb[THREADS_TOTAL * ( 13 )] L4_ALIGN(UTCB_SIZE); With this, my program got executed successfully. The logs were as follows:- code0: Mapping 0x3000 bytes as RX from 0x84000000 physical to 0xc0000000 virtual for project0 code0: Mapping 0x2000 bytes as RW from 0x84003000 physical to 0xc0003000 virtual for project0 In __l4_threadlib_init c0003100 = address of utcb ( starting address of array ) c0004e28 = address of &utcb + 1 ( last address of array ) Thus as we can see address accessed was 0xc0004e28 which is within the permissible range of ( 0xc0003000 + 0x2000 = 0xc0005000 ) When I modified it as follows:- static char utcb[THREADS_TOTAL * ( 14 )] L4_ALIGN(UTCB_SIZE); The logs were as follows:- code0: Mapping 0x3000 bytes as RX from 0x84000000 physical to 0xc0000000 virtual for project0 code0: Mapping 0x2000 bytes as RW from 0x84003000 physical to 0xc0003000 virtual for project0 In __l4_threadlib_init c0003100 = address of utcb ( starting address of array ) c0004f28 = address of &utcb + 1 ( last address of array ) Thus as we can see address accessed was 0xc0004f28 which is within the permissible range of ( 0xc0003000 + 0x2000 = 0xc0005000 ) But When I modified it as follows:- static char utcb[THREADS_TOTAL * ( 15 )] L4_ALIGN(UTCB_SIZE); It caused kernel panic The logs were as follows:- code0: Mapping 0x3000 bytes as RX from 0x84000000 physical to 0xc0000000 virtual for project0 code0: Mapping 0x2000 bytes as RW from 0x84003000 physical to 0xc0003000 virtual for project0 fault_ipc_to_pager: Sending ipc from 1 to 1, faulty_address=0xc0005060, faulty pc=0xc00016a8 tid=0x00000001 Unhandled kernel data abort at address 0x00000008 FAR:0x00000008 PC:0xf000e380 Unhandled kernel abort. Kernel panic. Halting system... Here, the array had an address range of 0xc0003100 till 0xc0005028 ( 0xc0004f28 + 100 ) which lies beyond the permissible range 0xc0003000 to 0xc0005000 ( 0xc0003000 + 0x2000 - as seen from kernel logs). [ Please Note :- The address 0xc0005060, as seen in logs , is for some different variable, which might have been assigned addresses successive to the array ] Hence, I understand that the memory for the RX section did not increase which should have been with increase of size of my global variables. Please let me if I need to make any changes in config file or build script for the proper execution of the program. Regards, Ayan Kumar Halder On Mon, Jul 9, 2012 at 7:11 PM, Amit Mahajan < [email protected]>wrote: > Hi Ayan, > > The pages/bytes going into various sections is not a harcoded value. At > the time of compilation of system, elf files are made for various > containers. The toolchain divides the elf file into various sections and > codezero system just loads the various sections with proper permissions > at run time. > > So, all this is automatically generated based on the code, > static/globals/const etc in your code. If you want to increase any > section introduce mode code/more variables which comes under that > section. > > > > > On Mon, 2012-07-09 at 18:31 +0530, AYAN KUMAR HALDER wrote: > > Hi, > > > > When I execute the "Hello World" program, I see that the 0x3000 bytes > > have been allocated to RX memory and 0x2000 bytes have been allocated > > to RW memory. I want to know , how to change this memory allocation to > > 0x5000 bytes for RX memory and 0x6000 bytes to RW memory( for > > example) . Please help me. > > > > Please find the kernel logs below for your reference:- > > > > > > Hit any key to stop autoboot: 0 > > mmc read: Invalid size > > > > 375294- 0xbc547fbc > > Loading the kernel... > > Entry point: 0x80008000 > > Copying to range from 0x80008000 to 0x80025018 of size: 0x1d018 > > Clearing memory... starting from 80025018, size: 6ff8 > > Copying to range from 0x80030000 to 0x8003c1b8 of size: 0xc1b8 > > Clearing memory... starting from 8003c1b8, size: 0 > > > > Loading containers... > > > > Loading section .cont.0 from top-level elf file. > > Loading .img.0 section image... > > Entry point: 0xc0000000 > > Copying to range from 0x84002244 to 0x8400224c of size: 0x8 > > Clearing memory... starting from 8400224c, size: 0 > > Copying to range from 0x84000000 to 0x8400224c of size: 0x224c > > Clearing memory... starting from 8400224c, size: 0 > > Copying to range from 0x84003000 to 0x840030b4 of size: 0xb4 > > Clearing memory... starting from 840030b4, size: 1cb0 > > > > Total of 1 images in this container. > > Total of 1 container images. > > elf-loader: kernel entry point is 0x80008000 > > elf-loader: Starting kernel > > > > code0: start kernel... > > > > code0: Init kernel mappings... > > code0: Virtual memory enabled. > > code0: CPU: Cortex-A9, r2p10 > > code0: CPU supports: ThumbEE/Thumb2/Jazelle/TrustZone > > code0: D-cache: PIPT, I-cache: VIPT > > code0: Cache Write-back granule: 32 bytes > > code0: Exclusive reservation granule: 32 bytes > > code0: D-cache minimum line: 32 bytes > > code0: I-cache minimum line: 32 bytes > > code0: 1 Levels of caches. > > code0: Required LoUUP/LoC/LoUIS levels: 1, 1, 1 > > code0: L1 cache(s): 32Kb, 4-way, 256 sets, 32-byte lines. > > code0: Separate I+D caches with WriteAlloc/ReadAlloc/WriteBack/ > > support. > > code0: Bringing up CPU1 > > code0: CPU1: Virtual memory enabled. > > code0: CPU1: Initialized. > > code0: SMP: 2 CPU cluster, CPU0/1/ are participating in SMP > > code0: Kernel area 0xf0008000 - 0xf003d000 remapped as 53 pages > > code0: Kernel built on Aug 19 2011, 14:01:38 > > code0: Mapping 0x3000 bytes as RX from 0x84000000 physical to > > 0xc0000000 virtual for project0 > > code0: Mapping 0x2000 bytes as RW from 0x84003000 physical to > > 0xc0003000 virtual for project0 > > In __l4_threadlib_init > > 3221238016 > > 3221245224 > > My api is tested > > I am in main func > > > > Regards, > > Ayan Kumar Halder > > _______________________________________________ > > codezero-devel mailing list > > [email protected] > > http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org > > -- > Thanks, > Amit Mahajan > >
_______________________________________________ codezero-devel mailing list [email protected] http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
