Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
Nacho_ has joined #linux-sunxi
yann has quit [Ping timeout: 250 seconds]
kaspter has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
nemunaire has quit [Ping timeout: 264 seconds]
nemunaire has joined #linux-sunxi
aballier has quit [Ping timeout: 240 seconds]
aballier has joined #linux-sunxi
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 265 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
pg12 has quit [Ping timeout: 264 seconds]
pg12 has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
mcan has quit [Quit: by]
pg12 has quit [Ping timeout: 265 seconds]
pg12_ has joined #linux-sunxi
<wens_> found out the hard way that reflog expire can delete your git stashes :(
wens_ is now known as wens
gzamboni has quit [Read error: Connection reset by peer]
_mamalala_ has joined #linux-sunxi
_mamalala has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft1 is now known as cnxsoft
<slapin> hi, all!
petr has quit [Ping timeout: 264 seconds]
petr has joined #linux-sunxi
<slapin> can anybody confirm, A64 preformance is basically the same as H3, but A64 can be considered cooler (almost always at 40C)?
kaspter has joined #linux-sunxi
<slapin> wens: stashing useful stuff all around is bad practice, it was never considered a permanent storage
<slapin> wens: but anyway it would be better if a bug was reported as I could not find anything similar
* slapin also likes to stash stuff around
Gerwin_J has joined #linux-sunxi
foxx_ has joined #linux-sunxi
fire219 has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
foxx_ is now known as f0xx
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
OverCR has joined #linux-sunxi
leio has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
jernej has quit [Ping timeout: 264 seconds]
IgorPec has joined #linux-sunxi
reinforce has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
OverCR has quit [Quit: Leaving.]
Gerwin_J_ has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 244 seconds]
Gerwin_J_ is now known as Gerwin_J
Mr__Anderson has joined #linux-sunxi
florianH has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
formruga has joined #linux-sunxi
formruga has quit [Client Quit]
formruga has joined #linux-sunxi
OverCR has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
yann has joined #linux-sunxi
OverCR has quit [Ping timeout: 244 seconds]
yann has quit [Ping timeout: 250 seconds]
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
popolon has joined #linux-sunxi
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
f0xx has quit [Client Quit]
f0xx has joined #linux-sunxi
apritzel has joined #linux-sunxi
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
yann has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
fl_0 has quit [Ping timeout: 244 seconds]
fl_0 has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
mzki has joined #linux-sunxi
lemonzest has joined #linux-sunxi
apritzel has joined #linux-sunxi
<diego71_> slapin: it should be faster at the same clock -> https://developer.arm.com/products/processors/cortex-a/cortex-a53
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
f0xx has quit [Quit: terminated!]
f0xx has joined #linux-sunxi
f0xx has quit [Client Quit]
netlynx has joined #linux-sunxi
enrico_ has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
Da_Coynul has joined #linux-sunxi
Amit_T has quit [Ping timeout: 240 seconds]
<ssvb> slapin: A53 is more power hungry than A7 and also a bit faster per MHz
Amit_T has joined #linux-sunxi
pietrushnic has quit [Ping timeout: 264 seconds]
<wens> mripard: having looked through the generic pinconf stuff, it puzzles me why we always have pullup = no and drive = 10mA in all the pinmux nodes
<wens> aren't these optional?
<jmcneill> we (freebsd) tripped on that recently
<jmcneill> pullup = no seems to mean "no change" in your driver
<jmcneill> we were explicitly setting pullup to no which basically broke mmc everywhere unless we patched the dts
<wens> yeah, that one i really think is a bug
<wens> but mripard said it was intentional
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<mripard> wens: hmmm
<mripard> I thought they were required
<mripard> but apparently they aren't
<Net147> mripard: got mali fbdev working
<mripard> jmcneill: it's a bug on our side then
<jmcneill> we're emulating your behavior for now but it would be nice if it was fixed :)
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Net147> mripard: the framebuffer yres_virtual needs to be twice yres for it to work
IgorPec has quit [Ping timeout: 250 seconds]
<wens> Net147: double buffering?
<wens> jmcneill: how much of the dts files are shared between linux and freebsd?
<Net147> wens: yes
<arete74> net147: was is you setup for working mali with mainline?
<Net147> arete74: I have Mali fbdev working on A20 using sun4i-drm on mainline
<rellla> Net147: what is your current output device?
<Net147> rellla: output to 4.3" LCD touchscreen on sun7i-a20-olinuxino
IgorPec has joined #linux-sunxi
<MoeIcenowy> Net147: Congratulations!
<arete74> net147: but the sun4i-drm is only for a13 ?
<Net147> arete74: I added device tree nodes to use it with a20
<rellla> Net147: would rgb output be possible, too? on cubietruck for example?
<arete74> net147: is possible have hdmi output ? you dts ?
<Net147> rellla: you mean the LCD controller?
<Net147> arete74: there is no driver for HDMI yet, mripard is working on it
<wens> rellla: rgb (lcd) output should be possible
<wens> rellla: vga, no
<rellla> Net147: it's not clear for me, what is needed for all these output variants. i'm very confused and always mix up LCD,VGA,LVDS ...
<rellla> wens: vga i meant, thanks
<wens> we only support lcd rgb and composite at the moment
<rellla> is there any documentation which explains the basics of all this relationships between lcd,vga,hdmi,composite,tcon,brigde ?
<wens> you mean the hardware or the drm structs?
<rellla> hardware, because i mix it all up and need to get clear in my mind :p
<rellla> sth. like "Display Basics" :)
<wens> the a80 manual has a diagram of its display pipeline
<wens> at least you get a rough idea of where things go
<wens> the tcon can output to an lcd panel using one of RGB (some call it MIPI DPI), LVDS, CPUIF (mcu stuff)
<wens> or it can pipe the output to the tv encoder or hdmi block
<wens> the tv encoder can do all the tv type outputs (composite, s/video, component) on the a10/a20, but only composite on the a13
<Net147> rellla: there is a diagram of sorts in the initial patchset - http://lists-archives.com/linux-kernel/28561424-drm-add-allwinner-a10-display-engine-support.html
<wens> ah right, that one
<wens> technically the tcon can also draw ram content, but it needs the system dma controller to feed it data
<wens> vga is the most funky output, as you need the tv encoder to do the rgb signals, and the tcon for hsync/vsync
<MoeIcenowy> wens: MIPI DSI seems to be different to RGB
<MoeIcenowy> consider the MSI Primo81 tablet
<wens> MoeIcenowy: I said MIPI DPI, not DSI :)
<wens> DSI is another block lol
fl_0 has quit [Ping timeout: 264 seconds]
<wens> and the MSI Primo81 does something stupid, as the a31s does _not_ have MIPI DSI
<MoeIcenowy> DPI...
<wens> so it has an RGB-to-MIPI DSI bridge lol
<mripard> it's not that stupid :)
<wens> MoeIcenowy: i learned that one while looking through the drm header files trying to find a type to set for the rgb encoder/connector
<wens> mripard: they could have picked another panel
<mripard> yes, sure
<mripard> but maybe it was easier for them to source the bridge than to source another panel
<mripard> or cheaper
tkaiser has joined #linux-sunxi
<mripard> because they had a good deal on the panel
<wens> probably
<wens> but the bridge is soldered on the ribbon cable... kind of nasty if you ask me
<rellla> wens: so we currently can do TCON->LCD(LVDS/RGB) ?
<wens> rellla: only RGB, not LVDS
<MoeIcenowy> maybe I will soon write a driver for LVDS
<rellla> TCON->HDMI and the VGA/Composite part through the TV Encoder are missing
<MoeIcenowy> one of my tablet uses A33 with LDVS
<MoeIcenowy> LDVS
<MoeIcenowy> LVDS
<wens> LVDS shouldn't be hard to add, you just need the hardware to test it
<MoeIcenowy> (seems that this kind of tablet is rare, as A33 is some kind of low-end chip
<tkaiser> longsleep: Now I have the Pine64 here you also tested already. First iperf result 177 Mbits/sec, 2nd close to 900 Mbits/sec. Only difference is DC-IN: http://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/?view=getlastpost
<wens> wha?
<tkaiser> Seems PHY is underpowered. No idea, I'm an electronics NOOB :)
fl_0 has joined #linux-sunxi
dot8 has joined #linux-sunxi
<dot8> I have bpi m3
<dot8> I install the arch image on it, after the a do a
<dot8> and the bpi does no longer work after the reboot. is it not possible to update the bpi with your image?
<dot8> pacman -Syuu
<MoeIcenowy> dot8: do you use systemd 231?
lemonzest has quit [Quit: Leaving]
<dot8> I Download the image from here: http://www.banana-pi.org/m3-download.html
<dot8> after that I do just a pacman -Syuu
<dot8> I do not take a look at anything at the update, so I do not know which systemd are installed
<dot8> MoeIcenowy: ,
perr has quit [Quit: Leaving]
<dot8> MoeIcenowy: arch tells me, that 231 is the version
<MoeIcenowy> systemd 231 needs linux kernel \3.8+
<MoeIcenowy> I think bpi m3 bsp is 3.4
<dot8> MoeIcenowy: ahhh ok
<Net147> plaes: did you have any luck getting sun4i-drm to work on A10 tablet?
<tkaiser> dot8: And don't be surprised if OS images from banana-pi.org don't work or do not survive updates. They're known for stuff like that :(
apritzel has quit [Read error: Connection reset by peer]
<dot8> tkaiser: any other hint
<dot8> tkaiser: for a image
<tkaiser> dot8: Nope. I made one some time ago based on an Armbian (Debian) rootfs but totally gave up on BPi-M3 in the meantime. Everything depends on this community here and mainline progress.
<KotCzarny> remove systemd?
<KotCzarny> :)_
<KotCzarny> solution for arch: http://systemd-free.org/
<jelle> KotCzarny: systemd is not the problem
<wens> lol
<KotCzarny> jelle, so what moe said is untrue?
<jelle> KotCzarny: moe?
<KotCzarny> 14:22 #linux-sunxi MoeIcenowy> systemd 231 needs linux kernel \3.8+
<KotCzarny> 14:22 #linux-sunxi MoeIcenowy> I think bpi m3 bsp is 3.4
<jelle> KotCzarny: that is true
* jelle is a bit tired of the systemd FUD
<MoeIcenowy> KotCzarny: call me Icenowy plz
<MoeIcenowy> Moe is only an adjective
<KotCzarny> clearly, both parties use that word (fud)
<KotCzarny> icenowy: k, what does it mean? (also, in simpsons there is a character named moe)
<MoeIcenowy> KotCzarny: meanless
<wens> me guesses Japanese: https://en.wikipedia.org/wiki/Moe_(slang)
<jelle> but that's funny vendor releases an unupdate-able image!
<KotCzarny> jelle, also, its not fud, systemd is broken by design
<Net147> I have used systemd 230 on 3.4 kernel and it boots, but it will hang when trying to load firmware blobs from outside the kernel because it relies on in-kernel firmware loading support introduced in later kernel versions
<wens> Net147: i just put all my blobs in the kernel :/
<MoeIcenowy> wens: yes, it's the slang
<Net147> wens: you can revert the removal of in-kernel firmware loading support if you want to get rid of the hang. it's fairly simple to do.
<MoeIcenowy> Net147: systemd won't promise it can be running on 3.8-
<Net147> MoeIcenowy: yes, it's your own risk
<wens> Net147: it's not hanging, it just can't find the blobs on the disk for whatever reason
<Net147> wens: I mean revert the removal of out-of-kernel firmware loading support...
<tkaiser> jelle: They did the same with their Debian images, took an Armbian rootfs, forgot to edit sources.list and with the next apt-get upgrade on BPi M3 images u-boot has been overwritten with mainline u-boot for H3. It happens again and again and 'Team BPi' simply does not care :)
<jelle> tkaiser: woah
<KotCzarny> hehe, 'forgot'
<KotCzarny> ;)
iamfrankenstein has quit [Quit: iamfrankenstein]
<Net147> wens: generally blobs need to be outside of the kernel unless they are GPL...
apritzel has joined #linux-sunxi
<wens> Net147: yeah
<MoeIcenowy> Net147: but wens do not want to redistribute the zImage
dot8 has quit [Read error: Connection reset by peer]
<Net147> wens: MoeIcenowy: yes, it's fine if you're not redistributing
<longsleep> tkaiser: yeah, so you didnt find a a problem except that if its not properly powered gigabit does not work
<longsleep> tkaiser: ah - so you think this board has a problem when powered with microusb more than usual?
<KotCzarny> longsleep, you need power source with regulated amperage
<KotCzarny> to test it easily
<willmore> I have a bunch power supply, a Pine64, and gigE. What needs tested?
<ssvb> wens: hmm, you seem to be the maintainer of the SinA33 board in U-Boot, do you have any idea why booting from eMMC fails for this person from the linux-sunxi mailing list?
<wens> ssvb: i've not tried it myself, but he might be using the defconfig directly, and putting it on eMMC
<wens> the defconfig does not enable the emmc connected mmc
<ssvb> wens: is there a good reason not to enable emmc support by default?
<wens> just haven't gotten around to it
<wens> i only did the patches a couple days ago
<ssvb> can you maybe reply in the linux-sunxi mailing list? or would it be better to be escalated to the mainline u-boot mailing list?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<wens> sure
<tuxillo> hi
<tkaiser> willmore: You could try to explain to me why if I feed 5V into Euler connector only 4.6V are available on Pine64's USB ports when jumper is in BAT position.
<tkaiser> willmore: Or you could measure exactly that and if it's 4.9V or more on your board maybe we found the real culprit for the GbE issues.
<tkaiser> longsleep: The relationship with the crap connector is obvious. Simply by powering through Euler pins throughput in TX directions increased from 177 to nearly 900 Mbits/sec. But still a lot of retries and still a HUGE count of retries in RX direction.
iamfrankenstein has joined #linux-sunxi
<tkaiser> And schematics we have are for the pre-production batches where power routing was different. So where/how to continue?
Putti has joined #linux-sunxi
<jemk_> tkaiser: since you probably have the biggest collection of h3 boards, would you mind doing this on !(opi plus) boards: https://linux-sunxi.org/User:Jemk/H3_DRAM_delay_tests
<jemk_> only needs fel and uart
jemk_ is now known as jemk
<tkaiser> A GbE PHY that wants 2.5V and 3.3V but gets only 2.0V and 2.8V might behave somewhat strange ;)
<tkaiser> jemk_: Why not letting someone test with H3 boards that are known to fail early?
<plaes> Net147: sorry, busy with SAR stuff
<plaes> fire drill on cruise ship
apritzel has quit [Read error: Connection reset by peer]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<jemk> tkaiser: more tests are good, but i also want to see the difference to known working boards
dhanson358 has joined #linux-sunxi
<jemk> everyone is invited to run this, though i can't promise any useful results yet
<jelle> jemk: I have an orange pi (pc, one) avaliable
<jemk> it only shows which delays produce errors and which don't, similar to ssvbs old tpr3 test
Putti has quit [Ping timeout: 252 seconds]
<jemk> jelle: if you have some minutes, please try it, it's fast and easy
<jelle> jemk: just boot right?
<jemk> only the spl is needed, via fel (or sdcard), output on uart
tkaiser has joined #linux-sunxi
<jelle> gotcha, I can find some time tommorow
<dhanson358> hey all…i’m new to the sunxi platform, but have been trying to get a buildroot running on an Allwinner H3 NanoPi Neo…I’ve had success getting everything running on mainline kernel, but not with a lot of peripherals (USB and Ethernet, mainly)…what’s my best bet for that to work? would it be compiling from the sunxi-next branch?
<tkaiser> willmore: Sorry, I meant the jumper has to be in 5VDC position. I'm talking about this one: http://linux-sunxi.org/Pine64#DC5V.2FBAT_POWER_jumper
<dhanson358> it’s a bit unclear to me support for H3 on there right now, a lot of the docs seem to have more references to the Axx series
<tkaiser> willmore: Would be interesting what voltage you get when powering through Euler pins. At least this something that should be compared between boards that are known to work ok with GbE and those who don't
tkaiser has quit [Client Quit]
afaerber has quit [Quit: Ex-Chat]
_mamalala has joined #linux-sunxi
_mamalala_ has quit [Ping timeout: 252 seconds]
<willmore> tkaiser, what software do you have it running? I imagine the config of the power controller chip will matter.
apritzel has joined #linux-sunxi
<dhanson358> sorry KotCzarny, I meant with regard to sunxi-next…is that the branch that’s one step ahead of what gets merged to mainline?
<dhanson358> i.e. a 4.x ?
<KotCzarny> dhanson358: nah. just use mainline and cherry pick patches from that page to enable subsystems you want (or just wait a bit)
iamfrankenstein has quit [Quit: iamfrankenstein]
tkaiser has joined #linux-sunxi
<mripard> dhanson358: you're right.
<tkaiser> willmore: If the jumper is in 5VDC position PMIC is not involved at all. But if I feed 5.1V and get then only 4.6V on the USB ports (and that's the only reason this jumper is there) simply looks 'wrong'. So I would suggest testing this out and compare between Pine64 boards that are known to work ok with GbE and those who don't.
<wens> dhanson358: it's mostly whatever sunxi related stuff that will be in the next release, a subset of linux-next
<wens> which doesn't get redone everyday
<tkaiser> willmore: AFAIK Pine64 folks never released schematics for the powering of the current PCB revisions so it's somewhat useless to continue research anyway.
Amit_t_ has joined #linux-sunxi
dhanson358 has quit [Quit: dhanson358]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 260 seconds]
dhanson358 has joined #linux-sunxi
<dhanson358> cool, thanks i’ll give that a shot.
matthias_bgg has joined #linux-sunxi
<dhanson358> anyone had any good/bad experiences with the nanopi neo (h3) ?
<KotCzarny> tkaiser had
<KotCzarny> its board is so small it has troubles with thermal dissipation
<KotCzarny> so you shouldnt put too much stress on it (ie. downclock and add some good heatsinks)
cnxsoft has quit [Quit: cnxsoft]
vishnup has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
<dhanson358> cool
<dhanson358> yeah i’m not looking to use it for anything very hard…telemetry type stuff mostly
vishnup has quit [Remote host closed the connection]
vishnup has joined #linux-sunxi
<dhanson358> tkaiser did you have it running on the 4.x kernel, or were you mostly testing on the stuff ported from Allwinner’s 3.x?
avph has quit [Ping timeout: 260 seconds]
reinforce has quit [Quit: Leaving.]
avph has joined #linux-sunxi
enrico__ has joined #linux-sunxi
enrico_ has quit [Ping timeout: 264 seconds]
dhanson358 has quit [Quit: dhanson358]
The_Loko has joined #linux-sunxi
The_Loko has quit [Remote host closed the connection]
y0x79 has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<lvrp16> it's hilarious how a chinese company comes out with a $15 dollar board and another chinese company will clone that board for sale
y0x79 has quit [Ping timeout: 264 seconds]
<KotCzarny> lvrp16: either that, or patent hell, choose your poison
<KotCzarny> smart users will choose good vendor, others will buy the cheapest
<KotCzarny> and keep in mind whole chinese economy is based on cloning
IgorPec112 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
Putti has joined #linux-sunxi
<ssvb> lvrp16: have I missed something? who has cloned what?
<lvrp16> pine64 not releasing schematics
<lvrp16> because it would take 1 business more to x-ray the board and clone it
reinforce has joined #linux-sunxi
<lvrp16> business day*
<lvrp16> some of the suppliers haggle over 0.005 rmb for a 3k order
<lvrp16> 15 rmb/month difference
<MoeIcenowy> lvrp16: to be honest
<MoeIcenowy> I've heard that
<MoeIcenowy> no x-ray is needed
<lvrp16> they delaminate?
<MoeIcenowy> the board factories in Shenzhen is a union
<MoeIcenowy> if you can pay
scream has joined #linux-sunxi
<MoeIcenowy> and provide the reference schematics
<MoeIcenowy> (the one provided by Pine64 is enough)
<lvrp16> hehe
<MoeIcenowy> and then they can get the original board file
<MoeIcenowy> and then produce it
IgorPec112 has quit [Ping timeout: 244 seconds]
<KotCzarny> hehe
<KotCzarny> so the whole 'lets hide our plans' is moot
dhanson358 has joined #linux-sunxi
<jmcneill> lvrp16
<jmcneill> lvrp16: there is a schematic for pine64+ 1GB
<lvrp16> I meant PCB layout schematic
<lvrp16> have they released that?
<lvrp16> i know they have logical schematic
Mr__Anderson has joined #linux-sunxi
jernej has joined #linux-sunxi
<vpeter> Which company actually give PCB design? I bet no one.
<MoeIcenowy> seems that olimex does
matthias_bgg has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
<willmore> tkaiser, did you put any load on the USB ports?
<willmore> What software are you using? I haven't gotten mine up and running since I had no specific use for it and the software seemed to be in a state of rapid change.
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
IgorPec112 has joined #linux-sunxi
<willmore> lvrp16, that's a lot of info and I love me some ODROIDS, but there's no gerber files there. :)
avph has quit [Ping timeout: 265 seconds]
avph has joined #linux-sunxi
IgorPec112 has quit [Ping timeout: 265 seconds]
IgorPec has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> willmore: the purpose of this jumper on the 1GB/2GB Pine64 variants is there to directly route DC-IN to USB ports (avoiding the PMIC at all). You would not even run any OS image on the board to measure what seems interesting to me.
<tkaiser> willmore: Of course I used Armbian (xenial/legacy in this case http://www.armbian.com/pine64/ ) but it shouldn't matter. And the 'load' on the USB port was a Banana Pro since there AXP209 can measure the voltage available.
<tkaiser> But in case you've a bench PSU and a multimeter all that's needed is connecting the PSU to Euler pins 4/6 and then measure on the USB port. Since I find it really strange to feed 5.1V on the Euler connector and then getting just 4.6V on the USB port. While feeding 5.1V through the Micro USB socket (leading to some voltage drops) I get higher voltages on the USB ports. This just feels 'wrong'
<tkaiser> And it's important in which position the jumper is. Has to be 5VDC and not BAT. The only purpose of this test is a quick check how/if other Pine64 do also show a voltage drop here. And if they do and are also affected be the 'GbE issue' then undervolting the PHY might be the culprit.
<tkaiser> If you never used the board before then you also don't know whether you're affected by the GbE issue? If so a quick check would be to run iperf3 against another GbE capable board. An ODROID-C2 with some tweaks should max GbE out.
dhanson358 has quit [Quit: dhanson358]
<tkaiser> Of course knowing whether/where test points for the PHY voltage are available on the board would be better than such a shot in the dark test.
dhanson358 has joined #linux-sunxi
<willmore> tkaiser, the only reason I ask about the software version is so I can see if I have problems with GigE.
<willmore> I'll take it up to my office and see.
yann has quit [Ping timeout: 240 seconds]
<tkaiser> willmore: Ah, understood. Then you can take legacy/xenial and end up at +900 MBits/sec in both directions, with vanilla/xenial you'll end up with 470/600 Mbits/sec depending on direction. Even more important when testing with iperf3: Look at the retry numbers. If they exceed 0 then something's wrong already.
<tkaiser> (most probably the main reason for lower performance with vanilla Armbian image is that then CPU cores are only clocked with 408 MHz)
enrico__ has quit [Quit: Bye]
<willmore> Eek. Okay.
<willmore> A 7z file? I'll have to see if I have anything to uncompress that.
<willmore> Ahh, p7zip might do it.
JohnDoe_71Rus has joined #linux-sunxi
<tkaiser> willmore: Yes, 7z|7za|7zr e $image will do the job. And 7-zip since a 1.2GB OS image is a +200MB .7z and a +700MB .zip
<willmore> Yikes. I don't tend to use 'zip' like programs. I'm an old UNIX guy, so I use tar to archive things and then whatever file compressor is currently the hot thing. I think I'm still using 'xz'.
<willmore> The "Yikes" was for the difference in compression.
<tkaiser> willmore: We only use zip on OS X since there the internal compressor/decompressor makes use of OpenCL and zip is processed there almost entirely on the GPU while the CPU can do other stuff.
<willmore> That's interesting. I didn't know that.
ricardocrudo has quit [Remote host closed the connection]
<tkaiser> You have to use ditto (not zip) which can also 'stream' ZIP to stdout (nice on web servers). But we get somewhat off-topic ;)
<willmore> tkaiser, agreed. ;)
<willmore> Okay, writing the uSD card. I'll head to the office when that's done.
Mr__Anderson has quit [Remote host closed the connection]
willmore has quit [Ping timeout: 255 seconds]
[7] has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
tkaiser has quit [Ping timeout: 264 seconds]
willmore has joined #linux-sunxi
tkaiser has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<apritzel> tkaiser: with "zip using OpenCL" you mean for the original DEFLATE algorithm? Or is that doing more advanced stuff?
<tkaiser> apritzel: On OS X the system's zip compressor uses OpenCL. In a shell you would've to use the ditto tool: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/ditto.1.html
<apritzel> I am just wondering because I found a few years ago that at least gzip is memory bound on modern CPUs
|Jeroen| has joined #linux-sunxi
<willmore> tkaiser, doing a quick test to see how the board does. Powered it via Euler (2,4 +; 6,11 GND).
<willmore> GigE seems fine.
<tkaiser> apritzel: I don't know much about that stuff. Apple started to propagate use of OpenCL in OS X 10.6 (called 'Grand Central Dispatch' there) and moved stuff on the GPU with every new OS X release. And now you get zip compression/decompression without CPU utilization.
<willmore> 992/903 Mb/s using iperf (v2) V3 not working for some reason. I'm looking into it.
<tkaiser> willmore: Good to known. Now really curious how voltage on the USB port looks like when using the 5VDC switch
<willmore> trying to find a good USB load to test with.
<jonkerj> resistor
<jonkerj> 2.5W 10ohm
<jonkerj> :-)
<KotCzarny> hdd enclosure
<KotCzarny> ;)
somedude23 has joined #linux-sunxi
<tkaiser> LOL, I found an adapter for 5.5/2.1 PSUs to be used with the crap connector (some people also call 'Micro USB').
<tkaiser> 5.0V PSU: 486 Kbits/sec, 5.2V PSU: 234 Mbits/sec. So the 0.2V difference are responsible for ~500 times more 'performance' (yeah, it's Kbits/sec vs. Mbits/sec):http://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/?view=getlastpost
<KotCzarny> :)
<KotCzarny> and that's why i love my meanwell PSUs (i can regulate voltage)
<apritzel> tkaiser: wow, that's pretty amazing. And strange, the PMIC should be able to provide stable 3.3V even with somewhat lower input voltage
<apritzel> or does that PHY draw some much current?
<tkaiser> apritzel: the PMIC works great on the USB ports, I also used a step-down converter before and fed between 4.0V and 5.5V and Pine64 worked and showed stabled 5.0V on the USB port with jumper in BAT setting
<apritzel> so the PHY seems to be driven by DC1SW, which I guess is using DCDC1 as the regulator
<tkaiser> But I have no idea how the 2.5 and 3.3V for the PHY are generated. Obviously they're not stable and depend on DC-IN input voltage (but I have no skills regarding electronics, I'm totally dumb here!)
<apritzel> which should be the voltage on the headers, so 3.3 V
<tkaiser> apritzel: RTL8211E on other boards is responsible for 370mW when switching between Fast and GBit Ethernet
<apritzel> driving the PHY with 2.5V is apparently _an option_ for an A64 board, but the Pine uses hardwired 3.3 Volts
<willmore> Okay, a 120mA light dropped the voltage by 50mV.
yann has joined #linux-sunxi
<tkaiser> willmore: Which voltage is available on the USB port and being fed?
<willmore> With no USB load, there is no voltage drop between the Euler and the USB--that I can measure. I'll try it with load.
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<tkaiser> willmore: That's great, since I have 0.5V difference on androsch's board when being idle.
<willmore> Okay, measured some more. 5.15 at the Euler. 5.15 at USB (unloaded). 5.13 at USB with 120mA load.
<tkaiser> willmore: Thanks a bunch, I think that pretty much explains it already. On the board I'm testing there happen voltage drops that seem to affect the PHY.
<willmore> Want me to try GigE performance vs input voltage?
<KotCzarny> what is voltage at euler with usb load?
<willmore> Kot, good question.
<tkaiser> willmore: Yeah, that would be great. Please try to feed 4.5V and check what's happening :)
<willmore> KotCzarny, 10mV or lower.
<willmore> tkaiser, okay.
<willmore> tkaiser, Okay, ran a bunch of tests down to the point where, I guess, there is a brown out protection.
<willmore> No difference in perfromance that I can detect.
<willmore> It shut down just around 4.5V
<tkaiser> willmore: ok, thanks
<KotCzarny> connect phone chaarger ?
<KotCzarny> your psu might be too good (not noisy)
<tkaiser> apritzel: I drove to the city today to buy a new multimeter. Measured 3.28V between 3.3V and GND on RPi connector
<willmore> Okay, I rebooted and got in a run at 4.43V. No difference. Any lower and I think it'll brown out again.
<tkaiser> Since I have no electronics knowledge at all maybe someone can help me: In case PCB traces are 'tiny' do they start to act also like resistors? 3.3V here get 3.0V there?
<willmore> KotCzarny, sorry. ;) it'a a linear supply with low gain on the last stage, so it should be very quiet.
<willmore> tkaiser, yes, smaller traces act as higher value resistors.
<KotCzarny> recheck speed with crappy psu
<willmore> a resistor 'resists' current flow. So, at higher currents, the voltage 'drops' along that resistance by more.
<willmore> KotCzarny, can you quantify that? ;)
<tkaiser> willmore: ok, so to really nail the problem down the voltage available to RTL8211E should be measured?
<KotCzarny> well, connect toa ndroid phone, if touchscreen acts up, then chsrger is crappy
<willmore> If anyone want the raw data: https://paste.fedoraproject.org/424060/47335910
<willmore> tkaiser, yes.
The_Loko has quit [Quit: Leaving]
<willmore> Or, maybe some block on the SoC that talks to the RTL8211E.
<tkaiser> willmore: That's why I asked for the voltage available at the USB ports all the time. On the board here there's a voltage drop but on yours not.
<willmore> I didn't try it with a very high current. 120m
<KotCzarny> maybe it matters WHICH port?
<willmore> A isn't much.
<willmore> I did the top port.
IgorPec112 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<tkaiser> Anyway: the affected boards can be considered defective. These voltage drops are not acceptable. Now people in pine64 forum could start to check their boards. But I doubt they are able to since one person prevents any progress being made by censoring others' suggestions.
<tkaiser> Let's hope pine64 folks accept the issue now as being a hardware issue, do some investigations on their own and offer refunds and/or new boards. And I really hope they replace the crap connector with a sane barrel plug on the next PCB revision
IgorPec has quit [Client Quit]
<willmore> tkaiser, let me know if you need more testing done at some later time. I'll work on getting a better USB load setup. I know I cut off some type A connectors some time ago that I can use to make something useful.
<tkaiser> willmore: Thanks for the offer but I doubt there is more to test from your side. Would now be important that affected Pine64 users would check their boards regarding insufficient powering (maybe just by avoiding the crap connector and powering through Euler pins many could resolve the issue)
<KotCzarny> he can check with crappy psu still
<willmore> One could hope that will resolve it. But, if something should happen, remember I have the gear and and am willing to test.
<KotCzarny> ie. noisy vs not-noisy
<willmore> I'm not sure I really have a crappy PSU....
<jemk> i don't have a crap psu around, but a clean lab supply from 4.5V to 5.3V all give constant ~600MBit/s here
<willmore> I guess I could use a phone charger or something.
<KotCzarny> willmore: order any 1-2usd psu from aliexpress
<KotCzarny> or order from someone
<KotCzarny> s/order/borrow/
<KotCzarny> most 'travel' chargers are crappy
<willmore> I've got some little 1A chargers. I'll try to lash one of them up.
<willmore> Hmm, armbianmonitor doesn't seem to report the SoC temp on the pine64.
<tkaiser> willmore: True: https://github.com/igorpecovnik/lib/issues/457#issuecomment-245194992 (I left it up to Igor to resolve the issue but he's ill so it might take some time)
nikre has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
dhanson358_ has joined #linux-sunxi
dhanson358 has quit [Ping timeout: 264 seconds]
dhanson358_ is now known as dhanson358
IgorPec112 has quit [Ping timeout: 276 seconds]
Amit_t_ has quit [Ping timeout: 264 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<nikre> has a realtime kernel build been attempted before on opi pc? any distribution
<tkaiser> nikre: You know you can use mainline kernel on H3 boards? And even for 3.4 there is something: http://forum.armbian.com/index.php/topic/1885-rt-patches-for-sun8i-kernel/
<willmore> thanks, tkaiser.
<tkaiser> willmore: Huh? What?
<willmore> For the link to the github issue for the temperature problem.
<willmore> :)
apritzel has joined #linux-sunxi
<nikre> ty tkaiser. there are multiple ways to use rt i guess. do you know how they differ? rt_preempt, xenomai, rtai, standard kernel with preempt.
<tkaiser> nikre: Nope, no idea at all (as with most kernel stuff)
<nikre> i guess some of them dont give you real time guarantee.
<mripard> nikre: standard kernel with preempt is not RT
<mripard> rtai is dead iirc
<mripard> or close to
<nikre> yup mripard
<mripard> which leaves PREEMPT-RT or Xenomai
<mripard> the latter having better latencies
apritzel has quit [Ping timeout: 244 seconds]
<mripard> but being way more invasive
<nikre> invasive in?
vishnup has quit [Quit: Leaving]
<nikre> there's a raspbian xenomai build
scream has quit [Remote host closed the connection]
<mripard> nikre: in the kernel
<mripard> it's basically an entire micro-kernel that sits beneath linux
<nikre> does it have a bad side to it?
avph has quit [Ping timeout: 260 seconds]
iamfrankenstein has joined #linux-sunxi
<nikre> is there a right cpu arch. for rt guaranteed jobs?
<GeneralStupid> nikre: whats rt?
<nikre> real time
avph has joined #linux-sunxi
<KotCzarny> GeneralStupid: guaranted to happen when you want it
<GeneralStupid> i guess it hardly depends on your application
vagrantc has quit [Quit: leaving]
<KotCzarny> on non-rt kernels, there might bedelays (called jitter)
<GeneralStupid> for example we delive an architecture without DMA because the lateny is smaller then
<mripard> nikre: it's harder to setup, you don't have a lot of kernel releases that are elligible
<GeneralStupid> hmm try bare metal -.-
<mripard> GeneralStupid: it really depends on what your latency requirement is
<GeneralStupid> for guaranteed real time, (there are two "levels" of that "real time" thing)
mpmc has quit [Ping timeout: 265 seconds]
<GeneralStupid> if you need to be sure program it bare metal. and if you know your application then use the right processor for it
<KotCzarny> programming bare metal is harder than taking rt linux and writing simple app
<mripard> GeneralStupid: it really depends on the latency you want to have
<mripard> not everything is a braking system
<GeneralStupid> we do a lot of hard realtime stuff at work and use our own architectures and we do a lot directly in hardware (or emulation on fpga)
<nikre> fpga is idd the best way but too expensive for now
lamer14733646012 has joined #linux-sunxi
<mripard> GeneralStupid: again, it depends on the latency you want to reach
<mripard> if the order of magnitude is the milliseconds
<nikre> this year intel brings fpga on cpu's
<mripard> then Linux is a perfectly valid choice
<nikre> i hope arm follows too
<mripard> ARM did that years ago :)
<nikre> i mean the end-user product. arm is new itself for the end user
<GeneralStupid> nikre: look at the zynq-7000
<GeneralStupid> it is an end user product
<nikre> i guess intel uses fpga for tlb
<GeneralStupid> fpga on CPUs or real CPUs in fpgas is not a real end user thing
<nikre> GeneralStupid, zynq is not end user product as i meant
tkaiser has quit [Ping timeout: 276 seconds]
<nikre> intel has bought altera
<GeneralStupid> theres a lot of research with "reconfigurable processor architecures"
iamfrankenstein has quit [Ping timeout: 265 seconds]
<GeneralStupid> its not really that easy :)
<nikre> i mean that
<nikre> it is coming this year
<nikre> they use fpga for tlb
<nikre> iirc
<nikre> translation lookaside buffer
<GeneralStupid> i talk about using fpga to implement special extensions e.g. trigonometric functions if they are needed
<nikre> xeon's will have fpga
<GeneralStupid> nikre: did you already write some real hardware modules?
<nikre> on fpga?
<GeneralStupid> its not really a difference (it should not be :-D)
<nikre> nope
<GeneralStupid> i remember IBM Processors which could load different microcode and then it would act as a special Databse CPU
<GeneralStupid> nikre: i like those boards and i like OpenRISC for example
<GeneralStupid> nikre: i would say iam good at C and iam also good at VHDL but doing hardware stuff takes A LOT MORE TIME
<nikre> yup i can imagine
<GeneralStupid> but for Server CPUs it would be a really nice addon
<GeneralStupid> maybe its just a matter of time and open source projects add hardware modules to their projects
florianH has quit [Quit: Connection closed for inactivity]
<GeneralStupid> wow Arria 10 is a good one -.- the smallest one has 160k Logic Elemts (holy shit)
iamfrankenstein has joined #linux-sunxi
<nikre> it is big news. intel buying altera was also big.
<GeneralStupid> intel buys altera is not new to me
<GeneralStupid> but the xeon thing is smthg. i didnt know
<GeneralStupid> iam really interesseted how they will push the tools
<GeneralStupid> for me developing hardware is that awful because the tools are awful
paulk-collins has quit [Quit: Leaving]
<nikre> it'd be great to have easier, more abstract fpga development libraries for a CS
<GeneralStupid> hm possible but atm generated hardware is not really good
somedude23 has quit [Quit: Ex-Chat]
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
paulk-aldrin has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
Putti has quit [Ping timeout: 250 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
lamer14733668814 has joined #linux-sunxi
lamer14733646012 has quit [Ping timeout: 264 seconds]
dhanson358 has quit [Quit: dhanson358]
gzamboni has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
lamer14733668814 has quit [Quit: jIRCii - http://www.oldschoolirc.com]
fire219 has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
afaerber has quit [Quit: Ex-Chat]
pg12_ has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
afaerber has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
formruga has quit [Read error: Connection reset by peer]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nikre has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
ganbold has quit [Ping timeout: 264 seconds]
petr has quit [Ping timeout: 276 seconds]
petr has joined #linux-sunxi
Raku has joined #linux-sunxi
<Raku> I have an oldish offbrand tablet deal, IdeaUSA CT802, it's an allwinner a10 device I believe. I was trying to build a newer twrp version for it and in the process found some prebuilt ones, so I tried them out just to test, the second one booted but had no touch response and adb wasn't functional past saying it was a thing. I went looking and found livesuit, I can get the tablet in to the FEL mode, but
<Raku> all images I try to load fail to load
<Raku> I'm on arch linux, and I compiled the latest livesuit from git
apritzel has quit [Ping timeout: 244 seconds]
jernej has quit [Ping timeout: 240 seconds]