ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
<bashintosh> amstan: with one hub only? Try cascading 2 hubs or even use two keyboards - the exposed USB port you're using is OTG or EHCI?
<amstan> the first 2 lines are hubs
<amstan> otg, ehci is an internal port going to the webcam
<bashintosh> Both external hubs or one is embedded on the board? I wonder if your controller driver actually fixes the problem then - when in happens, you can tell right away even by just using a terminal.
<amstan> both external hubs
<amstan> i typed lots of "testing the keyboard" "telling a story with my keyboard"
<amstan> i typed it like 10 times, besides me having tangled fingers i couldn't see any dropped keys
<bashintosh> amstan: try hitting both keyboards (even randomly) at the same time - also try changing hub ports. I'll show you a log in a second
<amstan> both keyboards?
<bashintosh> yes - if you have two USB keyboards
<bashintosh> If the internal keyboard is not USB then the issue won't appear - multiple USB input devices seem to trigger the issue
nighty-_ has quit [Quit: Disappears in a puff of smoke]
levd has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
naobsd has joined #linux-rockchip
<amstan> bashintosh: nope, 2 keyboards+1 flash drive dding stuff to /dev/zero
<amstan> through 2 hubs, chained
<amstan> perfectly fine
<bashintosh> amstan: OK sorry it took a while - here it is https://paste.fedoraproject.org/241783/ This is with 1 keyboard, 1 mouse and one multitouch digitizer after 2 hubs (embedded hub on the Firefly + Cypress HX2 external). I am monitoring the touch events of the multitouch - see UP and DOWN events. DOWN is basically when I touch the digitiser, UP when I release. Look at line 111 of the log: see how there's a
<bashintosh> DOWN event but no UP? That's the digitiser basically stuck - same happens for the keyboard when the sticky key issue shows up.
<bashintosh> amstan: here's the same thing with a USB keyboard https://paste.fedoraproject.org/241799/ - see line 90, the space event got stuck (sticky)
c0d3z3r0 has quit [Ping timeout: 264 seconds]
c0d3z3r0 has joined #linux-rockchip
markm has quit [Ping timeout: 256 seconds]
Bludot has quit [Quit: Connection closed for inactivity]
rperier has quit [Changing host]
rperier has joined #linux-rockchip
levd has joined #linux-rockchip
markm has joined #linux-rockchip
cristian_c has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 252 seconds]
AstralixNB has joined #linux-rockchip
wildea01 has joined #linux-rockchip
<steev> amstan: sorta progress-ish? segfault complaining that it can't get kms resources
<steev> mmind00: hm, i just noticed... you drop the sha512sum files into /usr/lib/mali-drivers - wouldn't that be something more fit for say, /usr/share/mali-drivers ?
<steev> maybe even /usr/share/doc/mali-drivers
<mmind00> steev: definitly not doc ;-) ... i.e. they are used to verify the files etc ... I remember thinking about where to put it
<steev> they definitely aren't libs
<steev> they are misc documentation imo, since it documents what the sha512sums are
<mmind00> /usr/lib/flashplugin-nonfree/pubkey.asc ;-)
<steev> cuz flash is a great thing to follow :P
<mmind00> which is probably what inspired their current location
<steev> eh, oh well
<mmind00> steev: I would argue against "misc documentation" ... as they are an integral part of installing/uninstalling/verifying the driver
<rperier> btw, how do you use this rockchip usb uart ? I mean , you just plug an usb-to-uart converter on your chromebook, then you add wires on your adapter for RX and TX... and then ? another uart-to-usb adapter on your development laptop does the trick (just invert TX and RX) ?
<mmind00> but usr/share would be ok too I think
<steev> mmind00: sure, but they can sit... anywhere
<rperier> (this + the kernel parameter "rockchip.usb_uart")
<steev> yes rperier
<rperier> mhhh very interesting, I really need to test it :D
<mmind00> rperier: no
<rperier> mmind00: ?
<mmind00> rperier: you cut open an usb cable, connect the green and white wires to an uart-converter and this then to your host
<mmind00> rperier: like http://i.imgur.com/gBoqbJu.jpg
<rperier> I mean , I don't understand why
<naobsd> rperier: you don't need to connect any usb-ttl for rk3288 side
<rperier> I just want to be able to have wires without cutting an usb cable
<rperier> I wanted to use what I have at home :)
<naobsd> well
<naobsd> I misunderstand something...
<steev> mmind00: which armsoc driver did you build?
<naobsd> mmind00: I think DP/DM pin become TX/RX pin without any logic, right?
<mmind00> naobsd: exactly
<naobsd> [PC USB]-[USB-TTL TX/RX]=[OTG DP/DM RK3288]
<naobsd> this should be wrong: [PC USB]-[USB-TTL TX/RX]=[TX/RX TTL-USB]-[OTG RK3288]
<cristian_c> hello
<cristian_c> I've tri3d gpio dump
<cristian_c> tried
<naobsd> (I should try myself...)
<cristian_c> I loaded the kernel module and I've checked all the pins, in three modes
<steev> mmind00: fyi, if you change debian/source/format to 3.0 (git), you don't have to build a tarball
<naobsd> lately I don't have any time for hacking :(
<cristian_c> but I'd like to know what to do in order to make things working
<cristian_c> any ideas?
<AstralixNB> mmind00, is there an automatism that applies all patches from a certain git revision (follow-up or catch-up function)
<mmind00> AstralixNB: pull, merge? not sure I understand you fully yet ;-)
<AstralixNB> rperier, I hope you only try one of these cables not both and you do not try to cut a normal USB cable and attach it to the ports of the rk3288 board :)
<AstralixNB> mmind00, I'd like to catch up on u-boot but there are zillions of patches that interconnect
<rperier> I will probably cut open an usb cable, as Heiko suggested
<AstralixNB> Even patches that introduce a new mechanism, then extend the mechanism and finally all is removed again and replaced by a different mechanism
<mmind00> AstralixNB: just clone the git from Simon I guess?
<AstralixNB> rperier, where do you want ot connect this cable?
<AstralixNB> I asked in the list, but did not get an answer where this git might hide... Or I did not see the answer
<rperier> on my chromebook
<AstralixNB> rperier, to which port?
hipboi has joined #linux-rockchip
<mmind00> AstralixNB: Simon replied to your mail ... should hide in your inbox
<mmind00> AstralixNB: branch rockchip-working - http://git.denx.de/u-boot-dm.git/
<mmind00> AstralixNB: the otg port, and yes the usb-uart stuff works like a charm here
<cristian_c> another question
<cristian_c> I'd like to access to mount user readable/writable nand partition (i.e. /sdcard)
<cristian_c> I think loop* block files are related to mtd partitions and I think I could mount /system or /sdcard , mtdblock8 and mtdblock9, respectively (they are ext4 the first one and vfat the second one). So, I'd like to know if maybe I've to enable some CONFIG options in the kernel configuration file or to something else. Any ideas?
<AstralixNB> rperier, the part above reads like someone is trying to connect USB D+ and D- to RX and TX of a serial port, but if the chromebook doesn't have a connector for OTG, then you can attach one like mmind00 said
hipboi_ has quit [Ping timeout: 248 seconds]
<rperier> AstralixNB: my chromebook only has usb host connectors
<mmind00> AstralixNB: of course ... rperier is talking about the usb-uart passthrough function of Rockchip SoCs ... the port stops being an usb port and handles the uart2 sugnals
<AstralixNB> mmind00, thanks, Simons reply got lost in the gmail view, got in in thunderbird... 18k+ mails in u-boot list...
<mmind00> rperier: for reference, on the Hisense Chromebooks the port you want is next to the micro-sd slot
<rperier> the boring stuff is that I will need to cut open an usb cable and add "black" adapters on these wires to be able to connect to an usb-to-ttl converter... (most of usb cables are armored)
<naobsd> I think it should be physically HOST, but internally OTG(1st dwc otg controller)
<rperier> but I will do it anyway, because otherwise I won't have uart on my chromebook :)
<rperier> mmind00: ok, thanks. I was wondering where is this port :)
<rperier> I suppose that it is the same one on asus c201...
<naobsd> I have to cut cheap OTG cable to try that function with my RK3288 boards :)
<rperier> :)
<rperier> that's the game, I know ;)
naobsd has quit [Quit: naobsd]
<libv> rperier: there are some really good crimp tools available for that
<libv> mine came from japan, and it is pretty nice and useful, and not very expensive
<libv> engineer pa-09 iirc (it's 400km away now)
levd1 has quit [Ping timeout: 256 seconds]
<AstralixNB> rperier, just follow mmind00's advise. It sounded just so odd from technical point of view... But it might be a cool feature if it works.
<AstralixNB> I have a rock1 that is dead on RX/TX, so probably it could come back to live with this
<rperier> AstralixNB: did you try other uarts ?
<rperier> I had this problem on my rock pro, I patched uboot to use uart0 instead of uart2 as default, it works like a charm
<AstralixNB> Yes, but I got a second board and that worked
<AstralixNB> But trying to use a different uart is an option as soon as I get u-boot running
nighty-_ has joined #linux-rockchip
cyrozap has quit [Ping timeout: 248 seconds]
cyrozap has joined #linux-rockchip
cristian_c has quit [Quit: Bye]
premoboss has joined #linux-rockchip
<AstralixNB> Has anyone ever tried Simons u-boot?
else- has quit [Remote host closed the connection]
else- has joined #linux-rockchip
<AstralixNB> naobsd, the rkflashtool linked to by linux-rockchip is the latest greatest version?
RokQuarry has joined #linux-rockchip
dack has joined #linux-rockchip
<dack> When using the RK FactoryTool and it says "Check Chip Fail", does anyone know what it does for this check? Is it checking the chip id against the id on the firmware?
field^Mop has joined #linux-rockchip
Bludot has joined #linux-rockchip
mrueg has quit [Remote host closed the connection]
mrueg has joined #linux-rockchip
konsgn has joined #linux-rockchip
<konsgn> for running linux, is it really faster to run it off of an sd card as opposed to internal flash?
<mrueg> konsgn: I'd recommend a usb flash drive
<konsgn> why? your dropping the amount of pins from widely parrallel in nand to only 4 in sd cards and lasty to 1 data channel with usb how can that possibly be better?
<AstralixNB> konsgn, the transfer speed is not related to the access speed.
<AstralixNB> And trasnferring high-speed over 10 traces in parallel is much more complicated in design and layout than over only 2 (complimentary) traces.
<konsgn> but for running the files in /bin or wherever, isn't nand the fastest, and if not, what is?
<konsgn> true, but thats an issue for hardware design, it nonetheless should be faster
<AstralixNB> An last not least, memory management in raw flash has to be done by the system in software, while SD, eMMC and USB drives have their integrated management hardware
<konsgn> basically I'm going to run linux on the mk822, and I'm trying to figure out what the most efficient medium would be
<konsgn> so is usb really the best?
<AstralixNB> I don't know the mk822, but if it has eMMC, use that, if not use a reliable no too cheap SD-Card
<konsgn> emmc being a nand chip?
<AstralixNB> I have no idea how to qualify USB sticks as you never know what kind of memory is inside.
<AstralixNB> emmc is same like SD, but has more data lines and therefore can be faster
<AstralixNB> It is like SDHC but 8-bit than only 4-bit
<konsgn> so not a nand chip
<AstralixNB> So fastest memory you can access with RK3288 is an eMMC. Physically it is limited to somewhat over 100MHz
<AstralixNB> USB is under 60MB/s
<AstralixNB> Nand Chips can theoretically go faster, but there is a lot of software overhead for management, as I told before
JohnDoe_71Rus has joined #linux-rockchip
<AstralixNB> raw nand chips, I meant
<AstralixNB> For all memories the same rule: all are NAND based and all have the same problems. There are good ones and cheap ones. Fast ones and slow ones.
<konsgn> that's interesting, so I will run the system off of an 8g sd card, and keep the nand as a seperat partition for home folder
<AstralixNB> Yes, that is an option
<AstralixNB> However, keep in mind that writing to any kind of NAND is always a thing to avoid if your system should run long time.
<konsgn> what do you mean?
<konsgn> as in a long write or the uptime of the system needs to be long?
<AstralixNB> If your linux is writing many many logs, as normal linux distributions do, it will wear out your flash memory.
<AstralixNB> There is no difference between SD, eMMC or raw-NAND, they are all NAND and they die if worn-out
<konsgn> gotcha, so turn off logging to flash
<AstralixNB> Turn off logging or log to a tempfs in RAM and only copy that once a day
<AstralixNB> And there is not only logging, but a lot of traffic in /var and /tmp in general
<konsgn> with regards to the parameters file, if i intend to have the home on the nand, should I give it 2 sections, one for kernel and another for home?
<AstralixNB> You need to have a boot with kernel in initramfs and a root or home.
<konsgn> would initramfs be on the sd card?
<AstralixNB> I solved the flash issue by modifying RCs scripts to copy old data from my harddrive at bootup and copy new data back on shutdown. So I do not save anything in NAND
<konsgn> my plan as of now is to have uboot launch the kernel from nand which will refer to the sd for the / partition and /home will be on the nand
<AstralixNB> depends on how you build your kernel. I build mine from mainline and have a fixed kernel command line to check for rootfs on my sd-card.
<AstralixNB> If you use NAND, you probably use rockchips kernel and you use rknand.ko?
<konsgn> mainline? i intend to
<AstralixNB> With mainline you probably have no NAND available, I might be wrong, but there is no driver existing to access that NAND controller in Rk chips
<konsgn> I haven't yet determined what the latest kernel available is, but one thing I do need is access to the built in ethernet of the rk3288
<AstralixNB> That is no issue
<konsgn> the one i tried compiling from aloksinha didn't work with my eth phy chip
<AstralixNB> if you use mainline you could place the kernel in nand to boot and access an SD
<AstralixNB> I do not know the hardware details of this stick.
<konsgn> which one of these is mainline?
<konsgn> its a set top box
<konsgn> a long time ago I posted info on it here:http://freaktab.com/forum/tv-player-support/rk3188-devices/other-rk3188-devices/10118-mk822-internals-cozyswan
<konsgn> but they have since discontinued it
<AstralixNB> These kernels are rockchip, not mainline, and these feature support of rknand driver to access raw NAND as MTD device
<AstralixNB> Check around there if you like to try mainline.
<AstralixNB> network, sd/mmc and such basic interfaces should work with 3188. So a no-gui home-server should be possible
<konsgn> right, hdmi is nto yet up for this one
<AstralixNB> Sorry, but I have to leave now. Will probably be back later the day
<konsgn> awesome, thank you for all the help
<mrueg> konsgn: I've tested transfer speeds for radxa here https://wiki.gentoo.org/wiki/User:Mrueg/Radxa_Rock
<konsgn> mrueg, that is interesting, I actually remember coming across that a long time ago, but i forgot that usb was that significant. I think I will first try to get sd working as there are many tutorials for that, then experiment
<AstralixNB> mrueg, you're right, I did not see, that this was a RK3188, and that was very limited on SD (50MBhz no DDR)
<AstralixNB> Only RK3288 supports higher speeds and DDR access with SD/MMC
AstralixNB has quit [Remote host closed the connection]
<konsgn> so on this 3188 of the mk822 I might as well use nand
<konsgn> ?
RokQuarry has quit [Ping timeout: 264 seconds]
konsgn has quit [Read error: Connection reset by peer]
konsgn has joined #linux-rockchip
RokQuarry has joined #linux-rockchip
wildea01 has quit [Quit: leaving]
GriefNorth has joined #linux-rockchip
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
GriefNorth has quit [Ping timeout: 264 seconds]
dack has quit [Remote host closed the connection]
nighty-_ has quit [Quit: Disappears in a puff of smoke]
c0d3z3r0 has quit [Ping timeout: 250 seconds]
c0d3z3r0 has joined #linux-rockchip
field^Mop has quit [Ping timeout: 256 seconds]
<steev> Wut
<amstan> steev: go tell him about your project, heh
<steev> Meh. Not really a project, that shit is my job
<amstan> the project of getting kali working on veyron
<steev> It already works. And works well, minus the whole armsoc debacle
<steev> And, to top it off, I think I'm breaking something now. Because if I install glx-diversions, xorg likes to segfault due to libglamorgl or some shit
<amstan> we got those too, i forgot how leming fixed it
<leming> i haven't?
<steev> You guys are past the no screen configurations found?
<steev> Oh
<leming> armsoc is on the backburner behind the backburner :P
<steev> Yeah same here
<steev> Heavy testing of xorg 1.17 on top of jessie
<amstan> leming: speaking of back burners... we should try getting heiko's upstream kernel patches working with the linux-armv7 package
<leming> how many patches are we talking about?
<steev> Billions
<amstan> lol, i'm not exactly sure, there's at least edp patches required
<steev> amstan: there. I replied to him. Happy
<leming> if there are like a handful of things that are tracked within a day of mainline tags, or are sufficiently out there to not depend heavily on current or future code, that's doable
<leming> if it's a giant archive of changes.. that's out of the realm of what i'm willing to maintain against those packages
<amstan> ok, maybe it's worth for me to do my own local pkgbuild then
<steev> It is
<amstan> at least for testing various things with 4.x, like armsoc
<leming> adding patches to your kernel is a great idea.. until you're the one that has to make them work as the versions creep upward every week
<steev> I want to test it on my peach too
<steev> Truth
<steev> At least there is pwclient though!
<amstan> leming: the only problem with me making a package is that only i can use it, if you make a testing package, we all can use it :)
<steev> amstan: if only they accepted pull requests :(
<leming> start doing it on your own time and with a personal github account :P
<leming> when they decide they have a problem, you can just laugh and point to california law
<amstan> lol