akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #beagle
<set_> Did the eLinux pages ever get the "update?"
<set_> Never mind me once again. I saw something but now it is gone. Blimps, bleeps, and _______.
<set_> If there was only an elevator controlled by the BBB to handle my tasks!
<set_> If only...
<set_> I got like a ka-zillion tasks and no one will allow me to work. Southern draw y'all. Poof.
<set_> I could have fixed the gate, the tasks of manipulation, and other things...BUT, no one will rely on me to handle something of such fun! Argh.
<set_> No matter how odd it gets, do not give up just yet!
<set_> There are people counting on you and your org to produce, give back, and learn from currently (ME).
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<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!]
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
shodan45 has quit [Ping timeout: 256 seconds]
shodan45 has joined #beagle
otisolsen70 has joined #beagle
j0rd has quit [Quit: ZNC - https://znc.in]
j0rd has joined #beagle
Shadyman has quit [Ping timeout: 240 seconds]
Shadyman has joined #beagle
johanhenselmans has quit [Quit: johanhenselmans]
johanhenselmans has joined #beagle
johanhenselmans has quit [Client Quit]
rob_w has joined #beagle
florian has joined #beagle
ikarso has joined #beagle
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> (*beaglebone-derived-custom-board-barbecue, technically)
<Guest2984> Thank you! ^^
buzzmarshall has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
Guest2984 has quit [Ping timeout: 256 seconds]
rob_w has quit [Quit: Leaving]
jfsimon1981 has quit [Ping timeout: 272 seconds]
lucascastro has quit [Ping timeout: 268 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt> argh, it really sucks that if u-boot fails to apply an overlay it just completely fails to boot at all
vagrantc has joined #beagle
_whitelogger has joined #beagle
lucascastro has joined #beagle
florian has quit [Quit: Ex-Chat]
lucascastro has quit [Ping timeout: 240 seconds]
fakuivan has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
fakuivan has joined #beagle
jfsimon1981 has joined #beagle
lucascastro has joined #beagle
<zmatt> 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
<zmatt> it also applied against 5.10-ti
<rcn-ee> cool, i'll merge that... looks like i did similar (patches 1 and 3..) https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/8fdb75912c67d8c7c1c4072b13096f312aa8a84b
<zmatt> yeah, drop patch 3, reset is handled by the new ti,sysc stuff
<zmatt> hmm, I didn't change patch.sh ... I think it got picked up anyway?
<zmatt> no point in enabling CONFIG_UIO_DMEM_GENIRQ, it cannot be configured via DT
<zmatt> it did not, I'm an idiot
<zmatt> lol
<zmatt> I should have checked that it actually applied the patch
<rcn-ee> ah okay, i'l ldop 3..
<rcn-ee> 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
<zmatt> oh right those are hooked up to a different node
<rcn-ee> found these two tests, do you have more that i should run?
<zmatt> intc-test.py to test irqs
<zmatt> if ddr-ping.py and intc-test.py work, everything works
<rcn-ee> so, i'll remove the 'de-assert' patch and retest... but it looks like we can ship it? ;)
<zmatt> you already tested ddr-ping, not intc-test
<rcn-ee> does intc_test.py ever stop?
<zmatt> no
<zmatt> just ctrl-C
<rcn-ee> ah, okay, it's just event 16 and event 17...
<rcn-ee> must be a pass then?
<zmatt> yes
<rcn-ee> perfect!
<zmatt> what's your overlay look like now?
<rcn-ee> the irq is the only diff from yours..
<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
<zmatt> 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
<zmatt> but I'm probably the only perform in the world who cares
<zmatt> *only person
<rcn-ee> wonder if mainline said no to that wrapper?
<rcn-ee> sounds like something useful, that wasn't considered generic enough. ;)
<zmatt> or maybe &pruss is now the wrapper
<rcn-ee> okay, also pulled in your 2nd patch..
<zmatt> it still does some stuff, but not enough to justify its existence
<zmatt> I'm actually not sure why the soc bus wrapper existed in the first place
<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> maybe sdl ?
<rcn-ee> directfb2? it's back... https://github.com/directfb2
<zmatt> or qt5 with the linuxfb backend
<jfsimon1981> sdl
<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..
<rcn-ee> x15, board now in hand..
<zmatt> maybe I fucked something up somehow
ikarso has joined #beagle
Shadyman has joined #beagle
<zmatt> yeah, I'll just have to find out what I did wrong when I get home to look at the poor thing
<rcn-ee> 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..
johanhenselmans has joined #beagle
<rcn-ee> i'm adding a network setting for /etc/systemd/network/eth1.network (bottom connnector)
xet7 has quit [Quit: Leaving]
<zmatt> I personally just use the switch mode instead of the dual vlan thing
xet7 has joined #beagle
ogra has quit [Changing host]
ogra has joined #beagle
<rcn-ee> uio_pruss looks good on v5.10.x too..
<zmatt> it's an incredibly simple driver, there's really not much that can go wrong
<zmatt> which is also why it worked without modification on the am572x, and should likewise work on the tda4
<zmatt> jkridner: hm, odd, the link to the tda4vm trm (https://www.ti.com/lit/pdf/spruil1) is giving me a 404
otisolsen70 has quit [Quit: Leaving]
<jfsimon1981> Hi
<jfsimon1981> Got SFML to work, good
<jfsimon1981> I compiled from sourcee although it can be installed from package
<jfsimon1981> Though I had an issue with video mode incompatibility which was solved by autodection depth which i think needed to be set to 16
<jfsimon1981> (otherwise some error with X11 : X Error of failed request: BadMatch (invalid parameter attributes)
<jfsimon1981> So going to develop with sfml if it performs well enough ... great
ikarso has quit [Quit: Connection closed for inactivity]