Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Ticket #70: m68kisr.txt

File m68kisr.txt, 3.6 KB (added by Joel Sherrill, on 12/03/06 at 13:31:13)

m68kisr.txt

Line 
1From - Wed Oct 31 07:57:29 2001
2Return-Path: <rtems-users-return-3707-joel=oarcorp.com@oarcorp.com>
3Delivered-To: joel@oarcorp.com
4Received: (qmail 12369 invoked by uid 330); 19 Oct 2001 00:19:03 -0000
5Mailing-List: contact rtems-users-help@oarcorp.com; run by ezmlm
6Delivered-To: mailing list rtems-users@oarcorp.com
7Received: (qmail 12362 invoked from network); 19 Oct 2001 00:19:00 -0000
8Received: from unknown (HELO bendor.com.au) (203.12.81.45)
9  by 0 with SMTP; 19 Oct 2001 00:19:00 -0000
10Received: from localhost (2906 bytes) by bendor.com.au
11        via sendmail with P:stdio/R:inet_hosts/T:smtp
12        (sender: <zoltan>) (ident <zoltan> using unix)
13        id <m15uNOR-0006RvC@bendor.com.au>
14        for <rtems-users@oarcorp.com>; Fri, 19 Oct 2001 10:20:07 +1000 (EST)
15        (Smail-3.2.0.101 1997-Dec-17 #1 built 1998-May-27)
16From: Zoltan Kocsi <zoltan@bendor.com.au>
17MIME-Version: 1.0
18Content-Type: text/plain; charset=us-ascii
19Content-Transfer-Encoding: 7bit
20Date: Fri, 19 Oct 2001 10:20:07 +1000 (EST)
21To: rtems-users@oarcorp.com
22Subject: m68k BSP with no VBR
23X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
24Message-ID: <15311.28847.79393.846142@tade.bendor.com.au>
25
26I think somebody on this list asked about the interupt vector
27handling w/o VBR and RAM at 0.
28
29The usual trick is this:
30
31You initialise the vector table (except the first 2 two entries, of
32course) to point to the same location BUT you also add the vector
33number times 0x1000000 to them. That is, bits 31-24 contain the vector
34number and 23-0 the address of the common handler.
35Since the PC is 32 bit wide but the actual address bus is only 24,
36the top byte will be in the PC but will be ignored when jumping
37onto your routine.
38
39Then your common interrupt routine gets this info by loading the PC
40into some register and based on that info, you can jump to a vector
41in a vector table pointed by a virtual VBR:
42
43//
44//  Real vector table at 0
45//
46 
47    .long   initial_sp
48    .long   initial_pc
49    .long   myhandler+0x02000000
50    .long   myhandler+0x03000000
51    .long   myhandler+0x04000000
52    ...
53    .long   myhandler+0xff000000
54   
55//
56// This handler will jump to the interrupt routine   of which
57// the address is stored at VBR[ vector_no ]
58// The registers and stackframe will be intact, the interrupt
59// routine will see exactly what it would see if it was called
60// directly from the HW vector table at 0.
61//
62
63    .comm    VBR,4,2        // This defines the 'virtual' VBR
64                            // From C: extern void *VBR;
65
66myhandler:                  // At entry, PC contains the full vector
67    move.l  %d0,-(%sp)      // Save d0
68    move.l  %a0,-(%sp)      // Save a0
69    lea     0(%pc),%a0      // Get the value of the PC
70    move.l  %a0,%d0         // Copy it to a data reg, d0 is VV??????
71    swap    %d0             // Now d0 is ????VV??
72    and.w   #0xff00,%d0     // Now d0 is ????VV00 (1)
73    lsr.w   #6,%d0          // Now d0.w contains the VBR table offset
74    move.l  VBR,%a0         // Get the address from VBR to a0
75    move.l  (%a0,%d0.w),%a0 // Fetch the vector
76    move.l  4(%sp),%d0      // Restore d0
77    move.l  %a0,4(%sp)      // Place target address to the stack
78    move.l  (%sp)+,%a0      // Restore a0, target address is on TOS
79    ret                     // This will jump to the handler and
80                            // restore the stack
81
82(1) If 'myhandler' is guaranteed to be in the first 64K, e.g. just
83    after the vector table then that insn is not needed.
84
85There are probably shorter ways to do this, but it I believe is enough
86to illustrate the trick. Optimisation is left as an excercise to the
87reader :-)
88
89I hope this helps,
90
91Zoltan