**** BEGIN LOGGING AT Sun Oct 23 02:59:56 2022 Oct 23 04:08:12 GenTooMan: The quadruped is working...well. One leg it working so far! Movin' slow mo' again! Oct 23 04:08:23 testing, testing! Oct 23 04:18:57 don't become testy about it.. and sleep calleth unto sleep. Oct 23 04:41:50 leap to sleep! Oct 23 10:36:05 GenTooMan: I am up! Oct 23 12:20:06 My set up config. of the hardware was at fault. The ServoCape works like a charm! Oct 23 12:20:26 I know, I know. You all knew but I had to test it! Oct 23 13:20:38 Well, the Cape luckily did not break the BBB. I altered some ideas w/ this Cape and it shut the BBB down for good. Luckily, it rebooted once I applied power again and again and again. Lucky mornings! Oct 23 14:05:53 hi Oct 23 14:06:24 i am not getting any message after starting kernel in tftpboot in BBB revc Oct 23 14:06:45 can someone help me Oct 23 14:06:50 i have all the data ready.. Oct 23 14:08:38 I have booted from emmc , and stoped at uboot Oct 23 14:08:58 then i did  "setenv serverip 192.168.7.2" Oct 23 14:09:28 then i did "setenv ipaddr 192.168.7.2" Oct 23 14:09:36 7.1 in the server ip Oct 23 14:10:02 then i did "tftpboot 0x8200000 uImage" Oct 23 14:10:17 "tftpboot 0x88000000 dtbname" Oct 23 14:10:34 "tftpboot 0x88080000 initramfs" Oct 23 14:11:36 then "setenv bootargs console=ttyO0,15200 root=/dev/ram0 rw initrd=0x88080000" Oct 23 14:11:52 this is all on the clinet/hardware side Oct 23 14:12:07 now...on the pc side , i checked all the necessary deamon running Oct 23 14:12:18 and did all the settings Oct 23 14:12:39 then sudo ifconfig enp150 192.168.7/1 Oct 23 14:12:51 and if i ping to this ip from hardware it is pinging Oct 23 15:00:06 "ttyO0,15200" ... that baudrate is wrong Oct 23 15:01:43 you probably meant ttyO0,115200n8 Oct 23 15:02:19 (technically it should probably also be ttyS0 instead of ttyO0, but ttyO0 will also work thanks to backwards compatibility in the kernel) Oct 23 19:32:20 Good evening Oct 23 21:51:36 hello everybody. I would like to change (experiment) some default pin config on my BBB by modifying the device tree overlay which is loaded at boot. I don't understand which is the default device tree overlay: i tried modifying (and re-compiling with dtb-rebuilder) the am335x-bone.commons.dtsi (since imported by am335x-boneblack.dts), than I copied Oct 23 21:51:37 the newly compiled file to the /boot/dtbs/4.19.94-ti-r42, overwriting the existing one. However, changes had no effect. Can you help me? Oct 23 21:52:27 murphized: generally you'd use an dt overlay rather than the base dts Oct 23 21:52:37 *rather than modifying the base dts Oct 23 21:53:15 of course for experimentation it's easier to use config-pin instead Oct 23 21:53:25 (runtime pinmux config) Oct 23 21:54:55 u-boot chooses which base dts to load and which overlays to apply based on hardware detection (of the board and any attached capes) and settings in /boot/uEnv.txt Oct 23 21:55:05 zmatt: yeah I already experimented with that tool. however, now I would like to experiment how to change default pin behavior at boot time. Is your suggestion to create a new customized dtb? Oct 23 21:55:16 am335x-boneblack.dtb is only used when u-boot overlays are entirely disabled Oct 23 21:55:20 no I would suggest using overlays Oct 23 21:55:49 my overlay-utils project has a bunch of examples: https://github.com/mvduin/overlay-utils Oct 23 21:55:52 zmatt: actually i did no changes to uEnv.txt Oct 23 21:57:29 you can configure up to 5 custom overlays in /boot/uEnv.txt using the uboot_overlay_addr4..7 variables and the dtb_overlay variable ... though you don't really need to configure more than one anyway since you can just use a single overlay to perform all your customizations Oct 23 21:58:11 this is my uEnv.txt: https://pastebin.com/7D3Mq6bf Oct 23 21:58:31 (note; for historical reasons overlay-utils uses different pinmux macros than mainline linux... mine are more concise and readable though ;) Oct 23 21:59:32 concretely, what are you trying to configure? Oct 23 21:59:57 zmatt: what does it mean "uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo" ?? an overlay other than the default one is going to be loaded? Oct 23 22:00:34 that selects the overlay used for PRU, you can use that to switch between uio-pruss and remoteproc-pru Oct 23 22:00:41 not sure that you meanb y "the default one" Oct 23 22:01:03 note that an "overlay" is effectively a patch applied onto a device tree Oct 23 22:01:28 (applied by u-boot to the base device tree before passing the final DT to the kernel) Oct 23 22:01:32 zmatt: concretely I want to change the pinmux mode of a set of pins. Oct 23 22:01:39 that's not concrete Oct 23 22:02:01 ok, let me be more concrete: Oct 23 22:02:08 normally pinmux is attached to the device/peripheral that uses the pins, which is why I asked so I can point to an example Oct 23 22:04:15 zmatt: https://pastebin.com/y61Y7eyC this is what I modified Oct 23 22:05:46 that's not how you do that Oct 23 22:06:16 if you want to disable the eMMC and reuse those pins for gpio, uncomment the disable_uboot_overlay_emmc=1 line in /boot/uEnv.txt (and obviously you'll have to boot from SD card instead of eMMC) Oct 23 22:07:32 zmatt: yes I want to boot from sd. however, uncommenting that line is someway like a "black-box"... I would like to experiment by programming pins by myself Oct 23 22:07:35 note: even if eMMC is disabled, you should avoid using both the eMMC clk and cmd pins (P8.20-21) for other purposes Oct 23 22:08:05 since the eMMC itself can't actually be disabled, hence if you toggle both of those I/Os it'll try to interpret this as commands Oct 23 22:08:28 (it's okay to use only one of the pins, I suggest leading the clk pin (P8.21) unused) Oct 23 22:08:32 *leaving Oct 23 22:09:12 murphized: it's not a matter of "programming pins", what's happening by uncommenting that line is that u-boot will refrain from applying the overlay that patches the declarations for the eMMC into the base device tree Oct 23 22:09:59 and it will instead declare pinmux helper devices for those pins to allow them to be configured at runtime using config-pin Oct 23 22:10:20 and it will export the gpios Oct 23 22:11:04 you mean I can effectively disable "data" pins for emmc but clk and cmd are still physically connected to the emmc even if a different mode is selected by mux? Oct 23 22:11:09 if you were to just do the equivalent of what you showed in your pastebin, what would happen is that the kernel would still try to communicate with the eMMC but the communication would fail and it would get confused Oct 23 22:12:07 all ten pins are physically connected to the eMMC... but as long as you don't accidently send it a command it won't care about what's going on with the data lines Oct 23 22:14:30 https://photos.app.goo.gl/a9JYULdYmwgu3Qk89 (this is just showing the first few pins obviously) Oct 23 22:16:34 zmatt: ok, so how the mux operates? Is it "internal" (i mean inside the soc - as a programmable register ) or "external" (i mean a physical device that operates on pin connections to the various peripherals? Oct 23 22:16:53 murphized: inside the SoC yes Oct 23 22:18:24 are all peripherals handled as the picture you sent, or this happens only for eMMC? Oct 23 22:18:49 when I'm talking about "peripherals" I'm generally talking about various functions inside the SoC Oct 23 22:18:53 the eMMC is an external chip Oct 23 22:19:31 ok, I mean external chips such as prus, spi, hdmi, ... Oct 23 22:19:52 PRU is not an external chip Oct 23 22:20:48 neither are the SPI controllers, and the BBB has no external SPI-connected chips Oct 23 22:21:48 the HDMI transmitter *is* an external chip, which connects to the display controller (lcdc) and an audio peripheral (mcasp0) inside the SoC via a bunch of pins Oct 23 22:23:24 specifically P8.27-46 are used to transfer video to the hdmi transmitter (unless video is disabled in /boot/uEnv.txt) Oct 23 22:23:36 zmatt: ok, I understand... I'm realizing to be a little confused. So, HDMI is surely an external chip, is it connected to the SoC in a similar way as shown into the picture? Oct 23 22:23:43 yes Oct 23 22:25:20 so can we say the pinmux never "cuts" pin connections from the devices that can be associated to those pins? pins are always connected to the devices. Oct 23 22:25:23 additionally P9.25, P9.28, P9.29, and P9.31 are used to transfer audio to the hdmi controller unless audio or video is disabled in /boot/uEnv.txt (disabling video disables hdmi entirely, both audio and video) Oct 23 22:25:57 yes since pinmux is internal to the SoC hence obviously can't influence the connection of chips external to the SoC Oct 23 22:26:24 i mean: the pinmux always operates after device phisical connections to the soc. Oct 23 22:26:26 ok Oct 23 22:27:40 for a summary of pinmux options and other considerations of the bbb's expansion header pins, see the P9 and P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126 Oct 23 22:29:33 that appears quite strange for me (few experience about embedded devices): that means some signal can influence all the devices externally connected with the SoC, even if the system has been programmed to not use a certain device (i mean some pin-conflicts situations) ? Oct 23 22:30:44 murphized: I mean, normally you'd obviously prefer to not have pins double-booked in this way, but this is done for the hdmi and eMMC pins on the BBB for reasons of flexibility and backwards compatibility: Oct 23 22:31:27 zmatt: ok I understand. Oct 23 22:31:28 the original beaglebone white had neither eMMC nor HDMI, so all of these pins are just connected directly to the AM335x and freely available for the user Oct 23 22:32:49 when the beaglebone black added eMMC and hdmi, they designed it such that they could still be disabled to free up these pins for other use, making it backwards compatibility Oct 23 22:33:41 (disabling the eMMC doesn't quite work anymore, that only worked on the original Micron eMMC, but you can still safely reuse the pins normally used for eMMC as long as you leave the clk pin alone) Oct 23 22:34:36 and the alternative would have been to have a bunch of expansion header pins not connected to anything anymore, since the BBB already uses nearly all pins of the AM335x Oct 23 22:34:39 so going back to the initial "question": suppose I want to disable emmc to use gpios. I can uncomment the specific line and then I should program my pins at runtime. uncommenting that line from uEnv.txt, acts as "disabling" some includes to the device tree. Correct? Oct 23 22:35:48 yeah Oct 23 22:36:29 I mean, you only need to configure pinmux at runtime if you want to use the pins for a function other than gpio of course, since gpio will be the default Oct 23 22:41:08 ok, so suppose now i want to override that default (I mean disabling some includes means not programming these pins and keeping the default config). What should I do? For example, I could  want to configure some of these pins with mode 3, some with mode 4, i mean, not MODE2 nor MODE7.  I also want that setup will be kept at reboot (no need to Oct 23 22:41:09 program pins at runtime). Can I edit/add some dts and override that default? Oct 23 22:43:22 you'd use an overlay that enables/configures (as needed) the peripheral that needs those pins and attaches a pinmux node to it that configures those pins Oct 23 22:43:59 (and disables "cape-universal" for those pins, which is the name of the (somewhat kludgy) mechanism that allows for runtime pinmux changes using config-pin) Oct 23 22:44:36 the eMMC pins however has almost nothing useful on their alternative modes Oct 23 22:44:51 other than gpio Oct 23 22:47:29 like I said a while back, my overlay-utils ( https://github.com/mvduin/overlay-utils ) has a bunch of examples Oct 23 22:48:41 ok, I understand maybe I choosed a "not quite interesting" use-case to experiment... however... are the steps: (1) uncomment "emmc_disable" line (2) uncomment "universal_cape_disable" line, (3) write a "customized" overlay (4) add it to the uEnv.txt file. Is it correcto? Oct 23 22:50:31 disabling cape-universal is not strictly required, my overlay-utils has a macro USES_PIN that disables cape-universal for specific pins, which means you can use these overlays for some things but maintain the ability to use config-pin on the remaining pins Oct 23 22:50:55 see e.g. https://github.com/mvduin/overlay-utils/blob/master/uart1.dtsi#L3-L5 Oct 23 22:50:56 i see Oct 23 22:51:48 this uart is pretty much a minimal example: the uart requires no configuration other than enabling ti (status = "okay";) and attaching a pinmux node to it for its two pins Oct 23 22:53:02 but some other devices are more complicated, e.g. some may require additional configuration for the device driver: https://github.com/mvduin/overlay-utils/blob/master/eqep2.dtsi#L18-L27 Oct 23 22:53:03 I understand. than what to do with that dtsi? Oct 23 22:53:23 overlay-utils has a Makefile that will compile these .dtsi files into .dtbo files Oct 23 22:53:33 just "make uart1.dtbo" Oct 23 22:53:41 or plain "make" to build all of the examples Oct 23 22:54:02 ok than finally have I to add a line into the uEnv.txt file to load that overlay? Oct 23 22:54:57 yeah, e.g. uboot_overlay_addr4=/home/debian/overlay-utils/uart1.dtbo Oct 23 22:55:55 ok I understand... going to try! Oct 23 22:56:48 good luck... device tree definitely has a bit of a learning curve, though my goal with overlay-utils and its macros and examples is to make the process at least slightly easier Oct 23 22:57:13 I also have some notes about device tree syntax, in case it's of any use: https://pastebin.com/XC8vB33d Oct 23 22:57:44 thank you very much! Oct 23 23:00:28 note also that the nice thing about the way overlay-utils works is that you can combine multiple overlays into a single overlay simply using #include, e.g.: https://github.com/mvduin/overlay-utils/blob/master/am57xx/uio-pruss-4.14.dtsi#L6-L7 Oct 23 23:00:55 zmatt: I just got confused again: suppose I boot with default config (from emmc) and then I (runtime) configure the eMMC pins to be GPIOs, what should happen? Oct 23 23:02:36 that would be quite complicated Oct 23 23:04:41 actually I just checked u-boot's logic, it looks like the eMMC overlay is applied *after* custom overlays are applied, so you can't really do that even Oct 23 23:07:35 ok, that means if I boot from emmc, than I cannot change the way that group of pins is programmed, correct? where did you check the u-boot's logic? Oct 23 23:08:15 if you boot from eMMC you must avoid touching those pins in any way whatsoever or you'll mess up the communication between the SoC and the eMMC Oct 23 23:08:37 (just to better understand how it works under the hood)ù Oct 23 23:09:35 recently there was someone here who had a custom cape attached to the BBB where they unfortunately had connected those P8 pins to an FPGA for flexibility, and even though the pins were not actually driven by the FPGA, the mere connection degraded the eMMC communications to the point of sporadically causing filesystem corruption Oct 23 23:13:49 uhm... this gets me a little confused again... suppose I don't want to use the eMMC, but i only want to use the P8 pins as GPIO to be connected to a custom cape. that means I probably will be never able to use the same device for another project, since the eMMC has been damaged? Oct 23 23:14:14 (another project with requires the eMMC) Oct 23 23:14:14 no Oct 23 23:14:28 nothing got damaged Oct 23 23:15:25 you mean that the filesystem corruption can be recovered by re-flashing the eMMC? Oct 23 23:15:48 but merely attaching wires or pcb traces to the pins used by eMMC while eMMC is actively used will cause signal reflects that can cause communication failures between the processor and the am335x, potentially resulting in data corruption Oct 23 23:16:24 ok I understand Oct 23 23:16:26 of course there's normally no reason to attach a wire to these pins unless you have eMMC disabled Oct 23 23:16:33 and yes you can fix that by reflashing anyway Oct 23 23:18:20 also, as for "where did you check the u-boot's logic", here's the default config of the beagleboard.org u-boot for am335x, reformatted to look more like a shell script for readability: https://pastebin.com/Kt1rUe5V (loading overlays starts at line 472) Oct 23 23:19:00 that's probably due to the "internal" mux, that is the wire is still connected to other wires (gpio) instead of being phisically detached... Oct 23 23:19:09 ehhh Oct 23 23:19:19 no you're confused Oct 23 23:24:51 oh god:)    what's wrong now? I mean the aforesaid "someone" could have connected P8 pins to another device because he believed the mux was external (while it's not) Oct 23 23:25:49 no they presumably just didn't think about the signal integrity implications of hooking the FPGA up to everything, including the eMMC pins Oct 23 23:25:50 if this does not make sense... I am definitely confused :) Oct 23 23:26:23 ah ok Oct 23 23:29:30 https://photos.app.goo.gl/HTNYW6UkjqNWLvnKA that "stub" that sticks out of the signal path between SoC and eMMC will cause signal degradation if it's too long. it's kept short enough on the BBB itself to not cause any issues, but if you attach a pcb trace or wire to it, that will likely cause problems Oct 23 23:30:44 (and attaching it to e.g. an FPGA will further increase the probability of signal degradation, even if the FPGA is configured to avoid touching that pin) Oct 23 23:31:27 ok Oct 23 23:39:08 looking at the u-boot source, sometime it's mentioned a strange "uboot_base_dtb" variable. that means u-boot sets "its own" default if overlay are disabled? Oct 23 23:39:38 regardless of whether overlays are used or not it needs a base dtb to which these overlays are applied Oct 23 23:40:02 though if overlays are enabled it will use a more stripped-down base dtb since optional features are then added using overlays Oct 23 23:41:56 ah, perhaps if one disables overlays, then u-boot loads the device tree from the file I modified before (am335x_boneblack.dtd) Oct 23 23:42:25 it does yeah, that's basically a legacy fallback mode Oct 23 23:47:15 ok thank you very much! I'll try to understand a bit more in depth the u-boot process in the next few days, before experimenting again. bye and thank you again! Oct 24 01:29:50 GenTooMan: I finally got it. The rush and influx of the stall current was creating the BBB to die out and turn off. Oct 24 01:30:00 I got lucky! Oct 24 01:30:33 I remember reading about it years ago. Now, I know what happens when it takes place. Bad stuff! Oct 24 01:37:12 if anyone asks about stall current on the ServoCape, there is my evidence. bbb == kaput Oct 24 01:38:51 It can take it, the BBB that is, for about three seconds on a server while the electricity thrives in a misunderstood way. Oct 24 02:56:43 I am high maintenance, bro... Oct 24 02:56:53 Ha. **** ENDING LOGGING AT Mon Oct 24 02:59:56 2022