**** BEGIN LOGGING AT Fri Jan 31 03:00:42 2020 Jan 31 03:00:49 Right. I will start w/ a LED. Jan 31 03:01:47 I just do not get the library to use just yet or the "from scratch" Python3 built-in library to use. Jan 31 03:03:24 I use to have a link to an article in 2013 for someone using his android phone (with camera) to drive a toy car it was pretty interesting. Jan 31 03:03:57 I mean. Pathlib in python3 can help a bit but only to a specific point. I will need time and some other type of library built-in. Jan 31 03:04:02 I can only try. Jan 31 03:09:42 well you won't likely have ADA fruit to help although the python library they have I had to partially rewrite .. I am glad they deprecated it. Jan 31 03:11:13 which reminds me I was working on some LCD code... Jan 31 03:11:13 Which one is that one? Jan 31 03:11:17 Oh. Okay. Jan 31 03:12:14 Adafruit_BBIO Jan 31 03:13:33 I'm thinking it's likely a lazy library so I'll probably have to use "better" control methods for IO pins. Jan 31 03:13:47 Oh. Jan 31 03:14:11 Adafruit_BBIO is a nice one. It makes the normal stuff easy. Jan 31 03:14:20 I just do not know the "normal stuff" yet. Jan 31 03:14:31 unless you need something slightly fast. Jan 31 03:14:33 :D Jan 31 03:14:56 Right. C/C++ can be used instead. Blazing! Jan 31 03:16:08 umm not necessarily. They may be using the file system method to toggle IO pins, which would be slow (IE lots of overhead). If you're just turning on and off an LED that's OK. Jan 31 03:17:23 I liked being a self-produced person in life. It is not so easy w/ Python3 w/out the Adafruit libraries (so far). I have to learn from scratch what I should have been learning this entire time. Jan 31 03:18:23 Hmmm you also need to follow a steady path instead of leaping all around. It's hard to accomplish something otherwise. Jan 31 03:18:55 It's sort of like building a car, you keep changing the car design every month and it takes a month just to design the engine. Jan 31 03:19:46 Right. Not me, though. I have 500+ projects to attempt and only a lifetime. I support you peoples' projects w/ the BBB to AI but I should have been learning how to do things on my own instead of relying on the library. Jan 31 03:20:00 Although the library has been a good one...wait. Jan 31 03:20:11 You say they deprecated it? Jan 31 03:20:20 No! Jan 31 03:21:16 Hey. They deprecated the Adafruit_GPIO library only to read-only, right? Jan 31 03:22:08 Not the other one that is used mostly, I think. Jan 31 03:24:30 I'll not comment on that :D Jan 31 03:24:56 Oh. Okay. I just used it the other day. I was wondering if it happened overnight or something. Jan 31 03:25:24 I copied on the Github repo. I will work on it later. Jan 31 03:25:37 I mean. whatever they were doing was working. Jan 31 03:26:50 The entire script worked w/ ease w/ gpio, i2c (used to be), adc, spi, uart, and I assume the eqep. I never did use the eqep stuff. Jan 31 03:28:18 Once I learn logging better, i am going to do it w/ everything i do. Jan 31 03:32:55 the important thing about a log is what data is of interest. Then how much data can you log. Jan 31 03:33:28 Right. I just got a log from my xfce4-session when using vncserver. Yikes. Jan 31 03:33:40 All kinds of issues. Jan 31 03:34:10 I just erased my .service file for starting vncserver xxxxxxxxx:2 at boot. Jan 31 04:51:01 GenTooMan: Are you still around? If so, have you gotten to make a "mesh" matrix on cv2 w/ two, separate files (.jpg)? Jan 31 04:55:17 I am asking b/c on the AI, I cannot load this line for some reason >> src1 = cv.imread(cv.samples.findFile('LinuxLogo.jpg')) Jan 31 06:29:16 CPU 100% = something is happening! Jan 31 06:34:20 cpu 100% = something is broken or whatever you're trying to do requires more cpu power than available Jan 31 06:37:57 100% == only one core? I have seen over 100% Jan 31 06:39:00 sure, but any single thread taking 100% means what I just said (except maybe if you're lucky there might still be enough cpu power for what you're trying to do if you can manage to distribute it across multiple cores) Jan 31 06:41:10 at 400MHz, it isn't that hard to peg the CPU Jan 31 06:41:12 playing videos, browsing web, compiling something, always at least 100% Jan 31 06:41:47 if playing video causes your cpu to be at 100% your video will be stuttering Jan 31 06:42:05 cv2 and image processing. Jan 31 06:42:27 and fair enough, some "batch" jobs like compilation can take 100% cpu without this meaning anything bad since the take it takes is just indetermine Jan 31 06:42:30 these small devices never played videos smoothly Jan 31 06:42:31 just use libjpeg directly Jan 31 06:42:50 the AI can play videos just fine Jan 31 06:42:54 same with the classic and xM Jan 31 06:42:59 Oh. Jan 31 06:43:07 BBB and BBW OTH.... Jan 31 06:43:13 by default there is no video hardware acceleration Jan 31 06:43:16 but e.g. when doing video analysis stuff (or indeed many things in embedded) you want whatever you do to work every time Jan 31 06:43:34 hence 100% cpu is a bad sign Jan 31 06:45:19 I have rpi3b+, cubietruck (some model of cubieboard) and BB AI, only cubietruck played videos normally with mpv Jan 31 06:46:20 browsing web is out of reach everywhere (ok, only one tab maybe can be) Jan 31 06:46:36 The cv2 is labor intensive for the AI w/ the vncserver attached to view what output I get. Jan 31 06:46:46 I mean, to be fair these SoCs are designed for specific embedded applications, not for use as desktop computer Jan 31 06:46:54 Right. Jan 31 06:46:59 Still fun to try. Jan 31 06:47:11 if you want to get video OUT of the AI, stream it with RTP Jan 31 06:47:13 not VLC Jan 31 06:47:16 VNC I mean Jan 31 06:47:19 that Jan 31 06:47:20 use VLC to read the RTP stream Jan 31 06:47:27 Oh. Okay. Jan 31 06:47:32 BB AI one example https://beagleboard.org/p/175809/tidl-on-beaglebone-ai-1ee263 can only be used somehow, if swap is activated before Jan 31 06:47:37 RTP. I will have to look that up. Jan 31 06:47:49 or use gstreamer :D Jan 31 06:47:52 * ds2 ducks Jan 31 06:48:05 you really don't want to enable swap Jan 31 06:48:20 without swap it will hang Jan 31 06:48:22 es0thz: I got that example to work w/ it saying Water Bottle instead of my soda can. Jan 31 06:49:15 swap will go in use about 400MB after running this example. so this is why it hangs without swap Jan 31 06:49:21 swap works better if you put rotating media on it Jan 31 06:49:33 running TIDL shouldn't need swap Jan 31 06:49:41 the classifer isn't that heavy weight Jan 31 06:49:47 es0thz: linux will use swap if it's there, it's not an indication it actually needs it Jan 31 06:50:29 it will not need swap without running this example. almost all swap is freed after stopping this example Jan 31 06:50:44 which example? Jan 31 06:50:56 https://beagleboard.org/p/175809/tidl-on-beaglebone-ai-1ee263 Jan 31 06:51:03 I don't recall needing swap for any of the TIDL stuff Jan 31 06:51:28 It is located at /var/lib/cloud9/BeagleBone/AI/ Jan 31 06:51:35 that's not the TIDL stuff Jan 31 06:51:41 that is the cloud9 stuff Jan 31 06:51:55 I thought they had some tidl stuff on the AI? Jan 31 06:52:21 I have a hacked up version that will grab from a webcam and output to stdout...that can be hooked up with a webserver Jan 31 06:52:34 strange, I left my bbai running overnight and it was in some sort of boot-loop state just now, even though before I went to sleep its temperature was stable at an unconcerning level Jan 31 06:52:51 downloaded latest firmware from BB web, installed it in microSD, enlarged filesystem in card, did upgrade as said in example (but not kernel upgrade, because of this 400MHz problem) and run this example Jan 31 06:53:18 06:53:11 up 1 day, 23:49, 1 user, load average: 0.00, 0.00, 0.00 Jan 31 06:53:50 it is that short cuz I was screwing with OpenCL and crashing the DSPs Jan 31 06:54:45 yeah I was running with my cortex-a15 prcm hack applied, maybe it actually does have an adverse impact on stability.. and I had cpu governor on "performance" (1.5 GHz) Jan 31 06:55:03 I have had it running for days with your prcm hack Jan 31 06:55:29 but I also have the strangle the cortex hack for thermal control running too :D Jan 31 06:56:07 I did notice that using my hack to get effective cpuidle causes the system load average values to become falsely high Jan 31 06:56:34 I guess the "missing" time is somehow being tracked wrong Jan 31 06:56:38 probally due to the idles happening in a process instead of the idle loop? Jan 31 06:56:51 except I don't see how that can be Jan 31 06:56:59 cpuidle is entered on wfi Jan 31 06:57:22 which is only ever used in the idle task afaik Jan 31 06:57:54 I'd agree with you but that's the only way the load avg should be impacted Jan 31 06:59:42 like, this was shortly after boot (temperature still rising, load avg still falling): Jan 31 06:59:46 uptime=133.15 idle=249.33 cpu=50.200 gpu=50.600 core=50.600 dspeve=49.800 iva=51.000 loadavg=(0.11 0.09 0.03) Jan 31 07:00:15 after a idling for a while on --retention: Jan 31 07:00:19 uptime=10965.62 idle=8895.25 cpu=53.000 gpu=53.400 core=54.200 dspeve=52.600 iva=53.400 loadavg=(0.71 0.77 0.73) Jan 31 07:00:27 what image are you using? Jan 31 07:00:50 then I switched cpufreq to -g performance and let it idle a bit more: Jan 31 07:00:51 uptime=11458.10 idle=9252.34 cpu=54.200 gpu=55.400 core=55.000 dspeve=54.200 iva=54.600 loadavg=(0.79 0.78 0.75) Jan 31 07:00:53 the stock iamge has the pesky GUI crap Jan 31 07:00:58 I killed the gui Jan 31 07:01:03 it bounces the load average up Jan 31 07:01:16 no gui, no tidl, no dsp/ipu firmware Jan 31 07:01:17 that GUI is a hoard of zombies that is hard to kill Jan 31 07:01:34 pretty sure stopping lightdm worked fine for me Jan 31 07:02:06 you can't generate zombies really since they can't escape the cgroup of the parent systemd service Jan 31 07:02:37 no, not zombie in the *nix sense, zombie as in the undead sense Jan 31 07:02:52 systemd likes to keep re-animating the GUI Jan 31 07:03:01 not if you stop it Jan 31 07:03:41 when I said "kill" I meant "systemctl stop", not actually killing processes manually Jan 31 07:03:59 yes, I have tried that Jan 31 07:04:05 ah I still had a "ps" in history, this is what I had running: https://pastebin.com/raw/qAdADe3g Jan 31 07:04:13 (ignoring kernel threads) Jan 31 07:04:40 hmmm is networking clean? Jan 31 07:04:52 I haven't modified networking, this is still stock Jan 31 07:05:31 normally I'd toss out all the connman crap and custom setup scripts and replace it by systemd-networkd, but my bbai is still pretty much the stock image Jan 31 07:05:52 but bbai has wifi.... Jan 31 07:06:09 I disabled wifi and bluetooth with rfkill Jan 31 07:06:58 (not that that prevents wpa_supplicant or bluetooth stuff from spawning) Jan 31 07:08:31 what's top say when that happens? Jan 31 07:08:48 interested in the userspace vs system allocation Jan 31 07:08:48 when what happens? Jan 31 07:09:02 when the high load avgs happens Jan 31 07:09:20 top doesn't show anything using significant cpu% Jan 31 07:09:32 nor anything in uninterruptible sleep Jan 31 07:09:35 it is the headers on top Jan 31 07:09:47 those are just the same info as uptime aren't they? Jan 31 07:10:01 Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Jan 31 07:10:04 like that Jan 31 07:10:04 I could boot up my bbai again if you really want to know Jan 31 07:10:05 oh those Jan 31 07:10:15 userspace vs system (aka kernel) Jan 31 07:10:18 hold on I'll power it up Jan 31 07:16:31 so, this is running normally, along with some system info: https://pastebin.com/raw/zBrxRHHu Jan 31 07:16:56 I've switched to retention and will let it idle for a bit to let the stats stabilize Jan 31 07:20:42 actually these loadavg values are already a bit puzzling... if load used to be high (because of boot) and then goes down, shouldn't the first number be the lowest since it has the shortest averaging? Jan 31 07:20:58 yep Jan 31 07:21:07 grab the top info Jan 31 07:21:23 top info is at the top of the paste Jan 31 07:21:35 you got an updated paste? Jan 31 07:21:39 I'll make another paste now with the info of --retention Jan 31 07:23:37 https://pastebin.com/raw/Xz9VKcZ4 Jan 31 07:23:55 so top still regards the system as being idle Jan 31 07:24:00 it's *just* loadavg that's fucked up Jan 31 07:27:05 can you give me /proc/uptime? Jan 31 07:28:32 those are the uptime= and idle= values in my log_thermal output Jan 31 07:28:56 what's 703.66 mean in your output? Jan 31 07:29:14 that's just the raw value from /proc/uptime Jan 31 07:29:24 oh first and 2nd field? Jan 31 07:29:29 pretty sure uptime is in seconds and idle in cpu-seconds Jan 31 07:29:35 it only has two fields: Jan 31 07:29:35 root@bbai:~# cat /proc/uptime Jan 31 07:29:35 1011.16 1231.00 Jan 31 07:30:02 if the second field is indeed in cpu-seconds, it is wonky Jan 31 07:30:03 hmm Jan 31 07:30:38 lemme turn cpuidle off again for comparison Jan 31 07:31:21 ok, loadavg is dropping again (and in a way that makes sense, i.e. first field falls fastest) Jan 31 07:33:08 yep, now idle is increasing at twice the rate of uptime Jan 31 07:33:13 so idle is indeed in cpu-seconds Jan 31 07:33:23 and its value is fucked when cpuidle is enabled using my hack Jan 31 07:33:34 =) Jan 31 07:33:58 for 2 CPUs...that would give it a load avg of about 0.6-0.7 range Jan 31 07:34:27 even though the values from /proc/stat do correctly account idle Jan 31 07:35:32 now to trace down how are they computed Jan 31 07:36:25 actually no, loadavg doesn't use that particular value I think? since it's not an average of how idle the cpus are, it's the average number of tasks running/runnable or in uninterruptible sleep Jan 31 07:36:34 or at least it's supposed to be Jan 31 07:37:02 open("/proc/uptime", O_RDONLY) = 3 Jan 31 07:37:06 from strace Jan 31 07:37:22 it looks at /proc/loadavg and /proc/uptime Jan 31 07:37:33 yes, uptime for the uptime, loadavg for the loadavg Jan 31 07:38:15 yes but they need to be normalized Jan 31 07:38:26 nevermind Jan 31 07:38:27 nope Jan 31 07:38:32 that's completely wrong.... mind broken :( Jan 31 07:39:00 now I am curious Jan 31 07:39:10 most likely both loadavg and the idle time value in /proc/uptime are independently wrong for the same undelying reason, whatever that reason is Jan 31 07:40:36 I should probably write this up in a post to the linux-omap list, since it would be really nice if cortex-a15 prcm gets fixed properly Jan 31 07:49:29 wonder if the nohz stuff is broken in this usage case Jan 31 07:50:07 too lazy to checkout new code but the old accounts for nohz to get jiffies to get loadavg...uptime is a bit more convoluted Jan 31 08:38:46 hmmm somehow this tidl example runs better today. maybe because I tried everything over network now Jan 31 08:44:13 wait, you were opening the cloud9 IDE and video playback stream in a web browser on the BBAI itself?! Jan 31 08:44:17 ouch Jan 31 08:45:01 honestly, shipping images with a desktop environment in the first place still feels like a mistake Jan 31 08:45:33 I feel like it should definitely not be the default Jan 31 08:46:57 yesterday tried in BBAI itself Jan 31 08:47:34 I mean, then it certainly doesn't surprise me you had problems Jan 31 08:47:43 desktop environment seems to be very bad Jan 31 08:48:08 alfa testing image was without desktop Jan 31 08:48:25 I really feel like it should be shipped without one Jan 31 08:48:31 let the fools who want one install it themselves Jan 31 08:49:08 device has gpu but this is not used by desktop? Jan 31 08:49:12 it's just a waste of space and resources Jan 31 08:49:59 (space is not problem with 64GB card) resources ofcourse wasted Jan 31 08:50:00 the gpu driver doesn't support x11, only fullscreen (drm) and wayland Jan 31 08:50:21 okay I never run from sd cards, only eMMC Jan 31 08:50:53 my eMMC broke after kernel upgrade (CPU speed stuck in 400MHz) Jan 31 08:51:05 how does that "break" eMMC? Jan 31 08:51:12 eMMC installation broke, I mean, not eMMC chip itself :) Jan 31 08:51:12 just switch back to the previous kernel Jan 31 08:51:14 or reflash Jan 31 08:51:28 installing a new kernel doesn't remove the previous kernel Jan 31 08:51:49 and you can just change which kernel you want to use in /boot/uEnv.txt Jan 31 08:52:25 is eMMC much faster than Sandisk extreme memory vard? Jan 31 08:56:12 no idea on the BBAI, it'll depend on whether the memory device or the interface is the limiting factor (which will also depend on what performance metric you're evaluating) Jan 31 08:57:13 on the BBB the interface is often the limiting factor (at least for reads), and in that case eMMC will win by a big margin since it uses an 8-bit wide data bus while SD uses a 4-bit wide data bus, and on the BBB both have the same max clock speed hence eMMC has twice the interface bandwidth Jan 31 09:01:31 eMMC on the bbai seems to run at 192 MHz interface speed: Jan 31 09:01:34 root@bbai:~# cat /sys/kernel/debug/mmc1/clock Jan 31 09:01:34 192000000 Jan 31 09:02:33 you can check /sys/kernel/debug/mmc0/clock to determine what your SD card is using Jan 31 09:02:56 however with these speeds I'd guess that the card/eMMC itself is probably the limiting factor, not sure though Jan 31 09:03:11 where is scard boot configured to be first if I want to use eMMC as boot and card as additional reserve space for low priority stuff? Jan 31 09:06:10 you need more than the 16GB of eMMC? what are you using all that space for? anyway, if you just wipe the card and create a fresh filesystem it'll obviously not boot from it Jan 31 09:07:09 there's two aspects to it: ROM has a boot-order (selected via pin strapping) used to determine where it'll look for the bootloader, and the bootloader will then search for bootable filesystems according to its boot script Jan 31 09:09:07 on the BBAI, changing the strapping options for the ROM bootorder would require a soldering iron Jan 31 09:09:43 but you can ensure it will ignore the SD card by wiping the space between the partition table and the rootfs partition (wiping sector 256 probably suffices) Jan 31 09:10:57 the boot script is hardcoded into the bootloader, I'm not 100% what criterion it uses to consider a filesystem to be bootable, but removing all kernels and the /boot directory will probably do the job just fine Jan 31 09:11:55 reflashing with script activated in /boot/uEnv.txt rsynced everything from card but ssh-server keys are changed somehow Jan 31 09:12:46 "somehow" ... how would they *not* change? Jan 31 09:12:48 ECDSA host key regenerated Jan 31 09:13:09 you'd need to explicitly backup the keys and restore them to avoid that Jan 31 09:13:34 it would actually be nice if the flasher did that, but I'm not sure it's desirable under all circumstances Jan 31 09:13:43 I expected this was just filesystem rsync and boot reconfigure Jan 31 09:13:45 (same with other identifiers like machine id and hostname) Jan 31 09:15:44 it mostly rsyncs (after wiping the device and creating a new partition map and filesystem) but obviously not things like ssh keys, you don't want to end up with multiple devices having the same unique identifiers Jan 31 09:21:46 card is using 192MHz also Jan 31 09:23:14 okay, so it'll have half the bandwidth of eMMC (just like on the BBB, except the BBAI has 4x the bandwidth compared to the BBB, for both eMMC and for SD, making it far less likely to be interface-limited) Jan 31 09:30:23 although I'm actually getting 160-167 MB/s (153-159 MiB/s) reading from eMMC, which is about 83-87% interface bandwidth utilization, which isn't bad Jan 31 09:30:40 and far more than even theoretically possible reading from SD card Jan 31 09:31:17 so at least for reading, eMMC should considerably outperform any SD card on the BBAI Jan 31 09:42:35 card write 21.6MB/s read 22.2MB/s; eMMC write 25.9MB/s read 100MB/s Jan 31 10:04:36 note: I tested using: dd if=/dev/mmcblk1 bs=4M iflag=direct of=/dev/null count=200 Jan 31 10:08:10 162MB/s Jan 31 10:08:52 note: dd's "MB" = 1000^2, not 1024^2 Jan 31 10:09:10 22.9MB/s card Jan 31 10:09:24 big difference Jan 31 10:11:31 yeah that read speed sucks, especially compared to write Jan 31 10:11:37 normally write is way slower than read Jan 31 10:14:26 is this the card you have? https://shop.westerndigital.com/products/memory-cards/sandisk-extreme-uhs-i-microsd#SDSQXA2-064G-AN6MA Jan 31 10:14:47 because they numbers they specify are definitely a lot higher Jan 31 10:15:38 well, ignoring the fact that including the words "up to" makes all the performance numbers mean absolutely nothing Jan 31 10:22:16 (and UHS-I speeds above 104 MB/s is not spec-compliant, which they do mention under "Disclosures") Jan 31 11:08:38 hi Jan 31 19:15:24 e Jan 31 19:50:09 kremlin I assume you are just testing to see if IRC still responds? Jan 31 19:51:25 e = good evening Jan 31 19:51:43 no it's not, it's just an e Jan 31 19:51:52 yes, it is Jan 31 19:54:46 ah the light goes on at the end of the tunnel. Jan 31 20:24:58 if there is light at the end of the tunnel and it's not red, you are driving in the wrong direction! Jan 31 20:36:57 indeed Jan 31 20:56:27 necessarily.... maybe I have flame throwers on my tail pipe :D Jan 31 20:57:56 the name's Bond .. ds2-bond :P Jan 31 21:02:17 ttps://www.carthrottle.com/post/heres-how-to-make-your-car-exhaust-spit-flames/ Jan 31 21:04:10 can't do it with most modern vehicles, without artificially injecting fuel into the exhaust system, which likely will fail emissions tests... Jan 31 21:04:34 *legally :p Jan 31 21:19:55 Ahh you want to be legal ... weird that. Jan 31 21:22:11 Actually since the flames are purely decorative (IE luminous) you could make an adapter to act much like a after burner. you just need extra air and use the heat of the exhaust with a little igniter and boom exhaust flambé. Not for use in California Nevada or any highly flammable local. Jan 31 21:26:19 Do I need to tell the PRU (somehow) on the AI to make address space for the IPUs or can i just type up some .c files w/out hesitation? Jan 31 21:26:26 I am still reading on this subject. Jan 31 21:27:46 I have been reading the sdk stuff but I know I do not have a large enough onboard chip to establish the sdk from TI on my AI. Jan 31 21:27:52 So, I am kind of out of the loop. Jan 31 21:30:08 PRU has nothing to do with the IPUs, but the IPUs are not an easy development target and honestly I'd suggest you forget about trying to run code on them... I have trouble imagining what use you could have for them anyway Jan 31 21:30:31 I am going to read rsc_types.h more. Wish me luck! @zmatt: Okay. Jan 31 21:30:34 But... Jan 31 21:31:01 There are a ton of people using this chip from what i read. I would like to be one of them one day. Jan 31 21:31:27 I see the Ada people have their own boards w/ m4 tech. on them and some other stuff w/ fpga chips too. Jan 31 21:31:52 really, who is running code on the IPUs? I've never seen any other than written by TI themselves Jan 31 21:32:31 I don't know what you're talking about just now, but it doesn't sound related to the IPUs Jan 31 21:32:52 Okay. Please hold. I will get the link. Jan 31 21:33:47 https://www.adafruit.com/product/4000?gclid=Cj0KCQiAvc_xBRCYARIsAC5QT9lNT0nWGbeywOIBkR4ejuq7igVsWmDpj9tngWMr7h3TsoUX3fCiZ_4aAslzEALw_wcB is what I found not too long ago. Jan 31 21:34:32 why are you linking to some random board? Jan 31 21:34:43 b/c it has a m4 on it. Jan 31 21:34:44 what does this have to do with the IPUs on the AM57xx ? Jan 31 21:34:54 IPU is the m4 right? Jan 31 21:35:30 a cow is a mammal, that doesn't mean every mammel is a cow Jan 31 21:35:55 So, there are different m4 chips. got it. Jan 31 21:36:47 just because something uses the same core doesn't mean they are even remotely similar for any practical purpose Jan 31 21:37:23 I get it. Okay, I would like to understand things. I am sorry. But, w/out the evm board, I guess I am just smack talking. Jan 31 21:37:38 ? Jan 31 21:37:52 what evm board? Jan 31 21:38:23 @zmatt: There is a am57xx board to learn on w/ the proper size chips to test the sdk. Jan 31 21:38:25 That is all. Jan 31 21:39:18 yes, which is the beagleboard-x15 with an lcd board plugged into it... but I don't understand why're bringing it up Jan 31 21:39:43 (nor which sdk you're suddenly talking about) Jan 31 21:40:49 If you know what I am discussing to get the m4 working for "enjoyment," good. But, please stop acting like you do not understand. Jan 31 21:41:15 The linux sdk from ti. Jan 31 21:41:17 That is all. Jan 31 21:41:28 no I have no idea what you sdk you could be talking about "to get the m4 working for enjoyment" Jan 31 21:41:38 what in that sdk do you imagine would be helpful for this objective? Jan 31 21:41:47 I will give you the link. Please hold. Jan 31 21:43:17 http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#ipc-quick-start-guide Jan 31 21:43:45 and you still haven't really explained why you'd want to mess with them... in the past I've developed for the direct predecessor of IPU so I know how it works, but it's honestly kind of a pain in the ass and I wouldn't use it unless I had a good reason for it Jan 31 21:44:00 and the fact that on the AM57xx you have two PRU subsystems to run code on makes IPU even less attractive Jan 31 21:45:04 No issue. Jan 31 21:45:24 I will stick to easy stuff while you and I are dealing w/ each other. I know I come up w/ rare issues. Jan 31 21:45:55 set_: why did you link to that page? Jan 31 21:46:12 B/c, I am reading and learning about things. Jan 31 21:46:49 GenTooMan: sgtm :D Jan 31 21:47:07 set_: you know what, good luck with that, I'm going to do something else Jan 31 21:47:28 Okay. Jan 31 22:43:00 set_ you have rare issues? Jan 31 22:56:15 Yep! Jan 31 22:56:30 I have one right now, too. .X1-lock gives me issues. Jan 31 22:57:55 It is not as rare as others but an issue in itself! Jan 31 23:43:41 hi, did someone try to use android on bb-x15? Feb 01 00:06:44 embden_new[m]: well the bbx15 is just the base board of the AM572x EVM, so presumably TI's Processor SDK for Android AM57x will work on it Feb 01 00:17:22 https://photos.app.goo.gl/Uc7xqwPAXD1r1dWA7 on the AI w/ cv2 and python2/3! Feb 01 00:17:35 guassian distributions! **** ENDING LOGGING AT Sat Feb 01 03:00:26 2020