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