**** BEGIN LOGGING AT Mon Dec 20 02:59:56 2021 Dec 20 10:57:36 hey Dec 20 11:02:37 Question Trying to enable early_printk but the kernel seems to just hang after u-boot i have enable early_printk in the kernel options after the option DEBUG_LL also these are my bootargs: "setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait earlyprintk" Dec 20 11:03:11 man that sentence construction xD Dec 20 11:04:05 I mean I enabled the kernel option early_printk after I enabled DEBUG_LL Dec 20 11:11:31 as soon as I remove earlyprintk from bootargs it works again I think I have something miss configured :) Dec 20 11:23:59 does the bbb need a nameserver to use the shared internet? Trying to set up another board under windows cannot get it to use the shared connection Dec 20 11:29:38 hmmm I have access to a system where i have earlyprintk working :) been looking through /proc/config.gz but not sure what I changed :) Dec 20 11:42:17 mattb0ne: if you connect the bbb via ethernet it should work plug and play Dec 20 11:43:47 Daulity: I've dug into earlyprintk and earlycon before, though I don't quite remember the conclusions... other than that earlyprintk is kinda gross. iirc earlyprintk also hardcodes the uart to be used into the kernel (while earlycon uses the uart selected as console by u-boot) Dec 20 11:44:26 and iirc earlyprintk has kind of a glitchy transition to normal console Dec 20 13:35:41 i got it to work eventually Dec 20 13:35:57 i had to set the uart_phys and uart_virt addresses correctly Dec 20 13:36:12 for somereason they are/were different Dec 20 13:46:36 trouble is i really shot my self in the foot here xD not documenting that i had to do that Dec 20 13:53:10 Daulity: any reason to use the brittle earlyprintk rather than the (afaict) more sane earlycon ? Dec 20 13:54:11 why do you need either anyway? does the normal serial console really appear that late? are the relevant drivers compiled into the kernel or did you build them as modules? Dec 20 13:58:17 (i.e. CONFIG_SERIAL_CORE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_OMAP=y ) Dec 20 14:03:47 Daulity: looks like earlyprintk should use the correct uart if you have "Kernel low-level debugging port" set to "Kernel low-level debugging messages via AM33XX UART1", i.e. CONFIG_DEBUG_AM33XXUART=y ... note that contrary to what the config var name and help message claim, that's actually UART0 (/dev/ttyS0) Dec 20 14:05:11 that sets CONFIG_DEBUG_UART_PHYS=0x44e09000 and CONFIG_DEBUG_UART_VIRT=0xf9e09000 Dec 20 14:09:03 in contrast, earlycon just requires CONFIG_SERIAL_EARLYCON=y and "earlycon" in the kernel parameters Dec 20 15:48:01 when I try to ping 8.8.8.8 it fails immediaetly Dec 20 15:48:07 i was used to it at least trying to reach out Dec 20 15:48:27 does the latest image use conman to control internet? Dec 20 15:48:42 my /etc/resolv.conf is blank too Dec 20 15:49:24 the one chance I did was uncomment iface eth0 inet dchp line in my /etc/network/interfaces file Dec 20 15:49:37 didnt work obviously Dec 20 15:49:47 i can reflash i guess Dec 20 15:49:52 hope for the best Dec 20 15:50:25 but I feel you did tell me to do something to get the internet sharing going on the bbb Dec 20 15:50:48 zmatt:internet sharing is plug and play Dec 20 16:02:06 mattb0ne: do not put anything in /etc/network/interfaces Dec 20 16:02:11 that will just break things Dec 20 16:02:48 mattb0ne: the only thing required on the bbb to have internet working when plugged into ethernet is just not breaking what works out of the box Dec 20 16:03:01 it works unless you mess it up Dec 20 16:42:11 ok Dec 20 16:42:25 let me comment out interfaces Dec 20 16:42:41 much of the BBB literature is so out of date Dec 20 16:46:41 has there even been a time where bb.org debian images _didn't_ use connman? if so that would be before my time Dec 20 17:07:01 auto lo is ok though right? Dec 20 17:07:22 and "iface lo inet loopback" Dec 20 17:07:43 yes that's in there by default Dec 20 17:08:48 connect: Network is unreachable Dec 20 17:09:07 if I try and ping 8.8.8.8 it is like immediate like it is not even trying Dec 20 17:10:19 so if i type ip addr show Dec 20 17:10:25 and ping the ip under eth0 Dec 20 17:10:27 i can ping that Dec 20 17:10:36 please pastebin the output of 'ip addr' Dec 20 17:10:49 and 'ip route' Dec 20 17:11:25 https://pastebin.com/HE8jiyzK Dec 20 17:12:00 https://pastebin.com/E4z7RKTY Dec 20 17:12:13 there's no internet available on ethernet, something must have gone wrong with internet sharing Dec 20 17:13:33 a 169.254.*.* IP address is a self-assigned link-local address, which means no DHCP server was found on ethernet Dec 20 17:17:25 hmm Dec 20 17:17:34 so you think it is a problem on the host Dec 20 17:17:39 yes Dec 20 17:17:43 let me play with windows Dec 20 17:17:45 arg Dec 20 17:17:47 it's not sharing internet to ethernet Dec 20 17:17:56 this was much eaiser on linux Dec 20 17:18:12 iirc it's easier on windows than on linux Dec 20 17:18:38 I rarely use windows but I don't recall having ever had any problems with windows internet sharing Dec 20 17:19:26 i share the connection that is actually providing the internet Dec 20 17:19:32 i was hoping it was that simple Dec 20 17:23:33 also I was going to ask you if I am processing data to slow using your code would that cause a memory leak in python Dec 20 17:23:50 I ask because I get an OOM error Dec 20 17:23:57 i am wondering how I can fix Dec 20 17:24:15 right now I deliberately throttle to block blow ups Dec 20 17:24:33 ?? Dec 20 17:25:19 you really need to clarify what you mean. "throttling" processing makes no sense to me, that would make any kind of problem worse Dec 20 17:29:01 are you talking about the client or the bbb? Dec 20 17:30:34 if the client is unable to keep up with the data being sent then... well first of all fix the client, it really isn't that much data, but second yes if that situation goes on long enough that will obviously make either the client or the bbb run out of memory if you didn't put in any checks Dec 20 17:31:31 I recall that in my example server code (for the bbb) I had a comment about exactly that Dec 20 17:35:38 the bbb runs fine Dec 20 17:35:42 issue is client side Dec 20 17:36:30 i guess by throttling i mean having the client do MORE stuff. If I just have the client try and save it blows up. If I have it do somethings like updating the GUI and save it will run Dec 20 17:36:47 ?? Dec 20 17:37:15 so the BBB is sending batches to the client Dec 20 17:37:30 no, the BBB is sending lines to the client Dec 20 17:37:55 ok the client is receiving lines in batches Dec 20 17:38:01 whether or not these were sent in batches is invisible and irrelevant to the client Dec 20 17:38:20 the client is receiving lines, and my version processes those in batches as a performance optimziation Dec 20 17:38:25 *optimization Dec 20 17:39:45 (by waiting until at least one line is available, and then processing all complete lines in the input buffer in one batch) Dec 20 17:39:57 right and those batches get parsed and some of that data is sent to the rest of the program Dec 20 17:40:36 so I tried running with nothing else really happening other than saving the image as a npy Dec 20 17:41:16 i can confirm I do not have a HW bottleneck as the sdd can handle 1.2GB/s in sequential write via DD Dec 20 17:41:30 I do get around ~25 images a second Dec 20 17:41:36 but I can only do so for 1 minute Dec 20 17:41:45 before I get an OOM Dec 20 17:41:58 what exactly does this image-stuff have to do with the data being sent from the bbb ? Dec 20 17:42:08 i watched during system monitor and on the client side something is not getting cleared Dec 20 17:42:21 nothing really the BBB is fine Dec 20 17:42:33 that's not what I asked Dec 20 17:42:47 i am just wondering if there is anything to watch out for on the client side and python in general to get that sort of behavior Dec 20 17:44:13 i am going to flash this 2nd beagle Dec 20 17:44:17 i must of done something Dec 20 17:44:32 your internet issue is not on the bbb Dec 20 17:45:49 and your memory leak question is too vague to be answerable... yes if you keep using more memory you'll eventually run out of memory... Dec 20 17:45:57 well windows is saying unidentified network or something Dec 20 17:46:23 on the memory question is there a way to force python to release memory Dec 20 17:46:28 kind of like C Dec 20 17:46:40 so just to be clear: on your internet connection you enabled internet sharing, and as "home network" in that sharing popup select ethernet Dec 20 17:46:53 python will release memory once it's unreferenced Dec 20 17:47:13 it can't release memory that's still referenced since then you'd crash Dec 20 17:49:27 ok bridge connection does not work Dec 20 17:49:30 I am on Win11 Dec 20 17:49:38 bridge is not the same thing as internet sharin Dec 20 17:49:38 g Dec 20 17:49:54 and the sharing option does not have a drop down to specify a specific connection to share with Dec 20 17:50:00 it was a shot in the dark Dec 20 17:51:55 definitely windows though you are right. when I click on the ethernet port it says no connectivity Ipv4 or Ipv6 Dec 20 17:52:07 i suppose a static IP would not help Dec 20 17:52:20 normally windows will set that up Dec 20 17:58:09 okay no idea what microsoft did with internet connection sharing in windows 11 Dec 20 17:59:22 I'm not getting any useful results so eh... good luck with that I guess? Dec 20 17:59:49 yeah i will just update the board on my linux box Dec 20 17:59:53 damn windows Dec 20 17:59:59 on the memory thing Dec 20 18:00:03 more important anyway Dec 20 18:00:08 is there a python release memory command Dec 20 18:00:15 or calling the garbage collector manually Dec 20 18:00:19 you're asking the wrong questions Dec 20 18:00:34 if you're leaking memory, your code is keeping that memory referenced Dec 20 18:00:59 which means that memory _cannot_ be safely released, in any programming language Dec 20 18:01:28 is oom the same as memory leak Dec 20 18:01:42 oom is the result, memory leak is the cause Dec 20 18:02:37 ok how could i go about finding where the issue is in my code Dec 20 18:02:44 do I need a 3rd party tool Dec 20 18:02:48 also, are you still doing things with that qt image api? I seem to recall it had some memory allocation caveats as well but I'd need to check again (and I don't remember what you were using) Dec 20 18:03:41 have you tried googling that problem? Dec 20 18:03:49 e.g. https://stackoverflow.com/questions/1435415/python-memory-leaks Dec 20 18:06:20 i assumed that was not the problem since I stopped all QT activity. I was going to try do a very barebones program where I just save nothing else and see if I run into the issue Dec 20 18:06:28 and then slowly add stuff back in. Dec 20 18:06:58 well if you're not doing anything with qt then the problem is presumably not there Dec 20 18:09:37 like you said think systematic Dec 20 18:09:45 so first let me see if I can save that fast Dec 20 18:09:55 I do the multiprocessing thing with 5 workers Dec 20 18:10:05 not sure that should matter but maybe it does Dec 20 18:10:15 then I will add the beagle communication Dec 20 18:37:39 brb Dec 20 19:11:22 Hi, is this the Beaglebone chatroom? Dec 20 19:12:12 yup Dec 20 19:12:44 (or more generally the chat for users of beagleboard.org products) Dec 20 19:12:48 Cool! This is my first time using IRC, so I am kinda unsure :D Dec 20 19:13:31 Does anyone here know if it's possible to get a screen working on a pocket beagle? I mean it has SPI.. Dec 20 19:15:15 I mean, you kinda answered your own question there... small screens that connect via spi (or i2c) will obviously work on any board that has spi (resp i2c) Dec 20 19:15:47 Yeah, I was just not that sure because I read somewhere that there is no way rendering a desktop Dec 20 19:16:17 Thank you, that's basically all I wanted to know! Dec 20 19:16:35 I mean, if the spi display has a kernel driver then I guess you could theoretically run X11 on it Dec 20 19:16:46 whether you'd _want_ to is a different question ;) Dec 20 19:16:59 given the size and performance limitations Dec 20 19:21:03 Well, it would be for a small DIY smartwatch (with the Octavo SIP, not with the pocket beagle). Plan would be running X and start a TKinter script right after booting Dec 20 19:21:19 No animations or anything fancy is needed-- Dec 20 19:23:26 would probably be more appropriate to use a graphics library that can directly use the framebuffer instead of running X11 Dec 20 19:23:52 also, if you're using the octavo sip directly you obviously also have access to the lcd controller pins Dec 20 19:24:56 though it's possible for a smart watch an spi display is more appropriate Dec 20 19:26:19 (lcdc also supports various bus protocols commonly used by displays with embedded framebuffer, though I don't think there's a kernel driver for that mode) Dec 20 19:28:25 Yeah, that's my intend. Don't get me wrong, I don't know much about embedded systems, but I am a CS student and I am able to design a PCB and solder BGA, with this Prerequisites I think it would be possible for me to create a fun device. Dec 20 19:29:00 I think SPI is pretty comfortable regarding the kernel as far as I have researched... Dec 20 19:29:05 the osd335x certainly makes it easier by integrating the particularly tricky bits related to power supplies and ddr3 memory Dec 20 19:29:44 yeah for spi you just use one of the spi controllers, not lcdc Dec 20 19:30:49 Good to hear! I initially found the OSD32MP15, but then discover the pocket beagle which would be the ideal  development board... Dec 20 19:31:12 lcdc is normally used for digital parallel video (aka display pixel interface), though like I said it has some other modes (e.g. for HD44780) but those modes aren't well supported in software Dec 20 19:31:45 Because you mentioned it before: Are there any major disadvantages with X11 compared to a graphic libarary? Dec 20 19:32:21 I mean, the pocket beagle is only ideal if you don't need any of the many pins it _doesn't_ pin out on its expansion headers... otherwise the beaglebone black, black-wireless, or green would be better for prototyping (avoid the green-wireless) Dec 20 19:32:32 performance Dec 20 19:32:35 overhead Dec 20 19:32:56 also the general awkwardness of having to setup X11, arrange for auto-login, have your program launched automatically on login Dec 20 19:33:16 versus just starting your app at boot and it directly rendering graphics to the framebuffer Dec 20 19:33:24 I looked up the pinout and found that I don't miss any pins on the pocket beagle Dec 20 19:33:36 well, it lacks the lcdc pins for one Dec 20 19:33:49 Of course, but I don't think I need them Dec 20 19:34:28 if you've already decided to use an spi display then true Dec 20 19:35:50 Regarding X: One thing I didn't told you before was, that I want multiple apps running and thus a graphic library would be not that useful as far as I understand. Btw, sorry for my improper spelling and phrasing, I am from Europe... Dec 20 19:36:20 Of course, if it's that bad with X, I could make ONE app and integrate all the functionality there... Dec 20 19:37:06 perhaps I'm overly pessimistic about X11... or I might be pessimistic by a perfectly appropriate amount, I guess you'll have to try and see ;) Dec 20 19:38:53 I would structure it like a real desktop and have a app launcher like you would have it when you don't use a complete DE in Linux. From there starting apps without borders in openbox (or any other lightweight WM). Closing would be a hardware button. Dec 20 19:40:10 I mean I would like to not use X, it bothered me quite some time when setting up arch, and I can only imagine how annoying it would be to set it up on a circular screen ... Dec 20 19:40:43 lol Dec 20 19:41:21 ? Dec 20 19:42:42 must of broke something, after reflashing it is working now Dec 20 19:42:44 yay Dec 20 19:45:05 Thanks for your help! I will probably be back soon in this channel when I got the beagle^^ have a nice day all **** BEGIN LOGGING AT Mon Dec 20 20:15:35 2021 Dec 20 20:44:16 zmatt: have you used the multiprocessing module Dec 20 20:44:18 https://pastebin.com/ErGpLi2R Dec 20 20:44:21 this does not work Dec 20 20:44:31 I think i have an issue with thread cleanup Dec 20 20:44:37 i am not sure how to fix it though Dec 20 20:45:15 from python docs "We can use a with statement to ensure threads are cleaned up promptly Dec 20 20:45:15 " Dec 20 20:45:42 i am not sure how to do this in my use case Dec 20 20:47:44 mattb0ne: I tested submitting working via asyncio's loop.run_in_executor() and that does not require cleanup or leak memory Dec 20 20:48:37 you don't need to clean up worker threads, that's the job of the ThreadPoolExecutor (in my tests I just used the default one provided by asyncio) Dec 20 20:49:36 however, your code seems to be creating a new thread pool for each image Dec 20 20:49:47 which completely defeats the purpose Dec 20 21:01:34 like, your code creates a thread pool, submits a single job in it (assuming grab succeeded), and then implicitly wait for that job to have completed as part of the thread pool cleanup that happens at the end of the with-block, overall doing the exact same thing you did without threading except with a lot more inefficiency Dec 20 21:09:30 also, when I google that camera library you're using, the first example I see ( https://github.com/basler/pypylon#getting-started ) contains an explicit release of the grabbed image: grabResult.Release() ... I'm not seeing that in your code Dec 20 21:10:08 also, this binding looks kinda horrid Dec 20 21:17:44 lol Dec 20 21:18:02 could i get away with just creating a thread and Thread.start() Dec 20 21:18:16 i know i read that creating threads and destroying them is not efficient Dec 20 21:18:46 it's more work, more complexity, and less efficient... why exactly would you want to do that? Dec 20 21:19:32 I'm more concerned about how to integrate this pylon crap into the overall application, since it looks like it's synchronous and blocking Dec 20 21:20:19 well i just did a simple version where I just create a thread and assign it and repeat the loop Dec 20 21:21:06 all I use it for is the image grab Dec 20 21:21:26 maybe inserting the release is what I need once I have it in a numpy array I am done until next image Dec 20 21:26:46 you'll probably want to have a dedicated image-grabbing thread (if there's no better way to deal with pylon) Dec 20 21:28:27 you definitely don't want to use multiple threads for image-grabbing, that will make a giant mess (if not outright crash, depending on whether pylon is threadsafe) Dec 20 21:30:18 how to best structure the processing of the grabbed images is a non-trivial matter and will depend a bit on what you intend to do with those images other than just save them Dec 20 21:32:58 basically my loop is: 1) get image 2) get data from BBB and 3) save image Dec 20 21:33:46 i would want a thread pool for all this? Dec 20 21:34:48 that description of the loop is ambiguous, since you don't "get" an image or data from the BBB at your command, the camera provides images at its own pace, and likewise the BBB provides its data at its own pace Dec 20 21:35:09 right that is what is hard Dec 20 21:35:25 a thread pool is for asynchronous execution of stuff like saving images Dec 20 21:35:59 right, which is why you need to explain better what exactly you're trying to do Dec 20 21:36:05 so a single separate thread for the image grabbing Dec 20 21:36:23 looks like pylon kinda forces you to do that yes Dec 20 21:36:35 ok Dec 20 21:36:44 or, well, based on the examples anyway, since there doesn't really seem to be API documentation on the web Dec 20 21:36:49 this will take a pretty sizable restructuring Dec 20 21:37:04 how is your program structured right now? Dec 20 21:37:11 its a mess Dec 20 21:37:13 lol Dec 20 21:37:26 isn't this a gui program with asyncio? how do you even fit this in? Dec 20 21:37:31 yes Dec 20 21:38:08 a threaded blocking API fits into an event-driven gui program like a chicken fits into a keyhole Dec 20 21:38:39 i am learning how true that is Dec 20 21:40:04 i guess i am not sure how to have a thread that just spits out images Dec 20 21:40:17 I'm also not sure that's what you want Dec 20 21:40:51 if you want a camera image that's close in time to the measurement data from the BBB, then you don't want images to be queued Dec 20 21:41:13 right ideally i want it matched up as close as possible Dec 20 21:41:15 though I'm still just guessing here what it is you want exactly since you haven't clarified Dec 20 21:41:48 and you're trying to do that for every image from the camera? or some specific interval? or something triggered by the BBB measurements? Dec 20 21:42:54 every image coming from the camera Dec 20 21:43:31 as I get an image back I look at the latest value coming from the BBB and then save them together Dec 20 21:45:26 hmm Dec 20 21:48:18 I guess you could have the main thread put the latest BBB values somewhere, have the camera grabber thread grabbing images in a loop and after obtaining an image grab the latest measurements from whereever the main thread saves them (the GIL makes this safe if you're careful) and then submit the np.save to a threadworkerpool Dec 20 21:50:22 for really tight synchronization you'd want a way to trigger the camera and simultaneously take a measurement sample, but that's probably a bit too complicated Dec 20 21:52:09 (or a way to get timestamps on camera images combined with a way to relate these to BBB measurements) Dec 20 21:52:32 anyway, afk Dec 20 21:52:35 ok Dec 20 21:52:39 thanks for the suggestion Dec 20 21:52:47 i will give it a shot Dec 21 00:28:57 Trying to load recent bullseye on BBBlack. Can't seem to find the network driver... Dec 21 00:30:17 My recent Yocto build works fine. Dec 21 00:30:28 Any suggestions for debugging this? Dec 21 01:10:51 set_ has been awful quiet Dec 21 01:16:19 is there a way to make a thread function as a generator Dec 21 01:16:24 i think that is what I need **** ENDING LOGGING AT Tue Dec 21 02:59:56 2021