Risc-v memory issue

[Joel Sherrill]

On Jun 12, 2017 3:10 PM, "Hesham Almatary" <heshamelmatary at gmail.com> wrote:



On Tue, Jun 13, 2017 at 2:09 AM, Denis Obrezkov <denisobrezkov at gmail.com>
wrote:
> Hello all,
>
> I was able to debug my program on top of HiFive1 board.
> I found out that I can't use next and until commands from gdb,
> they just hang gdb.
> And now I have a problem, this is my backtrace:
>
> #0  0x2041d728 in _User_extensions_Iterate (arg=0x80002eb8,
> visitor=0x2041d64e <_User_extensions_Fatal_visitor>,
> direction=CHAIN_ITERATOR_FORWARD)
>     at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/../../cpukit/score/src/userextiterate.c:155
> #1  0x20410ed4 in _User_extensions_Fatal (source=INTERNAL_ERROR_CORE,
> error=2) at
> ../../cpukit/../../../hifive1/lib/include/rtems/score/userextimpl.h:307
> #2  0x20410ef8 in _Terminate (the_source=INTERNAL_ERROR_CORE, the_error=2)
> at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/../../cpukit/score/src/interr.c:35
> #3  0x20410f40 in _Internal_error
> (core_error=INTERNAL_ERROR_TOO_LITTLE_WORKSPACE) at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/../../cpukit/score/src/interr.c:44
> #4  0x2041e484 in _Workspace_Handler_initialization (areas=0x80002f78,
> area_count=1, extend=0x0) at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/../../cpukit/score/src/wkspace.c:123
> #5  0x2040031c in bsp_work_area_initialize_default (area_begin=0x80001d58,
> area_size=8872) at
> ../../../../../.././hifive1/lib/include/bsp/bootcard.h:147
> #6  0x20400372 in bsp_work_area_initialize () at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/lib/libbsp/riscv32/hifive1/../../
shared/bspgetworkarea.c:61
> #7  0x2040f3ce in rtems_initialize_executive () at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/../../cpukit/sapi/src/exinit.c:95
> #8  0x204002cc in boot_card (cmdline=0x0) at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/lib/libbsp/riscv32/hifive1/../../
shared/bootcard.c:76
> #9  0x20400064 in _end_clear_bss () at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
kernel/rtems-riscv/c/src/lib/libbsp/riscv32/hifive1/start/start.S:116
>
> So, I think I should increase a workspace.
> Now, I have some questions:
> I took Hesham's linker file for riscv-generic, and there were no stack
> space,
> I allocated 0x1000 for stack. Should I make it zero again, or should I
> decrease its size?
> what size for stack should be enough?

>                 /*
>                  * The stack section will occupy the remaining
> REGION_STACK region and may
>                  * contain the task stacks.  Depending on the region
> distribution this
>                  * section may be of zero size.
>                  */
>
This means that the stack_end address is starting at your very top address
space (i.e. 16KiB if you set your linker size to 16KiB). The stack grows
dynamically downwards, so it might overflow other sections (e.g. work,
heap, data, etc) if you don't have enough memory size to fit. You can try
to see how much size each section occupies (riscv32-rtems4.12-objdump -h
hello.exe), especially work space.


This is how the SPARC start up stack is done. If you aren't careful, this
may not match the assumption in the default method that carves up the
workspace.

You need to be careful that the memory regions don't overlap.




> And why there were no space for stack? is it possible to work without
stack
> allocated in
> linkcmd file?
> Can RTEMS work with a smaller workspace?
>
As far as I remember, 4KiB was the smallest I could allocate for workspace
to work (with Epiphany). As I suggested before, you might want to start
saving up memory by using the local instruction memory (on HiFive) and
compressed version of RISC-V ISA.


Is this a characteristic of this board or the architecture​ in general? I
had the impression that the RISC-V was quite general purpose and could
handle plenty of RAM even if some boards don't have much.



> --
> Regards, Denis Obrezkov



-- 
Hesha

_______________________________________________
devel mailing list
devel at rtems.org
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170613/6bf8abe4/attachment-0002.html>