- l4-hackers - example.com Site

booting lx_ginger.iso
by cem akpolat 21 Jul '14

21 Jul '14

Hi, There is also issues while booting lx_ginger.iso (from l4android.org) it stems from the lx_ginger.cfg file. akpolat@akpolatX240:~/Desktop$ qemu-system-x86_64 -cdrom lx_ginger.iso -m 512 -serial stdio Welcome to Fiasco.OC (ia32)! L4/Fiasco.OC ia32 microkernel (C) 1998-2011 TU Dresden Rev: r30 compiled with gcc 4.4.3 for Intel Pentium [.up] Build: #32 Tue Feb 15 10:07:33 CET 2011 Performance-critical config option(s) detected: CONFIG_NDEBUG is off CONFIG_NO_FRAME_PTR is off Superpages: yes Kmem:: cpu page at 1fff8000 (4096Bytes) Enabling SVM support NASID: 0x10 ACPI-Init ACPI: RSDP = 0xf09e0 pRSDT = 1ffffbc1 pXSDT = 0 ACPI: OEM: BOCHS MADT = 0x203ffb11 IO-APIC[ 0]: struct: 0x203ffb45 adr=fec00000 IO-APIC[ 0]: pins 23 PIN[ 0m]: vector=20, del=0, dm=physical, dest=0 (high, edge) PIN[ 1m]: vector=21, del=0, dm=physical, dest=0 (high, edge) PIN[ 2m]: vector=22, del=0, dm=physical, dest=0 (high, edge) PIN[ 3m]: vector=23, del=0, dm=physical, dest=0 (high, edge) PIN[ 4m]: vector=24, del=0, dm=physical, dest=0 (high, edge) PIN[ 5m]: vector=25, del=0, dm=physical, dest=0 (high, edge) PIN[ 6m]: vector=26, del=0, dm=physical, dest=0 (high, edge) PIN[ 7m]: vector=27, del=0, dm=physical, dest=0 (high, edge) PIN[ 8m]: vector=28, del=0, dm=physical, dest=0 (high, edge) PIN[ 9m]: vector=29, del=0, dm=physical, dest=0 (high, edge) PIN[10m]: vector=2a, del=0, dm=physical, dest=0 (high, edge) PIN[11m]: vector=2b, del=0, dm=physical, dest=0 (high, edge) PIN[12m]: vector=2c, del=0, dm=physical, dest=0 (high, edge) PIN[13m]: vector=2d, del=0, dm=physical, dest=0 (high, edge) PIN[14m]: vector=2e, del=0, dm=physical, dest=0 (high, edge) PIN[15m]: vector=2f, del=0, dm=physical, dest=0 (high, edge) PIN[16m]: vector=30, del=0, dm=physical, dest=0 (high, edge) PIN[17m]: vector=31, del=0, dm=physical, dest=0 (high, edge) PIN[18m]: vector=32, del=0, dm=physical, dest=0 (high, edge) PIN[19m]: vector=33, del=0, dm=physical, dest=0 (high, edge) PIN[20m]: vector=34, del=0, dm=physical, dest=0 (high, edge) PIN[21m]: vector=35, del=0, dm=physical, dest=0 (high, edge) PIN[22m]: vector=36, del=0, dm=physical, dest=0 (high, edge) PIN[23m]: vector=37, del=0, dm=physical, dest=0 (high, edge) IO-APIC: dual 8259: yes IO-APIC: ovr[ 0] 00 -> 2 IO-APIC: ovr[ 1] 05 -> 5 IO-APIC: ovr[ 2] 09 -> 9 IO-APIC: ovr[ 3] 0a -> a IO-APIC: ovr[ 4] 0b -> b Allocate cpu_mem @ 0xfeff6000 Local APIC[00]: version=11 max_lvt=5 APIC ESR value before/after enabling: 00000000/00000000 Using the Local APIC timer on vector 90 (Periodic Mode) for scheduling SERIAL ESC: allocated IRQ 4 for serial uart SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. Absolute KIP Syscalls using: Sysenter CPU[0:0]: AuthenticAMD (6:6:3:0)[00000663] Model: Athlon (Palomino) at 2694 MHz 255/512 Entry I TLB (4K pages) 255 Entry I TLB (4M pages) 255/512 Entry D TLB (4K pages) 255 Entry D TLB (4M pages) 64 KB L1 I Cache (2-way associative, 64 bytes per line) 64 KB L1 D Cache (2-way associative, 64 bytes per line) 512 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 28672 bytes (7 pages) VMX: Not supported Calibrating timer loop... done. SIGMA0: Hello! KIP @ 400000 Found Fiasco: KIP syscalls: yes allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [0:1000;9efff] [0:10c000;13ffff] [4:140000;18ffff] [0:190000;2dbfff] [4:2dc000;2dcfff] [0:2dd000;3fffff] [0:469000;137dfff] [4:137e000;7883fff] [0:7884000;1d70ffff] IOMEM:---------------------- [0:0;fff] [0:9f000;fffff] [0:1fffe000;febfffff] [0:fec01000;fedfffff] [0:fee01000;ffffffff] IO PORTS-------------------------- [0:0;fffffff] MOE: Hello world MOE: found 377736 KByte free memory MOE: found RAM from 1000 to 1d710000 MOE: allocated 471 KByte for the page array @0x1000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:501000] BOOTFS: [137e000-146d25c] [C:503000] l4re BOOTFS: [146e000-165555b] [C:504000] ned BOOTFS: [1656000-1ea917f] [C:505000] io BOOTFS: [1eaa000-1f82d39] [C:506000] rtc BOOTFS: [1f83000-22812f8] [C:507000] mag BOOTFS: [2282000-23d7cf5] [C:508000] fb-drv BOOTFS: [908a000-908a83b] [C:509000] lx_ginger.cfg BOOTFS: [9064000-90643b7] [C:50a000] x86-legacy.devs BOOTFS: [9080000-908086f] [C:50b000] x86_android.vbus BOOTFS: [23d8000-28179f3] [C:50c000] vmlinuz.android BOOTFS: [2818000-2912000] [C:50d000] root-x86-ginger.img BOOTFS: [2913000-7884000] [C:50e000] system-x86-ginger.img MOE: cmdline: moe rom/lx_ginger.cfg MOE: Starting: rom/ned rom/lx_ginger.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/lx_ginger.cfg' io | Io service io | Hello from L4-ACPICA io | Find root Pointer io | AcpiOsMapMemory(40e, 2) = 40040e io | AcpiOsMapMemory(9fc00, 400) = 49fc00 io | AcpiOsMapMemory(e0000, 20000) = 4e0000 io | Find root Pointer: f09e0 io | AcpiOsMapMemory(f09e0, 24) = 4f09e0 io | ACPI: RSDP 0xf09e0 00014 (v00 BOCHS ) io | AcpiOsMapMemory(1ffffbc1, 24) = bffbc1 io | ACPI: RSDT 0x1ffffbc1 00034 (v01 BOCHS BXPCRSDT 00000001 BXPC 00000001) io | AcpiOsMapMemory(1ffffbc1, 34) = bffbc1 io | AcpiOsMapMemory(1ffff1c0, 24) = bff1c0 io | ACPI: FACP 0x1ffff1c0 00074 (v01 BOCHS BXPCFACP 00000001 BXPC 00000001) io | AcpiOsMapMemory(1ffff1c0, 74) = bff1c0 io | AcpiOsMapMemory(1fffe040, 24) = bfe040 io | ACPI: DSDT 0x1fffe040 01180 (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001) io | AcpiOsMapMemory(1fffe000, 24) = bfe000 io | ACPI: FACS 0x1fffe000 00040 io | AcpiOsMapMemory(1ffff234, 24) = bff234 io | ACPI: SSDT 0x1ffff234 008DD (v01 BOCHS BXPCSSDT 00000001 BXPC 00000001) io | AcpiOsMapMemory(1ffffb11, 24) = bffb11 io | ACPI: APIC 0x1ffffb11 00078 (v01 BOCHS BXPCAPIC 00000001 BXPC 00000001) io | AcpiOsMapMemory(1ffffb89, 24) = bffb89 io | ACPI: HPET 0x1ffffb89 00038 (v01 BOCHS BXPCHPET 00000001 BXPC 00000001) io | AcpiOsMapMemory(1fffe040, 1180) = bfe040 io | Parsing all Control Methods: io | Table [DSDT](id 0001) - 144 Objects with 18 Devices 52 Methods 8 Regions io | AcpiOsMapMemory(1ffff234, 8dd) = bff234 io | Parsing all Control Methods: io | Table [SSDT](id 0002) - 155 Objects with 32 Devices 42 Methods 1 Regions io | tbxface-0601 [02] TbLoadNamespace : ACPI Tables successfully acquired io | enable ACPI subsystem io | evxfevnt-0184 [02] Enable : Transition to ACPI mode successful io | AcpiOsMapMemory(1fffe000, 40) = bfe000 io | evgpeblk-1129 [04] EvCreateGpeBlock : GPE 00 to 0F [_GPE] 2 regs on int 0x9 io | /home/mlange/projects/l4re/src/l4/pkg/acpica/lib-acpi/src/osl-basic.cc:57:AcpiOsInstallInterruptHandler: UNINPLEMENTED io | initialize ACPI objects io | Completing Region/Field/Buffer/Package initialization:..................................... io | Initialized 9/9 Regions 2/2 Fields 21/21 Buffers 5/5 Packages (308 nodes) io | Initializing Device/Processor/Thermal objects by executing _INI methods: io | Executed 0 _INI methods requiring 1 _STA executions (examined 53 objects) io | evgpeblk-1234 [03] EvInitializeGpeBlock : Found 0 Wake, Enabled 16 Runtime GPEs in this block io | Interpreter enabled io | scanning for PCI root bridge io | Found PCI root bridge... io | Using IOAPIC for interrupt routing io | ACPICA-Version:20091214, System in ACPI MODE, 32bit timer io | WARNING: phys mmio resource allocation failed io | IOMEM * [000000000a0000-000000000bffff 20000] non-pref (32bit) (align=1ffff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM * [000000000a0000-000000000bffff 20000] non-pref (32bit) (align=1ffff flags=c002) io | IGNORE ACPI RES: 1 io | WARNING: phys mmio resource allocation failed io | IOMEM [000000000c0000-000000000fffff 40000] non-pref (32bit) (align=3ffff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [000000000c0000-000000000fffff 40000] non-pref (32bit) (align=3ffff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [0000000009f000-0000000009ffff 1000] non-pref (32bit) (align=fff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [0000000009f000-0000000009ffff 1000] non-pref (32bit) (align=fff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [00000000000000-00000000000fff 1000] non-pref (32bit) (align=fff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [00000000000000-00000000000fff 1000] non-pref (32bit) (align=fff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [000000000a0000-000000000bffff 20000] non-pref (32bit) (align=1ffff flags=c002) io | WARNING: phys mmio resource allocation failed io | IOMEM [000000000a0000-000000000bffff 20000] non-pref (32bit) (align=1ffff flags=c002) io | WARNING: device 'PS2' already assigned to an other virtual bus. io | WARNING: device 'S18_' already assigned to an other virtual bus. io | Service registration failed: 'froyo_bus' io | Ready. Waiting for request. mag | Hello from MAG fb | Trying execution of ``set VBE mode'' using x86emu fb | VBE BIOS not present. fb | Failed to setup Framebuffer mag | Error: Exception: Void capability invoked: requesting goos info: backtrace ... mag | 1002e2f mag | 103f4a5 mag | 1000dcb mag | 10026de mag | 105390c mag | 10000e1 mag | mag | MAG: destroy FB svc Ned[lua]: Hm, cpapbility 436000 does not support the meta protocol: -2004 Ned: ERROR: rom/lx_ginger.cfg:82: attempt to call method 'create' (a nil value) rtc | Date:21.07.2014 Time:16:18:35 Br, Cem Akpolat

2 1

Timer Interrupt Handler
by Xavier LEBARS 21 Jul '14

21 Jul '14

Hi everyone, I'm always trying to configure the timer for my Zedboard and the system clock doesn't advance. I checked this in the Timer::system_clock() function In order to construct my timer driver, I use mptimer option, so I configured the private timer of my board in the file timer-arm-mptimer.cpp. Private Timers call the function interval() which use the global timer of the board (bsp/zynq/ timer-arm-mptimer-zynq.cpp file) Here is a part of the implementation of my global timer (I just launch counter) : Mmio_register_block t(Kmem::mmio_remap(Mem_layout::Gpt_phys_base)); t.write<Mword>(0, GPT_CR); t.write<Mword>(0, GPT_CNT0); t.write<Mword>(0, GPT_CNT1); t.modify<Mword>(GPT_CR_EN, 0, GPT_CR); Mword vc = start_as_counter(); while (t.read<Mword>(GPT_CNT0) < Gpt_ticks) ; Mword interval = (vc - stop_counter()) / Ticks; t.write<Mword>(0, GPT_CR); return interval; The private timers are bind to the GIC with the IRQ 27, so I mentioned this value in the static unsigned irq() function. GIC is initialized in the bsp/zynq/pic-arm-zynq.cpp file (similar to the iMX6 architecture) Pic::init() { typedef Irq_mgr_multi_chip<Gic_sz> M; M *m = new Boot_object<M>(1); gic.construct(Kmem::mmio_remap(Mem_layout::Gic_cpu_phys_base), Kmem::mmio_remap(Mem_layout::Gic_dist_phys_base)); m->add_chip(0, gic, gic->nr_irqs()); Irq_mgr::mgr = m; } To finish I saw timer_tick class. It seems to be a good way to update system clock because there are interrupts handler which call the update_system_clock function. So I added a call to the Timer_tick::setup() function in my startup-arm.cpp file after timer initialization. But when I boot the sytem I obtain the following message Panic - Could not allocate scheduling IRQ 27 The origin of this problem is the allocate_irq() function So do I have to modify something in my IRQ manager or did I forget one step during the construction of my timer driver ? Thanks in advance Best regards, Xavier Le Bars

2 4

Fiasco bug
by Zahi Rima 18 Jul '14

18 Jul '14

Hello, When building Fiasco like told here : https://os.inf.tu-dresden.de/fiasco/build.html I got the following errors : In file included from /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/kern/context.cpp:22, from /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/kern/switch_lock.cpp:85, from /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/kern/helping_lock.cpp:4, from /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/kern/lock.cpp:3, from /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/kern/kobject.cpp:3, from /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/kern/kobject_mapdb.cpp:5, from auto/kobject_mapdb.cc:3: /home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/src/lib/libk/cxx/function:34: error: 'cxx::functor<Res(Args ...)>::functor(cxx::functor<Res(Args ...)>&&)' cannot be defaulted make[1]: *** [kobject_mapdb.o] Error 1 make[1]: Leaving directory `/home/rima/Documents/FK/l4re-snapshot-2014053111/src/kernel/fiasco/mybuild' make: *** [all] Error 2 What Can I do to fix the problem ? Regards, Rima ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

2 1

l4lx_memory_map_virtual_page messages ending in internal error
by Uwe Geuder 17 Jul '14

17 Jul '14

Hi! As mentioned in a previous thread I tried xz compression of my initramfs image in L4Linux on ARM. When L4Linux tried to decompress the following messages occured: > Trying to unpack rootfs image as initramfs... > l4lx_memory_map_virtual_page: Already used, existing is 2400020 > l4lx_memory_map_virtual_page: cannot attach vpage (2ca64000, 2816324f): -99 > l4lx_memory_map_virtual_page: Already used, existing is 2400020 and the same messages (with increasing address) repeated for a zillion of times until it eventually ended like this: > l4lx_memory_map_virtual_page: cannot attach vpage (2ee44000, 25d4324f): -99 > l4linux | Non-resolvable page fault at 2ca64003, ip 2168884. > l4linux | Page fault (non-resolved): pfa=2ca64003 pc=2168884 > Unable to handle kernel paging request at virtual address 2ca64000 > pgd = 0234b000 > [2ca64000] *pgd=25d51811, *pte=2816324f, *ppte=00000000 > Internal error: Oops: 410807 [#1] ARM > Modules linked in: > CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.0-l4 #14 > task: 2a03ba40 ti: 2a03c000 task.ti: 2a03c000 > PC is at dict_repeat.part.5+0x58/0x90 > LR is at lzma_main+0x984/0x990 > pc : [<02168884>] lr : [<02169240>] psr: 20000013 > sp : 2a03dd4c ip : 01c1f000 fp : 04205590 > r10: 00000003 r9 : 00000005 r8 : 2a12eee8 > r7 : 00006ee4 r6 : 00000000 r5 : 2a03ddf8 r4 : 2ae45000 > r3 : 00000042 r2 : 00000000 r1 : 01c1f000 r0 : 2a128018 > vcpu: b3000c00 vcpu-state: 00000000 > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Process swapper (pid: 1, stack limit = 0x2a03c238) > Stack: (0x2a03dd4c to 0x2a03e000) > dd40: 2a128000 00000002 00000000 25eb0548 32e00000 > dd60: 00000000 2a128000 2a03ddf8 00000000 00006ee4 2a12eee8 00000005 00000003 > dd80: 04205590 021698e4 00000000 002457cc 00000000 00000003 00000000 2a03ddf8 > dda0: 2a0ec000 00000003 00000001 021681d4 02321480 02309f44 02321480 02321480 > ddc0: 00001000 002457cc 00001000 00000000 00001000 00000000 02350054 02309cd4 > dde0: 2a0ec000 00000000 00000000 32e00000 00000000 02317cdc 32e00000 002457cc > de00: 0444ad5c 2a0c7000 00000000 00001000 00000005 00000000 00000000 0444ad5c > de20: 32e00000 02321480 02321480 02350054 02309b64 0230a0f4 00000000 02350054 > de40: 02309b64 0230a670 00000000 00000000 0235004c 022cb7d0 022b4b24 02326db8 > de60: 02350050 00000000 02350000 0230a670 0000003d 02350050 0235004c 0230a6e4 > de80: 0000000a 00000000 023462a0 0231fee4 00000000 02249f60 00000005 02349a60 > dea0: 00000000 021c9620 2a03ba40 02349a60 02349a60 02350000 02346284 02346284 > dec0: 02353b0c 02346284 00000000 02326bcc 00000005 02350000 02350000 0230a670 > dee0: 0000003d 2a03c030 00000000 02000444 0224f3c0 020da7d8 0233d430 022bd31c > df00: 2a05f800 0224f3c0 000000db 00000000 00000000 00000005 023357fc 00000001 > df20: 2a899e3b 0225af94 0000003d 02032e5c 022f16d8 00000005 2a899e50 00000005 > df40: 023357f0 02326bcc 00000005 02350000 02350000 0230819c 0000003d 02321400 > df60: 023213f0 02308880 00000005 00000005 0230819c 0233e900 2a03b700 00000001 > df80: 00000000 00000000 02243ed8 00000000 00000000 00000000 00000000 00000000 > dfa0: 00000000 02243ee0 00000000 02007da8 00000000 00000000 00000000 00000000 > dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 > [<02168884>] (dict_repeat.part.5) from [<00000002>] (0x2) > Code: e281c001 e580c008 e282c001 e7d42002 (e7c42001) > ---[ end trace 0aaf617cdd732ae2 ]--- > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > > panic: going to sleep forever, bye > l4linux | panic: going to sleep forever, bye > What can I learn from these messages? The same image could be decompressed on the same hardware with a native Linux kernel. I know that my compression options were probably not optimal and the algorithm might have used a lot of memory. But I have seen out of memory messages from Moe and L4Linux before and they were easy to understand. So could this really be some time of internal error, i.e. bug? Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder(a)nomovok.com (bot test: humans correct 1 obvious spelling error)

2 4

Question about function l4_sched_set_cpu_set
by Yuxin Ren 15 Jul '14

15 Jul '14

Hi I cannot understand the second and third arguments of this function. Could someone tell me how to use those arguments? Thank you Yuixn

2 1

Question about _wq in the class Sender
by Yuxin Ren 15 Jul '14

15 Jul '14

Hi, I note in the Sender class there is a variable "_wq". What is the role of this variable? And in the IPC, we set it to the sender_list of receiver. Why? Thank you. Yuxin

2 3

How to enable scheduling time in one-shot model
by Yuxin Ren 14 Jul '14

14 Jul '14

Hi All, I know in previous Fiasco kernel, there is a kernel option to use scheduling timer in one-shot model. But I cannot find this option in the latest Fiasco kernel. So now how can I enable this feature? In addition, where is the code for timer interrupt handler? Could someone give me some hints about that code? Thank you very much. Yuxin

3 2

User space filesystems for L4Linux
by Uwe Geuder 14 Jul '14

14 Jul '14

Hi! When looking at the examples and forum archives I get the impression that L4Linux users tend to work with ramdisks. However, in general I understand that in the Linux world ramdisks are considered mostly obsolete. Initramfs is the preferred solution https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/D… I replaced my disk image with a cpio archive suitable for initramfs and everything still works fine. Linux can dynamically recognize whether it is cpio or not. I understand my filesystem can grow dynamically until Linx runs out of memory. I dropped the ramdisk_size parameter from the kernel command line. Are there any drawbacks or pitfalls I am missing? The next step is compression. Both ramdisks and cpio archives can be compressed, again Linux can dynamically recognize that and uncompress before usage. (I have only tested cpio.gz so far, but I understand also disk images work and both faster lzo and more aggressive bzip2 and xz are supported.) However, when I tried to used my cpio.gz archive, the effect was zero. Someone had magically uncompressed my archive before making the U-Boot image. I tracked it down to the script src/l4/pkg/bootstrap/server/src/build.pl. > system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); > $file = "$modname.ugz" if !$?; It unpacks everything that is gzip compressed. Maybe that is necessary for object or executable files, I see some assembly manipulation a couple of lines further down, which I have not analyzed. However, for disk images or initramfs archives I cannot see the point. So I made the following hack diff --git a/src/l4/pkg/bootstrap/server/src/build.pl b/src/l4/pkg/bootstrap/server/src/build.pl index 22382d6..a31743e 100755 --- a/src/l4/pkg/bootstrap/server/src/build.pl +++ b/src/l4/pkg/bootstrap/server/src/build.pl @@ -75,8 +75,13 @@ sub build_obj($$$) printf STDERR "Merging image %s to %s [%dkB]\n", $file, $modname, ((-s $file) + 1023) / 1024; # make sure that the file isn't already compressed - system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); - $file = "$modname.ugz" if !$?; + if ($file =~ m/ramdisk-arm.rd$/) { + system("false"); + } else { + system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); + } + $file = "$modname.ugz" if !$? ; + print "using ", $file ; system("$prog_objcopy -S $file $modname.obj 2> /dev/null") if $strip && !$no_strip; system("$prog_cp $file $modname.obj") This worked as expected, my disk image remained compressed and Linux could uncompress it a boot time. Of course it is a hack, because the file name should not be hard-coded there. Same question as before, am I missing anything here? Also build.pl would fail to do the uncompression if a module is compressed with lzo, bzip2 or xz. Yes, I have found the variable BOOTSTRAP_UIMAGE_COMPRESSION. It worked fine during image creation, but during boot U-Boot failed with > Verifying Checksum ... OK > Uncompressing Kernel Image ... Error: inflate() returned -5 > GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover > resetting ... I assume this could be fixed by modiyfing the memory map. However, because my kernel is very small compared to the user space image and Linux has this nice dynamic support for various compression schemes I think I prefer an uncompressed U-Boot image containing a compressed user space image. Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder(a)nomovok.com (bot test: humans correct 1 obvious spelling error)

2 2

Pid 1 crashing under L4Linux
by Uwe Geuder 09 Jul '14

09 Jul '14

Hi! I'm pretty new to L4 so I hope this is not an FAQ. I tried to search the forum archives but couldn't find an answer. I'm using L4 on an i.MX6 device. Building fiasco, L4Re and L4Linux succeeded without any errors as far as I can tell. A small ramdisk containing busybox works fine and I can play around on the command line. (The system actually has framebuffer support, so I can even get something on the screen.) Now I replaced the small "demo" ramdisk by one containing a bigger distro. This bigger ramdisk runs without problems on a native Linux kernel. However, on L4Linux I always get > RAMDISK: ext2 filesystem found at block 0 > RAMDISK: Loading 262144KiB [1 disk] into ram disk... > EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities > EXT4-fs (ram0): couldn't mount as ext2 due to feature incompatibilities > EXT4-fs (ram0): mounted filesystem with ordered data mode. Opts: (null) > VFS: Mounted root (ext4 filesystem) readonly on device 1:0. > Freeing unused kernel memory: 116K (022f9000 - 02316000) > Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 > > CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #7 > [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) > [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) > [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) > [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) > panic: going to sleep forever, bye > l4linux | panic: going to sleep forever, bye > The stack trace is the same for init=/bin/sh and the default systemd. Looks like for some reason user space processes in this setup just crash pretty soon. The console log before that looks pretty unsuspicious to me. But I can of course post it should it be necessary to understand what is going on. What comes to my mind is that my user space is built for armv7tnhl, i. e. thumb instruction set, NEON, and hard-float. > -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb Can any of these options be a problem under L4? (The small busybox ramdisk, which works fine was built by a colleague of mine who is on holidays at the moment. I'm not sure how he built it, but I assume it's neither hard-float nor thumb. Well, I could disassemble something to be sure I guess...) If armv7tnhl does not cause obvious problems, do you have any debugging hints/pointers how to find out why/where pid 1 is crashing? Address 0x1 is nonsense I suppose, but if tells anything then that the processor is in thumb mode. Which is what I would expect from my user space. Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder(a)nomovok.com (bot test: humans correct 1 obvious spelling error)

2 2

MOE uses memory originally from IO device
by Martin Schröder 08 Jul '14

08 Jul '14

My board is equipped with 128MB external DRAM: > L4 Bootstrapper > Build: #1234 Do 3. Jul 17:34:17 CEST 2014, 4.6.2 > Scanning up to 128 MB RAM > Memory size is 128MB (40000000 - 47ffffff) > RAM: 0000000040000000 - 0000000047ffffff: 131072kB > Total RAM: 128MB In addition the CPU has 128kb internal RAM (so called On-Chip-RAM) which is located at address 0 - 0001ffff. I want to expose this OCRAM as a virtual device to a (already existing) kernel driver within l4linux, so I added these few lines to my config: > OCRAM => new Device() { > .hid= "ocram"; > new-res Mmio(0x00000000 .. 0x0001FFFF); > } > > client0 => new System_bus() { > ... > "ocram" = wrap(hw-root.OCRAM); > } Unfortunately IO cannot map this device, but maps instead something else which is of no use for me: > io | <0x1bff0>IOMEM [00000000000000-0000000001ffff 20000] non-pref (32bit) (align=1ffff flags=4002) > io | WARNING: phys mmio resource allocation failed > io | <0x1bff0>IOMEM [00000000000000-0000000001ffff 20000] non-pref (32bit) (align=1ffff flags=4002) > io | allocated resource: <0x1bff0>IOMEM [00000001000000-0000000101ffff 20000] non-pref (align=1ffff flags=4002) But a few lines up I see: > MOE: Hello world! > MOE: found 109032 KByte free memory > MOE: found RAM from 40000000 to 47000000 > ... Probably MOE assumes this as normal ram and adds it to its pool. But how can I inhibit MOE grabbing this piece of RAM and instead assign it to the OCRAM device in IO? Best regards, Martin

2 4