headers
Stefan Fritsch | 7 Feb 12:15
Picon
Favicon

Serial console with qemu/realview-eb

Hi,

I have some problems getting the serial console to work under qemu with 
ARM/realview-eb. I see the output from L4Linux but it does not get any input 
and also pressing escape does not enter jdb. I have tried qemu 1.0 and 
0.12.5. I call it with

qemu-system-arm -M realview-eb -nographic -m 
256 -kernel .../l4re/obj/l4/arm-rv/images/bootstrap_L4Linux_ARM.elf

Are there any options one need to pass with "-append"? "-append -serial_esc" 
does not make any difference. Any other ideas?

L4 version is from l4re-snapshot-2011081207.tar.xz

Output from qemu is below.

Cheers,
Stefan

L4 Bootstrapper
  Build: #12 Thu Jan 26 11:26:11 CET 2012, 4.4.1
  Scanning up to 256 MB RAM
  Memory size is 256MB (00000000 - 10000000)
  RAM: 0000000000000000 - 000000000fffffff: 262144kB
  Total RAM: 256MB
  mod09: 014bc000-017bc000: ramdisk-arm.rd
  mod08: 01201000-014bb524: vmlinuz.arm
  mod07: 01200000-012000bd: arm-rv.io
  mod06: 0111a000-011ff124: io
(Continue reading)

Permalink | Reply | 2 comments |
headers
Riccardo Cecolin | 6 Feb 18:29
Picon
Gravatar

L4Linux direct access

I'm trying to make a l4linux system access the vga directly without mag, l4con or fbdrv. I compiled it using the default configuration with virtual pci bus enabled, x86-mp_vPCI_defconfig.
I'm currently trying on qemu, i see that l4linux recognizes the pci devices and is able to mount the root fs from /dev/hda (i also tried with a ramdisk with same results) and loads the driver of the vga (vgaarb: device added: PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none).
But then i get a kernel panic because init (/bin/bash) exited (or didn't execute):

l4linux | EX: 0: pc = 0041176a sp = 07829fac trapno = 0xd err/pfa = 0x402
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: bash Not tainted 3.0.0-l4-svn23 #35

Looking at the binary at 0x41176a i see that the kernel is trying to execute execve but fails with trap 13.

... /src/l4linux/arch/l4/kernel/arch-x86/../../../x86/kernel/sys_i386_32.c:36
  411765:    b8 0b 00 00 00           mov    $0xb,%eax
  41176a:    cd 80                    int    $0x80

My config files are the following ones and i also attached a full log, where is my setup wrong?

------ linux-x2.cfg ------
loader = L4.default_loader;
local lxname = "vmlinuz";
vbus_l4linux = loader:new_channel();

loader:start({
  caps = {
    sigma0  = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0);
    icu = L4.Env.icu;
    l4linux = vbus_l4linux:svr();
  },
  log = { "io", "red" },
}, "rom/io rom/x86-legacy.devs rom/l4lx-x86-x2.io");
   
loader:start({
  caps = {
    log = L4.Env.log:m("rws");
    vbus = vbus_l4linux;
  },   
  l4re_dbg = L4.Dbg.Info,
  log = { "l4linux", "blue" },
}, "rom/" .. lxname .. " mem=120M earlyprintk=yes initcall_debug=1 showpfexc=1 root=/dev/hda init=/bin/bash", "allow_cli","all_sects_writable","allow_vga");

------ l4lx-x86-x2.io ------
l4linux => new System_bus()
{
  PCI0 => new PCI_bus()
  {
    host_bridge_dummy => new PCI_dummy_device();

    pci_gfx[] => wrap(hw-root.match("PCI/CC_03"));
    pci_l4x[] => wrap(hw-root.match("PCI/CC_02,PCI/CC_01,PCI/CC_04"));
  }

  vgadev => wrap(hw-root.VGA);
  ps2dev => wrap(hw-root.PS2);
}

L4 Bootstrapper
  Build: #1 Fri Feb  3 12:59:44 CET 2012, x86-32, 4.4.5
  RAM: 0000000000000000 - 000000000009f3ff: 637kB
  RAM: 0000000000100000 - 0000000012bfcfff: 306164kB
  Total RAM: 299MB
  Moving 11 modules to 1100000 with offset dee000
  moving module 11 { 15bd000-25bd000 } -> { 23ab000-33ab000 }
  moving module 10 { 10d7000-15bcc8a } -> { 1ec5000-23aac8a }
  moving module 09 { 10d6000-10d612b } -> { 1ec4000-1ec412b }
  moving module 08 { 10d5000-10d53b7 } -> { 1ec3000-1ec33b7 }
  moving module 07 { 86a000-10d4428 } -> { 1658000-1ec2428 }
  moving module 06 { 869000-869278 } -> { 1657000-1657278 }
  moving module 05 { 66d000-868154 } -> { 145b000-1656154 }
  moving module 04 { 57e000-66cd17 } -> { 136c000-145ad17 }
  moving module 03 { 3ba000-57d9ee } -> { 11a8000-136b9ee }
  moving module 02 { 379000-3b9995 } -> { 1167000-11a7995 }
  moving module 01 { 312000-378a40 } -> { 1100000-1166a40 }
  Scanning /fiasco -serial_esc
  Scanning /sigma0
  Scanning /moe rom/linux-x2.cfg
  Bootloader MMAP:
    [        0,     9f400) RAM (1)
    [    9f400,     a0000) reserved (2)
    [    f0000,    100000) reserved (2)
    [   100000,  12bfd000) RAM (1)
    [ 12bfd000,  12c00000) reserved (2)
    [ fffbc000, 100000000) reserved (2)
  Relocated mbi to [0x2dd000-0x2dd18e]
  Loading /fiasco
  Loading /sigma0
  Loading /moe
  find kernel info page...
  found kernel info page at 0x400000
Regions of list regions
    [        0,       fff] {     1000} Arch   BIOS
    [    9f400,     9ffff] {      c00} Arch   BIOS
    [    f0000,     fffff] {    10000} Arch   BIOS
    [   100000,    10a1b3] {     a1b4} Sigma0 /sigma0
    [   140000,    18b0df] {    4b0e0} Root   /moe
    [   2d0000,    2e13e7] {    113e8} Boot   bootstrap
    [   2dd000,    2dd28b] {      28c} Root   Multiboot info
    [   300000,    38ffff] {    90000} Kern   /fiasco
    [   400000,    46bfff] {    6c000} Kern   /fiasco
    [  136c000,   33aafff] {  203f000} Root   Modules Memory
    [ 12bfd000,  12bfffff] {     3000} Arch   BIOS
    [ fffbc000,  ffffffff] {    44000} Arch   BIOS
  API Version: (87) experimental
  Sigma0 config    ip:001001dc sp:002dca38
  Roottask config  ip:001401c4 sp:00000000
  Starting kernel /fiasco at 00300824

Welcome to Fiasco.OC (ia32)!
L4/Fiasco.OC ia32 microkernel (C) 1998-2011 TU Dresden
Rev: r38 compiled with gcc 4.4.5 for Intel Pentium Pro    []
Build: #5 Mon Feb  6 17:25:11 CET 2012

Performance-critical config option(s) detected:
  CONFIG_NDEBUG is off
  CONFIG_FINE_GRAINED_CPUTIME is on

Superpages: yes
Kmem:: cpu page at 11406000 (4096Bytes)
ACPI-Init
ACPI: RSDP[0xf8850]    r00 OEM:BOCHS.
ACPI: RSDT[0x203fdd90]    r01 OEM:BOCHS. OEMTID:BXPCRSDT
ACPI: FACP[0x203ffe70]    r01 OEM:BOCHS. OEMTID:BXPCFACP
ACPI: SSDT[0x203fdef0]    r01 OEM:BOCHS. OEMTID:BXPCSSDT
ACPI: APIC[0x203fde10]    r01 OEM:BOCHS. OEMTID:BXPCAPIC
ACPI: HPET[0x203fddd0]    r01 OEM:BOCHS. OEMTID:BXPCHPET
IO-APIC: MADT = 0x203fde10
IO-APIC[ 0]: struct: 0x203fde44 adr=fec00000
IO-APIC[ 0]: pins 24
  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 <at> 0xfdbfa000
Local APIC[00]: version=14 max_lvt=5
APIC ESR value before/after enabling: 00000000/00000000
Using the PIT (i8254) on IRQ 2 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.

KERNEL: Warning: Buddy::alloc: Size mismatch: 1c000 v 20000
Absolute KIP Syscalls using: int 0x30
CPU[0:0]: GenuineIntel (6:2:3:0)[00000623] Model: QEMU Virtual CPU version 0.12.5 at 3309 MHz

  32 KB L1 I Cache (8-way associative, 64 bytes per line)
  32 KB L1 D Cache (8-way associative, 64 bytes per line)
2048 KB L2 U Cache (8-way associative, 64 bytes per line)

Freeing init code/data: 28672 bytes (7 pages)

Calibrating timer loop... done.
SIGMA0: Hello!
  KIP <at> 400000
  Found Fiasco: KIP syscalls: yes
  allocated 4KB for maintenance structures
SIGMA0: Dump of all resource maps
RAM:------------------------
[0:1000;9efff]
[0:10b000;13ffff]
[4:140000;18bfff]
[0:18c000;2dcfff]
[4:2dd000;2ddfff]
[0:2de000;3fffff]
[0:465000;136bfff]
[4:136c000;33aafff]
[0:33ab000;11404fff]
IOMEM:----------------------
[0:0;fff]
[0:9f000;fffff]
[0:12bfd000;febfffff]
[0:fec01000;fedfffff]
[0:fee01000;ffffffff]
IO PORTS--------------------------
[0:0;fffffff]
MOE: Hello world
MOE: found 248476 KByte free memory
MOE: found RAM from 1000 to 11405000
MOE: allocated 276 KByte for the page array <at> 0x1000
MOE: virtual user address space [0-bfffffff]
MOE: rom name space cap -> [C:501000]
  BOOTFS: [136c000-145ad17] [C:503000] l4re
  BOOTFS: [145b000-1656154] [C:504000] ned
  BOOTFS: [1657000-1657278] [C:505000] linux-x2.cfg
  BOOTFS: [1658000-1ec2428] [C:506000] io
  BOOTFS: [1ec3000-1ec33b7] [C:507000] x86-legacy.devs
  BOOTFS: [1ec4000-1ec412b] [C:508000] l4lx-x86-x2.io
  BOOTFS: [1ec5000-23aac8a] [C:509000] vmlinuz
  BOOTFS: [23ab000-33ab000] [C:50a000] drops-rd.rd
MOE: cmdline: /moe rom/linux-x2.cfg
MOE: Starting: rom/ned rom/linux-x2.cfg
MOE: loading 'rom/ned'
Ned says: Hi World!
Ned: loading file: 'rom/linux-x2.cfg'
io      | Io service
io      | Find root Pointer
io      | Find root Pointer: f8850
io      | ACPI: RSDP 0xf8850 00014 (v00 BOCHS )
io      | ACPI: RSDT 0x12bfdd90 00034 (v01 BOCHS  BXPCRSDT 00000001 BXPC 00000001)
io      | ACPI: FACP 0x12bffe70 00074 (v01 BOCHS  BXPCFACP 00000001 BXPC 00000001)
io      | ACPI: DSDT 0x12bfdf30 01EC4 (v01   BXPC   BXDSDT 00000001 INTL 20100528)
io      | ACPI: FACS 0x12bffe00 00040
io      | ACPI: SSDT 0x12bfdef0 00037 (v01 BOCHS  BXPCSSDT 00000001 BXPC 00000001)
io      | ACPI: APIC 0x12bfde10 00072 (v01 BOCHS  BXPCAPIC 00000001 BXPC 00000001)
io      | ACPI: HPET 0x12bfddd0 00038 (v01 BOCHS  BXPCHPET 00000001 BXPC 00000001)
io      | Parsing all Control Methods:
io      | Table [DSDT](id 0001) - 254 Objects with 48 Devices 82 Methods 5 Regions
io      | Parsing all Control Methods:
io      | Table [SSDT](id 0002) - 1 Objects with 0 Devices 0 Methods 0 Regions
io      |  tbxface-0601 [02] TbLoadNamespace       : ACPI Tables successfully acquired
io      | evxfevnt-0184 [02] Enable                : Transition to ACPI mode successful
io      | evgpeblk-1129 [04] EvCreateGpeBlock      : GPE 00 to 0F [_GPE] 2 regs on int 0x9
io      | /home/rkj/L4/fiasco-2012/src/l4/pkg/acpica/lib-acpi/src/osl-basic.cc:57:AcpiOsInstallInterruptHandler: UNINPLEMENTED
io      | Completing Region/Field/Buffer/Package initialization:.................
io      | Initialized 5/5 Regions 0/0 Fields 8/8 Buffers 4/4 Packages (264 nodes)
io      | Initializing Device/Processor/Thermal objects by executing _INI methods:
io      | Executed 0 _INI methods requiring 0 _STA executions (examined 51 objects)
io      | evgpeblk-1234 [03] EvInitializeGpeBlock  : Found 0 Wake, Enabled 16 Runtime GPEs in this block
io      | ACPICA-Version:20091214, System in ACPI MODE, 32bit timer
io      | WARNING: device 'S2__' already assigned to an other virtual bus.
io      | WARNING: device 'PS2' already assigned to an other virtual bus.
io      | Ready. Waiting for request.
l4linux | PH  0 (t:        1) offs=00001000 vaddr=00400000 vend=007ba000
l4linux |                     phys=00400000 ephys=007ba000
l4linux |                     f_sz=003ba000 memsz=003ba000 flgs=r-x
l4linux | PH  1 (t:        1) offs=003bb000 vaddr=007ba000 vend=0091b000
l4linux |                     phys=007ba000 ephys=0091b000
l4linux |                     f_sz=0006e000 memsz=00161000 flgs=rw-
l4linux | PH  2 (t:        4) offs=002e8b0c vaddr=006e7b0c vend=006e7b30
l4linux |                     phys=006e7b0c ephys=006e7b30
l4linux |                     f_sz=00000024 memsz=00000024 flgs=---
l4linux | Starting binary at 0x400000, argc=8 argv=0x80007f88 *argv=0xb1007ff4 argv0=rom/vmlinuz
l4linux | External resolver is at 0xa80006e0
l4linux | ======> L4Linux 2.6 starting... <========
l4linux | Linux version 3.0.0-l4-svn23 (rkj <at> harpoon) (gcc version 4.4.5 (Debian 4.4.5-8) ) #35 SMP Mon Feb 6 17:50:12 CET 2012
l4linux | Binary name: rom/vmlinuz
l4linux | Linux kernel command line (7 args): mem=120M earlyprintk=keep initcall_debug=1 showpfexc=1 root=/dev/hda init=/bin/bash allow_cli
l4linux | vcpu 0 gets tamer 0
l4linux | CPU mapping (l:p)[1]: 0:0
l4linux | Image: 00400000 - 0091b000 [5228 KiB].
l4linux | Areas: Text:     00400000 - 007ba000 [3816kB] (a bit longer)
l4linux |        Data:     007ba000 - 007eb2a0 [196kB]
l4linux |        Initdata: 007ec000 - 00822000 [216kB]
l4linux |        BSS:      00828000 - 0090b000 [908kB]
l4linux | gs=43   fs=43
l4linux | l4lx_thread_create: Created thread 415 (tamer0) (u:b3000400, sp:00849034)
l4linux | Tamer0 is 415
l4linux | Using tamed mode.
l4linux | l4lx_thread_create: Created thread 416 (nop) (u:b3000600, sp:00830418)
l4linux | Device scan:
l4linux |   Device:
l4linux |     MEM: f0000000 - f1ffffff
l4linux |     MEM: f2000000 - f2000fff
l4linux |   Device:
l4linux |     PORT: 000001f0 - 000001f7
l4linux |     PORT: 000003f6 - 000003f6
l4linux |     IRQ: 0000000e - 0000000e
l4linux |     PORT: 00000170 - 00000177
l4linux |     PORT: 00000376 - 00000376
l4linux |     IRQ: 0000000f - 0000000f
l4linux |     PORT: 0000c000 - 0000c00f
l4linux |   Device:
l4linux |     IRQ: 0000000b - 0000000b
l4linux |     PORT: 0000c100 - 0000c1ff
l4linux |     MEM: f2020000 - f20200ff
l4linux |   Device: PNP0900
l4linux |     PORT: 000003b0 - 000003bf
l4linux |     PORT: 000003c0 - 000003df
l4linux |     MEM: 000a0000 - 000bffff
l4linux |   Device: PNP0303
l4linux |     PORT: 00000060 - 00000060
l4linux |     PORT: 00000064 - 00000064
l4linux |     IRQ: 00000001 - 00000001
l4linux |     IRQ: 0000000c - 0000000c
l4linux | l4x_fiasco_gdt_entry_offset = 9
l4linux | rtc not found
l4linux | WARNING: RTC server does not seem there!
l4linux | l4lx_thread_create: Created thread 418 (cpu0) (u:b3000800, sp:007bbff4)
l4linux | main thread will be 418
l4linux | l4x_register_pointer_section: addr = 007ba000 size = 1445888
l4linux | section-with-init: virt: 0x7ba000 to 0x91afff [1412 KiB]
l4linux | section-with-init: Phys: 0x0081f000 to 0x00980000, Size:  1445888
l4linux | l4x_linux_startup: thread 418.
l4linux | Main thread running, waiting...
l4linux | main thread: received startup message.
l4linux | l4x_setup_memory: Forcing superpages for main memory
l4linux | l4re_global_env: 0xb1007ef4
l4linux | Main memory size: 120MB
l4linux |     Main memory: virt: 0xc00000 to 0x83fffff [122880 KiB]
l4linux |     Main memory: Phys: 0x03400000 to 0x0ac00000, Size: 125829120
l4linux | Filling lower ptabs...
l4linux | Page fault: addr = 00002002 pc = 007eee2a (rw)
l4linux | Page fault: addr = 009fa002 pc = 007eee2a (rw)
l4linux | Done (1532 entries).
l4linux | l4x_register_pointer_section: addr = 007ba000 size = 1445888
l4linux |             end: virt: 0x7ba000 to 0x91afff [1412 KiB]
l4linux |             end: Phys: 0x0081f000 to 0x00980000, Size:  1445888
l4linux | l4lx_thread_create: Created thread 41d (l4lx.ipi0) (u:b3000a00, sp:0089fff4)
Linux version 3.0.0-l4-svn23 (rkj <at> harpoon) (gcc version 4.4.5 (Debian 4.4.5-8) ) #35 SMP Mon Feb 6 17:50:12 CET 2012
BIOS-provided physical RAM map:
 L4Lx-Memory: 0000000000000000 - 0000000000400000 (reserved)
 L4Lx-Memory: 0000000000400000 - 000000000091b000 (usable)
 L4Lx-Memory: 000000000091b000 - 0000000000c00000 (unusable)
 L4Lx-Memory: 0000000000c00000 - 0000000008400000 (usable)
Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
last_pfn = 0x8400 max_arch_pfn = 0x100000
init_memory_mapping: 0000000000000000-0000000008400000
132MB LOWMEM available.
  mapped low ram: 0 - 08400000
  low ram: 0 - 08400000
Zone PFN ranges:
  DMA      0x00000400 -> 0x00000000
  Normal   0x00000000 -> 0x00008400
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000400 -> 0x0000091b
    0: 0x00000c00 -> 0x00008400
Using APIC driver default
Intel MultiProcessor Specification v1.0
    Virtual Wire compatibility mode.
Processors: 1
SMP: Allowing 1 CPUs, 0 hotplug CPUs
Allocating PCI resources starting at 8400000 (gap: 8400000:f7c00000)
setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 11 pages/cpu <at> 07c00000 s20928 r0 d24128 u4194304
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31771
Kernel command line: mem=120M earlyprintk=keep initcall_debug=1 showpfexc=1 root=/dev/hda init=/bin/bash allow_cli
console [earlykdb0] enabled
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Initializing CPU#0
Memory: 121760k/135168k available (2973k kernel code, 6348k reserved, 1039k data, 216k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0x00100000 - 0x001e7000   ( 924 kB)
    vmalloc : 0x08400000 - 0x10400000   ( 128 MB)
    lowmem  : 0x00000000 - 0x08400000   ( 132 MB)
      .init : 0x007ec000 - 0x00822000   ( 216 kB)
      .data : 0x006e7548 - 0x007eb2a0   (1039 kB)
      .text : 0x00400000 - 0x006e7548   (2973 kB)
Hierarchical RCU implementation.
NR_IRQS:512
l4lx_irq_init: l4lx_irq_max = 512
l4linux | rtc not found
Console: colour dummy device 80x25
console [tty0] enabled
l4lx_irq_timer_startup(0)
l4linux | l4lx_thread_create: Created thread 41f (timer.i0) (u:b3000c00, sp:008a1ff4)
Detected 3309.724 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 6619.44 BogoMIPS (lpj=33097240)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
SMP alternatives: switching to UP code
timer_irq_thread: Starting timer IRQ thread.
Freeing SMP alternatives: 24k freed
CPU0: Intel QEMU Virtual CPU version 0.12.5 stepping 03
Performance Events: unsupported p6 CPU model 2 no PMU driver, software events only.
Brought up 1 CPUs
Total of 1 processors activated (6619.44 BogoMIPS).
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
PCI: L4 root bridge is device 17dd0
vgaarb: device added: PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none
PCI: Using L4-IO for IRQ routing
pci 0000:00:00.0: No interrupt pin configured for device 0000:00:00.0
pci 0000:00:01.0: No interrupt pin configured for device 0000:00:01.0
pci 0000:00:02.0: No interrupt pin configured for device 0000:00:02.0
L4IRQ: set irq type of 11 to 4
pci 0000:00:03.0: PCI INT A -> GSI 11 (level, high) -> IRQ 11
Switching to clocksource l4kipclk
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 128 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
platform rtc_cmos: registered platform RTC device (no PNP device found)
msgmni has been set to 237
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
l4fb l4fb.0: look for capability 'fb' as goos session
l4fb l4fb.0: init failed err=-2
initcall l4fb_init+0x0/0x17b returned with error code -2
L4 shared mem serial driver
brd: module loaded
l4bdds: No name given, not starting.
Uniform Multi-Platform E-IDE driver
piix 0000:00:02.0: IDE controller (0x8086:0x7010 rev 0x00)
pci 0000:00:02.0: No interrupt pin configured for device 0000:00:02.0
piix 0000:00:02.0: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xc000-0xc007
    ide1: BM-DMA at 0xc008-0xc00f
l4linux | cpu0: utcb=0xb3000800 418
l4linux | l4lx_thread_create: Created thread 420 (idler0) (u:b3000e00, sp:008a3ff8)
hda: QEMU HARDDISK, ATA DISK drive
Switching to clocksource tsc
hda: MWDMA2 mode selected
hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
hdc: MWDMA2 mode selected
l4lx_irq_dev_startup: creating IRQ thread for 14 (IRQ-cap 421000)
l4linux | l4lx_thread_create: Created thread 422 (IRQ14) (u:10400000, sp:008a5ff4)
l4linux | irq_thread: Started IRQ thread for IRQ 14
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
l4lx_irq_dev_startup: creating IRQ thread for 15 (IRQ-cap 423000)
l4linux | l4lx_thread_create: Created thread 424 (IRQ15) (u:10400200, sp:008a7ff4)
l4linux | irq_thread: Started IRQ thread for IRQ 15
ide1 at 0x170-0x177,0x376 on irq 15
ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
ide-gd driver 1.18
hda: max request size: 512KiB
hda: 32768 sectors (16 MB) w/256KiB Cache, CHS=32/255/63
hda: cache flushes supported
 hda: unknown partition table
ide-cd driver 5.00
ide-cd: hdc: ATAPI 4X CD-ROM drive, 512kB Cache
cdrom: Uniform CD-ROM driver Revision: 3.20
e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
e1000: Copyright (c) 1999-2006 Intel Corporation.
pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend <at> alpha.franken.de
mousedev: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
Registering the dns_resolver key type
initcall lapic_insert_resource+0x0/0x35 returned with error code -1
Using IPI No-Shortcut mode
async_waiting <at> 1
async_continuing <at> 1 after 0 usec
EXT2-fs (hda): warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 3:0.
async_waiting <at> 1
async_continuing <at> 1 after 0 usec
Freeing unused kernel memory: 216k freed
l4linux | EX: 0: pc = 0041176a sp = 07829fac trapno = 0xd err/pfa = 0x402
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: bash Not tainted 3.0.0-l4-svn23 #35
Call Trace:
 [<006e4a29>] panic+0x57/0x14b
 [<0042ddd1>] do_exit+0x601/0x6c0
 [<004839e2>] ? do_munmap+0x202/0x290
 [<0042df60>] ? sys_exit_group+0x20/0x20
 [<0042df73>] sys_exit+0x13/0x20
 [<00406b13>] l4x_user_dispatcher+0xdd3/0x22c0
 [<00409702>] l4_kernelinternal_execve+0x52/0xe0
 [<00400569>] in_kernel_int80_helper+0x9/0x20
 [<0041176c>] ? kernel_execve+0x1c/0x30
 [<004001b7>] run_init_process+0x17/0x20
 [<00400251>] init_post+0x91/0xb0
 [<007ec1d5>] kernel_init+0x10e/0x116
 [<007ec0c7>] ? parse_early_options+0x25/0x25
 [<00409a99>] kernel_thread_start+0x29/0x30
panic: going to sleep forever, bye
l4linux | panic: going to sleep forever, bye

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 5 comments |
headers
Wesley Miaw | 28 Jan 03:15
Gravatar

Sharing I/O Memory

I have an L4 process requesting access to a large chunk (512MB) of
physical RAM using l4sigma0_map_iomem(). I am not using l4sigma0_map_mem()
because Fiasco is running in a different partition of physical RAM.

I would like to then grant full read/write access to the same memory to a
second L4 process, but I'm not sure how to do that. I believe from looking
at the sigma0 code that any memory, I/O or RAM, can only be allocated to
one L4 process at a time.

It also doesn't look like clans have anything to do with this, other than
the possibility of creating some shared memory for an IPC. But that's not
really what I want to do, I want both L4 processes to directly access the
memory. Is there some way to accomplish this?

Thanks,
--

-- 
Wesley Miaw
wesley <at> wesman.net
Permalink | Reply | 7 comments |
headers
jangwoo | 26 Jan 03:10
Favicon
Gravatar

RE: l4-hackers Digest, Vol 105, Issue 9

Hi all.

I have similar problem.
Currently  applications on linux can't use mmap of framebuffer(/dev/fb0).
When apps access memory to get through mmap, it occurs page fault.

Without goos, fbdrv of L4 cell, mag, l4fb drv in linux, etc on,
Is there ways that it modify <linux lcd device driver> little bit as other
linux device drivers

In other words, could Apps use allocated  memory in linux kernel?

As a guide,
Because of using dedicated frame buffer only in one cell(linux), it mustn't
use things like goos, mag.

thanks
------------------------------
Message: 1
Date: Tue, 24 Jan 2012 20:03:36 +0100
From: Adam Lackorzynski <adam <at> os.inf.tu-dresden.de>
To: l4-hackers <at> os.inf.tu-dresden.de
Subject: Re: Fiasco.OC x86 IO port permission bitmap
Message-ID: <20120124190336.GE2897 <at> os.inf.tu-dresden.de>
Content-Type: text/plain; charset=iso-8859-1

Hi,

On Mon Jan 23, 2012 at 15:54:29 -0800, Daniel Waddington wrote:
> I want to use the TSS I/O permission bit map to support fine grained
> control of I/O access for user-level apps (x86 32 bit target).  From
> looking at the kernel code, I believe the bit map is switched out
> per-process as part of the Context class (Space::_io_space) -
> correct me if I am wrong.  My query is how to set/clear the bits for
> a given target task from a "root" task with sufficient privileges
> (e.g., base caps and sigma0 caps).  I could extend the kernel
> scheduler protocol, but I don't want to do this if there is already
> a clean way in place.

IO-ports are handled similar to page-faults, i.e. they can be mapped to
other tasks, and the pager receives io-page-faults when one of its
clients accesses an IO-port without having it. For example look for
L4_PROTO_IO_PAGE_FAULT and l4_iofpage().

Adam
-- 
Adam                 adam <at> os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

------------------------------

Message: 2
Date: Tue, 24 Jan 2012 13:12:03 -0800
From: Daniel Waddington <d.waddington <at> samsung.com>
To: Adam Lackorzynski <adam <at> os.inf.tu-dresden.de>
Cc: l4-hackers <at> os.inf.tu-dresden.de
Subject: Re: Fiasco.OC x86 IO port permission bitmap
Message-ID: <4F1F1EA3.7060309 <at> samsung.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Hi Adam,

I see. So it seems that you have to map all of the IO port space before 
getting IOPL raised to 3 (assuming Kconfig IO_PROT & !IO_PROT_3) and 
therefore the default mode of operation is a driver will map the whole 
space if it wants to use IO instructions directly.  Is it right that you 
currently don't use the TSS IO bitmap to allow access to only specific 
IO ports with CPL > IOPL?

Thanks
Daniel

On 01/24/2012 11:03 AM, Adam Lackorzynski wrote:
> Hi,
>
> On Mon Jan 23, 2012 at 15:54:29 -0800, Daniel Waddington wrote:
>> I want to use the TSS I/O permission bit map to support fine grained
>> control of I/O access for user-level apps (x86 32 bit target).  From
>> looking at the kernel code, I believe the bit map is switched out
>> per-process as part of the Context class (Space::_io_space) -
>> correct me if I am wrong.  My query is how to set/clear the bits for
>> a given target task from a "root" task with sufficient privileges
>> (e.g., base caps and sigma0 caps).  I could extend the kernel
>> scheduler protocol, but I don't want to do this if there is already
>> a clean way in place.
> IO-ports are handled similar to page-faults, i.e. they can be mapped to
> other tasks, and the pager receives io-page-faults when one of its
> clients accesses an IO-port without having it. For example look for
> L4_PROTO_IO_PAGE_FAULT and l4_iofpage().
>
>
> Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-
hackers/attachments/20120124/888c9277/attachment-0001.html>

------------------------------

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

End of l4-hackers Digest, Vol 105, Issue 9
******************************************
Permalink | Reply | 2 comments |
headers
Daniel Waddington | 24 Jan 00:54
Gravatar

Fiasco.OC x86 IO port permission bitmap

Hi,

I want to use the TSS I/O permission bit map to support fine grained control of I/O access for user-level apps (x86 32 bit target).  From looking at the kernel code, I believe the bit map is switched out per-process as part of the Context class (Space::_io_space) - correct me if I am wrong.  My query is how to set/clear the bits for a given target task from a "root" task with sufficient privileges (e.g., base caps and sigma0 caps).  I could extend the kernel scheduler protocol, but I don't want to do this if there is already a clean way in place.

Thanks
Daniel Waddington

 

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 4 comments |
headers
Chen Tian | 18 Jan 01:50
Picon
Favicon

Re: l4-hackers Digest, Vol 105, Issue 5

Hi Adam,

I got another trace:

Chen: caps_alloc for virt addr 0xf081f010 (index 0x1f01), new cap location 0xfec93000, [virt 0xf081f000-> mem 0xfec93000] in space 0xfedd7f08, s = 0x0
 Chen: caps_alloc for virt addr 0xf081f000 (index 0x1f00), new cap location 0xfec92000, [virt 0xf081f000-> mem 0xfec92000] in space 0xfedd7f08, s = 0x0
 thread 0xfed4c000: v_fabricate is false: (Obj_space) from [0xfedd7ef4/12], s_phys 0x0: 00001f01 size: 00000001 to [0xfedd7e9c/18] recv addr 0x1e8f

KERNEL: Warning: nothing mapped: (Obj_space) from [0xfedd7ef4/12]: 00001f02 size: 00000001 to [0xfedd7e9c/18] recv addr 0x1e90
Chen: v_delete on cap 0xfecf33b4 for virt addr 0x1ef8 (entry addr 0xfec90f80) in space 0xfedd7f08


As you can see,  the status variable "s" is Insert_OK for two invocations of caps_alloc. That means  mem_space()->v_insert function is not safe either? Why two insertions are successful at the same time on the same virtual address?

I have put a lock to protect l4_factory_create_xxx in my application and that seems to work.

Best,
Chen



On Tue, Jan 17, 2012 at 3:00 AM, <l4-hackers-request <at> os.inf.tu-dresden.de> wrote:
Send l4-hackers mailing list submissions to
       l4-hackers <at> 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 <at> os.inf.tu-dresden.de

You can reach the person managing the list at
       l4-hackers-owner <at> 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: race condition in obj_space-virt.cpp ? (Adam Lackorzynski)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Jan 2012 23:54:07 +0100
From: Adam Lackorzynski <adam <at> os.inf.tu-dresden.de>
To: l4-hackers <at> os.inf.tu-dresden.de
Subject: Re: race condition in obj_space-virt.cpp ?
Message-ID: <20120116225406.GA6550 <at> os.inf.tu-dresden.de>
Content-Type: text/plain; charset=iso-8859-1


On Fri Jan 13, 2012 at 16:37:06 -0800, Chen Tian wrote:
> Hello,
>
> I observed a race condition in Fiasco.OC. My environment is very
> complicated, but basically I have multiple threads, and each thread keep
> creating kernel object via l4_factory_create_xxxx and map the object to a
> new task.
>
> Here is the trace I got:

Thanks, we're looking into this.



Adam
--
Adam                 adam <at> os.inf.tu-dresden.de
 Lackorzynski         http://os.inf.tu-dresden.de/~adam/



------------------------------

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers


End of l4-hackers Digest, Vol 105, Issue 5
******************************************

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 1 comment |
headers
Chen Tian | 14 Jan 01:37
Picon
Favicon

race condition in obj_space-virt.cpp ?

Hello,

I observed a race condition in Fiasco.OC. My environment is very complicated, but basically I have multiple threads, and each thread keep creating kernel object via l4_factory_create_xxxx and map the object to a new task.

Here is the trace I got:

//printed from obj_space-virt.cpp in function caps_alloc:

Chen: caps_alloc for virt addr 0xf0826000 (index 0x2600), new cap location 0xfeb04000, [virt 0xf0826000-> mem 0xfeb04000] in space 0xfedd7f08
Chen: caps_alloc for virt addr 0xf0826010 (index 0x2601), new cap location 0xfeb05000, [virt 0xf0826000-> mem 0xfeb05000] in space 0xfedd7f08
Chen: v_insert cap 0xfed5a6a0 (index 0x2600 (entry addr 0xfeb04000) in space 0xfedd7f08
Chen: v_insert cap 0xfeb000b4 (index 0x2601) (entry addr 0xfeb05010) in space 0xfedd7f08

//printed from map_util
thread 0xfed4c000: v_fabricate is false: (Obj_space) from [0xfedd7ef4/12], s_phys 0x0: 00002601 size: 00000001 to [0xfedd7e9c/18] recv addr 0x2541

// then I got
KERNEL: Warning: nothing mapped: (Obj_space) from [0xfedd7ef4/12]: 00002602 size: 00000001 to [0xfedd7e9c/18] recv addr 0x2542
 Omnicore Panic: task map failed!
 
Basically, different object index (2600 and 2601) causes two different page to be created and mapped to the same cap_table virtual address 0xf0826000. Although one of the mapping
will fail, but the current logic did not return the correct address.

The fix I put in to solve this problem is to add the following lines after the switch statement in caps_alloc function:

  if (s != Insert_ok ) {
      Mapped_allocator::allocator()->q_unaligned_free(ram_quota(),
          Config::PAGE_SIZE, mem);
      mem= alien_lookup(virt & ~(Config::PAGE_SIZE/sizeof(Entry)-1));
  }

Please let me know if this is correct. Thanks.


Even with this fix, I still got another kernel "nothing mapped error" when I ask each thread not only to create and map kernel objects, but also to delete objects using l4_task_unmap. If I do not use l4_task_unmap,  everything is fine. I am still investigating why, but I got a feeling that there may be other race conditions on the cap_table related operations.

Best,
Chen

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 1 comment |
headers
Ivan Loskutov | 5 Jan 20:58
Picon
Gravatar

L4Re build system

Hello, Hackers!

I have some questions about L4Re build system

1. How to build library from *.cpp files? The library building if I rename *.cpp files to *.cc but it not easy. I tried to modify mk-files, see attached patch. *.cpp files compiled but don't linked correctly, *.cpp files added to linker command.

2. How to correct add prebuild and postbuild rules to Makefile for prog and library roles?

Thanks.

--
Best Regards,
Ivan Loskutov

Index: mk/binary.inc
===================================================================
--- mk.orig/binary.inc
+++ mk/binary.inc
@@ -479,9 +479,11 @@ endif
 #      3 - additional infix before .o in case of .cc files
 targetobjs_gen = $(SRC_C:.c=$(2).o) $(SRC_S:.S=$(2).o)                  \
                  $(SRC_CC:.cc=$(2)$(3).o)                               \
+                 $(SRC_CC:.cpp=$(2)$(3).o)                               \
                  $(foreach inter, $(OSYSTEM) $(1) $(1)_$(OSYSTEM),	\
                      $(SRC_C_$(inter):.c=$(2).o)			\
                      $(SRC_S_$(inter):.S=$(2).o)			\
+                     $(SRC_CC_$(inter):.cpp=$(2)$(3).o)	                \
                      $(SRC_CC_$(inter):.cc=$(2)$(3).o))	                \
                  $(patsubst %.c,%$(2).o,$(call IDL_SRC_Cfn,$(1)))

@@ -564,10 +566,10 @@ $(BID_OBJ_Makefile).inc: .general.d $(BI
 		$(foreach t,$(TARGET_PROFILE_PIC) $(TARGET_PROFILE_SHARED),\
 			$(call targetobjs,$t,.pr.s))),$(strip		\
 		$(addprefix \n$(obj): ,$(patsubst %.dpe,%.dpi,		\
-		$(DPE_$(obj:.o=.c)) $(DPE_$(obj:.o=.cc))		\
-		$(DPE_$(obj:.s.o=.c)) $(DPE_$(obj:.s.o=.cc))		\
-		$(DPE_$(obj:.pr.o=.c)) $(DPE_$(obj:.pr.o=.cc))		\
-		$(DPE_$(obj:.pr.s.o=.c)) $(DPE_$(obj:.pr.s.o=.cc))	\
+		$(DPE_$(obj:.o=.c)) $(DPE_$(obj:.o=.cc)) $(DPE_$(obj:.o=.cpp))	\
+		$(DPE_$(obj:.s.o=.c)) $(DPE_$(obj:.s.o=.cc)) $(DPE_$(obj:.s.o=.cpp))		\
+		$(DPE_$(obj:.pr.o=.c)) $(DPE_$(obj:.pr.o=.cc)) $(DPE_$(obj:.pr.o=.cpp))		\
+		$(DPE_$(obj:.pr.s.o=.c)) $(DPE_$(obj:.pr.s.o=.cc)) $(DPE_$(obj:.pr.s.o=.cpp))	\
 		))))' >>$@_
         #
         # create the object-dirs
@@ -715,6 +717,9 @@ $(eval $(call BID_GENERATE_DEFAULT_MAKE_
 %:	%.cc
 	

+%:	%.cpp
+	
+
 %:	%.S
 	

@@ -758,6 +763,12 @@ $(eval $(call BID_GENERATE_DEFAULT_MAKE_
 	$(VERBOSE)$(INDENT) -sob -o $@ $@
 	$(VERBOSE)$(if $(DO_SHOW_RESULT_FILE),$(PAGER) $@)

+%.s.i:	%.cpp FORCE
+	@$(COMP_MESSAGE)
+	$(VERBOSE)$(CXX) -E -H -dD $(CPPFLAGS) $(CXXFLAGS) $(PICFLAGS) $(call absfilename,$<) -o $@
+	$(VERBOSE)$(INDENT) -sob -o $@ $@
+	$(VERBOSE)$(if $(DO_SHOW_RESULT_FILE),$(PAGER) $@)
+
 %.i:	%.S FORCE
 	@$(COMP_MESSAGE)
 	$(VERBOSE)$(CC) -E -H -dD $(CPPFLAGS) $(ASFLAGS) $(call absfilename,$<) -o $@

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 1 comment |
headers
Julien SIMONE | 2 Jan 16:35
Picon

Initial environnement issue

Hi hackers,

 

Everytime I try to get a new free utcb in using L4re_env()->first_free_utcb, this call returns 0xffffffff.

I think there is something wrong with the utcb_area…

Do you think I forgot to initialize anything? Any idea?

 

 

Best regards,

 

Julien.

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 1 comment |
headers
Ivan Loskutov | 28 Dec 08:44
Picon
Gravatar

openssl port

Hello, Hackers!


I ported OpenSSL 1.0.0e for L4Re http://dl.dropbox.com/u/8558928/openssl.tar.bz2
I tested it on x86 and ARM.


_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 1 comment |
headers
e.fedotov | 22 Dec 12:40
Gravatar

How to fix RAM size limit 256MB on realview-pbxa9 platform.

Hello, All!

This post is about how to eliminate memory restriction 256MB in realview-pbxa9 platform (ARM Cortex A9 processor). The problem is that L4 bootstrap doesn't scan all RAM memory presented on this board. In QEMU source code for this platform (see hw/realview.c in QEMU source directory, function: realview_init) we can find that it can be 3 memory intervals in pbx a9:

1) base=0x00, size=min(sz, 256MB)
This is "SDRAM1"
2) base=0x20000000, size=sz-512MB   (appears when sz>512)
This is called "core tile ram"
3) base=0x70000000, size=512
This is "SDRAM2",
where sz is a total board memory, in QEMU specified via -m option.
If that memory map is true (I have no pbx-a9 board operator's manual), we can make a simple patch to L4 bootstrap (file <genode>/base-foc/contrib/l4/pkg/bootstrap/server/src/platform/rv.cc), that extends a basic 256MB memory to 256MB+512MB by overloading setup_memory_map virtual function.

namespace {
class Platform_arm_rv : public Platform_single_region_ram
{
  bool probe() { return true; }

  //fix a memory limit 256MB in realview-pbxa9.platform.  Adds another memory chip of 512MB.
  //WARNING: this fix works only if 512MB memory chip (or more) is present!
  //In case of QEMU you must run it with -m 512 or higher.
  void setup_memory_map(l4util_mb_info_t *,
                        Region_list *ram, Region_list *)
  {
    ram->add(Region::n(0x0,        0x10000000, ".ram", Region::Ram));  //SDRAM as it defined in realview.c (QUEMU sources)
    ram->add(Region::n(0x70000000, 0x90000000, ".ram", Region::Ram));  //the second 512MB SDRAM
    //TODO: add more RAM regions if you need it according to the the platform map.
  }
   
  void init()
  {
    static L4::Uart_pl011 _uart(36,36);
    _uart.startup(0x10009000);
    set_stdio_uart(&_uart);
  }
};
}

REGISTER_PLATFORM(Platform_arm_rv);

This is an example patch, it would be more correct (if total RAM size is less then 512) to find total memory size first, then add the memory regions, regarding a total memory size.
I hope it will be usefull.
Best regards, and happy cristmas&new year.

Evgeny Fedotov.
Samsung Research Center,
Moscow.
_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Permalink | Reply | 1 comment |

Gmane