**** BEGIN LOGGING AT Mon Oct 21 02:59:58 2019 **** BEGIN LOGGING AT Mon Oct 21 06:43:31 2019 Oct 21 13:56:11 Hi We had a BBB runnining with PRU stuff under Debian 6. It died and I've installed Debian 9.5. We changed to the new uEnvt.txt, but the PRU does't work. Any ideas? Oct 21 14:10:26 Were you using the uio interface or the remoteproc interface? Oct 21 14:19:00 remoteproc didn't exist yet Oct 21 14:19:02 I think Oct 21 14:19:53 Guest75805: make sure the "uboot_overlay_pru" setting in /boot/uEnv.txt is set to /lib/firmware/AM335X-PRU-UIO-00A0.dtbo Oct 21 14:20:47 Guest75805: and if you're using pins for pru then you can either configure them at runtime using the config-pin utility or you can still use a custom overlay (but it may require some changes) Oct 21 15:10:50 zmatt: thanks - where can I find doc. on the overlay changes? Oct 21 15:18:40 Guest75805: I'm not sure there are docs on that, but if you're using the overlay just for setting up pinmux then it may suffice to recompile it with the latest dtc and disable cape-universal in /boot/uEnv.txt Oct 21 15:18:58 if you share your overlay source code (e.g. via pastebin.com) we can give more concrete feedback Oct 21 16:03:47 zmatt: So I'm back at trying to get the pins set up on my BeagleBone AI. Oct 21 16:04:27 I'm still working on making a .dtsi file that will allow me to switch between pin modes using the pinmux helper. Oct 21 16:04:35 Does this make sense?: https://pastebin.com/raw/gMM8yKjd Oct 21 16:04:36 okay Oct 21 16:05:06 So, I don't even know what the different modes do, but does the structure make sense? Oct 21 16:05:07 nope Oct 21 16:05:50 I think part of the problem is I don't understand the .dts file syntax. Oct 21 16:07:03 also why mcspi pins? weren't you trying to switch pru pins? Oct 21 16:07:45 Yeah, I just used the pins from your example. I actually want to switch pru pins and a couple of mcspi pins as well. Oct 21 16:08:44 so, the basic outline would be something like this: Oct 21 16:08:46 https://pastebin.com/raw/vvkkxEfB Oct 21 16:11:15 Cool, thanks! Oct 21 16:11:38 so, the lookup works something like this: the pinctrl-names property of a device lists the names of the pinmux states defined for the device in your DT, for each state there's a pinctrl-$INDEX property which contains an array of references to pinctrl nodes, which are children of the device responsible for configuring pinmux, e.g. &dra_pmx_core Oct 21 16:12:32 Ok, the .dts files are just c code right? Oct 21 16:12:52 for property values, <> is an array of 32-bit integers. a node-reference placed in such an array is converted by the compiler (or the overlay-loader) to the id ("phandle") of the referenced node Oct 21 16:12:56 uhh, not even remotely? Oct 21 16:13:27 Lol, ok yeah dumb question now that I think about it... Oct 21 16:15:47 It uses some aspects of c though right? Like the // for comments and ending things with semicolons. Oct 21 16:16:17 as for what mode is what... you can find that in the am572x datasheet, and I also have a spreadsheet with that info (but beware that some numbering differs between my spreadsheet and TI's docs, see the README tab): https://goo.gl/jiazTL Oct 21 16:16:42 hmm I don't yet have a sheet indexed by BBAI expansion header pin... I think I started work on that at some point, lemme check where that went Oct 21 16:18:32 there, copied it over... it's not quite as nice yet as the BBX15 tab but it's something Oct 21 16:18:59 hmm, it doesn't include the pin index, that's annoying Oct 21 16:30:53 ok, added a column for pin index Oct 21 16:31:17 so the first argument to DRA7XX_CORE_IOPAD is 0x3400 + 4 * index Oct 21 16:31:35 (I personally would have put that part into the macro and just take the index as argument, but I didn't write the macro :P ) Oct 21 16:33:48 the F0..F13 columns refer to mux modes. additionally, mux mode 14 is gpio and mux mode 15 is "safe mode" (for unused pins) Oct 21 16:35:59 when two processor pins map to one expansion header pin, I suggest adding pinmux for both of them and just setting the unused one to mux mode 15 Oct 21 16:41:07 hunter2018: also, in case I haven't linked it before, since you said you didn't know DT syntax, I have a quick summary here: https://pastebin.com/XC8vB33d Oct 21 17:34:39 That's awesome! Oct 21 17:47:49 m Oct 21 17:50:08 Awesome! Thanks for all the info. Oct 21 17:57:36 Again I have to ask, where do you find all of this information? I feel like I don't know where to look for info such as the device tree syntax. Oct 21 17:58:48 have you tried googling "device tree syntax" ? :P Oct 21 18:00:04 I can't really point to a specific thing from which I learned what I know, it's just bits and pieces I picked up over time Oct 21 18:04:58 Ok, fair enough. I don't think I actually ever googled it because there is some good info there... Oct 21 19:23:36 zmatt: so your dra7-uio-pruss.dtsi file overwrites the pruss1 and pruss2 nodes which by default only one property (staus = "okay") Oct 21 19:24:08 Does this mean that out of the box you can't even use the remoteproc interface? Oct 21 19:24:10 ? Oct 21 19:24:37 Wait, my bad Oct 21 19:24:54 I'm only looking in the am5729-beagleboneai.dts file, not the files it includes Oct 21 19:25:46 keep in mind that &foo { ... }; modifies an existing node that was previously created (and labeled with foo:), it doesn't create a node Oct 21 19:25:47 I'm sure there are more properties for pruss1 and pruss2 in one of those includes, like maybe in dra74x.dtsi Oct 21 19:25:59 dra7.dtsi Oct 21 19:29:57 Ok, I see. There are quite a few properties of pruss1 and 2. Oct 21 19:30:44 So why do you change compatible = "ti,am5728-pruss-soc-bus"; to compatible = "ti,pruss-v2"; Oct 21 19:31:03 Does the kernel look at the compatible property to decide to use uio? Oct 21 19:34:43 Embarrassed to say, but I have an issue of flashing the new image into my BBB. Here is what I did: Oct 21 19:35:12 jkridner[m]: I just came across compatible="ti,pruss-shmem"; again... I know I've mentioned this before on the mailing list, but... there's absolutely no reason to use a custom driver for this, the uio_pdrv_genirq in mainline works perfectly for this (I use it for shared memory myself), also for power management reasons they should be in the corresponding pruss_soc_bus rather than in &ocp, i.e.: ... Oct 21 19:35:18 ...https://pastebin.com/raw/Duvt1HJh Oct 21 19:35:40 jkridner[m]: (also, status="okay;" is pointless when creating a new node, it's just for overriding a previous status="disabled" ) Oct 21 19:36:23 jkridner[m]: the symlink = "uio/pruss1-shmem"; would give the device a /dev/uio/pruss1-shmem symlink (thanks to /etc/udev/rules.d/10-of-symlink.rules) ... adjust to taste Oct 21 19:37:27 dreamhiker: Hello! Oct 21 19:37:29 the modprobe conf file is needed because the uio_pdrv_genirq (bizarrely and obnoxiously) requires its compatible-string to be specified via module parameter (with no default) Oct 21 19:37:55 hunter2018: "ti,pruss-v2" is the compatible-string for the uio_pruss driver yes Oct 21 19:37:58 What is your issue w/ flashing the new image (what image)? Oct 21 19:38:14 from beagleboard.org/latest-images? Oct 21 19:38:48 hunter2018: https://github.com/beagleboard/linux/blob/4.14/drivers/uio/uio_pruss.c#L360 Oct 21 19:42:57 brb Oct 21 19:43:35 set_ one second: forming a message ... Oct 21 19:43:45 No issue. I have time. Oct 21 19:45:04 Embarased to say, but I have issues with flashing the new image into my BBB. Here are my steps: Oct 21 19:45:05 https://pastebin.com/RQJB1zFX) Oct 21 19:45:19 Okay. Off to view it. Oct 21 19:45:27 Thanks set_! Oct 21 19:45:53 dreamhiker: It says the page has been removed. Oct 21 19:46:04 Let me try again. Oct 21 19:46:37 which page? Oct 21 19:46:51 Oh. Oct 21 19:46:57 I see what happened. Oct 21 19:47:08 You added a ) at the end? Oct 21 19:48:36 dreamhiker: You are flashing an image from scratch or are you using the Etcher thing? Oct 21 19:49:53 dreamhiker: I just went to the page at pastebin. It says missing but when I erase the ")" in your link, it works. Is that your link, i.e. the one w/out the ")" in the link? Oct 21 19:50:27 Hi set_, I am afraid to cause the confusion and tried my best to describe it in the itemized list 1 - 6. Let me check my pastebin Oct 21 19:51:03 Okay. Oct 21 19:51:34 No confusion. I see your link but it is missing or has been removed. Look at the link you posted for me, please. Oct 21 19:51:46 The link in this chat... Oct 21 19:52:08 I just used my 2 links in the incognito browser: the worked: Oct 21 19:52:13 https://pastebin.com/KqcK75NW Oct 21 19:52:16 Okay. Oct 21 19:52:21 Let me look at that one. Oct 21 19:52:31 https://pastebin.com/RQJB1zFX Oct 21 19:53:31 I see you might have missed the space when it was going to reboot. did you press space before the bootloader reloaded? Oct 21 19:55:00 Now, this may be something for someone more familiar w/ the process of booting from scratch or from rcn's repos but i can keep trying. Oct 21 19:55:25 were you able to see pastebin? Oct 21 19:55:31 Yes. Oct 21 19:55:36 The second link worked. Oct 21 19:55:47 and the first? Oct 21 19:56:28 Teh first link yuo posted did not work but when you posted it again, it worked. Oct 21 19:57:10 The last two links work. Oct 21 19:59:41 Where are you getting your info. for this set up of Linux on the BBB? Oct 21 20:00:33 both links work, what am I looking at? Oct 21 20:00:43 neither contains "steps" Oct 21 20:00:46 both contain a kernel log Oct 21 20:02:01 looks like you're having a boot failure due to an issue in old kernels Oct 21 20:02:41 Sorry, the steps are above. Allow me to re-list those: Embarased to say, but I have issues with flashing the new image into my BBB. Here are my steps: Oct 21 20:02:41 power Oct 21 20:02:42 into my sd-card during reboot Oct 21 20:02:42 hmm, although it's passing root=UUID=... so why is it failing Oct 21 20:02:54 dreamhiker: why are you using an ancient image btw? Oct 21 20:03:56 what do you mean? No intention to use an old one. Where do I get the lastest one? Oct 21 20:04:14 this is definitely https://beagleboard.org/latest-images Oct 21 20:04:34 woops, sentence fail Oct 21 20:04:51 this is definitely an ancient system, and you can find the latest images on aforementioned page Oct 21 20:05:05 you probably want the Debian 9.5 2018-10-07 4GB eMMC IoT Flasher Oct 21 20:05:10 Start by updating your bootloader on the eMMC. Oct 21 20:05:15 Oh. Oct 21 20:05:16 no Oct 21 20:05:20 that happens automatically Oct 21 20:05:27 normally you should never manually have to fiddle with the bootloader Oct 21 20:05:29 I see you just typed that solution. Oct 21 20:05:41 it's flashed along with everything else when you reflash eMMC Oct 21 20:05:42 Flasher is available now. I keep forgetting. Oct 21 20:06:08 that is irrelevant Oct 21 20:06:40 Okay. Oct 21 20:06:42 Okay. Oct 21 20:06:54 I will do that. But bone-eMMC-flasher-debian-9.11-console-armhf-2019-10-16-1gb.img.xz: is it ancient? It has timestamp 2019-10-16 Oct 21 20:07:17 I know the issue. Oct 21 20:07:18 which is 5 days ago Oct 21 20:07:27 so I don't know what your definition of "ancient" is, but... Oct 21 20:07:39 and sure you can use the console version if you prefer Oct 21 20:07:43 but that's not what I'm seeing here Oct 21 20:07:46 You cannot sign in via the BBBW b/c it does not have connectivity at boot. Oct 21 20:07:52 also wtf am I even looking at Oct 21 20:08:00 it's booting from eMMC, yet starting an eMMC flasher? Oct 21 20:08:05 w/ the console image. Oct 21 20:08:07 I hope I'm seeing that wrong Oct 21 20:08:19 set_: usb networking Oct 21 20:08:21 or serial console Oct 21 20:08:47 also this isn't a bbbw Oct 21 20:09:03 Okay but I tried a while ago and I figured I could not use that updated, weekly build from the wiki b/c of having a console on BBBW. Oct 21 20:09:05 Oh. Oct 21 20:09:06 Okay. Oct 21 20:10:03 dreamhiker: Please just use one of the images on the beagleboard.org/latest-images page. Oct 21 20:10:26 They are easy-peasey to set up and start w/ Etcher. Oct 21 20:10:37 dreamhiker: the KqcK75NW paste looks like you're booting from eMMC with an ancient u-boot and ancient linux kernel and somehow booting into the eMMC flasher Oct 21 20:11:23 I think he is using a rcn build and uboot to flash an image. Well, this is what i thought at first. Oct 21 20:11:37 Zmatt, sorry, I got confused: Let us do step by step: is bone-eMMC-flasher-debian-9.11-console-armhf-2019-10-16-1gb.img.xz is wrong image and I need to use Debian 9.5 2018-10-07 4GB eMMC IoT Flasher ? Oct 21 20:11:54 dreamhiker: either image is fine, but you didn't flash that image to eMMC nor did you boot from it Oct 21 20:11:57 in either of those logs Oct 21 20:12:50 try powering on with sd card inserted and while holding down the S2 button (the one closest to the card slot) ... you can let go of the S2 button once the power led turns on Oct 21 20:13:16 oh never mind it looks like it erased the sd card Oct 21 20:13:35 so, flash the bone-eMMC-flasher-debian-9.11-console-armhf-2019-10-16-1gb.img.xz to sd card again, then do the above Oct 21 20:13:48 Your suggested image "Debian 9.5 2018-10-07 4GB eMMC IoT Flasher" dates to 2018. Isn't it rather old? Oct 21 20:14:20 oh they didn't update the flasher yet, that's annoying Oct 21 20:14:26 yeah a later one is preferred Oct 21 20:14:31 e.g. the 2019-10-16 one Oct 21 20:14:53 Good! Oct 21 20:15:02 but like I said, there's no evidence of that image in any of your logs: it's showing u-boot from 2016 and kernel 4.4 Oct 21 20:15:13 For how long do I need to hold the boot key? Oct 21 20:15:13 so your attempt to flash a new image to eMMC failed miserably Oct 21 20:15:25 let go once any led turns on Oct 21 20:15:32 Old stuff plays tricks on a brother. Oct 21 20:16:44 dreamhiker: it looks like you never reflashed eMMC, and additionally somehow managed to mess with /boot/uEnv.txt on eMMC to turn it into a flasher, which subsequently reflashed the sd card Oct 21 20:17:17 Would it be bad if I hold the boot button longer? Oct 21 20:17:18 that's my best guess at this moment anyway Oct 21 20:18:19 dreamhiker: it is sampled about 20ms after the power led turns on, so holding it any longer than that is pointless. it might also be harmful if you keep holding it for extended time if the kernel enables video output (but I think that only happens if hdmi is plugged in) Oct 21 20:18:34 holding it for a few seconds is not a problem, just unnecessary Oct 21 20:19:43 Thanks! Let me do it! Oct 21 20:19:51 Go, go, go! Oct 21 20:21:41 And after that: I will 1) disconnect usb; 2) remove sd-card; 3) reconnect usb. Correct? Oct 21 20:22:13 if you're feeling uncertain about the S2 button, here's a tip: try it first with S2 button pressed but no sd card inserted. this should result in the beaglebone doing nothing (only power led turns on, no console activity other than "CCC"). now, without powering off, insert the sd card and press the reset button Oct 21 20:22:53 once it's done with flashing it will turn itself off, then remove the sd card and turn it back on (by pressing the power button or by unplugging it from usb and plugging it back in) Oct 21 20:24:02 rcn-ee[m]: not sure whether to ping you or jkridner[m] about this, but the Flasher image at https://beagleboard.org/latest-images is outdated compared to the standalone image Oct 21 20:27:41 Starting eMMC Flasher from microSD media Oct 21 20:27:41 ---------------------------------------- Oct 21 20:28:10 What happened? Oct 21 20:33:06 zmat, thanks! it seems it is ok now Oct 21 20:33:47 uname -a -> Linux beaglebone 4.14.108-ti-r120 #1 SMP PREEMPT Wed Oct 9 18:24:45 UTC 2019 armv7l GNU/Linux Oct 21 20:34:55 :) Oct 21 20:35:00 I will try another one (Beaglebone Green) Oct 21 20:37:30 BBG! Oct 21 20:38:45 I am confused by ==> Erasing: /dev/mmcblk1 Oct 21 20:38:56 why? Oct 21 20:39:01 mmcblk0 = sd card, mmcblk1 = eMMC Oct 21 20:39:35 Is it during flashing or always? Oct 21 20:40:27 always on current kernels (on old kernels the assignment was basically unpredictable) Oct 21 20:41:39 or rather, on old kernels if you didn't have an sd card inserted then eMMC would be mmcblk0, if you did have an SD card inserted it would be unpredictable which is which Oct 21 20:42:00 or maybe not unpredictable but at least unreliable, there was no guarantee Oct 21 20:42:46 that was fixed quite a while ago though, I think kernel 4.9 Oct 21 20:43:21 Thanks! I must have followed some old forum. Oct 21 20:44:24 Also, curious, if it is a flasher image, why do I need to hold S2? What if I do not hold it? Oct 21 20:45:01 you normally don't need the S2 button, but since you somehow ended up with a big mess it was a good idea to use it to force booting from sd card Oct 21 20:45:26 if you power on with the S2 button held down, eMMC is removed from the boot device order considered by bootrom (to load u-boot) Oct 21 20:47:34 dreamhiker: s2 switches the boot order... normall eMMC is 'first".. Oct 21 20:48:12 Thanks for a great explanation! Oct 21 20:49:15 And while on the subject, what is the easiest to revers the operation and to flash sd-card from eMMC? Oct 21 20:51:22 dreamhiker: same script goes both ways: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC Oct 21 20:52:18 you could also just run: "sudo /bin/bash /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh" but it's not 100% reliable.. works best in single user mode.. Oct 21 20:52:20 rcn-ee[m]: but how would you launch it without modifying /boot/uEnv.txt (which would render your eMMC unbootable until you fix it) Oct 21 20:52:47 right, that problem :) Oct 21 21:00:52 Thanks! Will try! Oct 21 21:33:13 zmatt: You said last week that there is a list of predefined states for the /sys/bus/platform/devices/my-pinmux-switch/state that can be found here: https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinctrl-state.h Oct 21 21:33:49 If you make a new state with pinctrl-names = "default", "foo"; Oct 21 21:34:01 is "foo" automatically added as a state? Oct 21 21:34:21 that property lists the states for the device Oct 21 21:34:27 that's its entire purpose Oct 21 21:35:02 any name that doesn't have a predefined meaning is freely usable for the driver's (i.e. your) own purposes Oct 21 21:36:46 Ahh, got it! So for instance there is a leds property that has pinctrl-names="default"; because you obviously want these 4 led pins to work by default. Oct 21 21:36:55 *in the base .dts file Oct 21 21:37:11 most devices only declare a "default" pinmux Oct 21 21:37:22 I see, I didn't recognize that at first. Oct 21 21:37:24 most drivers never request any specific pinmux state Oct 21 21:37:37 (hence then the kernel will automatically select the "default" state) Oct 21 21:42:15 I see that P9.11 on the BBAI has two indices, 203 and 136. Is this what you were talking about when you said "when two processor pins map to one expansion header pin, I suggest adding pinmux for both of them and just setting the unused one to mux mode 15" Oct 21 21:42:30 yep Oct 21 21:43:40 Why in the world would they make two processor pins map to one expansion header!? Is is just because there aren't enough header pins and so you kind of have a second kind of pinmuxing by putting on pin in mode 15? Oct 21 21:43:44 or maybe mux mode 14 (gpio) since rcn mentioned something about there being something with mux mode 15 (although it's not clear to me what he meant) Oct 21 21:44:04 hunter2018: even the BBB has a few expansion header pins that connect to two processor pins Oct 21 21:44:17 and yes on the BBAI there are way more processor pins than expansion header pins Oct 21 21:44:37 hunter2018: it was to replicate the functionality of the BBB Oct 21 21:44:45 it just means that for a particular expansion header pin you can select from the functionality of either of those pins Oct 21 21:44:50 So can you burn something up by for instance driving one processor pin high and the other low? Oct 21 21:44:52 hunter2018: here is a base template for overlays: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BBAI_TEMPLATE.dts Oct 21 21:44:53 so it's kinda like having a bunch of extra mux modes Oct 21 21:45:00 If they're connected together? Oct 21 21:45:17 hunter2018: absolutely, but same goes for driving a pin as output when external hardware also drives that pin Oct 21 21:45:18 I got one 16bit lcd to show "something" laste week: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BBAI_BB-BONE-LCD7-01-00A3.dts Oct 21 21:47:28 rcn-ee[m]: have you ever considered using the perl script from my overlay-utils to be able to write overlays much more readably? (i.e. like a .dtsi instead of having to manually write out fragment{} blocks) Oct 21 21:47:47 hunter2018: yes if your not careful, you can damage it.. Oct 21 21:48:19 what is referencing the cape_pins_default node? Oct 21 21:49:14 or... what is it even Oct 21 21:52:23 zmatt: jason setup a default-pin tate for the cape pins.. https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.14.x-ti/src/arm/am5729-beagleboneai.dts#L478 so in the overlay we need to over-write it to grab our pins' it should be the safest default state.. Oct 21 21:52:54 zmatt: yeah i think it would be nice to merge the overlay-utils perl script into the bb.org-overlays repo.. Oct 21 21:53:48 e.g. I'd write this overlay something like this: https://pastebin.com/raw/dSVaUEE1 (I've omitted the "default" block for brevity) Oct 21 21:53:56 rcn-ee[m]: why is that done in DT instea of in u-boot? Oct 21 21:55:12 this is terrible for compatibility, how would you deal with this if you have two overlays? Oct 21 21:55:58 proof of concept.. Oct 21 21:56:36 a few issues: https://photos.app.goo.gl/H6WmXK2tndHagw2VA Oct 21 21:58:43 strange those lines Oct 21 21:59:10 are the colors supposed to look like this? they seem off Oct 21 21:59:35 and the "pink" that's not quite "black" background. ;) Oct 21 22:00:15 ah so it's not :) Oct 21 22:03:20 i'm hoping it's just an un-documented RGB mode instead of the "other" ball pin's messing it up.. Oct 21 22:03:36 if it's the ball pin's.. no good.. ... Oct 21 22:04:30 I don't see how it could be the other ball messing it up like this... this doesn't look like a signal integrity issue to me Oct 21 22:05:59 but yeah, multiple overlays for the bbai.. I think it would be best to pre-process all the overlays with dtc-tools, then append the "unused" pins, and finally have "u-boot" load that one overlay or appended *.dtb Oct 21 22:10:10 zmatt: I'm writing the .dtsi for my application now. I need to use P9.30 as a PRU output pin. Does the one pin I've setup look right so far? https://pastebin.com/raw/c0smfYuw Oct 21 22:10:12 but again, why isn't the default just configured in u-boot? and leave them unused by default in DT (hence the kernel won't touch them) Oct 21 22:11:00 hunter2018: that won't do what you want... if you don't want a pin to be driven, don't mux it to pruout mode Oct 21 22:12:00 I'm not sure where PIN_INPUT is defined, I assumed that this would override the fact that I put it in MUX_MODE13 (which is an output mode) Oct 21 22:12:02 PIN_INPUT actually means in/out Oct 21 22:12:12 PIN_OUTPUT means out-only Oct 21 22:12:25 the difference is just whether the input-buffer is enabled or not Oct 21 22:12:51 https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/pinctrl/dra.h#L62-L66 Oct 21 22:13:55 also, if you're normally using a pin as output, that probably means it doesn't have external pull so you should enable internal pull (up or down) unless you're certain the net is being driven (by the am572x or externally) Oct 21 22:15:07 Doesn't the fact that it is an output mean that it is being driven all the time by the am572x? Oct 21 22:15:25 I thought pullup/pulldown only made sense for inputs/ Oct 21 22:15:45 basically two things to avoid w.r.t. pull-up/down: avoid having a net that is neither driven nor pulled (by the am572x nor external hw), and avoid having conflicting pull-up/down on the same net (either between two am572x pins tied together or between am572x and any external pull-up/down) Oct 21 22:16:16 yeah for a mode that's continuously driven like pruout its okay to disable pull... it's also okay to leave it enabled Oct 21 22:16:45 but you enabled it in your active mode and disabled it in your (failed attempt) at output-disabled mode Oct 21 22:16:51 which is exactly the wrong way around Oct 21 22:17:36 for your default mode use gpio (14) or safe (15) mode.... Oct 21 22:19:03 rcn-ee[m]: so what was wrong again with safe mode, or do I need to poke jkridner[m] for an explanation? (and if there's a problem with safe mode, why isn't this in the errata?) Oct 21 22:19:27 Got it! Oct 21 22:20:25 hunter2018: leaving pull-up/down enabled unnecessarily wastes a tiny bit of power, disabling pull up/down when it really should be enabled can damage the processor in the long run... so I tend to err on the side of leaving them enabled Oct 21 22:21:00 though actually now that I think of it, I'm not sure if the pull-up/down on the am572x is as weak as it is on the am335 Oct 21 22:21:03 x Oct 21 22:21:11 if it's stronger then it may be more relevant to disable it when appropriate Oct 21 22:21:45 Got it! But did you misspeak when you said that "also, if you're normally using a pin as output, that probably means it doesn't have external pull so you should enable internal pull (up or down) unless you're certain the net is being driven (by the am572x or externally)" Oct 21 22:22:13 Wouldn't that be you need a pullup/pulldown for inputs mainly? Oct 21 22:22:30 Because aren't outputs always being driven? Or am I confused Oct 21 22:22:55 hunter2018: if you're normally using the pin as output, then if (in default mode) you temporarily arrange for that output to be disabled, you almost certainly need a pull-up or pull-down (depending on the desired default level) in that state Oct 21 22:23:12 so no, I didn't misspeak Oct 21 22:23:22 Ok, that makes sense. Oct 21 22:24:16 But as long as a pin is actually in an output mode then it will be okay because it is actively being driven by the am572x Oct 21 22:24:31 correct Oct 21 22:24:47 so in active (pruout) state you don't need pull-up/down Oct 21 22:25:38 in default state (gpio/safe mode) you do want pull-up/down ... probably pull-down to match the default state after reset Oct 21 22:27:03 And can I just use the existing default state instead of redefining it as I've done? Oct 21 22:29:55 what do you mean "existing default state" ? Oct 21 22:30:41 The state that the base device tree uses. In my case the am5729-beagleboneai.dts Oct 21 22:31:05 It has some default state for the P9.30 pin upon startup, so assuming I don't want to mess with that... Oct 21 22:32:34 oh you mean the weird giant pinmux block I learned about today? that one is a big problem you'll need to work around, apparently currently the only way to deal with it is by overriding it with a copy-pasted version where you commented out the pins you use Oct 21 22:33:04 which is terrible but not really much alternative possible until this is fixed in a better way Oct 21 22:33:44 since otherwise you'll get a pinmux conflict (two drivers trying to claim the same pin(s)) Oct 21 22:35:28 rcn-ee[m]: so how are the pins currently muxed in u-boot? what happens if the cape-default block is just entirely disabled? Oct 21 22:35:51 Gotcha! So I can comment out my pin's line in the am5729-beagleboneai.dts file: DRA7XX_CORE_IOPAD(0x36DC, MUX_MODE14) /* B13: P9.30: mcasp1_axr10.off */ Oct 21 22:36:20 Then I can put this same line into my pru-default node. Oct 21 22:37:21 If I don't want to change the default startup behavior of that pin. Oct 21 22:37:28 as a rule I don't recommend modifying any upstream .dts/.dtsi file for personal customizations, it's generally better to override stuff in your custom .dts... but you can do it as a temporary hack of course Oct 21 22:38:42 Wait, but I thought I had to modify the am5729-beagleboneai.dts file by commenting out that line or else i'll get a pinmux conflict. Oct 21 22:40:11 no, I said you should override that block Oct 21 22:41:16 by copy-pasting it into your dts and then modifying it Oct 21 22:44:33 rcn-ee[m]: any progress on the git bundle stuff yet?! :p Oct 21 22:54:42 Gotcha, is this looking better? https://pastebin.com/raw/E5Wggd5r Oct 21 23:03:54 rcn-ee[m]: looks like maybe it's configured into 24-bit output mode... whereas on the am335x that would swap red and blue, with DSS you lose the red channel entirely and instead just output the 16 bits from blue and green channels: https://docs.google.com/spreadsheets/d/e/2PACX-1vR_yw3T67jWc4I7mjxl3NAyeFClZ_k27cvOWEuryKeA_5LTABJ54xelpHAtf8zXO3iLmN7K55Se5tHV/pubhtml?gid=1441290740&single=true Oct 21 23:05:49 hunter2018: yes, apart from indentation (and inaccurate comments, though not your fault since you copy-pasted those) Oct 21 23:17:11 rcn-ee[m]: oh, you already have data-lines = <16> ... hmm Oct 21 23:17:24 rcn-ee[m]: oh well, there goes that idea Oct 22 00:28:15 zmatt: i think it's the RGB fourcc profile, everything is the correct spot, just way red. it looks like you can specify a bus-format in the panel driver.. (just not in teh dt..) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c?h=v5.4-rc4#n2776 <- same panel for the am335x, but we use it in 16bit mode on teh bbb, but it's hardcoded to 24bit mode: Oct 22 00:28:16 MEDIA_BUS_FMT_RGB888_1X24 (am335x-evm must have used a 24bit inteface..) Oct 22 00:29:19 this isn't the driver you're using though Oct 22 00:29:23 I think? Oct 22 00:29:42 "panel-dpi" is in omapdrm/displays/ Oct 22 00:30:54 Sadly, i'm stuck on v4.14.x-ti still, v4.19.x-ti doesn't even light up the display at this point.. that panel-simple doesn't have the reference i need, and my backport faiiled. ;) Oct 22 00:32:04 ps, can't find it at the moment, but it looks like someone who worked on teh am5, remembered the am3 bug.. it looks like you could use the encoder/scaller to swap any set of pins if you screwed up your layout (or internal hardware) Oct 22 00:34:04 and based on a quick glance DSS doesn't have much configurability for its parallel video output format... mainly just a 2-bit selector for the width ( 12, 16, 18, 24 } Oct 22 00:34:25 you can swap colors using a colorspace transformation Oct 22 00:34:43 I don't think any other kind of pin-swapping is possible, but I haven't examined it in much detail Oct 22 00:40:53 ah, it's the vip packer engine.. it just allows you to more easliy configure the 24bit input.. Oct 22 00:42:05 yeah the inputs have a bunch of options Oct 22 00:42:29 (I think) Oct 22 00:42:59 we can pretty much assume, camera's don't always have the same output.. Oct 22 00:44:02 AFAIK, there is no SW solution Oct 22 00:44:19 has the problem been determined yet even? Oct 22 00:44:20 <--- built up a 24bit LCD adapter and had to hand rewire it Oct 22 00:44:40 then run the SW in 16bit mode. the display hw on the AM33 sucks Oct 22 00:45:04 are we talking about the same thing? Oct 22 00:45:12 rcn is having weird colors on the BBAI Oct 22 00:45:24 oh the AI Oct 22 00:45:33 that I donno. I had that problem on the BBB Oct 22 00:45:36 I've checked the wiring on the AI and that seems okay Oct 22 00:45:57 the AI has the full HW thingie like the DM37x Oct 22 00:46:04 it was too basic on teh am33. Oct 22 00:46:12 on the BBB you'll just get red and green channels swapped if you use 16-bit when the hw is wired up for 24-bit or other way around Oct 22 00:46:32 (technically it still supports both 16-bit and 24-bit pixel formats either way, just not the ones people are used to) Oct 22 00:46:52 zmatt: 'not the ones people are used to' <-- very funny Oct 22 00:46:54 but that's an LCDC-specific issue, not applicable to DSS Oct 22 00:46:58 veremitz: i have a patch, it's not working the way it should.. Oct 22 00:47:01 thinking about that errata, was it a really a problem. just wan't properly documented.. then it became an errata.. Oct 22 00:47:12 hand cut and rewiring 24 wires on a PCB is much less funny Oct 22 00:47:48 rcn-ee[m]: have you checked to see the clocking looks sane? Oct 22 00:47:50 rcn-ee[m]: I mean, it's definitely neither desirable nor expected Oct 22 00:48:01 i find it easier to work back from the HW in Oct 22 00:48:18 a parallel LCD clocking is pretty trivial Oct 22 00:48:47 now to wire up a FTDI adapter for the BBAI Oct 22 00:48:49 I don't see clocking issues causing wrong colors though Oct 22 00:49:09 LCDs do funny stuff when the clocking isn't right Oct 22 00:49:24 rcn-ee[m]: have you tried some test patterns to see if there's an obvious pattern in whatever is going wrong? Oct 22 00:49:31 making sure the timing and voltages are correct will help prevent a lot of baldness issues Oct 22 00:49:36 ds2: if your lazy, i had one made up: https://www.digikey.com/products/en?keywords=BBCAI-ND Oct 22 00:49:53 zmatt: i'll try that tomorrow.. Oct 22 00:50:31 rcn-ee[m]: I can't afford to blow $20 on this Oct 22 00:51:03 6 pin inline header, 30G wire and tack soldering Oct 22 00:51:22 vs $8 + $8 shipping plus tax plus another 2-3 days :( Oct 22 00:51:45 rcn-ee[m]: cool .. do you have it online anywhere yet? Oct 22 00:53:48 veremitz: no.. still working on it, for some reason, the dir already existed, and the git reference didn't transfer over.. hack job: https://paste.debian.net/1109051/ Oct 22 00:54:43 the other issue, linus rebuilds the bundle once a week, so the "wget -c" would fail from week to week.. Oct 22 00:55:04 rcn-ee[m]: yeah its a pity they're not snapshotted :/ Oct 22 00:55:13 it was faster then a straight 'git clone'... but i need to bulletproof it for users. Oct 22 00:55:15 they -should- stack Oct 22 00:55:38 does it? ;) we could find out in a week... Oct 22 00:56:02 well .. I haven't looked beyond that article .. Oct 22 00:56:14 we do repo snapshots for gentoo .. can't be -that- hard .. Oct 22 00:56:43 yeah i thought about hosting a proven snapshot.. Oct 22 00:56:52 but i need so much space for deb files and the rootfs's.. Oct 22 00:57:01 yeah :/ Oct 22 00:57:19 but kernel.org has better worldwide mirrors then my linode, so it wouldn't be worth it.. Oct 22 00:59:04 ah I see yeah it looks like its re-created Oct 22 00:59:38 I'm not sure I'd rely on wget -c fwiw .. I've come unstuck with the broadcom firmwares blindly using that :P Oct 22 00:59:56 I think I found another wget option Oct 22 01:00:13 iirc it doesn't do any 'version'/checksum checking Oct 22 01:00:47 iirc it does in combination with -N Oct 22 01:00:50 (based on timestamp) Oct 22 01:01:00 ah that would probably be enough Oct 22 01:01:18 for a file that doesn't change, it works.. but something dynamic.. but once you drop the -c, its really no different then a git clone for reliablity.. Oct 22 01:01:40 yeah you'd have to timestamp the download somehow Oct 22 01:01:48 or just overwrite and hope Oct 22 01:01:56 is there an actual up to date schematic on what is on the BBAI? Oct 22 01:01:56 what's the context? in what sense is git clone not "reliable" ? Oct 22 01:02:17 zmatt: kernel.org are recommending moving off heavy git clones to using 'bundles' Oct 22 01:02:31 looks like there was a last minute bodge resistor on the console Oct 22 01:02:33 because it pounds their git servers.. which is true Oct 22 01:02:44 esp. for full clones Oct 22 01:02:50 fair... presumably git will check a lot when unpacking a bundle? Oct 22 01:03:11 yeah it seems all the integrity stuff is built-in Oct 22 01:03:12 and wget + git bundle -> git clone fuu... is actually faster then a clean 'git clone' Oct 22 01:03:42 well you can stitch and multi-thing can't you with a download Oct 22 01:03:52 harder with a single git thread Oct 22 01:03:52 ah you actually pull from a git bundle Oct 22 01:03:57 yup Oct 22 01:04:10 zmatt: https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/plain/linux-bundle-clone Oct 22 01:04:12 ds2: this is a useful spreadsheet: https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit#gid=227990209 Oct 22 01:04:58 ds2: otherwise: https://github.com/beagleboard/beaglebone-ai Oct 22 01:05:09 zmatt: and/or https://www.kernel.org/cloning-linux-from-a-bundle.html Oct 22 01:05:22 rcn-ee[m]: that github is out of date. There is at least 1 resistor that is on a board and not on the schematic there and I don't see a ECN to add that Oct 22 01:05:42 ds2: yeah embest did that.. Oct 22 01:05:55 rcn-ee[m]: is that the ONLY undocumented change? Oct 22 01:06:05 ugh why dont people adhere to ECN's :/ Oct 22 01:06:10 wish they wrote a ECN to document it Oct 22 01:06:16 it's actually teh same bug that's on teh am335x.. if you have noise on the line, it stops u-boot.. only we had a software workaround for ever.. Whereas embest... hey let's just stick a resistor on it and call it good.. Oct 22 01:06:42 (FACE BALM) Oct 22 01:06:51 rcn-ee[m]: there is a resistor on the BBB/BBW schematics for that... I'd think embest should have put pads down for that resistor THEN figure out if needed Oct 22 01:07:09 veremitz: well those bundles at least have a Last-Modified header Oct 22 01:07:13 so wget -N -c should be safe Oct 22 01:07:17 what should be a easy tack 3 wires requires a little planning Oct 22 01:07:25 guessing that is probally a 10K pull down Oct 22 01:07:32 zmatt: sounds good Oct 22 01:07:40 * ds2 miss gerald's work :/ Oct 22 01:08:07 gerald did a tough job also Oct 22 01:08:16 but he must have done the big haul Oct 22 01:08:35 we stole that serial design from gerald.. because it's reliable.. unlike the blue.. which i've blown up way too many.. Oct 22 01:08:59 the blue looks like a power domain nightmare to me Oct 22 01:09:15 blue - no power/battery connected: - hit a key on keyboard while connected to usart = blown blue.. Oct 22 01:09:34 smoke 3 of them before i figured out why.. expensive morning.. Oct 22 01:09:50 putting an always-on 5V supply on the GSM connector (meant to power a GSM module which will then drive its uart signal into the BBBlue even while powered off) is also a terrible idea Oct 22 01:09:52 ow f*** ! Oct 22 01:10:51 well the uart buffer on the BBB isn't exactly perfect either, being powered from VDD_3V3B instead of VDD_3V3A Oct 22 01:11:33 when doing testing with battery-power that resulted in 45 mA being driven into the UART0_RXD pin's protection diode until I quickly cut the power Oct 22 01:13:11 oh, the blue has no buffer at all? Oct 22 01:13:48 then I don't see how hitting a key on a keyboard would be relevant, being connected while the BBB is shut down (regardless of whether a battery is present) should suffice to fry it Oct 22 01:13:51 nope.. all the usarts are tied directly to the i/o... "ALL"... Oct 22 01:14:52 The only way any of the i/o is remotely safe, is if you have a good battery plugged in.. otherwise it's very easy to fry.. Oct 22 01:14:56 it might actually be possible to abuse an xds100v2 as usb-serial converter with integrated level shifter :) Oct 22 01:15:12 I don't see how a battery would matter much... to present accidently cutting power you mean? Oct 22 01:15:20 thus i don't touch the blue anymore.. to risky.. Oct 22 01:15:23 a shutdown would still be fatal Oct 22 01:16:34 While powered and running, the i/o would have some protection on the blue internally.. but once the battery or power is gone.. any voltage on any of those interfaces is fatal.. Oct 22 01:17:37 :( Oct 22 01:17:52 bummer, ftdi didn't choose a sane pin usage... uart mode RxD (in) is on the same pin as mpsse mode TDI (out), so using the xds100v2 (or other ft2232h-based jtag debuggers with level shifter) in uart mode is a no go Oct 22 01:18:25 rcn-ee[m]: well it just needs to be powered or running... doesn't matter ultimately *how* it's powered Oct 22 01:18:31 *powered and running Oct 22 01:19:25 it would be nice to have a serial cable with level shifter that takes power (for the target-side of the level shifter) from the target Oct 22 01:19:58 (similar to what any not-completely-shit jtag debugger does for jtag) Oct 22 01:21:02 rcn-ee[m]: or use the other FTDI cable with a VDD_IO line and wire that to the power Oct 22 01:21:34 zmatt: nothing a few 0.1 headers and a wire wrap tool can't fix in a jiffy Oct 22 01:39:50 hmmm OOTB, BT doesn't work Oct 22 02:01:03 rcn-ee[m]: do you know how complete is the ti-tidl package? the makefile comaplains of missing stuff **** ENDING LOGGING AT Tue Oct 22 03:00:24 2019