- l4-hackers - example.com Site

Input driver configuration and use in L4Re
by Paul Boddie 24 May '18

24 May '18

Hello again, I have been implementing input drivers for the keypad/keyboard provided by the Ben NanoNote and Letux 400 notebook computer, and although I appear to have implemented something that works (tested using specialised example code), using the existing OMAP3 keypad code as a guide (in pkg/drivers/input), I wondered whether it is possible to connect such drivers to other components in a convenient way. I see that the input package is the thing that provides the device registry that I use when employing the arm_input_register macro, and in that package is a framework that supposedly exports input drivers as serial I/O devices using the "l4drv" driver. But I can't find anything obvious that uses the connect operation which would need to occur to probe, enable, and attach my driver to this framework. Is it possible to integrate my input drivers to things like Mag, which seems to use input events, or to fbterminal or other things? I haven't seen any documentation or code that demonstrates this, but I suppose that I may have missed something somewhere. Thanks for any help that is offered! Paul

2 4

Re: Assertion failure error in kernel vgic interrupt processing
by nico.hacker 14 May '18

14 May '18

Hi, The previous test is not enough to cause error, this error is not related to peripherals, I have removed almost all peripheral drivers In the previous test, I added a delay operation before the vm2 start, so that vm1 completely up and then start vm2, this will greatly reduce the probability of the error. Now I removed this delay, vm1 and vm2 started simultaneously, then the error will occur frequently (about 1/10 probability). The error is generated when kernel processes vtimer interrupts. Under normal circumstances, after processing a vtimer interrupt, the vcpu thread will return to uvmm and then execute prepare_guest_entry(). This operation will eventually enter the kernel through the system call to set the state of vcpu thread, but when the error occurs, I find that the vcpu thread does not execute vcpu_resume, it processes two consecutive vtimer interrupts. As a result, the assertion fails.  Is the kernel able to guarantee that the complete process of handling vgic and vtimer interrupts (including the process in uvmm) is not interrupted by a new interrupt?  Here's my configuration: ------------------------------------------------------------------------- uvmm.ned vmm.start_vm{   id=1,   mem=256,   vbus=io_busses.vm_hw,   bootargs=common_bootargs .. " ramdisk_size=9100 root=/dev/ram",   kernel="rom/Image.gz",   rd="rom/ramdisk-arm.rd",   fdt="rom/virt-board.dtb",   prio=nil, cpus=0x1 }; vmm.start_vm{   id=2,   mem=256,   vbus=io_busses.vm_nohw,   bootargs=common_bootargs .. " ramdisk_size=9100 root=/dev/ram",   kernel="rom/Image.gz",   rd="rom/ramdisk-arm.rd",   fdt="rom/virt-board.dtb",   prio=nil, cpus=0x1 }; -------------------------------------------------------------------------- io.cfg -- vi:ft=lua local Res = Io.Res local Hw = Io.Hw local add_children = Io.Dt.add_children add_children(Io.system_bus(), function()   VGIC = Hw.Device(function()     Property.hid = "arm-gicc";     Resource.reg0 = Res.mmio(0x12006000, 0x12007fff);     Property.flags = Io.Hw_device_DF_multi_vbus;   end)   VM1_DEV = Hw.Device(function()     Property.hid = "vm1_dev";     Resource.reg0 = Res.mmio(0x70100000, 0x70100FFF); --UART   end)   VM2_DEV = Hw.Device(function()     Property.hid = "vm2_dev";     Resource.reg0 = Res.mmio(0x70100000, 0x70100FFF); --UART   end) end) ---------------------------------------------------------------------------- vm_hw.vbus Io.add_vbusses {   vm_hw = Io.Vi.System_bus(function()     VGIC = wrap(Io.system_bus():match("arm-gicc"));     VM1_DEV = wrap(Io.system_bus():match("vm1_dev"));   end); } ---------------------------------------------------------------------------- vm_nohw.vbus Io.add_vbusses {   vm_nohw = Io.Vi.System_bus(function()     VGIC = wrap(Io.system_bus():match("arm-gicc"));     VM2_DEV = wrap(Io.system_bus():match("vm2_dev"));   end); }---------------------------------------------------------------------------- Nico 于 2018-04-11 05:59:58,Adam Lackorzynski<adam os="" inf="" tu-dresden="" de="">写道:</adam><blockquote style="padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:#ccc 1px solid"><pre>On Mon Apr 09, 2018 at 22:26:38 +0800, nico wrote: > Sorry, the last email did not specify this information. > I gave VM1 all the hardware resources, and it used eight cores. VM2 only has > uart resources (also timer, gic resources), using a single core. I tried to > give both VM1 and VM2 only the necessary hardware resources( uart, timer, gic), > and that error won't happen. Ok, that's interesting. So that means that some of the passed through hardware is causing this. Would you be able to find out which device is causing this, by selectively enabling/disabling devices? Adam > On 4/9/2018 06:28ï¼ Adam Lackorzynski<adam os="" inf="" tu-dresden="" de=""> wroteï¼ > > Hi Nico, > > On Fri Mar 30, 2018 at 10:15:33 +0800, nico wrote: > > Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is > running 64bit Linux. It is recommended to start two or three vms, that > will be easier to reproduce this problem. > > > So, I tried several things but cannot reproduce this issue. I assume > this are single-core VMs only? Any hardware passed through? > Just trying to narrow it down... _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers </adam></pre></blockquote><div style="height:30px;"></div><div style="height:2px;width:298px;border-bottom:solid 2px #e5e5e5"></div><div style="height:20px;"></div><a target="_blank" style="background-image:url(http://r.g.tom.com/kwap/r/app/other/suixinyou.png);bac… center;font-size:14px;background-size: 20px;height: 39px;line-height: 39px;padding-left: 25px;display:block;color:#333333;text-decoration: none;" href="http://mail.tom.com/webmail-static/welcomesxy.html" onmouseover="this.style.cssText='background-image:url(http://r.g.tom.com/kwap/r/app/other/suixinyou.png);bac… center;font-size:14px;background-size: 20px;height: 39px;line-height: 39px;padding-left: 27px;display:block;color:#4c4c4c; text-decoration:underline;'" onmouseout="this.style.cssText='background-image:url(http://r.g.tom.com/kwap/r/app/other/suixinyou.png);bac… center;font-size:14px;background-size: 20px;height: 39px;line-height: 39px;padding-left: 27px;display:block;color:#4c4c4c;text-decoration:none'">随心邮-在微信里收发邮件，及时省电又安心</a>

2 1

Assertion failure error in kernel vgic interrupt processing
by nico 10 Apr '18

10 Apr '18

2 5

Entrypoint for user-space syscall instruction
by Zihan Yang 26 Mar '18

26 Mar '18

Hi, I'm trying to figure out the entry for 'syscall' in Fiasco, I already know that Fiasco will set MSR_STAR, MSR_LSTAR and MSR_CSTAR in Cpu::setup_sysenter. However, things don't seem right when I run a simple program of my own, which is compiled statically outside in Ubuntu with gcc 5.4.0. This program directly issues a single 'syscall' instruction (instead of the syscall() function), which is equivalent to getpid(). Here is the program, which is compiled with gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c -------------------- BEGIN --------------------- //syscall_single.c //gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c #include <stdio.h> void printres(unsigned long res) { printf("Done, id = %d\n", res); } int main() { asm volatile( "mov $39, %%rax\n" "syscall\n" "mov %%rax, %%rdi\n" "call printres" : : : "cc" ); return 0; } --------------------- END ------------------------ Since Fiasco has specified MSR_LSTAR, I expect every normal system call to goto the 'entry_sys_fast_ipc_c' in src/kern/ia32/64/entry-native.S, therefore I add such line at the beginning of entry_sys_fast_ipc_c -------------------- BEGIN --------------------- .extern unsigned long test_rax; entry_sys_fast_ipc_c: movq %rax, test_rax //mov rax to the global variable test_rax --------------------- END ------------------------ And I print this variable in 'sys_ipc_wrapper'. Now strange things happen, when I type './syscall_single' in the shell, test_rax is never 39 at any time! But yet it can get the right result, and there is output in 'dispatch_system_call' in l4linux side(manually added by me). My questions are (1) What is the entrypoint and actual path if a user program directly issues a syscall instruction? (2) I find dispatch_system_call judges whether there is a system call based on the 'trap_nr' field of thread_struct, does this mean it is implemented through exception? Thanks.

1 1

Ben NanoNote patches (MIPS/Ingenic JZ4720) and memory mapping issues
by Paul Boddie 16 Mar '18

16 Mar '18

Hello, Accompanying my patches for the MIPS Creator CI20 (Ingenic JZ4780), I have some patches that get Fiasco.OC booting on the Ben NanoNote (Ingenic JZ4720). Currently, I can get a task running that shows some data on the screen. More details about the Ben NanoNote can be found here: http://en.qi-hardware.com/wiki/Ben_NanoNote (It is a "palmtop" device from around 2010 that was made in fairly limited quantities but unfortunately didn't get the attention it deserved that might have seen follow-on models, and many more units, being made.) Unfortunately, the data I display on the screen isn't aligned properly. This isn't a fundamental problem since I was happily using the screen to emit bit patterns in order to debug the kernel while working to bring it up on the hardware. However, now, in my example task, I see what would appear to be a 9-pixel misalignment with the screen. Something like this, each digit being a pixel of a certain colour, with groups of ten sharing the same colour: 122222222223333333333...111111111 Although I suspect that this is some kind of peripheral initialisation issue, none of the device registers are any different from before, and I can even neglect to initialise most of them, keeping the configuration from the bootloader, and still see the problem. The registers I do have to change are the ones that tell the LCD peripheral where the framebuffer is, but I can check that the values I use are consistent with where I am storing screen data. So it makes sense to me to check whether there might be something related to L4Re or Fiasco.OC (and my modifications, of course) that could be causing this. In my task, I do the following: l4re_ma_alloc_align(fb_size, fbmem, L4RE_MA_CONTINUOUS | L4RE_MA_PINNED, 6) Here, the documentation indicates that the alignment will be 2**6 or 64 bytes, although it will in practice be page-aligned and thus 4096 bytes in my case. This, upon success, is then followed by this: l4re_rm_attach(&fb_vaddr, fb_size,L4RE_RM_SEARCH_ADDR | L4RE_RM_EAGER_MAP, fbmem, 0, L4_PAGESHIFT) And upon success, I obtain the physical address for the region: l4re_ds_phys(fbmem, 0, &fb_paddr, &fb_size_out) Both the virtual and physical addresses seem to be page-aligned. From my limited knowledge of the hardware, I cannot envisage a situation where writes to the physical memory would be offset, let alone wrapped in the way described above. But I suppose I could easily be unaware of other things that might be happening, and so it seems worthwhile to ask around. By the way, my patches are here: http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html I would certainly appreciate hearing any ideas about things I might have overlooked. Thanks, Paul

1 2

I got an issue, when testing command like this :qemu–system–aarch64 -kernel uimage -smp 2...
by Jiang qihong 14 Mar '18

14 Mar '18

The whole command , qemu–system–aarch64 -kernel uimage -M vexpress -a15 -cpu cortex-a57 -smp 2 -m256 --nographic The issue is that when running into shell, i didn't find two cpus. The parameter "-smp 2",didn't work. Does qemu support arch arm -v8 when using the parameter(-smp)? From jqh mobile phone.

3 2

How to show call path in backtrace with jdb?
by Zihan Yang 14 Mar '18

14 Mar '18

Hi all, I'm trying to debug L4Linux using jdb in Fiasco. I have added a breakpoint in a function(e.g, syscall_exit), and it did hit into jdb when I run. However, when I type 'bt' in jdb, it only prints the values in the stack, or worse, it sometimes couldn't print the stack. I have tried enabling L4_DEBUG_REGISTER_NAMES and CONFIG_FRAME_POINTER in L4Linux, and uncheck 'config without frame pointer' and 'generate inline code' options in Fiasco, but still it doesn't work. QEMU could be an option, but qemu debugs the whole system while I just want to focus on the L4Linux itself because I just want to figure out the call path of ret_from_fork and how does L4Linux stop the user dispatch loop, etc. Is there any way to show the the call path in jdb to assist the debugging work? By way, is there any doc describing the call path from fiasco to L4Linux, I know it is implemented with sysretq or iretq, but where is the entrypoint in L4Linux? For example, when I type 'ls /bin' in shell, it would finally go into L4Linux's function 'syscall_exit()', but how can I find the call path between them? If I can figure it out, maybe I just don't need to debug anymore. Thanks

2 1

Is the L4Linux running as a Fiasco.OC server?
by Zeyu Mi 09 Mar '18

09 Mar '18

Hi all, I am studying the implementation of the Fiasco.OC and the L4Linux. I have searched on the Internet and many papers and documents record that L4Linux runs as an L4 server and any L4Linux user process is a new task, which has a new page table different from that of an L4Linux server. However, the experiment result seems to conflict with those documents. When I started a new program in the L4Linux shell and used "lp" command (show present list) in JDB, I noticed that there was one thread having "vcpu" state. But the resulted list did not contain any new thread or task which is related to the new program. I am very confused and wondering whether or not the implementation recorded in those papers or documents are wrong or obsolete? The experiment is based on "l4re-snapshot-2016082114". Thanks in advance for any explanation. -- Best Regards Zeyu Mi

3 12

Activating the sigma0 thread in the Fiasco kernel
by Paul Boddie 08 Mar '18

08 Mar '18

Hello, I've been trying to coerce L4Re and Fiasco.OC to work with the Ben NanoNote, which is related to the MIPS Creator CI20 that is (mostly - see earlier discussions) supported by this software. There are a few challenges involved, such as avoiding MIPS32r2 instructions that the NanoNote's SoC doesn't support (JZ4740 in the NanoNote versus JZ4780 in the CI20), and positioning things appropriately to avoid upsetting the installed bootloader. Since I last posted anything about this, I've managed to get Fiasco to go about its bootstrapping business, proceeding from the bootstrap package, entering the kernel, running kernel_main, doing various initialisation tasks, enabling interrupts, and ending up in the init_workload method where a sigma0 thread and a boot thread are created and activated. It is at this point that I seem to have encountered a particularly stubborn problem: how to get the sigma0 thread to activate and return control to init_workload for the boot thread to be activated, then going on to finish what little remains of the bootstrapping process. Strangely, the boot thread has no difficulty in being activated and returning control if I put it first in the sequence, but sigma0 seems to cause something different to happen. Now, for this activation, it seems that the real action begins in Context::switch_cpu, where an exchange of stack pointers occurs and a branch is made to the Context::switchin_context method, with the old context presumably being made to resume after the branchpoint. As far as I can tell, both threads manage to set this up correctly. I see that the new context then causes Thread::user_invoke to be called, with execution proceeding via the ret_from_user_invoke routine and ultimately into the user task. Looking at the address to which the CPU will "return" to in user mode, all seems reasonable and consistent with the configuration of sigma0. However, one thing that baffles me somewhat is the way that interrupts are disabled in Thread::user_invoke. Given that the CPU ends up in the task in user mode, it would surely need some kind of exception or interrupt for the kernel to be re-entered, yet I don't see any operation that re-enables interrupts anywhere. Maybe this is the cause of my problem, but I don't understand how sigma0 would be different from anything else. I have needed to change some CPU-level operations to adapt the code to the earlier microarchitecture revision, but I don't think I've made any obvious mistakes, and I have seemingly figured out how to describe the interrupt system because for a while I couldn't get past the Delay::init invocation in the bootstrap process which relies on interrupts working. (Some comments in the code would have helped me guess what numbers to use in certain invocations.) Does anyone have any thoughts or guidance about what I should be looking at? Thanks in advance and sorry for the wall of text! Paul

2 6

Fiasco.OC development version available on github
by Matthias Lange 22 Feb '18

22 Feb '18

Hi, Kernkonzept proudly announces the availability of a development version of the Fiasco.OC microkernel on github [1]. It features a detailed history and will be updated regularly. Those interested in exploring the latest changes can amend the latest L4Re snapshot release (see [2]) with this development version. We plan to release development versions of the build system and selected userspace components in the weeks ahead. So, let us know what you think. Cheers, Matthias. [1] https://github.com/kernkonzept/fiasco [2] https://l4re.org/download.html -- Matthias Lange, matthias.lange(a)kernkonzept.com, +49-351-41 888 614 Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

4 4