<BW^->
stdint,paulk-collins,wadim_: hey, generally, do you feel the RK3399 is a stable SoC platform?
<stdint>
that is rk3288, and not
<stdint>
the android for rk3399 is
<stdint>
but linux is not, only chrome become stable
<stdint>
the emmc staff is quit busy recently
<stdint>
but I am thinking the voltage problem
<stdint>
maybe disable the high speed would help
<paulk-collins>
stdint, that's in mainline linux
<paulk-collins>
stdint, sometimes works great, sometimes fails at the exact same point
<paulk-collins>
stdint, same clock phase is used both when it works and fails
<stdint>
paulk-collins, I know that, I have meet such thing before
<paulk-collins>
it fails when reading the partition table
<paulk-collins>
but otherwise still detect the card
<stdint>
the problem is the voltage for emmc can't archive 1.8v
<stdint>
the log wadim_ gave me shows that the problem happened in switch 3.3v to 1.8v
<paulk-collins>
ahh
<paulk-collins>
stdint, in my case it's not during the switch
<paulk-collins>
at least it seems
<paulk-collins>
but maybe so
<paulk-collins>
I'll investigate it more
<paulk-collins>
stdint, what's the solution then?
<stdint>
just disable those high speed proprieties in dts
<BW^->
stdint: wait.. eMMC as in onboard flash access, had problems?
<BW^->
stdint,paulk-collins: okay - except for the onboard flash interface, how do you experience it?
<stdint>
no the problem is PMIC
<BW^->
stdint,paulk-collins: how is the power controller related to onboard flash access issues?
<stdint>
and hardware design, some board vendor using the 3.3 as pull up voltage in all data lines for emmc
<BW^->
stdint,paulk-collins: anyhow - except for the onboard flash access, is there any operational issue?
<BW^->
stdint,paulk-collins: overheat? instability in any other respect?
<BW^->
stdint: wait, can you describe the problem further?
<stdint>
there are two known bugs in rk3288
<BW^->
i don't understand what/why/how "using 3.3V as pull-up from the PMIC" is an issue
<stdint>
1. the usb reset 2. vpu reset
<BW^->
stdint: USB reset as in sometimes USB devices reset, how big issue is that+
<BW^->
?
<BW^->
how frequent?
<stdint>
no
<BW^->
ah, then what?
<stdint>
you may google it in patchwork
<stdint>
I am too lazy to tell the whole story
<BW^->
stdint: ok i will
<BW^->
stdint: and the VPU was some graphics problem?
<BW^->
stdint: I don't find the issues online, on a quick search
<BW^->
anyhow
<BW^->
stdint: for the RK3399, any known issues?
<paulk-collins>
stdint, ok thanks, I'll look into that then
<BW^->
stdint: also, can the RK3288 USB and VPU issues be patched through, or are those "hard" issues that bug you forever?
<paulk-collins>
stdint, it still works fine with the chromeos-3.14 kernel though
<BW^->
paulk-collins: what do you say?
<paulk-collins>
stdint, regarding USB, I investigated more
<paulk-collins>
stdint, it appears to happen when the USB Wi-Fi dongle enters power saving mode
<stdint>
I am trying to find a usb dongle
nighty has quit [Quit: Disappears in a puff of smoke]
<BW^->
paulk-collins: and what was the issue?
<paulk-collins>
stdint, thanks
<stdint>
also the usb patch need a new version
<paulk-collins>
BW^-, usb being broken
<stdint>
after release a new version I would know whether could solve the problem
<stdint>
but most of wireless device here are sdio
<BW^->
paulk-collins: like, how broken? totally unreliable??
<paulk-collins>
BW^-, justs gets I/O errors after entering suspend
<BW^->
paulk-collins: but only in several Linux distros, not on Android?
<paulk-collins>
BW^-, I didn't try Android at all
<paulk-collins>
this is with mainline
<BW^->
paulk-collins: aha, so, if I never ever suspend but only poweron/poweroff/hard-reboot, I won't experience the issue. correct?
<paulk-collins>
it works with chromeos-3.14
<paulk-collins>
BW^-, no, it's about USB device suspend
<paulk-collins>
not system suspend
<BW^->
paulk-collins: aha, so ChromeOS-3.14 has proper USB behavior, and Linux has proper USB behavior too only that if you suspend and resume the laptop then USB crashed?
<BW^->
ahaaaaaa
<BW^->
paulk-collins: when an USB device goes into power savings mode, aha, okay
<BW^->
paulk-collins: gotcha.
<stdint>
not S3 resume
<stdint>
it is only about the usb system
<BW^->
paulk-collins: so on mainline Linux that is a problem, on ChromeOS-3.14 it's not - that's all?
<BW^->
gotcha.
<BW^->
okay!
<BW^->
paulk-collins: what's the VPU problem about?
<stdint>
just go and look usb: dwc2: assert phy reset when waking up in rk3288 platform
<paulk-collins>
stdint, that's a different issue from what I'm having though, right?
<stdint>
which one?
<BW^->
aha
<BW^->
paulk-collins,stdint: except for that USB sleep bug and the VPU problem, does the RK3288 work *perfectly* - no overheat, sudden crashes, memory corruption, or other issues???
<stdint>
then no
<stdint>
I trust google
<paulk-collins>
stdint, I mean, the issue that happens with USB low power mode is not the same as the one your series fixes?
<BW^->
paulk-collins,stdint: ?
<BW^->
paulk-collins,stdint: otherwise perfetly stable, in your experience?
<stdint>
not worse than sunxi
<stdint>
paulk-collins, have you tried to disable the power save mode in wireless?
f3z0 has joined #linux-rockchip
<paulk-collins>
stdint, I could try that
<stdint>
then without the wireless dongle I can't sure
<paulk-collins>
stdint, do you need one?
<paulk-collins>
depending on where you're based, I could perhaps send you one
<stdint>
China, not in Europe
<stdint>
China mainland
<paulk-collins>
ah, sounds hard
<paulk-collins>
I'm in France
<stdint>
:P
<BW^->
stdint: what do you mean by "not worse than sunxi[Allwinner SoC:s]" - did you have stability issues with them?
<BW^->
i mean
<BW^->
if you run an email server on your RocketChip
<paulk-collins>
stdint, well otherwise there are cheap ones on e.g. aliexpress
<BW^->
how often do you need to reboot it?
<BW^->
do they crash?
<BW^->
do they malfunction?
<stdint>
BW^-, it is stable to work as a tv box
<paulk-collins>
BW^-, you should probably ask a rockchip rep about tho
<paulk-collins>
this
<BW^->
mh
<BW^->
paulk-collins,stdint: well, if it's stable for TV (and you never shut it down), you should be able to do any other server activity from it too
<BW^->
of course non-ECC RAM will bitflip sometimes, so reboots will happen
<BW^->
but there is an important difference between a production-use-ready SoC, and a crappy buggy SoC
<BW^->
paulk-collins,stdint: I understand you're saying it's production-ready.
<BW^->
it's good solid stuff.
<stdint>
I didn't know a ARM chip support EEC RAM
<BW^->
stdint: maybe the Cavium ThunderX does, and the X-Gene1. others don't.
f3z0 has quit [Ping timeout: 260 seconds]
<stdint>
paulk-collins, I could buy it local
<stdint>
but those are not open source
<BW^->
paulk-collins,stdint: so basically the Rockchip works perfectly in your experience.
<BW^->
very well.
<BW^->
thanks for letting me know! =)
<paulk-collins>
stdint, try to look for AR9271
<paulk-collins>
stdint, ath9k_htc ones
<paulk-collins>
stdint, aliexpress has some
<stdint>
I have many atheros sdio wireless
<stdint>
WNA1100 150M USB
<BW^->
i'll be going.
<BW^->
thanks again for sharing.
BW^- has quit [Quit: BW^-]
<stdint>
paulk-collins, if that model is ok, I would order one