Hi Ayan, In the current scenario I guess you need to wait for the new releases, which are expected soon.
On Thu, 2012-07-19 at 10:23 +0530, AYAN KUMAR HALDER wrote: > 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 > <[email protected]> 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 > > <[email protected]> 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 > > -- Thanks, Amit Mahajan _______________________________________________ codezero-devel mailing list [email protected] http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
