**** BEGIN LOGGING AT Thu Sep 26 02:59:57 2019 Sep 26 03:28:59 rcn-ee[m]: thanks for the anbox link .. been looking for somethiing like that Sep 26 03:29:39 wanna run android apps on a pi .. but .. hrm, yeah apps :( Sep 26 03:31:20 rcn-ee[m]: whilst you're about I spotted a couple of things on the eewiki could be tweaked :D Sep 26 03:32:25 I dunno whether that site is anywhere in VCS for submitting patches or PR ;p Sep 26 10:28:54 * rg-28 sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/UHpeNhHKVNGZGJTlXzuKgPFH > Sep 26 10:49:34 I bought a beaglebone black but it didn't come with a case...I imagine this needs a case right? Should I order a case or just use something simple? Sep 26 10:50:46 jrmu: it does only need a case if you want it to be cased Sep 26 10:51:05 can i just leave it inside the paper box? would it overheat? Sep 26 10:51:20 I'm mostly worried about dust and perhaps someone accidentally touching it and damaging the components Sep 26 10:51:32 jrmu: most certainly nothing will happen. mines are all lying naked on my desk Sep 26 10:51:42 ah interesting, so cases are unnecessary? Sep 26 10:52:15 jrmu: well, don't spill coffee over it, don't try to put it into a microwave... Sep 26 10:52:19 =) Sep 26 10:53:56 of course it won't stand rough handling, but for the usual things its totally fine just having it on your desk and plugged it. Sep 26 10:54:20 alright, thank you LetoThe2nd , makes sense Sep 26 11:06:34 Their are cases available for it, but if you are doing lots of experimentation the case is likely to get in the way. Sep 26 11:17:49 true Sep 26 11:55:42 I think that is the best way to look at it. Just keep your bench clean, also you may want to mount it on plastic stand offs for clearance over the surface you are working on. Just a "oh shoot" moment avoidance problem. Sep 26 12:17:36 ds2: I shared my thoughts with you yesterday on what I want to achieve. So, I want to start experimenting with KVM on bb-x15. And restricting of Android capabilities is one of my goals. (information flows should be under control) Sep 26 12:18:06 Hope that there will be am7 based beagleboards in the future Sep 26 14:04:18 embden: https://anbox.io/ Sep 26 14:06:03 rcn-ee: yes, I've seen this before. Sep 26 14:08:19 cool, yeah wanted to make sure you weren't trying to do something that's already been done. ;) Sep 26 14:10:19 rcn-ee: there are so many technologies... Sep 26 14:10:49 lxc, kvm, xen, I need to investigate all of them to some extent Sep 26 14:17:48 embden Well ARM is now at the point of having to try and be relevant to people. Not a position they are use to. MIPS and RISC-V are suddenly open source alternatives for example. Sep 26 14:19:13 GenTooMan: I believe that RISC-V was created exactly for this purpose Sep 26 14:24:52 competition is a good thing.. RISC really didn't come out from anywhere, it just finally came really cheap to make them, thus it was even easier to improve it more.. Sep 26 15:06:42 risc-v doesn't have multi-word load/store? that's really annoying, for device memory two 32-bit load/stores is not the same thing as one 64-bit load/store Sep 26 15:12:35 ah they did add 64-bit load/store (but not bigger) Sep 26 15:14:31 never mind that's just the 64-bit instruction set Sep 26 15:34:19 zmatt: I was so upset when found out that lowRISC will never be produced. Sep 26 15:34:38 it was the first project I wanted invest money in so much Sep 26 16:10:59 signed division is the annoying/useless variant (which I understand since C99 made the awful decision of standardizing it, but still) Sep 26 16:46:53 zmatt lots of bad decision made. we humans tend to be childish at times and make terrible choices. Sep 26 16:48:12 yes but the particularly awful thing here is that it was known to be the wrong choice, the choice was made (for C99) apparently just to be compatible with fortran -.- Sep 26 16:48:12 I'm not sure it's a good idea to deprecate the volatile keyword because "it's hard to implement" that's just asking for things to go even more wrong. Sep 26 16:48:54 they want to deprecate volatile? lol Sep 26 16:49:23 zmatt welcome to computer science where they are divorced purposefully from reality. Sep 26 16:51:49 actually it doesn't sound like they want to deprecate volatile entirely, just nonsensical uses of it Sep 26 16:51:58 feedback on lowering the alert by 5 degrees and raising the critical by 5 in https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/601fbb01af17134950377c242f72866a88535b8a/src/arm/am5729-beagleboneai.dts#L1121 Sep 26 16:52:02 ? Sep 26 16:52:58 jkridner[m]: what's the story behind avoiding mux mode 15 ? rcn mentioned there was a reason for it when I pointed out that several pins were muxed to 14 even though this is an invalid mux mode for those pins (they have no gpio function) Sep 26 16:56:41 ds2: I am also going to try kvm today on bb-x15, will see how it works Sep 26 17:16:33 embden: sounds interesting... thought about doing stuff like that but no time :( Sep 26 17:18:33 GenTooMan: it seems that the "Deprecating volatile" proposal (P1152R0) just has an ill-chosen title, the actual proposal seems benign, and in fact seems to be a good idea Sep 26 17:18:51 they're not touching sensible uses of volatile, just nonsensical ones Sep 26 17:21:46 lol, "There are three things all wise programmers fear: C’s corner cases, a hardware platform with no documentation, and the anger of an optimizing compiler." Sep 26 17:43:51 hello everyone :) Sep 26 17:44:35 Has anyone used JTAG on beagleone AI? Sep 26 17:44:38 just replace volatile with #pragma _NO_OPTIMIZE_ Sep 26 17:44:41 :D Sep 26 17:52:18 HI Sep 26 17:58:16 darjan: are you doing a poll, or do you have an actual question? :P (it is pointless to ask a question of the type "has anyone ...?" since the answer, regardless of whether it is "yes" or "no", is of no use to you) Sep 26 18:06:15 in most technical irc channels, the productive thing is to just ask your question directly in a sufficiently self-contained way that a knowledgable person who happens to glance at chat can type an answer and return his/her attention to something else. asking incomplete questions that require people to pry more details from you or trying to find someone to help you with an "has anyone..?" question ... Sep 26 18:06:21 ...greatly decreases the probability of being able to get help Sep 26 19:32:05 back to work on the u-boot submission.... added info into the SRM: https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#board-id Sep 26 19:33:59 riot test Sep 26 19:34:26 odd, riot isn't displaying for me, but it is writing. Sep 26 19:34:40 FAILED. Insufficient participants to begin rioting. Sep 26 19:37:02 darjan: https://github.com/beagleboard/beaglebone-ai/issues/21 <-- JTAG fix Sep 26 20:26:14 zmatt I kind of thought deprecating volatile seemed strange thing but hadn't looked into it. It would make more sense to restrict it's use and meaning to things that were rational. Sep 26 20:37:05 yeah they just used a needlessly inflammatory title Sep 26 20:45:51 #clickbait Sep 26 21:01:23 zmatt yeah... unfortunately they may have done that to get attention to the problem. Or they weren't thinking carefully of how to phrase things. Perhaps "Use of volatile considered ignorant" would make more sense? Sep 26 21:27:57 wasn't there a posting like that on LKML? Sep 26 22:02:41 Hello Sep 26 22:05:21 Hello all Sep 26 22:06:10 tip: if you have a question, just ask it and have patience. don't expect a reply to "hello" Sep 26 22:06:30 It is about 1 month and I am trying to enable ethernet over usb on beagle board Sep 26 22:06:42 Using g_ether Sep 26 22:06:58 I tried everything Sep 26 22:07:06 beagleboard or beaglebone? Sep 26 22:07:16 Beagleboard Sep 26 22:07:29 Using daisy yocto project Sep 26 22:07:34 the original one? xM? x15? Sep 26 22:07:42 Original Sep 26 22:07:46 oh yocto, then you should probably ask in #yocto Sep 26 22:08:06 setting up g_ether shouldn't really be hardware-specific anyway, it's just a linux kernel feature Sep 26 22:10:11 It says g_ether module is not found in modules. dep Sep 26 22:10:29 sounds like a kernel configuration issue Sep 26 22:10:42 When I run modprobe g_ether Sep 26 22:10:48 I have no idea how kernel configuration in handled in yocto, that's a yocto question, not a beagleboard question Sep 26 22:11:07 hence my suggestion to ask in #yocto Sep 26 22:11:56 Even on ubuntu 14.02 when I run ifconfig Sep 26 22:12:11 No usb0 is showing up Sep 26 22:13:19 if there's no module I guarantee there will be no interface ;) Sep 26 22:14:14 OK thanks Sep 26 22:14:58 that doesn't just apply to the beagleboards and/or usb, that applies to qemu, wifi, vanilla ethernet as well... Sep 26 22:15:10 no module, no interface Sep 26 22:15:28 and for many drivers, no firmware, no interface either Sep 26 22:15:38 yes it doesn't sound like there's anything beagleboard-specific about your problem, it's just a matter of learning how to configure yocto properly Sep 26 22:16:06 rndis (tethering) is just the same too :) Sep 26 22:18:08 isn't yocto/angstrom using that bitbake crap? Sep 26 22:18:56 actually g_ether may use CDC-ECM or RNDIS depending on kernel config, iirc Sep 26 22:19:04 zmatt: true Sep 26 22:19:43 https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html Sep 26 22:20:45 looks like there's some good stuf fin there Sep 26 22:20:49 it just sucks that we can't just use CDC-EEM... linux supports it, but as usual windows doesn't, nor macos I think Sep 26 22:26:37 -shrug- Sep 26 22:27:26 (CDC-ECM is meant for usb-attached real ethernet interfaces, while CDC-EEM is for tunnelling ethernet over usb.. it's simpler, more efficient, and doesn't make the device assign a MAC address to the host) Sep 26 22:30:45 I guess 14 years just isn't enough time to implement a 16-page specification Sep 26 22:33:56 a page a year?! Sep 26 22:34:07 you mean .. M$ hasn't reinvented it for its own use yet :p Sep 26 22:34:24 s/its/their/ Sep 26 22:34:41 ¯\_(ツ)_/¯ Sep 26 22:55:07 I was thinking of using EEM to send X data to a beagle bone black as a method of display extension if one doesn't need a MAC address that would probably work well.. Sep 26 22:55:54 I'm trying to understand that sentence but I'm failing miserably Sep 26 22:56:27 note that with EEM the device obviously still needs a MAC address, but with ECM it needs a MAC address for itself *and* it needs to assign one to the host Sep 26 22:57:31 (since with ECM the device contains two virtual ethernet controllers connected via a virtual ethernet cable, with one of those controllers attached to the device's OS while the other is attached (via USB) to the host) Sep 26 23:08:54 LOL sorry zmatt I can think some confusing thoughts at times. Sep 26 23:10:37 so for this newfangled BBAI thingy Sep 26 23:10:55 do I need to make new overlays and do I do it the same way I did for BBB? Sep 26 23:17:23 jkridner, rcn-ee[m] is there any general guidance for trying to get a cape that requires DTB overlays on the BBB up and running on the BBAI? Sep 26 23:29:48 wiley: overlays aren't supported yet Sep 26 23:31:14 ah, okay Sep 26 23:33:09 more problematically, pinmux kinda needs to be setup in u-boot and it doesn't yet have code to do so based on DT, it's hardcoded in u-boot SPL... though you can get away with doing it in DT in some cases (if the external hardware is tolerant to the possibility of glitches on I/Os when they're being reconfigured by the kernel) Sep 26 23:34:13 I don't think it would be that hard to fix this situation, but I may be terribly underestimating it (I do suck at estimating how much work something is) Sep 26 23:35:59 not sure what you mean by "in some cases" - if U-Boot can't load/apply a DTB overlay and capemgr in the kernel is very dead, what's left? Sep 26 23:36:35 is it that U-Boot is loading a single DTB and you can patch that to "hardcode" your overlay rather than detecting/loading dynamically? Sep 26 23:36:47 overlays themselves aren't the problem... I don't know if they're in the current u-boot on the ai, but if they're not then I can't imagine it would be hard to port that code from the beaglebone u-boot Sep 26 23:37:09 the problem is that they're not very useful if you're not allowed to do pinmux setup in them Sep 26 23:37:37 (in DT in general, hence in overlays specifically) Sep 26 23:37:42 oh, okay Sep 26 23:38:00 pinmux is currently happening in early U-Boot and can't happen in the kernel? Sep 26 23:38:08 and I explained what I meant with "in some cases" by the part in parentheses Sep 26 23:41:24 I mean the kernel can do pinmux and iodelay setup, but it is advised not to do so due to two problems: reconfiguring pinmux or iodelay can cause "glitches up to multiple nano-seconds in length", and reconfiguring iodelay has the additional issue that concurrent access by another initiator (e.g. pru or dma) to the same L4 interconnect as the iodelay module can cause system lockup Sep 26 23:42:11 of course not everything needs iodelay, and the glitches are also not necessarily a problem in every application, but it still sucks Sep 26 23:43:03 I'm pretty sure u-boot could do the setup based on the DT (including overlays) it has loaded, but that would need to be implemented Sep 26 23:44:40 (including some awkward low-level code to temporarily jump back into executing from SRAM instead of DDR to be able to enter I/O isolation mode) Sep 26 23:47:26 sounds complicated :/ Sep 26 23:50:47 it shouldn't be too bad... gathering the padconf and iodelay data from DT (into an array in SRAM) should be fairly straightforward with libfdt already being in u-boot, and the transition code would basically be: copy helper function to sram, call helper function where that helper function does: suspend emif, enable I/O isolation, copy padconf/iodelay settings from sram to control module / iodelay ... Sep 26 23:50:54 ...module, disable I/O isolation, resume emif Sep 27 00:32:33 zmatt: is there any more details on the 'glitching'? does input pins suddenly become outputs for a while or ? Sep 27 00:32:58 I really wish I had more details, but I imagine stuff like that yes Sep 27 00:33:29 glitching is so vague Sep 27 00:33:34 indeed Sep 27 00:33:47 if we knew what can happen, the HW can be adjusted :/ Sep 27 00:34:35 yeah I really wish they'd give an explanation of what's going on exactly Sep 27 01:27:10 wiley: overlays are supported on the bbai via u-boot (the same commands that we use for the bbb are enabled) we just don't have any examples yet.. Sep 27 01:28:00 zmatt: i don't think TI want's to publish anything that says by doing xyz with the pinmux can make the part short out.... Sep 27 01:29:57 any other linode user out their with block storage noticed a massive speed reduction lately? Sep 27 01:55:15 where can i read more about the bb-ai chip capabilities Sep 27 01:58:29 is there any sample code for tensorflow Sep 27 02:12:07 rcn-ee[m]: don't use the block stuff but everything else is normal Sep 27 02:41:26 rcn-ee[m]: ah overlays are supported? good to know Sep 27 02:41:59 of course that doesn't solve the pinmux problem yet Sep 27 02:44:09 rcn-ee[m]: I very much doubt it can "make the part short out", unless you mean due to a drive conflict with external hardware (although a series resistor should suffice to cope with that, especially since it's only a few nanoseconds) **** ENDING LOGGING AT Fri Sep 27 02:59:57 2019