**** BEGIN LOGGING AT Thu Jan 25 03:00:06 2018 Jan 25 04:44:09 so if i have a usb hub plugged in to usb1 at boot it works, but if I have nothing plugged in at boot i get messages about VBUS_ERROR and the port is disabled... Jan 25 04:45:56 should I just stop using the usb1 vbus and vin pins, and power the hub from a separate 5v boost supply? Jan 25 06:06:29 pins? you're referring to the pocketbeagle I guess? Jan 25 06:07:22 the pocketbeagle requires an external vbus power switch (controlled by drvvbus) to have a proper functioning usb port Jan 25 06:07:49 powering the hub from elsewhere will not solve your problem at all Jan 25 06:08:54 the problem is that the usb controlled is expecting to be able to switch vbus power, and it is monitoring the vbus voltage to verify this Jan 25 06:08:57 *controller Jan 25 06:09:56 ok, i guess the System Reference Manual for the pocketbeagle is confusing in regards to USB1 Jan 25 06:10:40 what does it say? Jan 25 06:11:01 ah, that Jan 25 06:11:13 jkridner: this is just plain wrong -> https://github.com/beagleboard/pocketbeagle/wiki/FAQ#How_do_I_get_additional_USB_connections Jan 25 06:11:34 er yeah, that. Jan 25 06:11:58 that extra 5V line is the problem I guess, it can't be simplified to that extent. Jan 25 06:12:52 and having to make DTB changes to switch it between host & guest rather than the ID pin working is a bit of a :/ Jan 25 06:13:00 jkridner: vbus needs a power switch controlled by drvvbus (P1.3), same as what's on every other beaglebone Jan 25 06:13:35 GrizzlyAdams: setting it to dual-role mode and using the id pin doesn't work? I think it should Jan 25 06:13:55 I guess you have no way to test right now really Jan 25 06:14:17 since you can't hotplug a device into it Jan 25 06:14:31 well I can, but i don't think it will swap modes. Jan 25 06:16:20 and I can't easily tell what is going on if I swap my usb cable from USB0 to USB1, though I could tail -f /var/log/* Jan 25 06:16:28 (on my lcd) Jan 25 06:16:51 it should, actually. if the mode is set to dual role in DT, and you don't connect vbus to vin (connect vbus only to the usb socket) Jan 25 06:17:01 but it will only work in device mode then Jan 25 06:17:12 it should however *try* to go into host mode if you plug in a device Jan 25 06:17:15 and fail with a vbus error Jan 25 06:17:24 even if the device is self-powered? Jan 25 06:17:37 there's no difference between bus- and self-powered devices Jan 25 06:17:45 they are required to behave the same electrically Jan 25 06:18:11 hmm. Jan 25 06:18:21 e.g. a device is not allowed to pull up D+/D- if no vbus is present Jan 25 06:18:44 ah, well behaved devices :D Jan 25 06:18:57 yes Jan 25 06:19:01 which the pocketbeagle at least should be Jan 25 06:19:39 that's part of the reason why the usb controller is rather fussy about vbus Jan 25 06:22:57 GrizzlyAdams: if you want a properly working host/otg port, you'll need something like the tps2051 that's used on the bbb Jan 25 06:23:08 ugh. Jan 25 06:23:40 also, I'd suggest adding a 100 μF capacitor on the *output* of that switch (that's missing on the bbb) Jan 25 06:25:12 (the bbb is known to have issues where hotplugging a device can cause a vbus error due to the inrush current) Jan 25 11:33:18 zmatt: how do you tell BBB to boot from eth? is it enough to pull P8.44 to GND? Jan 25 12:08:19 I pull P8.43 to GND, P8.45 to 3.3v Jan 25 12:11:31 Hello! Does anyone know how to enable cape on the latest debian without using and i2c eeprom? Jan 25 12:16:41 what do you mean? Jan 25 12:17:02 ok thanks zmatt, i check now Jan 25 12:20:22 I mean how can I enable cape (for instance LCD4) in uEnv.txt with eeprom disconnected (without i2c connection) Jan 25 12:23:59 in /boot/uEnv.txt you can just manually specify overlays to be loaded... I don't remember the exact name of the variable, but iirc it was pretty obvious when reading that file (there are also comments there to further help) Jan 25 12:25:04 if you show the contents of your /boot/uEnv.txt (use pastebin.com or similar paste site) I can tell you which setting is the one you need Jan 25 12:25:04 Yes, I follow them Jan 25 12:25:34 uboot_overlay_addr4=/lib/firmware/BB-BONE-LCD4-01-00A1.dtbo Jan 25 12:25:54 that the line I uncommented and modified (the only one) in uEnv.txt Jan 25 12:28:27 okay, but? Jan 25 12:29:03 https://pastebin.com/JT8v5zUp Jan 25 12:29:26 yes that looks fine to me Jan 25 12:29:50 (assuming the path is correct) Jan 25 12:30:16 the cape works with i2c line connected, and even if I disconnect them immedeatly after the booting, but if i2c disconnected during booting the cape never loads Jan 25 12:31:00 zmatt: does it matter if eMMC contains a boot image? Jan 25 12:32:08 Andrejs: do you have a /sys/devices/platform/bone_capemgr/slots file? Jan 25 12:32:55 yes, and there is no capes identified in it Jan 25 12:34:06 Andrejs: then u-boot overlays aren't working at all, most likely because an old version of u-boot is being used. if you're booting from sd card, try wiping eMMC with sudo blkdiscard /dev/mmcblk1 (assuming you don't care about its contents) to force the u-boot that's on sd card to be used instead Jan 25 12:36:25 microdevel: I did say explicitly that I had made no change to the boot script and that you'll probably want to customize it, and that I simply interrupted the boot script and manually executed dhcp && bootm as a quick test Jan 25 12:36:53 the default boot script will obviously still just try to load linux from sd card or eMMC Jan 25 12:37:57 zmatt: misunderstanding. i doubt my beagle tries to boot from emac1 at all because of sysboot config Jan 25 12:38:32 do you use a cape to set sysboot[4:0]? Jan 25 12:38:32 sysboot affects only from where the ROM bootloader tries to load SPL Jan 25 12:38:49 exactly and i want it to be loaded via tftp Jan 25 12:39:10 that's determined by sysboot Jan 25 12:39:12 and I used two wires Jan 25 12:40:40 if i use your wire config, sysboot should result in 00001? Jan 25 12:40:58 definitely not Jan 25 12:42:24 default is 11100. pulling P8.43 down (or pressing the S2 button) makes that 11000. pulling P8.45 up yields 11001 Jan 25 12:42:45 zmatt: well, I had such a hunch before (that the eMMC can cause troubles), but I'm trying to avoid it because the content is really valuable Jan 25 12:43:24 Andrejs: you can also bypass the bootloader on eMMC by powering up while holding down the S2 button (you can let go once the power led turns on) Jan 25 12:43:43 zmatt: this might be why my board fails to boot from eth Jan 25 12:43:46 zmatt: thanks, will try that Jan 25 12:43:50 11001b -> SPI0 MMC0 EMAC1 UART0 Jan 25 12:44:10 MMC0 already contains boot image (eMMC) Jan 25 12:44:12 or you can just wipe sector 256 of eMMC. that suffices to disable the bootloader, but it's easy to restore it Jan 25 12:44:17 microdevel: eMMC is mmc1 Jan 25 12:44:21 mmc0 is sd card Jan 25 12:44:39 unless you have a custom board, then you should obviously figure out a suitable sysboot yourself Jan 25 12:45:10 no, am using BBB for the moment Jan 25 12:45:54 then eMMC is mmc1, not mmc0 Jan 25 12:46:11 ok so this wont be the issue Jan 25 12:46:53 and you dont have to release pins after booting? just keep them as they are? Jan 25 12:47:37 as long as you don't try to boot a linux system that configures those pins as outputs Jan 25 12:47:49 for safety it's worth using resistors instead of wires Jan 25 12:48:09 ;) used 10k for that, no i am just looking to run uboot Jan 25 12:48:43 you're sure it's not trying to netboot? Jan 25 12:49:02 I mean, what's the symptom you're seeing? Jan 25 12:49:25 just doesnt query dnsmasq, and no console output on UART Jan 25 12:50:44 zmatt: thank you! The booting with S2 pressed worked. Jan 25 12:50:51 well it works for me. connect ethernet directly to a PC and check for bootp requests using a packet sniffer? Jan 25 12:50:55 Andrejs: you're welcome Jan 25 12:52:00 yes, this will be my next step to find the issu Jan 25 12:52:05 thanks for help Jan 25 12:52:19 zmatt: maybe you can suggest where one can learn more about uBoot and BBB bootloader, as I find eLinux to be extremely succinct? Jan 25 12:53:06 uh, not sure I have a good reference to point to Jan 25 12:54:16 ok, never mind, you helped me alot, thank you once again! Jan 25 12:59:55 zmatt: I was wrong kernel 3.8 doesn't support ext4 Jan 25 13:00:11 I tried with ext2 and it worked now Jan 25 13:00:21 ehm, it does support ext4 Jan 25 13:00:42 so why did it worked in ext2? Jan 25 13:01:28 why wouldn't it work with ext2? it's a really ancient filesystem that hasn't been changed since prehistoric times Jan 25 13:01:35 that doesn't make it a good idea to use it Jan 25 13:04:08 ext4 has been around since kernel 2.6.28 (october 2008) Jan 25 13:10:32 zmatt: got it working, had to install latest version of dnsmasq Jan 25 13:50:14 good Jan 25 14:48:36 zmatt: it's still not working with ext4 but it worked with ext3 Jan 25 14:51:37 did you try mkfs.ext4 with the options I suggested? Jan 25 14:52:10 (to make sure all features that were introduced after kernel 3.8 are disabled) Jan 25 14:52:38 no I didn't do that Jan 25 14:54:12 I created disk partition using gparted Jan 25 14:54:55 so I don't feel a need of mkfs.ext4 Jan 25 14:56:00 if it has a way to pass options to mkfs.ext4 then that's fine too of course Jan 25 14:58:12 can you check which features it enables if you format the partition as ext4 ? dumpe2fs -h /dev/whatever | grep features Jan 25 15:03:13 it says Jan 25 15:03:16 https://www.irccloud.com/pastebin/m6O5MkbD/ Jan 25 15:03:34 you forgot the partition number Jan 25 15:04:04 i.e. sdb1 or sdb2 (iirc you used a separate boot partition, so sdb2) Jan 25 15:04:34 https://www.irccloud.com/pastebin/GS8lT2fs/ Jan 25 15:15:30 journal_checksum_v3 is definitely a problem Jan 25 15:15:42 kernel 3.8 supports journal checksum v2 Jan 25 15:16:42 I was searching about the command to disable feature flags Jan 25 15:17:07 sorry it took a bit... for some reason e2fsprogs and the kernel use differently named constants -.- Jan 25 15:18:13 metadata_csum also needs to be disabled Jan 25 15:18:32 I think the rest is fine Jan 25 15:18:40 ohk, I will try Jan 25 15:21:41 hi everyone Jan 25 15:22:15 I have a question regarding OSD3358-SM-RED board if someone know it ... Jan 25 15:22:34 I can't manage to get UART4 working ... Jan 25 15:29:28 krish-iyer: apparently the problem is that when the metadata_csum feature is enabled on the filesystem, the kernel automatically enables journal checksum when you mount the filesystem unless you pass -o nojournal_checksum Jan 25 15:30:22 so disabling metadata_csum when formatting should also prevent journal_checksum_v3 (or any other version) Jan 25 15:36:59 krish-iyer: you can also remove the features after the filesystem has been created: https://pastebin.com/raw/JGvg1gaE Jan 25 15:38:01 yeah I am on that but how to parse partition dir to tune2fs Jan 25 15:38:39 follow the exact steps I did in my paste, except replace ext4-test.img by /dev/sdb2 Jan 25 15:39:02 make sure the filesystem is not mounted Jan 25 15:39:46 if file system is not mounted then there will not be a partition dir - "/dev/sdb2 Jan 25 15:39:54 ?? Jan 25 15:40:04 sorry, w Jan 25 15:40:11 I got it :D Jan 25 15:53:36 zmatt:after that I disabled 64bit and resized to 32 bit Jan 25 15:54:07 -sudo resize2fs -s /dev/sdb2 Jan 25 15:54:41 it crashed even after disabling " metadata_csum " Jan 25 15:54:49 there shouldn't be any need to disable 64bit Jan 25 15:55:11 what does dumpe2fs say about which features are enabled, and what does the kernel log say? Jan 25 15:55:33 it can't be about unsupported journal features, the steps I gave should leave all journal features disabled Jan 25 15:56:32 hello people Jan 25 15:57:44 I'm working on bb blue and trying to make work some roboticscape examples Jan 25 15:57:46 yeah, you are right Jan 25 15:58:09 earlier I had only disable metadata_csum Jan 25 15:58:15 I updated my bb to last version Jan 25 15:59:02 but when I try to run an example, I get the error ; ERROR:pru-rproc driver missing Jan 25 15:59:18 sorry for bothering and thanks for the help :) Jan 25 15:59:32 elcrcp: in the latest images you can choose whether you want to have remoteproc-pru of uio-pruss enabled in /boot/uEnv.txt Jan 25 16:00:13 I thought remoteproc-pru was the default but I'm not really sure, maybe it isn't Jan 25 16:00:14 and I couldn't solve this for hours, does anyone knows how to solve this problem? Jan 25 16:00:32 I'll check right now Jan 25 16:00:38 which image did you install exactly/ Jan 25 16:00:40 ? Jan 25 16:01:00 Debian 9.1 2017-08-31 4GB SD LXQT Jan 25 16:01:10 wrong image Jan 25 16:01:32 uh why? Jan 25 16:01:41 grab the first download on https://bbb.io/latest-images Jan 25 16:02:44 the lxqt image is just provided for people who really want a desktop environment via hdmi output... but the image lags behind the iot (non-gui) image, and the bbblue doesn't have hdmi output in the first place Jan 25 16:03:31 I didn't think that Jan 25 16:04:06 ok! I'll flash my card with IoT image Jan 25 16:04:21 thanks for your help Jan 25 16:04:38 uhm by the way Jan 25 16:04:58 after flashing with IoT image and apt-get upgrade Jan 25 16:05:09 also, I recommend either flashing the image to emmc (see instructions below the download links) or wiping eMMC using sudo blkdiscard /dev/mmcblk1 Jan 25 16:05:27 this to avoid trouble when eMMC contains an older bootloader Jan 25 16:05:33 should I touch anything to run examples of roboticscape Jan 25 16:05:53 I don't really know anything about roboticscape Jan 25 16:06:50 ok thakns for your help, I should try first and ask later =) Jan 25 16:07:10 I'm around fairly regularly Jan 25 16:39:22 zmatt: how is it wrong? Jan 25 16:39:52 zmatt: power drive based on drvvbus would be nice.... Jan 25 16:39:56 but not needed for it to function. Jan 25 16:40:28 to have it would cause it to handle an error condition it cannot otherwise handle. Jan 25 16:41:03 my understanding is that it is required to be able to hotplug usb devices, and that also seems to be the experience of those who tried it Jan 25 16:42:29 hmmmm..... not sure why it'd be required for hotplugging. Does the processor only enable DRVVBUS after seeing a single-ended event? Seems odd to me. Jan 25 16:43:19 Don't know how you could count on a peripheral device to produce any load on the line if DRVVBUS wasn't already set. Jan 25 16:44:53 no I think it just briefly wants vbus to go low for "session end" ... I'd need to dig for the details Jan 25 16:45:03 it has to do with the complicated state machine for otg Jan 25 16:47:14 zmatt: that'd be ugly, especially since I'd expect it could all be easily handled internally. laziness is a possibility. Jan 25 17:05:47 hm, this is interesting Jan 25 17:13:14 I tried to reproduce it here by configuring drvvbus as default-high gpio (which is applied way before the usb driver loads) Jan 25 17:13:30 but that seems to work fine for me Jan 25 17:14:22 weird... I've had multiple reports here that it didn't, and am pretty sure I'd seen similar behaviour myself when I did some testing (which was quite some time ago though) Jan 25 17:16:37 next time someone is here with this issue I'll be sure to check which kernel version they're using, maybe this used to be an issue but has been fixed Jan 25 17:57:15 rcn Jan 25 18:17:50 hello again guys Jan 25 18:18:54 so, I was testing beaglebone blue outputs such motor output sockets Jan 25 18:19:27 I tried to obserwe pwm signals on oscillascope Jan 25 18:20:10 but interestingly, motor pwm signal levels were about 100mV Jan 25 18:20:38 I didn't connect 12v supply, only power it got is usb2 connection with pc Jan 25 18:20:48 could this be the reason ? Jan 25 20:33:04 bone-debian-9.1-lxqt-armhf-2017-08-31-4gb.img on the beaglebone black. Is 'sudo apt-get install package' how you install software on the bbb? Jan 25 21:46:34 yeah pretty much. This uses the Debian package repositories. Jan 25 21:53:20 doesn't "sudo apt install [package]" work on those too or is it not recent enough? Jan 25 23:42:44 yeah I think just apt is the preferred way Jan 26 02:55:32 anyone use Ubuntu internet connection sharing? Jan 26 02:55:59 I'm trying to use it to get Internet access on PocketBeagle **** ENDING LOGGING AT Fri Jan 26 03:00:02 2018