**** BEGIN LOGGING AT Wed May 26 03:00:34 2021
May 26 03:05:30 <set_> I am looking in the .dtb file now as a .dts file. I reversed the dtc usage. Anyway, it is a very long file. There are some nice tidbits and some random things.
May 26 03:05:57 <set_> Each of which, I know very little about currenctly. So, off to read the spec. sheet on the .dts stuff.
May 26 03:06:11 <set_> and relay to the TRM. Argh.
May 26 03:06:13 <zmatt> again, don't decompile a dtb
May 26 03:06:18 <set_> Oh.
May 26 03:06:21 <set_> Yikes.
May 26 03:06:23 <set_> Okay.
May 26 03:06:27 <zmatt> 03:56 <@zmatt> a decompiled dtb is an unreadable mess
May 26 03:06:36 <set_> Okay.
May 26 03:06:41 <zmatt> if you want to read the source code (you don't), read the source code
May 26 03:06:48 <set_> Okay.
May 26 03:06:52 <set_> Where should I read it?
May 26 03:06:59 <set_> I mean, where should I look?
May 26 03:07:58 <zmatt> /opt/source/dtb-4.19-ti/src/arm/  contains the source code of the 4.19 kernel dtbs
May 26 03:08:26 <zmatt> similar directories are in /opt/source for some other kernel series
May 26 03:08:42 <set_> Okay. Thank you.
May 26 03:09:08 <zmatt> it's a checkout of https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.19.x-ti/src/arm/
May 26 03:09:49 <zmatt> or maybe https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.19.x-ti-overlays/src/arm on the new images
May 26 03:10:01 <zmatt> that's the version with overlay support on bbai
May 26 03:10:15 <set_> Right. Okay...
May 26 03:10:22 <set_> I will look at those repos.
May 26 03:24:18 <set_> Where are some of the newer testing images located, outside of the the older elinux. page online?
May 26 03:25:52 <set_> No worry. I found 'em on the /latest-images page online.
May 26 03:28:25 <set_> still...they are from 2020. Should this matter?
May 26 03:35:49 <set_> Anyway...off to test.
May 26 06:50:27 <Guest_17> ayyy
May 26 06:50:27 <Guest_26> Ayyy guest 17 wat up homeesss
May 26 06:51:43 <Guest_26> Does anyone here know where to find a decent pinout for the beaglebone black by chance??
May 26 06:53:10 <Guest_26> We're looking for a general high level pinout for the board as a whole, not necessarily interested in the pinouts for the internal modules/components
May 26 07:19:08 <rob_w> my channels and many others got closed from freenode staff for  "spamming and advertising other networks" ..be ware and be quick
May 26 07:23:03 <kveremitz> yeah freenode is dying .. bleeding and dying
May 26 07:23:08 <kveremitz> they may reinvent, they may not
May 26 07:35:02 <rob_w> see you on the otherside
May 26 08:58:28 <markand> hey there
May 26 08:59:15 <markand> I have a small issue regarding remount-rootfs.service that fails at early boot (and make / kept ro) and once login is available, I'm able to start it again
May 26 08:59:22 <markand> https://paste.centos.org/view/85567cc0
May 26 08:59:36 <markand> systemctl status remount-rootfs.service shows no errors
May 26 09:25:42 <markand> during flashing from the SD to eMMC I get this error too (but it does not seem fatal though) https://paste.centos.org/view/04a0bd47
May 26 09:55:55 <markand> hmmm seems like rw as cmdline works better
May 26 15:42:14 <zmatt> ughh andrew lee just keeps reacting to things in the worst possible way he could /o\
May 26 15:47:36 <ogra> https://lwn.net/Articles/857252/rss
May 26 15:48:40 <ogra> looks like this happened to 700+ channels last night
May 26 18:01:08 <tbr> yeah, so I'll be on the "L"-network in #beagle
May 26 19:33:20 <m-atoms> does the eMMC flasher version from here: https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console
May 26 19:33:37 <m-atoms> flash the eMMC automatically on startup? I'm seeing some weird LED patterns
May 26 19:33:55 <zmatt> images labeled "flasher" will automatically flash on boot yes
May 26 19:34:33 <m-atoms> zmatt ah okay thanks. Based on the getting started page I thought I might have to change some boot scripts to do that automatically
May 26 19:34:50 <zmatt> no, those are instructions to turn a normal image into a flasher
May 26 19:35:13 <m-atoms> gotcha, ty for the clarification
May 26 19:35:45 <zmatt> the expected led activity (after brief boot activity) is a back-and-forth led pattern (0 1 2 3 2 1 0 1 2 3 2 1 0 etc)
May 26 19:35:56 <zmatt> ending in all leds on and then power-off
May 26 19:36:46 <m-atoms> yep that's exactly what I saw. The LED sweep felt like it was writing the eMMC so I'm glad that was the case. Now I remove the SD card and power on and should be good to go right?
May 26 19:36:54 <zmatt> yep
May 26 19:37:20 <zmatt> and once confirmed everything is good probably wipe the sd card so you don't accidently end up booting a beaglebone from it
May 26 19:38:07 <m-atoms> oh good point that could be dangerous
May 26 19:38:28 <m-atoms> bbb is up and running, though I already have 538M of my 3.5G storage used
May 26 19:38:29 <zmatt> or if you mount the sd card on a linux system you can modify its /boot/uEnv.txt to turn it into a normal image
May 26 19:38:39 <zmatt> usable as rescue image
May 26 19:39:05 <zmatt> 538M sounds like you're using the fairly minimalistic "console" iamge?
May 26 19:39:16 <m-atoms> yep
May 26 19:39:19 <zmatt> it is definitely possible to strip down even further
May 26 19:39:38 <m-atoms> not a hard requirement but I was expecting it to be a bit smaller
May 26 19:40:12 <zmatt> a fair bit of it is drivers for various wifi sticks to maximize the chance it works for people's networking setup
May 26 19:41:07 <m-atoms> ah yeah that makes sense. not necessary for my use case but understandable
May 26 19:41:43 <zmatt> sudo apt purge firmware-iwlwifi rtl8723bu-modules-4.19.94-ti-r50 firmware-brcm80211 firmware-atheros firmware-libertas firmware-ti-connectivity bluez rtl8821cu-modules-4.19.94-ti-r50 wpasupplicant firmware-realtek bb-bbai-firmware iw crda wireless-tools bb-wl18xx-firmware bluetooth firmware-zd1211 libiw30 wireless-regdb
May 26 19:42:05 <zmatt> you can probably add to that list:  firmware-misc-nonfree btrfs-progs
May 26 19:42:14 <zmatt> unless you have a specific use for those
May 26 19:42:19 <m-atoms> you're a wiz
May 26 19:42:23 <m-atoms> all I need is ethernet
May 26 19:43:52 <zmatt> you can also remove these to free up space and reduce boot time:  initramfs-tools initramfs-tools-core
May 26 19:44:49 <zmatt> (I think removing the packages will automatically remove the initramfs files, but maybe manually "sudo rm /boot/initrd.*" just in case)
May 26 19:46:21 <m-atoms> what's the relationship between the initramfs tools and the wifi drivers? As I understand it, the initramfs is just an intermediate boot stage prior to the kernel booting and mounting the rootfs
May 26 19:46:47 <zmatt> the relationship is being unnecessary and taking up space
May 26 19:46:58 <m-atoms> hahaha fair enough
May 26 19:47:26 <zmatt> all the wifi stuff is in the initial big line I pasted
May 26 19:49:29 <m-atoms> yep your instructions make sense, I just didn't realize the initramfs was optional
May 26 19:49:39 <zmatt> I also have these notes on stripping things, though this is for an older image hence kernel version doesn't match: https://pastebin.com/raw/M9qX9Js1
May 26 19:50:28 <zmatt> initramfs is only required if the drivers required for the kernel to locate and mount the root filesystem are compiled as modules rather than being compiled into the kernel
May 26 19:51:20 <zmatt> which is not the case with these kernels
May 26 19:52:07 <zmatt> the -ti and -bone kernel packages have all strictly-necessary drivers compiled into the kernel, so initramfs is optional and mostly just slows down boot
May 26 19:52:58 <m-atoms> I really appreciate the explanation!
May 26 21:27:06 <m-atoms> In order to avoid repeating the same environment config for the 3 boards I have to setup, I was planning to use the normal SD console version, make all my changes, then uncomment the line in /boot/uEnv.txt to turn it into a eMMC flasher version. I see a comment in there that `rsync` and `dosfstools` should be installed, but it seems the console
May 26 21:27:06 <m-atoms> version of debian buster does not include `dosfstools` by default. Is this something that needs to be installed manually?
May 26 21:27:28 <zmatt> if it's not installed it doesn't have to be
May 26 21:27:34 <zmatt> dosfstools definitely sounds irrelevant
May 26 21:28:54 <m-atoms> I looked it up and apparently it's for FAT filesystems. I was sorta surprised that it wouldn't already be installed if it were actually essential
May 26 21:29:04 <zmatt> yeah that sounds like obsolete instructions
May 26 21:29:12 <m-atoms> okay I'll ignore then
May 26 21:29:13 <zmatt> the images haven't used a FAT boot partition for a very long time
May 26 21:29:18 <zmatt> and rsync is installed by default of course
May 26 21:48:08 <zmatt> m-atoms: oh I missed hostapd in my list of wifi-related packages
May 26 21:49:12 <m-atoms> zmatt okay I added to my (your) list
May 26 21:54:44 <m-atoms> I feel compelled to express moral outrage that vim is not included by default on debian console image lol
May 26 21:55:15 <zmatt> m-atoms: in case it's of interest, I also have these notes on how to replace connman by systemd-networkd (this also frees up a bunch of packages): https://pastebin.com/3tjj3v3R   .. I can't remember if I fully tested these steps yet (especially usb networking)
May 26 21:55:21 <zmatt> yeah, just vim-tiny
May 26 21:56:05 <zmatt> I personally indeed install vim and remove nano :P
May 26 21:56:40 <zmatt> oh lol my own question is answered by the comments at the top... "# TODO test the usb networking"
May 26 21:57:51 <m-atoms> it's definitely of interest, I've saved all the notes you provided
May 26 21:58:03 <m-atoms> and I would have thought vi is vim tiny lol
May 26 21:58:53 <zmatt> vim-tiny is just one of the various variants of vim package available in debian (with different amounts of optional stuff compiled in, hence varying in the amount of dependencies)
**** BEGIN LOGGING AT Wed May 26 22:03:25 2021
May 26 22:03:58 <m-atoms> well you're not wrong but I find reaching all the way up there a bit oppressive haha. With `jk` or similar you don't have to leave the home row which is nice
May 26 22:03:59 <zmatt> plus, rebinding it and getting used to that would make using a default-configured vi on a random system that isn't mine super annoying to use
May 26 22:04:12 <m-atoms> ^this is very true
May 26 22:04:20 <zmatt> what do you mean jk?
May 26 22:04:45 <zmatt> as in, the letters?  what if you just want to type those letters?
May 26 22:07:39 <m-atoms> I've seen most people choose something like `jk` or `jj` because you almost never type those characters back to back. If you do indeed need to type `j` and then `k` you just have to wait a bit between the two. The rebind only captures if if they're entered within x ms of each other. Idr the exact timing but it's less than a second
May 26 23:10:33 <m-atoms> zmatt 593M used -> 453M used after purging
May 26 23:14:13 <zmatt> m-atoms: not bad!
May 26 23:14:50 <m-atoms> agreed! plus nothing seems catastrophically broken which is a good sign haha
May 26 23:19:15 <zmatt> I just checked our production beaglebones, those have 307 MB used when excluding our custom stuff.. but those are really stripped-down and not meant to be comfortable working environments (e.g. no "man" installed)
May 26 23:20:00 <zmatt> they could obviously be substantially leaner still, but that requires effort and there's not been any reason to put in such effort
May 26 23:24:16 <m-atoms> woah that's hardcore
May 26 23:24:46 <zmatt> what?
May 26 23:25:04 <m-atoms> all the way down to 307MB with no man or anything
May 26 23:25:12 <m-atoms> impressive but more hardcore than I need to be
May 26 23:25:27 <zmatt> well they're appliances, normally nobody will log into them
May 26 23:27:59 <m-atoms> oh yeah that makes sense
May 26 23:50:40 <zmatt> m-atoms: we also have a custom-built kernel with config tweaked to omit stuff we don't need, that reduced the installed-size of the kernel package from 34-54 MB to 17 MB
May 26 23:52:04 <zmatt> (but tweaking kernel config to your liking is fairly time-consuming and usually not worth it just to save a bit of space unless you're very tightly constrained)
May 27 00:21:19 <mothblur_> So...the BBAI_BBORG_Motor_00A2.dtbo creates the BBAI to not boot.
May 27 00:21:28 <mothblur_> Um...
May 27 00:21:33 <mothblur_> Dang it. Please hold.
May 27 00:22:04 <set_> Okay...
May 27 00:22:23 <set_> So, it seems that this specific .dtbo file is creating the AI to not boot.
May 27 00:23:06 <set_> Is there a particular .dtb file that I need to put into the uEnv.txt file to handle this .dtbo under the uboot-overlays section?
May 27 00:28:48 <zmatt> set_: why on earth are you trying to do stuff with the bbai?
May 27 00:29:21 <zmatt> you have enough trouble already with the BBB
May 27 00:30:22 <set_> Ha.
May 27 00:30:25 <set_> B/c...
May 27 00:30:35 <set_> It has a working .dtbo.
May 27 00:30:46 <set_> Supposedly. But nope, it fooled me.
May 27 01:24:52 <set_> Is the .org having trouble finding a good mfg. for the BBBlue?
May 27 01:25:28 <set_> I am asking solely b/c of the last three to five boards i have purchased have had some odd issues...mechanically.
May 27 01:25:51 <set_> And...this has led to issues w/ the hardware to software relation.
May 27 01:29:05 <set_> For some reason, my WiFi on the BBBlue(s) have gone out at specific times w/out me being able to sign in via SSH.
May 27 01:30:25 <set_> I should be able to sign in even w/out WIFi access and I cannot.
May 27 01:31:00 <set_> I guess i need to reflash. Damn it! I really did not want to reflash the current image I had onboard the BBBlue.
May 27 01:31:53 <set_> Forget it.
May 27 01:32:00 <set_> I will try the old way of signing in.
May 27 01:45:27 <set_> Argh.
May 27 01:45:38 <set_> it could be the telnet client.
May 27 01:45:51 <set_> Off to test out their new and improved versioning. Argh.
May 27 01:46:57 <set_> I think my 'puter needs updating too. Forget it everything I said. As usual.
May 27 01:50:12 <set_> but...
May 27 01:50:53 <set_> The mechanical on the BBBlue, components, that I received from Mouser has some distinct issues like someone did something to them after the mfg. process.
May 27 01:51:03 <set_> That is why I asked about the mfg. of the BBBlue.
May 27 02:31:33 <set_> Okay. So, the Getting Started Icon shows, the board is located in the Devices list, and I cannot sign in via ssh or a serial connection.
May 27 02:31:46 <set_> Is that normal?
May 27 02:35:59 <set_> Anyway...forget it. I think whomever had permission to handle the boards at the Mouser location, gave them a doctoring up before sending them out.
May 27 02:36:02 <set_> That is my guess.
May 27 02:44:45 <set_> well...the reflash worked. Phew. It just stopped out of nowhere and decided to not work any longer. Now, back to the ole, drawing board. argh.
**** ENDING LOGGING AT Thu May 27 02:59:56 2021