Hi Amit, I am using toolkit release version 0.5. dated 19.08.2011 for OMAP4/Pandaboard.
If the toolkit is using some pre - supplied configuration, then how do I change that configuration. I want to know , how to get my executable working for Pandaboard as my final aim is to build a bare-metal application which will interact with some peripherals ( similar to device_service example) for which, I believe, changing the configuration is must, Please help me to proceed further. Regards, Ayan Kumar Halder On Wed, Jul 18, 2012 at 9:56 PM, Amit Mahajan <amit.maha...@b-labs.com>wrote: > Hi Ayan, > > Are you using the toolkit release? > > Your observations are correct and from your elf output it seems like > system is working fine. Incase you are using some prebuilt binary of > hypervisor(as is the case with toolkits), the contain configuration is > pre-supplied to it and will not go above this settings I think. > > > On Wed, 2012-07-18 at 20:50 +0530, AYAN KUMAR HALDER wrote: > > > > Hi Amit, > > > > I have checked the elf file for "hello world" and confirmed that > > there are no RWX pages > > > > I was debugging the python build script to see if it is able to read > > the elf sections properly or not. I added some prints( to > > display adresses of various sections) in > > tools/pyelf/elf_section_info.py in elf_loadable_section_info(). The > > following were the logs:- > > rw_sections_start 0xc0003000 > > rw_sections_end 0xc0008000 > > rx_sections_start 0xc0000000 > > rx_sections_end 0xc0002190 > > > > But while executing I got the following logs:- > > > > > > 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=0xc0007ff8, faulty pc=0xc0000014 > > > > tid=0x00000001 > > Unhandled kernel data abort at address 0x00000008 > > FAR:0x00000008 > > PC:0xf000e380 > > Unhandled kernel abort. > > Kernel panic. > > Halting system... > > > > > > I can see that the RX section has been mapped correctly for 0x3000 > > bytes, but the RW section should have been mapped for 0x5000 bytes > > whereas it has been actually mapped for 0x2000 bytes. And the faulty > > virtual address 0xc0007ff8 is within our range of 0xc0008000. > > > > Therefore, please help me to locate the script where the mapping is > > defined. > > I tried to make some changes in linker.ld script( eg . += 0x8000 in > > bss section ), but it did not make any difference. > > > > (Please find my final.elf for your reference. Please execute it on > > Pandaboard to observe similar behavior ). > > > > Regards, > > Ayan Kumar Halder > > > > On Mon, Jul 9, 2012 at 10:24 PM, Amit Mahajan > > <amit.maha...@b-labs.com> wrote: > > On Mon, 2012-07-09 at 20:14 +0530, AYAN KUMAR HALDER wrote: > > > 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). > > > > > > > Ok you need to check 2 things here: > > > > 1. Check the elf file of the hello world container and do a > > readelf on > > it to make sure it is having correct number of RX and RW > > pages. It > > should not have any RWX section. > > > > 2. If 1. looks fine, then the problem is in Codezero's reading > > of elf > > sections at load time. These manipulations are done in some > > python > > script under codezero/config. Find this script and add some > > prints in it > > so see if it is manipulating container's section properly. > > > > > > > > -- > > Thanks, > > Amit Mahajan > > > > > > > > > > -- > Thanks, > Amit Mahajan > >
_______________________________________________ codezero-devel mailing list codezero-devel@lists.l4dev.org http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
