**** BEGIN LOGGING AT Tue Oct 22 03:00:24 2019 Oct 22 08:46:09 Hi all, I m lorant, I need some help. I bought Beagleboard X15 with Sitara AM5728. I would like run code on IPU core cortex M-4. I bought from TI XDS110 debug probe and tried uploa to core example project from Code Composer Studio. It s worked but I would like to load it from Linux at runtime. please help how to because dosnt work for me. I using Oct 22 08:46:09 Beagleboard debian. thank you Oct 22 10:48:37 that is a good question **** BEGIN LOGGING AT Tue Oct 22 12:35:16 2019 Oct 22 14:48:38 m Oct 22 15:31:49 The BB AI is getting so hot the kernel terminates Oct 22 15:32:00 Anyone else have this? Oct 22 15:32:07 Running latest 4.19 Oct 22 15:32:45 The heatsink it shipped with has screws that look like they accept a fan--I see in the FAQ the part number. But I'm not even doing anything with it other than basic system maintenance and installing packages at this point Oct 22 15:32:59 hmm sounds like cpu scaling is .. not working .. Oct 22 15:33:04 I also found a forum link where someone is using a 'better' sink Oct 22 15:33:28 veremitz I can check something if its helpful Oct 22 15:33:39 I have the device 'resting' right now but I can boot it back up Oct 22 15:34:17 I'm not sure whats the best thing to test, but someone else will likely pop up soon :) Oct 22 15:34:34 there's a few gurus that come and go Oct 22 15:41:58 I just set the governor to "conservative" from "performance" which I think it shipped with and it is still quite hot to the touch Oct 22 15:42:14 not sure there is a way to actually get temperature--lm-sensors doesn't see anything Oct 22 15:55:51 after booting im getting around 59C and it is gradually climbing to low 60s. I turned it off. But earlier during updating initramfs I did get a 85C kernel shutdown Oct 22 18:09:05 is there a kernel that is considered stable for the BB AI? Oct 22 18:09:19 the --stable commandline option doesn't seem to activate any of the kernels Oct 22 18:09:27 (for update_kernel) Oct 22 18:10:51 the 4.14-ti series is the stable series afaik Oct 22 18:17:38 good to know Oct 22 18:35:28 hmm that kernel seems to run hotter Oct 22 18:35:37 got up to 80C pretty fast Oct 22 18:37:48 I don't know how to evaluate heat sinks. They never come with any kind of actual specification Oct 22 18:52:10 I think the only thing to compare realistically is surface area and maybe base material Oct 22 19:29:32 hays: hmm, the AI already comes with a heatsink right? it just needs a fan Oct 22 19:29:38 (to get better cooling) Oct 22 19:30:17 yeah, the FAQ mentions a fan. I think that complicates things quite a bit--now I need to power the fan and make sure it fits in the case Oct 22 19:31:02 I found a heat sink with longer fins and more of them. hoping that will get more heat out Oct 22 19:31:08 I've never understood why people would put a beaglebone in a case... I generally want unrestricted access to the expansion headers. at most I've given some beaglebones little "feet" Oct 22 19:31:20 a case would probably also not help with keeping it cool Oct 22 19:31:39 unless you mean the case of a product in which it's embedded Oct 22 19:32:09 yep Oct 22 19:35:27 I like them in a simple case for development also to give them just a little protection Oct 22 19:36:00 there are enough aluminum flat surfaces around my desk that its better to just have it enclosed Oct 22 19:36:18 I do wonder how much variability there between am572x units in terms of heat production... there have been a few people here with thermal issues, but actually not that many Oct 22 19:36:44 also, you said it shuts down at 85 degrees? that sounds to me like the limit is set too low, it's rated at 90 degrees Oct 22 19:37:36 ive seen similar on two units Oct 22 19:37:42 haven't checked the third Oct 22 19:37:53 I mean it'll depend on the kernel, not on the unit Oct 22 19:37:56 board rev A1 Oct 22 19:38:07 oh I meant temperature issues Oct 22 19:38:43 im not changing the kernel just running the stock. I did put it back on 4.19 though because with 4.14 it seemed to be getting super hot for some reason Oct 22 19:39:12 oh is 4.19 the default for the x15/bbai currently? ok, my bad Oct 22 19:39:27 I actually don't remember--it was a while back Oct 22 19:39:40 but I chose a buster image, and I think 4.19 aligns with that generally speaking at least Oct 22 19:40:26 ok so you're using a testing image rather than the "recommended" image (this is not necessarily a bad thing but it's good to know) Oct 22 19:41:02 it sounds to me like the main issue is that it's not throttling when it starts to get too hot, and shuts down at too low tempereature Oct 22 19:43:29 maybe that was unwise. had an eye to the future--figuring 10 would be released soon Oct 22 19:43:57 well stretch vs buster shouldn't really impact this Oct 22 19:44:06 just the kernel does Oct 22 19:44:17 brb Oct 22 19:47:04 zmatt: what is the tolerance on those numbers? Oct 22 19:55:26 if the sensor is 85 +/- 5 deg and the spec is 90 +0,-5... I assume the sensor is just a diode or a B-E junction Oct 22 19:56:47 i think it would be weird to have a spec with a tolerance Oct 22 19:57:10 but agree the sensor might have 5C error Oct 22 19:57:31 specs ALWAYS must have a tolerance Oct 22 19:57:33 there also may be margin to allow for shutdown before it gets above 90C Oct 22 19:57:37 otherwise, it is meaningless Oct 22 19:58:11 I guess I mean to say a thermal limit with a tolerance Oct 22 19:58:21 seems unusual Oct 22 19:58:25 even that has a tolerance Oct 22 19:58:47 right, but the published number is a limit Oct 22 19:59:02 yes but you are matching it against a measurement Oct 22 19:59:11 If the limit is 85C-95C, theyd publish a limit of 85C Oct 22 19:59:16 look at drawings, those have tolerances on every call out Oct 22 20:00:54 if you are calling out 85C +/-0, then the temp sensor needs to trigger at 85C - lower tolerance of sensor Oct 22 20:01:50 where would the temperature sensor trigger if the limit was 85C-95C Oct 22 20:01:56 IIRC - the P/N junctions are very rough temp sensors...getting them more precise require controlling hte dopants Oct 22 20:02:20 i am not taking issue with the idea of a sensor having an accuracy Oct 22 20:02:30 that is same as saying 90C +/-5 - so you can take a +/-5 sensor and have it trip at 90 Oct 22 20:02:47 the other problem is WHERE is that temp call out for Oct 22 20:03:13 I have never seen limit mathematics done that way. What if the limit was 90C+/-100C? Oct 22 20:04:06 it comes down to how well can they control the process Oct 22 20:04:16 are you saying that you have to back out the actual limit from the tolerance? that its a limit-as-measured-by-sensor-with-tolerance-X? Oct 22 20:04:18 and how long do the part need to last Oct 22 20:05:18 I suspect if TI is packaging the temperature sensor with the chip, they tell you the limit as read by that chip in the datasheet Oct 22 20:05:20 look at it another way - that limit is the result of 2 factors - how long the part needs to last and how well is the process controlled... things like doping concentrations impact what temperature it can run at Oct 22 20:05:49 doping can be controlled up to a point...that in turn gives you a range of temperatures it can tolerate Oct 22 20:06:38 if TI called it out in terms of the temp sensor, then that isn't a temperature limit; it is just a threshold on the sensor Oct 22 20:12:52 oops, dropped off Oct 22 20:16:24 the answer looks complicated http://processors.wiki.ti.com/index.php/AM335x_Thermal_Considerations Oct 22 20:17:03 I think the chip you are referring to may have accuracy of 10.8C, and they recommend instead using an external sensor of board temperature and a correlation with power Oct 22 20:22:25 hays: note that the BBAI has an am572x, not an am335x Oct 22 20:25:28 ds2: fair, I don't know the answer to that. of course the 90 degrees isn't a hard limit either, it's just part of the Power-on hours (100k hours of continuous operation at OPP_NOM or OPP_OD with HDMI at max bitrate and a junction temperature of 90 degC) Oct 22 20:25:46 (65k hours at OPP_HIGH) Oct 22 20:40:25 trip_point_temp in kernel 4.14 seems to be 85C. there's one that's 55C not sure about that one Oct 22 20:41:31 its a 'passive' trip point Oct 22 20:42:45 passive in thermal management generally means cooling by reducing power consumption (i.e. cpu throttling) Oct 22 20:43:00 versus active which would mean turning on a fan Oct 22 20:43:14 so maybe that's when it begins throttling Oct 22 20:43:26 except you said it shut down Oct 22 20:43:33 right now I seem to be stable at 64C about Oct 22 20:43:43 oh nm Oct 22 20:43:45 I misread Oct 22 20:43:45 yeah I got a kernel message that it shut down at 85C Oct 22 20:44:11 there are 5 thermal zones--one of them has a passive limit, but all of them have a critical limit at 85C Oct 22 20:44:32 not sure where those are set or fully understand the basis Oct 22 20:45:48 my guess would be they're from DT Oct 22 20:46:19 yeah. are those on the image anywhere Oct 22 20:46:29 or just compiled as dtb? Oct 22 20:47:51 the dt sources? they may be on the device somewhere in /opt, if not then you can grab 'em from github. the primary repository for them is the kernel tree, but a more convenient repo for rebuilding them is https://github.com/beagleboard/BeagleBoard-DeviceTrees (which is apparently the replacement for dtb-rebuilder) Oct 22 20:50:22 am5729-beagleboneai.dts Oct 22 20:50:33 yup Oct 22 20:50:45 be sure to pick the right branch based on kernel version Oct 22 20:50:50 interestingly its 90000 in there Oct 22 20:51:27 not sure how these map to the thermal zones though Oct 22 20:52:19 where are you seeing that value? Oct 22 20:53:05 looks like the critical was raised from 80 to 85 and throttling lowered from 65 to 55 => https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/4d447957cb82 Oct 22 20:59:26 in /opt/sources Oct 22 20:59:33 but I am decompiling the actual dtb now Oct 22 21:01:30 yeah.. its showing it in hex 0x14c08 Oct 22 21:06:23 I have tried to connect 2 BBB to a single Windows-10 computer. They both connected over usb and Ethernet. Eth0 inet5 addresses are different (as expected). But usb0 and usb1 addresses are the same for 2 BBB: 192.168.7.2 and 192.168.6.2. Also the hostname is the same: beaglebone. Is that expected? Oct 22 21:09:34 dreamhiker: yes, why would you expect anything else? Oct 22 21:10:19 for the usb networking the beaglebone is the DHCP server hence it has a statically configured IP address Oct 22 21:12:05 giving each beaglebone its own hostname is something you'll have to do yourself Oct 22 21:13:05 Thanks! Can I change the usb ip address? Oct 22 21:13:39 I do have a setup with multiple beaglebones connected via usb, but I've configured that very differently: each beaglebone is a dhcp client for usb networking and the computer they're connected is configured to tie all usb networking interfaces along with the ethernet interface together via bridging, so the dhcp requests from the beaglebones will be answered by the dhcp server on the ethernet network Oct 22 21:15:32 Thanks! Do you have a how-to description for what you have done? Oct 22 21:15:40 I'm sure it can be changed somewhere, though I'm not sure where it's configured.... iirc usb networking is setup by some giant startup script instead of being handled by the network manager (though if it were handled by the network manager I still wouldn't know where to change it since I don't use connman) Oct 22 21:16:13 it's pretty easy to setup with systemd-networkd, which is what I use on both beaglebones and the server those beaglebones were connected to Oct 22 21:16:21 lemme see what I did Oct 22 21:23:14 Thanks! Oct 22 21:23:18 this is the host side: https://pastebin.com/gW6RHtLx (overriding the MAC addresses like this is optional but something I did to ensure this machine still used the same MAC address as it did before I set up bridging, so it would be recognized by the DHCP server) Oct 22 21:28:58 on the beaglebone I just added g_ether to /etc/modules and one systemd-networkd config file: https://pastebin.com/7cs1pHrR (in addition to the one for wifi since this is a beaglebone black wireless) Oct 22 21:29:29 Thanks! Oct 22 21:40:10 zmatt: yes, the power on hours == how long it needs to last Oct 22 21:41:16 some estimate thereof yes Oct 22 21:47:55 hopefully a worse case estimate (max temp/max clock/etc) Oct 22 21:48:16 anything lower then melting the bond wire should work for short periods of time Oct 22 21:48:37 s/bond wire/bond wire and solder/ Oct 22 21:57:41 what's the lowest freq supported on the am57x's Cortex-A? Oct 22 21:58:08 I don't think it has a specific lower limit Oct 22 21:58:26 seems like cpufreq only allows a lower limit of 1GHz Oct 22 21:58:31 seems a bit high Oct 22 21:59:00 a 500 MHz option should be available, I saw in the DT it was added Oct 22 21:59:14 not in the shipped image Oct 22 21:59:24 though I don't know the relative effectiveness of lowering the frequency versus inserting idle time Oct 22 21:59:56 if lowering the frequency doesn't permit lowering the voltage then it may not be a very effective power management strategy Oct 22 22:00:17 stopping one core does seem to help a bit Oct 22 22:00:26 I can hold my finger on the heatsink for 5 seconds now :D Oct 22 22:00:51 (either that or the previous settings burnt off the nerves) Oct 22 22:00:56 lol Oct 22 22:02:51 keystone is the am57 isn't it? Oct 22 22:02:56 nope Oct 22 22:03:15 am57xx is omap5-derived, keystone is C6x DSP derived, very different SoC architecture Oct 22 22:03:30 the am57 contains keystone doesn't it? Oct 22 22:03:55 trying to sort on package names Oct 22 22:04:08 no it contains a C6x DSP subsystem but that doesn't make it architecturally anything like a keystone Oct 22 22:04:25 it's more like the counterpart of sticking ARM cores into a keystone (which in fact they have) Oct 22 22:04:45 let see what happens then... there is an opencl package for keystone from RCN Oct 22 22:05:18 unless it is really badly named I would assume it to be inapplicable Oct 22 22:05:57 that apparently satisfies the demo build... so the badly named part may be right :D Oct 22 22:07:06 the AM65xx are keystones as is the upcoming AM752x Oct 22 22:07:09 no thermal throttling just yet Oct 22 22:07:36 I suspect the AM57xx series may be the last omap-derived SoCs Oct 22 22:08:02 seeing how omap is 'dead' :D Oct 22 22:08:37 it never died.. just renamed.. Oct 22 22:08:57 ah the ownwer of the repo Oct 22 22:09:36 rcn-ee[m]: well it does seem like TI is focussing on keystone SoCs instead Oct 22 22:09:38 rnc-ee[m]: is https://github.com/rcn-ee/tidl-api suppose to still work? Oct 22 22:09:45 for the near-future SoCs anyway Oct 22 22:10:21 yeah whatever automotive sector they stick it in.. Oct 22 22:10:49 Keystone also has a weird boot memory start, along with it's own mach-keystone in linux.. Oct 22 22:11:28 ds2: define work. ;) https://github.com/rcn-ee/tidl-api/tree/v01.02.02-bb.org is what we ship in "Stretch"... Oct 22 22:11:49 rcn-ee[m]: does "Stretch" ship as the factory image? Oct 22 22:12:23 ds2: yeap.. ps the lxqt-tidl has everything setup: https://rcn-ee.net/rootfs/bb.org/testing/2019-10-21/stretch-lxqt-tidl/ Oct 22 22:12:27 rcn-ee[m]: work as in compile. the updated README in jason's image isn't accurate... I had to blindly install a handful of other packages Oct 22 22:12:41 i still need to port the ti-opencl layer to buster/etc.. Oct 22 22:13:25 ds2: you need to 'build' the examples under /usr/share/ti/tild.../ but the api is built and installed.. Oct 22 22:13:45 zmatt: I'm trying to get your bbx15-spi-test in py-uio working on the BBAI and I've modified the .dtsi file to work with the BBAI (at least I've tried to) : https://pastebin.com/raw/z6vzRcgK Oct 22 22:13:54 rcn-ee[m]: do I want blank or or -debian if I want to run from uSD? Oct 22 22:14:10 ds2: blank = flasher.. ;) Oct 22 22:14:13 the factory image cannot build usr/share/ti due to missing headers Oct 22 22:14:20 so blank == eMMC-flaster? Oct 22 22:14:26 zmatt: when I run the example though I'm getting FileNotFoundError: [Errno 2] No such file or directory: '/dev/spidev3.1' Oct 22 22:14:57 hunter2018[m]: check kernel log? Oct 22 22:15:37 ds2: the factory image, wasn't 100% ready for the tidl.. ps, maybe the examples built, looking the ti-tidl build log: http://gfnd.rcn-ee.org:81/farm/outgoing/stretch/armhf/ti-tidl_01.02.02-bb.org-0.2-0rcnee3/ti-tidl_01.02.02-bb.org-0.2-0rcnee3~stretch+20190924_armhf.build Oct 22 22:15:57 hunter2018[m]: did you ensure the pins are not taken by the monstrous cape_default_pins ? Oct 22 22:16:23 rcn-ee[m]: I'd think apt update; apt upgrade should fix that, shouldn't it? Oct 22 22:17:04 all I want is a demo that will run a classifer from the commandline against a jpg/png/bmp/ppm/pbm/etc Oct 22 22:17:08 ds2: no... you need to run the kernel update script too.. that'll pull in the cmem-module, etc.. Oct 22 22:17:18 ah Oct 22 22:17:46 sigh Oct 22 22:17:56 i run out of memory building the demo on the board Oct 22 22:18:03 zmatt: Shoot, I forgot to override the cape_default_pins, could the /dev/spidev3.1 not show up because of this? Oct 22 22:18:04 or at least the API Oct 22 22:18:31 hunter2018[m]: if pins for the device are in use then it'll fail to probe yes Oct 22 22:19:28 ds2: yeah, it takes some ummph to build Oct 22 22:20:12 I hope the default pinmux gets moved into u-boot soon so this cape_default_pins hack can be removed Oct 22 22:20:39 since it's pretty annoying Oct 22 22:22:23 zmatt: here's my kern.log file: https://pastebin.com/raw/p4fkvdXx I'm not really sure what I'm looking for though... Oct 22 22:22:34 you can also create an empty cape_default_pins node and it'll nuke it.. Oct 22 22:23:05 rcn-ee[m]: sure but it shouldn't exist in the first place Oct 22 22:23:20 What will the default start states of the other pins be if you nuke it? Oct 22 22:23:26 whatever u-boot has configured Oct 22 22:23:36 (which is where these defaults belong) Oct 22 22:24:05 hunter2018[m]: ehhhh, something going very wrong Oct 22 22:24:13 hunter2018[m]: I see a big traceback Oct 22 22:24:49 caused by a bus error Oct 22 22:25:33 so that's not great Oct 22 22:26:25 lol, showing a traceback is completely pointless though since the cortex-a15 isn't even the initiator that caused the bus error Oct 22 22:27:09 whatever firmware was loaded onto the EVEs tried to access the L4_PER3 interconnect while linux had clock-gated those it seems Oct 22 22:27:26 anyway, that isn't related to your spi problem Oct 22 22:27:55 not seeing any spi-related log messages though, that's odd Oct 22 22:42:57 Where are you looking in the file? There is a lot in there... Oct 22 22:43:20 I just searched for spi Oct 22 22:44:26 it's really weird that nothing is showing up (other than the kernel module being listed in the errors dumped by the omap_l3_noc driver) Oct 22 22:44:35 is there anything in /sys/class/spi_master/ ? Oct 22 22:47:25 oh fun, off-by-one issues Oct 22 22:48:27 or not? hmm I'm confused Oct 22 22:49:06 zmatt: here is my .dtsi file that overwrites the cape_pins_default https://pastebin.com/raw/nXLeJGVq Oct 22 22:49:06 oh worse, there are no aliases for the mcspi instances in dra7.dtsi Oct 22 22:49:13 zmatt: No, there is nothing in my /sys/class/spi_master/ Oct 22 22:49:28 that's very strange Oct 22 22:49:37 so no error but not showing up either Oct 22 22:49:42 ehm Oct 22 22:50:00 s9 Oct 22 22:50:40 i hate g++ so very much Oct 22 22:51:15 I do see 5V pins on BBB. Somehow I was thinking that only 3.3V can be used. Is there any reason not to use 5V pins? Oct 22 22:51:39 dreamhiker: it is powered by 5V, it does not have 5V-tolerant I/O Oct 22 22:52:03 (it needs 5V e.g. for USB and HDMI) Oct 22 22:52:54 hunter2018[m]: just curious, does /proc/device-tree/aliases/spi3 exist for you and if so does it contain /ocp/spi@480b8000 ? Oct 22 22:54:32 It doesn't contain spi3, it contains: d_can0 d_can1 display0 ethernet0 ethernet1 i2c0 i2c1 i2c2 i2c3 i2c4 name rproc0 rproc1 rproc2 rproc3 rtc0 rtc1 serial0 serial1 serial2 serial3 serial4 serial5 serial6 serial7 serial8 serial9 spi0 Oct 22 22:55:08 okay so when it does show up it'll have the wrong number Oct 22 22:56:13 hunter2018[m]: does /sys/bus/platform/devices/480b8000.spi exist? Oct 22 22:57:42 if not, what does /proc/device-tree/ocp/spi@480b8000/status contain? Oct 22 22:59:14 It dosen't exist, and /proc/device-tree/ocp/spi@480b8000/status contains "disabled" Oct 22 22:59:52 then you're not using the right DT for whatever reason since the snippet you showed changes that property Oct 22 23:00:22 more specifically 5V for USB HOST Oct 22 23:00:26 forgot to include the snippet, forgot to recompile it, or forgot to copy it to the right place are among the options ;) Oct 22 23:00:36 and it is for VBUS only Oct 22 23:00:38 ds2: yeah that's what I meant, sorry Oct 22 23:00:55 zmatt: Gotcha, let me try again (this time overriding the cape_pins_default too) Oct 22 23:00:56 it is, but without vbus you don't have a working usb host port Oct 22 23:00:57 I do wonder if the USB DM/DP pins are 5V tolerante Oct 22 23:01:04 they are not Oct 22 23:01:18 zmatt: that can be worked around with hubs and such Oct 22 23:01:32 only if those hubs violate the usb specification Oct 22 23:01:38 *nod* Oct 22 23:01:49 and you should avoid those hubs since they may damage the beaglebone Oct 22 23:02:06 even then, you can hack in a small 5V charge pump.... only 100mA is required Oct 22 23:02:17 I did that for a battery powered setup Oct 22 23:02:29 sure but that's getting fairly outside the original context Oct 22 23:10:52 zmatt: I found my mistake. Now /proc/device-tree/ocp/spi@480b8000/status contains "okay" Oct 22 23:11:09 so now a /dev/spidev* device exists too hopefully Oct 22 23:11:15 zmatt: I forgot to include my snippet lol... Oct 22 23:12:01 zmatt: yeah, there is a /dev/spidev1.1 Oct 22 23:12:12 yeah, here's a snippet to fix the numbering: https://pastebin.com/raw/38ci70bq Oct 22 23:12:29 (spi0 is the qspi peripheral) Oct 22 23:12:55 Gotcha, so include that in my .dtsi file? Oct 22 23:13:38 yeah, for now until it's fixed upstream Oct 22 23:13:52 rcn-ee[m]: the mcspi devices are missing in /aliases Oct 22 23:14:07 so they lack stable numbering right now Oct 22 23:14:57 hunter2018[m]: a nicer solution btw is adding a property: symlink = "spi/whatever"; to your spidev child to get a /dev/spi/whatever symlink to open Oct 22 23:20:49 Ok! So after adding your snippet I get FATAL ERROR: Unable to parse input tree https://pastebin.com/raw/3HVKadmx Oct 22 23:20:56 Maybe I didn't add it correctly. Oct 22 23:21:35 weird Oct 22 23:22:19 I'm pretty sure this should be valid syntax... does / { aliases { ... }; }; instead of &{/aliases] { ... }; work? Oct 22 23:23:03 No, that fails too. Oct 22 23:23:28 ehhhh what Oct 22 23:23:44 Wait, it's not your snippet. I removed it and it still failed Oct 22 23:23:46 My bad Oct 22 23:23:48 lol Oct 22 23:24:14 error reporting in dtc isn't always great Oct 22 23:29:39 I accidentally had cape_pins_default: cape_pins_default { instead of &cape_pins_default { Oct 22 23:32:08 Cool, now I have /dev/spidev3.1 Oct 22 23:34:04 Now spi test gives me a different error: NameError: name 'sys' is not defined Oct 22 23:34:35 https://pastebin.com/raw/PNeexwzj Oct 22 23:34:43 lol, I must have fiddled with the test after last time I ran it or something Oct 22 23:34:48 add import sys at the top Oct 22 23:35:14 ohh, it's because that reports errors rather than when the test passes Oct 22 23:37:14 Worked, but got 125 bit errors because I don't have any jumpers inserted. Let me do that... Oct 22 23:57:12 It looks like it is running really fast at a 24MHz clock speed, and I might be getting some signal integrity issues... Oct 22 23:57:27 so lower the clock speed Oct 22 23:57:51 there's a speed_hz field in the transfer Oct 23 00:00:17 Like xfer.speed_hz = 1000 Oct 23 00:00:40 I don't know if such a low speed is possible, but sure Oct 23 00:00:48 That gave an invalid argument error... Oct 23 00:00:57 try 1 MHz Oct 23 00:06:57 is there enough divisor bits for 1000Hz? Oct 23 00:08:10 1MHz worked, I can see on the o-scope that the spi interface is working and clocking out data correctly. However, I don't see any response from the PRU Oct 23 00:08:51 hunter2018[m]: check pinmux, check that the pins you're using are correct for the pruss instance and pru core you're using Oct 23 00:10:25 Got it, I'll do that tomorrow. Thanks for all the help! At least I've successfully built the device tree that enables the spi pins. Oct 23 00:10:27 ds2: max clock divider is 4096, or in later mcspi versions up to 65536 (but above 4096 only powers of two) Oct 23 00:12:36 so minimum speed should be 733 Hz but maybe the kernel driver doesn't support dividers above 4096, in which case the min speed is just under 12 kHz Oct 23 00:15:58 * ds2 shakes fist at JSON Oct 23 00:16:07 json... -.- Oct 23 00:16:41 one of those great compromises of being inconvenient for humans and computers alike Oct 23 00:17:04 :D Oct 23 00:17:29 humans are adaptable. these compromises are an insult to humans Oct 23 00:17:45 the best thing one can say about it is "not quite as bad as xml" Oct 23 00:18:31 i need to make stripped down TIDL program that doens't need json libraries Oct 23 00:23:40 p Oct 23 00:40:39 hmmm only imagenet is available Oct 23 00:40:59 really wish people would write less bloated APIs Oct 23 01:01:23 LOL Oct 23 01:05:04 sigh... opencv is intermingled Oct 23 01:05:11 ds2: what, tidl on top of opencl, on top of the dsp/eve's.. ;) Oct 23 01:05:34 rcn-ee[m]: don't forget the #@$#@$@#%@#%#@%$ opencv bits shoved in Oct 23 01:05:42 oh that's right, there is opencv on top!! Oct 23 01:05:45 looks like their v4l2 driver is foobar'ed Oct 23 01:06:11 why can't they just write a simple C example Oct 23 01:06:40 there is more crap hidden behind classes then there are random crap hidden behind the walls of a 100year old house Oct 23 01:08:04 you should see the openvx work on meta-ti so we can get the m4 to help ;) Oct 23 01:08:29 this is making the jetson nano looking better and better :P Oct 23 01:09:01 I'm really tempted to try to get the various cores operational via uio :D Oct 23 01:09:18 zmatt: do you have docs to directly use EVE? Oct 23 01:09:39 eve is documented quite well, just not in the am572x trm Oct 23 01:09:47 oh? Oct 23 01:10:23 TI spent some time... do we want to actually "support" this feature... Jason got them to not efuse it off.. Oct 23 01:10:25 http://www.ti.com/lit/ug/sprui29f/sprui29f.pdf Oct 23 01:10:45 so it was limbo for about a year... Oct 23 01:10:48 efusing them off *facepalm* Oct 23 01:12:27 ds2: chapter 8 (pages 1735-2156) of the pdf above contains all the details Oct 23 01:13:28 nifty Oct 23 01:14:00 I do wonder wtf they mean by that "OCP" interconnect... OCP is a (heavily parameterize) protocol for interfacing *to* an interconnect, it is not an interconnect technology itself Oct 23 01:15:58 (the idea being, as far as I understand, is that OCP's parameterization makes it really easy to wrap your component's native bus interface into a flavor of OCP, and you can then feed a formal description of the OCP parameters you're using into your interconnect designer so it can generate the glue to hook it up) Oct 23 01:32:18 C++ is such crap Oct 23 01:34:57 buried in everything is the fact TIDL wants data in RRRRR...GGGGG....BBBBB.... not RGBRGBRGBRGB.... Oct 23 02:01:38 *sigh* the 1-based numbering of stuff on the am57xx is really obnoxious, especially since there's a mix of 0-based and 1-based numbering all over the place Oct 23 02:24:18 hmmm? I have seen that all over, not just am57x Oct 23 02:24:52 I don't think anything is 1-based on the am335x Oct 23 02:25:21 nor the dm814x (the first TI SoC I got familiar with) Oct 23 02:26:13 you mean just from the HW docs? Oct 23 02:26:32 yes as in peripheral instance numbers and such Oct 23 02:26:32 I am talking about the SW/HW mix Oct 23 02:26:50 well sw usually just tends even more to 0-based Oct 23 02:27:02 there are some 1 based ones (don't ask me to find it on demand) Oct 23 02:27:31 i usually run into that after an hour or two of debugging something only to find the doc and hte sw are talking about 2 different things (off by 1) Oct 23 02:27:34 yeah I think there was something 1-based in very old versions of the am335x DT, but that hasn't been the case for a long time Oct 23 02:27:44 the uarts iirc, maybe more stuff Oct 23 02:27:54 oh you are limiting to DTs... I am including pre-DT times Oct 23 02:28:25 I don't know much about what happened in prehistoric times Oct 23 02:28:32 ;) Oct 23 02:28:36 :D Oct 23 02:29:05 I can't even begin to imagine what could have made someone introduce 1-based numbering on the software side Oct 23 02:29:35 i can say the same thing about someone using C++ for examples ;) Oct 23 02:29:55 depends on for what I guess Oct 23 02:30:17 but I'm the wrong person to complain about, C++ is the main language I program in Oct 23 02:30:25 *to complain to Oct 23 02:30:29 'k Oct 23 02:30:41 all the important details are hidden behind classes Oct 23 02:30:48 that's what is frustrating me Oct 23 02:31:26 I mean, a class is just a struct... you can hide details in C just as easily Oct 23 02:32:13 yes except tha structure is hidden in god knows what header file Oct 23 02:32:40 run doxygen on it? Oct 23 02:32:55 you think that would do something in TIDL? :D Oct 23 02:32:57 so definitions can be found more easily Oct 23 02:33:14 dunno, I haven't looked at it :) **** ENDING LOGGING AT Wed Oct 23 02:59:58 2019