ReconOs on Zybo

[Syam Sanal]

Greetings,

Introducing myself I am Syam Sanal, pursuing final year M.Tech in VLSI and Embedded Systems from SV. National Institute of Technology, Surat, India.

I have decided to do my thesis on reconfigurable computing and multi threading. I have decided to use ReconOs to implement it on Zed board. But Unfortunately, halfway the Zed Board available in our college department stopped working. I have the option to implement the ReconOs on Zybo board.

I kindly request you to help me in configuring Zybo board and ReconOS.

Thanking you,

Yours sincerely,

Syam Sanal

[Sebastian Meisner]

Hello Syam Sanal and welcome to ReconOS!

I had a look at the Zybo Board:
http://store.digilentinc.com/zybo-zynq-7000-arm-fpga-soc-trainer-board/

It seems to be very similar to the Zedboard, so porting ReconOS should be
feasible. The main difference seems to be a smaller programmable area.

I suggest you follow the default tutorial at
http://www.reconos.de/gettingstarted/tutorial/

If you get stuck, please report to us where you got stuck and what error
message you did encounter.

Kind regards,
Sebastian Meisner

> --
> You received this message because you are subscribed to the Google Groups
> "ReconOS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reconos+u...@googlegroups.com
> <mailto:reconos+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Syam Sanal]

Greetings,

As you suggested, I followed the ReconOS tutorial to implement ReconOS on Zybo board. I am getting some errors, which I was unable resolve. In fact, the errors I got on Zedboard was exactly the same. I request your help in the matter. 

[Christoph Rüthing]

Hi Syam,

 

for me that error looks like an issue with the initialization of the processing system, i.e. the ps7_init code. Have you just used the zedboard design as it is, or have you modified the generated edk project to fit the zybo board? Maybe you should try to adapt it and generate a new ps7_init by exporting the design to SDK (you will then get the ps7_init in the generated folder).

 

To test if this is really the problem and if you have solved it, you could try to access the ram manually by executing the following commands in xmd after turning the board on (with setting the jumpers to jtag boot):

-          connect arm hw

-          rst

-          source ps7_init.tcl

-          ps7_init

-          ps7_post_config

-          mrd <someaddr> 1

-          dow -data <datafile> <someaddr>

 

Yours,

Christoph

 

Von: Syam Sanal
Gesendet: Dienstag, 27. September 2016 17:45
An: ReconOS
Betreff: Re: [reconos] ReconOs on Zybo

 

Syam Sanal <syam....@gmail.com> hat am 27. September 2016 um 17:45 geschrieben:

To unsubscribe from this group and stop receiving emails from it, send an email to reconos+u...@googlegroups.com.

[Syam Sanal]

Greetings,

 I have implemented ReconOS on Zybo Board. The issue was regarding ps7_init. Also I used newer versions of linux kernel and u-boot, as the one in the tutorial doesn't have Zybo configuration files. I was able to run only software threads. Recently, I tried to built the ReconOS system again on Zybo Board. But I got an error message : "Loading kernel module". The problem is with inserting mreconos.ko module. I request your help regarding the issue.


Yours,

Syam Sanal

[Syam Sanal]

[chri...@muppetnet.net]

Hi Syam,

 

great that you got your board working. I also setup the zedboard with the newest linux kernel and also encountered the problem of not working hardware threads, i.e. the sort demo starts but newer gets an acknowledge back from the hardware thread. The problem here is, that the interrupt numbers changed in the newest kernel releases and, therefore, the hardcoded interrupts are no longer working. I’m currently working on updating some components and also want to fix that interrupt issue by integrating the ReconOS components correctly via the device tree. As a quick fix to this problem you can try to manually update the interrupt numbers in the driver (hopefully that works and we do not need further initialization performed when integrated into the device tree).  For the zedboard my fixed driver uses interrupts 164 (was 90 before, https://github.com/ReconOS/reconos/blob/develop/linux/driver/osif_intc.c#L53) and 165 (was 91 before), https://github.com/ReconOS/reconos/blob/develop/linux/driver/proc_control.c#L54). Maybe you can try this out. If it does not work we can think of integrating my changes partially so that at least the interrupts are working again.

 

Regarding your second problem I cannot give you any hints without further information. There might be many reasons why a kernel module cannot be inserted.

 

Yours,

Christoph

--

[Syam Sanal]

Greetings,

Thanks for the support. I have made the changes in interrupt numbers, but I am getting segmentation fault. I am attaching the screenshot too. I request your help to resolve the issue.

Thanks and Regards,

Syam Sanal

[Syam Sanal]

Greetings,

Thanks for the support. I have made the changes in interrupt numbers, but I am getting segmentation fault. I request your help to resolve the issue. I would like to integrate the changes you have mentioned in the previous post. Thank you.

[chri...@muppetnet.net]

Hi Syam,

 

it is a little bit hard to tell you what exactly went wrong in your case. For some reason there is a null pointer exception during clenaup of the module. However there should be no cleabup when you try to load the module. I believe you are loading the module using the reconos_init script, which first tries to remove any existing module.

 

Does the exception also occur when insmod the kernel module on a newly booted system. In that case during initialization something goes wrong and the kernel module tries to celanup all already requested resources. However , it should not cause a null pointer exception.

 

Did you do any further changes except the interrupt numbers? I checked what happens when the interrupt allocation fails but I don’t think that this error arises from there.

 

To get a little bit more output to tell you what exactly is going weong you might want to turn on some debugging output by defining the __printk macro in https://github.com/ReconOS/reconos/blob/develop/linux/driver/reconos.h

[Syam Sanal]

Yes, I am loading the module using reconos_init script. Infact, I am trying to insert the module on a newly booted system. I haven't made any changes except interrupt numbers. I have enabled both the __printk macro (screenshot attached). Is the error related to .dts file, since, there too are interrupt numbers. 

[Christoph Rüthing]

Hi Syam,

today I had some time to try everything out in my own setup. I also had troubles with just changing the interrupt numbers to the new ones, but with a slightly different error (Operation not permitted). Therefore, I implemented a quick fix to be no longer dependent on the hard-coded interrupt numbers but read them from the device tree. The fix is already commited to the current develop branch, you are also using as I belive. I also updated the Howto in https://github.com/ReconOS/reconos.github.io/blob/develop/gettingstarted/tutorial/index.md.

For me the fixed driver now works with the newest Linux kernel in the Xilinx repository. To use it, as also written in the commit message, you (and everyone else also) need to adjust the device tree used. I will write a separate mail on the mailing list for this, just that everyone knows about it. You can try this out and hopefully it also works for you. If not, just feel free to ask again.

Yours,
Christoph

[Syam Sanal]

Hello,

     Thanks for the support, but the system still waits for the acknowledgment from hardware threads. The software threads works as it is. I have made changes only to .dts file, created the .dtb file and loaded it to board along with already built u-boot and linux kernel. Is there any other changes I need to make? 

Thanks,

Syam Sanal

[Christoph Rüthing]

Hi Syam,

it should be fine to edit the device tree and use the old u-boot and linux binaries. However, you need to update your ReconOS repository and rebuild the ReconOS kernel module. Just to make sure, you are working with the develop branch, right? Does the loading of the kernel module shows any errors? You should enable the debug output as described earlier by enabling the __printk in https://github.com/ReconOS/reconos/blob/develop/linux/driver/reconos.h and enabling debug output in linux by echo 7 > /proc/sys/kernel/printk. Maybe you can send this output, it should look something like the following:

[reconos] initializing driver ...
[reconos-proc-control-STATIC] found device reconos_proc_control
[reconos-proc-control-STATIC] found memory at 0x6fe00000 with size 0x10000
[reconos] detected 2 HWTs
[reconos-proc-control] initializing driver ...
[reconos-proc-control] found device reconos_proc_control
[reconos-proc-control] found memory at 0x6fe00000 with size 0x10000
[reconos-proc-control] found interrupt 165
[reconos-proc-control] driver initialized successfully
[reconos-osif] initializing driver ...
[reconos-osif] found device reconos_osif_intc
[reconos-osif] found memory at 0x7b400000 with size 0x10000
[reconos-osif] found interrupt 164
[reconos-osif-intc] registered interrupt controller

I tested the current develop branch on a ZedBoard with the setup described in https://github.com/ReconOS/reconos.github.io/blob/develop/gettingstarted/tutorial/index.md and it works fine for me.

Yours,
Christoph

[Syam Sanal]

Hello,

I am using the master branch.

Thanks,

Syam Sanal

[Christoph Rüthing]

Hi Syam,

aha, that explains why it is not working for you. I would recommend to switch to the develop branch, since it has some major improvements compared to the master. However, if you want to stay with the master branch, I have commited a similar patch for the linux driver there. You can just update your repository and recompile the ReconOS kernel module. Furthermore, you need to adjust you deveice-tree for the correct version numbers, i.e. use 3.0 instead of 3.1.

amba: amba {
       reconos_osif: reconos_osif@75a00000 {
               compatible = "upb,reconos-osif-3.0";
               reg = <0x75a00000 0x10000>;
       };

       reconos_osif_intc: reconos_osif_intc@7b400000 {
               compatible = "upb,reconos-osif-intc-3.0";
               reg = <0x7b400000 0x10000>;
               interrup-parent = <&intc>;
               interrupts = <0 58 4>;
       };

       reconos_proc_control: reconos_proc_control@6fe00000 {
               compatible = "upb,reconos-control-3.0";
               reg = <0x6fe00000 0x10000>;
               interrupt-parent = <&intc>;
               interrupts = <0 59 4>;
       };
};

With my modifications, the sort demo should work again. I tested this with the up-to-date linux kernel on the ZedBoard and hopefully it works for you too.

Yours,
Christoph

[Syam Sanal]

Hi,

The hardware thread works now. Thanks for the support. 

Thanks and regards,

Syam Sanal