l4-hackers June 2008

l4-hackers@os.inf.tu-dresden.de

13 participants
18 discussions

Problem with compiling Fiasco L4 on Suse
by Stefan Kögel 23 Jun '08

23 Jun '08

Hi, first of all thanks for your great help. I've never seen such an active and fast response. Now to my problem: I recently switched to OpenSuse 11 and tried to compile the whole L4 Tree using make -C l4 O=~/my-l4-build oldconfig make O=~/my-l4-build/ While doing so make stops with: make[5]: Entering directory `/Fiasco/svn/tudos/dice/lib/debug' /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 -module -version-number 0:3:0 -o libdice-debug.la -rpath /home/drops/lib/dice init.lo BETrace.lo L4BETrace.lo L4V4BETrace.lo g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbeginS.o .libs/init.o .libs/BETrace.o .libs/L4BETrace.o .libs/L4V4BETrace.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.2.3/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o -Wl,-soname -Wl,libdice-debug.so.0 -o .libs/libdice-debug.so.0.3.0 g++: /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o: No such file or directory g++: /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbeginS.o: No such file or directory g++: /usr/lib/gcc/i486-linux-gnu/4.2.3/crtendS.o: No such file or directory g++: /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o: No such file or directory A "locate crtn.o crti.o crtbeginS.o crtendS.o" returns "/usr/lib/crti.o /usr/lib/crtn.o /usr/lib/gcc/i586-suse-linux/4.1.3/crtbeginS.o /usr/lib/gcc/i586-suse-linux/4.1.3/crtendS.o" How can I tell "make" to use these files, instead of "/usr/lib/gcc/i486-linux-gnu/4.2.3/..."? Or do I need to configure gcc in a different way? Currently this config is in use: gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.3 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.3 20080612 (prerelease) (SUSE Linux) Thanks in advance. Kind Regards, Stefan

2 1

how can we know the needed module?
by fangzhengshu 21 Jun '08

21 Jun '08

hi all, when I want to test a module of a package,I don't know which modules it need.In a given example in wiki.tudos.org ,we know the "hello" module's dependent modules ,but when I want to run another module like ore I don't know how many modules and which it need. Is there any way that I can fast know how many modules does a module need without read the code deeply? fang,

2 1

ore problems
by fei li 17 Jun '08

17 Jun '08

Hi I accepted the advice and recompiled the ore package, then I started it in qemu, this time I got the result: simplets| Configured for 64 tasks. io | Using platform configuration 'x86' io | PCI: Using configuration type 1 io | PCI: Probing PCI hardware io | PCI: Probing PCI hardware (bus 00) io | PCI: PIIX3: Enabling Passive Release on 00:01.0 io | Limiting direct PCI/PCI transfers. io | Activating ISA DMA hang workarounds. io | 00000000-ffffffff : PCI mem io | e0000000-e1ffffff : Cirrus Logic GD 5446 io | e2000000-e2000fff : Cirrus Logic GD 5446 io | e3000000-e30000ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/ io : 8139C+ io | 0000-ffff : PCI IO io | 0cf8-0cff : PCI conf1 io | 1000-100f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] io | 1400-14ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ io | b100-b11f : Intel Corporation 82371AB/EB/MB PIIX4 ACPI bmodfs | Passed the following modules: bmodfs | module "/ore" (2322kB) loader | "ore" is a valid binary image loader | ore: Starting sigma0-style application loader | ore: Loading binary loader | ore,#d: Entry at 00009f8c => 01800000 loader | ore,#d: Started io | Available IRQs=[ <!0> 1 <!2> 3 <!4> 5 6 7 8 9 a b c d e f 10 11 ] ore | Softirq daemon starting ore | Initializing DDE page cache ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 8086:7000 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 8086:7010 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 8086:7113 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 1013:b8 ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | _add_ddekit_device: Detected device: 10ec:8139 ore | <6>e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI ore | <6>e100: Copyright(c) 1999-2006 Intel Corporation ore | <6>8139too Fast Ethernet driver 0.9.28 ore | <6>8139too 0000:00:04.0: This (id 10ec:8139 rev 20) is an enhanced 81 ore : 39C+ chip ore | <6>8139too 0000:00:04.0: Use the "8139cp" driver for improved perform ore : ance and stability. ROOT: Sending ports 1400-14ff to task #07 io | PCI: Setting latency timer of device 00:03.0 to 64 ore | <7>8139too 0000:00:04.0: unknown chip version, assuming RTL-8139 ore | <7>8139too 0000:00:04.0: TxConfig = 0x74800000 ore | <6>eth0: RealTek RTL8139 at 0x8000, 52:54:00:12:34:56, IRQ 10 ore | <7>eth0: Identified 8139 chip type 'RTL-8139' ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | unimplemented: pci_fixup_device ore | l4dde26_register_rx_callback: New rx callback @ 0x018012f0. ore | main(): initialized DDELinux2.6 ore | main(): loopback: 0 ore | <6>device lo entered promiscuous mode ore | <6>device eth0 entered promiscuous mode ore | <6>eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 ore | main(): Initialized 2 network devices. ore | Device = lo, IRQ = 0, MAC = 00:00:00:00:00:00 ore | Device = eth0, IRQ = 10, MAC = 52:54:00:12:34:56 ore | main(): Registering 'ORe' at names.. Now eth0 has mac address, but I guess there are still problems, I have some questions, first is what does "unimplemented: pci_fixup_device" mean, is there any driver I haven't installed or anything else? The second is "ore | <7>8139too 0000:00:04.0: unknown chip version, assuming RTL-8139", I have choosed the 8139 and 8139c+ options, what does "unknown" mean? Can't recognize? The third is "device eth0 entered promiscuous mode", when we let promiscuous mode enabled, we know maybe it's under monitoring or .., what does this mean? I'm a newbie in this field, some questions maybe too simple or even stupid, but I just want to solve the problem and thanks a lot. Thanks and best regards!

2 1

RE: ore problems
by Bjoern Doebel 17 Jun '08

17 Jun '08

Hi Li, Please consider using the l4-hackers mailing list for such questions, because you might get faster answers there. > I install ore in my machine and start it in qemu, but I get > these informations, what's the problem, thanks. > > First I'll show you my menu.lst > > title ORe > kernel /bootstrap -serial -modaddr 0x2000000 > module /fiasco -serial_esc -comport 1 > module /sigma0 > module /roottask task modname "bmodfs" attached 1 modules > module /names > module /log > module /l4io > module /events > module /dm_phys > module /simple_ts > module /bmodfs > module /ore > module /loader -fprov=BMODFS ore The menu.lst looks fine so far. > The output in qemu is > > io | Using platform configuration 'x86' > io | PCI: Using configuration type 1 > io | PCI: Probing PCI hardware > io | PCI: Probing PCI hardware (bus 00) > io | PCI: PIIX3: Enabling Passive Release on 00:01.0 > io | Limiting direct PCI/PCI transfers. > io | Activating ISA DMA hang workarounds. > io | 00000000-ffffffff : PCI mem > io | e0000000-e1ffffff : Cirrus Logic GD 5446 > io | e2000000-e2000fff : Cirrus Logic GD 5446 > io | e3000000-e30000ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/ > io : 8139C+ Ok. So you configure Qemu to emulate an RTL8139 network interface. > io | 0000-ffff : PCI IO > io | 0cf8-0cff : PCI conf1 > io | 1000-100f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] > io | 1400-14ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ > io | b100-b11f : Intel Corporation 82371AB/EB/MB PIIX4 ACPI > bmodfs | Passed the following modules: > bmodfs | module "/ore" (2176kB) > loader | "ore" is a valid binary image > loader | ore: Starting sigma0-style application > loader | ore: Loading binary > loader | ore,#d: Entry at 00009f8c => 01800000 > loader | ore,#d: Started > io | Available IRQs=[ <!0> 1 <!2> 3 <!4> 5 6 7 8 9 a b c d e f 10 11 ] > ore | Softirq daemon starting > ore | Initializing DDE page cache > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | _add_ddekit_device: Detected device: 8086:7000 > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | _add_ddekit_device: Detected device: 8086:7010 > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | _add_ddekit_device: Detected device: 8086:7113 > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | _add_ddekit_device: Detected device: 1013:b8 > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | _add_ddekit_device: Detected device: 10ec:8139 > ore | <6>e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI > ore | <6>e100: Copyright(c) 1999-2006 Intel Corporation Here we see, that the e100 NIC driver is trying to initialize. However, there is no such NIC in your setup and therefore there is no eth0 available. Go to l4/pkg/ore/server and run "make config" and configure ORe to use the RTL8139 network driver. > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | unimplemented: pci_fixup_device > ore | l4dde26_register_rx_callback: New rx callback @ 0x018012f0. > ore | main(): initialized DDELinux2.6 > ore | main(): loopback: 0 > ore | <6>device lo entered promiscuous mode > ore | main(): Initialized 1 network devices. > ore | Device = lo, IRQ = 0, MAC = 00:00:00:00:00:00 > ore | main(): Registering 'ORe' at names... > ore | main(): Ready for service. Kind regards, Bjoern

1 0

Compiling L4 with a different Fiasco Config
by Stefan Kögel 13 Jun '08

13 Jun '08

I downloaded the svn (version 373) hello module and would like to compile it. I use: - make -C l4 O=/my-build oldconfig - make O=/my-build Here "make" always compiles the kernel using the ia32short template. Compiling Fiasco separately with a different config works fine. Now my questions: Is it possible to build L4 using a different Fiasco Config? If so, how? Is it possible to compile L4 hello module without building the kernel and use this together with the separately build kernel? If so, how? Thanks for your help. Kind Regards, Stefan

2 2

CFP: JAR Special Issue On Operating Systems Verification
by Hendrik Tews 11 Jun '08

11 Jun '08

[apologies for crossposting, here is a CFP that might be interesting for those that are into formal methods -- Hendrik] Call for Papers Special Issue On Operating Systems Verification Journal of Automated Reasoning Industrial-strength software analysis and verification has advanced in recent years through the introduction of model checking, automated and interactive theorem proving, static analysis techniques, as well as correctness by design. However, many techniques are working under restrictive assumptions which are invalidated by complex (embedded) system software such as operating system kernels, low-level device drivers or microcontroller code. This special issue will be devoted to the formal verification of operating systems and similar low-level systems code. The emphasis is on techniques and methods that provide real solutions to real software problems. 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. Submissions are encouraged, but not limited to, the following topics and their application to operating systems or low-level systems code: * model checking * automated and interactive theorem proving * embedded systems development * programming languages * verifying compilers * software certification Manuscripts should be unpublished works and not submitted elsewhere. Revised and enhanced versions of papers published in conference proceedings that have not appeared in archival journals are eligible for submission. All submissions will be reviewed according to the usual standards of scholarship and originality. Papers should be in pdf format, following the JAR guidelines for authors, and be submitted via EasyChair at: http://www.easychair.org/conferences/?conf=jarosv08 Please do not use the Springer online submission system for the special issue at this stage, but EasyChair instead. To encourage a speedy review cycle, it will be expected that authors of submissions also serve as referees. For more information, please see http://www.cse.unsw.edu.au/~kleing/JAR-OSV-08/ Guest Editors Gerwin Klein, NICTA, Australia, gerwin.klein at nicta.com.au Ralf Huuck, NICTA, Australia, ralf.huuck at nicta.com.au Bastian Schlich, RWTH Aachen, Germany, schlich at cs.rwth-aachen.de Important Dates Sep 15 2008 Submission Deadline Dec 15 2008 Notification of accepted papers Jan 15 2009 Final version

1 0

timing right
by eric johnson 07 Jun '08

07 Jun '08

i need to write a user land program which would measure the times in milliseconds . how do i do this ? i wouldnt want to make a system call. ej

2 1

Driving audio card
by Saya Sheng (盛淑蕙) 06 Jun '08

06 Jun '08

Hi all, Does anybody know whether there are some documents in English for teaching how to drive a audio card such that a application on l4 can use it? It is known that driver can be ported via DDE but how to do that? I am a newbie in this area, Could you please give me some advice? Thanks in advance Saya

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers June 2008