e1z0 has quit [Read error: Connection reset by peer]
e1z0 has quit [Read error: Connection reset by peer]
e1z0 has quit [Read error: Connection reset by peer]
victhor has quit [Ping timeout: 260 seconds]
victhor has quit [Ping timeout: 260 seconds]
victhor has quit [Ping timeout: 260 seconds]
<wens_>
megi: IIUC migration only applies to mailing lists on vger
<wens_>
megi: IIUC migration only applies to mailing lists on vger
<wens_>
megi: IIUC migration only applies to mailing lists on vger
e1z0_ has quit [Ping timeout: 240 seconds]
e1z0_ has quit [Ping timeout: 240 seconds]
e1z0_ has quit [Ping timeout: 240 seconds]
DrFrankensteinUK has quit [Ping timeout: 244 seconds]
DrFrankensteinUK has quit [Ping timeout: 244 seconds]
DrFrankensteinUK has quit [Ping timeout: 244 seconds]
camus has joined #linux-sunxi
camus has joined #linux-sunxi
camus has joined #linux-sunxi
e1z0 has joined #linux-sunxi
e1z0 has joined #linux-sunxi
e1z0 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
camus is now known as kaspter
camus is now known as kaspter
cnxsoft has quit [Ping timeout: 256 seconds]
cnxsoft has quit [Ping timeout: 256 seconds]
cnxsoft has quit [Ping timeout: 256 seconds]
cnxsoft has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
DrFrankensteinUK has joined #linux-sunxi
DrFrankensteinUK has joined #linux-sunxi
DrFrankensteinUK has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
e1z0 has quit [Ping timeout: 245 seconds]
e1z0 has quit [Ping timeout: 245 seconds]
e1z0 has quit [Ping timeout: 245 seconds]
e1z0 has joined #linux-sunxi
e1z0 has joined #linux-sunxi
e1z0 has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 265 seconds]
mmarc__ has quit [Ping timeout: 265 seconds]
mmarc__ has quit [Ping timeout: 265 seconds]
no1b4me has quit [Quit: Leaving]
no1b4me has quit [Quit: Leaving]
no1b4me has quit [Quit: Leaving]
e1z0 has quit [Client Quit]
e1z0 has quit [Client Quit]
e1z0 has quit [Client Quit]
e1z0 has joined #linux-sunxi
e1z0 has joined #linux-sunxi
e1z0 has joined #linux-sunxi
e1z0_ has joined #linux-sunxi
e1z0_ has joined #linux-sunxi
e1z0_ has joined #linux-sunxi
e1z0 has quit [Ping timeout: 246 seconds]
e1z0 has quit [Ping timeout: 246 seconds]
e1z0 has quit [Ping timeout: 246 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
warpme_ has quit [Quit: Connection closed for inactivity]
warpme_ has quit [Quit: Connection closed for inactivity]
_whitelogger_ has quit [Remote host closed the connection]
<gediz539>
jernej: I could not test it with HDMI yet, only LCD with an A13 board. I will try to print a colorful logo on the banner, let's see what happens.
gediz539 has quit [Quit: Leaving]
prefixcactus has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 265 seconds]
asdf28 has joined #linux-sunxi
reinforce has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
rqou has joined #linux-sunxi
cmeerw has quit [Ping timeout: 272 seconds]
mmarc__ has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
linkmauve has joined #linux-sunxi
mmarc__ has quit []
mmarc__ has joined #linux-sunxi
damex has quit [Ping timeout: 265 seconds]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
yann has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
warpme_ has joined #linux-sunxi
tnovotny has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 264 seconds]
victhor has joined #linux-sunxi
kaspter has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 245 seconds]
ldevulder_ is now known as ldevulder
tnovotny_ has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
mmarc___ has joined #linux-sunxi
damex_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
ldevulder has quit [*.net *.split]
damex has quit [*.net *.split]
tnovotny has quit [*.net *.split]
mmarc__ has quit [*.net *.split]
mmarc___ has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 245 seconds]
andy25225 has quit [Ping timeout: 256 seconds]
andy25225 has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #linux-sunxi
dev1990 has joined #linux-sunxi
ldevulder_ is now known as ldevulder
tnovotny_ has quit [Quit: Leaving]
jo0nas has joined #linux-sunxi
maciejjo has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
tnovotny has joined #linux-sunxi
<prefixcactus>
apritzel: MoeIcenowy: do you own a bananapi ultra and/or berry?
<MoeIcenowy>
prefixcactus: both
rzerres has joined #linux-sunxi
<prefixcactus>
I'm thinking, since I'm going to add pinmux settings for all of the OKA's uarts to r40.dtsi, and (as far as I can tell) the bananapis also use uarts 0,2-5,7 and have them on the same pingroups as the OKA does (the only one that's different is UART4: OKA has it on PG, the berries on PH), I could add the UART4 PH pins to r40.dtsi as well while I'm there
<prefixcactus>
however my knowledge about what uarts the bananapis use is from a patch found in armbian, so I'd rather not submit this without someone testing that the settings really do correspond to the actual hardware
<apritzel>
prefixcactus: the rule of thumb is that we don't add pins unless needed
<apritzel>
and "pins exposed on some GPIO header" do not qualify, since they could be used for anything
<apritzel>
in your case the headers are meant for UART, and have a label next to it, IIUC
<apritzel>
so that's a different case, and you should describe them as such
<prefixcactus>
Do you mean to say that in the case of the bananapi boards the same pins can be considered "more general-purpose" than those on my board, and thus shouldn't be declared as UART pins in the DT?
<apritzel>
yes
<prefixcactus>
that makes sense
<prefixcactus>
BTW, is there a way to switch at runtime between a special function or plain GPIO in such cases, or is it only possible through recompilation of the DT?
<apritzel>
prefixcactus: DT overlays would be the answer
<apritzel>
prefixcactus: if it's just for experimentation, you can also amend the DT on the U-Boot command line with the "fdt" command
<apritzel>
prefixcactus: and btw: it's: preparatory patches first, then your actual changes, so the second case in your email (first r40.dtsi, then board+SoM)
<prefixcactus>
OK.
<prefixcactus>
what about whether to split the r40 patch into the MMC part and the UART part or not, and whether to make the documentation changes a separate patch?
<prefixcactus>
(and if I do, where in the sequence should the docs go?)
<apritzel>
prefixcactus: this is all about pins, right? I would put r40.dtsi part in one patch then
<apritzel>
prefixcactus: and what documentation changes do you mean?
<prefixcactus>
checkpatch gave me a bunch of warnings about the compatible strings for the board&manufacturer being absent from Documentation/devicetree/bindings
<prefixcactus>
(also about possibly adding myself to the MAINTAINERS file, since the patch adds new files)
<prefixcactus>
I'm not sure about MAINTAINERS, but adding documentation seems like a good idea indeed
<apritzel>
ah, binding patches first. That way the automated binding checks will pass when your .dts patch is applied
swiftgeek has joined #linux-sunxi
<apritzel>
and I don't think we put board maintainers into Linux' MAINTAINERS file
<prefixcactus>
so then the correct patch sequence would be pinmux, bindings, board+SoM?
<apritzel>
yes, or swap the first two, that part doesn't really matter
cnxsoft has quit [Quit: cnxsoft]
kaspter has joined #linux-sunxi
zdc has joined #linux-sunxi
zdc97 has joined #linux-sunxi
zdc has quit [Ping timeout: 240 seconds]
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
zdc97 has left #linux-sunxi [#linux-sunxi]
zedascouves has joined #linux-sunxi
<zedascouves>
Hello, I have a completely unresponsive (not bootable) Onda V973 clone tablet (AllWinner A31), after flashing a wrong TWRP recovery. Phoenix Suite doesn't detect it, and I tried using the SD boot method, but there's no response at all when I try to turn the tablet on. What else can I try? Thanks in advance!
<KotCzarny>
since it's onda, it should have the file somewhere available
<zedascouves>
yes, I do have the original .img from the clone maker.
<KotCzarny>
then get a phoenix flasher and use it properly?
<zedascouves>
that's what I'm trying to flash back
<zedascouves>
phoenix flasher = phoenix suite?
<KotCzarny>
yes
<zedascouves>
I've tried, and it doesn't detect the tablet with the usual button combination
Mangy_Dog has quit [Remote host closed the connection]
<KotCzarny>
maybe battery is empty?
<zedascouves>
Shouldn't be, as the unbootable status came right after flashing the wrong recovery, and the battery was at about 70%
Mangy_Dog has joined #linux-sunxi
<KotCzarny>
you can check if the fel mode works, maybe
<zedascouves>
that's what I'm trying to do :-)
<zedascouves>
but I'm not sure how to check it
<KotCzarny>
have you tried fel-sdcard method?
<zedascouves>
I've burned the original firmware to a SD card
<KotCzarny>
nope
<KotCzarny>
it wont work probably
<zedascouves>
ok then
<KotCzarny>
as it will most likely will try to boot from nand anyway
<zedascouves>
I have to zero out the boot sector?
<KotCzarny>
nope, sunxi devices have different layouts
<zedascouves>
Something like:
<zedascouves>
dd if=/dev/zero of=/dev/block/nanda
<zedascouves>
reboot
<zedascouves>
?
<KotCzarny>
nope, not a good idea
<zedascouves>
;(
<KotCzarny>
anyway, you should use phoenix to burn the original image to nand
<KotCzarny>
unless you dont need android
<zedascouves>
yes, I've tried... phoenix doesn't do anything. It's as if the tablet isn't connected at all.
pgreco has quit [Ping timeout: 260 seconds]
reinforce has quit [Quit: Leaving.]
pgreco has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 265 seconds]
camus is now known as kaspter
andy25225 has quit [Ping timeout: 264 seconds]
matthias_bgg has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
netlynx has joined #linux-sunxi
andy25225 has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
popolon has joined #linux-sunxi
cmeerw has joined #linux-sunxi
zdc has joined #linux-sunxi
zdc12 has joined #linux-sunxi
zedascouves has quit [Ping timeout: 240 seconds]
zdc has quit [Ping timeout: 240 seconds]
mmarc__ has joined #linux-sunxi
<martinayotte>
megi: Thanks for your help ! It is now working, and I figured out that reverting only the ccu patch is enough. Now, we need to know what effects will be on non-Pinebook ...
<megi>
effect will be that HDMI out on pinephone will be much less reliable
<megi>
nothing else should be much affected
<megi>
(and that's maybe only in dual output mode)
<MoeIcenowy>
megi: for what?
<MoeIcenowy>
I'm feeling that my patch is now in trouble?
<megi>
there are some issues with original pinebook/edp bridge use case
<megi>
reverting the patches helps
<megi>
maybe you have original pinebook around to try?
<sunshavi>
zedascouves: which OS and which arch are You using?. I think it is probably Win. I have flashed the LY-F1. But that tablet was very picky. It was undetected until I tried (linux-mint 17 on x86-64). That's the way I got it working
<sunshavi>
I tried on x86. But with the same version of linux-mint. But It did not work
vagrantc has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
fuzzybritches has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 265 seconds]
zdc12 is now known as zedascouves
<zedascouves>
sunshavi: yes, I tried on windows 7, as that's the latest version the tablet was ever recognized on.
<zedascouves>
I've never tried on linux
<zedascouves>
windows 7 x64 btw
<zedascouves>
My problem is that I can't know if the tablet ever turns on or not, since nothing shows up on it's screen.
prefixcactus has quit [Ping timeout: 244 seconds]
<martinayotte>
megi: MoeIcenowy: maybe the CCU code could stay there but never executed if DT "model" == "Pinebook" ?
zdc13123 has joined #linux-sunxi
zdc13123 has left #linux-sunxi [#linux-sunxi]
zdc13123 has joined #linux-sunxi
zedascouves has left #linux-sunxi [#linux-sunxi]
zdc13123 has quit [Client Quit]
<sunshavi>
zedascouves: Yes. that's the idea. get the versions somebody else has tried in the past and reported success. That's the way I have got it working
<anarsoul|2>
MoeIcenowy: martinayotte: megi: I remember having a problem with tcon0 parent on pinebook back in ~4.15 days
zedascouves has joined #linux-sunxi
<zedascouves>
Let's see if anyone has more ideas...
<zedascouves>
I have a completely unresponsive (not bootable) Onda V973 clone tablet (AllWinner A31), after flashing a wrong TWRP recovery. Phoenix Suite doesn't detect it, and I tried using the SD boot method, but there's no response at all when I try to turn the tablet on. What else can I try? Thanks in advance!
<anarsoul|2>
basically the driver was thinking that it was using one parent while actually the other parent was configured
<sunshavi>
zedascouves: if adb is not working SD is your only option. and resetting the table for entering fel-mode.
matthias_bgg has quit [Ping timeout: 256 seconds]
andy25225 has quit [Read error: Connection reset by peer]
fuzzybritches has quit [Quit: WeeChat 3.0]
fuzzybritches has joined #linux-sunxi
<zedascouves>
sunshavi: that's fine by me. My problem now is how to enter FEL mode... :-\
<anarsoul|2>
martinayotte: try comparing /sys/kernel/debug/clk/clk_summary for both kernels
<sunshavi>
zedascouves: sunxi wiki should help You with that. The only time I have done it in the past was with another manufacturer(not for allwinner). For my casein the past It was a clip and volume control pressed for 10 seconds {take it with salt}. 4 years I have not repeated those steps
<martinayotte>
anarsoul|2: with the non-working kernel, the clk_rate were different, by reverting CCU patch, it is now the same on 5.11.6 and old 5.7.6.
<zedascouves>
sunshavi: I haven't found anything useful for my case in the wiki yet, but thank you for the interest :^)
asdf28 has quit [Ping timeout: 256 seconds]
<anarsoul|2>
martinayotte: do you have clk_summary from failing and working kernels?
damex_ has quit [Quit: damex_]
mmarc__ has joined #linux-sunxi
<martinayotte>
I've only compared the tcon0/tcon1/tcon-pixel-clock values, but I didn't kept backup, the good ones are 650666666/325333333/72296296, The bad ones were about halt of those, except pixel-clock which was the same if I remember
pgreco has quit [Ping timeout: 260 seconds]
pgreco has joined #linux-sunxi
<jernej>
apritzel: I resolved all driver/DT related issues for A64 in my U-Boot DE2 rework (https://github.com/jernejsk/u-boot/commits/de2-fixes), but it has one important problem - driver for second mixer never gets probed
<jernej>
that's because sunxi has only one vidconsole in sunxi-common.h defined and that probes only mixer0
<jernej>
it works if mixer0 is disabled in DT
<jernej>
because then mixer1 gets sequence number 0
<anarsoul|2>
jernej: out of curiousity, does it break parallel rgb support?
<jernej>
I'm thinking of removing sunxi_de2.c DT-fication in v3 for now
<jernej>
I didn't touch parallel rgb
<jernej>
and since it uses mixer0, it should not be impacted with this problem
<anarsoul|2>
do you mean that it's not supported in reworked de2 driver?
<jernej>
no, all functionality is the same
<jernej>
I just wanted to use as many information from DT as possible
<jernej>
only user visible change from that rework is that HDMI checks also extended EDID for additional timings and modes with pixel clock higher than 297 MHz are rejected (if you connect board to 4k display)
\\Mr_C\\ has joined #linux-sunxi
<jernej>
other than that, patches are either cleanups or moving to DT based probing and DM clocks/resets
<apritzel>
jernej: how does is probe mixer0? they have different compatible strings, don't they? So does it follow the phandles via the allwinner,pipelines property in the display-engine node?
<apritzel>
and just uses the first one, which is for LCD only?
<jernej>
no, it's much more simple
<jernej>
DT framework just goes through all nodes and binds driver (if node is enabled and driver exists)
<jernej>
but then, stdio muxer goes through stdio devices specified in env var
<jernej>
in our case, "serial,vidconsole"
<jernej>
vidconsole means to probe driver in video class with sequence number 0
<jernej>
which is mixer0
<jernej>
vidconsole1 would probe mixer1
<jernej>
but then, there is no console driver for vidconsole1...
<jernej>
so, if you disable mixer0 in DT, mixer0 driver is never binded and thus mixer1 gets sequence number 0 and everything works...
maciejjo_ has joined #linux-sunxi
<jernej>
additional issue - framebuffer is reserved two times, once for each mixer
<jernej>
so I think I'll just leave probing of DE2 driver alone in v3
swiftgeek has quit [*.net *.split]
maciejjo has quit [*.net *.split]
swiftgeek has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
jonkerj has joined #linux-sunxi
tuxd3v has quit [Remote host closed the connection]