<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.
<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?
<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?
<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
<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.
<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.
<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.
<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?
<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.
<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>
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.
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