**** BEGIN LOGGING AT Fri Mar 15 02:59:57 2019 Mar 15 06:18:14 Hello Mar 15 06:19:06 i want to control gpio pin from web page. Mar 15 06:19:27 but my python file not exc in php. Mar 15 06:25:56 hello Mar 15 06:26:44 I want to control gpio pin from ewb page Mar 15 09:06:02 zmatt are you there ? I can't figure out where exactly to insert the node for infrared receiver into an exixsting dts Mar 15 09:06:24 do you have an existing _custom_ overlay? Mar 15 09:06:31 if not, make a new one Mar 15 09:06:41 don't stick it into a random overlay that isn't yours Mar 15 09:08:47 you can just grab my overlay-utils ( https://github.com/mvduin/overlay-utils ), make a file named e.g. ir-receiver.dtsi declaring the node (along the lines of https://pastebin.com/h9F6JG7Q ) and use "make ir-receiver.dtbo" to compile it Mar 15 09:13:08 I'm actually using the modified LCD7-A2 to fit my custom LCD Mar 15 09:13:25 oh right I keep forgetting that's you Mar 15 09:13:55 oh right I still needed to check why my version of the overlay didn't work Mar 15 09:14:09 I keep forgetting that too :$ Mar 15 09:14:14 It would be enugh a new dts and place the node as root node ? Mar 15 09:15:10 if you don't use overlay-utils you need to convert the fragment into the format needed for overlays (see https://pastebin.com/b8kZfhRG ) Mar 15 09:16:18 (be careful to give the fragment node a different name as the previous ones, typically accomplished by sequentially numbering them fragment@N ) Mar 15 09:16:49 (if you have only one fragment in the file that's not a concern of course) Mar 15 09:17:18 using overlay-utils for this overlay would be simplest Mar 15 09:17:28 that fragment thing is were I was stuck into.... Mar 15 09:17:42 that's exactly why overlay-utils exists ;) Mar 15 09:17:43 I'll go for overlay-utils and new overlay Mar 15 09:18:51 just received a call for outside maintenance, have to go Mar 15 09:19:03 I'll try after lunch Mar 15 12:53:36 what pin is gpios = <&gpio0 19 1>; referring to ? Mar 15 13:17:04 fred__tv: not one that's valid on the beaglebone :P Mar 15 13:17:42 gpio 0.19 corresponds to the processor pin that's used as 24 MHz clock output for the HDMI framer Mar 15 13:18:57 you can find gpio numbers for expansion header pins in my spreadsheet ( https://goo.gl/Jkcg0w ) or in the comments in the file include/bone/pins.h in overlay-utils Mar 15 13:20:02 that last "1" means ACTIVE_LOW. I recommend you #include "gpio.h" and use the ACTIVE_LOW or ACTIVE_HIGH constant Mar 15 13:39:20 it seemed a strange value.... so for P9_24 gpio0[15] Mar 15 13:47:04 so, I'm ended in a ir-receiver.dtsi like this : https://pastebin.com/JxR62HBc Mar 15 13:53:25 fred__tv: there's no reason to label the node ("ir:") Mar 15 13:53:49 if you want to do it *completely* proper, you'd also include pinmux setup like this: https://pastebin.com/2fSgJVqk Mar 15 13:54:29 (this is not strictly required since you're using the pin as gpio, which is the default pinmux setting anyway, but it's better to set it explicitly) Mar 15 13:56:21 IR receiver has already an internal pullup Mar 15 13:56:27 any difference ? Mar 15 13:56:58 then you can use _PULLUP or _NOPULL, doesn't really matter Mar 15 13:57:30 trying... Mar 15 13:58:22 I'd suggest leaving pull enabled to ensure the pin won't float even if you don't have the receiver connected Mar 15 14:02:40 beagle doesn't even start... Mar 15 14:03:10 can you pastebin the source of your dtsi ? Mar 15 14:03:33 your last pastebin Mar 15 14:03:41 a silly typo is sufficient to make u-boot unable to apply the overlay, and it indicates this problem by not booting at all -.- Mar 15 14:03:57 hmm Mar 15 14:04:22 I don't immediately see any silly typo Mar 15 14:04:56 if you have a serial console cable you can check u-boot's output Mar 15 14:05:42 unfortunately not Mar 15 14:06:28 it's really useful to have one whenever you do anything with DT customization (or kernel or u-boot customization obviously) Mar 15 14:06:42 debugging boot issues while blind is no fun Mar 15 14:07:23 it's a white , does it have seral console ? that header close to eth connector ? Mar 15 14:07:37 ah right, I forget you have a white Mar 15 14:07:40 the white has one integrated Mar 15 14:07:49 so the serial console shows up if you have it connected via usb Mar 15 14:09:51 the white has an integrated usb hub with the processor on one downstream port and the other downstream port is used for an ftdi usb-serial chip that connects to jtag (port A) and the serial console (port B) Mar 15 14:15:38 really, I have a serialconsole cable as intended usb-ttl for BBB, Mar 15 14:16:22 ehh, but earlier you said you didn't? Mar 15 14:16:27 regardless, the white doesn't need one Mar 15 14:16:28 what about the white ? should I connect the mini-usb to a PC and expect to be seen as serial interface to be managed with a terminal ? Mar 15 14:16:37 yes Mar 15 14:17:01 just realized what really the serial console cable for BBB is... ;-)) Mar 15 14:17:27 also a win pc ? Mar 15 14:18:41 windows may require driver installation. if it doesn't happen automatically, see https://www.ftdichip.com/Drivers/VCP.htm Mar 15 14:25:40 got it Mar 15 14:25:54 what serial speed ? Mar 15 14:25:58 115200 Mar 15 14:26:56 great , now let's see what happens Mar 15 14:30:24 https://pastebin.com/XwAAF9yL Mar 15 14:31:07 wtf Mar 15 14:31:13 oh Mar 15 14:31:20 failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY Mar 15 14:31:30 thanks u-boot, that's really informative Mar 15 14:31:30 seen Mar 15 14:32:28 base fdt does did not have a /__symbols__ node Mar 15 14:32:28 make sure you've compiled with -@ Mar 15 14:32:41 yeah no, all errors after the first one are bogus Mar 15 14:33:04 it looks like failing to apply the DT causes it to lose the DT entirely or something Mar 15 14:34:52 (those messages were the cause of my "< zmatt> wtf", and then "< zmatt> oh" was when I saw the FDT_ERR_BADOVERLAY and realizes the rest was nonsense) Mar 15 14:35:01 *realized Mar 15 14:37:40 can you try this variation: https://pastebin.com/SNM99g3q Mar 15 14:37:50 (i.e. I've just swapped the two fragments) Mar 15 14:40:22 same error Mar 15 14:40:31 :/ what is going on here Mar 15 14:51:50 I really don't get it. I've also checked the compiled overlay, and it really looks fine to me Mar 15 14:56:06 I have to get back to work. I'll look into this tonight Mar 15 15:00:29 ok no problem Mar 15 15:09:51 just gone with this: https://pastebin.com/yiUuMQ5J Mar 15 15:10:08 . /dev/lirc0 is created Mar 15 15:10:59 so that does work? hm Mar 15 15:11:14 so something with the pinmux declaration/reference Mar 15 15:13:09 how can I very basically read from lirc0 to see if it receives something ? Mar 15 15:13:29 no clue, I don't know anything about lirc Mar 15 15:17:26 m Mar 15 16:37:47 Hi, is there a way to read core temperature on BBB? something similar to lm-sensors? Mar 15 16:49:17 td-kros: there was in 3.8.x, ti hardware people said it was to un-reliable, so it never went upstream... zmatt, any thoughts on just forward porting the 3.8.x temperature patch? Mar 15 16:51:36 the bandgap sensor? isn't that thing known to be extremely inaccurate? Mar 15 16:52:00 right, this could be quite useful, I'm using octavo osd335x-sm, it may get quite hot Mar 15 16:52:25 yeap the "dev/random" bandgap sensor.. Mar 15 16:52:29 lol Mar 15 16:52:52 td-kros: how do you intend to calibrate it? Mar 15 16:53:29 no calibration, just can't touch it for >2s ;-) Mar 15 16:53:51 td-kros: here's the old driver: https://github.com/beagleboard/linux/blob/3.8/drivers/hwmon/am335x-bandgap.c but like zmatt says, how do you plan to reference it's value.. Mar 15 16:54:06 apparently it has an accuracy of "±10.8°C" Mar 15 16:54:19 and TI support says "The AM335X built-in bandgap sensor has no use for end customers, it's used in factory and test measurements. Mar 15 16:54:22 " Mar 15 16:54:23 right, that's not good, indeed Mar 15 16:55:17 okay, I understand, in this case probably external temperature sensor will be more useful Mar 15 16:56:38 it would have been convenient if octavo had integrated one Mar 15 16:59:01 yes, indeed. Thanks for info, we'll have to add temperature sensor Mar 15 17:00:15 whenever am335x thermal stuff is mentioned I'm reminded of the E2E post from someone who had some "thermal issues", including "smoke and flame" coming from the SoC Mar 15 17:03:43 do you have link to this post? I wonder if they found what caused this Mar 15 17:04:10 I don't recall the thread being informative Mar 15 17:04:51 they were using it in a high temperature environment (like 90 ͏°C or something) iirc, so that probably didn't help Mar 15 17:07:23 okay, no plands for so high temperatures for now. Mar 15 18:23:38 <__ikki__> I want to test a kernel module which already has support in the kernel version I'm running. If I download the kernel source code for the specific version and compile+insmod the driver, then would it work ? Is this approach advisable ? Mar 15 18:24:23 __ikki__: I wouldn't recommend that Mar 15 18:24:36 <__ikki__> I plan to download it from here: https://github.com/beagleboard/linux/releases/tag/4.19.9-ti-r5 Mar 15 18:24:38 especially since it's really easy to just build a new kernel package with custom config Mar 15 18:24:58 <__ikki__> zmatt: Oh, what do you recommend then ? Mar 15 18:25:00 https://pastebin.com/raw/eLhrp1Hg Mar 15 18:25:42 so in your case you'd use the ti-linux-4.19.y branch of the ti-linux-kernel-dev repository Mar 15 18:27:53 (on your host system of course, I wouldn't try to compile a kernel on the beaglebone itself) Mar 15 18:32:33 <__ikki__> zmatt: Where is system.sh ? Mar 15 18:33:05 see third line of my pastebin Mar 15 18:33:35 <__ikki__> zmatt: That's exactly what I wonder when I read the 3rd line Mar 15 18:34:01 <__ikki__> Do we need to create a new system.sh with our "taste" ? Mar 15 18:34:33 that's what it says: you "cp system.sh.sample system.sh" and then modify it to taste Mar 15 18:34:58 since system.sh.sample is an example for system.sh :P Mar 15 18:36:20 I think the minimum you need to do is set the 'CC' variable Mar 15 18:36:23 <__ikki__> zmatt: Yeah, I'm stupid. Hehe. Mar 15 18:36:54 or maybe it would autodetect even that, not sure. I do have it set explicitly Mar 15 18:37:01 <__ikki__> Last question: Any refernce to write a dt-overlay for a spi slave ? Mar 15 18:37:31 I have an overlay-utils project which aims to make overlays easier to read and write Mar 15 18:37:38 https://github.com/mvduin/overlay-utils Mar 15 18:37:42 it includes spi examples Mar 15 18:37:52 https://github.com/mvduin/overlay-utils/blob/master/spi0.dtsi Mar 15 18:39:45 <__ikki__> Wow! Great, thanks zmatt Mar 15 18:40:02 <__ikki__> I was literally struggling with pinctrl Mar 15 18:41:11 <__ikki__> So, in spi0.dts I will change the chip@0 node to my slave sensor node ? Mar 15 18:41:24 yes Mar 15 18:42:49 <__ikki__> zmatt: how do I use it after tweaking the .dtsi ? Mar 15 18:43:12 make name-of-file.dtbo Mar 15 18:43:40 <__ikki__> ok. Then cp to /lib/firmware/ ? Mar 15 18:43:43 yeah Mar 15 18:44:09 <__ikki__> And then add it u-boot overlay in uEnvt.txt ? Mar 15 18:44:10 the enable in /boot/uEnv.txt, reboot, and pray it still boots Mar 15 18:44:31 (u-boot signals any issues with applying an overlay by failing to boot entirely) Mar 15 18:45:02 <__ikki__> zmatt: I came to know capemgr is deprecated and we should u-boot overlays ? Mar 15 18:45:13 <__ikki__> *use Mar 15 18:45:30 yes, u-boot overlays has been the default for quite a while now already Mar 15 18:58:38 <__ikki__> zmatt: Following your kernel building instruction, I would get a .deb package at the end ? Mar 15 18:59:03 I am a newbie for the beaglebone black wireless. I have two questions about bbbw. 1 - the 2 antennas that are on the bbbw board now are omni directional or if they are directional ? 2 - How to turn off the two antennas? I want to use new antennas via usb. Mar 15 19:01:59 like most antennae they're not very directional but not quite omnidirectional Mar 15 19:03:00 and you got a beaglebone black wireless but don't want to use its wireless? o.O Mar 15 19:06:14 they're close to omnidirectional though Mar 15 19:09:02 to Zmatt: Yes, we will use better antennas on the board. Do you know how to turn off the antenna? Mar 15 19:10:33 if you just want to use better antennas, you can attach better antennas Mar 15 19:11:14 that's not the same thing as disabling the wifi/bluetooth module entirely and attaching an usb wifi device Mar 15 19:12:10 if you don't want to use the on-board wifi you'd probably be better off with a regular beaglebone black instead of a beaglebone black wireless, but you can probably also disable it using rfkill Mar 15 19:12:42 having been away from bbb for about 6 years i was pleasantly surprised how easy it is now to make wifi work Mar 15 19:12:50 wifi with external usb dongle Mar 15 19:13:00 to zmatt: You means that We just use the new antennas and don't need to take care of the orginal antennas? Mar 15 19:13:28 Rickta59: well people have quite varied results Mar 15 19:13:50 Jacky__ they are attached to a common connector, just grab new antennas and replace the existing connections.. Mar 15 19:13:56 Jacky__: you can detach the antennas and connect different ones (provided they use the same connector) Mar 15 19:14:11 i plugged in the one I had back then, which I had to compile a customer driver module for, used connmanclt and bingo bango working Mar 15 19:14:26 granted I'm only using it as a dhcp client Mar 15 19:14:41 Rickta59: "compile a custom driver" would not be among most people's idea of "pleasantly surprised how easy it is" Mar 15 19:14:57 right that was 6 years ago .. now it is part of debian Mar 15 19:15:10 no custom driver required Mar 15 19:15:11 Rickta59, some of that might be we better understand noise emissions, and have the jtag clock, cec clock DISLABED, so they don't interfere with the wifi radio.. Mar 15 19:15:11 ah Mar 15 19:15:26 back then it was angstrom crap Mar 15 19:15:33 to Zmatt: Got it. You means I can remove the old antennas and detache the new on the same place. Mar 15 19:15:53 yeah, as long as they have an u.fl connector Mar 15 19:16:24 Thank you. Mar 15 19:37:32 Rickta59: wifi usb sticks are kinda hit-and-miss though. even if a certain stick is known to work, if you later buy another one of the same brand and model number, it might actually turn out to contain a different chip that's not supported on linux Mar 15 19:38:07 sure i picked one that I knew worked with raspberry pi and then tried to make it work with the bbb Mar 15 19:38:18 yeah if it works on the rpi it should work on the bbb Mar 15 19:38:19 and the pain part was angstrom Mar 15 19:38:32 now i'm using debian so life is more consistent Mar 15 19:38:42 yeah I've never dealt with angstrom Mar 15 19:38:58 the yotoco thing .. was such a p-i-t-a Mar 15 19:39:27 main reason i stopped begleboning Mar 15 19:39:58 however there always seems to be a wet paint issue with bbb Mar 15 19:40:01 beaglebones Mar 15 19:40:18 lol, "wet paint issue" ? Mar 15 19:40:21 i guess if I had come back when there was no remoteproc i would have been happy Mar 15 19:40:34 you can still happily ignore remoteproc if you want to Mar 15 19:40:34 but i jumped back in again where there is still transisiton Mar 15 19:40:44 I definitely do :D Mar 15 19:40:57 well doesn't that make life more difficult with using u-boot overlays? Mar 15 19:41:02 or am I confused? Mar 15 19:41:03 no Mar 15 19:41:18 you can switch between the two by commenting out one line in /boot/uEnv.txt and uncommenting another Mar 15 19:41:21 i thought you had to turn off u-boot overlays to use uio Mar 15 19:41:24 no Mar 15 19:42:17 maybe i misread that section ... let me find what I read Mar 15 19:42:35 you simply set uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo in /boot/uEnv.txt (instead of pointing it to the RPROC overlay for your kernel series) Mar 15 19:42:38 that's it Mar 15 19:42:55 see also the readme of my https://github.com/mvduin/py-uio project Mar 15 19:43:26 so remoteproc-pru and uio-pruss are equally easy to enable (in fact uio-pruss is easier since it has the same overlay for all kernel versions) Mar 15 19:44:10 ok i guess i misread that Mar 15 19:45:58 so there's no need to feel any pressure whatsoever to use remoteproc-pru yet Mar 15 19:46:00 so the 5 cent difference between uio and remoteproc .. uio i have to write a user side app to load the pru code and the remoteproc I use system utils? Mar 15 19:46:27 and the code has to be linked differently for uio and remoteproc? Mar 15 19:46:57 remoteproc can only load ELF executables. the old libprussdrv can only load raw binaries. my py-uio library can load both Mar 15 19:47:11 k Mar 15 19:47:26 (a better C/C++ lib for uio-pruss is still on my to-do list) Mar 15 19:47:53 so the uio stuff you have to embedded a resource table instead of having it in a .elf section? Mar 15 19:48:05 it has no resource table Mar 15 19:48:25 (my ELF loader also doesn't support a resource table yet, that's still work in progress) Mar 15 19:48:38 what do you use the resource table for? Mar 15 19:48:55 i read about that in the complier clpru crap Mar 15 19:49:03 i think the c compiler uses it Mar 15 19:49:13 it doesn't, you have to manually declare one if you want one Mar 15 19:49:37 so it is only using the .text section to figure out what to load into the pru instruction memory? Mar 15 19:49:45 https://github.com/jadonk/pru-software-support-package/blob/master/examples/PRU_gpioToggle/resource_table_empty.h#L118-L122 Mar 15 19:49:50 that's a resource table Mar 15 19:49:52 (an empty one) Mar 15 19:50:22 my ELF loader supports loading both code and data segments Mar 15 19:51:18 can can i use the clpru compiler for uio? Mar 15 19:51:34 or is uio happier with only asm Mar 15 19:51:57 uio itself doesn't care whatsoever since when using uio-pruss, loading code into pruss is done by userspace. Mar 15 19:52:33 like I said, the old libprussdrv only supports raw binaries (as produced by pasm), but py-uio supports loading ELF executables produced by clpru, and includes an example of that Mar 15 19:52:47 https://github.com/mvduin/py-uio/blob/master/pru-examples/elf-test.py Mar 15 19:53:07 https://github.com/mvduin/py-uio/tree/master/pru-examples/fw-c (corresponding pru firmware) Mar 15 19:53:15 ok .. i'll have to look at all this stuff thanks Mar 15 19:53:39 ew why didn't I mark that variable as volatile Mar 15 19:54:47 inefficient compiler helping you ? : ) Mar 15 19:55:26 also I should use __halt() instead of inline assembly Mar 15 19:58:10 there, pushed **** ENDING LOGGING AT Sat Mar 16 02:59:57 2019