Problem with L4re and L4Linux on Qemu/VMware

Daniel (Xiaolong) Wang xiaolongw at mail.usf.edu
Mon Jun 26 23:29:42 CEST 2017


Hi Adam and all,

I figured the problem out. Adam was right. The issue was due to the input not working. Although I do not know why there is no response for both QEMU and VMware VM, it might be helpful for someone who has the same issue.

The default command automatically launches QEMU. But without specifying "-serial stdio” a new window will pop up and there is no way to input anything e.g. enter (at least for me). 
# make qemu O=${build-dir} MODULE_SEARCH_PATH=${build-dir} 

The same thing when I created a iso image using grub2iso. Instead I created a ELF image use “make elfimage”, then launches it as:
# qemu-system-i386 -m 256 -serial stdio -kernel ${path_of_elfimage} -append “-arg fiasco,,-serial_esc -freq=533000”

Then I can interact with the VM. Is it the correct way to run it or did I do something wrong earlier that caused it?

Also I still could not make the L4Linux run stably on BeagleBone Black as I mentioned in another email (https://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg07891.html <https://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg07891.html>)

The L4Linux got boot then shortly about 10 second the system reboot… I will try with another device but I doubt it is due to the device. Any help would be greatly appreciated!

Thanks
-Dan
> On Jun 26, 2017, at 3:37 PM, Daniel (Xiaolong) Wang <xiaolongw at mail.usf.edu> wrote:
> 
> Hi Adam,
> 
> I’m not sure if input works. I guess it is probably due to the input not working. Is it possible that the input on both QEMU and VMware fusion failed? Have you encountered it before? Any suggestions for debug/fix?
> 
> Thanks
> -Dan  
>> On Jun 22, 2017, at 5:44 PM, Adam Lackorzynski <adam at os.inf.tu-dresden.de> wrote:
>> 
>> 
>> On Wed Jun 21, 2017 at 16:25:01 -0500, Daniel (Xiaolong) Wang wrote:
>>> I’m sorry to bother, again… But I keep getting problems hope you can give me some advice.
>>> 
>>> I’m trying to test out L4re +L4Linux on X86 and ARM i.MX6. I downloaded the newest l4re-snapshot-2006082114. I built Fiasco with Intel Pentium Pro and Virtualization (did not change anything else).
>>> I built L4re with Pentium Pro type CPU (everything else are default settings). Then I built L4Linux with the L4re builddir. I turned off 64-bit kernel, CPU selected Pentium-Pro, turned off most of the settings as the warning instructed. 
>>> 
>>> These are the settings of L4Linux that I enabled:
>>> 
>>> Processor type and features:
>>> 	* DMA memory allocation support
>>> 	* Processor feature human-readable name
>>> 	* Fast CPU feature tests
>>> 	* Support for extended X86 platform
>>> 	* Single-depth WCHAN output
>>> 	* High memory support is OFF
>>> 	* Enable bounce buffers
>>> 	* X86 architectural random number generator
>>> 	* Enable seccomp to safety compute untrusted bytecode
>>> 	* Enable the LDT
>>> 
>>> Power Management and ACPI options:
>>> 	* Suspend to RAM and standby
>>> 	* device power management core functionality
>>> 	* CPU Frequency scaling is OFF
>>> Bus Options:
>>> 	* PCI support
>>> 	* PCI access mode is Direct
>> 
>> That's ok. You can also use one of the defconfigs, e.g.
>> x86_32-mp_vPCI_defconfig.
>> 
>>> I was able to compile all three parts and build both iso image (for vmware fusion on macOS) and qemu simulator. I first tested hello, hello-cfg, hello-shared, frame buffer-example-x86, all of those works as expected.
>> 
>> Ok, good.
>> 
>>> However when I tried to build L4Linux-basic and L4Linux-mag-x86. Not of them works.
>>> 
>>> for L4Linux-mag-x86 the system shows a diagram “system is booting” then hang forever.
>> 
>> In such a case it is essential to have the serial output to see what's
>> going on as we won't see anything on the graphical screen in this case.
>> 
>>> for L4Linux-basic the image boot but freeze soon. The screen shows:
>>> 
>>> 	l4cdds: No name given, not starting
>>> 	brd: module loaded
>>> 	l4cdds: no name given, not starting
>>> 	moused: ps/2 mouse device common for all mice
>>> 	l4x: Faking dummy RTC
>>> 	rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
>>> 	rtc_cmos rtc_cmos: only 24-hr supported
>>> 	rtc_l4x: l4x-rtc: Could not find ‘rtc’ cap
>>> 	rtc_l4x: probe of rtc-l4x failed with error -2
>>> 	NET: Registered protocol family 17
>>> 	L4IRQ: set irq type of 64 to 1
>>>    	RAMDISK: ext2 filesystem found at block 0
>>> 	RAMDISK: Loading 3072KiB [1 disk] into ram disk… done.
>>> 	VFS: Mounted root (ext2 filesystem) on device 1:0.
>>> 	Freeing unused kernel memory 188K (00494000 - 004c3000)
>>> 	Write protecting the kernel text: 2684K
>>> 	Write protecting the kernel read-only data 768k
>>> 	rodata_test: test data was not read only
>>> 
>>> 	Please press Enter to activate this console. clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2845e81c5f6, max-idle_ns: 440795276432 ns
>>> 	clocksource: Switched to clocksource tsc
>> 
>> That actually looks good. It finished booting as it is supposed to do.
>> Is input not working, i.e. pressing enter?
>> 
>> 
>> 
>> Adam
>> 
>> _______________________________________________
>> l4-hackers mailing list
>> l4-hackers at os.inf.tu-dresden.de
>> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20170626/e19c31d5/attachment.htm>


More information about the l4-hackers mailing list