junyangliu

【转】如何解决目录改变时,Nios II project无法编译的问题? (SOC) (Nios II) (DE2-70)

0
阅读(2612)

Abstract
若我们从网络上下载范例程序,或者从书上的光盘将范例程序复制到硬盘时,只要是Quartus II版本正确,都可以正常地开启Quartus II project并且编译之,但Nios II project却常常虽然能开启,却无法正常编译,本文讨论其root cause并提出解决方式。

Introduction
使用环境:Windows XP SP3 + VirtualBox 4.1.2 + Quartus II 11.0

本文将讨论以下主题:

1.为什么会需要改变目录名称或目录位置?

2.改变目录名称或目录位置,在Nios II project会遇到什么问题?

3.Root cause与解决方法。

4.使用Blank Project方法所面临的问题。

1.为什么会需要改变目录名称或目录位置?

我们常会有各种理由会改变原来project的目录名称或目录位置:

1.为了管理方便,可能将原来在d:\project\的所有project移到e:\project\下

2.同事将project整个目录压缩给我,因为我并不知道该project放在同事计算机什么工作目录下,所以我将压缩文件解压缩到我自己的工作目录下

3.从网络上下载整包范例程序的压缩文件后,因为我并不知道原本范例程序所存放的目录,所以我将压缩文件解压缩到我自己的工作目录下

4.从书上光盘复制范例程序到硬盘,因为我并不知道原本范例程序所存放的目录,所以我将范例程序复制到我自己的工作目录下

5.新的project与旧的project类似,想从旧的project去做修改即可,开了一个新的目录,将旧的project所有档案复制到新的目录下

6.为了管理方便,想改变原本project的目录名称

以上的情形,若是纯粹Quartus II project,只要Quartus II版本正确,开启*.qpf档即可顺利开启,并且正常编译,唯一有问题的是Programmer的*.cdf文件可能因为路径不对无法写入,只是重新指定*.sof与*.pof的位置即可。

Quartus II的*.qpf project概念类似Visual C++ 6的*.dsw或者Visual Studio的*.sln,整个project内的档案是相对路径,所以改变项目名称或者改变目录位置都没有关系,只要档案相对位置没有改变,整个project就可以正常运作。

但是Nios II project就没这么单纯了!!

Nios II SBT是用Eclipse去改的,用的是Eclipse的workspace概念,很类似Visual Studio的*.sln概念,但又不完全一样。Eclipse允许你在一个workspace下,去管理多个project,workspace记住的是project的绝对路径,所以当你Nios II project目录名称改变,或者目录位置改变,该workspace自然就找不到了。

依照Eclipse workspace哲学的正规解法,此时你应该将目录改变的Nios II project重新Import到你的workspace。但事实上真的如此吗?

2.改变目录名称或目录位置,在Nios II project会遇到什么问题?

我们实际做个实验,如下图所示,原本DE2_70_SOPC_golden_mini是一个在Quartus II与Nios II SBT都完全正常的project。

clip_image001

我们现在将目录名称改变,从DE2_70_SOPC_golden_mini改成DE2_70_SOPC_golden_mini2

clip_image002

大家都知到改变目录名称或目录位置不会影响Quartus II project的开启与编译,所以就略过不讨论,现在将焦点放在Nois II project部分。

开启Nios II SBT,将workspace目录切换到新的目录DE2_70_SOPC_golden_mini2

clip_image003

开启后显示更改目录名称之前的2个project:hello_worldhello_world_bsp,由于现在目录名称已经改变,所以只能看到project名称,却完全无法开启。

clip_image004

由于2个project已经无法开启,我们将这2个project从workspace中删除之。

clip_image005

删除完后,整个workspace完全没有任何project。

clip_image006

根据Eclipse哲学的正规解法因为目录已经改变,我们必须将2project使用import的方式加载到新的workspace

clip_image007

由于之前是使用Nios II SBT产生makefile的project,所以在此选择Import Nios II Software Build Tools Project

clip_image008

首先将hello_world project import进来,值得注意的是:要将Clean project when importing打勾,也就是在import project完时,马上执行make clean,将之前所留下的object file全部清除。

clip_image009

import完成后,显示了以下的warning,告诉我们project想include旧的项目路径的目录,但因为目录名称改变,所以include失败。这是第1个问题。

clip_image010

接下继续import hello_world_bsp,也记得将Clean project when importing打勾。

clip_image011

import完成后,并没有显示任何错误讯息与warning。

clip_image012

若在hello_world_bsp执行Nios II –> Generate BSP,会出现以下错误讯息,表示找不到*.sopcinfo。这是第2个问题。

clip_image013

若在hello_world_bsp执行Nios II –> BSP Editor会出现以下错误讯息,表示找不到*.sopcinfo。这是第3个问题。

clip_image014

若实际Build App project(hello_world)与BSP project,虽然仍可出现*.elf与*.a,但会出现以下错误讯息,表示Makefile找不到*.sopcinfo。这是第4个问题。

clip_image015

clip_image016

总结以上实验,我们发现若改变目录名称或者目录位置,在Nios II project会出现以下4个问题:

1.App project(hello_world)会出现include path not found warning。
2.BSP project(hello_world_bsp)会无法执行Generate BSP。
3.BSP project(hello_world_bsp)会无法执行BSP Editor。
4.Build App project(hello_world)与BSP project(hello_world_bsp)会出现Makefile找不到SOPC File的warning。

3.Root cause与解决方法。

App project (hello_world)include path not found warningRoot cause

在hello_world的Properties的C/C++ General –> Paths and Symbols的GNC C与GNC C++,我们可以发现Include directories的目录错了,抓的都是修改前的目录名称,且这些目录名称还无法删除或者修改,因为这是Eclipse自动抓的,这是第1个问题的root cause。

clip_image017

clip_image018

App project (hello_world)include path not found warningSolution

Step 1App project (hello_world)properties

clip_image019

Step 2C/C++ Build –> Discovery OptionsCygwin C Compier,按下Clear清除目前所抓的include path

clip_image020

提示include path即将清除,将在Build时重新抓取include path,按『OK』继续。

clip_image021

Step 4C/C++ Build –> Discovery OptionsCygwin C++ Compier,按下Clear清除目前所抓的include path

clip_image022

提示include path即将清除,将在Build时重新抓取include path,按『OK』继续。

clip_image021[1]

Step 5:检查目前App project (hello_world)include path

C/C++ General –> Paths and Symbols的Includes的GNC C,确定已经清除所有的include paths

clip_image023

C/C++ General –> Paths and Symbols的Includes的GNC C++,确定已经清除所有的include paths

clip_image024

原本App project (hello_world)的warnings也都不见了。

clip_image025

看到这里,或许你会说:『不是应该要include新目录的BSP project路径才对吗?』没错,如同Step 3与Step 4的提示所言,最后只要重新Build App project (hello_world),就会重新discover include path,这我们等BSP project也解决后再一起重新Build。

BSP project (hello_world_bsp)无法Generate BSPRoot cause

首先了解Nios II SBT的Generate BSP到底做了什么事情,根据[3]Nios II Software Build Tools Reference的p.15-8的nios2-bsp-generate-files与[4]Nios II Software Build Tools的p.4-30的Regenerating Your BSP所述,Generate BSP会根据BSP project的settings.bsp去寻找*.sopcinfo,再根据目前的*.sopcinfo去产生最新的drivers与HAL目录所需要的档案以及重新产生Makefile。

打开settings.bsp,会发现BspGeneratedLocation与SopcDesignFile所记录的路径都是改变目录名称之前的路径,因此在Generate BSP时会找不到*.sopcinfo而导致执行错误。这是第2个问题的root cause。

clip_image026

BSP project (hello_world_bsp)无法Generate BSPSolution

Step 1:修改BspGeneratedLocationSopcDesignFile的路径

clip_image027

修改完存盘时会出现以下错误讯息,主要是BspGeneratedTimStamp使用了中文时间,按下『Save as UTF-8』格式存盘即可。

clip_image028

Step 2:重新Generate BSP

可顺利执行Generate BSP没有任何错误讯息。

clip_image029

BSP project (hello_world_bsp)无法执行BSP EditorRoot cause

BSP Editor主要的目的在于修改settings.bsp一些只与BSP project相关的设定,BSP Editor无法执行,主要原因也是因为找不到*.sopcinfo。这是第3个问题的root cause。

BSP project (hello_world_bsp)无法执行BSP EditorSolution

在之前的步骤已经修改过settings.bsp的*.sopcinfo路径,所以也一并解决了这个问题,不必再做其他修改。

重新执行BSP Editor,可正常执行没有任何错误讯息。

clip_image030

Build App project (hello_world)BSP project (hello_world_bsp)会出现Makefile找不到SOPC FilewarningRoot cause

App project (hello_world)与BSP project (hello_world_bsp)在Build时,事实上就是执行Make动作,所以需要参考Makefile,会出现warning主要是因为Makefile找不到*.sopcinfo。这是第4个问题的root cause。

Build App project (hello_world)BSP project (hello_world_bsp)会出现Makefile找不到SOPC FilewarningSolution

理论上应该要去修改Makefile,不过由于执行Generate BSP时,nios2-bsp-generate-files已经根据修改过的settings.bsp更新过Makefile,所以我们不须再手动修改Makefile了。

重新Build BSP project (hello_world_bsp),可顺利Build没有任何错误讯息。

clip_image031

最后重新Build App project (hello_world),也可顺利Build没有任何错误讯息。

clip_image032

还记得在App project (hello_world) :include path not found warning的Solution时,我们只清除了App project所include的错误路径,但却还没有将正确地修正include路径。

在Build完后App project (hello_world)后,马上观察hello_world的Properties的C/C++ General –> Paths and Symbols的GNC C与GNC C++,会发现正确的include路径都回来了。

clip_image033

clip_image034

之前的洋洋洒洒,只是因为要边解释root cause边介绍solution,其实整个步骤很简单,只要5个步骤即可。

clip_image035

4.使用Blank Project方法所面临的问题

Nios II project只要改变路径就无法编译的问题,其实从我使用Quartus II 6.0时就已经发现了,应该说Nios II要使用Eclipse,就注定会有这个workspace的问题,很多人的解法(包括我自己)都与[2]张亚峰[笔记].为何在Nios II SBTE中,直接拖放到工程文件夹的文件,编译会出错?一样,都是重新开1个blank project,然后重新将所需要的*.c, *.cpp拖放进新建的blank project,最后在手动去修改Makefile,这样的解法的确是可以避开include paths错误与*.sopcinfo路径错误的问题,不过settings.bsp与Makefile都是新的,所以必须手动去检查Makefile是否与原project一样,然后手动修改Makefile。

在[1]Getting Started with the Graphical User Interface的p.2-11的User Source Management有以下一段文字:

clip_image036

简单的说,就是既然你用了Nios II SBT,就不建议手动去改Makefile,应该采用GUI或者Command line script的方式,由tools去更改你的Makefile,而不该手动去更改你的Makefile。本文采用的方式,虽然知道Makefile有问题,但依照Nios II SBT的逻辑,使用了Nios II SBT的GUI方式与流程去修改Makefile,完全没有手动去修改Makefile,这样可确定Makefile的正确性,也省去了一一比对原本Makefile的功夫。

完整程序代码下载
DE2_70_SOPC_golden_mini2.7z

Conclusion
这篇博文中的解法,是参考了Altera的官方资料所做出的总结,并经过无数次的实验所归纳的心得, 因为这是我困扰好几年的问题,假如你也为Nios II project路径问题而困扰,可以参考本文的解法。

See Also
(原创) Qsys或RTL做修改后,Nios II SBT该如何面对新的硬件? (SOC) (Nios II) (Qsys)

Reference
[1]Getting Started with the Graphical User Interface
[2]张亚峰[笔记].为何在Nios II SBTE中,直接拖放到工程文件夹的文件,编译会出错?
[3]Nios II Software Build Tools Reference
[4]Nios II Software Build Tools

全文完。

Baidu
map