MV
Occasional ContributorJoined 8 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: CycloneV U-Boot FPGA Load Fails: Code -6
I think this is a good question and begs for an answer. Running into a similar issue and also speculating about a size limit of .rbf file that perhaps u-boot or the FPGA driver is able to handle. Anyone can shed light on this? Thanks!2.5KViews0likes0CommentsRe: Verify BSP settings
Got that one resolved! I decided to re-build bootloader and tried to follow the GSRD v14.0 - Generating and Compiling the Preloader When I copied the binary to my uSD card the system didn't boot - likely some of the important details like partition type etc. I went back to my previous scripts that use mainline u-boot (branch v2019.07). After some searching how the BSP specific information gets included into the u-boot-with-spl_DE0.sfp u-boot binary I discovered in the u-boot build tree the file board/terasic/de0-nano-soc/qts/pinmux_config.h I edited desired "...USEFPGA" values to "1" abbreviated ... 1, /* UART1USEFPGA */ 0, /* CAN1USEFPGA */ 0, /* USB1USEFPGA */ 0, /* I2C3USEFPGA */ 1, /* I2C2USEFPGA */ ... rebuilt the u-boot, placed on my uSD card and the previously failing kernel with corresponding drivers and device tree started to work as expected. Hoping this may help someone else. Martin1.9KViews0likes0CommentsVerify BSP settings
I am developing a system using Cyclone V under Linux OS. Up to now I was focused on rebuilding of the kernel and device tree. The device tree that is loaded contains the HPS peripherals I am looking for with status = "okay"; but the devices do not seem to work. Also cat /proc/interrupts doesn't seem to be showing interrupts associated with some of the peripherals. Would that likely be an issue with my device tree or could that be that the HW is not enabled in my BSP (that I didn't touch since I started with the GHRD). In case of the UART (serial1) I clearly have a Linux driver running on serial0 so I should be covered there. I realize that the BSP code embedded into the u-boot is responsible for bring-up of the HPS resources that will be used by the kernel drivers. Is there a way to verify that the resource (such as "serial1") is actually enabled from within a running OS? Can one enable a HPS module during run-time or is the bootloader the only place? Thanks - MartinSolved1.9KViews0likes5CommentsRe: arm-linux-gnueabihf-gcc missing
Thanks for the pointer. I didn't get a chance to try since I got past that point: Basically I have given-up on any Quartus past 18.1 (since Cyclone V is old (while still going strong) and doesn't seem to be benefiting from any newer Quartus versions. Also installed Quartus 18.1 on Linux - since this is the more "native habitat for Quartus". With the 18.1 (and on Linux) I didn't have to download and install any additional tools and things seemed to work as expected.2.8KViews0likes0CommentsRe: Warnings on files generated by Platform Designer (QSys)
@KhaiChein_Y_Intel Thank you very much. You are right the top level names were different. These were created meaningful like the "HPS_LED" below. .hps_0_hps_io_hps_io_gpio_inst_GPIO53 ( HPS_LED ) I was on a wrong path chasing down the port names (hps_0_hps_io_hps_io_gpio_inst_GPIO53) since these were similar to the names in the SDC file. That was - in part - due to the fact that these names have multiple times repeated prefix "hps_io_" and that seemed to be the difference - until I figured out that it is the "HPS"LED" what counts. Still puzzled why: - The auto-generated SDC uses different names than desired - Platform Designer generates port names with numerous repetitive prefixes. Tried to see how to control this and didn't find it. Thanks!1.8KViews0likes0CommentsWarnings on files generated by Platform Designer (QSys)
My (pretty much Cyclone5 SoC GHRD) project is producing almost 700 warnings. Majority of the warnings originates from files automatically generated by Platform Designer as a result of the integration of the HPS. As an example: Warning (332049): Ignored set_false_path at soc_system_hps_0_fpga_interfaces.sdc(44): Argument <from> is an empty collection Info (332050): set_false_path -from [get_registers {*fpga_interfaces|f2sdram~FF_3823}] Warning (332174): Ignored filter at soc_system_hps_0_fpga_interfaces.sdc(46): *fpga_interfaces|f2sdram~FF_3831 could not be matched with a register The above warning (one of many) is originated by the contents of file \soc_system\synthesis\submodules\soc_system_hps_0_fpga_interfaces.sdc generated by the Platform Designer with following contents (snippet): ... set_false_path -from [get_registers {*fpga_interfaces|f2sdram~FF_3823}] ... I can certainly comment out the contents of these .sdc files (tried successfully) but this doesn't seem right since the files are generated and perhaps the warnings have value and should be addressed properly. Manifests without any change on Quartus Prime Lite 18.1 and 20.1 Thanks for any advice.Solved1.8KViews0likes4CommentsRe: BSP Editor fails to generate files
Hi @Rajeshm , Thanks for the suggestion. It is worth trying. As soon as I have a moment I will go back to the future (20.1) and soo if this was (one of) my problems. I am happy with 18.1 at the moment so I am not pressured but "out of scientific curiosity" want to close the loop sooner or later. Are you on windows or Linux? Thanks M.6.6KViews0likes1CommentRe: BSP Editor fails to generate files
I understand your frustration way too well. I am still working on something what I expected to be covered by "out of the box example". However, I suspect that the tool as it is (Quartus 20.1) would work with a project fully configured and set-up for this environment. And that looks like a steep hill to climb. Intel seems to be less focused on FPGA business than it was back in the Altera days when Altera folks didn't have other distraction from their core business. Good luck - Martin6.6KViews0likes0Comments