jstein has quit [Remote host closed the connection]
chomwitt has quit [Ping timeout: 255 seconds]
_whitelogger has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
lurchi__ is now known as lurchi_
ninolein has joined #linux-sunxi
lurchi_ is now known as lurchi__
ninolein_ has quit [Ping timeout: 260 seconds]
bier33_ has joined #linux-sunxi
bier33 has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
BenG83 has joined #linux-sunxi
pg12_ has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 255 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Read error: Connection reset by peer]
guest267 has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
terra854 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
halex has quit [Ping timeout: 240 seconds]
halex has joined #linux-sunxi
leviathan_ has joined #linux-sunxi
guest267 has quit [Remote host closed the connection]
_whitelogger has joined #linux-sunxi
BenG83_ has quit [Remote host closed the connection]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
_whitelogger has joined #linux-sunxi
techping has joined #linux-sunxi
techping has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
jernej has quit [Ping timeout: 260 seconds]
jernej has joined #linux-sunxi
ThibG has joined #linux-sunxi
<ThibG>
Hi, I'm still experiencing seemingly-random MMC failures on an A20-OLinuXIno-LIME2 board. I changed units and µSD card, so this is almost definitely a driver issue
<ThibG>
I'm using Debian on this board, and have been running old versions of u-boot and linux (4.0) with (I think) different issues (freezes under load, which I assume was because of the DRAM settings in earlier u-boot)
<ThibG>
When I switched to recent u-boot and linux versions (4.9 at the time), I started having those MMC failures: at seemingly random points, when dealing with the µSD card, the µSD card reader would get stuck (presumably requiring a cold reboot)
<ThibG>
On the other hand, I have been running Arch Linux ARM for a few weeks on other A20-OLinuXIno-LIME2 units for a few weeks with no issue so far
<ThibG>
But this issue is really frustrating to tackle, as I have found no reliable way to trigger the failure yet: regardless of the CPU or I/O load, it may trigger within hours, or after weeks
<diego71>
ThibG: Arch linux which version of kernel does it use?
<ThibG>
$ uname -r
<ThibG>
4.11.2-2-ARCH
<diego71>
So is it possible, that was fixed in later kernel?
* diego71
was wondering if it is possible to bisect it?
<ThibG>
diego71, well, it is possible it was fixed in 4.11, I'm not sure
<ThibG>
about bisecting, well, since I don't have a reliable way to trigger it…
<diego71>
ThibG: it means it require some time, I know the pain ...
LargePrime has quit [Ping timeout: 260 seconds]
<ThibG>
I tried to do it between versions provided by Debian, but there are a few caveats: in some occurrences it took 2~3 weeks before triggering this issue, which means I was never sure whether I correctly marked a kernel as ok
<ThibG>
also, my methodology turned out to be wrong, as I soft-rebooted to another kernel when I found no issue (since that's a pretty low-level error that apparently requires a cold reboot to get back from, I'm not sure booting a “correct” kernel after a “wrong” one would avoid the crash)
<ThibG>
lastly, I'm not 100% sure it's a linux issue and not a u-boot one…
<diego71>
I'm going to test a recent debian installer on a spare lime2 just to see what happens...
<ThibG>
thanks!
<ThibG>
I'm now running the latest 4.11 snapshot provided by Debian (there's still no package for the release), as well as u-boot from Arch, to see if things are better…
scream has joined #linux-sunxi
<diego71>
I've found a lime2 with debian jessie + kernel 4.9.0-0.bpo.1-armmp-lpae
chomwitt has joined #linux-sunxi
<ThibG>
yeah, that's what I was running at some point (but not sure about the exact u-boot version)
terra854 has quit [Quit: Connection closed for inactivity]
LargePrime has joined #linux-sunxi
<ThibG>
thanks again, I've been dealing with this bug for months now and it makes my personal server pretty unreliable (I'm particularly worried about mails getting lost when the MMC subsystem is down)
<diego71>
I've a personal server on a20-micro, so I'm interested in checking this too, before upgrading to stretch :)
<diego71>
u-boot version is: U-Boot 2014.10+dfsg1-5
<ThibG>
I think I was using 2016.11+dfsg1-4
<ThibG>
(the point was to avoid the DRAM clock issue)
wookey has quit [Ping timeout: 240 seconds]
dev1990 has joined #linux-sunxi
kloczek has quit [Ping timeout: 240 seconds]
wookey has joined #linux-sunxi
kloczek has joined #linux-sunxi
viktor has joined #linux-sunxi
lemonzest has joined #linux-sunxi
clonak_ is now known as clonak
Gerwin_J has joined #linux-sunxi
BenG has joined #linux-sunxi
BenG is now known as Guest70263
leviathan_ has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
perr has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
clonak has quit [Ping timeout: 240 seconds]
clonak has joined #linux-sunxi
Keziolio has quit [Ping timeout: 246 seconds]
viktor has quit [Ping timeout: 260 seconds]
Keziolio has joined #linux-sunxi
leviathancn has joined #linux-sunxi
techping has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
jstein_ has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
jstein_ is now known as jstein
techping has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Ping timeout: 260 seconds]
terra854 has joined #linux-sunxi
techping has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
paulk-elm has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
JohnDoe7 has joined #linux-sunxi
JohnDoe7 has quit [Client Quit]
JohnDoe9 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
<diego71>
ThibG: I got a "BUG: Bad page state in process dhclient pfn:7d69e" on the lime2
<diego71>
I wonder if it is related to the dram clock issue
<diego71>
(and how to check it)
cnxsoft has quit [Quit: cnxsoft]
kloczek has joined #linux-sunxi
<ThibG>
I'm using pure Debian
<ThibG>
well, except for u-boot
<ThibG>
(which used to be from Debian, but right now is from Arch)
<ThibG>
that BUG doesn't ring a bell here, but maybe I've overlooked it
lurchi_ is now known as lurchi__
perr has quit [Quit: Leaving]
lurchi__ is now known as lurchi_
<diego71>
ThibG: and does u-boot from arch works fine also with debian?
<diego71>
(u-boot in debian have memory clock=384 so it should be fine too ...)
<ThibG>
well, it seems to work so far (~18h up)
<ThibG>
(even 2014.10+dfsg1-5?)
<diego71>
(I checked the latest u-boot)
<diego71>
and the lime2, which had u-boot 2014 and kernel 4.9, doesn't boot anymore. So I probably need to reinstall debian on the sd
<MoeIcenowy>
montjoie: current linux-next got "EMAC reset timeout" and "probe of 1c30000.ethernet failed with error -12" with no cable plugged at boot with Orange Pi PC
<MoeIcenowy>
dwmac-sun8i is builtin
<ThibG>
Yeah, I don't think I had any other issue than the MMC failures with latest u-boot from Debian, and I've switched to Arch's to see if it changes anything
<diego71>
btw I've testing also a debian stretch on a A20-micro and it works fine till now
<ThibG>
wrt. the (presumably DRAM-related) hang issue, the hardware watchdog was sufficient to automatically get the thing on its feet again, and I have been able to run it for months without the watchdog even kicking it
<ThibG>
eventually, it happened again and I relaized I was running a super old kernel, so I decided to update u-boot + kernel
<ThibG>
and now I have the much more frequent and insiduous MMC failures :(
lurchi_ is now known as lurchi__
techping has quit [Ping timeout: 245 seconds]
leviathancn has quit [Ping timeout: 260 seconds]
bonbons has joined #linux-sunxi
lurchi__ is now known as lurchi_
gzamboni_ has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
<montjoie>
MoeIcenowy will try
<MoeIcenowy>
u-boot is 2017.05-rc1-00095-gd53ecad92f which contains EMAC support
<MoeIcenowy>
this may affect
<MoeIcenowy>
(in fact I'm debugging TVE driver v2 patchset and the found is a side effect)
<MoeIcenowy>
montjoie: with cable inserted at boot emac starts properly
<MoeIcenowy>
maybe you should assert the reset line of emac before deasserting it
<MoeIcenowy>
like what is done in TCON driver
Gerwin_J has quit [Quit: Gerwin_J]
<montjoie>
clearly lack of test from myself on "boot unplugged"
leviathan_ has joined #linux-sunxi
leviathancn has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
guest267 has joined #linux-sunxi
paultag has joined #linux-sunxi
<paultag>
Anyone know the status of the Nanopi Neo's emac driver being upstreamed? I see a few repos and a few messages on lkml, but nothing that I trust, really
<paultag>
I'd love to use a stock Linux kernel
<montjoie>
paultag: emac is in linux-next
<paultag>
sweeet
<paultag>
Congrats!
<paultag>
is the chip on the nanopi support it? I seem to recall someone having to write some glue for it
<paultag>
does*
<MoeIcenowy>
paultag: the someone is montjoie, who talked to you just before
<paultag>
Sorry, let me rephrase - does the emac driver support the sunxi emac hardware? I recall someone writing glue to make the nanopi eth driver compatable with those emac bits
jernej has joined #linux-sunxi
<paultag>
cool
<MoeIcenowy>
montjoie: I added a ` reset_control_assert(gmac->rst_ephy); ` before ` ret = reset_control_deassert(gmac->rst_ephy); `
<MoeIcenowy>
and now GMAC initializes OK without cable plugged
<MoeIcenowy>
could I send this patch?
<montjoie>
MoeIcenowy: yes how can i say no:)
<montjoie>
anyway I will test it on all my boards
<MoeIcenowy>
oh let me also do that.
<montjoie>
MoeIcenowy: could you paste it ?
<MoeIcenowy>
paste the patch?
<montjoie>
yes
<paultag>
Right, i'll take that as a things will work once net-next makes it up. Thanks, y'all
<MoeIcenowy>
oh the EPHY fix seems to doesn't work on opi0...
<jernej>
MoeIcenowy: Did you use U-Boot with TVE driver during Linux TVE driver development?
<MoeIcenowy>
jernej: nope
<jernej>
Because fixed divider should be 8
<MoeIcenowy>
jernej: but the crtc_clock is half dot clock.
<paulk-collins>
anyone here with an approx. idea of what the max GPIO output current on A13 can be?
<jernej>
MoeIcenowy: So how much is crtc_clock? I don't follow the logic behind
<MoeIcenowy>
jernej: so it's expected to be 13500kHz
<MoeIcenowy>
13500 * 16 = 216000
<jernej>
TCON is set to 216?
<Moofoo>
Hi, probably a question for Icenowy .. what's the best uboot + kernel source to knock up a headless SATA BPI R40 preferably with wifi I2C or SPI working ? Probably mainline kernel is too far away ? Thx
<MoeIcenowy>
Moofoo: not so far
<MoeIcenowy>
but such a branch now only exists on my HDD.
<MoeIcenowy>
and note ethernet is not supported
<MoeIcenowy>
jernej: yes, as Maxime thinks that feed CLK_TVE to TCON1 is better
paulk-collins has quit [Quit: Leaving]
<Moofoo>
I'm not too bothered about Ethernet I just need SATA wifi a little SPI or I2c OLED and wifi 4 a squeezebox server
<jernej>
MoeIcenowy: so TVE runs at 432 MHz but because input clock is 216 MHz, it still works as expected?
<MoeIcenowy>
jernej: the input clock should be 216MHz
<MoeIcenowy>
montjoie: please remove the if sentence in my patch when testing
<jernej>
yes, but TVE is clocked at 432 MHz, no? Only TCON is clocked at 216 MHz
<MoeIcenowy>
there's no dedicated TVE clock...
<MoeIcenowy>
I suggest you run my kernel branch and check /sys/kernel/debug/clk
<jernej>
what about chapter 4.3.5.38 in H3 datasheet?
<MoeIcenowy>
mripard: I found a problem on this sentence in sun4i_tcon.c: if (!reset_control_status(tcon->lcd_rst)) reset_control_assert(tcon->lcd_rst);
<jernej>
MoeIcenowy: ^
<MoeIcenowy>
the problem is that -- sunxi-ng doesn't support status at all
<MoeIcenowy>
jernej: yes, it should be the input of the TCON, and the passed to TVE
<MoeIcenowy>
and it should be set to 216MHz
<MoeIcenowy>
now I let the TCON to set it to 216MHz
<MoeIcenowy>
montjoie: the problem starts to become complicated
<MoeIcenowy>
I should first send a fix to sunxi-ng driver
<MoeIcenowy>
then the dwmac fix
<jernej>
MoeIcenowy: Why do you say that TVE has no dedicated clock? It is PLL_DE or PLL_PERIPH1 with divider between 1 and 16
<MoeIcenowy>
you mean CLK_TVE?
<jernej>
yes
<MoeIcenowy>
it's shared between TVE and TCON1
<MoeIcenowy>
P.S. in fact I wanted to create a clock from TVE that is correctly divided
<MoeIcenowy>
but mripard refused this idea
Moofoo has quit [Ping timeout: 260 seconds]
<jernej>
MoeIcenowy: So when are you setting TCON clock, it is in fact CLK_TVE, which gets set?
<MoeIcenowy>
yes
<jernej>
ok, that makes more sense, thanks for explanation
<jernej>
but it is a bit confusing
<MoeIcenowy>
montjoie: oh I think just run assert on the reset line is OK even if it's already asserted
<MoeIcenowy>
as the semantic of reset_control_assert is to guarantee the line is asserted
leviathancn has quit [Remote host closed the connection]
lkcl has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
<MoeIcenowy>
montjoie: fix sent.
<MoeIcenowy>
and now I should get sleep
<MoeIcenowy>
montjoie: maybe I should now make V3s driver -- V3s is like the H3, but without external *MII interface, only ephy
<montjoie>
MoeIcenowy: why current emac is not sufficient for v3s ?
<MoeIcenowy>
montjoie: sufficient.
<MoeIcenowy>
the only problem is that the V3s MAC cannot do RMII/RGMII
<MoeIcenowy>
so dedicated compatibles are needed to disable these capabilities.
<montjoie>
perhaps just a "bool external_phy" will do the trick
<MoeIcenowy>
in fact I only added a new quirk struct for it.
<techping>
A few days ago I use sun8i-emac v5.0 on V3s board, directly use of h3's compatible. the eth can be used successfully
<jernej>
MoeIcenowy: What about mripards comment that mixer should have DT properties with number of ui and vi planes? That should remove all quirks and all other additional units are based on vi & ui count
<MoeIcenowy>
jernej: but there's more capability differences than channel count.
<jernej>
which ones? plane size, what else?
<MoeIcenowy>
for example "VEP" is only supported on mixer0 channel 0
<MoeIcenowy>
write-back is only supported on mixer0
<MoeIcenowy>
on H3
<MoeIcenowy>
they are not compatibles -- we only implemented the common subset of the functions in both mixer0 and mixer1
<jernej>
still, number quirks would be minimized that way
<MoeIcenowy>
and you will go to the way of ugly allwinner BSP DTs
<MoeIcenowy>
you will have a &mixer0 { allwinner,vi-channels = <1>; allwinner,ui-channels = <4>; allwinner,vep-capable = <0>; allwinner,wb-capable; }
<MoeIcenowy>
these device_type related infomation should be in driver and be checked out by compatible strings
<jernej>
well, that's more a philosophical issue, but it doesn't seem wrong. After all, DT is HW description and mmc nodes looks something like that
<MoeIcenowy>
and I think dt maintainers are refusing more and more hardware block details into DT
leviathancn has joined #linux-sunxi
<jernej>
ok then
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
paulk-elm has quit [Remote host closed the connection]
<MoeIcenowy>
montjoie: so strange... if I use newly added allwinner,sun8i-v3s-emac compatible, enabling eth0 will fail with "dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY"
<MoeIcenowy>
but if I use the allwinner,sun8i-h3-emac compatible it will succeed
paulk-elm has joined #linux-sunxi
<montjoie>
could you paste your modifications ?
<MoeIcenowy>
oh the compatible should be added to stmmac_platform.c
<montjoie>
MoeIcenowy: yes hidden:)
<techping>
maybe you should add "allwinner,sun8i-v3s-emac" compatible into the driver file
<techping>
yeah...
paulk-elm has quit [Remote host closed the connection]
paulk-elm has joined #linux-sunxi
<techping>
maybe the driver should be adjusted slightly to be compatible with v3s？
<MoeIcenowy>
yes... there's another dt id matching table in stmmac_platform.c
<MoeIcenowy>
for MDIO bus
<MoeIcenowy>
terrible...
<montjoie>
MoeIcenowy: didnt see better than that
quard has joined #linux-sunxi
<montjoie>
hacked so many part of stmmac...
paulk-elm has quit [Remote host closed the connection]
<MoeIcenowy>
techping: could I upload my kernel branch and let you test?
<MoeIcenowy>
I doubt the prototype dock has a bad Ethernet port
paulk-elm has joined #linux-sunxi
<techping>
MoeIcenowy: ok , i can test it tomorrow
<techping>
oh ..
leviathancn has quit [Remote host closed the connection]
<MoeIcenowy>
techping: if your test failed, could you set the value in emac_variant_v3s struct to 0x58000 (drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c)?
<techping>
ok
GrimKriegor has quit [Ping timeout: 255 seconds]
techping has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
guest267 has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
guest267 is now known as techping
techping has quit [Remote host closed the connection]
techping_ has joined #linux-sunxi
leviathancn has quit [Ping timeout: 255 seconds]
techping_ has quit [Client Quit]
techping_ has joined #linux-sunxi
techping has joined #linux-sunxi
techping_ has quit [Client Quit]
paulk-elm has joined #linux-sunxi
techping has quit [Client Quit]
techping has joined #linux-sunxi
lurchi_ is now known as lurchi__
GrimKriegor has joined #linux-sunxi
lurchi__ is now known as lurchi_
<kivutar>
can I use a modern u-boot with dtbs with the 3.4 sunxi kernel?