outrageous has quit [Remote host closed the connection]
zjason` is now known as zjason
set_ has quit [Remote host closed the connection]
dkaiser has quit [Quit: Leaving]
Guest2 has joined #beagle
set_ has joined #beagle
Shadyman has joined #beagle
<Guest2>
Hello, how should I interpret the error message Could not initialize timer (err -19) when trying to boot a pocket beagle from a system created with buildroot?
<set_>
Hmm. Good question! I bet there is something online. Let me look.
<Guest2>
I found that by using the provided beaglebone defconfig, the system would start up correctly and by comparing the two config files it appeared that the error most likely to be caused by the kernel, but I was just wondering if I could've found this out from the error message?
<set_>
Oh!
<set_>
You want commands I am assuming...
<set_>
I looked up err -19. I am unfamiliar w/ this error message but if dmesg is installed, try that command. Scroll. And...if you have systemd, use journalctl -xe if you have sudo privileges.
<set_>
Just for reference, I do not use the Pocket Beagle for whatever reason but I am sure the Linux kernel may be similar.
<Guest2>
WDT: Started with servicing (60s timeout)
<Guest2>
Could not initialize timer (err -19)
<Guest2>
This is the full readings from the serial port
<Guest2>
the system doesn't seem to start and it just loops the error message over and over again
<set_>
Oh.
<set_>
I thought you said it booted?
<set_>
Okay... So, did the entire command to start your buildroot build run successfully?
<set_>
No errors or warnings?
<set_>
Also, I have, when using Buildroot, tried different u-boot versionings and different kernels. This is a lengthy process that has not cure to me. But! Every so often I get it booted. it just takes time to use the correct versioning and kernel from what I have seen.
<Guest2>
I had been following the buildroot training instructions to create a beaglebone image, and that didn't seem to work. However, using the provided defconfig file for the beaglebone works, and the only significant difference i could find between the two .config files was the kernel that was used
<set_>
Adding different arguments to your make command after menuconfig will prove valuable.
<set_>
Hmm.
<set_>
Okay.
<Guest2>
I was just wondering if I was able to come to this conclusion quicker by just looking at the error messages I had gotten from the initial boot
<set_>
Oh.
<set_>
Got it. Sorry. I am not familiar w/ that (err -19) in the logs.
<set_>
I can keep checking.
<set_>
time.c ?
<set_>
Maybe you need to set the date?
<Guest2>
U-Boot 2021.04 (Dec 15 2021 - 14:32:47 +1100 It seems that u-boot has the date as one day behind that might that be the problem
<set_>
Hmm. Oh and if you get bored one day, sent your commands in w/ the allocated kernel parameters picked as options. I can probably help one day. It is almost 10:00 now. I might need to retry tomorrow or after Christmas.
<Guest2>
Ok, thank you very much for the help today
<set_>
I think when I booted last, the files needed for booting w/ a network were located in a specified location.
<Guest2>
Hmm, I'll have a look
<set_>
Okay. Until next time. Snore!
<set_>
Zzzzz.
<set_>
Oh and by the way, I am learning as much as feasibly possible about buildroot in case the coffee hits the fan.
<CoffeeBreakfast>
I had a similar problem running U-Boot on a stm32. The problem was a missing property in the device tree from the u-boot source
<set_>
You guys chat. I am out.
<Guest2>
But, when I tried with a different kernel the device seemed to boot without any problems?
<Guest2>
So I had assumed that the problem was with the kernel itself and not the u-boot loader
<CoffeeBreakfast>
I compiled u-boot with the DEBUG flag, then I got "ofnode_read_prop: tick-timer: <not found>", also, that error msg is in the u-boot source.. I don't know if it's also in the kernel
<Guest2>
Hmm, so since the error message is from the u-boot source it is more likely to be a problem due to u-boot than the kernel itself?
<set_>
Oh! Also, try multiple, different toolchains to test... Again. Three main components (Uboot, toolchain, Kernel). Mix and match until perfection! I cannot wait until you all figure out the less stressed way of compilation. I am waiting too!
<set_>
I have been reading about buildroot. It seems things need to be associated a specific way in specific files.
<set_>
I think you can account for br2_package_libWhatever in the Config.in file in case something is missing.
<set_>
Instead of building the same kernel and other components again and again under the same name, also, make a new name for each build and mark it down.
<set_>
There was something about buildroot that makes incremental building a pain.
<Guest2>
I had been creating completely new buildroot directories and testing different settings, so I don't think that should be much of a problem
<set_>
Oh. Okay. I just remember using make constantly instead of make MyNewFile during builds. This created issues as it kept iterating the old build w/ the same properties.
<Guest2>
Ok, I will keep that in mind, Thank you so much for your help.
<set_>
I also used a specified toolchain outside of what is offered internally. ARM has them and so does linaro (for now).
buzzmarshall has quit [Quit: Konversation terminated!]
Guest2 has quit [Ping timeout: 256 seconds]
vd33 has quit [Ping timeout: 256 seconds]
<set_>
Um, hello and how does one get WiFi up and runnin' on the BBBW w/ the Bullseye Distro?
<set_>
It boots and it keeps booting. But! No the WiFi! No the WiFi. Send rations!
lucascastro has quit [Ping timeout: 256 seconds]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 256 seconds]
<set_>
apt is loaded and firmware-ti-connectivity is loaded but...
<set_>
networkd and network-manager is not loaded.
<set_>
Aw!
Shadyman has quit [Remote host closed the connection]
lucascastro has joined #beagle
<set_>
So, I checked the outdated udev rule dept. and notta. I think NetworkManager in Bullseye is leaning towards something different that is not udev rules for setting up interfaces in /etc/network/ .
<set_>
But...damn debian is not stating what exactly their method of use will be like currently or what the future may bring.
<set_>
Some stuff is working! I can get to Node-red online and a VSCode thing.
<set_>
It works!
<set_>
No updates or upgrades, no git, and no blah. I know, I am in the way. Enjoy today!
russ has quit [Ping timeout: 240 seconds]
russ has joined #beagle
set_ has quit [Ping timeout: 256 seconds]
buzzmarshall has joined #beagle
rcn-ee has joined #beagle
<zmatt>
rcn-ee: amazing, we just discovered that someone in the world has a pair of the speakers we make connected to a network where DHCP hands out public unfirewalled IPv4 addresses
<zmatt>
(fortunately we made sure sshd only accepts public-key authentication)
vagrantc has joined #beagle
set_ has joined #beagle
<set_>
I am like a spoiled rug. Leave me alone w/ my BBB!
<set_>
Oh and sorry but did anyone figure out how to add wifi to the BBBW w/ Bullseye? I am asking b/c I would like to know, i.e. outside of me being spoiled w/ my spoils. BBB!
<set_>
Santa can wait!
<set_>
"Silent Night" is my favorite song during Christmas...
<set_>
Can someone tell me now?
<set_>
Aw!
<zmatt>
probably a wpa-supplicant config file? unless there's a utility/script to help with setting up wifi yet
<set_>
Oh.
<set_>
@zmatt: Do you hate Christmas?
vagrantc has quit [Quit: leaving]
<set_>
I do not hate it. I like it. Family, yelling, fun!
<set_>
The reason I bring that up is this idea.
<set_>
A long time ago, my bot was supposed to listen to me w/ a specific library during Christmas.
<set_>
But...the lib. was deprecated and the people from the college moved on in the speech recognition "game."
<set_>
Anyway, thank you for answering. I will try wpa-supplicant and the config file.
<zmatt>
config file is probably /etc/wpa_supplicant/wpa_supplicant.conf or /etc/wpa_supplicant/wpa_supplicant-wlan0.conf depending on how it's been setup, assuming it has been
<set_>
Right. Off to look.
<set_>
I tried so many files so far. I will most likely have to restart something or another thing.
vd33 has joined #beagle
<zmatt>
if you modify the config file you can ask wpa-supplicant to re-read it using "wpa_cli -i wlan0 reconfigure"
<set_>
Nice.
<set_>
Thank you kind gent. Now, Santa will be gracious upon thee or whatever. Time to test!
<set_>
FAIL
<set_>
I tried that command.
<set_>
I tried sudo wpa_cli -i wlan0 reconfigure b/c w/out sudo, it does not do anything.
<zmatt>
that's weird on both counts
<set_>
Now, I set up a loopback and wlan0 inet thing in networking in that specified file in /etc/wpa-supplicant/ .
<zmatt>
uhh what?
<zmatt>
what are you talking about?
<set_>
That is what returned in the terminal, e.g. FAIL.
<set_>
Just post my credentials in an open file that is writable by sudo? Are you sure?
<zmatt>
I mean, connman also stores your credentials in a file
<zmatt>
if a computer needs to be able to connect to wifi on its own, it needs to store the credentials *somewhere*
<zmatt>
and any file can be accessed with sudo
<set_>
I am not trying to get you to do other work...Oh. Well, there I go again. Getting ramshafted by technology w/out knowing it. Should I use some encryption or a Santa Sley?
<set_>
Hash the Santa Sley part.
<set_>
I mean, I can do one of those odd 128-bit ram-jams of encryption.
<set_>
Or more...whatever really.
<set_>
Thank you sir.
<set_>
Oh!
<zmatt>
it's possible to use the wpa_passphrase utility to hash the password... but it should be noted that that hashed password is equally useful to connect to the wifi network as the original password is, the main benefit is that someone looking over your shoulder when you edit the config file probably can't memorize a 64-character hexadecimal string
<set_>
Can I type network1 { blah, blah, blah } && network2 { more, more, more } ?
<zmatt>
you can put multiple network {...} blocks in the config file
<set_>
Nice.
<set_>
So, I can ssh and sftp from some other location to look at my files and get/put them on the BBBW!
<set_>
Nice.
<zmatt>
?
<set_>
No?
<set_>
Well.
<zmatt>
it will connect to only one network, whichever has the strongest signal
<set_>
I mean, w/ separate networks, one would think I could access. Oh. Nevermind. I can get joggled.
<set_>
Okay. Nice and smart.
<set_>
I will try right now.
<zmatt>
it's mostly useful if you move the bbb between different locations
<set_>
Right. Or around an extremely large house w/out hotspots or tethers?
<set_>
My system is so jacked up right now. It says I am offline but I can communicate via chat. Odd!
<zmatt>
even if you have multiple wifi access points in a house, you'd normally give them all the same wifi network name
<set_>
Oh! I never do that...I always try to make the access point another name. I have a thing and access point. The thing handles Ethernet.
<set_>
The access point handles wifi.
<set_>
I am in a tiny home w/ many shitty, if I can say so (Cox), connections. Ha.
<set_>
That is their actual name.
<set_>
ISPs and their odd names.
<set_>
It is like that type of dog. Shi Tsu.
<set_>
For some reason, that never gets old.
<zmatt>
also, for improved security it is worth telling wpa-supplicant to require the use of WPA2 and CCMP like this: https://pastebin.com/zdBBKsSV
<set_>
Okay.
<zmatt>
so that it will not even attempt to connect to a wifi access point with the same name that doesn't support proper encryption
<set_>
Nice. That is extra smart. I never really thought about connections like w/ what you just presented.
<zmatt>
(this is assuming your access point does in fact support proper encryption... though if it doesn't it probably belongs in a museum)
<set_>
It is easy to stroll in, say high, and then access "delicate" info. on purpose when close enough to specific hot spots I guess.
<set_>
There is so much to learn. Sheesh.
<set_>
FAIL == still the print out.
<set_>
or the error on the terminal, FAIL .
<set_>
I will brb. here and there. Something is yelling outside. I need to make sure people are not w/ pitch forks and knives outside my door.
<zmatt>
rcn-ee: does it make sense to package that?
<rcn-ee>
zmatt, i also want to package show-pins.pl... so 2 debian package names. ;)
<zmatt>
show-pins hasn't had a .pl suffix since... forever
<rcn-ee>
zmatt, the other option, pre-git clone it under /opt/source/
<zmatt>
yeah that sounds more sensible to me
<rcn-ee>
set_, did you accently write to /dev/ttyUSB0 at some point whithout a cable present? you might have created a file there.. thus messing everything up..
<set_>
Hmm. Maybe but I seriously doubt it.
<set_>
I really do not think I wrote anything to /dev/ttyUSB0 w/out the cable present. Well.
<set_>
I did type tio /dev/ttyUSB0 w/out the FTDI cable present.
<rcn-ee>
if you remove the cable, is that node still present? you are dialout?
<set_>
I am on dialout.
<zmatt>
rcn-ee: the bulk of overlay-utils is its examples, which people may want to modify, or use to create their own overlay, so it should be in a writable directory and not be unintentionally overwritten if they update their packages
<set_>
Right now, the "node" is present if it is hotplugged or hotpulled.
<rcn-ee>
zmatt, perfect, so git clone would make sense, that directory is already masked 1000:1000, so they just have to use it or git pull to update it..
<zmatt>
set_: just check if a new /dev/ttyUSB* device shows up when you plug in the ftdi
<rcn-ee>
set_, as long as "nothing" is plugged in and using it, nuke it as root, then replug it in..
<zmatt>
I wouldn't suggest that
<zmatt>
unless it really is a normal file (check with ls -l)
<zmatt>
it might just be a random internal device
<set_>
No /dev/ttyUSB* shows up on the BBBW at all when plugged in.
<set_>
Hmm.
<zmatt>
none is expected there
<set_>
Oh. Okay. Hmm.
<zmatt>
I meant on the computer where you're plugging it into usb
<rcn-ee>
set_, where is the "usb" plugged into.. your computer or the bbgw?
<set_>
Right.
<zmatt>
also wtf is tio
<set_>
Computer.
<rcn-ee>
it's a very simple serial terminal..
<zmatt>
ah
<set_>
rcn-ee told me about it years ago. CTRL-t then q to exit.
<zmatt>
nice, that's useful. I generally use screen for that purpose, but that's something I'd hesitate to recommend to other people, especially since it's easy to accidently still have it running without realizing it
<set_>
um, the device showed up after plugging it in many times.
<set_>
I cannot remember what my computer called it...
<set_>
Let me check again.
<rcn-ee>
it supports autoconnect out of the box too.. i always fail when using screen..
<set_>
TTL232R-3V3 yep and yep.
<set_>
It is working again.
<rcn-ee>
good, it's alive!
<set_>
Yep!
<set_>
Yes sir.
<zmatt>
I don't think I've ever felt a desire for autoreconnect... I guess for something like the usb-serial console of the beaglebone, because it temporarily disappears when you reboot?
<rcn-ee>
yeah it works nice when rebooting a beagle with usb-serial console.. it just comes right back up...
<set_>
Bare metal as they call it! It works wonders on speed.
<zmatt>
I've never used the usb-serial console... in part because I almost never connect a beaglebone via usb, and if I do I have a network connection to it and just ssh
<zmatt>
the only time I've needed a serial console is when things are so fucked that the usb-serial console probably wouldn't be available either
<set_>
I get that at times.
<set_>
The serial console is busted and quits and hangs.
<set_>
I remember trying to get into the system. I had to do this for 10 seconds then it would quit. Another two mintues and then it would quit.
<zmatt>
set_: whatever you're talking about is not what I was talking about
<rcn-ee>
do you remember which kernel?
<rcn-ee>
a month, or year ago?
<set_>
4.14.x
<set_>
Before the udpate to 4.19.x.
<set_>
Even my silly bot started to act oddly and was out of control.
<rcn-ee>
weird, as 4.14.x was especially rock solid a few of my installs.. it took awhile before 4.19.x(eventually 5.4.x) till they were as solid again in my testers..
<set_>
I had all kinds of trouble before the update to the new kernel for reasons I did not look into or explain well at the time.
<set_>
I need to reboot. My old computer crashed and this one is on the fritz. Reboot!
set_ has quit [Remote host closed the connection]
russ has quit [Ping timeout: 240 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
russ has joined #beagle
<CoffeeBreakfast>
Some guides use arm-linux-gnueabihf.... for compiling the kernel... (chicken and egg situation?); isn't that for making normal linux programs, using glibc?
<zmatt>
doesn't matter, kernel doesn't use any of the headers or libraries from the toolchain