Re: RISC-V interrupts
2017-06-07 22:41 GMT+03:00 Hesham Almatary : > On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov > wrote: > > 2017-06-07 14:44 GMT+03:00 Sebastian Huber > > : > >> > >> 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 0x2040 > addresses (where your text section > is loaded to)? AFAIK, that's not the case. Spike's default machine > only works with addresses >= 0x8000. You've to look up if Spike, > Qemu [1] or GDB target sim model your board. > I will investigate this. Could you also explain you .stack section in linkcmd file? is it on purpose always of zero size (.work section consumes all remaining memory)? -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
2017-06-08 12:24 GMT+03:00 Denis Obrezkov :
> 2017-06-07 22:41 GMT+03:00 Hesham Almatary :
>
>> On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov
>> wrote:
>> > 2017-06-07 14:44 GMT+03:00 Sebastian Huber
>> > :
>> >>
>> >> 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 0x2040 > addresses (where your text section
>> is loaded to)? AFAIK, that's not the case. Spike's default machine
>> only works with addresses >= 0x8000. 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 = 0x2040, LENGTH = 128M
RAM : ORIGIN = 0x8000, 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RTEMS-libbsd USB interrupt issue[GSOC]
Hi all, I am porting Beagle USB from FreeBSD to RTEMS-libbsd, the file i ported is from freebsd/sys/arm/ti/am335x, the file is: AM335x_musb.c , am335x_usbss.c ,etc. BSP: Beaglebone Black, CPU:AM335x The issue i meeted is : When the USB1_DRVVBUS pin pull high, the interrupt vector 0x19 occured, it stuck, and don't go the the ISR. The code stuck at here: https://github.com/freebsd/freebsd/blob/master/sys/dev/usb/controller/musb_otg.c#L3126 The install ISR at here: https://github.com/freebsd/freebsd/blob/master/sys/arm/ti/am335x/am335x_musb.c#L299 Best Regards Sichen Zhao ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
2017-06-08 17:49 GMT+03:00 Denis Obrezkov :
> 2017-06-08 12:24 GMT+03:00 Denis Obrezkov :
>
>> 2017-06-07 22:41 GMT+03:00 Hesham Almatary :
>>
>>> On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov
>>> wrote:
>>> > 2017-06-07 14:44 GMT+03:00 Sebastian Huber
>>> > :
>>> >>
>>> >> 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/sr
>>> c/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 0x2040 > addresses (where your text section
>>> is loaded to)? AFAIK, that's not the case. Spike's default machine
>>> only works with addresses >= 0x8000. 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 = 0x2040, LENGTH = 128M
> RAM : ORIGIN = 0x8000, 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 (0x) while reading from 0x8000effc
--
Regards, Denis Obrezkov
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
Hi Denis,
Does your board support any accesses to > 0x8000. 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 wrote:
> 2017-06-08 17:49 GMT+03:00 Denis Obrezkov :
>>
>> 2017-06-08 12:24 GMT+03:00 Denis Obrezkov :
>>>
>>> 2017-06-07 22:41 GMT+03:00 Hesham Almatary :
On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov
wrote:
> 2017-06-07 14:44 GMT+03:00 Sebastian Huber
> :
>>
>> 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 0x2040 > addresses (where your text section
is loaded to)? AFAIK, that's not the case. Spike's default machine
only works with addresses >= 0x8000. 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 = 0x2040, LENGTH = 128M
>> RAM : ORIGIN = 0x8000, 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 (0x) while reading from 0x8000effc
>
> --
> Regards, Denis Obrezkov
--
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
2017-06-09 1:52 GMT+03:00 Hesham Almatary :
> Hi Denis,
>
> Does your board support any accesses to > 0x8000. 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
> wrote:
> > 2017-06-08 17:49 GMT+03:00 Denis Obrezkov :
> >>
> >> 2017-06-08 12:24 GMT+03:00 Denis Obrezkov :
> >>>
> >>> 2017-06-07 22:41 GMT+03:00 Hesham Almatary :
>
> On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov <
> denisobrez...@gmail.com>
> wrote:
> > 2017-06-07 14:44 GMT+03:00 Sebastian Huber
> > :
> >>
> >> 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 0x2040 > addresses (where your text section
> is loaded to)? AFAIK, that's not the case. Spike's default machine
> only works with addresses >= 0x8000. 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 = 0x2040, LENGTH = 128M
> >> RAM : ORIGIN = 0x8000, 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 (0x) while reading from 0x8000effc
> >
> > --
> > Regards, Denis Obrezkov
>
>
>
> --
> Hesham
>
Yes, it definitely supports it, I've already done it.
0x8000 is the start of 64 KiB RAM, and 0x2000 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V interrupts
On 09/06/2017 09:09, Denis Obrezkov wrote: > > 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! > Some gdb simulators have target options, for example: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=sim/erc32/interf.c;h=45be1b37ac377ecc6bf7bef77ae69127d990ced3;hb=HEAD#l160 Maybe the amount of memory could be one? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
