**** BEGIN LOGGING AT Fri Mar 03 03:00:01 2017 Mar 03 09:15:39 hello Mar 03 09:16:36 i have a beaglebone and i have reset my password with the command sudo passwd -l root but the password is not reset. I have now type the password but the password is not correct Mar 03 09:17:27 -l locks the password. Mar 03 09:17:32 see the manpage. Mar 03 09:18:06 and what is now my password ? Mar 03 09:22:00 it's disabled. you can not use it to login. Mar 03 09:22:26 you can unlock it with 'sudo passwd -u root' Mar 03 09:23:33 ok and how login Mar 03 09:24:49 with root ? Mar 03 09:34:20 you should not at all. aways use sudo. Mar 03 09:35:18 isn't passwd setuid ? Mar 03 09:37:16 it likely is. but how does that help? Mar 03 09:37:27 no when ic type the ip in putty i must type i username and the password. when i now use my password isn't not correct Mar 03 09:42:07 my bad failed reading entirely, got surprised by "sudo passwd" Mar 03 09:47:51 ls Mar 03 09:48:09 Hi Mar 03 09:53:58 gquere: no worries. it's still early. Mar 03 10:10:00 Are the DDR3 parameters of BBB also configured in the kernel or only in u-boot spl? Mar 03 10:23:17 flomotar: the kernel expects main memory to be working already Mar 03 10:23:28 flomotar: so it's the boot loaders responsibility to set up DDR Mar 03 10:28:04 KotH: Okay, thanks! Mar 03 10:28:43 np Mar 03 11:06:20 the bbb iot sd card image has /dev/ttyS0 through /dev/ttyS5 present by default it seems. does that mean all serial ports are enabled after booting? Mar 03 11:11:49 I doubt that Mar 03 11:12:01 check the actual DT Mar 03 11:16:27 i'm trying to understand what i'm looking for. afaik , i need to enable the uart *and* setup the pinmux> Mar 03 11:16:29 ? Mar 03 11:18:35 tbr: i think /proc/device-tree/ocp/serial@48024000/ is uart2, what am i looking for here? Mar 03 11:19:45 not sure, busy with other stuff right now Mar 03 11:20:06 I'd expect that you need to load a DT overlay to turn on additional UARTs beyond the debug UART Mar 03 11:21:01 tbr: no, the image came with prepopulated devs (and dmesg outputs something about them); loading the BB-UART2 overlays fails (busy). i'll try to figure it out though, thanks Mar 03 11:23:07 I wouldn't take presence of devfs entries as them being active and pinmuxed to the outside Mar 03 11:27:36 /proc/device-tree/ocp/serial@48024000/... ...status == "okay", while ... "pinctrl-0" is empty; so i'm assuming it's on, without any pins muxed Mar 03 16:22:14 greetings all Mar 03 16:22:50 is there a server (headless cli) image for the beagle bone black wifi? Mar 03 16:23:16 if not, what would be the best way to create one **** BEGIN LOGGING AT Fri Mar 03 17:36:04 2017 Mar 03 18:23:52 anyone have an idea how to change the speed of the i2c bus @ 4802a000? changing the dtb doesnt seem to do anything :/ Mar 03 18:24:03 clock-frequency = <400000>; Mar 03 18:24:12 [ 34.964969] omap_i2c 4802a000.i2c: bus 2 rev0.11 at 100 kHz Mar 03 18:41:15 evening everyone Mar 03 18:41:44 i've got a question: on P8, there are some pins that are connected to the eMMC? Mar 03 18:42:16 specifically, P8.11,13,..,21 Mar 03 18:42:34 what's the use for those? can i connect an external flash memory through that? Mar 03 18:42:55 also, is it possible to use those as GPIO pins by changing some pinmux settings? Mar 03 19:45:51 sgflt: assuming you use the internal eMMC, those pins should be left untouched Mar 03 20:45:55 zmatt: hmm, i wish i should've thought about that beforehand =) Mar 03 20:46:18 well, one of those -.- Mar 03 21:01:10 sgflt: the original beaglebone (white) did not have eMMC nor HDMI Mar 03 21:01:18 so there all pins were freely usable Mar 03 21:01:42 the black is sort of like a white + eMMC "cape" + HDMI "cape" Mar 03 21:02:02 wouldn't it be a good idea to be able to use emmc without it being exposed to P8 pins? Mar 03 21:03:30 well the pins expose all IOs that weren't occupied for special dedicated functions... there's therefore no way to connect eMMC to the am335x without stealing some of those Mar 03 21:04:00 they left the connections to p8 intact since you can choose to disable the eMMC and then you can use those pins again freely Mar 03 21:04:19 same goes for the signals used by hdmi Mar 03 21:04:32 well, were there no other extra GPIO pins available to connect there (and not exposing the eMMC or hiding it behind pinmux)? Mar 03 21:05:48 not really no Mar 03 21:06:45 maybe one or two.. not worth sacrificing the backwards compatibility option Mar 03 21:07:06 backwards compatibility is a point i guess Mar 03 21:07:32 what pins should i use in the future if i need gpio pins>? Mar 03 21:08:21 https://goo.gl/Jkcg0w .. I suggest making a nice printout of the P9 and P8 tabs of my spreadsheet :) Mar 03 21:09:27 it shows which functionality is on which pins. it assumes you want to use eMMC hence no alternate functions are listed for those Mar 03 21:10:01 it also shows the default pull direction of each pin (H = pull up, L = pull down) Mar 03 21:10:13 at first glance, i can't make out any "unused" gpio pins Mar 03 21:10:34 well, P8.07 maybe Mar 03 21:10:49 everything you see are *available* options Mar 03 21:10:59 including gpios in the F7 columns Mar 03 21:11:56 do you need hdmi? Mar 03 21:12:17 the annoying thing with eMMC is, before that, i assumed that "i don't need it" == "i don't want to connect anything to it" Mar 03 21:12:23 (to the pins) Mar 03 21:12:27 but that doesn't hold for eMMC Mar 03 21:12:38 I don't understand Mar 03 21:12:59 you can connect stuff to those pins, but then you'll need to boot from μSD card or some other medium Mar 03 21:13:13 that's the point Mar 03 21:13:14 and choose a DT config that disables eMMC Mar 03 21:13:24 i want to boot from eMMC, but i'm not connecting anything to those pins Mar 03 21:13:38 so i'm not using the pins. i'm just using eMMC, which threw me off Mar 03 21:14:22 I understand it's maybe not obvious, but those P8 pins are simply connected directly to the cpu pins and to the eMMC pins Mar 03 21:14:46 to me, the case of having extra GPIO pins seems more useful than exposing eMMC - i can't think of a reason right now to connect to those eMMC pins Mar 03 21:14:50 (from the outside) Mar 03 21:14:58 you're missing the point Mar 03 21:15:04 the pins aren't exposed to let you use the eMMC Mar 03 21:15:19 they're exposed to let you use the cpu pins, provided you disable the eMMC Mar 03 21:15:54 and those CPU pins were unproblematic before, when there was no eMMC, because then they were "just" GPIO pins? Mar 03 21:16:28 so what i'm understanding is, to keep backwards compatibility with capes that do no use eMMC but used those old pins, those were kept Mar 03 21:16:54 and because it would be silly to remove the pins... that would only reduce options and make the bbb less useful Mar 03 21:17:14 whereas, in a new design, it would have been possible to move some other GPIOs that might not be connected at the moment there Mar 03 21:17:20 there aren't any] Mar 03 21:17:22 oh Mar 03 21:17:53 this makes me wonder: if any pin has multiple functions, are those always the same on a CPU pin? Mar 03 21:18:20 or does the board attach route multiple functions to a single pin by itself? Mar 03 21:18:30 my spreadsheet lists which functions are available per pin Mar 03 21:18:47 the BBB tab shows it in columnar format Mar 03 21:19:26 zmatt: since there's only one entry in the Ball ZXZ column, i assume it's always 1 P8/P9 pin connected to 1 CPU pin? Mar 03 21:19:50 *ZCZ Mar 03 21:21:56 in most cases yes. there are three pins (P9.15, P9.41, P9.42) that connect to two cpu pins each, see my P9 overview Mar 03 21:23:23 i see. Mar 03 21:23:32 I know my spreadsheet can be a bit overwhelming due to the high information-density, but I think it's useful to have all important info together in one overview Mar 03 21:24:15 i'm a bit torn on that. but it sure beats the reference manual Mar 03 21:24:39 the highlighting means various things... I really should make a legend or something Mar 03 21:25:17 zmatt: different views depending on what you're trying to achieve would be a boon. but that is quite a bit to ask from a spreadsheet. Mar 03 21:25:31 well there are already quite a few views on the same info Mar 03 21:25:47 for example my BBB tab also has filter views (menu Data -> Filter views) Mar 03 21:26:15 nice, i didn't even know that feature Mar 03 21:26:30 the Signals tab is meant to search by function Mar 03 21:26:48 e.g. "I need an uart, which pins can be used for that?" Mar 03 21:27:33 how would you look for the least used gpio pins? Mar 03 21:27:55 define "least used" Mar 03 21:28:17 "doesn't break another functionality that is common" Mar 03 21:28:34 doesn't make me end up with a broken emmc =) Mar 03 21:28:58 (i had to cut off the pins for now and route some other to them from the top for now, until i can fix the pcb) Mar 03 21:29:03 well eMMC is marked very clearly, with grayed out gpio numbers and eye-stabbing purple highlights Mar 03 21:30:56 do you use hdmi? Mar 03 21:31:16 zmatt: i might. it's useful for debugging sometimes Mar 03 21:32:02 really? I prefer the serial console for that (if for some reason I can't ssh in) Mar 03 21:32:56 when working on creating new base images, plugging in an actual keyboard and seeing the output is fairly valuable, especially when you just messed up the kernel cmdline =) Mar 03 21:33:38 again, serial console :) Mar 03 21:33:47 works under way more circumstances than hdmi Mar 03 21:34:16 and also allows access to u-boot which lets you recover if you messed up /boot/uEnv.txt really badly Mar 03 21:34:23 you can find an HDMI monitor and keyboard in much more places you can find a serial console though =) Mar 03 21:34:34 but yeah, i'll keep that in mind Mar 03 21:34:55 that is true, but I wouldn't want to sacrifice 20 pins for it Mar 03 21:35:08 btw, is there a secret to figuring out the current function of a pin on a live system? Mar 03 21:35:33 aka, the current pinmux state. i've check the /sys/kernel/debug/pinctrl stuff, but i cannot make much sense of it Mar 03 21:35:35 yes! I've written a script for that Mar 03 21:35:43 please link =) Mar 03 21:35:54 it combines info from /sys/kernel/debug/ with tables based on my spreadsheet Mar 03 21:36:12 "show-pins", found here -> https://github.com/mvduin/bbb-pin-utils Mar 03 21:37:05 the first column contains the P9/P8 number (and description) so "sudo show-pins | sort" gives you the output sorted by expansion header pin Mar 03 21:37:33 it even has color ❤ Mar 03 21:37:38 indeed Mar 03 21:38:31 so, if i understand this correctly, enabling a GPIO pin (other than exporting and setting it through the kernels gpio interface) is about pinmuxing it correctly, right? Mar 03 21:38:32 by default it only shows expansion header pins... more pins can be listed if you pass the -v option. pass the -v option twice to really list all pinmux registers no matter how useless Mar 03 21:38:47 I don't understand that question Mar 03 21:39:00 "GPIO" is a particular function that a pin can have Mar 03 21:39:05 well, i'm trying to figure out if that could've helped me figure out the issue earlier Mar 03 21:39:49 e.g. this line: P8.21 / eMMC clk 32 fast rx up 2 mmc 1 clk mmc@481d8000 (pinmux_emmc_pins) Mar 03 21:39:54 and it's one of the pinmux options a pin may have (and for nearly all pins, does have) Mar 03 21:40:07 "up" = pull-up enabled Mar 03 21:40:20 2 = function (i.e. pinmux setting) Mar 03 21:40:27 "mmc 1 clk" = description of function Mar 03 21:40:30 i see Mar 03 21:40:34 that's the one i was looking for Mar 03 21:41:03 so with the right device tree, there could be a "gpio" there Mar 03 21:41:24 mmc@481d8000 is the device owning the pin, and in parenthesis is the pinmux config node Mar 03 21:41:27 yes Mar 03 21:41:37 the show-pins tool seems very useful Mar 03 21:41:52 it would be nice if it could show a header Mar 03 21:41:54 or have a --help option Mar 03 21:42:00 all true Mar 03 21:42:14 well, a header would conflict with |sort Mar 03 21:42:27 you could make it optional Mar 03 21:42:29 with a flag Mar 03 21:42:37 no doubt there are many improvements possible Mar 03 21:42:53 i'm just saying - the spreadsheets and scripts seem very useful Mar 03 21:43:08 just not beginner-friendly, due to a few missing ergonomics Mar 03 21:43:11 but thanks for writing those Mar 03 21:43:27 if you put a working system on a uSD card (e.g. one of the "standalone" images you can download) Mar 03 21:43:51 then set dtb=am335x-boneblack-overlay.dtb in its /boot/uEnv.txt Mar 03 21:44:07 then eMMC pins will be available Mar 03 21:44:35 zmatt: so the comments say. but i do actually need the eMMC Mar 03 21:45:09 well you asked 'so with the right device tree, there could be a "gpio" there' ... I was giving a concrete example how Mar 03 21:45:12 :) Mar 03 21:45:15 p9.14 and p9.15 look like prime candidates for gpio Mar 03 21:45:34 no optional functions (at least not according to -vv) Mar 03 21:46:19 and p8.08 through p8.13 Mar 03 21:46:38 everything has optional functions, show-pins shows how things are configured right now, not how they could be configured Mar 03 21:46:43 for that, see spreadsheet Mar 03 21:47:10 P9.11-16 are however indeed quite sparse on alternate functions Mar 03 21:47:47 i think i've been reading the wrong docs Mar 03 21:48:05 P8.7-10 ditto Mar 03 21:48:56 there's a useful cue on my P9 tab: the background color of the pin number Mar 03 21:49:01 some other (non-official) doc i'm looking at right now shows p8.11 and p8.12 as also belonging to emmc Mar 03 21:49:27 that's wrong Mar 03 21:50:22 anyway, on the P9 tab the background color of the pin number (i.e. columns L and M) is green for pins that have no special purpose on the bbb with default software Mar 03 21:50:24 i'm thoroughly confused, one sec... Mar 03 21:51:14 pink are pins used by hdmi audio. if you don't use hdmi audio (make sure it's disabled) then those are also freely usable Mar 03 21:51:43 yellow means they have a special purpose, at least under some circumstances Mar 03 21:52:02 power supplies and dedicated pins are in eye-stabbing bright colors Mar 03 21:52:11 i've noticed Mar 03 21:53:07 in the P8 spreadsheet, it shows lcd d18 for p8.11 Mar 03 21:53:37 but the output of show-pins -vv shows this line: P8.11 13 fast rx down 7 gpio 1.13 Mar 03 21:53:50 shouldn't it list the alternate function (lcd d18) here? Mar 03 21:53:53 lcd d18 is *an* optional function for that pin Mar 03 21:53:58 a rarely used one Mar 03 21:54:01 no Mar 03 21:54:26 show-pins shows how the pins *are* configured, right now Mar 03 21:54:39 not alternate ways in which they *could* be configured Mar 03 21:54:46 i see Mar 03 21:55:13 how important are timer 4, 5, 7, 6? Mar 03 21:56:13 so, it's important to realize: the options you see are *options*, which you can choose to use if you have use for them Mar 03 21:56:36 timer 4-7 pins can be used for pwm Mar 03 21:56:47 i realize that - without much experience it's just hard to judge which functions are rare and which aren't Mar 03 21:56:58 fair enough Mar 03 21:57:02 (and yes, it depends on the application, but still!) Mar 03 21:57:17 well there are quite a few pins usable for pwm... I've marked those functions with that orangy background color Mar 03 21:58:05 hmm, i don't need PWMs, so i guess i could use those. Mar 03 21:58:24 they can also be used as "capture" input, meaning a timestamp gets recorded on a signal edge Mar 03 21:58:39 the "cap" pins can do that too, but fancier Mar 03 21:58:41 otoh, if i'm reading this right, using an LED-display an HDMI one simultaneously is impossible? Mar 03 21:58:58 what kind of led display? Mar 03 21:59:04 undecided yet =) Mar 03 21:59:13 the small, cheap kind? =) Mar 03 21:59:16 hdmi uses the LCD controller Mar 03 21:59:25 you have small cheap led displays that connect to i2c or spi Mar 03 22:01:05 it seems there are no alternate functions for adc pins Mar 03 22:01:15 i assume that's to ensure these don't mess with ADC readings? Mar 03 22:02:44 adc uses dedicated pins indeed... caution: the adc I/O supply voltage is 1.8V, those pins are absolutely *not* 3.3V-tolerant Mar 03 22:02:58 ... i guess i'll stay clear of those Mar 03 22:03:13 well, don't stay clear of those if you need analog inputs obviously :) Mar 03 22:03:47 if i need analog inputs or things above 12 V, i ask my friends with an EE degree Mar 03 22:04:00 that way, neither the hardware nor me get hurt in the process =) Mar 03 22:04:07 lol Mar 03 22:04:31 I don't think the analog inputs are really more fragile than the other I/O Mar 03 22:04:59 i have this fun gpio-switchable 230 V cable that i made out of a relay that, even after checking with 3 other people, i never dare to use Mar 03 22:06:02 is there a trick to figuring out the linux GPIO number from the bank.pin notation? Mar 03 22:06:03 in general there's a trade-off: tiny transistors = faster, cheaper, less power consumption Mar 03 22:06:21 but also easy to fry Mar 03 22:06:26 if you're careless Mar 03 22:06:29 i.e. P8.07 == GPIO 2.02 == gpio ??? Mar 03 22:06:43 substitute "clueless" for "careless" =) Mar 03 22:06:50 or that yes Mar 03 22:07:30 so, unfortunately there's a bunch of ways of identifying pins Mar 03 22:08:39 the only one that works for all I/O (incl analog) is what I simply call the 'pin number', which is the index into the pinmux config array Mar 03 22:08:59 which is also the order in which show-pins lists things Mar 03 22:09:47 then there's a gpio number which works for most cpu pins, either . or bank*32+pin (used by the kernel) Mar 03 22:10:03 (there's your "trick" :) Mar 03 22:10:24 damnit Mar 03 22:10:42 i just figured that out Mar 03 22:10:59 well, that's good enough for me. Mar 03 22:11:10 the expansion header pin numbers of the beaglebone have the issue that they don't always uniquely identify a cpu pin (because of P9.15, P9.41, P9.42) Mar 03 22:11:11 i think i know enough to fix this board now, thanks! Mar 03 22:12:49 to convert between the three there's no better solution than a lookup table Mar 03 22:14:43 zmatt: thanks a bunch. it's been great talking to you! Mar 03 22:14:59 https://hastebin.com/jecebijila.cpp Mar 03 22:15:42 good luck :) Mar 03 22:16:29 thanks! Mar 03 22:17:44 I'm gonna continue with some light reading... the documentation of a power management IC Mar 03 22:17:51 (~400 pages) Mar 03 22:19:57 well, enjoy your weekend =) Mar 03 22:20:04 I will! :D Mar 04 01:17:16 I am trying to expand the debian 8 installation to use my entire microsd card Mar 04 01:18:48 when i run grow_partition.sh it expands the partition to completely fill the card but it breaks the usb tether Mar 04 01:20:08 I mean i can nolonger ssh into the BBB wireless over the usb. Im not really sure where to go to fix this issue. I did it with a regular BBB in debian 7 and it worked fine, but debian 8 on the BBB wireless did not work **** ENDING LOGGING AT Sat Mar 04 03:00:01 2017