<Thedemon007>
Hello i compile new uboot with CONFIG_MMC_SUNXI_SLOT_EXTRA=2 and no can see emmc only sdcard in archlinux
<Thedemon007>
the problem still present
Thedemon007 has quit [Max SendQ exceeded]
Thedemon007 has joined #linux-sunxi
chlorine has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
chlorine has quit [Ping timeout: 256 seconds]
xes has joined #linux-sunxi
<Thedemon007>
how to can turn off blacklight of lcd? my config uboot is this http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=blob_plain;f=configs/q8_a13_tablet_defconfig;hb=HEAD
wzyy2 has quit [Disconnected by services]
wzyy2 has joined #linux-sunxi
kaspter has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Pepe has quit [Read error: Connection reset by peer]
Pepe has joined #linux-sunxi
chlorine has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
Andy-D has quit [Ping timeout: 240 seconds]
chlorine has quit [Ping timeout: 240 seconds]
laj has joined #linux-sunxi
rookieone has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
<wens>
MoeIcenowy: the manual should have said how, it's either hardware default or latched pin
<MoeIcenowy>
wens: for the AXP polyphase thing, I didn't see any explain in AXP803 datasheet, but at least it's successfully automatically detected on Pine64
<wens>
reg14H says: bit 5 & 6 default is customized
<wens>
and yes, the code i wrote to support polyphase does read back the initial values to decide how to do things
<wens>
mainly because it doesn't make much sense to have them configurable
<MoeIcenowy>
I think AXP may be able to detect the situation that DCDC2 and DCDC3 is connected together
<MoeIcenowy>
as I tried to fully power down the board and reboot, and the polyphase is still correctly detected
<wens>
i think it's that they are by default poly-phase
<wens>
if they weren't, but by default on, you might get a short or voltage variances
<MoeIcenowy>
yes
<wens>
as the manual said, the default is customizable at the factory
<MoeIcenowy>
and then the chips used by A64 are all customized as default 1?
<wens>
yeah
<wens>
you buy them together anyway
<MoeIcenowy>
in fact when buying AW chips in big amount you can omit AXP (this is the developer of Lichee Pi Zero told me)
scream has quit [Remote host closed the connection]
<MoeIcenowy>
so we can just add dcdc2 in device tree and bind cpu-supply to it?
<wens>
yup
<MoeIcenowy>
P.S. yesterday I already sent one AXP803 patchsets
<MoeIcenowy>
s/sets/set/
<wens>
when tied together in multiphase, only the controls for the first regulator work (or so it said in the axp806 manual)
<wens>
i saw it, though it might not make it in 4.12
<MoeIcenowy>
I hope the MFD part can make it in 4.12
<MoeIcenowy>
so I splitted it to multiple parts
<wens>
fyi you don't need to split up the dts patches so finely though
<wens>
ok, i see
<MoeIcenowy>
there's one problem now: ATF can power down the board, but it will use the RSB controller
<wens>
Lee's schedule is somewhat unpredictable though
<MoeIcenowy>
after R_CCU is ready, the RSB controller's clock is disabled
<MoeIcenowy>
so that ATF can no longer access RSB
<wens>
you probably need to work it out
<MoeIcenowy>
one solution is just enable RSB on the boards now
<wens>
or see if having the axp driver loaded will provide an alternative power off option
<MoeIcenowy>
in fact we just need to keep RSB bus ready
jernej has joined #linux-sunxi
<MoeIcenowy>
maybe I should split patch 5 again to two part: one enables RSB that is necessary in 4.12, one enables AXP that can wait for MFD?
chlorine has joined #linux-sunxi
<wens>
no need
<wens>
if the mfd bindings are good, they can just go in
<wens>
just no driver available for the axp to probe
<MoeIcenowy>
thus who merges the mfd binding?
<wens>
Lee does
<MoeIcenowy>
should we have also axp number sorted in the drivers (axp803, 806, 809)?
<wens>
i'm not sure what the current order is, iirc i tried to keep them in order
chlorine has quit [Ping timeout: 240 seconds]
<mripard>
wens: qschulz has been after the same issues recently
juri_ has joined #linux-sunxi
<mripard>
I don't think he tried to increase that delay yet
cptG_ has joined #linux-sunxi
perr has joined #linux-sunxi
<MoeIcenowy>
wens: is the NMI controller's device tree binding OK?
cptG has quit [Ping timeout: 260 seconds]
<wens>
mripard: increased it to 5 but still hangs, might be something else :|
<MoeIcenowy>
wens: try the u-boot patch in armbian?
reinforce has joined #linux-sunxi
<MoeIcenowy>
according to armbian people it's needed for H3 DVFS to work properly
<MoeIcenowy>
or maybe we should tweak the NKMP type clock setting code, to prevent any temporarily frequency higher than the original one?
<wens>
the problem is the effects of changing the divider happens faster than changing the multiplier
<wens>
so you get a really high rate once you change it, then it _should_ stabilize down to the new rate
<wens>
but by then the cpu already crashed
<MoeIcenowy>
wens: my thought is that we should read back the original register, and first check whether the divider is bigger than the old, if it is we first apply divider, otherwise we first apply multiplier
<MoeIcenowy>
is this correct?
lkcl has joined #linux-sunxi
<wens>
something like that should work
<MoeIcenowy>
low frequencies are more safe then high frequencies ;-)
<wens>
you need to add a delay in between, and that kind of limits how fast clock rate changes can happen
<mripard>
wens: but then, that would also mean that the lock time isn't good enough
<mripard>
we are waiting for it to be locked before changing the muxing back to the PLL
<wens>
yeah
<mripard>
so even if the intermediate frequency isn't good, the CPU shouldn't be affected
<wens>
but i get the feeling that the lock bit is just a simple timer, not an actual indicator :/
jernej has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
wens: try to raise the delay to a very high number? e.g. 1000?
Hao__ has quit [Ping timeout: 240 seconds]
<montjoie>
tkaiser yes dwmac-sun8i-v3 is the good one for the moment
<terra854>
Anyone interested in an Exynos 8895 based SBC if it exists?
apritzel has joined #linux-sunxi
chlorine has joined #linux-sunxi
<fest>
it sounds like it would be the best performing arm sbc
<fest>
I had a project where odroid xu4 was a bit too underpowered (image processing) so I had to go with Intel Nuc (size and weight were not a concern)
foxx has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
paulk-collins has quit [Read error: Connection reset by peer]
rookieone has left #linux-sunxi [#linux-sunxi]
BenG83 has quit [Quit: Leaving]
massi has joined #linux-sunxi
foxx has quit [Ping timeout: 240 seconds]
paulk-elm has joined #linux-sunxi
leviathan has quit [Remote host closed the connection]
paulk-elm_ has joined #linux-sunxi
paulk-elm has quit [Read error: Connection reset by peer]
chomwitt1 has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
Andy-D has joined #linux-sunxi
foxx has joined #linux-sunxi
jernej has joined #linux-sunxi
perr has quit [Ping timeout: 264 seconds]
nemunaire has quit [Quit: quit]
nemunaire has joined #linux-sunxi
perr has joined #linux-sunxi
Andy-D has quit [Ping timeout: 258 seconds]
BenG83 has joined #linux-sunxi
foxx has quit [Ping timeout: 260 seconds]
paulk-elm_ has quit [Remote host closed the connection]
paulk-elm_ has joined #linux-sunxi
paulk-elm_ has quit [Remote host closed the connection]
popolon has joined #linux-sunxi
paulk-elm has joined #linux-sunxi
paulk-elm has quit [Remote host closed the connection]
paulk-elm has joined #linux-sunxi
chlorine has joined #linux-sunxi
perr has quit [Ping timeout: 256 seconds]
chlorine has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 240 seconds]
fkluknav has joined #linux-sunxi
paulk-elm has quit [Remote host closed the connection]
paulk-elm has joined #linux-sunxi
paulk-elm has quit [Remote host closed the connection]
mic-e has joined #linux-sunxi
paulk-elm has joined #linux-sunxi
<mic-e>
hi, me again :) yesterday I asked about how to configure a TXC skew for communication with the micrel KSZ9031 PHY (either in the PHY, or in the MAC, but preferrably in the PHY).
sztibi88 has joined #linux-sunxi
<mic-e>
I managed to re-build my u-boot with the CONFIG_PHY_MICREL and CONFIG_PHY_MICREL_KSZ9031 options and now my u-boot prompt correctly identifies the PHY and allows me to read the extended registers
paulk-elm has quit [Remote host closed the connection]
paulk-elm has joined #linux-sunxi
<mic-e>
ah yes, it's currently configured to its default value 0b01111, at 60ps increments, i.e. 900ns. I'll attempt to increase it to its maximum 0b11111, i.e. 1.9ns
<mic-e>
now, how do I make those changes permanent? do I need to add them somewhere in the boot script? or patch them into u-boot's C sources? if both are possible, which would be the cleaner way?
<beeble>
change it in the dts
foxx has quit [Ping timeout: 264 seconds]
<beeble>
mic-e: see doc/device-tree-bindings/net/micrel-ksz90x1.txt
jonkerj_ has quit [Quit: tot zo!]
jonkerj has joined #linux-sunxi
<mic-e>
beeble: just to clarify things for me, the device tree is parsed and applied by u-boot before the kernel is loaded, correct?
<MoeIcenowy>
mic-e: nope
<MoeIcenowy>
I remember you used 3.4 kernel...
<mic-e>
yes...
<MoeIcenowy>
so there's no cleaner way
<MoeIcenowy>
or we should say
<MoeIcenowy>
the cleaner way is to switch to mainline kernel
<mic-e>
unfortunately I didn't get some GPIO stuff to work with the mainline kernel... (mostly PWM)
<beeble>
MoeIcenowy: he has a mainline uboot, with ethernet enabled and can apply the skew delays in uboot
<beeble>
via dts
<beeble>
uboot devicetree
<MoeIcenowy>
does u-boot phy driver have this logic?
<beeble>
yes
<beeble>
otherwise i would not suggest it
<MoeIcenowy>
ok there is
<plaes>
you can also incorporate this to boot script
<plaes>
well, never mind...
<beeble>
but he is building a new uboot anyway. so why not do it the clean way :)
<plaes>
yeah.. should've parsed through the backlog first...
<mic-e>
just for reasons of learning and personal interest, how would the integration via boot script work?
<mic-e>
the fact that I can't use vanilla kernel quite annoys me, but I definitely want the cleanest solution that doesn't break stuff
<plaes>
you just create new boot script that includes the md command
<mic-e>
plaes: /boot/boot.cmd?
<plaes>
yes, though you need to "compile" it
<mic-e>
yeah
<mic-e>
it says 'do not edit this file' though, I suppose I don't care about that warning
wzyy2 has quit [Disconnected by services]
<plaes>
well, if you're using armbian, then it's automatically created by build scripts
wzyy2 has joined #linux-sunxi
<mic-e>
ok
paulk-elm has quit [Remote host closed the connection]
paulk-elm has joined #linux-sunxi
paulk-elm has quit [Remote host closed the connection]
<mic-e>
adding via boot.cmd worked, thanks @plaes
<mic-e>
now to do it the device tree way
<mic-e>
what file does u-boot load the device tree from?
<plaes>
that's also specified in the boot.cmd
<beeble>
no u-boot dtb. thats defined in the config and the dtb is merged with the boot binary
<mic-e>
oh
<beeble>
CONFIG_DEFAULT_DEVICE_TREE in the config
<mic-e>
it seems that the legacy kernel doesn't have a dtb?
<beeble>
right
<mic-e>
at least in my boot.cmd only the compiled FEX file is used
<beeble>
you want to edit whatever your correct dts is in ./arch/arm/dts/ (uboot sourcetree)
<plaes>
wait.. you're using 3.4
<plaes>
then it's FEX
<mic-e>
wait, so the vanilla kernel doesn't even have this horrible FEX stuff?
<plaes>
yeah.. only device tree
<mic-e>
maybe that's why I didn't get PWM to work with vanilla in the first place
<mic-e>
I attempted to enable it through fex and wondered why no pwm devices appeared in /sys/class/pwm-sunxi
foxx has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
fkluknav has joined #linux-sunxi
mossroy has quit [Ping timeout: 240 seconds]
yann has joined #linux-sunxi
wzyy2 has quit [Ping timeout: 240 seconds]
srikant has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
montjoie: Good news! With dwmac-sun8i-v3 benchmark numbers are even lower.
perr has joined #linux-sunxi
<Ke>
tkaiser: did you receive your wifi dongle?
<Ke>
with 5GHz or something
<Ke>
or was it someone else
<tkaiser>
Ke: Yup, both but did just a quick test with the Ralink.
srikant has quit [Ping timeout: 260 seconds]
<montjoie>
tkaiser: lower ? perf decrease ?
BenG83 has quit [Ping timeout: 256 seconds]
<tkaiser>
montjoie: Yeah, that's great since it showed the benchmark is the problem and not the driver :)
<tkaiser>
montjoie: With this test (combined network/storage test) I got lower numbers with Armbian/mainline compared to Raspbian running on an RPi 3.
<mic-e>
So I suppose the two alternatives are boot.cmd on the legacy kernel and devicetree on vanilla kernel
<tkaiser>
Now used your repo to build OMV and get even worse numbers while iperf results are the same. Then tested on RPi with very slow storage and that affected performance there too. So now I have to search what's different between 4.10 and 4.11 and it's related to 'write to disk' and not network here.
<Thedemon007>
or lib http://forum.linksprite.com/index.php?/topic/3409-help-kernel-complication-make-livesuit-got-error/ pasted the complete error mfratello
<mfratello>
Thedemon007, thanks, but i seem to have all the files
chlorine has quit [Ping timeout: 240 seconds]
<mfratello>
nope, nothing changed
chlorine_ has quit [Remote host closed the connection]
<miasma>
tkaiser: the case is nice, but unfortunately too small for my needs anyways :P
<miasma>
they could have used the space better
jernej has quit [Ping timeout: 240 seconds]
<tkaiser>
miasma: My guess is that they sell another NAS thingie for NEO 2 based on the same case but with a second PCB to mount a second disk on. The 12V input could be an indication.
lkcl has quit [Ping timeout: 240 seconds]
<miasma>
tkaiser: i asked them if i could use the current one in my car. i'd wanted to build a media player
<miasma>
the problem is, car voltage varies between 12-14,5V
<jelle>
use an usb stick? :p
<miasma>
um
<miasma>
and plug it where?
<jelle>
in the nanopi
<miasma>
not enough space
<miasma>
i currently use 2.5" hdd (1TB), opi pc, usb dac, usb wifi, 24V 2x50W+100W amp
<miasma>
and a $1.5 usb sata converter
<jelle>
oh yeah
<miasma>
which is great :) > 30 MB/s for $1.5
<jelle>
more then I expected :p
<miasma>
the music is 256 kbps though :P
_whitelogger has quit [K-Lined]
_whitelogger has joined #linux-sunxi
reinforce has joined #linux-sunxi
leviathan has joined #linux-sunxi
<tkaiser>
miasma: And why not getting any PCM5102A on Aliexpress/ebay and putting this into the enclosure? BTW: the step-down converter is this here: http://www.ti.com/lit/ds/symlink/tps54331.pdf
<miasma>
tkaiser: yes, but without schematics i can't tell how it's connected, would it fry leds/hdd with 14V
leviathan has quit [Remote host closed the connection]
<miasma>
apparently h5 support didn't make it in uboot v2007.3
<miasma>
at least there's no opi pc2 files in the repo
<miasma>
vpeter: the car battery is 12V, car generator 14V. opis use 5V, hdd uses 5V, the amp uses 24V
<miasma>
vpeter: and i already have 12 -> 24 for the amp, the nas case would have the other converter in a compact form
<vpeter>
Got it.
fkluknav has joined #linux-sunxi
<tkaiser>
jelle: Hehe, just checked my mails. How late is it now in China? Mindee from FriendlyELEC just wrote 'we'll reduce the heartbeat brightness in the future since it's not for the Iron man'. They also sent JMS567 datasheet (I never asked for :) ) so maybe they follow the suggestion to replace the USB-to-SATA bridge on their NAS thingie with JMS567 in the future :)
<jelle>
hehe lol
<MoeIcenowy>
tkaiser: it's 01:34 am now
<jelle>
but yay more datasheets :-)
<tkaiser>
MoeIcenowy: you need to go to bed now. It's late! Good night! ;)
<MoeIcenowy>
reduce the heartbeat brightness is a good thing ;-)
<MoeIcenowy>
I can still remember the first time I start a Cubieboard1 (with mainline kernel)
<jelle>
just solder a bigger resistor ;-)
<MoeIcenowy>
yes
<MoeIcenowy>
the green LED which is put into heartbeat is very very light...
apritzel has quit [Ping timeout: 246 seconds]
<willmore>
tkaiser, that's good news. The possible JMS567 replacement.
<willmore>
Did you upload that datasheet, tkaiser?