brook has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
brook has joined #beagle
CygniX has left #beagle [Konversation terminated!]
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 255 seconds]
CygniX has joined #beagle
<set_>
GenTooMan: The quadruped is working...well. One leg it working so far! Movin' slow mo' again!
<set_>
testing, testing!
<GenTooMan>
don't become testy about it.. and sleep calleth unto sleep.
<set_>
leap to sleep!
buzzmarshall has quit [Quit: Konversation terminated!]
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
lucascastro has joined #beagle
<set_>
GenTooMan: I am up!
<set_>
My set up config. of the hardware was at fault. The ServoCape works like a charm!
<set_>
I know, I know. You all knew but I had to test it!
johanhenselmans has quit [Ping timeout: 260 seconds]
<set_>
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!
Guest91 has joined #beagle
<Guest91>
hi
<Guest91>
i am not getting any message after starting kernel in tftpboot in BBB revc
<Guest91>
can someone help me
<Guest91>
i have all the data ready..
xet7 has joined #beagle
<Guest91>
I have booted from emmc , and stoped at uboot
<Guest91>
then i did "setenv serverip 192.168.7.2"
<Guest91>
then i did "setenv ipaddr 192.168.7.2"
<Guest91>
7.1 in the server ip
<Guest91>
then i did "tftpboot 0x8200000 uImage"
<Guest91>
"tftpboot 0x88000000 dtbname"
<Guest91>
"tftpboot 0x88080000 initramfs"
<Guest91>
then "setenv bootargs console=ttyO0,15200 root=/dev/ram0 rw initrd=0x88080000"
<Guest91>
this is all on the clinet/hardware side
<Guest91>
now...on the pc side , i checked all the necessary deamon running
<Guest91>
and did all the settings
<Guest91>
then sudo ifconfig enp150 192.168.7/1
<Guest91>
and if i ping to this ip from hardware it is pinging
lucascastro has quit [Quit: Leaving]
johanhenselmans has joined #beagle
<zmatt>
"ttyO0,15200" ... that baudrate is wrong
johanhenselmans has quit [Quit: johanhenselmans]
<zmatt>
you probably meant ttyO0,115200n8
<zmatt>
(technically it should probably also be ttyS0 instead of ttyO0, but ttyO0 will also work thanks to backwards compatibility in the kernel)
Guest91 has quit [Ping timeout: 244 seconds]
johanhenselmans has joined #beagle
johanhenselmans has quit [Quit: johanhenselmans]
johanhenselmans has joined #beagle
lucascastro has joined #beagle
lucascastro has quit [Quit: Leaving]
GenTooMan has quit [Ping timeout: 272 seconds]
buzzmarshall has joined #beagle
GenTooMan has joined #beagle
GenTooMan has quit [Ping timeout: 272 seconds]
CrazyEddy has quit [Ping timeout: 264 seconds]
GenTooMan has joined #beagle
GenTooMan has quit [Ping timeout: 260 seconds]
vagrantc has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
<jfsimon1981>
Good evening
brook has quit [Remote host closed the connection]
brook has joined #beagle
alfatau has joined #beagle
alfatau has left #beagle [#beagle]
murphized has joined #beagle
<murphized>
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
<murphized>
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?
<zmatt>
murphized: generally you'd use an dt overlay rather than the base dts
<zmatt>
*rather than modifying the base dts
<zmatt>
of course for experimentation it's easier to use config-pin instead
<zmatt>
(runtime pinmux config)
<zmatt>
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
<murphized>
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?
<zmatt>
am335x-boneblack.dtb is only used when u-boot overlays are entirely disabled
<murphized>
zmatt: actually i did no changes to uEnv.txt
<zmatt>
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
<zmatt>
(note; for historical reasons overlay-utils uses different pinmux macros than mainline linux... mine are more concise and readable though ;)
<zmatt>
concretely, what are you trying to configure?
<murphized>
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?
<zmatt>
that selects the overlay used for PRU, you can use that to switch between uio-pruss and remoteproc-pru
<zmatt>
not sure that you meanb y "the default one"
<zmatt>
note that an "overlay" is effectively a patch applied onto a device tree
<zmatt>
(applied by u-boot to the base device tree before passing the final DT to the kernel)
<murphized>
zmatt: concretely I want to change the pinmux mode of a set of pins.
<zmatt>
that's not concrete
<murphized>
ok, let me be more concrete:
<zmatt>
normally pinmux is attached to the device/peripheral that uses the pins, which is why I asked so I can point to an example
<zmatt>
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)
<murphized>
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
<zmatt>
note: even if eMMC is disabled, you should avoid using both the eMMC clk and cmd pins (P8.20-21) for other purposes
<zmatt>
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
<zmatt>
(it's okay to use only one of the pins, I suggest leading the clk pin (P8.21) unused)
<zmatt>
*leaving
<zmatt>
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
<zmatt>
and it will instead declare pinmux helper devices for those pins to allow them to be configured at runtime using config-pin
<zmatt>
and it will export the gpios
<murphized>
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?
<zmatt>
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
<zmatt>
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
<murphized>
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?
<zmatt>
murphized: inside the SoC yes
<murphized>
are all peripherals handled as the picture you sent, or this happens only for eMMC?
<zmatt>
when I'm talking about "peripherals" I'm generally talking about various functions inside the SoC
<zmatt>
the eMMC is an external chip
<murphized>
ok, I mean external chips such as prus, spi, hdmi, ...
<zmatt>
PRU is not an external chip
<zmatt>
neither are the SPI controllers, and the BBB has no external SPI-connected chips
<zmatt>
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
<zmatt>
specifically P8.27-46 are used to transfer video to the hdmi transmitter (unless video is disabled in /boot/uEnv.txt)
<murphized>
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?
<zmatt>
yes
GenTooMan has joined #beagle
<murphized>
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.
<zmatt>
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)
<zmatt>
yes since pinmux is internal to the SoC hence obviously can't influence the connection of chips external to the SoC
<murphized>
i mean: the pinmux always operates after device phisical connections to the soc.
<murphized>
ok
<zmatt>
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
<murphized>
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) ?
<zmatt>
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:
<murphized>
zmatt: ok I understand.
<zmatt>
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
otisolsen70 has quit [Quit: Leaving]
<zmatt>
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
<zmatt>
(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)
<zmatt>
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
<murphized>
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?
<zmatt>
yeah
<zmatt>
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
<murphized>
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
<murphized>
program pins at runtime). Can I edit/add some dts and override that default?
<zmatt>
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
<zmatt>
(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)
<zmatt>
the eMMC pins however has almost nothing useful on their alternative modes
<murphized>
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?
<zmatt>
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
<zmatt>
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
<murphized>
I understand. than what to do with that dtsi?
<zmatt>
overlay-utils has a Makefile that will compile these .dtsi files into .dtbo files
<zmatt>
just "make uart1.dtbo"
<zmatt>
or plain "make" to build all of the examples
<murphized>
ok than finally have I to add a line into the uEnv.txt file to load that overlay?
<zmatt>
yeah, e.g. uboot_overlay_addr4=/home/debian/overlay-utils/uart1.dtbo
<murphized>
ok I understand... going to try!
<zmatt>
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
<murphized>
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?
<zmatt>
that would be quite complicated
<zmatt>
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
<murphized>
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?
<zmatt>
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
<murphized>
(just to better understand how it works under the hood)ù
<zmatt>
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
<murphized>
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?
<murphized>
(another project with requires the eMMC)
<zmatt>
no
<zmatt>
nothing got damaged
<murphized>
you mean that the filesystem corruption can be recovered by re-flashing the eMMC?
<zmatt>
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
<murphized>
ok I understand
<zmatt>
of course there's normally no reason to attach a wire to these pins unless you have eMMC disabled
<zmatt>
and yes you can fix that by reflashing anyway
<zmatt>
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)
<murphized>
that's probably due to the "internal" mux, that is the wire is still connected to other wires (gpio) instead of being phisically detached...
<zmatt>
ehhh
<zmatt>
no you're confused
<murphized>
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)
<zmatt>
no they presumably just didn't think about the signal integrity implications of hooking the FPGA up to everything, including the eMMC pins
<murphized>
if this does not make sense... I am definitely confused :)
<murphized>
ah ok
<zmatt>
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
<zmatt>
(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)
<murphized>
ok
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
<murphized>
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?
<zmatt>
regardless of whether overlays are used or not it needs a base dtb to which these overlays are applied
<zmatt>
though if overlays are enabled it will use a more stripped-down base dtb since optional features are then added using overlays
<murphized>
ah, perhaps if one disables overlays, then u-boot loads the device tree from the file I modified before (am335x_boneblack.dtd)
<zmatt>
it does yeah, that's basically a legacy fallback mode
<murphized>
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!