You could look at the TI starterware code  for examples of setting  up the 
interrupt table and the code at the tables.

 

Graham

 

From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagleboard@googlegroups.com] 
Sent: Sunday, March 07, 2021 12:30 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table

 

Your handler needs the keyword interrupt to save the registers so when the 
vector occurs whatever was running isn't corrupted

 

Besides interrupt vector table don't forget exceptions they need a vector as 
well as in bus error or address error

 

Here's a brief reference you should look for interrupt code to verify and the 
correct arm programming guide

 

 

https://community.arm.com/developer/tools-software/tools/f/armds-forum/13621/need-interrupt-handling-code-for-arm-cortex-a9

 

 

Sent from Yahoo Mail on Android 
<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
 

 

On Sun, Mar 7, 2021 at 12:01 PM, Josh Cole

<threeorb...@gmail.com <mailto:threeorb...@gmail.com> > wrote:

Update! 

 

I've solved my own problem and thought I'd share for any lost soul in the 
future who seeks these answers.

 

If you look at the technical reference manual for the am355x section 26-3 it 
shows an interrupt vector table which exists wildly far away from your 
application entrypoint. Upon closer inspection, I realized some entries are 
listed twice. This is because the interrupt vector table is actually a bunch of 
indirection.

 

If you want to set the IRQ branch address you specify the address at location 
0x4030_CE38

If you want to set the pre-fetch abort address you specify the address at 
location  0x4030_CE2C

 

Example code:

// Set the IRQ handler to the entrypoint of the application + 24 bytes

*(0x4030_CE38 as *mut u32) = 0x402F_0400 + 0x18;

 

I assumed I needed to write an actual branch instruction to those locations. 
Which is where my confusion started. So if you are building a low-level kernel 
and are working with interrupts, just remember that the vector table can be 
updated by simply writing the correct address to your handler based on the 
vector table in the reference manual (not an actual branch instruction).

 

On Friday, March 5, 2021 at 6:12:00 AM UTC-8 Josh Cole wrote:

Hi everyone,

 

I'm working on a low-level kernel for the Beaglebone Black. I've gotten to a 
point in my project where I want to specify an IRQ handler and enable 
interrupts.

 

According to the technical reference manual  
<http://www.sal.wisc.edu/st5000/datasheets/tq-systems/spruh73p.pdf> (section 
26.1.4), there are two primary locations you can load a disk image to. The 
first is what they call "Public ROM" which seems pretty straightforward. You 
load your image to address 0x20000 and the interrupt vector table is the first 
thing which gets encountered.

 

The second location you can load an image is "Public RAM" (which I'm using). 
This starts executing at 0x402F0400 and you get 109kb of space for your 
application. The weird part is, the interrupt vector table appears to be 
located super far away from the entrypoint, at location 0x4030CE00. This is 
more than 109kb away, so it can't be included in the image which gets flashed 
to the device.

 

I am at a loss about how to get an instruction to that particular location in 
memory since my image fundamentally can't be that size. Any guidance on how to 
setup the IVT for Public RAM would be greatly appreciated.

 

Thank you for your time!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 

https://groups.google.com/d/msgid/beagleboard/b63bc711-fcda-497b-b4e5-ee35c0081176n%40googlegroups.com
 
<https://groups.google.com/d/msgid/beagleboard/b63bc711-fcda-497b-b4e5-ee35c0081176n%40googlegroups.com?utm_medium=email&utm_source=footer>
 

.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com 
<mailto:beagleboard+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1482309015.269358.1615148982352%40mail.yahoo.com
 
<https://groups.google.com/d/msgid/beagleboard/1482309015.269358.1615148982352%40mail.yahoo.com?utm_medium=email&utm_source=footer>
 .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/001001d71433%248d59d000%24a80d7000%24%40comcast.net.

Reply via email to