<MoeIcenowy>
ccu fixed based on the user manual (one more bus gate, one more bus reset, resolved a conflict in dram gate and changed the SATA's mux 1 to sata-ext, which is the same with plaes's patchset
perr has quit [Ping timeout: 252 seconds]
perr has joined #linux-sunxi
lkcl has joined #linux-sunxi
<wens>
you need to update the commit subject prefixes to match
<wens>
such as, drop the "dts: " bit
<wens>
and "ARM" should be uppercase
<wens>
for the phy driver, r40 comes before v3s
<MoeIcenowy>
oh forgot the commit prefix change
<wens>
and since we now have a proper datasheet/manual, you could drop the paragraph that says we don't (in the basic dtsi commit message)
<MoeIcenowy>
ok ;-)
<MoeIcenowy>
P.S. trying AHCI
<wens>
I would suggest you hold off sending it until -rc1 comes out, and we've all rebased our maintainer trees
<MoeIcenowy>
the R40 AHCI added a reset line
<wens>
unless you've been tracking all the extra stuff closely
<wens>
MoeIcenowy: not unexpected. follows the sun7i -> sun6i trend
<MoeIcenowy>
wens: I will do this, so I pushed them first to a github branch now
<MoeIcenowy>
yes ;-)
<MoeIcenowy>
but the ahci_platform framework seems to never deal with resets...
<wens>
it is possible to add it to libahci_platform, as an "optional" reset control
<wens>
or, just add it to ahci_sunxi, and make it required for sun8i-r40-ahci
<MoeIcenowy>
oh I saw tegra and st variants dealed with resets themselves
<wens>
looks like there's no dealing with it in platform easily
victhor has quit [Ping timeout: 255 seconds]
<MoeIcenowy>
oh the sata controller needs two regulators on R40...
<MoeIcenowy>
and the regulators seem to be also dealed with ahci_sunxi, as the regulator dealing in libahci_platform is for powering ports, not powering the controller
<MoeIcenowy>
got AHCI to work ;-)
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
<MoeIcenowy>
seems that SATA is now in a dedicated power domain on R40
<MoeIcenowy>
the IP cores are surely identical ;-)
<MoeIcenowy>
only the power part changed
<MoeIcenowy>
simple sequence performance test via dd shows: read 103.9MB/s write 32.0MB/s on a HITACHI HTS72755 D0H0 (Lenovo FRU 42T1721)
<MoeIcenowy>
P.S. when I'm testing, the display is OK and all texts are properly displayed, but the Tux at left-top corner disappeared
vetkat has quit [Quit: Bye bye]
vetkat has joined #linux-sunxi
vetkat has joined #linux-sunxi
vetkat has quit [Quit: Bye bye]
vetkat has joined #linux-sunxi
vetkat has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
<MoeIcenowy>
agraf: I'm sorry to tell you that U-Boot EFI GOP support for DM_VIDEO is also broken
jernej has joined #linux-sunxi
<jernej>
MoeIcenowy: Do you mean on 32 bit platforms?
<MoeIcenowy>
jernej: ON ALL PLATFORMS.
<MoeIcenowy>
the efi_gop.c is only enabled for CONFIG_LCD, not CONFIG_DM_VIDEO
<MoeIcenowy>
and if I really enable CONFIG_DM_VIDEO to build it
<jernej>
ah, that issue
<MoeIcenowy>
it will fail at one point where it access gd->fb_base
<MoeIcenowy>
which doesn't exist in pure dm video situation
fire219 has quit [Read error: Connection reset by peer]
<MoeIcenowy>
and it seems that the booted Linux won't probe the efifb at all
<jernej>
send a patch?
<MoeIcenowy>
(it's another problem)
<MoeIcenowy>
and even if the efifb is probed, it will fail to work, as the needed clock will be disabled by ccu driver
<MoeIcenowy>
yes it's a disadvantage of CCU
<MoeIcenowy>
mripard: ^
<MoeIcenowy>
for the not probing problem I think it's because U-Boot didn't generate the needed smbios part
<MoeIcenowy>
I made a patch to enable simplefb for DE2 driver
<jernej>
really?
<jernej>
for DM video?
<MoeIcenowy>
yes
lurchi__ has joined #linux-sunxi
<jernej>
I think it would be worth doing some general way and integrate it in DM video framework
<MoeIcenowy>
but allwinner have some specific simplefb logic
<MoeIcenowy>
which is used to keep the clocks after booted
<MoeIcenowy>
otherwise you will face the same problem "the needed clock will be disabled by ccu driver"
<jernej>
well, you add callback function which populates node with driver specific things like clocks and/or pipe name?
<jernej>
Actually, IIRC, node must be there already, you only ask driver for pipe name
<MoeIcenowy>
I still think the allwinner simplefb populating code should be private
<wens>
simplefb is not allwinner specific
<wens>
it was just extended to support us
<MoeIcenowy>
except if we can generalize the pipeline mechanism
<wens>
the pipeline stuff is just string matching
<MoeIcenowy>
as the allwinner simplefb populating code in fact checks not for "simple-framebuffer" but "allwinner,simple-framebuffer"
<jernej>
MoeIcenowy: Did you push your patch somewhere?
<MoeIcenowy>
as only "allwinner,simple-framebuffer" should have "allwinner,pipeline"
<MoeIcenowy>
jernej: currently nope
<MoeIcenowy>
let me push it
<MoeIcenowy>
We don't get linelength from UGA Draw Protocol, only from EFI Graphics Protocol. So if it's not in DMI, and it's not passed in from the user, we really can't use the framebuffer. ...
<MoeIcenowy>
(the comments in Linux efifb driver)
<jernej>
wens: a bit related, do you plan to add axp221s driver to Linux?
lurchi__ has quit [Remote host closed the connection]
<wens>
jernej: it's the same as axp221
lurchi__ has joined #linux-sunxi
<jernej>
except it uses i2c?
<wens>
they are dual mode
<wens>
axp221s is also used with A31s
<jernej>
well, I looked into enabling DE2 driver for R40 in U-Boot
<MoeIcenowy>
I think AXP221s is totally the same as AXP221
<MoeIcenowy>
jernej: you got a BPi M2U?
<jernej>
but there is an issue with DM_I2C
<wens>
the P2WI/RSB controllers have a function that writes a pattern to a specific register to get it to switch over
<jernej>
yes
<wens>
however getting it to switch back with I2C controllers is unlikely
<jernej>
MoeIcenowy: ŷes
<wens>
but, if you started in I2C, then you can just continue to use I2C with it
<MoeIcenowy>
P.S. I bought a M2U and then BPi people sent me one more...
<wens>
The only differences between AXP221 and AXP221s seem to be some of the current limits of the regulators
<MoeIcenowy>
Yes the Linux driver relies on DMI or cmdline to probe efifb
<MoeIcenowy>
as the screen may vary we cannot surely use cmdline
<MoeIcenowy>
but U-Boot doesn't populate DMI
<wens>
how do you do DMI on ARM? :p
<MoeIcenowy>
I think it's only an EFI configuration table
<MoeIcenowy>
we can also do ACPI on ARM! If you like ;-)
<wens>
I would rather not go down that path
<jernej>
wens: DM_I2C has to be enabled for DM_VIDEO, but that would prevent to compile current axp regulators drivers, right?
<wens>
not sure, never tried it
<jernej>
I was considering porting I2C connected regulators to DM
<MoeIcenowy>
note: the AXP driver is in SPL
<MoeIcenowy>
but I think they're properly abstracted
<wens>
yeah, we don't really need the AXP drivers in U-boot proper
<MoeIcenowy>
see arch/arm/mach-sunxi/pmic_bus.c
<MoeIcenowy>
wens: we need it for "poweroff" command.
<wens>
oh right
<wens>
jernej: Theobroma Systems' git repo has some work on DM-ifying the RSB bus driver and some AXP drivers
<wens>
you could take a look
<jernej>
if they plan to push it, I'm totally ok with it :)
<MoeIcenowy>
yes let us forget EFI GOP and continue to use SimpleFB
<jernej>
unless if work stalled
<wens>
jernej: it was for the A80, so I doubt mainlining that is high on their TODO list
<wens>
jernej: FYI the A80 SPL work was mostly done by them, we just picked the patches over and clean them up some more
<MoeIcenowy>
P.S. what's the current state of A83T U-Boot support?
<wens>
MoeIcenowy: basic stuff only
<wens>
MoeIcenowy: i have USB patches in my repo but have not rebased and tested them
<MoeIcenowy>
jernej: a question: why did the Tux on the left-top corner disappeared with the dm-video driver?
<jernej>
because console rendering code is not the same
<jernej>
so, that's normal :)
<jernej>
wens: do you have url of theobroma git?
<MoeIcenowy>
wens, mripard: another problem: should we open a github or somewhere repository to place mainline DT overlays?
Ntemis has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
chomwitt has quit [Ping timeout: 252 seconds]
<agraf>
MoeIcenowy: did i mention that i find it terrible to have linux control clocks? :)
<agraf>
MoeIcenowy: either way, I am glad you got it working with DM_VIDEO. Please send a patch to fix up the broken code - I didn't realize it was broken :)
<MoeIcenowy>
agraf: so... who control it?
<agraf>
MoeIcenowy: EL3
<agraf>
MoeIcenowy: the only entity that knows about the full system
<wens>
jernej: not on hand, sorry
<MoeIcenowy>
how about ARMv7?
<MoeIcenowy>
agraf: I have already dropped the code...
<agraf>
MoeIcenowy: you get the same issues when you run EL1s code which happens to access devices behind a clock domain that EL1 controls
<MoeIcenowy>
agraf: thus does the EL3 code in U-Boot have clock controlling framework now? ;-)
<agraf>
MoeIcenowy: no, andre was working on ATF support for it
<agraf>
MoeIcenowy: not sure how far he got by now
<agraf>
MoeIcenowy: last time i talked to him he said he had something working
<MoeIcenowy>
at least on his github repo there's only mmc clock
<wens>
at least with the new CCU bindings, it would be easy enough to just switch out the compatible string to use SCPI clocks
<MoeIcenowy>
but the requisite of switch to SCPI clocks is that we should have all clocks in SCPI
bonbons has joined #linux-sunxi
<wens>
you can't have a split view anyway
<wens>
it's all or nothing
pg12 has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
chlorine has joined #linux-sunxi
<MoeIcenowy>
P.S. if one board come with different compatible SoC what should we deal this with devicetree?
<MoeIcenowy>
e.g. BPi M2+ with H3 and BPi M2+ with H5
<KotCzarny>
treat it as a new device? add soc to the name?
<KotCzarny>
imo soc should be the first word in the name for every soc based board
<MoeIcenowy>
KotCzarny: most of the peripherals are shared
<MoeIcenowy>
naming is not a big problem.
<KotCzarny>
it would nicely sort the files
jernej has quit [Ping timeout: 258 seconds]
pg12 has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
BenG83 has quit [Ping timeout: 260 seconds]
Ntemis has quit [Remote host closed the connection]
<dgp>
MoeIcenowy: peripherals are in an include file for h3/h5 .. that makes sense to me
<dgp>
If the boards are mostly the same then an include between them would make sense
BenG83 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7099-gca80ee628, build type: debug, sources date: 20160102, built on: 2017-03-12 14:49:35 UTC git-7099-gca80ee628 http://www.kvirc.net/]
BenG83 has quit [Read error: Connection reset by peer]
BenG83 has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 245 seconds]
_whitelogger has joined #linux-sunxi
elvirolo1 has joined #linux-sunxi
<elvirolo1>
hi all
<MoeIcenowy>
oh linux 4.11 is out
<MoeIcenowy>
Pine64's USB and MMC support
<MoeIcenowy>
BPi M64's MMC support
<elvirolo1>
Does anyone know how to install an encrypted Debian on a olimex lime2?
f0xx has joined #linux-sunxi
reev has quit [Ping timeout: 252 seconds]
reev has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
reinforce has joined #linux-sunxi
velly has joined #linux-sunxi
reev has quit [Ping timeout: 268 seconds]
velly has quit [Max SendQ exceeded]
velly has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
yann-kaelig has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
destroyedlolo has joined #linux-sunxi
<destroyedlolo>
Hello
<destroyedlolo>
A question about DTs, U-Boot and kernel relationship.
<destroyedlolo>
Is the kernel using its own DT or does get it from U-Boot one ?
<MoeIcenowy>
its own
jstein_ has joined #linux-sunxi
jernej has joined #linux-sunxi
<destroyedlolo>
ok.
<destroyedlolo>
Thanks.
<dgp>
destroyedlolo: I think the idea is to be able to use the same DT for uboot and the kernel though
jstein_ is now known as jstein
<destroyedlolo>
I'm fighting to add my 3.5 LCD display on my BananaPI (with latest kernel and u-boot) and I asked to be sure I'm working with the right DTS :)
<destroyedlolo>
Is an how to about steps to follows to achieve that ?
<destroyedlolo>
I found only parcelar information.
elvirolo1 has quit [Quit: Leaving.]
fdcx has quit [Read error: Connection reset by peer]
fdcx has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
kloczek has joined #linux-sunxi
victhor has joined #linux-sunxi
elvirolo has joined #linux-sunxi
elvirolo has left #linux-sunxi [#linux-sunxi]
dave0x6d has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
f0xx has quit [Ping timeout: 240 seconds]
rwmjones has quit [Read error: Connection reset by peer]
rwmjones has joined #linux-sunxi
lurchi__ is now known as lurchi_
chlorine has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 240 seconds]
terra854 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
chlorine has quit []
<willmore>
MoeIcenowy, wow, I was behind a few days. You've been very busy! Great work!
phipli has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
LargePrime has joined #linux-sunxi
f0xx has joined #linux-sunxi
lurchi_ is now known as lurchi__
pg12 has quit [Ping timeout: 258 seconds]
lurchi__ has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
jernej has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
vishnup has joined #linux-sunxi
martinayotte has quit [Remote host closed the connection]
jstein_ has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
jstein_ is now known as jstein
Gerwin_J has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
destroyedlolo has quit [Remote host closed the connection]
Kais_ has joined #linux-sunxi
vishnup has quit [Ping timeout: 260 seconds]
yann-kaelig has quit [Quit: Leaving]
lurchi__ has joined #linux-sunxi
Xal1u5 has joined #linux-sunxi
Nacho has joined #linux-sunxi
ruben-ikmaak has joined #linux-sunxi
libv_ has joined #linux-sunxi
alexxy[home] has joined #linux-sunxi
f0xx has quit [*.net *.split]
JohnDoe_71Rus has quit [*.net *.split]
victhor has quit [*.net *.split]
BenG83 has quit [*.net *.split]
arete74 has quit [*.net *.split]
[Awaxx] has quit [*.net *.split]
Nacho_ has quit [*.net *.split]
djakov has quit [*.net *.split]
xes has quit [*.net *.split]
libv has quit [*.net *.split]
medvid has quit [*.net *.split]
KotCzarny has quit [*.net *.split]
ikmaak has quit [*.net *.split]
alexxy has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
heffer_ has quit [*.net *.split]
heffer has joined #linux-sunxi
MoeIcenowy has joined #linux-sunxi
[Awaxx] has joined #linux-sunxi
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
arete74 has joined #linux-sunxi
xes has joined #linux-sunxi
kloczek has quit [Remote host closed the connection]
Kais_ has quit [Quit: Page closed]
tkaiser has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
phipli has quit [Ping timeout: 268 seconds]
lurchi__ is now known as lurchi_
lennyraposo has quit [Ping timeout: 240 seconds]
wookey has quit [Ping timeout: 260 seconds]
wookey has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
yann-kaelig has joined #linux-sunxi
Ntemis has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
phipli has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
medvid has joined #linux-sunxi
lurchi_ is now known as lurchi__
djakov has joined #linux-sunxi
djakov has joined #linux-sunxi
phipli has quit [Ping timeout: 240 seconds]
f0xx has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
victhor has joined #linux-sunxi
scream has joined #linux-sunxi
fkluknav has joined #linux-sunxi
deskwizard has quit [Quit: disapeared.]
KotCzarny has joined #linux-sunxi
tkaiser has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
<vagrantc>
i'm trying out the dwmac-sun8i driver, and it seems to work fine on the orange pi plus2, but the pine64 has really slow performance
<vagrantc>
also moved them both onto the same network switch, to reduce variables
<KotCzarny>
seems to be more than few kB/s
<vagrantc>
indeed
<vagrantc>
yet, doing things like apt download/apt update/apt upgrade stall out at very slow speeds compared to other machines with similar configuration
<vagrantc>
wget off the network, etc.
<KotCzarny>
run iperf over internet?
<MoeIcenowy>
some Pine64's are partly broken
<KotCzarny>
assuming you have some server handy
<MoeIcenowy>
but usually broken boards are fully broken
<MoeIcenowy>
that means one direction (I forgot which) is totally unusable
<vagrantc>
ugh.
<vagrantc>
i've been limping along with usb ethernet adapters, but was hoping that would only be temporary
<vagrantc>
i've got three different boards, haven't tested the others, but they all were shipped around the same time
<vagrantc>
but wouldn't the iperf results above suggest it's working fine?
<MoeIcenowy>
P.S. do you want to try out my kernel branch?
<KotCzarny>
i have different results depending where iperf server was running
<MoeIcenowy>
it uses sun8i-emac, but it contains the Pine64 PHY workaround
<willmore>
vagrantc, yes. Those results look good.
<willmore>
They're not earth shattering--either good or bad.
<MoeIcenowy>
if your network got well here I think you may be a victim of the broken RTL8211E PHY
<vagrantc>
the other end was an imx6, which is supposedly limited to 480Mbit rather than full gigabit
<vagrantc>
MoeIcenowy: any way to confirm that?
<MoeIcenowy>
vagrantc: first directly test with my branch, if it's ok, then revert 53a35e5b1aac29d6dac32b77721333a8be83718a and test
<MoeIcenowy>
(53a35e5b1aac29d6dac32b77721333a8be83718a is the commit that enables the workaround)
<MoeIcenowy>
if the network got broken because of the revert of 53a35e5b1aac29d6dac32b77721333a8be83718a that means you got a broken PHY
<vagrantc>
downloading a 50MB file using wget from the same machine that ran the iperf3 server, i got 2017-05-01 12:48:31 (2.72 MB/s) - ‘test50mb.img’ saved [52428800/52428800]
<willmore>
vagrantc, could be horribly slow storage on one end or both.
<vagrantc>
well, that's better than what i've usually been getting, which is KB/s
<vagrantc>
~25KB/s or so
<willmore>
FWIW from an OpiPC2 to an Intel based server: