**** BEGIN LOGGING AT Wed Mar 16 02:59:56 2022 Mar 16 11:55:28 Hello! I wonder what the temperature range for BeagleBone Black v2.1 and v2.5 is. I can find it for the Industrial version of BeagleBone Black, but not the "normal" version. Mar 16 11:56:26 ehm, there's no such thing as a "BeagleBone Black v2.1" nor "v2.5" ... the most recent BBB revisions are rev C and rev C3 Mar 16 11:57:39 oh, the two boards I have say v2.1 and v2.5 on them. I guess there could be some non official version, these are for Antminers. Mar 16 11:58:12 those are not beaglebones, they're custom boards Mar 16 11:58:21 only loosely based on the beaglebone black Mar 16 11:58:51 Ah ok! Thanks :) I will see if I can get the temp range from Bitmain then. Mar 16 11:59:17 yeah, their schematic and parts list isn't public afaik, so they're the only ones who can give a good answer on that Mar 16 11:59:42 my guess would be 0 to 85 ͏°C Mar 16 12:01:01 Thank! I'll note that down, and see if I can get an official answer! Thanks for the help! :) Mar 16 12:01:22 junction temperature, so you obviously can't actually run them in a 85 ͏°C environment Mar 16 12:01:47 (but the max environmental temperature depends on how effectively components can get rid of their heat) Mar 16 12:02:38 With my employer we will probably end up in 85C, but then I have a range to point at, so he they might listen when a few thousand miners goes offline ^^ Mar 16 12:03:12 it's also not a binary thing... like, the question isn't "will it work?" but "how long will it work?" Mar 16 12:04:02 you may want to change the ddr3 configuration to enable high temperature mode (assuming the ram supports it) and increase the refresh rate, to help reduce the risk of memory errors Mar 16 12:07:47 I'll see if we can do that. I am not sure the webinterface support that, we use the stock firmware. But the more I can ask the better, maybe there is an official way to poke around. I am very sure we will have a tough summer with the current attitude from the top ^^ Mar 16 12:08:45 Guest2984: section 5.3 of the AM3358 datasheet is also worth noting Mar 16 12:11:04 it shows that even when using AM335x parts rated for high temperature, device lifetime is reduced when operating at OPP "Turbo" (800 MHz) and "Nitro" (1 GHz) at 105 ͏°C junction temperature, and operating at 125 ͏°C junction temperature prohibits going above OPP100 (600 MHz) and requires OPP50 (300 MHz) to avoid significantly reduced device lifetime Mar 16 12:11:46 most likely because running at a lower performance point allows for lowering supply voltages, which reduces the rate at high damage accumulates Mar 16 12:11:55 *at which Mar 16 12:12:59 they also require lowering DDR3 speed from 400 MHz (DDR3-800) to 333 MHz (DDR3-667) Mar 16 12:13:30 when going above 105 ͏°C junction temperature Mar 16 12:13:47 Oh thanks, I will note that down and see if I can find that document, I think I found the wrong document. Mar 16 12:13:53 (ram doesn't support such temperature, but the AM335x junction temperature may be higher than that of the ram in same environmental conditions) Mar 16 12:14:25 the datasheet? https://www.ti.com/lit/ds/sprs717l/sprs717l.pdf Mar 16 12:16:06 note, when examining tables in section 5.4, be sure to look at tables for ZCZ revision "A or Newer", not ZCE, not revision "Blank" Mar 16 12:18:00 and of course, if the actual part used by antminer isn't rated for high temperature, technically none of this matters (though it's obviously a strong hint that if you're going to run outside the temperature specs, it would be a good idea to limit cpu clock speed and perhaps the ram too) Mar 16 12:19:43 running a part outside the binned temperature spec will of course increase the probability of random issues, similar to overclocking Mar 16 12:20:07 in addition to reducing the device lifetime Mar 16 12:27:58 rcn-ee: btw, I've applied the uio-pruss patch from 4.19 to 5.4.106-ti-r39 (just the first patch in the patch set, the rest should no longer be relevant I think) and it applied cleanly and compiled successfully... gotto do other stuff now but I'll give it a try later to see if it actually works Mar 16 12:34:56 Thanks for the link! :) I had to a accept a delivery. I will checkout the document you linked. Mar 16 12:37:14 Guest2984: I'll be afk for a while.... anyway, good luck with your beaglebone-barbecue ;) Mar 16 12:37:52 (*beaglebone-derived-custom-board-barbecue, technically) Mar 16 12:41:56 Thank you! ^^ Mar 16 15:36:24 argh, it really sucks that if u-boot fails to apply an overlay it just completely fails to boot at all Mar 16 19:27:23 zmatt: should we add more default to the uio option for v5.4.x? https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/overlays/AM335X-PRU-UIO-00A0.dts Mar 16 19:29:15 rcn-ee: https://github.com/mvduin/overlay-utils/blob/master/uio-pruss-5.x.dtsi Mar 16 19:29:34 rcn-ee: also, I haven't been able to test it yet, but it does compile: https://github.com/mvduin/ti-linux-kernel-dev/commits/ti-linux-5.4.y Mar 16 19:30:02 it also applied against 5.10-ti Mar 16 19:30:50 cool, i'll merge that... looks like i did similar (patches 1 and 3..) https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/8fdb75912c67d8c7c1c4072b13096f312aa8a84b Mar 16 19:33:28 yeah, drop patch 3, reset is handled by the new ti,sysc stuff Mar 16 19:34:01 hmm, I didn't change patch.sh ... I think it got picked up anyway? Mar 16 19:34:14 no point in enabling CONFIG_UIO_DMEM_GENIRQ, it cannot be configured via DT Mar 16 19:35:14 it did not, I'm an idiot Mar 16 19:35:15 lol Mar 16 19:35:44 I should have checked that it actually applied the patch Mar 16 19:36:49 ah okay, i'l ldop 3.. Mar 16 19:37:59 it really wants the irq's to be filed in.. this gives me all the /dev/uio*... https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/1b0d6e97d6cce0aa7c8b659dc8e292fc436550d2 Mar 16 19:38:57 oh right those are hooked up to a different node Mar 16 19:38:58 found these two tests, do you have more that i should run? Mar 16 19:39:03 https://www.irccloud.com/pastebin/GhovCwvm/ Mar 16 19:39:47 intc-test.py to test irqs Mar 16 19:40:06 https://www.irccloud.com/pastebin/U3bVguvi/ Mar 16 19:40:07 if ddr-ping.py and intc-test.py work, everything works Mar 16 19:40:19 https://www.irccloud.com/pastebin/bXWlQoSG/ Mar 16 19:40:35 https://www.irccloud.com/pastebin/MLnECcz2/ Mar 16 19:40:54 so, i'll remove the 'de-assert' patch and retest... but it looks like we can ship it? ;) Mar 16 19:41:03 you already tested ddr-ping, not intc-test Mar 16 19:41:40 does intc_test.py ever stop? Mar 16 19:41:51 no Mar 16 19:42:04 just ctrl-C Mar 16 19:42:06 ah, okay, it's just event 16 and event 17... Mar 16 19:42:10 must be a pass then? Mar 16 19:42:12 yes Mar 16 19:42:17 perfect! Mar 16 19:42:28 what's your overlay look like now? Mar 16 19:42:44 https://www.irccloud.com/pastebin/xSE5cBOj/ Mar 16 19:43:06 the irq is the only diff from yours.. Mar 16 19:43:42 disabling &pruss_uart and &pruss_mdio is not needed, since we're changing the driver of &pruss, all of its child nodes will get ignored (since the uio pruss driver isn't a bus) Mar 16 19:44:35 ah very true...thanks to the compatible Mar 16 19:46:33 it's unfortunate they removed the soc bus wrapper, I liked having that to be able to add additional devices (from linux' perspective) within pruss Mar 16 19:47:53 in 4.x you could do https://github.com/mvduin/overlay-utils/blob/master/uio-pruss.dtsi and still add more nodes to &pruss_soc_bus Mar 16 19:48:19 but I'm probably the only perform in the world who cares Mar 16 19:48:24 *only person Mar 16 19:58:51 wonder if mainline said no to that wrapper? Mar 16 19:59:06 sounds like something useful, that wasn't considered generic enough. ;) Mar 16 20:00:09 or maybe &pruss is now the wrapper Mar 16 20:00:40 okay, also pulled in your 2nd patch.. Mar 16 20:01:45 it still does some stuff, but not enough to justify its existence Mar 16 20:01:54 I'm actually not sure why the soc bus wrapper existed in the first place Mar 16 20:02:03 https://www.irccloud.com/pastebin/X0kwIQ2Q/ Mar 16 20:02:20 all tests pass.. tag and bag it, and ship it.. Mar 16 20:02:36 uio-pruss, alive forever more Mar 16 20:02:58 and it's one less patch since v4.19.x (reset..) Mar 16 20:03:17 indeed Mar 16 20:03:33 still need to get it to work on tda4.... Mar 16 20:03:40 shouldn't be too hard Mar 16 20:04:38 I should also look into doing that improvement that was suggested: put the intc offset into the driver, based on compatible-string, instead of in DT Mar 16 20:07:13 wonder if we can patch uio to steal it from: Mar 16 20:07:17 https://www.irccloud.com/pastebin/QjUhStiN/ Mar 16 20:10:53 that would be much more complicated and quite gross Mar 16 20:11:02 like, there's no reason for that node to exist when using uio-pruss Mar 16 20:11:22 it just does because we're repurposing the node that was meant for remoteproc Mar 16 20:18:07 rcn-ee: looks like the tda4 pruss layout has been kept backwards-compatible, so I think the uio-pruss driver should work without any changes Mar 16 20:31:28 Good evening, i have a question, i need to develop a small app showing an image and eventually a small animation plus some background works with io Mar 16 20:32:24 i have some difficulties to find the proper graphic kit for that, i intended to use sfml however it seems i need to compile from source including opengl and install the graphic driver Mar 16 20:32:48 any idea which is a simple graphic environment i could use, just a 2d environment Mar 16 20:34:53 maybe sdl ? Mar 16 20:35:05 directfb2? it's back... https://github.com/directfb2 Mar 16 20:35:16 or qt5 with the linuxfb backend Mar 16 20:35:41 sdl Mar 16 20:35:41 (which nowadays also supports using the modern drm api instead of only the legacy fbdev) Mar 16 20:36:23 ok hx Mar 16 20:36:26 thx Mar 16 20:36:50 i'm looking into it Mar 16 20:37:07 rcn-ee: argh, must have done something wrong.. I installed the 5.10.100-ti-r38 I compiled onto my bbx15 (with default dtb, nothing custom yet) and it fails to boot :/ Mar 16 20:37:11 had no problem with 5.4 Mar 16 20:37:35 so now I got two non-booting boards waiting for me at home ;) Mar 16 20:37:46 i should boot the x15... wonder if something broke.. Mar 16 20:38:08 x15, board now in hand.. Mar 16 20:38:09 maybe I fucked something up somehow Mar 16 20:57:03 zmatt: seems to boot fine... https://gist.github.com/RobertCNelson/0c0d85dc3281f87bf9834256da5fc9cf Mar 16 21:02:19 yeah, I'll just have to find out what I did wrong when I get home to look at the poor thing Mar 16 21:03:16 that's actually the first time, i've tried booting v5.10.x-ti... i've just been using the bbai.. my x15's are still on v5.4.x.. Mar 16 21:04:01 i'm adding a network setting for /etc/systemd/network/eth1.network (bottom connnector) Mar 16 21:04:55 I personally just use the switch mode instead of the dual vlan thing Mar 16 21:13:29 uio_pruss looks good on v5.10.x too.. Mar 16 21:13:47 https://www.irccloud.com/pastebin/vFdcFon0/ Mar 16 21:23:52 it's an incredibly simple driver, there's really not much that can go wrong Mar 16 21:26:35 which is also why it worked without modification on the am572x, and should likewise work on the tda4 Mar 16 23:01:41 jkridner: hm, odd, the link to the tda4vm trm (https://www.ti.com/lit/pdf/spruil1) is giving me a 404 Mar 16 23:10:30 Hi Mar 16 23:10:40 Got SFML to work, good Mar 16 23:11:01 I compiled from sourcee although it can be installed from package Mar 16 23:13:00 Though I had an issue with video mode incompatibility which was solved by autodection depth which i think needed to be set to 16 Mar 16 23:13:33 (otherwise some error with X11 : X Error of failed request: BadMatch (invalid parameter attributes) Mar 16 23:13:54 So going to develop with sfml if it performs well enough ... great Mar 17 02:49:05 Hi everyone. I have a BBB that has been sitting about for a long time. Now I would particularly like to use it to do some development work using the PRU and I am wondering what is the best Linux to get for this. It has Ubuntu on it right now. Somewhere around 18. I thought I would be able to just put the tools on to that. But after a bit of head Mar 17 02:49:05 scratching appears to not be the case. I'd prefer to do the development native on the device itself. **** ENDING LOGGING AT Thu Mar 17 02:59:56 2022