ganbold_ has quit [Read error: Connection reset by peer]
ganbold has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
TheSeven has quit [Ping timeout: 244 seconds]
TheSeven has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 240 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 264 seconds]
<wens>
anyone with an orange pi pc plus on hand? seems I got the polarity of the ethernet LEDs wrong
<KotCzarny>
is opipc also okay?
<wens>
opipc looks correct (at least mine does)
<wens>
at 100 Mbps the yellow led should be lit, and the green one flashes with traffic
<KotCzarny>
hrm, my opipc+ is in another location apparently
Asara has quit [Read error: Connection reset by peer]
Asara has joined #linux-sunxi
netlynx has joined #linux-sunxi
random_yanek has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
<montjoie>
wens: I got one
<montjoie>
does someone know if I can power a nanopim1+ via headers ? the microusb power is half unsolder
reinforce has joined #linux-sunxi
<wens>
montjoie: could you check the ethernet leds on both the opipc and opipc+ ?
sunshavi has quit [Ping timeout: 258 seconds]
<montjoie>
I dont have a opipc+ only opipc, I will check this morning
sunshavi has joined #linux-sunxi
cmeerw has joined #linux-sunxi
libv has quit [Read error: Connection reset by peer]
libv has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
hlauer has joined #linux-sunxi
kaspter has joined #linux-sunxi
AneoX has quit [Ping timeout: 258 seconds]
AneoX has joined #linux-sunxi
[TheFreeman] is now known as [Psycholog]
gediz539 has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 258 seconds]
lkcl__ has joined #linux-sunxi
yann has joined #linux-sunxi
lkcl_ has quit [Ping timeout: 246 seconds]
ldevulder_ has joined #linux-sunxi
[Psycholog] is now known as [ToorisT]
ldevulder has quit [Ping timeout: 256 seconds]
dev1990 has joined #linux-sunxi
<karlp>
I have one, and yes, both leds ar eon with nothing connected..
<karlp>
that's on an armbian kernel from a month ago or so, let me check
<karlp>
green is doign activity correctly when plugged in though
<karlp>
and 100M, this is 5.4.45? have there any relevant changes since then?
<KotCzarny>
keep in mind armbian has some patches
florian has joined #linux-sunxi
<karlp>
where even is it in device tree?
<karlp>
I've just done the "dtc -I fs -O dts /sys/firmware/devicetree/base" wiggle and there's nothing like it defined.
ldevulder_ is now known as ldevulder
tnovotny has joined #linux-sunxi
juri_ has quit [Ping timeout: 260 seconds]
juri_ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
warpme_ has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 265 seconds]
reinforce has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
niceplaces has joined #linux-sunxi
niceplace has quit [Ping timeout: 246 seconds]
kaspter has quit [Quit: kaspter]
arti_ is now known as arti
tuxillo has quit [Remote host closed the connection]
tuxillo has joined #linux-sunxi
deesix has quit [Ping timeout: 258 seconds]
dddddd has quit [Ping timeout: 264 seconds]
<martinayotte>
montjoie:my NanoPiM1+2 is powered via 5V GPIO header since months ...
<montjoie>
according to the datasheet, all VDD in the header are output only
<montjoie>
anyway the urgent "give cartoons to child for still working" was fixed with a potato, solder dc barrel will wait
dddddd has joined #linux-sunxi
deesix has joined #linux-sunxi
<martinayotte>
According to the file NanoPi-M1-Plus-1702-Schematic.pdf I have, all VDD_5V are connected together.
<montjoie>
I fear to destroy it
<KotCzarny>
they are cheap
<KotCzarny>
and sdcard should work just by simply swapping devices (and dt/uboot)
<montjoie>
I am stingy and dont want to buy new devices:)
<martinayotte>
montjoie: Don't get fear, simply download schematic :-)
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #linux-sunxi
<mripard>
MoeIcenowy: do you know to which regulator the pinephone 1.0 backlight is wired?
<mripard>
the DTS is missing the power-supply property (and I assume the brightness levels)
lurchi_ is now known as lurchi__
<willmore>
montjoie, I'm looking at the M1+ schematic and it looks like it's just fine to power it from the GPIO. As usual, it has no reverse polarity protection there, so be careful.
* willmore
wonders how many stupid things you have to do to get the polarity wrong on a micro-USB cable.....
<willmore>
But they always reverse polarity protect *those*.
<willmore>
Sure, do it for a generic input like a barrel connector, but an inherently polarized connector like USB? *shakes head*
<mru>
I have a prototype board somewhere with all the usb pins reversed
<willmore>
I guess that answers the question "how many stupid things". :)
<mru>
but only three of them were made
<willmore>
I've seen too many 'push the top layer copper to the bottom without flipping it' mistakes. Was it something like that?
<mru>
they changed the usb connector for another one and didn't notice that the pins were reversed
<willmore>
They used to make certain chips--generally memories--in reverse pinout packages. It started because someone screwed up a board, but it became a sort of common thing because it makes double sided board layouts easier.
<willmore>
Ouch.
<mru>
vertical type A
<willmore>
back to front, side to side.
<mru>
the pins can be on either the "left" or the "right" side
<willmore>
Yep. Makes sense.
<willmore>
But that's going to be an A connector, right?
<mru>
right
<mru>
see above :)
<willmore>
So you would kill the device plugged into your board. That's SEP, then.
kaspter has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<mru>
if said device has reverse polarity protection, it'll be fine
<willmore>
Unless they do so by using the reverse biased diode trick. Then someone had better have a fuse or something will become one.
<mru>
or the diode will blow up, shortly followed the thing it was meant to protect
<willmore>
Like these little SBCs that hard wire their 5V supply to the USB power line. Don't do that. Put a proper power controller on there so overcurrent can be detected and power can be shut off.
<willmore>
mru, could be that, too. Hopefully they sized the trace leading to the diode to be a fuse.
<mru>
a zener and a thermal polymer fuse can be used to good effect
<willmore>
Yep, polyfuses are very nice.
<mru>
then you get both overvoltage and reverse polarity protection
<willmore>
But you can get a voltage drop over the poly at higher currents.
<willmore>
And once tripped, their base resistance goes up and never recovers.
<mru>
not until the bad voltage is removed
<willmore>
It improves from the 'tripped' stage, but it never goes back to the 'like new' value.
<mru>
if it's feeding a regulator, a slight voltage drop probably isn't a problem
<willmore>
True, but if you're using a crappy micro-USB connector to get power and a low gauge USB cable.... It all adds up. Or subtracts in this case.
<karlp>
"just don't hold it wrong" ;)
<willmore>
karlp, that was my initial idea.
<willmore>
Stop hooking wires up wrong. :)
<mru>
MAX4866L is a slightly more expensive option
<willmore>
Those are very nice, but would be better if they had current limits as well.
Igelritter has joined #linux-sunxi
lurchi__ is now known as lurchi_
<mru>
that's a different problem
cnxsoft has quit [Quit: cnxsoft]
<mru>
voltage/polarity protection saves the downstream parts from blowing up if someone connects the wrong power supply
<mru>
current limiting saves the power supply if someone connects a bad load
<mru>
I imagine that maxim device would typically be sat in front of a regulator
<mru>
at least that's how I've used it
<karlp>
you're building fancy hw though ;)
libv has quit [Read error: Connection reset by peer]
<mru>
and the regulator has built-in current limit
<karlp>
just keyed connector and call it good, remove parts for great bom glory
libv has joined #linux-sunxi
<mru>
you don't know where I used that chip
<mru>
but needless to say, there were more expensive things behind it
kaspter has quit [Ping timeout: 258 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<karlp>
exactly :)
vagrantc has joined #linux-sunxi
[CaughtNabz] is now known as [MuhaDib]
gediz539 has quit [Quit: Leaving]
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
Igelritter has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
<montjoie>
willmore: for reverse polarity story, I created a beautiful adapter, well solder (for me very rare), well protected and.... the machine which need it was the only DC barrel I know with + oustide
<mru>
I have a few gadgets with tip negative barrel inputs
<mru>
bloody annoying
florian has quit [Ping timeout: 258 seconds]
<vagrantc>
making vaguely compatible things incompatible since the dawn of the consumer age
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 256 seconds]
Igelritter has joined #linux-sunxi
merbanan has quit [Ping timeout: 256 seconds]
lkcl_ has joined #linux-sunxi
lkcl__ has quit [Ping timeout: 258 seconds]
libv has quit [Read error: Connection reset by peer]
libv has joined #linux-sunxi
hlauer has quit [Ping timeout: 240 seconds]
merbanan has joined #linux-sunxi
<willmore>
mru, if you want to get fancy on that next design, put in one of Linear Technology (Analog Devices now) "Ideal Diode Bridges". You need four mosfets with the little controller, but it'll rectify any input polarity with very little voltage drop (two MOSFET drops).
<willmore>
Tip negative people deserve to be put in a metal *grounded* cage.
<willmore>
Go ahead, drop that connector. Let's see how much you like shorting things out.
<mru>
yeah, I know of those devices
<willmore>
I'd like to see one of those with the mosfets built in for this application.
<willmore>
I assume the process they use to make them is amenable to good MOSFET designs.
<mru>
at least they make packages with two mosfets
<willmore>
I'm sure they could co-package some MOSFETs if they couldn't put the on the same die.
<karlp>
maxim's ADI too now..
<mru>
oh right
<willmore>
Well, that's all the good analog chip makers.
<willmore>
Well, onsemi, I guess.
<mru>
ti/national?
<willmore>
Oh, yeah, ti. Which reminds me, I need to ask a question of a friend of mine who workes there.
kaspter has joined #linux-sunxi
libv has quit [Read error: Connection reset by peer]
libv has joined #linux-sunxi
<mru>
friends at TI can be useful
kaspter has quit [Quit: kaspter]
<willmore>
He's been there for 25 years, I hope he knows a few people by now. :)
<willmore>
Darn, he doesn't have any idea. He's never seen anything like it. I wonder if I should offer it to bunny and see if he wants to use it for his "Name that Ware" contest.
tuxillo has quit [Ping timeout: 256 seconds]
lurchi_ is now known as lurchi__
tuxillo has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 265 seconds]
andy25225 has quit [Ping timeout: 258 seconds]
andy25225 has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
<hexdump0815>
jernej: as promised - fresh dump - https://pastebin.com/raw/bAVpN1cy ... looks like at the initial one really something went wrong as the value you mentioned is different now
xes_ has quit [Read error: Connection reset by peer]
<jernej>
hexdump0815: that looks better, thanks!
<jernej>
hexdump0815: just one more request, if you still have HW ready, can you set frequency to 840 MHZ? that way frequency dependent values would be same as dump with libdram
<hexdump0815>
jernej: i'm here now and can try whatever you want :)
<jernej>
well, if you really have time, you can try to minimize that patch :)
<hexdump0815>
that was my plan :) ... you mean CONFIG_DRAM_CLK=820?
<hexdump0815>
with tcke reverted it still boots ... next round ...
<hexdump0815>
without udelays: still booting ... next round ...
juri_ has quit [Ping timeout: 256 seconds]
<jernej>
thanks, now the dump is really similar, much easier to compare
<jernej>
from the dump, I see that trrd is calculated differently between libdram and mainline
<hexdump0815>
just reverted trrd - still booting
mcerveny has joined #linux-sunxi
<hexdump0815>
txp reverted - still booting ... only mr_ddr3 and the "clrsetbits_le32(&mctl_phy->pgcr[2], GENMASK(17, 0), ns_to_t(7800 * 2));" line in dram_sun50i_h6.c left
<hexdump0815>
mr_ddr3 reverted - still working
<hexdump0815>
ok - looks something with my first testing back then must have been wrong - even with that clrsetbits_le32 reverted it still boots - so looks like just ranks=1 does it for my box as well like for ashleee - verifying this now by reverting ranks back to 2
<jernej>
just found something that might be reason for your issue
<jernej>
can you set second value in mr_ddr3 array from 0x18 to 0x20 and see if that works even with .ranks = 2?
<hexdump0815>
sure - just verified: ranks=2 still fails ... will try your suggested change now
<hexdump0815>
third value you mean - right?
<jernej>
ah, yes, index 2, third value :)
<hexdump0815>
0x20 does not help ... any other suggestion?
msimpson has joined #linux-sunxi
<jernej>
that is with other changes applied or not?
<jernej>
actually, you can also try with first value in mr_ddr3 set to 0x1e14
<jernej>
together with third value set to 0x20
<hexdump0815>
ok - will try - i guess i can drop the dump code now?
<jernej>
yes
<jernej>
not sure how big influence have these mr values
hlauer has joined #linux-sunxi
<hexdump0815>
no change - still: DRAM:Error while initializing DRAM PHY!
<KotCzarny>
jernej: write a program that runs on arisc and initializes/tests dram? :>
libv has quit [Read error: Connection reset by peer]
<jernej>
not really sure how to do that...
<KotCzarny>
can you write C code ?
libv has joined #linux-sunxi
<jernej>
hexdump0815: I noticed that libdram somehow initializes some registers (4005230 - 400523c), which are not set on mainline
<jernej>
but I can't see those registers referenced in disassembly
<jernej>
KotCzarny: too much work and I'm really not that interested in those MR values...
<KotCzarny>
might simplify testing just some of the registers
<jernej>
hexdump0815: false alarm, they're status registers
<Ashleee>
oh hey hexdump0815 :)
<hexdump0815>
hey ashleee :)
<Ashleee>
any luck so far? too much text :)
<hexdump0815>
looks like my box is the same as yours - the extra patch i added back then was not required - looks like i had a messed up build back then
<hexdump0815>
so ranks=1 is enough for my box too ...
juri_ has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
<Ashleee>
hehe nice
<jernej>
hexdump0815: another thing to try, tx delays
<jernej>
but first I have to recalculate values
<jernej>
which will take some time
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.1, revision: 5.0.1+git-7433-0df9f22f2, build type: debug, sources date: 20160102, built on: 2019-12-08 19:19:20 UTC 5.0.1+git-7433-0df9f22f2 http://www.kvirc.net/]
<jernej>
ah, I mean write delay
hexdump0815 has quit [Remote host closed the connection]
<jernej>
hexdump0815: do you still have values you used to initialize libdram?
<hexdump0815>
what about the mr_ddr3 values - keep them at the ones we tested?
<hexdump0815>
the SUN50I_H6_DDR3_DX_READ_DELAYS change did not help
xqdzn has quit [Remote host closed the connection]
msimpson has quit [Quit: Leaving]
<jernej>
ok, so nothing suspicious in phy part
<hexdump0815>
jernej: something generic - i'm usually reading linux-sunxi via irc logs nearly daily, so i'll see it if you post anything for me even if i'm not online
<jernej>
ok
<hexdump0815>
and i'll keep todays build dir around in case you have anything else to test any other day ... will also be around for a bit tonight
lurchi_ is now known as lurchi__
<hexdump0815>
jernej: leaving for today - as said, if there is something new to test, just post it here and i should find it in the irc logs and respond
<jernej>
ok, I found some differences. I'll make patch and you can test it when you have time
<jernej>
thanks for testing
<hexdump0815>
thanks for all your work!
lurchi__ is now known as lurchi_
hexdump0815 has quit [Remote host closed the connection]
<jernej>
hexdump0815: here are additional differences I found: http://ix.io/2vwI