memory problems on Fiasco porting

[Adam Lackorzynski]

Hi,

On Thu Feb 26, 2009 at 01:27:24 +0800, Tsai, Tung-Chieh wrote:
> 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.

Ok, and where? Any prominent place?

> 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' :
> 
> ----
> 
> (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
> 
> It seems sigma0 has problem on PC, but the value of Kip::k()->sigma0_ip
> is correct.

The pc looks like it already did something. The last page should be the
syscall page. Did it go through Thread::user_invoke and tried to enter
user-mode? What's the pc of roottask?
In the initial boot-prompt you should also enabled page fault logging
(P*) to see if any (unusual) happened (with T). And maybe also IPC
logging (I* and IR+).

> 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.

Looking at the table in the manual this only affects kernel-only ro
pages which there should not be any. d0 is the only one used so the
other should not play a role. Also on integratorcp d1-d15 should be 0,
i.e. no access. I think you mean in the AP bits in the page table.


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