**** BEGIN LOGGING AT Wed May 25 02:59:58 2016 May 25 14:07:29 anyone know about usb otg, libcomposite and configfs? May 25 14:09:11 just wondering why the g_[usb_gadget] kernel modules are loaded, as well as libcomposite. Doesn't the latter make the former redundant? May 25 14:19:06 I don't know anything about those, sorry, but maybe someone can help during primetime hours May 25 14:19:15 channel is kind of quiet now May 25 14:25:12 ScrumpyJack: I'm pretty sure that is the case indeed May 25 14:27:05 zmatt to the rescue May 25 14:27:24 my rndis+eem+ecm combo shows: May 25 14:27:31 usb_f_ecm 6758 2 May 25 14:27:31 usb_f_eem 5572 2 May 25 14:27:31 usb_f_rndis 15794 2 May 25 14:27:31 u_ether 7573 3 usb_f_ecm,usb_f_eem,usb_f_rndis May 25 14:27:31 libcomposite 30989 22 usb_f_ecm,usb_f_eem,usb_f_rndis May 25 14:27:43 and no other usb-related drivers May 25 14:28:06 (that combo btw works out-of-the-box on linux, mac, and windows, without any manual driver installation) May 25 14:32:01 zmatt: do you have any g_ modules loaded like g_ether or g_multi? May 25 14:33:32 my 8.4 default kernel as g_multi loaded, with used by = 0 May 25 14:34:09 I have no g_* loaded May 25 14:34:25 uname -a? May 25 14:34:35 zmatt, is that systemd-gloriousness? May 25 14:34:43 never seen usb_ before May 25 14:34:43 or just uname -r :) May 25 14:34:55 ScrumpyJack: customized 4.6.0-bone3 May 25 14:35:01 aha! May 25 14:35:02 stt_michael: nothing to do with systemd May 25 14:35:20 4.1.15-ti-rt-r40 here May 25 14:35:28 hmm maybe they changed the driver names .. didn't notice anything in 4.4 different from g_xyz May 25 14:35:30 i want your kernel :) May 25 14:35:38 stt_michael: no, g_* still exists May 25 14:35:54 so those are gadget drivers? or what? May 25 14:36:19 yeah, libcomposite is the new way of doing usb_gadget (with configfs to create devices) May 25 14:37:18 ScrumpyJack: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.6 May 25 14:37:37 thanks May 25 14:38:09 keep in mind my needs might not be your needs, and stuff may be arbitrarily broken because I decided I didn't need it May 25 14:39:28 kk. might stick to this kernel then :) May 25 14:39:58 of course there are perks to a stripped kernel too.... http://gerbil.xs4all.nl/boot.svg May 25 14:41:02 :0 May 25 14:41:13 That's pretty nice May 25 15:10:29 ok it actually seems this config doesn't work... I realized I only added eem *after* testing other platforms, so it seems I may need to stick to rndis+ecm May 25 15:10:41 even though eem is simpler and more efficient May 25 15:12:40 you can always diff the configs and decide .. too .. May 25 15:19:41 ok the previous config no longer seems to work either for some reason May 25 15:19:56 * zmatt strangles microsoft and apple with a usb cable May 25 15:29:21 the usb CDC-EEM spec was published in early 2005, how fucking hard can be it JUST IMPLEMENT IT ALREADY May 25 16:06:58 microsfot and appel don't di "implement" they do "reinvent" May 25 17:35:02 is there other method of applying overlays to DT from userspace other than capemgr? May 25 17:38:13 maciejjo, talk to zmatt and his uio driver framework May 25 17:40:34 is it this repo https://github.com/mvduin/py-uio ? May 25 17:41:14 sounds about right :) May 25 17:41:35 although python isn't the only language iirc May 25 17:41:38 it seems that it expects /sys/kernel/config/device-tree/overlays May 25 17:42:10 which probably requires some patches to kernel May 25 17:42:11 yes, there *is* no way to access peripherals without device-tree configuration... that is how the kernel knows about the underlying devices without a BIOS May 25 17:42:59 I have device tree, but it seems my kernel does not have patches to support modification of DT via configfs May 25 17:43:10 what kernel version .. uname -a ? May 25 17:43:24 this is kernel from TI tree May 25 17:43:29 4.4.10 May 25 17:43:47 hmm not the beagle.org ones .. May 25 17:43:55 I am building custom distro using openembedded with BSP layer meta-ti which provides kernel May 25 17:44:40 ah yes.. you'll need to find a way to incorporate the appropriate patches .. May 25 17:45:15 ok, I will look around beaglebone kernel repo May 25 17:45:43 maciejjo, https://github.com/beagleboard/image-builder is your friend .. :) May 25 17:46:05 and its parent. May 25 17:47:41 thanks May 25 17:47:42 jkridner, nice builds.beagleboard.org :] May 25 17:58:38 configfs overlays are still not in mainline? May 25 17:59:08 yes, not yet merged May 25 18:08:59 to be fair, overlays suck, I'm only using them in py-uio to make it more accessible to the average user. I personally use a custom main dts and basically never use overlays May 25 18:09:47 overlays shouldn't be necessary unless you#re doing crazy on-the-fly chip configuration :D May 25 18:11:14 which is rather uncommon... most hardware is not really designed for hotplugging May 25 18:13:24 currently I am customizing kernel dts, but overlays seem easier to maintain separately from kernel May 25 18:32:55 What changes (to mmcblk1/boot I presume) are needed to make hands-free booting from SD card possible? May 25 18:32:57 ...and yet allow for eMMC to boot as usual if no SD card is inserted. May 25 18:51:06 u-boot's default boot script already deals with that May 25 18:54:41 zmatt, somehow I doubt we're dealing with 'default' and/or 'official' :/ May 25 18:57:53 zmatt:only the part about hands-free booting to eMMC is default. May 25 18:58:01 zmatt: to boot to SD card, there must be access to the S2 button. May 25 18:58:54 Hands-free booting to SD card is not default with Beaglebone's u-boot configuration, and that's what I'm trying to achieve. May 25 18:59:21 stt_michael: Indeed, the distro on eMMC is the 'official' Debian as taken from https://debian.beagleboard.org/images/ May 25 18:59:41 msvb-lab, you will probably need to examine the boot ordering and tweak the boot pins appropriately May 25 18:59:55 zmatt probably knows enough about the ordering :P May 25 19:00:11 msvb-lab, in the TRM (boot order) May 25 19:00:40 otherwise the BBB 'official' methods are a bit of a bodge iirc :D May 25 19:01:11 stt_michael: Do you mean that the change I need to make is a hardware only (pin header) change? May 25 19:01:44 I was under the impression that editing uEnv.txt or some other file would work. May 25 19:03:38 I keep reading 'refer to the TRM'. What is TRM??? May 25 19:04:05 Technical Reference Manual May 25 19:04:11 "rtfm" lol May 25 19:05:10 msvb-lab, you -might- be able to fudge it with only changes to the bootloader, but you may not .. it depends on which device you want to have priority .. and as it stands eMMC has it .. holding the boot button, pulls a hardware pin up/down (can't remember which off the top of my head) May 25 19:05:12 rtftrm May 25 19:05:20 Ragnorok++ May 25 19:05:48 the S2 button pulls sysboot2 down May 25 19:06:14 and even though eMMC has priority, its u-boot script I think still checks for bootable sd card first May 25 19:06:26 may depend on which u-boot you have installed of course May 25 19:06:31 zmatt++ May 25 19:08:18 zmatt: rtftrm is not too useful, like I mentioned: docs exist for hands-free booting to TFTP and NFS but not SD card. It's quite surprising. May 25 19:09:54 sad fact is .. there's a lot of rt* to anything embedded .. and the docs aren't really 'friendly' for non-techs May 25 19:10:16 unless you'er a pi-addict there are precious few "how-to"s ... May 25 19:11:37 stt_michael: About a ton of 'how-to' hands-free booting to NFS or TFTP. Even 'how-to' boot from SD card, but the suggestion is to destroy the eMMC boot partition (say what?) May 25 19:12:30 its a bodge :D May 25 19:17:31 hello May 25 19:18:19 Going to be another long day reading 4 year old manuals and trying to apply documentation that aren't relevant to current u-boot implementations. May 25 19:18:26 Oh well, thanks for trying to help anyway. May 25 19:19:37 i am having trouble reconnecting a bluetooth keyboard to a bbb. it had been working up until the time i tried to also connect a bluetooth speaker. now neither works. May 25 19:21:45 msvb-lab, it shouldn't be too difficult .. just gotta reverse what the BBB does automagically May 25 19:22:02 mtnman, oops :) May 25 19:22:17 bbiab home-time May 25 19:22:24 bye May 25 22:28:29 msvb-lab: what are you trying to do exactly? May 25 22:29:22 msvb-lab: btw, in case you haven't found it already, this is how the standard bootloader for the bbb is built -> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot May 25 22:30:06 zmatt: I am trying to (without disturbing a functioning BBB that has no SD card inserted) allow my board to boot hands-free from SD card. May 25 22:31:17 msvb-lab: that is only possible if the u-boot on eMMC is programmed to try to boot from sd before trying to boot from eMMC May 25 22:31:27 which it is by default, at least in current u-boot versions for bbb May 25 22:31:35 zmatt: Thanks for the reference, I had found the document but after 4+ hours of RTFMs (many dozens) I wasn't reading in detail. May 25 22:32:11 Probably quite important is to check out and understand '0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch' and the 'am335x_evm_defconfig' Makefile target. May 25 22:32:17 it's a maze May 25 22:32:19 a real maze May 25 22:32:29 and varies per u-boot version May 25 22:32:36 but in the latest one the magic is in this env var: May 25 22:32:39 boot_targets=mmc0 legacy_mmc0 mmc1 legacy_mmc1 nand0 pxe dhcp May 25 22:32:56 note that mmc0 (sd card) is listed before mmc1 (eMMC) May 25 22:33:02 zmatt: Yes I see that. May 25 22:34:06 zmatt: In which file (of which image.img) are you finding the 'boot_targets' variable? May 25 22:34:08 crap gotto run to catch train, bbiab May 25 22:34:25 printenv on the commandline May 25 22:34:27 zmatt: Okay, thanks for the tips again. I'll keep looking where we left off. May 25 22:34:49 I'll be back soon May 25 22:34:50 afk May 25 22:46:48 that's presumably in the uboot on the emmc May 25 22:47:37 so provided, the UBL(?) and uboot on the emmc is satisfactory for your purposes .. you can get the eMMC to 'boot' uSD .. which, I think zmatt is correct in saying, should attempt the uSD before eMMC if present May 25 23:25:30 UBL ? May 25 23:26:31 SPL you mean? actually that's another possibility, there might be a chance the SPL on eMMC might load the u-boot from SD in preference to the one on eMMC, but I seem to recall being mentioned that SPL always loads u-boot from the same place it came from itself May 25 23:26:55 I'm not sure whether that's actually true, let alone whether that's always been true May 25 23:48:35 zmatt: from memory, there's several variables that have been ... "tweaked" .. to make the current version fairly robust May 26 00:37:45 Nuts May 26 00:38:05 I popped in here a week or two ago seeing if anyone would help me with a project I was working on to make a "fake radio" May 26 00:38:10 Anyone remember that? x3 May 26 00:38:19 Maybe someone has logs that could help? :P May 26 00:38:37 Wait no May 26 00:38:39 I have logs x3 May 26 00:39:08 PDogJr: It's working okay in my test setup at least May 26 00:56:45 cool **** ENDING LOGGING AT Thu May 26 02:59:58 2016