**** BEGIN LOGGING AT Thu Oct 31 02:59:58 2019 Oct 31 04:10:32 jkridner[m]: fyi, so far we've seen 70 BBBs mistakenly identifying themselves as industrial (A335BNLTEIA0) from three different production weeks: 1 from 2018 wk 25, 63 from 2018 wk 42, 6 from 2019 wk 3 Oct 31 04:12:16 if you want the serial numbers just let me know Oct 31 04:34:39 wow... Jetson wants >2A to run this net Oct 31 04:34:51 wonder if smoke will come out of a BBAI if I ever get this on there :D Oct 31 05:16:10 point for jetson - CUDA makes porting some NN's brain dead simple Oct 31 06:01:20 Hi, id there a way to run the beaglebone debian image on a virtual machine such as virtualbox or vmware? Oct 31 06:02:26 ebader18: no since you'd need to emulate the hardware to a sufficient degree to allow it to boot, and there is no such emulator for it Oct 31 06:02:48 Thanks, that makes sense! Oct 31 06:03:51 I created a GUI in Visual Studio in Windows, and I am hoping I could run it on beaglebone with a display. Oct 31 06:04:03 Is there a way to install the .NET framework on Debian? Oct 31 06:04:26 ebader18: dotnet core yes, windows forms, no Oct 31 06:06:25 they are actually doing a quite good job in documenting: https://dotnet.microsoft.com/download/dotnet-core/3.0 Oct 31 10:06:30 hi Oct 31 10:07:13 i want to know that which jtag emulator is to be used in Beaglebone black Oct 31 10:11:26 (but you weren't willing to wait a few minutes for the answer) Oct 31 10:45:44 hello! There's a way to reload a dtbo without rebooting? Oct 31 10:46:07 or a way to change "dinamically" the parameters it sets? Oct 31 11:02:25 Parduz: that's what runtime overlays were for, but they never worked reliably Oct 31 11:02:58 oh, ok. Oct 31 11:03:32 i'm also looking for the touch calibration, but seems i can't find any .... ? Oct 31 11:03:54 touch calibration is normally handled in userspace Oct 31 11:04:27 yup, it was an unrelated question :) Oct 31 11:04:45 i'm attacking on more than one front :) Oct 31 11:29:39 m Oct 31 11:43:25 how the /opt/scripts/3rdparty/xinput_calibrator_pointercal.sh should be used??? Oct 31 11:57:22 zmatt: i still wonder if it is possible to let the kerner load the driver for the screen only and build and run a service for the touch detection. Oct 31 11:58:09 that way i could do as many test i want without having to compile the kernel.... Oct 31 12:08:06 I have no idea what you mean by that... compile the kernel? to do what? Oct 31 12:32:46 zmatt: i'm still trying to get a better response from the touch panel, and not clogging the CPU when you actually touch it. this means that i'll have to modify the ti_am335x_tsc.c, which, if i'm not wrong, require to recompile the kernel Oct 31 12:34:55 fortunately it's pretty quick and easy to do so, especially recompilation after a small change (with tools/rebuild_deb.sh in the build repo) Oct 31 12:35:52 (as long as you have a not-too-crappy x86 linux system available to do so) Oct 31 12:37:01 notes about building a customized kernel: https://pastebin.com/eLhrp1Hg Oct 31 12:38:43 after the first time, modifying stuff in the KERNEL dir, running tools/rebuild.sh, copying the .deb to the beaglebone, installing it with dpkg -i, and rebooting is not the fastest edit-compile-test cycle in the world, but it's tolerable Oct 31 12:39:39 i see Oct 31 12:41:22 if the driver is built as module you may also be able to hot-swap it at runtime Oct 31 12:41:47 by unloading the kernel driver (after unbinding the device if necessary), replacing it, and loading the replacement kernel driver Oct 31 12:42:18 oh? Oct 31 12:42:23 interesting Oct 31 12:43:21 but before replacing just a kernel module you'll want to ensure the kernel installed on the BBB matches your build tree exactly, hence you'd first build a custom kernel once Oct 31 12:48:33 ok, i'll see what "built as module" means :) Oct 31 12:54:15 in kernel configuration when you select to enable or disable a driver you generally also have the option to compile it as module Oct 31 12:56:56 you can try changing CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y to CONFIG_TOUCHSCREEN_TI_AM335X_TSC=m in patches/defconfig before running ./build_deb.sh Oct 31 13:00:30 ok Oct 31 13:03:25 but could it be possible to "disable" the touch reading (still having the LCD driver) and make a program that reads the touch like the driver do? Oct 31 13:04:21 i could see how the reads are and try to smooth the result... i could even chart it! ... and then apply my math to my custom driver Oct 31 13:05:09 sure, but that would be non-trivial work, and for what purpose? to try to experiment with good ways to filter the measurements and then port that back to the kernel driver? Oct 31 13:05:28 exactly Oct 31 13:05:38 you could use uio Oct 31 13:06:18 it'll let you map the ADC registers into userspace and it can deliver IRQs from the ADC to userspace via a file descriptor Oct 31 13:07:47 seems good. But the running driver will not "interfer" with it? Oct 31 13:08:29 uio would be the running driver, the normal kernel driver would not be in use Oct 31 13:09:00 you can't have two drivers bound to the same device Oct 31 13:09:25 ...even the LCD driver? Is the screen "separated" from the "touch"? Oct 31 13:09:41 lcd and touch are completely unrelated Oct 31 13:10:13 so the LCD cape uses two different and indipendent drivers, great. Oct 31 13:10:21 ohey I actually already made an example DT snippet for it a while back... https://github.com/mvduin/py-uio/blob/master/dts/adc.dtsi Oct 31 13:10:32 the LCD cape uses a whole bunch of drivers probably Oct 31 13:12:29 lcdc, tscadc, some pwm device for the backlight, maybe gpio-leds if it has additional leds, gpio-keys if it has physical buttons Oct 31 13:12:49 the panel is also a device separate from lcdc itself Oct 31 13:14:28 yup. I'm slowing going to figure it all :) I'm sorry but really this world is a "mess" for me, until i get how things are related Oct 31 13:15:16 ok, so to check if i've got it: i could make a dtbo which loads the usual LCD driver and the UIO for the touch channels, then i can write a program that get the touch channels readings, and then playing with that values Oct 31 13:34:42 yup Oct 31 13:36:43 in case it's of interest, here's a C++ header I wrote for the adc registers including some comments/observations: https://liktaanjeneus.nl/adc.h.html (plain .h file is in the same location) Oct 31 13:39:34 (of course you could also use py-uio if you prefer python) Oct 31 13:47:47 i know "nothing" about python Oct 31 13:48:51 no worries it's kinda meh, I was just mentioning it as option since I happen to have written a uio library for python Oct 31 13:49:23 (my first "major" python project, might also be my last since the more I use python the less I like it) Oct 31 13:50:02 i had the same feeling when i wrote a macro i don't even remember for what :) Oct 31 13:51:06 different topic: Oct 31 13:51:28 is this the way we're supposed to calibrate the touchscreen? https://johanneskinzig.de/index.php/systems-engineering/16-bbb-touchscreen-calibration Oct 31 13:52:44 using the xinput, calculating the matrix and writing the results in a file that needs to be loaded after boot? Oct 31 13:55:34 xinput_calibrator -v gives an output and tells to write it in /usr/share/X11/xorg.conf.d/99-calibration.conf file, but does'nt seems to work, so should i try that matrix computation? Oct 31 13:56:25 I vaguely recall that calibration is more confusing than it needs to be in part because it'll depend on which xorg input driver you're using (e.g. evdev or libinput) Oct 31 13:56:48 Parduz: xorg doesn't use the values anymore.. you need to pass them to xinput, that http links show it.. Oct 31 13:56:49 in case of libinput iirc you can also configure the calibration matrix in an udev rule Oct 31 13:57:20 (which has the benefit of working not just for x11 but for anything that uses libinput) Oct 31 13:58:24 ok, thanks to you both Oct 31 13:58:27 lol, the libinput documentation helpfully says "It is thus not expected that the user sets this option. The desktop environment should provide an interface for this." Oct 31 13:58:48 :D Oct 31 13:59:02 very helpful when not using a desktop environment Oct 31 14:01:07 you see? for a noob like me it is all this way: someone says "do that" and then you discover that it was valid only if or . So that's why i asked for that page: always unsure that is (still) valid Oct 31 14:01:30 yeah touchscreen calibration is an opaque mess for some reason Oct 31 14:01:38 I really feel like it shouldn't need to be Oct 31 14:02:05 given the era we're living, i agree :) Oct 31 14:03:11 it kinda seems like once we all moved to capactive touch, which really doesn't need to be calibrated, just usually mirred and offset. all the calibration utilties just stopped being worked on.. Oct 31 14:03:54 (but we still have existing resistive touch screen that need to be calibrated) Oct 31 14:07:28 yep Oct 31 14:07:36 ok, last question for a while: Oct 31 14:07:52 what exactly the ti,charge-delay parameter do? Oct 31 14:08:16 i've read the https://www.kernel.org/doc/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt description, but i can't get it Oct 31 14:08:44 but changing it from 0x400 to 0x4000 in the cape dts really changed my life :) Oct 31 14:09:02 you're probably just making the measurements slow as fuck Oct 31 14:09:23 which is... a way of rate-limiting I guess :P Oct 31 14:10:27 well, it works wonderfully. The mouse could be a very bit slow (really, just a bit) if you had to draw with the tcs, but for my app that's made of buttons it works like a charm Oct 31 14:11:12 it's the time spend on the charge step (which charges up the touchscreen for touch-detection) Oct 31 14:11:51 soory for my ignorance. "charge step" means? Oct 31 14:12:04 I explained that in parentheses Oct 31 14:13:33 yup, but i'm dumb (also, not fond in electronics). Do this means that the tcs needs to be charged before reading the coordinates? or to determine if is touched? Oct 31 14:14:24 curious, it looks like the kernel driver doesn't actually use the charge step at all Oct 31 14:15:17 so charge-delay just acts like mandatory idle-time after each measurement Oct 31 14:16:01 from where in the driver file you see that it is not used? Oct 31 14:16:42 it loads the value in ts_dev->charge_delay Oct 31 14:16:48 /* Make CHARGECONFIG same as IDLECONFIG */ Oct 31 14:17:37 then "titsc_writel(ts_dev, REG_CHARGEDELAY, ts_dev->charge_delay);" Oct 31 14:17:40 yeah the time is used, but the charge step isn't used to charge anything up, the touchscreen transistors are disabled... unless IDLECONFIG is being written somewhere in a non-obvious way ( Oct 31 14:17:56 I haven't dug through the code in much detail Oct 31 14:18:40 maybe I'm wrong Oct 31 14:19:15 ok Oct 31 14:19:26 ah it's configured in drivers/mfd/ti_am335x_tscadc.c Oct 31 14:20:54 is givin "so much time" to charge harmful for the hardware? Oct 31 14:22:31 no, note again that the config for the charge step is the same as for the idle step Oct 31 14:22:50 like I said, the charge_delay basically acts like a minimum amount of idle time Oct 31 14:23:20 great. Oct 31 14:23:35 so i've done a bad hack, basically Oct 31 14:23:36 after performing measurements it'll perform the "charge step", which is basically just idle for the configured amount of time, and then it'll go to the idle step Oct 31 14:24:14 ideally you'd want few or no events as long as you're holding your finger in a fixed spot Oct 31 14:24:30 slowing the measurement rate down is never going to accomplish that Oct 31 14:24:46 yup. But also the mouse is still "nervous" around where you're touching (it jumps back and forth 3/4 pixels costantly) Oct 31 14:24:47 so it just makes the problem slightly less problematic Oct 31 14:25:04 exactly, that's the root issue Oct 31 14:25:08 so it will never happen anyway until i find how to smooth it. Oct 31 14:25:24 that jitter needs to be smoothed out Oct 31 14:25:34 then the event flood is automatically solved Oct 31 14:26:06 do you have any clue if the adc branch parameters could help for that? i don't expect to solve it, but i wonder if they can help Oct 31 14:26:54 i mean, the ti,chan-step-opendelay and ti,chan-step-sampledelay Oct 31 14:28:20 I don't expect any adc parameter to help except maybe averaging (although software can probably filter much better than decimating by simple averaging ever will) Oct 31 14:29:19 I don't really understand why you'd ever want to use opendelay instead of sampledelay though, that part is still a mystery to me Oct 31 14:30:42 i don't WANT to use anything :) i'm just trying to figure out if i can do something about it before digging in the kernel/driver customization Oct 31 14:33:02 basically i'm just trying to guess what's the meaning of what i see, and to learn from you :) So if you tell me that the opendelay is to be left as it is, i'll leave it as it is Oct 31 14:37:00 so, basically for each measurement it needs to 1. configure the adc (mux the appropriate input (or input(s) in case of differential measurement), enable/disable pull-up/down transistors, select reference voltages) 2. sample the input (i.e. connect the input to the internal capacitors of the adc and let them charge/discharge to the level of the input) 3. perform conversion (disconnect the internal ... Oct 31 14:37:06 ...capacitors from the inputs and convert their voltages into binary) Oct 31 14:38:03 opendelay is the time between step 1 and 2, i.e. time spent with everything configured for the measurement but without sampling the value Oct 31 14:38:49 sampledelay is the time between 2 and 3, i.e. time spend letting the internal caps settle to the voltage you're trying to measure Oct 31 14:40:48 ah! so my feeling was right, increasing opendelay does not really benefit the measurement at all: Oct 31 14:41:14 "Open delay allows the user to insert fixed delays between steps when they need the ADC to sample at very predictable periodic sample rates that falls between the rate adjustment provided by changing the adc_clk divider. This delay does not have any effect on accuracy of the acquisition." Oct 31 14:42:03 although that still doesn't really explain why you'd use open delay for that instead of sample delay Oct 31 14:46:38 Parduz: are you using 4-wire or 5-wire touchscreen? Oct 31 14:56:23 4 Oct 31 14:58:06 zmatt: thanks for the explanation Oct 31 15:02:36 so yeah, then in idle it will drive y+/y- low and it will weakly pull up x+, a touch will cause x+/x- to connect (resistively) to y+/y- hence discharging the x+ pin, which is interpreted as a touch and triggers the programmed measurement steps to figure out where the touch is Oct 31 15:03:42 (if you're unfamiliar with how a 4-wire resistive touchscreen works, there's a good explanation with nice diagrams in chapter 2 of https://www.nxp.com/docs/en/application-note/AN10675.pdf Oct 31 15:04:30 section 2 is maybe a better word, "chapter" sounds bigger than the 2.5 pages it actually is ;) Oct 31 15:07:51 ah, and the way linux programs the adc is explained by advisory 1.0.31 of the am335x errata Oct 31 15:10:08 basically the intended purpose of the charge step is to charge x+ up to high level before switching to weak pull-up to ensure pen-up/touch-release is detected expediently Oct 31 15:11:42 but it can result in false pen-up interrupts, so instead normal steps are used for this purpose and the charge step is indeed just used as a "forced idle" period during which x+ gets a bit of time to discharge again if you're still touching Oct 31 15:18:51 wow Oct 31 15:18:55 thanks a lot Oct 31 17:01:59 this line: xinput set-prop "ti-tsc" "libinput Calibration Matrix" 1.08108108, 0.0, -0.06193694, 0.0, 1.14606742, -0.08146067, 0.0, 0.0, 1.0 seems to works Oct 31 17:02:15 should i put it in a udev rule file? Oct 31 17:03:56 or just in the .xsessionrc ? Oct 31 17:06:01 whichever you prefer... like I said, udev has the benefit it'll be X11-independent (e.g. wayland uses libinput, qt5-eglfs supports libinput) Oct 31 17:06:42 ok. it goes just like that? i mean, i create a file and paste that line as it is? Oct 31 17:06:55 for an udev rule you'd use some criterion that matches the touchscreen followed by ENV{LIBINPUT_CALIBRATION_MATRIX}="1.08108108 0 -0.06193694 0 1.14606742 -0.08146067 0 0 1" Oct 31 17:08:03 ok .... i've just found a more urgent problem. Oct 31 17:08:55 I can give a concrete suggestion for an udev rule if you can share the output of udevadm info -a PATH where PATH is the touchscreen device (in /dev or in sysfs) Oct 31 17:09:34 sure Oct 31 17:10:41 more urgent problem? Oct 31 17:10:59 it appeared when i disabled the services to optimize the boot time ... did'nt really though at it but now i've discovered the .xsession-errors file... which contains the output of my app. Oct 31 17:11:08 i2c_read_addr error at byte 0: Inappropriate ioctl for device Oct 31 17:11:18 o.O Oct 31 17:11:44 seems that i don't have access to the i2c anymore... Oct 31 17:11:49 I have trouble imagining how any startup service could affect whether your application produces that or not Oct 31 17:11:57 if you don't have access I don't think you'd get this error Oct 31 17:14:19 can you share your i2c code? because that error is hard to make sense of unless you somehow perform the ioctl() on the wrong file descriptor Oct 31 17:14:41 yep Oct 31 17:14:46 gonna get it Oct 31 17:16:34 just checked, the only ENOTTY in drivers/i2c/*.c is for an unrecognized ioctl(), and the error does not occur in drivers/i2c/busses/i2c-omap.c either Oct 31 17:17:10 so it kinda has to be the result of performing either a nonsense ioctl or a valid ioctl on the wrong file descriptor Oct 31 17:18:32 found a "permission denied" error when i open it Oct 31 17:18:43 when my app starts Oct 31 17:19:19 what flags are you passing to open() ? Oct 31 17:20:38 that still doesn't explain things btw since if open() fails then the "file descriptor" returned is -1, and if you try to do an ioctl() on -1 you'd get EBADF, not ENOTTY Oct 31 17:21:33 wait, im slow :) Oct 31 17:21:41 unless I dunno you have the fd in a global variable that's initialized to 0 instead of -1 and open() failing causes that variable to be left at zero, then you're trying to do the ioctl() on stdin and you'd get ENOTTY Oct 31 17:23:08 take your time Oct 31 17:24:28 fd = open("/dev/i2c-2", O_RDWR); Oct 31 17:24:32 this line fails Oct 31 17:25:00 i think i have to check why i go further in trying to use it, but this fails. Oct 31 17:25:50 (actually that string ic a char pointer passed to the function) Oct 31 17:25:57 *is Oct 31 17:27:34 could it be that my app tries to open it but the BBB is still bootin and it is'nt ready. Oct 31 17:27:43 ? Oct 31 17:33:12 hah, optimized boot time too much ;) it's not inconceivable. normally if a service has a fixed dependency on a device (or another service) you'd declare that dependency in the service file and systemd would take care of things. alternatively you can use udev to monitor for the availability of devices (which is also how you can support devices being missing and/or hotplugged) but that's obviously ... Oct 31 17:33:18 ...more complicated Oct 31 17:34:04 the fact that your app isn't a service makes things a bit more annoying, but you could add the dependencies to the display manager service instead Oct 31 17:35:26 (you can add dependencies or other directives to a distro-provided service file by creating an /etc/systemd/system/UNIT.d directory containing a .conf file with your overrides Oct 31 17:35:29 ) Oct 31 17:36:32 ...i f...up something. Now when the BBB reboots asks for login in the console, it doesnt start the windows manager. ARGH! Oct 31 17:36:47 check journal Oct 31 17:36:55 or the status of the unit Oct 31 17:37:25 hard on the LCD :( Oct 31 17:37:33 it soesn makes me ssh Oct 31 17:37:47 what did you do :P Oct 31 17:38:35 afaik, added that line about xinput to the home/debian/.xsessionrc file Oct 31 17:38:56 removed it already Oct 31 17:39:06 btw just as example of what I just said about how to elegantly add/override some parts of a distro-provided service file: https://pastebin.com/i6gfRSPQ (this was to enable debug logging in systemd-networkd) Oct 31 17:39:30 ok, i'll look at Oct 31 17:39:32 I really don't see how that could prevent you from ssh'ing in Oct 31 17:40:02 silly me Oct 31 17:40:15 i was logging as root with user passwoerd Oct 31 17:40:21 though I am glad we managed to avoid X11 entirely for our gui application ;) Oct 31 17:40:33 you generally shouldn't log in as root anyway :P Oct 31 17:40:41 it was a mistake Oct 31 17:41:15 i use WinSCP and launched putty from the root window (which i need to edit root files) Oct 31 17:44:33 my journal Oct 31 17:44:34 https://pastebin.com/gMkTsN2S Oct 31 17:46:43 okay what kind of bizarro udev rule is trying to mess with stuff in /lib/firmware Oct 31 17:46:57 that doesn't belong *at all* in an udev rule Oct 31 17:48:11 what are you looking at? Oct 31 17:48:57 all of the "systemd-udevd[...]: Process '...' failed with exit code 1." lines Oct 31 17:49:10 yup, seen Oct 31 17:50:03 they're not the cause of your problems, but they are indicative of an udev rule that could use some attention (by that I remove it entirely, optionally replace by an /etc/tmpfiles.d/ config file if necessary) Oct 31 17:50:12 and it'll cause slowdown Oct 31 17:50:40 so, what i've done today is apt install xinput and xinput-calibrate, and played with the calibration. nothing else Oct 31 17:53:16 did you install any packages? there's a config file /usr/share/X11/xorg.conf.d/99-calibration.conf that has a grammatical error Oct 31 17:53:26 perhaps 'cause there's no more the "initramfs" and they're should be? Oct 31 17:53:46 Oct 31 17:32:54 beaglebone slim[318]: Parse error on line 1 of section InputClass in file /usr/share/X11/xorg.conf.d/99-calibration.conf Oct 31 17:55:13 you can check to which package the file belongs with dpkg-query --search /usr/share/X11/xorg.conf.d/99-calibration.conf Oct 31 17:55:33 that's belong to the package "i'm a noob" Oct 31 17:56:07 I mean surely you didn't create it yourself right? given that /usr/share/ entirely belongs to distro-provided files whereas your custom config would go into /etc/X11/xorg.conf.d/ Oct 31 17:56:30 :P Oct 31 17:57:02 NOT AT ALL! :P Oct 31 17:57:37 ok, we're ok, it runs Oct 31 17:57:47 back to the i2c problem :| Oct 31 18:00:42 ok , i can confirm that my app starts and get the permission denied. Oct 31 18:00:58 i close it and run again after, and it works Oct 31 18:01:57 looking at the link you give me: Pastebin.com is under heavy load right now :( Oct 31 18:02:04 argh Oct 31 18:06:34 Quick Question, Does anyone know of some good information about inter pru communication? I see there is some shared memory I could map to both of them, but I didn't know if there was any other ways of doing it. Oct 31 18:18:00 zmatt: what's the systemd service that gives me access to the i2c? Oct 31 18:18:19 trying to figure it out but i don't get it Oct 31 18:25:29 Parduz: so instead of dealing with individual devices you can probably do this: https://pastebin.com/1Ajh0vYD Oct 31 18:27:38 alternatively you could add such rules for device units, but you may then need an udev rule to tag them to create device units in the first place Oct 31 18:29:26 chaise: it depends on the application. shared memory, shared scratch pad, direct core-to-core transfers (which also act as synchronization points), delivering events via the pruss intc Oct 31 18:31:03 not sure what you mean with "could map to both of them", both pru cores can access all three data rams in pruss (although typically dram0 is considered reserved for core0, dram1 for core1, and dram2 is intended for shared memory) Oct 31 18:31:09 anyway, bbl, shopping Oct 31 19:03:56 Hi. I have compiled the 4.19 linux kernel with the bb.org_defconfig and load it from the u-boot shell via UART0. I have am335x-boneblack.dtb in there as well. When I start the kernel the output in my serial terminal stops after "Starting kernel". It could be a miss-configured serial connection. but how do I fix this? Oct 31 19:21:19 zmatt: https://docs.google.com/spreadsheets/d/e/2PACX-1vSB0SmXxNCxdazDYFF9x55__ks2zxsuh8-AZYl7kkCSIJptsBHP02ZPD2lu-XS6JTe8-uWtnhnWOSwz/pubhtml?gid=1887626825&single=true seems to be missing some of the gpio modes I set on shorted pins. Oct 31 19:21:38 P9.11 ball B8, for example. Oct 31 19:43:08 zmatt: also, no change to the ehrpwm pins. Oct 31 19:43:17 anyway, can you recheck it? Oct 31 22:50:54 For some reason on BBB pins P8.37 and P8.38 are unavailable: Oct 31 22:51:08 root@beaglebone:~# config-pin -q p8.37 Oct 31 22:53:44 It happens on 2 BBB. At the same time, it seem that BB Green does not have this issue. Oct 31 23:22:55 dreamhiker: if hdmi is enabled, pins P8.27-46 are in use for video. if you don't care about hdmi and want to free up the pins, there's a config option for that in /boot/uEnv.txt Oct 31 23:23:14 dreamhiker: the BB green doesn't have hdmi, hence the pins are free by default there Oct 31 23:47:46 jkridner: ah somehow I saw the latest commit ("SW: u-boot: pinmux: add pull-ups on I2C4") but completely missed the one that actually mattered (SW: u-boot: pinmux: update based on review), my bad! Oct 31 23:58:24 zmatt, I am using the smallest BB image Debian_Stretch_Console_Snapshot image. Why would HDMI be enabled? Oct 31 23:58:37 Looking at uEnv.txt: Oct 31 23:58:40 #cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e Oct 31 23:59:22 That's the only place it is mentioned. How do I disable HDMI? Oct 31 23:59:45 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices Nov 01 00:05:03 take chisel and.... Nov 01 00:09:31 Thanks zmatt and rcn. This has fixed the issue. Nov 01 00:10:44 At the same time, I am still curious why video was enabled in the minimal image? is it a bug that jkrinder is talking about? Nov 01 00:11:49 dreamhiker: video is always enabled by default.. Nov 01 00:11:55 doesn't matter what image it is. Nov 01 00:12:16 either your happy it's disabled or happy it's enabled.. it's enable because it's onboard.. Nov 01 00:18:28 Thanks! I need to accept this. I am curious, if there is a command to check if video/audio is enabled Nov 01 00:19:25 this will give you a big hint: sudo /opt/scripts/tools/version.sh Nov 01 00:32:09 Thanks rcn! What is the best way to learn those things? Nov 01 00:33:10 dreamhiker: option B, if your overlays are recent enough you can check /proc/device-tree/chosen/overlays/ to see if the HDMI overlay is there Nov 01 00:58:21 jkridner: are there one or two processor pins going to P9.13 ? the schematic says one but iirc I saw something somewhere implying there might be two. it could definitely use a sibling since the processor pin that connect to P9.13 has no gpio mode, so without having another pin provide that it's not possible to use that pin in gpio mode Nov 01 00:58:48 ok I've updated my spreadsheet and I'm taking a look Nov 01 01:40:10 jkridner: P8.33a, P8.35a, and P9.27b should definitely be gpio instead of safe since their companion is muxed to eQEP Nov 01 01:44:11 I noticed some pins won't have a gpio by default... is it important to mux eQEPs and pruins early? since they're inputs the only risk is "up to multiple nanoseconds" of drive conflict during boot but I don't know if that's actually a problem or not (for the am5729 or external electronics) Nov 01 01:48:24 jkridner: P9.21, P9.27, P9.29, P9.31, P9.41, P8.31-35, P8.37-38, and P8.45-46 still have two pulldowns each Nov 01 01:57:25 jkridner: is there a system in your choices of pull-up vs pull-down? since they match neither the defaults nor the BBB, and for quite a few I'm not sure why they're configured the way they are.... a concern about changing a default pull-up pin to pull-down is that it'll basically send a pulse during early boot, which may have unexpected effects if the pin is used as output (I've accidently driven ... Nov 01 01:57:31 ...transistors with the internal pull-ups on the AM335x) Nov 01 01:58:52 I've added a column for the BBB's Pull direction btw, for comparison Nov 01 02:01:35 + Nov 01 02:02:38 jkridner: I guess good arguments can be made both for leaving pulls in their default direction (except to resolve pull-pull conflicts) Nov 01 02:02:58 and for setting all pulls to be same as the BBB for maximum compatibility Nov 01 02:03:13 not sure what the Right Thing to do is Nov 01 02:04:00 I'm leaning towards leaving at default since the board is going to spend at least *some* time in default state anyway, so any cape will have to cope with it regardless Nov 01 02:05:14 and preferably you'd have a stable default level for signals until they are configured for use, rather than having signals transitions before the kernel even loads **** ENDING LOGGING AT Fri Nov 01 03:00:13 2019