<wens>
montjoie: your branch included a merge of some scsi fixes?
apritzel has quit [Ping timeout: 244 seconds]
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 264 seconds]
lemonzest has quit [Quit: Leaving]
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 244 seconds]
kaspter has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
kaspter has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
Net147 has quit [Ping timeout: 276 seconds]
Net147 has joined #linux-sunxi
reev has joined #linux-sunxi
vagrantc has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 276 seconds]
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<KotCzarny>
willmore: yeah, that thing (probably). and because led logic isnt always reliable, to be sure test is (still) working is to see cube on gray background
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 272 seconds]
Mr__Anderson has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
JohnDoe_71Rus has joined #linux-sunxi
tkaiser has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
jernej has quit [Quit: Konversation terminated!]
reinforce has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
<tkaiser>
wens: A second user reported that 624 MHz fail. I opened a github issue, asked the other users to not report back per personal message but in the thread in Armbian forum. And won't waste any more time with BPi M2+ from now on. https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/3
kaspter has joined #linux-sunxi
<KotCzarny>
that's pretty bad, how is it possible? different memory modules used or some board design f*ckups?
<KotCzarny>
maybe noise?
<tkaiser>
KotCzarny: Clueless people using wrong hardware setup since they just did copy&paste from loboris (Orange Pi PC)?
<montjoie>
wens: perhaps
fl_0 has joined #linux-sunxi
<KotCzarny>
tkaiser: so its only software?
<tkaiser>
KotCzarny: These are hardware settings. DRAM timing and such stuff. And they obviously just did copy&paste from the fex file loboris used for Orange Pis and used it for their own board.
luoyi has joined #linux-sunxi
<tkaiser>
wens: User gaara reported that 624MHz fail after approx 15 minutes. And he copied these messages: http://pastebin.com/SzFtZDsG
<wens>
ssvb should understand this better than me
<tkaiser>
wens: True, but the real information is 'after 15 min, the system freeze'
<tkaiser>
Based on just these two samples it sounds like CONFIG_DRAM_CLK=576 now ;) I hope we get a few more results within the next hours.
<KotCzarny>
in short 20% lower memory bandwidth
<KotCzarny>
than ooranges
<wens>
tkaiser: 48 Mhz step?
<KotCzarny>
wens, ssvb recommends stable-24
<wens>
oh i see
<tkaiser>
wens: Nope, but some safety headroom as suggested by ssvb when he described the lima-memtester approach. That's why we use CONFIG_DRAM_CLK=624 for all Orange Pi (at least in Armbian, upstream u-boot uses higher values for Opi Plus IIRC)
vagrantc has quit [Quit: leaving]
IgorPec has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Mr__Anderson has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<montjoie>
now time to prepare cover letter for emac
<wens>
montjoie: i suggest splitting emac device node and emac rgmii pin into 2 patches
<montjoie>
why ?
<wens>
"ARM: dts: sun8i-h3: add sun8i-emac ethernet driver" should add xxx device node, not driver
<wens>
montjoie: do 1 thing per patch
apritzel has joined #linux-sunxi
<wens>
for the enable emac on X board patches, describe whether they use an internal phy or external phy (and what model) in the commit message
<montjoie>
ok
<wens>
simply put, the commit message should contain as much context as possible, so people that weren't part of the development process can still understand what you want to do
<montjoie>
for the board, only opipc could be sent, since opiplus use the regulator
apritzel has quit [Ping timeout: 244 seconds]
<wens>
then you could hold off on sending the rgmii pins, as your series wouldn't use it yet
<montjoie>
ok
ganbold has quit [Ping timeout: 260 seconds]
<ssvb>
wens: "passing" the lima-memtester check after merely running it for a few hours is not enough (it could still potentially fail after e few more hours), so at least one step down is necessary for extra safety headroom
<ssvb>
wens: so tkaiser is right about using no more than 576 MHz for DRAM, based on the current findings
<ssvb>
wens; this estimate could still go further down if we get more test results
Net147 has quit [Ping timeout: 244 seconds]
kaspter has quit [Ping timeout: 244 seconds]
kaspter has joined #linux-sunxi
diego_r has joined #linux-sunxi
Net147 has joined #linux-sunxi
<tkaiser>
ssvb: wens: The second test result was not done using FEL boot so we don't know the DRAM clockspeed used. I asked the user to repeat the test and added the section to the Wiki (but it's quite complicated with BPi M2+ since underpowering could also be an issue here since M2+ starts when power is provided on the OTG port): http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B#DRAM_clock_speed_limit
Wizzup has quit [Ping timeout: 260 seconds]
Mr__Anderson has quit [Ping timeout: 272 seconds]
Mr__Anderson has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
<tkaiser>
ssvb: He just executed './lima-memtester 100M' in a running system since my instructions were unclear. So based on the error messages only the memtester part was running without stressing Mali and DRAM clockspeed was 672MHz. But then the results are worthless right (except of freezing after 15 minutes seems not to be ok anyway)?
<ssvb>
tkaiser: did he see the spinning cube?
<ssvb>
tkaiser: if yes (the kernel has a suitable mali driver), then the test result is valid
<tkaiser>
Already asking :) And I checked the settings he uses, both u-boot and fex were set to 672 MHz so in case he reports a spinning cube his board failed after 15 minutes at 672MHz which would be way better than my board.
<ssvb>
and the power supply quality is always a possible concern
<ssvb>
we had a guy who tried to use the USB port of a laptop to power the Orange Pi PC board and it was failing the lima-memtester check with any DRAM clock speed due to having not enough power :-)
<ssvb>
tkaiser: does the armbian 3.4 kernel allow runtime DRAM re-clocking?
<tkaiser>
ssvb: Yes, but u-boot and fex value were identical. And yes, powering is also a concern. I used Xunlong's 3A PSU connected to barrel connector
<ssvb>
I mean the CONFIG_DEVFREQ_DRAM_FREQ option
<tkaiser>
ssvb: Yes, it's true and after cpufreq changes DRAM freq will also be adjusted
<KotCzarny>
ssvb, how valid are the results without the cube if one doesnt plan to use mali at all?
<ssvb>
tkaiser: well, it's probably always safer to disable this option, because changing the DRAM clock speed at runtime is a potential reliability hazard (depending on the quality of the code doing the job)
<tkaiser>
BTW: Since I use Pine64 as host to FEL boot BPi M2+ I also tested disconnecting PSU. Lima-memtester continued to run for an hour powered by the Pine64's USB host port (according to TL Lim maxing out at 650mA what would match my power meter readings)
<tkaiser>
ssvb: Agreed. And that's the reason I recommend doing the test again through FEL boot with your kernel where it's diabled
<ssvb>
tkaiser: btw, the mysterious 70C deadlocks observed by KotCzarny might be also possibly related to DRAM reclocking
<KotCzarny>
ssvb, i will retest the board today with good psu
<ssvb>
KotCzarny: you could also try disabling CONFIG_DEVFREQ_DRAM_FREQ kernel option as a test
<KotCzarny>
ssvb, did you see my maliless testing question?
<tkaiser>
ssvb: We tried to use both 624 MHz in u-boot and fex files for all Orange Pis (even those where upstream u-boot uses 672 MHz since tests never happened).
<ssvb>
KotCzarny: regarding the validity of test results without the mali part, our intention is to put the hardware into stressful conditions (both GPU and CPU competing for the access to DRAM)
<KotCzarny>
ssvb, but if one wants to use only cpu/network/storage, then it might be meaningful to know that it can be clocked higher
<ssvb>
KotCzarny: even if you don't plan to use mali, you still could have the DMA block of some hardware unit competing with the CPU sometimes
<KotCzarny>
ssvb, thats why i asked if your initrd detects such situation, or if you have an idea for such tool
ganbold has joined #linux-sunxi
<ssvb>
this scenario is much more difficult to simulate, that's why we rely on mali
<tkaiser>
KotCzarny: Do you have any use cases where memory bandwidth makes a real difference? 'Real' as in 'performance differs by more than 5 percent'?
<ssvb>
the G2D unit doing 90 degrees rotation can be used instead of Mali too, I had confirmed that it has a similar effect
pulser_ is now known as pulser
<ssvb>
Mali is better than G2D because it is used in more SoC types
<KotCzarny>
tkaiser, memory bandwidth(speed) means lower latency
<KotCzarny>
ssvb, h3 doesnt have g2d?
<tkaiser>
KotCzarny: Not 'meanings', I mean real world examples and tests.
<KotCzarny>
tkaiser, do any benchmark with 576 then redo with 672
<ssvb>
KotCzarny: if you can do the loopback network based test, which matches the lima-memtester sensitivity to DRAM misconfiguration, then be my guest :-)
<KotCzarny>
if it doesnt scale almost linearly its not an issue then
<tkaiser>
KotCzarny: _I_ did this several times and I now know why I don't care :P I was asking you!
<tkaiser>
Laughable if you translate synthetic benchmark results to real world performance (for example NAS useage)
<tkaiser>
KotCzarny: And Moronix test suite running with 672MHz and 600MHz on Orange Pi PC: Exactly no difference (but that's already known that this 'fire and forget' sort of benchmarking always produces meaningless numbers only)
matthias_bgg has joined #linux-sunxi
<KotCzarny>
but any compute app could show the difference
<tkaiser>
KotCzarny: Weigh the 'costs' of bit flips that might corrupt data or crash processes or the whole system with laughable performance gains. Everything less than 5 percent isn't worth a thought
matthias_bgg has joined #linux-sunxi
<KotCzarny>
yup
<KotCzarny>
not arguing with that
zerotri has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
nihcas has quit [Remote host closed the connection]
<tkaiser>
Especially on boards that might be powered insufficient (Micro USB). At Armbian almost all stability issues we get reported are due to: insufficient power and crappy SD cards (and maybe DRAM clockspeed too high on Cubieboard 2 -- I still don't get why we did not decrease this already)
<KotCzarny>
might be meaningful to write an installer that will bench and tune such params detecting crappy psu/board
<KotCzarny>
in fact it might be after-install tool too
<KotCzarny>
ssvb, does running limamemster from inside running os is meaningful?
<ssvb>
KotCzarny: yes, of course, that's how it has been used from the very start
<KotCzarny>
good, easier than felbooting with switching sdcards then
<ssvb>
KotCzarny: the FEL based part is just an easy way to try different DRAM clock frequencies
<KotCzarny>
ssvb, someone said that those clock freqs COULD be changed runtime with i2c
tkaiser has quit [Ping timeout: 244 seconds]
<ssvb>
if you disable CONFIG_DEVFREQ_DRAM_FREQ, then the kernel should (?) have no code for DRAM reclocking compiled in
<ssvb>
this will ensure that the DRAM settings from the bootloader are preserved
<ssvb>
there was no interest from the distribution maintainers though, so it remained as a nice technical demo
<KotCzarny>
lets just focus on armbian
<KotCzarny>
no need for other distros (especially that they are clueless usually)
<ssvb>
fedora, debian and the others? ;-)
<KotCzarny>
armbian is almost a debian
<KotCzarny>
but important bit being they are focused on sunxi devices (and few others)
<wens>
is lima-memtester run with mainline u-boot?
<KotCzarny>
and they are unencumbered by long and slow acquiring process
luoyi has quit [Ping timeout: 250 seconds]
<ssvb>
wens: yes
<ssvb>
wens: I did test boot0 in the past, but it was a one time occurrence
<KotCzarny>
hmm
<wens>
so there's a slim chance the bpi-m3 boot0 is better
<ssvb>
yes, of course
pzabielo has joined #linux-sunxi
<montjoie>
wens: I have update my emac branch with your comments
<montjoie>
could you give me your comments about "commit messages"
<wens>
all except the last 3 look good
<wens>
for the regulators you could explain why you need 1 or 2 regulators
<wens>
for opi+ explain it is emac + rtl8211e w/ rgmii mode
tkaiser has joined #linux-sunxi
<wens>
my bpi-m3 is getting warm
<montjoie>
wens: I didnt work on last 3 since I will not send them:)
<wens>
no problem
<montjoie>
but I will integrate your comment:)
<montjoie>
wens: I will send the first 4
Mr__Anderson has joined #linux-sunxi
datagutt_ has joined #linux-sunxi
datagutt_ has joined #linux-sunxi
datagutt_ has quit [Changing host]
alexxy[home] has joined #linux-sunxi
tgaz_ has joined #linux-sunxi
<tkaiser>
ssvb: Glowing red background. First time I see this :) https://www.youtube.com/watch?v=I0M_xx7s1ls (this is user gaara executing lima-memtester from within Armbian with 672 MHz feezing now after 21 mins)
souther_ has joined #linux-sunxi
<tkaiser>
wens: BPi-M3 getting warm is not normal. It should get rather _hot_ ;)
FergusL has quit [Ping timeout: 264 seconds]
tgaz has quit [Ping timeout: 264 seconds]
reinforce has quit [Ping timeout: 264 seconds]
datagutt has quit [Ping timeout: 264 seconds]
TheLinuxBug has quit [Ping timeout: 264 seconds]
peepsalot has quit [Ping timeout: 264 seconds]
alexxy has quit [Ping timeout: 264 seconds]
souther has quit [Ping timeout: 264 seconds]
huehner has quit [Ping timeout: 264 seconds]
tgaz_ is now known as tgaz
datagutt_ is now known as datagutt
souther_ is now known as souther
clonak has quit [Remote host closed the connection]
<wens>
tkaiser: it's running mainline w/ 1 core and idle
huehner has joined #linux-sunxi
TheLinuxBug has joined #linux-sunxi
peepsalot has joined #linux-sunxi
<tkaiser>
wens: At which cpufreq and VDD_CPUX voltage?
reinforce has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
<wens>
whatever mainline u-boot setup
<wens>
which i think is 1008 MHz @ 1.2V?
<tkaiser>
wens: 1.2V would be pretty high for A83T
kaspter has joined #linux-sunxi
<tkaiser>
wens: 840mV would be ok for 1008 MHz. 1080mV would be ok for 1800 MHz. 1200 mV is rather insane overvolting
<tkaiser>
According to BPi M3 fex file and real world tests
<wens>
looks like 0.9V
<wens>
there's no pmic driver in linux, so i'm just looking at the default u-boot settings
<tkaiser>
wens: ssvb: I will use an OS image based on boot0 later on BPi M2+ and test again 624MHz and if that succeeds will also try out higher clockspeeds. Just to get the idea whether mainline u-boot DRAM code and boot0 might make a huge difference
<maz>
wens: sorry I got sidetracked on the reviewing front. I'll get on it today.
ricardocrudo has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
nihcas has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
iamfrankenstein has quit [Ping timeout: 244 seconds]
WhiteKIBA has quit [Ping timeout: 246 seconds]
WhiteKIBA has joined #linux-sunxi
nihcas has quit [Remote host closed the connection]
zerotri has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
nixdork has quit [Remote host closed the connection]
NiteHawk has quit [Remote host closed the connection]
NiteHawk has joined #linux-sunxi
NiteHawk has quit [Changing host]
NiteHawk has joined #linux-sunxi
<tkaiser>
ssvb: 'Error: ioctl MALI_IOC_MEM_INIT failed: Inappropriate ioctl for device' using their kernel (which is loboris' kernel back from last year: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp ). Stop wasting time now and putting this board into the drawer.
Uninstall has quit [Remote host closed the connection]
<wens>
my opi pc does not like long ethernet cables :(
<plaes>
how long is long?
<wens>
5 ~ 10 meters, through a wall socket, to the central switch
<wens>
with a 1 foot cable to the switch on my desk it works nicely
Uninstall has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<ssvb>
tkaiser: you still can just try to replace their kernel on the SD card with the kernel from the lima-memtester fel package
<ssvb>
tkaiser: just find their uImage file and overwrite it
iamfrankenstein has joined #linux-sunxi
<tkaiser>
ssvb: Ok, they managed to make use of u-boot script recently so exchanging the kernel should work.
<tkaiser>
ssvb: And with 'Team BPi' default THS settings your new cpuburn-a7 managed to kill 2 CPU cores successfully and now the system runs with 2 cores and refuses to clock higher than 480 MHz. Great stuff
<MoeIcenowy>
tkaiser: your soc is broken?
medvid has joined #linux-sunxi
<tkaiser>
MoeIcenomy: Don't think so, I'm just trying out OS images from hell ;)
<tkaiser>
ssvb: Replaced kernel and now memtester is running. Watching the spinning cube now
<MoeIcenowy>
tkaiser: I means have you broken your soc
<tkaiser>
ssvb: still gray background after a minute. And the fex file used sets 672 MHz
<MoeIcenowy>
and how to replace script.bin for new Allwiner SoC sdk image?
<tkaiser>
MoeIcenowy: I did understand but most probably not. Will retry it later again with Armbian. But there we tuned these THS settings (and have a kernel patch that brings back killed CPU cores)
<KotCzarny>
ssvb: limamemtester feature request: print active cpu count and freqs (and maybe temps)
<MoeIcenowy>
I cannot replace it on my A33 tablets :-(
<MoeIcenowy>
(But now I use mainline :-)
<KotCzarny>
or just 5 last lines from dmesg, should be informative enough too
<tkaiser>
Will increase THS trip points later to ensure at least operation at 1008 MHz
Andy-D has joined #linux-sunxi
<plaes>
wens: does that same cable work with your PC
<KotCzarny>
plaes, wens: could it be some timing issue?
apritzel has joined #linux-sunxi
Michal has joined #linux-sunxi
ganbold has joined #linux-sunxi
formruga has joined #linux-sunxi
phipli has joined #linux-sunxi
gaby has joined #linux-sunxi
<tkaiser>
ssvb: I increased first trip point to 85*C and restarted the test. With 1200 MHz cpufreq and 672 MHz DRAM clock stable since 3 minutes. :(
<ssvb>
tkaiser: well, it just means that boot0 is probably doing a better job configuring DRAM, maybe it even has different DRAM settings hardcoded in it (not the same as in fex)
<tkaiser>
Powermeter shows 4.7W. When I did the tests yesterday (without fan) then it showed 3.2/3.3W. Will let this run now for at least an hour if it survives and will then re-test with active fan with mainline u-boot
<ssvb>
tkaiser: try to run it longer, and if you get consistently better results with boot0, then we can investigate this
<tkaiser>
ssvb: Sure, will do. Now off to the kitchen doing Pasta :)
kaspter has quit [Ping timeout: 244 seconds]
<tkaiser>
ssvb: IIRC you configured Mali to 252 MHz in your kernel?
<ssvb>
tkaiser: yes, I did not see it necessary to clock higher
<ssvb>
otherwise we would be probably facing another philosophical question about whether 600MHz is really safe for mali or not :-)
<tkaiser>
ssvb: Ok, should be sufficient for lima-memtester? Since we increased the value to 600MHz when we relied on this older BSP kernel in Armbian a while ago and one user reported he got way better fps in an ego shooter (didn't know that such things exist for SBC)
gaby has quit [Quit: leaving]
gaby has joined #linux-sunxi
gaby has left #linux-sunxi [#linux-sunxi]
<ssvb>
I tried different mali clock speeds and did not see any correlation with the test result
<ssvb>
yes, somebody playing 3D games in a real system would be interested in better performance
<tkaiser>
ssvb: Then we changed that to 600 MHz just to drop the kernel with the new BSP variant released by FriendlyARM one week later where this is handled differently
<ssvb>
the GPU clock speed should be probably handled as part of budget cooling
<tkaiser>
(AFAIK now it can be configured in script.bin but I'm an absolute noob in this area)
<tkaiser>
ssvb: Yes, it will. Kernel drops messages regarding GPU clockspeed adjustments also on console
<ssvb>
well, it is a part of the budget cooling design, but the Allwinner's implementation is dodgy
<ssvb>
and somebody needs to hook it up with the mali kernel driver (if we still use r3p0)
Wizzup has quit [Ping timeout: 276 seconds]
<apritzel>
montjoie: thanks for the post! will comment on it later
Wizzup has joined #linux-sunxi
paulk-nyan-big has joined #linux-sunxi
paulk-nyan-big has quit [Quit: Leaving]
Mr__Anderson has quit [Quit: Leaving.]
Mr__Anderson has joined #linux-sunxi
<montjoie>
apritzel: :) I fear the comment from dmiller...
<apritzel>
montjoie: be brave and just fix what he suggests ;-)
<wens>
it seems my bpi-m2+ crashed
<tkaiser>
ssvb: Now testing with 696MHz and boot0
<tkaiser>
wens: Running a specific workload?
<GeneralStupid>
5
libv_ is now known as libv
<wens>
tkaiser: if you call gpsd a workload
<wens>
hooked it up to a gps module to try gps time for ntp
ninolein_ has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
<tkaiser>
wens: So nothing special. I just ask because with mainline and without working THS/throttling H3 on BPi M2+ is in danger when all CPU cores are active and cpufeq is allowed to exceed 816 MHz or something like that :)
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
ganbold has quit [Ping timeout: 244 seconds]
reev has quit [Ping timeout: 276 seconds]
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 272 seconds]
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
pzabielo has quit [Quit: Ex-Chat]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<MoeIcenowy>
allwinner is getting much easier and easier to overheat...
iamfrankenstein has quit [Quit: iamfrankenstein]
<MoeIcenowy>
my A33 tablet can still run stably on 1.2GHz Quad-Core...
<tkaiser>
On the left OPi Plus 2E w/o heatsink, in the middle BPi M2+ with heatsink, on the right OPi Lite w/o heatsink. The thermal loser is the board with applied heatsink in the middle
<TheLinuxBug>
ssvb: I noticed your lacking the BPi M1
<KotCzarny>
'you're'
<TheLinuxBug>
(facepalm)
<TheLinuxBug>
thanks gramar nazi
<TheLinuxBug>
:Z
<TheLinuxBug>
you're
<KotCzarny>
too much internets?
<TheLinuxBug>
just busy
reinforce has quit [Quit: Leaving.]
<plaes>
hrm.. spam attach
<TheLinuxBug>
actually in the middle of packing
solarnetone has quit [Read error: No route to host]
<TheLinuxBug>
moving tomorrow
<TheLinuxBug>
so in the process of working and packing up my office
<plaes>
rellla: when you delete the spam page, please empty the content line
<plaes>
err.. reason line :)
IgorPec has joined #linux-sunxi
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 272 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 244 seconds]
cnxsoft1 is now known as cnxsoft
cnxsoft has quit [Client Quit]
bmeneg has quit [Remote host closed the connection]
<ssvb>
TheLinuxBug: I already have too many boards, there is no room for additional "refugees"
IgorPec has quit [Ping timeout: 260 seconds]
<TheLinuxBug>
;p
<TheLinuxBug>
I have quite a few too, but probably not all the cools ones you have ;p
<TheLinuxBug>
I have... 2x A10 cubiboard, 1x BPi M1, 1x RPi2, 1xRPi3, 1xRPi B+, 1xOdroid C2 and 1x Orange Pi Plus 2E on the way :z
<TheLinuxBug>
and a few misc old marvel boards
cosm has joined #linux-sunxi
zuikis has joined #linux-sunxi
<KotCzarny>
:)
<KotCzarny>
sell those a10 boards and rpis
enrico_ has joined #linux-sunxi
<willmore>
Survey completed.
<tkaiser>
ssvb: How can I reliably check DRAM clockspeed? I created an image for BPi M2+ to test with (u-boot 2016.05) and want to verify that I really use different DRAM settings in u-boot. ./lima-memspeed with which options?
<tkaiser>
ssvb: Also '# CONFIG_DEVFREQ_DRAM_FREQ is not set'
<ssvb>
tkaiser: sunxi-tools has the 'meminfo' tool, but it does not support H3 yet
<tkaiser>
ssvb: Ok, then I try my luck using 7-zip
<ssvb>
you still can check some hardware registers via devmem2
<ssvb>
also the boot0 header should contain the dram parameters information
<ssvb>
regarding "CONFIG_DEVFREQ_DRAM_FREQ is not set", do you mean the armbian default kernel config? or something else?
<tkaiser>
ssvb: Currently using u-boot 2016.05. And I compiled an own kernel where I disabled it (default in Armbian it's activated)
afaerber has joined #linux-sunxi
afaerber has quit [Client Quit]
<tkaiser>
ssvb: Normally current DRAM clockspeed is available as /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq (but not if "CONFIG_DEVFREQ_DRAM_FREQ is not set")
<tkaiser>
ssvb: Now when testing 744 MHz glowing red after 8 minutes. Now testing with 600 MHz just to be sure. Is it possible that something significant changed between 2016.01-rc3 (?) and 2016.05 regarding DRAM on H3 boards?
<ssvb>
tkaiser: you can check git commit logs
<ssvb>
if something really changed, then we will need to update the U-Boot image when testing DRAM reliability
<ssvb>
there is another possible explanation: some DRAM parameters are calibrated at boot time and may differ across reboots
solarnetone has joined #linux-sunxi
<ssvb>
so it may randomly flip between 'crap' and 'ok' states, mostly depending on the SoC temperature at boot time
<tkaiser>
I'm currently testing with an active fan (now powered by the OPi Plus 2E lying next to the Banana so consumption values are more realistic) and will now test from top to bottom now that I could confirm that DRAM clockspeed in u-boot is ok.
<ssvb>
somebody could also package lima-memtester for armbian
<tkaiser>
ssvb: Sure, but right now it's more important to understand what's going on. Will test tomorrow with Orange Pi PC since then I can use your original archive without the chance to introduce errors by me. And then exchange u-boot/script.bin on the test image I made half an hour ago and double check. And I really hope we get a clue how to deal with 'crap' and 'ok' states since this makes the whole testing approach somewhat
<tkaiser>
moronic
massi has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 260 seconds]
<tkaiser>
ssvb: Last bit for today. With the aforementioned Armbian image I was able to run lima-memtester over 30 minutes at 720MHz. Shutdown, every power source disconnected and then tried again using the FEL memtester: http://pastebin.com/TM9mB29S
<tkaiser>
So at least there's something important _different_
<tkaiser>
Boot log from the Armbian image with IIRC also 720 MHz configured (or maybe 744): http://pastebin.com/tDwtLgYP
iamfrankenstein has quit [Quit: iamfrankenstein]
IgorPec has joined #linux-sunxi
massi has quit [Remote host closed the connection]
<zoobab>
any news on the H3 ethernet driver?
<zoobab>
last time I tried it was unusable
<zoobab>
BTW @IgorPec @tkaiser armbian with mainline kernel on my bpi is unstable, keeps rebooting
<IgorPec>
who tells you that is stable?
<zoobab>
:-)
<IgorPec>
you are talking about banana pi+ / H3, right?
<KotCzarny>
tkaiser: do you know how to add 1280x1024 mode for hdmi output? (opi+2e)
Amit_t_ has quit [Quit: Page closed]
matthias_bgg has joined #linux-sunxi
fredy has quit [Excess Flood]
iamfrankenstein1 has joined #linux-sunxi
fredy has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 264 seconds]
iamfrankenstein1 is now known as iamfrankenstein
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 264 seconds]
iamfrankenstein1 is now known as iamfrankenstein
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 264 seconds]
<plaes>
libv: it seems like spammers are getting through :(
iamfrankenstein1 has joined #linux-sunxi
solarnetone has quit [Ping timeout: 260 seconds]
iamfrankenstein has quit [Ping timeout: 264 seconds]
iamfrankenstein1 is now known as iamfrankenstein
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 264 seconds]
iamfrankenstein1 is now known as iamfrankenstein
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 264 seconds]
iamfrankenstein1 has quit [Ping timeout: 264 seconds]
iamfrankenstein has joined #linux-sunxi
vagrantc has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 264 seconds]
iamfrankenstein has joined #linux-sunxi
formruga has quit [Ping timeout: 244 seconds]
iamfrankenstein has quit [Ping timeout: 264 seconds]
formruga has joined #linux-sunxi
mosterta has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
<vagrantc>
well, 4.7.0-rc1 + a64-v5 patches work pretty well, although ethernet seems to stall out a lot
<vagrantc>
cherry-picking the usb patches from a64-wip still seem to cause a crash ... but yay... pine64 lives and seems well on it's way to mainline! :)
fredy has quit [Excess Flood]
solarnetone has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
fredy has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
jstein_ has joined #linux-sunxi
jstein has quit [Ping timeout: 276 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
Netlynx has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
tkaiser has joined #linux-sunxi
nove has quit [Quit: nove]
tkaiser has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
premoboss has joined #linux-sunxi
fdcx has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
vickycq has quit [Ping timeout: 276 seconds]
vickycq has joined #linux-sunxi
phipli has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-6627-gf708225, sources date: 20160102, built on: 2016-05-12 17:32:15 UTC git-6627-gf708225 http://www.kvirc.net/]
Zliba has joined #linux-sunxi
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 272 seconds]
premoboss has quit [Read error: Connection reset by peer]