<set_>
although selfish and blindly needing to fit, I will take all info. at your leisure.
<set_>
@zmatt: Did you ever reply to those odd questions I had for you and that lib. you produced?
<set_>
I am asking b/c I have the overlay on during boot and I am trying to alter the pinctrl.h file (most likely) w/out knowing it.
<set_>
I looked through the logs. It seems my computer must have bit the dust that day or something else happened that I am not fully aware of currently.
<set_>
GenTooMan: did you see anything?
vagrantc has quit [Quit: leaving]
<set_>
In 15 minutes is when I will be rebooting my 'puter. Please do not post if you are planning on replying until I can get back.
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
<set_>
I am back!
<set_>
Boring, yawn, yes. I know. But...to the quarter of BBB land!
thinkfat has quit [Ping timeout: 256 seconds]
thinkfat has joined #beagle
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
Shadyman has quit [Remote host closed the connection]
Posterdati has quit [Ping timeout: 256 seconds]
Posterdati has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
Guest2984 has joined #beagle
<Guest2984>
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.
<zmatt>
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
<Guest2984>
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.
<zmatt>
those are not beaglebones, they're custom boards
<zmatt>
only loosely based on the beaglebone black
<Guest2984>
Ah ok! Thanks :) I will see if I can get the temp range from Bitmain then.
<zmatt>
yeah, their schematic and parts list isn't public afaik, so they're the only ones who can give a good answer on that
<zmatt>
my guess would be 0 to 85 ͏°C
<Guest2984>
Thank! I'll note that down, and see if I can get an official answer! Thanks for the help! :)
<zmatt>
junction temperature, so you obviously can't actually run them in a 85 ͏°C environment
<zmatt>
(but the max environmental temperature depends on how effectively components can get rid of their heat)
<Guest2984>
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 ^^
<zmatt>
it's also not a binary thing... like, the question isn't "will it work?" but "how long will it work?"
<zmatt>
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
<Guest2984>
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 ^^
<zmatt>
Guest2984: section 5.3 of the AM3358 datasheet is also worth noting
<zmatt>
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
<zmatt>
most likely because running at a lower performance point allows for lowering supply voltages, which reduces the rate at high damage accumulates
<zmatt>
*at which
<zmatt>
they also require lowering DDR3 speed from 400 MHz (DDR3-800) to 333 MHz (DDR3-667)
<zmatt>
when going above 105 ͏°C junction temperature
<Guest2984>
Oh thanks, I will note that down and see if I can find that document, I think I found the wrong document.
<zmatt>
(ram doesn't support such temperature, but the AM335x junction temperature may be higher than that of the ram in same environmental conditions)
<zmatt>
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"
<zmatt>
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)
<zmatt>
running a part outside the binned temperature spec will of course increase the probability of random issues, similar to overclocking
<zmatt>
in addition to reducing the device lifetime
ME has left #beagle [#beagle]
<zmatt>
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
<Guest2984>
Thanks for the link! :) I had to a accept a delivery. I will checkout the document you linked.
<zmatt>
Guest2984: I'll be afk for a while.... anyway, good luck with your beaglebone-barbecue ;)
<zmatt>
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)
<rcn-ee>
ah very true...thanks to the compatible
<zmatt>
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
<rcn-ee>
all tests pass.. tag and bag it, and ship it..
<zmatt>
uio-pruss, alive forever more
<rcn-ee>
and it's one less patch since v4.19.x (reset..)
<zmatt>
indeed
<rcn-ee>
still need to get it to work on tda4....
<zmatt>
shouldn't be too hard
<zmatt>
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
<rcn-ee>
wonder if we can patch uio to steal it from:
<zmatt>
that would be much more complicated and quite gross
<zmatt>
like, there's no reason for that node to exist when using uio-pruss
<zmatt>
it just does because we're repurposing the node that was meant for remoteproc
<zmatt>
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
<jfsimon1981>
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
<jfsimon1981>
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
<jfsimon1981>
any idea which is a simple graphic environment i could use, just a 2d environment
<zmatt>
(which nowadays also supports using the modern drm api instead of only the legacy fbdev)
<jfsimon1981>
ok hx
<jfsimon1981>
thx
<jfsimon1981>
i'm looking into it
<zmatt>
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 :/
<zmatt>
had no problem with 5.4
<zmatt>
so now I got two non-booting boards waiting for me at home ;)
<rcn-ee>
i should boot the x15... wonder if something broke..