<calebccff>
Tartarus: thx for the ping... sorry i've been getting pulled into tf-a stuff lately. I sent lore.kernel.org/u-boot/20241030003317.2901772-2-caleb.connolly@linaro.org which I hope fixes this, don't have the hardware to easily test though
<Tartarus>
calebccff: OK, thanks, I'll give it a spin here
<calebccff>
regarding clang, I built with it once to use __builtin_dump_struct() and I think it all "just worked" (except the pre-processor defconfig stuff)
* calebccff
off to bed, hopes CI passes
naoki has joined #u-boot
warthog9 has quit [Quit: Leaving]
warthog9 has joined #u-boot
qschulz has quit [Remote host closed the connection]
sfo has quit [Read error: Connection reset by peer]
sfo has joined #u-boot
lane has quit [Read error: Connection reset by peer]
d4ve has quit [Read error: Connection reset by peer]
lane_ has joined #u-boot
d4ve_ has joined #u-boot
d4ve_ is now known as d4ve
slobodan has joined #u-boot
samekh has quit [Ping timeout: 272 seconds]
zenomat has quit [Ping timeout: 276 seconds]
d4ve has quit [Ping timeout: 264 seconds]
lane_ has quit [Ping timeout: 264 seconds]
sfo has quit [Ping timeout: 260 seconds]
bryanb has quit [Ping timeout: 272 seconds]
zenomat has joined #u-boot
zenomat has quit [Read error: Connection reset by peer]
lane has joined #u-boot
sfo has joined #u-boot
samekh has joined #u-boot
d4ve has joined #u-boot
bryanb has joined #u-boot
zenomat has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
mmu_man has joined #u-boot
rber|res has quit [Quit: Leaving]
Stat_headcrabbed has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
bryanb has quit [Ping timeout: 246 seconds]
lane has quit [Ping timeout: 272 seconds]
samekh has quit [Ping timeout: 272 seconds]
sfo has quit [Ping timeout: 272 seconds]
zenomat has quit [Ping timeout: 246 seconds]
d4ve has quit [Ping timeout: 246 seconds]
naoki has quit [Quit: naoki]
lane has joined #u-boot
zenomat has joined #u-boot
sfo has joined #u-boot
samekh has joined #u-boot
d4ve has joined #u-boot
bryanb has joined #u-boot
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Client Quit]
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Client Quit]
Stat_headcrabbed has joined #u-boot
<Guest88>
can anyone tell me who calls this function "fecmxc_recv"? I have turned on the logs and see this function is polled continuously. I am trying to debug where my receiving data is being lost on ethernet framework. Is device.c is the nearest one can go to hardware?
helene has quit [Ping timeout: 246 seconds]
Danct12 has quit [Ping timeout: 252 seconds]
wooosaiiii1 has joined #u-boot
Lightsword_ has joined #u-boot
m5zs7k_ has joined #u-boot
jclsn_ has joined #u-boot
zenomat_ has joined #u-boot
Guest88 has quit [Quit: Client closed]
senzilla_ has joined #u-boot
qschulz has quit [Ping timeout: 252 seconds]
Danct12 has joined #u-boot
Lightsword has quit [Quit: ZNC]
alan_o has quit [Remote host closed the connection]
Sout_ has quit [Excess Flood]
m5zs7k has quit [Quit: m5zs7k]
Lightsword_ is now known as Lightsword
qschulz has joined #u-boot
zenomat has quit [Read error: Connection reset by peer]
lehmanju has quit [Quit: Ping timeout (120 seconds)]
prabhakalad has quit [Remote host closed the connection]
indy_ has joined #u-boot
tlwoerner has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
jclsn has quit [Remote host closed the connection]
wooosaiiii has quit [Remote host closed the connection]
xroumegue has quit [Ping timeout: 276 seconds]
senzilla has quit [Read error: Connection reset by peer]
lehmanju5 has joined #u-boot
wooosaiiii1 is now known as wooosaiiii
slobodan has quit [Read error: Connection reset by peer]
senzilla_ is now known as senzilla
alan_o has joined #u-boot
bryanb has joined #u-boot
prabhakalad has joined #u-boot
Sout_ has joined #u-boot
quinq has quit [Ping timeout: 252 seconds]
lehmanju5 is now known as lehmanju
quinq has joined #u-boot
m5zs7k_ is now known as m5zs7k
agraf has joined #u-boot
helene has joined #u-boot
Guest47 has joined #u-boot
warpme has joined #u-boot
<Guest47>
marex perhaps you could answer my question stated above
xroumegue has joined #u-boot
indy_ is now known as indy
ikarso has quit [Quit: Connection closed for inactivity]
monstr has joined #u-boot
<marex>
guest47: what question ?
<Guest47>
marex can anyone tell me who calls this function "fecmxc_recv"? I have turned on the logs and see this function is polled continuously. I am trying to debug where my receiving data is being lost on ethernet framework. Is device.c is the nearest one can go to hardware?
dsimic has quit [Ping timeout: 265 seconds]
dsimic has joined #u-boot
flokli has quit [Ping timeout: 245 seconds]
Jones42 has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]
<marex>
net/eth-uclass.c: ret = eth_get_ops(current)->recv(current, flags, &packet);
<marex>
net/net.c: eth_rx();
<marex>
net.c net_loop() calls eth_rx() which calls ->recv callback of FEC or whatever other registered netdevice
<Guest47>
marex thanky you very much for your response. That's what I thought as well. I want to go however more deeper next to hardware to find out the journey of incomming packets. I am getting the IP from DHCP-Server which can be traced through wireshark. However it gets lost somewhere before fecmxr_recv can access it, somewhere between PHY and MAC. I
<Guest47>
thought maybe device.c would be the deepest I can go. Is it correct?
ikarso has joined #u-boot
alpernebbi has quit [Ping timeout: 245 seconds]
<marex>
guest47: the FEC DMA dumps packets into DRAM, so you should either see the packets in the fec .recv callback or the packet is corrupted when it enters FEC
<marex>
try 'dcache off' and see if that "fixes" it ... if so, it might be some cache issue
<marex>
which U-Boot version is this ?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mmu_man has quit [Ping timeout: 252 seconds]
<Guest47>
marex I am using 2024.4. Once I call dhcp I get https://paste.mozilla.org/WF0WVPOC various times and then it gets aborted. In u-boot's console do I have to do dcache off?
alpernebbi has joined #u-boot
monstr has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<marex>
guest47: oh, is that the NXP downstream fork for 700k+ LoC changed ?
mmu_man has joined #u-boot
<Guest47>
marex yes it's from NXP
<marex>
oh ok, then please ask NXP for support with their downstream heavily modified fork
<marex>
guest47: or try current mainline and see if the problem persists
<Guest47>
marex thank you very much for your help! Should I still try ''dcache off' or would it be of no use
mckoan is now known as mckoan|away
Guest47 has quit [Quit: Client closed]
<marex>
I do not have experience with NXP downstream fork, I do not know, sorry
slobodan_ is now known as slobodan
eballetbo has quit [Quit: Connection closed for inactivity]