<martinayotte>
@smaeul , is André's ATF already in v2017.09, because I still don't power on USB, I've confirmed that by plugging an USB-TTL where no LED turned on. If Yes, then my USB1-VBUS patch is maybe faulty.
<smaeul>
did you set the appropriate gpio for the vbus pin?
<smaeul>
ATF version is independent from u-boot version
<martinayotte>
PD7 as described in schematic ... Did you made any patch yourself for USB1-VBUS ?
<martinayotte>
@smaeul : About FSL_ERRATUM_A008585, my Pine64 still have good date, I will let it run, more than 48hrs for now ... Since I'm working with my OPiWin with the above USB Boot, I'm rebooting it all the time, so it won't be part of testing for now ...
<smaeul>
martinayotte: ok, I'm using CONFIG_HISILICON_ERRATUM_161010101. It's the same concept, it just checks if they're <32 apart, as opposed to <1 apart
<martinayotte>
Maybe ... This bug is a bit strange, because it is not the hardward clock that got corrupt, but the kernel system sysclock, and there is no way to get it back to un-corrupt state except with reboot.
<smaeul>
martinayotte: that's because do_settimeofday64 has a guard to keep difference between the system clock the monotonic clock from overflowing
<smaeul>
so the fact that it requires a reboot to fix is intentional™
<martinayotte>
Yes, that what I figured out, but that really silly if I wish to fix the bug by command line, especially on board in production...
<kilobyte>
do_settimeofday64 could also apply a sanity check for forward bumps, it's not like these kernels will be supported in 2112 (which is what the time warps to for me)
_hp197 has joined #linux-sunxi
hp197 has quit [Ping timeout: 260 seconds]
chomwitt has quit [Ping timeout: 258 seconds]
_whitelogger has joined #linux-sunxi
anarsoul has quit [Ping timeout: 258 seconds]
jbrown has quit [Ping timeout: 248 seconds]
anarsoul has joined #linux-sunxi
Hao has quit [Ping timeout: 240 seconds]
Hao has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
[7] has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
Hao has quit [Ping timeout: 258 seconds]
lurchi__ has quit [Ping timeout: 248 seconds]
JohnDoe_71Rus has joined #linux-sunxi
TheSeven has quit [Ping timeout: 246 seconds]
TheSeven has joined #linux-sunxi
Ntemis has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
qeed has quit [Quit: Leaving]
jernej has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-sunxi
cnxsoft1 is now known as cnxsoft
IgorPec has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
Gerwin_J has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
netlynx has joined #linux-sunxi
sunxi_fan_2 has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
<Putti>
jernej, I meant yesterday that I lowered the resolution to 1080p (tried to use the english passive "you").
leviathanch has joined #linux-sunxi
sunxi_fan_2 has quit [Ping timeout: 260 seconds]
gnufan has quit [Ping timeout: 240 seconds]
f0xx has joined #linux-sunxi
<jernej>
ah, ok
<jernej>
Putti: did you try with another HDMI cable for 4k quality?
<Putti>
I have not yet
gnufan has joined #linux-sunxi
<Putti>
jernej, Most likely not a cable problem: I used it now with a 4k capable machine and it works flawlessly
JohnDoe3 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 248 seconds]
JohnDoe_71Rus has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
nvz has quit [Ping timeout: 248 seconds]
nvz has joined #linux-sunxi
sunxi_fan_2 has joined #linux-sunxi
<sunxi_fan_2>
Net147: sorry, didn't understand your yeserday remark: is your current DRM WIP linux tree providing one framebuffer with two renderers: RGB & HDMI?
<sunxi_fan_2>
... and still can have two different graphics on those screens?
<sunxi_fan_2>
..like two different viewports on the same "larger" framebuffer area..
<sunxi_fan_2>
otherwise, i cannot understand how one can have different graphics on the two outputs from a single "logic" framebuffer..
<sunxi_fan_2>
IIRC, xwindows used to have a "mode" where you could display a smaller viewport of a larger framebuffer.. it was called "virtual framebuffer"..
<sunxi_fan_2>
but it's something that i used maaany years ago on a graphic card called S3 911.. ages ago, really..
<KotCzarny>
feeling old means realizing 1990 was not 10 years ago, but 27 ;)
scream has joined #linux-sunxi
chomwitt has joined #linux-sunxi
paulk-gagarine has quit [Ping timeout: 258 seconds]
agraf has joined #linux-sunxi
paulk-gagarine has joined #linux-sunxi
sunxi_fan_2 has quit [Ping timeout: 260 seconds]
Mr__Anderson has joined #linux-sunxi
scream has quit [Read error: Connection reset by peer]
<Net147>
sunxi_fan_2: the fbdev emulation only provides a single framebuffer that is mirrored on all screens
paulk-gagarine has quit [Ping timeout: 260 seconds]
<Net147>
sunxi_fan_2: to show different graphics on RGB and HDMI, you need to create a separate framebuffer for each screen from your application
<Net147>
sunxi_fan_2: avoid the legacy fbdev API
paulk-gagarine has joined #linux-sunxi
<Net147>
sunxi_fan: ^
montjoie has quit [Quit: leaving]
sunxi_fan_2 has joined #linux-sunxi
SP7RT has joined #linux-sunxi
<sunxi_fan_2>
Net147: i currently have a Qt5.4 application running smoothly on a "simpleFb" /dev/fb0 in a "full screen" model; and my naive plan, for a dual head setup, was to have two Qt apps targeting two different /dev/fbX "legacy" framebuffer..
<sunxi_fan_2>
maybe i'm not so skilled on Qt to know there's a different DRM backend that can achieve the same result, without passing for the "legacy fbdev API".. need to look better.. thanx for your insights
<Net147>
sunxi_fan_2: any reason you're not using a newer Qt version like 5.6 or 5.9? there have been many DRM/KMS improvements in newer versions
<sunxi_fan_2>
KotCzarny: my main issue about the "skew" between the nineties and today, it's that i DO NOT feel that different, "mentally" speaking; ..but the "raw numbers" are scaring! :-)
paulk-gagarine has quit [Ping timeout: 240 seconds]
<KotCzarny>
comparing tech helps sometimes
<KotCzarny>
ie. pentium1@90mhz based laptops vs allwinner h3 boards ;)
<KotCzarny>
both power usage, performance and price ;)
<sunxi_fan_2>
Net147: not really.. just the lazyness to bump-up the underlying "buildroot" environment.. currently i think it already support Qt5.9 (btw a search engine for buildroot package version should be somewhere.. but i don't find it..)
paulk-gagarine has joined #linux-sunxi
<sunxi_fan_2>
so you say that an up-to-date Qt5.9 would have a DRM backend that could run on your "DRM WIP" testing tree and permit different apps to render different content on the two video interface RGB and HDMI.. need to make my homework better.. :-)
montjoie has joined #linux-sunxi
<Net147>
sunxi_fan_2: it will permit a single app to render to 2 different displays
Harrier has quit [Remote host closed the connection]
<Net147>
sunxi_fan_2: if you use 2 applications, then first application will become DRM master and the second application will be unable to do any modesetting
<Net147>
sunxi_fan_2: if using multiple applications it may be better to use Wayland
sunxi_fan_2 has quit [Ping timeout: 260 seconds]
fugitive has joined #linux-sunxi
lemonzest has joined #linux-sunxi
sunxi_fan_2 has joined #linux-sunxi
<Net147>
sunxi_fan_2: you can have a single application render to 2 different displays
Harrier has joined #linux-sunxi
Mr__Anderson has quit [Ping timeout: 258 seconds]
reinforce has joined #linux-sunxi
SP7RT_ has joined #linux-sunxi
SP7RT has quit [Ping timeout: 246 seconds]
a|3x has quit [Ping timeout: 248 seconds]
lkcl has quit [Ping timeout: 248 seconds]
lerc has quit [Ping timeout: 248 seconds]
a|3x has joined #linux-sunxi
lkcl has joined #linux-sunxi
lerc has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
dlan_ has joined #linux-sunxi
dlan has quit [Ping timeout: 260 seconds]
msimpson has joined #linux-sunxi
<Pe3ucTop_>
hello to all, question: How to correctly pass "mtdparts=" option, if only known that it's mtd0 ???
SP7RT_ has quit [Ping timeout: 240 seconds]
qeed has joined #linux-sunxi
dlan_ is now known as dlan
SP7RT has joined #linux-sunxi
phipli has joined #linux-sunxi
msimpson has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
sunxi_fan_2 has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 248 seconds]
SP7RT_ has joined #linux-sunxi
SP7RT has quit [Ping timeout: 246 seconds]
dave0x6d has joined #linux-sunxi
<martinayotte>
@smaeul : Your usb-phy patch for u-boot works perfectly ! Many thanks ! I think it will benefit some other scenario where scanning simply pick first MS and stop scanning. Right ?
Ntemis has joined #linux-sunxi
<martinayotte>
Did you submitted it ?
cnxsoft has quit [Quit: cnxsoft]
lurchi_ is now known as lurchi__
<Pe3ucTop_>
Do anybody have experiance with SPI NAND on Allwinner ?? And boot option from it ??
SP7RT_ has quit [Ping timeout: 258 seconds]
SP7RT has joined #linux-sunxi
lurchi__ is now known as lurchi_
fugitive has quit [Ping timeout: 260 seconds]
netlynx has quit [Quit: Ex-Chat]
<Ntemis>
jernej: here?
msimpson has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
SP7RT_ has joined #linux-sunxi
SP7RT has quit [Ping timeout: 240 seconds]
msimpson has quit [Read error: Connection reset by peer]
fl_0 has quit [Ping timeout: 264 seconds]
fl_0 has joined #linux-sunxi
ykchavan has joined #linux-sunxi
f0xx has joined #linux-sunxi
pmpp has quit [Ping timeout: 260 seconds]
SP7RT_ has quit [Ping timeout: 248 seconds]
<smaeul>
martinayotte: no, it's really hacky. It needs to be redone by someone who understands the u-boot driver model
<smaeul>
and I don't have time to learn u-boot
SP7RT has joined #linux-sunxi
<smaeul>
MoeIcenowy: it looks like the lockups I was experiencing on A64 with your DVFS patches were actually due to the timer bug
<smaeul>
just your patches were making the timer bug very obvious :)
<smaeul>
so with that worked around, they've been very solid (successfull gcc bootstrap, 12 hours mostly idle, reinstalling all distro packages, etc.)
pmpp has joined #linux-sunxi
pmpp has quit [Ping timeout: 248 seconds]
f0xx has quit [Ping timeout: 240 seconds]
pmpp has joined #linux-sunxi
fl_0 has quit [Ping timeout: 258 seconds]
pmpp has quit [Ping timeout: 246 seconds]
jbrown has joined #linux-sunxi
fl_0 has joined #linux-sunxi
pmpp has joined #linux-sunxi
ykchavan has quit [Read error: Connection reset by peer]
ykchavan has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
SP7RT has quit [Ping timeout: 240 seconds]
pmpp_ has joined #linux-sunxi
SP7RT has joined #linux-sunxi
pmpp has quit [Ping timeout: 240 seconds]
fugitive has joined #linux-sunxi
IgorPec has joined #linux-sunxi
jbrown has quit [Ping timeout: 248 seconds]
aalm has quit [Quit: xyz 1.9]
IgorPec has quit [Ping timeout: 260 seconds]
Keziolio has quit [Remote host closed the connection]
Keziolio has joined #linux-sunxi
Keziolio has quit [Changing host]
Keziolio has joined #linux-sunxi
lurchi_ is now known as lurchi__
ykchavan has quit [Read error: Connection reset by peer]
lurchi__ is now known as lurchi_
SP7RT_ has joined #linux-sunxi
pmpp_ is now known as pmpp
SP7RT has quit [Ping timeout: 240 seconds]
libv_ has joined #linux-sunxi
popolon has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 260 seconds]
Putti has quit [Ping timeout: 248 seconds]
lkcl has quit [Ping timeout: 260 seconds]
Putti has joined #linux-sunxi
<Putti>
if there is a breakout in the PCB for uart0 but not for uart1 and uart2, should I leave uart1 and uart2 completely out from the board's device tree or set the property status = 'disabled'?
<Putti>
And this is a H2+ sunvell r69 tv box I'm talking about (doing device tree for it, which I hope one day will be included in the kernel)