**** BEGIN LOGGING AT Wed Jan 23 02:59:57 2019 Jan 23 08:14:27 zmatt are you here ? Jan 23 08:17:06 i have debian 9 on my laptop, just flashed debian 9.5 IoT to my beaglebone green, connected laptop to bbg via micro usb cable. i'm unable to connect to it via beaglebone.local Jan 23 08:17:30 ssh 192.168.7.1 Jan 23 08:17:36 i ran mkudevrule.sh, i see "USB Ethernet Connecting" but it doesn't Jan 23 08:17:48 ok, trying that now Jan 23 08:18:00 readme says 192.168.7.2 Jan 23 08:19:31 192.168.7.{1,2} neither work Jan 23 08:19:40 hmm. Jan 23 08:19:53 thanks for your attention on this Jan 23 08:20:30 i was able to get a beaglebone blue connected via usb with the same image flashed to it Jan 23 08:21:43 i would try cycling the cables but i've not had much luck with the OTG/USB ethernet device Jan 23 08:21:58 how do you connect? Jan 23 08:22:20 oh, i'll try a different cable, good idea Jan 23 08:23:19 wait... the fact that i can see the device at all means the cable has data Jan 23 08:23:43 i mean plug/unplug the current one Jan 23 08:23:51 soemtimes it won't attach in OTG/ethernet mode Jan 23 08:23:57 k Jan 23 08:24:31 yeah, it shows up as a usb storage device Jan 23 08:24:48 but can't do 192.168.7.{1,2} or beaglebone.local Jan 23 08:25:02 replugged in usb cable Jan 23 08:25:17 ok, well bummer Jan 23 08:25:37 i'll have to wait until i have the beaglebone blue again Jan 23 08:25:45 thanks kremlin! gnight Jan 23 08:25:52 np, night Jan 23 08:28:22 oh derp Jan 23 08:28:35 sd card wasn't in all the way Jan 23 08:28:49 192.168.7.1 works now and gives apache2 debian default page Jan 23 08:29:14 ;-) Jan 23 08:30:51 er... i thought the default username/pw was debian/temppassword is it not? Jan 23 08:31:01 i forget. check the SRM Jan 23 08:31:29 oh hey, beaglebone.local works! Jan 23 08:40:19 how do i connect the beaglebone to the internet? Jan 23 08:40:57 through the usb? the guides i'm finding are not for debian and it's kinda hard to google for debian on the laptop, the results seem to think i'm talking about debian on the beaglebone Jan 23 08:42:07 what you're trying to do isn't board-specific, but you want to bridge the interface to whichever one the public internet is on Jan 23 08:46:46 how should I install the device tree compiler ? Jan 23 08:47:22 apt install device-tree-compiler is correct ? Jan 23 08:49:59 kremlin, thanks again. now i really will go to bed. i'll work on bridging tomorrow Jan 23 08:50:58 np, night Jan 23 12:27:56 m Jan 23 14:22:23 zmatt ru there ? Jan 23 14:41:57 sort of. I'm at work Jan 23 14:42:33 in general though, just ask your questions instead of asking for someone's attention Jan 23 14:42:37 so too much busy.... Jan 23 14:43:14 it just means it may take a while to get a reply Jan 23 14:43:43 but not asking a question is a guaranteed way to never get a reply to it ;) Jan 23 14:44:08 I'm OK for give a try to modify LCD7 clone eprom , but I have to be taken by hand step-by-step.... Jan 23 14:44:21 not even idea from where to start... Jan 23 14:45:08 https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md Jan 23 14:45:24 tutorial with link to a "cape eeprom generator" made by someone Jan 23 14:45:35 I just found it by googling for "cape eeprom" Jan 23 14:47:54 first of all 24c256 WP pin is connected to ground. Jan 23 14:48:13 that's convenient, that means write-protection is disabled Jan 23 14:48:56 we already kinda established that last time though Jan 23 14:50:31 tutorial doesn't tell us how to READ current eprom... Jan 23 14:50:39 it does Jan 23 14:51:07 under "Programming the EEPROM" it first verifies eeprom contents (with a Useless Use of "cat") Jan 23 14:51:31 except the path is wrong I think Jan 23 14:51:41 but just use the path that worked for you last time Jan 23 14:52:06 hexdump -C /sys/bus/nvmem/devices/2-00540/nvmem Jan 23 14:52:58 (note: /sys/bus/nvmem/devices/2-00540/nvmem and /sys/bus/i2c/devices/2-0054/eeprom are more or less equivalent in functionality) Jan 23 14:53:43 (the nvmem devices are newer and preferred) Jan 23 14:55:19 https://pastebin.com/BPND2HgS Jan 23 14:56:08 if you want to make a backup, just do cat /sys/bus/nvmem/devices/2-00540/nvmem >eeprom-backup.bin Jan 23 14:58:39 done Jan 23 15:00:32 should I now modify the current content ? Jan 23 15:02:35 as described in the tutorial you can use the bbcape_eeprom utility to create a new eeprom Jan 23 15:02:51 and write it to file Jan 23 15:03:10 and then write that file to eeprom Jan 23 15:07:50 note again though, like I said last time, programming the eeprom (or even the presence of one) is not all that important for a custom cape, you can just use /boot/uEnv.txt to load the correct overlay. what matters most is the absence of wrong information that causes an inappropriate overlay to be loaded Jan 23 15:09:08 you could erase it using: Jan 23 15:09:35 perl -C0 -e 'print "\xff" x 256' >/sys/bus/nvmem/devices/2-00540/nvmem Jan 23 15:10:51 autodetection is really only useful for capes that are sold to people and whose overlays are in the bb.org-overlays repository, for the convenience of making them work "plug & play" Jan 23 15:11:11 Should it be erased before (not just overwritten) ? Jan 23 15:11:45 it has no separate erase command Jan 23 15:13:36 basically an i2c eeprom's interface just consists of "seek to offset", "read byte", and "write byte" Jan 23 15:14:36 I mean has it to be erased first then written ? Jan 23 15:15:27 there is no concept of "erase" Jan 23 15:15:36 what I called "erase" is just writing 0xff bytes Jan 23 15:15:56 you said before with perl -C0 etc Jan 23 15:16:10 yeah ok Jan 23 15:16:21 perl -C0 -e 'print "\xff" x 256' writes 256 0xff bytes to stdout Jan 23 15:16:28 ok Jan 23 15:19:02 to make things simpler, (preparing the device tree as described in tutorial) isn't easier to modify just what needed on read eprom then write and next modify the dtbo it was calling for and rename to fit modified eprom ? Jan 23 15:19:07 so, just curious, what's the story behind all this? it's a bit unusual to have a custom cape but not much idea of how to get it operational (since typically there'd be a prototyping phase during which such knowledge would be acquired) Jan 23 15:19:49 you don't need autodetection (based on the cape eeprom) to load an overlay, you can just specify it explicitly in /boot/uEnv.txt Jan 23 15:21:41 no, simply you have suggested to modify eprom to avoid claiming to system what it really is NOT Jan 23 15:21:55 exactly Jan 23 15:22:57 so you could put custom info in it, or you could just "erase" it (overwrite the data with 0xff, since that's the default content for an eeprom when shipped) Jan 23 15:24:43 since now I'm doing thing without to know what I'm doing (that's awful) this morning I have modified /lib/firmware/BB-BONE-LCD7-01-00A2.dtbo with non-standard 640x480 resolution and it works like a charm Jan 23 15:25:10 even with autodetection you would need to customize your /boot/uEnv.txt anyway, since the current overlay system is rather imperfect and still requires some information hardcoded in the bootloader based on cape id, namely which standard overlays must be disabled Jan 23 15:25:23 Can I make a copy of modified dtbo (renamed) and recall it from uEnv.txt ? Jan 23 15:25:34 yes Jan 23 15:26:25 how ? Jan 23 15:26:28 I'm actually surprised you didn't need to also explicitly disable the hdmi overlay Jan 23 15:26:49 since it looks like the LCD7-01-00A2 cape is completely missing in the bootloader's hardcoded table Jan 23 15:26:59 it only has LCD7-01-00A3 Jan 23 15:28:01 so, save it as /lib/firmware/my-cape.dtbo or whatever, and then... Jan 23 15:28:26 dtb_overlay=/lib/firmware/my_new.dtbo Jan 23 15:29:10 https://pastebin.com/raw/a8KkqM88 Jan 23 15:29:12 something like that Jan 23 15:30:10 I mean, you could use dtb_overlay too *I think* ... but since your cape does actually have an eeprom it would be more appropriate to use uboot_overlay_addr0 Jan 23 15:32:03 does "disable_uboot_overlay_video=1" prevent the recognized LCD7 to be automatically loaded ? Jan 23 15:34:20 no Jan 23 15:34:27 that's just for the built-in hdmi Jan 23 15:34:45 oh wait, you don't have any Jan 23 15:34:48 that's why it works Jan 23 15:35:04 I forgot you have a beaglebone white Jan 23 15:35:19 in that case disable_uboot_overlay_video=1 and disable_uboot_overlay_audio=1 do nothing Jan 23 15:36:25 on a beaglebone black disabling the on-board hdmi video would be required to make the cape work Jan 23 15:37:38 really u-boot ought to do so automatically based on the information in the overlay, but currently it does so based on a hardcoded list (in which BB-BONE-LCD7-01-00A2 is missing entirely) Jan 23 15:39:15 But how should I tell it "don't load the LCD7 dtb for the cape you have automatically recognized" ?? Jan 23 15:39:39 perl -C0 -e 'print "\xff" x 256' >/sys/bus/nvmem/devices/2-00540/nvmem Jan 23 15:40:00 overwrite the eeprom data, it won't see an LCD7 cape anymore Jan 23 15:40:13 :-)))) Jan 23 15:40:15 right Jan 23 15:40:20 you have a backup Jan 23 15:41:22 actually setting the uboot_overlay_addr0 variable should override autodetection in this case, but it would be better to not have wrong identification to begin with Jan 23 15:41:36 and this ? https://pastebin.com/HPXxb6FM Jan 23 15:42:46 about what it? those are comments explaining (more or less) the various variables that exist Jan 23 15:42:50 *what about it? Jan 23 15:43:44 doesn't "disable_uboot_overlay_addr0=1" prevent the load of specified cape even if recognized ? Jan 23 15:44:34 presumably. it probably also disables any manually-specified overlay in uboot_overlay_addr0 Jan 23 15:44:40 there are plenty of options Jan 23 15:45:05 anyway , erased eprom = no cape detected Jan 23 15:45:17 I was just giving the most obvious and sensible settings Jan 23 15:46:45 trying.... Jan 23 15:49:02 When rebooting , screen is stuck with tux penguin for long time (20-30sec) before login prompt why is this ? Jan 23 16:00:12 Well, erased eprom and modified dtbo recalled , all OK Jan 23 16:03:18 if you want to know what it was doing, check journal (journalctl -b) or make a boot graph using: systemd-analyze plot >boot.svg Jan 23 16:05:02 ok Jan 23 16:06:20 you're using the latest console image? Jan 23 16:06:33 yes Jan 23 16:07:03 I wonder which connection manager it uses, ifupdown or connman... since ifupdown is known to cause slow boot if the bbb is not connected to an ethernet network Jan 23 16:07:30 (I use systemd-networkd myself) Jan 23 16:08:29 connman, for my laziness I have removed it and gone with usual /etc/network/interfaces Jan 23 16:09:03 well maybe you've discovered the reason for the slow boot :) Jan 23 16:09:28 it is connected to eth, though Jan 23 16:09:35 hmm Jan 23 16:09:52 perhaps waiting for usb interface ? Jan 23 16:09:54 well, I was just guessing, check logs or boot plot to actually know for sure Jan 23 16:10:46 Last problem: touchscreen calibration : xinput_calibrator ends with something like this: Jan 23 16:11:06 I can highly recommend systemd-networkd btw, it's just as easy to configure as ifupdown but tends to be more efficient and flexible and tends to work better with dynamic network changes Jan 23 16:11:46 https://pastebin.com/dAysXXHz Jan 23 16:12:32 I've created /etc/X11/xorg.conf.d/99-calibration.conf with those data but no way..... Jan 23 16:13:10 as well as /usr/share/X11/xorg.conf.d/99-calibration.conf Jan 23 16:13:16 same thing... Jan 23 16:14:07 you should not modify stuff in /usr (outside /usr/local), those files are managed by the package manager Jan 23 16:15:51 hmm, which xinput driver is used for the touchscreen? (check for "Using input driver" lines in your Xorg.log ) Jan 23 16:21:04 in general it may be useful to pastebin Xorg.log Jan 23 16:23:54 I think if libinput is used then you can also set the calibration using an udev rule, which would have the benefit of not being X11-specific Jan 23 16:24:07 not sure why your xorg.conf snippet doesn't work though Jan 23 16:24:29 just a moment.....and..... Jan 23 16:26:18 ti-tsc Jan 23 16:26:39 input device 'ti-tsc', /dev/input/event0 is tagged by udev as: Touchscreen Jan 23 16:28:33 that's not the driver Jan 23 16:28:38 I think? Jan 23 16:28:46 seems like the name to me Jan 23 16:30:54 you're right Jan 23 16:30:56 Using input driver 'libinput' for 'ti-tsc' Jan 23 16:34:40 https://pastebin.com/BnHThJUS Jan 23 17:01:37 so, libinput can be configured via an udev rule Jan 23 17:02:42 what you pasted is not really the format needed though... can you try xinput_calibrator --output-type evdev ? Jan 23 17:05:38 sorry I meant --output-type xinput Jan 23 17:05:59 or alternatively, after doing the calibration, check the relevant property using: Jan 23 17:06:03 xinput list-props 'ti-tsc' | grep 'Coordinate Transformation Matrix' Jan 23 17:06:27 oh wait never mind, that last option probably only applies to evdev and not libinput Jan 23 17:06:31 not 100% sure though Jan 23 17:06:56 either way the goal is to get a coordinate transformation matrix instead of an xorg.conf snippet Jan 23 17:11:28 xorg print calibrator does not support the supplied --output-type Jan 23 17:11:36 (xinput) Jan 23 17:11:44 huh, it's in the man page Jan 23 17:11:50 in fact.... Jan 23 17:12:14 alternatively, you could make x11 use the evdev driver instead of the libinput driver probably Jan 23 17:12:45 that's how it worked in older systems... Jan 23 17:12:58 don't know how to do now... Jan 23 17:14:18 one lazy way would be by making sure xserver-xorg-input-evdev is installed and then purge xserver-xorg-input-libinput .. but probably you could also just specify Driver "evdev" in your xorg snippet or something like that? Jan 23 17:14:40 yeah that should work Jan 23 17:16:13 try using the xorg snippet you already had but with Driver "evdev" added inside the section Jan 23 17:16:40 I also have 40-libinput.conf on /usr/share...... https://pastebin.com/WyUpMNrm Jan 23 17:16:59 added in there produces nothing.... Jan 23 17:17:25 huh? what does Xorg.log say? Jan 23 17:18:43 a driver specified in /etc/X11/xorg.conf.d/99-calibration.conf should take precedence once the one in /usr/share/X11/xorg.conf.d/40-libinput.conf Jan 23 17:19:25 I havent the /etc/X11/xorg.conf.d directory ! Jan 23 17:19:40 just /etc/X11/xorg.conf file Jan 23 17:19:47 so make the directory! Jan 23 17:20:03 what? there's an xorg.conf file? what's in it? Jan 23 17:20:55 I have no idea how an xorg.conf file is treated relative to xorg.conf.d snippets... a modern linux system should not have an xorg.conf file Jan 23 17:21:32 an xorg.conf file is something from the time of sadness and despair... https://xkcd.com/963/ Jan 23 17:23:08 in fact....there's something related to fbdev Jan 23 17:24:12 oh that, yeah that really belongs in a file in xorg.conf.d Jan 23 17:24:39 I should poke rcn about that... but I don't really care enough, I don't use x11 on any beaglebone Jan 23 17:25:57 xorg.conf https://pastebin.com/pPSt1NYa Jan 23 17:26:52 however /etc/X11/xorg.conf.d/99-calibration.conf doesn't work... Jan 23 17:27:09 time to go... what a pity Jan 23 17:27:41 tomorrow morning i'll made some tests Jan 23 17:28:08 see also https://wiki.archlinux.org/index.php/Calibrating_Touchscreen Jan 23 17:28:23 on how to calculate a coordinate transformation matrix from the info xinput_calibrator spits out Jan 23 17:28:58 the libinput driver accepts those numbers either in a udev property (as described on that page) or, probably more conveniently, in an xorg.conf.d snippet Jan 23 17:29:23 Option "CalibrationMatrix" "(9 numbers here)" Jan 23 17:32:04 i was looking to.... Jan 23 17:32:10 tomorrow Jan 23 17:32:17 Grat thank you Jan 23 17:32:24 good luck Jan 23 21:36:06 I have never used UART on beagle, should I enable desired one recalling /lib/firmware/BB-UARTx-00A0.dtbo from uEnv.txt ? Jan 23 21:38:09 you already have a custom overlay for your cape, that's the place to describe your hardware Jan 23 21:38:30 you could look at those uart overlays for inspiration Jan 23 21:41:55 but yeah, if there is an existing overlay for the right pins then you can use that too, though once you've confirmed it works I'd still suggest just merging it into your custom overlay Jan 23 21:43:47 do you mean I have to check uart pins don't conflict with lcd ones ? Jan 23 21:44:51 and/or make a single dtb for both devices ? Jan 23 21:45:44 okay maybe I should have checked: is the uart interface for communication with something on your cape (i.e. which pins are used is already fixed) ? or do you want to connect something to the beaglebone in addition to the cape? Jan 23 21:49:44 I have to connect via uat to an external device while display is working Jan 23 21:49:51 *uart Jan 23 21:51:23 that doesn't really answer my question... is this lcd part of the cape (i.e. it is already connected to the beaglebone), or is it something you still need to connect? Jan 23 21:51:28 *this uart Jan 23 21:52:29 not already connected Jan 23 21:52:47 okay, yeah then you should pick uart pins that are not already in use by the cape Jan 23 21:53:15 are you even able to access any expansion headers while the cape is connected? does it have pass-through headers? Jan 23 21:54:17 ok I haven't yet checked if LCD7 pins leave a UART pair free... Jan 23 21:56:08 not a pass-through needed (I can weld tx and rx on free pins under that green pcb you've seen ) Jan 23 21:57:17 you probably mean "solder" rather than "weld" :) Jan 23 21:57:37 a question : how can multiple capes (dtbo) be enabled on uBoot.txt Jan 23 21:58:08 yes, I was asking myself the right verb to use.... Jan 23 22:00:26 both involve using heat to join two metals, but welding involves melting the materials you want to join Jan 23 22:01:24 like in carpentry... Jan 23 22:01:25 and you can use uboot_overlay_addr0-7 and dtb_overlay to enable up to 9 overlays Jan 23 22:04:04 I don't think welding is something that would normally be considered to be part of carpentry... Jan 23 22:04:25 I guess it could be in some cases Jan 23 22:07:28 ok , language issue.... carpentry here is intended as metal carpentry... Jan 23 22:08:30 I mainly associate the word with woodwork Jan 23 22:08:56 that in english language is ... Jan 23 22:09:55 try to search google-images between "carpentry" and "carpenteria" ... Jan 23 22:10:55 the first gives images of people working with wood, the second gives me images of some flower Jan 23 22:11:40 /13/13 Jan 23 22:11:44 ahaha Jan 23 22:12:50 google doesn't really give consistant results as it incorporates a lot of effort into figuring out who is asking Jan 23 22:13:47 mainly counrty... Jan 23 22:13:55 I get the same results in an incognito window, but I guess it may still be country-dependent Jan 23 22:13:58 *country Jan 23 22:18:10 Anyway.... just uncommenting #uboot_overlay_addr0=/lib/firmware/.dtbo and specifying right file name is enough to enable that cape ? Jan 23 22:28:28 that overlay you mean Jan 23 22:28:34 yes Jan 23 22:28:47 nice Jan 23 22:30:51 ok I'm almost sleeping over the keyboard...tomorrow I will dig into touchscreen calibration.... Jan 23 22:34:49 Hello! Jan 23 23:44:39 fred__tv: if you want your overlay source code a bit more readable and easier to understand and tweak, save https://pastebin.com/UYJJVrG6 as "lcd-cape.dtsi" (or whatever) inside a checkout of https://github.com/mvduin/overlay-utils and do "make lcd-cape.dtbo" Jan 23 23:46:53 it's the LCD7-01-00A2 overlay converted to the style used by my overlay-utils, reorganized, and with a few minor things fixed here and there Jan 23 23:47:16 of course I have no way to test it, so hopefully I didn't make any typos or other stupid mistakes ;) Jan 23 23:48:17 I've also added in some comments about the lcd panel configuration (copied from another dts I wrote) Jan 23 23:50:27 I was shutting down PC... thank you for overlay, also buttons and backlight etc would be removable as my cape isn't equipped with.. Jan 23 23:51:25 in the morning I will give it a try. Jan 23 23:51:27 yes I figured that Jan 23 23:51:35 Thanks Jan 23 23:51:42 but at least you'll have them as a reference Jan 23 23:51:53 of example snippets Jan 23 23:52:04 I figured you'd be sleeping by now and would see it in the morning ;) Jan 23 23:52:27 anyway, good night! Jan 23 23:53:07 yes, wake up in 5 hours.... :-(( Jan 23 23:53:09 bye Jan 24 02:07:25 how do i install the best image for beagleboard 15 Jan 24 02:09:15 https://beagleboard.org/latest-images Jan 24 02:09:26 https://beagleboard.org/getting-started#update **** ENDING LOGGING AT Thu Jan 24 02:59:56 2019