ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft has quit []
cnxsoft has joined #linux-sunxi
Net147 has quit [Server closed connection]
Net147 has joined #linux-sunxi
wens has quit [Server closed connection]
wens has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
cnxsoft has quit [Server closed connection]
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
smaeul has quit [Quit: Down for maintenance...]
smaeul has joined #linux-sunxi
smaeul has quit [Quit: Down for maintenance...]
smaeul has joined #linux-sunxi
smaeul has quit []
smaeul has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
apritzel_ has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
aggi has quit [resistance.oftc.net charm.oftc.net]
aggi has joined #linux-sunxi
paulk1 has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
macromorgan is now known as Guest2732
macromorgan has joined #linux-sunxi
Guest2732 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
apritzel_ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit []
apritzel_ has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Arthur[m]123 has joined #linux-sunxi
gnarface has quit [Read error: Connection reset by peer]
gnarface has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
apritzel_ has joined #linux-sunxi
gamiee2 has joined #linux-sunxi
gamiee2 has quit []
machinehum has joined #linux-sunxi
<ynezz> hi, in u-boot there is https://github.com/u-boot/u-boot/blob/master/board/sunxi/gmac.c#L19 CONFIG_GMAC_TX_DELAY being set, but I can't find that counterpart in kernel drivers/clk/sunxi/clk-a20-gmac.c
<ynezz> how is that tx delay set in kernel?
<ynezz> is simply kernel relying on that reg being set properly by uboot?
evgeny_boger has joined #linux-sunxi
hlauer has joined #linux-sunxi
<gamiee> ynezz: Hi, i'm not sure, but this can give you hint https://github.com/torvalds/linux/commit/bd5431b2f9b30a70f6ed964dd5ee9a6d1c397c06
JohnDoe_71Rus has quit []
<ynezz> ah, ok, so uboot uses delay in gmac and linux in phy
ftg has joined #linux-sunxi
vagrantc has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<apritzel> ynezz: so do the two patches fix Ethernet on the Lime2 for you? Or is there more to fix?
<ynezz> apritzel: IIUC that 2nd patch is noop on lime2, since there is no support in uboot to configure rgmii tx/rx delays for ksz9031 phy
<ynezz> so actually to get working uboot I need to set CONFIG_GMAC_TX_DELAY=4 to get usable networking in uboot
<apritzel> ynezz: looking closer it seems indeed that nothing in Linux is setting this CCU register
<ynezz> yeah, that's my latest finding, when uboot sets delay on gmac and linux sets delays on phy, the delays might be off
<ynezz> there is currently CONFIG_GMAC_TX_DELAY=0 in A20-OLinuXino-Lime2-eMMC_defconfig, so it probably works for revisions with Realtek PHYs
<ynezz> I need CONFIG_GMAC_TX_DELAY=4 in A20-OLinuXino-Lime2-eMMC_defconfig for my K revision with Micrel PHY
<ynezz> but I can't set it in that config, because it would probably break previous revisions using Realtek PHYs
<ynezz> ideally that gmac tx delay would be set from DT
<apritzel> ynezz: well, yes, that code is very old, and it's in the wrong place anyway
<ynezz> apritzel: so what do you suggest, what would be upstreamable solution? :)
<apritzel> ynezz: do you know of anything that tells apart a revK from the previous versions (apart from the different PHY)?
<ynezz> nope
<apritzel> ynezz: so did this work with the Micrel PHY before?
<ynezz> apritzel: yes, it was working, otherwise I wouldn't trying reverting that change
<ynezz> apritzel: I just found out, that it was probably working due to the following downstream hack https://github.com/openwrt/openwrt/blob/master/package/boot/uboot-sunxi/patches/063-fix-lime2-revK-add-micrel-PHY.patch#L41
<apritzel> huh, I see. So you should definitely have that CONFIG_PHY_MICREL_KSZ90X1=y in both defconfigs, that shouldn't hurt the older revisions
<ynezz> so with that hack, that gmac delay was set and so with that phy-mode change in kernel rgmii -> rgmii-id another delay was added in phy, thus breaking networking with that switch
<apritzel> in Linux, you mean?
<ynezz> yes
<ynezz> while looking into it, I've compiled latest uboot master, which is missing that tx delay hack and network doesn't work in uboot as expected
<ynezz> and thus setting CONFIG_GMAC_TX_DELAY=4 obviously made network working in uboot again, but I can't do that, as it would probably break that Realtek PHY revisions
<ynezz> BTW that CONFIG_PHY_MICREL_KSZ90X1=y seems to be enabled already
<apritzel> ynezz: but for the eMMC defconfig only, right?
<ynezz> yes
<aggi> greetings. don't want to interrupt, stumbling with a toolchain and the linker adding stuff, which it didn't before:
<ynezz> libv: wow, thanks a lot, gold mine of information
<aggi> # ldd bin/ls; libgcc_s.so.1 => /usr/lib/gcc/armv7a-hardfloat-linux-musleabihf/4.7.4/libgcc_s.so.1 (0xe502b000)
<aggi> since recently, for an unknown reason, with the toolchain in question, the linker decides to link almost all binaries against libgcc_s.so.1
<aggi> which it didn't before, again for an unknown reason (too many details to mention)
<aggi> anyway, question, is this expected armv7a-hardfloat links against libgcc_s.so.1 ? it may do so with softfp i suspect, yet it's hardfloat.
<libv> ynezz: our wiki often is that :)
<apritzel> aggi: do you know what triggers the linking? some division routines, maybe?
<aggi> and, i've found one symbol being suspicios from libgcc: __aeabi_unwind_cpp_pr0; which i don't know if/why/when gcc/linker decide to enforce it's presence
<ynezz> apritzel: thanks a lot for help!
<aggi> with 64bit operations libgcc_s may be required; however i think it is the unwind symbol
<apritzel> ynezz: so it looks like the Linux Micrel PHY drivers know how to compensate timing, by using the pad skew settings mentioned in the datasheet
<apritzel> but the U-Boot PHY driver does not
<aggi> anyway, sorry for the noise; my mind slipped after days of fiddling with gentoo stage-tarballs
<ynezz> apritzel: yeah, I'll probably disable the MAC delay in U-Boot and leave the Linux with current rgmii-id and see if it works
<ynezz> will report back next week, when I'm back home
<aggi> it would be helpful if anyone could confirm linking against libgcc with armv7a-hardfloat is expected or not
<apritzel> ynezz: there is *some* delay code in the U-Boot PHY driver, but no specific values, just on/off
<apritzel> aggi: IIUC if the toolchain pulls in libgcc_s depends on many factors, namely its configuration, but also the functions you use and the optimisation level, for instance
<aggi> apritzel: -O2
<aggi> if you got any armv7 box nearby and ldd /bin/ls ?
<ynezz> apritzel: where specificaly?
<apritzel> aggi: bah, 32-bits ... but what comes to mind is integer divisions, for instance, which are not supported even with hardfloats unless you have armv7ve, and thus might be provided by libgcc_s
<aggi> apritzel: strange then. for example, if this is of any interest, a cross-compiled toolchain does not link against libgcc_s; and a natively compiled toolchain later does
<aggi> with the exact same optimization (yet some other side-effect could be triggered by the somewhat complicated toolchain scripting)
<apritzel> ynezz: ah wait, that's 9131 code
<aggi> and i think it is this symbol at fault __aeabi_unwind_cpp_pr0
<aggi> ok then. seems linking against libgcc seems common to do (although i do not appreciate the idea the linker adds stuff not explicitely asked for)
<ynezz> apritzel: 22:10:25 < ynezz> apritzel: IIUC that 2nd patch is noop on lime2, since there is no support in uboot to configure rgmii tx/rx delays for ksz9031 phy :)
<ynezz> that's why I've provided only Tested-by: for patch 1/2
<apritzel> aggi: you asked it for, *implicitly*, but using functions that the hardware doesn't support, like divisions or 64-bit arithmetic
<apritzel> aggi: and the toolchain decided to not inline the functionality (if that would be even an option for that particular feature)
<aggi> /bin/ls doesn't do neither 64bit arith or division; there isn't any the eabi symbols for this
<aggi> *of
<apritzel> aggi: have you tried to explicitly disable exception handling? for instance with -fno-unwind-tables -fno-asynchronous-unwind-tables
<aggi> it is __aeabi_unwind_cpp_pr0 which caused linkage against libgcc with all binaries non-reproducible
<aggi> apritzel: yes, tried those two switches; no difference
<apritzel> aggi: can you objdump the generated binary and figure out who uses this symbol?
<aggi> interesting: in bin/ls nothing is using this symbol; nothing in libc.so
<aggi> nonetheless ldd bin/ls shows this symbol, provided by libgcc_s.so.1 here
<aggi> objdump -x is what i used
<apritzel> does objdump -d list it?
<aggi> yep, my mistake, same with objdump -d which shows the symbol names, yet without __aeabi_unwind_cpp_pr0
<aggi> so, the linker insisted on linking of the symbol which isn't used anywhere, which is again irritating
<aggi> anyway, probably some side-effect; not important, i'll make a minor hack in the toolchain for the linker search path to prevent some build error, suffices for now
* aggi has a suspicion to discuss elsewhere
<aggi> apritzel: thanks nonetheless.
evgeny_boger has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest2762
macromorgan has joined #linux-sunxi
Guest2762 has quit [Read error: Connection reset by peer]