**** BEGIN LOGGING AT Fri Jan 12 03:00:03 2018 Jan 12 05:00:41 I'm trying to build kio-gdrive on debian 9 and kde. KPimGAPI has to be version 5.5.0, but that version needs Qt5Config.cmake > 5.8.0 ... I cannot find 5.8.0, only 5.7.1. Any ideas how I can install 5.8.0? Jan 12 05:01:03 oh sorry this was for the debian channel Jan 12 05:01:17 slightly off topic here huh :) Jan 12 09:02:41 Hmmm, after installing RCN's xenomai-patched kernel (bb-kernel), I had trouble reading over serial, so today I got an appropriate HDMI, hooked it up, and... the display just puts a Tux penguin in the top left corner... and freezes with that. BBB is flashing heartbeat in the meantime... Jan 12 11:04:10 Question concerning eMMC performance on BBB: Tested writing speed from RAM to eMMC is 5 MB/s and reading speed is 2 MB/s. Is this the expected speed of the Hardware? Any chance to make r/w faster? Jan 12 11:05:16 Tested on Debian 9.2 2017-10-10 4GB SD IoT Jan 12 11:06:17 that will also depend on which eMMC is on your BBB. I think there are a few different ones as those are pretty much interchangeable. Jan 12 11:06:44 also make sure you run an up to date kernel Jan 12 11:08:02 hynix H26M31001HPR, waiting for datasheet from manufacturer for details Jan 12 11:08:30 but all in all, is your feeling that this might be ok or way too slow? Jan 12 11:08:57 how can we convert beaglebone black to beaglebone black wireless Jan 12 11:09:34 kishore you mean by using a cape? Jan 12 11:10:29 yes by any means Jan 12 11:19:37 easiest way might be by adding usb BT/wifi stick Jan 12 11:20:55 don't know if theres any capes to support both, might be hard but not impossible to design a cape for that purpose, just looked up the pins that wifi chip is using on BBG, maybe not all pins are on expansion connectors Jan 12 11:24:21 update: there is wifi capes out there, just get one Jan 12 11:35:58 microdevel: please don't send private messages. just ask your questions here Jan 12 11:36:17 read slower than write? that doesn't sound right Jan 12 11:37:54 have to recheck the read again. but write speed is in expected range? Jan 12 11:37:55 and sk hynix eMMC should be blazingly fast? although that part does seem to be the oldest part still listed on their site (the only one that's still eMMC 4.5 instead of eMMC 5.1) Jan 12 11:38:11 write speed is still slow Jan 12 11:39:11 tested with dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=256 oflag=direct, is that okay? Jan 12 11:39:42 for their eMMC 5.1 parts, sk hynix specs 140 MB/s write and 270 MB/s read (and their latest 3D memory parts are even faster) ... (which are speeds you'll never reach on the BBB since you'll saturate the interface around 20 MB/s) Jan 12 11:40:19 ok so what might be the limiting factor on a standard console image? Jan 12 11:40:23 use the erase block size... which is probably 4 MB or even bigger Jan 12 11:40:33 no idea Jan 12 11:40:44 ok i check again and come back Jan 12 11:41:18 I can reach bus-saturating speeds even on the cheapass kingston eMMC that's on the BBB if I reconfigure it to SLC mode Jan 12 11:43:41 wait, maybe not quite, need to double-check that Jan 12 11:43:41 may i ask what you mean by reconfiguring it? Jan 12 11:43:55 in MLC mode (default), write speed was around 7 MB/s iirc Jan 12 11:44:08 how do you switch to SLC? Jan 12 11:45:11 read speed basically saturates the bus: 67108864 bytes (67 MB, 64 MiB) copied, 1.78066 s, 37.7 MB/s Jan 12 11:45:32 moment Jan 12 11:49:27 could you post your read/write test commands? Jan 12 11:50:11 dd if=/dev/mmcblk1 bs=4M count=16 of=/dev/null iflag=direct Jan 12 11:50:26 I can't do a write-test right now, but the ones I did used similar commands Jan 12 11:51:09 read speed is as follows: 67108864 bytes (67 MB, 64 MiB) copied, 1.59776 s, 42.0 MB/s Jan 12 11:51:54 that's essentially the max speed you can hope for Jan 12 11:52:20 write speed: 67108864 bytes (67 MB, 64 MiB) copied, 6.61847 s, 10.1 MB/s Jan 12 11:53:28 how can you set it to SLC mode? Jan 12 11:53:30 does using a bigger block size help? Jan 12 11:53:45 wait, i try 8M Jan 12 11:54:40 SLC mode is part of the eMMC's one-time-programmable settings (i.e. IRREVERSIBLE) and sacrifices 50% of its capacity (in exchange for higher reliability/endurance and performance) Jan 12 11:55:29 we use it for the higher reliability/endurance... the performance was a nice bonus Jan 12 11:55:56 eMMC has quite a significant number of OTP settings Jan 12 11:56:43 can you progam these settings from linux or do you need a programmer? Jan 12 11:58:11 you can program them from linux Jan 12 11:59:06 but settings will depend on manufacturer and model, right? no standard stuff that works on every eMMC.. Jan 12 11:59:14 no, it's eMMC standard Jan 12 11:59:35 well Jan 12 11:59:37 sort of Jan 12 11:59:49 ok my test showed that variying block size doesn't change write speed Jan 12 12:01:47 weird, maybe H26M31001HPR is just much shittier than their later parts... or maybe something isn't quite configured right yet Jan 12 12:03:10 but if you have a look at: https://lists.linaro.org/pipermail/flashbench-results/2013-January/000353.html , my speed is quite good compared to a cheap micron eMMC Jan 12 12:03:39 the micron eMMC used on very old BBBs was indeed sloooooow Jan 12 12:06:30 ok maybe i have to do some research on that. if i mount the emmc (ext4) and write to it via FS, my write speed is just 5 MB/s Jan 12 12:10:41 has anyone tested other flashing methods for the BBB than using SD or USB? Jan 12 12:10:50 like TI Uniflash? Jan 12 12:11:10 I've only done it via USB (using a derivative of BBBlfs) Jan 12 12:11:21 I still have doing it via Ethernet on my to-do list Jan 12 12:11:33 should be very similar to USB though Jan 12 12:11:37 well Jan 12 12:11:57 the main diff being that via USB I currently use USB mass storage mode Jan 12 12:14:24 i'm looking for a method to flash the board really quick and i'm wondering how it is done during BBB production (flashing U-boot at least) Jan 12 12:16:13 microdevel: btw, I'd be interested if you could build https://github.com/dutchanddutch/mmc-utils and provide the output of sudo ./mmc extcsd read /dev/mmcblk1 Jan 12 12:17:08 and maybe sudo ./mmc extcsd dump /dev/mmcblk1 (so I can check if 'read' skipped over anything of importance... it does that sometimes) Jan 12 12:17:27 silly question but where to build it, have no build environment set up yet. is it possible to build on BBB directly? Jan 12 12:18:07 yeah, just type 'make' Jan 12 12:18:22 ok be back Jan 12 12:18:26 it doesn't really require anything other than a C compiler and make Jan 12 12:18:53 I'm also semi-afk for a bit but I'll be back Jan 12 12:20:09 built is ready Jan 12 12:21:54 ./mmc extcsd read /dev/mmcblk1 -> https://pastebin.com/wy7rV3kK Jan 12 12:23:46 ./mmc extcsd dump /dev/mmcblk -> https://pastebin.com/rkWJiXpH Jan 12 12:58:11 microdevel: oh wow, that does actually spec really crappy performance Jan 12 12:58:48 so the hynix is a bad hynix :( what exactly specs it to be so bad? Jan 12 12:58:50 microdevel: so I guess you've got sk hynix' last remaining crappy eMMC :) Jan 12 12:59:13 line 56 Jan 12 12:59:42 0x08 Class A: 2.4MB/s Jan 12 13:00:57 for comparison, I have a device with a newer sk hynix part (H26M64208EMR), and it specifies: [MIN_PERF_W_8_52: 0x8c] Jan 12 13:00:57 but it doesn't say something about max writing performance right? Jan 12 13:01:18 looking up 0x8c in the eMMC spec gives: Jan 12 13:01:28 0x8C Class R: 42.0 MB/s Jan 12 13:01:56 these values are "minimum overall performance" Jan 12 13:02:10 ok so the tested 10MB/s are very much likely to be correct :/ Jan 12 13:02:13 based on a specific testing procedure Jan 12 13:02:24 yeah you just got mediocre eMMC :) Jan 12 13:03:02 ahhh anyway, thanks a lot for your help on that. now i know what's the deal Jan 12 13:03:29 i will put some effort on flashing via TI uniflash Jan 12 13:03:45 let you know if theres any significant outcome Jan 12 13:06:41 microdevel: if you want to try SLC mode, you can check out the 'custom' branch of my mmc-utils repo and use ./mmc reliable-slc-configuration /dev/mmcblk1 but like I said, keep in mind that this is _permanent_ and you'll lose 50% of the eMMC's space Jan 12 13:07:12 how much write speed boost can you expect from that? Jan 12 13:09:45 iirc write performance tripled in my case, but I didn't do extensive benchmarks and I have no idea whether this number might vary a lot depending on eMMC manufacturer Jan 12 13:10:17 but it was really a _lot_ ... I was quite surprised by that even though in retrospect it makes a lot of sense Jan 12 13:16:15 oh huh, that line isn't supposed to be there: https://github.com/dutchanddutch/mmc-utils/blob/016f149b/mmc_cmds.c#L1431 Jan 12 13:16:53 weird, maybe I committed the wrong version... or maybe I just added that line to make a "safe" version of the command and just forgot I did that Jan 12 13:18:04 yeah, just returns 0 without condition :) Jan 12 13:18:21 yes, after doing all checks and right before it would actually perform any reconfiguration Jan 12 13:18:38 did you commit a wrong version maybe? Jan 12 13:19:23 I probably just needed something to check the configuration on a device without risk of accidently reconfiguring, hence added that line and then forgot about it Jan 12 13:19:50 and I never committed the original to git (I only just noticed that and quickly committed it without checking) Jan 12 13:23:18 ok, found the right version Jan 12 13:23:54 can you commit it? Jan 12 13:24:05 so, apologies to all my downstream users (i.e. you) but I'm going to replace the commit instead of committing a fix ;) Jan 12 13:24:17 yeah i can wait :D Jan 12 13:24:25 done Jan 12 13:27:22 (in case you're not too familiar with git: what I did means you can't pull my changes. toss the branch or just clone it fresh if you're lazy) Jan 12 13:29:42 yeah i was expecting that but thanks a lot for the info anyway, seem like you always do some solid work Jan 12 13:30:45 actually I'm also going to change the commit message to include more ominous warnings, just in case anyone stumbles across this Jan 12 13:36:44 there, that should do the job Jan 12 13:39:30 ok i clone it now and give it a go Jan 12 13:44:59 you've read the commit message right? Jan 12 13:45:05 (just a final check ;) Jan 12 13:46:24 yes Jan 12 13:46:32 seems to have worked: https://pastebin.com/TfTvnpsv Jan 12 13:46:36 now lets test Jan 12 13:47:18 optionally you can run the command again after power cycling Jan 12 13:47:23 it'll just confirm that everything is ok Jan 12 13:50:46 thats the output after cycle: https://pastebin.com/zVn5BGwR Jan 12 13:51:03 yep, all good Jan 12 13:51:48 ok we almost doubled it on write side: 67108864 bytes (67 MB, 64 MiB) copied, 3.49596 s, 19.2 MB/s Jan 12 13:51:51 now for the big moment... did it improve write speed or did you just waste an eMMC for no good reason? :) Jan 12 13:52:10 thats actually quite cool on bullshit hardware :D Jan 12 13:52:21 not bad Jan 12 13:52:30 not great, but certainly not bad Jan 12 13:52:49 honestly to me it was more than expected Jan 12 13:53:31 this is with 8 MB blocksize? Jan 12 13:53:52 no with 4MB Jan 12 13:54:01 but same with 8MB Jan 12 13:54:39 yeah actually, your eMMC claims its erase block size is 512 KB ... I wonder if that's really true, it seems so small Jan 12 13:54:55 i could try with 512K Jan 12 13:55:31 bit slower, 18.8 MB/s Jan 12 13:55:47 I guess maybe with sequential writes it doesn't show all that much Jan 12 13:56:12 yeah anyway, we are better than USB2.0 stick right now Jan 12 13:57:09 read speed is not affected right? Jan 12 13:57:22 you may also want to enable background operations (if you search kernel log you'll probably find a warning about that being disabled currently) Jan 12 13:57:47 i can do this in u-boot right? Jan 12 13:58:54 you may want to confirm the kernel indeed complains about it (i.e. that it supports it... which should be true unless you're using a truly ancient kernel) and then ./mmc bkops enable /dev/mmcblk1 Jan 12 13:59:14 (this is once again irreversible btw... eMMC just loves its one-time-programmable bits) Jan 12 13:59:53 actually Jan 12 14:00:02 yeah it behaves like a samsung smartphone you wish to flash a custom rom :D Jan 12 14:01:09 but don't i have to manually enable this feature for the kernel? Jan 12 14:03:03 I don't remember... I recall having seen kernels complain about bkops being disabled (which indicates it's expecting it to be enabled) but I don't actually see it in the kernel log of the first random bbb I check here Jan 12 14:03:18 it should definitely only be enabled in eMMC if the kernel supports it Jan 12 14:03:25 no i dont see it either Jan 12 14:03:40 i recall that you have to enable this in module config Jan 12 14:04:07 that sounds extremely unlikely Jan 12 14:04:23 [ 2.465796] mmc1: MAN_BKOPS_EN bit is not set Jan 12 14:04:28 there it is Jan 12 14:04:49 there ya go Jan 12 14:05:16 ok so i enable it and then we see Jan 12 14:05:29 ah, it's log-level debug, that's why I don't see it Jan 12 14:05:55 your command didn't give any output, is that correct? Jan 12 14:06:26 sounds plausible enough Jan 12 14:06:54 ok power cycle and see what happens Jan 12 14:09:40 warning message is gone Jan 12 14:10:29 speed is the same Jan 12 14:10:54 you won't see bkops in simple benchmarks like this, it's more about responsiveness in real-world system use Jan 12 14:11:28 ahh okay Jan 12 14:12:16 well that is brilliant, now i can flash my BBB with doubled up speed Jan 12 14:12:58 btw, how are you doing the write speed test? Jan 12 14:15:44 boot latest debian console image from SD, login via ssh and execute dd command Jan 12 14:20:21 dd from what? Jan 12 14:20:34 /dev/zero ? Jan 12 14:25:17 dd if=/dev/zero of=/dev/mmcblk1 bs=4M count=16 oflag=direct Jan 12 14:28:13 ok **** ENDING LOGGING AT Sat Jan 13 03:00:01 2018