<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?
<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]