**** BEGIN LOGGING AT Wed Jun 17 02:59:57 2020 Jun 17 03:00:33 I tried that custom DTB method from here https://www.element14.com/community/community/project14/visionthing/blog/2019/11/16/beagleboard-ai-brick-recovery-procedure Jun 17 03:01:25 I am going to create that custom file and let you know if it changes anything. Jun 17 03:02:36 yep that person has clearly also talked to me, since I recognize his dts as containing stuff I've written :D Jun 17 03:03:10 ohh nice Jun 17 03:05:56 jkridner[m]: u-boot default pinmux for the bbai really needs to get fixed asap. it's really not okay that a whole bunch of pins are being configured as outputs until the kernel reconfigures them based on DT (which might never happen when someone's custom pinmux conflicts with the "cape-default" hack)... this is something that could easily end up destroying hardware Jun 17 03:09:45 nothing changed after using custom dtb :( Jun 17 03:10:38 lorforlinux: share your custom dtb please? Jun 17 03:10:41 *dts Jun 17 03:11:13 sharing both give me 2 minutes Jun 17 03:11:32 you've made sure you have a suitable cape-default override like I explained? no errors in kernel log about pin conflicts? Jun 17 03:12:07 sharing the dts suffices, I have no use for the dtb Jun 17 03:12:09 it was just a typo Jun 17 03:13:38 okie I have looked for conflicts using /opt/scripts/tools/version.sh and it's not showing any Jun 17 03:17:41 dts? Jun 17 03:19:30 https://pastebin.com/Ymm57Rw5 Jun 17 03:20:09 https://pastebin.com/SYjPftgi Jun 17 03:20:39 why did you paste the whole beagleboneai dts? Jun 17 03:20:53 I hope you haven't been modifying that (you should never do that) Jun 17 03:21:31 and your custom dts doesn't actually customize anything? Jun 17 03:21:39 I tried modifying it but removed changes afterwards. Jun 17 03:22:26 I just want to change the muxmode of that one pin, for customization i am using DT overlay. Jun 17 03:22:59 you can do this in an overlay as well, if overlays work (I didn't know overlays were supported yet on bbx15/bbai) Jun 17 03:23:22 it's either-or, there's no point in using a custom dts *and* an overlay Jun 17 03:23:55 but to be honest, as long as that cape-default monstrosity is necessary, it's completely pointless to use overlays Jun 17 03:24:13 since it's mutually exclusive with modularity Jun 17 03:24:15 yes i have created virtual overlays and they are working fine at least 2 of them. Jun 17 03:24:51 the whole benefit of overlays is that they can be modular, each overlay being responsible for some small set of customizations Jun 17 03:25:00 how can i contribute to resolve the u-boot part? Jun 17 03:25:14 nagging jkridner ? Jun 17 03:25:36 ohh Jun 17 03:25:49 or build a custom u-boot yourself Jun 17 03:26:31 anyway, nothing wrong with using a custom dtb, it's not that scary ;) Jun 17 03:26:45 I guess i have to build a custom u-boot then. Jun 17 03:26:47 just add your customizations to your bbai-custom.dts Jun 17 03:27:09 put the compiled bbai-custom.dtb in /boot/dtbs/ and set "dtb=bbai-custom.dtb" in /boot/uEnv.txt Jun 17 03:27:59 you should not touch any standard dts files like am5729-beagleboneai.dts Jun 17 03:28:10 Actually at last i want an overlay only, that's why i tried the custom dtb first for one peripheral and when similar overlay worked i switched to creating overlays. Jun 17 03:28:59 yes i have done all that, compiled the custom dtb then copied it into /boot/dtbs/ and then changed the uEnv.txt Jun 17 03:29:00 you should be able to restore its original contents with git checkout -- am5729-beagleboneai.dts assuming you're working in a git checkout of the BeagleBoard-DeviceTrees repository Jun 17 03:29:41 I only changed one muxmode from 14 to 15 (Driver-Off) Jun 17 03:29:50 sadly it didn't do anything Jun 17 03:29:53 why? Jun 17 03:30:03 there's not really any benefit to doing that Jun 17 03:30:35 yes learned that hard way Jun 17 03:31:22 anyway, like I said: it doesn't really matter if you use an overlay or a custom dts, the result is identical Jun 17 03:32:05 the main benefits of a custom dts over an overlay are better compile-time error-checking and the ability to use /delete-node/ and /delete-property/ (which don't work in an overlay) Jun 17 03:32:06 okay thank you very much for your valuable time, I guess compiling u-boot is the next task now. Jun 17 03:32:17 the main downside is kernel version dependence Jun 17 03:32:21 I mean, you don't have to Jun 17 03:32:38 using a fixed cape-default block Jun 17 03:32:45 is a workaround for now Jun 17 03:33:02 but in the snippet you shared you enabled _all_ lines of the cape-default block Jun 17 03:33:11 so it'll conflict with all other uses of expansion header pins Jun 17 03:33:36 your cape-default block has to omit declarations for all pins for which you have other pinmux declaration blocks Jun 17 03:33:40 Can you try changing the pinmux of P9.11b on your machine? Jun 17 03:34:02 I don't have my bbai at hand, but I know I can change it just fine Jun 17 03:34:25 your problem has nothing to do with P9.11, one glance at show-pins makes it completely obvious that nearly all of your pinmux is a mess Jun 17 03:34:35 the reason for that is also simple: cape-default wasn't applied Jun 17 03:34:58 oh Jun 17 03:34:59 or Jun 17 03:35:07 what does show-pins output look like now? Jun 17 03:35:24 because I just realized that specifying a custom dtb in /boot/uEnv.txt might disable overlays Jun 17 03:35:41 since, like I said, using both a custom dtb _and_ overlays doesn't really make sense Jun 17 03:36:32 my overlay -> https://pastebin.com/cpq3jvcT Jun 17 03:38:15 show-pins output is same Jun 17 03:38:17 that looks like it should work, provided you don't have any other overlays Jun 17 03:38:27 nothing else Jun 17 03:39:11 (btw, why are you giving &uart5 the symlink "bone/i2c/4" ?!) Jun 17 03:39:47 following this https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec Jun 17 03:40:29 bone/i2c/4 Jun 17 03:40:32 ^^^ Jun 17 03:40:32 ^^^ Jun 17 03:40:33 ^^^ Jun 17 03:40:38 for an aurt Jun 17 03:40:40 *uart Jun 17 03:40:52 ohh my bad Jun 17 03:41:25 I don't have your udev in plave so it's not doing anything right now. Jun 17 03:42:02 fixed that :D Jun 17 03:43:55 and I have no idea why cape-default still doesn't apply for you Jun 17 03:44:09 I know the technique works Jun 17 03:44:37 can you pastebin the show-pins output again, just to confirm? Jun 17 03:44:42 I am having problems with P9_24 Jun 17 03:45:34 https://pastebin.com/ckW2cD82 Jun 17 03:46:17 dmesg is saying Jun 17 03:46:18 https://pastebin.com/UEKFkX8B Jun 17 03:46:37 I should be ok in terms of the LCD Jun 17 03:46:48 maybe I do need to explicity disable my HDMI? Jun 17 03:47:00 show-pins and version.sh output -> https://pastebin.com/d41Dpe8x Jun 17 03:47:18 MattB0ne: it's saying the pin is in use by a serial port Jun 17 03:48:55 forgot I had one of the prestock overlays enabled Jun 17 03:49:15 MattB0ne: a quick glance at show-pins output would have shown the pin being muxed to uart mode Jun 17 03:49:38 lorforlinux: okay really weird, I have no idea what's going on Jun 17 03:50:26 okay no problemo ;) Jun 17 03:50:47 lorforlinux: could you try setting status="disabled" on your &uart5 (in your overlay) just to see what happens? Jun 17 03:51:06 oh wait Jun 17 03:51:13 no! Jun 17 03:51:44 you're not overriding the existing &cape_pins_default node Jun 17 03:52:18 you're overriding &dra7_pmx_core and replacing the node Jun 17 03:52:39 that might not work right, especially since you're creating a new &cape_pins_default label Jun 17 03:53:13 instead, use target=<&cape_pins_default>; and have just the pinctrl-single,pins property in the __overlay__ Jun 17 03:53:19 and god I hate overlay syntax Jun 17 03:53:44 why would you prefer writing it like this? lol Jun 17 03:54:39 there is a file created by rcn-ee src/arm/BBAI_TEMPLATE.dts that i followed :D Jun 17 03:54:56 zmatt: I got ecap activated and I tried running the ecap firmware under your debugging script Jun 17 03:54:58 https://pastebin.com/Q63s2Bcf Jun 17 03:55:04 are they not compatible Jun 17 03:55:36 MattB0ne: what's after the sbco statement in your source code? Jun 17 03:55:55 after that last sbco I mean Jun 17 03:56:08 let me check Jun 17 03:56:37 let me guess, absolutely nothing because you just pasted my snippet (which was just that: a _snippet_, not a full program) into a file Jun 17 03:57:04 you are correct Jun 17 03:57:11 so the program counter ran beyond the end of your code, causing debugging.py to index out of bounds Jun 17 03:57:40 since it's trying to look up the 12th instruction of your 11-instruction program Jun 17 03:58:20 I should probably make py-uio warn if you're trying to load a program that doesn't end in a "halt" instruction or an unconditional jump Jun 17 03:58:35 ok Jun 17 03:58:43 all assembly should end in halt ? Jun 17 03:59:12 or a jmp Jun 17 04:00:13 usually pru programs are designed to run indefinitely hence they'll end in a jmp (like the decoder does) Jun 17 04:00:35 but if you just want it to do something and then halt, then it should end in "halt" Jun 17 04:01:25 ok Jun 17 04:01:32 lorforlinux: maybe I'm wrong, but I suspect that's not kosher Jun 17 04:03:35 that didn't work wither :( Jun 17 04:04:53 jkridner[m] might have something on this will try talking to him Jun 17 04:05:10 lorforlinux: so ehh, does the bbai IoT TIDL image have overlays enabled in its /boot/uEnv.txt ? because the console image doesn't Jun 17 04:07:28 boot log prompts to turn on the overlays by setting enable_uboot_overlays=1 that's what i did (just like we have for BBB) Jun 17 04:07:51 if it's not enabled by default that should be taken as a strong indication that it's not officially supported yet Jun 17 04:08:46 ohh okay, didn't knew that :D Jun 17 04:13:02 So I am looking at the TI TRM for eCAP Jun 17 04:13:28 I am supposed to just right to certain bits in these eCap registers and start the thing right ? Jun 17 04:13:41 there code snippets are not helpful for one at my level Jun 17 04:13:46 their* Jun 17 04:14:39 lorforlinux: can you try with overlay disabled and just a custom dts: https://pastebin.com/6WaQVKq7 Jun 17 04:14:51 (hopefully I didn't make any mistake) Jun 17 04:15:41 other than leaving the comments on P9.24/26, lol Jun 17 04:17:02 MattB0ne: can you give me the link to my ecap snippet? I can't immediately find it Jun 17 04:17:31 https://pastebin.com/raw/sMa8qvqa Jun 17 04:18:22 like is there a go command? =? Jun 17 04:28:14 also what is the deal with shadow mode Jun 17 04:29:11 writing to CAP3&4 enables shadow mode Jun 17 04:29:22 MattB0ne: https://pastebin.com/raw/sfbZx4W5 Jun 17 04:30:19 that would be what I call ECAP_LD_MAXIMUM and ECAP_LD_COMPARE .. and what "the deal" is with them is explained in the comment after those Jun 17 04:30:24 (which was already there in my original version) Jun 17 04:31:50 but the short version is: set ECAP_MAXIMUM and ECAP_COMPARE during initialization (before eCAP is enabled), but once it's enabled updating the frequency and duty cycle should be done by writing ECAP_LD_MAXIMUM and ECAP_LD_COMPARE respectively Jun 17 04:32:25 updating the pwm frequency is probably not something you need, hence you won't use ECAP_LD_MAXIMUM Jun 17 04:33:12 note that you could also initialize eCAP using py-uio, in which case pru only ever needs to write to ECAP_LD_COMPARE to change the pwm output Jun 17 04:36:05 ok Jun 17 04:46:27 is shadow loading a common term Jun 17 04:48:00 the term "shadow registers" definitely shows up here and there Jun 17 04:48:22 that hold a copy of the real register for one reason or the other Jun 17 04:48:38 sort of like a backup file Jun 17 04:48:45 foo.bak Jun 17 04:49:22 example of pru ecap initialization using py-uio: https://pastebin.com/ZswaUEB1 .. this is basically equivalent to pasm snippet for initialization, except there I forgot to initialize the counter to 0 Jun 17 04:49:55 should you decide to initialize it using pru code it would be a good idea to add that initialization to it Jun 17 04:50:24 though tbh if you're using py-uio, then using it to initialize ecap makes sense Jun 17 04:50:54 since it's simpler in python and there's no benefit in making pru do that work Jun 17 04:51:24 yeah I will do so in py-uio Jun 17 04:51:41 I would like to keep my PRU firmware as simple as possible Jun 17 04:52:11 yep, very sensible Jun 17 04:53:23 your pruss class has like the entire PRU enabled underneath Jun 17 04:54:13 or in other words all the IO can be run through your pruss class Jun 17 04:54:29 and you can also use py-uio to prototype your pru1 code: it can read the decoder position from pruss memory and update the pwm output just like the pru1 core might Jun 17 04:54:32 except slower Jun 17 04:54:45 much easier than trying to set up a resource_table to configure interupts Jun 17 04:54:49 yep you can access all of pruss Jun 17 04:55:04 and set everything up the way you want before starting your pru cores Jun 17 04:55:14 pretty awesome Jun 17 04:55:25 much more approachable than anything else I have seen Jun 17 04:55:33 that was the objective Jun 17 04:55:49 well mission accomplished Jun 17 04:56:14 anyways I am hitting the sack I will continue on tomorrow. As always thanks for the help Jun 17 04:58:07 lorforlinux: did my custom dts work? Jun 17 04:59:08 sorry i was gone for some time, I will test it now Jun 17 05:06:15 zmatt finally, it worked. no gibberish from RX =D Jun 17 05:06:42 and pin is says it's unused now Jun 17 05:07:54 and be honest, it's much nicer to read than those fragment@N { __overlay__ { .. }; }; blocks ;-) Jun 17 05:08:34 yes i totally agree. Jun 17 05:09:32 I switched back to old DTS format when things were not working correctly, I will use the new format only now and find a way to make it work instead of going for old format! Jun 17 05:10:05 I'd just stick to using a custom dts for now rather than trying to use an overlay Jun 17 05:10:57 eventually it should be possible to build an overlay from it with some minor changes to the #includes and a suitable makefile that uses my perl script to preprocess it into overlay-syntax Jun 17 05:10:58 Actually It's not about one peripheral, I have to test all of them that's why i chose overlays. Jun 17 05:11:31 wait we can do that? Jun 17 05:11:55 I understand but it's easier to do that in one custom dts, especially since you need to ensure that every pin you use in a custom pinmux block is commented out in the cape_default_pins list Jun 17 05:12:14 I mean the make makefile that uses my perl script to preprocess it into overlay-syntax, how to do this? Jun 17 05:12:56 okay I will make sure that Jun 17 05:13:08 that's what my overlay-utils does: https://github.com/mvduin/overlay-utils .. it also uses custom headers for historical reasons, but there shouldn't be any obstacle to using the same perl script with the standard includes Jun 17 05:13:36 but for now I'd just avoid overlays on the bbai Jun 17 05:14:44 That's cool Jun 17 05:20:30 mru: apparently the VDD_3V3B supply had been shorted to GND Jun 17 05:21:23 not sure what gets toasted as a result of that, but clearly _something_ wasn't happy about it ;) Jun 17 05:44:09 zmatt i tried updating the overlay and it worked without any problem, https://pastebin.com/qcYEdhgq Jun 17 05:45:03 BTW rcn-ee already created BBAI overlays for LCD7 cape Jun 17 05:46:31 lorforlinux: it might work but it's a bad idea since you still need to keep cape_default_pins in sync Jun 17 05:46:49 having that in separate files just makes it harder to ensure cape_default_pins is right Jun 17 05:46:53 * set_ use Linux Jun 17 05:47:43 Sorry. Jun 17 05:48:15 lorforlinux: btw, you should not have lines that do not have any of PIN_INPUT / PIN_OUTPUT (with or without _PULLUP / _PULLDOWN) Jun 17 05:48:31 for unused pins use PIN_OUTPUT | MUX_MODE15 Jun 17 05:48:45 (note: "PIN_OUTPUT" is poorly named, it just means "not an input") Jun 17 05:49:07 if they are set to driver off Jun 17 05:49:12 and inputs should normally always have _PULLUP or _PULLDOWN to keep them from floating Jun 17 05:49:25 ohh what does that means then? Jun 17 05:50:53 like my example showed: https://pastebin.com/6WaQVKq7 PIN_INPUT_PULLUP | MUX_MODE4 for the rxd pin, PIN_OUTPUT | MUX_MODE15 for the unused shared pin Jun 17 05:51:46 omitting PIN_WHATEVER entirely is equivalent to PIN_OUTPUT_PULLDOWN Jun 17 05:52:31 which is probably not what you want, and when it is what you want you should specify it explicitly since it's not intuitive at all that that's what you get if you omit PIN_INPUT/PIN_OUTPUT Jun 17 05:53:13 what does what mean? pull-up/down? you're unfamiliar with those terms? Jun 17 05:53:38 I am familiar with them. Jun 17 05:53:41 ok Jun 17 05:54:02 * set_ I have sound on and it is odd! Jun 17 05:54:39 lorforlinux: there's also no harm in having _PULLUP or _PULLDOWN on outputs, although it's usually not necessary Jun 17 05:55:09 bbl! Jun 17 05:55:10 but it's better to enable internal pull-up or -down when not necessary then to disable it when it should have been enabled Jun 17 05:55:28 since floating inputs can be detrimental to the long-term health of the hardware Jun 17 05:55:40 okay I didn't see anyone using PULLUP/PULLDOWN with UART that's why i skipped that. Jun 17 05:56:33 that's a mistake then. while it shouldn't matter if there's something actually connected to it... but when experimenting that might not be the case, and then it's important to have internal pull Jun 17 05:56:36 zmatt when we use any overlay the existing muxmodes from base DTB are updated right? Jun 17 05:56:49 I have no idea what you mean by that Jun 17 05:57:44 an overlay is just a way of customizing the dtb, similar to adding some blocks to your custom dts (except with some deficiencies) Jun 17 05:58:43 It's adding to the DTB instead of updating modified parts from overlay? Jun 17 05:58:55 ?? Jun 17 05:59:39 okay got it just like custom dts Jun 17 05:59:58 an overlay .dtbo basically just contains instructions on how u-boot should patch the dtb before passing it to the kernel Jun 17 06:02:38 I was asking as we created same cape_pins_default node in our custom dts and base dts, the final DTB will only include one instance of the pinmux values and priority will be given to custom dts values right? Jun 17 06:04:51 a dts file contains a sequence of fragments that each add or modify nodes or properties of some existing node. the compiler will apply those fragments in order to create the final device tree structure that's serialized to a .dtb Jun 17 06:05:00 for general explanation of how a .dts works: https://pastebin.com/XC8vB33d Jun 17 06:05:26 Also, we don't have any PIN_OUTPUT / PIN_INPUT under cape_pins_default of am5729-beagleboneai.dts, what do you think about that? Jun 17 06:05:54 yes it's a complete mess Jun 17 06:06:17 that's something I already observed more than half a year ago, and jkridner went about fixing it, but somehow nothing happened Jun 17 06:06:41 (ditto for the u-boot defaults) Jun 17 06:06:50 anyway, I was still explaining Jun 17 06:07:32 your custom dts contains correct configs why don't you create a PR for that? Jun 17 06:07:36 yes continue please Jun 17 06:10:24 https://pastebin.com/DdZEL2u0 here's an annotated version of my dts example Jun 17 06:11:32 your device tree summary is very helpful thanks Jun 17 06:12:44 One thing i am not understanding is why we are keep record of cape_pins_default in both dts files? Jun 17 06:13:08 because am5729-beagleboneai.dts is not yours to touch Jun 17 06:14:17 I'm assuming am5729-beagleboneai.dts is left entirely original Jun 17 06:14:35 okay what happens if I don't keep the record in my custom dts? Jun 17 06:14:46 and your custom dts #includes it to have a basis (since most of it it right) and you override the things you want to modify Jun 17 06:14:52 yes, am5729-beagleboneai.dts is intact. Jun 17 06:15:35 so the purpose of cape_pins_default is to set a sane pinmux configuration for all unused pins Jun 17 06:15:51 to fix the insane defaults from u-boot Jun 17 06:16:33 but cape_pins_default can't contain any pin that you actually use, because then there's a pin conflict Jun 17 06:16:50 but i am changing fraction of pins, shouldn't other pins be with their original pinmux configuration from base dts? Jun 17 06:16:51 cape_pins_default is just a terrible hack and shouldn't exist Jun 17 06:17:19 I am tired of using it in each file. Jun 17 06:17:37 well 1. cape_pins_default in the base dts is also not great 2. there's no way to preserve parts of it, you can only override it entirely Jun 17 06:17:40 what do you mean "each file" ? Jun 17 06:17:52 you have more than one custom dts ? Jun 17 06:18:16 in that case, yes you need to have a separate one for each custom dts Jun 17 06:18:36 No i don't have them now but I had to create when I was fooling around. Jun 17 06:18:36 it sucks, it's awful, it shouldn't be this way, but right now it is Jun 17 06:19:53 once u-boot's pinmux defaults are fixed, cape_pins_default can die and buried in the desert, and we can try to forget it ever existed Jun 17 06:20:12 *and be buried Jun 17 06:21:19 and then we can also start considering to use overlays Jun 17 06:22:13 okay Jun 17 06:22:26 see this -> https://pastebin.com/aj1MShAn Jun 17 06:23:17 what's 160 ? Jun 17 06:23:23 that's not in my dts Jun 17 06:23:54 that `pin PIN203 already requested by 48066000.serial; cannot claim for cape_pins` message disappears when I include the cape_pins_default in my overlay. Jun 17 06:23:55 why are you messing with an overlay again? Jun 17 06:24:02 STOP USING OVERLAYS Jun 17 06:24:06 for fuck's sake Jun 17 06:25:01 and it means your cape_pins_default includes pin 203 (P9_11A) and therefore conflicts Jun 17 06:25:13 okay got it :') first the u-boot default setup then overlays Jun 17 06:26:10 that conflict is it's own, nothing is using that pin and It has already assigned that to serial and that's what I wanted. Jun 17 06:26:23 That message disappears when I include the cape_pins_default in my overlay. Jun 17 06:26:50 Got it no overlay chat now Jun 17 06:27:05 and what you're describing is exactly what is expected Jun 17 06:27:13 what part about it are you confused about? Jun 17 06:27:32 if you do not override cape_pins_default, _everything_ will conflict with it Jun 17 06:28:11 yes i learned it the hard way, by doing it over and over several times. Jun 17 06:29:53 ah and pin 160 is the non-existent "P9_13B" Jun 17 06:30:03 don't try to declare that, it will fail Jun 17 06:33:09 okay :) Jun 17 06:34:23 btw, since the BeagleBoard-DeviceTrees repository doesn't seem to have macros for bbai pins, here: https://pastebin.com/vwn4m7Nf Jun 17 06:35:05 you can save that as bbai-pins.h and #include that so you can use those Jun 17 06:37:46 there macros for BBAI here -> include/dt-bindings/pinctrl/dra.h Jun 17 06:38:28 I am able to use pins like as BBAI_P8_03 Jun 17 06:39:19 I also saw your definitions somewhere, don't remember where it was Jun 17 06:40:00 I see those in bb.org-overlays, not in BeagleBoard-DeviceTrees Jun 17 06:40:20 and since you're not making overlays anymore, the one ine bb.org-overlays isn't terribly helpful Jun 17 06:40:26 (it also reaaaaly doesn't belong in that header file) Jun 17 06:41:06 ohh okay, I will use yours then Jun 17 06:41:19 anyway, here's the updated example: https://pastebin.com/yUz0wE0w to use those definitions Jun 17 06:41:46 if you prefer the BBAI_ prefix I can add it if you want... I personally don't see the point, it seems like pointless verbosity Jun 17 06:46:33 no it's fine with me Jun 17 06:49:16 Thank you for the detailed example :) Jun 17 08:04:49 zmatt: I have a short memory and get distracted easily. Jun 17 08:05:11 zmatt: what does it mean to get the default pinmux in u-boot? Jun 17 08:05:30 jkridner[m]: https://github.com/jadonk/u-boot/commit/ce02a3e97aa071f46e4a5a956d595cd64c5ee1b5 Jun 17 08:05:37 I thought we already had AM5729 pinmuxing in u-boot. Jun 17 08:06:16 right now the pinmuxing in u-boot is nonsense... it looks like it's trying to use AM572x-EVM pinmux on the BBAI Jun 17 08:06:25 Is that not either upstream or in rcn-ee's items? or, is it just incomplete? Jun 17 08:06:40 no idea, it's your repo not mine Jun 17 08:07:29 been a bit. I'd have to go search. the idea we'd approached was making the default pinmux be much like what was needed for the robotics cape, as it had a lot of useful I/O on it. Jun 17 08:07:38 that sounds like a very bad idea Jun 17 08:07:43 so, it would give a mix of PWMs, EQEPs, etc. Jun 17 08:07:48 very very bad idea Jun 17 08:08:02 you want "neutral" defaults in u-boot Jun 17 08:08:22 since they'll applied to everyone until the kernel takes over Jun 17 08:08:45 so any pin configured as output (e.g. pwm) could result in hardware damage if someone is actually using that pin as input Jun 17 08:11:14 I'd stick to gpio mode or safe mode, with pull-up or pull-down (either in a direction that's compatible with the BBB or in whatever direction is the default for the am572x... arguments can be made for either option) Jun 17 08:11:34 I thought we avoided enabling any outputs to avoid potential cape damage. Jun 17 08:11:48 or board damage. Jun 17 08:12:25 not right now, nor with your idea of configuring pins as PWM by default (which immediately causes them to drive their pins) Jun 17 08:12:51 I'm fine if lorforlinux wants to provide some safer defaults. The work he's doing to provide snippets for enabling different peripherals will be very helpful in lieu of having 'config-pin' support. Jun 17 08:13:34 pretty sure I commented out settings of PWM. Jun 17 08:13:46 jkridner[m]: iirc we worked out sane defaults, that's exactly what that commit is I linked you Jun 17 08:13:50 that was your latest version iirc Jun 17 08:13:57 oh! Jun 17 08:13:58 but nothing was done with that Jun 17 08:14:10 that commit didn't go anywhere? Jun 17 08:14:11 rcn-ee said there will not be any support for config-pin on BBAI ever Jun 17 08:14:23 there's no reason for that Jun 17 08:14:42 since right now we're doing all pinmux in DT, which is just as bad as runtime config via config-pin Jun 17 08:15:25 jkridner[m]: I think the u-boot on the latest images actually predates that commit Jun 17 08:15:33 so I have no idea if that commit went anywhere Jun 17 08:15:49 guess not. :-( Jun 17 08:15:52 sorry I forgot about it. Jun 17 08:16:22 yeah, I recall working on this to make sure things were sane, but never closed the loop it seems. Jun 17 08:17:55 jkridner[m]: this should probably be fixed asap and new images built, since right now u-boot configures a ton of pins to be outputs by default (vout, uart txd, clkout, rgmii tx, and pwm) Jun 17 08:18:02 Yes i agree that the boot time stuff we are doing is just as bad as runtime config via config-pin and I saw no glitches. I was monitoring the UART output while booting the board. Jun 17 08:18:16 as bad as updating with dt in u-boot is, do you really thing it is that bad? Jun 17 08:18:30 "updating with dt in u-boot" ? Jun 17 08:18:43 u-boot does not set pinmux based on dt Jun 17 08:18:45 the kernel does Jun 17 08:18:45 agreed. Just sent rcn-ee a note to see if he can pull that commit. Jun 17 08:19:11 u-boot sets pinmux based on mux_data.h Jun 17 08:19:30 hmmm.... ok. I thought u-boot did both the table-based updates as well as did some pinmux updates based on dt, despite not loading drivers (obviously) Jun 17 08:19:35 and I don't know how bad it is, that's something you were trying to pry out of your colleagues at TI ;-) Jun 17 08:19:40 * jkridner[m] notes not having slept yet. Jun 17 08:19:48 * zmatt hasn't either Jun 17 08:19:58 me too Jun 17 08:20:12 indeed. never got that "[oh we've got an] app note for that" Jun 17 08:20:32 jkridner[m]: "safe" pinmux config (according to TI) can currently only be done during early SPL, at which point it hasn't loaded any DT yet Jun 17 08:21:28 I have an idea on how u-boot might be able to do safe pinmux based on DT (by reentering I/O isolation) but I haven't had time yet to explore whether this idea can really work Jun 17 08:23:03 right now the best we can do is make sure u-boot configures all non-expansion-header pins correctly, and configures expansion headers to something sane and safe (i.e. gpio) Jun 17 08:23:12 my intention wasn't to do it "safe" by TI's definition as I feel the requirement is bogus as no one can explain it to me. Jun 17 08:23:31 and then hope that any glitches from later reconfiguration is not a problem in practice Jun 17 08:23:36 Sure, there could be glitches on the pins in some corner conditions..... Jun 17 08:23:49 but, that's hardly "its not possible" Jun 17 08:24:30 and if we're okay with doing pin configuration after early u-boot SPL, then we may as well use bone-pinmux-helper and thereby allow config-pin to work Jun 17 08:25:43 (if we do, it would be nice if users don't need to know whether the mode they want is on "A" or "B" of a pin.. there's really no need for that I think. just throw all modes available on one pile for the user) Jun 17 08:29:08 sounds great to me! Jun 17 08:29:45 I'd also say that config-pin should print out something like show-pins if there is no arguments given. Jun 17 08:30:13 and that damn C version of config-pin needs to burn in hell. :-) I appreciate the start, but not ready for general usage. Jun 17 08:30:32 lol Jun 17 08:31:00 something that updated itself based on pinmux helper would be amazing. Jun 17 08:31:31 lorforlinux: what do you think about trying to tackle pinmux-helper and config-pin for BBAI? ;-) Jun 17 08:32:02 I think we turn it on. I sent another request for that app note to the person who said it existed. Jun 17 08:32:40 if nishanth ever shows up here, I'd suggest asking him as well. he claims to understand the issue. Jun 17 08:33:24 sure, I can try that but it will change the project timeline a bit. Jun 17 08:34:37 just do everything else faster so you have more time for fun. ;-) Jun 17 08:35:04 * jkridner[m] gets delirious without sleep. Jun 17 08:36:54 I will try my best =D Jun 17 08:41:56 an interesting question would be what names to give to modes... like, calling a mode "uart" like on a bbb is not going to be specific enough Jun 17 08:44:07 jkridner[m]: one caveat though: a DT-based approach may be able to become "safe" in the future if my idea works for having u-boot perform safe dt-based pinmuxing, while config-pin never wil Jun 17 08:44:11 l Jun 17 08:45:59 so it would be really helpful if we had the information needed to understand the severity/impact of the pinmux glitch problem before deciding whether to give config-pin to users Jun 17 08:46:17 or which modes to make available via config-pin Jun 17 08:50:26 why isn't just saying "uart" enough? that is what we do for bbb, isn't it? Jun 17 08:50:43 jkridner[m]: because one pin can have modes for multiple uarts Jun 17 08:51:56 but why would you need more than 1 uart option per pin? now, if it is for the cts/rts signals, then that probably needs a different name. Jun 17 08:52:36 but, if you are grabbing a pin for a uart, it shouldn't matter so much which uart you get. I don't think the point of config-pin is to be exhaustive. Jun 17 08:54:18 because you need multiple pins for an uart, and the other pin for one uart might be in a bad place for some people Jun 17 09:05:09 for reference, bbai uart modes: https://pastebin.com/raw/GGfYPYTj Jun 17 09:20:53 updated to improve readability, added overview matrix Jun 17 09:21:27 if you want to use a bunch of uarts but also need certain pins for certain other modes it can be an interesting jigsaw puzzle Jun 17 11:55:41 jkridner[m], 3am, I am usually asleep. I assume you are talking of am57x and iodelay and need to program it at boot? Jun 17 11:59:30 jkridner[m], i will need to dig up old presentations and details, but: a) the glitch on the IOs in am57x is pretty significant, b) there were assymettric aging issues (simplistically put: basically signal paths will age will age up in different rates and the data sheet values will no longer hold good) - so you will end up seeing functional failures on boards.. not at first, but eventually. Jun 17 12:00:39 if that helps.. i mean, no reason why a pinmux helper or userspace pinmux wont work.. just do it often enough and you'd probably have a dead board on your hands.. shrug.. Jun 17 12:04:34 NishanthM: thanks for responding. Understanding the underlying cause will help improve with accepting this "aging issues" argument. There must be a contention or something like that to impact the circuit life-span, so, can we do a safe transition by understanding the potential causes of whatever state generates the problem? Jun 17 12:06:14 jkridner[m], the mmc signal voltage contention was another issue, i think got resolved in the latest ES chip.. we can dig up the assymetric aging rationale.. Sorry, the discussions are many years old now, i really will need to stretch my search fu to find the details Jun 17 12:06:49 someone told me there was an app note, but I cannot find such a thing. Jun 17 12:07:20 jkridner[m], there should be. I think Steve or someone had written it.. we can find the details. Jun 17 12:08:14 * NishanthM hates iodelay.. comes back to haunt every year! Jun 17 12:10:22 NishanthM: I'm assuming the glitch is due to iodelay specifically, and the only reason changing padconf can cause the same thing is because the iodelay in non-manual mode depends on padconf (muxmode and virtual timing) ? Jun 17 12:13:26 zmatt, there were few things -> iodelay -> manual mode and viceversa, and even the iocells were changed (as i recollect, we used to have glitchless muxes before : eg, mode3 to mode2 with pull up switch would'nt create any noticable glitches even on chips that did'nt have glitchless mux - but now, it is detectable as i recollect). Jun 17 12:13:58 if that hypothesis is true then I wonder whether it might be an option to just set fixed manual iodelay for the pins that use runtime-pinmux, since the modes for which runtime pinmux is used are generally not very timing-sensitive (gpio, uart, i2c, that sort of stuff) Jun 17 12:14:06 thankfully that version of iocells stopped with am57x. Jun 17 12:14:16 began and stopped ;) Jun 17 12:14:57 I mean, the idea doesn't seem bad (albeit a bit heavy-handed maybe), but it seems the implementation is... not ideal Jun 17 12:15:13 zmatt, just do the right timing constraints on layout.. Jun 17 12:15:17 like everyone else does.. Jun 17 12:15:39 bah.. anyways.. jkridner[m] i started the thread for the app note.. Jun 17 12:16:04 in the SoC you mean? but with so many pins each having so many mux modes... I can imagine that it's no easy task Jun 17 12:16:05 once i get time later today, will search on my older pst to see if i have data (i think i still have psts upto 2013) Jun 17 12:16:38 zmatt, yes. this is not a new problem for us. we just decided that we are making chips where people wont need dynamic mux configuration.. Jun 17 12:17:24 might be accurate for specific narrow markets in a braindead inflexible s/w env.. but was (and we had pushed back) a bad choice.. Jun 17 12:18:15 zmatt, everytime i hear iodelay, i can taste bile in my mouth.. so lets say grinds a rather raw spot for me.. Jun 17 12:18:40 I think the 'we' is a specific team or set of team(s) in this case. Man, I seem to have the discussion about why dynamic pinmux/peripheral-config/etc. is needed just about every day. Jun 17 12:18:46 https://www.ti.com/lit/an/sprac44a/sprac44a.pdf Jun 17 12:19:16 hah.. they dont explain anything! Jun 17 12:19:42 ofcourse, the why is a TI internal problem, is'nt it :P Jun 17 12:19:50 I understand... but the problem is right now all we have is "you need to do all pinmux during i/o isolation" which is just incredibly impractical... but we have no mental model of what's going on exactly, which makes it very hard to figure out if there are certain things we can do safely, or what the implications are Jun 17 12:20:58 in reality, right now, _all_ expansion header pins on the bbai are being reconfigured outside I/O isolation on every boot Jun 17 12:22:53 nyways.. need to speak in the meeting. will look up details later, will send to your official emailID jkridner[m] ... you can pick and get permissions to make it public.. i cant directly put anything out there Jun 17 12:28:08 heh, I was wondering if the am572x internal pull-up was more narrowly defined than that of the am335x, but that's a big nope... min 10 μA typ 100 μA max 290 μA Jun 17 14:07:08 m Jun 17 14:27:48 m 2 u Jun 17 14:49:35 hello, I am trying to further undesrtand the software uart implementation on the beaglebone black pru and i want to ask that after generating the .out file from the CCS how can i upload the code to the card without a jtag emulator Jun 17 15:15:59 does the Beagle AI have a LCD cape Jun 17 15:16:02 yet Jun 17 15:16:14 or is it too new Jun 17 17:10:27 MattB0ne: it will work with 16-bit BeagleBone Black LCD capes---with some software updates (dt and u-boot). Jun 17 17:11:00 A couple have been made to work. Jun 17 17:13:32 zmatt: ugh. Why can't I get to TI.com materials? Can you see https://www.ti.com/lit/pdf/sprz429 ? Jun 17 17:14:02 yep, redirects to https://www.ti.com/lit/er/sprz429l/sprz429l.pdf Jun 17 17:14:06 jkridner[m]: wfm fwiw Jun 17 17:14:10 ^ that Jun 17 17:14:24 but I know those pages use javascript to redirect, for some reason Jun 17 17:14:37 I must have eaten some bad cookies. Jun 17 17:14:52 probably :P Jun 17 17:16:04 * jkridner[m] uploaded an image: image.png (1758KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ruRTwTjyqGkdmFItrNZBJRDy > Jun 17 17:16:29 I don't like to use this Windoze box for much of nothin', but I had to get on the VPN. Jun 17 17:16:53 does it work in an incognito window? Jun 17 17:19:51 it works now. Not sure what happened. Jun 17 17:19:58 cosmic rays Jun 17 17:20:55 The iodelay issues with simultaneous access doesn't look like any sort of problem in u-boot/earlyboot-in-kernel. Jun 17 17:21:02 unless SMP has cranked up somehow. Jun 17 17:21:26 no that's not an issue Jun 17 17:21:54 iirc it's even fairly unlikely at runtime, lemme check the conditions again Jun 17 17:23:21 since it requires simultaneous access by another initiator to another target on the L4_PER2 Jun 17 17:24:25 and I'm pretty sure that initiator also has to use a different initiator port of that interconnect, since each initiator port cannot perform more than one access at the same time (that's the whole reason for having multiple of them) Jun 17 17:31:20 so that's dma access (sdma or one of the edma instances) to one of: uart7-9, mcasp4-8, or dcan2 Jun 17 17:33:42 if my reasoning is right, accessing the iodelay module is only hazardous (in the sense of risking system lockup) if any of those peripherals have dma enabled Jun 17 17:33:52 (and are in use) Jun 17 18:11:48 hello everyone Jun 17 18:12:21 I have problem with ethernet bandwidth on beagleboard Jun 17 18:12:29 could anyone help me Jun 17 18:12:52 which board? Jun 17 18:13:23 i am using beaglebone green Jun 17 18:13:33 with usb ethernet adapter Jun 17 18:14:09 I read another test that it can reach nearly 100Mbps Jun 17 18:14:54 but on my board i can forward between to ethernet about 20Mbps Jun 17 18:15:28 i can forward packet between 2 eth0 and usb2 about 20Mbps Jun 17 18:15:58 check the interfaces separately and see which one is slowing it down Jun 17 18:17:40 what size packets? Jun 17 18:17:43 64byte? Jun 17 18:19:12 how i can check this, i just follow port_forwarding guide to configuration it Jun 17 18:20:18 each interface work well and support 1000 Jun 17 18:20:28 it will forward whatever packets come in Jun 17 18:20:50 the sender decides the size Jun 17 18:21:39 yes, and i test bandwidth with iperf Jun 17 18:22:52 MTU in each port is 1500 Jun 17 18:23:08 probably just usb being slow Jun 17 18:23:13 on the bbb Jun 17 18:23:23 it's what usb does best Jun 17 18:23:36 well especially on the bbb, mostly because the driver sucks Jun 17 18:23:41 and dma is disabled Jun 17 18:23:46 musb? Jun 17 18:24:08 yeah, with extra suck in the ti-specific part Jun 17 18:24:23 musb takes everything bad about usb and amplifies it hundredfold Jun 17 18:30:10 so do you mean that i should check usb dma Jun 17 18:31:28 what are you trying to achieve anyhow? are you trying to use the bbb as network router or something? because I have a feeling there are probably cheaper devices that would do a much better job Jun 17 18:32:36 or, you can try to fix the usb driver and make it perform well, if you're well-versed in kernel programming and sufficiently determined. I'm sure a lot of people would appreciate it Jun 17 18:36:28 i would like to make router with it Jun 17 20:17:38 question on memory registers. I am reading the TRM and it talks about how the PRUS can both quickly access each others local memory. So PRU0 has its local registers starting at 0x0000_0000 and can see PRU1 stuff starting at 0x0000_2000. The manual says the same thing goes for PRU1 with the same registers. So how is it distinguished. Somehow it is flipped? Jun 17 20:29:31 MattB0ne: there are two memory blocks, ram0 and ram1 Jun 17 20:29:50 pru0 sees ram0 at address 0x0000 and ram1 at 0x2000 Jun 17 20:30:08 pru1 sees ram1 at 0x0000 and ram0 at 0x2000 Jun 17 20:30:50 ok I guess my confusion arrises when I want to specify a register I need a location and an offset Jun 17 20:30:56 zmatt: you mean, like, the cppi dma they put in in the omap3 instead of using the musb's own dma engine? I vaguely seem to remember something Jun 17 20:31:10 but it seems I would need to know this generic location like ram0, the location and offset Jun 17 20:31:41 so I always need to 3 pieces of info to specify a register in the system is that fair ? Jun 17 20:31:53 from the point of view of each pru, "local" ram is at 0x0000 and "other" ram is at 0x2000 Jun 17 20:31:54 so like for shared i would have sram Jun 17 20:32:13 ok so perspective matters Jun 17 20:32:17 there's a shared block at 0x10000 Jun 17 20:32:38 so my firmware would know its pru0 and therefore would know to use ram0 etc... Jun 17 20:33:00 no need Jun 17 20:33:19 because the firmware is on pru0 Jun 17 20:33:35 that is all it needs to know for my local i go to ram0 and stuff Jun 17 20:33:37 then accesses to 0x0000-0x1fff will go to ram0 Jun 17 20:33:48 ok I that makes sense Jun 17 20:33:59 low = local, high = remote Jun 17 20:34:04 wherever you happen to be Jun 17 20:35:08 and when coding I can just say go to ram0 and it will handle the rest or do I have to be putting 0x0000 and managing the offset as i put stuff in or take stuff out Jun 17 20:35:24 of local Jun 17 20:35:50 are you communicating between pru cores? Jun 17 20:35:50 how much will the PRU manage the registers Jun 17 20:36:09 or do I need to keep track of all of the 8kb Jun 17 20:36:33 and what I have hanging out there during execution. Jun 17 20:37:02 I don't understand the question Jun 17 20:37:25 say I have a loop and I want to track how many times it iterates Jun 17 20:37:32 and I throw it in local Jun 17 20:37:35 Just use each PRU like it's independent. Local ram will always be in the same place. The "other" PRU RAM will always bein the same place. Shared will always be in the same place. Jun 17 20:37:37 use a register, not memory for that Jun 17 20:38:34 bad example. Say I dump a lot of text or something in local. Jun 17 20:38:56 are the PRUs smart enough to figure out how it would fit Jun 17 20:39:13 do you need to communicate between the cores? Jun 17 20:39:26 No. It doesn't know how big its RAM is. Jun 17 20:39:29 I will eventually but I am just asking these for basic understanding Jun 17 20:39:48 the pru core knows nothing of what is connected to it Jun 17 20:40:20 the PRU core can be treated as another processor on the same die Jun 17 20:40:23 so If i were storing data. and assigning it to local it does not check for how filled where it fits or where it goes. So I have to say go to local and give it an offset Jun 17 20:40:26 and remember all that Jun 17 20:40:49 I use shared as a ring buffer for logging, and I had to code limits to prevent wandering all over memory and killing kittens. Jun 17 20:40:49 there is no check, you need to figure out in the code Jun 17 20:40:56 the linker can do that kind of check Jun 17 20:41:07 if you have a linker Jun 17 20:41:08 all the sizes are documented Jun 17 20:42:02 but I need to specify where in memory it is via the offset. So rather than variable names the offset is really my tracker is that fair? Jun 17 20:42:26 Variables work normally. They're just offsets with a name. Jun 17 20:42:30 variable names are offsets Jun 17 20:43:05 but who specifies the offset me or the program or either? Jun 17 20:43:12 C does. Jun 17 20:43:22 who ever is programming decides all that just like any other chip Jun 17 20:43:33 Unless you're using asm. Then it would be whatever one would normaly do for that. Jun 17 20:43:53 ok so I am responsible Jun 17 20:44:00 I did mine in C. Was vastly simpler. Jun 17 20:44:29 even in C you have to provide link maps Jun 17 20:44:35 yeah i dont know C that well and there is a lot going on the whole 'volatile' thing scares me Jun 17 20:44:56 assembly seems short to the point though the code is still crpytic to me Jun 17 20:45:11 I didn't do anything special. Once I had the environment set up I just clicked the button and loaded the .bin. Done. Jun 17 20:45:23 most uses of volatile are wrong Jun 17 20:46:15 half the time it works only because it scares the compiler into disabling way more optimisations that it would actually have to Jun 17 20:46:21 lol Jun 17 20:46:44 * Ragnorok has the compiler shaking before it boots Jun 17 20:47:37 typical "embedded" compilers are stupid beyond belief Jun 17 20:47:52 locating things in the shared memory would surely be an appropriate use of volatile ;) Jun 17 20:47:54 the same code compiled on a halfway decent compiler often breaks in myriad ways **** ENDING LOGGING AT Thu Jun 18 02:59:57 2020