Discussion:
sopc2dts with altera example
Erik Lehmann
2011-09-21 18:29:50 UTC
Permalink
Hi,


I just started with the new devicetree stuff but my main goal is to convert my old sopc design into the new qsys and update my linux2.6 nommu to the new linux3.0 kernel also without mmu. I installed Quartus 11 and thought it might be a good idea to start with a small sample project to test everything and to minimize problems. So I thought using an Altera example already updated to qsys might be a good thing to do. So I downladed niosii-ethernet-standard-3c25.zip (http://www.altera.com/support/examples/nios2/exm-net-std-de.html) and generated the qsys. Next step was to update my GIT branches und recompiled the toolchain. I also got sopc2dts and compiled it successfully (in linux). Because I use a VirtualBox linux machine (without GUI) on Windows I thought it would be great to use sopc2dts with GUI under Windows through a shared folder. So I wrote a small batch file that starts the compiled sopc2dts with gui. I attached it because someone else may find it useful (could be added to git too).
So I loaded the eth_std_main_system.qsys in sopc2dts but some modules seam to be missing both connected to the flash module:

Name: "flash_tristate_bridge" Description: "altera_tristate_conduit_bridge"
Name: "ext_flash" Description: "altera_generic_tristate_controller"

How do I add the components to the sopc2dts library and what information is necessary?

Maybe this design could be used as example in the wiki to illustrate the whole process. Because, I couldn't find any example showing the sopc2dts generation and some uClinux settings. What do you think?

Kind regards
Erik
Walter Goossens
2011-09-21 19:28:56 UTC
Permalink
Hi Erik,

when using qsys designs with sopc2dts, it's best to use the sopcinfo
file instead of the qsys file. There is some support for parsing qsys
files directly but some info (especially the ranges of components) is
not included in the qsys file and thus the resulting dts is not quite
usable. I guess that could be better documented...

On to the real problem...
When switching to qsys altera completely reworked the tristate stuff.
Works nicely, but is kind of a pain for sopc2dts to figure out.
I have postponed looking into that but I guess the time has come... You
don't have to try to add it to the library because the whole
tristate-qsys stuff isn't supported yet by sopc2dts. I'll keep you posted.

Walter
Post by Erik Lehmann
Hi,
I just started with the new devicetree stuff but my main goal is to convert my old sopc design into the new qsys and update my linux2.6 nommu to the new linux3.0 kernel also without mmu. I installed Quartus 11 and thought it might be a good idea to start with a small sample project to test everything and to minimize problems. So I thought using an Altera example already updated to qsys might be a good thing to do. So I downladed niosii-ethernet-standard-3c25.zip (http://www.altera.com/support/examples/nios2/exm-net-std-de.html) and generated the qsys. Next step was to update my GIT branches und recompiled the toolchain. I also got sopc2dts and compiled it successfully (in linux). Because I use a VirtualBox linux machine (without GUI) on Windows I thought it would be great to use sopc2dts
with GUI under Windows through a shared folder. So I wrote a small batch file that starts the compiled sopc2dts with gui. I attached it because someone else may find it useful (could be add
ed to git too).
Post by Erik Lehmann
Name: "flash_tristate_bridge" Description: "altera_tristate_conduit_bridge"
Name: "ext_flash" Description: "altera_generic_tristate_controller"
How do I add the components to the sopc2dts library and what information is necessary?
Maybe this design could be used as example in the wiki to illustrate the whole process. Because, I couldn't find any example showing the sopc2dts generation and some uClinux settings. What do you think?
Kind regards
Erik
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
Erik Lehmann
2011-09-22 08:35:27 UTC
Permalink
Hi,

First of all, thank's for the clarification!
when using qsys designs with sopc2dts, it's best to use the sopcinfo file instead of the qsys file. There is some support for parsing qsys files directly but some info (especially the ranges of components) is not included in the qsys file and thus the resulting dts is not quite usable. I guess that could be better documented…
Because you said it would be better to use the sopcinfo file instead of the qsys file I tried with the mentioned example. Tristate stuff didn't work but that's no surprise but sopc2dts seams to have trouble working with "subsystems" which were introduced with QSYS. I get class unknown warnings and the TSEMonolithic failed to find SGDMA RX and TX. But on the other hand a TSE mac is added in Boardinfo. The generated DTS doesn't look right because only the missing subsystems show up.
On to the real problem...
When switching to qsys altera completely reworked the tristate stuff. Works nicely, but is kind of a pain for sopc2dts to figure out.
I have postponed looking into that but I guess the time has come... You don't have to try to add it to the library because the whole tristate-qsys stuff isn't supported yet by sopc2dts. I'll keep you posted.
Okay, is there any thing I can help with?

Kind regards
Erik
Post by Erik Lehmann
Hi,
I just started with the new devicetree stuff but my main goal is to convert my old sopc design into the new qsys and update my linux2.6 nommu to the new linux3.0 kernel also without mmu. I installed Quartus 11 and thought it might be a good idea to start with a small sample project to test everything and to minimize problems. So I thought using an Altera example already updated to qsys might be a good thing to do. So I downladed niosii-ethernet-standard-3c25.zip (http://www.altera.com/support/examples/nios2/exm-net-std-de.html) and generated the qsys. Next step was to update my GIT branches und recompiled the toolchain. I also got sopc2dts and compiled it successfully (in linux). Because I use a VirtualBox linux machine (without GUI) on Windows I thought it would be great to use sopc2dts with GUI under Windows through a shared folder. So I wrote a small batch file that starts the compiled sopc2dts with gui. I attached it because someone else may find it useful (could be add
ed to git too).
Post by Erik Lehmann
Name: "flash_tristate_bridge" Description: "altera_tristate_conduit_bridge"
Name: "ext_flash" Description: "altera_generic_tristate_controller"
How do I add the components to the sopc2dts library and what information is necessary?
Maybe this design could be used as example in the wiki to illustrate the whole process. Because, I couldn't find any example showing the sopc2dts generation and some uClinux settings. What do you think?
Kind regards
Erik
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
W.A. GOOSSENS
2011-09-22 08:59:18 UTC
Permalink
Post by Erik Lehmann
Hi,
First of all, thank's for the clarification!
when using qsys designs with sopc2dts, it's best to use the sopcinfo file instead of the qsys file. There is some support for parsing qsys files directly but some info (especially the ranges of components) is not included in the qsys file and thus the resulting dts is not quite usable. I guess that could be better documented…
Because you said it would be better to use the sopcinfo file instead of the qsys file I tried with the mentioned example. Tristate stuff didn't work but that's no surprise but sopc2dts seams to have trouble working with "subsystems" which were introduced with QSYS. I get class unknown warnings and the TSEMonolithic failed to find SGDMA RX and TX. But on the other hand a TSE mac is added in Boardinfo. The generated DTS doesn't look right because only the missing subsystems show up.
The sopcinfo file is a flattened representation of the qsys system. So subsystems are not really an issue (except maybe that you get a few extra bridges).
Post by Erik Lehmann
On to the real problem...
When switching to qsys altera completely reworked the tristate stuff. Works nicely, but is kind of a pain for sopc2dts to figure out.
I have postponed looking into that but I guess the time has come... You don't have to try to add it to the library because the whole tristate-qsys stuff isn't supported yet by sopc2dts. I'll keep you posted.
Okay, is there any thing I can help with?
Be patient ;) I'm working on it right now. I'll download the example design as well to test with it.
Post by Erik Lehmann
Kind regards
Erik
Post by Erik Lehmann
Hi,
I just started with the new devicetree stuff but my main goal is to convert my old sopc design into the new qsys and update my linux2.6 nommu to the new linux3.0 kernel also without mmu. I installed Quartus 11 and thought it might be a good idea to start with a small sample project to test everything and to minimize problems. So I thought using an Altera example already updated to qsys might be a good thing to do. So I downladed niosii-ethernet-standard-3c25.zip (http://www.altera.com/support/examples/nios2/exm-net-std-de.html) and generated the qsys. Next step was to update my GIT branches und recompiled the toolchain. I also got sopc2dts and compiled it successfully (in linux). Because I use a VirtualBox linux machine (without GUI) on Windows I thought it would be great to use sopc2dts with GUI under Windows through a shared folder. So I wrote a small batch file that starts the compiled sopc2dts with gui. I attached it because someone else may find it useful (could be add
ed to git too).
Post by Erik Lehmann
Name: "flash_tristate_bridge"          Description: "altera_tristate_conduit_bridge"
Name: "ext_flash"                          Description: "altera_generic_tristate_controller"
How do I add the components to the sopc2dts library and what information is necessary?
Maybe this design could be used as example in the wiki to illustrate the whole process. Because, I couldn't find any example showing the sopc2dts generation and some uClinux settings. What do you think?
Kind regards
Erik
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
W.A. GOOSSENS
2011-09-22 12:05:18 UTC
Permalink
Hmm good news and bad news.

The good news is that I now seem to be able to parse the Generic Tristate Controller core (a bit). Could you pull sopc2dts and give it a try?
The bad news is that the system indeed makes a mess of the hierarchical stuff. I'll have to look into that.

Walter
Post by W.A. GOOSSENS
Post by Erik Lehmann
Hi,
First of all, thank's for the clarification!
when using qsys designs with sopc2dts, it's best to use the sopcinfo file instead of the qsys file. There is some support for parsing qsys files directly but some info (especially the ranges of components) is not included in the qsys file and thus the resulting dts is not quite usable. I guess that could be better documented…
Because you said it would be better to use the sopcinfo file instead of the qsys file I tried with the mentioned example. Tristate stuff didn't work but that's no surprise but sopc2dts seams to have trouble working with "subsystems" which were introduced with QSYS. I get class unknown warnings and the TSEMonolithic failed to find SGDMA RX and TX. But on the other hand a TSE mac is added in Boardinfo. The generated DTS doesn't look right because only the missing subsystems show up.
The sopcinfo file is a flattened representation of the qsys system. So subsystems are not really an issue (except maybe that you get a few extra bridges).
Post by Erik Lehmann
On to the real problem...
When switching to qsys altera completely reworked the tristate stuff. Works nicely, but is kind of a pain for sopc2dts to figure out.
I have postponed looking into that but I guess the time has come... You don't have to try to add it to the library because the whole tristate-qsys stuff isn't supported yet by sopc2dts. I'll keep you posted.
Okay, is there any thing I can help with?
Be patient ;) I'm working on it right now. I'll download the example design as well to test with it.
Post by Erik Lehmann
Kind regards
Erik
Post by Erik Lehmann
Hi,
I just started with the new devicetree stuff but my main goal is to convert my old sopc design into the new qsys and update my linux2.6 nommu to the new linux3.0 kernel also without mmu. I installed Quartus 11 and thought it might be a good idea to start with a small sample project to test everything and to minimize problems. So I thought using an Altera example already updated to qsys might be a good thing to do. So I downladed niosii-ethernet-standard-3c25.zip (http://www.altera.com/support/examples/nios2/exm-net-std-de.html) and generated the qsys. Next step was to update my GIT branches und recompiled the toolchain. I also got sopc2dts and compiled it successfully (in linux). Because I use a VirtualBox linux machine (without GUI) on Windows I thought it would be great to use sopc2dts with GUI under Windows through a shared folder. So I wrote a small batch file that starts the compiled sopc2dts with gui. I attached it because someone else may find it useful (could be add
ed to git too).
Post by Erik Lehmann
Name: "flash_tristate_bridge"          Description: "altera_tristate_conduit_bridge"
Name: "ext_flash"                          Description: "altera_generic_tristate_controller"
How do I add the components to the sopc2dts library and what information is necessary?
Maybe this design could be used as example in the wiki to illustrate the whole process. Because, I couldn't find any example showing the sopc2dts generation and some uClinux settings. What do you think?
Kind regards
Erik
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
_______________________________________________
Nios2-dev mailing list
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
Erik Lehmann
2011-09-22 16:43:48 UTC
Permalink
Hi,

I checked and I see the ext_flash module now, also in the generated DTS file. Great work! The tristate bridge (altera_tristate_conduit_bridge) is still missing, right?
It seams that sopc2dts is not identifying subsystems and treats them as regular modules which can't indeed be found. As result the parser quit.

I found in the sopcinfo file for example:

<plugin>
<instanceCount>1</instanceCount>
<name>ethernet_system</name>
<type>com.altera.entityinterfaces.IElementClass</type>
<subtype>com.altera.entityinterfaces.IModule</subtype>
<displayName>ethernet_system</displayName>
<version>1.0</version>
</plugin>

Where "name" and "displayName" appear to be equal if the plugin is a QSYS subsystem. Maybe that can be used as reference for subsystems? Or is there another indicator?

Kind regards
Erik
Post by W.A. GOOSSENS
Hmm good news and bad news.
The good news is that I now seem to be able to parse the Generic Tristate Controller core (a bit). Could you pull sopc2dts and give it a try?
The bad news is that the system indeed makes a mess of the hierarchical stuff. I'll have to look into that.
Walter
Post by W.A. GOOSSENS
Post by Erik Lehmann
Hi,
First of all, thank's for the clarification!
when using qsys designs with sopc2dts, it's best to use the sopcinfo file instead of the qsys file. There is some support for parsing qsys files directly but some info (especially the ranges of components) is not included in the qsys file and thus the resulting dts is not quite usable. I guess that could be better documented…
Because you said it would be better to use the sopcinfo file instead of the qsys file I tried with the mentioned example. Tristate stuff didn't work but that's no surprise but sopc2dts seams to have trouble working with "subsystems" which were introduced with QSYS. I get class unknown warnings and the TSEMonolithic failed to find SGDMA RX and TX. But on the other hand a TSE mac is added in Boardinfo. The generated DTS doesn't look right because only the missing subsystems show up.
The sopcinfo file is a flattened representation of the qsys system. So subsystems are not really an issue (except maybe that you get a few extra bridges).
Post by Erik Lehmann
On to the real problem...
When switching to qsys altera completely reworked the tristate stuff. Works nicely, but is kind of a pain for sopc2dts to figure out.
I have postponed looking into that but I guess the time has come... You don't have to try to add it to the library because the whole tristate-qsys stuff isn't supported yet by sopc2dts. I'll keep you posted.
Okay, is there any thing I can help with?
Be patient ;) I'm working on it right now. I'll download the example design as well to test with it.
Post by Erik Lehmann
Kind regards
Erik
Post by Erik Lehmann
Hi,
I just started with the new devicetree stuff but my main goal is to convert my old sopc design into the new qsys and update my linux2.6 nommu to the new linux3.0 kernel also without mmu. I installed Quartus 11 and thought it might be a good idea to start with a small sample project to test everything and to minimize problems. So I thought using an Altera example already updated to qsys might be a good thing to do. So I downladed niosii-ethernet-standard-3c25.zip (http://www.altera.com/support/examples/nios2/exm-net-std-de.html) and generated the qsys. Next step was to update my GIT branches und recompiled the toolchain. I also got sopc2dts and compiled it successfully (in linux). Because I use a VirtualBox linux machine (without GUI) on Windows I thought it would be great to use sopc2dts with GUI under Windows through a shared folder. So I wrote a small batch file that starts the compiled sopc2dts with gui. I attached it because someone else may find it useful (could be add
ed to git too).
Post by Erik Lehmann
Name: "flash_tristate_bridge" Description: "altera_tristate_conduit_bridge"
Name: "ext_flash" Description: "altera_generic_tristate_controller"
How do I add the components to the sopc2dts library and what information is necessary?
Maybe this design could be used as example in the wiki to illustrate the whole process. Because, I couldn't find any example showing the sopc2dts generation and some uClinux settings. What do you think?
Kind regards
Erik
Loading...