rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
<karlp> anyone have a china shipping consolidiaator they're happy with? for generall consumer retail honestly, nothing seriously commerical
NeuroScr has quit [Quit: NeuroScr]
<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
<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
<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]
lurchi__ has joined #linux-sunxi
Ke has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 245 seconds]
ldevulder has quit [Quit: Leaving]
warpme_ has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria]
megi has quit [Ping timeout: 258 seconds]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 245 seconds]
warpme_ has quit [Quit: warpme_]
afaerber has joined #linux-sunxi
gaston_ has joined #linux-sunxi
selfbg has quit [Ping timeout: 258 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 272 seconds]
matthias_bgg has joined #linux-sunxi
sunshavi has joined #linux-sunxi
diego_r has joined #linux-sunxi
warpme_ has joined #linux-sunxi
ldevulder has joined #linux-sunxi
ldevulder has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
<libv> hrm, just closed old windows... jbizcocho from img did not return recently it seems
<KotCzarny> hope dies last?
<libv> everything about it smelled not very well thought through, and definitely not broadly supported by img management
<fALSO> good evening
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 268 seconds]
ldevulder has joined #linux-sunxi
vagrantc has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 245 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<montjoie> ah ah, first h6 kernelci boot
<fALSO> kernelci
<fALSO> didnt knew that project
msevo has quit [Quit: Leaving]
chewitt has quit [Remote host closed the connection]
<fALSO> montjoie, is that site privatE?
<montjoie> kernelci is public
<fALSO> i meant, can people "register" to create their builds ?
<fALSO> or is that part private?
msimpson has joined #linux-sunxi
<fALSO> hum sirs... i've been taking a look at the boot of my PI ONE PLUS
<fALSO> it shows U-Boot SPL ...
<fALSO> but it seems that after that, it should display another message with U-Boot something
<fALSO> so , only "half" the uboot is working for me
<fALSO> going to confirm is theres any problem with boot.cmd or something
<montjoie> fALSO: it boots only kci builds
<mru> u-boot should print a banner quite early
<fALSO> it is just printing the SPL banner
<fALSO> and then hangs at: Trying to boot from MMC...
<mru> yes, so things go wrong well before it would be looking at boot.cmd
<fALSO> its probably something something that i did
<fALSO> because i also tried downgrading to 2019.04 and its the same
<fALSO> ill waste a few more hours today when i get home =)
<fALSO> going to also take a look at which arm-trusted-firmware armbian is using for this board
<fALSO> im not sure, but i believe SPL has something to do it that?
<fALSO> im probably saying something stupid
JohnDoe_71Rus has quit [Ping timeout: 248 seconds]
BenG83 has joined #linux-sunxi
TEKrantz has quit [Ping timeout: 268 seconds]
TEKrantz has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
msimpson has quit [Remote host closed the connection]
msimpson has joined #linux-sunxi
megi has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
TEKrantz has quit [Quit: Oh, so they have Internet on computers now!]
ldevulder has quit [Ping timeout: 258 seconds]
vagrantc has quit [Quit: leaving]
cnxsoft has quit [Quit: cnxsoft]
JohnDoe_71Rus has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
DrFrankensteinUK has quit [Ping timeout: 248 seconds]
DrFrankensteinUK has joined #linux-sunxi
reinforce has joined #linux-sunxi
vagrantc has joined #linux-sunxi
yann has quit [Ping timeout: 244 seconds]
tnovotny has quit [Ping timeout: 272 seconds]
SopaXorzTaker has quit [Remote host closed the connection]
iamfrankenstein has joined #linux-sunxi
chewitt has joined #linux-sunxi
aalm has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
yann has joined #linux-sunxi
diego_r has quit [Ping timeout: 244 seconds]
AneoX has quit [Quit: Textual IRC Client:]
<ElBarto> is anybody have problems with u-boot and video on pine64/pine64-lts ?
<ElBarto> I don't have video in u-boot but as soon as the freebsd loader get executed I can use efi gop
<ElBarto> running mainline on both (2019.07) but I'm pretty sure that it happens for me since 2019.01 (at least)
<anarsoul> I'm running u-boot from april-may 2019 on pine64-lts and video works just fine
<ElBarto> damn
<fALSO> elbarto, weird resolution?
<ElBarto> I've checked with another screen on my lts but on on the pine64
<ElBarto> fALSO: no
<fALSO> OK, i had some problems but it was because of my Ultra Wide Monitor
<fALSO> 2560x1080
<fALSO> so forget about what i asked ;-)
<ElBarto> this is a small car monitor which only do 1280x1080 max
* vagrantc was pleasantly surprised to see HDMI output from u-boot on pine64+ recently
<vagrantc> anarsoul: any word on HDMI output for pinebook?
<vagrantc> or anyone else for that matter?
<ElBarto> and it seems that orangepi-pc2 cannot netboot with 2019.07 ...
<ElBarto> phy auto neg fails
<anarsoul> vagrantc: well, you can disable anx6345 driver in u-boot and it will use hdmi
<vagrantc> but then won't have LCD ?
<anarsoul> yep, in u-boot
<anarsoul> linux has its own driver
* vagrantc is travellign and giving some presentations and wondering it it would be possible with the pinebook
<anarsoul> vagrantc: poke jernej and mripard
chewitt has quit [Quit: Zzz..]
<vagrantc> doh. i forgot the mini/micro hdmi out cable anyways...
<vagrantc> jernej, mripard: any prospects on using both the LCD and HDMI output at the same time on pinebook?
iamfrankenstein has quit [Quit: iamfrankenstein]
arnidg has quit [Ping timeout: 244 seconds]
<montjoie> hello I have a nanopineoplus2 and the network dont work in uboot, certainly due to power not enabled
<montjoie> the config have MACPWR="PD6"
<anarsoul> vagrantc: that's not limited to pinebook. It's about having multiple outputs on A64
<vagrantc> anarsoul: i see
<montjoie> how can I debug my problem ?
Basil has joined #linux-sunxi
arnidg has joined #linux-sunxi
Basil is now known as Guest76047
msimpson has quit [Quit: Leaving]
Guest76047 has quit [Remote host closed the connection]
<ElBarto> fALSO: ah ! it might be weird resolution after all
<ElBarto> if I switch my monitor from 16:9 to 4:3 it works everytime
<ElBarto> yeah or not
dgm78 has joined #linux-sunxi
<dgm78> jernej, Hi! News about HDMI audio for H6?
<willmore> Anyone know much about u-boots SPI NOR functions?
DrFrankensteinUK has quit [Quit: - Chat comfortably. Anywhere.]
<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: ever seen something like this :
<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> printf() has been good to me.
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria]
diego_r has joined #linux-sunxi
<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
<anarsoul> libv: thanks, good to know
ldevulder_ has quit [Quit: Leaving]
ninolein has quit [Quit: - Chat comfortably. Anywhere.]
djakov has quit [Ping timeout: 252 seconds]
ldevulder has joined #linux-sunxi
willmore has quit [Ping timeout: 245 seconds]
djakov has joined #linux-sunxi
vagrantc has quit [Ping timeout: 250 seconds]
willmore has joined #linux-sunxi
Putti has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
afaerber has joined #linux-sunxi
arnidg has quit [Quit: ZNC -]
arnidg has joined #linux-sunxi
arnidg has quit [Quit: ZNC -]
<fALSO> im probably doing something wrong
arnidg has joined #linux-sunxi
<fALSO> uboot doesnt pass the SPL part
<fALSO> on the orange pi one plus
<fALSO> maybe going to try to build uboot with debug
<fALSO> Trying to boot from MMC1
<fALSO> U-Boot SPL 2019.07-00347-g0e80dda32c-dirty (Jul 17 2019 - 21:26:44 +0100)
<fALSO> DRAM: 1024 MiB
<fALSO> hangs in here
arnidg has quit [Client Quit]
arnidg has joined #linux-sunxi
skiboy has quit [Ping timeout: 268 seconds]
<jernej> fALSO: btw, which version of binutils you use?
<fALSO> hum, im on the future probably
<fALSO> let me confirm
<jernej> one of previous versions had a bug which didn't link U-Boot correctly
<fALSO> [I-O] [ ] cross-aarch64-unknown-linux-gnu/binutils-2.32-r1:2.32
<jernej> that's fine
<fALSO> going to take a look on how to enable debug on uboot
<libv> fALSO: do you perhaps have a known good version?
<fALSO> i should've backuped up the working one :/
<libv> well, the actual binary is not important, the version is
<libv> it usually pays to have a quick scroll through the relevant bits of history before going into actual debugging
<jernej> fALSO: it would be also a good idea to compile debug build of ATF
<jernej> that way you'll see some text from it to confirm it works
<jernej> I think you just add "DEBUG=1" to ATF build command
<fALSO> yap uboot debug build failed ;-), gonna try ATF
<fALSO> aarch64-unknown-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram'
<fALSO> aarch64-unknown-linux-gnu-ld.bfd: region `.sram' overflowed by 1296 bytes
<fALSO> well, it seems im already building it with DEBUG
<fALSO> im doing: make CROSS_COMPILE=aarch64-unknown-linux-gnu- PLAT=sun50i_h6 DEBUG=1 bl31
<jernej> so it seems ATF is not bundled in U-Boot binary
<fALSO> im copying bl31.bin into the u-boot root folder
<megi> fALSO: if you want known good one I have it online
<fALSO> megi, yes, share it with me please
<jernej> and which binary you flash on SD?
<megi> dl pi3.tar.gz
<fALSO> so that i figure out if the problem is there or other place
<megi> uboot is there
<fALSO> jernej,
<fALSO> dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=8k seek=1
<megi> i use for opi3 config for opi one+ :)
<jernej> fALSO: so no issues there...
<jernej> are you using default config or your own?
<fALSO> default
<fALSO> make ARCH=arm CROSS_COMPILE=aarch64-unknown-linux-gnu- -j4 orangepi_one_plus_defconfig
<jernej> ok, then I'm out of ideas
<fALSO> no problem
<megi> i can even upload the latest build that you can test if my fix for power up boot unreliability works for you too
<jernej> I don't have OrangePi One Plus, just Orange 3, but I think it shouldn't be much different
<megi> it's the same, basically
<fALSO> gonna try it with your uboot megi
<megi> as far as u-boot concerned
<fALSO> yay
<fALSO> it worked
<megi> yup
Putti has quit [Ping timeout: 272 seconds]
<fALSO> should i try building uboot for a orange pi 3?
<fALSO> just to see if it works, or maybe is something worng on my system
<fALSO> gonna use your config
<megi> there's no such defconfig
<fALSO> Linux orangepioneplus 5.2.0+ #15 SMP Wed Jul 17 22:46:59 WEST 2019 aarch64 GNU/Linux
<fALSO> :-)
<megi> please try powercycling it a few times :)
<megi> with serial console connected, ideally
<megi> if you can make it lock up just after atf prints its stuff
<fALSO> let me try
<fALSO> nice, reboot also WORKS
<fALSO> and kernel panic after it booted
<fALSO> ;-D
<fALSO> megi, your version seems to always boot at first try
<megi> how many tries?
<fALSO> 3
<fALSO> gonna do one moar
<megi> yeah, try more like 20 :)
<megi> for me it fails more the more I try
<fALSO> well the other working one that i had failed like 2 in 3
<fALSO> ;-D
<megi> :)
Mangy_Dog has quit [Ping timeout: 268 seconds]
<megi> I wonder if it fails, whether it will print the wrong DRAM size
<fALSO> i should order a few more orange pi chargers
<fALSO> this one does a nice weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee sound
<megi> it's enough to powercycle without letting it boot to linux
<fALSO> like the sound of a CRT tv turned on
<megi> nice
<fALSO> lolololol ;-D
lurchi__ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-sunxi
<fALSO> your config doesnt "work" on a more recent uboot
<fALSO> asks a lot of difficult questions :-P
<megi> I know
<fALSO> well, im gonna keep with your bin!
<fALSO> wanted to be able to figure out why the master version doesnt work, but i dont have enought knowledge on how to do it ;-)
dddddd has quit [Remote host closed the connection]
gaston_ has quit [Quit: Konversation terminated!]
<fALSO> megi, powered it on and off for more 3 times, and it always booted
<fALSO> ;-D
<megi> ok, thanks
<fALSO> thank you too
skiboy has joined #linux-sunxi
dev1990_ has quit [Remote host closed the connection]
dev1990 has joined #linux-sunxi