[mc1322x] _rom_data_init_ branch

[Mariano Alvira]

Giandomenico,

This is great! Thank you. Every piece of documentation helps.

I did also want to mention that both mc1322x-tests and contiki-mc1322x
use interrupts. Anyone working with interrupts may find the following
files useful:

  mc1322x-tests/src/isr.c
  mc1322x-tests/src/start.S
  mc1322x-tests/boot.lds

and 
 
  contiki-mc1322x/cpu/mc1322x/isr.c
  contiki-mc1322x/cpu/mc1322x/mc1322x.lds
  contiki-mc1322x/cpu/mc1322x/startup.S
  contiki-mc1322x/cpu/mc1322x/clock.c

-Mar.


On Thu, Jul 16, 2009 at 04:17:43PM +0300, Giandomenico Rossi wrote:
> > I can't say for sure exactly what rom_data_init does --- unfortunatly
> > only Freescale has the answer to that. 
> > 
> > The following:
> > 
> >    .org 0x120
> >    ROM_var_start: .word 0
> >    .org 0x7ff
> >    ROM_var_end:   .word 0
> > 
> > reserves space for the ROM services and I believe rom_data_init does
> > work in this area.
> I report, if it could be useful to someone,  some developments on my
> hacking rom_data_init call.
> 
> I have just notice that in rom_data_init call there are 2 entries at
> address 0x11788 and 11798 of the form :
> +-----------------------------------------------------+
> |   address1 |  address2  | size  | function adddress |
> +-----------------------------------------------------+
> |  0x40020c  |  0x40020c  | 0x520 |    0x10b2c        |
> +-----------------------------------------------------+
> |  0x400120  |  0x400120  | 0x97  |    0x10a9c        |
> +-----------------------------------------------------+
> The first routine to 0x10b2c set to 0  memory 
> from 0x40020c to 0x40020c+0x520 but I don't know what stand for.
> 
> The second entry point refers to address 0x400120 which is ROM_var_start
> as  Mariano said!
> 
> Well, I was writing code for CRM interrupt handler when I figured out
> that I didn't know where Interrupt handler table was located.
> Looking inside the file doc/ws-dis of mc1322x-tests it's easy to find in
> the exception vector table the address of irqHandler that is the routine
> where CPU jumps whenever a normal interrupt request is fired:
> 
>   400018:       eaf041fc        b       10810 <IrqHandler>
> 
> 
> IrqHadler is at address 0x10810.
> This is a routine coded in ARM instructions  so I had no problem
> disassembling it with FORTH DASM and discover that it does the
> following:
> 
> i)  read pending normal interrupt source from read-only register
> NIVECTOR
> 
> ii)  check if source is less than 11, the max number of interrupt
> sources 
> 
> iii) if it is the case load an address from 0x10838+8 in R1
> 
> iv) add 4*( interrupt source ) to R1 and jumps there.
> 
> The very funny thing is that looking for address in 0x10838+8 I've found
> 0x400120 which is ROM_var_start !!!! EUREKA!!!!
> ** First 11*4 bytes of ROM_var_start contain interrupt vector table. ** 
> 
> Rom Driver has 2 obscure functions for handler interrupts which are:
> 
> ITC_Init ()          @ 0xfe9d
> IntAssignHandler ()  @ 0xff25
> 
> The latter resets interrupt vector table and the former inserts an
> handler to interrupt table.
> Rom_data_init uses ITC_Init to fill interrupt vector table with the
> address of a dummy function located in rom at address 0x1001D .
> Call to  IntAssignHandler add handler function address to a
> corresponding  interrupt  vector table at ROM_var_start.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mc1322x mailing list
> mc1322x at devl.org
> http://devl.org/cgi-bin/mailman/listinfo/mc1322x