tuxd3v has quit [Remote host closed the connection]
stikonas has quit [Ping timeout: 272 seconds]
kevery has quit [Read error: Connection reset by peer]
adjtm_ has quit [Ping timeout: 240 seconds]
adjtm has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
vstehle has quit [Ping timeout: 240 seconds]
kevery has joined #linux-rockchip
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #linux-rockchip
elektrinis has quit [Remote host closed the connection]
elektrinis has joined #linux-rockchip
chewitt has joined #linux-rockchip
elektirnis has joined #linux-rockchip
elektrinis has quit [Ping timeout: 265 seconds]
chewitt has quit [Quit: Zzz..]
dlrobertson has quit [Quit: WeeChat 2.7]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
vstehle has joined #linux-rockchip
return0e_ has joined #linux-rockchip
return0e has quit [Ping timeout: 260 seconds]
chewitt has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
return0e has joined #linux-rockchip
return0e_ has quit [Ping timeout: 265 seconds]
chewitt has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
kevery has quit [Quit: kevery]
kevery has joined #linux-rockchip
kevery has quit [Quit: kevery]
kevery has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 has joined #linux-rockchip
kevery1 is now known as kevery
field^Mop has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
chewitt has joined #linux-rockchip
nsaenz has quit [Ping timeout: 265 seconds]
nsaenz has joined #linux-rockchip
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
Xalius has joined #linux-rockchip
kevery has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
Xalius has quit [Quit: Leaving]
alpernebbi has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 260 seconds]
ldevulder_ is now known as ldevulder
maya_b has joined #linux-rockchip
<maya_b>
hi all - anyone have any luck with the gasket-dkms driver in kernel 4.4?
<maya_b>
i'm trying to build it with a headers package based on the bsp and after resolving a lot of build errors, am now stuck at:
<maya_b>
"bin/sh: 1: ./scripts/recordmcount: Exec format error "
<maya_b>
i found some other similar dkms build issues solved with an arch hack but that didn't fix it
nashpa has quit [Ping timeout: 260 seconds]
nashpa has joined #linux-rockchip
nashpa has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-rockchip
lkcl has quit [Read error: Connection reset by peer]
kevery has quit [Ping timeout: 240 seconds]
kevery has joined #linux-rockchip
lkcl has joined #linux-rockchip
maya_b has quit [Remote host closed the connection]
<ldevulder>
hello! I'm trying to connect a serial console on my roc-rk3328-cc board without any success... I know the the baudrate should be set to 1500000 but even with this I only have garbage on my picocom connexion.... The cable+uart/usb adapter works fine with an s905x base board, so this part seems good
<ldevulder>
anyone has an idea?
hramrach has joined #linux-rockchip
alpernebbi has quit [Quit: alpernebbi]
kevery has quit [Ping timeout: 268 seconds]
JohnDoe_71Rus has joined #linux-rockchip
<ldevulder>
found why: my uart/usb adapter is a CP2102, so it can't be used for baudrate above 1M... I need to buy a new one
<robmur01>
FWIW I've never had any issues with FT232R adapters - the ones with a 3.3V/5V jumper are especially handy since you can remove it and take the I/O voltage from the target if need be
<ldevulder>
robmur01, thx, I ordered one based on CP2104, as firefly sell an adapter with this chip and it works well with rk socs, and it can works with both 3.3v and 5v
return0__ has joined #linux-rockchip
return0e has quit [Ping timeout: 260 seconds]
nashpa has joined #linux-rockchip
lkcl has quit [Ping timeout: 268 seconds]
lkcl has joined #linux-rockchip
<hramrach>
I second that FT232 is the most reliable chip. It does not do bauds over 1M either, though
<hramrach>
The CP chips are sort of hybrid - working at 3.3V and tolerant to 5V. This means there are more limits on the signal they can recognize as valid. And it measn they cannot work on ohter voltages should you ever need that
<robmur01>
hramrach: the FT232R's I have do 1.5Mbaud quite happily, that's part of what I was implying ;)
nsaenz has quit [Remote host closed the connection]
<hramrach>
that's not what the spec says but I never used high speed with any of the chips
<hramrach>
which all seem to be based on ancient upstream u-boot
<hramrach>
any idea what is the purpose?
<fALSO>
they were developing stuff
<fALSO>
that has been merged on mainline uboot
<hramrach>
*are* developing stuff
<fALSO>
are they being updated?
<hramrach>
yes
<fALSO>
from what i tried, those old forks
<fALSO>
dont even build with recent gcc and glibc
<fALSO>
useless
<fALSO>
and the possibility of that being merged... with such differences
<fALSO>
i doubt it
<hramrach>
which also means that if my device is supported with such fork the possibility of it working with mainline is doubtful
<aalm>
except it doesn't
<aalm>
curious, what's your device?
<hramrach>
pinebook pro
<hramrach>
they supply u-boot based on the latter fork which is based on the former which in turn seems to be based on sumething like u-boot 2013.4 .. with recent backports
<fALSO>
lol
<fALSO>
good luck with that
<fALSO>
enjoy having to use binary only rockchip tools
<fALSO>
and img binarys to boot
<fALSO>
and having to use a very old distribution just to be able to build that
<hramrach>
I mean with the amount of stuff they backport to they tree it would be way easier to just merge with upstream
<hramrach>
but NIH
<fALSO>
they probably arent doing it the correct way
<fALSO>
so it isnt merged
<hramrach>
and they are Chinese so can't admit to not doing it the correct way
<fALSO>
jejje
<hramrach>
so is rk3399 supported by mainline?
<robmur01>
but then they also have a whole bunch of Android stuff and drivers in there that are massively divergent from mainline and could never be merged anyway
<robmur01>
ultimately, BSP code is BSP code ;)
<hramrach>
what does Android stuff do in u-boot?
<robmur01>
RK3399 works nicely with upstream U-Boot and ATF as of fairly recently
<robmur01>
with DDR3, at least
<hramrach>
the pinebook has LPDDR4
<hramrach>
can the memory code from the old u-boot be reused or is the interface completely different?
<robmur01>
BSP u-boot doesn't touch memory - that's the binary miniloader's job in that configuration
<robmur01>
Android> all the fastboot and recovery mode stuff, plus all the parameters.txt nonsense
<hramrach>
fastboot and recovery are kind of useful standardized interface
<hramrach>
that does not mean they must be directly provided by u-boot, though
<hramrach>
It may not be just Chinese being Chinese but they also may have some NDA on the miniloader code
<hramrach>
ok, time to find an emty SD card
<hramrach>
thanks for your help
<robmur01>
aalm: but also scroll down for "Option 2" ;)
<aalm>
oh, nice, yeah, should read to the end:]
<robmur01>
however as far as I'm aware the TPL/SPL code may not handle all RAM configurations properly yet
<robmur01>
all I can say for sure is that my NanoPC-T4 has been booting with the upstream-only flow since the end of last year :D
<aalm>
iirc. that NDA thing has actually been the case for either rockchip, or some allwinner soc for using (slightly modified?) DW ddr ip, i don't remember the exact details tho..
<hramrach>
dw shounds like rockchip but you never know