Microtronix / Nios version info.

[Altera_Forum]

I am currently using Nios version 3.2 with the Microtronix Linux distribution 1.3. 

 When I compile the kernel to include Nios serial support, I get an Internal Compiler Error ... Fatal Error Signal 11 when compiling the module "serial.c". Also, when compiling this module, the compiler looks for the header file "serial.h" in asm/asm-niosnommu and cannot find it. (Obviously, because it's not there to begin with!)  I also get the message "Sorry your gcc is too old...it builds incorrect kernels" during the compiliation of various kenel modules throughout the build.  I cannot yet move up to Nios II because the Microtronix distribution 2.6 does not yet support the Cypress SL811HS USB controller which is included in my hardware design.   My questions are...  1) Is the Microtronix dist. 1.3 compatable with Nios 3.2. 2) If not, which versions of Microtronix support which versions of Nios? 3) When will the Microtronix versions targeted to Nios II support the SL811 USB controller (Any Microtronix guys out there??) 4) Will the UHBI or OHBI USB drivers in the Microtronix version 2.6 support the SL811? (I say, probably not)  Thanx in advance!

[Altera_Forum]

Hello nci, 

 Well, I can help with some of your problems.  The Linux Developer CD v1.3 does support the Nios 3.2 Kit along with Quartus II 4.0 SP1. You can ignore the "gcc is too old" message (referred to in the readme.txt). If you have registered your product (or haven't yet) you have 30 days of support.  We will be supporting the Cypress USB 1.1 no later than September, as we will be releasing a new, very cool development product that uses this chip.  I'll wander over to someone and see if they can help you with the serial support (probably not a big problem) and the UHBI and OHBI drivers question.  Regards, Robert Brookes Marketing Manager, Microtronix

[Altera_Forum]

Hello rb! 

 The help is greatly appreciated!  Just to add some info... I am using Quartus 4.0 with SP1 and have tried at least once to delete / recreate the uClinux directory when generating the CPU.

[Altera_Forum]

Now I have an installation issue as well. 

 I wanted to try removing and reinstalling Linux Developer 1.3 and got the following InstallShield error...  During removal or installation: Error 1321: The installer has insufficient priviledges to modify the file C:\Config.Msi\<different filename each time>.rbf  This dir. doesn&#39;t exist in my filesystem during installation or removal. I am running Windows 2000 Prof. as administrator.  Nick

[Altera_Forum]

Hi nci. 

 The error your receiving has to do with the uClinux directories that are installed. Cygwin permissions and Windows permissions don&#39;t always synchronize properly.  So if you&#39;re trying to remove the installation, I would recommend deleting all the uClinux directories associated with the installation of version 1.3 of the Linux Dev CD. They can be found in any example projects you installed as well as in the uClinux SOPC Builder component.  Alternatively, you could also try performing a   chmod -Rf 777 uClinux  on any installed uClinux directories and letting the installshield take care of deleting the directories for you.  Let me know if this helps.

[Altera_Forum]

One issue solved! (just deleted all uClinux dirs. through Windows Explorer) 

 Reinstalled 1.3, now I&#39;m doing a make all... we&#39;ll see if I can get past my original problem although I don&#39;t think so.

[Altera_Forum]

More details! 

 The kernel will compile through with "Nios serial support" enabled under "Character Devices".  However, the compiler gives me the serial.h error and the Signal 11 failure when I include "Standard/generic (8250/16550)...." support. I need this since my board level design includes 2 quad UARTS (Exar 16c854) connected externally to the Nios / FPGA. If I copy a "serial.h" file over to asm/asm-niosnommu from another directory, I only get the Signal 11 failure.  Since I have a total of 9 (!) UARTS in my system (one Nios UART and 8 external hardware UARTS) I will also want to enable the "Support more than 4 serial ports" option in the kernel also.  Also, my system includes an SPI bus which I am using to interface with other components. When I enable "Nios SPI Device Support" in the kernel, I also get many compile errors for "spi.c" which cause the compiler to stop, but no Signal 11 failures. I MUST have SPI enabled for my system to work!!!

[Altera_Forum]

The following options, when selected, cause the kernel compile to crash with various errors... 

 BSD Process Accounting USB HID / Input core / keyboard support NIOS SPI support Standard / generic UART support  these are only the ones that I found so far...  I did not have these issues when starting out with Microtronix v. 1.1  What&#39;s the deal?

[Altera_Forum]

Hello Nick, 

 re: SPI. Presumably when spi.c fails to compile it is becuase there are missing symbols. Have you added SPI to your core? If not, you&#39;ll need to pop into SOPC Builder and add the SPI component (our default Quartus Projects do not include SPI IIRC). Then, you&#39;ll need to run core_update to propogate the information to the kernel. Page 20 of the Getting Started Guide talks a bit about this process.   re: 16550, USB etc. The Linux kernel contains literally hundreds of configuration options and that&#39;s what make the offering so powerful. However, Linux was developed initially for an Intel *86 (and that&#39;s still by far the most popular architecture). So, device drivers sometimes assume this native architecture is present. For example, I imagine by enabling the 16550 your kernel assumes there is a COM port at 0x3F8 in your I/O space. Like SPI, you&#39;ll need to ensure the output from SOPC Builder is propogated to the kernel (and that the kernel can use this information meaningfully -- in the case of SPI, there is already support built-in but in the case of the UART you will have to do some legwork to map the "PC COM1" type approach to a Nios-Avalaon architecture).  mike

[Altera_Forum]

hi Mike: 

 Thanks for the info! I do have the SPI module included in my Nios core but will have to run core_update again to ensure that the header files are properly updated.   Concerning standard UART/serial support, I was thinking last night that I might have to do some work to port that module to the Nios platform from x86 land. Since I am just getting started with this particular port and distribution of Linux, I am unclear as to how much of this work was actually done vs. what needs to be done.   As mentioned in one of my previous posts, I seem to be missing a header file, serial.h, which is supposed to be found in the "asm/asm-niosnommu" directory. The "asm-*" directories for the other processors included in this package have this header file. The compiler only searches for this header when I have enabled the Standard / generic UART support option in the kernel configuration. Is this file generated by SOPC Builder and placed in another directory, to be copied over manually?  Nick

[Altera_Forum]

Hi Nick, 

  <div class='quotetop'>QUOTE </div>  --- Quote Start ---  As mentioned in one of my previous posts, I seem to be missing a header file, serial.h, which is supposed to be found in the "asm/asm-niosnommu" directory. The "asm-*" directories for the other processors included in this package have this header file. The compiler only searches for this header when I have enabled the Standard / generic UART support option in the kernel configuration. Is this file generated by SOPC Builder and placed in another directory, to be copied over manually?[/b]  --- Quote End ---    Yep -- you&#39;re on the right track. The header search path includes &#39;asm&#39; which is actually a symbolic link to an architecture-specific directory (e.g. asm->asm-niosnommu for the Nios distribution). So, if you&#39;re compiling a 386 kernel, asm->asm-i386 and serial.h is found. For the Nios, we supply NIOSserial.h because the Nios Serial IP is not a 16550. You&#39;d need to, as you say, copy serial.h over and use it as a starting point.  mike