RISC-V interrupts

[Denis Obrezkov]

2017-06-09 1:52 GMT+03:00 Hesham Almatary <heshamelmatary at gmail.com>:

> Hi Denis,
>
> Does your board support any accesses to > 0x80000000. Note you still
> use such region in your linker script, which shouldn't be used if your
> board doesn't support it. I'd suggest your read about memory mapping
> on your board and fix the linker script accordingly.
>
> Regards,
> Hesham
>
> On Fri, Jun 9, 2017 at 8:38 AM, Denis Obrezkov <denisobrezkov at gmail.com>
> wrote:
> > 2017-06-08 17:49 GMT+03:00 Denis Obrezkov <denisobrezkov at gmail.com>:
> >>
> >> 2017-06-08 12:24 GMT+03:00 Denis Obrezkov <denisobrezkov at gmail.com>:
> >>>
> >>> 2017-06-07 22:41 GMT+03:00 Hesham Almatary <heshamelmatary at gmail.com>:
> >>>>
> >>>> On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov <
> denisobrezkov at gmail.com>
> >>>> wrote:
> >>>> > 2017-06-07 14:44 GMT+03:00 Sebastian Huber
> >>>> > <sebastian.huber at embedded-brains.de>:
> >>>> >>
> >>>> >> On 06/06/17 18:58, Hesham Almatary wrote:
> >>>> >>
> >>>> >>> Originally RTEMS had a one big linkcmd for each platform, which
> >>>> >>> defines linker symbols (used in C code) and required sections.
> This
> >>>> >>> has been improved with current BSPs (like ARM-based ones), by
> >>>> >>> splitting up shared linkcmd parts (linkcmd base) and BSP specific
> >>>> >>> ones
> >>>> >>> that include the shared one. riscv_generic, given that it's old,
> >>>> >>> follows the old way of having a single big linkcmd. You can change
> >>>> >>> this for your new BSP.
> >>>> >>
> >>>> >>
> >>>> >> New ports/BSPs should definitely use a shared linkcmds.base (see
> >>>> >> ARM). Use
> >>>> >> "riscv-rtems4.12-ld --verbose" to get the default linker script.
> >>>> >
> >>>> > Ok.
> >>>> >
> >>>> > Now I have a problem:
> >>>> >
> >>>> > https://github.com/embeddedden/rtems-riscv/blob/
> hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L117
> >>>> > When I step to that line, gdb hangs with a message:
> >>>> > (gdb) step
> >>>> > Note: automatically using hardware breakpoints for read-only
> >>>> > addresses.
> >>>> >
> >>>> How do you run/attach simulator (and which one do you use)? Do GDB and
> >>>> the simulator support 0x20400000 > addresses (where your text section
> >>>> is loaded to)? AFAIK, that's not the case. Spike's default machine
> >>>> only works with addresses >= 0x80000000. You've to look up if Spike,
> >>>> Qemu [1] or GDB target sim model your board.
> >>
> >> I use openOCD from FreeStudio kit:
> >>
> >> https://github.com/sifive/freedom-e-sdk/blob/master/
> FreedomStudio/HiFive1/hello/openocd.cfg
> >>
> >> I was able to run code in ROM region, after I made this:
> >>
> >> MEMORY
> >> {
> >>     ROM      : ORIGIN = 0x20400000, LENGTH = 128M
> >>     RAM      : ORIGIN = 0x80000000, LENGTH = 64K
> >> }
> >>
> >> REGION_ALIAS ("REGION_VECTOR", RAM);
> >> REGION_ALIAS ("REGION_START", ROM);
> >> REGION_ALIAS ("REGION_TEXT", ROM);
> >> REGION_ALIAS ("REGION_TEXT_LOAD", ROM);
> >> REGION_ALIAS ("REGION_RODATA", ROM);
> >> REGION_ALIAS ("REGION_RODATA_LOAD", ROM);
> >> REGION_ALIAS ("REGION_DATA", RAM);
> >> REGION_ALIAS ("REGION_DATA_LOAD", ROM);
> >> REGION_ALIAS ("REGION_FAST_DATA", RAM);
> >> REGION_ALIAS ("REGION_FAST_DATA_LOAD", ROM);
> >> REGION_ALIAS ("REGION_BSS", RAM);
> >> REGION_ALIAS ("REGION_WORK", RAM);
> >> REGION_ALIAS ("REGION_STACK", RAM);
> >>
> >> And gdb can step till the "call boot_card" instruction,
> >> but I can't proceed any further due to the error:
> >> gdb hands after stepping into "call boot_card"
> >> At the same time openocd shows:
> >>
> >> halted at 0x20400202 due to step
> >> halted at 0x20400262 due to hardware trigger
> >> halted at 0x204010c2 due to step
> >>
> >> The last line appears after attempt to make the step.
> >> Links to my linkcmd and start.S files:
> >>
> >> https://github.com/embeddedden/rtems-riscv/blob/
> hifive1/c/src/lib/libbsp/riscv32/hifive1/startup/linkcmds
> >>
> >> https://github.com/embeddedden/rtems-riscv/blob/
> hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S
> >>
> >>
> >> Regards, Denis Obrezkov
> >
> >
> > I also found out that when I use stepi on "call boot_card" I got a
> warning
> > from openocd:
> > Core got an exception (0xffffffff) while reading from 0x8000effc
> >
> > --
> > Regards, Denis Obrezkov
>
>
>
> --
> Hesham
>
Yes, it definitely supports it, I've already done it.
0x80000000 is the start of 64 KiB RAM, and 0x20000000 is the start of flash.

I think I found the problem. It seems that this gdb build supports 16 KiB
of RAM (as in Freedom E300 specification).
I changed the value of RAM length to 16 KiB, so now I can execute further.
Thanks!



-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170609/a79a113f/attachment-0002.html>