On 9/25/26 3:29 PM, Anders Roxell wrote:
On 2026-09-17 18:13, Anshul Dalal wrote:
On Wed, 16 Sep 2026 14:38:00 +0200, Anders Roxell <[email protected]>
wrote:
[...]
ums. Love tested v7 on AMD/Xilinx boards. The rest is build tested only.
One thing is still open. Anshul sees a single "unknown endpoint event 0"
line on AM62p during enumeration. It is there with and without the cache
patch, and the transfers work anyway. I do not see it on X15, and we do
not know yet if it is older than this series.
The transfers work regardless, if it helps the issue seems to be in the ep0.c
file.
CC + Chintan, Siddharth
Hi Anshul,
Thanks. That is what I would expect. If the whole event word is 0 it
decodes as endpoint 0 with event 0, and then it ends up in the default
case in dwc3_ep0_interrupt(). So it does not tell us where the 0 comes
from yet.
I think my two questions from the earlier mail [1] got lost:
1. Do you see it on plain mainline, without my patches? If it is there
too then the resync did not cause it, and it can be fixed on its own.
If mainline is clean then I broke it, and then it has to be fixed in
this series.
2. Can you print the raw word and send me what it says? If it is
00000000 we read an empty slot. If other bits are set it is a real
event, and we decode it wrong.
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ static void dwc3_process_event_entry(struct dwc3 *dwc,
const union dwc3_event *event)
{
+ printf("evt raw %08x\n", event->raw);
+
if (!event->type.is_devspec)
Chintan, Siddharth, if one of you has an AM62p or a BeaglePlay, the
answer to 1. is the one I need most.
When I had first enabled USB DFU Boot on AM62P, I had tested it and had
included the logs as well.
Patch series is at:
https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/
Test Logs are at:
https://gist.github.com/Siddharth-Vadapalli-at-TI/50198ee3348c2db73e0dbd3a14cb0f8b
I didn't see "unknown endpoint event 0" at that point, so this series seems
to introduce a regression.
Regards,
Siddharth.
