- l4-hackers - example.com Site

How to compiler DROPS
by fiasco 11 Mar '13

11 Mar '13

Hi, Now, I learn how to compiler DROPS, but I can not get the manual book which could guide me to compiler the DROPS and boot it form cd rom. Could someone give me a help? The document I need is how to compiler DROPS, create iso image and boot it. The target compiler DROPS is listed: http://os.inf.tu-dresden.de/drops/download.html

2 1

boot image
by fiasco 11 Mar '13

11 Mar '13

Hi, I find that some webpage is deleted which is about how to compiler, create iso, boot the DROPS. Could someone give me some doc, thanks, The DROPS is listed below: http://demo.tudos.org/eng_download.html

1 0

Re: memory problem about s5pv210 porting
by meng-qy 05 Mar '13

05 Mar '13

Hi,Adam, The problem has been solved, thank you for your supports! Indeed, that fault is caused by cache. In file "pagetable-arch", the code only flush dcache and do not flush icache which leads to this unstable phenomenon. Now, the system seem to ok after I adding it. Steven Meng On 2013年03月01日 19:00, l4-hackers-request(a)os.inf.tu-dresden.de wrote: > On Thu Feb 28, 2013 at 21:33:53 +0800, meng-qy wrote: >> > Thank you for your suggestion! Following your guidance, I log the PF info when system dead like this: >> > >> > test 1: >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 144 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 143 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 142 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 141 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 140 >> > test 2: >> > pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 105 >> > pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 104 >> > pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 103 >> > pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 102 >> > test 3: >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 116 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 115 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 114 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 113 >> > pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 112 >> > >> > What is spc? pc or sp ? I objdump the image, and did not found that address. > pc is the program counter, sp is the stack pointer, spc is a kernel > internal data structure (Space). So this is a code pagefault, likely in > the roottask/moe. > >> > However, we can't get more info in dump file because the file didn't include any symbol table(Can we >> > dump the symbol table by adding some compile option? ). > Use fiasco.image file for the kernel. > >> > At last, different from other chip, we found that address >> > e0000000-fb000000 in s5pv210 is some important register, and the >> > kernel seem to map that address, it doesn't matter? > What you describe are physical addresses, the kernel uses virtual ones, > i.e. the virtual address does not point to the physical address. So yes, > it does not matter. > > > > > Adam > -- Adam adam(a)os.inf.tu-dresden.de Lackorzynski > http://os.inf.tu-dresden.de/~adam/ --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

1 0

Genode OS Framework version 13.02 released
by Sebastian Sumpf 03 Mar '13

03 Mar '13

We are pleased to announce the release of Genode version 13.02. The most prominent features are the improved handling of dynamic workloads on the NOVA hypervisor, IOMMU support as well as the integration of Markus Pateymüller's work on the Vancouver VMM. Fiasco.OC has been updated to the most recent version and there are new platforms available for our custom kernel. The full story can be explored in the release notes: http://genode.org/documentation/release-notes/13.02 Release-notes summary: - DMA protection via IOMMU (NOVA/x86) - Full virtualization via the Vancouver VMM (NOVA/x86) - Redesigned audio-output support for low latency - Base API and OS infrastructure - New fault-detection facility - New mechanism for file-system notifications - New terminal multiplexer - Device drivers - ACPI support for 64-bit machines - New OMAP4 UART driver - USB support for Samsung Exynos 5250 - Base platforms - Custom kernel platform with added support for Samsung Exynos 5250 and Freescale i.MX53 - NOVA kernel improved for highly dynamic workloads - Fiasco.OC kernel forked, Exynos-5250 support added - Improved memory management on Linux Enjoy, Sebastian -- Sebastian Sumpf Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

3 3

Re: Fiasco.OC performance issues
by Sebastian Sumpf 03 Mar '13

03 Mar '13

On 01/29/2013 12:09 AM, Adam Lackorzynski wrote: > On Fri Jan 25, 2013 at 00:00:26 +0100, Sebastian Sumpf wrote: >> On 01/17/2013 11:31 PM, Adam Lackorzynski wrote: >>> On Thu Jan 17, 2013 at 17:03:36 +0100, Sebastian Sumpf wrote: >>>> I recently upgraded Fiasco.OC to SVN revision 42 and experience some >>>> pretty severe performance degradation compared to revision 40 on the >>>> Pandaboard (SMP). It seems that 'simga0' and the root task stall for 5 >>>> to 10 seconds during boot up. I tracked the issue down to be caused by >>>> the initial mapping operations, especially our root task maps all the >>>> available memory during bootstrap. Within the kernel the >>>> 'Context::xcpu_tlb_flush' is called for each mapping. The function sends >>>> an IPI (to CPU1 which is idle) and then waits for an IPI in order to >>>> signal the end of the operation. The whole operation seems to have >>>> gotten slower compared to revision 40, but I could not find many >>>> differences in the IPI-handling code. Do you have any ideas or >>>> suggestions what could cause the delay (maybe scheduling changes) and >>>> how to fix it? >>> >>> I noticed a similar/same thing but hadn't time to investigate yet. >> >> Okay, I just wanted to make sure that the problem is not at our side nor >> at our usage pattern. >> Another thing I wonder is: Since you now have second level cache support >> for the PandaBoard, how do I map DMA memory to a client? The problem >> seems to be that sigma0 maps all memory as cached. So what we have been >> trying to do is this: When someone requests DMA memory we map the page >> as uncached and then call 'l4_cache_dma_coherent' afterwards. This >> doesn't seem to work out well for our drivers. The thing I think I could >> gather is that memory that is mapped cached (sigma0, roottask) and >> uncached (client) at the same time has an undefined behavior (I might be >> wrong here) on ARM. So, what is the protocol to implement this on >> Fiasco.OC/L4RE setups? > > Indeed, having memory with different attributes must be avoided. > But it's also about accessing that memory. So for example for sigma0 > this isn't a problem because sigma0 does not touch the memory itself. > Is your roottask accessing the memory, i.e. pulling it into caches? Yes this is the problem we're trying to solve. We don't have a notice of normal RAM and DMA pools within our roottask (if we had this, the question of how to dimension DMA pools would arise, also this seems to be an ARM only issue). So here is what we did with L1 caches enabled only: Acquire the memory in roottask, map it to the client as non-cacheable, zero out the memory (as it might have been previously used as normal RAM and for security reasons), clean and invalidate the data-cache. With the L2-cache enabled on PandaBoard, I tried to use the 'l4_cache_dma_coherent' function to accomplish the same behavior, which worked out well for the L1-case ... but it didn't. So, what am I doing wrong here, or isn't this supported anyways? Thanks a lot, Sebstian

3 7

How to start a program in a application ?
by Jason.han 02 Mar '13

02 Mar '13

Hi all, I want to start a program in my application ,(e.g task A--->start task B) I can't get enough information in latest source version , so I wonder if some know whether there is some system call like fork() or APIs to do this. Please give me some suggestion ,and example it preferred . --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

2 1

RE: Re: [ARM11] Question for the ARM 11 GPIO MAPPING
by Jason.han 02 Mar '13

02 Mar '13

Dear Adam : Thank you very much ! Now I have understand the IO MAPPING rules . All IO address mapping is only recognized by first 5 bits ,the last three bit is no mean for address(only for flags) . I mapping the S3C6410 GPIO ,Video-control ,Sfr once again . Now i can make the LCD bright and run the spectrum in real hardware . Thanks . Best regards ~~ ------------------------------ Message: 2 Date: Wed, 27 Feb 2013 22:13:47 +0100 From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> To: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: [ARM11] Question for the ARM 11 GPIO MAPPING Message-ID: <20130227211347.GA6841(a)os.inf.tu-dresden.de> Content-Type: text/plain; charset=iso-8859-1 Hi, On Tue Feb 26, 2013 at 20:10:15 +0800, Jason.han wrote: >> Now I have GPIO Mapping problems happened when >> run the L4re in Arm 11 (6410 ). >> >> .devs ==> Res.mmio(0x7f008100, 0x7f00813f); >> .lcd.c ==>l4io_request_iomem(0x7f008100, 0x03f, >> L4IO_MEM_NONCACHED, &lcd_gpio_virt_base); >> >> when >> "l4_mem_write(lcd_gpio_virt_base+0x00,L4_MEM_WIDTH_4BYTE,0xaaaaaaaa); >> download in real-hw board : the core will died as it : >> >> Ned: loading file: 'rom/arm-rv-lcd.cfg' >> >> hello | Hello World! >> IO | Dev_factory: register factory for N2Hw6DeviceE >> IO | GTF: register factory for 7Pci_dev >> IO | GTF: register factory for N2Hw12Msi_resourceE >> IO | Dev_factory: register factory for N2Hw11Gpio_deviceE >> IO | Io service >> IO | Ready. Waiting for request. >> fbdrv | Using LCD driver: S3C6410 >> fbdrv | lcd_control_virt_base is 0x3000 >> fbdrv | lcd_gpio_virt_base is 0x4000 >> fbdrv | Video memory is at virtual 0x5000 (size: 0x3fc00 Bytes) >> fbdrv | Physical video memory is at 0x50394000 ==>core died >> >> after delete it and only use l4_mem_read , value always is >> >> IO | Ready. Waiting for request. >> >> fbdrv | Using LCD driver: S3C6410 >> fbdrv | lcd_control_virt_base is 0x3000 >> fbdrv | lcd_gpio_virt_base is 0x4000 >> fbdrv | Video memory is at virtual 0x5000 (size: 0x3fc00 Bytes) >> fbdrv | Physical video memory is at 0x50395000 >> fbdrv | 0 value is 0x220022 ==> core run is ok. >> >> In the range of the GPIO ,whatever I defined , the >> lcd_gpio_virt_base + offset (value 0) is always 0x220022 ,can't >> be written . >> the lcd_gpio_virt_base + offset (value 0x04) is always 0x23 ,can >> be written ,but value never be changed . >> From Offset (value 0x08) is normal . why only GPIO like this ,I >> write some time and control -register always OK. >> >> Do you know Why , Can you give me some advices ? Thank you . >> >> I also try to .devs ==> Res.mmio(0x7f008000, 0x7f00813f); >> .lcd.c ==>l4io_request_iomem(0x7f008000, >> 0x03f, L4IO_MEM_NONCACHED, &lcd_gpio_virt_base); >> when >> "l4_mem_write(lcd_gpio_virt_base+0x100,L4_MEM_WIDTH_4BYTE,0xaaaaaaaa); >> The offset 0x00 ,and 0x04 same problem ,but now I can write >> 0xaaaaaaaa for this IO port, even though working not well . > What I notice is that you want to have 0x7f008100, however, mappings are > page granular, i.e. lower 3 digits are 0. The output says the virt_base > is 0x4000, so you probably want to access 0x4100. Maybe the device at > offset 0 is behaving like what you're seeing. > > > > > Adam --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

1 0

memory problem for s5pv210 porting
by meng-qy 01 Mar '13

01 Mar '13

Hi, Adam, Thank you for your suggestion! Following your guidance, I log the PF info when system dead like this: test 1: pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 144 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 143 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 142 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 141 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 140 test 2: pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 105 pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 104 pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 103 pf: 000a pfa=20144128 ip=20144128 (r-) spc=0xf12e475c 102 test 3: pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 116 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 115 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 114 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 113 pf: 000a pfa=2016a8f8 ip=2016a8f8 (r-) spc=0xf12e475c 112 What is spc? pc or sp ? I objdump the image, and did not found that address. However, we can't get more info in dump file because the file didn't include any symbol table(Can we dump the symbol table by adding some compile option? ). At last, different from other chip, we found that address e0000000-fb000000 in s5pv210 is some important register, and the kernel seem to map that address, it doesn't matter? Steven Meng > On Tue Feb 26, 2013 at 19:33:49 +0800, meng-qy wrote: >> Hello,l4-hackers, >> >> We are working at porting fiasco to s5pv210 platform. Now, we >> encounter a unstable problem when fiasco booting. Sometimes, the >> system seems ok. But more often, the system dead in different >> places when start moe. We trace the program and find that the system >> halts in function "handle_page_fault" of >> sigma0(dir=/l4/pkg/sigma0/server/src/memmap.cc). The log is >> described more specifically as following: >> >> case 1: Page fault >> ........ >> Calibrating timer loop... done. >> SIGMA0: Hello! >> KIP @ 20002000 >> allocated 4KB for maintenance structures >> SIGMA0: Dump of all resource maps >> RAM:------------------------ >> [0:20000000;20000fff] >> [0:20065000;2008ffff] >> [0:20097000;20097fff] >> [0:2009f000;2013ffff] >> [4:20140000;20171fff] >> [0:20172000;20177fff] >> [4:20178000;2018efff] >> [0:2018f000;21010fff] >> [4:21011000;21011fff] >> [0:21012000;210fffff] >> [4:21100000;21133fff] >> [0:21134000;3effffff] >> IOMEM:---------------------- >> [0:0;1fffffff] >> [0:40000000;ffffffff] >> SIGMA0: alloc addr ok, addr is 20140000 //which we add in func >> handle_page_fault >> SIGMA0: alloc addr ok, addr is 2017d000 >> SIGMA0: alloc addr ok, addr is 2017c000 >> SIGMA0: alloc addr ok, addr is 2016e000 >> SIGMA0: alloc addr ok, addr is 2016f000 >> SIGMA0: alloc addr ok, addr is 20169000 >> SIGMA0: alloc addr ok, addr is 2016c000 >> SIGMA0: alloc addr ok, addr is 2016b000 >> MOE: Hello world >> SIGMA0: Page fault, did not find page at 200020e0 for 4 >> SIGMA0: Page fault, did not find page at 200020e0 for 4 >> SIGMA0: Page fault, did not find page at 200020e0 for 4 >> SIGMA0: Page fault, did not find page at 200020e0 for 4 >> SIGMA0: Page fault, did not find page at 200020e0 for 4 // >> endless loop >> SIGMA0: Page fault, did not find page at 200020e0 for 4 > > The second case smells like cache/tlb issue but I wouldn't understand > why this would be a problem. And the case above looks rather not like > that. 20002000 is the kip and there should not be a page-fault there. > In jdb, you should log page-faults (P*) to check (with shift-T) for any > repeating patterns (e.g. same pc or similar). > > > > Adam > -- > Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > > > ------------------------------ > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > > > End of l4-hackers Digest, Vol 118, Issue 14 > ******************************************* --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

2 1

memory problem for s5pv210 porting
by meng-qy 27 Feb '13

27 Feb '13

Hello,l4-hackers, We are working at porting fiasco to s5pv210 platform. Now, we encounter a unstable problem when fiasco booting. Sometimes, the system seems ok. But more often, the system dead in different places when start moe. We trace the program and find that the system halts in function "handle_page_fault" of sigma0(dir=/l4/pkg/sigma0/server/src/memmap.cc). The log is described more specifically as following: case 1: Page fault ........ Calibrating timer loop... done. SIGMA0: Hello! KIP @ 20002000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [0:20000000;20000fff] [0:20065000;2008ffff] [0:20097000;20097fff] [0:2009f000;2013ffff] [4:20140000;20171fff] [0:20172000;20177fff] [4:20178000;2018efff] [0:2018f000;21010fff] [4:21011000;21011fff] [0:21012000;210fffff] [4:21100000;21133fff] [0:21134000;3effffff] IOMEM:---------------------- [0:0;1fffffff] [0:40000000;ffffffff] SIGMA0: alloc addr ok, addr is 20140000 //which we add in func handle_page_fault SIGMA0: alloc addr ok, addr is 2017d000 SIGMA0: alloc addr ok, addr is 20167000 SIGMA0: alloc addr ok, addr is 2018e000 SIGMA0: alloc addr ok, addr is 20166000 SIGMA0: alloc addr ok, addr is 20179000 SIGMA0: alloc addr ok, addr is 20178000 SIGMA0: alloc addr ok, addr is 2018d000 SIGMA0: alloc addr ok, addr is 20145000 SIGMA0: alloc addr ok, addr is 20163000 SIGMA0: alloc addr ok, addr is 20162000 SIGMA0: alloc addr ok, addr is 20141000 SIGMA0: alloc addr ok, addr is 20164000 SIGMA0: alloc addr ok, addr is 20143000 SIGMA0: alloc addr ok, addr is 20149000 SIGMA0: alloc addr ok, addr is 2014a000 SIGMA0: alloc addr ok, addr is 2017e000 SIGMA0: alloc addr ok, addr is 20153000 SIGMA0: alloc addr ok, addr is 2014b000 SIGMA0: alloc addr ok, addr is 2014d000 SIGMA0: alloc addr ok, addr is 2014e000 SIGMA0: alloc addr ok, addr is 2014f000 SIGMA0: alloc addr ok, addr is 20150000 SIGMA0: alloc addr ok, addr is 20152000 SIGMA0: alloc addr ok, addr is 20154000 SIGMA0: alloc addr ok, addr is 20155000 SIGMA0: alloc addr ok, addr is 20156000 SIGMA0: alloc addr ok, addr is 20160000 SIGMA0: alloc addr ok, addr is 20168000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2016e000 SIGMA0: alloc addr ok, addr is 2016f000 SIGMA0: alloc addr ok, addr is 20169000 SIGMA0: alloc addr ok, addr is 2016c000 SIGMA0: alloc addr ok, addr is 2016b000 MOE: Hello world SIGMA0: Page fault, did not find page at 200020e0 for 4 SIGMA0: Page fault, did not find page at 200020e0 for 4 SIGMA0: Page fault, did not find page at 200020e0 for 4 SIGMA0: Page fault, did not find page at 200020e0 for 4 SIGMA0: Page fault, did not find page at 200020e0 for 4 // endless loop SIGMA0: Page fault, did not find page at 200020e0 for 4 case 2: alloc ok ...... IOMEM:---------------------- [0:0;1fffffff] [0:40000000;ffffffff] SIGMA0: alloc addr ok, addr is 20140000 SIGMA0: alloc addr ok, addr is 2017d000 SIGMA0: alloc addr ok, addr is 20167000 SIGMA0: alloc addr ok, addr is 2018e000 SIGMA0: alloc addr ok, addr is 20166000 SIGMA0: alloc addr ok, addr is 20179000 SIGMA0: alloc addr ok, addr is 20178000 SIGMA0: alloc addr ok, addr is 2018d000 SIGMA0: alloc addr ok, addr is 20145000 SIGMA0: alloc addr ok, addr is 20163000 SIGMA0: alloc addr ok, addr is 20162000 SIGMA0: alloc addr ok, addr is 20141000 SIGMA0: alloc addr ok, addr is 20164000 SIGMA0: alloc addr ok, addr is 20143000 SIGMA0: alloc addr ok, addr is 20149000 SIGMA0: alloc addr ok, addr is 2014a000 SIGMA0: alloc addr ok, addr is 2017e000 SIGMA0: alloc addr ok, addr is 20153000 SIGMA0: alloc addr ok, addr is 2014b000 SIGMA0: alloc addr ok, addr is 2014d000 SIGMA0: alloc addr ok, addr is 2014e000 SIGMA0: alloc addr ok, addr is 2014f000 SIGMA0: alloc addr ok, addr is 20150000 SIGMA0: alloc addr ok, addr is 20152000 SIGMA0: alloc addr ok, addr is 20154000 SIGMA0: alloc addr ok, addr is 20155000 SIGMA0: alloc addr ok, addr is 20156000 SIGMA0: alloc addr ok, addr is 20160000 SIGMA0: alloc addr ok, addr is 20168000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 SIGMA0: alloc addr ok, addr is 2017c000 //endless loop Who can give some guidance or suggestion? Steven Meng --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

2 1

[ARM11] Question for the ARM 11 GPIO MAPPING
by Jason.han 27 Feb '13

27 Feb '13

Dear Adam, How are you doing now ? I am fresh member for L4re . Now I have GPIO Mapping problems happened when run the L4re in Arm 11 (6410 ). .devs ==> Res.mmio(0x7f008100, 0x7f00813f); .lcd.c ==>l4io_request_iomem(0x7f008100, 0x03f, L4IO_MEM_NONCACHED, &lcd_gpio_virt_base); when "l4_mem_write(lcd_gpio_virt_base+0x00,L4_MEM_WIDTH_4BYTE,0xaaaaaaaa); download in real-hw board : the core will died as it : Ned: loading file: 'rom/arm-rv-lcd.cfg' hello | Hello World! IO | Dev_factory: register factory for N2Hw6DeviceE IO | GTF: register factory for 7Pci_dev IO | GTF: register factory for N2Hw12Msi_resourceE IO | Dev_factory: register factory for N2Hw11Gpio_deviceE IO | Io service IO | Ready. Waiting for request. fbdrv | Using LCD driver: S3C6410 fbdrv | lcd_control_virt_base is 0x3000 fbdrv | lcd_gpio_virt_base is 0x4000 fbdrv | Video memory is at virtual 0x5000 (size: 0x3fc00 Bytes) fbdrv | Physical video memory is at 0x50394000 ==>core died after delete it and only use l4_mem_read , value always is IO | Ready. Waiting for request. fbdrv | Using LCD driver: S3C6410 fbdrv | lcd_control_virt_base is 0x3000 fbdrv | lcd_gpio_virt_base is 0x4000 fbdrv | Video memory is at virtual 0x5000 (size: 0x3fc00 Bytes) fbdrv | Physical video memory is at 0x50395000 fbdrv | 0 value is 0x220022 ==> core run is ok. In the range of the GPIO ,whatever I defined , the lcd_gpio_virt_base + offset (value 0) is always 0x220022 ,can't be written . the lcd_gpio_virt_base + offset (value 0x04) is always 0x23 ,can be written ,but value never be changed . From Offset (value 0x08) is normal . why only GPIO like this ,I write some time and control -register always OK. Do you know Why , Can you give me some advices ? Thank you . I also try to .devs ==> Res.mmio(0x7f008000, 0x7f00813f); .lcd.c ==>l4io_request_iomem(0x7f008000, 0x03f, L4IO_MEM_NONCACHED, &lcd_gpio_virt_base); when "l4_mem_write(lcd_gpio_virt_base+0x100,L4_MEM_WIDTH_4BYTE,0xaaaaaaaa); The offset 0x00 ,and 0x04 same problem ,but now I can write 0xaaaaaaaa for this IO port, even though working not well . please help to check the problem . Do you have some good example for this . ps: > .devs file : local Res = Io.Res local Hw = Io.Hw Io.hw_add_devices { LCD = Hw.Device { hid = "LCD s3c6410"; Res.mmio(0x77100000, 0x77100fff); }, GPIO = Hw.Device { hid = "LCDGPIO"; Res.mmio(0x7f008100, 0x7f00813f); } } > .cfg file : is not changed ,same as arm-rv-lcd.cfg > .io file : gui => new System_bus() { } fbdrv => new System_bus() { LCD => wrap(hw-root.LCD); GPIO => wrap(hw-root.GPIO); } >module.list entry arm-lcd-example bootstrap bootstrap -serial kernel fiasco -serial_esc roottask moe rom/arm-rv-lcd.cfg module arm-rv-lcd.cfg module arm-rv-lcd.io module arm-rv-eb.devs module l4re module io module ned module fb-drv module mag module ex_fb_spectrum_cc module hello --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

2 1

FYI: Visions on Genode OS development
by Christian Helmuth 18 Feb '13

18 Feb '13

Hello L4 hackers, this morning I stumled upon a blog posting http://allsoftwaresucks.blogspot.de/2013/02/visions-on-genode-os-developmen… by Alexander Tarasikov, who also comments on "L4Linux issues" in the last section of the posting. IMO he addresses an important point that is also sporadically asked on this mailing list: Beside the technical issues with SVN and Git, how open is the development of L4Linux, L4Re etc. and what could we expect from it? Will it walk an community-relared open path in the future? I'd by very glad to hear some words about this from the current developers. Thanks -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 1

Re: How to add EXYNOS platform support
by Chao-Jui Chang 18 Feb '13

18 Feb '13

Hi Adam, Thanks for your quick reply. After looking tegra2 bsp, I make some memory layout change. Can you help me to check about it [1]? Another question is about l4re. l4re also need platform init code at pkg/bootstrap/server/src/platform/tegra2.cc I am new to porting. I don't have any idea about how to modify this. Is there any document for reference? [1] https://www.dropbox.com/s/bjrf5l2d36wa4yw/exynos4.tgz [2] EXYNOS4 datasheet: https://www.dropbox.com/s/fcw5oe5oyjy1yg2/SEC_Exynos4210_pulbic_manual_Ver.… Thanks, Chao-Jui 2013/2/13 Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> > On Mon Feb 11, 2013 at 12:46:44 +0800, Chao-Jui Chang wrote: > > I want to port Fiasco.OC to run on hardkernel's ODROID[1] platform. > > Could anyone point out the direction of porting Fiasco to me? > > > > I find some BSP info in l4/src/kernel/fiasco/src/kern/arm/bsp, but I > don't > > know how to start porting. > > Which BSP can be the base to modify for EXYNOS platform? > > I'd go for tegra2 bsp. > > > > Adam > -- > Adam adam(a)os.inf.tu-dresden.de > Lackorzynski http://os.inf.tu-dresden.de/~adam/ > > _______________________________________________ > l4-hackers mailing list > l4-hackers(a)os.inf.tu-dresden.de > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers >

2 1

How to add EXYNOS platform support
by Chao-Jui Chang 13 Feb '13

13 Feb '13

Hi, I want to port Fiasco.OC to run on hardkernel's ODROID[1] platform. Could anyone point out the direction of porting Fiasco to me? I find some BSP info in l4/src/kernel/fiasco/src/kern/arm/bsp, but I don't know how to start porting. Which BSP can be the base to modify for EXYNOS platform? [1] ODROID platform: http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G13399… Thanks, Chao-Jui

2 2

Using l4re in loadable modules of L4Linux
by Haohui Mai 13 Feb '13

13 Feb '13

Hi folks, I'm building a loadable module of L4Linux. The module calls l4re_rm_alloc() / l4re_rm_attach() to allocate shared memory. Because the symbols l4re_rm_attach_srv / l4re_utils_cap_alloc / l4re_ma_alloc_srv are not exported to the modules, I exported them using EXPORT_SYMBOL(). The module, however, still fails to load, complaining about that these symbols cannot be found. Is there a way to export these symbols so that loadable modules can use L4Re? Thanks very much! ~Haohui

2 1

Debug: how to enumerate all kernel objects
by Евгений Федотов 07 Feb '13

07 Feb '13

Hello, L4 Hackers! My question is: How to retrieve all kernel object list (threads, tasks, IRQs, Gates) in non-interactive way? Since Fiasco JDB stores the full list of objects, is there any l4_invoke_debugger call to retrieve object information from order number or ID? Best regards, Eugene.

2 1

About JDB non-interactive commands
by Евгений Федотов 04 Feb '13

04 Feb '13

Hello, L4 Hackers! From JDB manual I found that JDB supports non-interactive commands such as: enter_kdebug("*#I*IR+"); //enable IPC logging Does it work in other than x86 architectures, e.g.. Fiasco on ARM? Best regards, Eugene.

2 1

Fiasco.OC: question regarding l4_ipc_wait() and l4_ipc_reply_and_ipc_wait().
by Сергей Грехов 01 Feb '13

01 Feb '13

Hello, L4Hackers! I have several questions about two IPC: l4_ipc_wait() and l4_ipc_reply_and_ipc_wait(). 1) Is there any way to know on the receive side who had sent the IPC we have catched with l4_ipc_wait()? One of the ways if to enable IPC logging in JDB. But the problem is that trace usually consist of several thousands of IPCs and I need only one. Filtering helps a bit, but still it takes much more time to find needed info. 2) According to the description of l4_ipc_reply_and_ipc_wait() in header file: "A message is sent to the previous caller using the implicit reply capability. Afterwards the invoking thread waits for a message from any source." The question is what events/things/whatever updates this implicit reply capability and what will happen if this capability is invalid? And one more general question. Is there any documentation on JDB? -- Best regards, Sergey S. Grekhov

2 1

[OT] Berlin based Trust2Core GmbH searching for L4 developers
by Michael Voigt 31 Jan '13

31 Jan '13

Hey L4 hackers, As you may already know, recently a company called Trust2Core GmbH was founded in Berlin, which is heavily involved in the L4 microkernel business. This being the L4 hackers list, it might be of interest for you that Trust2Core is currently intensively seeking for employees with L4 and microkernel related skills. If that sounds interesting to you, please do not hesitate to have a look here <http://jobsuche.monster.de/Jobs/Trust2Core-GmbH_6?re=106> to obtain further information and apply ;). Kind regards, Michael -- Michael Voigt -Software Expert- Trust2Core <http://www.trust2core.de> Trust2Core GmbH Kurfürstendamm 22, D-10719 Berlin (Neues Kranzlereck) Phone: +49-30-652 136 152 Fax: +49-30-652 136 177 michael.voigt(a)trust2core.de Leadership in software virtualization technologies on consumer hardware platforms. Enabling the trusted path to user for highest security @ maximum fun! Trust2Core GmbH Geschäftsführung: Robert Butz (CEO), Melanie Tillmann (CFO) Handelsregister: Amtsgericht Bonn HRB 19360 Sitz der Gesellschaft: Bonn Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

1 0

[OT] Berlin based Trust2Core GmbH searching for L4 developers
by Michael Voigt 31 Jan '13

31 Jan '13

Hey L4 hackers, As you may already know, recently a company called Trust2Core GmbH was founded in Berlin, which is heavily involved in the L4 microkernel business. This being the L4 hackers list, it might be of interest for you that Trust2Core is currently intensively seeking for employees with L4 and microkernel related skills. If that sounds interesting to you, please do not hesitate to have a look here <http://jobsuche.monster.de/Jobs/Trust2Core-GmbH_6?re=106> to obtain further information and apply ;). Kind regards, Michael -- Michael Voigt -Software Expert- Trust2Core <http://www.trust2core.de> Trust2Core GmbH Kurfürstendamm 22, D-10719 Berlin (Neues Kranzlereck) Phone: +49-30-652 136 152 Fax: +49-30-652 136 177 michael.voigt(a)trust2core.de Leadership in software virtualization technologies on consumer hardware platforms. Enabling the trusted path to user for highest security @ maximum fun! Trust2Core GmbH Geschäftsführung: Robert Butz (CEO), Melanie Tillmann (CFO) Handelsregister: Amtsgericht Bonn HRB 19360 Sitz der Gesellschaft: Bonn Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

1 0

Fiasco.OC interrupt handling
by Daniel Waddington 29 Jan '13

29 Jan '13

Hi, I'm looking into the interrupt handling in Fiasco.OC r.40 (x86/amd64). Browsing the code, it appears that the IDT only gets set up on CPU 0 and therefore on a multicore platform all interrupt handling from the kernel's perspective is from core 0. Of course the user-level handlers themselves may be elsewhere. Do I have this correct or am I misunderstanding? Thanks, Daniel

2 2

Re: Error during the "ned" package build (svn revision 42)
by ggasnier31＠free.fr 29 Jan '13

29 Jan '13

On Fri, 25 Jan 2013 00:09:55 +0100, Adam Lackorzynski wrote: >On Thu Jan 24, 2013 at 22:30:36 +0100, ggasnier31(a)free.fr wrote: >> I got the following error building the "ned" package for ARM architecture (Cortex-A9, Pandaboard). >> I use the last Linaro toolchain "gcc-linaro-arm-linux-gnueabihf-4.7-2012.12-20121214_linux". >> >> make[4]: Leaving directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' >> make[4]: Entering directory `/home/repository/L4.kernel/fiasco/src/l4/ArmBuild/pkg/ned/server/src/OBJ-arm_armv7a-l4f' >> make[4]: *** No rule to make target `ned.lua.bin.o', needed by `ned'. Stop. >This is strange because there is a rule for that file. ned.lua should be >in the srcdir of l4/pkg/ned/server/src? Which make version? The file ned.lua is in the l4/pkg/ned/server/src directory and the make version is 3.81 Guillaume GASNIER

2 1

Fiasco.OC performance issues
by Sebastian Sumpf 29 Jan '13

29 Jan '13

Hi L4 hackers, I recently upgraded Fiasco.OC to SVN revision 42 and experience some pretty severe performance degradation compared to revision 40 on the Pandaboard (SMP). It seems that 'simga0' and the root task stall for 5 to 10 seconds during boot up. I tracked the issue down to be caused by the initial mapping operations, especially our root task maps all the available memory during bootstrap. Within the kernel the 'Context::xcpu_tlb_flush' is called for each mapping. The function sends an IPI (to CPU1 which is idle) and then waits for an IPI in order to signal the end of the operation. The whole operation seems to have gotten slower compared to revision 40, but I could not find many differences in the IPI-handling code. Do you have any ideas or suggestions what could cause the delay (maybe scheduling changes) and how to fix it? Thanks, Sebastian -- Sebastian Sumpf Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 3

Re: Launching NOVA on QEMU
by Alexander Boettcher 26 Jan '13

26 Jan '13

Hello, try using a cpu model which is capable emulating vmx/svm. qemu -cpu ? and you get all models. qemu -cpu phenom ... works well for me. Cheers, Alex. oleg <g6kl9-07(a)yandex.ru> schrieb: >_______________________________________________ >l4-hackers mailing list >l4-hackers(a)os.inf.tu-dresden.de >http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

2 1

Launching NOVA on QEMU
by oleg 25 Jan '13

25 Jan '13

1 0

About java support on L4linux
by Wajidali Whowe 25 Jan '13

25 Jan '13

Dear all, I have some applications written in Java and running without any problem on my local computer, where I have off course (openjdk) support. I wanted to run these applications on one of my L4linux instances where I may only have "jamvm" (an embedded version of java, which is provided for buildroot environment) Till now I booted L4linux only with ramdisks and off course for a full Java support, which might be provided for bigger systems, it would not be possible to create ramdisks. (For instance for Ubuntu or debian or Voyage... ) Do you have any suggestion on this issue? Best Regards,

2 1