RE: Hook and Chain Interrupt, ARM Assembly

Attached is the .gel file

Hi Jeff,

This forum supports only the TI distributed Linux EZSDK. If you are interested in Starterware, the forum location is http://e2e.ti.com/support/embedded/starterware/f/790.aspx

Thanks for the reply Biser.  I really would just like to know what I may be missing on hooking the interrupt vector table of the A8.  I just saw a lot of replies referring people to Starterware and thought I would preemptively address it...probably wasn't necessary.

Jeff

See attachment for a working interrupt-driven GPIO example for the BeagleBone Black, entirely in assembly.

You can either upload build/MLO.elf via JTAG and run to symbol _start or put build/MLO on a FAT-formatted microSD card and boot from that.

When running, USR0 turns on.  Pressing the SD-boot button (SW2) will trigger an interrupt which changes the LEDs.

3000.trivial-a8.zip

To add: no GEL file is strictly necessary for my example unless you want to upload it from Wait-in-reset, in which case the OCMC memory isn't enabled yet (and I think the watchdog might be running? not sure).

You can change MLO.ld to send .text to a8ram instead of ocmc0 to remove the dependency on OCMC memory, but the cortex-a8 local RAM has the disadvantage that it isn't accessible via DAP and therefore can't be examined without halting the core.  (It has the advantage of always being available and it has lower access time.)

The Makefile expects you have an arm-none-eabi toolchain in your path.  For the Cortex-A series, the Linaro toolchain seems nice, though for an assembly-only project it really doesn't matter much.

Matthijs,

Thank you so much for the thorough reply and example.  I didn't expect example code to reference so that was a nice surprise.  I am still learning assembly and all of the nuances of the Cortex A8.  I have looked through your code and will continue to do so until everything makes sense.  Thanks again.

Jeff

You're welcome!  Doing baremetal programming on processors like these has a bit of a learning curve and it's not always easy to find useful examples.

Note BTW that my code is actually Thumb rather than ARM, but thanks to unified assembler syntax you don't really notice the difference apart from smaller code size.  In general, on the cortex-A8 and later processors the two instruction sets are virtually identical and Thumb gets you smaller size (hence, due to caching, faster code) so I would personally regard the original ARM instruction set as deprecated.  The main differences that I've noticed are:

• Slightly different range for immediate operands to ALU ops (neither bigger nor smaller, just different)
• Smaller range of immediate operand for load/store with base register writeback
• No PC-relative stores supported, only PC-relative loads.
• ldrd and strd allow arbitrary registers for the low and high words (ARM required an even/odd pair of adjacent registers)

As for the nuances of the cortex-A8, its TRM is not always very clear, and contains errors:  I noticed the "L2 cache enabled" bit of the L2 auxiliary control register is, contrary to the TRM, not banked between secure and non-secure states.  Other people have noticed the instruction cycle timings are simply wrong, so if you plan to write any performance-critical code I suggest you google on that topic.  Fortunately the latest revision (r3p2) of the processor, which is what's on the am335x, has only a few errata.  Since that doc is for some reason hard to find I'll list them:

• Performance counter overflow flag (and associated IRQ) is unreliable.  Workaround: since a counter can't increment more than twice per cycle, polling the counters with an interval of less than 2³¹ cycles guarantees that you will always be able to notice when they wrap.
• Data cache clean and/or invalidate ops that hit cache can deadlock if the memory is marked as non-cacheable.  When changing memory type of a section or page from cacheable to non-cacheable, be sure to invalidate it *before* making the change.  (Some later processors on the other hand require the cache invalidation *after* changing memory type due to speculative execution, but that's not an issue on the cortex-a8)
• L2 cache should not be configured as "inner cache" (there's no reason to do this anyway).
• "BTB invalidate by MVA" ops have unpredictable behavior if the "IBE" bit is set in the auxiliary control register.  Explicit BTB invalidates are however never necessary on the cortex-a8, and there's also no reason for the IBE to be set (however I've noticed that on the DM814x the bootrom code sets the IBE bit.  I haven't checked the AM335x yet, but if its bootrom does the same I recommend clearing it.  Changing the auxiliary control register requires a secure monitor call, this is explained in the AM335x TRM.)
• Converting a 32-bit integer to 32-bit float gives wrong result for a single input value (0xffffff01) when rounding mode is set to "round to +∞" and floating-point unit is configured in "fast mode" ("Default NaN" and "Flush-to-zero" enabled)
• Watchpoint incorrectly takes precedence over data abort.  You don't need to care unless you're writing a debugger.

Finally, if you care at all about performance, I strongly advise enabling the MMU so you can set appropriate memory attributes.  Even if you don't care about performance it may still be a good idea since Cortex-A8 MMU-disabled behaviour is somewhat tricky.

Good luck!

Thanks to unified assembler syntax, there's little difference between the two.

Attached is an updated version. trivial-a8.tar.gz  I've changed one occurrence of cbz to beq (the condition was already set correctly), and synchronized the initialization code, Makefile, and linker script to that of my own baremetal codebase.

You can now do "make no_thumb=1" to generate an ARM-only version. (Big question is of course, why would you want to?)

In theory you can even assemble some files in ARM-mode and others and Thumb-mode and the result should still work, but I have not tested this. Actually, I haven't checked whether it still works at all... I just made sure I didn't get any assembler/linker errors and checked whether the output files looked plausible. Let me know if there's any trouble.

Note that it's currently configured to link at 0x402f0400 to ensure you can also use peripheral boot. If you don't care about peripheral boot, you can change the link address to 0x40300000 which may be more convenient for debugging. See demo.ld.

ok thanks, i'll giver' a go.
my irq demo runs, but hangs on the first interrupt.
i suspect it is not jumping to my isr.
i am having difficulty figuring out what address the bbb jumps
to when an irq is triggered.
i'm working on it............dd

hi matt.  i am still having trouble.  your demo.ld does alot of stuff i am not familiar with. 

my program runs but it still does not jump to my isr with output segment beginning at 0x40300000.

i am trying to build a stripped down version of an i2c_IRQ example.  i am loading with

an xds100v2 jtag cable.  maybe that is causing my confusion.  how do you load? 

maybe you can have a quick look at my initial code and see if i am screwing up somewhere

else besides the .ld script: 

here is my irqvector.s:

//
// Interrupt vector init
//
.global Entry
.text
.code 32

Entry:

reset:  b     start  // p4664
undef:  b     undef
swi:    b     swi
pabt:   b     pabt
dabt:   b     dabt
        nop
irq:    b     i2c1_ISR  // must peek ACTIVEIRQ & follow doc
fiq:    b     fiq

// finito

and here is my startup.s:

//
// generic startup routine - init stacks
//
.global _stack                  

    .set  UND_STACK_SIZE, 0x8
    .set  ABT_STACK_SIZE, 0x8
    .set  FIQ_STACK_SIZE, 0x8
    .set  IRQ_STACK_SIZE, 0x100
    .set  SVC_STACK_SIZE, 0x8

    .set  MODE_USR, 0x10            
    .set  MODE_FIQ, 0x11
    .set  MODE_IRQ, 0x12
    .set  MODE_SVC, 0x13
    .set  MODE_ABT, 0x17
    .set  MODE_UND, 0x1B
    .set  MODE_SYS, 0x1F            

    .equ  I_F_BIT, 0xC0               

.text
.code 32
.global start
start:
    LDR   r0, =_stack                     @ Read the stack address

    MSR   cpsr_c, #MODE_UND|I_F_BIT       @ change to undef mode
    MOV   sp,r0                           @ write the stack pointer
    SUB   r0, r0, #UND_STACK_SIZE         @ give stack space

    MSR   cpsr_c, #MODE_ABT|I_F_BIT       @ Change to abort mode
    MOV   sp, r0                          @ write the stack pointer
    SUB   r0,r0, #ABT_STACK_SIZE          @ give stack space

    MSR   cpsr_c, #MODE_FIQ|I_F_BIT       @ change to FIQ mode
    MOV   sp,r0                           @ write the stack pointer
    SUB   r0,r0, #FIQ_STACK_SIZE          @ give stack space

    MSR   cpsr_c, #MODE_IRQ|I_F_BIT       @ change to IRQ mode
    MOV   sp,r0                           @ write the stack pointer
    SUB   r0,r0, #IRQ_STACK_SIZE          @ give stack space

    MSR   cpsr_c, #MODE_SVC|I_F_BIT       @ change to SVC mode
    MOV   sp,r0                           @ write the stack pointer
    SUB   r0,r0, #SVC_STACK_SIZE          @ give stack space

    MSR   cpsr_c, #MODE_SYS|I_F_BIT       @ change to system mode
    MOV   sp,r0                           @ write the stack pointer

    bl main

stop:
    b stop

// finito

i am doing stacks.  the rest of the init stuff like isr_vector, isr_i2c, aintc_init & i2c_irq init is done from

the main program.  we can look at it later, if need be.  right now lets focus on a bare-bones

.ld script.  i am very uneasy with my image building abilities and i do not know what is going on

with the boot procedure, where to locate the irqvector, the code, where execution begins and

where it jumps to when an irq is generated. 

i am loading and booting via jtag, maybe that is where i am screwing up. 

looking at my irqvector.s and startup.s, what would be the simplest .ld script? 

thanks alot, i am running out of ideas............dd

You need to configure the base address of your vector table using an mcr instruction, see init.S in my latest assembly version. Note that my code relies on init being called with "bl" from the reset vector (which is also the entrypoint) and obtains the vector table address using LR.

Also, get rid of all those stacks... you really don't need a stack per mode anymore in ARM architecture v6 or later.

All my examples use a single stack. This is accomplished by giving each exception handler a 2-3 instruction prologue (created using my ".handler" macro) and return using "rfefd sp!" (for which I also made a macro "hret").

hi again matt.  here is my attempt at a .ld script:

MEMORY
{
    RAMvector    : o = 0x40300000, l = 0x000002E  /* RAM vector */
    SRAM     : o = 0x80000000, l = 0x00001000  /* 64kB internal SRAM per pwm.cmd */
}
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)

SECTIONS
{
  .reset_handle :
  {
    *vector.o (.text)
  } >RAMvector

    .text ALIGN(4) :
    {
        *(.text)
    } >SRAM

    .data ALIGN(4) :
    {
        *(.data)
    } >SRAM
    .stack :
    {
    } >SRAM
    _stack = ORIGIN(SRAM) + LENGTH(SRAM) - 4;

}

it hangs when the IRQ is generated, like your demo.ld

what do you think?.............dd

ok, after grokking trivial-a8, i think i will toss my init stuff entirely and use yours.  i'd rather build the interrupt vector and stacks manually, but i will assume your way is ultimately better. 

we shall see.......................dd

I'm not quite sure what you mean... I actually endorse building the vector table at runtime, like I do in my C++ version, but the whole thing with multiple stacks is a relic of the past and considered deprecated by ARM: they've dumped it themselves when they had the opportunity to do so, in ARMv7-M and in ARMv8. My code basically simulates the new (v7-M / v8) way of doing things and is therefore forward-compatible.

The only thing I still have on my to-do list is supporting a separate "thread" and "handler" stack rather than having a single unified stack, but it hasn't been a priority for me.

>I actually endorse building the vector table at runtime, like I do in my C++ version

Well, my interrupt vector table may be in the wrong place.  That is one of the suspected culprits. 

Tell me what address you put it at please. 

Starterware puts it at 0x4030FC00 in startup.c.

The trm says 0x4030CE00. 

thanks..............dd

I think we're talking about different vector tables. I was referring to the 128-entry table used for interrupt dispatching (called irq_vectors in my code). You're presumably talking about the exception vector table (called vectors in my example). I would not recommend constructing it at runtime, since it seems pointless to do so and moreover it is code rather than data.

You can put the exception vector table at any 32-byte aligned address. You need to program its address into a specific CP15 register (see my init.S, the instruction with comment "set vector base").

Hi again Matt.  I tried to build and test your trivial-a8 example with gcc without success. And I can't build it in CCS either.  So, I am examining it manually, again.  I found something very interesting in init.s , the line:

    mcr    p15, 0, r4, c12, c0, 0    // set vector base (bit 0 is ignored)

What does it do?  Where is this documented?  Where did you get it? 

I could not find out much.  Apparently it transfers data to coprocessor p15, or instructs it to do something.  This is probably the answer to my problem. 

Also you do some fancy footwork by calling it from the reset vector before the vector has been initialized.  Please explain what is going on here.  And don't harp on thumb or thread mode stuff.  I don't want to go there yet, I am doing this the old way as outlined in spruh73j ch 6.2 Basic Programming Model. 

And send me an image dump.  It will help me decipher things.  To  d7 at hushmail dot c0m

thanks a bunch.............dd

Don Lawrence said:

I tried to build and test your trivial-a8 example with gcc without success.

Hmm, what error are you getting? Also, what version of gcc are you using? I think it needs at least 4.9. For example you can use the latest Linaro toolchain.

Don Lawrence said:

in init.s , the line:

    mcr    p15, 0, r4, c12, c0, 0    // set vector base (bit 0 is ignored)

What does it do?  Where is this documented?  Where did you get it?

If you look at the last line of my previous post:

Matthijs van Duin said:

You can put the exception vector table at any 32-byte aligned address. You need to program its address into a specific CP15 register (see my init.S, the instruction with comment "set vector base")

The CP15 registers are documented in general in the ARM Architecture Reference Manual and CPU-specifics in the Cortex-A8 Technical Reference Manual. Here's the register description in the A8 TRM.

Don Lawrence said:

Also you do some fancy footwork by calling it from the reset vector before the vector has been initialized.

Correct, I described this previously also: I use the "reset vector" as entrypoint of the program (note that an actual reset of course will never end up there directly). From there I do "bl init", which allows me to extract two pieces of information from LR: I obtain the location of the vector table, which I program into the vector table base CP15 register, and bit 0 reflects whether the vector table was compiled in ARM or Thumb mode, which I need to configure into a particular CP15 System Control Register bit to ensure the processor switches to the right state on exception entry.

Technically I should clear bit 0 before writing it into the vector table base register, since bits 0-4 are reserved/SBZ, but since they are RAZ/WI in practice I was lazy and didn't bother ;)

Matthijs van Duin said:

Hmm, what error are you getting? Also, what version of gcc are you using? I think it needs at least 4.9.

Wait, actually that's just my C++ code that needs 4.9... trivial-a8 doesn't even involve compiling, it's all assembly...

Hi again.  I got a ton of errors, I got thru most of them but your code looked much different so I decided to just incorporate your technique instead.  I am not so good at this level.  I will forge ahead with your added input.  Blow me away.  thanks.............dd

That doesn't make any sense, I obviously made sure it builds before I uploaded it. If the Makefile is giving trouble, I can successfully build it simply with:

arm-none-eabi-gcc -nostartfiles -Wl,--build-id=none -o demo-arm.elf -T demo.ld *.S

for ARM mode, or:

arm-none-eabi-gcc -nostartfiles -Wl,--build-id=none -Wa,-mthumb -o demo.elf -T demo.ld *.S

for Thumb mode.

You can also use arm-linux-gnueabihf-gcc instead. The particular GCC you use shouldn't matter since it only uses the preprocessor, assembler, and linker. It doesn't use any external headers or libraries (not even those supplied by the compiler).

Hi.  ok thanks i was able to build from your cmd line :

arm-none-eabi-gcc -nostartfiles -Wl,--build-id=none -o demo-arm.elf -T demo.ld *.S

all i got for an error was "undefined reference to __image_end"  in mlo-header.s which i dutifully commented out.  i cannot comprehend much of what you are doing, as i said, i am not good at this level...  but now i have an image dump that i can scrutinize. 

i had a quick look at the cortex-a8 manual from arm,  all that cp15 stuff is boggling, i really do not like it, but it appears necessary.  it is far beyond armv6 interrupt handling. 

i will now load/run your demo on my bbb.  is there any wiring or run instructions?  it looks like u just press the boot button to toggle the userleds. 

thanks again............dd

Don Lawrence said:

all i got for an error was "undefined reference to __image_end"  in mlo-header.s

Uhh, the new version of my trivial-a8 doesn't have an mlo-header.S, it includes a utility to generate the MLO header instead. Did you mix files from the old version and new version? In the new version, to produce peripheral boot (.bin) and memory boot (MLO) images from the ELF file do:

arm-none-eabi-objcopy -O binary demo.elf demo.bin
bin/mk-gpimage 0x402f0400 demo.bin MLO

Don Lawrence said:

i will now load/run your demo on my bbb.  is there any wiring or run instructions?  it looks like u just press the boot button to toggle the userleds. 

No specific wiring or run instructions, you can e.g. put the MLO on a μSD card and boot that, or serve the peripheral boot image via any supported peripheral boot method (I often use TFTP over Ethernet). If using JTAG upload of the ELF file, make sure u-boot hasn't run since it sets up the MMU and caches and you don't want to have to deal with the leftovers of that. An easy way is powering up the BBB with the SD-boot button pressed but no card inserted.

Don Lawrence said:

i had a quick look at the cortex-a8 manual from arm,  all that cp15 stuff is boggling, i really do not like it, but it appears necessary.  it is far beyond armv6 interrupt handling. 

I think it's actually roughly the same set of registers as ARMv6Z (ARM1176JZF-S). Note that you don't actually need to touch many of them (in fact, many are only accessible in secure world; Secure ROM has an API to set three of them, none of which you need unless e.g. you want to enable parity/ECC of the L1/L2 caches).

When I find a moment I'll post a follow-up outlining the few registers you may need to concern yourself with. (E.g. it is strongly recommended to set up the MMU and enable caches.)

Hi Matt.  It builds ok, I must have mixed the new and old version.  The one I have now trivial-a8.tar.gz (7728 bytes) I got from earlier in this thread.  The .bin loads via jtag without complaint: 

arm-none-eabi-gcc -nostartfiles -Wl,--build-id=none -o demo-arm.elf -T demo.ld *.S
arm-none-eabi-objcopy -j .text -j .data -O srec demo-arm.elf rts.bin

Yes I power-up holding down the boot button. 

Then nothing happens when the boot button is pressed. Do you turn on a USR LED after all the init stuff?  I don't know if it is running. 

I'll keep trying, It looks clean and small. 

thnks.............dd

ok, I'm an idiot and should have tested the new version properly even though I made only "minor changes" from the original, since one of those minor changes broke the program.

vectors.S, in init_intc, insert "push { lr }" at top and replace its "ret" by "pop { pc }"

or use attached new files: 5001.trivial-a8.tar.gz

BTW, why are you converting the ELF file to srec? You can just load the ELF file in CCS (Run -> Load -> Load Program) which also automatically loads symbols for debugging.

Also there's no point in selecting sections with those -j statements, you get the same result without them, and using them is actually dangerous -- this little assembly test only contains a .text section, but my C++ version has a non-empty .rodata section, which you would have discarded. (The linker script makes sure there's no crap in the ELF file anyway.)

Hi Matt.  Ok, it builds/loads/runs with gcc from the command line.  A USR LED lights up and stays lit after the boot button is pressed.  This is progress!  Under CCS6.0 with the Linaro compiler it gives 1 error:

./vectors.S:43: Error: bad instruction `srsfd sp!,0b11111'

With the TI compiler it gives 50 errors, mostly it does not like your comments. 

I tried your advice (Run -> Load -> Load Program) to load demo.elf but there is only a Debug option which rebuilds and does not let me select another load file.  It would be very nice to have the ability to debug either in CCS or the command line.  I have the freebie version. 

I got rid of the compile option -j  ,  no joy. 

thanks, later...........dd

ps I do not use make on the windows command line, just the cmds:

arm-none-eabi-gcc -nostartfiles -Wl,--build-id=none -o demo.elf -T demo.ld *.S
arm-none-eabi-objcopy -O srec demo.elf rts.bin
arm-none-eabi-objdump -d -S -h -t demo.elf

maybe you should try it that way.  Fast, easy and no surprises. 

Don Lawrence said:

./vectors.S:43: Error: bad instruction `srsfd sp!,0b11111'

Try passing -mcpu=cortex-a8

Don Lawrence said:

With the TI compiler

Yeah you can stop that sentence right there... I have no intention of supporting the TI compiler.

Don Lawrence said:

I tried your advice (Run -> Load -> Load Program) to load demo.elf but there is only a Debug option which rebuilds and does not let me select another load file.  It would be very nice to have the ability to debug either in CCS or the command line.  I have the freebie version. 

You can reconfigure the debug configuration to load a different file, or no file at all (which is my preference since I want to be able to attach to a running system). In any case, after the debug session is started you can select the cortex-A8, suspend it (click the pause button), and then use menuitem Run -> Load -> Load Program

I've also often used dss from the commandline, that works too and starts a lot quicker than CCS.

Don Lawrence said:

maybe you should try it that way.

haha, if you want to type all that every time you want to rebuild, go ahead. I rather type "make". Also, this is just a trivial project, but as things get more complex you will definitely want a build tool of some sort. I'm not saying Make is good, in fact it's crap, but it's ubiquitous and I know its quirks well enough to keep me from being sufficiently motivated to give alternatives a serious try.

I can imagine my makefile won't work on Windows though, at least not without using cygwin or something like that. It needs at least a sufficiently recent GNU make, bash, awk, perl, and possibly other things I'm overlooking. It is way more complicated than needed here since it's basically copied over from my less-trivial projects ;-)

Hi again Matt.  With your latest example I get a USR LED to light up when boot is finished. But it stays lit when the boot button is pressed. I can get no further.  It should toggle every time it the boot button is pressed, no?  I am running out of ideas.  Did you get it working with arm-none-eabi-gcc is your dev system Linux of Windows? 

I am on Widows and I build with the cmd:

arm-none-eabi-gcc -nostartfiles -Wl,--build-id=none -o demo.elf -T demo.ld *.S

No, it is not a problem without using Make, I just put the cmds in a .bat file.  I gave up on Linaro and the TI compiler.  Maybe give me your dump and I will compare it with mine. 

thanks............dd

Don Lawrence said:

is your dev system Linux of Windows?

Linux, I do not use any Windows system.

I've included compiled versions in attachment, both thumb and non-thumb versions, both verified to work on a BBB: leds 0 and 1 are on initially, leds 0, 2 and 3 are on while button S2 is pressed.

It also includes a greatly simplified makefile that might work with the GNU make that's included with CCS, but I haven't tested this.

4452.trivial-a8.tar.gz

Hi again Matt.  Yeah it works great!  And the makefile works also.  I 'make' with GNUwin32. 

Thanks alot man.  I hate to ask someone to spoon-feed me but I have been stuck

on this for 2 months.  It is really quite difficult to get running the first time. 

So many different things can go wrong, assembly, peripheral specs, ld scripts. 

I don't like Windows either but I can't afford another machine now, (between jobs). 

thanks again, I'll keep you posted...............dd

Don Lawrence said:

It is really quite difficult to get running the first time. 

So many different things can go wrong, assembly, peripheral specs, ld scripts.

Yeah, I know. Not to mention incomplete or wrong documentation, and "examples" that should never be followed.

Things generally get easier once you have something to start with, though baremetal coding on a big SoC like this still takes some time to get comfortable with.

Don Lawrence said:

I don't like Windows either but I can't afford another machine now, (between jobs). 

I had to semi-regularly work on Windows for a while. I found MSYS2 quite useful to give me a decent shell (bash) and standard utilities you'd have available on Linux. Of course a BeagleBone Black also works fine as development system for small projects, even if it's a bit slower.