**** BEGIN LOGGING AT Sat Sep 10 02:59:58 2016 Sep 10 08:35:30 Hi all! I can't find any info online about booting the bbb from eMMC while leaving the root partition on external storage. I want this to get the boot speed of eMMC without having the rootfs size limited to 4GB. Is there any reason this wouldn't work / is a bad idea? It looks like I'd just need to tell Linux where to find the reports by modifying the boot args. Thanks! Sep 10 08:42:13 hi Sep 10 08:42:25 wotfan: USB rootfs ? Sep 10 08:42:33 check this out http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/ Sep 10 08:44:38 iskander: thanks for the link. I don't want to boot from USB, I just want to have my root partition on it. So /boot lives on the eMMC. Or is this totally pointless? Sep 10 08:45:26 it's the same, just load your kernel from eMMC but mount the rootfs from USB Sep 10 08:45:42 modify uboot config to load kernel from eMMC Sep 10 08:47:03 Cool, and then mount the eMMC at /boot Sep 10 08:47:18 yeah Sep 10 08:47:27 Thanks, I'll give it a try Sep 10 08:47:36 np Sep 10 08:47:47 How quick is USB boot btw? Sep 10 08:48:24 no idea, i haven't tested it yet, only sd card and eMMC Sep 10 08:49:02 Ok. Yeah, I don't have the patience for sd card boot times ;) Sep 10 08:49:52 booting is OK :) writing an image to sd card is a pane Sep 10 09:11:11 hi Sep 10 09:11:28 anyone there? Sep 10 09:13:49 hi Sep 10 09:15:36 I am working with beaglebone black Sep 10 09:15:51 and when I connect it via usb and without sd card Sep 10 09:15:56 it's not booting up Sep 10 09:16:37 when I observed .. I saw only usr1 and usr3 led is constant staying on and frequently it's getting rebooted. Sep 10 09:17:20 can anyone here help me what is happening here. Sep 10 09:20:42 Hinesh: you would need to attach to the debug serial port to investigate this. Sep 10 09:34:37 Hinesh: boot with sd card and check the eMMC partitions Sep 10 09:46:13 hi all. I want to connect to wifi adapters to my beagle bone black. should I use an USB hub with external power supply, or is it okay to use one without external power supply? Sep 10 09:46:26 these are the wifi adapters (2 of the same kind): http://www.tp-link.us/products/details/TL-WN722N.html Sep 10 09:46:45 I could not find any information on how much power the draw... Sep 10 09:46:51 thx in advance :) Sep 10 09:54:58 hello Sep 10 09:55:22 I have connected the debug cable Sep 10 09:55:44 @tbr : I have attached debug cable Sep 10 09:55:56 r u thre? Sep 10 09:59:01 Hinesh: well, and what is the output if you boot it without SD card? Sep 10 09:59:05 use a pastebin! Sep 10 10:00:17 i came here to find dogs Sep 10 10:01:53 nebul8: one is usually already on the edge, I'd recommend a powered hub. Sep 10 10:03:30 ok Sep 10 10:03:50 if I boot from SD it's.. its booting Sep 10 10:04:11 but while booting form sd I am only geting usr1 and usr3 led constand ON Sep 10 10:04:33 Hinesh: you claim to have the debug cable attached. What is the output? Sep 10 10:04:42 after 4-5 minutes board gets restarted. but I am not able to coneect with any terminal Sep 10 10:04:47 it's problem Sep 10 10:05:11 what sort of debug cable are you using and which terminal emulation software? Sep 10 10:05:22 I do. But When I boot from eMMC Sep 10 10:05:38 Cable :- USB. Terminal. :- TeraTerm Sep 10 10:05:52 booting from eMMC not working Sep 10 10:05:54 what's on the other end of the USB cable? Sep 10 10:06:08 My laptop runnig with win 8. Sep 10 10:06:11 with drivers. Sep 10 10:06:14 and on the other end? Sep 10 10:06:16 tbr: thx. Sep 10 10:06:22 np Sep 10 10:06:44 where does the cable attach to the beaglebone? Sep 10 10:07:05 P4 port Sep 10 10:07:56 usb cable one end to beaglebone ( p4) and one end to laptop with win8 running Sep 10 10:08:04 *zonk* Sep 10 10:08:12 the debug port is J1 Sep 10 10:08:22 you need a USB-to-UART cable for that Sep 10 10:08:53 http://www.dizzy.co.za/images/embest/BBB_Detail.jpg Sep 10 10:09:15 ok Sep 10 10:10:15 after connecting to the cable then? Sep 10 10:11:07 do you own such a cable? Sep 10 10:28:02 I ll make one Sep 10 11:14:24 note that such a "cable" isn't a cable, it contains a small PCB Sep 10 11:15:33 see http://elinux.org/Beagleboard:BeagleBone_Black_Serial Sep 10 12:24:45 ya Sep 10 12:25:02 I understood . but I will make one the converter. Sep 10 12:25:30 by the way. I trace that I have made changes in device tree file . Sep 10 12:25:45 and I have overwrited the main file. Sep 10 12:25:56 that May be the reason Sep 10 12:26:02 i guess Sep 10 12:31:20 quite likely, yes. You'll find out more once you have a cable. That's pretty much a hard requirement for messing with kernel/u-boot Sep 10 12:31:50 in the interim you can ofc try to fix things by booting from microSD and mounting the emmc Sep 10 14:31:29 What's the ideal way to flash binary to the PRUs on a black. Sep 10 15:00:15 impatient... Sep 10 15:00:33 he got flashed, by a beagle Sep 10 15:17:11 helo folks Sep 10 15:17:57 I receive my beagleboard yesterday Sep 10 15:19:19 I'm very excited but when I conect de external supply the external supply the board going to shutdown Sep 10 15:19:59 I don't found help in the faq's or forums Sep 10 15:20:22 I'm very disapointed with the isue Sep 10 15:21:05 any body can helpme? Sep 10 15:22:47 which board exactly, what are the specs of the supply, what exactly are the symptoms you're seeing Sep 10 15:24:09 beaglebone black Sep 10 15:24:33 Ok thanks zmatt for your interest Sep 10 15:25:00 I conect the board to computer trough usb and Sep 10 15:25:06 all goes well Sep 10 15:25:21 I have ssh etc Sep 10 15:25:36 but when I try to add a 5V 2A (checked) Sep 10 15:25:51 the board go to shutdown Sep 10 15:26:02 I see the mesage on the linux console Sep 10 15:26:34 the board reboot but I can't login again trough ssh Sep 10 15:29:14 ok, that sounds all sorts of weird, you're actually seeing a shutdown message? Sep 10 15:29:41 what happens if you connect only the adapter? Sep 10 15:29:53 could be the PMIC getting confused? Sep 10 15:30:00 nothing the board don't boot Sep 10 15:30:19 the blue led marked pwr near the externa conector Sep 10 15:30:30 had that, too Sep 10 15:30:39 is on and off Sep 10 15:30:48 got a shutdown message Sep 10 15:30:50 blink one time Sep 10 15:31:05 is a normal shutdown message linux Sep 10 15:31:09 rattinp: ok so the pmic comes briefly up but then powers down Sep 10 15:31:16 the system go to shutdown now Sep 10 15:31:20 ..etc Sep 10 15:31:37 the mesage says Sep 10 15:31:48 I'd suspect the power supply being either too high or too low in voltage Sep 10 15:32:01 is 5.25V Sep 10 15:32:03 the shutdown message suggests a similar thing: it sees power, then sees power pulled out; for some reason the pmic driver sends a "power button" message to userspace if you disconnect ac adapter while still powered via usb (annoying issue) Sep 10 15:32:29 yea it's anoyng :) Sep 10 15:32:34 but very strange Sep 10 15:33:21 the shutdown in response to seeing an 5V adapter disconnect (while still powered via USB) is just a driver issue though Sep 10 15:33:42 I go to try with another image Sep 10 15:33:52 but it's seeing a 5V disconnect, i.e. same thing that's happening when you use only the adapter Sep 10 15:34:05 what sort of power supply is that? Sep 10 15:34:18 when you conect only the adapter the board don't boot Sep 10 15:34:31 right, because it almost immediately gets shut off Sep 10 15:34:32 just light one time the blue led (pwr) Sep 10 15:34:45 I'd try with a different power supply Sep 10 15:34:58 yeah it sounds like some sort of problen with the supply, hard to say what Sep 10 15:35:16 could also try to add a beefy capacitor. Maybe the initial transient upsets it? Sep 10 15:35:18 I reply the erro now Sep 10 15:35:23 the msg say Sep 10 15:35:29 Power button pressed Sep 10 15:35:38 the system go to shutdown now Sep 10 15:35:43 yes, that's what I said Sep 10 15:36:07 the pmic is reporting: 5V connected; 5V disconnected Sep 10 15:36:10 can you tell us more about that power supply? Sep 10 15:36:13 and on the second event a shutdown is triggered Sep 10 15:36:27 the root problem is that the 5V adapter is just not working Sep 10 15:36:40 * tbr agrees Sep 10 15:36:51 (i.e. you can fix the shutdown with a simple workaround, but then you're still just running off USB power and not the adapter) Sep 10 15:37:19 the problem also isn't inrush current since there shouldn't be any when switching from usb power to 5V adapter Sep 10 15:37:34 yes I want to conect a wirless and other peripherals on the usb Sep 10 15:37:44 use a powered usb hub Sep 10 15:38:12 Ok thanks a lot zmatt Sep 10 15:38:32 I try to boot with another image Sep 10 15:38:41 my first guess would be that the adapter actually can't deliver the necessary current Sep 10 15:38:48 first and continue investigate Sep 10 15:38:52 that is not useful Sep 10 15:39:24 I use the adapter with other board and looks good 2A Sep 10 15:39:50 but I go to try with another adapter might be the conector is the problem Sep 10 15:40:15 Ok thanks a lot good weekend from Uruguay Sep 10 15:41:24 right, if the barrel connector has a too large inside diameter, it might just briefly touch Sep 10 15:41:46 also an interesting option indeed Sep 10 15:42:05 that would explain the immediate loss of 5V Sep 10 15:42:35 Yes I have similar isue with others devices in the past I go to try with another adapter and tell if works Sep 10 15:59:45 much better... small kernel patch and one udev rule later I have symlinks /dev/gpio/$label -> /sys/class/gpio/gpio$n (where $label is given in DT) with proper permissions setup to avoid any need for root access Sep 10 16:11:24 neat Sep 10 16:11:49 still going to do a few more simple improvements to the sysfs node Sep 10 17:31:14 Just reflashed my bbg with the latest official beaglebone image, and I can't find the MLO and u-boot.img files. Nothing in /boot, and only one partition on the eMMC. What am I missing? Sep 10 17:35:32 wotfan: those are now in the raw space at the beginning of the device Sep 10 17:35:44 at least MLO Sep 10 17:44:54 Ah, okay. Any info about that online? Sep 10 17:56:26 wotfan, http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 Sep 10 18:02:25 Ahh haha cool, dd'd straight to the drive. And if there is a /uEnv.txt it takes precedence over /boot/uEnv.txt Sep 10 18:02:37 tbr: uboot too Sep 10 18:02:40 wotfan: it loads both Sep 10 18:02:53 zmatt: yeah, wasn't sure about u-boot Sep 10 18:03:28 zmatt: oh okay Sep 10 18:03:30 with a different options to 'env import' for /uEnv.txt as for /boot/uEnv.txt .. never bothered to look up what that option does Sep 10 18:06:04 Okay so whatever disk u-boot.img is found on, it looks for uEnv.txt? Sep 10 18:08:17 it has a fairly complicated boot script Sep 10 18:09:25 zmatt: Hmm okay. Thanks for the info. Just trying to sort all this out in my head! Sep 10 18:23:04 wotfan: could you check which uboot version you're using? Sep 10 18:23:09 dd status=none if=/dev/mmcblk1 skip=$(( 768 )) count=1 | strings Sep 10 18:23:34 (replace mmcblk1 by mmcblk0 if that's your eMMC) Sep 10 18:23:54 oh sorry for the silly unnecessary $(( )) Sep 10 18:26:06 Yep, 2016.03-00001-gd12d09f Sep 10 18:27:49 My serial boot log looks very similar to RobertCNelson's gist:98f6d2... Sep 10 18:28:00 zmatt: why do you ask? Sep 10 18:30:18 well if you interrupt boot you can type printenv to get all environment vars including the boot scripts, but you'll get a huge unreadable blob of text vomited across your terminal. since I wanted to know some details about current boot scripts myself and have experience cleaning that output up somewhat I figured I'd take a look Sep 10 18:30:48 2016.03 is a bit older version though, latest jessie snapshots use v2016.09-rc2 Sep 10 18:36:38 Oh oops, I'm on the 2016-05-13 debian image Sep 10 18:37:21 I intended to be on the latest weekly. Oops Sep 10 19:50:52 ok wow, that's unintuitive... so active_low does actually work, though declaring gpios as such in gpio_helper was broken, and moreover the initial level when configuring a pin as output (via gpio_helper or via sysfs) is the raw level ignoring active_low Sep 10 20:00:52 zmatt: in what context? Sep 10 20:08:48 what do you mean in what context? Sep 10 20:16:11 What was broken / where? Sep 10 20:43:03 I I mentioned what was broken where Sep 10 20:43:35 declaring gpios as active-low in gpio_helper is broken (it ignored the gpio flags entirely) Sep 10 20:44:45 and more confusion was created by the inconsistency between initializing the level when changing direction to output versus setting the value after it is output, but this appears to be Working As Designed™ rather than a bug Sep 10 20:48:33 the patches I did so far to the gpio sysfs interface or gpio-of-helper are patches 0005-0009 here -> https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.8/patches/gpio Sep 10 20:48:57 0007 is a bug fix, the rest is just enhancement Sep 10 20:55:53 Ahh right, cool, nice one. Yep the output init value is a bit unintuitive Sep 10 21:03:14 How can I add the bone_capemgr in yocto build? Sep 10 21:06:20 or how can I load a dtb that doesn't seem to be loading Sep 10 21:09:04 does this mean that there are multiple partitions on the BeagleBone? Sep 10 21:09:05 $ sudo fdisk -l | grep "Disk /dev/" Sep 10 21:09:05 Disk /dev/mmcblk1: 3.7 GiB, 3909091328 bytes, 7634944 sectors Sep 10 21:09:05 Disk /dev/mmcblk1boot1: 2 MiB, 2097152 bytes, 4096 sectors Sep 10 21:09:05 Disk /dev/mmcblk1boot0: 2 MiB, 2097152 bytes, 4096 sectors Sep 10 21:09:40 do df -h it will list them Sep 10 21:09:41 how can I see what is on those other 2MiB partitions? (curiosity) Sep 10 21:10:07 df -h does not list them -- probably because they're not mounted? Sep 10 21:10:37 it's an sd card? Sep 10 21:10:40 Google "mmc-dev-parts txt" Sep 10 21:10:44 eMMC Sep 10 21:11:16 StephaneCharette: you can hexdump them but most likely they'll be full of zeros Sep 10 21:11:36 thanks, wotfan Sep 10 23:55:11 how can I disable HDMI on beaglebone black? Sep 11 00:09:18 Change dtb in /boot/uEnv.txt Sep 11 00:12:35 Or you can add this to that file capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN Sep 11 00:14:28 cat /sys/devices/platform/bone_capemgr/slots Sep 11 00:14:43 should show it's disabled Sep 11 00:15:13 should have an O flag at the begin Sep 11 00:16:05 I can't get this to work on bbb latest debian rev, but image from 7/2015 works Sep 11 00:49:38 /boot/uEnv.txt contains updated instructions for 4.x kernels Sep 11 00:49:55 you select a different main dtb Sep 11 01:56:08 http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration#Disabling_eMMC_or_HDMI Sep 11 02:00:46 in the uEnv.txt file it gives examples for kernel 4.1.x, which allowed #cape_disable=bone_capemgr.disable_partno= seems maybe that has changed in 4.4 Sep 11 02:01:47 no, that line is highlighting that capemgr.disable_partno (in 3.8) has changed to bone_capemgr.disable_partno (in 4.x) Sep 11 02:02:35 either way when I disable it doesn't show up disabled when I cat /sys/devices/platform/bone_capemgr/slots Sep 11 02:03:08 it only shows me 4 slots, and the 4th one is 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,univ-all Sep 11 02:03:28 I'm having a hard time getting my can cape to work Sep 11 02:03:48 that's cape-universal, disable it by removing the option that enables it from cmdline in /boot/uEnv.txt Sep 11 02:07:09 bone_capemgr bone_capemgr: loader: failed to load slot-0 TT3201-001:01 (prio 0) Sep 11 02:07:28 you disabled cape-universal and rebooted? Sep 11 02:07:35 yup Sep 11 02:08:00 it lists my device in bone_capemgr/slots Sep 11 02:08:32 but Something Went Wrong™, and capemgr is ever so informative with its error messages :P Sep 11 02:08:48 I don't see a dtbo file the cape Sep 11 02:09:21 I can get it to work on 3.8 kernel Sep 11 02:09:37 if you echo a name into slots it will look for a dtbo in /lib/firmware/ Sep 11 02:10:27 http://wiki.beyondlogic.org/index.php?title=BeagleBoneBlack_Cape_Manager Sep 11 02:10:36 I don't get lines 4 and 5 Sep 11 02:10:50 I've tried echo before Sep 11 02:11:27 they're not supposed to be there on a 4.x kernel, that page is wrong Sep 11 02:12:09 ok Sep 11 02:13:53 I don't think there is a dts for a this cape Sep 11 02:14:42 I'm pretty sure there are only custom dtb files for a few really invasive capes that couldn't be done conveniently with an overlay Sep 11 02:16:01 https://github.com/jadonk/cape-firmware/blob/master/arch/arm/boot/dts/TT3201-001-01.dts Sep 11 02:16:07 I find this dts Sep 11 02:17:23 dtc -O dtb -o TT3201-001-01.dtbo -b 0 -@ TT3201-001-01.dts Sep 11 02:17:31 I copy that to the /lib/firmware Sep 11 02:18:38 [ 656.698614] bone_capemgr bone_capemgr: slot #7: 'Override Board Name,00A0,Override Manuf,TT3201-001' Sep 11 02:19:14 but /sys/devices/platform/bone_capemgr/slots show it in slot 0 Sep 11 02:20:30 well I'd assume bone_capemgr is just being silly. better question, does it seem to have worked? Sep 11 02:23:58 I have a script that can be useful to verify pin configuration: show-pins in https://github.com/mvduin/bbb-pin-utils Sep 11 02:25:24 it doesn't seem to work Sep 11 02:25:34 if I do ifconfig -a it doesn't show my can channels Sep 11 02:26:18 http://pastebin.com/FCDQ3E72 Sep 11 02:26:35 yeah nothing has happened Sep 11 02:27:08 maybe dts, I dunno Sep 11 02:27:17 needs updated* Sep 11 02:27:27 it looks like the cape has a few separate bits, e.g. can Sep 11 02:30:24 try grabbing my https://github.com/mvduin/overlay-utils Sep 11 02:30:53 make can1.dtbo && sudo bin/add-overlay can1.dtbo Sep 11 02:32:16 like so? dtc -O dtb -o can0.dtbo -b 0 -@ can0.dts Sep 11 02:33:03 no I said "make can0.dtbo" Sep 11 02:33:07 there's a makefile in that project Sep 11 02:33:44 I rely on preprocessing to make writing overlays a lot less painful Sep 11 02:34:30 [ 880.753219] of_resolve_phandles: Could not find symbol 'pinctrl' Sep 11 02:34:30 [ 880.759542] create_overlay: Failed to resolve tree Sep 11 02:34:50 ah that's my bad, I added the two can examples a bit too hastily Sep 11 02:35:23 this is one of the reasons I never use overlays personally... no compile-time error checking :P Sep 11 02:35:51 (when compiling a normal dtb you'd get a missing reference error) Sep 11 02:36:44 device tree and overlays is all new to me Sep 11 02:38:09 ok, I've pushed the fix Sep 11 02:39:28 well, overlays are just runtime patches onto the device tree... that means however they need be able to reference nodes in the main device tree Sep 11 02:39:51 as a result, dtc just assumes any reference to anything is okay Sep 11 02:40:06 you'd hope the kernel would give an informative error on loading such a dtbo though :/ Sep 11 02:40:13 root@beaglebone:~/overlay-utils# [ 1216.111755] pinctrl-single 44e10800.pinmux: pin 44e1097c.0 already requested by 4819c000.i2c; cannot claim for 481cc000.can Sep 11 02:40:14 [ 1216.123232] pinctrl-single 44e10800.pinmux: pin-95 (481cc000.can) status -22 Sep 11 02:40:14 [ 1216.130506] pinctrl-single 44e10800.pinmux: could not request pin 95 (44e1097c.0) from group can0 on device pinctrl-single Sep 11 02:40:14 [ 1216.141840] c_can_platform 481cc000.can: Error applying setting, reverse things back Sep 11 02:40:40 you tried can0, not can1 :P Sep 11 02:41:02 can0 is one the same pins as the capemgr i2c Sep 11 02:41:43 ok can1 no errors Sep 11 02:41:48 yay Sep 11 02:43:11 but doesn't seem to work Sep 11 02:43:23 it ought to Sep 11 02:43:38 what do you see in kernel log? Sep 11 02:44:29 c_can_platform 481d0000.can can1: setting BTR=1c05 BRPE=0000 Sep 11 02:45:29 I'm just not seeing anything on the other end of the bus Sep 11 02:45:50 so the can interface did come up? Sep 11 02:46:01 yea shows it up Sep 11 02:46:15 ok, check with show-pins whether the pins indeed got muxed Sep 11 02:47:02 yeah pins p9.26 and 24 Sep 11 02:47:42 you're sure you got the right port of the three, since it apparently has three can interfaces? Sep 11 02:48:01 http://www.towertech.it/en/products/hardware/tt3201-can-cape/manual/ Sep 11 02:48:05 (one via can1 on the bbb, two implemented using mcp2515 spi controllers) Sep 11 02:48:06 I'm going by the manual Sep 11 02:48:22 for 3.8+ kernels, unless it's shifted again Sep 11 02:48:46 that numbering is entirely unpredictable unless you use udev rules to fix it into stone Sep 11 02:48:51 whichever interface comes up first is can0 Sep 11 02:49:25 using an udev rule to fix that is not hard though Sep 11 02:52:02 I'd guess "CAN3" is the one Sep 11 02:52:19 I tried all 3 and no go Sep 11 02:52:34 hmz Sep 11 02:52:46 I know can works on recent kernels, we use it too **** ENDING LOGGING AT Sun Sep 11 02:59:58 2016