**** BEGIN LOGGING AT Tue Jan 16 03:00:03 2018 Jan 16 05:20:20 Hi Jan 16 05:20:46 i have one new beaglebone black revision C board Jan 16 05:21:02 i tried with u-boot Jan 16 05:21:17 but stuck in loading u-boot Jan 16 05:22:01 can someone help me the complete steps for compilation of u-boot for this board Jan 16 05:22:25 this board is from element14 Jan 16 05:23:48 prakash: you're trying to customize u-boot ? Jan 16 05:24:43 ....why? Jan 16 05:26:00 removing the stench of DT? Jan 16 05:27:59 you can reproduce a standard beaglebone u-boot build by following these instructions: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot Jan 16 05:28:15 you can use that as basis for customization Jan 16 05:33:45 I wonder if anything will actually happen with the u-boot patches I sent upstream, or whether I'll be maintaining those out-of-tree indefinitely... oh well, *shrug* Jan 16 12:50:12 hello，how to replace the kernel of the debian in BBB Jan 16 13:23:16 On the pocket SRM it looks like R31 b12 and b13 are inaccessible to the pru, do I read that right? Jan 16 13:23:18 https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#6123-pru-icss-pin-access Jan 16 14:30:05 hello. i am trying to enable i2c1 for BBB. I have next dts - https://pastebin.com/zteC7MtL and when trying to use i2cdetec for i2c1 get next: https://pastebin.com/Sn3JxPQm What it can be? Jan 16 14:32:15 kernel version 4.4.110+ Jan 16 15:14:11 inisider: if you're using a recent debian image, you shouldn't need to manually deal with enabling the i2c and doing pinmux anymore Jan 16 15:14:34 i2c1 should already be enabled in the default configuration, and you can setup pinmux using config-pin Jan 16 15:15:26 declaring an i2c device that has a kernel driver (such as the nunchuk in you case) can still be done via DT overlay, or I think it can also be done directly via sysfs Jan 16 15:15:40 zmatt: I had this error pop up in the logs a couple of times, but the scan would still go ahead. Maybe 1-2 times per i2cdetect but the bus works Jan 16 15:15:59 as the first line of its output indicates, i2cdetect is a very hazardous command to use Jan 16 15:16:06 it should basically never be used Jan 16 15:16:18 yeah Jan 16 15:16:27 in this case however it's more likely the pinmux config hasn't been done Jan 16 15:17:18 causing the bus to seem continuously busy (sda and scl held low) Jan 16 15:17:21 it's just tempting to newbs because if you can at least see the device, the physical connectivity is there. That's something I struggle with confirming when using SPI, without a protocol analyzer Jan 16 15:18:14 the problem is that it may cause indeterminate behaviour, including causing the device to lock up and become unresponsive (I've seen one case of that here) Jan 16 15:18:29 I think that happened to one of my sensors as well yeah Jan 16 15:19:25 So I ordered this a couple of days ago, and will run it with Sigrok: https://www.ebay.com/itm/USB-saleae-Logic-Analyzer-w-Lines-USB-Cable-24MHz-8CH-CAN-24MHz-for-SCM-Black/ Jan 16 15:20:00 hope it will do the job Jan 16 15:20:25 wouldn't a beaglebone running beaglelogic be a more powerful signal analyzer? Jan 16 15:21:05 yes but it's ~1000 miles away in storage right now so I went for a cheap temporary solution Jan 16 15:29:58 zmatt: where i can see example of DT overlay? Jan 16 15:32:32 I have some utils that make it easier to build overlays, https://github.com/mvduin/overlay-utils (see i2c1-mcp7940x.dtsi for an example of an i2c device, use "make i2c1-mcp7940x.dtbo" to build the overlay) Jan 16 15:32:40 but it's probably easier to just use sysfs to add the i2c device Jan 16 15:33:37 I think it might just be: echo nunchuck 0x52 > /sys/bus/i2c/devices/i2c-1/new_device Jan 16 15:34:10 does it actually have a linux driver? Jan 16 15:34:16 (otherwise you don't need to declare it at all) Jan 16 15:34:47 yeap, i have this driver Jan 16 15:34:56 thanks will look for this. Jan 16 15:35:16 but i cant understand why i can not just declare such node with & Jan 16 15:35:35 it's an out-of-tree kernel module? Jan 16 15:35:51 yes Jan 16 15:36:13 using a custom dt should definitely work too Jan 16 15:36:51 but it is not, but if i declare all the same in "am335x-bone-common.dtsi" than all work OK Jan 16 15:37:01 uhh what? Jan 16 15:37:04 that makes no sense Jan 16 15:37:49 are you sure u-boot actually loaded your customized dtb ? Jan 16 15:38:07 yes, i am sure Jan 16 15:38:11 check /proc/device-tree to see if your declarations are visible there Jan 16 15:46:29 zmatt: seems that it is - https://pastebin.com/spC0vNp4 Jan 16 16:04:50 Hi, Happy new year :) ! Jan 16 16:04:52 I'm looking for a kind soul giving me a clue on how to set up the sound with the chromium browser using a little usb sound card on the BBB Jan 16 16:05:27 would somebody has a clue on that ? Jan 16 16:59:31 test bot Jan 16 16:59:49 AT_: I'd think Chromium would just grab the system card. Just need to set it up as default for the user. Jan 16 18:19:01 So. I'm using "BeagleBoard.org Debian Image 2017-10-10", and trying to give PRU0 access to P9_31, P9_29, P9_30, P9_28, P9_42, P9_27, P9_41, and P9_25. This seems to work for all pins except P9_42 and P9_41, just using "config-pin". I need all of these pins, and I can't use the other PRU instead. The device tree has always been crazy and confusing to me, particularly now as I'm trying to keep up as it changes again. Can someone point me to something to l Jan 16 18:21:51 n8vi: in what sense does it not work? does config-pin give an error? Jan 16 18:22:24 config-pin P9_42 pruout Jan 16 18:22:24 Invalid mode: pruout Jan 16 18:22:38 which modes does it say are available for the pin? Jan 16 18:23:08 config-pin -l P9_42 Jan 16 18:23:08 default gpio gpio_pu gpio_pd spi uart pwm Jan 16 18:23:40 that is odd Jan 16 18:24:09 except P9_42 is definitely PR1_pru0_pru_r31_4/PR1_pru0_pru_r30_4 Jan 16 18:25:48 oh I see now Jan 16 18:25:49 ew Jan 16 18:25:54 why oh why Jan 16 18:26:12 It's so weird to me that writing assembler is by far the easiest part of PRU development Jan 16 18:26:22 see, P9_41 and _42 are actually connected to two pins of the am335x each Jan 16 18:26:53 and for some reason they let you configure those individually, even though that's not very likely to be useful and not very user-friendly Jan 16 18:27:39 they called the second processor pin that maps to P9_41 "P9_91" and likewise the second pin that connects to P9_42 is called P9_92 Jan 16 18:27:57 orly Jan 16 18:28:01 the pru functions are on P9_91 and P9_92 Jan 16 18:28:50 P9_41 and P9_42 should be left configured as default or gpio (with either no pull, or the same pull as the corresponding P9_91/92) Jan 16 18:29:28 Where did you find this delightful little nugget of information? You just saved me a ton of heartburn, I've been digging around for what to do all day Jan 16 18:30:49 well I already knew those expansion header pins map to two cpu pins each (see also the P9 tab of my pins spreadsheet, https://goo.gl/Jkcg0w ), so I wondered how they handled that Jan 16 18:31:25 so I checked https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/univ-bbb-EVA-00A0.dts Jan 16 18:32:28 okay, fair enough. Jan 16 18:33:11 I don't really understand why they didn't simply include those modes in the list for P9_42, have each mode configure both cpu pins Jan 16 18:34:39 dts is still greek to me. I need to find a good tutorial on that Jan 16 18:34:45 but, apparently I don't Jan 16 18:35:03 As I will happily use config-pin and ignore the fact the device tree exists. Jan 16 18:35:15 Thanks again Jan 16 18:35:16 keep in mind that cape-universal is the most horrid blob of DT you could possibly find Jan 16 18:35:51 Well, it's a cancel-out-a-hack hack, so of course it is Jan 16 18:36:39 some of the small examples I wrote in https://github.com/mvduin/overlay-utils are nicely short and simple to understand Jan 16 18:37:18 (unlike typical overlays, these are written as normal device tree fragment that you could simply #include into the main device tree. I wrote a perl script to convert them to the mess required for actual overlays) Jan 16 18:37:23 How does one check what overlays are loaded these days? Jan 16 18:37:38 hasn't changed afaik Jan 16 18:37:54 I thought it was catting a file named "slots" which no longer exists Jan 16 18:38:26 read /sys/devices/platform/bone_capemgr/slots Jan 16 18:38:42 cat /sys/devices/platform/bone_capemgr/slots Jan 16 18:38:42 cat: /sys/devices/platform/bone_capemgr/slots: No such file or directory Jan 16 18:38:53 ah, you're using u-boot overlays probably Jan 16 18:38:59 yup Jan 16 18:39:04 in that case the overlays are merged into the main device tree before it's even passed to the kernel Jan 16 18:39:09 I just discovered that about ten minutes ago Jan 16 18:39:14 so, technically there are no overlays "loaded" anymore Jan 16 18:39:48 I don't know if u-boot leaves a trace of what it did anywhere other than on the serial console Jan 16 18:39:59 So does that mean config-pin is the canonical way to change pinmodes? I'm okay with this. Jan 16 18:40:00 it would be kinda nice if it did Jan 16 18:40:26 whether you use config-pin or not is a completely separate issue Jan 16 18:40:33 config-pin is available if and only if cape-universal is enabled Jan 16 18:40:48 you can use cape-universal without u-boot overlays, and you can use u-boot overlays without cape-universal Jan 16 18:41:14 there's a config var to enable/disable cape-universal and various other things in /boot/uEnv.txt Jan 16 18:43:59 Hmmm. Jan 16 18:44:04 the big difference between using DT overlays and cape-universal is that in the former case you just declare the hardware that exists, while cape-universal declares all the options and uses a tiny custom device driver to allow runtime switching of pinmux Jan 16 18:44:35 as a side-effect cape-universal also enables basically all peripherals and loads their associated device drivers, even if not used Jan 16 18:44:58 Ah. Jan 16 18:45:11 Well, that doesn't matter in my current project, but good to know Jan 16 18:45:22 I appreciate it's convenient for new users, but still... it's so hideous Jan 16 18:48:05 probably also not great for startup time Jan 16 18:50:21 seems to load by default on the current build Jan 16 18:52:03 yes, cape-universal has been default for quite a while already Jan 16 18:52:11 long before u-boot overlays became a thing Jan 16 18:53:13 the main contribution of u-boot overlays is that it allowed modularizing parts of the DT that couldn't before (e.g. because loading it at runtime just didn't work) Jan 16 18:53:37 instead of having a heap of variants of the main dtb Jan 16 18:57:08 * n8vi verifies everything is indeed working on all the pins needed Jan 16 18:57:10 thanks again Jan 16 18:57:27 I'll check out your github stuff and see if I can figure out that side of things too Jan 16 18:57:33 but later. For now, this works Jan 16 18:58:12 I still think it would be really nice to have a good way to build device trees, preferably with a gui (perhaps a web application) **** ENDING LOGGING AT Wed Jan 17 03:00:01 2018