How to access the 8GB ram of DDR in Agilex 7
Hi, I need to access 8GB DDR ram in agilex dev kit,but now i able to access only 2GB ram.While trying to access the remaining 6GB of ram ot throw error as "TFTP error: trying to overwrite reserved memory...". I have tried to access the remaining 6GB of ram by changing memory address in .dtb file,but same issue continues. Thanks M Gokulraj
Can't execute an ARM Compiler 5/6 built image from Arria V SoC devkit SDRAM without debugger
Hi, I try to build a bare metal app for the Arria V SoC devkit using Arm Compiler 6/5 (DS-5 built in) and load it from the QSPI into the SDRAM (on the devkit without debugger). The app is never executed. I followed several guides, All resulted with working preloader that doesn't load the app: 1. Link: https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/scatter-file-linker-script-and-preloader-integrations-for/m-p/1472491/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExHME5POUsyNERNRFVVfDE0NzI0OTF8U1VCU0NSSVBUSU9OU3xoSw#M1882 2. asdf soc hands baremetal (attached) 3. guide found in this forum (attached) 1 | My Environment - Windows 10 - SoC EDS 18.1.0.625 - DS-5 Ultimate Edition, Version: 5.29.1 (installed with SoC EDS) - Quartus Prime 18.1 (including Quartus Prime Programmer) 2 | Example Projects For comparison I used two example projects: 1. Altera-SoCFPGA-HardwareLib-Unhosted-AV-GNU - Link: (attached to this post) - Result: The built app is loaded successfully with debugger and without it (SoC only) 2. Altera-SoCFPGA-HardwareLib-Timer-AV-ARMCC - Link: (attached to this post) - Result: The app is loaded only when using debugger. I wish to load it without debugger. 3 | 1. I used the Arria V SoC GHRD handoff folder to build the preloader: - Checked SDRAM scrub - Unchecked watchdog interrupt and any boot device other than the QSPI - Next image address is 0x60000) I see the preloader UART prints. I use the same preloader with both images (only the GCC built image is executed without debugger) 2. In both cases I flash the bare metal app into the QSPI starting from address 0x60000: quartus_hps -c 1 -o PV -a 0x60000 [image_name].bin 3. I don’t know if its matters, but in project (2.1) the resulted ELF is converted to .bin using objcopy. In project (2.2) its converted using fromelf. In both cases I use the same mkimage command: mkimage -A arm -T standalone -C none -a [SDRAM_START_ADDR] -e 0 -n "baremetal_image" -d [name].bin [image_name].bin 4. The [SDRAM_START_ADDR] is different in both projects. In (2.2) its provided in the scatter file, in (2.1) its provided in the linker script. I did noticed a comment in the GCC project (2.1) linker script: MEMORY { boot_rom (rx) : ORIGIN = 0xfffd0000, LENGTH = 64K oc_ram (rwx) : ORIGIN = 0xffff0000, LENGTH = 64K /* Need to have 64bytes available before start of program, to store the mkimage header */ ram (rwx) : ORIGIN = 0x100000 + 0x40, LENGTH = 1023M - 0x40 } "Need to have 64bytes available before start of program, to store the mkimage header" I'm not sure this space exists in project (2.2) as well. Could this be the reason for my problem? 5. I looked at each project built ELF "Image entry point". In both cases it points to a valid place (proj 2.1 – cs3_reset , proj 2.2 – alt_interrupt_vector). Both lead to main So I don't know what is the specific difference causing the GCC project (2.1) built image to be loaded and work properly as opposed to the ARM project (2.2) built image.
High-Latency Ethernet on Arria 10 SoC device using HPS EMAC and KSZ9031
Hello, I observe a strange issue using the 1Gbps Ethernet on the Arria 10 SoC HPS. I observe the issue on our custom board and also on the Arria 10 Dev Kit. For simpler debugging, explanation and potential reproducibility, I focus now on the Dev Kit: https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/arria/10-sx.html I built the Kernel 6.6 for the development board and use the tool `iperf3` for an Ethernet stress test. The setup is simple: Direct connection from the DevKit to a Computer. On the Dev Kit I start the "Server" with `iperf3 -s` and on the PC side, I call the client in bidirectional mode like this: `iperf3 -c <IP> --bidir`. In parallel I start a ping on my PC console to observe the Ethernet latency. Every now and than, the ping latency increase to 500-1000ms (after the iperf3 test has finished and no data transfer is done). It is really sporadic and doesn't happen every time. But it is some how a big issue on our product using the Arria 10 device. I think it is some how related with an old observation: https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/is-there-a-bug-in-the-Ethernet-MAC-of-Arria10-SoC-devices/m-p/1238772#M866 At this time now specific answer for the issue was found. And now the issue is back after the kernel update. So whats happen here? And how can we get a stable Ethernet connection? Is there any patches or bugfixes available for the EMAC driver? Cheers Silvan
Interrup numbers of Arria 10 EDAC
Hi, I try to enable the Error Detection and Correction (EDAC) for EMAC1 on my Arria 10 SoC device. I found the device tree entries for EMAC0 in the Linux kernel sources: emac0-rx-ecc@ff8c0800 { compatible = "altr,socfpga-eth-mac-ecc"; reg = <0xff8c0800 0x400>; altr,ecc-parent = <&gmac0>; interrupts = <4 IRQ_TYPE_LEVEL_HIGH>, <36 IRQ_TYPE_LEVEL_HIGH>; }; emac0-tx-ecc@ff8c0c00 { compatible = "altr,socfpga-eth-mac-ecc"; reg = <0xff8c0c00 0x400>; altr,ecc-parent = <&gmac0>; interrupts = <5 IRQ_TYPE_LEVEL_HIGH>, <37 IRQ_TYPE_LEVEL_HIGH>; }; Where do I find the interrupts used for EMAC1? Is there any documentation available? And does it require some changes in my Quartus project as well or is it fully covered by the Linux drivers?
Investigating Device Trees
Note: This article is an English translation of this Japanese article. Please refer to the original article for updates. 1. Introduction While operating an FPGA with an embedded ARM CPU on Linux, I encountered the need to modify the device tree. Therefore, I will write about what I have researched (and understood in my own way) to roughly understand the content of the device tree source (.dts) included in the Kernel source. I hope that those who see the .dts files in the Kernel source and think "what is this?" can somewhat understand and feel capable of making additional modifications. 2. What is a Device Tree? 2.1 Overview A device tree can be described as a data structure (file format) that describes hardware components accessible from the OS (CPU) from the perspective of software (device drivers). This format was established by a group called Open Firmware (different from the Linux development group). 2.2 Usage in Linux Linux also uses this format, separating the Kernel code from board-specific information (i.e., the device tree). This allows the same Kernel binary to operate on different boards, as long as the appropriate device tree for the board is provided. The Kernel source contains device tree source (.dts) files for major supported boards, and device tree binaries can be generated using the Makefile system (e.g., `make dtbs`) similarly to building the Kernel binary (e.g., `make zImage`). As of May 2020, the Linux kernel source tree on Kernel.org had over 1200 .dts files for 32-bit ARM CPUs. During initialization, each device driver in the Kernel code searches for the information it needs from the device tree and completes device registration and initialization accordingly. Therefore, if the information required by the Kernel code is not described in the device tree, the Kernel may not boot. As a principle, the Kernel binary and device tree should be created from the same version of the Kernel source. 2.3 Types of Device Tree Files Device tree sources written in human-readable text format have the .dts extension. The binary form of these files is called a device tree blob, with the .dtb extension. The Kernel reads binary device tree blobs (.dtb). Conversion from device tree source to device tree blob is done using the device tree compiler (dtc command). The device tree compiler also supports reverse conversion from .dtb to .dts, which can be useful when you want to view the content of a binary .dtb. 3. Understanding Device Trees To understand device trees in Linux, it is helpful to divide the understanding into two parts: Device tree format (how to write it) What information needs to be included in the device tree (what information Linux device drivers read from the device tree) Here, we will focus on "how to write a device tree (format)." The necessary information in a device tree depends on what information the Linux device drivers need. At the end of this article, we will briefly introduce this aspect. 3.1 Overview of the dts File Format To put it simply, a dts file is: A list of hardware (device nodes) to be accessed by the CPU, described as a tree-structured database Comprised of only two types of components: node and property Nodes can have various attribute information properties and child nodes Properties are expressed as combinations of attribute names and values, used to describe hardware information such as address and interrupt numbers For more detailed information, please refer to the following link: https://elinux.org/Device_Tree_Usage 3.2 Nodes [label:] node-name[@unit-address] { [properties definitions] [child nodes] } Devices are represented as nodes Nodes can have properties and child nodes Nodes are defined with the format node-name @ unit-address, and their content is defined within curly braces { } The unit-address part is written in hexadecimal and specified by the reg property. If there are multiple devices with the same node name, they can be distinguished by unit-address. Nodes without a reg property do not need a unit-address. Linux's dtc allows compilation even without a unit-address (a warning will be issued) Node names are simple ASCII strings, with a maximum length of 31 characters. Names representing the function of the device (e.g., ethernet, serial, gpio) are recommended The top-level (root) node has no name, only "/". `/ { ... };` The tree structure of nodes (parent node - child node relationship) should represent the connection state of devices as seen from the CPU (e.g., define Bus bridge as the parent and SlaveDevice connected to the Bus bridge as child nodes) If a label is attached, the node's phandle (like a pointer to another node) can be specified as `&label`. If compiled with the -@ option, it can be referenced from another file (overlay file). (See the explanation of the phandle property below) 3.3 Properties Properties are combinations of property-name and value Properties can also be defined without values [label:] property-name = value; [label:] property-name; 3.3.1 Types of Values Used in Properties Text String: Enclosed in double quotes. Example: compatible = "arm,cortex-a9"; Array/Cell-list: A set of 32-bit unsigned integers enclosed in angle brackets <>. Example: reg = <0xffd04000 0x1000>; Binary Data: Enclosed in square brackets []. Example: mac-address = [12 34 56 ab cd ef]; Multiple Data: Can be concatenated using commas. Examples: reg = <0xff900000 0x100000>, <0xffb80000 0x10000>; mixed-property = "a string", [0x01 0x23 0x45 0x67], <0x12345678>; 3.3.2 Standard Properties Commonly Used in Many Nodes compatible The most important property used to associate with the device driver. Devices requiring a device driver need this property The initialization routine of the device driver that has a matching compatible string with this value is called, and the device is registered A list of text strings in the format "manufacturer,model". Example: compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac"; status Indicates whether the device is enabled or not Value is "okay" or "disabled" phandle Sets the ID number indicating the node as a Cell-list Usually omitted in human-written .dts If omitted, the dtc compiler automatically generates a unique ID and adds the phandle to the .dtb The phandle of a node with label "XXX" can be specified as <&XXX>. Often used in the description of the interrupt property reg Address information for the device. Specified as a pair of (address-cells, size-cells) Address-cells specifies the base address, and size-cells specifies the memory size in bytes The number of address-cells and size-cells is determined by the values of #address-cells and #size-cells in the parent node #address-cells, #size-cells Defined in nodes with child nodes. Specifies how the child nodes are addressed. Determines the addressing method in the ranges and reg properties of the child hierarchy #address-cells specifies the number of address cells in the reg property of the child node, usually 1. If there are multiple bus masters, it may be 2 (specified by bus number and addr). 64-bit address is 2 #size-cells specifies the number of size cells in the reg property of the child node, usually 1. If not memory mapped, 0 ranges Defined in nodes representing a bus, specifies how address translation is performed between the node and its child nodes Specified as a combination of If no value is provided, it means the parent and child nodes are in the same address space 3.4 Example of #address-cells and ranges Usage / { ... sopc0: sopc@0 { ranges; /* The relationship between sopc@0 (parent) and bridge@0xc0000000 (child) sopc@0 and bridge@0xc0000000 share the same memory space (no address translation). */ #address-cells = <1>; #size-cells = <1>; ... hps_0_bridges: bridge@0xc0000000 { reg = <0xc0000000 0x20000000>, <0xff200000 0x00200000>; /* bridge@0xc0000000 has two memory areas: 0xc0000000 with size 0x20000000 and 0xff200000 with size 0x00200000 */ #address-cells = <2>; #size-cells = <1>; /* The child nodes of bridge@0xc0000000 are expressed with 2 address cells and 1 size cell. */ ranges = <0x00000000 0x00000000 0xc0000000 0x00010000>, <0x00000001 0x00020000 0xff220000 0x00000008>, <0x00000001 0x00010040 0xff210040 0x00000020>; /* Memory area from 0xc0000000 with size 0x00010000 is assigned from child node address <0x00000000 0x00000000> with size 0x00010000, Memory area from 0xff220000 with size 0x00000008 is assigned from child node address <0x00000001 0x00020000> with size 0x00000008, Memory area from 0xff210040 with size 0x00000020 is assigned from child node address <0x00000001 0x00010040> with size 0x00000020 (No other areas are assigned to child nodes). */ ... led_pio: gpio@0x100010040 { compatible = "altr,pio-16.0", "altr,pio-1.0"; reg = <0x00000001 0x00010040 0x00000020>; /* gpio@0x10001004 has a memory area from <0x00000001 0x00010040> with size 0x00000020, which maps to the memory area from 0xff210040 with size 0x00000020 in the parent node. (CPU can access it within the range 0xff210040-60). */ ... }; // end gpio@0x100010040 (led_pio) ... }; // end bridge@0xc0000000 (hps_0_bridges) }; }; interrupt-controller Has no value. Indicates the device is an interrupt controller #interrupt-cells A property of the interrupt controller node. Specifies the number of cells in the interrupt property. Defined by the device driver of the interrupt controller (e.g., interrupt number, active-high/active-low/posedge/negedge). Refer to the controller's documentation. More explanation in the section "4. What information to write in the DeviceTree" interrupt-parent A property of nodes that output interrupts. Sets the phandle of the connected interrupt controller node. If not present, the value of the parent node is used interrupts A property of nodes that output interrupts. Specifies the attributes of the output interrupt signal. Set the values defined by the #interrupt-cells of the connected interrupt-controller 3.5 Additional Notes The first line is /dts-v1/; Comments can be in C style (/* ... */) or C++ style (// ...) If the same node name appears at the same level, it is considered the same node and additional definitions are made to that node. Redefinition of properties is also possible (the later definition is used) When compiling with the Kernel Makefile, it is first processed by the gcc preprocessor, so #include and #define can be used 4. What information to write in the DeviceTree To understand this point, it is best to read the documentation of the Kernel Source. As an example, let's look at the description of a node with interrupts. intc: intc@fffed000 { compatible = "arm,cortex-a9-gic"; #interrupt-cells = <3>; interrupt-controller; ... }; soc { interrupt-parent = <&intc>; ... i2c0: i2c@ffc04000 { ... interrupts = <0 158 0x4>; ... }; }; In the code above, the interrupts property of i2c@ffc04000 consists of three cells. To understand what these three values should be, search for the interrupt controller's compatible string "arm,cortex-a9-gic" in the Kernel Source's Documentation/devicetree/bindings directory (e.g., `find Documentation/devicetree/bindings -name "*.txt" | xargs grep "arm,cortex-a9-gic"` or if you have the Kernel Source with git, `git grep "arm,cortex-a9-gic" -- Documentation/devicetree/bindings`). You will find a file named Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt. According to this file, #interrupt-cells is 3, and the content of each cell is as follows: The first cell is the interrupt type: 0 for Shared Peripheral Interrupt (SPI), 1 for Private Peripheral Interrupt (PPI) The second cell is the interrupt number: SPI ranges from [0-987], PPI ranges from [0-5] The third cell is a flag with the following meanings: 1 = low-to-high edge triggered 2 = high-to-low edge triggered (invalid for SPIs) 4 = active high level-sensitive 8 = active low level-sensitive (invalid for SPIs) The value <0 158 4> means: Shared Peripheral Interrupt SPI interrupt number 158 Active high level-sensitive interrupt By the way, according to the specification of the SoC described by this .dts, the Shared Peripheral Interrupt numbers start from 32 in the GIC interrupt controller, so the value written in the .dts subtracts 32 from the interrupt number in the SoC specification (the SoC specification states that i2c@ffc04000 is interrupt number 190). Probably, for SoCs using ARM GIC, the interrupt number in the .dts will be commonly written with 32 subtracted. For those who want to know more about how to write .dts overall, reading the Documentation/devicetree/booting-without-of.txt in the Linux Source's Documentation folder is recommended. It describes essential nodes such as: root node /cpus node /cpus/* nodes /memory node(s) /chosen node /soc<SOCname> node and more, in detail. That's all for now. 5. References https://elinux.org/Device_Tree_Usage https://elinux.org/Device_Tree_presentations_papers_articles https://devicetree-specification.readthedocs.io/ https://www.kernel.org/doc/Documentation/devicetree/ https://www.nds-osk.co.jp/atc/wp-content/uploads/DeviceTree2.pdfHow to access entire 4GB DDR from Agilex 7 HPS
We have a configuration where the Agilex 7 HPS EMIF interface is connected to 4GB DDR on the board. However the Linux/uboot is able to access only 2GB i.e address 0x0 - 0x7FFF_FFFF, while from F2H Acelite interface we can access the entire 4GB 0x0 - 0xFFFF_FFFF. The Agilex™ 7 Hard Processor System Technical Reference Manual , does https://www.intel.com/content/www/us/en/support/programmable/articles/000090809.html But even after enabling that we aren't able to access the address 0x10_8000_0000 - 0x10_FFFF_FFFF neither from the uboot using "md" command nor from the acelite. The app note does refer to Stratix10 instead of Agilex7 , so not sure if its even relevant. Any pointers on how to access the entire 4GB DDR from HPS in Agilex7.C5SX Dev Kit RGII pinning fails
Dear community, on the C5SX development kit I would like to test a 1 GB Ethernet connection with the Triple Speed Ethernet IP core. The core is configured with an RGMII output to the Micrel KSZ9021RN PHY. I have found the corresponding pins in the dev kit documentation - the schematic shows the same pins - so I think the pins are correct. But the Fitter insists that the pins are wrong. For every RGMII pin I try to allocate I get the following errors: Fitter Errors: Error (14566): The Fitter cannot place 2 periphery component(s) due to conflicts with existing constraints ... Error (175020): The Fitter cannot place logic pin in region (68, 81) to (68, 81), to which it is constrained, because there are no valid locations in the region for logic of this type. Error (184016) There are not enough single-ended output pin locations available What does this mean? Thank you Best regards ------------- Excerpt from the top.vhd-file FPGA RGMII Ports (bold = assigned pins) eth0_mac_rx_clk : out std_logic; -- RX Clock (G20) eth0_mac_tx_clk : out std_logic ; -- TX Clock 125MHz (H19) eth0_rgmii_in : in std_logic_vector(3 downto 0) ; -- RX Bus (D21, B18, B20, A21) eth0_rx_ctrl : in std_logic; -- RX data valid (K17) eth0_rgmii_out : out std_logic_vector(3 downto 0); -- TX Bus (F19, F21, J19, F20) eth0_tx_ctrl : out std_logic -- TX data valid (A20) .qsf file set_location_assignment PIN_D21 -to eth0_rgmii_in[3] set_location_assignment PIN_B18 -to eth0_rgmii_in[2] set_location_assignment PIN_B20 -to eth0_rgmii_in[1] set_location_assignment PIN_A21 -to eth0_rgmii_in[0] set_location_assignment PIN_F19 -to eth0_rgmii_out[3] set_location_assignment PIN_F21 -to eth0_rgmii_out[2] set_location_assignment PIN_J19 -to eth0_rgmii_out[1] set_location_assignment PIN_F20 -to eth0_rgmii_out[0] set_location_assignment PIN_G20 -to eth0_mac_rx_clk set_location_assignment PIN_K17 -to eth0_rx_ctrl set_location_assignment PIN_H19 -to eth0_mac_tx_clk set_location_assignment PIN_A20 -to eth0_tx_ctrl For all the above pins. all pins I set: set_instance_assignment -name IO_STANDARD "3.3-V LVCMOS" -to <pin name> Fig. Doku pins
DE-10 PROJECT
HII i bought the DE-10 KIT AND I WANT TO USE THE UART ON THE HPS SIDE TO RECIEVE A CHAR FROM THE PC according to the char value to turn on a gpio on the fpga fabric side that means that i there is have to be hps_to_fpga bride involved is there an example that i can use or an application or a tutorial that can help me in this subject
