RISC-V interrupts

Sun Jun 11 11:36:22 UTC 2017

I found out that there is 16 KiB of RAM. So, Freedom E310 chip has only 16
KiB of RAM.
And Freedeom E310 chip is based on E31 Coreplex core that allows maximum of
64 KiB of RAM.
So, I was just a bit confused with these names at first.

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

> On Fri, Jun 9, 2017 at 9:09 AM, Denis Obrezkov <denisobrezkov at gmail.com>
> wrote:
> > 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!
> >
> Great! Glad to know it's working now. You might want to do some
> analysis of the size/footprint of your executable (e.g. hello world),
> and what should go into ROM vs RAM. 64 KiB might not be enough for
> some applications. Also there is a "compressed" version of the RISC-V
> ISA, might be worth looking at.
>
> >
> >
> > --
> > Regards, Denis Obrezkov
>
>
>
> --
> Hesham
>

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