ssvb has quit [Read error: Connection reset by peer]
ssvb has joined #linux-rockchip
afaerber has joined #linux-rockchip
robogoat has quit [Ping timeout: 265 seconds]
robogoat has joined #linux-rockchip
sunxi_fan has quit [Ping timeout: 272 seconds]
sunxi_fan has joined #linux-rockchip
nighty-_ has quit [Remote host closed the connection]
kapouer has joined #linux-rockchip
gb_master has joined #linux-rockchip
gb_master has quit [Quit: Leaving]
chiprocks has joined #linux-rockchip
<chiprocks>
hi, I'm wondering if any body knows if RK3066 can be used with Linux 4.x
<mmind00>
chiprocks: it can, with a reduced functionality
<chiprocks>
mmind00: what do you mean with "reduced functionality"? are there things known not to work on 4.x?
<mmind00>
chiprocks: correct ... for example the whole graphics area on rk3066/rk3188
<chiprocks>
mmin0: so the GPU driver is known not to work on 4.x? does
<chiprocks>
does it fails at run time or compile time?
<chiprocks>
mmind00: so the GPU driver is known not to work on 4.x? does it fails at run time or compile time?
<chiprocks>
mmind00: what I see, is that it looks like the ioctl() calls to the driver are returning ENOTTY
<mmind00>
chiprocks: it's more ... the whole graphics output pipeline is currently simply unsupported there ... the actual mali-gpu is only a tiny part of that
<chiprocks>
mmind00: what would be what you call "graphics output pipeline"? couldn't the mali-gpu just use fbdev?
<chiprocks>
mmind00: and how is that it is not supported? it is based on APIs that are no longer present on Linux 4.x?
<mmind00>
chiprocks: the gpu does just render to memory ... from there you need to configure crtcs+hdmi+whatever controllers, that are Rockchip-specific components for which only the rk3288-variants are currently supported
<chiprocks>
mmind00: I see, do you know which RK chips support Linux 4.x?
<mmind00>
chiprocks: at the moment you'll get the most functionality with a rk3288
<rperier>
btw, it's me I did read something saying that u-boot (only the second level bootloader) is supported on rk3188/rk3066 (experimental support)... ? because I don't find these informations upstream...
<chiprocks>
mmind00: so most are stuck with old kernels?
<chiprocks>
mmind00: where could I find the Linux tree / branch for the rk3288 ?
<chiprocks>
mmind00: because actually I'm just trying to debug the ENOTTY thing
<mmind00>
rperier: I think that was not a mainline uboot, but the Rockchip variant
<chiprocks>
mmind00: ok, thanks, do you know where to find the GPU driver for rk3288 on the Linux kernel tree? I could find the DRM driver, and according to this http://linux-rockchip.info/mw/index.php?title=3d2dAcceleration the GPU driver should be in drivers/gpu/mali or drivers/gpu/mali_drm but I don't see them in mainline
<mmind00>
chiprocks: the mali kernel-parts for the binary driver will never be part of mainline (due to the binary-userspace)
<mmind00>
chiprocks: again, that is for the midgard mali (T76x) from the 3288
<chiprocks>
mmind00: ok, thanks, I'm going to checkout that, see if I can find why I get ENOTTY. By any chance, would somebody have a clue on that error for ioctl to /dev/mali on Linux 4.x?
<chiprocks>
By any chance, would somebody have a clue on that error for ioctl to /dev/mali on Linux 4.x?
<naobsd>
chiprocks: what kind of system(SoC/kernel/userland) are you using?
<chiprocks>
naobsd: actually, I'm not using a RK, but the GPU is the same so I figured the problems would have been faced by RK and thus while searching on the internet I ended up here
<chiprocks>
naobsd: I have tested the driver up to Linux 3.4 and it works. For Linux 4.x there were a few things that I had to change on the kernel driver because of some APIs gone missing.
<chiprocks>
naobsd: the driver thus loads on Linux 4.x, but for some reason all ioctls() calls to /dev/mali are being rejected with ENOTTY
<chiprocks>
naobsd: in my case, I never see the driver on "cat /proc/devices", even on Linux 3.4 where it does work, so I don't know if that URL has the right information
<rperier>
anyway, I think that I will test lastest mainline on my marsboard (rk3066) to be sure that there are no regressions, and perhaps hack a bit on the nand controller (If I find helpful informations in public trm)
<sjoerd>
rperier: btw did you have a chance for some more u-boot testing, i've tested my rock2 board against my laptop cross-linkes, phy comes up at 1gbit and it works
<rperier>
oh yeah thanks, right, I also need to find a solution for this ethernet support for the rock2
<rperier>
:D
<sjoerd>
I didn't have the time to force & test with cross-linked 100mbit/s thusfar
<sjoerd>
This always happens during the x-mas/newyears holidays, I hope to do a lot of stuff and it always gets derailed
<rperier>
my old laptop has an 1GBs ethernet interface... I can test with it...
<rperier>
it is broken with 100Mbs, I am sure, but perhaps that it will work with my old laptop...
<sjoerd>
++
<sjoerd>
well i'd still love it if you could test 100mbs non-crosslinked ;)
<rperier>
yeah but I need a router or hub or switch for that, no ?
<sjoerd>
rperier: I'll try and test your leds patch tonight btw :)
<sjoerd>
rperier: ack
<sjoerd>
You don't have such a thing in your house ?
<sjoerd>
Anyway, i can test taht as well but first need to do some winter cleaning of my home office and then DIY :)
<rperier>
I will try to find one... :p
<sjoerd>
mmind00: speaking fo 3188 and u-boot did you ever get a chance to bang on your u-boot branch for it some more ?
<mmind00>
sjoerd: nope ... got distracted after the spl didn't seem to like me at all
<sjoerd>
Yeah that's the nastiest part :/
<chiprocks>
sjoerd, mmind00: thanks for the links, but I already have some binaries, the whole thing works on 3.4 but I would like to use 4.x
<chiprocks>
sjoerd, mmind00: I would have thought that would amount to just rebuilding the kernel module, which I did, but it rejects the ioctls()
<sjoerd>
chiprocks: I don't think the binaries should care about the kernel version as long as you expose the same nterface
<chiprocks>
sjoerd, mmind00: and I don't know how to debug that ioctl issue, the call does not even reach the ioctl handler on the kernel module, so the kernel is not forwarding it and it is rejecting it by itself
<chiprocks>
sjoerd: exactly
<chiprocks>
sjoerd: the kernel version should not matter, but somehow it does. The kernel module builds with Linux 4.x (with a few modifications that do not break it for 3.4 so I consider them safe)
<chiprocks>
sjoerd: but then, for whatever reason, the kernel is not forwarding the ioctl calls to the kernel module (the mali kernel driver), and it just plains rejects them with ENOTTY
<chiprocks>
sjoerd: so I think the driver must be missing a call to some API or something else changed, and it may not be properly registering
<rperier>
sjoerd: well.... on the same laptop... If I remove the cross-link adapter, ping works but in 10Mbs, half-duplex... still with the same laptop using the cross-link adapter it works at 1Gbs on linux ... on my old laptop... with the cross-link adapter it does not work at all, and without it it works like a charm at 1Gbs full duplex
<rperier>
:D
<sjoerd>
"cross-link adapter" ?
<sjoerd>
you mean cable
<sjoerd>
or ?
<rperier>
crossover adapter sorry
<rperier>
I always used this crossover adapter with all my rockchip boards, and it worked all the time at the right speed ... that's strange :/
<sjoerd>
Ah
* sjoerd
never uses those
<sjoerd>
all modern phy's detect it for themselves
<aborche>
sjoerd, i think adapter means plug on one side and socket on another
<chiprocks>
sjoerd, mmind00: actually, not even the "open" call reaches the kernel module :(
<sjoerd>
rperier: with your "new" laptop just a straight cable is giving issues then?
<rperier>
yep
<sjoerd>
rperier: and a stright cable there comes up in ? 100/1000 or?
<sjoerd>
rperier: see why i'm wary of cross-links :)
<rperier>
well, that's what I planned to test, let me find a stright cable first :p
<rperier>
sjoerd: yeah but I use this technic since... 1.5 year now... it worked all the time with all my boards... so... that's why I did not care about it :)
<rperier>
but it makes sense....
<sjoerd>
I guess the kernel does something to make it work better
<sjoerd>
or maybe retries more often or whatever
<rperier>
I think that it is completly related to the phys during autonego... I mean... uboot only probe the mdio bus periodically to check if the link is up or not...
<rperier>
it only checks a standard register for that :)
<sjoerd>
could well be
<sjoerd>
it just worked for me so i din't dig into that
<rperier>
okay and now... with my straight cable (with or without this crossover plug) it no longer works... ! :D
<rperier>
wtf ? :D
<rperier>
on linux it works in all cases
<sjoerd>
heh, curious
<sjoerd>
is this with your rock2 or firefly or both?
<sjoerd>
though that 'shouldn't really matter in principle
<sjoerd>
Guess you're a good volunteer to hack on u-boots mdio :p
<rperier>
except if the phy on the rock2 is badly configured by the driver in uboot....
<sjoerd>
could be
<sjoerd>
well, i didn't think u-boot configured it at all
<sjoerd>
not any phy specific coniguration at least
<sjoerd>
So i guess some tuning might be needed after reset?
<rperier>
yes, I guess so. if you use the phy generic driver in uboot only the standard mdio registers will be used, if you plan to use a specific phy configuration, you should use the vendor phy driver, in our case that's drivers/net/phy/realtek.c
<rperier>
anyway, I will investigate
<sjoerd>
rperier: at least linux detect the phy automaticlaly on rock2
cnxsoft has quit [Remote host closed the connection]
<via>
mmind00: the display doesnt come back on after resuming from suspend. i know it still works since i can type halt -p and it turns off... so its just the display. any ideas of what i can try?
dlezcano has quit [Ping timeout: 240 seconds]
<libv>
ssvb, chiprocks: .
dlezcano has joined #linux-rockchip
<libv>
#lima is not for closed driver support
<mmind00>
via: I do think I had that at one time as well, haven't investigated further yet
<chiprocks>
ssvb: I think it does not matter if you have the hardware or not
<chiprocks>
ssvb: without the hardware you cannot test indeed, but I'm trying to see if somebody has ever made Mali work on Linux 4.x, maybe it is not supported at all
<chiprocks>
would anybody have a clue about the "/dev/mali" <-> mali.ko disconnect on Linux 4.x? Does Mali support Linux 4.x?
<mmind00>
hipboi: are the two rock2 leds (gpio7_b7 and gpio0_b3) listed somewhere in the schematics [or are these the led_state1 and led_state2 shown in the square-schematics]?
kapouer has quit [Quit: kapouer]
<rperier>
hipboi: Hi Tom, can we control the state of the red led on the rock2 ? (square board)
<rperier>
I am pretty sure that it is off when booting the official linux distribution ... :/
<rperier>
(I am still a noob when reading a schematic... so perhaps that I missed something too :p)
<sjoerd>
rperier: no that's wired directly onto VCC_SYS
<sjoerd>
so that'll just be always on if there is power applied
kapouer has joined #linux-rockchip
<rperier>
mhhh okay... good point
<rperier>
:)
<rperier>
so in uboot... everything works in 10Mbs Half/Full, nothing works for 100Mbs Half/Full, and it only works for 1Gbs Full not in Half , I can reproduce the issue with my two laptops
<rperier>
so that's not a pin muxing issue, not related to irq... not related to phy configuration (I don't think so... )... so I would say something specific in gmac_rk3288: the clocks or something related to the grf perhaps...
<rperier>
something related to the speed of the link...
<rperier>
at least, as I understood, I might be wrong too
<rperier>
you can easily reproduce the issue using ethtool. You can ask your phy to negociate the same speed
<sjoerd>
nod
<sjoerd>
i swear it did work on my 100mbs switch, but i'll recheck
<sjoerd>
rperier: the only thing linux (and u-boot should) do when changing speed is to adjust the clock
johnnyr_ has joined #linux-rockchip
johnnyr has quit [Ping timeout: 255 seconds]
adj_ has joined #linux-rockchip
_whitelogger has quit [Ping timeout: 240 seconds]
_whitelogger has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
daniels has joined #linux-rockchip
akaizen_ has joined #linux-rockchip
gb_master has joined #linux-rockchip
akaizen has quit [Ping timeout: 264 seconds]
daniels_ has joined #linux-rockchip
daniels has quit [Read error: Connection reset by peer]