**** BEGIN LOGGING AT Sat Mar 24 03:00:01 2018 Mar 24 03:23:59 kenrestivo: yup :/ Mar 24 03:24:24 you also cursed with hearing that's annoyingly good in the upper range of the spectrum? Mar 24 03:27:28 the buck converters on the beaglebone (part of the pmic) are a good example of how it should be... 2.25 (±0.3) MHz Mar 24 03:28:05 they do switch to PFM mode if little power is being drawn from them, but that can be disabled via i2c Mar 24 03:35:00 the power management chip on the beaglebone is a thing of beauty Mar 24 03:35:09 lol, no Mar 24 03:35:15 it's weird and buggy Mar 24 03:35:30 really? i like it. compared to the powermanagement on a raspberry Mar 24 03:35:33 which is... NOTHING. Mar 24 03:35:45 TI has definitely made better pmics Mar 24 03:36:09 maybe it's time for a board rev Mar 24 03:36:38 what does the rpi use as pmic? Mar 24 03:38:19 ah it has an integrated pmic Mar 24 03:38:26 completely undocumented no doubt Mar 24 03:41:27 .. or? hmm, bit unclear Mar 24 03:41:58 oh well, don't care Mar 24 05:43:34 it doesn't seem to have one at all Mar 24 05:43:39 anyway, back on topic Mar 24 05:43:46 gpios = <&gpio3 21 1>; <--- how do i interpret this? Mar 24 05:44:07 what do those two numbers represent? 21 and 1? guessing 21 is the io 3.21. but what's the 1? Mar 24 06:02:42 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/include/dt-bindings/gpio/gpio.h#L14 Mar 24 06:03:33 it's annoying when people write magic values instead of using macros for these things Mar 24 06:04:48 thanks Mar 24 06:09:08 i ended up with https://gist.github.com/kenrestivo/6cc6a0f14bfda09a918e873897546fae but get __of_adjust_tree_phandle_references: Illegal property (size) 'fixup' @/__local_fixups__ Mar 24 06:10:02 eh? Mar 24 06:10:05 the pinmux part throws no errors. the keypad does Mar 24 06:10:18 when doing add-overlay from overlay-tools Mar 24 06:10:32 dmesg complains " __of_adjust_tree_phandle_references: Illegal property (size) 'fixup' @/__local_fixups__" Mar 24 06:12:41 that's the only error you're getting? Mar 24 06:12:52 which kernel version? Mar 24 06:15:41 is it possible you have a weird dtc version? it looks like this error indicates a malformed dtbo Mar 24 06:16:42 that makes sense Mar 24 06:17:07 i'm compiling dtbos on my desktop, and scp'ing over to the bone Mar 24 06:17:16 will try compiling using the dtc on the bone instead Mar 24 06:17:29 well that shouldn't matter Mar 24 06:17:36 as long as it's a suitable version of dtc Mar 24 06:18:03 desktop: Version: DTC 1.4.0-gf345d9e. bone: ersion: DTC 1.4.4 Mar 24 06:18:38 perhaps it matters Mar 24 06:18:51 I don't know which version is old and which isn't Mar 24 06:20:41 cpp -nostdinc -undef -x assembler-with-cpp -D__DTS__ -I include uart4.dtsi -pipe | bin/dtsi-to-overlay \ Mar 24 06:20:43 | dtc -@ -q -I dts -O dtb -o uart4.dtbo Mar 24 06:20:55 gives "dtc: invalid option -- '@'" Mar 24 06:21:11 that's definitely a wrong version of dtc then Mar 24 06:21:13 after upgrading to 1.4.2 Mar 24 06:21:25 you need one with overlay support Mar 24 06:21:37 makes sense, thanks Mar 24 06:23:25 that worked, thanks! Mar 24 06:24:46 now i have to resolve the pin conflict, but i'm on solid ground now, thanks again Mar 24 06:24:49 pinctrl-single 44e10800.pinmux: pin 44e109ac.0 already requested by ocp:P9_25_pinmux; cannot claim for keypad Mar 24 06:25:02 you probably have cape-universal enabled Mar 24 06:25:11 probably, can i turn it off? Mar 24 06:25:16 yes Mar 24 06:25:31 in uEnv.txt, i suppose? Mar 24 06:25:34 yep Mar 24 06:26:02 if you're using a recent image, comment out the "enable_uboot_cape_universal=1 Mar 24 06:26:04 " line Mar 24 06:26:13 i see it, done. Mar 24 06:27:28 holy crap, it worked! Mar 24 06:33:25 i'm getting keyboard events. beautiful. Mar 24 06:47:08 hurray :) Mar 24 09:45:55 hello Mar 24 09:46:11 i am new to beaglebone black Mar 24 09:46:39 can anyone please help me with the default login id ans pass Mar 24 09:50:12 if it's the standard debian image then it's 'debian' and 'temppwd' IIRC Mar 24 09:55:41 i tried it Mar 24 09:55:47 it is not working Mar 24 09:57:09 neiter the root and blank password is working nor debin and temppwd is letting me login Mar 24 09:58:31 did you just flash this image? Mar 24 09:58:49 or has that installation been used by someone else previously? Mar 24 10:00:19 i just flashed the image using etcher Mar 24 10:00:45 which image did you flash to the SD car… Mar 24 10:00:48 oh well Mar 24 11:37:46 join Mar 24 11:38:39 hi Mar 24 11:40:38 i need help for write a LED blink.py code python in beaglebone white..after reboot can not run the code that is not blink the LED...i put intial #! /usr/bin/python .. Mar 24 11:40:56 pls help Mar 24 11:57:59 i write a LED code for python as well as c after reboot not working LED...using beaglebone..pls help me.. Mar 24 17:24:30 hello all, Mar 24 17:24:42 a generic c/c++ question here, Mar 24 17:25:47 I am receiving data from a bunch of sensors, and I wanted to store that data in a file so that i can plot it later. The data retrieval loop will be run 100K times and I will be storing all the data points in the text file Mar 24 17:25:54 what is the best way to log this data continuously Mar 24 17:26:05 best as in, most efficient, without doing any fancy multithreading Mar 24 18:34:30 what's the best way to do config-pin early on? Mar 24 18:38:36 Anyone know about this? I have a problem where my beaglebone is connected to my LCD and as soon as the BB starts booting up I get gibberish on the screen. Eventually I have a shell script that runs that does config-pin on the lcd pins, setting them to GPIO (not totally sure this step is necessary), then when my software app starts up, it successfully prints expected messages to the LCD. I want to stop the gibberish Mar 24 18:52:04 hello everyone, anyone has got an adafruit pca9685 PWM board working on a bbbgreen ? Mar 24 18:53:50 I'd like to have the sysfs overlay to control it... modprobe pwm-pca9685 works , but that's it ... i don't know how to move on Mar 24 18:53:54 any suggestions? Mar 24 19:59:02 (suggestion: stick around after asking a question) Mar 24 20:16:04 Hi folks, hoping someone can help with a dnsmasq-dhcp question Mar 24 20:16:35 trying to connect usb to bbb and never receive dhcp for my PC's interface Mar 24 20:16:55 I hooked up a switch and was able to ssh in and then journalctl -f Mar 24 20:17:17 and noticed it's only advertising in the range 192.168.7.1-192.168.7.1 Mar 24 20:17:56 I tried to expand this range by editing /etc/dnsmasq.conf but no dice Mar 24 21:05:39 what's the best way to change the default pin mux mode on startup? Mar 24 21:07:38 if you're using cape-universal you can put your config-pin calls in /etc/rc.local although it's ran fairly late in the boot process. you could also make a separate service for it that's run earlier Mar 24 21:09:07 it can be set considerably earlier when you use an overlay instead of cape-universal since the current images use u-boot overlays, which means that pinmux will probably get applied before userspace is even up (depending a bit on which driver the pinmux is attached to) Mar 24 21:09:20 what is cape-universal ? Mar 24 21:09:48 it's a universal overlay that enables most peripherals and allows pinmux to be configured at runtime Mar 24 21:09:55 I've been seeing a lot about using overlays with uEnv.txt but I don't know what an overlay is Mar 24 21:10:15 an overlay is basically a patch for the device tree Mar 24 21:10:44 originally they were applied at runtime, although that's been deprecated and nowadays u-boot applied them to the DT before passing it to the kernel Mar 24 21:11:18 they're being used to keep the device tree modular instead Mar 24 21:11:29 I have an MCU alongside my BB and the MCU is writing to an LCD but once the BB starts up, which is also wired to the LCD, the pin defaults are sending garbage to the LCD. Once I config-pin those pins correctly, I can take control from the MCU for the LCD or hand control back. I would like to do the config-pin as early as possible to avoid the interim garbage state Mar 24 21:12:00 that makes sense except I'm not sure what a device tree is Mar 24 21:12:26 is it a C-level definition of the hardware layout and mux modes? Mar 24 21:12:40 and an overlay is a text file that the kernel applies (patches) on startup? Mar 24 21:12:41 use 1K-10K resistors to pull the lines in the correct direction. that works immediately from power on up to the moment the pins can be configured correctly Mar 24 21:13:32 it's a description of the hardware used by the kernel to know which platform devices exist and which drivers they need (along with some driver configuration sometimes) Mar 24 21:13:36 they're not text Mar 24 21:13:47 well, they're written in text format but then compiled Mar 24 21:14:16 I have a repository with some tools that make it earlier to write overlays, along with various examples of them: https://github.com/mvduin/overlay-utils Mar 24 21:14:46 you can find the official overlays here, although they're not as pleasant to the eyes: https://github.com/RobertCNelson/bb.org-overlays/tree/master/src/arm Mar 24 21:15:07 zmatt thanks looking. maybe the gpio demo? Mar 24 21:15:44 the main device trees for a particular kernel version can be found e.g. here: https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.9.88-ti-r107/arch/arm/boot/dts (replace 4.9.88-ti-r107 by the relevant kernel version) Mar 24 21:16:08 or here (select appropriate branch for the kernel series you use): https://github.com/RobertCNelson/dtb-rebuilder/tree/4.9-ti/src/arm Mar 24 21:16:36 thanks Mar 24 21:17:15 be cautious that my overlay-utils sometimes use slightly different macros than mainline linux (because I wasn't aware they existed, or they were added later by mainline, or I just disagreed with them) Mar 24 21:17:24 ok Mar 24 21:18:45 using config-pin, if I set a gpio to 'in' then it doesn't affect the high/low state Mar 24 21:19:05 hang on. Mar 24 21:19:53 obviously, if it's an input it should be driven externally Mar 24 21:20:20 there are on-die pull-up/down resistors, but they're extremely weak (100KΩ ± 50%) Mar 24 21:21:27 i see Mar 24 21:22:27 that's why if you want to ensure pins have the right level before they're configured, the best way to do it is with external 1-10KΩ pull-up/down resistors Mar 24 21:23:12 zmatt I have some insight into my problem but maybe I don't understand it fully... Mar 24 21:23:35 if you want to check what the default pull direction is for pins, see my pins spreadsheet: https://goo.gl/Jkcg0w nicest overview for the purpose is the P9/P8 tabs, which show "L"/"H" next to the pin labels to indicate pull-down and pull-up respectively Mar 24 21:23:44 just taking one of the pins, the default mode looks like, "P2_01 Mode: default Direction: in Value: 0" Mar 24 21:24:10 oh, pocketbeagle Mar 24 21:24:13 yeah Mar 24 21:24:43 when my BB is writing to the LCD successfully, the pin mode looks like this: "P2_01 Mode: gpio Direction: out Value: 1" Mar 24 21:24:46 sorry, that complicates the use of my spreadsheet... you can still find the default pull direction of processor pins there though Mar 24 21:26:00 when my BB script quits, I set all the LCD pins to inputs so that I'm not outputting anything to them so the MCU can take over writing to those lines (I have a control pin to signal to the MCU that it's ok for it to write to the lines). Once the BB script successfully quits and hands over control, the pin mode looks like, "P2_01 Mode: gpio Direction: in Value: 1" Mar 24 21:26:27 presumably because the mcu is driving the line high then? Mar 24 21:27:20 I'm just guessing here Mar 24 21:27:46 if either the beaglebone or the mcu is driving the line (has the pin configured as output), then its output level applies Mar 24 21:28:22 otherwise, if one or both of them has a pull-up configured it's high; if one or both of them has pull-down configured it's low Mar 24 21:28:33 otherwise the line level is probably indeterminate (avoid this situation) Mar 24 21:29:10 if mcu and beaglebone have conflicting pull directions, either one will win (if it has much stronger pull than the other) or again down configured it's low Mar 24 21:29:15 woops Mar 24 21:29:34 sorry, something went wrong there Mar 24 21:29:47 if mcu and beaglebone have conflicting pull directions, either one will win (if it has much stronger pull than the other) or again indeterminate line level results Mar 24 21:31:36 (similar thing is true if mcu and beaglebone are both outputs and drive opposing levels, although in that case the current may also damage the hardware. this can be prevented by a suitable series resistor) Mar 24 21:33:10 the mcu when it finds my control line is hight, sets the lines to output, otherwise to input. Same as how the bb side works to control which one is currently has write permissions on the lcd lines Mar 24 21:33:33 when in output mode, the lines are low not high for both the MCU code and the BB code Mar 24 21:33:43 zmatt: How can I get weston running? I have the pvr driver running but glxgears says DRI2: Failed to authenticate... google search said X has some problem with GLES I guess Mar 24 21:33:51 may be an old post though Mar 24 21:34:21 Sidharth: X11 is not supported by the pvr drivers. weston should work but I have no experience with it Mar 24 21:35:03 zmatt re: your suggestion about using a 1K to 10K on the lines, my partner doing the hardware responded, "regarding that suggestion we don’t want them to be high or low, we want them to be “floating” Mar 24 21:35:03 so pullup or pulldown won’t help, they need to be “input” or “floating”". Mar 24 21:35:22 what? you never want a logic pin to be floating Mar 24 21:36:16 it's probably a misunderstanding and he thought you meant low/high as in "driven low/high" Mar 24 21:37:00 or not, uh Mar 24 21:37:29 I dunno, but if he really means he "they should be floating" part, that would require some good explanation Mar 24 21:39:27 since in that case you should probably also make sure the pin's receiver is disabled on the beaglebone since otherwise extended exposure to intermediate voltage levels might damage the io cell in the long run (due to excessive current internally in the receiver) Mar 24 21:39:47 oh dear Mar 24 21:40:08 that's why normally pull-up/down resistors are used to keep pins from floating Mar 24 21:40:36 (even for pins where the logic level doesn't matter, e.g. unused pins) Mar 24 21:42:34 zmatt I'm not sure what the relevant factor is here: https://gist.github.com/abcd-ca/6e25bb1b5d856e050fbea2023f9e7716 Mar 24 21:43:07 these aren't showing pull direction Mar 24 21:43:11 oh Mar 24 21:43:36 I just checked for this pin, mode 'default' has pulldown Mar 24 21:43:49 mode 'gpio' has pull disabled Mar 24 21:43:55 oh wait Mar 24 21:43:58 what Mar 24 21:44:02 mode default isn't gpio at all Mar 24 21:44:07 it's pwm out Mar 24 21:44:11 I think that's my problem Mar 24 21:44:12 so it's probably actually *driven* low Mar 24 21:44:27 but also, mode 'gpio' has no pull enabled Mar 24 21:44:38 you should probably check if the mcu has internal pull-ups Mar 24 21:45:24 I've invited my partner into the here Mar 24 21:46:09 into here* Mar 24 21:46:13 if the mcu can be configured to pull-down then the problem is probably fixed, although I'd still recommend using mode 'gpio_pd' instead of 'gpio' on the beaglebone Mar 24 21:46:53 if the mcu has no pull-up or pull-down, using mode 'gpio_pd' may fix the problem although external pull-down may be preferred due to the weakness of the internal pull Mar 24 21:47:00 in all other cases, external pull-down will be required Mar 24 21:47:23 if you want to pin to be low after relinquishing control that is Mar 24 21:49:19 another alternative would be to use a sufficiently large series resistor (e.g. 1K) on either the beaglebone or the mcu to allow that one to drive default levels instead of relinquishing control, and the other party (without series resistors) just enables its outputs to override the pins Mar 24 21:50:54 ultimately there are lots of ways to ensure a net has the right level at the right time... you just need to keep track of everything pulling on the net and its resistance, and make sure there's one clear winner (e.g. a factor 10 lower resistance than any conflicting pulls) Mar 24 21:54:37 also, I really don't like that the pocketbeagle configures various pins as outputs by default :-/ Mar 24 21:55:57 e.g. due to selecting pwm output for the P2_01 pin by default: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-pocketbeagle-common.dtsi#L489-L490 Mar 24 21:57:20 (also lol, mode "gpio" and mode "gpio_input" are literally the same thing since PIN_INPUT == (PIN_OUTPUT | INPUT_EN) ) Mar 24 21:58:55 thank you Mar 24 22:04:30 anyway, I'm off Mar 25 01:03:23 I was right, it's set in the kernel device tree Mar 25 01:03:32 source code **** ENDING LOGGING AT Sun Mar 25 03:00:04 2018