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
libv has joined #linux-sunxi
bwarff has quit [Ping timeout: 276 seconds]
sophiee has joined #linux-sunxi
TheSeven has quit [Ping timeout: 248 seconds]
juri_ has quit [Ping timeout: 276 seconds]
libv_ has joined #linux-sunxi
juri_ has joined #linux-sunxi
<sophiee> hi there we have a problem with an q8 a13 tablet, we want boot a sunxi 3.4.104 linux kernel the uart of the ttl serial gives us this kernellog:
<sophiee> is there a simple fix to continue the kernelboot?
TheSeven has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
<sophiee> fixed
<sophiee> lol
<sophiee> new uboot fixed the problem
wazzup has quit [Ping timeout: 252 seconds]
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 260 seconds]
libv has quit [Ping timeout: 276 seconds]
libv has joined #linux-sunxi
wazzup has joined #linux-sunxi
bwarff has joined #linux-sunxi
ninolein has quit [Ping timeout: 248 seconds]
apritzel has quit [Ping timeout: 244 seconds]
ninolein has joined #linux-sunxi
khuey is now known as khuey|away
ganbold has quit [Ping timeout: 244 seconds]
ganbold_ has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 244 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
egbert has quit [Ping timeout: 250 seconds]
egbert has joined #linux-sunxi
cptG_ has quit [Ping timeout: 268 seconds]
cptG has joined #linux-sunxi
<willmore> More meaningless benchmarks. minerd: PiB+ 0.49KH/s Pi2B 1.85KH/s Opi1 2.05KH/s C2 4.56KH/s. All native code built for that processor's features and everyone has enough cooling not to throttle.
<willmore> I'm sort of surprised at the performance of the pi2B compared to the Opi1. A 0.9GHz A7 quad vs a 1.2GHz A7 quad. I was expecting a bigger gap. /proc/cpuinfo says they're the same core revision, but I could be reading that wrong.
Andy-D has joined #linux-sunxi
khuey|away is now known as khuey
khuey is now known as khuey|away
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 264 seconds]
montjoie_ has quit [Ping timeout: 240 seconds]
montjoie has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
khuey|away is now known as khuey
reev has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1_ has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 276 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
IgorPec has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 248 seconds]
Gerwin_J has joined #linux-sunxi
<wens> montjoie: i'll check the schematics
<wens> montjoie: but if you mean regulator for external phy, then no, that has to be added to the ethernet driver
<wens> (it would probably be with the mdio bus driver if they were separate)
<wens> i'm still in the US at another conference though
IgorPec has joined #linux-sunxi
cptG_ has joined #linux-sunxi
<montjoie> wens: ok
cptG has quit [Ping timeout: 248 seconds]
KotCzarny has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
JohnDoe_71Rus has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
clonak has joined #linux-sunxi
ddc has joined #linux-sunxi
<ddc> wens : hi
<ssvb> willmore: regarding the performance difference vs. pi2, there appears to be something wrong with the L2 cache behavior on H3 with the 3.4 kernel - https://github.com/ssvb/tinymembench/wiki/Orange-Pi-PC-(Allwinner-H3)
<ssvb> the memory access latency increases really a lot after 128K
<ssvb> while on the pi2, we can see the whole 512K being properly used in the latency test - https://github.com/ssvb/tinymembench/wiki/Raspberry-Pi-2-(BCM2836)
leviathancn_szu has joined #linux-sunxi
bwarff has quit [Quit: Leaving]
<topi`> maybe the H3 has a 128K cache? :)
<topi`> found the reason why they're dirt cheap!
<topi`> has anyone successfully gotten SPI to work on BananaPI? if so, tell me how :)
<topi`> I tried spidev_test.c from linux/Documentation/spi and it says Inappropriate ioctl for device
leviathancn_szu has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
leviathan_ has joined #linux-sunxi
<topi`> SPI_IOC_MESSAGE: Invalid argument
<topi`> duh.. I wish I had more experience with SPI
<plaes> do you have spi node in the dts?
<topi`> this is 3.4.x kernel, so probably does not use the dts but the FEX?
<topi`> Linux bananapipro 3.4.110-sun7i #12 SMP PREEMPT Tue Mar 1 08:39:29 CET 2016 armv7l GNU/Linux
<plaes> yea
<plaes> is there spi section in fex?
IgorPec has joined #linux-sunxi
tkaiser has joined #linux-sunxi
fredy has quit [Excess Flood]
<tkaiser> ssvb: Did you run tinymembench with mainline kernel on H3 also?
fredy has joined #linux-sunxi
<ssvb> tkaiser: yes, I think that the L2 cache was working fine with the mainline kernel
<ssvb> I have done this test a long time ago, because I wanted to confirm if H3 really has 512K or L2 cache
<ssvb> *of L2 cahce
<ssvb> damn typos
<tkaiser> ssvb: I run it currently with 4.6 and AFAIK 1008 MHz (if nothing has changed in 2016.03)
<tkaiser> ssvb: Yes, looks better: http://pastebin.com/e7wE4kAe
<tkaiser> With 3.4 even the 128k look suspicious
premoboss has joined #linux-sunxi
<ssvb> yes, usually this means either hardware misconfiguration, or some parasitic activity in the background which thrashes the caches
<tkaiser> ssvb: I'm eagerly waiting for the THS stuff to get rid of 3.4 finally. Already prepared some test setups to verify/test thermal read-outs
<topi`> I guess 4.4 should work fine with BananaPi?
<topi`> yesterday I flashed the most recent Armbian 5.04 with 4.4 vanilla kernel, but (I think) it did not boot
<topi`> do not have a HDMI monitor handy to verify, I was just using the uart console
<topi`> maybe the uart console was just misconfigured after handing control u-boot -> kernel
<tkaiser> topi`: There are more than 3 users of these OS images, so if something's wrong why do you expect it's the image's fault and not yours (insufficient power supply, crap SD card)?
<topi`> yeah
<topi`> I'll try another SD
<tkaiser> topi`: Why? Why don't you *test* the card in question? h2testw and f3 do exist and are easy to use
<topi`> the power supply ought to be fine - I've used the very same supply with other BPi's which have a 2.5" spinning rust disk attached
<topi`> I just exchange SD cards for a new one when they stop working ;
<topi`> ;)
<topi`> I should probably stop buying cheap chinese clone cards from dealextreme...
<tkaiser> topi`: That's why there's still a huge market for counterfeit cards, since people do not test after purchase.
<topi`> and some do not even notice :)
Gerwin_J has quit [Ping timeout: 244 seconds]
<topi`> hm, this batch of Kingstons states "JAPAN" on the card... let's hope for the best
<tkaiser> topi`: And labels like Kingston are the reason there is still a counterfeit card market existent. 'Twice the price' for questionable hardware possible since people love brands. I would never buy a card that's nor from a manufacturer producing NAND chips and controllers and assembles them in their own factory
<topi`> it seems the ODROID-C2 is a clear winner hardware-wise, but probably not so well-supported, mainline-wise, than Allwinners
<topi`> tkaiser: true. I usually buy Sandisk and hope they're not counterfeit
diego_r has quit [Ping timeout: 248 seconds]
massi has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Gerwin_J has joined #linux-sunxi
<topi`> OK - the 4.4.3 image works OK
<topi`> using that cursed brand of Kingston )
<jelle> tkai
<topi`> it seems no /dev/spi* on igor's 4.4.3 kernel... so I guess it's time to try to modify the devicetree
mane has joined #linux-sunxi
scream has joined #linux-sunxi
<topi`> is there a "binary editor" for dtb's or do I always have to git clone kernel source and take that route?
paulk-collins has joined #linux-sunxi
<NiteHawk> topi`: some distros provide a separate package for dtc (http://devicetree.org/Device_Tree_Compiler). you can edit the .dts and (re-)compile it with dtc
<topi`> cool
_stephan has joined #linux-sunxi
<topi`> there are plenty of spi nodes in different addresses, I wonder what's the correct one...
<topi`> if I look at the BPi gpio layout, there seems to be only 1 set of SPI pins
<topi`> (the original variant, 26 pins)
<topi`> I feel like this is way beyond my skills
<topi`> I found spi0..spi3, spi0 is at 01c05000
tkaiser has joined #linux-sunxi
<_stephan> topi`, the manual yields the base addresses... wait a second
<tkaiser> jelle: ?
<topi`> hmm.. the second spi @ 01c06000 is actually disabled. Maybe that's the correct one
<_stephan> topi`, so basicly you're trying to find out, which spi the pins refer to?
<jelle> tkaiser: nice information about the bananapi
<topi`> _stephan: yeah, and enable the SPI that is exposed at the gpio header :)
<topi`> I've got a SPI display here from adafruit, but so far haven't been able to display anything :/
<tkaiser> jelle: You mean M2+?
<jelle> tkaiser: yes
<tkaiser> jelle: I still don't understand why SinoVoip copied Orange Pi only by 99% and not also the missing percent (SY8106A) too
<_stephan> according to the schematic it's spi0
<jelle> tkaiser: sigh lol
<_stephan> did you check for electrical activity on the spi using a scope yet?
<jelle> tkaiser: maybe they found one that was 1 cent cheaper :-)
<_stephan> (just to check, if the platform and all drivers are set up properly)
<topi`> I don't have a scope :(
<topi`> _stephan: there was a discussion on armbian forum about SPI, so I'm trying the patches suggested there
<_stephan> okay :)
scream has quit [Ping timeout: 268 seconds]
<tkaiser> jelle: They use one with a fixed voltage. I didn't know before how badly this affects performance when the board starts to throttle. Same will then apply to NanoPi M1 and Olimex' small H3 device too :(
vickycq has quit [Ping timeout: 244 seconds]
<jelle> ohh that's sad
<topi`> dmesg|grep spi gives nothing :(
vickycq has joined #linux-sunxi
<topi`> it seems SPI_SUN6I is builtin according to /proc/config.gz
<topi`> CONFIG_SPI_SUN6I=y
<topi`> what kind of chip is SUN4I?
<plaes> A10
<topi`> oh :)
<_stephan> sun6i is A31... I think you should look for sun7i (A20)
<topi`> I think the only vendor who still uses A10, is Olimex
<plaes> A10/A20 are mostly compatible
<tkaiser> jelle: On the other hand 'normal' use cases aren't that much affected. If you don't do benchnmarking for a living then you might not notice a difference. But temperatures/consumption will always be higher compared to OPis especially those using SY8106A
<plaes> ie A20 is using sun4i drivers
<topi`> plaes: OK, that explains
apritzel has joined #linux-sunxi
<topi`> at least i2c seems to work ;)
mane has quit []
libv_ is now known as libv
ssvb has quit [Remote host closed the connection]
mzki has joined #linux-sunxi
khuey is now known as khuey|away
mane has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
mane has quit [Ping timeout: 244 seconds]
Amit_T has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
ddc has quit [Ping timeout: 250 seconds]
apritzel1 has quit [Ping timeout: 244 seconds]
zzeroo has quit [Quit: WeeChat 1.3]
<Amit_T> NiteHawk: Hello: I tried EFL boot on organe pi pc but it didn't work either, Does it have special FEL key on board?
<tkaiser> Amit_t: Orange Pi PC always FEL boots when no SD card is inserted: I already did it today: http://pastebin.com/0wxkhn7P
Amit_T has quit [Ping timeout: 250 seconds]
Amit_T has joined #linux-sunxi
<Amit_T> NiteHawk: Ok but its says if I don't use card at all it should fall back to FEL mode which I don't see
<tkaiser> Amit_t: Another system, USB cable in between and 'sunxi-fel ver' doesn't work?
<Amit_T> tkaiser: Sorry just didn't get you here
<tkaiser> Amit_t: Do you know how FEL boot works? You need a second computer and there the sunxi-fel command
bwarff has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
<Amit_T> tkaiser: oh you mean to say , I needed to have usb cable going through organe pi to host machine?
The_Loko has joined #linux-sunxi
<apritzel> Amit_t: yes, actually even an USB OTG cable and you need to use the USB OTG port on the OrangePi
<Amit_T> apritzel : Ok and on host I need to run ./fel command from sunxi_tools , right ?
<apritzel> yes, "./sunxi-fel ver" for a start to confirm that FEL mode is working
kaspter has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
qt-x has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<Amit_T> apritzel: This is what I see afer running ./fel command http://paste.ubuntu.com/15684926/
<apritzel> looks like success, only that you need to make sure you have a branch of sunxi-tools that supports OrangePi
<Amit_T> With other branch http://paste.ubuntu.com/15684962/
<Amit_T> but u-boot does't boot
<tkaiser> Amit_t: Why do you use an outdated sunxi-tools version. Should look like: https://github.com/linux-sunxi/sunxi-tools/issues/37#issuecomment-198913403
<tkaiser> Amit_t: Ah, ok, you updated in the meantime
<Amit_T> tkaiser: But this /sunxi-fel uboot u-boot-sunxi-with-spl.bin doesn't work ?
<Amit_T> tkaiser: you mean to say I didn't use right syntax ?
<tkaiser> jelle: Another variant to get BPi M2+ really slow is to use SinoVoip's OS images. I try out their Raspbian currently (ARMv6 userland -- hooray)
<tkaiser> Amit_t: '-p' or not might be different?
<tkaiser> jelle: max cpufreq is 1008 MHz with this Raspbian and now Moronix Test Suite running killed cpu3 with the 'john the ripper' bench and c-ray killed also cpu2. Not I have a 1GHz dual core system already. Thanks to Raspbian made by SinoVoip :)
<tkaiser> s/Not/Now/
<KotCzarny> seriously, how about 'buying guide' chart/faq
<KotCzarny> one of the columns will be 'prone to overheating due brainf*cked voltage regulator'
<tkaiser> KotCzarny: The settings make the difference. SinoVoip re-used loboris' kernel and adopted the THS settings in a wrong way.
<tkaiser> The Phoronix tests aren't that demanding (compared especially to the new cpuburn-a7) so with other settings no CPU cores would be killed
<Amit_T> tkaiser: '-p' didn't not make any difference though
<KotCzarny> tkaiser: but wont perform up to rated clock neither => marketing cheat
<tkaiser> KotCzarny: But now BPi M2+ runs stable with 2 remaining CPU cores running at 1008 MHz and max. temp of 72¡C
<KotCzarny> also, that bpi-m2+ states 1.2GHz H3 cpu
<tkaiser> KotCzarny: It works perfectly with 1.2GHz, you just have to avoid the crappy SinoVoip OS images.
<KotCzarny> so i guess all h3s are rated as such (unless you add heatsinks by default)
<KotCzarny> now opi-pc doesnt look so bad when there are lots of even crappier boards available
<KotCzarny> in fact it looks like one of the best ;)
<NiteHawk> Amit_t: please state your *exact* Orange Pi model - yesterday you were talking about A20, but judging from your sunxi-fel output i guess that's a H3-based model (Orange Pi "PC"?)
<KotCzarny> nitehawk: let him make the photo of the board
<tkaiser> KotCzarny: Yes, in the meantime I changed my mind regarding XunLong/Steven. If he would produce a H3 variant with GbE and without garbage like the GL830 then this would be my board of choice currently
<KotCzarny> hehe, more usb ports + usb--sata dongle pack?
<Amit_T> NiteHawk: Its Orange Pi PC
<Amit_T> YES
<NiteHawk> 16:26 <Amit_T> What are minimum images needs to write on SD card in order to bring u-boot on orangepie(I was trying booting with only u-boot.spl compiled for a20 based soc)
<NiteHawk> an A20 u-boot won't get you anywhere then
cnxsoft has quit [Quit: cnxsoft]
<Amit_T> NiteHawk: yes , I am trying same u-boot-spl.bin with FEL command and seeing this error libusb usb_bulk_send error -1
<NiteHawk> error -7, or?
<NiteHawk> disconnect the device, start all over again - you need to reset/restart FEL
<Amit_T> Its error -1
<Amit_T> I need to remove only USB device not the power connection, right?
<tkaiser> Amit_t: Everything, even a serial console
<tkaiser> Amit_t: Serial adapters backpower the board sometimes somewhat and then things go crazy and you get strange behaviour.
<Amit_T> tkaiser: oh right now I don't have serial console connected (ttl to usb )
<tkaiser> Amit_t: Anyway, do a *real* power cycle
<Amit_T> tkaiser: Would u-boot boot process on serial console ?
<NiteHawk> you can confirm it's working again by doing another "./sunxi-fel ver"
<Amit_T> *Would I see u-boot boot process on serial console ?
<Amit_T> NiteHawk: Yes: Once I disconnect and reconnect , ver command works but uboot command fails with same message
<NiteHawk> where's that u-boot-spl.bin from?
<Amit_T> Its from package you provided
<Amit_T> This u-boot-sunxi-with-spl.bin file I am using with uboot command
<Amit_T> NiteHawk: is there some issue with this Image(u-boot-sunxi-with-spl.bin) ?
<NiteHawk> i suspect the culprit more likely is your sunxi-fel version
apritzel1 has joined #linux-sunxi
<Amit_T> But now , I am using latest ver of sunxi-fel pointed by tkaiser
<NiteHawk> Amit_t: power-cycle again, check with "sunxi-fel ver" and then try "sunxi-fel spl u-boot-sunxi-with-spl.bin" - same error?
<Amit_T> ok
<Amit_T> Yes , same issue , it could be from libusb package ?
<Amit_T> NiteHawk: can you please point me to expected output after running this command ,any snapshot
<NiteHawk> could be a size limitation maybe. try "sunxi-fel spl sunxi-spl.bin" instead - the .bin file is also contained in that .tar.gz
<NiteHawk> Amit_T: and i still don't get it why you keep ignoring my previous advice - start with a "known good" os image for the opi pc, so you can at least expect some sensible output on the serial console, to verify your uart setup. (only) after that start experimenting on your own
apritzel1 has quit [Ping timeout: 244 seconds]
<Amit_T> ok I would try it once I am in situation to download more that 1MB of data
<NiteHawk> "sunxi-fel spl sunxi-spl.bin" is expected to show some initial SPL output on the serial console (very basic initialization). this is an A20 example:
<NiteHawk> U-Boot SPL 2016.01-00003-gee85385-dirty (Apr 06 2016 - 11:54:07)
<NiteHawk> DRAM: 1024 MiB
<NiteHawk> CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
<NiteHawk> Trying to boot from
<NiteHawk> but first of all we need to make sure that "sunxi-fel spl" doesn't run into that error -1 also
<Amit_T> It run into same issue :(
_stephan has quit [Quit: Ex-Chat]
uwe_ has quit [Read error: Connection reset by peer]
<NiteHawk> Amit_t: can you repeat the procedure, and this connect you UART before you issue the "sunxi-fel spl ..." command? does that show anything on the serial?
Amit_T has quit [Ping timeout: 250 seconds]
uwe_ has joined #linux-sunxi
leilei has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 250 seconds]
mzki has quit [Quit: leaving]
afaerber has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
JohnDoe_71Rus has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
mane has joined #linux-sunxi
ssvb has joined #linux-sunxi
reev has quit [Ping timeout: 248 seconds]
jernej has joined #linux-sunxi
Amit_T has joined #linux-sunxi
mane has quit []
apritzel1 has joined #linux-sunxi
igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<ssvb> a bit of offtopic, anyone planning to participate in https://code.google.com/codejam this year?
apritzel1 has quit [Ping timeout: 244 seconds]
leviathan_ has quit [Ping timeout: 244 seconds]
merbzt has quit [Ping timeout: 268 seconds]
leviathan_ has joined #linux-sunxi
leviathan_ has quit [Remote host closed the connection]
Amit_T has quit [Ping timeout: 250 seconds]
orly_owl has quit [Ping timeout: 276 seconds]
cnxsoft has quit [Quit: cnxsoft]
merbzt has joined #linux-sunxi
khuey|away is now known as khuey
qt-x has quit [Quit: Leaving]
<willmore> ssvb, thanks for that info. It really doesn't look like a 512K L2 is really there. I wonder if it's not initialized right or if we really don't have a 512K L2 on the H3.
megi has joined #linux-sunxi
<megi> I probably touched my orange pi one in a bad way :(
<megi> it will not talk to me and just eats all the current it can
<megi> thankfully I had it connected just to DC-DC wit current limit set to reasonable value, not to my 30A supply :D that would not be funny
<willmore> megi, you make a good point. I just swapped out my small 5A supply and put in my big 20A supply. I should do something to limit current or one of these guys might go Pzzzffffttt!
<megi> it shouldn't be possible to brick something so that it effectively shorts the supply pins by just touching the gpio header
<megi> yeah
<willmore> Agreed, but that means polyfuses and those cost money... :)
<willmore> ssvb, tkaiser: the kernel for my H3 is 3.4.110-sun8i is that the one with the misconfigured L2? It's Armbian current.
<megi> I use those DC-DC converters with CC from china to be a bit safer, and put them between the big supplies and the boards
zuikis has joined #linux-sunxi
<willmore> megi, that's what I want to do long term. Use the 12V supply on a buss to those boards and each SBC gets its own 3A regulator.
<megi> right, that's my setup too 12V/250W + DC-DC. there may be polyfuse somewhere on the board, but i'm not sure if it is in the path when connecting power to gpio pins and not to the DC barrel
reinforce has quit [Quit: Leaving.]
<megi> I would have to check the schematics
premoboss has quit [Ping timeout: 246 seconds]
<willmore> Good point. I am feeding my boards through the GPIO pins as I'm sick of everyone using a different silly barrel connector on their boards.
<megi> no polyfuse there, just esd protection
<willmore> Okay, then that
<willmore> 's going to need some current limiting.
<willmore> topi`, The odroid c* boards are undergoing a mainlineing effort.
<megi> and GPIO 5V and the barrel connector is connected to the same line
<willmore> megi, and how big is the trace between them? pcb traces make great fuses if you want them to or not...
<megi> it's not insignifficant, ~2mm, i don't think that will provide much resistance
<megi> 3cm long going right to the regulator
<megi> i usually worry more about the wires going to the board from dc-dc, if those are thin, it can introduce a lot of instability when the board is under load
<megi> btw, I've updated my power regulation patches for oranges, here's more info https://github.com/megous/linux/commit/51de0e45c67b036ce713fb3788a66017730a01f4 in the comments if anyone is interested
<willmore> Oh, you're that megous, sorry megi, I'm new here and hadn't made the connection. I was browsing through your patches yesterday. :)
<willmore> I'm looking forward to using a mainline kernel on my Opi1 boards. :)
<willmore> Thanks for all your work!
Amit_T has joined #linux-sunxi
<willmore> Oh, those Pi1B numbers are for an overclocked board, oops. It's at the standard 1GHz overclock. That explains how it's running neck and neck with one of the Pi2 cores.
<megi> willmore: it's fun :) though now that I'm without opi1, i will only be able to test them on opi pc, but it shouldn't be a problem, because opi1 specific patches were just device tree modifications
doppo has quit [Ping timeout: 264 seconds]
doppo has joined #linux-sunxi
<Amit_T> NiteHawk: Would you like to suggest me how should I debug it (libusb usb_bulk_send error -1)
<megi> i have to learn how/where to send patches
<NiteHawk> Amit_t: That message is pretty unspecific/useless ("Input/output error"). Did you try what i suggested last (running the SPL with serial attached)?
<NiteHawk> 11:48 <NiteHawk> Amit_t: can you repeat the procedure, and this connect you UART before you issue the "sunxi-fel spl ..." command? does that show anything on the serial?
<NiteHawk> *and this time connect your
<Amit_T> ok, I think I didn't receive your last few message
<willmore> megi, that is important. :)
<Amit_T> NiteHawk: same result , nothing seems to be changed
<NiteHawk> what does that mean, no UART output?
reinforce has joined #linux-sunxi
<Amit_T> NiteHawk:Its just few garbase char on serial console, This time I used minicom for serial
<apritzel> Amit_t: is the serial console working at all? Do you have the right baud rate? Is TX and RX connected properly (and not swapped)?
<NiteHawk> Amit_t: your minicom settings should look like this http://fpaste.org/351839/14601292/
cosm_ has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<Amit_T> apritzel: baud rate is 115200 and I white cable of pl2303 is connected tx of orange pi and green cable is conncted to rx of orange pi
leilei has quit [Remote host closed the connection]
<Amit_T> these same connection I used to have on cubietrack board where it works
<KotCzarny> uym
<KotCzarny> did you connect the black cable?
<Amit_T> black cable I didn't connect
<KotCzarny> o.O
<NiteHawk> omg
<KotCzarny> it must be connected to gnd
<Amit_T> its for gnd , it it required
<Amit_T> *is
<Amit_T> ok
<KotCzarny> the only cable you dont need is the red one, and it MUST NOT be connected
<NiteHawk> you sure connected gnd for cubie, or?
<Amit_T> I am very much sure I never connected gnd on cubietrack
<KotCzarny> nitehawk, maybe they used common ground via power adapters
<KotCzarny> or some other device
<NiteHawk> well, okay - thats pure luck/coincidence then
<NiteHawk> anyway, gnd has to be connected as is clearly stated in our wiki (UART howto)
<megi> red wires are only good for bombs
<NiteHawk> they're also good at frying socs or boards...
<apritzel> megi: but only for a short while, as they are usually cut ;-)
<megi> :D
<KotCzarny> yeah, but that bomb will be less than satisfactory (ie. nothing would 'splode, only effect will be dead device ;)
<maz> an interesting face-palm moment...
<KotCzarny> maz, can happen to anyone
<Amit_T> NiteHawk: Now I don't see even there garbase on serial after connecting black cable to gnd of orange pi
<maz> KotCzarny: sure.
<apritzel> try swapping TX and RX
<KotCzarny> amit, power off the device, disconnect serial, on pc do: cat /dev/ttyUSB0, connect serial cable, connect power to device
<Amit_T> ok
<KotCzarny> apritzel, white has to be connected to TX pin on the board
<KotCzarny> amit, also, to which header/pins you are connecting? as there are few uarts
<apritzel> KotCzarny: I always get confused about what TX actually relates to, so I find myself swapping TX and RX happily
<Amit_T> KotCrarny : Its three header set representing tx,rx and gnd . Its not on GPIO header
<apritzel> also mapping colours to functionality sounds a bit Apple-ish to me ;-)
<megi> btw, there is only one safe uart for 5V on pi, and it has separate header
JohnDoe_71Rus has joined #linux-sunxi
khuey is now known as khuey|away
<KotCzarny> apritzel, yeah, would work eventually, i just try to remember white-to-TX on sbc
<megi> it has 5V/3V converter on board
<Amit_T> Now I don't see even a single garbase char on serial, is this board gone ??
<KotCzarny> apritzel, ever used black for anything else than gnd?
<KotCzarny> amit: reinsert usb plug
<KotCzarny> maybe it got misconfigured in the meantime
massi has quit [Quit: Leaving]
<apritzel> KotCzarny: no, black is always GND, ever since I first touched electronics 30 years ago ;-)
<NiteHawk> Amit_t: does the opi pc have a reset button? press reset, go through "sunxi-fel spl" routine again
<Amit_T> ok, only the sunxi-fel ver command is working
<ssvb> Amit_t: try to also add '-v' option to the sunxi-fel command line to make it more talkative
<megi> reset doesn't work this way I think on opi pc, not for me anyway... it's just connected to PL3 pin and does nothing
<ssvb> Amit_t: suxh as running "sunxi-fel -v spl ..." or "sunxi-fel -v uboot ..."
<NiteHawk> megi: really? that's pretty awful then
<megi> RESET pin on soc is connected to vcc-io (with some delay)
<megi> powercycle is the only way
<megi> I think it's meant for software reset control, like on PC with the power button on ATX boards
<Amit_T> ssvb : I just do see after appending -v option http://paste.ubuntu.com/15690925/
<ssvb> Amit_t: looks very much like a wrong SPL binary
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
<Amit_T> ssvb: would you please point me to right one
<ssvb> Amit_t: what kind of board is that?
<NiteHawk> ssvb: that error -1 no longer applies to H3? i found backreferences to that, e.g. https://www.mail-archive.com/linux-sunxi%40googlegroups.com/msg12720.html
<Amit_T> Its orange pi pc
<ssvb> NiteHawk: if one runs a boot0 blob, then the blob does not return control back to FEL and this is pretty much expected
kdubious has joined #linux-sunxi
<kdubious> ITEAD board only gets IP with UART connected... any ideas?
<NiteHawk> ssvb: okay, but we're not doing that without sd card and purely FEL, right?
<ssvb> Amit_t: are you *really* sure? Exactly the same as on the pictures from https://linux-sunxi.org/Orange_Pi_PC ?
<ssvb> Amit_t: if yes, then you can download the tarball from https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test
<ssvb> Amit_t: and run some tests with it, or take the U-Boot binary that is included there
<Amit_T> ssvb: ok, This is the one I am using https://www.crazypi.com/orange-pi-india/orange-pi-pc-india, looks same as you pointed out.
<Amit_T> ssvb: I would try from the branch you pointed out
<ssvb> ok, the board looks indeed like the Orange Pi PC
IgorPec has joined #linux-sunxi
Amit_T has quit [Ping timeout: 250 seconds]
<ssvb> NiteHawk: it's just a generic symptom of the case when the SPL runs and does not return control back to FEL (it could happily boot from the SD card in the case of boot0, or it could just die in some obscure way as Amit_t observes)
<NiteHawk> oh, okay. i pointed Ami_t to one of the mainline u-boot builds before (tarball), assuming that the contained SPL would meet sunxi-fel's expectations/standards
<kdubious> I'm on Mainline kernel & Mainline u-boot
<ssvb> NiteHawk: U-Boot is not the best piece of software and things get broken there on regular occasion
<ssvb> NiteHawk: somebody probably needs to test that U-Boot build to check if there is anything wrong with it
Amit_T has joined #linux-sunxi
<megi> NiteHawk: the tip of the master works though on orange-pi-pc + fel boot over usb
<NiteHawk> megi: i see. will keep that in mind. we had a somewhat awkward situation with the v2016.03 release where it seems that sunxi gmac was broken
<megi> ah that was meant for ssvb
<megi> not sure about that, i don't upload kernel over ethernet, but over usb
<NiteHawk> megi: no issues with usb-ehci? it thought that was effed up too currently (the fix is in u-boot-usb, but not propagated to master yet)
<ssvb> megi: ok, thanks
<megi> i don't use any usb devices in u-boot either :D
<megi> i try to limit my exposure
<NiteHawk> lucky bastard :D
JohnDoe9 has joined #linux-sunxi
khuey|away is now known as khuey
<megi> i have it so that u-boot just basicly does setenv bootargs and bootz, nothing else... and use sunx-fel to write kernel, dtb and scr to appropriate locations, so u-boot doesn't even has to have usb enabled
JohnDoe_71Rus has quit [Ping timeout: 248 seconds]
<Amit_T> ssvb : running first test case throws this http://paste.ubuntu.com/15691929/
<megi> it is good for development, but that's about it... it uses one too many cable
<KotCzarny> amit, put sunxi-fel into path
<Amit_T> ok but why it needs this .bin file ?
<KotCzarny> to change freq
<KotCzarny> as it's stability tester
<KotCzarny> s/freq/mem freq/
<lennyraposo> hehe
<lennyraposo> liek the response longsleep
<lennyraposo> 'these scripts are probably not for you'
bwarff has quit [Ping timeout: 276 seconds]
<lennyraposo> a lot of disappointed 2gb pine users
<lennyraposo> android/remix no worky good ;)
<lennyraposo> btw longsleep
<KotCzarny> lennyraposo: all in all, those sbc boards are called 'development boards' and ship with android only for a reason
<lennyraposo> have you looked at my workaround for the audio issue?
<KotCzarny> they were never meant to be used as linux boxes
<lennyraposo> it's pulseaudio
<KotCzarny> pulseaudio is evil and should die in a fire
<lennyraposo> well that's not what the Pine Team advertised
<lennyraposo> it should
<lennyraposo> poisoned, shot, hung, decapitated and incinerated ;)
<KotCzarny> and keep in mind PA would eat mem bandwidth and cpu for no good reason
<jelle> wow,
<jelle> KotCzarny: PA is fine these days
<KotCzarny> jelle: does it use dma etc or just churn data all the time?
* jelle isn't a PA dev
<jelle> but it has been working fine for me for years
<KotCzarny> jelle, working, yes, sure, but if you are limited in resources it starts showing its ugly head
<jelle> KotCzarny: ohh how low?
formruga has quit [Ping timeout: 244 seconds]
<KotCzarny> jelle: 600mhz single core with highpass filter for speakers stability?
<lennyraposo> yep Major NSA jackoff
<lennyraposo> pardon my wording
formruga has joined #linux-sunxi
<jelle> KotCzarny: with those specs I don't have experience
<lennyraposo> alsa was simple enough ;)
<jelle> you can still use alsa
<KotCzarny> but keep in mind it must copy/mix data, and those allwinner boards are severely crippled bandwidth wise
<lennyraposo> I know
<lennyraposo> but tell that to new users in teh community
<lennyraposo> it's sprea dliek abad rash on every distro
<Amit_T> ssvb: I think It worked :) , would you please confirm http://paste.ubuntu.com/15692265/
<ssvb> Amit_t: do you see a spinning cube?
<ssvb> Amit_t: or something on the serial console?
<KotCzarny> lennyraposo: not every distro, mostly on those debian/rh based ones
<KotCzarny> there is life out of deb/rh :P
<Amit_T> ssvb : let me check on serial console
<lennyraposo> like Mandriva ;)
<lennyraposo> lol
<lennyraposo> sorry
<lennyraposo> I know there is
<kdubious> Any ideas on this UART + DHCP issue?
<ssvb> Amit_t: as megi mentioned, the current U-Boot master branch should be working fine on Orange Pi PC, you have probably tried to use some broken U-Boot release earlier
<KotCzarny> afaik 2006.01 works
<KotCzarny> 2016.01
<KotCzarny> didnt try 2016.03 yet
<NiteHawk> kdubious: maybe you get random noise/characters from uart, which could cancel u-boot autostart?
<Amit_T> ssvb : Hey , I can see u-boot booting up on serial console. Thank you very mach !!!
<kdubious> What happens is this:
<Amit_T> *much
<kdubious> with no UART connected, I do not get an IP
<kdubious> with UART, I do
<ssvb> Amit_t: you are welcome
<NiteHawk> oh... that's weird
<kdubious> Actually... I need TX & either GND or RCV, and I can get an IP
<KotCzarny> amit: while you are at it, you might want to test your board with that tool
<kdubious> If I boot without uart, then connect it... no IP.
<KotCzarny> and post to wiki the results
<kdubious> I have to power on with a UART connected
<KotCzarny> as there might be a chance that your device is unstable with default freq
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<NiteHawk> kdubious: i'm tempted to suspect power supply issues there, maybe you get enough current leaking through the uart to prevent it?
<kdubious> They say 7-23V in. I'm using a 12V wall wart, no connection to earth ground
<Amit_T> KotCzarny : Sure, I just need to provide result of these cases with different freq?
<kdubious> let me see what else I have
avph has quit [Ping timeout: 246 seconds]
vagrantc has joined #linux-sunxi
<NiteHawk> which itead board is that exactly?
<KotCzarny> amit, start with default, then if it survives till the red light go up
<tkaiser> willmore: Yes, 3.4.110 kernel shows that strange behaviour where L2 cache size seems to be affected
oneinsect_ has joined #linux-sunxi
<oneinsect_> friends can someone please tell me what is the difference between a fex file and device tree?
<KotCzarny> ooh, another one with 648, that makes 3 now
<kdubious> ITEAD Core EVB + AW2041 SOM
<oneinsect_> do we need for u-boot for mainline?
<oneinsect_> both*
<KotCzarny> oneinsect_: fex is for 3.x, dt is for mainline
<oneinsect_> aha
<KotCzarny> both serve similar function
<oneinsect_> so i dont need fex file if I have dt for a particular board and when using a mainline u-boot
<KotCzarny> erm, sorry, my bad, fex is for uboot
<ssvb> KotCzarny: do you mean 4 with 648 MHz?
<KotCzarny> ssvb: ooh, 4!
<KotCzarny> oneinsect_: ^^
avph has joined #linux-sunxi
<Amit_T> ssvb : One doubt , if I have to replace default u-boot image with my own compiled u-boot Image, what should I do (Shall I replace it with default one) ?
<ssvb> KotCzarny: 4 out of 22 is ~18%, which more or less agrees with the prediction at http://linux-sunxi.org/Orange_Pi_PC#Analysing_the_first_6_reported_results: :-)
<KotCzarny> ssvb: still, pool is small, but at least no board worse than 648
<oneinsect_> KotCzarny: thanks voltage issues aside can I use the device tree of orange pi one with nanopi m1
<KotCzarny> i wonder if power supply quality/ambient emi have the effect on stability
<NiteHawk> kdubious: i have no real idea what's going on there. both uart pins and network phy seem to be on the base board, so maybe something is wrong with the way they get setup (regulators?)
<ssvb> KotCzarny: yes, we might see some board failing at 648MHz too, the estimated probability is around 3-4%
<NiteHawk> kdubious: when you say "no IP", does that relate to u-boot (only), or affect the linux kernel too?
<kdubious> in the kernel
<KotCzarny> oneinsect_: most likely things will be different (different manufacturer), but ask the wizards here, also, you can probably generate fex from android image supplied with your board
<kdubious> I'm fairly certain that the device send nothing out on Eth0
<kdubious> even though the software reports things are ok
<Amit_T> Also one more thing I don't see any LED blinking while running first case ?
<NiteHawk> kdubious: can you tell if the network interface is active at all? e.g. by looking at status leds on the connector or switch it is attached to
<KotCzarny> oneinsect_: if your manufacturer provides sdk you might check there
<oneinsect_> but everything seems the same
<oneinsect_> expect for USBs
<oneinsect_> i am planning to use mainline
<oneinsect_> so want to avoid using fex
<ssvb> Amit_t: try to reboot the board and reduce the DRAM clock speed, maybe it has already failed the test at 672MHz
<ssvb> Amit_t: you should see the memtester output on the serial console if the test is alive and kicking
<kdubious> NiteHawk: both sides are blinking
<tkaiser> oneinsect_: Good luck at the current state of things ;) You can take .dts for OPi PC since NanoPI M1 is closest to this
<KotCzarny> oneinsect_: seems != is, does it boot images for opipc? dont know if you can break anything
<kdubious> my switch shows: Sent Packets 71
<Amit_T> ssvb: but U-boot prompts comes even if the test case fails, right ?
<kdubious> Broadcast Packets Sent 94
<kdubious> but 0 for RECEIVED
<NiteHawk> kdubious: that's with uart? or is it the same without (i.e. when you don't receive an ip)?
<kdubious> sorry.. no UART now
<kdubious> and the switch shows 0 received
<tkaiser> oneinsect_: And if you don't apply at least megi's patches I'm testing right now, chances are great that you destroy your board with Mainline kernel now :)
<ssvb> Amit_t: U-Boot is much less sensitive to unreliable DRAM settings than this specialized memory tester
<oneinsect_> oooh
<KotCzarny> burn baby, burn?
<tkaiser> oneinsect_: NanoPi M1 uses also a fixed voltage so read from here on please: http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B#Fixed_voltage_.2F_overheating
<oneinsect_> here is the comparison https://s29.postimg.org/tfv2hmlkn/comparison.png
<NiteHawk> kdubious: does u-boot support your network interface with that A20 SOM? have you tried to issue "dhcp" from the u-boot prompt? it might be worth to check if u-boot networking fails in the same way
<kdubious> With UART: Received Bytes (Octets) 1715
<KotCzarny> opi* are 1.2ghz, dont believe marketing scams
<kdubious> I'd need to connect to UART to issue dhcp on u-boot prompt... but thats when things work
<NiteHawk> kdubious: ah sorry - that won't do. to access u-boot (prompt), you'd always have to connect the uart - so that's a bit pointless
<kdubious> yeah
<oneinsect_> i dont remember the url to megi's patches
<KotCzarny> oneinsect_: try selling off that nanopi, and get opipc ;)
<Amit_T> ssvb: This is serial output for memtester http://paste.ubuntu.com/15693210/
<oneinsect_> lol yes i am planning that
<tkaiser> oneinsect_: https://github.com/megous/linux/tree/orange-pi-pc (and remember: fixed voltage so you have to figure out on your own how to get this working)
<kdubious> oh, crap... it worked this time, without UART connected
<oneinsect_> hmmm
<ssvb> Amit_t: is that all? unless you see more output, it has already died
apritzel has quit [Ping timeout: 244 seconds]
<Amit_T> ssvb: on 408 freq I just see the LED blink and then it just went off in a sec
<oneinsect_> how on earth can nanopi guys just ship a product like this
<oneinsect_> without even a heatsink
<KotCzarny> amit, try 648?
<KotCzarny> may be 408 is too low
fredy has quit [Excess Flood]
<ssvb> yes, the current U-Boot default is 624MHz, which is expected to be stable on practically all Orange Pi PC boards
fredy has joined #linux-sunxi
<Amit_T> KotCzarny : Again it just blink of green LED for sec on 648, how can I run it for longer
kz1_ has joined #linux-sunxi
<ssvb> Amit_t: try 624 and then maybe 600
<ssvb> Amit_t: also check your power supply, if it does not provide enough power then the board may be unreliable
<KotCzarny> yup
<kdubious> NiteHawk: => dhcp
<kdubious> ethernet@01c50000 Waiting for PHY auto negotiation to complete......... TIMEOUT
<kdubious> ethernet@01c50000: No link.
<Amit_T> 624 gives me same and How can I check power supply, I am using usb to power cable
<kdubious> this is after reboot, with UART connected
kz1 has quit [Ping timeout: 246 seconds]
kz1_ is now known as kz1
<KotCzarny> amit: is the cable thin?
<ssvb> Amit_t: what is the maximal current rating of your power supply?
<NiteHawk> kdubious: so now you've been through all combinations? network/no network with both uart attached and disconnected? seems fishy / pretty unstable, but i have no idea what's going on there
<oneinsect_> does Orange Pi One have dynamic voltage regulator
<Amit_T> ssvb: but how do I check it
<wens> reset should be an active low pin, normally pulled high by external resistor
<wens> you have to pull it down to ground to trigger reset
Gerwin_J has quit [Quit: Gerwin_J]
<ssvb> Amit_t: where do you connect the USB plug of your power cable?
<kdubious> NiteHawk... seems like that's the case
<kdubious> UART connected: dhcp in u-boot fails
<kdubious> UART connected: dhcp in kernel SUCCESS
<kdubious> UAART not connected: dhcp in kernel USUALLY fails
<KotCzarny> ssvb: opipc uses barrel connector
<kdubious> UART not connected: dhcp in kernel USUALLY fails
<NiteHawk> kdubious: hold on, can you pastebin/show "ver" and "mii info" from u-boot?
<kdubious> ver: U-Boot 2016.03-rc2-00087-g12a7444-dirty (Mar 22 2016 - 12:53:17 -0400) Allwinner Technology
<kdubious> arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-1) 5.2.1 20151005
<kdubious> GNU ld (GNU Binutils for Ubuntu) 2.24
<kdubious> mii info:
<kdubious> PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX
<kdubious> .... PHY 0x1F:...
<kdubious> all sequential
<tkaiser> oneinsect_: linux-sunxi wiki, and yes, it has but rather primitive but still better than NanoPi M1
<NiteHawk> kdubious: i suspect you have one of those u-boot versiosn where sunxi gmac is broken. so dhcp not working there is meaningless
<oneinsect_> thanks
<ssvb> KotCzarny: Amit_t apparently uses a usb-to-barrel-plug cable, the same as shown on the picture - http://www.aliexpress.com/store/product/Best-Seller-Orange-Pi-One-SET-1-Orange-Pi-One-USB-to-DC-4-0MM-1/1553371_32640573188.html
<kdubious> ok
<oneinsect_> i wish i had talked to you guys before buying
<Amit_T> ssvb : I have connected USB plug to host machine's USB socket
<tkaiser> Amit_t: To ensure 500mA max?
<NiteHawk> kdubious: if you compiled u-boot yourself, either go back to v2016.01 or use latest master
<Amit_T> ssvb: Yes its right
<ssvb> Amit_t: then you indeed do not have enough power, this explains the failures under load
<ssvb> Amit_t: if you have a powered usb hub in house, then you may have a better success with it
<KotCzarny> or just connect to 5v in pc molex ;)
<ssvb> Amit_t: but it's best to buy a 2A or 3A capable power supply :-)
avph_ has joined #linux-sunxi
<wens> kdubious: 0x00 on all phy ids means the mdio bus pull-ups aren't enabled
avph has quit [Read error: Connection reset by peer]
avph_ is now known as avph
<wens> so you are probably missing some regulator setting
<kdubious> ok, we're looking...
<Amit_T> ssvb : I also have this DC 5V 2.1 A connector where there are two USB socket
<ssvb> Amit_t: that would be a perfect choice
<Amit_T> Shall I try with it
<Amit_T> but its 2.1 A , is it ok
<ssvb> yes, unless it is some kind of "smart" charger
<NiteHawk> wens: i've seen that MII weirdness with an A20 device from commit c32a6fd up to fc8991c in mainline u-boot. recent changes broke things there
<KotCzarny> perfect choice would be meanwell rd-65a or similar ;)
<lvrp16> if anyone needs an orange pi board, please let me know and i will mail you one
<lvrp16> along with a power supply if you need it
Nacho has quit [Quit: No Ping reply in 180 seconds.]
Nacho__ has joined #linux-sunxi
<Amit_T> ssvb: This is how I am using power supply http://picpaste.com/IMG_20160408_224801404-XVx5uzm0.jpg
<Amit_T> Black wire from my host to opi is power supply and white one is for FEL
afaerber has quit [Quit: Ex-Chat]
<ssvb> Amit_t: the laptop USB port can only supply 500mA, this is way below what the board may consume under load
<KotCzarny> ssvb: depends on the laptop
<KotCzarny> but yeah, expecting more than 500mA is a lottery
<ssvb> Amit_t: there is a reason why the Orange Pi PC board can't be powered via the Micro-USB OTG port, they specifically designed it this way to avoid accidents
<oneinsect_> lvrp16:
<oneinsect_> what location is it in?
<Amit_T> ok
<oneinsect_> you can mail me one
<ssvb> KotCzarny: I would say that laptops are usually pretty strict about the USB ports current limit, just because they are battery powered themselves
<ssvb> KotCzarny: but yes, it is not uncommon for the desktop computers to supply more than 500mA
<KotCzarny> ssvb: unless usbadapter+1A rated hdd lie, thinpads were working fine, even when pcs didnt start the disk
<KotCzarny> *thinkpads
<Amit_T> ssvb: This is DC 5V 2.1 A connector I was talking about http://picpaste.com/IMG_20160408_225858479-G8ZGdt6x.jpg
<ssvb> Amit_t: this should be good, try it
<lvrp16> oneinsect_ check ur pm
<Amit_T> ok but I have only main power supply socket here where laptop is connected(Laptop is running directly without battery) :( , I would buy an extension and try
clonak has quit [Ping timeout: 240 seconds]
<Amit_T> *only one main power socket
clonak has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
<oneinsect_> tkaiser:
<oneinsect_> which board you suggest in orange pi
<oneinsect_> the one which has dynamic voltage regulator
uwe_ has quit [Ping timeout: 264 seconds]
jernej has quit [Quit: Konversation terminated!]
<tkaiser> oneinsect_: Orange Pi PC/2/Plus use the same SY8106A regulator. This is my favourite since I like chips that stay cool when idle
<oneinsect_> thanks
<kdubious> NiteHawk: => mii info
<oneinsect_> i will probably try to port alpine linux to orange pi then instead of nanopi
<kdubious> PHY 0x00: OUI = 0x0732, Model = 0x11, Rev = 0x05, 1000baseT, FDX
<ssvb> tkaiser: cool when idle? does it matter much?
<kdubious> wens: we went back to 2016.01 and I have new values for "mii info"
<NiteHawk> kdubious: should be fewer (likely only 2) - does "dhcp" work now?
<tkaiser> ssvb: Apple MacBooks from 2012 or more recent supply 900mA on the USB ports. And no, idle temp doesn't matter that much but I like it ;)
<kdubious> yes...
<ssvb> tkaiser: the fixed voltage regulator makes the boards less power efficient at lower clock frequencies (when under heavy multithreaded workload and throttling)
<kdubious> 2 items listed, and DHCP works in u-boot
<tkaiser> ssvb: Yes, and this is one of my use cases. Downclocking them to 648 MHz max
<kdubious> NiteHawk: going to try to boot without UART now
<NiteHawk> kdubious: okay, then you got bitten by that sunxi regression, and are now back to the expected behavior
<ssvb> tkaiser: even running with a performance governor does not affect the idle power consumption and temperature much
<kdubious> Hoping that fixes my kernel issue, too
<kdubious> but seems unlikely
<tkaiser> ssvb: You mean with fixed voltage it doesn't affect it that much?
<NiteHawk> kdubious: that's possible, assuming that the kernel doesn't touch the regulators / voltage enable for the PHY again
<ssvb> tkaiser: well, the idle power consumption gets higher at higher voltage but is still quite reasonable (of course IMHO)
klarrt has quit [Ping timeout: 240 seconds]
<ssvb> tkaiser: I don't like the ondemand or interactive governors because they make the system less responsive
<tkaiser> ssvb: I agree on ondemand but interactive is quite fine. And when using 'wrong' settings (loboris) the difference when idling between interactive and performance was a whopping +10¡C
<tkaiser> ssvb: 1.3V vs. the insane 1.5V
<ssvb> 1.5V is just broken
<ssvb> this is not a very representative comparison :-)
uwe_ has joined #linux-sunxi
<tkaiser> ssvb: Sure, but with OPi PC/2/Plus it makes still a difference compared to BPi M2+ with fixed voltage. And throttling behaviour (starting way earlier) is another thing
<kdubious> NiteHawk: I think the kernel does config the regulators via the dts file, right?
Gerwin_J has joined #linux-sunxi
<tkaiser> ssvb: BTW: Tried out SinoVoip's Raspbian today with BPi M2+ and Moronix Test Suite. First test killed cpu3, second cpu2 and THS settings limit max cpufreq to 1008 MHz. They seem to test their software not that much
<ssvb> tkaiser: SinoVoip, OLIMEX, Xunlong and even PINE64 are not very good with the software
<NiteHawk> kdubious: that's how it should work, given that the kernel has the appropriate information for all regulator nodes - i can't tell what the status of itead-based boards is there
<tkaiser> ssvb: Pine64 does software?
<willmore> I need to order a tube of heatsinks for these boards. Wish I owned an end mill.
<ssvb> tkaiser: well, I'm not sure
<ssvb> tkaiser: maybe I misunderstood some forum messages
<kdubious> NiteHawk: is there a way to see the mii settings in kernel?
<tkaiser> ssvb: They added a desktop environment to longsleep's first Arch image and get Android from Allwinner I would suppose.
klarrt has joined #linux-sunxi
<tkaiser> ssvb: But doesn't matter anyway. Results look better compared to Xunlong and SinoVoip
<NiteHawk> kdubious: that's a good question. unfortunately, i don't know the answer - maybe wens knows that?
<willmore> How far is the H3 from having a useable headless mainline? Seems almost done from what I've read.
<kdubious> wens: i solved the u-boot dhcp failure by falling back to 2016.01. but I have the same issue in kernel.
umiddelb has joined #linux-sunxi
<kdubious> I only get an IP if the serial UART is connected during power up
<tkaiser> megi: This time I tried your OPi PC branch directly and it doesn't work either: core: _opp_supported_by_regulators: OPP minuV: 980000 maxuV: 980000, not supported by regulator
megi has quit [Ping timeout: 276 seconds]
<tkaiser> cpu cpu0: _opp_add: OPP not supported by regulators (408000000)
<tkaiser> Unable to handle kernel NULL pointer d%reference at virtual address 00000000
<ssvb> tkaiser: are you trying to undervolt your board?
Amit_T has quit [Quit: Page closed]
<tkaiser> ssvb: LOL, no I try out megi's dvfs/cpufreq/SY8106A stuff: https://github.com/megous/linux/commits/orange-pi-pc
<tkaiser> IMO that's the missing piece to use H3's headless with mainline kernel
<ssvb> 980mV seems to be a rather low voltage
<tkaiser> ssvb: Yes, but it works. We set this in Armbian more or less by accident for 3.4 kernel and no one complained so far
<willmore> tkaiser, yay! Go, megi!
<ssvb> tkaiser: the Allwinner's FEX file lists 1040mV as the minimum voltage and the H3 datasheet even has 1100mV as the recommended minimum for VDD_CPUX
<tkaiser> IIRC I asked Igor to take your settings as I did in the fix-thermal-issues.sh script known from Orange Pi forums.
<ssvb> we probably need to confirm what is the default CPU clock frequency after reset on H3
<ssvb> because we need to be sure that this default reset CPU clock frequency can work reliable with the lowest DVFS voltage
<ssvb> or people may encounter deadlocks after pressing the reset button :-)
avph has quit [Ping timeout: 246 seconds]
<tkaiser> ssvb: Ah, good to know. As a related note: megi has also an u-boot branch where he sets rather high values: https://github.com/megous/u-boot/commit/e43b43009667d48becd97d1bd43dfa23c7646ed4
klarrt has quit [Ping timeout: 248 seconds]
<tkaiser> But since he left, I will leave too for a few beers now :) Cheers
<willmore> Enjoy!
<ssvb> tkaiser: ouch, these U-Boot settings do not look reasonable, one may encounter troubles when booting a kernel without DVFS and thermal throttling support
<tkaiser> ssvb: Sure. I didn't applied these. He ran in a lockup issue and tweaked some clock settings and said this was essential to avoid the lockup
<ssvb> just boot a wrong kernel, run something heavily multithreaded and your board is fried
avph has joined #linux-sunxi
<tkaiser> I will open an issue and discuss this tomorrow. But I still want to test this stuff out (not the high values in u-boot but whether dvfs/cpufreq work with H3 on OPi PC)
pmattern has joined #linux-sunxi
<NiteHawk> kdubious: check "dmesg | grep eth" for output related to PHYs. e.g. my banana pi has
<NiteHawk> [ 1.204894] stmmaceth 1c50000.ethernet: no reset control found
<NiteHawk> [ 1.258365] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
<NiteHawk> [ 1.271139] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
<NiteHawk> [ 20.005245] stmmaceth 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
<NiteHawk> it reports the first PHY as active and the correct link speed a bit later / further on
<kdubious> NiteHawk: [ 0.943047] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
<kdubious> [ 0.949395] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01)
<kdubious> [ 15.100636] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
<kdubious> [ 0.907351] sun7i-dwmac 1c50000.ethernet: no reset control found
<kdubious> you have stmmaceth & I have sun7i-dwmac
klarrt has joined #linux-sunxi
<NiteHawk> kdubious: hmm... iirc one is the gbit version (sunxi "gmac") and one the soc-internal 10/100 mbit ("emac"). but i'm no expert there
khuey is now known as khuey|away
kdubious has quit [Ping timeout: 250 seconds]
tkaiser has quit [Ping timeout: 260 seconds]
kdubious has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<NiteHawk> kdubious: what's your kernel version? i'm using an older 4.1.6 one.
<kdubious> 4.5
megi has joined #linux-sunxi
<tkaiser> kdubious: IIRC montjoie said Ethernet with A20/4.5 would be broken
apritzel has joined #linux-sunxi
<montjoie> and in rc2 it workd
<kdubious> tkaiser: did it (does it) work in 4.4?
<kdubious> I have a very strange case... where it works ONLY if UART is connected during power up
<montjoie> oups rc3 in fact
<kdubious> montjoie: 4.5 rc3 has working Ethernet on A20?
<lennyraposo> hey umiddelb
<tkaiser> kdubious: It works with 4.4.6. In Armbian we reverted back to u-boot 2016.01 for sun7i and skip 4.5 at the moment. Everything working
<tkaiser> kdubious: I missed it. Which device do you use?
<kdubious> ok... oddly, I've got an AW-SOM board working with 4.5.0-rc1
<kdubious> and the one with the issue is the ITEAD CoreEVB
<kdubious> with AW2041 SOM
<kdubious> I get an IP if I power up with UART connected... otherwise, the device never creates network signals
<tkaiser> Sounds funny :)
<kdubious> sounds funny... but in reality, it's pull-your-hair-out-painful
<NiteHawk> kdubious: btw - our wiki only has http://linux-sunxi.org/Itead_Iteaduino_Plus , would be nice if you eventually find some time and add the core evb there
<kdubious> I started to, then somoene deleted it
<NiteHawk> oh
<kdubious> then I added it back... http://linux-sunxi.org/ITEAD_CoreEVB
apritzel has quit [Ping timeout: 244 seconds]
<willmore> kdubious, If you connect the serial later, does the ethernet start working?
<kdubious> no, it doesn't
<kdubious> has to be connected during power up, or it never works
<kdubious> even power up > connnect UART > reboot... fails
<willmore> What about a warm restart?
<willmore> Ok.
<willmore> You got ahead.
cosm_ has quit [Quit: Leaving]
<kdubious> trying the reset button now...
<kdubious> reset button also fails
yann|work has joined #linux-sunxi
<kdubious> power up > connect uart > reboot > u-boot > dhcp:
<kdubious> Speed: 1000, full duplex
<kdubious> ... then fails
<kdubious> UART > power up > u-boot > dhcp:
<kdubious> ethernet@01c50000 Waiting for PHY auto negotiation to complete........ done
<kdubious> Speed: 1000, full duplex
<kdubious> DHCP client bound to address (18 ms)
megi has quit [Ping timeout: 276 seconds]
mossroy has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<kdubious> so even u-boot seems to fail if I don't first connect the UART.
<kdubious> although the only way to test this requires that I first boot to the kernel, then reboot and look at u-boot
<willmore> Are you hooking up just the boards TX line to your terminal or are you hooking up both TX and RX?
<NiteHawk> i still suspect some regulator not being initialized properly, and the uart providing enough 'parasitic' current to somehow get things working
<willmore> NiteHawk, that's why I asked about RX. If it's TX only, then there shouldn't be any meaningful leakage.
<NiteHawk> ah, i see
<willmore> Also, could be a grounding issue.
<kdubious> willmore... usually, I'm hooking up both
<kdubious> but, I did find that if I connect both (and not ground).. it works
<willmore> Okay, the concern is that TX to the board could supply some power to some part of the SoC that makes things work.
<kdubious> if I connect only tx and ground, it works
<willmore> That's TX *from* the board?
<kdubious> if I connect only RCV & GND, it fails
<kdubious> yes... TX & RCV relative to the board
<kdubious> sorry... let me think
<willmore> That seems backwards.
<kdubious> willmore: if the board TX & GND only, it seems to have just worked
<kdubious> I could see the screen from the UART session, but cannot send it data
<kdubious> and I have an IP
<willmore> That makes very little sense.
<willmore> Did you try ground only?
<kdubious> now I powered up, unable to see the screen... and I still get an IP???
<kdubious> now I powered up and nothing is connected... just Eth & DC barrel... no IP
<willmore> What about ground only?
<kdubious> I'll try....
<NiteHawk> kdubious: have you tried testing against a 100mbit/s network connection? we've seen cases where gbit networking was unreliable for some devices (GMAC_TX_DELAY comes to mind)
<kdubious> NiteHawk: is it sufficient to set my switch's port to 100?
<kdubious> I don't have a hardware 100Mbps, but my switch can be configured
<kdubious> willmore: booting w/ only GND failed to get an IP
<NiteHawk> kdubious: should do. try it and see if your SOM reports back the lower link speed
kdubious_ has joined #linux-sunxi
kdubious__ has joined #linux-sunxi
<NiteHawk> attack of the clone warriors?
<kdubious__> sorry.... that boot crashed my pc. (I write my putty logs to disk)
<willmore> So, GND only fails. RX/GND fails. TX/GND works. TX/RX/GND works.
kdubious_ has quit [Client Quit]
<kdubious__> willmore: let me verify
kdubious has quit [Ping timeout: 250 seconds]
<kdubious__> this time... TX + GND failed. (TX from Device Perspective)
<willmore> This is getting screwier and screwier.
<kdubious__> GND + RX = success
<willmore> Okay, that makes sense.
<willmore> That supports the power leakage theory.
jstein has joined #linux-sunxi
<kdubious__> in 100% of my tests.. GND + RX + TX = success
<kdubious__> and 95%: no UART = FAIL
<willmore> Okay. Sounds like power leakage.
<longsleep> [
<longsleep> sorry
<kdubious__> willmore: ideas to solve it? Or am I doomed to use another board?
oneinsect_ has quit [Ping timeout: 250 seconds]
<willmore> kdubious__, what was the board?
<kdubious__> ITEAD CoreEVB + AW2041 SOM
tsuggs has quit [Ping timeout: 246 seconds]
<kdubious__> they say 7v - 23v in, I'm using 12v.
<NiteHawk> kdubious__: did you try their support forum or even contact them directly? maybe they can point you to a solution if it's a known problem
<willmore> kdubious__, Looking at the boards.... Where is the serial header?
<kdubious__> I've tried them, no success
<kdubious__> on the "side connector"
<willmore> Okay.
<willmore> Without schematics, it's hard to tell you much more. Sorry.
<kdubious__> connector J4: pins 9 & 10, plus GND on 29
<willmore> Looks like most of that connector goes right to the daughter board.
<kdubious__> I have access to the schematics... but sounds like that's a bigger project than helping me on IRC
<willmore> Oh, wow. Okay, I don't know if I have Eagle on anything around here anymore. Let me look into that.
<willmore> I used to have the eurocard license for it..... Back when you got your software on floppies....
<kdubious__> I think KiCAD works
megi has joined #linux-sunxi
vagrantc has quit [Ping timeout: 250 seconds]
vagrantc has joined #linux-sunxi
<willmore> kdubious__, those schematics aren't complete. :(
<kdubious__> really?
<willmore> Yeah, it's just for the carrier.
<kdubious__> ahh.
<kdubious__> not the module
<willmore> Yep. Not the modules.
fredy has quit [Excess Flood]
pmattern has quit [Quit: Genug für heute.]
<kdubious__> I can only find teh EVB on their repo:
<kdubious__> Wait.. pdfs are here:
mzki has joined #linux-sunxi
fredy has joined #linux-sunxi
JohnDoe9 has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<kdubious__> willmore: does that show you what you need?
ricardocrudo has joined #linux-sunxi
<kdubious__> The u-boot sun7i-a20.dtsi shows uart5_pins PI10, PI11
<kdubious__> and on the SOM shematic, it shows those pins as SPIO-CS and SPIO-SCK
<kdubious__> is that meaningful?
<kdubious__> Another difference: clk_out_a_pins_a: clk_out_a@0 { allwinner,pins = "PI12"; clk_out_a ... in the dts, and on the schematic:
zuikis has left #linux-sunxi [#linux-sunxi]
<kdubious__> PI12 = SPIO_MOSI, PI13 = SPIO_MISO
<kdubious__> the dtsi shows PI13 as: clk_out_b_pins_a: clk_out_b@0 { allwinner,pins = "PI13"; allwinner,function = "clk_out_b";
<mripard> kdubious__: every pin can be used for several functions
<mripard> it's up to the board designer which one is used on that particular board
<kdubious__> ok, I understand that... I'm working on an issue where I do not get Eth0 traffic unless I power up with a UART attached
<kdubious__> more precisely, I need the device RX & GND connected to my PC's USB in order for DHCP to work. Otherwise, no network traffic.
<kdubious__> I'm not very familiar with DTS, so I'm trying to find possible anomalies with the "standard" and my board
<mripard> werid
<kdubious__> yeah, painfully weird
<mripard> does it also happen with 3.4?
<kdubious__> took a long time to figure out that this is what was going on
<kdubious__> yes.. I had an issue with 3.4, too
<kdubious__> so I abandoned the project a while back... then picked it up when I was able to get help with I2S on the mainline kernel, and my Eth0 worked "most" of the time
<kdubious__> but now I see that it works if I connect the UART, and it works sometimes without the UART.... (in my chassis, with other compnentes alos connected)
<kdubious__> but in the most simple version... no UART at power up = Eth0 fails. Even if I later connect the UART
khuey|away is now known as khuey
<kdubious__> mripard: any ideas?
<kdubious__> I'm working from a potentially good FEX from the manufacturer, and a DTS created with much help
tkaiser has quit [Ping timeout: 260 seconds]
<kdubious__> Also notable on my shcematic: ETH MII/GMII... no mention of RGMII
<kdubious__> but I don't think it could be GMII
tsuggs has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
tkaiser has joined #linux-sunxi
<willmore> kdubious__, sadly, I don't see it in there. sorry.
tsuggs has quit [Ping timeout: 250 seconds]
<willmore> Hmm, after reading here, let me look again.
<willmore> kdubious__, Nope, it just goes straight through, I don't see any ESD on it. That could have bled backwards into a power run, but I don't see it.
<willmore> Your serial USB adapter is 3.3V?
<willmore> If so, try this. Find a 3.3V supply run on the board and hook it to the RX on the board. See if the board can power itself.
<kdubious__> yes... the adaptor is 3.3
<kdubious__> wall power > device | 3.3v out > UART-RCV?
<willmore> 3.3V on the board to the RX on the board. Board stands alone.
<kdubious__> it needs external power... right?
<willmore> Power the board however you normally power it. Just jumper the RX pin on the board to a 3.3V supply on the board.
tsuggs has joined #linux-sunxi
<kdubious__> that worked
<kdubious__> wtf?
p1u3sch1_ has quit [Ping timeout: 260 seconds]
<kdubious__> willmore: is this just crazy?
<willmore> Looks like there is either a break somewhere on the board or they just did the power wrong.
mossroy has quit [Quit: Quitte]
p1u3sch1 has joined #linux-sunxi
<kdubious__> I need to step away for a little bit... I'd love to know if there is a way to "fix" this through DTS, etc. This seems like a very odd hack to me...
Netlynx has quit [Quit: Leaving]
<willmore> I'm not sure how. I don't know how the different voltages in the A20 are managed. You'd need someone with a pretty deep understanding of the chip.
<kdubious__> ok, thanks for hanging in there with me
<willmore> At least for now you have a working board.
<kdubious__> yeah... any repurcussions from this that you can think of?
<willmore> No problem. Glad to help. I'm not much use on the software yet, so I might as well get some use out of hardware knowledge. :)
<willmore> Yes, you're feeding power into a pin not meant to take it to backpower some system that's not running right. You could blow the board with time.
<willmore> Have you tried reseating the card in the carrier recently?
<willmore> That seems unlikely as the power generation for the SoC is on the daughter card and the SoC is directly connected to them, so there shouldn't be anything going over the edge connector that should effect this.
<kdubious__> I'll try to reseat it.. but this happened on 3 boards with 3 cards
<willmore> Okay, then it sounds like a design problem.
<kdubious__> I'm wondering if maybe I only need this on boot... then I can kill it.
<willmore> That seems likely. It very well could be a power supply sequencing issue. This might only be providing power for a very short time period.
reinforce has quit [Quit: Leaving.]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
kdunious has joined #linux-sunxi
kdubious has joined #linux-sunxi
<kdubious> anyone know how i woukd control the chip's psu at boot?
kdunious has quit [Ping timeout: 250 seconds]
kdubious__ has quit [Ping timeout: 250 seconds]
kdubious has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 246 seconds]
mzki has quit [Quit: leaving]
megi has quit [Ping timeout: 264 seconds]
tsuggs has quit [Ping timeout: 276 seconds]
kdubious has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
<wens> NiteHawk: stmmac was librarized sometime ago, so the new driver is sun7i-dwmac, calling into stmmac
<kdubious> wens: I'm getting closer....
<kdubious> with uart connected, eth0 works fine... but only if UART is connected at power up
<kdubious> it was suggested that I try connecting 3.3v to UART RCV
<kdubious> that also makes eth0 work
<kdubious> ...but I'm sure that's not appropriate
<kdubious> so... any idea what could be wrong on the software side?
<NiteHawk> wens: thx. i guess i'll have to leave stable behind and catch up with bleeding edge on mainline kernel ;)
<wens> coreevb pdf is not searchable :(
<kdubious> maybe I can find it... what are you looking for?
<mripard> kdubious: was it working at some point?
<kdubious> not ever reliably
<kdubious> I've had it connected to UART, or to my I2S send board, and it often works
<wens> there's no proper external pullups on the mdio and mdc lines
<wens> mdio access to the phy won't work reliably
<kdubious> but now that I've gotten very methodical about this, I see that applying 3.3v to UART-RCV seems to make it work 100% reliably
<kdubious> wens: are you looking at File: gmac.sch Sheet: /gmac/
<wens> i can only look at pdfs
<wens> and the pdf does not show pull-ups
<kdubious> yes... date on the pdf page is 10 sep 2014?
<kdubious> oops... 19 sep 2014
<kdubious> Is there anything I can do? Or is this an issue only ITEAD can fix?
<wens> you can try enabling internal pull-ups in the pinctrl
<wens> though i don't know if that is strong enough
<kdubious> ok.. u-boot, kernel, or both DTS files?
<kdubious> (I assume both)
<kdubious> [ please be gentle, this is all relatively new to me ]
<wens> for kernel it's done in the dts
<wens> for u-boot... you need to add code
<kdubious> ok.. personally, I only care about eth0 in the kernel, i'm booting from sd
<wens> you can check the uart pull-ups, in board/sunxi
<wens> kdubious: ok, so with uart or i2c or mmc, a few dts enable the pull-ups for them
<wens> basically it's adding "allwinner,pull???? = PULL_UP" to the gmac pin node you are using
<kdubious> this is from my kernel DTS:
<kdubious> &gmac {
<kdubious> pinctrl-0 = <&gmac_pins_rgmii_a>;
<kdubious> phy = <&phy1>;
<kdubious> phy-mode = "rgmii";
<kdubious> phy1: ethernet-phy@1 {
<kdubious> reg = <1>;
<wens> add &gmac_pins_rgmii_a { allwinner,pull = <SUN4I_PINCTRL_PULL_UP>; }; somewhere to the dts
<kdubious> I think: <&gmac_pins_rgmii_a> is in the sun7i-a20.dtsi... right?
<kdubious> OK, so a setting here overrides settings in teh files that are referenced?
<wens> yes
<wens> which is what &gmac { ... } does
<kdubious> ok, then compile the DTB and try it?
<wens> yeah
<willmore> kdubious, I'll hit you up later as I have some I2S work to do. :)
<kdubious> nice...
<kdubious> i got i2s on the mainline working recently myself... so nice
<kdubious> thanks, willmore
<willmore> I have some nice 192k/24 ADCs that I want to use some day for SDR.
<willmore> No problem, I hope wens helps you get this sorted for good. My backfed power thing was just a hack.
<wens> do we have an i2s driver already?
<wens> i won't be around later today though
<wens> wrapping up the conference i'm at and catching a flight home
<kdubious> sort of...
<kdubious> I had some specific needs (32 bit word size)
<kdubious> and worked with some folks to cobble together a working dai, driver, sound card, etc.
<kdubious> PULL_UP doesn't seem to have worked
<kdubious> but I want to verify I did it right, so I'm trying again
<kdubious> does the gmac pins line need to come before the $gmac section?
<wens> no
<kdubious> 40 milliamp, right? anything else I can try to tweak? or is this a hardware issue now?
<wens> likely a hardware issue
<wens> you can check other board schematics
<wens> normally you have pull-ups on mdio/mdc, as it is an open-drain bus
<kdubious> if I force the phy-mode to mii (instead of rgmii), same issue?
<wens> phy-mode must match the hardware you are using
<wens> mismatch == can't understand signal
<kdubious> ok
<kdubious> and does the hack make sense... connecting 3.3v to UART-RECV makes it work?
<wens> i have no idea
<kdubious> ok