<megi>
fALSO: try the ^ patch if it helps with power cycle issues on your orange pi one+ with u-boot 2019.04
<fALSO>
megi, just gonna be able to try it out tomorrow
<fALSO>
megi, its 1:35, im almost going to be
<fALSO>
bed
<megi>
sure, no problem, just informing :)
<fALSO>
yes, i saved the link also
<megi>
good night
NeuroScr has joined #linux-sunxi
itdnhr has quit [Ping timeout: 246 seconds]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 268 seconds]
<sunshavi>
fALSO: I have tried mpv. :). But probably you are sleeping now
<fALSO>
not_yet
<fALSO>
does mpv know how to talk with the v4l2 part ?
<sunshavi>
jaja. It renders a little bit better than vlc. But fullscreen is not posible yet
<fALSO>
nice, i'll have to try it out later
<sunshavi>
fALSO: no idea if that is possible. I have just tried it with mesa 19.1 with glamor disabled
<fALSO>
smoking the last cigarrete, waking up tomorow will be dificult level: HARD
<sunshavi>
ok. Let me know if You need my help for turning off glamor for trying mesa 19.1
<fALSO>
i dont even know what glamor is :-X
<fALSO>
ill have to read up a bit first
<fALSO>
im doing my CEDRUS tests in X.org
<sunshavi>
You are going to know if try mesa 19.1 on your H3
<fALSO>
and the LIMA tests on the framebuffer
<fALSO>
sunshavi, ok :)
<sunshavi>
:o
<sunshavi>
ok mpv with framebuffer?
<fALSO>
probably works!
<fALSO>
tomrrow ill report
<fALSO>
added to notes.txt
<fALSO>
:-)
<sunshavi>
i am going to try it right now. but probably not fullscreen it
<sunshavi>
i have a notes.org
<fALSO>
.org... hum
<fALSO>
EMACS user ?
<sunshavi>
right
<fALSO>
hehe, tried to learn it lots of time, and also common lisp
<fALSO>
still using vim
<sunshavi>
i have done some experimentation with common-lisp and common-qt
<sunshavi>
but emacs is for lisp :P
<fALSO>
yes, from what i know (little)
<sunshavi>
emacs is not a text editor. So no comparisson with vi
<fALSO>
there is a ton of lisp'sss
<fALSO>
emacs has its own kind
<sunshavi>
right. Emacs is as weird as lotus notes was
<fALSO>
nice to see someone using it sunshavi
<fALSO>
never saw one of YOU in the wild :-)
<sunshavi>
I know a few people that uses it. Besides my sons
<fALSO>
never saw normal emacs user *using* it
<sunshavi>
but no emacs on droid. and my son uses droidVim
<fALSO>
:)
<sunshavi>
I am teaching him turbo-pascal on his tablet
<fALSO>
thats a good language to start learning
<fALSO>
its almost english
<fALSO>
great choice sunshavi
<sunshavi>
My son loves how I read news from inside my mail client wanderlust (a complete emacs-lisp MUA). And I am going to stop here cos this is a sunxi chanell
<fALSO>
;-)
vagrantc has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
vagrantc has quit [Quit: leaving]
megi has quit [Ping timeout: 272 seconds]
cnxsoft has joined #linux-sunxi
nashpa has quit [Ping timeout: 248 seconds]
sunilmohan has quit [Ping timeout: 245 seconds]
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
nashpa has joined #linux-sunxi
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 276 seconds]
TheSeven has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
skiboy has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 268 seconds]
freemangordon has joined #linux-sunxi
selfbg has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<jernej>
megi: great! but why data barrier is not enough?
reinforce has joined #linux-sunxi
TheSeven has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
SopaXorzTaker has joined #linux-sunxi
tl_lim has quit [Read error: Connection reset by peer]
warpme_ has joined #linux-sunxi
ldevulder_ is now known as ldevulder
NeuroScr has joined #linux-sunxi
yann has quit [Ping timeout: 245 seconds]
tnovotny has joined #linux-sunxi
msevo has joined #linux-sunxi
<fALSO>
good morning
ldevulder is now known as ldevulder__
ldevulder has joined #linux-sunxi
yann has joined #linux-sunxi
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-sunxi
ldevulder__ has quit [Quit: Leaving]
ldevulder has quit [Client Quit]
ldevulder has joined #linux-sunxi
AneoX has joined #linux-sunxi
<mru>
morning
Mangy_Dog has joined #linux-sunxi
<DuClare>
mooing
plaes has quit [Remote host closed the connection]
plaes has joined #linux-sunxi
plaes has joined #linux-sunxi
jonkerj has quit [Quit: brb]
jonkerj has joined #linux-sunxi
jonkerj has quit [Client Quit]
warpme_ has quit [Quit: warpme_]
jonkerj has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #linux-sunxi
willmore has quit [Ping timeout: 245 seconds]
willmore has joined #linux-sunxi
warpme_ has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
megi has joined #linux-sunxi
<megi>
jernej: because the cache sees different addresses, but you're testing whether writes to different addresses end up in the same location in DRAM
<megi>
you need to make sure you actually read back from DRAM
<megi>
not just from cache
<megi>
dsb just ensures data are written to DRAM, not that they're read back from actual DRAM
<megi>
i added some prints and this function was sometimes returning false negative results, leading to detecting more columns then they are
<Mangy_Dog>
progress............ so tested with the amp module as well as on my board, got my phone hooked up playing music on my board, while it could still do with a low pass filter it seems, as there is some distortion in the peaks... its much much clearer than what the pi was pumping out
<Mangy_Dog>
i think the dac on the pi is boosting a low gained signal internally in the processing rather than producing a correctly dynamic signal to send out on the line out pins
<megi>
anyway, I can't reproduce the issue with this patch anymore
<Mangy_Dog>
which is why the output is much more mushyer and distorted
<Mangy_Dog>
though still the sound quality on these speakers is still less than what i hoped
<Mangy_Dog>
its like a 90s laptop
warpme_ has joined #linux-sunxi
chewitt has joined #linux-sunxi
dddddd has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
lurchi_ has quit [Read error: Connection reset by peer]
<DuClare>
Much? Not much, but what do you want to know
megi has quit [Quit: WeeChat 2.5]
megi has joined #linux-sunxi
<willmore>
I'm trying to figure out why a board erases so slowly. From what I can see u-boot only uses 4k sector erase commands and never uses 32K ones. I'm pretty sure that's not enought to explain the problems I'm seeing--I need to break out the scope and hook it up.
<willmore>
For example, erasing around 12M takes almost 5 minutes. Programming it takes like <20 seconds.
DrFrankensteinUK has joined #linux-sunxi
<willmore>
I've walked through the code to familiarize myself with it and I don't know if this is expected to be this slow. I'm seeing a 4K sector erase taking just over 88ms.
<DuClare>
Ah dangit, I wouldn't know. I know that some flash are ridiculously slow to erase, but just *how* slow is.. I don't know
<DuClare>
Did you try under linux?
<willmore>
Yeah, true, but I'm told these same chips perform better than this in other environments.
<willmore>
I have not as the only chunk large enough to really test on is the root fs and it's memory mapped--which would be a complete disaster.
<willmore>
Plus the programming goes around 800KB/s, so why would erase be that slow?
<willmore>
They're roughly similar actions.
<willmore>
Fortunately, I think my scope understands this protocol. It understands SPI at least.
<willmore>
Oh, I think it can work over the network with sigrok..... That would be way more useful....
<DuClare>
Idk why but I've certainly run into such a thing before.. installing a fresh system took minutes but then updating it took hours because the erase was so slow
<DuClare>
Which chip is it?
<DuClare>
But yeah it's possible there's something fishy going on.
<willmore>
w25q128
<willmore>
I don't have a datasheet for that specific one.
<martinayotte>
willmore: did you tried under linux with mtdtools ?
<willmore>
martinayotte, not yet as the only large partition is the rootfs one and it's memory mapped--which would be painful.
<willmore>
I think the problem might be that u-boot only uses 4k erases. The data sheet says a typical erase time is 30! ms and could be as high as 200.
<ElBarto>
ok that's weird, sometimes sunxi_de2_probe isn't called ...
<willmore>
Since I'm only seeing 88 ms, it could be better, but even 30 is too much. I think I need to see if I can teach it to use larger erase instructions.
<willmore>
martinayotte, do you know if they just call kernel functions to access the chip or do they do low-level SPI operations?
CC0422 has joined #linux-sunxi
<willmore>
Because the kernel code looks to be used by u-boot. At least every time I've googled a u-boot function name or constant, the results I get are first for the kernel and they're identical.
<ElBarto>
anarsoul: this is two boot (power down between them), one calls the probe function one doesn't ...
<willmore>
I'll go hook up a scope and peek around. Thanks for the advice everyone.
<anarsoul>
ElBarto: debug it?
<ElBarto>
anarsoul: that's what I'm doing :)
<ElBarto>
anarsoul: but I'm not familiar with u-boot device stuff
<martinayotte>
willmore: I don't know for u-boot, I've always used mtd from linux kernel using flashcp
<DuClare>
willmore: I think mtd tools use ioctls on the mtd device which in turn would call the spi-nor driver
<anarsoul>
ElBarto: that's not a lot of C code, you can figure it out :)
<DuClare>
(Unless there's a different way to set it up that I do not know about)
<ElBarto>
anarsoul: yeah ... maybe ... I mean the way that device are found and driver instanciated is a bit obscure to me :)
<willmore>
DuClare, then I would expect the same code to get executed by both linux and u-boot if they really are sharing the code. Now, there are plenty of things they don't share--like caches being turned on and bus speeds being set, so that's a possible difference. I'll go look at what's happening in reality and see if that helps. :)
<DuClare>
Probably not caches, probably not bus speed issue if programming is still fast
<DuClare>
I'm not familiar enough with the code to tell where it decides what sector size erase to use
<DuClare>
If it comes from the mtd layer, then u-boot wouldn't have that I think
<DuClare>
You're playing with the sf command, yes?
<DuClare>
But yeah, take a look
<willmore>
DuClare, yes, the sf command. The best I can see, there is no code for anything other than 4K erase in u-boot. There are some tables where it will convert instructions from non-BAR to BAR versions and those know how to translate 32K erases (but not 64K ones).
<willmore>
So, if the mtd driver in linux is passing in 32K erase commands then it's possible it's getting that 5x speedup (going from datasheet values of typical erase of 4K being 30ms and 32K being 120ms)
<DuClare>
Right
<DuClare>
I think that's the most plausible explanation (assuming it's better in linux which I guess we haven't confirmed yet)
<DuClare>
Let me know if you find out :)
CC0422 has quit [Quit: -a- IRC for Android 2.1.52]
netlynx has quit [Quit: Ex-Chat]
<willmore>
(sorry got the math wrong, it's 2x speedup for 32K erases and 3x for 64K erases)
<willmore>
DuClare, thanks. I will. Not sure I'll be able to do much testing in Linux so that I can do a comparison due to the memory mapped nature of this system.
<willmore>
Hmm, I have an Opi0 board that I soldered a 16MB NOR flash onto. I wonder if I can use it as a baseline. It's a different flash chip (similar model, same vendor) and SoC, but it should give me a ballpark of what should be practical.
<willmore>
I guess I can either dig out the logic analyzer now or beat my head against overlays and then get the logic analyzer out. :)
<DuClare>
The third alternative is to git your hands dirty with the code, that's probabably where you end up having to go anyway if you want to make it fast :P Hopefully it doesn't take a logic analyzer to figure out what the code does
<DuClare>
Of course I say this only because I'm the doofus who has no logic analyzer.
<willmore>
I've already dug through the code and didn't see anything unusual, but the u-boot code is a bit of a dogs breakfast--layers of hand grown OO and more than a few kludges.
NeuroScr has joined #linux-sunxi
diego_r has quit [Remote host closed the connection]
dgm78 has quit [Quit: Leaving]
ninolein has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
<jernej>
vagrantc: That should be possible already. What kind of issues do you have?
<jernej>
dgm78: Same as before, patches exist, mainlining them is very slow. I'll send H6 I2S patches soon (prerequirement for HDMI audio)
<vagrantc>
jernej: no idea how to set it up, mostly ... although at the moment, i don't have an HDMI output device or cables and such :)
<jernej>
well, I never worked with any type of LCD output, only HDMI and TVE
<jernej>
but having dual output should work if you correctly define DT nodes and somehow make sure that TCONs use different parent clock
<vagrantc>
seems like HDMI is marked as disabled in the device-tree
<vagrantc>
just tweaking the device-tree, then?
<jernej>
read second part of my sentence
<jernej>
that is easiest done in clock driver
<vagrantc>
reading and comprehending are very different things :)
<anarsoul>
jernej: IIRC it doesn't work properly because tcon0 and hdmi phy share the same clock
<anarsoul>
they both use pll-video0
<anarsoul>
it didn't work for me in 5.0 and I haven't tried it on 5.2 yet
<jernej>
I think it's just a matter of configuration. Let me check datasheet
<jernej>
vagrantc: your focus is on A64?
<anarsoul>
jernej: IIRC datasheet is wrong and on A64 hdmi phy can be clocked from pll-video0
<jernej>
actually, there is no explanation for HDMI PHY clock sources in A64 datasheet
<anarsoul>
see 558a9ef94a329a1ac75613407ad15d0d0071ff4c
<jernej>
I know, I made a lot of tests for that
<anarsoul>
right
<jernej>
but this doesn't mean it doesn't it isn't possible, just that you have to carefully match resolutions so clock sharing is possible
<jernej>
s/it doesn't//
<anarsoul>
jernej: yeah, but it's not implemented atm
<jernej>
what would you implement? resolution filtering?
<vagrantc>
jernej: for now, sure, have a few A64 devices, most interested in pinebook
<anarsoul>
jernej: well, HDMI just doesn't work if LCD is running at 1080p 60Hz
<anarsoul>
so I'm not sure what filtering is possible here
<anarsoul>
LCD resolution is fixed
<vagrantc>
was hoping to someday give a presentation using the pinebook, but if it requires a lot of manual configuration, this doesn't sound plausible with arbitrary HDMI devices
<anarsoul>
vagrantc: you can use one or the other
<jernej>
anarsoul: can you show me panel configuration node for 1080p?
<anarsoul>
i.e. "xrandr --output eDP1 --off; xrandr --output HDMI-1 --auto" works for me
<vagrantc>
anarsoul: in which case i'll probably just borrow a laptop :)
<jernej>
anarsoul: doesn't panel need a DT node with all timings specified?
<anarsoul>
jernej: 1) it's not supported (really, look at simple-panel bindings) 2) eDP panels have EDID
<jernej>
anarsoul: I suppose that first number after string in Modeline line is frequency
<anarsoul>
jernej: yes
<jernej>
HDMI needs 148.5 MHz for 1080p, so these two modes are not compatible
<anarsoul>
138.50 KHz
<jernej>
are you sure it's not MHz?
<anarsoul>
oh, right
<anarsoul>
MHz
<jernej>
so 10 MHz off
<anarsoul>
for 768p pinebook it's 72.30 MHz
<vagrantc>
yeah, i don't think this is a 1080p model...
<anarsoul>
it's reduced timings
<vagrantc>
1366x768 is the resolution i'm getting
<anarsoul>
it's pretty standard mode
<anarsoul>
try 'cvt -r 1920 1080 60' and you'll get 138.5
<jernej>
you have to match pixel clock from panel and HDMI, but it seems that 1080p on panel and 1080p on HDMI doesn't use same pixel clock
<anarsoul>
s/timings/blanking
<libv>
panels are pretty resilient
<libv>
get the datasheet
<libv>
they usually accept quite a wide range of timings
<libv>
and are sometimes very forgiving when it comes to either v/hsync or de
<libv>
anarsoul: the author of cvt (me) can tell you that reduced timing is not equal to standard cvt timing, and even standard cvt timing is not the same as the usual 148.5 1080p vesa standard resolution
<anarsoul>
jernej: tcon0 can use pll-mipi instead of pll-video0 (yeah, pll-mipi source is still pll-video0 but we can definitely get more combinations)
<jernej>
yes, that might do it
<anarsoul>
jernej: only in theory. It doesn't work in practice
<jernej>
just convince CCU driver PLL-MIPI is the only clock source, but then you will also have to make sure that PLL-MIPI gets reconfigured every time HDMI pixel clock changes
<jernej>
I think this is done with notifiers, but I'm not sure
<anarsoul>
IIRC mripard was against removing pll-video0 from tcon0 sources
reinforce has quit [Quit: Leaving.]
<jernej>
I don't remember...
<anarsoul>
and yeah, I'm not sure how to convince pll-mipi to reconfigure everytime when pll-video0 changes