From: Mike Frysinger Date: Thu, 24 Mar 2011 03:18:17 +0000 (+0000) Subject: sim: bfin: document SIC limitation X-Git-Tag: cgen-snapshot-20110401~132 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=b16a1f4c4fcbc6bc90bbe25fb0534a02f0923226;p=platform%2Fupstream%2Fbinutils.git sim: bfin: document SIC limitation Signed-off-by: Mike Frysinger --- diff --git a/sim/bfin/ChangeLog b/sim/bfin/ChangeLog index 36c8665..c5ab9ae 100644 --- a/sim/bfin/ChangeLog +++ b/sim/bfin/ChangeLog @@ -1,5 +1,9 @@ 2011-03-23 Mike Frysinger + * TODO: Document some known SIC issues. + +2011-03-23 Mike Frysinger + * devices.h (dv_w1c): Fix typos in documentation of "bits" arg. * dv-bfin_cec.c (bfin_cec_io_write_buffer): Pass 0xffee to dv_w1c_4. * dv-bfin_emac.c (bfin_emac_io_write_buffer): Pass 0xe1 to dv_w1c_4 diff --git a/sim/bfin/TODO b/sim/bfin/TODO index d180ab2..b81d770 100644 --- a/sim/bfin/TODO +++ b/sim/bfin/TODO @@ -19,7 +19,29 @@ fix single stepping over debug assert instructions in hardware exception in IVG5 causes double fault ? -add a "file" option to the async banks to back it +SIC int forwarding doesn't accurately reflect the hardware. what the sim +does is: + - device generates an interrupt + - int is sent to SIC + - SIC logs it into its ISR + - so long as SIC's IMASK allows it, bits set in ISR generate + an interrupt to the CEC + - no way to clear the SIC's ISR +the way the hardware works is that the device monitors the interrupt level and +the SIC's ISR bits are basically hardwired from each peripheral. so when the +device has its interrupt cleared, the bit in the SIC's ISR is automatically +cleared as well. +perhaps the only way to model this behavior in the sim is to have each device +set up an event callback that sends out a port event: a level of 0 means the +int has been ACKed and the SIC can clear its ISR while a level of 1 means the +int is being generated still. if the device is still generating an interrupt, +it can reschedule itself again. + +insns that cause an interrupt don't seem to be processed at the right time. +for example, setup a glue device that generates an interrupt upon right. +when the store insn is executed, the interrupt is taken right away instead +of being scheduled *after* the insn has finished executing. difference is +that RETI needs to point to the *next* insn and not the store insn. tests: - check AN bits with Dreg subtraction