jstein has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
kaspter has quit [Ping timeout: 258 seconds]
kaspter has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
curtis22 has quit [Quit: Leaving]
pg12 has quit [Ping timeout: 276 seconds]
pg12 has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
pg12 has quit [Ping timeout: 264 seconds]
pg12_ has joined #linux-sunxi
AnticitizenOne has joined #linux-sunxi
fire219 has quit [Read error: Connection reset by peer]
Gerwin_J has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
jernej has joined #linux-sunxi
mosajjal has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
mosterta has joined #linux-sunxi
jernej has quit [Ping timeout: 244 seconds]
reinforce has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
mosterta has quit [Ping timeout: 244 seconds]
iamfrankenstein has joined #linux-sunxi
OneSploit has joined #linux-sunxi
OneSploit has quit [Changing host]
OneSploit has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein has joined #linux-sunxi
ganbold has quit [Ping timeout: 240 seconds]
foxx_ has joined #linux-sunxi
MiLeon has joined #linux-sunxi
ganbold has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
yann has quit [Ping timeout: 258 seconds]
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein has joined #linux-sunxi
IgorPec has quit [Ping timeout: 244 seconds]
OneSploit has quit [Quit: Leaving]
kaspter has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
orly_owl has joined #linux-sunxi
OverCR has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
apritzel has joined #linux-sunxi
ganbold has quit [Ping timeout: 244 seconds]
popolon has joined #linux-sunxi
Putti has joined #linux-sunxi
yann has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
MiLeon has quit [Quit: Leaving]
OverCR has quit [Quit: Leaving.]
OverCR has joined #linux-sunxi
aalm has quit [Ping timeout: 265 seconds]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
aalm has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
lemonzest has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
libv_ has quit [Ping timeout: 276 seconds]
libv has joined #linux-sunxi
Putti has quit [Ping timeout: 250 seconds]
Putti has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
IgorPec has quit [Ping timeout: 258 seconds]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 244 seconds]
ganbold has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
<oliv3r>
hi, i'm playing with the a stable u-boot (2016-05) (on an ancient 4.2 kernel) and while a cold start/reset works, if i reboot linux, the SPL just hangs after printing th efirst line. sometimes I get the "DR" from the DRAM init, but that's it. A new kernel with the new bootloader also shows this same problem (4.6) I'm using the stock lime2 defconfig
Putti has quit [Ping timeout: 244 seconds]
<KotCzarny>
lower your dram speed in uboot?
<KotCzarny>
though, it might be something else
<oliv3r>
it's something else :p
<oliv3r>
it only fails on reboot for one
<oliv3r>
not on reset
<oliv3r>
and the other versions of u-boot work fine; and i haven't seen any changes to the lime2 on dram (but i could have overlooked there)
<KotCzarny>
still, try lowering dram speed
<KotCzarny>
:)
<KotCzarny>
before someone knowledgeable comes
<oliv3r>
but if the DRAM spee dis to high, why is not changed upstream
<oliv3r>
i doubt it's the memory itself, as we have this on all of our bards
<oliv3r>
and thus, everybody should be having the same issue :p and i don't find anything yet online
<oliv3r>
it fails during the printf of printf(DRAM: %d\n", get_ram_size()); (or something from the top of my head)
<oliv3r>
i'll download a pre-made image to see if that changes things
<oliv3r>
bisect time
OverCR has quit [Quit: Leaving.]
<MoeIcenowy>
oh
<MoeIcenowy>
using rtl8723bs bluetooth on mainline kernel
<MoeIcenowy>
is a disaster
Putti has joined #linux-sunxi
<MoeIcenowy>
Wi-Fi is easily to be driven
<MoeIcenowy>
but Bluetooth is not...
<apritzel>
MoeIcenowy: really? Isn't that simple some AT commands send via one of the UARTs
<tkaiser>
While at the same time Olimex own 'Stable official image' uses 384 MHz DRAM clock (old u-boot looking into fex file where this is still the default)
<tkaiser>
So Tsvetan claimed 532 MHz are possible -- https://olimex.wordpress.com/2014/10/27/a20-olinuxino-lime2-review-and-updates/#comment-16211 --, Olimex submitted a patch with the maximum 480 MHz, this has been accepted and no one ever tested while at the same time Olimex own settings files and images use the old 384 MHz from Lime here and there. I would call this a good start :)
<wens>
has anyone ran into mmc_release_host warnings with 4.8-rc1?
<oliv3r>
tkaiser: i'm bisecting it right now
<oliv3r>
tkaiser: i'm not suffering stability problems per say
<oliv3r>
tkaiser: i just updated the bootloader and its troublesome, and the old one is fine
<tkaiser>
oliv3r: But I still highly doubt that the 480 MHz we're using all the time have ever been tested correctly, it seems all is based on the assumption that Lime2's PCB routing is great and 532 MHz DRAM clock (!) are possible.
<oliv3r>
tkaiser: i wholeheartedly agree with you
<oliv3r>
tkaiser: and i'm not even denying this
<oliv3r>
tkaiser: but we have 700 boards in stock right now, and they all fail with the later bootloaders, and 2015.07 works fine
<oliv3r>
so hence, bisect
<tkaiser>
So why fiddling around with a value that has never been tested instead of lowering it to eg 432 MHz unless some *real* tests have been passed?
<oliv3r>
tkaiser: i also agree :)
<tkaiser>
BTW: Olimex uses 2015.10 on their newer OS images with mainline u-boot
<oliv3r>
interesting
<oliv3r>
tkaiser: mind you though, if it where really a memory freq. problem
<oliv3r>
it would randomly fail,a nd also on a reset button press
<oliv3r>
not only on a reboot
<oliv3r>
and guaranteed on a reboot
<tkaiser>
oliv3r: Sure, different issue. I just wonder why we all believe in these strange defaults. Armbian forum is full of problems. Latest report: Using recent u-boot hangs disappeared on 5 boards (sample size a bit low) after lowering clockspeed from 480 to 456 MHz
<oliv3r>
i can still run massive tests om lime2's
<oliv3r>
i just need to have it reasonably automated
<oliv3r>
and i can put some time in helping there
Sakami_ has joined #linux-sunxi
<tkaiser>
I don't get why we should use these defaults anyway. They seem to be only backed by 'hooray, we improved trace routing between SoC and DRAM' instead of a series of reliability tests.
<oliv3r>
yes, but, the past is the past :)
<oliv3r>
lets run a big scale test and then debunk the current settings
<oliv3r>
and i can help in running the test
<oliv3r>
on many many boards, i just need it to be somewhat automated
<oliv3r>
swapping SD cards is okay
<oliv3r>
manually analyzing the data too
<oliv3r>
step 1 i guess is to have a SD image, with a few bootloaders in /boot, the tests that run automatically
<tkaiser>
oliv3r: unfortunately I can not test with the only Lime2 I have (productive use now). But it should already suffice to use an SD card image, take lima-memtester binary from the bottom of this page https://github.com/ssvb/lima-memtester/releases then put it in /usr/local/bin/ and call it from /etc/rc.local
<oliv3r>
well the bad news is, looks like i was off by a year :p i tried to bisect between 2015.07 and 2015.10 and they all ended up working, but i needed to do it between 2016.01 and 2016.05
<oliv3r>
tkaiser: i know how to do it manually quite easy :)
<oliv3r>
done it a few times :p
<oliv3r>
we just need to automate the whole thing a bit more
<oliv3r>
a quick bash script maybe, that takes good/bad as argument
<oliv3r>
and on good it goes a version up, and on bad a version down
<oliv3r>
version == u-boot compiled with higher/lower clock speeds
<tkaiser>
oliv3r: Sure but my approach is different, checking the 480 MHz first and if they fail simply use 432 and check from this base
<oliv3r>
exactly
<oliv3r>
hence a simple script that does that
<oliv3r>
start at the max speed
<oliv3r>
if that fails, do a ./memtest bad
<oliv3r>
and the script goes down a version for you
<oliv3r>
:)
<oliv3r>
so you don' thave to fiddle much with the files
<tkaiser>
oliv3r: Could be done easily with Armbian since we package u-boot as .deb which can be simply installed by a script using dpkg -i
<oliv3r>
not that manually doing is THAT much work
<oliv3r>
or that
<oliv3r>
im thinking a lot simpler though :p just a /boot/u-boot/ with 5 or so u-boots in it
<oliv3r>
but either works
<tkaiser>
oliv3r: the package post install script simply overwrites u-boot+spl using dd. I automated this a while ago for our beloved problem board ;)
<tkaiser>
Tested through 64 u-boot combinations back then automatically
<oliv3r>
that's the reason i'm mucking with the new bootlader :)
<oliv3r>
i think he has old boards that suffered the gbit layout problem
<oliv3r>
and combined that with the master/slave mode of the phy
<tkaiser>
oliv3r: Yes, but the link was more to outline the 'automatic test' approach ;)
yann has quit [Ping timeout: 250 seconds]
<oliv3r>
yeah i found that now too :)
<oliv3r>
still requires to generate 64 debian packages :p
<tkaiser>
oliv3r: I would assume 480, 456, 432 and 408 should be enough?
<oliv3r>
but not bad at all :)
<oliv3r>
yeah i think so too
<tkaiser>
Ok, I fire up my build host
<oliv3r>
:p
<tkaiser>
Should I use 2016.07 or better 2016.05?
<oliv3r>
i'm bisecting 2016.03 - 2016.05 because 05 oens't work anymore
<oliv3r>
(for me)
<oliv3r>
after a soft-reboot
<oliv3r>
so i'd go with 2016.03
<tkaiser>
ok
<oliv3r>
btw, i'm currently testing on the new boards with the new gbit phy :)
<MoeIcenowy>
wens: have you tried to use uart1 on A23/33?
jernej has joined #linux-sunxi
yann has joined #linux-sunxi
<oliv3r>
tkaiser: or, i just make 5 sd cards, with each a different bootlaoder
<oliv3r>
and test 5 boards in parallel :)
<tkaiser>
oliv3r: Good luck, tried that with 4 NanoPi NEO and got totally confused so I ended up putting 3 in the drawer to get consistent results (testing consumption/thermal stuff)
<oliv3r>
lol
<oliv3r>
i'll obviously label the sd cards :)
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
dearfibonacci has quit [Quit: Leaving]
<KotCzarny>
oliv3r, well, master board with a bunch of relays that can reboot boards on memtest failur?
<KotCzarny>
on a side note: i've just added power switch to my orange box, because its easier to cycle it than to eject/insert power plug
cnxsoft has quit [Quit: cnxsoft]
<oliv3r>
KotCzarny: works great, but requires effort :)
<KotCzarny>
but effort is one time
<oliv3r>
well if you can get my boss to alot time for this effort; then all is peaches :)
<KotCzarny>
and saves time later, also adds a lot of convenience
<oliv3r>
ok for some reason affa020559bc breaks u-boot on mainline
<oliv3r>
KotCzarny: also these boards are built into machines :)
<KotCzarny>
well, tell him that you need universal board testing station
<oliv3r>
lol 'but these boards are supposed to work, we buy these as working boards, not my problem
<KotCzarny>
because you dont want customers with rma
<KotCzarny>
but you want happy customers
<oliv3r>
ok wow, why does enabling the LDO3 and LDO4's on lime2 cause it to no longer work after a boot?
<oliv3r>
was this tested at all?
<oliv3r>
nobody complained yet?
<oliv3r>
i'll figure out as to why this goes wrong after a reboot, but it is flabergasting
<tkaiser>
oliv3r: This Armbian image should ship with 2016.05 @ 480 MHz DRAM clock (IIRC)
<oliv3r>
everything is in it?
<oliv3r>
i'll download them :)
<oliv3r>
thanks tkaiser
<tkaiser>
oliv3r: the Armbian image needs little attention in the beginning. You have to choose a new root pwd (default 1234) and then create a normal user
<oliv3r>
if its a 1 time thing, i'll manager
<tkaiser>
So I would start with a single image, do this stuff, untar the archive with the u-boot debs and then clone this SD card image to be used on different boards in parallel
<oliv3r>
does it work headless? only with a serial console?
<tkaiser>
oliv3r: Sure, but you should check at least once you see the spinning cube in front of a grey background!
<tkaiser>
If background is read then something's going wrong. But if this works once I would assume you can simply redirect lima-memtesters output to a file for further test runs
<tkaiser>
s/read/red/
<oliv3r>
aye
<oliv3r>
i'll have to find a monitor
<oliv3r>
or does it automatically work with the olimex display?
<oliv3r>
(the resistive touch one)
<oliv3r>
hmm, maybe my bug is in my dtb
<oliv3r>
i should check my device tree for those ldo settings too i guess
dlan has quit [Ping timeout: 258 seconds]
<tkaiser>
oliv3r: dont's think so, better use SSH for the first time to set it up (or console)
dlan has joined #linux-sunxi
<oliv3r>
to bad :(
<tkaiser>
oliv3r: I don't understand enough to confirm testing with LCD is ok (maybe the lima part of memtester needs a huge HDMI framebuffer?)
<oliv3r>
ah also true
<oliv3r>
yeh i
<oliv3r>
i'll just hook up a hdmi monitor
reinforce has quit [Quit: Leaving.]
<tkaiser>
oliv3r: BTW: you don't need a keyboard or mouse, HDMI monitor is enough. Simply connect it, let the desktop start and then fire up lima-memtester remotely through SSH. memtester will takeover the framebuffer
<oliv3r>
yeah i know
<tkaiser>
Good
<oliv3r>
i ran lime-memtester + burn ARM (x2) 2 years ago during our hot summer
<oliv3r>
i got it to crash quite easily
<oliv3r>
the boards ran 120 degree's celcius according to our heat cam
<tkaiser>
oliv3r: Have seen this alreay. To be honest I don't trust thermal sensor in A10/A20 at all since it's there by accident than by design ;)
<oliv3r>
tkaiser: yeah, but 2 years ago, we had to find out if it was accurate or not :)
OverCR has joined #linux-sunxi
<oliv3r>
but with those tests, i managed tog et it to overheat quite easily :)
<tkaiser>
oliv3r: But I would assume location of the sensor also matters. As with RPi 3: there the thermal sensors sits obviously far far away from the ARM cores
<oliv3r>
yeah
<tkaiser>
Anyway: Looking forward to your findings :)
<oliv3r>
:)
<oliv3r>
well right now, still bisectig :(
<oliv3r>
commit beba401 sunxi: power: Add support for disabling axp209 regulators breaks my reboot!
<oliv3r>
maybe bad devicetree blob on my kernel!
<oliv3r>
tada, problem found, old bob, don't define the LDO3 and LDO4 options
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
jstein_ has joined #linux-sunxi
<tkaiser>
oliv3r: Good to hear. Then you can test with 2016.07 packages, right? BTW: since build host was up and running I also added 504/528 MHz later to the archive (the 532 MHz Tsvetan was talking about are not possible anyway). No idea whether these clockspeeds can work
jstein_ is now known as jstein
jernej has quit [Ping timeout: 258 seconds]
reinforce has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
tkaiser has quit [Ping timeout: 252 seconds]
tkaiser has joined #linux-sunxi
<KotCzarny>
hmm
<KotCzarny>
what could be the reason of busy audio device on h3/3.4.x?
<KotCzarny>
mplayer says:
<KotCzarny>
[AO_ALSA] Unable to get initial parameters: Inappropriate ioctl for device
<KotCzarny>
[AO_ALSA] alsa-lib: pcm_hw.c:1557:(snd_pcm_hw_open) open '/dev/snd/pcmC0D0p' failed (-16): Device or resource busy
IgorPec has joined #linux-sunxi
<KotCzarny>
igorpec, do you know which possible 'gotchas' prevent analog audio on h3 working?
<IgorPec>
on which H3 board?
<KotCzarny>
opipc
<IgorPec>
it should work
<KotCzarny>
i get device busy, even though lineout is enabled in alsamixer
<KotCzarny>
so im wondering what else could be the culrpit
<IgorPec>
actually i was playing with audio yesterday and working fine, hdmi and analogue
<KotCzarny>
*culprit
<KotCzarny>
aplay: set_params:1204: Broken configuration for this PCM: no configurations available
<KotCzarny>
hrm
<IgorPec>
strange. what conf do you use?
<IgorPec>
i mean do you use some recent build or did you play around settings?
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
apritzel has quit [Ping timeout: 244 seconds]
yann has quit [Ping timeout: 258 seconds]
<KotCzarny>
how i love those sneaky configuration options
<KotCzarny>
all is well again and sounds nice
somedude23 has joined #linux-sunxi
apritzel has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
jstein__ has joined #linux-sunxi
jstein is now known as Guest13854
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
jstein__ is now known as jstein
lemonzest has joined #linux-sunxi
Guest13854 has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 244 seconds]
scream has joined #linux-sunxi
nikre has joined #linux-sunxi
<nikre>
hi, i am testing 4.6 kernel on orangepi pc. it is said that there is no temperature feedback for 4.x kernel on h3 SoC yet. Should i still be worried if i have a heatsink and a fan blowing on it?
pg12_ has quit [Ping timeout: 264 seconds]
Nacho_____ has quit [Ping timeout: 252 seconds]
pg12 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 240 seconds]
mosajjal has joined #linux-sunxi
MiLeon has joined #linux-sunxi
nikre has quit [Quit: Leaving]
OverCR has quit [Quit: Leaving.]
pulser_ is now known as pulser
Putti has quit [Ping timeout: 260 seconds]
tsuggs has joined #linux-sunxi
<topi`>
how do I toggle the output of a certain GPIO pin with sunxi-pio ?
<topi`>
I tried that, but still reports it as 0,0,0,0
<topi`>
I guess it is forced to 0 somehow
<KotCzarny>
i mean, set second digit to 1
<KotCzarny>
though if it doesnt change any field then something is wrong
<KotCzarny>
if mode == 0, it means pin is configured as input
<topi`>
ok
<topi`>
yeah, and with output the pull can stay at 0
<topi`>
the <drive> param I do not understand.
<topi`>
i
<topi`>
I could turn on and off the red LED with sunxi-pio
<topi`>
so I guess that particular GPIO (PL2) isn't just adjustable
<topi`>
it does show up in the schematics
<KotCzarny>
i think you have to define gpios in fex/dts
<topi`>
it seems PL2 pin is shared with S_UART_TX
<topi`>
I wonder if that can conflict?
tkaiser has joined #linux-sunxi
<KotCzarny>
most likely
<KotCzarny>
offtopic, added microamp to my opipc, it works wickedly nice. 38C during media play via nfs at 648mhz
lemonzest has quit [Quit: Leaving]
tkaiser has quit [Ping timeout: 252 seconds]
foxx_ has joined #linux-sunxi
<willmore>
Curd, I found my SMD adapter boards and I don't have anything for these Winbond SPI Flash chips. Curd. Time to do some point to point wiring.
<KotCzarny>
or order new ones and call it a day
Putti has joined #linux-sunxi
<KotCzarny>
kittens wouldnt watch themselves, you know
<willmore>
Uhh, no, wrong SSOIC. Shrink Small Outline Integrated Circuit. IIRC.
<willmore>
Oh, yeah, buying adapters would make more sense. Last time I searched, eBay was not cooperative. Plenty of results--none for what I was looking for. My google-fu was too weak.
longsleep has joined #linux-sunxi
<KotCzarny>
would help you if i had a tiny clue about the topic
curtis22 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
<willmore>
KotCzarny, I have SPI chips in a 16 pin wide SOIC package and need to get at the normal SPI pins of them. I was looking for a little PCB that would break out the pins to larger pads that I could solder to--and then attach it to my Opi1
<willmore>
Yeah, the 1207 product looks right. Now, just to find it anywhere but Adafruit or Sparkfun.
<KotCzarny>
its plenty, google: soic-16 breakout board
<willmore>
KotCzarny, yeah, I was looking for 'adapter'. "break out board" is the magic term I wasn't using. Plenty of them now. Thanks! Your google-fu is mighty.
<KotCzarny>
and i dont even dabble in electronics, go figure ;)
tsuggs has quit [Ping timeout: 264 seconds]
<willmore>
I couldn't see the forest because of all of the trees. :)