<longsleep>
apritzel: hey, i am currently looking into 1000m mode of pine64 in sunxi-mac - did you see those comments in there about some A version which does not work with 1000M ?
<apritzel>
longsleep: no, but I was remembering some other issue yesterday
<apritzel>
the DT node for the MAC was wrong in the BSP kernel
<apritzel>
the first region is the MAC register interface, which is fine, the second region is the EMAC clock register, which starts at offset 0x30 and is 4 bytes lon
<apritzel>
I stumbled upon this in December, when I first looked at this driver
<apritzel>
montjoie: do you care to share the link to your H3 Ethernet driver in development with longsleep?
<longsleep>
apritzel: as i said, 100 Mbit works find and good, but 1000 does not send or receive anything
<longsleep>
s/find/fine
<longsleep>
i am tempted to disable gbit in the driver and roll an image
<apritzel>
please do not waste too much time with this crappy kernel
<apritzel>
I can write up an elaborate rant on the reasons - if that wouldn't be wasted time too ...
<apritzel>
do you have CONFIG_CPU_OPS_SUNXI defined?
<longsleep>
apritzel: well - i do it as excercise - i have to work with another Kernel from Amlogic which is similar crappy and want to have a base for comparison
<longsleep>
apritzel: nope # CONFIG_CPU_OPS_SUNXI is not set
<apritzel>
great, so you are mainlining Odroid C2 support, then? :-P
<longsleep>
not that but might have to use it at work
<longsleep>
but as it does not have SPI we will see
<apritzel>
I based it on the right commit and the diff looked much more usefl
<longsleep>
well true, i might rebase it eventually
<longsleep>
but i rather would prefer to get rid of the android stuff
<longsleep>
but - speaking of waste of time :)
IgorPec has quit [Ping timeout: 240 seconds]
<apritzel>
yeah ...
<longsleep>
so - "ethtool -s eth0 speed 100 duplex full" , ethernet works at once
<longsleep>
ethtool -s eth0 speed 1000 duplex full - stops working at once
<longsleep>
libphy detects the link just fine in both modes
<longsleep>
but in 1000m nothing gets through
<longsleep>
apritzel: how would the CONFIG_CPU_OPS_SUNXI option be related?
<apritzel>
well, 1000M and 100M is using a different protocol (RGMII vs MII) and also needs the PHY and the clocks to be configured differently
<apritzel>
so it's not really a surprise that one works while the other is broken
IgorPec2 has quit [Ping timeout: 264 seconds]
<apritzel>
(if they have a bug in their kernel)
<longsleep>
ok - in the dt i see phy-mode = "rgmii";
<apritzel>
CPU_OPS_SUNXI is apparently a leftover from Allwinner's early experiments
<apritzel>
it just wouldn't work with the current firmware
<apritzel>
so it's not related to this issue
<apritzel>
but when I saw this code I decided to not look any further into that kernel
<longsleep>
yeah - wise choice
<apritzel>
you should do the same ;-)
<apritzel>
I'd rather see you debugging on the mainline kernel :-)
<longsleep>
well - i can do that as well but i seem to be unable to help very much as of device tree fun
<apritzel>
I see a good chance that we have most features working by summer - apart from 3D, that is
<apritzel>
but at least 2D acceleration and video seems to be within reach
<longsleep>
yeah true - 3D might as well never happen
<apritzel>
never say never ;-)
MY123 has joined #linux-sunxi
<longsleep>
but dont you feel that having stable images with the BSP Kernel would be of no value in the meantime?
<KotCzarny>
depends
<MY123>
GPL seems to be now invalid in China
<apritzel>
please don't use stable and BSP in the same sentence
<KotCzarny>
if all you need is getting box up and running without caring for anything else
<MY123>
damn
<longsleep>
apritzel: right, lets nay not crashing
<longsleep>
say
<MY123>
laws
<apritzel>
KotCzarny: you can use the Android image for that purpose
<apritzel>
and install a SSH server app
<KotCzarny>
apritzel, does one get all onboard devices working?
<longsleep>
apritzel: i could build an not crashing Arch Linux image now, which would work to play around with the board and use it as server. Except that i would like to have 1000M
<KotCzarny>
(but i agree, having proper drivers is better)
<apritzel>
KotCzarny: with which kernel? the BSP one?
tkaiser has joined #linux-sunxi
<KotCzarny>
apritzel, right now im using opipc with the droid kernel i think
<longsleep>
apritzel, KotCzarny well my intention was to get Ubuntu Snappy running - i could do it now as i have full U-Boot and full Kernel control.
<longsleep>
So both points checked based on BSP sources. But for Snappy the rest does not matter so much.
<apritzel>
longsleep: btw: did you see that I got upstream U-Boot running, with booti support?
<apritzel>
loaded by boot0
<longsleep>
apritzel: oh thats cool - no i did not - i want to integrate that then. SO u-boot does no longer link to libdram?
<apritzel>
no, I adjusted the TEXT_BASE to be 1.5KB later and prepended a header recognized by boot0
<apritzel>
I just use the main U-Boot image, no SPL
<apritzel>
also I hacked the booti command to use Allwinner's ATF 64-bit jump
<apritzel>
nasty hack, but works
<longsleep>
yes i saw that one
<apritzel>
but I lost SMP on the way, I guess it's due to the PMIC now not being programmed properly
<apritzel>
which the BSP U-Boot did
<longsleep>
so you got rid of the ATF as well?
<apritzel>
no, but I never wanted to do so
<apritzel>
instead I still use their version with some fixes
<apritzel>
as soon as Linux support is on the way, I will make a proper port of ATF
<longsleep>
ok - sounds like something i want to try next weekend