- l4-hackers - example.com Site

Fiasco.OC (rev. 40) Pandaboard support
by Stefan Kalkowski 07 Sep '12

07 Sep '12

Hi L4-hackers, recently I've tried to adapt Genode's Fiasco.OC-platform support to use the latest Fiasco.OC/L4Re subversion revision. When trying it on x86 I didn't run into any trouble. It worked "out of the box". But when it came to ARM, I got problems to boot Fiasco.OC on the Pandaboard in general (also when using plain Fiasco.OC/L4Re). I've debugged the problem down to Cpu::init_errata_workarounds(). The problem is that pandaboard's boot code initializes TrustZone, and triggers a configuration-disable signal beforehand. That leads to 'undefined instruction' exceptions, whenever one tries to write into the p15/c15-c0-1 debug register (like it's done in init_errata_workarounds). The attached patch implements Cpu::init_errata_workarounds() empty for the pandaboard. Moreover, it restricts the appliance of ERRATA 743622 to CPU revisions: r2p0-r2p2. With the attached patch Fiasco.OC runs fine on the Pandaboard too. Best regards Stefan -- Stefan Kalkowski 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 2

l4linux filesystem under fiasco-ux
by Ryan Brown 27 Aug '12

27 Aug '12

So far I've been running l4linux in a virtual machine. I'd like to run it in fiasco.ux to compare performance. But if l4linux under ux has no access to hardware, how do I access the filesystem? Am I stuck with the initial ramdisk? Or is there some way to mount the host filesystem, or a part of it?

2 1

Announcement: Genode 12.08 improves NOVA and ARM support
by Christian Helmuth 23 Aug '12

23 Aug '12

Today Genode Labs released the 4th anniversary version of the Genode OS Framework. Most notable are the NOVA microhypervisor platform improvements for x86 64bit, object-integrity protection, and centralized kernel-resource allocation in core as well as comprehensive support for the OMAP4 SoC used in the PandaBoard. A quick overview of all changes that come with version 12.08: - Base platforms - New base-hw platform for running the framework on bare ARM hardware - NOVA support for x86_64, object integrity protection, core-only kernel-resource allocation - New OMAP4 SoC device drivers - HDMI output - SD-card - USB HID - Networking - New FFAT-based file-system service - New TAR file-system service - Improved Noux runtime - New port of the Lynx web browser - Shell scripting support - 3rd-party libraries - New ports of openssl, pcre, expat - MPC, libgmp for x86_64 and ARM - lwIP updated to version 1.4.1-rc1 - New port of the lighttpd web server More details are described in the release notes http://genode.org/documentation/release-notes/12.08 Have fun with our new release -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://genode.org/ · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Local APIC address and MSI address
by Chen Tian 22 Aug '12

22 Aug '12

Hi, According to Intel manual, local APIC address starts at FEE00000, which is overlapping with the MSI's address register. How does this actually work? Thanks.

2 1

i.mx53 and fiasco.oc
by Nikolay Golikov 22 Aug '12

22 Aug '12

Hello. I trying to run fiasco.oc + l4re on freescale i.mx53qsb. And have some problems to do this. I using i.mx51 platform configuration with some changes. I changed addresses in src/kern/arm/bsp/imx/mem_layout-arm-imx.cpp: EXTENSION class Mem_layout { public: enum Virt_layout_imx53 { Timer_map_base = 0xef1ac000, Uart_map_base = 0xef1bc000, Watchdog_map_base = 0xef198000, Pic_map_base = 0xef200000, Uart_base = Uart_map_base, }; enum Phys_layout_imx53 { Device_phys_base_1 = 0x53f00000, Device_phys_base_2 = 0x0fffc000, Watchdog_phys_base = 0x53f98000, // wdog1 Timer_phys_base = 0x53fac000, // epit1 Uart_phys_base = 0x53fbc000, // uart1 Pic_phys_base = 0x0fffc000, }; }; And made some little changes in other source files. When I try to boot it, I see something like this: ## Booting kernel from Legacy Image at 70800000 ... Image Name: L4 Image #47 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 897192 Bytes = 876.2 kB Load Address: 71000000 Entry Point: 71000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... L4 Bootstrapper Build: #47 �В�т. �а�в�г. 21 16:49:21 MSK 2012, 4.5.1 Scanning up to 1024 MB RAM Memory size is 512MB (Limited by Scan) (70000000 - 90000000) RAM: 0000000070000000 - 000000008fffffff: 524288kB Total RAM: 512MB mod04: 710c1000-710da540: hello mod03: 710a7000-710c0458: l4re mod02: 7106d000-710a6624: moe mod01: 71063000-7106c370: sigma0 mod00: 71015000-71062cac: fiasco Moving 5 modules to 71100000 with offset eb000 moving module 05 { 710c1000-710da540 } -> { 711ac000-711c5540 } moving module 04 { 710a7000-710c0458 } -> { 71192000-711ab458 } moving module 03 { 7106d000-710a6624 } -> { 71158000-71191624 } moving module 02 { 71063000-7106c370 } -> { 7114e000-71157370 } moving module 01 { 71015000-71062cac } -> { 71100000-7114dcac } Scanning fiasco Scanning sigma0 Scanning moe --init=rom/hello Relocated mbi to [0x7100f000-0x7100f0d6] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x70002000 Regions of list regions [ 70001000, 700019bf] { 9c0} Kern fiasco [ 70002000, 7005cfff] { 5b000} Kern fiasco [ 70090000, 7009e17b] { e17c} Sigma0 sigma0 [ 70140000, 701717d3] { 317d4} Root moe [ 70178000, 7018eec7] { 16ec8} Root moe [ 71000000, 710143ef] { 143f0} Boot bootstrap [ 7100f000, 7100f1d3] { 1d4} Root Multiboot info [ 71192000, 711c553f] { 33540} Root Modules Memory API Version: (87) experimental Sigma0 config ip:700900e0 sp:71013044 Roottask config ip:70140178 sp:00000000 Starting kernel fiasco at 70001000 Hello from Startup::stage2 Initialize page table It stops on line 151 src/kern/arm/gic.cpp: Io::write<Mword>(0, _dist_base + DIST_CTRL); where _dist_base is Pic_map_base. If I understand correctly tzic on i.mx53 and tzic on i.mx51 is equivalent. And second question: I do not understand for what purpose make pysical devices and sdram mapping in: src/kern/arm/bootstrap.cpp? // map sdram linear from 0xf0000000 for (va = Mem_layout::Map_base, pa = Mem_layout::Sdram_phys_base; va < Mem_layout::Map_base + (4 << 20); va += 0x100000, pa += 0x100000) map_1mb(page_dir, va, pa, true, false); // map sdram 1:1 for (va = Mem_layout::Sdram_phys_base; va < Mem_layout::Sdram_phys_base + (4 << 20); va += 0x100000) map_1mb(page_dir, va, va, true, true); map_hw(page_dir); And why afterwards devises on physical addresses are out of order?

2 1

Local APIC cannot deliver MSI to CPU (Fiasco.OC) ?
by Chen Tian 22 Aug '12

22 Aug '12

I am trying to use MSI for my network card. After setting the MSI slot in the PCI configuration block based on Intel manual, I can confirm the interrupt is delivered to the processor's local APIC by looking at the IRR content in kernel debugger. The bit in IRR that reflects the vector I specified in MSI message is set to 1 by APIC. However, the interrupt handler installed at that vector is never invoked. Does someone have any idea on this? The priority does not seem to be the issue, because I checked the TPR, which was 0x80 when I entered kernel debugger and decreased to 0 when I press 'g'. The error status register is also zero in the kernel debugging mode, while there is a pending interrupt request as suggested by IRR. But the cpu just can't get the interrupt. Any suggestions? Thanks.

1 0

Issues in l4re-snapshot-2012081219 for ARM
by Ivan Loskutov 18 Aug '12

18 Aug '12

Hello, I tried new l4re-snapshot-2012081219 and found the following issues for ARM target: 1. File bin/setup.d/04-setup has error in BeagleBoard and Pandaboard L4Re configs generation. Patch attached. 2. I get errors at startup on Pandaboard KERNEL-369098737: alignment error at da067a03 (PC: f001e0ec, SP: 6e72654b, FSR: 400001, PSR: 600001d3) KERNEL-369098737: alignment error at da067a03 (PC: f001e0ec, SP: ea00000f, FSR: 400001, PSR: 600001d3) KERNEL-369098737: alignment error at da067a03 (PC: f001e0ec, SP: ea00000f, FSR: 400001, PSR: 600001d3) KERNEL-369098737: alignment error at da067a03 (PC: f001e0ec, SP: ea00000f, FSR: 400001, PSR: 600001d3) I found that the error is caused by a init_errata_workarounds() call in Cpu ::init (src/kernel/fiasco/src/kern/arm/cpu-arm.cpp). If I comment this call, then kernel started and hello example worked. Error is occurred when called set_c15_c0_1() function. I have not solved this issue yet. -- Ivan Loskutov

2 1

dma memory mapping
by Chen Tian 18 Aug '12

18 Aug '12

I'd like to allocate some physical memory for a device's DMA. Do I need to use some special flags in l4_task_map? Thanks.

2 1

input signal
by gaober 17 Aug '12

17 Aug '12

hi >Why do you need the IRQ in L4Linux then? Who is driving the touchscreen? That >instance should handle the TS IRQ as well. in mag, the tsc-omap3.c gets the coordinate like this mag | l4evdev.c Ev[22]. D: OMAP_TSC/input0, T : 3, C : 0 , V: 1085 mag | l4evdev.c Ev[23]. D: OMAP_TSC/input0, T : 3, C : 1 , V: 701 I want to make the l4linux and android kown the coordinate. now i cat /proc/interrupts it shows 210: 32 l4 l4-uart 211: 0 l4 l4fbev Err: 0 when i touch the omap3530 screen , the l4fbev still shows 0. i think i didn't get the l4fbev interruput.then how can i get it? in l4fb.c, there is the function irqerurn_t event_interrupt(), but in my board it didn't perform.maybe it is the reson? thanks very much! _______________________________________________ l4android-dev mailing list l4android-dev(a)lists.l4android.org http://lists.l4android.org/mailman/listinfo/l4android-dev

1 0

Call for Papers: System Software Verification Conference (SSV 2012)
by Toby Murray 17 Aug '12

17 Aug '12

[Note: Submission Deadline is 19 September 2012] 7th Systems Software Verification Conference (SSV 2012) November 28--30, 2012 Sydney, Australia http://www.ssv-conference.org/ *Scope Industrial-strength software analysis and verification has advanced in recent years through the introduction of model checking, automated and interactive theorem proving, and static analysis techniques, as well as correctness by design, correctness by contract, and model-driven development. However, many techniques are working under restrictive assumptions that are invalidated by complex embedded systems software such as operating system kernels, low-level device drivers, or microcontroller code. The aim of this workshop is to bring together researchers and developers from both academia and industry who are facing real software and real problems with the goal of finding real, applicable solutions. By “real” we mean problems such as time-to-market or reliability that the industry is facing. A real solution is one that is applicable to the problem in industry and not one that only applies to an abstract, academic, toy version of it. In this workshop we will discuss software analysis and development techniques and tools; this forum will serve as a platform to discuss open problems and future challenges in dealing with existing and upcoming systems-level code. Topics include, but are not restricted to: • Model checking • Automated and interactive theorem proving • Static analysis • Automated testing • Model-driven development • Embedded systems development • Programming languages • Verifying compilers • Software certification • Software tools • Experience reports *Submissions Submissions must be made electronically through the EasyChair system (https://www.easychair.org/conferences/?conf=ssv2012) until September 19th, 2012. Papers should be up to 15 pages in pdf format and formatted in EPTCS style. Additional details may be included in a clearly marked appendix, which will be read at the discretion of the program committee. All will be subject to peer review under normal conference standards. Experience reports and papers on work in progress are welcome as long as there is a clear contribution. Submissions which are based or discuss a non-trivial piece of software are required to make all those non-standard software parts available, which a referee may need, in order to check the claims of the submission. Submitted papers must not have previously appeared in a journal or conference with published proceedings and must not be concurrently submitted to any other peer-reviewed workshop, symposium, conference or archival journal. Any partial overlap with any such published or concurrently submitted paper must be clearly indicated. *Publication The proceedings will be published with EPTCS (http://eptcs.org) *Important Dates Abstract Submission: September 14, 2012 Paper Submission: September 19, 2012 Notification: October 19, 2012 Conference: November 28–30, 2012 *Location The workshop will be held in Sydney, Australia at NICTA NRL Laboratory. *Organization Organizing Committee and PC Chairs • F. Cassez, NICTA, Sydney, Australia • R. Huuck, NICTA and UNSW, Sydney, Australia • G. Klein, NICTA and UNSW, Sydney, Australia • B. Schlich, ABB Corporate Research, Ladenburg, Germany Program Committee • Cyrille Artho, AIST, RISEC, Japan • Stefan Berghofer, Secunet, Germany • Frédéric Boniol, ONERA, France • Alessandro Coglio, Kestrel, USA • Joe Hurd, Intel, USA • Stefan Kowalewski, RWTH Aachen University, Germany • Thomas Kropf, Robert Bosch GmbH & U. of Tübingen, Germany • Kim G. Larsen, CISS, Aalborg University, Denmark • Toby Murray, NICTA, Sydney, Australia • Jan Peleska, Verified Systems International GmbH and University of Bremen, Germany • John Regehr, University of Utah, USA • Natarajan Shankar, SRI, USA • Zhong Shao, Yale, USA • Konrad Slind, Rockwell Collins, USA • Jun Sun, National University of Singapore, Singapore The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

1 0

L4Re/Fiasco IO memory map.
by Daniel Waddington 15 Aug '12

15 Aug '12

Hi, I have a SATA controller card. When I try to map in the IO memory from the PCI BAR regs an NMI is generated - and the mapping doesn't seemed to have worked (fully?). What might generate this NMI? The same platform/device works fine in Linux. Thanks Daniel

2 2

Fiasco-for ppc32
by Vishal Gupta 15 Aug '12

15 Aug '12

Hello!! I am using fiasco-2012081219 and i want to make fiasco image file for ppc32-[p2041]. but i read Makefiles there is one makeconf.ppc32 but i am not able to make buildir for ppc32. please send me some options. Thanks & Regards, vishal linux

2 1

NUL_problem
by oleg 15 Aug '12

15 Aug '12

2 1

Re: NUL_problem
by oleg 14 Aug '12

14 Aug '12

1 0

NUL_problem
by oleg 14 Aug '12

14 Aug '12

2 1

Problem Booting x86_64 kernel in qemu
by Markus Pfeiffer 12 Aug '12

12 Aug '12

Dear all, I tried building the Fiasco kernel (x86_64, from svn) together with the hello demo inside a qemu as it is shown on the website under "Getting started". Unfortunately the kernel traps while booting (Unexpected trap while booting Fiasco). The trap number seems to be invalid (-8029759185026510704). Any pointers towards where to look for a fix? Cheers Markus -- Markus Pfeiffer, University of St Andrews email: markus.pfeiffer(a)morphism.de | xmpp: markus.pfeiffer(a)jabber.morphism.de

3 5

Questions about Shared Memory Area and IRQ
by ZhangEditing 10 Aug '12

10 Aug '12

Hello. I have been trying to use the shared memory library and have learnt that it uses signals to notify parties that participate in communication. When I looked into the library code, I found that it implements signals with IRQs. However, I could not figure out which IRQ the library use. I have noticed that l4shmc_add_signal creates an IRQ object, but no IRQ number is used. The only thing that appear like an IRQ number is the second argument of l4_irq_attach, which is called by l4shmc_attach_signal_to. But I haven't found any clue about the meaning of the argument. Would you please tell me what the second argument of l4_irq_attach is? I have also noticed that l4shmc_add_signal registered an IRQ object to the namespace of the shared memory area. Does this mean that the IRQs used to implement signals are guaranteed not to conflict with any IRQ used by the hardware or any other software IRQ, regardless of the ORDER in which they are created? Thank you in advance!

2 1

i.MX53QSB port + IOmem access
by Andy Wagner 08 Aug '12

08 Aug '12

PT checks are probably adequate <those should not be modifiable from usr> but any user-context that can map the pages gets access. IO and the io configuration enforce resource assignment policy here and granularity is adequately fine to segregate resources via .cfg file entries. Agreed that trapping slows down IO process but could make porting more transparent. Tradeoff is the amount of work required to manage within the BSP and have that correspond to IO <or wherever the handler would be most suitable>. There is work in either case and it is probably more easily achieved by having the bits cleared at boot or init and minimizing changes required to linux. TZ would be still more entertaining to support. thanks, Andy On Tue Aug 07, 2012 at 13:41:56 -0700, Andy Wagner wrote: > Clearing sp for opacr21 allows the access to complete without fault. > It would be very nice if the sp could remain enabled and have the > fault handler trap to supervisor so that hardware enforcement can > be leveraged as well as software resource allocation check. > > Since mprot and opacr assignments are SoC specific this > would have to be implemented as part of the BSP framework perhaps > over complicating the issue. Preference is to keep things simple > and probably leave in the underlying linux, where the drivers > are located <executing code localization>, without making fiasco > or l4 more aware of the hardware than necessary. Instruction > emulation could be a bit messy due to differing memory maps > between faulting and exception handling contexts. Well, the hardware enforcement used is the page table which makes sure that a client can only access those devices it is given access to. Which benefit does a user/supervisor access check add here? Trapping any access to io memory would also slow down access to devices, plus someone would need to check if the access is valid, which would not be the kernel. Adam -- Adam adam at os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/

2 1

i.MX53QSB port + IOmem access
by Andy Wagner 07 Aug '12

07 Aug '12

Clearing sp for opacr21 allows the access to complete without fault. It would be very nice if the sp could remain enabled and have the fault handler trap to supervisor so that hardware enforcement can be leveraged as well as software resource allocation check. Since mprot and opacr assignments are SoC specific this would have to be implemented as part of the BSP framework perhaps over complicating the issue. Preference is to keep things simple and probably leave in the underlying linux, where the drivers are located <executing code localization>, without making fiasco or l4 more aware of the hardware than necessary. Instruction emulation could be a bit messy due to differing memory maps between faulting and exception handling contexts. Most simply, the sp bits can be cleared by a call into the bsp and leave the boot loader alone. Many thanks for your help and insight. Work now proceeds to migrate the drivers. thanks & best regards, Andy >I'd guess that access from user-mode is the 'problem' here. Could you >check the setting of AIPSTZ_OPACR21 and possibly adapt accordingly? Adam -- Adam adam at os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ Previous message: i.MX53QSB port + IOmem access Next message: Ethernet device Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the l4-hackers mailing list

2 1

Re: Ethernet device
by Matthias Lange 07 Aug '12

07 Aug '12

On Mon, Aug 06, 2012 at 04:47:36PM -0700, Wajidali Whowe wrote: > I prepared another iso image including only l4linux and a small file system prepared by the buildroot (including busybox). > the .devs file was exactly the same as the one that I sent before and similarly the .vbus file. The following is the outputs during bootup until fb-drv takes the console: (moreover I wanted to show also dmesg outputs after boot and "lspci" or "mdev -s" outputs after mounting the /proc and /sys", however I could not copy them from qemu or virtual box as I could not activate serial console, please kindly find the screenshots in the respective order for the dmesg outputs" and sorry for the high load of debug outputs...) Have you tried the "-serial stdio" option? I cannot see anything PCI or e1000 related in the L4Linux log. Can you post the result of "grep PCI .config" and "grep E1000 .config" from your L4Linux config? Matthias. -- Dipl.-Inf. Matthias Lange <mlange(a)sec.t-labs.tu-berlin.de> Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, 10587 Berlin Phone: +49 - 30 - 8353 58 553 Mobile: +49 - 160 - 587 28 07 Web: http://www.t-labs.tu-berlin.de/sect

2 1

i.MX53QSB port + IOmem access
by Andy Wagner 06 Aug '12

06 Aug '12

Many thanks for your response. Yes, reading valid addresses from l4linux within the aips1 region hangs including CCM_CCR. The fiasco kernel does have read access; Aips1[0]: 77777777 Aips1[1]: 77777777 MXC_CCM_CCR: 000016ff Aips1[0] and Aips1[1] contain the mprot fields for the 16 bus masters reachable via Aips1. The values 0x77777777 for both fields are set by u-boot (reset value according to imx53RM 0x0700000/0x00000000). Additional information from the debugger <latter part of kc output>: Control Register: 00c5387d Auxiliary Control Register: 00000000 Coprocessor Access Control Reg: 00f00000 Secure Configuration Register: 00000000 Secure Debug Enable Register: 00000000 Non-Secure Access Control Reg: 00000000 Translation Table Base Reg 0: 7006c000 Translation Table Base Reg 1: 00000000 Translation Table Base Control Reg: 00000000 Domain Access Control Register: 00000001 Data Fault Status Register: 00001008 Instruction Fault Status Register: 00000007 Fault Address Register: 109d4000 Instruction Fault Address Register: a8008ddc Interesting to note that the FAR contains the VA for the read that hangs. I'm not sure where the instruction lies -- it would be great if we were able to get at kallsyms at runtime to obtain symbol <entry point/function id>. Data fault status register suggests "precise external abort" if I'm interpreting the bitmap correctly according to ARM RM. Are there any particular flags to the IO allocation request that should be used other than non-cacheable ? thanks, Andy On Fri Aug 03, 2012 at 19:22:24 -0700, Andy Wagner wrote: > We have a minimal fiasco/l4re/l4linux port running on Freescale i.MX53QSB. > Uart (console), tzic, epit and wdog appear to be working. > > We are now proceeding to port migrate some native drivers (eg., FEC) for QSB into > l4linux. > > We have run into an issue with access to IO regions: > - aips1 region is defined in IO map and virtual to physical mappings are handled via callback in mach_setup <similar to dmamem_cb>. > - virtual memory is apparently being assigned. > We have attempted IO with varying size map/requests down to 4k page. Results are similar > regardless of size of requested region. > > Attempt to read from IO region at assigned virtual location causes the kernel to hang. > Escaping to debugger <esc> and checking both virtual and physical address for IO area reveal same contents -- which suggests that the mapping exists. > > The question is why does the kernel hang ? > > Part of boot log below: > Calling predefined callback for device 'aips1'. > IO | new iomem region: p=53c00000 v=c00000 s=400000 (bmb=0x3650) > IO | map mem: p=53f00000 v=f00000 s=100000: done > aips1 mem phys at 53f00000 - 53ffffff > aips1 mem virt at 08500000 - 085fffff > Added static device 'aips2' with 1 resources. > Calling predefined callback for device 'dmamem'. > DMA mem phys at 703be000 - 70bbdfff > DMA mem virt at 10900000 - 110fffff > dmamem_cb: dma_alloc_coherent: va: 10900000 phys: 703be000 > init_l4: about to read(va): 085d4018 > > VA 85d4018/53fd4018 is CCM_CBCMR <a clock control register, several of > which need to be set up by initialisation code in order to bring up > devices such as FEC>. I supposed that reading any other register such as CCM_CCR also hangs? Does access to this area works from within the kernel? > We have confirmed that writes/read for dmamem virtual addresses appear > in physical equivalent. > > l4linux is configured as arm7; fiasco as cortex/a8. > > The entire aips1 region has been mapped by fiasco as well -- because > fiasco only maps 1M segments and requires access to aips1 <etc> in > order to have uart, clock, tzic. Does fiasco page create a conflict > for IO ? No, that's not a problem. > We also tried to map physical memory transparently to native imx53 > layout using create_mapping(). Access via mappings established this > way result in unresolved page faults. Drivers and IO maps will not > port without significant hassle unless we are able to specify > virt/phys mappings. > > Behaviour of the kernel suggests that page faults are not being handled. You mean the Linux original virtual addresses? Those are above 3G and thus this cannot work. So the figures would have to be changed anyway. create_mapping also will not create an L4 mapping. Specifying a virtual address will work with l4io_request_iomem_region(). Adam -- Adam adam at os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/

2 1

Ethernet device
by Wajidali Whowe 06 Aug '12

06 Aug '12

Dear all, I have been working on running different linux based OSs on top of L4. Is there any documentation or tutorial where I might find information on how to make platform devices available for the linux OS running on top of L4. For instance, I could not get ethernet devices detected by the OS. Best Regards

2 6

i.MX53QSB port + IOmem access
by Andy Wagner 05 Aug '12

05 Aug '12

We have a minimal fiasco/l4re/l4linux port running on Freescale i.MX53QSB. Uart (console), tzic, epit and wdog appear to be working. We are now proceeding to port migrate some native drivers (eg., FEC) for QSB into l4linux. We have run into an issue with access to IO regions: - aips1 region is defined in IO map and virtual to physical mappings are handled via callback in mach_setup <similar to dmamem_cb>. - virtual memory is apparently being assigned. We have attempted IO with varying size map/requests down to 4k page. Results are similar regardless of size of requested region. Attempt to read from IO region at assigned virtual location causes the kernel to hang. Escaping to debugger <esc> and checking both virtual and physical address for IO area reveal same contents -- which suggests that the mapping exists. The question is why does the kernel hang ? Part of boot log below: Calling predefined callback for device 'aips1'. IO | new iomem region: p=53c00000 v=c00000 s=400000 (bmb=0x3650) IO | map mem: p=53f00000 v=f00000 s=100000: done aips1 mem phys at 53f00000 - 53ffffff aips1 mem virt at 08500000 - 085fffff Added static device 'aips2' with 1 resources. Calling predefined callback for device 'dmamem'. DMA mem phys at 703be000 - 70bbdfff DMA mem virt at 10900000 - 110fffff dmamem_cb: dma_alloc_coherent: va: 10900000 phys: 703be000 init_l4: about to read(va): 085d4018 VA 85d4018/53fd4018 is CCM_CBCMR <a clock control register, several of which need to be set up by initialisation code in order to bring up devices such as FEC>. We have confirmed that writes/read for dmamem virtual addresses appear in physical equivalent. l4linux is configured as arm7; fiasco as cortex/a8. The entire aips1 region has been mapped by fiasco as well -- because fiasco only maps 1M segments and requires access to aips1 <etc> in order to have uart, clock, tzic. Does fiasco page create a conflict for IO ? We also tried to map physical memory transparently to native imx53 layout using create_mapping(). Access via mappings established this way result in unresolved page faults. Drivers and IO maps will not port without significant hassle unless we are able to specify virt/phys mappings. Behaviour of the kernel suggests that page faults are not being handled. Any help is appreciated. thanks in advance, Andy

2 1

Re: l4-hackers Digest, Vol 112, Issue 3
by raylei0825ssdut 03 Aug '12

03 Aug '12

I just remove the statement "msr cpsr_c,r7". But It just doesn't Work. And If I change the code to the following: I set the vcpu_state_t registers as following : vcpu->r()->r[6]=(l4_umword_t)exit_map_addr; vcpu->r()->r[4]=(l4_umword_t)(idle_stack+sizeof(idle_stack)-1); vcpu->r()->ip =(l4_umword_t)super_code_map_addr; vcpu->r()->r[5] = (l4_umword_t)idle_code_map_addr; vcpu->r()->sp = (l4_umword_t)0x30000; and I change the my_super_code : asm ( ".pushsection .text\n" ".p2align 12 \t\n" ".global my_super_code \t\n" "my_super_code: \t\n" " swi 0 \t\n" " mov sp, r4 \t\n"" mov lr, r6 \t\n"" mov pc, r5 \t\n"".popsection"); and still, it doesn't work.And The vcpu upcall function will be called again and again. 2012-08-03 raylei0825ssdut 发件人：l4-hackers-request 发送时间：2012-08-03 18:00 主题：l4-hackers Digest, Vol 112, Issue 3 收件人："l4-hackers"<l4-hackers(a)os.inf.tu-dresden.de> 抄送： Send l4-hackers mailing list submissions to l4-hackers(a)os.inf.tu-dresden.de To subscribe or unsubscribe via the World Wide Web, visit http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers or, via email, send a message with subject or body 'help' to l4-hackers-request(a)os.inf.tu-dresden.de You can reach the person managing the list at l4-hackers-owner(a)os.inf.tu-dresden.de When replying, please edit your Subject line so it is more specific than "Re: Contents of l4-hackers digest..." Today's Topics: 1. Re: vcpu example problem (Adam Lackorzynski) ---------------------------------------------------------------------- Message: 1 Date: Thu, 2 Aug 2012 22:14:21 +0200 From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> To: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: vcpu example problem Message-ID: <20120802201421.GA7129(a)os.inf.tu-dresden.de> Content-Type: text/plain; charset=iso-8859-1 Hi, On Thu Aug 02, 2012 at 11:14:34 +0800, ?????? wrote: > Hi, > I am trying to modify the vcpu example of l4re-snapshot to > switch registers to execute my C function.But It doesn't work. > I have read some papers about l4linux tranplantion.and follow it . > To switch the process, I fill the vcpu_state_t structure with > its registers.and call vcpu_resume_commit action.Then Jump to the ASM > Code. > But problem arises when I want to jump from asm code to C > function. What's the Problem? The Code is as following: > #define SVC_MODE 0x00000013 > #define USR_MODE 0x00000010 > > asm volatile > ( > ".pushsection .text\n" > ".p2align 12 \t\n" > ".global my_super_code \t\n" > "my_super_code: \t\n" > " msr cpsr_c, r7\t\n" > " mov lr, r6 \t\n" > " mov pc, r5 \t\n" > //" b my_super_code \t\n" > ".popsection" > ); I think the problem is not the jump but the msr, which you cannot do in user-land and which you probably can safely remove. 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 112, Issue 3 ******************************************

2 1

vcpu example problem
by 雷雷健 02 Aug '12

02 Aug '12

Hi, I am trying to modify the vcpu example of l4re-snapshot to switch registers to execute my C function.But It doesn't work. I have read some papers about l4linux tranplantion.and follow it . To switch the process, I fill the vcpu_state_t structure with its registers.and call vcpu_resume_commit action.Then Jump to the ASM Code. But problem arises when I want to jump from asm code to C function. What's the Problem? The Code is as following: /* * (c) 2009 Technische Universität Dresden * This file is part of TUD:OS, which is distributed under the terms of the * GNU General Public License 2. Please see the COPYING file for details. */ #include <l4/sys/ipc.h> #include <l4/sys/thread> #include <l4/sys/factory> #include <l4/sys/scheduler> #include <l4/sys/utcb.h> #include <l4/sys/kdebug.h> #include <l4/util/util.h> #include <l4/re/env> #include <l4/re/util/cap_alloc> #include <l4/re/util/kumem_alloc> #include <l4/sys/debugger.h> #include <l4/vcpu/vcpu> #include <l4/cxx/iostream> #include <l4/re/error_helper> #include <l4/sys/task> #include <l4/sys/irq> #include <l4/sys/vcpu.h> #include <cstdlib> #include <cstdio> #include <cstring> #define PSR_T_BIT 0x00000000 #define SVC_MODE 0x00000013 #define PSR_E_BIT 0x00000200 #define PSR_I_BIT 0x00000000 #define USR_MODE 0x00000010 using L4Re::chksys; using L4Re::chkcap; static L4::Cap<L4::Irq> irq; static char thread_stack[8 << 10]; static char hdl_stack[8 << 10]; static char idle_stack[8<<10]; static L4::Cap<L4::Task> vcpu_task; static L4vcpu::Vcpu *vcpu; const l4_addr_t super_code_map_addr = 0x10000; const l4_addr_t idle_code_map_addr = 0x20000; const l4_addr_t stack_map_addr = 0x12000; const l4_addr_t exit_map_addr=0x13000; extern char my_super_code[]; extern char my_super_code_excp[]; extern char my_super_code_excp_after[]; extern char exit_code[]; void idle_code(void) { ; while(1) { __asm__ volatile("swi 0"); l4_sleep(500); } } asm( ".global exit_code \t\n" "exit_code: \t\n" "b exit_code \t\n" ); asm volatile ( ".pushsection .text\n" ".p2align 12 \t\n" ".global my_super_code \t\n" "my_super_code: \t\n" " msr cpsr_c, r7\t\n" " mov lr, r6 \t\n" " mov pc, r5 \t\n" //" b my_super_code \t\n" ".popsection" ); static void setup_user_state_arch(L4vcpu::Vcpu *) { } static void handler_prolog() {} static void handler(void) { handler_prolog(); vcpu->state()->clear(L4_VCPU_F_EXCEPTIONS); printf("hello handler\n"); //vcpu->print_state(); // very simple page-fault handling // we're just replying with the only page we have, without checking any // values if (vcpu->is_page_fault_entry()) { printf("page fault\n"); vcpu_task->map(L4Re::This_task, l4_fpage((l4_addr_t)my_super_code, L4_PAGESHIFT, L4_FPAGE_RWX), super_code_map_addr); vcpu_task->map(L4Re::This_task, l4_fpage((l4_addr_t)idle_code, L4_PAGESHIFT, L4_FPAGE_RWX), idle_code_map_addr); vcpu_task->map(L4Re::This_task, l4_fpage((l4_addr_t)exit_code, L4_PAGESHIFT, L4_FPAGE_RWX), exit_map_addr); vcpu->saved_state()->add(L4_VCPU_F_PAGE_FAULTS); } else if (vcpu->is_irq_entry()) { // We use the label 2000 for our IRQ if (vcpu->i()->label == 2000) printf("Our triggered IRQ\n"); else if (vcpu->i()->label == 0) // direct IPC message to vCPU without // going through an IPCgate, label is set to 0 printf("IPC: %lx\n", vcpu->i()->tag.label()); else printf("Unclassifiable message\n"); } else printf("unhandled exception\n"); printf("resume\n"); L4::Cap<L4::Thread> self; self->vcpu_resume_commit(self->vcpu_resume_start()); //vcpu->state()->set(0); while(1) ; } static void vcpu_thread(void) { printf("Hello vCPU\n"); l4_umword_t label; memset(hdl_stack, 0, sizeof(hdl_stack)); //memset(super_stack,0,sizeof(super_stack)); // memset(idle_stack,0,sizeof(idle_stack)); setup_user_state_arch(vcpu); l4_touch_rw(stack,sizeof(stack)); l4_touch_rw(idle_stack,sizeof(idle_stack)); vcpu->saved_state()->set(L4_VCPU_F_USER_MODE | L4_VCPU_F_EXCEPTIONS | L4_VCPU_F_PAGE_FAULTS | L4_VCPU_F_IRQ); vcpu->r()->flags=(l4_umword_t)SVC_MODE; vcpu->r()->r[7]=(l4_umword_t)SVC_MODE; vcpu->r()->r[0]=(l4_umword_t)0; vcpu->r()->r[4]=(l4_umword_t)(idle_stack+sizeof(idle_stack)-1); vcpu->r()->r[6]=(l4_umword_t)exit_map_addr; vcpu->r()->ip =(l4_umword_t)super_code_map_addr; vcpu->r()->r[5] = (l4_umword_t)idle_code_map_addr; vcpu->r()->sp = (l4_umword_t)0x30000; L4::Cap<L4::Thread> self; printf("IRET\n"); vcpu->task(vcpu_task); self->vcpu_resume_commit(self->vcpu_resume_start()); printf("IRET: failed!\n"); while(1); } int run(void) { l4_utcb_t *u = l4_utcb(); L4::Cap<L4::Thread> vcpu_cap; printf("vCPU example\n"); l4_debugger_set_object_name(l4re_env()->main_thread, "vcputest"); // new task vcpu_task = chkcap(L4Re::Util::cap_alloc.alloc<L4::Task>(), "Task cap alloc"); chksys(L4Re::Env::env()->factory()->create_task(vcpu_task, l4_fpage_invalid()), "create task"); l4_debugger_set_object_name(vcpu_task.cap(), "vcpu 'user' task"); /* new thread/vCPU */ vcpu_cap = chkcap(L4Re::Util::cap_alloc.alloc<L4::Thread>(), "vCPU cap alloc"); l4_touch_rw(thread_stack, sizeof(thread_stack)); //l4_touch_rw(hdl_stack,sizeof(hdl_stack)); chksys(L4Re::Env::env()->factory()->create_thread(vcpu_cap), "create thread"); l4_debugger_set_object_name(vcpu_cap.cap(), "vcpu thread"); // get an IRQ irq = chkcap(L4Re::Util::cap_alloc.alloc<L4::Irq>(), "Irq cap alloc"); chksys(L4Re::Env::env()->factory()->create_irq(irq), "irq"); l4_debugger_set_object_name(irq.cap(), "some irq"); // get memory for vCPU state l4_addr_t kumem; if (0) kumem = (l4_addr_t)l4re_env()->first_free_utcb; else { if (L4Re::Util::kumem_alloc(&kumem, 0)) exit(1); } l4_utcb_t *vcpu_utcb = (l4_utcb_t *)kumem; vcpu = L4vcpu::Vcpu::cast(kumem + L4_UTCB_OFFSET); vcpu->entry_sp((l4_umword_t)hdl_stack + sizeof(hdl_stack)); vcpu->entry_ip((l4_umword_t)handler); printf("VCPU: utcb = %p, vcpu = %p\n", vcpu_utcb, vcpu); // Create and start vCPU thread L4::Thread::Attr attr; attr.pager(L4::cap_reinterpret_cast<L4::Thread>(L4Re::Env::env()->rm())); attr.exc_handler(L4Re::Env::env()->main_thread()); attr.bind(vcpu_utcb, L4Re::This_task); chksys(vcpu_cap->control(attr), "control"); chksys(vcpu_cap->vcpu_control((l4_addr_t)vcpu), "enable VCPU"); chksys(vcpu_cap->ex_regs((l4_umword_t)vcpu_thread, (l4_umword_t)thread_stack + sizeof(thread_stack), 0)); chksys(L4Re::Env::env()->scheduler()->run_thread(vcpu_cap, l4_sched_param(2))); // Attach irq to our vCPU thread chksys(irq->attach(2000, vcpu_cap)); // Send some IPCs to the vCPU l4_sleep(10); while (1) { // printf("triger irq\n"); // irq->trigger(); l4_sleep(500); } l4_sleep_forever(); return 0; } int main() { try { return run(); } catch (L4::Runtime_error &e) { L4::cerr << "FATAL uncought exception: " << e << "\nterminating...\n"; } catch (...) { L4::cerr << "FATAL uncought exception of unknown type\n" << "terminating...\n"; } return 1; }

2 1