sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
michalkotyla has quit [Quit: michalkotyla]
michalkotyla has joined #u-boot
mckoan|away is now known as mckoan
monstr has joined #u-boot
apritzel has joined #u-boot
guillaume_g has joined #u-boot
ldevulder_ is now known as ldevulder
sszy has joined #u-boot
apritzel has quit [Ping timeout: 260 seconds]
lucaceresoli1 has joined #u-boot
lucaceresoli has quit [Quit: Leaving]
zibolo has joined #u-boot
apritzel has joined #u-boot
lucaceresoli1 has quit [Quit: Leaving]
mmu_man has joined #u-boot
tucanae47_ has quit [Quit: Connection closed for inactivity]
michalkotyla has quit [Read error: Connection reset by peer]
michalkotyla has joined #u-boot
zibolo has quit [Ping timeout: 272 seconds]
torez has joined #u-boot
MrSaturn has joined #u-boot
<MrSaturn>
Hi all. Having a bit of a strange issue: imx6 <--> pd83867 phy. Getting about 500kB/s when the link is 1000baseT-FD. (slower for lower speeds). Any idea what some easy things to rule out are?
<marex>
check if your link isn't actually 10/Half for some reason, check the MII interface , skews
<marex>
did it ever work in 1000/Full e.g. in Linux? If so, compare PHY and MAC registers
<MrSaturn>
marex, I have looked at the mii registers... there are are few that I am not sure I can access with "mii" - 0x86 return 0xFFFF which doesn't make any sesne as the the upper bits are always 0.
<MrSaturn>
But for the most part, things are as expected. I will try the linux test. It will take a bit, as I am builting the rootfs now.
<georgem>
How are you testing? With tftp?
<MrSaturn>
georgem: yes. I have a devboard with the same processor and am able to get ~16MB/s
<georgem>
ah. ok. interesting
<MrSaturn>
different phy
<MrSaturn>
Also a different yocto layer. I am wondering if something weird with the clocks.
<georgem>
maybe. try running wireshark on the machine running the server and see if there are retransmissions or any other kind of issue.
<georgem>
Once a hardware engineer put in the wrong capacitor value off of one of the lines on a board I was working on and it resulted in a similar sounding problem.
<MrSaturn>
georgem: https://imgur.com/a/k4oLJad Everything looks pretty good to me I don't see anything marked as retry
<georgem>
there I don't either but that's only a small part of the transfer
<MrSaturn>
I scrolled down I transfered an 8MB file
<wyre>
kabel, I know already what was happening
<wyre>
the problem is the version that comes flashed as brand new in the SoM
<wyre>
from the provider, I mean
<wyre>
when I flash the u-boot.imx built along my image files it works as expected
<MrSaturn>
Forty-Bot: Is there a better protocol for grabbing files?
andr01d has quit [Read error: Connection reset by peer]
andr01d has joined #u-boot
cdsteinkuehler has quit [Quit: Client closed]
<MrSaturn>
Stupid question about ethernet: mii reads and writes go through the (RG)MII interface, and MDIO commands go through the MD* interface. What is the division in functionality? Also... is there a way to access extended registers with the "mii" command?
monstr has quit [Remote host closed the connection]
<marex>
MrSaturn: mii goes through MDIO bus, it's like an I2C bus right next to the MII bus (thats the high speed connection through which the ethernet traffic is going)
<MrSaturn>
So what is the difference between the mii reads and the mdio reads?
<marex>
rfried: ^ time to unify the mdio/mii commands
<cambrian_invader>
with in-band "autonegotiation" you can do commands over mii...
<cambrian_invader>
or rather, read responses
<marex>
cambrian_invader: that's supported ? :)
<cambrian_invader>
nope
<cambrian_invader>
well, by Linux
<cambrian_invader>
I think in U-Boot we just let the driver handle it
mmu_man has quit [Ping timeout: 272 seconds]
<marex>
;-)
<MrSaturn>
https://pastebin.com/UvXAfkhJ <--- this is what I am seeing when I try "mii read 2 0x86" I don't know if anyone has some advice.
<MrSaturn>
Many of the other (lower numbered) registers read correctly.
<marex>
We value your privacy
<marex>
please use paste.debian.net or so, something which doesn't have ton of ads and popups
<cambrian_invader>
marex: get tom to put some better pastebins in the topic
<marex>
check these things in your board config , or git grep for them in other board configs ...
<marex>
there is GPR reg in IOMUXC which selects 125 MHz clock direction (either generated by PHY or SoC CCM), and then the CCM clock are also configured some way
vagrantc has joined #u-boot
<MrSaturn>
marex: I don't see that in the board init... I don't see any calls to external functions that would do that, either.
<MrSaturn>
oh man
<MrSaturn>
Although, to be fair - the development board doesn't either
<MrSaturn>
ret = enable_fec_anatop_clock(FEC_MXC_0, ENET_125MHZ);
<MrSaturn>
found it
<marex>
make sure this is set correctly
<marex>
there is no FEC_MXC_0 symbol in mainline U-Boot ?
<MrSaturn>
It is defined as 0.
<MrSaturn>
Hrmm, there are lots of debug prints. I should figure out how to turn those on.
<marex>
add #define DEBUG 1 at the beginning of the file, then debug() gets turned into printf()
<marex>
anywhere before include <common.h> works iirc
<MrSaturn>
so it looks like the order is - Configure IO, setup the clocks, reset the phys, then there is a manual command (fecinit) that needs to be run to intialize the ethernet. It looks like all of those are being run.
prabhakarlad has quit [Quit: Client closed]
<MrSaturn>
Hrm... I haven't considered that the DDR could be misconfigured in u-boot. Does that even sound possible?
sobkas has joined #u-boot
mckoan is now known as mckoan|away
<MrSaturn>
Huh... there appears to be quite a bit of latency (ping is > .300ms)
alan_o has quit [Ping timeout: 240 seconds]
<MrSaturn>
Wow, his is really wild. So in linux - tftp I get ~2MB/s. Still pretty bad. wget I am seeing ~22MB/s. I am having a hard time explaining how I am seeing 16MB/s on the development board through tftp
alan_o has joined #u-boot
apritzel has quit [Ping timeout: 260 seconds]
<marex>
MrSaturn: what is manual command 'fecinit' ?
<marex>
the ethernet works without any manual commands
<cambrian_invader>
does CONFIG_SYS_NAND_BLOCK_SIZE change the units of nand_spl_load_image?
<MrSaturn>
marex: This system has ethernet disabled by default. It has something to do with gpio conflicts on boot. I haven't quite tracked down how they accomplished that (CONFIG_DM_ETH=n, so perhaps that would do it)
<MrSaturn>
I am trying to grapple how a misconfiguration would effect tftp/udp but not http/tcp.
<marex>
MrSaturn: are you using mainline u-boot or some downstream fork of nxp downstream fork btw ?
<MrSaturn>
marex: It is u-boot-imx with some patches. Let me check the recipe and see where it comes from. If you can't tell, this isn't hardware I very familiar with :)
<marex>
hum, 283000 lines added compared to v2021.04 mainline ...
<MrSaturn>
yuck
apritzel has joined #u-boot
<MrSaturn>
I am still not sure what they are doing to prevent the network from coming up on boot. They obviously took the mx6sabresd.c and modified it quite heavily.
<MrSaturn>
I see. On boot the phys are configured, but the mac is saved for the custom command (hence the name, fecinit and not netinit)
<MrSaturn>
#ifndef CONFIG_DM_ETH
<MrSaturn>
/* Disable FEC intialization at startup. This is workaround * to power cycle ping issue we saw during burn-in */
<marex>
there is no netinit in mainline u-boot either
<marex>
I think you really need to talk to your vendor about this, this is some non-standard crap
prabhakarlad has joined #u-boot
<MrSaturn>
I was just making that point that they could have called the command "macinit" because the phy was already configured.
<marex>
you don't need any custom commands if your board port is done property, the network just works in that case
<marex>
so maybe what you're debugging here is broken hardware
<marex>
and broken software on top of it
<MrSaturn>
I would love to have them fix this, but we are not their customer. We have no sway on this.
<MrSaturn>
Tracing through manual configuration of ethernet is pretty mind numbing.
<marex>
MrSaturn: is this a publicly available devkit ?
<MrSaturn>
Unfortunately no. I would love to share more. The board file is pretty whacky.
<MrSaturn>
I am probably chasing something I won't find. This hardware: Linux + wget = 22MB/s, Linux + tftp = 2MB/s, u-boot + tftp = 500KB/s. Devboard: u-boot + tftp = 16MB/s. The numbers are all over the place, and the 2MB tftp in linux is really concerning.
<MrSaturn>
the closest configuration I can find is the udoo/neo/
<rfried>
Hi. What's Michal Simek nick ?
<marex>
rfried: monstr, you just missed him
<marex>
rfried: wait till monday
<rfried>
marex: np, just delegating some patches to him
<marex>
MrSaturn: this is something to ask your board vendor about
<marex>
MrSaturn: if they provided poor software with insane amount of changes, they have to be able to help you