**** BEGIN LOGGING AT Tue Dec 21 02:59:56 2021 Dec 21 03:21:03 this sound familiar to anyone? [ 7.023036] cpsw 4a100000.ethernet: 0: Error retrieving port phy: -517 Dec 21 03:21:39 ethernet on the beagleboneblack broken on debian bullseye (linux 5.10.x) and debian bookworm (linux 5.15.x) Dec 21 03:36:26 slightly different on 5.15.x [ 7.249830] cpsw-switch 4a100000.switch: /ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/ethernet-ports/port@1: Error retrieving port phy: : -517 Dec 21 03:48:30 vagrantc, new driver... Dec 21 03:51:37 vagrantc, i think debian needs: CONFIG_TI_CPSW_PHY_SEL Dec 21 03:51:47 my config, https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.15/patches/defconfig#L2371-L2375 Dec 21 03:53:39 wait, that's the old one.. https://cateee.net/lkddb/web-lkddb/TI_CPSW_PHY_SEL.html idk. Dec 21 03:54:16 rcn-ee: ah, thanks! Dec 21 03:54:29 rcn-ee: i think we've discussed this before, but i never acted on it :/ Dec 21 03:55:18 i thought that was something similar, but different.. Dec 21 03:55:24 oh, could be Dec 21 03:55:30 * vagrantc waves hands Dec 21 03:57:40 nothing in my irc scroll back.. this is one thing i love about slack... i can figure out what we did last month... ;) Dec 21 03:58:13 figureing out what i did early today is hard enough! Dec 21 04:00:14 rcn-ee: I mean, if you can't scroll back then you need a better irc client :P also there's https://libera.irclog.whitequark.org/beagle/2021-12-21 Dec 21 04:00:59 i just use hexchat, looks like i only had 5000 line scroll back.. Dec 21 04:01:06 probably configurable Dec 21 04:02:32 ah perfect zmatt, you saved us, vagrantc it was the musb bus, fixed in 5.10.75 Dec 21 04:02:58 musb? what does musb have to do with cpsw ? Dec 21 04:03:12 that was the earlier issue Dec 21 04:03:19 so the musb was fixed, so now the user can actually bootup instead of hardlocking... so now the cpsw bug shows up.. Dec 21 04:03:25 lol Dec 21 04:04:13 it's like we've got a nice molehill and some nasty moles and just this ineffectual hammer Dec 21 04:04:42 i wonder... does kernelci have any BBB"s running anymore? it's like nothing get's tested anymore.. Dec 21 04:09:56 I meanm "KernelCI doesn’t run any labs itself" ... if you want BBBs in the tool you should probably host some Dec 21 04:10:06 *in the pool Dec 21 04:10:50 hrm. bool "TI CPSW Phy mode Selection (DEPRECATED)" Dec 21 04:11:18 deprecated ... so it's a *new* driver depending on a deprecated feature Dec 21 04:11:19 ? Dec 21 04:11:59 i saw that too, the's the only real diff in the CPSW section of my config.. Dec 21 04:12:49 PHY_TI_GMII_SEL really can't be used? Dec 21 04:16:43 vagrantc: the dt syntax required is different Dec 21 04:16:49 check. Dec 21 04:16:59 so presumably it'll work with a dt update Dec 21 04:17:14 and then, of course, will enabling TI_CPSW_PHY_SEL break other things? Dec 21 04:18:04 no, why would it? it's a driver Dec 21 04:18:10 if dt doesn't ask for it, it won't get used Dec 21 04:18:20 if dt does ask for it, you need it or you won't have working ethernet Dec 21 04:18:27 ok Dec 21 04:19:46 though, I'm not seeing it being referenced in the 5.10 DT Dec 21 04:20:11 so I don't think there's any point in enabling it Dec 21 04:20:49 vagrantc, i think we dealing with this fallout: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-bone-common.dtsi?h=v5.16-rc6&id=c477358e66a3a6db4f1799b7415068d6660c95c3 Dec 21 04:22:56 more hints... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx-l4.dtsi?h=v5.16-rc6&id=1a93456d08b872d7b1679ccb7196b570609a16f4 wish they stated the driver name.. Dec 21 04:24:36 ah, litterly: "new"... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/ti/Makefile?h=v5.16-rc6#n19 Dec 21 04:24:43 CONFIG_TI_CPSW_SWITCHDEV) += ti_cpsw_new.o Dec 21 04:26:06 during the debian installation, I remember be offered both ti_cpsw and ti_cpsw_new Dec 21 04:26:10 oh Dec 21 04:27:13 In the "no network interface found" dialog, I tried selecting each of these (individually) and the installer could not successfully find the network card. Dec 21 04:31:54 rcn-ee: has the davinci_mdio_update_dt_from_phymask() hack been updated to match the new cpsw yet? Dec 21 04:32:06 zmatt, nope... Dec 21 04:32:11 it's got ti_cpsw_switchdev enabled as a module Dec 21 04:32:31 rcn-ee: then again it sounds like they're testing mainline kernels so they're missing that fix anyway Dec 21 04:32:48 zmatt, in theory, with a mainline u-boot, it should be fixed... Dec 21 04:33:00 yeah these are debian kernels, pretty much mainline Dec 21 04:33:02 has u-boot been updated to support the new cpsw structure? Dec 21 04:33:02 (aka u-boot updates the device-tree.. Dec 21 04:33:32 but i'm 0/2 with bbb's coming up with eth0.... Dec 21 04:33:35 hey guys, remember when the rhetoric from kernel devs was that DT is supposed to represent the hardware, not OS-specific stuff like drivers? ;) Dec 21 04:33:36 i've tested with u-boot 2021.10 and 2021.01 Dec 21 04:34:32 zmatt, yeah they lied.. Dec 21 04:34:39 i could also probably test 2022.01~rc4 once it is done baking Dec 21 04:35:26 rcn-ee: which version of u-boot, or is that a dead end ? Dec 21 04:35:53 vagrantc, so i'm on 2020.10 Dec 21 04:36:34 i really have one main patch... assume everything is BBB... (i'm not really supporting ethernet in u-boot anymore..) Dec 21 04:37:04 correction... 2021.10 Dec 21 04:38:00 Does it seem clear that to you all that the current debian build cannot be fixed to support the BBB ethernet device (i.e., without a kernel rebuild)? Dec 21 04:38:03 okay, 0/3 on cpsw with v5.15.x my only board that works in the Green Gateway, but that has a musb bases smsc95xx Dec 21 04:38:50 dkaiser, mainline changed something on AM335x to support a new driver, and broke it for AM335x... Dec 21 04:38:51 dkaiser: seems you've found a rather pesky problem Dec 21 04:39:38 i can't recall if i had it working on earlier 5.10.x kernels Dec 21 04:39:54 if you revert https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-bone-common.dtsi?h=v5.16-rc6&id=c477358e66a3a6db4f1799b7415068d6660c95c3 the old driver should still work... Dec 21 04:40:33 probably should report that regression on the linux-omap list Dec 21 04:40:38 I would be happy to provide some testing time for Debian on BBB, if someone would provide some direction. Dec 21 04:41:18 ... once I get the network running (or, I suppose, even before). Dec 21 04:41:54 who needs ethernet anyway, just use ppp over a serial port ;-) Dec 21 04:42:54 may as well dig out my 300n baud coupler modem, while i'm at it Dec 21 04:43:42 dkaiser: sounds like a patched .dts and rebuiling the device-tree might work Dec 21 04:44:38 unless that requires TI_CPSW_PHY_SEL enabled Dec 21 04:44:56 zmatt, here's the u-boot fixup: https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L657 Dec 21 04:44:57 always more to learn... Dec 21 04:45:03 I think the phy change is independent from the cpsw change but I'm not 100% sure Dec 21 04:45:38 actually yes I'm sure, both the old and new cpsw nodes reference the same &phy_gmii_sel node Dec 21 04:46:15 ok Dec 21 04:46:25 * vagrantc looks up devicetree-rebasing ... Dec 21 04:47:45 https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git ... easy to rebuild a patched device-tree from the appropriate version from there Dec 21 04:51:25 zmatt: who needs ethernet when you can put your telephone handset on top of an acoustic coupler Dec 21 04:52:13 we can go back to passing around punch cards (or tape) Dec 21 04:53:44 can't find my coupler, or a landline, time to get ham cdertified Dec 21 04:56:46 I've also tried two USB devices (1 wired, 1 wifi) and they both fail to load... Dec 21 05:15:21 rcn-ee: that commit appears to only be in 5.15.x and wasn't backported to 5.10 as far as i can tell "ARM: dts: am335x-bone: switch to new cpsw switch drv" c477358e66a3a6db4f1799b7415068d6660c95c3 Dec 21 06:04:32 rcn-ee: based on vagrantc's last comment here, do you still think that reverting the commit will fix the problem? Dec 21 06:10:06 I just realized, -517 is not an actual error, it's EPROBE_DEFER Dec 21 06:11:02 which happens when a device gets probed before some other devices it references are probed, so EPROBE_DEFER means the driver asks the kernel to try probing it again later Dec 21 06:11:36 so a single -517 from a driver in the kernel log typically means it got successfully probed on the next attempt Dec 21 06:12:05 (most drivers explicitly avoid printing any message on EPROBE_DEFER) Dec 21 06:14:27 rcn-ee: I dtc'd am335x-boneblack.dtb into am335x-boneblack.dts and it looks like this file is prior to the commit that you reference above. Dec 21 06:15:09 rcn-ee: Any other suggestions for fixing the current installation? Dec 21 06:17:25 I've successfully run a 5.10 kernel on my bbb Dec 21 06:18:07 so whatever is causing problems must be some difference between mainline 5.10 and rcn's 5.10-ti kernel (specifically the kernel I've run is 5.10.65-ti-r23) Dec 21 06:19:28 at least I assume it ran successfully, I still have it installed on the bbb and don't remember a failure (and I'd surely have removed it immediately if it didn't boot or didn't have ethernet) Dec 21 06:21:32 yep, it runs fine, with ethernet Dec 21 06:25:21 https://pastebin.com/M6ZLcXZ3 Dec 21 06:28:27 zmatt: thanks. Now, to figure out how to install that version... Dec 21 06:28:54 Hello Dec 21 06:28:56 Or, how that version differs from the one I have Dec 21 06:29:21 dkaiser: you can add http://repos.rcn-ee.com/debian as repo Dec 21 06:29:22 Is this the right place to ask about beaglebone? Dec 21 06:30:06 Guest31: sure Dec 21 06:31:04 dkaiser: there's no metapackage for "latest 5.10-ti kernel" or such though, you need to explicitly install the specific kernel package you want Dec 21 06:31:23 I was facing a issue while compiling the blinkInternalLED.pru0.c using gcc, located at /var/lib/cloud9/PocketBeagle/pru Dec 21 06:31:38 It is giving the err, pru_cfg.h file not found Dec 21 06:33:44 I searched about this issue but could not find anything significant of my help Dec 21 06:35:30 Guest31: heh, looks like these makefiles are extremely crufty Dec 21 06:36:13 zmatt in the makefile provided there, there's just one line of code Dec 21 06:36:54 looks like "make TARGET=blinkInternalLED.pru0" does work.... but EW it doesn't merely build the executable but also immediately runs it, who thought that was a good idea Dec 21 06:38:41 thanks that works Dec 21 06:38:59 I had seen that thing prev, but I forgot '=D Dec 21 06:39:36 oh it doesn't merely run it but also installs it such that it'll get run again at boot, wtf Dec 21 06:40:17 I was a happier person before knowing this makefile existed, lol Dec 21 06:40:41 really? Dec 21 06:41:40 I'm joking, but this makefile *is* kinda gross Dec 21 06:42:24 ... Dec 21 06:43:30 bitflip.pru0.c doesn't runs though Dec 21 06:43:31 like, when you type "make" you expect it to build the various executables, not do nothing unless you specify a build target through some environment variable, and then proceed to implicitly install and execute that target Dec 21 06:43:43 if you follow same suite Dec 21 06:44:05 zmatt yes exactly Dec 21 06:47:20 oh sorry bitflip works Dec 21 06:49:21 so if any pru is working it won't be shown in htop/top right? neither it will be shown as a system job Dec 21 06:49:34 no, it runs completely independent of linux Dec 21 06:51:56 can we run a RTOS there? something like freeRTOS? Dec 21 06:52:21 it has 8KB of program memory per core Dec 21 06:52:29 2048 instructions Dec 21 06:53:02 generally speaking you'd just run a dedicated program, not attempt to run an OS Dec 21 06:53:06 it also doesn't have interrupts Dec 21 06:53:38 so, there is no button interrupt example for this? Dec 21 06:53:41 (it does have an interrupt controller, but its outputs just go to two status bits in r31 that software can test if it wants to) Dec 21 06:54:12 it has no interrupts therefore no there cannot exist an interrupt example Dec 21 06:54:53 so what is its use? I mean practically where can we use this? Dec 21 06:55:39 anything that has strict real-time needs and isn't too complicated, especially things like custom I/O protocols Dec 21 06:56:43 its extremely simple and determinstic instruction timing along with having dedicated gpio wired directly into registers allows for generating signals with single-cycle (5ns) accuracy Dec 21 06:58:13 so can it access any of the SoC's peripherals? like timers, counters and so Dec 21 06:58:30 "beaglelogic" uses pruss to turn a beaglebone into a 12-channel 100Msps logic analyzer, with one pru core sampling its inputs every other cycle and the other pru core writing it out to a ringbuffer in ddr3 ram Dec 21 06:58:35 yes pru can access everything Dec 21 06:59:19 pruss also has local peripherals for timers, you'll want to use those in preference to the SoC ones Dec 21 06:59:42 so like can we make a kernel module which can access the PRUs and make it do things? Dec 21 07:00:06 I guess? I've only ever worked with it from userspace (via uio rather than remoteproc) Dec 21 07:00:30 this is a project of mine: https://github.com/mvduin/py-uio Dec 21 07:02:02 we currently use pru to get accurate audio timestamps, since the timestamps from alsa are utter trash Dec 21 07:03:07 people also use pru to drive large led matrices Dec 21 07:04:22 that project is very well documented Dec 21 07:04:28 thanks for that Dec 21 07:05:03 zmatt: Anything more I can do to assist in testing/troubleshooting the BBB ethernet issue? Dec 21 07:06:53 Guest31: py-uio? surely you're joking, it (regrettably) has almost no documentation... it's still kinda on my to-do list Dec 21 07:09:49 Atleast there's a good readme Dec 21 07:10:01 that's enough Dec 21 07:14:23 zmatt can you explain the concept of far pointer with regards to your program Dec 21 07:14:28 most examples are in assembly since PRU was really designed to be programmed in that rather than C... a C compiler was eventually created (many years after pru was introduced) but pru's instruction set really isn't well-matched to being targeted by a C compiler and the code output quality is... mediocre Dec 21 07:14:29 I saw one in test.c Dec 21 07:18:48 marking the variable as "far" causes it to be placed in a different section (.fardata/.farbss/.rofardata rather than .data/.bss/.rodata), and the linker script will place that in a different memory (the pruss "shared" memory at 0x10000 - 0x12fff rather than the core's local memory at 0x0000 - 0x1fff in the core's memory view) Dec 21 07:20:01 generally speaking "far" and "near" also applies to pointers where "near" means the pointer can be represented in 16 bits by virtue of the thing being pointed to being within a specific data region, I haven't actually checked if that's also the care for clpru Dec 21 07:21:08 i.e. far pointers can point to any memory while near pointers can only point to near variables (which is the default unless explicitly marked as "far") Dec 21 07:23:08 I don't think clpru supports near pointers Dec 21 07:24:12 zmatt: Thanks again for all your help. Please let me know if there is something more I can do to help with testing... Dec 21 07:24:13 yeah it doesn't support applying far/near to pointers, only to variables Dec 21 07:24:58 dkaiser: not really anything I can think of... if you want a quick fix, install a known-working kernel Dec 21 08:32:40 zmatt: I had CONFIG_DEBUG_AM33XXUART=y but it was still wrong, the reason to use earlyprintk was because i had that working earlier but I will look into earlycon soon (i hope). Dec 21 08:33:26 zmatt: i need them because I had a situation where there the kernel crashed before serial was up and running :) Dec 21 08:33:42 Daulity: CONFIG_DEBUG_AM33XXUART only sets the default for the physaddr/virtaddr, so if you already have it wrong your config then setting the right default with CONFIG_DEBUG_AM33XXUART=y no longer helps Dec 21 08:33:55 oh Dec 21 08:34:09 then i do not know where the wrong defaults came from Dec 21 08:34:43 at least that's what the Kconfig looks like to me Dec 21 08:35:24 my config is based on an older config though and it might have been wrongly configured in the past and migrated to the new config in some way Dec 21 08:35:55 that is still something i really want to do start from scratch with the config because I have ran against this kind of thing before. Dec 21 09:02:26 how do chats happen here? Dec 21 09:02:43 If you get disconnected, your chats are gone Dec 21 09:14:14 hi Dec 21 09:14:28 hello Dec 21 09:14:32 how are you Dec 21 09:14:41 can u help me i have problem Dec 21 09:14:50 with beaglebone black Dec 21 09:15:17 sure, if I can Dec 21 09:15:23 i try to login beaglebone Dec 21 09:15:31 through it's ip Dec 21 09:15:40 (192.168.7.2) Dec 21 09:15:57 i tried the default authencation Dec 21 09:16:07 but Dec 21 09:16:22 give me invaild Dec 21 09:16:27 so what should i do Dec 21 09:16:29 ?? Dec 21 09:17:00 it connect but didn't allow me to Dec 21 09:17:02 login Dec 21 09:17:04 are you doing a ssh to the board or using cloud9? Dec 21 09:17:17 ssh to board Dec 21 09:17:22 through putty Dec 21 09:17:33 u need to ssh to debian@192.168.7.2 Dec 21 09:17:40 and give pass temppwd Dec 21 09:17:57 i tried this solution Dec 21 09:18:05 but it didn't help Dec 21 09:18:42 whats the err you are getting? Dec 21 09:18:54 or you are simply unable to login? Dec 21 09:18:58 password is incorrect Dec 21 09:19:23 how to reset it Dec 21 09:19:27 to default Dec 21 09:19:45 pass is temppwd Dec 21 09:19:55 if none works, flash a new image Dec 21 09:20:02 may be the one used this board before me changed it Dec 21 09:20:26 so how i reset it Dec 21 09:20:41 ?? Dec 21 09:21:03 If you can't login, u can't reset Dec 21 09:21:11 flash new image i'm new to embedded linux Dec 21 09:21:21 oh, same here Dec 21 09:21:26 so may be this solution is big deal for me Dec 21 09:22:11 how to reset it Dec 21 09:22:12 ? Dec 21 09:22:16 well, I would have given direct solution Dec 21 09:22:25 but I insist you search a bit Dec 21 09:22:28 did u try to reset it Dec 21 09:22:39 on how to flash a new image onto your board Dec 21 09:22:42 i searched before Dec 21 09:22:53 some say the solution is to rset Dec 21 09:23:00 reset it Dec 21 09:23:05 yea reset it Dec 21 09:23:11 and search how to do that Dec 21 09:23:36 i come here to ask professional people who tried this solution before Dec 21 09:23:51 that's easy btw Dec 21 09:23:56 however, wait Dec 21 09:24:03 am sending u the link Dec 21 09:24:10 great Dec 21 09:24:43 u have beaglebone black rev c right? Dec 21 09:24:53 I have BBG Dec 21 09:24:55 green Dec 21 09:24:59 wow Dec 21 09:25:03 the solution works for all Dec 21 09:25:04 https://learn.adafruit.com/beaglebone-black-installing-operating-systems/flashing-the-beaglebone-black Dec 21 09:25:08 even it's better Dec 21 09:28:12 so how can i find the default image Dec 21 09:28:13 ? Dec 21 09:28:55 goto beaglebone's  official website Dec 21 09:29:03 and search for official debian Dec 21 09:29:05 image Dec 21 09:30:12 okay thank you for your help Dec 21 09:30:20 no worries Dec 21 09:30:51 can i have your email or anything to communicate with u if i faced any issue Dec 21 09:31:07 am not any offcial guy here Dec 21 09:31:12 I joined today Dec 21 09:32:00 anyone here tried to use JTAG with the board? Dec 21 09:52:18 no problem just give me any way to connect u if i faced any problem Dec 21 09:52:21 ? Dec 21 09:54:57 u use telegram? Dec 21 10:10:51 Guest31: most people use irc clients other than the web client, which typically maintain scrollback, and there are also public logs here: https://libera.irclog.whitequark.org/beagle/ Dec 21 10:12:05 btw you can change your name to something other than Guest-something using the /nick command (e.g. "/nick desirednamehere"), as long as it's not yet in use (on this irc network) Dec 21 10:12:43 yeah Dec 21 10:13:46 I have an old beaglebone with jtag header soldered on that I used for some baremetal experiments, but generally speaking there's very rarely any reason for people to use jtag Dec 21 10:14:12 on the beaglebone Dec 21 10:14:27 I also don't have a good reason Dec 21 10:14:30 just wanna do Dec 21 10:14:41 also, that link is really really old Dec 21 10:14:49 they're talking about Angstrom Dec 21 10:15:11 somewhere they might have mentioned debian Dec 21 10:15:33 all u need to do is uncomment a line, that's all Dec 21 10:16:20 the instructions are wrong too, the S2 button (boot button, which they call "user button") usually isn't needed at all, and if you do use it you can let go once the power led turns on, there's absolutely no reason to hold it until all 4 leds light up let alone for seconds longer Dec 21 10:17:11 that part is no longer necessary either, you can just download a pre-made flasher image from the "Flasher Debian images" section of https://beagleboard.org/latest-images Dec 21 10:18:08 flash onto SD card (preferably using Balena Etcher, except version 1.7.1 where they broke shit) and boot from it, and it'll automatically proceed to reflash eMMC Dec 21 10:19:14 oh, so that's why its called flasher, cause it's instantaneous Dec 21 10:19:25 no it's called a flasher because it flashes to eMMC Dec 21 10:24:18 yea, I meant that ... like instantaneouls flashes without any commenting or anything Dec 21 10:25:27 the only difference is still that line in /boot/uEnv.txt, downloading the flasher image just saves you from having to manually modify a standalone image into a flasher Dec 21 10:26:26 btw, assuming that was the same Guest31, you asked about near vs far earlier... here's more (some might say excessive) details, including how it affects performance: https://pastebin.com/CU1zCM9V Dec 21 10:26:36 yea I read that Dec 21 10:26:43 from the logs Dec 21 10:26:52 this has more details though Dec 21 10:27:10 possibly more than needed, but I thought I'd share Dec 21 10:27:24 thanks for that Dec 21 10:27:54 Any good reference from where to learn these C attributes? Dec 21 10:28:21 well these are not standard C attributes, but they're documented in the compiler manual https://www.ti.com/lit/ug/spruhv7c/spruhv7c.pdf Dec 21 10:29:09 in the py-uio code I just use "far" to put variables into shared memory Dec 21 10:29:31 (though technically any core can access any of the memories) Dec 21 11:27:14 so you read that entire doc? Dec 21 11:30:18 btw, thanks to the beaglebone team, I'm super happy with my beaglebone Dec 21 11:30:24 openbsd is running nicely Dec 21 11:31:08 I tried arch Dec 21 11:31:12 failed even to boot Dec 21 11:38:17 I've never tried arch but openbsd works on beaglebone black rev c Dec 21 12:12:04 ya Dec 21 12:12:10 i have one Dec 21 12:14:47 +201289085503 Dec 21 13:09:09 hi every one Dec 21 13:12:34 ?? Dec 21 13:12:35 ?? Dec 21 13:12:36 ? Dec 21 13:14:08 hi Mahmoud Dec 21 13:14:41 if i have any question what's average time of response Dec 21 13:14:42 ?? Dec 21 13:15:12 cause most of time i stick with problems Dec 21 13:15:15 ? Dec 21 13:15:38 stuck* Dec 21 13:25:16 ? Dec 21 13:25:18 ????? Dec 21 13:28:42 Mahmoud: the developers/staff here seem very friendly Dec 21 13:28:52 IRC often requires you wait a few minutes, sometimes a few hours, but they will reply Dec 21 13:28:56 they may be asleep right now Dec 21 13:29:04 but they will answer you if you wait Dec 21 13:29:22 okay thank you Dec 21 13:29:34 thank you very much Dec 21 13:29:41 they answered me about 3 hrs ago Dec 21 14:11:13 hi Dec 21 14:12:24 hi Dec 21 14:12:32 okay so now its working Dec 21 14:12:54 I was just testing out irssi on cli Dec 21 14:13:22 and we are same guy Dec 21 14:14:37 clear Dec 21 14:25:25 clear Dec 21 14:53:15 Hello I have been doing development on the BeagleBoard X15 and just started to work on the BoneScript in regards to GPIO programming ususage, Is there any documentation out that shoes how the expansion headers map to bone script? I ahve been trying for days and all that comes are details for the Beaglebone Black Dec 21 15:50:14 Angel_Sosa, Bonescript is not maintained, just use sysfs.. Dec 21 16:12:29 ok thats great to know thanks Dec 21 17:42:12 vagrantc, got ethernet working on v5.16.x: https://gist.github.com/RobertCNelson/67eca1f66659614d08a8a291203785f3 i'll doucmnet the other kernels.. Dec 21 17:51:38 rcn-ee: good news, thanks! Dec 21 17:52:33 rcn-ee: working out of the box on 5.16, or do you need patches/adjustments still? Dec 21 17:54:14 just the config change... just tested v5.10.x, that one works for me without the change.. Dec 21 17:54:43 in the .dts ? Dec 21 17:56:53 vagrantc, this is my dts changelog: https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/9bdd13fbea468a8f71a8029d1326cc2469c78c7e cpsw_* dts matches mainline as-is.. Dec 21 18:03:07 vagrantc, and found a third regression on v5.15.10... atleast ethernet is fixed, stil trying to fix a usb issue.. but now i have a fun lockup! ;) Dec 21 18:03:44 What is the process for these changes making it into mainline and the "standard" debian builds? Dec 21 18:07:11 dkaiser, rcn-ee and vagrantc talk, vagrantc sends email to debian kernel team. ;) Dec 21 18:07:12 someone emails patches to appropriate kernel lists and deals with issues raised ... and then gets them backported to older kernels Dec 21 18:07:18 hah Dec 21 18:09:26 vagrantc and rcn-ee, how reasonable is it to expect that the debian builds "just work" on BBB? Or, should one generally use a build based on rcn-ee repositories? Dec 21 18:10:16 dkaiser: they used to work fine, so anytthing that doesn't work is generally a bug that needs to be fixed Dec 21 18:10:52 the beagleboneblack is what got me neck-deep in arm stuff, for better or worse :) Dec 21 18:11:23 i was maybe only in to my ankles or knees up till then ... Dec 21 18:13:08 dkaiser, it only broke as someone decided to write a new cpsw driver, and none of use really nocticed.. Dec 21 18:13:21 vagrantc, I may end up deeper than I had anticipated... Dec 21 18:14:28 dkaiser, normally, am335x is at a point, everything is really mainline, so it should just work... unless someone decides to rewrite something, and we don't properly handle the transition.. Normally am335x is kinda boring every merge cycle. ;) Dec 21 18:14:30 originally, I had not planned to start studying the sources for the kernel network stack... Dec 21 18:16:32 dkaiser: you might be able to install buster still, and then upgrade to bullseye using the older kernel Dec 21 18:16:57 dkaiser: kind of ugly but if you don't want to fall down this particular rabbit hole... Dec 21 18:17:10 or just use the beagleboard.org images... Dec 21 18:17:12 * vagrantc shrugs Dec 21 18:17:34 you should be able to install debian kernel on beagleboard.org images. ;) Dec 21 18:20:19 My end goal is to be testing OpenCPN (maritime chart plotter + multiple functional plug-in modules) on various debian stable releases. Dec 21 18:20:59 I had hoped that it was simply matter of downloading and installing ready made debian release images. Dec 21 18:21:19 But, this is fun...? Dec 21 18:21:51 dkaiser, which version do you need, stretch, buster, bullseye, etc? Dec 21 18:23:08 I wanted to start with bullseye, and then look backwards at least one release (maybe more, if it is not too much work...) Dec 21 18:23:51 dkaiser: try with buster at this point, we'll get the other issues fixed eventually Dec 21 18:24:28 dkaiser, for bullseye i'm still cleaning it up for beagleboard.org, it's getting closer: https://rcn-ee.net/rootfs/debian-armhf/2021-12-21/ Dec 21 18:25:08 vagrantc, It seems like I remember in a previous IRC interaction that maybe networking was also an issue in buster? Dec 21 18:25:10 dkaiser, for buster, these get re-built every month: https://forum.beagleboard.org/t/debian-10-x-buster-monthly-snapshots/31203 Dec 21 18:25:23 dkaiser: i *hope* not, but would be good to findout Dec 21 18:26:30 vagrantc, it might have just been earlier releases of bullseye, however. I don't remember for sure. Dec 21 18:26:50 * vagrantc checks Dec 21 18:27:24 dkaiser, was it my version? there was a lot of churn to convert from connmanctl -> systemd-networkd.. espically with usb0/usb1, that's been fixed now.. Dec 21 18:27:39 vagrantc, how are you set up to check so quickly? Dec 21 18:27:52 ouch, buster kernel OOPSes Dec 21 18:28:12 rcn-ee, no I was working with the "straight" debian builds Dec 21 18:28:15 dkaiser: i have a machine plugged in with remote power cycling and serial console Dec 21 18:28:30 dkaiser: and testing network booting from u-boot Dec 21 18:28:57 only if i get a broken u-boot installed do i have to deal with the physical board directly :) Dec 21 18:30:45 and a machine on the network that supports network booting off of stretch, buster, bullseye, and the daily debian-installer builds ... Dec 21 18:31:41 or rather, a tftp server ... Dec 21 18:33:55 it's been a while since i've tried, but never had any luck with mainline u-boot on the beaglebone-ai either ... Dec 21 18:34:21 and havne't been running the beagle-x15 lately... Dec 21 18:34:35 and fried my pocketbeagle a while back ... Dec 21 18:34:43 * vagrantc is not really doing a great job with the beagles Dec 21 18:35:31 i fried a prototype last week.. luckly have 2 more units... but disappointed wiht my self.. Dec 21 18:37:36 ouch Dec 21 18:42:38 it happens Dec 21 18:44:55 i am on board 7 if it makes you feel any better Dec 21 18:45:25 fortunately i do my BBB work late at night so people do not hear the yell when the computer lets out the chrip of death Dec 21 18:49:44 mattb0ne, ouch! i was close to that with BeagleBone Blue's.. Got one to smoke really nice.. Dec 21 18:49:53 lol Dec 21 18:50:02 we got a whole stack of dead BBBs Dec 21 18:50:23 they don't call them blue for no reason Dec 21 18:50:33 zmatt, you should re-sell the TPS's.. there's a nice market right now for them.. Dec 21 18:50:47 rcn-ee: hah Dec 21 18:51:17 vagrantc, blue... darn usart0 doesn't have any protection... accsdently hit a key with on console over usb-ftdi.. = fried blue.. just takes one keystroke.. Dec 21 18:51:39 it's cheaper that way Dec 21 18:51:43 trick is to leave the battery plugged in all the time, only protection.. Dec 21 18:52:49 the blue's power scheme also looks like an accident waiting to happen... e.g. the GPS header provides an always-on-5V supply for the GPS module, which also means that gps module wlil drive its uart output high even when the am335x is powered off Dec 21 18:52:59 hah, this machine still has images leftover from debian jessie :) Dec 21 18:54:35 dkaiser: fwiw, the stretch image appears to boot and detect network ... 4.9.x Dec 21 19:04:27 zmatt, i think the blue designer, wanted to sell boards endless.. Dec 21 19:08:26 what would cause your swap to be used before memory Dec 21 19:08:39 my code keeps blowing up Dec 21 19:09:24 nothing, it just means your code ran out of memory hence the kernel started to use swap Dec 21 19:09:53 but my memory was at like 15% and increasing but swap is at 100% Dec 21 19:10:05 the program will go until OOM Dec 21 19:10:20 i guess there is something glaringly wrong with my code Dec 21 19:10:25 i put the camera on a thread Dec 21 19:10:25 then whatever you're using to determine those numbers is probably wrong Dec 21 19:10:33 https://pastebin.com/hrUg1zQB Dec 21 19:10:36 here is my code Dec 21 19:10:50 not sure why it is eating up memory Dec 21 19:11:07 i am releasing the image in the camera thread Dec 21 19:11:12 i am not even saving in this one Dec 21 19:11:21 i should trim hold on Dec 21 19:12:04 this is a calibration run Dec 21 19:12:17 which only displays the image in the qt form and does not interact with the BBB Dec 21 19:12:30 so my issue is just with how the camera works with asyncio I guess Dec 21 19:12:44 asyncio and QT Dec 21 19:14:07 first of all, probably unrelated to your memory leak but don't use queue.Queue to transfer images to your main event loop Dec 21 19:14:35 .get() on these queues will block your entire main event loop (i.e. all asyncio stuff and your GUI) Dec 21 19:15:41 ok Dec 21 19:15:59 i saw it as a way to getting the data out of the thread Dec 21 19:16:07 in general, any interaction between a thread and anything else requires a great deal of care Dec 21 19:16:40 how can I have it produce images to be consumed in my main thread Dec 21 19:16:51 blocking on the images produced by the thread makes the entire thread pointless Dec 21 19:17:14 true Dec 21 19:17:23 they have an asyncio queue Dec 21 19:17:26 i could use that Dec 21 19:17:30 nope Dec 21 19:17:33 ok Dec 21 19:17:34 lol Dec 21 19:17:35 can't use asyncio stuff from a thread Dec 21 19:17:41 grrr Dec 21 19:17:45 so how do I get the images out Dec 21 19:17:47 unless the function explicitly says you're allowed to Dec 21 19:18:09 also how do I reset my swap it is still full according to my system monitor even though I stopped my prgam Dec 21 19:18:13 program Dec 21 19:18:19 so, last time I asked what exactly you were doing with the images, you did not mention this part of it, you just said you wanted to save it together with data from the bbb Dec 21 19:18:52 memory from other applications that got swapped out will get swapped in again automatically when it's accessed Dec 21 19:19:08 no need to worry about it Dec 21 19:22:18 also, your queue doesn't have a size limit hence can grow without bounds, causing an OOM, if the consumer consumes images slower than the image producer is producing them Dec 21 19:22:44 also, "await asyncio.sleep(0) # required to allow GUI to update" ... no, that's just a side-effect of you blocking the entire event loop with image_queue.get() Dec 21 19:23:24 so i do not need it Dec 21 19:23:47 i can take out and I can specify a size on the queue but I am getting rid of it right ? Dec 21 19:23:54 you are yes Dec 21 19:24:02 what should I replace it with Dec 21 19:24:02 though I'm not sure what's the replacement Dec 21 19:24:07 i see Dec 21 19:24:52 especially since I don't know what kind of threadsafety this pylon SDK has Dec 21 19:24:55 if any Dec 21 19:28:28 it's possible it's unsafe to share pylon images between threads entirely Dec 21 19:28:54 I'd consult the sdk documentation, except none is available on the web Dec 21 19:31:45 in general, don't assume anything is safe to share between threads unless you have explicit confirmation that it is Dec 21 19:33:57 also, a hazard of submitting save_image to a thread pool is that if that in fact images can't be saved as fast as they're being captured, you'll run out of memory as jobs accumulate in the thread pool queue Dec 21 19:35:17 the only way to prevent that is by tracking the number of images "in flight" and limiting that by refraining from capturing more images if necessary Dec 21 19:35:34 the bookkeeping to do so is non-trivial, especially with all the threadsafety issues Dec 21 19:39:29 also your QImage code is a crash waiting to happen Dec 21 19:42:50 hmmm Dec 21 19:43:24 i could not image continuously and ask for an image one at a time Dec 21 19:44:31 I'm honestly also not sure I'm in the mood to ponder this mess right now, sorry Dec 21 19:51:07 Hi all:)  Does anyone know how to can run wireshark on the beaglebone to analyze activity on its USB ports? Dec 21 19:51:52 google "usbmon" Dec 21 19:52:50 ok\ Dec 21 19:53:08 (though running wireshark on the bbb sounds painful, I'd be more inclined to use commandline tools and if need be transfer a packet trace from the bbb to my laptop and analyze it in wireshark there) Dec 21 19:54:52 afk Dec 21 19:55:23 Thank you for the reply zmatt. I am using the beaglebone on virtualbox ubuntu (I have wireshark running here). So I have tried capturing packets using tcpdump to view them on Ubuntu, but tcpdump is not available on my beaglebone ... Dec 21 19:57:23 dkaiser: well, managed to get it working with stretch's kernel ... 4.9.x Dec 21 20:06:56 vagrantc, thanks for the update. Dec 21 20:10:44 going to upgrade the userspace and install all the various kernels to see... Dec 21 20:52:35 Alex93, tcpdump is available: https://packages.debian.org/bullseye/tcpdump Dec 21 20:53:14 Alex93: just install tcpdump (sudo apt update && sudo apt install tcpdump) Dec 21 21:08:07 rcn-ee & zmatt:  I am using a beaglebone green and I cannot install tcpdump. Do you guys have any idea why I cannot install this?   debian@beaglebone:~$ sudo apt install tcpdump Dec 21 21:08:08 Reading package lists... Done Dec 21 21:08:08 Building dependency tree Dec 21 21:08:09 Reading state information... Done Dec 21 21:08:09 The following NEW packages will be installed: Dec 21 21:08:10   tcpdump Dec 21 21:08:10 0 upgraded, 1 newly installed, 0 to remove and 312 not upgraded. Dec 21 21:08:11 Need to get 377 kB of archives. Dec 21 21:08:11 After this operation, 796 kB of additional disk space will be used. Dec 21 21:08:12 Err:1 http://deb.debian.org/debian-security stretch/updates/main armhf tcpdump armhf 4.9.3-1~deb9u2 Dec 21 21:08:12   Temporary failure resolving 'deb.debian.org' Dec 21 21:08:13 E: Failed to fetch http://deb.debian.org/debian-security/pool/updates/main/t/tcpdump/tcpdump_4.9.3-1~deb9u2_armhf.deb Temporary failure resolving 'deb.debian.org' Dec 21 21:08:13 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Dec 21 21:08:14 debian@beaglebone:~$ ^C Dec 21 21:08:14 debian@beaglebone:~$ Dec 21 21:08:38 I mean, if the bbb doesn't have an internet connection it's not going to be able to install packages off the internet Dec 21 21:08:55 also, debian stretch is really ancient Dec 21 21:12:36 * vagrantc chuckles as vagrantc has installed stretch twice today :) Dec 21 21:13:27 Alex93, oh fun, any reason your still on stretch? Dec 21 21:14:51 it's the most recent version of debian where debian-installer works on the beagleboneblack :) Dec 21 21:15:19 pretty sure it worked ok earlier in the buster and even bullseye release cycles... Dec 21 21:15:21 Alex93, is your Green, connected thru the network on the USB cable or ethernet? Dec 21 21:22:40 rcn-ee, I am basically developing drivers on ARM Cortex4 and after debugging, I am only using the beaglebone to analyze transmission packets from the ARM UART (through RS232 to USB) into the beaglebone USB pot. The beaglebone is currently connected to the host ubuntu computer which can control via ssh all beaglebone installations and updates and so Dec 21 21:22:41 far all periferal seem ok. I can even control the beaglebone through Node-red. Dec 21 21:25:50 Alex93, okay, temporary connect the Ethernet cable and install tcpdump Dec 21 21:52:01 Does anyone have any sample code or a link I can reference on setting and manipulating GPIO pins on the expansion headers  for a Beagle X15 Dec 21 21:53:34 Does anyone have any sample code or a link I can reference on setting and manipulating GPIO pins on the expansion headers for a Beagle X15 using C or C++ Dec 21 21:53:48 I would really appreceate it Dec 21 23:03:41 dkaiser: well, interesting news ... installing with debian-installer from stretch, and then upgrading to buster, and then upgrading to bullseye, the network seems to work Dec 21 23:04:20 vagrantc: quite the process! Dec 21 23:05:45 but at least it means the kernel works; there's something missing in debian-installer Dec 21 23:06:36 same for the 4.19 kernel from buster (although running on bullseye, didn't test booting part-way through) Dec 22 01:02:16 defining the queue size stopped the OOM **** ENDING LOGGING AT Wed Dec 22 02:59:56 2021