<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jul 5, 2017 7:22 AM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Tue, Jul 4, 2017 at 7:47 AM, Denis Obrezkov <<a href="mailto:denisobrezkov@gmail.com">denisobrezkov@gmail.com</a>> wrote:<br>
> 2017-07-03 21:17 GMT+02:00 Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>>:<br>
>><br>
>><br>
>><br>
>> On Jul 3, 2017 12:45 PM, "Denis Obrezkov" <<a href="mailto:denisobrezkov@gmail.com">denisobrezkov@gmail.com</a>> wrote:<br>
>><br>
>> 2017-07-03 19:09 GMT+02:00 Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>>:<br>
>>><br>
>>><br>
>>><br>
>>> On Jul 3, 2017 11:49 AM, "Denis Obrezkov" <<a href="mailto:denisobrezkov@gmail.com">denisobrezkov@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> 2017-07-03 7:43 GMT+02:00 Hesham Almatary <<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>>:<br>
>>>><br>
>>>> On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov <<a href="mailto:denisobrezkov@gmail.com">denisobrezkov@gmail.com</a>><br>
>>>> wrote:<br>
>>>> > 2017-07-03 4:59 GMT+02:00 Hesham Almatary <<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>>:<br>
>>>> >><br>
>>>> >> You can have a look at riscv-pk [1] as a RISC-V reference how to<br>
>>>> >> handle interrupts. RTEMS-wise, you can look at or1k and ARM code and<br>
>>>> >> how the platform-dependent interrupt handling code is linked to<br>
>>>> >> platform-independent one.<br>
>>>> >><br>
>>>> >> mcause value can be used as an index to a software vector table that<br>
>>>> >> you<br>
>>>> >> set up.<br>
>>>> >><br>
>>>> >> Why do you need software interrupts? GSoC-wise, I thought the plan<br>
>>>> >> was<br>
>>>> >> to develop UART/Console driver (which doesn't need interrupts), and<br>
>>>> >> use simulated ticker, as a first step. Then it will be easier to<br>
>>>> >> debug/proceed from there with interrupt handling code.<br>
>>>> ><br>
>>>> > I thought, I have to implement an interrupt console driver. Okay, then<br>
>>>> > I am<br>
>>>> > going to<br>
>>>> > investigate a simulated ticker.<br>
>>>> Yeah that can be done in later stages, for optimisation purposes. But<br>
>>>> I think it's easier to implement it in polling mode first, just to get<br>
>>>> things working, then you can easily move to interrupt-based<br>
>>>> implementation. For example, if you've a polling console driver, you<br>
>>>> can debug using printk, when developing the clock driver. Once you get<br>
>>>> the clock driver working, you will have a more mature code for<br>
>>>> interrupt handling, which enables you to very easily implement<br>
>>>> interrupt-based UART driver.<br>
>>>> > --<br>
>>>> > Regards, Denis Obrezkov<br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Hesham<br>
>>><br>
>>><br>
>>> It seems that vectored interrupts aren't available in FE310 SoC.<br>
>>> Thus, I will work with mcause register.<br>
>>> As for now, I want to:<br>
>>> * add local interrupt handlers<br>
>>> * add init code for counters initializtion (since we want to set up a<br>
>>> baudrate)<br>
>>> * implement a dummy clock driver<br>
>>><br>
>>><br>
>>> This is easy and just requires one line in the BSP Makefile.am and an<br>
>>> include in the .tcfg file to skip tests known to fail. See either the shsim<br>
>>> or v850sim BSPs based on gdb for examples.<br>
>>><br>
>>> It also lets you have all the tests running so you can add your target to<br>
>>> RTEMS tester. :)<br>
>>><br>
>>> * implement a polling uart<br>
>>><br>
>>><br>
>>> Personally I would do this as soon as possible and get printk working.<br>
>>> Very helpful and needed to run the tests with simulated clock tick with the<br>
>>> polled driver.<br>
>>><br>
>>> The counter is only needed for math on the baud rate I would guess.<br>
>>><br>
>>> * figure out how interrupts are handled in RTEMS<br>
>>> * implement global interrupt handlers<br>
>>> * implement a clock driver<br>
>>> * implement an interrupt-mode uart driver.<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Regards, Denis Obrezkov<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
>>><br>
>>><br>
>> Ok, I will try to make a uart driver as soon as possible.<br>
>> I had some issues with dummy_clockdriver, I think there was a mistake,<br>
>> that an address of clock initialization function was wrong, so, I will<br>
>> investigate it tomorrow.<br>
>> Also, I have a problem, as I mentioned earlier, that the minimum example<br>
>> finished with the error ''INTERNAL_ERROR_THREAD_<wbr>EXITTED".<br>
>><br>
>><br>
>> That is probably the correct behavior. It is not intended to be executed.<br>
>> It is just an example of how to strip down a configuration to get a program<br>
>> running. The Init thread is completely empty as I recall so it would return<br>
>> and fail like this.<br>
>><br>
>> I would move on to hello. Use the existing sim clock driver and the polled<br>
>> console driver framework until this much all works. See how the two BSPs I<br>
>> mentioned earlier do things. That will minimize the amount of code you have<br>
>> to write until you can focus on the interrupts.<br>
>><br>
>> Also.. hello world is the first step. Usually adding a delay/sleep call to<br>
>> that or using ticker/sp01 is how to debug a clock driver and interrupt<br>
>> driven console driver.<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Regards, Denis Obrezkov<br>
>><br>
>><br>
><br>
> I found out, that I have an exception "Illegal instruction", I get this<br>
> exception after I step in:<br>
> 0x204007c2 in Clock_initialize (major=0, minor=0, pargp=0x0)<br>
>     at<br>
> /home/reprofy/Projects/riscv/<wbr>rtems/development/rtems/<wbr>kernel/rtems-riscv/c/src/lib/<wbr>libbsp/riscv32/hifive1/../../<wbr>shared/clockdrv_shell.h:182<br>
><br>
><br>
> from<br>
> 0x2040ef06 in rtems_io_initialize (major=0, minor=0, argument=0x0)<br>
>     at<br>
> /home/reprofy/Projects/riscv/<wbr>rtems/development/rtems/<wbr>kernel/rtems-riscv/c/src/../..<wbr>/cpukit/sapi/src/ioinitialize.<wbr>c:36<br>
><br>
> But this is a part of my disas output for 0x204007c2 address:<br>
>    0x204007b8 <+16>:    sw      a2,-44(s0)<br>
>    0x204007bc <+20>:    lui     a5,0x80001<br>
>    0x204007c0 <+24>:    sw      zero,-1576(a5) # 0x800009d8<br>
>    0x204007c4 <+28>:    sw      zero,-20(s0)<br>
>    0x204007c8 <+32>:    lui     a5,0x80001<br>
>    0x204007cc <+36>:    li      a4,1<br>
>    0x204007ce <+38>:    sb      a4,-1580(a5) # 0x800009d4<br>
><br>
> How is it possible?<br>
><br>
</div>It's suspicious that your EPC is 204007c2 but that does not correspond<br>
with an instruction in your disassembly.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Good spot Gedare. Could it be a math error in the assembly before you get near here? Perhaps computing the offset I to an array of vectors wrong and adding it to the base address of the handler?</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="elided-text"><br>
> --<br>
> Regards, Denis Obrezkov<br>
><br>
> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></blockquote></div><br></div></div></div>