Altera Monitor Program
Nancie Fazzari
I've seen that message when I had a bad configuration file, or when I forgot to load the FPGA configuration before starting the monitoring program. You can narrow it down by seeing if the board works with a known good configuration file.
I have tried restarting the Altera Monitor Program, and ensuring I use the quartus programmer to flash the device before I start the monitor program, this still gives the same problem. If I don't use the SDRAM controller in the qsys design and instead use on-board RAM or ROM for the reset and exception vectors then the system works. Which makes me suspicious of the SDRAM components. However if I use some test code that uses an SDRAM controller and periphery (but with no NIOS) then that program works ... so i suspect the SDRAM isn't broken...
Hi, I assume that the SDRAM will act somewhat like a frame buffer, and the RTL will just continuously read from there and output it (something like RAW2RGB ). If this is the case, take a look at Terasic's example for D5M:
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
If you read at this link -software.html#altera-monitor-program/ it states that the monitor program is available as part of the FPGA University Program Installer which can be found a little further down on the same page.
One of the shortcomings of the guide appears to be that it does not include instructions on how to program the FPGA from u-boot in the CycloneV workflow. I have gotten around this using a boot script and modifying u-boot to run the script before booting the kernel.
so You will not need to recompile and replace boot-script each time to change content of FPGA. Just change value of the variable. It is very fajn soution .
Hope it could help You a bit.
Best wishes,
Yours Jan Konečn.
A brief view on FPGA manager
The FPGA manager in HPS configures the FPGA fabric from HPS. It also monitors the state of
FPGA and drives or samples signals to or from the FPGA fabric. The application software is
provided to configure FPGA through the FPGA manager. The FPGA configuration data is stored in
the file with .rbf extension. The MSEL[4:0] must be set to 01010 or 01110 before executing the
application software on HPS.
I do have a correct configuration, which is MSEL[4:0]=01010. Unless I am misreading this doc or my switches, I think this is not a concern. Perhaps there is a compression vs. non-compression of RBF issue. I do not know how to check whether the RBF is compressed or where to find out whether or not it should be, but this seems like a stretch.
I am not sure if this is right. I used the Python script mentioned in the guide in my first post to load the files onto the sd card and format it. In actuality, I had to find an updated script compatible with a newer Python version. That script can be found here.
Hello @jackfrye11,
well FAT partition is the 1st one, it is OK.
The script make_sdimage.py is usefull but to comperhand what it does I recommend You to create SD card manuly accroding to this great tutorial:
RocketBoards.org Embedded Linux Beginners GuideBeginners guide to using embedded Linux on Altera SoC devices
@JanKonecny
I tried reformatting my SD Card according to the guide you posted. Instead of putting preloader-mkpimage.bin on the A2 then u-boot.img on the VFAT partition, I simply placed u-boot-with-spl.sfp on A2. ( u-boot-with-spl.sfp contains both preloader and uboot per this guide) Building Bootloader for Stratix 10 and Agilex Documentation RocketBoards.org
One more note: Preloader and U-Boot should be compiled and placed at SD card together (preloader compiled as the first one, U-boot as the second one). Mixing versions (means different hardware configurations) of preloader and U-Boot could cause very strange problems such as Yours.
I am sorry I could not help You in a better way.
It is highly recommended to use only the same versions together - i.e. use Intel SoC EDS of the same version as Intel Quartus Prime. Source code of U-Boot is a part of the Intel SoC EDS. Mixing them is not a good idea while looking for a source of problems!
I use version 17.1 due to the license of standard version which I purchased.
Hello @jackfrye11,
You could try to start with Golden Hardware Reference Design (GHRD) and Golden Software Reference Design (GSRD) and try to change their parts step by step, one by one according to Your target design. You would be able to identify the source of problem in this way.
Golden reference designes could be found at RocketBoards.org for Your board, e.g. for Altera Cyclone V SoC Board here:
Will try using Bitbake to build everything. The maintainer of this layer assures me that everything should work
GitHub kraj/meta-alteraOfficial Altera BSP layer for OpenEmbedded/Yocto Project - kraj/meta-altera
Only once that is complete would I start playing with their device tree generator. I would compare to make sure that what it is generating has all the important hard stuff (MAC, etc) in the reference device tree. I also would not rely on it recognizing all of its own (proprietary Altera/Intel IP) peripherals. Even if it does, there is still the matter of ensuring that there is built-in kernel support and that you actually enable it when you build the kernel (I have not done this).
At this point, you will have to deal with your own peripherals. Are you doing custom IP in this design? I do not know if you are able to somehow integrate the Quartus IP development flow into their device tree generator tool. (Maybe you could fill me in on this one).
For example I do not know if they have a PIO driver in their kernel, but I was trying to light some LEDs on my board. In that case, rather than going through device tree madness and driver kernel build config/platform device driver registration and figuring out how to use their software, I simply used /dev/mem and hit the registers manually. If it is something monstrously complicated like a soft MAC, maybe you go with their driver.
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
In the last couple years I've been completely disappointed with consumer displays. The TV market after the plasma panels production completion was saved by LG with their OLED implementation for large screens, but this did not happen for the computer display market.
This problem is solved in professional displays (sometimes not completely) with a variety of add-ons. The price of a decent professional display can be quite high. I needed to replace 2 displays. I wanted a higher resolution and 30-32" size. I could not find anything in a store. I figured out that I need to look for among professional displays, broadcast displays and medical displays.
The monitor supports special software and a sensor for calibration of tones/chromaticity. It has a comfortable stable stand and it has a built-in USB hub. I was upset only about a 8bit matrix. However, the monitor must have a 12bit LUT table and a strange input signal mode 2560x1600x10bit@24Hz. I think this is a limitation of the DVI-D dual-link interface.
I am sure that this monitor simply has a "selected" matrix, which is also installed on a SX3031W and slightly different software. The most interesting thing for me is compliance with the DICOM Part 14 standard.
DICOM stands for Digital Imaging and Communication in Medicine. It is a medical standard that describes how medical imaging information should be exchanged and managed. Related to that is DICOM Part 14, which was published by the National Electrical Manufacturers Association (NEMA) and the American College of Radiology (ACR).
I do not need DICOM and of course I will use gamma 2.2, but the display should have a perfect backlight. Poor backlight uniformity can lead to misdiagnosis and patient death. I like these device requirements!
What could be wrong with these wonderful and very expensive monitors? Everything is very simple. I guess it was Samsung mistake. EIZO bought a matrix from Samsung, which included a TCON board. The TCON board was made on the basis of the Altera FPGA, and later the ASIC is used, which was also produced by Altera.
The MX300W manual shows that the monitor lifespan is at least 30000 hours. The whole problem is that the ASIC on the TCON board heats up to about 80-100C during operation and after 5000-10000 hours of operation the crystal packaging is damaged.
At high temperatures the thermal pad dries out in several thousand hours and turns into a heat insulator. That's why I prefer not to use thermal pads in my designs and if I do it I prefer to use a thin thermal pad and a larger area.
To restore the monitor, I needed a new Altera crystal and to upgrade cooling solution. Of course it was impossible to buy such a crystal or a new board. But I wouldn't buy these displays if I didn't have a plan.
The same TCON board (and matrix?) was firstly used on the Gateway XHD3000 monitor in 2007. And it used a regular FPGA Altera Stratix, what was later replaced by ASIC to reduce the cost. But the board itself remained unchanged. Altera Stratix EP1S30F780C8N FPGA and Altera EPC FLASH EPC16UC88N for storing firmware are installed on the board.
93ddb68554