**** BEGIN LOGGING AT Tue Oct 29 03:02:49 2019 Oct 29 03:04:45 lol Oct 29 03:05:10 yeah my understanding is that it's a reference to being a low-cost platform for TI's "Deep Learning" (TIDL) sdk Oct 29 03:08:19 I just purchased my first BBAI today, is there not a headless image/download? Oct 29 03:08:59 there is but for some reason not on the latest-images page Oct 29 03:13:04 bastukee: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots you can find a variety of images here Oct 29 03:13:57 jkridner[m]: ^ :p Oct 29 03:17:57 zmatt: thanks for pointing me on the right direction. I think I found it Oct 29 03:18:22 I see an IOT and a Console debian 9 version for X15/AI Oct 29 03:18:56 bastukee: there are basically two headless images: "iot' with is the featureful version and "console" which is a very minimal image for people who prefer to just install whatever they want themselves Oct 29 03:19:23 basically on the iot image stuff *should* just work, on the console image stuff only works if you make it work ;) Oct 29 03:22:21 now that I thought about it, one of the great features I liked about the angstrom distro is creating a custom image to do just what you wanted. That's not to hard with Debian as long as they have the binary packages made up. You just need the console version and a script to load what you need. Oct 29 03:23:28 zmatt: That answers my question, I may grow to console but not yet if I'm just learning Oct 29 03:41:29 ls Oct 29 03:41:44 wrong window Oct 29 03:42:29 wrong X ?! XD Oct 29 03:48:32 That reminds me of when I somehow managed to have window under X open that didn't process keypresses and sent it to the window behind it. That created an interesting mess. Oct 29 03:49:12 lol Oct 29 03:50:12 yoikes! Oct 29 03:55:42 Yes it was very confusing at first. It was weird because mouse movement and clicks worked.. then I started seeing the web browser window behind it doing weird flickering things. Finally I alt tabbed to a shell and literally used "kill -9" to it I couldn't close it through the menu, might have been the keyboard accelerator for the app. Oct 29 05:46:45 imagenet has the oddest things in it Oct 29 05:47:48 'bullet proof vest' is an image in that dataset Oct 29 15:24:42 hey :) Oct 29 15:25:24 the LCD4 cape is still loading the CPU to 100% when the screen got touched. Oct 29 15:26:00 zmatt: do you remember that you looked at the kernel driver and noticed it was using too much interrupts? Oct 29 15:50:27 I seem to have hosed my AI. I tried to run a flasher w/o updating uEnv.txt. Now it appears to be stuck in a boot cycle. Oct 29 15:51:20 It happened to me some days ago. My problem was no more room on the eMMC Oct 29 15:51:59 It never actually ran the flasher I suspect, but who knows? Oct 29 15:53:04 on my MicroSD the image left 66MB free, the eMMC did'nt had even that and was booting but stuck somewhere. Dunno if it is your case Oct 29 15:53:51 How do I know if it even tried to flash it? And how did you recover? Oct 29 15:54:25 Search so far has yeilded no love. Oct 29 15:54:50 i have a BB Black, Oct 29 15:55:11 it flashed 'cause the blue leds goes in "supercar mode" Oct 29 15:55:21 then it shutdown Oct 29 15:55:28 I'm familiar with the Black. Flashed it many dozens of times. Oct 29 15:55:31 also, it wrote everything on screen :D :D Oct 29 15:56:10 Expected similar from the AI but it's been so long I did't recall having to update uEnv.txt. When it didn't flash I went and looked, but now it won't do anything. Oct 29 15:56:59 i think i'm too much a noob to be helpful :) Oct 29 15:57:10 Windows makes its "connect" noise, then the "disconnect" noise, and just does that over and over. Oct 29 15:57:24 so your don't boot from eMMC and from SDCard neither? Oct 29 15:57:27 Since it doesn't have a barrel jack I can't power it w/o using USB. Oct 29 15:57:47 Nope. SD is removed. eMMC appears to be corrupted. Oct 29 15:58:24 afaik, flashing with USB power is dangerous 'cause low amperes availabòe Oct 29 15:58:47 the reccomend the power suplly with 2A Oct 29 16:01:03 USB3 is supposed to have "more". Haven't found any recommendations on that so far. The "getting started" part of the web site is not very well laid out for determining anything board-specific. Oct 29 16:01:42 then i've reached the top of my knowledge :D Oct 29 16:02:04 It just says write the image, follow the instructions (I forgot to do), and it'll flash. Oct 29 16:02:50 well, you still have the SD, just boot from there and do it again Oct 29 16:02:57 I would not have expected the instructions I forgot to do would cause corruption. Those instructions link the flasher script to the boot process. If I'm reading them correctly it should have done nothing. Oct 29 16:04:01 The SD is flasher image. I can't boot from it. That seems to imply there is a bootable image at the site, though. I'll go look. Oct 29 16:10:03 Ragnorok: a flasher image has "flasher" in the name Oct 29 16:10:10 a normal standalone image does not Oct 29 16:10:27 I was hoping it would be that easy. lol Thanks. Oct 29 16:11:02 note that the "updating uEnv.txt" instructions are to turn a normal standalone image into a flasher image Oct 29 16:11:30 the whole point of a flasher image is to not have to do anything, you just boot from it and it'll flash eMMC Oct 29 16:11:32 Oh. So it did try to flash, seems like, and failed. Oct 29 16:11:44 That is exactly what I expecte to happen, actually. Oct 29 16:12:20 Instead it did the boot loop with the flasher installed, so I removed it, and it keeps doing the boot loop. Oct 29 16:13:19 what did you do exactly? I've seen people manage to do really weird stuff, like changing /boot/uEnv.txt to turn it into a flasher that reflashes the SD card and silly things like that Oct 29 16:14:26 I snagged am57xx-eMMC-flasher-debian-9.11-iot-armhf-2019-10-21-4gb.img.xz, I used WinDiskImager to write it to SD, I stuck it in the AI, and I powered it up. Same process I'd use for a Black. Oct 29 16:15:04 does WinDiskImager verify the sd card contents after writing it? if not, consider using a tool that does, like Etcher Oct 29 16:15:38 I don't actually know. I've been doing this for two years or more and never had an issue. Oct 29 16:16:12 I've written dozens if not hundreds of images in that time. Oct 29 16:16:14 well there's a first time for everything, sd cards are not perfectly reliable and have finite lifetime (and their mode if failure is random bitflips) Oct 29 16:16:30 True. Sadly. Oct 29 16:16:36 having used a particular sd card a lot just increases the probability of this having become a problem :) Oct 29 16:17:30 also, make sure the BBAI stays sufficiently cool during flashing... if it has a thermal shut down during flasher I imagine you won't have a working system on eMMC ;) Oct 29 16:19:11 zmatt: the LCD4 cape is still loading the CPU to 100% when the screen got touched. do you remember that you looked at the kernel driver and noticed it was using too much interrupts? Oct 29 16:19:36 I don't, sorry Oct 29 16:19:47 np :) Oct 29 16:19:52 * zmatt is a goldfish, blub blub Oct 29 16:20:30 i lost the log of that chat, and it's time to deal with this problem Oct 29 16:20:49 but i was'nt sure if something was already done in newer kernels... Oct 29 16:20:52 zmatt: ++ Oct 29 16:21:38 It does verify but it's a separate step that I probably have never done. In this instance it verifies success. Oct 29 16:22:23 Parduz: tsc_adc driver hasn't seen any real changes in a long time....... Oct 29 16:22:49 Most of the new lcd's switched to an i2c cap touch sensor.. Oct 29 16:23:20 Parduz: when was this conversation approximately? Oct 29 16:24:18 rcn-ee[m]: oh... ok. The problem is that when you touch the screen the CPU goes to 100%, affecting even the refresh of GUI apps (you don't see the buttons going down, or the page switching until you raise the finger) Oct 29 16:24:32 zmatt: uh .... about a year ago? Oct 29 16:24:43 +/- 3 months :D Oct 29 16:25:04 It never ran long enough to overheat. It immediately started the boot loop on power up w/ the flasher SD in. Hopefully it will boot from SD at all. Oct 29 16:25:29 Ragnorok: that sounds like something really weird went wrong Oct 29 16:26:55 Lucky me. (grimace) Oct 29 16:27:08 rcn-ee[m]: the impressio was there too much interrupts being generated ... the driver could have been less "tight" and leave more time for other tasks Oct 29 16:27:21 I presume an USB3 connector is an adequate power source? Oct 29 16:27:26 Parduz: was your nickname "Parduz" back then? Oct 29 16:27:36 yup Oct 29 16:27:45 Ragnorok: you mean the USB-C connector? yes Oct 29 16:27:59 assuming the source is an adequate power source Oct 29 16:28:33 i saved the link to the file in the 4.9.y branch Oct 29 16:28:49 Just making double-dog sure. It's definitely in an USB3 plug on the laptop end, so it shouldn't have any power issues. Oct 29 16:29:23 Parduz: there's no search results for Parduz in my IRC logs from 2018-06 .. 2019-02 Oct 29 16:29:38 doh Oct 29 16:31:30 that link on my HD was created on 18 oct 2018.... so i'd say it were that time... Oct 29 16:34:11 before a few days the last time "Parduz" shows up in my logs was 2 years ago Oct 29 16:34:34 (and none of the conversation in 2017 seems relevant) Oct 29 16:35:07 yup... before that we (you after chatting to me) e-mailed rcn-ee[m] about the patch for the LCD "jitter" problem that "slipped" out in newer kernel versions. But that was before, as i said. Oct 29 16:35:45 well, i don't know. :) Oct 29 16:36:16 ah, it was parduz, not Parduz Oct 29 16:36:51 2018-09-25 Oct 29 16:36:55 lol..... sorry. As a Windows man, i'm not so case sensitive :D Oct 29 16:38:24 i'd guess you could search for "interrupts" then and find your messages about it Oct 29 16:39:35 http://logs.nslu2-linux.org/livelogs/beagle/beagle.20180926.txt Oct 29 16:39:57 I guess in the timezone of the logging bot it was the 26th already :) Oct 29 16:39:59 ah, great Oct 29 16:40:04 your conversation starts basically at the top Oct 29 16:40:18 I think Oct 29 16:41:05 " if it's literally blocking your process with continuous interrupts then everything will be frozen, i.e. an ssh shell will also be unresponsive" that was what i recall .... thanks Oct 29 16:44:03 well, if rcn-ee[m] is still here and he's willing, i could take any advice about that problem. Oct 29 16:45:54 obviously also from you, zmatt, if you have any. Oct 29 17:01:27 Parduz: do you have a fix we can push mainline? Oct 29 17:02:41 It really annoys me how I search for "BeagleBone AI boot from SD card" and all the hits are about the Black. Oct 29 17:03:19 Well not all, but all regarding boot, which are all that matter. Oct 29 17:05:25 Getting started claims it should "just work". It doesn't. I still have boot loop. Oct 29 17:05:51 rcn-ee[m]: Me? I'm startiung to look at it now, and i'm totally new to this... Oct 29 17:06:17 i was hoping in a fix from you :P Oct 29 17:06:35 well, some tips and direction, really. Oct 29 17:07:04 Except now. I guess first time isn't a charm. So it's working from SD. Whew. Oct 29 17:07:52 Well, i know nothing of the ts_adc internal, our current patch was from someone who spent a lot of time tweaking things for his lcd7 display.. Oct 29 17:08:13 So if I update uEnv.txt on this SD it will flash itself to eMMC, or at least try. Just want to be double dog sure before I hose up something else. (wry grin) Oct 29 17:08:41 oh .... ok Oct 29 17:09:45 This AI image has an "enable x15" line and script that's "v3-no-eeprom". Oct 29 17:10:55 maybe the iot image hasn't been prepared for the AI yet? I dunno Oct 29 17:11:41 no wait rcn-ee[m] mentioned it was I think Oct 29 17:11:53 It came from rcn-ee's site. But that's later. I just want to be sure uncommenting the x15 flasher line on this bootable SD will attempt to flash, because I'm no longer confident. (grin) Oct 29 17:12:18 I feel like that's *supposed* to work for reflashing eMMC Oct 29 17:12:44 I feel that I already booted the iot image on my AI Oct 29 17:12:53 Not improving the confidence level. lol Guess I'll try it and keep the fingers crossed. Oct 29 17:13:08 well I don't have a BBAI yet so I can't verify any of this for myself Oct 29 17:13:19 Ragnorok: if you don't want to edit /boot/uEnv.txt ther eis a flasher.. Oct 29 17:13:42 rcn-ee[m]: I don't mind editing. Just wanted to be sure I did the right edit. (grin) Oct 29 17:13:46 https://rcn-ee.net/rootfs/bb.org/testing/2019-10-28/stretch-iot/am57xx-eMMC-flasher-debian-9.11-iot-armhf-2019-10-28-4gb.img.xz Oct 29 17:13:59 but yeah, it's the same Oct 29 17:14:26 I tried the 10.21 flavor I downloaded yesterday and it appears to have messed up my AI. (pout) Oct 29 17:14:58 what did it mess up? Oct 29 17:15:04 I see the "cylon". \o/ Oct 29 17:15:19 It did a "boot loop" over and over, and no "cylon". Oct 29 17:16:16 Windows made the device noise, it made the disconnect noise, the LEDs on the AI flickered, then it repeated, in about a 25 second loop. Oct 29 17:16:40 did you have external power? or usb connected to windows? Oct 29 17:16:57 USB3 cable to a USB3 port. Oct 29 17:17:24 That's what I'm using now as well. Oct 29 17:17:31 thanks to usb.if that doesn't help.. doh. ;) Oct 29 17:17:47 the only thing i can think of is power starvation.. Oct 29 17:17:56 so it was brownouting.. Oct 29 17:18:01 Sounds like I shouldn't use even USB3? I have to patch in power via the header? Oct 29 17:19:38 no, the usb3 spec has lots of optional power options.. depending on your pc/etc it might not provide enough.. Oct 29 17:19:56 The full system flasher seems to have worked fine. Oct 29 17:20:34 rcn-ee[m]: may i tell you that the bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img does'nt ryn well on my BBBrevC? it runs from SDCard but not in the mEEC: too large, not enough free space, the BBB boots but then it stucks somewhere. Oct 29 17:20:35 I'm in and disabling the EVE cores to get it to cool down some. Oct 29 17:24:02 I'll try the 10-28 flasher and see what it does. (shrug) Oct 29 17:24:11 Parduz: it should be fixed with: https://github.com/RobertCNelson/omap-image-builder/commit/3bab6de0ad4c0a320bb15d5a589b1156cce74bb9#diff-83fc9d8c0c7c103bae57957c0246792d Oct 29 17:24:39 That was on Sept 25th Oct 29 17:26:02 nope, i tried that image the past week Oct 29 17:30:43 Parduz: what image date? Oct 29 17:31:37 bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz from the "latestimages" page Oct 29 17:32:19 then the "bone-eMMC-flasher-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz" Oct 29 17:32:34 also BBBW-blank-debian-9.9-lxqt-armhf-2019-08-03-4gb.img Oct 29 17:33:27 Parduz: i just stated that i had fixed that issue on Sept 25th... DO images after that day still have the issue? Oct 29 17:33:40 08-03 = August 3rd.. Oct 29 17:34:05 sorry, my mistake, i was on the phone meanwhile Oct 29 17:34:30 nope, switched on the IOT one and loaded UI stuffs from there Oct 29 17:34:51 i mean, "installed" Oct 29 17:36:04 the lxqt got big from all the ai's opencl/tidl stuff, so i ripped all that out and made a new lxqt-tidl varient, which defaults to a 6gb size vs 4gb.. Oct 29 17:37:12 ok, good to know, thanks Oct 29 18:04:27 10-28 IoT seems to be working. I have 'cylon'. \o/ Oct 29 18:11:15 This has the "getting started" thing in it, but 7.2 doesn't connect. Is there info on what's enabled in the IoT? Search has again failed me. Oct 29 18:12:14 Again. First time must not be a charm. I just tried again, for feces and grins, and *ding*. Connect. (wry grin) Oct 29 18:15:08 If PM_GPU_PWRSTST is zero that should be off as well, right? Oct 29 18:30:52 The connman on the AI doesn't seem to match what I see for debian in general, and I don't see any clear means for setting static IP. On a black we had to twiddle scripts and conf to eliminate connman and use the normal /etc/network. I suspect that will be necessary here? Oct 29 18:32:27 systemd-networkd++ Oct 29 18:33:06 Ragnorok: connman has a magic string for doing eth0 static, there is an example in /etc/network/interfaces Oct 29 18:35:18 Oh. Spiff. Thanks! Oct 29 18:36:32 zmatt: finally! http://arago-project.org/pipermail/meta-arago/2019-October/012029.html Oct 29 18:37:33 rcn-ee[m]: not yet complete, but almost there Oct 29 18:38:22 so what does this mean exactly? Oct 29 18:38:34 denix: yeah, it's missing the mesa patch.. :( i got excited after reading the first one.. Oct 29 18:40:06 rcn-ee[m]: there are couple issues even with mesa patch, there's some work going on internally to address those Oct 29 18:41:53 zmatt: this mainly gives SGX some facelist to have EGL 1.5 support (incomplete, but enough). lot's of latest components start requiring it Oct 29 18:41:58 yeah, mesa can be fun, its' pretty fast development, so anything that get's pushed out will have some fun maintenance Oct 29 18:42:04 facelift Oct 29 18:42:54 denix: ah, so mesa is basically helping to emulate newer stuff in terms of older stuff? does it also mean normal openGL (non-ES) would work? Oct 29 18:44:24 zmatt: afaik, no full GL in SGX, unless you emulate it in SW Oct 29 18:45:26 I know there are libraries that try to map GL to GLES, hence I was wondering whether mesa would be doing that... I don't quite understand its role yet I guess Oct 29 18:48:18 zmatt: as of mesa, it provides frontend, while backend is still pvr. it used to be some very old frontend libs (i.e. old snapshot of mesa) was bundled into SGX blobs. this is an attempt to de-couple those and use newer upstream mesa Oct 29 18:48:38 rcn-ee[m]: wouldn't upstreaming the abandoned patches in bb-kernel save you a lot of work in forward porting them? Oct 29 18:49:13 rcn-ee[m]: I'm kind of a bit mystified as to why you're maintaining a huge collection of kernel patches instead of upstreaming them? Oct 29 18:50:30 rah: are you volunteering to upstream them? Oct 29 18:50:51 rah: sorry, which ones do you mean.. ;) lots of reasons for not-mainline... Oct 29 18:51:12 denix: what constitutes the "frontend" ? like, the platform glue (the WSEGL layer) ? Oct 29 18:51:48 reasons vary from: being outright rejected by mainline, to we dissagree with a direction of mainline.. or it was rejected due to api breakage that we didn't care about.. Oct 29 18:52:40 some patches might be upstreamable *maybe*, but it would take substantial energy to find out and forward-porting is often not much work Oct 29 18:55:02 zmatt: ps, Drew Fustini got some direction from the gpio maintainers do re-do bone-pinmux-helper in a mainline way... I told him to jump on irc and bug you.. ;) Oct 29 18:55:33 oh boy :) Oct 29 18:56:04 the same gpio maintainers who think the gpio chardev is an acceptable replacement of the sysfs interface? Oct 29 18:56:08 he want's to jump, but i wanted him to talk to you about things it "should" have. ;) Oct 29 18:56:38 maybe: Linus Walleij Oct 29 18:57:42 I'm curious what they're thinking w.r.t. bone-pinmux-helper though, since its job is a tough one to do in a way that's not a gross hack Oct 29 18:58:45 I personally don't care much about it in production, but I understand its value for newcomers to the platform for whom customizing a DT is a bit intimidating Oct 29 18:59:12 (I *do* care a lot about gpio-of-helper which I see as an essential driver) Oct 29 18:59:47 rah: only 54 patches in 5.4 branch of bb-kernel.. 1 backport, 10 from (aufs/wireguard/can_isotp), so only 43 real patches.. it's getting closer to 0.. ;) Oct 29 19:01:05 30: 12 are for an imx board.. 1 for an old version of systemd (thank you buster) Oct 29 19:01:34 rah: it'll hit single digits in a few more releases.. Oct 29 19:01:34 when are the official images moving to buster? Oct 29 19:02:42 zmatt: wifi/bluetooth should now wokr for the AI on buster.. i'm working on ti's opencl/tidl layer, getting close on node-red 1.0.x working again, then it's just cloud9-ide bugs.. Oct 29 19:03:38 the AI kinda stuck on this patchset: https://community.cypress.com/community/linux/content?filterID=contentstatus[published]~objecttype~objecttype[document] Oct 29 19:03:50 i've back-hacked our v4.19.x to work with that.. Oct 29 19:04:15 rcn-ee[m]: Any ideas on making it run cooler? Afaik I have everything turned off except IPU, that I can turn off. It's still running warmer than I'd like, consider we'd like to completely enclose it. Oct 29 19:05:20 Ragnorok: sadly, that's jkridner and zmatt ... i'm mostly working on keeping the random assortment of packages people bug us about.. Oct 29 19:05:27 ..working... Oct 29 19:06:02 Roit toe. Oct 29 19:06:24 Ragnorok: IPUs should be off by default (unless you mean the "IPU" clock domain, which seems to be unrelated to the actual IPUs) Oct 29 19:07:36 I did a omapconf dump prcm | grep PWRSTST and looked at what was zero on the premise that's "Off". Oct 29 19:08:39 zmatt: the amount of work required for forward-porting is ever-increasing as time passes and the patches aren't upstreamed Oct 29 19:09:36 rcn-ee[m]: "only 43"?! Oct 29 19:10:05 rcn-ee[m]: if it'll hit single digits in a few more releases, that implies that the patches are being upstreamed? Oct 29 19:11:20 rah: "functionality" upstream. .;) Oct 29 19:12:17 rcn-ee[m]: you mean the patches aren't needed because a different implementation went into mainline? Oct 29 19:13:45 Ragnorok: well IPU2 is part of PD_CORE so it can't really be turned off (except maybe in suspend), though it can still be clock-gated of course Oct 29 19:13:48 correct.. Oct 29 19:14:52 rah: but each patch it's own story.. so you can't just say push them all upstream.. ;) Oct 29 19:15:32 rah: if you have one your specifically interested in, i can point you to what happened, or what he plan is going forward.. Oct 29 19:16:03 I followed the pattern used by USB in /etc/network/interfaces to set a static IP for eth0. If I plug in USB I can see eth0 is the right IP, but I can't ssh to it. I don't see anything in sshd_config that looks like it's excluding i'faces. Oct 29 19:16:51 Ragnorok: only root is blocked. Oct 29 19:17:11 As I'd expect. It won't even give a login w/ puTTY. Oct 29 19:18:01 can you share the output of 'ip addr' and 'ip route' ? Oct 29 19:18:04 It actually looks just like a regular interfaces entry for eth0. Oct 29 19:18:06 Sure. Oct 29 19:19:24 rah: also the number of patches is less important than how invasive they are... it's actually better to have multiple smaller patches than one giant one, both for forwarding-porting and for upstreamability Oct 29 19:21:14 I've been having a very consistent first failure / second works all day. Annoying, but it's working now. Oct 29 19:21:23 lol Oct 29 19:23:22 rcn-ee[m]: there is one patch that interests me which is 0001-cpsw-search-for-phy.patch Oct 29 19:23:39 although that doesn't seem to fix all my problems Oct 29 19:23:50 rah: that's fixed in u-boot... it'll be going away.. Oct 29 19:23:57 I still get Oct 29 19:23:58 [ 27.066603] cpsw 4a100000.ethernet: phy "/ocp/interconnect@4a000000/segment@0/target-module@100000/ethernet@0/mdio@1000/ethernet-phy@0" not found on slave 0 Oct 29 19:24:06 they phy-id rename in 5.x. is going to break that one.. Oct 29 19:24:11 it's only a partial workaround anyway Oct 29 19:24:20 the only real way to fix it is in hardware Oct 29 19:24:33 I didn't want to read that Oct 29 19:24:40 you're saying there's a hardware issue? Oct 29 19:25:22 rah: it's a buggy patch.. it works about 75% of time.. Oct 29 19:25:31 rcn-ee[m]: I noticed Oct 29 19:25:38 the proper fix is to run a gpio pin to the reset on the phy... Oct 29 19:25:53 currently the phy's reset line is muxed to the cpu's reset.. Oct 29 19:26:15 so this *is* a hardware issue? Oct 29 19:26:15 i can never remember the commit, but there is a better work-around in u-boot now.. Oct 29 19:26:19 yeah, the beaglebone has suffered from it from the start but it was never fixed for some reason. on our latest hw we've added a reset-extender to the reset pin to keep it asserted for 200ms or so at power-up, and we added 100K pull-up to it to try to make it rise a bit faster despite the silly about of capacitance Oct 29 19:26:32 rah: this is absolutely a hardware issue Oct 29 19:27:02 it's on teh rev D list.. keeping bug jkridner , he's tired of just me .;) Oct 29 19:27:05 I just put a lot of effort into building a machine based on a beaglebone green Oct 29 19:27:23 that's been sat around for three years Oct 29 19:27:29 I finally put it together Oct 29 19:27:34 rcn-ee[m]: honestly the beaglebone needs an official errata doc, with suggested workarounds for people integrating it Oct 29 19:27:44 solder my wifi card, drill holes, get a Debian image together Oct 29 19:28:09 and now I'm told there's a hardware bug that stops the ethernet working Oct 29 19:28:17 urgh Oct 29 19:28:24 wait, irc's the offical errata doc? Oct 29 19:28:28 * wait, irc's not the offical errata doc? Oct 29 19:28:29 zmatt: Why start this late in the game? (wink) Oct 29 19:28:49 there's an errata doc? Oct 29 19:29:08 rah: there's a low probability of the phy being messed up after power-on yes (fixed by hard-resetting, or you can power-cycle to roll the dice again) Oct 29 19:29:18 rah: no I just said there *should* be one Oct 29 19:29:23 and should have been one years ago Oct 29 19:29:55 I'm astounded that this design has seen such widespread usage with such a critical flaw Oct 29 19:30:46 Try running a Black on battery. lol Oct 29 19:30:56 lol Oct 29 19:31:10 yeah and that power supply flaw was even copy-pasted into the OSD335x Oct 29 19:31:17 Have the AI on our custom board, powered from it, using the 10-28 IoT image. CPU is hovering around 58C. Oct 29 19:32:08 that seems reasonable. is that with the cpu power management at default or configured to allow retention using my hack? Oct 29 19:32:20 No hacks yet. Oct 29 19:32:21 rcn-ee[m]: is it possible to solder a bodge wire in order to "run a gpio pin to the reset on the phy"? Oct 29 19:32:57 if you cut it you can... otherwise you'll just reset yourself too.. Oct 29 19:32:59 rah: you'd need to cut the phy's connection to the beaglebone reset line though Oct 29 19:33:30 this however sounds harder than adding a reset-extender (which is just a tiny IC with three pins that to go gnd, 3.3v, and reset, all of which close together on P9) Oct 29 19:33:55 we're currently doing tests with that, I hope to have results later this week Oct 29 19:34:38 zmatt: where would those results be announced? Oct 29 19:34:44 here, if you ask me Oct 29 19:35:05 ok Oct 29 19:35:31 She's a'creepin' up. I'm thinking if it hits 78 or so that's cause for alarm. Going to write a script that monitors temp while I'm fiddling around and bitches if it's unhappy. Oct 29 19:37:28 just add water-cooling Oct 29 19:37:55 Ethylene glycol baby! Oct 29 19:38:15 rah: here is the u-boot fix: (which is better then the kernel fix) https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L629-L700 Oct 29 19:39:18 rah: thus the only reason i still carry the patch, is for user still running old u-boot.. Oct 29 19:40:26 Here's the commit: https://github.com/u-boot/u-boot/commit/20c37fb1bfb9f20804645b2199699cd815a4d55c Oct 29 19:41:13 U-Boot 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500), Build: jenkins-github_Bootloader-Builder-128 Oct 29 19:41:30 Does the old uio system work on an AI or is there something "better"? Oct 29 19:41:31 github seems to think that patch went into 2019.10 Oct 29 19:41:53 Ragnorok: I happily use uio-pruss on the x15 Oct 29 19:42:04 is there a beaglebone image with a later u-boot image that I can flash? Oct 29 19:42:10 whether remoteproc-pru is "better" is a matter of opinion :P Oct 29 19:42:15 but you can use whichever you want Oct 29 19:42:29 you could use uio-pruss for one pruss and remoteproc-pru for the other if you wanted to :P Oct 29 19:42:30 rah: give me a moment. ;) Oct 29 19:42:36 I take that as a "yes". Nice. I'd prefer not to redo that part of the system. UIO is very straightforward. Oct 29 19:42:37 (I'm assuming the u-boot is what's on the eMMC, not the SD card?) Oct 29 19:43:28 Ragnorok: dunno about libprussdrv though, at the very least it'll only support the first insance since it contains a hardcoded assumption to use /dev/uio0-7 Oct 29 19:43:40 Ragnorok: but my py-uio fully supports both instances Oct 29 19:44:07 One is all I need for now. If I think I need the other pair I can burn that bridge when I get there. (grin) Oct 29 19:44:42 (and doesn't break if you happen to use uio for other stuff, causing uio0 to be something other than a pruss entirely) Oct 29 19:45:16 Yeah. I only use it for pruss though. Oct 29 19:45:40 e.g. uio is the easy way to be able to use the full feature-set of PWMSS devices Oct 29 19:46:01 * Ragnorok takes note Oct 29 19:47:17 uio is also great for creating a device that lets userspace map some specific bit of physical memory, e.g. some of pruss shared memory (without being able to necessarily map all of it, for security reasons) Oct 29 19:49:10 jkridner added an uio_pruss_shmem driver for that reason (to cover up the deficiencies of remoteproc-pru I think), although that was entirely pointless since the mainline driver uio_pdrv_genirq supports the same functionality (and more) Oct 29 19:50:20 Pretty sure I only use it via libprussdrv to load firmware and whatnot. Oct 29 19:50:36 My needs are pretty simple. Oct 29 19:50:46 rah: special build for you: sudo /opt/scripts/tools/developers/update_bootloader.sh --beta Oct 29 19:53:18 rcn-ee[m]: pretty sure you could just drop the uio_pruss_shmem and replace it with https://pastebin.com/zT2fpydd Oct 29 19:53:43 rcn-ee[m]: thanks, I'll give it a try Oct 29 19:53:53 rah: , there should be a new print: printf("fixing up phy_id for %s, old: %d, new: %d\n", Oct 29 19:54:12 or no kernel patch at all and instead use compatible = "uio"; in DT along with this config file: https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf Oct 29 19:54:28 rcn-ee[m]: it looks like I was wrong about the release version though, it looks like this patch went in from v2018.11-rc1 onwards Oct 29 19:55:46 Does the AI use the same device tree as the Black? Best case I could plop my DT on it directly, but doing a tweak/compile isn't much harder, long as there's not a huge restructuring of everything. Oct 29 19:56:10 BTW reuse seems a bit impossible, but hey, I can dream. Oct 29 19:56:26 Ragnorok: no, not even remotely Oct 29 19:56:31 not even a tiny bit Oct 29 19:56:59 it's a completely different board, completely different SoC Oct 29 19:57:35 hence completely different DT Oct 29 19:58:06 So I have relearn a whole new DT scheme? Or can I patch up something because the arch is the same but the details vary? All the bits I care about are in the AI, mainly PRU & McASP. Oct 29 19:58:29 I mean, DT syntax itself is still the same, as are the DT bindings for individual peripherals Oct 29 19:58:56 Ok. That's what I expected. The reuse was me being all Kittens & Unicorns. Oct 29 19:59:31 rcn-ee[m]: I'm not seeing this printf: https://paste.debian.net/1111765/ Oct 29 19:59:43 Ragnorok: like, this is an example I made that sets up an i2c bus and an ehrpwm peripheral with two outputs: https://pastebin.com/W1ae9fYH Oct 29 20:02:11 Cool. I actually didn't do the original DT so this is going to be interesting. Now that I see your example I'm pretty sure there's some I2C bits as well. Oct 29 20:02:29 rah: ugh CONFIG_OF_BOARD_SETUP, that's the fdt path, we are still using the classic board path.. Oct 29 20:03:38 i'll need to do some testing, the last time i tried switching over the fdt path, it was a shit show... Oct 29 20:04:02 atleast now, we spec a larger hole at the start of the partition. Oct 29 20:04:30 ok, that's all going over my head but I get that you can't sort it out now :-) Oct 29 20:04:42 thanks anyway Oct 29 20:07:13 u-boot on a path to do what the kernel did.. Device Tree over Board Files.. However it's been a few more years to get where the kernel has gotten too.. Oct 29 20:11:28 Our version: MLO: 90K u-boot.img: 465K Oct 29 20:11:29 mainline: u-boot DT: MLO: 109K u-boot-dtb.img: 742K Oct 29 20:39:53 Looks like IoT is stretch? Don't care, just expected buster. Oct 29 20:44:14 there's a stretch-iot and a buster-iot... ;) Oct 29 21:01:05 Poo. I got the wrong one! Oh well. Next time. Oct 29 22:33:59 rcn-ee[m]: do you know what is the ambient temperature of the place you test your AI images? Oct 29 22:57:07 Hello, I just bought a new BBB Wireless. I am having trouble with BBB drivers. Drivers are installed but not recognised by Windows 8.1. And 192.168.7.2 does not load as well. Can someone please help? Oct 29 22:58:55 Also I can't connect to BBB Wifi using default password Oct 29 23:00:17 The linux image installed on SD card is the latest one Oct 29 23:54:57 #@$@#$@#$@## AWS hosting syn flooders Oct 29 23:58:57 Noobone: You can use connmanctl for wifi connectivity. Oct 30 00:11:45 ds2: 23C, but i've taken one's life previously, it didn't have an heatsink Oct 30 00:12:27 /exec (23*9/5)+32 Oct 30 00:12:28 blah Oct 30 00:12:49 rcn-ee[m]: and no spontaneous shutdowns? Oct 30 00:12:50 73.4 Oct 30 00:13:55 I am hitting it with the imagenet classifer once every 1-2 seconds and so far no shutdowns... can't tell if this is an ambient temp thing or the force retention mode via zmatt's util Oct 30 00:14:30 ambient right now is about 67 here Oct 30 00:14:41 the issue is obviously °F Oct 30 00:15:00 god made your program fails as a punishment Oct 30 00:15:53 when C has more precision... :P Oct 30 00:16:11 each integer bit of F has 9/5s more precision then C :P Oct 30 00:16:38 :( Oct 30 00:17:05 then just use μ͏°C, it has A MILLION times more precision Oct 30 00:17:06 :P Oct 30 00:17:29 once you fit that into 8 bits... Oct 30 00:17:57 this kind of stuff rears its ugly head when you start playing with BLE Oct 30 00:18:13 and cause of it, there 234234234234 different formats for sending temperature... ARRRRRG Oct 30 00:18:35 if you want to fit the most precision into 8 bits, use neither scale but figure out what the max and min values you need in your application and scale those to be 0 and 255 respectively Oct 30 00:19:39 from a programmer prospective, sure Oct 30 00:20:02 from someone who has to figure out what the UUIDs being transmitted with minimal docs means - @#$@#%$@#%@#%^@#%@#$@#$!!!!!!!!! Oct 30 00:20:21 so your complaint is really about poor documentation Oct 30 00:20:25 almost every single one of those little BLE demo dongles does it differnetly Oct 30 00:20:40 some use a variant of BCD, others scale, others.... Oct 30 00:21:08 I wish the C scale never existed Oct 30 00:21:11 use of bcd clearly indicates they didn't care about minimizing space/precision ratio Oct 30 00:21:28 at least the K scale tries to be useful Oct 30 00:21:33 I really don't see how you can possibly blame this on the celsius scale Oct 30 00:21:39 zmatt: yep Oct 30 00:21:59 ds2: thought you were in Europe, i flipped the switch on my gauge, 74F ;) Oct 30 00:22:53 i've been mostly using pixel phone chargers and the pi4 chargers, no sudden reboots, other then teh one i killed... that one somtimes get's to uboot.. Oct 30 00:23:05 rcn-ee[m]: we are colder then out here even with all the large campfires! Oct 30 00:23:45 well my bitcoin farm is downstairs with me, so it's nice and warm.. Oct 30 00:24:09 rcn-ee[m}: Amazon sells a very nice hub for this kind of use. It can provided up to 2A (has a wall wart)... so that plus a micro to C adapter... and it has a hard power switch Oct 30 00:28:44 is the USB host port stable on the BBAI? Oct 30 00:29:45 it's not musb! ;) Oct 30 00:31:26 yes but is it better or worse? :D so far 2 oopss running a UVC cam Oct 30 00:32:10 100x better.. do you have enough power? moving to v4.19.x-ti should help. Oct 30 00:33:12 i still need to finish the dsp for v4.19.x.. yuck.. i did get one thing fixed in buster today, i need atleast a week away from nodejs before i start on another nodejs project. Oct 30 00:33:14 I should have enough power Oct 30 00:33:21 does TIDL work with 4.19? Oct 30 00:33:50 no, i need to bring the newer cmem, ti-opencl, and new firmware.. Oct 30 00:34:14 no point then Oct 30 00:34:31 ti's sdk built: http://gfnd.rcn-ee.org:8080/view/Builds/job/ti-sdk-06.01.00.08/ws/tisdk/build/arago-tmp-external-arm-toolchain/deploy/ just need to steal the bits i need (firmware) Oct 30 00:36:11 it comes down to where to spend time Oct 30 00:36:28 I really want to get things far enough to start looking at how to get another model running Oct 30 00:36:37 and so far no sign of where to locate the model translation utils Oct 30 00:36:47 Imagenet is so boring Oct 30 00:37:52 rcn-ee[m]: lol, not a fan of nodejs? ;) Oct 30 00:40:00 Nope, especially when a big projects changes there build system and doesn't actually show how it was built.. So i ended up hacking a released *.js files to add systemd socket support.. Oct 30 00:40:18 rcn-ee[m]: https://github.com/dutchanddutch/node-sd-daemon Oct 30 00:41:14 pretty Oct 30 00:41:31 is Cloud9 glued onto systemd now? Oct 30 00:41:43 I saw some silly business going to 127.0.0.1:3000 on the webserver Oct 30 00:42:01 ds2: oh cloud9 is even worse.. ever since Amazon picked it up, it's been dead... Oct 30 00:42:15 it almost looks like ngnix has been completely neutered Oct 30 00:42:52 Buster has nodejs v10.x, our git version only supports nodejs v8.x.. yeah.. Oct 30 00:42:55 ds2: we are shipping ngnix in every build now.. Oct 30 00:43:13 oh yeah I still need to fix nodejs 10 compat in my shit Oct 30 00:43:25 rcn-ee[m]: yes but you seem to have put in code to do nothing but redirect to 127.0.0.1:3000 Oct 30 00:43:45 rcn-ee[m]: would be nice if you added something like /local/ to point to /var/www/html or something Oct 30 00:45:37 ds2: i think that's this: https://github.com/rcn-ee/bb.org-cloud9-core/blob/master/patches/0003-bb.org-use-systemd.patch#L20-L34 Oct 30 00:47:21 But yeah, in the current image's http://addres/ -> cloud9 which replaces the old bone101 getting started guide. Oct 30 00:47:52 Then jkridner and Mark have been adding a getting started guide to cloud9, including the pull down on the upper left.. Oct 30 00:48:39 all those setting are hosted here: https://github.com/beagleboard/cloud9-examples and from cloud9, you can git pull to get the latest.. Oct 30 00:48:57 rcn-ee[m]: yes but any chance you can make the default ngnix server have a URL that maps to /var/www/html? like if you goto /local/ or somethign else? Oct 30 00:49:10 useful for being able to serve up small stuff for test/demo Oct 30 00:49:18 i think port 8080 is mapped to / Oct 30 00:49:41 no listener on port 8080 with the factory image Oct 30 00:49:56 seems a waste of ngnix to make it nothing but a redirector Oct 30 00:50:14 I suspect it is just a few more lines in /etc/ngnix/sites-available/default Oct 30 00:50:20 it's way better at it then apache ;) Oct 30 00:50:32 i'm pretty sure i put it in there.. Oct 30 00:50:35 I have hacked out the '/' redirect but I know that will never fly with Jason Oct 30 00:51:03 for a board like this, I don't think it matters which webserver Oct 30 00:52:14 Here is teh template, yeap no 8080, it was in the old apache.. https://github.com/RobertCNelson/boot-scripts/blob/master/distro/buster/nginx/default#L55-L79 Oct 30 00:53:11 ds2: i'll gladly take a 8080 / base redirect and stick it in there, as that'll match what we did in apache.. Oct 30 00:53:44 rcn-ee[m]: works for me. Oct 30 00:54:21 i have a mostly hacked up demo that takes a webcam, runs it through imagenet, and places it a self refreshing webpage Oct 30 00:54:41 it was just irritating to find that things have been so convoluted by cloud9 Oct 30 01:29:53 Well...get this! I got the BBBlue (I know, old news) to fly w/ WiFi only. I figured out what I did incorrectly on the last pass. I need to get the executables of arducopter on my BBBlue. Oct 30 01:29:54 ... Oct 30 01:30:45 Anyway...I tried w/ 4.0 but I received too many errors. So, ardupilot is being downgraded to 3.6 again to fly into the night. LEDs! Oct 30 01:31:39 That fellow's github repo. has a way to put in noise too, i.e. sound! Oct 30 01:32:50 LEDs, bbblue, action! Oct 30 02:39:37 it is done! Off to test and wake up the neighbors! Oct 30 02:52:48 Yea boy! It done does it nicely now! Oct 30 02:53:03 It was the executables I missed on the last try. Oct 30 02:53:08 Scary! Oct 30 02:54:08 bzzt, bzzt! **** ENDING LOGGING AT Wed Oct 30 02:59:57 2019