I am looking for a simple example of how to power up the PFE sub system and setting up the appropriate clocks. I have a driver that I have written that should work on a native A53 (no Linux). The clocks never come up. I know that prior to me working on this logic I could not get the PFE registers to even read now they read but not everything is working and I have traced it down to this.
Here is the basic code to init the subsystem (this is very fragmented and not clearly explain by NXP) so any source example would be appreciated.
therefore it does not come out of reset */
Hello @aaronbaranoff,
We do not have any specific documentation regarding the HIF and its ring buffers. To this point I have already shared all documentation regarding the PFE, there is no more documents we have on that. That said, you can check section 2.1 Network Interfaces of the LNX PFE Driver User Manual or section 11.5.2 Configuration example and 11.7 Egress QoS of the PFE FCI API Reference.
Regarding the Tx and Rx of packets 'without the complexities', I'm afraid that there is no way to avoid the PFE complexities if you want to take advantage of it, if you prefer you can use the GMAC module, which is quite simpler, however you will need to handle all the operations in the main core.
Do you have any documnetion on HIF particularly the ring buffer structure and the registers?
On a seperate not so I can get it transmitting nad recieving packets without the complexities. How do I transmit and recived via the DEBUG FIFO interface in the MTL.
Hello @aaronbaranoff,
I took the dump just before sending any frames, to show the PFE registers configuration.
To know exactly how to send packages using PFE, I strongly recommend you check the PFE MCAL API, in particular, check the function calls starting from example_application\src\sample_app_ethswt_eth.c, in Tst_Pfe_SendDummyFrame() there is a call to the API Eth_43_PFE_Transmit(), the MCAL code includes a lot of runtime and compilation checks that may not be useful to you, you can strip the code as you require, however that is the best reference on how to use the PFE send functionality.
Thanks
None of the registers in the Red area are NOT accessible (readback 0 always). I can’t talk to them and your PFE code does not seem to use them (otherwise I would expect them to have non-zero values), so that seems to confirm the DMA interface is missing on the instantiations of the GMACs used for the PFE. So, the only way to send raw packets out of the PFE MACs is via the Slave interface (not documented by NXP) or the Debug Interface (which the registers are documented but not the sequence). Please Help and confirm or correct my suspicions.
Thank you for the dump.
When I compare your register settings and mine. I find you have no ring buffers or list addresses set up for any queues/channel.s How then are you sending packets? Clearly not the documented DMA interface. Is that inteface disabled on the PFE MACs? If so how do I send packets?
Hello @aaronbaranoff,
Sorry for the late reply, here is the complete dump for all the PFE EMAC registers, from 0x460A8000-0x460A936C, you can check it with any hex viewer.
This dump was taken after finishing all initialization.
I noticed a diff in values with the following location.
EL1N0xFFFF0000460A8800 you have a value of 0x00003FF7 the issue is that is not a documented register? What is it?
After stating at you PFE configuration I realized it too was not fully initilalized. You had yet to write to the list addresses (or you can't)
| 0x00000000 | EL1N:0xFFFF0000460A9114 | 00000000 | 0x00000000 |
| 0x00000000 | EL1N:0xFFFF0000460A9118 | 00000000 | 0x00000000 |
| 0x00000000 | EL1N:0xFFFF0000460A911C | 00000000 | 0x00000000 |
I addition can you dump and compare the register settings for the ACCEL_PLL per the documention we are setting it to 600 Mhz.
Make sure the PFE_MAC_2 and the clocks are fully enabled prior to the compare.
I am confused or am I missing something. Our PFE setting I believe are close enough (MAC addresses, and other non-critical settings). But our CGM_2 settings are way off. Maybe the differs were captured on your side were before they were setup.
For PFE_MAC2 according to the documention (see images below).
CGM_2 Mux 0 needs to be set to 33 ACCEL_PLL_PH1_CLK (That we match)
CGM2 Mux 3 needs to be set to PERIPH_PLL_PHI5_CLK (I have that set but you are pointing to FIRC_CLK)
CGM2 Mux 6 needs to be set to PFE_MAC2_RX_CLK(I have that set but you are pointing to FIRC_CLK)
Hello @aaronbaranoff,
Here are the differences I found, same format as last time. For the MC_CGM_2 I stopped the program in the same line as last time, for the PFE_EMAC I stopped here:
Let me know if the behavior is different after the changes.
One more data point. I even tried putting the PFE_MAC2 in loopback (via the MAC_CONFIGURATION) register bit 12. Still can't talk to those DMA related registers.
Hello @aaronbaranoff,
Thanks for the information, Please allow me some time to check those registers.
I will get back to you as soon as possible
Could you also compare my MC_CGM_2 registers to yours. I Think there is some clock that is missing and since all the PFE clocks are in that section.
Here is the registers just prior to me not being able to successfully write to DMA_CH0_RxDesc_Ring_Length and to DMA_CH0_RxDesc_List_Address. When I write to them and read back the value it reads back 0 even though I write a valid address.
I however can sucessfuly get the link status, write and readback registers like the MAC address.
This code is virtually identical to the code we are sucessfully using control the GMAC. But, on the PFE_MAC2 it does not allow use to read and write to certain registers. (mostly DMA related). In addition to the register comparison. Are the any other things outside of the PFE_MAC2 needed to enable its DMA (addition clocks or resets)?
So in my code. I added checks and the following fail.
- DMA_CH0_TxDesc_List_Address (failed readback)
- DMA_CH0_TxDesc_Ring_Length (failed readback)
- DMA_CH0_RxDesc_List_Address (failed readback)
- DMA_CH0_RxDesc_Ring_Length (failed readback)
- MTL_TxQ0_Operation_Mode (is correct value but I can’t modify it)
- MTL_RxQ0_Operation_Mode (is correct value but I can’t modify it)
- MAC_RxQ_Ctrl0 (does not allow accept the write values)
Hello @aaronbaranoff,
You mean the registers in the PFE EMAC correct? this is, the same registers described in the GMAC reference manual.
If so, can you share a dump of all the registers, so that I can compare them with the registers state of the demo app just before sending.
Thanks in advance.
It behaves as if the internal clocks are not correct. But since the Subsystem bug does not let us read the status it is hard to tell. I have verified the PIn Mux is setup to the correct pins and the clocks look like they are setup correctly.
Thank you for the diffs. The only surprise was the CLKENs for the blocks inside the PFE were not set in the code you. Is that a known issue? I guess it is ignored or not needed.
| 0x0000000F | EL1N:0x0000000040088530 | 00000000 | 0x00000000 | X |
OK, my PFE GMAC has come out of reset and I have valid link status. However, I have one more issue. All the registers outside of the DMA read and write, I can see our writes written as expected. But the DMA ones (TX or RX) seemed to allow us to write (no errors) but the value does not stick (it reads back 0). Is there something else that I am missing. It is like there is an extra external step I need to get the PFE GMAC to come to life that is not documented.
Hello @aaronbaranoff,
Sorry for such a delay in my reply. I was finally able to obtain the differences in the registers just before configuring the PRTN2_COFB0_CLKEN register, you can find them in the xlsx file attached, you will find the differences marked with a red "X", each register dump is in a different page.
My registers were taken in this context:
Hello @aaronbaranoff,
Thanks for all the info. I tried testing the PFE Demo application, however with the S32 Debug Probe I have encountered some problems that lead to a hard fault. I will need to test this with a Lauterbach debugger, as suggested in the description the demo app. However, I do not have one with me at this exact time, I will need to get one next week and perform the tests.
Regards the call, me and my team do not handle calls with customer, moreover, it usually takes me quite some time to find relevant information for a reply.
Sorry for the delay on the relevant reply.
What time zone are you in maybe when can work interactively.
Also added S32G_GPR
Attached are the registers dumbs (in excel from the debugger)
Hello @aaronbaranoff,
As mentioned, it seems that the fact that MC_ME.PRTN2_COFB0_STAT.R is 0 is a know issue with only a workaround for now, skipping the check. The next thing I can think of to find the root cause is to compare your registers to mine, Please send a register dump of the MC_ME whole register rage, just before configuring PRTN2_COFB0_STAT, that way I can compare it to one of the available examples.
Thanks
I even tried pushing this to the very early stages in the bootloader and had the same results.
MC_ME.PRTN2_COFB0_STAT.R is 0 (it should 0xf)...
WHY?!?
Still no luck. PFE Partition does not fully initialize. The block clocks do not enable. There is no clear documentation on the expected sequence. The turn-on process is in Figure 148 of the S32G2 Reference Manual but it does not mention the block clocks (PRTN2_COFB0_STAT or PRTN2_COFB0_CLKEN). I am hoping some other user who has had luck with this can post an example bit of code. It comes out of reset and the PCS flag says the clocks are enabled but the block clocks don't get enabled but, not clue as to why. I even trying taking the exterenal clocks out of the picture. by using the FIRC.
After setting up (PFE_MACx_RX_CLK, PFE_MACx_TX_CLK, PFE_PE_CLK) to used the default FIRC. PFE partition still comes out of reset but the block clocks being enabled is ignored. I have tried that moving the block clock enable before and after the rest of the is PFE partition out of reset also no impact.
I have tried in EL1 and EL3 modes. I have even trying ignoring the PRTN2_COFB0_STAT regardless of my attempts to enable via PRTN2_COFB0_CLKEN REQs if I ignore the status that then I can read the PFE registers but writing to some registers fail and the behavior is not correct. See Table 195.
I am using the RDB2 board (untill our board is ready) but have not had any luck.
Hello @aaronbaranoff,
Can you elaborate on this statement? "but the block level clocks do not enable. If I ignore the status the behavior is that I don't get link status although I can read many of the PFE GMAC registers when I write to the DMA registers the values don't stick."
I have checked the documentation and just as you, I did not see anything specific considering EL3 vs EL0, however, I would recommend using EL0 to avoid any issue accessing the memory regions.
I have replicated NXP's code but added checking. The PFE subsystem comes out of reset but the block level clocks do not enable. If I ignore the status the behavior is that I don't get link status although I can read many of the PFE GMAC registers when I write to the DMA registers the values don't stick.
I believe that the status is a clue but get NO insight as to why. I have enabled the clocks and the pin mux prior to the PFE init.
Are there any other rules about being in EL1 vs EL3 mode or similiar I don't see any in the documention.
Hello @aaronbaranoff,
Thanks for the reference on the AUTOSAR driver bug, I checked internally the change related to that bug fix, the function that got changed is Power_Ip_MC_ME_ConfigureCOFB(), you can see the final implementation in the RTD 5.0.0 QLP3. For what I understand, the problem is not in the writing part of the process, but when reading to verify, you will see in the function that when POWER_IP_MC_ME_PRTN2_COFB0_STAT_RESERVED is defined ad STD_ON the validation for PartitionIndex is skipped. Checking the configuration files for any S32G you will see POWER_IP_MC_ME_PRTN2_COFB0_STAT_RESERVED is true, for example: Resource_TS_T40D11M50I0R0\resource\CORTEXM_S32G2XXM7_s32g274a_bga525.properties:
what I understand is that there is a known issue with that register validation and for now skipping it is the know workaround.
Even the AUTOSAR code reports issues with similar things but no solution or clarity.
What I am asking is not driver specific. This is a simple register (reference manual) question.
I am trying to get Blocks 0-3 to have their clocks enabled in PRTN2_COFB0_STAT. Even if I wanted to use your driver per 47.4 I need to (Enable PFE COFB clocks in MC_ME as described in the "MC_ME partition 2 mapping" section in this document.)
This is basic sequence but it does not work and the datasheet does not give any insight as to anything else that is needed. The partition comes out of reset and Figure 148 in the Reference Manual does not cover enabling the block clocks inside the partition.
MC_ME.PRTN2_COFB0_CLKEN.B.REQ0 = 1;
MC_ME.PRTN2_COFB0_CLKEN.B.REQ1 = 1;
MC_ME.PRTN2_COFB0_CLKEN.B.REQ2 = 1;
MC_ME.PRTN2_COFB0_CLKEN.B.REQ3 = 1;
MC_ME.PRTN2_PCONF.B.OSSE = 1;
MC_ME.PRTN2_PUPD.B.OSSUD = 1;
MC_ME.PRTN2_PCONF.B.PCE = 1;
MC_ME.PRTN2_PUPD.B.PCUD = 1;
/* Tell hardware to check above registers for changes */
Write_Control_Key();
After this I read PRTN2_COFB0_STAT but the status never shows the clocks enabled.
Hello @aaronbaranoff,
Thanks for reaching out to us again. At the movement I cannot share any resource that I have not shared before, for instance, the reference manual, FCI API documentation and code or code samples. Since the SW support for the A53 is very focused on Linux and the PFE being such a complicated module, I cannot offer you much support by looking at your program, I can suggest the same I always do, to check the already offered implementations and adapt them to your needs.
I can check internally if there is any plan to release more documents related to the PFE initialization, however I cannot ensure there will be anything helpful for your case.
I will get back to you