rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
sunshavi has quit [Remote host closed the connection]
Ntemis has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 272 seconds]
ChriChri_ is now known as ChriChri
jo0nas has quit [Ping timeout: 260 seconds]
lurchi_ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-sunxi
<megi> hmm, opi3 ethernet doesn't work with phy/rgmii-id, while opi pc 2 does
<megi> though changing allwinner,{t,r}x-delay-ps makes it work again...
<tuxd3v> megi, are you in 5.9.1?
<megi> why?
<tuxd3v> I have a one plus too(H6)
<tuxd3v> and I saw clement comment above
<tuxd3v> :)
<megi> I'm testing opi3
<megi> with 5.9.0
<tuxd3v> I believe its better to jump to 5.9.1 the last because of a bug that afects a lot of releases..I don't know if it hapen also in arm, but I assume so...its Bluetooth related, so not to worrie
<tuxd3v> anyway, you managed to solve the ethernet with 5.9, with {t,r}x-delay-ps?
kaspter has joined #linux-sunxi
<tuxd3v> they have a 200 by default I think
<tuxd3v> I was thinking in doing that, but you beat me :)
<megi> I changed dts to phy-mode = "rgmii-id" and *-delay-ps to <200>
<megi> seems to work fine without packet loss
<megi> your board already has delays set to 200ps
<tuxd3v> yes, was what I saw
<tuxd3v> so I assume it should world then..
[CONFIDENTIAL] is now known as [messymystic]
<tuxd3v> world -> work :)
<megi> maybe, it still has phy-mode = "rgmii", though
<tuxd3v> yes it has
<tuxd3v> I will try with the actual situation, and later with 'rgmii-id'
<tuxd3v> one problem that I have in one plus, is that if I reboot, ethernet is lot
<tuxd3v> it doesn't come up
<megi> do you have my patches?
<tuxd3v> now would be nice to test with this change
<tuxd3v> I believe not
<megi> they fix that
<tuxd3v> how?
<megi> by turning off phy regulators before reboot
<megi> so after reboot the situation is the same as on first poweron
<megi> or this whole branch, really: https://megous.com/git/linux/log/?h=opi3-5.9
kaspter has quit [Ping timeout: 264 seconds]
<tuxd3v> megi, many thanks
kaspter has joined #linux-sunxi
<tuxd3v> I didn't knew about that, I was suspecting of gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
<tuxd3v> the power signal that enables the power for the controller
jo0nas has joined #linux-sunxi
<tuxd3v> probably it doesn't activate, because of the lost state ..thinking that it was already up
<megi> problem is that the other regulator never turns off
<megi> and this one does
<megi> phy gets messed up by only half of the regulators being up
<megi> and never recovers
<tuxd3v> I see it makes sense now
vagrantc has quit [Quit: leaving]
<tuxd3v> I supose that code will land on 5.10?
<tuxd3v> I mean that patch
<megi> no
<megi> it was already rejected long time ago
<tuxd3v> but its a fix..
<tuxd3v> does someone purposed something diferent?
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
lurchi_ has quit [Remote host closed the connection]
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 256 seconds]
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Client Quit]
megi has quit [Quit: WeeChat 2.9]
megi has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
sunshavi has quit [Ping timeout: 260 seconds]
lurchi_ is now known as lurchi__
TheSeven has quit [Ping timeout: 244 seconds]
TheSeven has joined #linux-sunxi
sunshavi has joined #linux-sunxi
<wens> CONFIG_VIDEO_SUNXI in U-boot is getting disabled by default now
lucascastro has joined #linux-sunxi
lucascastro has quit [Ping timeout: 265 seconds]
zoobab has quit [Ping timeout: 260 seconds]
<wens> megi: the delay supported by rtl8211e is 2ns, so 200 ps working is kind of weird
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 260 seconds]
chewitt_ has joined #linux-sunxi
chewitt has quit [Ping timeout: 260 seconds]
chewitt_ has quit [Client Quit]
lucascastro has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
zoobab has joined #linux-sunxi
asdf28 has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 258 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 264 seconds]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
reinforce has joined #linux-sunxi
cmeerw has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
msimpson has joined #linux-sunxi
msimpson has quit [Remote host closed the connection]
lynxis has quit [Remote host closed the connection]
lynxis has joined #linux-sunxi
eduardas has joined #linux-sunxi
ldevulder__ is now known as ldevulder
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-sunxi
<megi> wens: that's a delay in the SoC ethernet controller
<wens> megi: right. but if it was working before the realtek phy patch, then broke, then worked again after applying 200 ps delay, that doesn't really make sense
gediz0x539 has joined #linux-sunxi
<megi> the delay was 1500ps/700ps (rx/tx)
<megi> still, I don't know why it broke
<megi> anyway, setting any delay between 100ps and 700ps works, as long as it is the same for both rx/tx
florian_kc has joined #linux-sunxi
<montjoie> does someone have some hint to enable uboot network opi1+, I tried syncdtb,add CONFIG_SUN8I_EMAC=y and CONFIG_MACPWR="PD6"
<montjoie> but it fail with "Could not get PHY for ethernet"
<wens> megi: because the PHY can provide a 2ns delay for RX/TX, and most boards have it enabled by default (using pull-ups).
<wens> megi: the phy driver patch "fixed" the configuration of the feature using PHY registers, so now if the DT says "rgmii" instead of "rgmii-id", the driver disables the delays on the PHY, messing up the timing
<megi> yes, but I have rgmii-id, and I was expecting this would result in the same behavior as before (the board has pull-ups)
<megi> but it broke, and I needed to adjust the allwinner eth controller delays
<megi> I changed it to "rgmii-if" in expectation that leaving phy-mode = "rgmii" would break the ethernet, after the 5.9 phy fix clementp[m] warned about
<megi> instead rgmii-id
<megi> eh, english :) rgmii-if is just typo
<wens> so IIUC you changed it to rgmii-id, but still needed to change {t,r}x-delay-ps
<megi> yes
<wens> makes even less sense lol
<megi> precisely :)
<megi> it will be interesting to see if tuxd3v's Orange Pi One Plus will also break with change to rgmii-id
florian_kc is now known as florian
<wens> a can of worms for the new kernel
<karlp> megi: re " by turning off phy regulators before reboot" doesn't that meant that say, watchdog resets will still fail to come up?
<karlp> relying on shutdown to work properly seems like pushing problems to the future.
<megi> yes, but it's the easiest fix :)
<megi> for the most common case
<karlp> hrmmm.
AneoX has joined #linux-sunxi
atsampson has quit [Ping timeout: 272 seconds]
<montjoie> anyone enabled uboot network in opi1+ ? probably I miss something but cannot find what
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
atsampson has joined #linux-sunxi
chewitt has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
diego71 has quit [Ping timeout: 240 seconds]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
jstein has joined #linux-sunxi
jstein has quit [Client Quit]
diego71 has joined #linux-sunxi
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
\\Mr_C\\ has joined #linux-sunxi
lurchi_ is now known as lurchi__
AneoX has joined #linux-sunxi
lurchi__ is now known as lurchi_
DonkeyHotei has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
DonkeyHotei has quit [Ping timeout: 260 seconds]
<montjoie> I found that on opi1+, sunxi_name_to_gpio(MACPWR) return -22
tnovotny has joined #linux-sunxi
<montjoie> false error, MACPWR is well set...
froese has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #linux-sunxi
parazyd has quit [Quit: leaving]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
parazyd has joined #linux-sunxi
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 256 seconds]
tnovotny has quit [Quit: Leaving]
cmeerw has quit [Ping timeout: 244 seconds]
The_Loko has joined #linux-sunxi
<atsampson> Aha - I guess that rgmii-id thing is why I didn't have an Internet connection this morning!
<atsampson> (My router's a pcduino3-nano, which has an RTL8211E and uses rgmii, and it rebooted into 5.9.1 overnight...)
kaspter has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has joined #linux-sunxi
kaspter has joined #linux-sunxi
tnovotny has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
matthias_bgg has quit [Quit: Leaving]
eduardas has quit [Quit: Konversation terminated!]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 260 seconds]
KotCzarny has quit [Quit: brb]
KotCzarny has joined #linux-sunxi
cmeerw has joined #linux-sunxi
florian has quit [Quit: Leaving]
Putti has quit [Ping timeout: 265 seconds]
pmp-p has quit [Quit: No Ping reply in 180 seconds.]
pmp-p has joined #linux-sunxi
Putti has joined #linux-sunxi
putti_ has joined #linux-sunxi
Putti has quit [Disconnected by services]
putti_ is now known as Putti
gaston1980 has joined #linux-sunxi
damex has quit [Ping timeout: 246 seconds]
damex has joined #linux-sunxi
<matteo_> hello! Does anybody have any detail about the DDR3 memory in the Allwinner S3?
<matteo_> we designed a module with the S3 onboard, to release as Open HW/FOSS and we just received the first run of prototypes
<matteo_> we started with the u-boot config for a V3s (in the 2019.10 release) and of course the memory is not detected
<matteo_> (no config headers for it, just for the V3s)
<matteo_> so ... we need to write those headers, I guess
<matteo_> but the DRAM section in the S3 datasheet is a one-liner: "One built-in DDR3 memory is in the S3 processor."
<matteo_> not very useful =)
<matteo_> I have applied to Sochip for access to their developers SDK, but somehow I feel like I won't get a reply
<jernej> matteo_: DRAM code is usually reverse engineered from libdram, which is found in the SDK
<jernej> and IIRC V3s is DDR2 only
<matteo_> yup, the V3s is DDR2
<matteo_> which is why the V3s u-boot won't detect the DDR3 on the S3, I guess =)
<jernej> but maybe you could reuse H3 DDR3 code, AFAIK they have very similar DRAM controller
<matteo_> yup, AFAIK the controller is the same in H3, V3s and S3
<matteo_> what I think I need to put together is an S3 equivalent of arch/arm/mach-sunxi/dram_timings/ddr2_v3s.c
[messymystic] is now known as [generic]
<jernej> are you sure that's necessary?
<jernej> can't be current code reused directly?
<matteo_> well, not as-is: I just tried a build and u-boot does not detect the RAM
<jernej> megi: OrangePi 3 ethernet works well for me on 5.9, without any additional changes vs. 5.8
<matteo_> jernej: here is the output: https://blog.elimo.io/2020/10/19/board-bringup/
willmore has quit [Ping timeout: 240 seconds]
<matteo_> jernej: I am guessing the changes wouldn't be radical, but I would need to know which parameters to change to what =)
<megi> jernej: good to know, I didn't even try without a patch :)
<jernej> megi: I included your patches for regulator handling but nothing else
<matteo_> jernej: I was not, thanks
<megi> I already merged changes into those patches
<jernej> well, they are from old branch
<jernej> I didn't update them quiet some time
<megi> ok
jstein has joined #linux-sunxi
<tuxd3v> jernej, does you tried to reboot and see if ethernet comes up?
<jernej> yes, several times
<tuxd3v> on 5.8 it doesn't for me on orangepi one plus
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
<jernej> I don't have One Plus but I also didn't receive any complaints
<jernej> about it
luke-jr has joined #linux-sunxi
[generic] is now known as [Zer0CheaT]
willmore has joined #linux-sunxi
willmore has quit [Ping timeout: 240 seconds]
willmore has joined #linux-sunxi
<matteo_> jernej: applied the patch, still the same result
<matteo_> it seems to me that the issue is not the init of the DRAM controller itself, but rather the timings of the DRAM that's used in the S3
macifom has joined #linux-sunxi
<jernej> do you have any kind of working image?
<matteo_> nope
<matteo_> I am not aware of any publicly available build for the S3
<matteo_> but the Mandarin commit message says that he couldn't get u-boot to even start
<jernej> having libdram or any kind of working image for S3 (not necessarily your board) would be very helpful
<jernej> since code could be REd then
<matteo_> yeah, I know
<matteo_> that's why I tried to apply for access to Sochip's SDK repo
<matteo_> AFAIK the S3 is a partnership between Allwinner and Sochip
<matteo_> and they have an eval board and SDK
<matteo_> but access to the SDK is restricted via an approval process
<matteo_> god knows if anybody is even checking the mailbox you have to write to...
Kasreyn has quit [Quit: leaving]
xes__ has joined #linux-sunxi
xes_ has quit [Ping timeout: 272 seconds]
froese has quit [Quit: Leaving]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
lurchi__ is now known as lurchi_
vagrantc has joined #linux-sunxi
lurchi_ is now known as lurchi__
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
camus1 is now known as kaspter
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
cmeerw has quit [Ping timeout: 272 seconds]
jstein has quit [Quit: quit]
tnovotny has quit [Quit: Leaving]
The_Loko has quit [Quit: Leaving]
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
asdf28 has quit [Ping timeout: 256 seconds]
Mangy_Dog has quit [Ping timeout: 240 seconds]