Re: RSB Architecture request: aarch64, x86_64, risc-v

[Hesham Almatary]

Hi Chris,



On Mon, Jun 26, 2017 at 10:11 AM, Chris Johns  wrote:
> On 26/06/2017 10:03, Hesham Almatary wrote:
>>
>> I've already submitted a patch for riscv32 here [1].
>>
>
> Thanks. My reading of the thread there are some unresolved questions.
>
> What is the status?
>
Regarding FSF paperwork, I asked my employer about that. Shouldn't be
an issue for this patch as I fetch the patch from my personal GitHub
repo.

Sebastian, is any more work needed for this patch to be merged?

> Thanks
> Chris
>
>> [1] https://lists.rtems.org/pipermail/devel/2017-May/017951.html.
>
>
>



-- 
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB Architecture request: aarch64, x86_64, risc-v

[Chris Johns]

On 26/06/2017 10:03, Hesham Almatary wrote:
> 
> I've already submitted a patch for riscv32 here [1].
> 

Thanks. My reading of the thread there are some unresolved questions.

What is the status?

Thanks
Chris

> [1] https://lists.rtems.org/pipermail/devel/2017-May/017951.html.



___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB Architecture request: aarch64, x86_64, risc-v

[Hesham Almatary]

Hi Chris,

I've already submitted a patch for riscv32 here [1].

[1] https://lists.rtems.org/pipermail/devel/2017-May/017951.html.

Cheers,
Hesham

On Mon, Jun 26, 2017 at 9:57 AM, Chris Johns  wrote:
> Hello,
>
> I would like to add aarch64, x86_64, and risc-v to 4.12/rtems-all so these 
> tools
> are always built when regression testing tool set changes. This change makes
> sure the tools are in a suitable state for those looking to add support for
> these architectures.
>
> To add RISC-V I need the architecture added to the RSB. Could those working 
> with
> this architecture to please considering post patches to this list list for
> review that adds this architecture.
>
> Thanks
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RSB Architecture request: aarch64, x86_64, risc-v

[Chris Johns]

Hello,

I would like to add aarch64, x86_64, and risc-v to 4.12/rtems-all so these tools
are always built when regression testing tool set changes. This change makes
sure the tools are in a suitable state for those looking to add support for
these architectures.

To add RISC-V I need the architecture added to the RSB. Could those working with
this architecture to please considering post patches to this list list for
review that adds this architecture.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V BSP: a clock driver

[Hesham Almatary]

On Sun, Jun 25, 2017 at 9:13 PM, Denis Obrezkov  wrote:
> 2017-06-25 13:04 GMT+02:00 Hesham Almatary :
>>
>> Hi Denis,
>>
>> Good to know you're making progress this far. There's no clock driver for
>> Spike BSP (the one my port is based on), it just used simulated tick. You'll
>> have to implement both console and click driver for your board. I'd suggest
>> you start with the console driver.
>>
>> Cheers,
>> Hesham
>>
>> On Sun, 25 Jun 2017 at 8:49 pm, Denis Obrezkov 
>> wrote:
>>>
>>> Hello all,
>>> I was able to proceed till the rtems_io_initialize function,
>>> so it seems to me that now I need to initialize a clock driver.
>>>
>>> I tried to find the current implementation of the driver in RISC-V BSP,
>>> but wasn't able to do it. Hesham, could you clarify the current state of
>>> the clock driver in the BSP?
>>>
>>> --
>>> Regards, Denis Obrezkov
>>
>> --
>> Hesham
>
>
> Could you expand, how it works? I have read a RTEMS Driver Manual and found
> there some information
> about drivers initialization, but I can't find in your BSP any IRQ handlers
> or clock initialization routine
> (in the manual it is written that a simple tick driver also needs some
> initialization )
>
Simulated clock driver [1] is architecture-independent i.e. it doesn't
need any IRQ or init handling. It's provided by RTEMS. You'll have to
write your init code and IRQ handling for both UART and Clock drivers
for HiFive.

[1] 
https://github.com/heshamelmatary/rtems-riscv/blob/priv-1.10/c/src/lib/libbsp/riscv32/riscv_generic/Makefile.am#L70
>
> --
> Regards, Denis Obrezkov



-- 
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V/HiFive memory limitations

[Joel Sherrill]

That doesn't appear to do much more than clear the bss. So no hints on more
to do there. The atexit() call and init/fini are handled by RTEMS in
portable code.

On Jun 25, 2017 6:24 AM, "Denis Obrezkov"  wrote:

> 2017-06-25 2:50 GMT+02:00 Denis Obrezkov :
>
>> 2017-06-25 2:15 GMT+02:00 Joel Sherrill :
>>
>>> They are supposed to use the installed linkcmds.
>>>
>>> On Jun 24, 2017 6:04 PM, "Denis Obrezkov" 
>>> wrote:
>>>
 2017-06-23 21:03 GMT+02:00 Denis Obrezkov :

> 2017-06-23 20:16 GMT+02:00 Denis Obrezkov :
>
>> 2017-06-23 16:39 GMT+02:00 Joel Sherrill :
>>
>>>
>>>
>>> On Jun 23, 2017 9:29 AM, "Gedare Bloom"  wrote:
>>>
>>> On Thu, Jun 22, 2017 at 8:32 PM, Denis Obrezkov <
>>> denisobrez...@gmail.com> wrote:
>>> >> Ok, then I will try to adapt the default linkcmd file today.
>>> >>
>>> >> --
>>> >> Regards, Denis Obrezkov
>>> >
>>> >
>>> > Hello all,
>>> > It seems that data section wasn't copied from ROM, so I've added
>>> the
>>> > initialization code
>>> > and now I have a proper value. Thus, I can proceed further to new
>>> errors.
>>> >
>>> > I haven't started to develop new linkcmd file, general for the
>>> architecture
>>> > + specific
>>> > for the BSP. Should I? Hesham?
>>> >
>>> You may want to just get it working first, and then refactor the
>>> linkcmds.
>>>
>>>
>>> +1 just make sure it is working when you start doing this. :)
>>>
>>>
>>> > Also, I have a question:
>>> > there is a section called 'rwbarrier' and it is placed in data.
>>> Should it be
>>> > also initialized?
>>> > (copied from rom)
>>> Everything up to the bss probably should be copied from ROM.
>>>
>>>
>>> Agreed. Is there a crt0 in libgloss for this architecture to check
>>> against?
>>>
>>> Just remember that the order and layout of sections may have
>>> implicit ties to the code in the startup.
>>>
>>>
>>> > And is it possible to decrease a required memory amount by
>>> restricting a
>>> > user to C language usage?
>>> > (no C++ sections in linkcmd)
>>> >
>>> I don't think so. They shouldn't really be having an impact anyway
>>> except for C++ applications.
>>>
>>>
>>> All you end up with is a loop to iterate over the list of empty
>>> global constructors.
>>>
>>>
>>> >
>>> > --
>>> > Regards, Denis Obrezkov
>>> >
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>>> I have a little question: is there any connection between RTEMS
 linker files
 and example-v2 applications' linker files?
 I think I have a similar mistake there: .data section is not
 initialized.



 --
 Regards, Denis Obrezkov

>>> Ok, I will investigate this and libgloss question.
>>
>> Since, I was a bit lazy, I moved the low_ticker example into the rtems
>> testsuite folder and built it
>> Now, I have no mistakes with uninitialized data section and I was able to
>> proceed till the rtems_io_initialize function.
>>
>> --
>> Regards, Denis Obrezkov
>>
> There is a crt0.s for RISC-V architecture.
> https://github.com/riscv/riscv-newlib/blob/riscv-
> newlib-2.5.0/libgloss/riscv/crt0.S
>
>
> --
> Regards, Denis Obrezkov
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V/HiFive memory limitations

[Denis Obrezkov]

2017-06-25 2:50 GMT+02:00 Denis Obrezkov :

> 2017-06-25 2:15 GMT+02:00 Joel Sherrill :
>
>> They are supposed to use the installed linkcmds.
>>
>> On Jun 24, 2017 6:04 PM, "Denis Obrezkov" 
>> wrote:
>>
>>> 2017-06-23 21:03 GMT+02:00 Denis Obrezkov :
>>>
 2017-06-23 20:16 GMT+02:00 Denis Obrezkov :

> 2017-06-23 16:39 GMT+02:00 Joel Sherrill :
>
>>
>>
>> On Jun 23, 2017 9:29 AM, "Gedare Bloom"  wrote:
>>
>> On Thu, Jun 22, 2017 at 8:32 PM, Denis Obrezkov <
>> denisobrez...@gmail.com> wrote:
>> >> Ok, then I will try to adapt the default linkcmd file today.
>> >>
>> >> --
>> >> Regards, Denis Obrezkov
>> >
>> >
>> > Hello all,
>> > It seems that data section wasn't copied from ROM, so I've added the
>> > initialization code
>> > and now I have a proper value. Thus, I can proceed further to new
>> errors.
>> >
>> > I haven't started to develop new linkcmd file, general for the
>> architecture
>> > + specific
>> > for the BSP. Should I? Hesham?
>> >
>> You may want to just get it working first, and then refactor the
>> linkcmds.
>>
>>
>> +1 just make sure it is working when you start doing this. :)
>>
>>
>> > Also, I have a question:
>> > there is a section called 'rwbarrier' and it is placed in data.
>> Should it be
>> > also initialized?
>> > (copied from rom)
>> Everything up to the bss probably should be copied from ROM.
>>
>>
>> Agreed. Is there a crt0 in libgloss for this architecture to check
>> against?
>>
>> Just remember that the order and layout of sections may have implicit
>> ties to the code in the startup.
>>
>>
>> > And is it possible to decrease a required memory amount by
>> restricting a
>> > user to C language usage?
>> > (no C++ sections in linkcmd)
>> >
>> I don't think so. They shouldn't really be having an impact anyway
>> except for C++ applications.
>>
>>
>> All you end up with is a loop to iterate over the list of empty
>> global constructors.
>>
>>
>> >
>> > --
>> > Regards, Denis Obrezkov
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> I have a little question: is there any connection between RTEMS
>>> linker files
>>> and example-v2 applications' linker files?
>>> I think I have a similar mistake there: .data section is not initialized.
>>>
>>>
>>>
>>> --
>>> Regards, Denis Obrezkov
>>>
>> Ok, I will investigate this and libgloss question.
>
> Since, I was a bit lazy, I moved the low_ticker example into the rtems
> testsuite folder and built it
> Now, I have no mistakes with uninitialized data section and I was able to
> proceed till the rtems_io_initialize function.
>
> --
> Regards, Denis Obrezkov
>
There is a crt0.s for RISC-V architecture.
https://github.com/riscv/riscv-newlib/blob/riscv-newlib-2.5.0/libgloss/riscv/crt0.S


-- 
Regards, Denis Obrezkov
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V BSP: a clock driver

[Hesham Almatary]

Hi Denis,

Good to know you're making progress this far. There's no clock driver for
Spike BSP (the one my port is based on), it just used simulated tick.
You'll have to implement both console and click driver for your board. I'd
suggest you start with the console driver.

Cheers,
Hesham

On Sun, 25 Jun 2017 at 8:49 pm, Denis Obrezkov 
wrote:

> Hello all,
> I was able to proceed till the rtems_io_initialize function,
> so it seems to me that now I need to initialize a clock driver.
>
> I tried to find the current implementation of the driver in RISC-V BSP,
> but wasn't able to do it. Hesham, could you clarify the current state of
> the clock driver in the BSP?
>
> --
> Regards, Denis Obrezkov
>
-- 
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RISC-V BSP: a clock driver

[Denis Obrezkov]

Hello all,
I was able to proceed till the rtems_io_initialize function,
so it seems to me that now I need to initialize a clock driver.

I tried to find the current implementation of the driver in RISC-V BSP,
but wasn't able to do it. Hesham, could you clarify the current state of
the clock driver in the BSP?

-- 
Regards, Denis Obrezkov
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel