<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]
<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
<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
<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
<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>
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]
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
<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)?
<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]
<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
<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) ?
<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
<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 ;)
<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?
<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.]
<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
<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
<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?
<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 :-)
<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
<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 10.10.10.113 (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?
<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.