**** BEGIN LOGGING AT Fri Jun 26 03:01:39 2020 Jun 26 08:37:38 set_: no Jun 26 08:38:06 set_: PATH and ld.so.conf have nothing to do with each other, and you generally have no need to modify either Jun 26 08:58:48 LD_LIBRARY_PATH does though Jun 26 10:16:54 hello Jun 26 10:18:36 hello there Jun 26 12:49:29 m Jun 26 12:52:12 I've been unable to discover if device tree entries are position dependent. I decompiled the old kernel's dtb, and the one for the new kernel. I clearly missed some things, but others are present at the correct branch, but in a different place. I'm trying to tell if that's a problem. Jun 26 13:08:03 Ragnorok: it shouldn't be Jun 26 13:08:16 Thanks! I was thinking that would be the case but wanted to be sure. Jun 26 13:08:33 any situation where the order matters would be a kernel bug Jun 26 13:08:39 lol Jun 26 13:09:08 like, it probably influences the order in which devices are probed Jun 26 13:09:13 but that shouldn't matter Jun 26 13:10:04 but it might, if a driver doesn't correctly handle EPROBE_DEFER Jun 26 13:11:17 Sure. But overall probably not an issue. Until I have a reason to believe otherwise I will work on the premise it's non-positional. Jun 26 13:12:10 also, reading decompiled dtbs sounds awful, and obviously most changes will probably be due to the substantial difference in upstream dtsi files Jun 26 13:12:30 due to the substantial difference in kernel version Jun 26 13:13:18 I can't say it's the funnest thing I've done, but my expectation is things like i2c changes will be largely similar. At least the decompiled bits look very similar. Jun 26 13:14:37 what sort of problem are you trying to debug? does a device not show up? kernel errors? Jun 26 13:14:50 what i2c changes? Jun 26 13:17:44 Kernel won't load. It gets some errors and stops at the initramfs prompt. Jun 26 13:18:02 okay so kernel does load but it can't find the root filesystem? Jun 26 13:18:04 what errors? Jun 26 13:18:23 I'm going to whack at this a bit more and next time it fails I'll get a pastebin. Jun 26 13:18:34 and just to confirm, this problem doesn't happen with the default dtb ? Jun 26 13:18:45 It doesn't. Jun 26 13:18:49 okay Jun 26 13:19:15 Actually I lost my dtb changes by accident. It doesn't happen with the my old dtb but it does with my new one. lol Jun 26 13:19:33 My "old" being the new kernel, dtb I lost the dts/i for. Jun 26 13:19:58 When I decomp that one I see I have errors in it, so it's not usable. Jun 26 13:20:34 and this is why you should do your work in a git clone of the BeagleBoard-DeviceTrees repo and commit early, commit often Jun 26 13:22:59 and if you have a dts file that starts with #include "am335x-boneblack.dts" and adds your changes to it with a bunch of fragments below that, grouped by topic, then just disable some or all of those fragments with #if 0 and bisect until you've found the problem Jun 26 13:24:48 I wan't able to build that repo. My file is what you suggest, except maybe I need fragments to put things in the right place. I was thinking I may have to go there. Jun 26 13:25:01 wasn't able to build that repo? Jun 26 13:25:03 why not? Jun 26 13:25:17 maybe update dtc? (apt package "device-tree-compiler") Jun 26 13:25:36 if you can't build that repo, how are you compiling your dts ? Jun 26 13:26:19 The kernel builds dtc for me. I didn't know where it was and was to dumb that day to look for it. So I did the same thing you suggested w/ the new file, in the kernel dts dir. Jun 26 13:26:47 right, but rebuilding the kernel any time you want to make a dts change sounds tedious as hell Jun 26 13:27:01 I'm not. It will do just dtb from there. Jun 26 13:27:04 I never suggested working in the kernel dts dir Jun 26 13:27:20 I never said you did. I said I couldn't get the repo to build so I worked there. Jun 26 13:27:27 oh I misread Jun 26 13:28:08 I'm doing exactly what you said, but I'm doing it in the kernel tree. I can do a make some.dtb and it works. Jun 26 13:29:04 Now I know where dtc is I can probably move back to the repo. Jun 26 13:42:45 Hi, where is the title string "U-Boot 2020.01 .rc0 ... configuration " stored when editing using make menuconfig. It is not from .config file. Jun 26 13:43:36 Ragnorok: nicer example for a customized dts: https://pastebin.com/b60VG5Ys Jun 26 13:46:48 david44: couldn't it be found using '/' in menuconfig? Jun 26 13:47:17 PH3550: if it's not in .config then it's not a config var Jun 26 13:47:21 hence not found in menuconfig Jun 26 13:47:54 zmatt: oops! Jun 26 13:48:49 Ragnorok: https://pastebin.com/b60VG5Ys updated to fix mistake in comments Jun 26 14:04:48 I found: It is from Makefile Jun 26 14:06:41 @zmatt: how's your judgment about this way to automount with systemd? Jun 26 14:06:43 https://blog.tomecek.net/post/automount-with-systemd/ Jun 26 14:16:12 Parduz: pointlessly complicated and probably not applicable for you Jun 26 14:17:15 "complicated" is relative :) What i mean is that i tend to understand it better than fstab line. Which is my fault for sure, but Jun 26 14:17:25 since 1. using fstab is way easier, systemd will generate the automount unit for you 2. "automount" does not do what you think it does Jun 26 14:17:59 automount (in the sense used here) is mostly useless for removable media Jun 26 14:18:20 and I seem to recall you were doing this for usb sticks Jun 26 14:18:34 yup Jun 26 14:19:17 automount means the filesystem is automatically mounted on first access, something typically used to mount e.g. network filesystems only when needed Jun 26 14:19:52 if the filesystem is unavailable at that time, the automount unit will end up in failed state Jun 26 14:20:25 it will not look for the device showing up and mount it then Jun 26 14:20:49 oh. yes, i didnt understood that way. Jun 26 14:22:44 if the device has a consistent device path (or you're able to give it one using an udev rule) then just create an fstab entry for it with flag "user" to allow your program to mount and umount it when it needs to access it Jun 26 14:23:03 that's what i'd avoid Jun 26 14:23:08 why? Jun 26 14:23:14 that's the simplest and most sensible solution Jun 26 14:23:18 i'd like more to have the USB mounted by the system Jun 26 14:23:32 and how would the system know when your application is done accessing it so it can be safely unmounted? Jun 26 14:24:07 the program will tell to the user "you can remove the USB stick now" Jun 26 14:24:07 how would your application know the filesystem has been mounted successfully? Jun 26 14:24:27 by checking the /media/sda folder existence Jun 26 14:24:29 and how does the program know the usb stick can be safely removed? Jun 26 14:24:39 the folder for a mountpoint always exists Jun 26 14:24:46 even before it's mounted Jun 26 14:24:53 nope Jun 26 14:25:05 for normal mountpoints (including automountpoints) yes Jun 26 14:25:09 there's dev/sda but not media/sda Jun 26 14:25:32 the only exception is if you have something like udisks that's dynamically creating mountpoints Jun 26 14:25:44 even in that case, the mountpoint is created _before_ the mounting process starts Jun 26 14:26:13 (since the mount() kernel call requires the existence of the mountpoint) Jun 26 14:27:10 anyway, you need to explicitly unmount it before you can tell the user to safely remove it, which you'll generally not be able to do unless you also mounted it Jun 26 14:27:22 and doing one but not the other makes little sense anyway Jun 26 14:28:51 Repo has duplicate addresses in it. https://pastebin.com/7Lsr16yX Jun 26 14:29:00 so like I said: if the device has a consistent device path (or you're able to give it one using an udev rule) then use an fstab entry, have your program perform mount/umount, and if you want notification that the device has appeared then the simplest solution it to use libudev (or some wrapper) Jun 26 14:30:34 i don't get this: why can't i just be sure to have sync() it and let the system unmount it when it get removed? Jun 26 14:30:35 Ragnorok: I understand why it's warning about it, but it's correct in this case Jun 26 14:31:02 Parduz: the system can't unmount once the device has been removed since the device will have been removed Jun 26 14:32:03 I'm also not sure whether sync() actually guarantees that the NAND flash writes on the usb stick have completed Jun 26 14:32:19 Ok. Just wanted to be sure. So when I do my custom I can ignore this set of output. Thank! Jun 26 14:32:24 I think it ought to, but I'm not sure it does Jun 26 14:32:34 Ragnorok: interestingly I'm getting them at all Jun 26 14:35:57 Parduz: like, maybe it works, at least most of the file, but the filesystem will still not be cleanly unmounted. if you're going to inform the user he can safely remove the usb disk, it makes no sense to not make sure the filesystem is unmounted before doing so (instead of merely calling sync()) Jun 26 14:36:03 *most of the time Jun 26 14:36:27 k Jun 26 14:36:30 Parduz: it's not significantly more complicated, and it's the Right Thing t odo Jun 26 14:36:31 to do Jun 26 14:41:21 if it is not possible give the usb stick a consistent device path (hence can't use fstab), or you want to avoid using the mount/umount utilities (e.g. to be able to use NoNewPrivileges=yes on your service), the alternative would be to use udisks and communicate with it via dbus Jun 26 14:43:24 though that uses polkit, which might be annoying Jun 26 14:45:38 although it seems to be very flexible, so presumably you can make it authorize based on what application is requesting the action and prevent it from ever trying to show an authorization dialog or bullshit like that Jun 26 14:46:47 udisks would have the additional benefit of being able to reformat usb sticks if necessary (if suitable authorization is present) Jun 26 14:47:31 mh... i'm starting with fstab: Jun 26 14:47:43 this line should work? /dev/sda0p1 /mnt/usb auto users,uid=1000,gid=1000,fmask=0137,dmask=0027,noauto 0 0 Jun 26 14:48:10 looks plausible enough Jun 26 14:48:22 partitions will likely be Fat32, exFat32 or NTFS Jun 26 14:49:10 * exFat , sorry Jun 26 14:49:41 using exfat-fuse and ntfs-3g ? Jun 26 14:51:01 I wonder how "auto" as filesystem type works, how it finds the appropriate mount-utility Jun 26 14:51:41 Parduz: I stuck a udev rule in to run a script. That script mounts the USB stick, runs some stuff against it, then unmounts it. I had some issues where it wasn't getting the same device all the time, and the udev rule worked around that by capturing the device path and passing it to the script. Jun 26 14:51:59 Ragnorok: udev rules cannot mount things Jun 26 14:52:02 normally Jun 26 14:52:19 unless you messed with systemd-udevd.service Jun 26 14:53:30 Ragnorok: the correct way to do what you're saying is by using the udev rule to 1. give the device a consistent alias 2. start a systemd service to do your thing (using ENV{SYSTEMD_WANTS}) Jun 26 14:53:46 Right. I did a "hotplug" service as well, iirc. There's a udev rule as well that ties it together. Jun 26 14:54:33 like, udev RUN rules are meant to invoke tiny fast utilities to tweak something on the device or such Jun 26 14:55:13 zmatt: mount -t auto uses blkid and as fallback everything listed in /proc/filesystems Jun 26 14:55:14 and udev normally runs in an isolated environment that precludes it from mounting anything Jun 26 14:55:15 I have it doing ENV() on add of any sd device. Jun 26 14:56:06 Ragnorok: but in this case there's clearly a user interface and user involvement is desired, so then it makes less sense to go this route Jun 26 14:56:33 Roit. I read history but missed the UI bit. I'll stop being static now. Jun 26 14:56:45 like, monitoring the completion of the systemd service in the user interface is probably more complicated than just doing the whole thing there Jun 26 14:57:29 (though it is another option if doing mount/umount in the UI is undesirable for privilege separation reasons) Jun 26 14:57:52 Ragnorok: I wouldn't call it "static", it's a reasonable solution but probably not the easiest in this case Jun 26 14:59:48 sudo mount /dev/sda /mnt/usb Jun 26 14:59:48 mount: /mnt/usb: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error. Jun 26 14:59:53 :( Jun 26 15:00:08 -t vfat? Jun 26 15:00:23 if it's vfat then you don't need -t vfat Jun 26 15:00:25 it'll autodetect that Jun 26 15:00:47 Parduz: you never did answer this: Jun 26 15:00:50 16:49 <@zmatt> using exfat-fuse and ntfs-3g ? Jun 26 15:01:07 the linux kernel does not support exfat nor ntfs Jun 26 15:01:18 That hasn't been my experience, so I always include it. Jun 26 15:01:29 (well, it supports nfts read-only, which isn't of use to you) Jun 26 15:01:38 Ragnorok: really? I've never seen it not work Jun 26 15:01:39 this stick is a Fat32 Jun 26 15:01:45 that's weird Jun 26 15:01:50 f.... i have a call Jun 26 15:01:54 :( Jun 26 15:01:57 zmatt: Come now, you should know by now I always see things no one else does. Jun 26 15:02:17 well now I'm starting to doubt myself Jun 26 15:02:36 Got my i2c mux loading. Progress! Jun 26 15:02:39 since I do have explicit "vfat" in the fstab entry for sd cards on one system here Jun 26 15:02:44 hmm Jun 26 15:04:44 It also looks like the DT repo is loading uio already. Bonus. Jun 26 15:05:24 Ragnorok: -bone kernels will use uio-pruss by default yeah Jun 26 15:06:05 Parduz: do you have dosfstools installed? Jun 26 15:06:09 Ragnorok: ditto :P Jun 26 15:06:49 since based on what mru said: if blkid is used to identify the filesystem type, then mount probably tries to invoke "mount.$TYPE" Jun 26 15:07:12 but for vfat, that mount helper is part of dosfstools, even if the filesystem itself is supported by the kernel Jun 26 15:08:48 zmatt: I need help/guidance regarding that UART Jun 26 15:09:25 MattB0ne: I've experimented a bit with the pru uart... I've at least fixes the syntax-errors, but I still haven't been able to get it to work right Jun 26 15:09:38 oh ok Jun 26 15:09:46 the uart that is, as far as i can tell the problem isn't in my py-uio code Jun 26 15:09:56 i will just use the regular UART comms that we had working then for now Jun 26 15:10:06 but either the UART is buggy or there's something fundamentally wrong in my understanding of it Jun 26 15:10:19 for clarification this is using the hardware UART or SW UART Jun 26 15:10:46 I get confused since the PRU can access anything on the board Jun 26 15:10:54 but supposedly has a dedicated high speed uart Jun 26 15:11:12 the pruss uart. I've never done anything with a software uart, nor would it make sense for code for one to be part of py-uio Jun 26 15:19:31 there's no reason for you to be thinking about a software uart Jun 26 15:20:23 ok Jun 26 15:20:35 well thanks for looking into it Jun 26 15:23:26 dosfstools: yes, it's installed Jun 26 15:24:18 sda is vfat Jun 26 15:24:20 wait Jun 26 15:26:00 should i use mount /dev/sda, /dev/sda0p1 , sda1, what? Jun 26 15:26:45 Parduz: if both /dev/sda0 and /dev/sda1 exist then you have a problem, since it means there are multiple devices Jun 26 15:26:55 but yeah the p1 you probably do need Jun 26 15:26:56 nono Jun 26 15:27:03 wait sorry Jun 26 15:27:06 sda and sda1 Jun 26 15:27:16 yeah I was about to say, a second device would be sdb Jun 26 15:27:21 the 1 is already the partition number Jun 26 15:27:44 so is not sda0p1 in the fstab line but sda1? Jun 26 15:28:08 why would you put /dev/sda0p1 there if no such thing exists? Jun 26 15:28:36 'cause i'm learning and the line you gave me was like that :D Jun 26 15:28:52 that seems highly unlikely Jun 26 15:29:09 you're probably talking about /dev/mmcblk0p1 Jun 26 15:29:46 which is what the first partition on an sd card of the bbb's sd card slot would be named Jun 26 15:30:10 YAY! Jun 26 15:30:38 not a problem, zmatt. Jun 26 15:30:39 and "sudo mount /dev/sda /mnt/usb" (which doesn't use fstab) clearly had the problem that you were using /dev/sda instead of /dev/sda1 Jun 26 15:31:12 (using fstab would be "mount /mnt/usb" without sudo and without device path) Jun 26 15:32:38 i was about to ask this :D Jun 26 15:32:43 well, it works Jun 26 15:33:51 Parduz: btw using "user" rather than "users" in the fstab options is preferred Jun 26 15:34:45 ok Jun 26 15:44:36 i have one last problem: Jun 26 15:44:47 slim[220]: /usr/bin/X11/xauth: file /home/debian/.Xauthority does not exist the file is there Jun 26 15:45:32 i also have a line in .config/openbox/autostarts that returns that a file (an image) does not exists Jun 26 15:45:45 but if a copy/paste that command it works. Jun 26 15:46:20 seems that the directories are not still ready at that moment... is this something possible? Jun 26 16:01:11 no Jun 26 16:05:51 my guess would be something is removing the file before xauth is run Jun 26 16:05:55 hence xauth prints that warning Jun 26 16:06:10 (it's a harmless warning btw, xauth automatically creates the file if does not exist) Jun 26 16:06:56 it is kind of an annoying message since it sounds like a problem but actually isn't Jun 26 19:33:01 The new dtb has lots of stuff in it the old one doesn't, like P9_19_pinmux w/ a pile of pinctrl entries, cape_universal, and a whole pile of pinmux_P9* pinctrl things. I'm thinking the prior dude removed all them? Or are they a change in the dts? Jun 26 19:33:57 I'm also thinking they may be conflicting with the changes I'm trying to make, which implies I'm doing something wrong. Jun 26 19:34:32 Ragnorok: I think the base dts does have a bunch of pinmux blocks but they're not used by default, they're just there to be available for cape-universal (though I have absolutely no idea _why_ they're there instead of in the overlay) Jun 26 19:34:43 it shouldn't have cape-universal though? Jun 26 19:34:44 Oh. Cool. Jun 26 19:34:52 let me see Jun 26 19:34:59 THe old one doesn't. I don't know if it *should*. Jun 26 19:35:34 I have this thing that was cobbled together from original dts/i I'm trying to make sense of in the context of the new dts/i. Jun 26 19:36:34 I'm deriving as you suggested, and it's booting, but I'm not getting the devices / modules I need yet. Still something wonky. Jun 26 19:37:07 what sort of devices are missing? if they're platform devices, are they present in /sys/bus/platform/devices/ ? Jun 26 19:37:32 I also broke the i2c mux. (pout) All I did was up the clock freq to 400k like the old one. Jun 26 19:38:33 Looking at what's there. Jun 26 19:38:33 hmm I'm not seeing any cape-universal stuff at all in am335x-boneblack.dts or its #includes Jun 26 19:38:51 you're using the v4.19.x branch I assume? Jun 26 19:39:12 (since iirc you're using v4.19-bone rather than v4.19-ti) Jun 26 19:39:21 When I decomp my dtb, which has only mcasp & i2c changes at present, it has cape-universal in it. Jun 26 19:39:35 I'm using the repo you pointed me at a day or so ago. Jun 26 19:39:41 yes but what branch? Jun 26 19:39:47 there's a branch per kernel series Jun 26 19:39:49 Ah. Hang on. Jun 26 19:40:02 you need to use the one corresponding to the kernel you're using Jun 26 19:41:56 There we are. Another bonehead move by yours truly. Let's use the right branch and try again. (grimace) Jun 26 19:42:15 dtc -q -I dtb -O dts src/arm/am335x-boneblack.dtb | grep universal Jun 26 19:42:18 gives me nothing Jun 26 19:43:43 Back to parse errors. Oh well. More when those are resolved. Jun 26 19:44:32 Default builds w/ the same set of warnings as before. At least there is consistency. Jun 26 19:45:42 I still get no warnings at all (when I do "make -B src/arm/am335x-boneblack.dtb" on branch v4.19.x nor on v4.19.x-ti, using dtc 1.6.0) Jun 26 19:46:26 I don't have -B, but i have DTC= to point to my dtc. Jun 26 19:46:34 -B was just to force remake Jun 26 19:47:05 Ok. Since I edit the dts, that just happens. Jun 26 19:47:07 why do you need to point to your dtc? Jun 26 19:47:20 you're using some distro that doesn't have it? Jun 26 19:47:22 It's not in my path. Jun 26 19:47:45 Rather than install it, I'm using the one the kernel built, the last time I built the kernel. Jun 26 19:47:47 I understand that, but that suggests you're manually compiled it and that's the part I was wondering about Jun 26 19:48:04 oh, why? apt-get install device-tree-compiler ? Jun 26 19:48:16 Why not? It's on my system. Jun 26 19:49:04 because it's generating warnings that apparently the makefile is supposed to be able to suppress, but for some reason in your case isn't? Jun 26 19:49:34 the only difference between us being that I just have the one packaged by debian Jun 26 19:50:59 (I do get those warnings if I decompile the dtb without -q, so this version of dtc is evidently able to generate the warnings, but I don't get them when I build the dtb with "make") Jun 26 19:52:08 Ah. I see. I'm building on Debian but that doesn't matter for dtc does it? Jun 26 19:52:21 well debian provides a dtc (package "device-tree-compiler") Jun 26 19:52:26 which is the one I'm using Jun 26 19:52:36 So it doesn't matter. (wink) Jun 26 19:53:09 ? Jun 26 19:53:21 I'll install it and see what happens. Jun 26 19:54:16 It doesn't matter if I build the device tree on a Debian VM using Debian's dtc, then put that on B'Bone Black. DTB are arch-agnostic? Jun 26 19:54:23 they are yes Jun 26 19:54:43 Haven't done an update in a while it seems. lol Jun 26 19:58:34 Now make src/arm/...dtb says "dtc invalid option '@', where before it compiled. Jun 26 19:59:13 lol Jun 26 19:59:36 It's 1.4.0. The one the kernel built is 1.4.6. Jun 26 19:59:40 hah, buster still has an ancient dtc it turns out Jun 26 19:59:47 bullseye and sid ship 1.6.0 Jun 26 20:00:27 uhh, 1.4.0 ? buster ships 1.4.7 Jun 26 20:00:33 I'm on jessie. Jun 26 20:00:38 jesus christ Jun 26 20:00:43 :D Jun 26 20:02:06 like, I understand people running on debian stable (i.e. currently buster) if having high stability is worth the non-uptodateness of the packages Jun 26 20:02:29 but jessie is *two* releases older than current stable Jun 26 20:02:43 it's probably starting to fossilize Jun 26 20:03:35 I could re-build my entire development environment with the latest or I could make do. I've elected to do the latter. If that means I can't use the latest, then I have to redo my entire environment. Until it means that, I rather not. Jun 26 20:04:06 oof, well use whatever dtc you like I guess ;) Jun 26 20:05:08 I probably would just grab the latest dtc and install it into /usr/local or something. actually no I just wouldn't be using such an old debian, I'd go crazy :P Jun 26 20:05:27 Long as it'll work. (other than these warning) If you think it won't, perhaps I'll have to sink all that time into it. Jun 26 20:05:37 it probably doesn't matter Jun 26 20:05:49 but you can just compile the dtb on the bbb anyway Jun 26 20:07:05 I can, but I don't. I figure it doesn't matter, and I has X set up against the VM so it's drag/drop to move files around. Jun 26 20:07:43 it shouldn't matter anyhow Jun 26 20:10:31 (though it might if at any time you want to try building an overlay) Jun 26 20:12:39 Overlays are the fragments, right? I don't have any ... yet. Jun 26 20:13:56 overlays are a way to customize the dtb without using a custom dtb: instead you compile just your changes into an overlay (.dtbo) and have u-boot apply it to the main dtb Jun 26 20:14:15 which also means you can easily switch between kernels without having to rebuild a custom dtb Jun 26 20:14:34 but your u-boot is undoubtedly too old for this Jun 26 20:15:10 Right. And probably. I could rebuild it, but I'm on the custom / extend dtb path for now. Jun 26 20:15:46 yeah like I said previously, custom dtb is easiest for now, you can always consider using an overlay later on Jun 26 20:24:41 Now I have the *right* branch most of the "extra" bits are gone. Go figure! Jun 26 20:47:46 You asked about platform devices. Did a diff from old to new: https://pastebin.com/fzYx9Yx7 I'm pretty sure I need some that are missing, but until I get i2c working properly I'm not convinced they'll show up. Jun 26 20:50:48 I asked which _you_ were missing :P also a diff without -u is spectacularly unreadable Jun 26 20:51:08 most of these seem irrelevant Jun 26 20:51:48 -u. Check. I missed the part about what I'm missing. I'll try again. lol Jun 26 20:51:57 uart, two spi controllers, pruss Jun 26 20:52:08 I also got confused before "old" was new and "new" was old Jun 26 20:54:24 looks like v4.19.x is entirely missing the declaration for pruss, lemme cook one up for you Jun 26 20:56:19 I have one. I just haven't gotten that far. I'm trying to get the i2c mux to work and show connected devices. Jun 26 20:57:49 you have one? Jun 26 20:58:18 getting an i2c mux to work shouldn't be any different I'd assume Jun 26 20:58:27 I need i2c, both mcasp, pruss, edma-dma-engine, omap-pcm-audio, and some sound device configuration that's in the dtb but doesn't appear as a device there other than "sound". If I need others I'm currently unaware. Jun 26 20:58:39 wtf is "omap-pcm-audio" ? Jun 26 20:58:40 I have a pruss declaration in a different file that I have't stuck in. Jun 26 20:58:59 No idea. It's just active in the old unit. If I don't need it, it'll work without it. lol Jun 26 20:59:11 yeah /sound is normally where you define your "sound card" Jun 26 20:59:46 hmm, if you need that then you may want to not #include "am335x-boneblack.dts" but something a bit more sparse, lemme check Jun 26 20:59:51 Right. That'll probably be the last thing I look at. Jun 26 21:01:53 I may need hdmi. Something has to be pulling from the tlv320 codecs, but they arenn't listed as a "device". Jun 26 21:02:10 "may need" ? you don't know if you need hdmi or not? Jun 26 21:02:21 Maybe omap-pcm-audio is doing that? Jun 26 21:02:27 (hint: if your product sticks a hdmi cable into the hdmi port, you need hdmi) Jun 26 21:02:48 I thought that was disabled, but it's listed as a device on the old unit. We have no hdmi cables of any sort. Jun 26 21:03:03 (conversely, if your product uses any of the hdmi-related pins for other purposes, you explicitly want hdmi disabled) Jun 26 21:03:40 hdmi-related pins being P9.25, P9.28-29, P9.31, and P8.31-46 Jun 26 21:03:49 Could be it was never properly disabled. Could be it's using the audio part of hdmi and not the video. I don't know. I didn't build this part and it ofc it's not documented. Jun 26 21:04:30 if you want audio but you're not using hdmi (and therefore not hdmi-audio), you'll want your own sound device Jun 26 21:08:25 Schematic looks like the P9 pins are in use but not the P8 ones. I know the codes inject PCM to one of the mcasp, and the other mcasp is used as a standard ALSA audio output. Jun 26 21:09:20 yeah so you're using the audio pins for custom purposes Jun 26 21:09:29 so you'll want hdmi-audio disabled since it will conflict Jun 26 21:09:43 and if you're not using hdmi then you'll want that disabled too Jun 26 21:10:29 Roit toe! It looks like it is, but hdmi-audio-codec is loaded, so I'll have to whack that most likely. Jun 26 21:13:14 see https://pastebin.com/b60VG5Ys for disabling hdmi Jun 26 21:14:22 I think I see why it "works". Those pins only go to an expansion connector we aren't using atm. So the fact hdmi conflicts, doesn't cause problems. Jun 26 21:14:42 hdmi audio conflicts Jun 26 21:14:44 Thanks! Jun 26 21:15:39 so in your case, after doing /delete-node/ sound; you'd create your own sound-node Jun 26 21:15:47 The old 4.1 unit has hdmi, but "works". The new 4.19 unit lacks hdmi, but has hdmi-audio. I was just curious why 4.1 works when hdmi is active. My edification only. Jun 26 21:15:53 Okey doke. Jun 26 21:16:04 and you probably want &mcasp0 enabled, but configured right for your application Jun 26 21:16:31 Could I do that same delete thing for mcasp or is that not advised? Jun 26 21:16:43 you absolutely must not since you need it Jun 26 21:17:00 I figured if I deleted it, I could recreate it completely. Jun 26 21:17:11 it would be silly to do that Jun 26 21:17:24 normally all platform devices are defined in am33xx.dtsi Jun 26 21:17:27 Ok. That falls under "ill advised". I figured, but had to ask. Jun 26 21:17:38 I am ofc not doing that right now. Jun 26 21:17:38 and individual boards just enable and configure them Jun 26 21:17:44 all SoC peripherals I mean Jun 26 21:17:54 (that's narrower than "platform devices") Jun 26 21:18:01 Right. Jun 26 21:18:19 but the /sound node is entirely custom, you'll want a completely new one rather than tweak a few properties Jun 26 21:19:04 (sigh) I think dinner is about ready. I'm going to have to jet. More fun tomorrow. Have a great whatever part of day it is there, and as always, many many thanks!! Jun 26 21:21:00 if you want the audio oscillator on P9.25 to be enabled, just make sure your /sound node uses clocks = <&clk_mcasp0>; on the cpu or codec node (whichever needs it, i.e. the master) Jun 26 21:21:41 I bet that's very important, as the schematic makes it look like the hardware expects signal there. Jun 26 21:22:07 so question is, is the beaglebone supposed to provide it or does the codec provide it? Jun 26 21:22:36 My recollection is the b'bone does it. Jun 26 21:24:30 L8r! Jun 26 21:24:37 one sec Jun 26 21:24:43 https://pastebin.com/CN6UPm1P Jun 26 21:24:55 that would be the basic outline Jun 26 21:25:05 to go along with mcasp configuration (including pinmux) Jun 26 22:00:03 whats DMA transfer Jun 26 22:00:10 dynamic memory something? Jun 26 22:01:42 DMA stands for direct memory access, it's referring to hardware directly transferring data to/from memory instead of the cpu doing so. hardware with the specific purpose of copying data from A to B when certain events happen is known as a dma controller Jun 26 22:02:15 ok thanks Jun 26 22:16:59 would the UART example in the sdk work Jun 26 22:17:02 it should right? Jun 26 22:17:13 what uart example in what sdk? Jun 26 22:17:46 ti-processor-sdk-linux-am335x-evm-06.03.00.106 Jun 26 22:18:08 they have a UART example it is in C though Jun 26 22:18:15 i could paste bin it Jun 26 22:18:52 PRU_Hardware_UART.c ? Jun 26 22:19:42 https://pastebin.com/JCYAWMmu Jun 26 22:19:45 yeah Jun 26 22:20:38 or potentially modify what is in py-uio Jun 26 22:20:40 this looks like what I'm doing on py-uio, though because of the order in which they do things this wouldn't see the problems I was encountering Jun 26 22:20:53 i see Jun 26 22:21:01 well I dont but I am nodding my head Jun 26 22:21:03 (the problems I was encountering when actually transmitting and receiving data) Jun 26 22:21:25 like, their transmit/receive loop is the simplest stupidest test conceivable, it would even work without any fifo Jun 26 22:21:36 lol Jun 26 22:22:06 since they're writing 1 byte, then wait until it has been received, and read the byte before transmitting the next byte Jun 26 22:23:19 so they never have data in the transmit fifo (longer than perhaps the single cycle it sits there before going to the transmitter), and never use more than 1 byte of the receive fifo Jun 26 22:23:37 right I saw that 8 instead of 16 Jun 26 22:23:47 "8 instead of 16" ? Jun 26 22:23:49 ?? Jun 26 22:24:06 The FIFO size on the PRU UART is 16 bytes; however, we are (arbitrarily) only going to send 8 at a time Jun 26 22:24:11 1 Jun 26 22:24:15 only 1 Jun 26 22:24:49 so the FIFO can hold 16 they said they would send 8 at a time but only actually send 1 Jun 26 22:25:03 where are they saying they would send 8 ? Jun 26 22:25:10 oh there Jun 26 22:25:14 I now see the comment Jun 26 22:25:20 yes that's not what the code does Jun 26 22:25:59 and this makes me really concerned that whoever made this example originally intended to send 8, couldn't get it to work (just like I couldn't), and just changed the example instead of investigating the problem and possibly getting a hardware erratum issued Jun 26 22:26:46 i found a few other UART examples but none of them are hardware Jun 26 22:26:50 all soft UARTS Jun 26 22:26:57 maybe noone got it to work Jun 26 22:27:06 the problem however isn't merely that I couldn't receive more than 1 byte (transmit worked fine I think) Jun 26 22:27:32 I think the soft-uart example is mainly for the old pruss on omap-L1xx which didn't have a hardware uart Jun 26 22:29:07 anyway, as I was saying, the problem wasn't just that receiving more than 1 char in the fifo failed, it also seems to reset the receive fifo whenever I wrote a byte, which is really disturbing Jun 26 22:29:59 I could try with fifo disabled I guess... that might make receiving data in py-uio problematic (especially at higher speeds) but it wouldn't be a problem for PRU itself Jun 26 22:33:33 up to you Jun 26 22:34:14 i really dislike all of TI documentation on the subject Jun 26 22:34:21 it is not made for entry level Jun 26 22:34:24 that is for sure Jun 26 22:38:16 same thing, after transmitting and receiving the first byte LSR is 0b01100001. immediately after writing the second byte lsr reads as zero (i.e. the indication that a byte has been received has vanished) and once the second byte has been received, lsr just reads 0b01100001 again, no overrun indication Jun 26 22:39:17 the only thing I could still try is using PRU to do it, instead of doing the writes from the ARM processor using py-uio... it shouldn't matter, but maybe it's causing something weird to happen Jun 26 22:39:26 should be easy enough to make a trivial test Jun 26 22:43:48 is this an unusual thing in the embedded world? or typical Jun 26 22:44:09 do you think it is a error in the HW design itself Jun 26 22:45:04 right now it's feeling like a hardware bug yes, but maybe I'm overlooking something Jun 26 22:45:28 and yes, when dealing with hardware it's not hugely uncommon to discover hardware is _also_ buggy ;) Jun 26 22:45:35 bugs are not exclusive to software Jun 26 22:57:00 so typically it is just flaggedd and hopefully fixed in the next iteration of the chip? Jun 26 22:57:33 more commonly flagged with known workarounds (if any) Jun 26 22:59:13 if found early enough and the problem is serious enough, has no good workaround, and it matters to some important customer, it _might_ be fixed in a chip revision (but the am335x isn't going to get another revision, I'd be extremely surprised if it does) Jun 26 23:12:31 what is the market price for the JTAG debugger Jun 26 23:12:37 i have seen as high as 300 Jun 26 23:12:47 you don't need one Jun 26 23:13:44 JTAG is something you might need if you're trying to debug baremetal software like u-boot, or maybe advanced linux kernel debugging Jun 26 23:13:55 ok Jun 26 23:13:59 also, you don't have a jtag header on your beaglebone Jun 26 23:14:17 I saw this video where you solder something Jun 26 23:14:23 did not fully look into it Jun 26 23:39:28 interesting, I'm not witnessing the problem this time Jun 26 23:40:20 so either there's a difference in behaviour when accessing the uart from PRU vs from the Cortex-A8, or there's something subtle I'm overlooking Jun 26 23:42:11 to work around I could just have the PRU write to shared memeory? Jun 26 23:42:23 and have py-uio read that same offset? Jun 26 23:45:26 once you have pru code dealing with the uart, what would be the reason to pass it back to py-uio? for testing? Jun 26 23:45:42 I guess Jun 26 23:45:55 though I'm still trying to understand wtf is going on Jun 26 23:46:07 that and I would want to display the values on the gui so I need to pass it out to the OS Jun 26 23:46:37 right but you wouldn't pass the raw data from that, the whole reason for using the pru uart was because pru needed those values Jun 26 23:47:03 for your control algorithm or something Jun 26 23:47:03 that too eventually this will go into a control loop Jun 26 23:47:06 yes Jun 26 23:47:19 for now I just want to get it enabled and occasionally poll Jun 26 23:47:29 because you think you need to do that using pru for some reason Jun 26 23:48:01 i do Jun 26 23:48:19 it will be combined with the encoder Jun 26 23:48:25 info Jun 26 23:48:29 not as fast Jun 26 23:48:57 though Jun 26 23:49:22 right but the load cell's update rate is max 1200 updates per second, i.e. once every 833 microseconds Jun 26 23:49:47 I guess that's still fast enough to be worth doing on pru, would otherwise keep the cortex-a8 somewhat busy Jun 26 23:52:42 I should try the uart test in C/C++ on the cortex-a8, maybe python is doing something funky Jun 27 01:17:27 I figured it out! :D Jun 27 01:20:49 assigning a value to a ctypes.c_uint32 object actually both reads and writes the underlying memory location Jun 27 01:20:53 fucking python Jun 27 01:21:34 (ditto for c_uint32 struct fields) Jun 27 01:22:33 thus, writing a byte to the uart also silently discards a received byte Jun 27 01:31:23 HELLO EVERYONE! Jun 27 01:31:38 I am working with beaglebone Black Jun 27 01:31:50 I am stuck at not able to connect to wifi. Jun 27 01:31:57 can anyone help? Jun 27 01:48:22 back Jun 27 01:48:46 code composer is very buggy Jun 27 01:48:56 hello matt_bone Jun 27 01:49:01 hey Jun 27 01:49:10 i have been working since the morning. Jun 27 01:49:27 i think my BBB is burnt, Jun 27 01:49:33 that is not good Jun 27 01:49:38 I have fried one though Jun 27 01:49:44 doesn't power on Jun 27 01:49:57 XD Jun 27 01:50:08 do you suugest me the best Image ? Jun 27 01:53:10 Hey... Jun 27 01:53:20 go to bbb.io/latest-images Jun 27 01:53:34 There you will shall find one. Or two! Jun 27 01:55:09 MattB0ne: @zmatt was saying something after you left. "I figured it out! :D" <<< Jun 27 01:55:51 I've downloaded the latest Jun 27 01:56:03 but i am not able to connect to the wifi Jun 27 01:56:12 Srikamt: Oh. Do you have ethernet? Jun 27 01:56:13 i cannot find WLAN-0 Jun 27 01:56:23 Yes i have the ethernet it works welll Jun 27 01:56:38 Oh. Jun 27 01:56:42 Nice. Jun 27 01:56:49 Did you try to fool w/ files yet? Jun 27 01:57:05 No Jun 27 01:57:12 Sometimes it is either hit or miss w/ specific chipsets on the WiFi dongles. Jun 27 01:57:19 What is your chipset? Jun 27 01:57:38 i bought an adapter on the amazon Jun 27 01:57:53 i dont know what chipset it has Jun 27 01:58:12 I understand you have one but when you plug it in w/ the BBB powered on, you can use different commands to figure that out. Jun 27 01:59:06 I did everything I can that showed up on the internet, Jun 27 01:59:17 Right. Okay. Jun 27 01:59:26 But i dont, if the image is bad or my skills Jun 27 01:59:35 Oh. Jun 27 01:59:40 i was trying since morning Jun 27 02:00:02 My friends say it worked with earlier images Jun 27 02:00:36 I got it to work on a BBB not too long ago but... Jun 27 02:00:42 I cannot find W-LAN 0 that usually shows up everwhere Jun 27 02:00:50 I cannot remember exactly what i did. I did not take notes. Jun 27 02:00:51 Right. Jun 27 02:00:56 Okay. Jun 27 02:01:12 So, plug in Ethernet and the WiFi dongle. Jun 27 02:01:28 not hotplug though. Cold plug only. Jun 27 02:01:53 So, w/ your BBB booted, what does uname -a say? Jun 27 02:02:01 or uname -r? Jun 27 02:02:57 I'll send you a mail if you have one Jun 27 02:03:21 Oh and Srikamt, you need a Power Adapter for the BBB for WiFi. Jun 27 02:03:31 via your Barrel Jack! Jun 27 02:03:50 okay, Set_ Jun 27 02:03:54 No emails. Just here. Jun 27 02:03:56 I'll do that Jun 27 02:03:59 okay Jun 27 02:04:10 Okay. So... Jun 27 02:04:14 Are you booted? Jun 27 02:04:31 name_r=4.19.94-ti-r42 Jun 27 02:04:47 Okay. Let me boot mine real quickly. Jun 27 02:05:04 Error wifi: Method "SetProperty" with signature "sv" on interface "net.connman.Technology" doesn't exist Jun 27 02:05:23 Right. Do not worry about connmanctl or any of those ideas for wifi. Jun 27 02:06:46 I think after a lot of trials, i corrupted the emmc!!!!!!!!!!!!!!!! Jun 27 02:06:52 It doesnt boot Jun 27 02:07:02 Maybe but you can always boot a new image. Jun 27 02:08:20 Oh. Jun 27 02:08:33 It does not boot? How did you find the name_r? Jun 27 02:09:05 uname_r=4.19.94-ti-r42 Jun 27 02:09:32 Right. Jun 27 02:09:46 I thought you said your board does not boot. Are you using a SD Card? Jun 27 02:10:11 i dont know what happened all of a suddent Jun 27 02:10:18 Oh and Srikamt, please view this link on the wiki from debian: https://wiki.debian.org/NetworkConfiguration Jun 27 02:10:27 MY SD CARD got corrupted and my BBB doesnt boot Jun 27 02:10:30 oh god Jun 27 02:10:31 That will give a really nice overview of these ideas. Jun 27 02:10:37 i am in my capstone Jun 27 02:10:45 Get a new one! Jun 27 02:10:58 Hey. Just get a new image. Jun 27 02:11:33 Srikamt: if you have all your data on it, then try to use a serial connect via the six header pins. Jun 27 02:12:01 But...remember to back up a lot if you have important data on it. Jun 27 02:12:39 i have nothing on it. i justed booted in the morning to connect the wifi Jun 27 02:12:55 Set_ how can i connect you again? Jun 27 02:13:02 Okay. Jun 27 02:13:41 Thanks for the Debian Turorial for the network configuraton Jun 27 02:13:56 Just go to /etc/network/interfaces w/ your favorite editor and try to change things up. Jun 27 02:14:44 Add eth0 and wlan0 in your looping. It may work but there are other things to try too. It is not easy. Jun 27 02:15:20 You have no data on your BBB? Okay, good! That way, we can keep trying to make things work on my end and your end. Jun 27 02:15:29 you should not mess with /etc/network/interfaces on a BBB Jun 27 02:15:35 the BBB uses connman as network manager Jun 27 02:16:00 YES I'VE SEEN CONNMAN CONMAN EVERYWHERE ON THE INTERNET Jun 27 02:16:05 WHY ARE YOU SHOUTING Jun 27 02:16:15 haha, sorryy Jun 27 02:16:35 Ha. Jun 27 02:16:41 that error you quoted looks weird as helll Jun 27 02:17:02 are you using the latest image? Jun 27 02:17:13 yes zmatt Jun 27 02:17:19 uname_r=4.19.94-ti-r42 Jun 27 02:17:41 that's a kernel version, not an image version (which you can find in /etc/dogtag) Jun 27 02:18:09 so, you're trying to get wifi to work... on a BBB, not a BBBW ? you're using a wifi usb stick or something? Jun 27 02:18:34 yes Jun 27 02:18:39 AM3358 Debian 10.3 2020-04-06 4GB SD IoT Jun 27 02:18:51 are you booting from sd card or did you flash to eMMC ? Jun 27 02:19:07 i flashed it to eMMC Jun 27 02:19:11 ok good, just checking Jun 27 02:19:29 if you run the "ip link" command, does it show a wlan0 interface? Jun 27 02:19:53 thank you set_, any how i have to flash the image again buying a new sd card may be Jun 27 02:20:09 buy a new sd card? o.O Jun 27 02:20:09 why? Jun 27 02:20:14 i did iwconfig and ifconfig Jun 27 02:20:23 i have not seen any wlan Jun 27 02:20:55 i think it got corrupted, i was so frustated since morning, i dont what i did Jun 27 02:21:12 why does it matter if your sd card got corrupted if you're flashed to eMMC anyway? Jun 27 02:21:16 *you've Jun 27 02:21:23 MY sd card doesnt show up on the PC Jun 27 02:21:33 that's not "corrupted", that's "broken" Jun 27 02:21:39 even the eMMC got corrupted Jun 27 02:21:45 Breathe! Jun 27 02:21:53 assuming you mean you also can't reformat the SD card Jun 27 02:22:01 does Etcher still see it? Jun 27 02:22:38 SD Card is not showing up on the PC Jun 27 02:22:51 i have tried different adapters Jun 27 02:22:55 nothing works Jun 27 02:23:11 what OS are you using on your PC? Windows? Linux? Jun 27 02:23:52 Linux Ubuntu Jun 27 02:23:58 20.04 LTS Jun 27 02:24:12 does anything appear in kernel log when you insert the card? (monitor with journalctl -k -f) Jun 27 02:25:07 mmc0: error -110 whilst initialising SD card Jun 27 02:25:11 but also, you say you managed to get eMMC corrupted? what makes you draw that conclusion? what's the actual symptom you observe? Jun 27 02:25:19 wow that's really not good Jun 27 02:25:40 may your SD card rest in peace Jun 27 02:25:45 I tried to re-flash 9.9 Image Jun 27 02:26:16 SD! Jun 27 02:26:24 just checking, were you using Etcher to write the sd card? Jun 27 02:26:42 mmc0: card never left busy state Jun 27 02:26:50 yes Jun 27 02:26:53 ok Jun 27 02:26:54 balenaEtcher Jun 27 02:27:43 SD Card doesnt even show up on lsblk Jun 27 02:28:02 so you tried to reflash eMMC but this failed for some reason (possibly due to the SD card dying?) and after that your SD card no longer worked? Jun 27 02:28:12 yeah if it can't initialize the card it's kinda all over Jun 27 02:28:18 Dang. Jun 27 02:28:24 I had high hopes. Jun 27 02:28:45 So, the BBB died? Jun 27 02:28:45 no bro. Jun 27 02:29:06 The BBB lives? Jun 27 02:29:10 sounds like the card's controller firmware is crashing / deadlocking... I've seen that happen with eMMC devices when worn out due to writes Jun 27 02:29:10 exactly zmatt Jun 27 02:29:18 set_: huh, how on earth did you conclude that? Jun 27 02:29:54 zmatt How can I contact you next time? Jun 27 02:29:58 Conclusions are off on another level for me. So, it lives and it dies. Dang. Jun 27 02:30:15 Srikamt: Do you want his personal email? Jun 27 02:30:41 whatever email twitter facebook reddit stackoverflow to talk again Jun 27 02:30:46 set_: if you hand anyone's email to anyone without their permission, you're permanently banned from this channel Jun 27 02:31:01 I have no one person's email. Calm down, sheesh. Jun 27 02:31:08 OHH Jun 27 02:31:13 Not funny. Jun 27 02:31:19 set_: then maybe you need a better taste in humor Jun 27 02:31:24 Fine. Jun 27 02:31:49 coooool. Jun 27 02:32:01 Srikamt: just ask your questions in this channel and have patience. there are plenty of knowledgeable people here, even if it can take a fair bit of time to get a response Jun 27 02:32:17 So Srikamt, your board is dead? Jun 27 02:32:20 Thanks zmatt for your answers Jun 27 02:32:25 no set_ Jun 27 02:32:28 Oh. Jun 27 02:32:29 his sd card is dead Jun 27 02:32:31 Oh! Jun 27 02:32:33 Nice. Jun 27 02:32:38 Well, sort of. Jun 27 02:32:38 I am happy that i found a platfofrm of real personas Jun 27 02:33:10 Srikamt: anyway, 9.9 is obsolete, please stick to the latest image Jun 27 02:33:17 @zmatt knows more than I. So, if he interrupts, he has precendence over my words. Jun 27 02:33:26 Is that good humor? Jun 27 02:33:39 Srikamt: as for the wifi stick... usb wifi sticks on linux can be kinda hit-of-miss, some work, some don't, so be sure to first confirm that it works on your PC Jun 27 02:34:06 I bought a random TP-LINK wifi adapter my bad Jun 27 02:34:11 I know they get hot too. Those little buggers burn some heat. Jun 27 02:35:15 They need fans. Jun 27 02:35:20 https://www.elinux.org/Beagleboard:BeagleBoneBlack#WIFI_Adapters Jun 27 02:35:49 Srikamt: I think the rpi folks have some webpage listing usb wifi sticks with test results, which should also apply to the BBB. iirc it's quite a mess, sometimes a manufacturer will just switch to a completely different wifi chip without even changing the part number of their product, so you'll have no idea what you get if you buy one of those Jun 27 02:36:39 In the site they say these adapters work with BBB Jun 27 02:36:41 https://www.elinux.org/Beagleboard:BeagleBoneBlack#WIFI_Adapters Jun 27 02:36:52 Srikamt: also, anything USB on the BBB can be a headache, especially things that bursts of high power consumption... like wifi sticks. using a powered USB hub between the BBB and the wifi stick helps in those cases Jun 27 02:37:23 you have that exact TP-LINK ? Jun 27 02:37:55 TP-LINK AC600 Jun 27 02:38:20 that's not listed on that page Jun 27 02:38:23 okay zmatt I will buy a hub to not to mess up Jun 27 02:38:42 Yes, I've seen the list after I bought the adapter LOL Jun 27 02:39:05 okay i will return it.right away now. Jun 27 02:39:07 https://elinux.org/RPi_USB_Wi-Fi_Adapters this is the rpi list I mentioned earlier Jun 27 02:39:39 sometimes usb sticks can work but need some additional driver or something (although I think rcn also includes a few with the bbb image) Jun 27 02:40:57 There are included drivers. Jun 27 02:41:22 w/ the BBB images, there are included drivers. I found them a while back. RTLxxxxxx stuff. Jun 27 02:42:13 I have to a lot of stuff using the BBB in those whole semester Jun 27 02:42:15 I've found some forum post saying the rtl8812au works for the TP-LINK Archer T2U (which I think is what you mean) Jun 27 02:42:39 I have the T2U Jun 27 02:43:49 looks like you'd have to compile some kernel module yourself Jun 27 02:43:56 an unofficial driver Jun 27 02:44:43 please dont scare me. Jun 27 02:44:49 https://askubuntu.com/questions/1185952/need-rtl8814au-driver-for-kernel-5-3-on-ubuntu-19-10 Jun 27 02:45:04 that _might_ work, but requires your bbb has internet access (e.g. via Ethernet) Jun 27 02:45:33 yes, i canconnect the BBB with internet Jun 27 02:46:00 so once you have your BBB in working state again on the latest IoT image, you can try that Jun 27 02:46:26 okay zmatt Thank you for the help! Jun 27 02:46:42 (or try to find a wifi stick that's actually supported by mainline linux, or just use Ethernet) Jun 27 02:47:14 I've commited to do the wifi enabled BBB Jun 27 02:47:48 or obviously the easiest way to have wifi on a BBB is by using a BBBW :P Jun 27 02:48:12 (just avoid the beaglebone green wireless, it sucks) Jun 27 02:48:32 If i fail, i have n other option to buy aBBB wireelss Jun 27 02:49:36 btw thank you so much for the wonderfu support am little cool now.!! Jun 27 02:49:41 thanks guys Jun 27 02:49:43 good luck Jun 27 02:49:51 Nice! Jun 27 02:50:07 i have to get back here when i am ready with the BBB Jun 27 02:50:31 Thanks set_ , thanks zmatt Jun 27 02:50:38 Yeppers! Jun 27 02:50:54 Why the chat bozx isin spanish Jun 27 02:51:05 ? Jun 27 02:51:14 what do you mean? Jun 27 02:51:23 there's nothing about this chat that's in spanish Jun 27 02:51:24 My chat box is in spanish i dont kow how Jun 27 02:51:31 "in spanish" ?? Jun 27 02:51:37 Tu configuración y redes se recordarán en este ordenador. Jun 27 02:51:45 Nombre real: Jun 27 02:52:19 The chat box options show up in Spanish, Weird. Jun 27 02:52:27 come se deces redes in Engles? Jun 27 02:52:49 netwrosk Jun 27 02:52:52 OH. Jun 27 02:53:09 @set_ do you speak spanish? Jun 27 02:53:27 No. Jun 27 02:53:29 Ha. Jun 27 02:53:31 oh wow I didn't know the web chat was this annoying Jun 27 02:53:38 nothing in spanish here though Jun 27 02:54:11 Srikamt: how are you connecting to here? Jun 27 02:54:21 just via beagleboard.org/chat ? Jun 27 02:54:25 Yes Jun 27 02:54:38 Community live chat Jun 27 02:55:08 is your browser language set to spanish? maybe kiwiirc has localization Jun 27 02:55:21 dunno, it's not happening here so it's something specific to you Jun 27 02:55:34 Hello! Jun 27 02:55:47 i dont know it shows everything in spanish Jun 27 02:56:01 Srikamt: what's "everything" though, when I use the webchat I mostly just see... the chat Jun 27 02:56:16 there aren't really any messages other than the chat Jun 27 02:56:33 chat options i mean Jun 27 02:57:17 all in english for me Jun 27 02:57:53 WOAH, everything is spanish here Jun 27 02:58:02 Mostrar los cambios de modos de sala Jun 27 02:58:09 Colorear apodos en la lista Jun 27 02:58:17 Comparte cuando estoy escribiendo un mensaje Jun 27 02:58:19 stop copy-pasting stuff Jun 27 02:58:32 it serves no purpose Jun 27 02:59:05 the web chat client is provided by freenode.org, maybe it's trying to guess your language based on location or maybe it's just buggy, I dunno Jun 27 02:59:19 just use any other IRC client if it's being annoying Jun 27 02:59:26 okay zmatt I've to leave now, nice talking to you and set_ **** ENDING LOGGING AT Sat Jun 27 02:59:57 2020