memory problems on Fiasco porting

Tsai, Tung-Chieh tsaitungchieh at gmail.com
Wed Feb 25 18:27:24 CET 2009


Dear Adam,

On Fri, Feb 20, 2009 at 5:41 AM, Adam Lackorzynski
<adam at os.inf.tu-dresden.de> wrote:
> This is the point where interrupts are enabled and also the points where
> it's likely that the first timer hits. The cache_enabled constant just
> influences the cp15-c1 value so maybe you should also disable the
> flushing functions, maybe there's something strange? Another
> simplification is also not to do any range based flushing but alsways
> flush everything. When you mean stuck is it because of a fault or is it
> looping or something else? Do you look at the system with some external
> debugger?

I use `stuck' to describe that it would falling into a infinite loop. I use
ARM AXD debugger to debug.

I set cache_enabled to false, using empty cache flush/clean function,
and change Config::scheduler_granularity to 100UL, make the timer
interrupt less frequently, then it could pass the "Calibrating timer
loop... ",
leaveingThread::init_workload() normally. ( Without changing
Config::scheduler_granularity , it wouldn't pass) But wouldn't show any
thing further.It seems because sigma0 wouldn't work. I try to enter jdb
after leaving init_workload() , jdb shows that the status of sigma0 is
`cancel,dead' and boot_task is `poll,ipc_progr,snd_progr' :

----

L4 Bootstrapper
  Memory size is 128MB
  mod00: 3140d000-3144bb78: fiasco
  mod01: 3144c000-3145c174: sigma0
  mod02: 3145d000-3147e6ac: roottask
  mod03: 3147f000-3148a268: hello
  move modules to 32000000 with offset bf3000
  move module 4 start 3147f000 -> 32072000
  move module 3 start 3145d000 -> 32050000
  move module 2 start 3144c000 -> 3203f000
  move module 1 start 3140d000 -> 32000000
  Scanning fiasco -serial_esc -comport 1 -nowait -nokdb -jdb_cmd=JH
  Scanning sigma0
  Scanning roottask
  Relocated mbi to [0x3004f000-0x3004f0e7]
  Loading fiasco
  Loading sigma0
  Loading roottask
  find kernel info page...
  found kernel info page at 0x30002000
    [ 30001000,  3000197f] Kern   fiasco
    [ 30002000,  3004efff] Kern   fiasco
    [ 3004f000,  3004f1e4] Root   Multiboot info
    [ 30068000,  3007335b] Sigma0 sigma0
    [ 30078000,  3013ffff] Root   roottask
    [ 31400000,  3140cd4f] Boot   bootstrap
    [ 32072000,  3207d267] Root   Modules Memory
  API Version: (87) experimental
  Sigma0 config    ip:30068000 sp:3140c910
  Roottask config  ip:30078000 sp:00000000
  Starting kernel fiasco at 30001000
Hello from Startup::stage2
Initialize page table
Vmem_alloc::init()
Vmem_alloc::TEST
  allocate zero-filled page... [0xefc01000] done
  free zero-filled page... done
  allocate no-zero-filled page... [0xefc02000] done
  free no-zero-filled page... done
SERIAL ESC: allocated IRQ 26 for serial uart
Not using serial hack in slow timer handler.
Welcome to Fiasco(arm)!
DD-L4(v2)/arm microkernel (C) 1998-2008 TU Dresden
Rev: rUNKNOWN compiled with gcc 3.4.4 for pacpmp    []

  --init-----------------------------------------------------PC: f0003244

(0.00) jdb: g

Calibrating timer loop... done.

  --before while(runnung)------------------------------------PC: f001be74

(0.00) jdb: kf

KIP @ 0xf0002000
magic: L4µK  version: 0x87004444
clock: 0000000000020b70 (134000)
freq_cpu: 0kHz
freq_bus: 0kHz
sigma0_ip: 30068000 sigma0_sp: 3140c910
sigma1_ip: 00000000 sigma1_sp: 00000000
root_ip:   30078000 root_sp:   00000000
Memory (max 20 descriptors):

  1:phys [0000000030000000-0000000038000000] Conventional
  2:phys [0000000030002000-000000003004f000] Reserved
  3:phys [000000003004f000-000000003004f400] Bootloader
  4:phys [0000000030068000-0000000030073400] Dedicated
  5:phys [0000000030078000-0000000030140000] Bootloader
  6:phys [0000000032072000-000000003207d400] Bootloader
  7:virt [0000000000000000-00000000c0000000] Conventional
  8:phys [0000000037800000-0000000038000000] Reserved

user_ptr: 0x3004f000   vhw_offset: 00000000    vkey_irq:  26
Kernel features: deceit_bit_disables_switch abiver:9 multi_irq exception_ipc exc
eption_ipc pagerexregs utcb kip_syscalls thread_names

(0.00) jdb: t2

thread:   2.00 <00040000>               prio: 10  mcp: 00  mode: Con
state: 300 cancel,dead
wait for:   *.**    polling:            rcv descr:
lcked by: ---.--                        timeout  :
cpu time: 900.000 µ                     timeslice: 200/1000 µs
pager   :   0.00        cap: ---.--     utcb: f0bfb000
preemptr:   0.00        not monitored   ready lnk: ---.-- ---.--
                                        prsent lnk:   4.00   0.00

PC=ffffffd8 USP=300707d0
[0] 3006e4a8 0000000f 0000000f 3006e6c0 [4] 30002000 c00807ec c00807a0 f0048144
[8] c0000000 c0000004 c00006f4 3007304c [c] 00000006 300707d0 3006c804 ffffffd8

    720  f0038e90 f0038a8c f0038a8c f0038a90 f0038a90 f001472c c0000000 c0000000
    740  c0080000 600000d3 f0038e90 f0038a8c f0038a8c f0038a90 f0038a90 f00148d8
    760  00000000 f0048144 c0080004 60000053 00000001 c0080000 c0000000 c0000004
    780  c00006f4 3007304c f0005808 c0080000 c00807ec c00807a0 f0048144 f0007d84
    734  30002000 c00807ec c00807a0 ffff0318 ffffffd8 f001472c 3006e4a8 0000000f
    7c0  0000000f 3006e6c0 30002000 c00807ec c00807a0 f0048144 c0000000 c0000004
    7e0  c00006f4 3007304c 00000006 20000010 300707d0 3006c804 3006cae4 ffffffd8

(0.00) jdb: lp

    id name                pr   wait    to state
  4.00                     10              poll,ipc_progr,snd_progr
  2.00                     10              cancel,dead
  0.00                      0              ready

(0.00) jdb: g

----

It seems sigma0 has problem on PC, but the value of Kip::k()->sigma0_ip
is correct.

Besides, I found that I didn't enable ROM protection(R bit in CP15_c1, bit 9)
, because if I adding it to Cpu::Cp15_c1_generic to enable it, an RDI
warning will be raised on AXD and uart wouldn't give any output from
fiasco kernel. In Page_table::init(Page_table*), it write the domain access
permission to 0x0001. In original situation, for example, in integratorcp,
d1 ~ d15 will become read only, but in my situation, since R bit is unable to
enable, d1 to d15 will become `No acess' . I guess this cause my problem,
but not very sure.

Best Regards,
Tsai, Tung-Chieh




More information about the l4-hackers mailing list