There is no tentative schedule yet, we are looking into it.
On Fri, 2012-07-27 at 19:54 +0530, AYAN KUMAR HALDER wrote: > Hi Amit, > > Please tell me a tentative date for the new release of codezero > toolkit which will obtain the memory configuration from the > applications' > elf headers so that I will be able to execute bare-metal applications > for device-interaction on Pandaboard( using codezero hypervisor ). > > The current configuration of 0x3000 bytes for RX pages and 0x2000 > bytes for RW pages has really become a major blocker for my > development activity on Codezero Hypervisor. > > Hence, I will be glad to know some tentative date which will help me > to schedule my activity on codezero hypervisor. > > Regards, > Ayan Kumar Halder > > On Thu, Jul 19, 2012 at 10:52 PM, Amit Mahajan > <amit.maha...@b-labs.com> wrote: > 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 > > <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 > > > > > > > -- > 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
