**** BEGIN LOGGING AT Wed Oct 07 02:59:58 2015 Oct 07 03:58:52 holy crap what's the easiest way to change xorg resolution to 720p on bbb Oct 07 04:10:30 nyt: http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI Oct 07 04:11:30 except with the latest images none of that works right :/ Oct 07 04:11:46 nfi, havnt had my bbb hanging of a display in a long time Oct 07 04:12:12 yeah same :/ Oct 07 04:16:33 Screen 0: minimum 1680 x 1050, current 1680 x 1050, maximum 1680 x 1050 Oct 07 04:16:33 default connected 1680x1050+0+0 (0xe9) normal (normal) 0mm x 0mm Oct 07 04:16:40 1680x1050 (0xe9) 0.0MHz *current Oct 07 04:16:40 h: width 1680 start 0 end 0 total 1680 skew 0 clock 0.0KHz Oct 07 04:16:40 v: height 1050 start 0 end 0 total 1050 clock 0.0Hz Oct 07 04:16:41 :/ Oct 07 04:25:26 root@beaglebone:~# xrandr --output HDMI-0 --mode 720x480 --rate 60 Oct 07 04:25:27 xrandr: Failed to get size of gamma for output default Oct 07 04:25:27 warning: output HDMI-0 not found; ignoring Oct 07 04:30:11 don't think xrandr works .. Oct 07 04:32:05 i set the screen to 720 in cmdline Oct 07 04:32:14 using video=HDMI-A-1:1280x720@60 Oct 07 04:32:53 root@beaglebone:/sys/devices/ocp.3/4830e000.fb/drm/card0/card0-HDMI-A-1# grep 1280x720 modes Oct 07 04:32:53 1280x720 Oct 07 04:32:56 looks to support it Oct 07 04:32:58 but i get no screen output Oct 07 04:34:30 without setting anything, it comes up at 1680x1050 and display works, ugh Oct 07 04:34:50 monitor can't do 24hz, so it wont come up at 1920x1080, so I'm trying for 1280x720 Oct 07 04:35:22 you sure the 'video' line works .. it doesn't need to be something different .. like tilcdc.mode= or some crazy shiznit Oct 07 04:35:48 or is that already in uEnv.txt Oct 07 04:35:59 root@beaglebone:/sys/devices/ocp.3/4830e000.fb/drm/card0/card0-HDMI-A-1# cat /proc/cmdline Oct 07 04:35:59 console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd video=HDMI-A-1:1280x720@60 Oct 07 04:36:06 i added the video to that Oct 07 04:36:30 after that, xrandr reports 1280x720, but no screen output :/ Oct 07 04:37:30 I don't think it uses 'standard' calls Oct 07 04:38:00 im just going from what the docs on the wiki say :/ there's not much information and what's available doesnt work Oct 07 04:38:11 that sounds about right lol Oct 07 04:38:17 hold up .. gonna see what I can dig out Oct 07 04:38:22 what kernel you on? Oct 07 04:38:42 3.8.13-bone70 Oct 07 04:39:02 latest deb image Oct 07 04:39:04 ahhhh best 3.8 vintage :D Oct 07 04:40:18 whats the latest image that supports all the gpio and dts goodness? Oct 07 04:43:26 hmm whatever is up on the site .. 2015.03 or 05 I think Oct 07 04:43:34 ok I must cook .. bbs Oct 07 04:44:49 Setting up linux-image-3.8.13-bone78 (1wheezy) ... Oct 07 04:44:53 does 4.x support dts ? Oct 07 05:11:10 yes, it's back in 4.1, but I didn't try it yet Oct 07 05:11:42 had issues trying to upgrade the kernel Oct 07 05:32:22 if you're reasonably confident in building a kernel .. RN's site at eewiki.net is fairly good .. since he does a lot of work on the debian images anyway .. Oct 07 05:32:49 much more bleeding edge .. https://eewiki.net/display/linuxonarm/BeagleBone+Black Oct 07 05:50:45 I'll try compiling a new kernel when I have some more beaglebones. I have to compile the kernel native, because I found no crosscompiler for the stupid suse PC at work Oct 07 06:09:24 linaro should work Oct 07 06:09:57 I was bein lazy on gentoo .. coulda built my own toolchain lol Oct 07 06:11:58 hi Oct 07 06:13:55 Please suggest me wher i can dowload source code for beaglebone linux 3.8.13bone 72 Oct 07 06:16:07 nearest I know of is .. https://github.com/beagleboard/linux/tree/3.8 Oct 07 06:20:22 has someone succeded reading eQEP strobe? Oct 07 06:28:37 kernel 3.8.13-bone50 and we use all 3 eQEPs Oct 07 06:29:41 reading the position works, but strobe always returns 0 Oct 07 06:31:53 have you tried looking at the kernel source? compare that to the TRM? Oct 07 06:32:45 we read the registers directly Oct 07 06:33:49 no kernel driver? Oct 07 06:34:40 there is one, since we have -bone50 Oct 07 06:35:08 just spotted .. https://github.com/jadedanemone/BBB-eQEP .. if that's any use .. Oct 07 06:35:34 does that maybe interfere with you reading that directly? (just general ideas, as I have no direct knowledge of that) Oct 07 06:37:49 the worst is, that one of the strobe pins seems to work against the input signal Oct 07 06:38:13 reading also .. https://nathanielrlewis.com/archives/87 ... Oct 07 06:38:25 I compared the overlay sources and I can find no difference between them Oct 07 06:39:59 I know both those links, my problem is, I'm not a software developer, I usually create hardware Oct 07 06:40:35 nice steep learning curve then ... ;) Oct 07 06:40:36 and I can't read c++ Oct 07 06:40:57 find someone who can/does ... ;) Oct 07 06:47:33 the worst is that one eQEP has the strobe pulled down to low Oct 07 06:51:59 mm, those articles did say there were some issues unless you have custom hardware .. Oct 07 07:04:40 what kind of issues? Oct 07 08:16:07 i have to decode a micro Data Matrix Code and looking for a processing unit. The camera i will use has 12 MP cause the area i scann the code is 120mm x 120mm. Do you know if there is a beagle bone how can handels this Raw Pictrue informations? Oct 07 08:17:30 depends on how many frames per second you need Oct 07 08:17:52 hmm i think about 6 Oct 07 08:18:35 may or may not work. I guess processing the image data might max out the cpu. so you'll just have to try Oct 07 08:19:25 ok and on which beaglebone board? Oct 07 08:19:39 or dou you think rasperry pi will handle this better? Oct 07 08:20:10 I doubt it, the rpi is armv6 and has a slower cpu Oct 07 08:20:47 hi, im unable to find the linux kernel 3.8.13bone72 source code, please suggest where to search Oct 07 08:21:04 oke thx tbr Oct 07 08:21:18 ravi_: you've been pointed to a git repository, have you tried that? Oct 07 08:22:31 ya i tried there in github, 3.8.13bone67 is there. Oct 07 08:29:17 sanch, you're going to need a video processing chip .. a $30 arm board ain't gonna cut the mustard. Oct 07 09:15:31 hello Oct 07 09:16:15 anyone familiar with beaglebone black version that bitmain is using for their S5 miner product? Oct 07 09:16:56 I'm trying to find way to make it boot from sdcard stead of internal flash Oct 07 09:18:13 think the flash is corrupted, all I got from serial port is series of CCCCC... when I apply power Oct 07 09:18:30 is there an sdcard slot? Oct 07 09:18:44 there is Oct 07 09:18:58 then put a card Oct 07 09:19:25 done that, it has no effect Oct 07 09:19:54 Don't you need to press a button to boot from SD? Oct 07 09:20:08 depends on how its configured Oct 07 09:20:57 this is a stripped down version, they removed alot of stuff from the board, no power jask, no buttons Oct 07 09:21:04 i mean to boot u-boot from sd Oct 07 09:21:12 yes Oct 07 09:21:15 its not a stock BBB Oct 07 09:21:42 different board layout too Oct 07 09:21:45 some flash on the bottom Oct 07 09:21:52 http://g02.a.alicdn.com/kf/HTB1.kE.HFXXXXcFXVXXq6xXFXXXd/ANTMINER-S5-1200G-BTC-miner-bitcoin-MINNING-miner-send-by-EMS-or-DHL-BETTER-THAN-ZEUS.jpg Oct 07 09:22:30 if you see CCCCC on serial, then you could possibly boot over that, or if you see it briefly over USB Oct 07 09:23:19 yes, that too Oct 07 09:23:20 there is no usb port either, CCC is on serial Oct 07 09:23:30 how to boot through serial? Oct 07 09:23:33 thaolx: then boot over serial Oct 07 09:24:03 I think someone has documented that Oct 07 09:24:36 in your case it would be enough to send SPL and U-Boot and then jump to the SD card Oct 07 09:25:16 cool, I dig some more Oct 07 09:25:17 the other thing would be to figure out if the necessary trace for the sysid switch to SD-card is still there Oct 07 09:25:24 do you have some schematics? Oct 07 09:25:34 no Oct 07 09:25:42 thaolx: did you look at the other side of the board? Oct 07 09:25:45 top side? Oct 07 09:25:51 maybe the switch pads are still there Oct 07 09:25:57 then all you need is to solder a wire Oct 07 09:26:04 or short with something Oct 07 09:26:21 https://groups.google.com/forum/#!topic/beagleboard/bsIWXc2pJJY Oct 07 09:26:35 can you upload some picture of the upper side? Oct 07 09:27:19 yes, the pads are there Oct 07 09:27:24 so there Oct 07 09:27:25 perfect Oct 07 09:27:27 solved Oct 07 09:27:28 next! Oct 07 09:27:34 short them, connect power, presto! Oct 07 09:28:23 will do, my soldering skill is mediorcre tho, lol Oct 07 09:28:33 there's an app for that Oct 07 09:28:54 thaolx: for testing you could just hold a mëtäl object across Oct 07 09:29:00 https://play.google.com/store/apps/details?id=com.tigoli.how.to.solder Oct 07 09:34:33 this is the upper side picture: http://imgur.com/hbaYf08 Oct 07 09:35:03 thanks guys, I'll report back when there's more progress Oct 07 09:39:17 yeah, S2 pads are there Oct 07 09:44:42 rofl .. its a ripped up beagle .. bastards! lol Oct 07 09:46:11 stt_michael: I guess its one of the white-label ones Oct 07 09:46:16 that you can order from CCO Oct 07 09:46:21 customized Oct 07 09:55:29 ahhh Oct 07 09:55:36 bastardised! lol Oct 07 11:06:22 so anyone have tips for playing higher res videos on the bbb at an acceptable framerate? Oct 07 11:07:02 don't compress the video? Oct 07 11:09:04 nyt: just dont Oct 07 11:09:23 use a board that has accelerated video decoding Oct 07 11:09:41 :/ a friend is trying to use a bbb in an interactive exhibit, already has the io stuff done, trying to play a video as well Oct 07 11:10:00 its only a single core A8 and no HW acceleration Oct 07 11:10:19 you can always hook an rpi-cape to the expansion port Oct 07 11:10:34 you could use vlc in split mode and many bbb's, each providing a 320x240 snippet :) Oct 07 11:10:41 lol rpi-cape ? Oct 07 11:10:42 just needs more HW Oct 07 11:11:11 https://www.youtube.com/watch?v=9pwUdRKllo0 Oct 07 11:11:12 as RPi is actually a video decoder with an ARM cpu glued on, yes, that is about the only use case where it makes sense Oct 07 11:12:20 rofl, so 6 bb's for that ;/ Oct 07 11:15:07 so omapfbplay may be better than mplayer? Oct 07 11:15:29 for omap devices ... Oct 07 11:15:43 (which the bbb isnt) Oct 07 11:16:12 ah yes Oct 07 11:24:02 nyt: omapfbplay is just using libavcodec/libavformat Oct 07 11:24:16 and it can use the HW accel on e.g. OMAP4 Oct 07 11:24:35 wow 4.1 feels snappier Oct 07 11:47:47 ok so different issue, trying 4.1 Oct 07 11:47:53 but the dts files i generate/compile don't seem to be happy Oct 07 13:40:26 Hi Oct 07 13:45:06 I need to include in kernel compiling, the driver of the Audio codec tlv320aic32X4, and exclude the actual compiling of the tlv320aic3X Oct 07 13:47:43 make menuconfig .... Oct 07 13:48:06 I tryed to esclude in "defconfig" tlv320aic3X codec, and I have included tlv320aic32X4, but after the compiling sequence in ../sound/soc/codecs/tlv320aic32x4.o isn't present Oct 07 13:49:18 @av500: I select in menuconfig the new codec, but after I run compiling... Oct 07 13:51:08 First, I run menuconfig Oct 07 13:51:36 after, in the ordr Oct 07 13:51:39 order Oct 07 13:51:42 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- beaglebone_defconfig Oct 07 13:51:53 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage dtbs Oct 07 13:52:05 ecc ecc Oct 07 13:52:10 if you make the defconfig Oct 07 13:52:15 it will make the defconfig, no? Oct 07 13:52:20 not your changed one Oct 07 13:53:17 yes Oct 07 13:53:36 How to resolve? Oct 07 13:54:26 make the defconfig Oct 07 13:54:28 once Oct 07 13:54:39 then use menuconfig to change the config Oct 07 13:54:48 then just make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- Oct 07 13:55:32 I have tried to change defconfig, but my change is ignored Oct 07 13:55:55 change your .config Oct 07 13:55:58 with menuconfig Oct 07 13:55:58 fr1, your change got overridden when you ran "make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- beaglebone_defconfig"... Oct 07 13:56:27 ah! .config Oct 07 13:57:05 rcn-ee: yes, overridden Oct 07 13:59:45 when I run "make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- beaglebone_defconfig" what file is involved? Oct 07 14:00:22 beaglebone_defconfig is copied to .confog Oct 07 14:00:24 config Oct 07 14:00:34 from arch/arm/configs or sp Oct 07 14:00:36 so* Oct 07 14:00:42 okay Oct 07 14:01:56 In order, I change the .config and after I run ..beaglebone_defconfig Oct 07 14:02:04 yes? Oct 07 14:03:17 fr1, "only" if you want to change the ".config", that "beaglebone_defconfig" copied.. Oct 07 14:03:17 yes Oct 07 14:03:44 okay, now clear.. thanks Oct 07 14:05:39 latest info, sorry .config is in main path of the kernel? Oct 07 14:06:30 yes Oct 07 14:06:33 ls -a Oct 07 14:06:37 okay Oct 07 14:06:44 I try Oct 07 14:06:47 :-) Oct 07 14:06:55 or DIR /ah Oct 07 14:17:08 rcn-ee: oaky Oct 07 14:17:13 okay* Oct 07 14:20:10 @av500:the file "defconfig" what role? Oct 07 14:24:10 @av500: in the main path, of the kernel 3.8, https://github.com/beagleboard/linux/tree/3.8 I don't found ".config"" Oct 07 14:24:37 Hello, i was wondering if anyone could verify something for me. Before I connected a Piezo Buzzer from P9_12 straight to ground and nothing happened. Later when i tried changing the state of P9_12 from high to low, it would still remain high. I am not sure if i have fried the GPIO pins or not since the beaglebone still boots up fine. Oct 07 14:24:51 fr1: of course there is no .config in the git Oct 07 14:25:00 its different for everybody Oct 07 14:25:13 fri, "bb.org_defconfig" Oct 07 14:25:13 fr1: defconfig = default config Oct 07 14:26:35 Hi there, I have an problem that my uart serial port stops sending characters, and I have found no way to reset it other than restarting the system. Receiving is still fine, how can I debug this issue, our board is based on the BBB Oct 07 14:26:57 Running linux kernel 4.2-rc8 Oct 07 14:27:18 -bone2 Oct 07 14:27:48 @av500, rcn-ee: In my root, is present defconfig, Oct 07 14:30:56 @av500, rcn-ee: where I have changed: CONFIG_SND_SOC_TLV320AIC3X=y with CONFIG_SND_SOC_TLV320AIC32X4=y, but in compilig is generated TLV320AIC3X.o Oct 07 14:31:15 etph, any change with 4.2.3 (or v4.2 final) we had switched to the generic serial stack for omap.. Oct 07 14:32:04 rcn-ee: thanks! Oct 07 14:32:45 rcn-ee: no more ttyOx? Oct 07 14:33:00 fr1: you need to edit .config Oct 07 14:33:04 using make menuconfig Oct 07 14:33:46 av500, well.. udev rull ttyOx = ttySx... Oct 07 14:34:27 av500, and kernel is setup to replace "console=ttyOx" -> "console=ttySx" Oct 07 14:34:37 and systemd knows to start getty based on "console=..." Oct 07 14:34:46 so... no one should notice. ;) Oct 07 14:34:52 rcn-ee: butits back to ttyS? Oct 07 14:34:55 but its Oct 07 14:35:33 yeap... back to the 2.6.32 days... i figure by v5.10 or so we will be back to ttyOx... for some stupid reason... Oct 07 14:36:03 @av500: I tried to using make menuconfig, but after my selection of the new codec, the changes is ignored. Oct 07 14:37:25 @av500: but because I performed ..beaglebone_defconfig Oct 07 14:37:25 fr1, if you do it correctly: https://paste.debian.net/314816/ it'll work... Oct 07 14:38:46 @av500, rcn-ee: okay.. my sequence isn't incorrect Oct 07 14:40:24 @av500, rcn-ee: very thanks! Oct 07 15:11:14 when I run menuconfig, and I apply any change, when I exit and save a configuration, where is saved the new configuration? Oct 07 15:11:30 fr1, ".config"... Oct 07 15:11:31 in .config? Oct 07 15:12:41 rcn-ee: in this case, defconfig is ignore? Oct 07 15:12:52 ignored? Oct 07 15:13:31 fr1, "defconfig" is a common way to talk/pass/copy/paste ".config"... Oct 07 15:13:38 the kernel scripts don't use it... Oct 07 15:13:54 rcn-ee: okay clear Oct 07 15:15:11 fr1, the "." in .config makes it hard for users to see "it" as it's hidden by default in linux file systems, so defconfig is commonly used to replace .config for users.. Oct 07 15:16:46 for example, if I run make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- bb.org_defconfig ".config" is create with the default...? Oct 07 15:17:44 fr1, that actually runs: "cp ./arch/${ARCH}/configs/bb.org_defconfig .config" ; "make ARCH=${ARCH} oldconfig" ; Oct 07 15:17:59 default value contents in defconfig, true? Oct 07 15:18:25 fr1, what else would be in their? Oct 07 15:18:41 def = default. ;) Oct 07 15:18:48 okay :-) Oct 07 15:38:02 thanks all, bye Oct 07 16:10:11 Hi. Should Qt Quick 5.4 from Debian (testing) work in 16bpp (I get "Unable to find an X11 visual which matches EGL config 125")? It works in 24bpp. Oct 07 16:21:08 Hello there. I've got an issue with BBB: I am developing a server using files from an SD card. I put an automount command in fstab and it works fine when I insert and remove the card, but the problem occurs when I boot the BBB with the SD inserted - the block device names are assigned in some strange manner, where SD card gets "lp number" lower then the eMMC card, contrary to when the card is inserted after system booting (I refer to mm Oct 07 16:21:11 rcn-ee: were the problem that tx stops working on omap uart reported for pre 4.2-final kernel? Oct 07 16:21:16 This makes a lot of mess Oct 07 16:22:00 Does anybody now how to make the block device name for SD card unchanged wheter it is inserted after or before system boot? Oct 07 16:22:53 heh Oct 07 16:22:57 jalooc: you can use UUID in fstab Oct 07 16:23:26 jalooc: yes, and it gets periodically proposed to the mmc-dev list and rejected Oct 07 16:24:37 jalooc: but it's basically a kernel patch involving less than a dozen lines Oct 07 16:25:31 the bare minimum version is probably a two-line patch Oct 07 16:25:31 zmatt: isn't uuid in fstab a solution for that? Oct 07 16:26:00 etph: it is not literally a solution to the question asked Oct 07 16:26:26 zmatt: how does the kernel patch works? and why isn't it merged? Oct 07 16:26:37 etph, it's a never ending battle. ;) Oct 07 16:27:07 zmatt: but putting the UUID in fstab will make the SD card being mounted both on boot up and after boot up? Oct 07 16:27:41 jalooc: yes, assumes it's always the same card and you don't need to boot from it without initramfs Oct 07 16:28:08 *assuming Oct 07 16:28:09 zmatt: I just want to write some data to it, that's all Oct 07 16:29:12 rcn-ee: but does upgrading the kernel solve my problem, or it might solve my problem? :p compiling 4.3-rc4-bone1 now anyway so Oct 07 16:29:23 etph: zmatt: so is there some solution for being able to use any card, not just the ONE? maybe the other way - somehow exvlude the eMMC from the names? Oct 07 16:29:33 *excluding Oct 07 16:29:47 etph, just double checked, there were no 8250_omap patches past rc8.. (it's a relatively new-replacment driver) it's co-auther is on beagleboard@google group... Oct 07 16:30:49 jalooc, use blkid's uuid value.. i've been working on another solution using partuuid, and patching the kernel for those latest chagnes... Oct 07 16:30:50 rcn-ee: great, I'll try it out :) Oct 07 16:31:07 rcn-ee: that's still card-dependent Oct 07 16:32:06 jalooc: the solution is the kernel patch that rcn-ee no doubt has on his list of patches that really need to be applied in the near future ;-) Oct 07 16:32:34 etph, ping Peter Hurley peter@hurleysoftware.com, he's worked on 8250_omap.. Oct 07 16:33:17 rcn-ee: okey Oct 07 16:34:08 zmatt: haha okay, I'll get some cofee and wait for the patch :p in a meantime I'll have to use that UUID trick I guess.. Oct 07 16:34:25 * zmatt still has his kernel config'd to use the ttyO driver and doesn't quite get the whole issue between the two different drivers Oct 07 16:45:49 jalooc: maybe the usbmount package is a better option for you ? Oct 07 16:46:12 jalooc: then no need to use fstab automount Oct 07 16:47:46 zmatt, just pushed the initramfs fix for (broken kernel mmc-number, pass partuuid for gpt partitions) for wheezy/jessie/stretch, just got to do the ubuntu's.. then it's kernel fix time.. (there's a systemd fix i need to do for non-gpt partitions, damn you imx5/6 bootrom!!) Oct 07 16:50:09 jalooc: or a script that can iterate the devices (emmc, sd card), and see which one of them is mounted at /, and mount the other one manually :) Oct 07 16:50:41 rcn-ee: is this also helpfull for my case? :P I'm new to Linux and not sure what you've just wrote.. Oct 07 16:51:35 etph: I'll check both options Oct 07 16:53:36 rcn-ee: but the whole initramfs patch and gpt stuff becomes basically unnecessary if you apply the patch... Oct 07 17:05:33 zmatt, true, but there are people that run a un-patched kernel.. ;) Oct 07 17:06:18 I'm sure they'll manage to cope Oct 07 17:29:54 Hey guys. I'm brand new here and trying to figure out if BBB is the right platform for a new project. One of my biggest questions is how active the community is when I inevitably hit road blocks getting started. Have you guys had a good experience? Oct 07 17:30:23 * stt_michael chuckles Oct 07 17:31:18 TheKid: The bone and related boards probably have the biggest, most cohesive community of any of the hobbyist SBCs. Oct 07 17:33:43 TheKid, at times we are too active, thus creating new and exciting roadblocks to breakthru. ;) Oct 07 17:36:21 TheKid: Personally I had a very good experience with the platform and community :) Oct 07 17:37:06 That's great to hear. Thanks for your comments agmlego, rcn-ee, and etph. Oct 07 17:38:29 I have a ton to learn, but no real questions at the moment. I guess I better order a board and start reading the documentation. Oct 07 17:41:27 TheKid: The biggest single piece of advice I can give is this: Learn Linux. *So many* questions in this channel boil down to "How do I $common_Linux_thing on the bone?" Oct 07 17:41:49 Whenn it would be better to figure out hoiw to do that thing, period. Oct 07 17:43:40 agmlego: Haha. Unfortunately that's going to be the steepest part of the learning curve for me. I have a strong background in programming, electronics and test/measurement. I've spent nearly a decade in the National Instruments ecosystem, but I hardly know anything about Linux. Oct 07 17:47:53 TheKid: Oct 07 17:48:10 If you are intending to use HDMI or need 3D acceleration, forget it :) Oct 07 17:48:45 TheKid: in that case, learn to use /dev/mem ;-) I've often enough dumped a kernel driver in favor in direct userspace access to peripherals Oct 07 17:50:21 * zmatt had prior baremetal experience with these SoCs though Oct 07 17:51:21 3d accel and hdmi work, just not as convenient as desired Oct 07 17:51:22 Haha. Okay. Luckily this first project *should be* relatively simple: At powerup start acquiring on all analog inputs and store to file. Hopefully that's not too exotic? Oct 07 17:51:32 TheKid: No worries, everyone starts somewhere. Just keep in mind that, if you are asking a question that does not directly concern the bone's hardware in some way, chances are a better place for the question is with the software project's support community, not here. Oct 07 17:51:45 TheKid: ohh, you so want direct userspace access for that... the kernel adc driver is crap Oct 07 17:51:57 hold on Oct 07 17:53:44 rcn-ee: regarding your initramfs-tools patch, what boards are impacted by it? Oct 07 17:54:06 rcn-ee: i tested u-boot v2015.10-rc4 on the BBB and it didn't have any issues Oct 07 17:54:23 though i was also using flash-kernel ... and patch u-boot in debian... so hm. Oct 07 17:55:07 vagrantc, as long as you boot.scr, you'll never see the issue.. but by default ti's u-boot going to pass root=PARTUUID= Oct 07 17:55:19 ewww Oct 07 17:55:24 TheKid: this is an old version of an ADC test I wrote that uses /dev/mem instead of the kernel driver -> http://gerbil.xs4all.nl/adc-demo.tar.xz Oct 07 17:55:42 TheKid: it's more complicated than necessary though since it actually sets up DMA to a circular buffer Oct 07 17:56:12 also, using uio instead of /dev/mem would be a bit more elegant and avoid the need to run as root -> http://pastebin.com/GrHwgYiR Oct 07 17:56:26 vagrantc, btw i updated https://bugs.debian.org/801154 with more info.. For ti, this will be an issue for dual mmc devices omap5_uevm/bbx15/bbb... btw, fedora's dracut passes PARTUUID jsut fine, and it was fedora guy that set it up in u-boot ;) Oct 07 17:56:57 zmatt: For me, HDMI doesn't work with all monitors. E.g. my DELL U2412M is always showing a black screen and even the monitor's menu doesn't work. It reacts to `xrandr --output HDMI-0 --off`, but nothing else. Oct 07 17:56:57 zmatt: very cool. Thank you! I might have use for a circular buffer in a later stage, so this could be very handy starting point. Oct 07 17:57:35 TheKid: if you use uio and an -rt kernel you can also just get an irq when enough data is in the fifo and read it out Oct 07 17:58:06 rcn-ee: ok, yeah, i typically use boot.scr ... but i'll see if i can't reproduce it and comment Oct 07 17:58:13 vagrantc, btw, unlike uuid's you can pass "partuuid"'s without an initrd to decode them for the kernel.. so in a way, partuuid's are better then uuid's.. it's just that initramfs-tools in debian doesn't know what to do with it.. Oct 07 17:58:51 programming DMA from userspace will get you labeled a loony by some of the regulars in this channel, but it's actually safe to do if the dma channel is declared in device tree (which causes the kernel driver to reserve the resources you need) Oct 07 18:00:06 zmatt: That sounds like what I was planning to do for the first pass, so it sounds like I'll want to start with an -rt kernel. These are the kinds of details that I can see myself getting hung up on, so I'll be proceeding with caution. Oct 07 18:00:35 rcn-ee: makes sense to me, patch looks straightforward enough, just like to verify with my own eyes :) Oct 07 18:00:35 TheKid: I recommend a recent -ti-rt kernel then Oct 07 18:00:58 zmatt: great. That's good to know. Thank you! Oct 07 18:01:40 vagrantc, just make sure you setup a gpt partition... i haven't 100% worked out how to decode partuuid -> uuid, as the udev doesn't create /dev/disk/by-partuuid/ on msdos partitions.. Oct 07 18:02:25 vagrantc, i'm tempted to patch systemd/udev to create those for msdos too... then the gpt requirement isn't no longer needed.. Oct 07 18:02:52 TheKid: still, I measured an interrupt latency to userspace of about 44-80 μs on a -ti-rt kernel, so if e.g. you want 1 Msps things will get a bit tight as the fifo is only 64 samples Oct 07 18:03:41 zmatt: the max sample rate we need on this project is 40 kS/s, but that's something to keep in mind. Oct 07 18:04:15 still puts it out of reach of the kernel driver though unless it has significantly improved nowadays ;) Oct 07 18:04:39 TheKid, use the pru! ;) Oct 07 18:04:44 rcn-ee: sure, i've also not used gpt ... so there are at least two reasons why i never saw this :) Oct 07 18:04:48 that's the alternative yes Oct 07 18:04:52 and a good one Oct 07 18:05:00 but higher entry barrier Oct 07 18:05:04 (probably) Oct 07 18:05:48 TheKid: so, AM335x has plenty of shortcomings, but one of its major gems are its two PRU cores Oct 07 18:05:56 vagrantc, this all started with, how to i use this new ti default, that way root=uSD or root=eMMC is easily passed. Then it turned into a big partuuid/gpt rabbit hole. ;) Oct 07 18:06:08 TheKid: 200 MHz _non-pipelined_, even though it has a 32-bit arithmetic compare-and-branch instruction Oct 07 18:08:12 you mentioned an electronics background... consider doing the read latency of instruction memory, instruction decoding, muxing the right source operands, 32-bit unsigned compare, generate new PC, all in 5 ns Oct 07 18:08:42 PRU is fucking awesome :D Oct 07 18:09:36 zmatt: haha. That's some real power. 5 ns sounds good to me! I'm excited to dig into this. Oct 07 18:10:10 rcn-ee: FWIW, debian may switch to dracut during stretch... Oct 07 18:10:11 TheKid: PRU can *bigbang* a 100 MHz clock (though that would take 100% cpu load though) Oct 07 18:10:26 vagrantc: I was also pondering about dracut Oct 07 18:10:31 since I learned it's supported by debian Oct 07 18:10:46 since it sounds like a good deal Oct 07 18:10:51 vagrantc, really? dracut supports PARTUUID out of the box. ;) Oct 07 18:10:52 * vagrantc hasn't spent more than a couple afternoons experimenting with dracut Oct 07 18:10:56 More practically, a member of i3Detroit is using a PRU to broadcast a WWVB-compatible time signal. Oct 07 18:11:23 TheKid: also, *bitbang* ... typo :P Oct 07 18:11:24 the main issue is that dracut is actively maintained, and initramfs-tools isn't.. Oct 07 18:12:20 vagrantc: dracut also sounds like it should contribute to faster boot, assuming you can configure it to avoid including unnecessary crap in the initramfs Oct 07 18:12:26 vagrantc, the "un-maintained" feature of initramfs-tools is making my wheezy/jessie/stretch trusty/vivid/wily backport easy thou. ;) Oct 07 18:13:33 dracut's also unified for a bunch of distro's so it's the best future option... Oct 07 18:13:46 wheezy? there are people still using wheezy? I mean, when debian themselves call a release "obsolete" you know it _really_ is Oct 07 18:15:18 zmatt, wheezy's about half of my jessie traffic on Packages.gz in my repo... so it's dieing... Oct 07 18:15:32 but twice "trusty"... Oct 07 18:16:12 fun with stats: https://rcn-ee.com/cgi-bin/awstats.pl?output=main&config=rcn-ee.com Oct 07 18:16:21 oh wait, that's ip locked. ;) Oct 07 18:16:56 maybe you should have a policy for obsolete releases to only have their distro dirs available on even weeks and 404 on odd weeks Oct 07 18:17:00 just to wake people up Oct 07 18:17:56 Nah, just substitute random versions of glibc. Oct 07 18:18:46 "for wheezy we're now deprecating systemd and switching to upstart" Oct 07 18:19:04 return "glibc%d.%d"%(request.millisecond%10,request.millisecond%21) Oct 07 18:19:42 you're not considering uclibc or musl? Oct 07 18:19:54 Nope. But those would be fun as well. Oct 07 18:20:28 i'm not that crazy, if i pushed glibc, i'd have to do it write and rebuild the whole archive.... nah use jessie. ;) Oct 07 18:22:55 use stretch you mean :P Oct 07 18:24:21 stretch is blast with the gcc-5.x migration. ;) Oct 07 18:24:54 TheKid: that's another piece of personal advice: debian "testing" (currently "stretch") is quite old enough, debian "stable" (jessie) is ancient crap, anything older than that ("wheezy") is "omg did they have computers back then?!" Oct 07 18:25:04 rcn-ee: I've had zero problems Oct 07 18:26:06 zmatt, you must not be running qt5/plasma5... things have been interesting.. it just works fine now.. Oct 07 18:28:06 most of our BBBs have no graphics (lcdc disabled, pins reused) Oct 07 18:28:30 the only one with graphics does have qt5 Oct 07 18:28:47 (single application currently launched with startx, no window manager) Oct 07 18:29:13 it's really anything built with g++ with the c++2011 spec.. Oct 07 18:29:45 yeah I know the transition you're referring to, had plenty of fun with that on my laptop Oct 07 18:30:13 especially since i had upgraded some packages before they realized it was ABI-incompatible (sid) Oct 07 18:30:24 I'm trying to wrap my head around and understand bbb booting with u-boot. Is there any documentation anywhere about uEnv.txt, u-boot environment variables, u-boot scripts used, etc? Oct 07 18:30:32 which quickly locked me in a "no way back, no way forward" situation Oct 07 18:31:08 and temporarily saying "Y" to aptitude's suggestion of removing itself as part of the resolution Oct 07 18:32:01 nice. Oct 07 18:32:25 rcn-ee: any idea whether qt quick can work in 16bpp mode under X (swrast of course)? Oct 07 18:34:11 kaak: basically: boot ROM fetches SPL (a mini-u-boot) from eMMC at fixed location, SPL inits DDR3 and loads full u-boot from fixed location, u-boot executes an enormous mess of built-in bootscripts to hunt for something resembling a bootable system Oct 07 18:34:17 kaak, we've tried to implement every option by default for u-boot scripts. ;) Oct 07 18:34:54 yeah, that enormous mess is what I'm _attempting_ to get to the bottom of ... Oct 07 18:36:38 kaak: http://pastebin.com/032rGnC7 Oct 07 18:36:40 I'm in the process of cleaning some of it up, with the hopes of sharing. I'm updating alot of the am335x configuration to leverage Kconfig, and _trying_ to untangling all the crazy u-boot scripts that are inlined in old-style configuration headers under include/config Oct 07 18:37:24 kaak: ohh, admirable courage Oct 07 18:37:56 zmatt, man, that link is a sight for sore eyes Oct 07 18:38:06 long live regex Oct 07 18:38:49 I've also got new Kconfig options for the u-boot autobooting features so you don't get stuck in u-boot forever on stray console keys/noise Oct 07 18:39:22 I tried setting it to require ^C, but that failed horribly Oct 07 18:39:45 I mean, it did require ^C to interrupt booting, but it just stuck without giving a prompt Oct 07 18:40:06 My current thoughts for the crazy scripts are looking towards moving the u-boot image into a FIT formatted image and using the u-boot script compiler to move the rootfs discovery mess into "script images" that are packaged along side u-boot, rather than fucking compiled in ... Oct 07 18:40:37 kaak, use "config_distro_default"... if your building from scratch.. Oct 07 18:40:51 i'm slowly migrating our massive pile to that.. Oct 07 18:41:32 I've got it setup (and working even) that you have to type in "uboot" to enter the uboot promt, and that it will timeout and reboot after 60 seconds (configurable) if no inputs are received Oct 07 18:41:34 kaak: also, some notes, if they're of any use... https://github.com/dutchanddutch/u-boot/wiki/AM335x-notes Oct 07 18:42:12 kaak: that's not acceptable for me though, 1 second is bad enough Oct 07 18:44:29 I consider the 10-second boot I currently have to be excessively slow Oct 07 18:44:51 its alot less pretty, but here are my notes: http://pastebin.com/aVj5jkH5 Oct 07 18:45:01 zmatt, also, it doesn't affect boot time Oct 07 18:45:18 well it does if it picks up crap Oct 07 18:45:25 its only if you get into the u-boot prompt Oct 07 18:45:26 ahh Oct 07 18:45:28 a Oct 07 18:45:43 and I've had BBBs that for some reason failed to boot after I typed "reboot" Oct 07 18:46:00 I suspect, but haven't verified yet, that they got stuck in u-boot Oct 07 18:47:14 I'd rather use a test of the sd-button to allow a 0-second timeout Oct 07 18:47:56 that's usally the case.. i need to hack up circuitco's eeprom flashing script to work when passing 'uboot' instead of lots of noise.. Oct 07 18:48:27 (works in progress) Kconfig: http://pastebin.com/cQNbgzF5 Defconfig: http://pastebin.com/KTeihcGd Oct 07 18:48:56 kaak: consider pushing a branch to e.g. github ? Oct 07 18:49:44 zmatt, definitely. I'm still cleaning up, and just now at the point to start up conversations and start working in Oct 07 18:50:52 I've also been adding some work to a simple bootloader manager that can be used from userspace/image tools to safely install u-boot + spl Oct 07 18:50:54 https://bitbucket.org/kelledge/beaglebone/src/9aa399efa856cd12e697cfd8ecbd0b9a4b787b1d/beaglebone/bootloader.py?at=master&fileviewer=file-view-default Oct 07 18:51:44 Its currently smart enough to correctly detect the SPL format and u-boot format, and I'm working towards adding some more guards and functionality around it Oct 07 18:52:18 Eventually, I'd like the bootloader install process to be as easy as: beaglebone bootloader install --spl=/path/to/spl --uboot=/path/to/uboot.img Oct 07 18:53:04 with an optional root block device as the target, and also the smarts to ensure that the images are indeed the correct format and bootable Oct 07 18:53:40 I still hope to ditch u-boot entirely some day :P Oct 07 18:54:03 big pile of crap... Oct 07 18:54:24 you just need to enable falcon mode, spl -> kernel... Oct 07 18:54:40 heh, aside from the configuration, I've not found it too awful. Perhaps I just haven't been around long enough Oct 07 18:54:49 that I certainly need to do and is on my shortlist of things to do Oct 07 18:55:21 kaak: the fact they can't fit a fucking bootloader in the 100 KB of internal SRAM Oct 07 18:55:33 you can fit a complete multitasking OS in there Oct 07 18:56:54 haha, yeah, the SPL took me a bit to get accustomed to Oct 07 18:57:10 it also makes e.g. TFTP boot a real headache Oct 07 18:57:59 also the fact that on any data abort it reboots, real fun when trying to poke around in peripherals to see what their state is Oct 07 18:58:34 (I was very glad to eventually get a jtag header soldered onto my original BBB) Oct 07 18:59:28 I've also got alot of work towards a completely self-contained USB boot daemon that can work for the full USB to linux ram disk boot procedure. Oct 07 18:59:53 like BBBlfs but less broken? Oct 07 19:00:09 hahah, that was my inspiration. Oct 07 19:00:19 its usb_flasher is really a gem Oct 07 19:00:26 like BBBlfs, but without sending raw RNDIS packets using libusb Oct 07 19:00:56 "receive packet, discard it, send BOOTP reply. receive packet, discard it, send ARP reply. receive packet, discard it, ..." Oct 07 19:01:45 yeah and it only works if you have e.g. Network Manager that automatically tries to bring the interface up, since usb_flasher silently relies on RNDIS initialization already having been done by kernel Oct 07 19:01:46 its got a ethernet bridge manager, bootp server, and tftp server, and udev manager all in one daemon Oct 07 19:01:59 plus a yaml config to tie it together Oct 07 19:02:39 you've been busy Oct 07 19:02:40 all my servers are well tested, but my integration of them is still a bit messy and needs some cleaning up before releasing Oct 07 19:03:05 We order BBBs in big lots, and I wanted a tool to provision them all :) Oct 07 19:03:56 wow ok, with a logic analyzer and a library written using libsoc (which uses sysfs and /dev/spidev underneath), I just discovered why the PRUs exist. Oct 07 19:04:01 holy hellish lag batman Oct 07 19:04:12 udev just adds and removes the interfaces to a bridge, and my bootp and tftp servers just listen on that bridge and hand out the files the BBB wants/needs Oct 07 19:04:23 * Spirilis is used to doing SPI from microcontrollers where everything happens pretty quick Oct 07 19:04:30 Spirilis: hahaaa Oct 07 19:04:44 Spirilis: are you using an rt kernel? Oct 07 19:04:49 zmatt: no :) Oct 07 19:04:53 lol Oct 07 19:04:59 that would be step 1 Oct 07 19:05:03 haven't walked down that path yet Oct 07 19:05:10 "that path" is apt-get install Oct 07 19:05:24 and things magically work better? Oct 07 19:05:31 assuming things don't crash, yes Oct 07 19:05:38 hmm ok Oct 07 19:06:11 and give your thread real-time scheduling Oct 07 19:06:26 (SCHED_FIFO with priority > 0 ) Oct 07 19:06:30 (but < 51 ) Oct 07 19:06:37 ahh gotcha Oct 07 19:06:57 I vaguely recall reading about that (back when I didn't have any rt systems, always looked like a curiosity) :) Oct 07 19:07:41 you may or may not also need to give the spi processing thread the same priority, I'm not sure if you block on that whether you block in a way that allows for priority-inheritance Oct 07 19:08:15 dunno, my thread is using libsoc to read/write from /dev/spidev I think Oct 07 19:08:15 alternatively, ditch the kernel driver and use uio Oct 07 19:08:20 ah Oct 07 19:08:24 ditch libsoc also Oct 07 19:08:35 don't tell me you're using that for gpio too? Oct 07 19:08:39 oh yeah :) Oct 07 19:08:43 hahaa Oct 07 19:09:12 figured it's best to get something "working" first on the hardware Oct 07 19:09:31 so that's at least two syscalls for a single gpio change, instead of being able to set and/or clear any subset of the 32 pins of one GPIO bank in a single write (~150 ns) Oct 07 19:09:42 ehh, "set or clear" Oct 07 19:09:44 alas, now that the code logic is well fleshed out it shouldn't be hard to swap in other ways of doing it Oct 07 19:09:45 never mind the and Oct 07 19:26:22 Spirilis: so, you're about to witness the most disgusting way to do fast gpio (well, gpo) -> http://pastebin.com/h3esPvdz (btw, the use of ' as digit separator, on which pastebin's syntax highlighting fails hilariously, is valid C++ in recent editions) Oct 07 19:27:05 don't ever use MAP_FIXED in production code, in fact don't use /dev/mem but use uio instead ( http://pastebin.com/GrHwgYiR ) Oct 07 19:28:14 btw, the clear and set are not truly simultaneous, there's probably about 40 ns delay between the clear and the set Oct 07 19:28:33 which is still less than the delay you'd have when using two separate writes Oct 07 19:29:41 (which would presumably be ~150 ns) Oct 07 19:32:55 for gpio you can just add a second device node with the same address space as the original (which obviously need to remain intact if the kernel also needs to be able to use it) Oct 07 19:33:40 Soooo, I have a uboot problem... The uboot enumerates the mmc devices as 0=sdcard and 1=onboard storage, but Linux sees 0=onboard storage and 1=sdcard. The mmcboot script in uboot sets the root partition based on what it sees for the mmc number, and Linux fails to boot. Best of all, I can't fix this by setting mmcroot in my uEnv.txt because mmcboot sets mmcroot after uEnv.txt is loaded! Oct 07 19:34:48 rcn-ee: it's really mmc-device-number-day today Oct 07 19:34:50 :D Oct 07 19:35:00 lol Oct 07 19:35:23 zmatt, yeap! Oct 07 19:35:53 rcn-ee: maybe we should have every person who comes by send an email complaint to linux-mmc@vger.kernel.org Oct 07 19:35:57 feeex eeet ! Oct 07 19:36:15 abferm, use the uuid... quick fix #1 is now implemented... (initramfs-tools upgrade + u-boot v2015.10-rc4).. Oct 07 19:36:24 zmatt and I have a mmc kernel fix too... Oct 07 19:37:08 abferm, and i've added a root overide in rc4... uevn_root=... Oct 07 19:38:50 abferm: the patch to fix it has been repeatedly rejects by the fine folks maintaining the linux-mmc subsystem Oct 07 19:38:54 *rejected Oct 07 19:39:40 abferm: by all means, feel free to express your happiness about that on their mailing list ;-) Oct 07 19:40:01 odd that uboot should such an 'unhelpful' angle... Oct 07 19:40:19 veremit, that's fixed now in rc4... "partuuid"... Oct 07 19:40:29 I mean .. even for compatibilities sake... Oct 07 19:40:46 rcn-ee.. thats a fudge too :P lol Oct 07 19:41:00 veremit: u-boot isn't to blame here Oct 07 19:41:02 the kernel is Oct 07 19:41:15 zmatt... no I'm inclined to agree Oct 07 19:41:23 but consistency is often good :) Oct 07 19:41:45 along with repeatability and reliability :D Oct 07 19:41:56 consistency is boring.. ;) Oct 07 19:42:00 u-boot can't be consistent with the kernel since the kernel's order of assigning numbers is "first come, first serve" Oct 07 19:42:01 pffft Oct 07 19:42:13 zmatt.. ie .. Random?! Oct 07 19:42:31 rcn-ee... wanna swap jobs for a month?! :D Oct 07 19:42:32 if the sd card responds sluggishly (e.g. a command gets corrupted and a timeout/retry has to happen) then eMMC will be first again Oct 07 19:43:06 it's simply whoever manages to complete being probed first Oct 07 19:43:15 and the SD card has a head-start compared to eMMC Oct 07 19:43:24 aka. Random. Oct 07 19:43:27 yes Oct 07 19:43:29 :D Oct 07 19:43:40 very biased random though Oct 07 19:43:45 not a good RNG Oct 07 19:43:52 indeed Oct 07 19:44:02 which means most of the time a hardcoded value will work Oct 07 19:44:18 which is possibly more evil than true random Oct 07 19:44:46 musb random?! *snicker* Oct 07 19:45:17 an external card reader could in theory manage to get in front of the internal ones, but it's not very likely Oct 07 19:45:22 musb wasn't random... it's designed to fail.. Oct 07 19:45:32 lol rcn-ee +1 Oct 07 19:45:56 I'm not sure it was ever Designed at all .. lol Oct 07 19:45:57 rcn-ee: but according to the am335x errata nearly all problems have been fixed in silicon revision 2.0, so musb should work like sunshine now right? :D Oct 07 19:46:26 zmatt.. that means its a Software problem .. lol Oct 07 19:46:30 those are the published errata.. you know there's a stack of un-published, ah crap errata... Oct 07 19:46:59 rcn-ee.. "that'll never work because ... xyz pqrst ... " Oct 07 19:47:02 rcn-ee: I'm still waiting for the ones I reported for the dm814x to show up in an updated errata document Oct 07 19:47:11 (reported two years ago or so) Oct 07 19:47:34 you might have to remind them.. it's probally in someone's email box that left ti... Oct 07 19:47:36 or "working as intended .. " Oct 07 19:47:56 rcn-ee: the poor guy at DM814x support probably submitted it properly Oct 07 19:48:20 and got fired for it??! lol Oct 07 19:48:41 but afaict they don't have access to more documentation than the general public, and when I had a PRCM inquiry he had to send multiple internal emails and wait weeks to get a vague and useless reply from a prcm designer Oct 07 19:49:43 I wouldn't want his job Oct 07 19:50:10 veremit: no, still the same guy there for the past few years Oct 07 19:50:10 depends what the perks are .. lol Oct 07 19:50:27 I doubt there are any... Oct 07 19:52:37 rcn-ee: Ducati, at least on the dm814x, had a fun bug: any invalid access to its external PPB would lock it up, hence also its internal PPB as a result Oct 07 19:53:13 insensitive to subsystem reset, and if you followed the TRM's advice w.r.t. the power domain controls then the bus lockup would even persist over global warm reset Oct 07 19:54:02 combined particularly well with the wrong Coresight Debug ROM contents, which claimed the existence of debug peripherals on the external PPB that weren't actually there Oct 07 19:54:42 yikes lol Oct 07 19:55:25 :D Oct 07 21:05:54 hi Oct 07 21:28:27 sigh... that bug is STILL there? Oct 07 21:58:46 * vagrantc didn't realize the beagle-x15 had dual ethernet Oct 07 22:00:29 Does anyone know of any short comings with respect to the ethernet path on the BBB? Currently I have a TI SDK 7.0.0 image with the preempt rt patches and when running iperf with a 3Mbps 147 packet size, 3000 packets per second, packet train the networking irq thread uses 15% cpu. (iperf -c 10.12.0.198 -u -T 32 -l 147 -i 1 -t 100000 -b 3528000). When running the same on a imx6 solox I don't even see networking thread in 'top'. I also ran some distro (mayb Oct 07 22:00:30 e Debian) and I would get sever packet loss with this same data rate. Any ideas? Is the networking subsystem just limited? Oct 07 22:02:50 how bad is it with 1500 packetsize? Oct 07 22:04:18 and is DMA enabed Oct 07 22:04:22 enabled Oct 07 22:06:30 About 3% with 1500; but that isn't very useful as we aren't downloading something. We need to communicate with other devices sending out upto 15mbits with packet sizes from 150-300 bytes.. Oct 07 22:07:03 What do I look for to determine if DMA is enabled? In the /proc/config.gz? Oct 07 22:07:56 donno off hand thesedays Oct 07 22:08:01 either that or buried in a DT Oct 07 22:08:23 the hw supports chained descriptors, IIRC Oct 07 22:10:52 CONFIG_TI_DAVINCI_CPDMA=y ? Oct 07 22:11:28 seems a bit off Oct 07 22:13:31 dhirc: the hardware is fine, I wish I could say the same about the driver Oct 07 22:14:22 zmatt: Have you experienced issues as well? Oct 07 22:14:23 I haven't inspected its packet handling in detail though, dunno if there's something in there wasting time in a stupid way Oct 07 22:14:32 not really, but haven't done any performance tests either Oct 07 22:14:55 which kernel version you have? Oct 07 22:15:10 zmatt: I would be really curious for other (potentially with different OS's) to run a similar test to compare results. Oct 07 22:15:44 I'm currently in the train, but I can try later Oct 07 22:15:48 Kernel is 3.12 with preempt rt Oct 07 22:15:55 that's quite an old kernel though Oct 07 22:17:09 consider trying the latest 4.1 ti-rt kernel from rcn-ee's repository Oct 07 22:18:33 zmatt: It is not so trivial to just change the kernel version as I am actually not in complete control (working with others). It may be worth a try though.. Oct 07 22:19:15 when running into an issue with the kernel, trying a very recent version is always a good idea Oct 07 22:19:22 e.g. linux-image-4.1.9-ti-rt-r20 Oct 07 22:19:55 also try non-rt (rt is in general not good for efficiency) Oct 07 22:20:34 dhirc, https://paste.debian.net/314894/ (100Mbs ethernet switch) Oct 07 22:23:28 need to switch trains and won't have internet till I get to work, be back in 45 mins or so Oct 07 22:23:37 zmatt: ok thanks Oct 07 23:23:24 * zmatt is almost back Oct 07 23:25:11 I got slightly distracted by being followed by a van... wtf Oct 07 23:34:27 dhirc: dma is always enabled btw, the ethernet subsystem doesn't have any non-dma way to operate it Oct 07 23:37:07 zmatt: OK, the paste that rcn-ee didn't make much sense to me, but he left straight after he posted so I could not respond. He seemed to use the BBB as the client, not the server, for the test. Also, the bandwitdth was saying 34.4 Gbps?? I'm not saying it hasn't been improved, but this doesn't appear to tell me anything. Oct 07 23:37:26 it seems it buffers way too deep Oct 07 23:37:55 dhirc, cpsw is buffered for 1Gb links... Oct 07 23:38:05 you want me to swap them? Oct 07 23:38:51 rcn-ee: still doesn't make sense to me, is it dropping those packets then? if so, the subsystem is being misconfigured since it should never do that Oct 07 23:39:52 I mean, it has to be dropping them Oct 07 23:40:00 In my setup I run, "iperf -s -u -i 1", on the BBB under test and then "iperf -c 10.12.0.198 -u -T 32 -l 147 -i 1 -t 100000 -b 3528000 " from a x64 linux box with a good NIC (i350) Oct 07 23:40:08 i don't have the link, ran from work to home.. Oct 07 23:40:21 https://paste.debian.net/314894/ Oct 07 23:42:42 now it's just 2%: (top) [ 3] 48.0-49.0 sec 431 KBytes 3.53 Mbits/sec Oct 07 23:43:16 sure htop is not this node.. give me sec for cpu.. Oct 07 23:44:35 rcn-ee: 2% seems pretty reasonable I guess, can you quickly try say 15Mbps at the same packet size? Curious to see if the increase in packet rate has a non-linear affect on CPU usage Oct 07 23:45:53 i know you need to be careful on older kernels, there was a bug where cpuidle was fighting the m3 pm, the cpsw subsystem was a casutily of that fight.. Oct 07 23:46:40 rcn-ee: If you could also paste the results of "ethtoo -c eth0" that would be great. Want to make sure you don't also have interrupt moderation on and that's why there is less CPU Oct 07 23:47:20 rcn-ee: Also wonder if the preempt rt patch has some effect.. Oct 07 23:48:22 rcn-ee: it also seems the cpsw driver includes a quirk/fix for the irq erratum of silicon revision 1.0 even though it has been fixed in 2.x Oct 07 23:49:45 setting compatible = "am4372-cpsw"; would disable that quirk Oct 07 23:50:33 dhirc evertyhing is zero eith ethtool... Oct 07 23:51:00 rcn-ee: OK same here. Thats good then. Oct 07 23:51:40 dhirc: having irq pacing disabled on the tx irq sounds like a pointless waste of cpu time though Oct 07 23:51:43 okay, right bbb now.. 4 instances of iperf... 13%, 12% 1.2% 0%... Oct 07 23:54:00 rcn-ee: do you mean you are running 4 iperf servers on the BBB and they are using those cpu %'s respectively? Oct 07 23:54:59 should just be one, but htop is reporting 4.. 2 look like dead pid's.. Oct 07 23:57:12 Hello! Anyone know if i can use the beaglebone as a router (specifically multiple vlans) Oct 07 23:57:43 Jonnyw2k, i think openwrt supports it out of the box.. Oct 07 23:58:16 htop shows threads, so each iperf will probably show up twice. press 'H' when in htop and it should just show one process Oct 07 23:58:44 dhirc, yeap just one .;) Oct 07 23:59:16 rcn-ee: and is that one using 13, 12, .. %? Oct 07 23:59:23 or still 2%? Oct 07 23:59:26 13% Oct 07 23:59:46 with 15mbps? Oct 07 23:59:58 3.53 Mbits/sec Oct 08 00:00:20 rcn-ee, cheers I'll give it ago, I've given up with the cisco router I was trying it on lol Oct 08 00:00:21 rcn-ee: OK that is what I see my end Oct 08 00:00:42 Jonnyw2k: Stick with the cisco! Oct 08 00:00:43 we use to have a bufferbloat patch that helped out, but with the cpsw changes in v4.1.x it had has to be-rewritten.. Oct 08 00:00:51 our v3.14.x had that patch.. Oct 08 00:00:54 dhirc, trying to get access to a vpn Oct 08 00:01:25 rcn-ee: a what patch? Oct 08 00:01:47 rcn-ee: was that 2% you were mentioning before for the BBB receiving the packets? Oct 08 00:01:48 Jonnyw2k, pc engines apu + pfsense... Oct 08 00:03:06 cool, also cisco's have the worlds loudest fans on them lol Oct 08 00:03:09 zmatt, bufferbloat's are 1/2.. https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.0/patches/beaglebone/phy Oct 08 00:03:56 rcn-ee, Due to cumbersome recycling regulations in the EU we do not sell to end users in EU countries. damnitt Oct 08 00:04:13 rcn-ee: why not reduce the size of the tx ring is the problem is there? Oct 08 00:05:05 dhirc, just reversed server/client... bbb when client is 36.3%.. Oct 08 00:05:41 Jonnyw2k, which is funny as they are in switzerland... Oct 08 00:07:02 rcn-ee, not EU (like Mexico and Canada are in America but not USA) Oct 08 00:07:08 rcn-ee: Would you agree that something seems 'broken' here? Should not be using that much CPU on either side.. Oct 08 00:07:57 Jonnyw2k, yeah i forgot, it's been a few years since i last crossed the atlantic... Oct 08 00:09:12 dhirc, more like not optimzed.. for the bbb, we should be able to tweak the buffers for 100Mb... this same ip on the x15 has dual 1Gb connections.. Oct 08 00:09:27 rcn-ee, https://www.gov.uk/eu-eea Oct 08 00:09:38 it's a strange relationship lol Oct 08 00:10:03 i have friends in norway, they have a similar fun relationship with eu.. Oct 08 00:11:58 rcn-ee: Any ideas on what can be done to optimise this? Can you explain how tweaking the buffers may improve this? Oct 08 00:12:50 dhirc, take a look at patches 1/2 here: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.0/patches/beaglebone/phy Oct 08 00:13:11 they need to be modififed for the ti changes in 4.1.x Oct 08 00:13:17 or he can try the 4.0 kernel Oct 08 00:13:45 that tooll... give me a few minutes... ;) these test bbb's have the slowest/cheapest microSD... Oct 08 00:14:19 rcn-ee: So can I just confirm that you see 2% on 4.1.x and on what kernel do you see 13%?? Oct 08 00:14:40 dhirc, that was the top of the 4.1.x-ti branch... Oct 08 00:14:48 right now i'm installing linux-image-4.0.4-bone4 Oct 08 00:14:59 and i hava bone with rt: linux-image-4.0.8-bone-rt-r8 Oct 08 00:15:34 rcn-ee: That was another unrelated query I have, sometimes when I run "ls" on the BBB it seems to stall for a second or two before printing the directory contents. Have you seen similar behaviour and if so is it related to the sdcard driver? Have not bothered investigating as yet.. Oct 08 00:16:07 sounds like a stall in the mmc edma... Oct 08 00:16:46 unlike previous omap mmc ip's that is one relies a lot on the edma... Oct 08 00:17:16 rcn-ee: Thanks a lot for taking the time to do that, this has been really helpful Oct 08 00:18:20 oh and v4.1.x-ti has preempt enabled by default too... Oct 08 00:18:37 CONFIG_PREEMPT=y Oct 08 00:19:35 v4.0.x-bone has CONFIG_PREEMPT_VOLUNTARY=y Oct 08 00:20:35 with v4.0.x-bone, iperf is 6%... Oct 08 00:21:10 What does the VOLUNTARY mean? Oct 08 00:22:09 it's basically the middle setting of the latency/efficiency slider in non-RT kernels Oct 08 00:22:22 OK thanks Oct 08 00:22:31 (CONFIG_PREEMPT being the low-latency side of the slider, at least until RT came along) Oct 08 00:43:33 rcn-ee: Do you have any idea what may have caused the drop from 6% to 2% CPU from v4.0.x-bone to 4.1.x? I am guessing the patches you linked to may be responsible for the 12% to 6% improvement. Oct 08 00:49:22 dhirc, pretty sure it's the bufferbloat patch in v4.0.x (which v4.1.x doesn't have) Oct 08 01:08:41 hey rcn Oct 08 01:08:51 going to start porting my beaglebone gem that's on the bbb to 4.1 soon Oct 08 01:08:53 or adding support Oct 08 01:09:15 i tried loading some of my compiled dts files into the new loc for the slots files Oct 08 01:09:17 but there was no joy Oct 08 01:10:29 just trying to load a gpio pin Oct 08 01:10:35 any thoughts Oct 08 01:20:50 * zmatt usually just produces a custom dtb instead of using overlays Oct 08 01:21:35 also, I heard the dtbo format of 4.1 isn't quite the same as 3.8 so you need a matching version of the dtc Oct 08 01:22:01 I've successfully loaded overlays though Oct 08 01:22:13 via the configfs mechanism Oct 08 01:24:39 where to get dtc Oct 08 01:28:37 I'd hope apt-get install device-tree-compiler gets you a suitable version, but in case of doubt you can also clone my git version and compile it -- at least I know that one works -> https://github.com/dutchanddutch/dtc/tree/devel Oct 08 01:36:10 yah its already installed, dunno if it works for 4.1 though? Oct 08 01:36:17 the dts that i was compiling that worked fine on 3.8 didnt work on 4.1 Oct 08 01:36:25 it built, but didnt load right Oct 08 01:36:33 i'll try cloning that at some point Oct 08 01:37:07 could be the dts or the dtc, dunno how using the wrong dtc manifests itself Oct 08 01:37:55 ill poke at it later Oct 08 01:38:01 swamped atm :( Oct 08 01:39:44 FIY: for my dtc I grabbed the most recent "overlays" dtc I could find on github, merged it with the divergent improvements made in mainline dtc, and added my own patch on top which increases the flexibility of the grammar somewhat Oct 08 01:40:39 that was more than two months ago though, dunno if overlays have now finally been mainlined Oct 08 02:20:02 nyt use https://github.com/beagleboard/bb.org-overlays/blob/master/dtc-overlay.sh Oct 08 02:20:51 ty, bookmarked Oct 08 02:20:59 nyt, look for "/sys/devices/platform/bone_capemgr/" it's the easiest clue your on v4.1.x+ capemanager.. Oct 08 02:21:23 anything prior wasn't under "platform".. Oct 08 02:21:24 yeah i alreayd modified my code to find either slots file Oct 08 02:21:35 i installed --lts Oct 08 02:21:41 ah.. good.. Oct 08 02:21:46 shit ran nice, but needed dts support Oct 08 02:21:51 the gpio# is the biggest diff.. Oct 08 02:21:53 working on some stuff now Oct 08 02:21:57 what changes? Oct 08 02:22:22 around 3.10/11 or so, the gpioX value was corrected... 3.8.x was always one off.. Oct 08 02:23:26 ah Oct 08 02:23:28 http://pastebin.com/raw.php?i=wWJVVdw7 Oct 08 02:23:31 in the 3.8.x dtbo example, we always commented "gpioX" /* really gpioX-1*/... Oct 08 02:23:32 what i generate now for p8_10 Oct 08 02:23:52 would i need to change anything there? Oct 08 02:26:01 that should be fine.. Oct 08 02:36:24 nyt, btw, in panto's tree this looks interesting.. never thought of using extcon interface before.. Oct 08 02:36:30 https://github.com/pantoniou/linux-beagle-track-mainline/commit/4dd38fe9c0ef1a0db76cacb8f09bef9b36fcd9ff Oct 08 02:36:55 it's kinda like cape-universal.. but extcon is already in the kernel.. **** ENDING LOGGING AT Thu Oct 08 02:59:58 2015