**** BEGIN LOGGING AT Fri Jan 19 03:00:01 2018 Jan 19 04:00:27 hi,may i know if i burn the debian to microsd 32g...will it become 4gb? Jan 19 08:58:28 hello? Jan 19 08:58:57 i need help regarding beagle bone blue Jan 19 11:30:27 Hi, I am working with BB Blue and I am trying to turn off wifi access point, which runs of the board. I have tried "connmanctl tether wifi off", but BB still broadcasts. I can turn it off with "ip link set SoftAp0 down", but that is not nice solution. Does anyone know? thanks! Jan 19 12:53:53 well... that was interesting Jan 19 12:54:39 we had a beaglebone which had weird errors (timeouts) during eMMC writes Jan 19 12:55:00 I was still able to make a full backup of it fortunately, i.e. no errors during read Jan 19 12:56:03 then I tried erasing its eMMC... which froze. and now the eMMC stops respond during initialization, hence /dev/mmcblk1 doesn't even appear anymore Jan 19 12:59:33 my guess would be corruption of the eMMC's metadata, resulting in crash of the eMMC controller's firmware, but hard to say for sure Jan 19 16:56:05 What do y'all think?: I'm trying to build a custom function generator up to 2 MHz that responds to real time control (at about 500 Hz) from a separate computer. I thought UART serial to the PRUs outputting to a DAC (bypassing the main BBB processor) seemed reasonable. Am I missing anything? Jan 19 17:15:43 qaute: sounds like something that could work Jan 19 17:16:32 if anything, the specs actually sound conservative Jan 19 17:19:21 Well, that's good news. I think the most uncertainty lies in the serial connection; I've no idea how many processor cycles that will take. Jan 19 17:19:32 note there's an UART inside PRUSS you can use Jan 19 17:20:11 thus avoiding the high (and variable) latency of accessing any of the other uarts via the L3 interconnect Jan 19 17:22:29 I'm not an expert at low level hardware (or the BBB). How does it work? Input pins in the GPIO headers and received bytes into some kind of shared buffer? Jan 19 17:23:27 well, for a project like this it'll be fairly unavoidable to become more familiar with low-level stuff :) Jan 19 17:24:34 the pru uart is available via two choices of pins: either P9.17/18 or P9.24/26 (for TxD/RxD) Jan 19 17:25:09 pinmux needs to be setup from linux of course (that goes for all pinmux) Jan 19 17:26:38 the uart has a pretty simple register interface. but basically, ignoring initialization, you can either periodically poll whether a character is available or arrange for it to notify the pru core via its interrupt controller (appears via bit 30 or 31 of pru register r31) Jan 19 17:26:51 and then read the byte from the uart Jan 19 17:26:56 and do whatever with it Jan 19 17:29:24 there's a 16-byte fifo inside the uart to buffer received bytes until you read them, and likewise a 16-byte transmit buffer Jan 19 17:29:51 Fair enough- I can probably handle this much, if that's all it is. What documentation would you suggest I look at? Is there enough information on the wiki somewhere, or do I need to go find the processor datasheet? Jan 19 17:30:11 definitely grab the AM335x Technical Reference Manual Jan 19 17:30:43 chapter 4 is all about PRUSS Jan 19 17:30:55 Got it. That should be free from TI, right? Jan 19 17:31:16 yes, http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf Jan 19 17:32:41 Thanks! Before I go try my luck, is there a best PRU programming toolchain these days (preferably in C)? Jan 19 17:33:38 for pinmux details, I also have a spreadsheet which can be useful: https://goo.gl/Jkcg0w the P9 and P8 tabs give a nice overview of the bbb's expansion connectors. the Signals tab lets you look up by signal, (e.g. scroll down to "uart pru" to find to which bbb pins its signals can be mapped) Jan 19 17:34:29 if you really want to program in C and don't care about its inefficiency, then obviously use TI's PRU toolchain Jan 19 17:35:07 for programming in pru assembly, good old pasm (in Jan 19 17:35:16 https://github.com/beagleboard/am335x_pru_package ) may actually still be the best option Jan 19 17:35:47 it's quite a powerful macro-assembler with support for named variables and structs and such Jan 19 17:37:18 this choice also sorta decides whether you'll be using remoteproc-pru or uio-pruss to load the code (although technically I think you can use either, it may just be less straightforward) Jan 19 17:40:59 Okay. Maybe I will try my hand at assembly; I guess it isn't that hard. Jan 19 17:41:23 Are the last two programs to load the code from BBB Linux? Jan 19 17:41:26 pru has a nice instruction set, and pretty simple Jan 19 17:41:34 kernel drivers, but yes Jan 19 17:42:09 if you're using a recent enough system image, you can select in /boot/uEnv.txt which one of the two you want to enable Jan 19 17:42:34 Alright. What's the difference? Jan 19 17:43:29 uio-pruss mainly just allows mapping the pru subsystem into a userspace process, thus allowing it to load code into it (and also debug it) Jan 19 17:44:03 it also has some features for allocating DDR3 memory for use by pruss if desired, and dispatching interrupts from pruss to linux Jan 19 17:44:57 remoteproc-pru moves much more functionality into the kernel, which has the overall effect of making it less flexible and more complicated to use Jan 19 17:45:47 I don't really see much good reason to use it, except maybe if you want to write linux kernel code that cooperates with code running in pruss Jan 19 17:46:39 Yeah, probably not. uio-pruss, then. Jan 19 17:47:11 Well, do you think there's anything else I should know? General advice? Jan 19 17:47:58 hard to give an answer to such a vague and general question :) Jan 19 17:48:52 it may be useful to read some posts about the design of beaglelogic, which touch on aspects on pruss performance Jan 19 17:49:14 it squeezes a lot of out of pruss Jan 19 17:49:57 e.g. http://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-the-prus-part-1/449 Jan 19 17:50:48 Can't fault you on that! :P I'll look into the beaglelogic. Jan 19 17:50:56 hopefully you can avoid having to deal with ddr3 memory, or other resources outside pruss Jan 19 17:51:14 you can do linux kernel interfacing with both rproc and uio Jan 19 17:51:29 rpoc wants an elf binary, IIRC Jan 19 17:51:34 it does Jan 19 17:51:45 think uio can do just a bin Jan 19 17:51:54 (i.e. raw code, no segments) Jan 19 17:52:09 yes, so that's why I said the choice of toolchain kinda determines whether you'll use uio-pruss or remoteproc Jan 19 17:52:20 of course you can convert binaries if you want to, but it's more hassle Jan 19 17:52:31 elf -> bin is easy Jan 19 17:52:37 bin -> elf can be painful Jan 19 17:53:16 I'll second that on no miscellanea. Think I'll probably avoid interfacing with Linux for now; I don't see any immediate reason to. Jan 19 17:54:09 qaute: well, when using uio it's pretty straightfoward since pruss is mapped into userspace, so accessing a variable in pruss-local memory isn't really any different from access any other sort of variable Jan 19 17:54:15 what are you talk to with the pru? Jan 19 17:54:26 ds2: he wants to make a signal generator Jan 19 17:54:38 ah... one way Jan 19 17:55:23 Yup. Take input at about 500 Hz over PRU UART, output at up to a few MHz to a DAC. Jan 19 17:56:05 is the PRU UART pins brought out? Jan 19 17:56:07 qaute: also worth keeping in mind: generating signals in real-time on a pru core may be somewhat tricky depending on what you want to do Jan 19 17:56:19 ds2: two mux options for each of the signals Jan 19 17:56:33 all on P9 Jan 19 17:58:02 never looked at pru uart mux options Jan 19 17:58:33 qaute: the pru core can do integer add/subtract, and it has a coprocessor that can do 32x32 -> 64 bit unsigned integer multiply. any math you want to do has to be based on that Jan 19 17:58:51 True. I'm hoping for four separate 4 to 8 bit DAC outputs. Each is just a sine wave of chosen frequency and amplitude with possible DC offset. Barely worthy of the "signal generator" name. Jan 19 17:59:21 So put the sine wave in a lookup table and hope for the best.. Jan 19 17:59:55 DDS? Jan 19 18:00:01 how fast do you expect the signal to change in response to a request? Jan 19 18:01:50 "four separate 4 to 8 bit DAC outputs" ... that's actually a lot of pins Jan 19 18:02:01 Amplitudes should change at perhaps a thousand Hz. The sine waves should all have the same frequency and can shift frequencies slowly. Jan 19 18:02:06 assuming you mean DACs with parallel input Jan 19 18:02:33 Yeah, I'm hoping the signal simplicity will make up for it. Jan 19 18:03:10 it won't, there aren't enough PRU I/O pins available for 4x8 signals Jan 19 18:03:31 do the DACs latch the input based on a trigger/clock signal? Jan 19 18:03:46 since if so, you can probably share the same 8-bit data bus for all four DACs Jan 19 18:03:53 and just use a separate trigger for each Jan 19 18:04:48 eh? Jan 19 18:05:05 is it 4 _TO_ 8 bit or is it 4 _TIMES_ 8 bit outputs? Jan 19 18:05:15 Ah, that's good to know. As many bits as I can get, though four or five should be sufficient. I'd assumed the PRUs could access all the headers... how many outputs do they have? Jan 19 18:05:29 ds2: four separate DACs with 8-bit data is 4x8 Jan 19 18:05:32 The DACs can be latched if need be. Jan 19 18:05:53 I read that as 4 outputs, each can be as little as 4 bits wide Jan 19 18:05:54 Yes. Four separate, with up to eight bits. Jan 19 18:06:06 Correct. Jan 19 18:06:06 which can be done in 16bits of output Jan 19 18:06:13 Yes. Jan 19 18:07:03 yes, I was mainly saying there aren't enough pins for 4 times 8-bit parallel Jan 19 18:07:04 if you can tolerate a little glitching, LCDC.... Jan 19 18:07:39 and using 16 pins in total would already complicate things, since there aren't 16 pru gpios available from a single core Jan 19 18:08:08 qaute: my pins spreadsheet ( https://goo.gl/Jkcg0w ) also has a PRU tab that gives an overview of all pru pins Jan 19 18:08:25 Yup, just looked at it. Jan 19 18:08:29 thought one of them can do 16 pins, IIRC Jan 19 18:09:52 ds2: pru1 has io0-13 and io16 accessible if you disable use of the eMMC Jan 19 18:09:53 Looks like PRU1 on the sheet can do fourteen, not counting UART? Jan 19 18:10:09 Er, counting. Jan 19 18:10:34 How easy is it for the two to communicate? Jan 19 18:11:56 qaute: very easy. in fact, beaglelogic uses both cores in close cooperation: one core samples the data and sends it in batches to the other core, which is responsible for writing each batch out to memory Jan 19 18:13:31 they did that because a memory write is a multi-cycle instruction (1 + number of words), while each pru core can read or write any contiguous byterange of its general-purpose registers (r0-r29) from/to one of the three 120-byte "scratchpads" shared between the two pru cores Jan 19 18:13:36 in a single cycle Jan 19 18:16:34 if you're curious to see what that looks like, here's the loop that samples 8-bit data at 100 MHz (one sample per two cycles): https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru1-core.asm#L111-L175 Jan 19 18:17:03 and beaglelogic-pru0-core.asm in the same directory is the other core's code, responsible for writing that data out to memory Jan 19 18:18:17 zmatt: how many are exposed on the PRU that lives in the LCD pins? Jan 19 18:18:27 Great; that's easy! Looks like PRU 0 and 1 have 9 and 10 outputs, not counting UART? Jan 19 18:18:38 ds2: that's pru1 Jan 19 18:18:41 can't find my notes at the moment Jan 19 18:19:57 qaute: uhh, no? Jan 19 18:21:17 qaute: pru1 has io0-13 and in16 accessible (io12-13 only if eMMC is disabled) Jan 19 18:22:07 qaute: pru0 has io0-7, out14-15, and in14-16 available Jan 19 18:22:18 the pru uart isn't listed on that sheet Jan 19 18:23:52 Counting the pins on your spreadsheet. I guess this is a good time for me to go open that processor manual. But pru1 has all 0-11? Could I use those and bring in UART from pru0? Jan 19 18:24:45 UART can be used from either pru0 or pru1 Jan 19 18:25:12 nearly everything is shared between the two cores in pruss, their dedicated gpio being the exception Jan 19 18:26:17 I'll add the pru uart to that sheet Jan 19 18:26:27 Ok... So pru1 has over twelve outputs and gpio, and pru0's gpio pins are separate. Jan 19 18:28:02 If that's the case, I can stick with pru1 and not worry about interprocessor communication. Jan 19 18:29:16 I have to go: thank y'all for the help! Jan 19 18:30:27 it might actually be easier to have one core dedicated to outputting values Jan 19 18:30:41 since that requires very strict timing Jan 19 18:31:04 otherwise you have to do all your random other stuff (e.g. dealing with the uart) in between updating the outputs Jan 19 18:31:19 which could get messy quickly Jan 19 18:34:09 2 MHz means 100 cycles per output update... it's a fair amount of time I guess, but still it's probably also easy enough to burn through them if you're not careful Jan 19 18:35:00 oh, he's gone Jan 19 22:29:41 Anyone here that could help me with getting eQEP working on my BBB? It works when I manually configure the pins with the "config-pin" util, but when I load the associated .dtbo, it fails to count encoder pulses properly Jan 19 22:39:38 hmm, eQEP still requires an overlay even when cape-universal is in use? Jan 19 22:39:59 oh, I guess because it can be configured in more than one mode via DT Jan 19 22:40:08 what's the dtbo name? Jan 19 22:41:41 actually, no, all eqep instances are already enabled by cape-universal Jan 19 22:41:47 no overlay should be required Jan 19 22:42:49 or do you mean, it works when using cape-universal, but you want to avoid that and are trying to get it to work by loading an overlay instead? Jan 19 22:43:38 oh lol Jan 19 22:43:39 wut Jan 19 22:44:11 the bone_eqep* overlays configure the driver in a totally different mode than cape-universal does Jan 19 22:44:45 compare: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/univ-bbb-EVA-00A0.dts#L3270-L3275 Jan 19 22:45:06 with: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/bone_eqep0-00A0.dts#L61-L71 Jan 19 22:45:21 Thanks, just processing all this Jan 19 22:45:26 (still here!) Jan 19 22:46:23 the overlays don't configure eQEP in quadrature mode Jan 19 22:46:39 the dt (line in my uEnv.txt) is: uboot_overlay_addr4=/lib/firmware/bone_eqep2b-00A0.dtbo Jan 19 22:47:01 ahh, from you last comment, that's exactly the behavior I"m seeing. It's as if it doesn't know how to interpret the pulses Jan 19 22:47:54 So, when I don't load the dtbo (comment it out), and reboot, and configure the pins manually, ie, "config-pin p8.11 qep ...", it works great Jan 19 22:48:06 seems to set it for quadrature mode in that case Jan 19 22:48:48 that's because that doesn't involve the bone_eqep* overlays at all Jan 19 22:49:19 ok, thanks for explaining this, I"m a BBB newbie... Jan 19 22:49:30 by default, "cape-universal" is being used, which is basically sort of "one overlay to rule them all" with a mechanism that allows runtime configuration of pins Jan 19 22:49:33 worked with linux for years, but cape-managers, etc...not my forte Jan 19 22:50:34 using overlays like bone_eqep* is basically the "old way" of configuring functionality Jan 19 22:50:47 ok, so if I have a predetermined hardware setup that I want loaded at boot, I should comment out this line in my uEnv.txt: enable_uboot_cape_universal=1 Jan 19 22:51:54 or, if that's the old way, then what's best practices now, for a known hw config? Just run a script at boot that contains tons of "config-pin" commands? Jan 19 22:53:33 I guess? :D I personally think cape-universal is just gross and don't use it at all, even though I appreciate it makes things easier for new users Jan 19 22:54:05 note that I don't use overlays either, we make a custom dtb for each hardware setup Jan 19 22:55:45 ok, this has been very helpful. So you just create and load one custom dtb for your application? I'm not sure I'm versed well enough in dts syntax to do that. Was hoping to just load specific .dtbos (tons of them in /lib/firmware) for the hw config I need Jan 19 22:56:32 you can do that too, except when there isn't one that does what you want :) like in this case Jan 19 22:56:47 at least nowadays overlays are applied to the main DT before it's passed to the kernel Jan 19 22:57:11 which should be a lot less buggy than loading them at runtime (which was being done until very recently) Jan 19 22:57:39 I'm on a 4.4 kernel, so I guess I have the new (uboot overlays) method? Jan 19 22:58:12 or is it actually my uboot version that's relevant? Jan 19 22:58:43 it requires a recent enough u-boot Jan 19 22:59:40 I don't know if they also changed anything in the kernel for this Jan 19 23:01:19 ok. It looks like root cause is the encoder mode ( "count" ) being "1" in the eQEP .dtbo file, which is not quad mode Jan 19 23:01:45 yes Jan 19 23:02:08 it is "0" in the univ-bbb-EVA-00A0.dts file you linked Jan 19 23:02:48 is the univ-bbb-EVA-00A0.dts file the default? I'd really like to understand why I get the correct behavior by default Jan 19 23:03:16 I don't see that file name (or an associated .dtbo) in my uEnv.txt file Jan 19 23:03:47 is the "enable_uboot_cape_universal" flag giving me that behavior? Jan 19 23:07:30 there are a bunch of variants of the cape-universal overlay Jan 19 23:08:05 the correct one is picked by u-boot based on the beaglebone model you're using and which other functionalities are enabled (eMMC, hdmi video, hdmi audio) Jan 19 23:08:36 I'd really like to know which one I'm getting, so I have some sense of the default behavior... Jan 19 23:08:52 the one you linked, how did you pick that one? Jan 19 23:09:41 https://github.com/dutchanddutch/u-boot/blob/am335x-v2017.11+overlays/include/configs/ti_armv7_common.h#L530-L587 Jan 19 23:10:20 univ-bbb-EVA is for a beaglebone black with eMMC, video, and audio all enabled (which is the default) Jan 19 23:11:03 I have those disabled in my uEnv.txt, so I'm guessing uboot picks a different file? Jan 19 23:11:48 yeah, but they're all generated from the same template with parts of it disabled using #if .. #endif Jan 19 23:12:04 makes sense Jan 19 23:12:22 so things like eqep configuration is the same in each case Jan 19 23:13:19 makes sense (again) Jan 19 23:13:44 thank you so much for your help and patience; there seems to be very little relevant info/support on this issue Jan 19 23:14:33 yes, there is an unfortunate lack of (correct, uptodate) documentation Jan 19 23:15:17 so I assume that even when I comment out the specific .dtbo file, the driver is still loaded due to uboot finding the "enable_uboot_cape_universal" parameter, loading the universal dts, which references eqep, hence loading the driver? Jan 19 23:15:17 anyway, if you want an overlay that does work, you can just grab a copy of that bb.org-overlays repository, change the count_mode, and rebuild the dtbo Jan 19 23:15:44 ^yes, was thinking of doing that in this case Jan 19 23:16:25 yes, the driver gets loaded as long as the peripheral is enabled (status = "okay";) by any overlay Jan 19 23:16:29 for my previous question, I was wondering how/why the driver was even loading with NO dtbos referenced in my uEnv.txt Jan 19 23:16:47 cape-universal enables everything and the kitchen sink Jan 19 23:16:48 but it was the uboot universal cape Jan 19 23:16:53 :D Jan 19 23:17:00 very helpful Jan 19 23:17:56 I'm going to edit my dts and recompile. Jan 19 23:18:01 note that afaik cape-universal gets automatically disabled if you load some random other overlay Jan 19 23:19:03 (or rather, specify one to be loaded at boot. loading an overlay at runtime obviously won't get rid of cape-universal, instead the overlay will most likely just fail to load due to conflict) Jan 19 23:19:54 makes sense Jan 19 23:20:08 how did you learn all this? Jan 19 23:21:54 I just pick stuff up Jan 19 23:22:01 and look at source code :) Jan 19 23:22:53 weird, looks like driver still loaded, even with no .dtbos and enable_uboot_cape_universal=0 Jan 19 23:24:39 I see /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/position Jan 19 23:24:57 which I take to mean the eQEP driver loaded, Jan 19 23:27:27 indeed Jan 19 23:27:54 ohh, don't assign 0 to it, comment the variable out Jan 19 23:28:17 I'm pretty sure they just test whether the variable is non-empty Jan 19 23:29:20 hmm, it also loaded when commented out, so I tried 0 Jan 19 23:29:48 that's odd Jan 19 23:30:08 does /sys/platform/devices/bone_capemgr/slots exist? Jan 19 23:31:05 no, closest path I have is /sys/devices/platform/bone_capemgr/ Jan 19 23:31:11 and no slots under that Jan 19 23:31:21 ok good Jan 19 23:31:44 wonder how the driver is getting loaded... Jan 19 23:32:05 can you pastebin your /boot/uEnv.txt ? Jan 19 23:33:08 sure Jan 19 23:33:41 [root@beaglebone]> cat /boot/uEnv.txt #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=4.4.91-ti-r133 #uuid= dtb= #dtb=am335x-boneblack-overlay.dtb ###U-Boot Overlays### ###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays ###Master Enable enable_uboot_overlays=1 ### ###Overide capes with eeprom #uboot_overlay_addr0=/lib/firmware/bone_eqep2b-00A0.dtbo #uboot_overlay_a Jan 19 23:33:59 don't paste multiline content into irc Jan 19 23:34:05 use a paste service like pastebin.com Jan 19 23:34:22 sorry Jan 19 23:34:45 fortunately it got truncated anyway Jan 19 23:35:11 https://pastebin.com/vy1WfRAy Jan 19 23:35:17 btw, which image version are you running? (cat /etc/dogtag) .. I thought kernel 4.9 was already the default nowadays Jan 19 23:35:21 cool site, never used but makes sense Jan 19 23:35:35 Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l GNU/Linux Jan 19 23:35:47 was the latest off the BBB support site Jan 19 23:36:13 /etc/dogtag says 2017-10-10 ? Jan 19 23:36:34 BeagleBoard.org Debian Image 2017-10-10 Jan 19 23:37:00 tell me if you see anything wonky in my uEnv.txt Jan 19 23:37:02 ok, weird that it still uses 4.4 Jan 19 23:37:21 well yeah, having enable_uboot_cape_universal=0 Jan 19 23:37:33 can you comment it out and try again just to be sure? Jan 19 23:37:41 I commented that out and still saw the eqeq/position files Jan 19 23:37:43 setting it to 0 is most definitely wrong Jan 19 23:37:47 ok, will try again Jan 19 23:38:28 the script in u-boot uses est -n ${enable_uboot_cape_universal} Jan 19 23:38:31 test -n Jan 19 23:39:41 just commented out and rebooted Jan 19 23:40:00 all 3 eqep drivers (0,1,2) loaded, 3 position files :P Jan 19 23:40:12 I wonder what's loading them... Jan 19 23:40:48 any other signs of cape-universal being active? e.g. all uarts being loaded (/dev/ttyS*) Jan 19 23:40:54 wait no, that's not a sign Jan 19 23:40:56 uh Jan 19 23:41:03 does config-pin work? Jan 19 23:41:49 yes Jan 19 23:41:58 huh Jan 19 23:42:05 so somehow that universal cape is still loading I'm guessing Jan 19 23:42:29 does /sys/platform/devices/bone_capemgr/slots exist? Jan 19 23:42:43 this is the uEnv.txt on my sdcard. I'm not booting off the emmc, but I know there is another uEnv.txt on that, could that be loading too? Jan 19 23:43:13 pretty sure no, however it *will* be using the u-boot installed on eMMC by default in preference over the one on SD card Jan 19 23:43:15 no Jan 19 23:43:33 (file does not exist) Jan 19 23:43:47 and my path is different... sys/devices/platform... Jan 19 23:43:58 oh yeah sorry, typo on my part Jan 19 23:44:11 anyway, that rules out the possibility it got runtime-loaded Jan 19 23:44:19 so u-boot is still applying the universal overlay Jan 19 23:44:21 weird Jan 19 23:44:48 but, like I just said, when booting from sd card you got the unfortunate situation of a potential version mismatch between u-boot and the rest of the system Jan 19 23:44:50 maybe there's a way to tell it not to in the uEnv.txt file that I'm not aware of Jan 19 23:45:33 need to boot, need pins used by the emmc for our hw design Jan 19 23:45:43 sorry, need to boot off sd Jan 19 23:45:54 do you care about what's currently on eMMC? if not, erase it with sudo blkdiscard /dev/mmcblk1 (you'll need to temporarily boot with eMMC enabled to be able to do that) Jan 19 23:46:58 something tells me, though, that with the universal cape disabled, and no dtbos, I could almost brick my system, as no pins would be configured for network (no ssh), and usb (no serial port) Jan 19 23:47:06 maybe there is some idiot-proofing? Jan 19 23:47:22 incorrect, those are features of the base dtb, not of cape-universal Jan 19 23:47:29 cape-universal is just about the expansion headers Jan 19 23:47:37 ahh, ok Jan 19 23:48:18 well, maybe the same board file that's loaded for the pins not brought to the headers, references eqep Jan 19 23:48:37 something, somewhere, is setting up network and usb pins Jan 19 23:48:49 btw, when reusing the eMMC pins, you should do one of: 1. avoid using P8.20, 2. avoid using P8.21, 3. enable the eMMC hardware reset signal in the eMMC OTP configuration Jan 19 23:48:53 maybe that same codeblock references other devices Jan 19 23:49:38 the possibility that eqep might be enabled by default occurred to me, but it seems unlikely. also, if that were the case, config-pin wouldn't work (it relies specifically on cape-universal) Jan 19 23:50:35 eqep is not enabled by default (I just checked) Jan 19 23:50:54 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am33xx.dtsi#L1015 Jan 19 23:51:12 ok, so something is loading the universal cape but I haven't found it...hmmm Jan 19 23:51:39 try wiping eMMC... maybe it has an old u-boot that's new enough to have u-boot overlays but not new enough to support all the config vars present in your /boot/uEnv.txt Jan 19 23:52:11 how do I wipe it? Jan 19 23:52:55 (I can google the process, if it's involved) Jan 19 23:52:57 00:45 < zmatt> do you care about what's currently on eMMC? if not, erase it with sudo blkdiscard /dev/mmcblk1 (you'll need to temporarily boot with eMMC enabled to be able to do that) Jan 19 23:53:29 don't care what's on it Jan 19 23:54:22 before I do, though, just for my understanding, isn't there a uboot on the sd card that is running and interpreting the uEnv.txt? Are you saying there's another uboot on the eMMC that is ALSO acting on the system? Jan 19 23:55:25 boot ROM loads u-boot from eMMC if present, and falls back to loading it from SD card otherwise Jan 19 23:55:38 ahhh, good to know! Jan 19 23:55:50 so I'm likely getting my eMMC's uboot Jan 19 23:55:55 you can bypass this by powering on with the S2 button held down (you can let go once the power led turns on) Jan 19 23:56:07 yes Jan 19 23:56:22 if it's the same version as on sd card then it won't matter Jan 19 23:56:30 Ok, so that might be the faster way to test Jan 19 23:56:31 but it might not be Jan 19 23:56:45 no need to bland the eMMC if I boot with S2 held Jan 19 23:56:47 blank Jan 19 23:56:57 yes, but the button can be a bit finicky to hold down while applying power :) Jan 19 23:57:57 going to try; theoretically, the driver shouldn't load this time Jan 19 23:58:05 (one way to be sure you did it right is by doing it without sd card inserted: it should result in the bbb not booting at all. then insert sd card and hit reset button) Jan 19 23:59:34 did the above, didn't boot, inserted, reset, now booting :) Jan 19 23:59:39 to debug these kinds of weirdness it may also be useful to check u-boot's output on the serial console, if you have a suitable cable for it Jan 19 23:59:48 yes, I need to set that up Jan 19 23:59:54 just gotten away with ssh so far Jan 20 00:00:36 driver still loaded :P Jan 20 00:00:54 I assume seeing /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/position means it loaded? Jan 20 00:01:27 seeing /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep at all means the device is enabled in DT Jan 20 00:01:58 and attributes like 'position' indeed show up once the driver loads for it Jan 20 00:02:03 that's what I thought...ugh Jan 20 00:02:09 mystery Jan 20 00:02:26 really weird Jan 20 00:02:28 I don't want to waste your time with this, would be good to understand what's going on under the hood, though Jan 20 00:02:52 you've already helped me find root cause on the eQEP mode being wrong in my .dtbo file Jan 20 00:03:17 if you want to try random stuff, you could try the latest testing image -> https://rcn-ee.com/rootfs/bb.org/testing/2018-01-14/stretch-iot/bone-debian-9.3-iot-armhf-2018-01-14-4gb.img.xz Jan 20 00:03:54 ok, if I can get some spare cycles, I'll try newer images Jan 20 00:04:01 u-boot overlays are still fairly new... maybe it still had issues back in october Jan 20 00:04:08 for now, I think I have what I need to get eQEP working Jan 20 00:04:19 I could post this question/issue on the forums too Jan 20 00:04:31 the google BBB forum led me to this chat site Jan 20 00:07:46 Thanks again for your help with all of this. Have a good evening (late in the day here on the West Coast) Jan 20 00:11:11 np Jan 20 00:37:00 zmatt, in case you're still there, my suspicion is that if uboot doesn't find ANY .dtbos, it load the universal cape, no matter how that flag is set in uEnv.txt Jan 20 00:37:20 that's not what the boot script says Jan 20 00:37:45 when I do load a .dtbo, I can't use config-pin, which is the behavior you thought would be tied to not having universal capes Jan 20 00:38:10 this is with eMMC's uboot bypassed? Jan 20 00:39:03 also, I should mention that the boot script I've inspected is a fairly recent one... I just can't be bothered to check which version is used on the 2017-10-10 image and dig that one up :P Jan 20 00:39:08 no, only checked driver was loading when I bypassed eMMC Jan 20 00:39:22 ok, no worries Jan 20 00:39:28 perhaps mine is stale Jan 20 01:12:53 zmatt, you still there? Jan 20 01:18:15 occasionally **** ENDING LOGGING AT Sat Jan 20 03:00:01 2018