Reset BMAN Buffers in DPAA

[mehmetcelik]

Hi,

We are using the Netcomm codebase and ported the DPAA Normal Mode driver to our board having P2041 processor. We have used the driver successfully for quite some time. Then we decided to use the ethernet driver in the bootloader as well.

Now, we are having a problem when both the bootloader and the application software initializes and uses the DPAA hardware. We are looking for a way to reset BMAN, and hopefully QMAN as well.

The bootloader creates 100 buffers in Buffer Pool 0 in BMAN. Similarly, the application adds 100 buffers to the same buffer pool in BMAN. Now, there are 200 buffers in the pool but the application expects the 100 buffers only. Besides, the application does not want any buffer that had already been placed in BMAN, because the addresses might not be in the allowable range.

In the DPAA documentation and the Netcomm code, we couldn't find a way to reset BMAN, so that we cannot get rid of the buffers created by the bootloader.

We had a similar issue for QMAN, in frame queues and found a workaround. However, tt would be great to be able to reset QMAN as well. 

Thank you for your help,

Best Regards,

[Goker]

Hello Mehmet,

I know the question was too old but did you remember how to solve the issue?

[yipingwang]

Hello Mehmet Celik,

Please refer to the following sequence to issue a QMAN/BMAN warm reset.

1. Software shuts down software portal interfaces (stops de-queueing new work from QMAN and stops enqueueing new work to QMAN).

This can be achieved by having the driver software stop doing enqueues and dequeues.  If for some reason this isn't possible, then the SW portals can be disabled.  This can be done using the register DEBUG_CFIFO (for BMan) and QCSP_DD_IHRFR_i (for QMan).  These are documented in the DPAA RM

2. Software quiesces FMAN.

a. This is needed because FMAN doesn't support hardware directed stop/stop_ack protocol that the COP logic leverages to get all other DPAA clients quiesced as part of the QMAN/BMAN warm reset process that it manages.
b. This is a process to get FMAN to the state where it is no longer enqueueing to / de-queueing from QMAN (stop adding entries to frame queues by stopping or dropping receive traffic and stop pulling new work from QMAN).

3. Software writes QMAN/BMAN warm reset register (QMBM_WARMRST) in DCFG block . Note that QMAN and BMAN must be reset together/concurrently since BMAN's software portal logic is physically part of QMAN and there is nothing worthwhile to be accomplished in just resetting BMAN.

4. The Reset block manages resetting QMAN/BMAN.

5. Software polls QMBM_WARMRST to know when warm reset has completed.

6. Software re-initializes QMAN/BMAN. This may include clearing out any history it has of QMAN portal ring state as well as forgetting about buffers it may not have previously released.

7. Software starts using QMAN/BMAN and DPAA again, including restarting FMAN.Step 6 seems to indicate that the warm reset may not completely reinitialize the logic the way a Hard Reset will.     

Thanks,

Yiping

[mehmetcelik]

Hi Yiping,

Thank you for your response. We couldn't find any information nor register map for the following registers in QorIQ Data Path Acceleration Architecture (DPAA) Reference Manual document or P2040 QorIQ Integrated Multicore Communication Processor Family Reference Manual of P2040/P2041 documentation.

DEBUG_CFIFO

QMBM_WARMRST in the DCFG block.

Can you please give more information (register map/offset addresses) of these registers?

Thank you,

[cstreece]

For T-series (FMAN v3, MEMAC) the DCFG registers are documented in the SoC reference manual.

For P-Series (DTSEC) there does not seem to be the same functionality.