xilinx / embeddedsw Goto Github PK

The function XSpiPs_PolledTransfer checks the transfer completion by testing the flag XSPIPS_IXR_TXOW_MASK, which is reported to be the flag indicating the TX FIFO overwater, meant to be asserted whenever the content of TX FIFO crosses the configured watermark.
This causes an issue when the master is configured with the manual SS mode. Indeed, checking the XSPIPS_IXR_TXOW_MASK causes the de assertion of SS before the transfer is completed; this is due to the fact that the TX FIFO is being dequeued until it is empty when the master is configured with the auto start mode.

To resolve the problem, a simply work around can be adopted: instead of checking the XSPIPS_IXR_TXOW_MASK (raw 576 of xspips.c), it should be enough to check the condition XSPIPS_IXR_RXNEMPTY_MASK once the RX Watermark is set equal to the amount of byte queued into the TX fifo.
This will be eventually set since the counterpart device is going to sent backwards data during the master transfer, hence XSPIPS_IXR_RXNEMPTY_MASK will be asserted each time the TX fifo has been emptied.

So, probably there is the need to split up the XSpiPs_PolledTransfer into two versions: one with automatic SS and the other one with the manual SS; alternatively a branch over the SS mode can be adopted instead.

While I'm unsure of exactly what the required conditions are for this issue to occur, it has happened to me a couple of times over the past week. Fortunately, the cause wasn't too difficult to find:

emacps_error_handler() in xemacpsif_hw.c is called from interrupt context. Unlike its "sister" functions, emacpsif_send_handler() and emacpsif_recv_handler(), it fails to increase xInsideISR as it should. This can result in xQueueSend() being called instead of xQueueSendFromISR().

So, just do the proper xInsideISR++ and xInsideISR-- in emacps_error_handler().

I am using Vivado 2018.2 and lwip202, and run the Freertos LwIP echo server.

The board was MYIR Zturn Lite which has a microchip ethernet chip KSZ9031RN. Lwip202 was configured as: phy_link_speed is fixed to 1000 Mbps, socket mode and the sprintf messages are logged to UART. The FreeRTOS was compiled and run without any modification.

This ethernet is not working and the following messages are printed continuously at the console,

-----lwIP Socket Mode Echo server Demo Application ------
Board IP: 192.168.1.10

Netmask : 255.255.255.0

Gateway : 192.168.1.1

WARNING: Not a Marvell or TI or Realtek Ethernet PHY. Please verify the initialization sequence
link speed for phy address 3: 1000

              Server   Port Connect With..
-------------------- ------ --------------------
         echo server      7 $ telnet <board_ip> 7

Ethernet Link down
link speed for phy address 3: 1000
Ethernet Link up
Ethernet Link down
link speed for phy address 3: 1000
Ethernet Link up
Ethernet Link down
link speed for phy address 3: 1000
Ethernet Link up
Ethernet Link down

How could I fix this issue?

BTW: Before upgrade to Vivado 2018.2, I was using 2017.2. There is no problem running FreeRTOS 9 and lwip141 under 2017.2 using FreeRTOS lwip Echo Server application.

In Axi Dma driver when only one channel present, for example, MM2S or S2MM, kernel driver fail in function XAxiDma_Reset, with message "unable to handle kernel NULL pointer dereference". When all channels enabled, reset is done right.

if(XAxiDma_HasSg(InstancePtr)){
-       XAxiDma_BdRingSnapShotCurrBd(TxRingPtr);
-
-       for (RingIndex = 0; RingIndex < InstancePtr->RxNumChannels;
-                       RingIndex++) {
-           RxRingPtr = XAxiDma_GetRxIndexRing(InstancePtr,
-                       RingIndex);
-           XAxiDma_BdRingSnapShotCurrBd(RxRingPtr);
+       if(InstancePtr->HasMm2S)
+           XAxiDma_BdRingSnapShotCurrBd(TxRingPtr);
+
+       if (InstancePtr->HasS2Mm){
+           for (RingIndex = 0; RingIndex < InstancePtr->RxNumChannels;
+                           RingIndex++) {
+               RxRingPtr = XAxiDma_GetRxIndexRing(InstancePtr,
+                           RingIndex);
+               XAxiDma_BdRingSnapShotCurrBd(RxRingPtr);
+           }
        }

As of 2016.4 the send and receive handlers of the IIC driver have a ByteCount parameter. The functions in the example code xiic_eeprom_example.c don't have this parameter. I doubt your code compiles.

Board-dependent code in dynamic DDR init section of ZynqMP FSBL, which assumes I2C1 is used, an I2C mux is present with a hard-coded device address and that the DIMM is assigned to a hard-coded channel number. This should be guarded by conditional compile for Xilinx eval boards.

UG1087 (v1.7) has only 5 Interrupt Configuration Registers (ICDICR) (0xC08-0xC18).
On the other hand, Interrupt Configuration Register written in xscugic_hw.h is described as 0xC00-0xCFC as comment of XSCUGIC_INT_CFG_OFFSET, and it can be read that there are many Interrupt Configuration Registers.

Which is the correct information?
5 or more?

Thanks and Regards

I am using xaxidma_example_sg_intr.c and can't recieve TX and RX in loop test with streamm data fifo. But xaxidma_example_sg_pool.c is ok。

Hi,

 In the xaxidma_example_sgcyclic_intr.c,

The cyclic mode setup of TxDMA [MM2S] does NOT follow the [AXI DMA v7.1 14 PG021 April 4, 2018]

"This bit should be set/unset only when the DMA is idle or when not running. Updating this bit while the DMA is running can result
in unexpected behavior."

https://github.com/Xilinx/embeddedsw/blob/b2f54f649486ec1435f2f6b6e524d9c9c84f2efc/XilinxProcessorIPLib/drivers/axidma/examples/xaxidma_example_sgcyclic_intr.c

Code: -

in Txsetup(), the DMA engine is started

in TxSetup() --> XAxiDma_BdRingStart() --> XAxiDma_StartBdRingHw() --> the bit of XAXIDMA_CR_RUNSTOP_MASK is set in this function

and in SendPacket() [a much later function in the code flow], the bit of XAXIDMA_CR_CYCLIC_MASK is set in

XAxiDma_SelectCyclicMode()

This goes against the Xilinx official document.

Thanks

I wanna generate a devicetree for SoC, however when I choosing "uartns550", GUI runs into error.
Then I used a script like this.

export PROJECT_NAME=device_tree_bsp
export PROJECT_DIR=$(pwd)/$PROJECT_NAME
export HDF_FILE=top_wrapper.hdf
export MSS_FILE=$PROJECT_DIR/system.mss
git clone git://github.com/Xilinx/device-tree-xlnx.git
echo "::hsi::set_repo_path $(pwd)/device-tree-xlnx
::hsi::utils::write_sw_mss -hw $HDF_FILE -sw $PROJECT_NAME -dir $PROJECT_DIR -processor ps7_cortexa9_0 -os device_tree
::hsi::utils::set_current_hw_sw $HDF_FILE $MSS_FILE
# set the console_device path
::hsi::utils::set_comp_param -hw $HDF_FILE -sw $MSS_FILE -parameter console_device -value "ps7_uart_1"
# set uart driver to uartns550
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_0 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_1 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_2 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_3 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_4 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_5 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_6 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_7 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_8 -name uartns550 -ver 3.5
::hsi::utils::set_driver_version -hw $HDF_FILE -sw $MSS_FILE -instance axi_uart16550_9 -name uartns550 -ver 3.
::hsi::utils::update_mss -hw $HDF_FILE -mss $MSS_FILE
::hsi::utils::closesw $MSS_FILE
::hsi::utils::set_current_hw_sw $HDF_FILE $MSS_FILE
::hsi::utils::generate_bsp_sources $HDF_FILE $MSS_FILE $PROJECT_DIR
::hsi::utils::set_current_hw_sw $HDF_FILE $MSS_FILE
::hsi::utils::closesw $MSS_FILE">device_tree_generator.tcl
xsct device_tree_generator.tcl
cd $PROJECT_DIR
dtc -I dts -O dtb -o devicetree.dtb system-top.dts

when processed to ::hsi::utils::generate_bsp_sources $HDF_FILE $MSS_FILE $PROJECT_DIR it raised error like this:

couldn't open "../../include/xparameters.h": no such file or directory
ERROR: [Hsi 55-1545] Problem running tcl command ::sw_uartns550_v3_5::generate : couldn't open "../../include/xparameters.h": no such file or directory
    while executing
"open $filename a"
    (procedure "::hsi::utils::open_include_file" line 3)
    invoked from within
"::hsi::utils::open_include_file $file_name"
    (procedure "xdefine_include_file" line 3)
    invoked from within
"xdefine_include_file $drv_handle "xparameters.h" "XUartNs550" "NUM_INSTANCES" "DEVICE_ID" "C_BASEADDR" "C_HIGHADDR" "CLOCK_FREQ_HZ""
    (procedure "::sw_uartns550_v3_5::generate" line 2)
    invoked from within
"::sw_uartns550_v3_5::generate axi_uart16550_0"
ERROR: [Hsi 55-1442] Error(s) while running TCL procedure generate()
ERROR: [Hsi 55-1450] Error: running generate_bsp.
ERROR: [Common 17-39] 'hsi::generate_bsp' failed due to earlier errors.

My environment is Arch Linux, Vivado 2017.04

Depending by the QSPI mode, a reduced pin set is used by the controller. (e.g. "single" qspi mode -> MIO0 to MIO5).

The PMU firmware, however, doesn't provide such reduced pin-groups for the QSPI function.

I got that error (ld.exe: cannot find -lxilisf) because that lib can not be compiled due to:
xilisf.h:1183:49: error: unknown type name 'XIsf_Iface'
and the original error is from XPAR_XISF_INTERFACE_AXISPI is not defined.
So how to enable define "XPAR_XISF_INTERFACE_AXISPI" in configuration?

Thanks.

I've modified the uartns550 interrupt example to receive 1 less bytes than sent (and only compare the 99 bytes). Then delay a bit to let the ReceiveTimeout interrupt fire. After you do this, the driver interrupt handler keeps firing and locks up the system. See code below.

https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/uartns550/examples/xuartns550_intr_example.c#L284-L319

	/*
	 * Start receiving data before sending it since there is a loopback,
	 * ignoring the number of bytes received as the return value since we
	 * know it will be zero and we are using interrupt mode.
	 */
	XUartNs550_Recv(UartInstancePtr, RecvBuffer, TEST_BUFFER_SIZE-1);

	/*
	 * Send the buffer using the UART and ignore the number of bytes sent
	 * as the return value since we are using it in interrupt mode.
	 */
	XUartNs550_Send(UartInstancePtr, SendBuffer, TEST_BUFFER_SIZE);

	/*
	 * Wait for the entire buffer to be received, letting the interrupt
	 * processing work in the background, this function may get locked
	 * up in this loop if the interrupts are not working correctly.
	 */
	while ((TotalReceivedCount != TEST_BUFFER_SIZE-1) ||
		(TotalSentCount != TEST_BUFFER_SIZE)) {
	}

	/*
	 * Verify the entire receive buffer was successfully received.
	 */
	for (Index = 0; Index < TEST_BUFFER_SIZE-1; Index++) {
		if (RecvBuffer[Index] != SendBuffer[Index]) {
			BadByteCount++;
		}
	}

	/*
	 * Delay a bit (how long? i think the length of 4 character times,
	 * so that the RecieveTimeout interrupt fires, which then gets stuck in a loop.
	 */

	for(Index = 0; Index < 1000000; Index++)
	{
		__asm("or    r0, r0, r0");   /* NOP                     [1 cycle ] */
	}

	/*
	 * Disable the UartNs550 interrupt.
	 */
	UartNs550DisableIntrSystem(IntcInstancePtr, UartIntrId);


	xil_printf("You Will Never Get Here!");

e.g. in embeddedsw/lib/bsp/standalone/src/arm/cortexr5/xil_cache.c

if adr+len > 2^32 (bad usage)
or adr+len == 2^32 (valid usage),
nothing will happen.

more dangerously, if (adr+len > 2^32 - cacheline) && (adr+len < 2^32) (also valid usage),
the while loop never terminates.

Most of the dma test examples have a block that looks something like this

#ifdef XPAR_AXI_7SDDR_0_S_AXI_BASEADDR
#define DDR_BASE_ADDR		XPAR_AXI_7SDDR_0_S_AXI_BASEADDR
#elif XPAR_MIG7SERIES_0_BASEADDR
#define DDR_BASE_ADDR	XPAR_MIG7SERIES_0_BASEADDR
#elif XPAR_MIG_0_BASEADDR
#define DDR_BASE_ADDR	XPAR_MIG_0_BASEADDR
#elif XPAR_PSU_DDR_0_S_AXI_BASEADDR
#define DDR_BASE_ADDR	XPAR_PSU_DDR_0_S_AXI_BASEADDR
#endif

The problem is that while the first preprocessor test is using an #ifdef the else statements check for a truth instead of an define. In many cases the base address will be 0 for XPAR_PSU_DDR_0_S_AXI_BASEADDR so the build results in a warning and picks a poor choice for the address. This bug is not just in the dma code, and #elif code that checks for an address should be using defined like this #elif defined(XPAR_PSU_DDR_0_S_AXI_BASEADDR)

Example here

in xaxicdma_hw.h:74:

#define XAXICDMA_MAX_TRANSFER_LEN 0x7FFFFF /**< Max length hw supports */

I think it should be 0x7FFFFF+1 because it's a length, not an offset. Using 0x7FFFFF as length in XAxiCdma_SimpleTransfer() I'm missing one byte.

The return value of XCanFd_ReadReg() is unused, Is that line necessary?

According to CAN FD v1.0 LogiCORE IP Product Guide Table 2-18 It doesn't state host reading of TX Buffer Ready Request Register affects anything.

Pls update the code of https://github.com/Xilinx/embeddedsw/blob/release-2018.3/lib/sw_apps/openamp_echo_test/src/system/freertos/machine/zynqmp_r5/helper.c#L23 app_gic_initialize function to make it compatible with FreeRTOS task scheduler.

Failed to generate xparameters.

The block design contains 4 uart_lite IP's that share one interrupt with a util_reduced_logic IP(in 'or' configuration), all the other interrupt sources have different drivers.

I think this error has something to do with assigning interrupts ID's. The interrupt numbers are incremented for each uart. Since the PS has only 16 interrupts the assigning fails on interrupt 17.

Error:
(XSDB Server)ERROR: [Hsi 55-1545] Problem running tcl command ::sw_scugic_v3_10::generate : expected integer but got ""
while executing
"format "#define XPAR_FABRIC_%s_%s_INTR %d$uSuffix" [string toupper $ip_name] [string toupper $port_name] $port_intr_id"
("foreach" body line 86)
invoked from within
"foreach periph $periphs {

    # get the gic mode information
    set scugic_mode [common::get_property CONFIG.C_IRQ_F2P_MODE $periph]

  ..."
(procedure "xdefine_gic_params" line 30)
invoked from within

"xdefine_gic_params $drv_handle"
(procedure "::sw_scugic_v3_10::generate" line 10)
invoked from within
"::sw_scugic_v3_10::generate ps7_scugic_0"
ERROR: [Hsi 55-1442] Error(s) while running TCL procedure generate()

In embeddedsw/lib/sw_apps/zynqmp_fsbl/src/xfsbl_qspi.c there is a global static structure for reading data from QSPI. The ReadID function will populate FlashMsg[1] with a dummy transaction. XFsbl_Qspi32Copy re-uses this structure and only conditionally sets FlashMsg[1] when it is needed.

The use of FlashMsg[1] is not dterministic when initiating a XQspiPsu_PolledTransfer call.
This also applies to XFsbl_Qspi24Copy.

Dont' know if I am posting in the right place, but in the
embeddedsw/lib/bsp/standalone/src/common/xil_testmem.c
I have the feeling that at line 167 and 181 the walk-ones test cycle should run for Words times, not only for 32 times.

XNullHandler is defined both in xil_assert.c and xbasic_types.c I think the one in xil_assert should be called xil_nullhandler or something.

Perhaps I'm doing something wrong, because I'm not sure why nobody else is noticing this.

Hi,

Does FreeRTOS for Xilinx support Contiguous Memory Allocation?

Thanks.

Hi,

I'm having trouble in Xilinx SDK, with creating a FSBL project for a hardware platform generated from Vivado 2018.2:

23:13:50 ERROR	: (XSDB Server)ERROR: [Hsi 55-1545] Problem running tcl command ::sw_intc_v3_7::generate : can't read "source_name(6)": no such element in array
    while executing
"string compare -nocase $source_name($i) "system""
    ("foreach" body line 18)
    invoked from within
"foreach periph $periphs {
        #update global array of Interrupt sources for this periph
        intc_update_source_array $periph

        lappend ..."
    (procedure "xredefine_intc" line 21)
    invoked from within
"xredefine_intc $drv_handle $file_handle"
    (procedure "xdefine_canonical_xpars" line 72)
    invoked from within
"xdefine_canonical_xpars $drv_handle "xparameters.h" "Intc" "DEVICE_ID" "C_BASEADDR" "C_HIGHADDR" "C_KIND_OF_INTR" "C_HAS_FAST" "C_IVAR_RESET_VALUE" "C..."
    (procedure "::sw_intc_v3_7::generate" line 57)
    invoked from within
"::sw_intc_v3_7::generate axi_intc_0"

23:13:50 ERROR	: (XSDB Server)ERROR: [Hsi 55-1442] Error(s) while running TCL procedure generate()

23:13:50 ERROR	: (XSDB Server)ERROR: [Hsi 55-1450] Error: running generate_bsp.

23:13:50 ERROR	: Error generating bsp sources: Failed in generating sources

From what I see, it fails in intc.tcl / xredefine_intc called for the axi_intc_0 component:

proc xredefine_intc {drvhandle config_inc} {
    ...
    foreach periph $periphs {
        ...
        for {set i 0} {$i < $num_intr_inputs} {incr i} {

            if {[string compare -nocase $source_name($i) "system"] == 0} {  <-- FAILS HERE
                continue
            }
        ...

Apparently, the code tries to access an nonexistent item of $source_name.

The connections of axi_intc_0 looks like:

HDF file:
ultra96_board_wrapper-hdf.zip

Any idea how to fix / workaround this?

Thanks,
Attila

I think there is a error in the XScuGic_InterruptMapToCpu function. In my opinion there should be a binary AND instead of an OR to clear the previous settings first.

Before:

    RegValue = (RegValue | (~(0xFF << (Offset*8))) );

After:

    RegValue = (RegValue & (~(0xFF << (Offset*8))) );

Also it should be specified what is meant with Cpu_Id. Because for Zynq we need either 1 for CPU0 and 2 for CPU1

In XIic_DynMasterSend why are the XIIC_INTR_TX_ERROR_MASK and XIIC_INTR_TX_EMPTY_MASK interrupts cleared and enabled AFTER writing the address and data to the TX FIFO? When trying to talk to a slave in reset, I am expecting a NACK event to be generated. However, code based on the dynamic eeprom example is getting stuck waiting for TransmitComplete to zero out and the status handler never gets called with the NACK event.
I believe this happens because by the time the interrupts are cleared and enabled, the address in the FIFO is already sent and the TX Error Status bit is set. Clearing and enabling interrupt will lose the NACK event with no handlers called.

Initially posted on Xilinx forums [1]: there is DMA cache incoherencies when using lwIP and the PS EMAC on a Zynq at high throughput. The problem can be reproduced by following the steps in described in the post [1].

We have a workaround in place where we force lwIP to re-do IP packets checksum and invalidate any that fail. This obviously slows down the CPU and the total throughput but at least we can once again believe that the data we are receiving is valid. A fix would be appreciated however.

[1] https://forums.xilinx.com/t5/Embedded-Processor-System-Design/FreeRTOS-lwip-driver-cache-issues-in-2018-2/td-p/879070

xilisf.c contains these global variables:

/*
 * The following variables are shared between non-interrupt processing and
 * interrupt processing such that they must be global.
 */
volatile unsigned int XIsf_TransferInProgress;
u32 XIsf_StatusEventInfo;
unsigned int XIsf_ByteCountInfo;
static u32 XIsf_FCTIndex;

But you are supposed to be able to have multiple XIsf instances, with their state stored in XIsf structures. Don't the global variables cause collisions between instances?

In commit: 7ec11fb

"=" has been added to this line:
while((ReceivedCount <= InstancePtr->ReceiveBuffer.RemainingBytes)&&

That creates a buffer overrun. Remaining will become 2^32-1 and keeps writing.

InputClockHz for uart seems to be hardcoded before setting proper configuration for baudrate in e.g.:

https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexa53/32bit/uart.c#L94

Hello!

I am working on ZYNQ 7020 and need to use OpenAMP libraries alongside with my application, it was developed in C++.

However, I realized that OpenAMP has issues if you try to compile with a C++ application. Let me show you the logs:

As you can see the issue is with the atomic library. It seems that the issue is related to the compilation with g++.

I appreciate any insight.

Thank You

Kevin

Hi, I think Xilinx should embed FreeRTOS-CLI into their bsp.

You may use FreeRTOS-CLI as a shell to interact with Zynq via usb or ethernet. And, you can also build demos around this CLI interface. I found it very useful in my personal project.

Hi, I am trying to build the example for the AXI DMA driver for a reference in how to use it. The make files are incomplete and probably bootstrapped by an external build system. Also, attempts to add all dependencies manually and setting the include paths, ended in not having the driver libs to link against. Therefore, would it be possible to add:

1. A guide how to build the drivers themselves
2. And examples
3. A link in the source to further documentation?

When disabling the software timers in the FreeRTOS BSP settings (freertos823_xilinx => software_timers => use_timers = false), the BSP does not compile

[...]
"Compiling FreeRTOS"
timers.c:84:3: error: #error configUSE_TIMERS must be set to 1 to make the xTimerPendFunctionCall() function available.
  #error configUSE_TIMERS must be set to 1 to make the xTimerPendFunctionCall() function available.
   ^
make[1]: *** [libs] Fehler 1
make: *** [ps7_cortexa9_1/libsrc/freertos823_xilinx_v1_0/src/make.libs] Fehler 2
[...]

The setting INCLUDE_xTimerPendFunctionCall cannot be configured through the BSP settings though.

• Situation:
  • adds uartps to hw design (but uartps is not a debug channel for the developer)
  • select another uart(ns16550) for STDIN and STDOUT in BSP(for fsbl) setting.
  • uartps should not make any output data on boot
• Problem:
  • fsbl hang on OutputStatus function (invalid baseaddress for uartps)
• Solution:
  • apply patch to main.c

 void OutputStatus(u32 State)
 {
 #ifdef STDOUT_BASEADDRESS
-#ifdef XPAR_XUARTPS_0_BASEADDR
+#if defined(XPAR_XUARTPS_0_BASEADDR) && (STDOUT_BASEADDRESS == XPAR_XUARTPS_0_BASEADDR)
 	u32 UartReg = 0;
 #endif
 
 	fsbl_printf(DEBUG_GENERAL,"FSBL Status = 0x%.4lx\r\n", State);
 	/*
 	 * The TX buffer needs to be flushed out
 	 * If this is not done some of the prints will not appear on the
 	 * serial output
 	 */
-#ifdef XPAR_XUARTPS_0_BASEADDR
-	UartReg = Xil_In32(STDOUT_BASEADDRESS + XUARTPS_SR_OFFSET);
+#if defined(XPAR_XUARTPS_0_BASEADDR) && (STDOUT_BASEADDRESS == XPAR_XUARTPS_0_BASEADDR)
+	UartReg = Xil_In32(XPAR_XUARTPS_0_BASEADDR + XUARTPS_SR_OFFSET);
 	while ((UartReg & XUARTPS_SR_TXEMPTY) != XUARTPS_SR_TXEMPTY) {
-		UartReg = Xil_In32(STDOUT_BASEADDRESS + XUARTPS_SR_OFFSET);
+		UartReg = Xil_In32(XPAR_XUARTPS_0_BASEADDR + XUARTPS_SR_OFFSET);
 	}
 #endif
 #endif
 }

thank you.

When Ethernet full-duplex communication is performed (especially at high rates - over 1Gb Ethernet), it is noticed that Tx side of communication becomes the dominant one and completely "kills" the Rx side. This problem is already described at [1]. Emac PS Tx handlers are much more frequent while Rx side is overflowed with "Receive over run" errors from Emac PS error handlers. We assume that the same thing is causing problem described at [2]. Investigation on this problem would be appreciated.

Thank you,
Nenad

P.S. The problem was also noticed while using FreeRTOS+TCP network stack. Check at [3].

[1] - https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-7000-LwIP-2-0-2-Low-RX-throughput-when-TX-is-active/m-p/870921
[2] - https://forums.xilinx.com/t5/Embedded-Processor-System-Design/LwIP-Unresponsive-Tx-path-amp-TCP-MSS-effect/m-p/880420
[3] - https://sourceforge.net/p/freertos/discussion/382005/thread/3bde8d1d/

I am running mcap on Ubuntu Linux LTS. I am able to run the clean (-C) command but the program (-p) commands generates dmesg errors and I believe goes into timeout. I need to do a full power cycle (cold boot) of the machine to get the communication back with the FPGA and mcap.

sudo ./mcap -x 0x8038 -C ../FPGA_programming/ver1_tpcie_update_region_partial_clear.bin

Gives:

Xilinx MCAP device found
FPGA partial configuration is performing. It might take a few minutes...Info: A partial reconfiguration clear file (-C) was loaded without a partial reconfiguration file (-p) as result the MCAP Control register was not restored to its original value
FPGA partial configuration done.

But: sudo ./mcap -x 0x8038 -p ../FPGA_programming/ver1_tpcie_update_region_partial.bin

Gives the following DMSG: (and the the OS gets support slow with no success)

2073.813839] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=125509 end=125511) time 48143 us, min 1073, max 1079, scanline start 1090, end 965
[ 2079.406307] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=125847 end=125850) time 48132 us, min 1073, max 1079, scanline start 458, end 332
[ 2081.528028] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=125974 end=125977) time 48138 us, min 1073, max 1079, scanline start 799, end 674
[ 2081.817252] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=125992 end=125994) time 48132 us, min 1073, max 1079, scanline start 72, end 1071
[ 2082.396226] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=126023 end=126026) time 48154 us, min 1073, max 1079, scanline start 1026, end 902
[ 2083.697043] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=126104 end=126107) time 48132 us, min 1073, max 1079, scanline start 957, end 959
[ 2085.673613] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=126220 end=126226) time 96314 us, min 1073, max 1079, scanline start 626, end 377
[ 2087.989219] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=126362 end=126365) time 48123 us, min 1073, max 1079, scanline start 432, end 305
[ 2090.158056] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=126489 end=126492) time 48137 us, min 1073, max 1079, scanline start 699, end 700
[ 2094.450190] [drm:intel_pipe_update_end [i915]] ERROR Atomic update failure on pipe A (start=126747 end=126752) time 96304 us, min 1073, max 1079, scanline start 169, end 46

uname -a returns:
xxxxxx 4.15.0-29-generic #31~16.04.1-Ubuntu SMP Wed Jul 18 10:19:08 UTC 2018 i686 i686 i686 GNU/Linux

Please comment on this, Thank yoU!

Hi to all,

I have been working on MicroBlaze with FreeRTOS Lwip Echo Server example. I use lwip in "Socket API" mode. But default project settings and configurations do not work properly. I start ping to FPGA and pings stop for a while. I started debug to code. I realized that this problem is derived from "Binary Semaphore" usage in "xemacif_recv_handler" function.

Let me explain problem step by step:

1. A packet is received from Emaclite within "xemacif_recv_handler()" interrupt funtion.

2. Packet is written to receive queue.

3. Binary Semaphore is given

After scheduler works , xemacif_input_thread takes the Binary Semaphore and read only one incoming packet from queue. Packet processing stuff goes on... and then xemacif_input_thread starts waiting the binary semaphore again.

But, if two packets are received from Emaclite before scheduler works(it means two packets arrived nearly at same time and xemacif_input_thread did not work yet), then the above steps are repeated except 3rd step. Because binary semaphore is already given when first packet received. But length of receive queue became 2. So it will cause an event lost.

After scheduler works xemac_input_thread takes the binary semaphore which is given by interrupt handler. And only one incoming packet is processed due to one binary semaphore. But now one packet is still waiting in receive queue. Because binary semaphore is given once however incoming packets keep writting to receive queue all time. So, counting of coming packets accumulating slowly.

I think that it would be better to use counting semaphore instead of binary semaphore in xemacif_recv_handler().

How can I solve this problem? Using counting semaphore enough? Do you have any idea?

Thanks...

-------------- Packet Processing Thread--------------------

#if !NO_SYS
/*

• The input thread calls lwIP to process any received packets.
• This thread waits until a packet is received (sem_rx_data_available),
• and then calls xemacif_input which processes 1 packet at a time.
  */
  void
  xemacif_input_thread(struct netif *netif)
  {
  struct xemac_s *emac = (struct xemac_s )netif->state;
  while (1) {
  / sleep until there are packets to process
• This semaphore is set by the packet receive interrupt
• routine.
  */
  sys_sem_wait(&emac->sem_rx_data_available); //Semaphore is waiting...

/* move all received packets to lwIP */
xemacif_input(netif); // Only one Packet is read from queue
}
}
#endif

-------------- Packet Received Interrupt--------------------

static void
xemacif_recv_handler(void *arg) {
struct xemac_s *xemac = (struct xemac_s *)(arg);
xemacliteif_s *xemacliteif = (xemacliteif_s *)(xemac->state);
XEmacLite *instance = xemacliteif->instance;
struct pbuf *p;
int len = 0;
struct xtopology_t *xtopologyp = &xtopology[xemac->topology_index];

#ifdef OS_IS_FREERTOS
xInsideISR++;
#endif

#if XLWIP_CONFIG_INCLUDE_EMACLITE_ON_ZYNQ == 1
#else
XIntc_AckIntr(xtopologyp->intc_baseaddr, 1 << xtopologyp->intc_emac_intr);
#endif
p = pbuf_alloc(PBUF_RAW, XEL_MAX_FRAME_SIZE, PBUF_POOL);
if (!p)
{
#if LINK_STATS
lwip_stats.link.memerr++;
lwip_stats.link.drop++;
#endif
/* receive and just ignore the frame.

• we need to receive the frame because otherwise emaclite will
• not generate any other interrupts since it cannot receive,
• and we do not actively poll the emaclite
  */
  XEmacLite_Recv(instance, xemac_tx_frame);
  #ifdef OS_IS_FREERTOS
  xInsideISR--;
  #endif
  return;
  }

/* receive the packet */
len = XEmacLite_Recv(instance, p->payload); // receive the packet from EmacLite

if (len == 0)
{
#if LINK_STATS
lwip_stats.link.drop++;
#endif
pbuf_free(p);
#ifdef OS_IS_FREERTOS
xInsideISR--;
#endif
return;
}

/* store it in the receive queue, where it'll be processed by xemacif input thread /
if (pq_enqueue(xemacliteif->recv_q, (void)p) < 0) //Write packet to queue
{
#if LINK_STATS
lwip_stats.link.memerr++;
lwip_stats.link.drop++;
#endif
pbuf_free(p);
#ifdef OS_IS_FREERTOS
xInsideISR--;
#endif
return;
}

#if !NO_SYS
sys_sem_signal(&xemac->sem_rx_data_available); // Semaphore is given
#endif
#ifdef OS_IS_FREERTOS
xInsideISR--;
#endif
}

Line 392 below subtracts 1 from the interval and multiplies by the timeout factor. However, for 128 packets-per-second, logMeanSyncInterval = -7 and XAvb_ConvertLogMeanToDuration converts -7 to 1. Then, when finally 1 is subtracted in line 392, a 0 multiplies the timeout factor. Ultimately, timeout always occur for this sync rate option.

Referring to commit 6a07f50 the use of L2 Cache is discouraged in Open AMP application since it can lead to unexpected behaviour as stated by @mubinsyed .

Based on that commit only the first section of the TLB is set to "inner cacheable", but not the entire L2-Cache. This seems to be inconsistent. I expected to have the whole DDR RAM being set to not cacheable or inner cacheable, but not only the first page.

I think this should read LPDDR4. At least on my system I use LPDDR4, but the memory test returns LPLPDDR2, which really does not make sense to me in the first place.

The following memory leaks exist in mcap_lib.c. The line numbers are based on the following version of mcap_lib.c: "8826f30 on Nov 23, 2015"

• Line 81 in MCapProcessRBT calls getline with raw = NULL. According to the getline man page "If lineptr is NULL, then getline() will allocate a buffer for storing the line, which should be freed by the user program.". raw is never freed.
• Line 617 in MCapConfigureFPGA does not close fptr before returning
• Line 649 in MCapConfigureFPGA does not free data or close fptr before returning
• Line 654 in MCapConfigureFPGA does not free data or close fptr before returning

In embeddedsw/ThirdParty/sw_services/openamp/src/open-amp/lib/system/freertos/bm_env.c
a value of 0 is returned when the semaphore creation fails, and 1 is returned if it succeeds.
These return values should be swapped in order to make them coherent with the library semantics.

In "embeddedsw/XilinxProcessorIPLib/drivers/uartps/examples/xuartps_intr_example.c"
XPAR_XUARTPS_1_INTR
should be
XPAR_XUARTPS_0_INTR
Just found that out "the hard way"...

On running mcap in root I am getting this error. "Unable to get the Register Base"

root $ ./mcap -x 0x7028
Xilinx MCAP device found
Unable to get the Register Base

Please help !!

THIS Makefile does not work. After assigning the C compiler (petalinux-v2018.3/tools/linux-i386/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc) make does this:

echo "Compiling axidma"
Compiling axidma
aarch64-linux-gnu-gcc -I../../../include *.c
In file included from xaxidma_bd.h:114:0,
from xaxidma_bd.c:61:
xaxidma_hw.h:64:10: fatal error: xil_types.h: No such file or directory
#include "xil_types.h"
^~~~~~~~~~~~~

etc. etc...

Pain in the rear here...

Hello,

I'm encountering an issue accessing a NAND flash device using the nandps v2.2 driver. Relevant geometry characteristics are:

• 8192 bytes per page
• 128 pages per block
• 8192 blocks, hence 1048576 pages in total.

My problem is, the driver can't seem to write the BBT (bad block table) at its proper location. I have tracked down the problem and determined that it is caused by this line at the end of the XNandPs_WriteBbt() function:
Offset = Desc->PageOffset * InstancePtr->Geometry.BytesPerPage;

In my case, the main BBT has to be written in block 8191, so Desc->PageOffset = 8191*128 = 1048448. Knowing that InstancePtr->Geometry.BytesPerPage = 8192, the right offset is 1048448*8192 = 8588886016 = 0x1FFF00000.
However, since both Desc->PageOffset and InstancePtr->Geometry.BytesPerPage are typed u32, the multiplication overflows in my build, and the offset is miscalculated as 0xFFE00000.

Note that I observed this undesired behavior using command-line arm-xilinx-eabi-gcc compiler, in both 4.8.3 and 4.9.2 versions.

I have found that explicitly casting both factors to u64 prior to multiplying them fixes the problem for me, so I will create a pull request containing this fix for both XNandPs_WriteBbt() and XNandPs_ReadBbt() functions.

The Rx buffer address location within the FlashMsg[x] struct (RxAddr64bit) is never set.

Value should be set to Destination Address (such as from u32 XFsbl_Qspi32Copy(u32 SrcAddress, PTRSIZE DestAddress, u32 Length))

Effect is that functionalities such as this call to XQspiPsu_Setup64BRxDma(const XQspiPsu *InstancePtr, XQspiPsu_Msg *Msg) will never be hit properly.

The documentation of XUsbPs_ConfigureDevice mentions a macro called XUsbPs_DeviceMemRequired() but it doesn't exist. A macro of the same name is mentioned in the examples as well. So the required size of the buffer is unknown. In the examples, I find a buffer size of 64*1024. But it is unclear where this "magic constant" came from or whether is enough for a given XUsbPs_DeviceConfig.

Also, XUsbPs_ConfigureDevice does currently not check the buffer size which seems like a bad idea to me. Also, the buffer size is currently not passed to XUsbPs_ConfigureDevice, since the XUsbPs_DeviceConfig structure lacks a field for the buffer size.

The computation of DeviceConfig.PhysAligned is wrong. It should round to the next multiple of 2048, but it will round 2048 to 4096, 4096 to (4096+2048), and so forth. Add only XUSBPS_dQH_BASE_ALIGN - 1 before masking out the lower bits. See the code below, which lacks the -1 and was taken from the latest version of xusbps_endpoint.c:

	/* Align the buffer to a 2048 byte (XUSBPS_dQH_BASE_ALIGN) boundary.*/
	InstancePtr->DeviceConfig.PhysAligned =
		(InstancePtr->DeviceConfig.DMAMemPhys +
					 XUSBPS_dQH_BASE_ALIGN) &
						~(XUSBPS_dQH_BASE_ALIGN -1);

Also, all examples pass an 32-byte aligned buffer - which is then rounded up to 2048-byte alignment. Shouldn't the examples pass a buffer with proper alignment instead?