Because as far as I know most BBAI sitting in distribution still have Debian 9 on them (Mouser for example has 300+ in stock despite the semiconductor situation). Debian 9 still gets security updates just like Debian 10. So that was not a consideration. The recent addition of a Debian 9 image for BBAI was because someone recently had to restore a BBAI this way, it worked, so I thought I'd include it.
Now, the BBAI uses a totally unique way of setting up the SPI/GPIO pins (via a custom, BBAI-specific device tree). How did you do this for a Debian 10 distro? Did you just follow your BBG/BBB procedure for D9 => D10 upgrading or did you actually figure out how the BBAI device tree stuff works? (it's mostly in the Kiwi main Makefile)
John, on one of my BB-AI (newer) I'm flashed Debian 10 image from micro SD and then I did everything described in topic of this theme, - KiwiSDR start normal.
On the second BB-AI (more older) I'm upgraded from Debian 9 to Debian 10 with edit "/etc/apt/sources.list" file without any problem.
My misery may be self-imposed. I upgraded to Buster to get the rest of Linux current for that non-kiwi stuff I am going to trying to run on the same BBAI
I don't know if this is the right place to post an issue/question, but today I hit a glitch while prepping a new BBAI for my KiwiSDR.
After updating Debian (https://beagleboard.org/upgrade, minus the sections on TI deep learning tools, WiFi, USB and Cloud9), I attempted to start the install of KiwiSDR software:
Cloning into 'Beagle_SDR_GPS'...fatal: unable to access 'https://github.com/jks-prv/Beagle_SDR_GPS.git/': Failed to connect to github.com port 443: No route to host
The prior updates seemed to go normally, so I assume the ethernet connectivity is ok. Something else I'm missing?
On the BBAI, pinging github.com or any other external server produces "Destination Host Unreachable" errors:
debian@beaglebone:~$ ping github.com
PING github.com (192.30.255.113) 56(84) bytes of data.
From 192.168.7.2 (192.168.7.2) icmp_seq=1 Destination Host Unreachable
From 192.168.7.2 (192.168.7.2) icmp_seq=2 Destination Host Unreachable
Although the BBAI apparently obtains github.com's numeric IP address correctly as shown in the first output line, the external site is then shown as 192.168.7.2. This shows the same regardless of whatever external site I pick.
The content of /etc/resolv.conf is:
# Generated by Connection Manager
search example.com example.com
nameserver 192.168.1.1
nameserver xxxx:xxxx:xxxx:xxxx::1
nameserver xxxx:xxxx:xxxx:xxxx::1
The entries "xxxx:..." are actually what I gather is a hexidecimal MAC address, which I've obscured in the (unlikely?) event that it might not be a good idea to post for any reason. Those last two lines in the file are identical to each other.
On the same LAN, I have a BBG + Kiwi which is operating normally, and which will successfully ping github.com or other servers. Although the BBG is on Debian 8.5 and the BBAI shows as 9.13 -- and probably deal with resolv.conf differently -- I thought I'd copy the BBG's resolv.conf to the BBAI for the heck of it. The content of this file is:
domain lan
search lan
nameserver 192.168.1.1
On the BBAI, /etc resolv.conf is actually a link to /run/connman/resolv.conf. When I place a copy of the BBG's resolv.conf file there and reboot the BBAI, it dynamically overwrites the file with the same content shown above. Apparently Debian 9.x uses something called Connection Manager. Maybe my problem is that there's some Connection Manager config I need to do manually?
If not, at this point I'm thinking about re-flashing the BBAI with a Beagle Debian 9 factory image and redoing the update. Although the network issue might be solvable on its own, the fact that it's occurring on my LAN (which is a pretty plain-vanilla home network) reduces my confidence that the copy of Debian 9 on the BBAI is healthy.
P.S. When posting on this forum, is there text formatting that can be selected for code snippets? Looked around a little but didn't see anything on this.
"route" I think works across all versions to show that
look for the gateway, it might just show as "_gateway" in which case you could try "ping _gateway" to see if it resolves and is contactable.
If no default gateway listed
"route add default gw 192.168.1.1 eth0"
Assuming your router is 192.168.1.1
As the AI does indeed use "connman" that search term will find a few references, just ignore the ones with me moaning about it, others seem to have fared OK but it does seem to need occasional resets.
Thanks for the suggestions. The "route add default gw ..." command let me get to github. However, a bunch of errors occurred during the Kiwi install, and it didn't complete.
So I re-flashed the BBAI with the Debian 9 factory image, redid the update and installed the Kiwi software. It all went very smoothly, and after the final reboot the Kiwi server is now running. The temperature is around 47 C with a makeshift fan -- I'll have to watch it when increasing the clock speed and/or number of receivers.
Only minor issue now is that username debian and password temppwd no longer work to log in. Did the install change that?
I'd try the Kiwi serial number, the root password is reset on the basic version like that, as part of the upgrade path but I can't honestly remember on the AI.
I'd been running the BBAI + Kiwi with a 92mm 5v fan a couple of inches away pointed at an angle toward the BBAI cpu. With the room's ambient temperature around 73 F, BBAI cpu freq set to 1.0 GHz, and 12 of the Kiwi's 14 receivers in use by wsprdaemon, the cpu temp was steady at 45 C today.
The fan cape then arrived from Newark, so I installed it and removed the 92mm fan. After a few minutes running, the cpu temp started to edge up, finally reaching 50 C.
I placed the 92mm fan nearby with the fan cape still operating, and the cpu temp is now around 43 C. Not sure if multiple fans are overkill or not, but that's what produces the lowest temp.
Comments
Added 9-Feb-22 update to first post about how to re-flash a BBAI.
Hi John, why Debian 9 for BB-AI in the instruction? I use Debian 10 on my BB-AI and it works good or you know about some problems?
Because as far as I know most BBAI sitting in distribution still have Debian 9 on them (Mouser for example has 300+ in stock despite the semiconductor situation). Debian 9 still gets security updates just like Debian 10. So that was not a consideration. The recent addition of a Debian 9 image for BBAI was because someone recently had to restore a BBAI this way, it worked, so I thought I'd include it.
Now, the BBAI uses a totally unique way of setting up the SPI/GPIO pins (via a custom, BBAI-specific device tree). How did you do this for a Debian 10 distro? Did you just follow your BBG/BBB procedure for D9 => D10 upgrading or did you actually figure out how the BBAI device tree stuff works? (it's mostly in the Kiwi main Makefile)
John, on one of my BB-AI (newer) I'm flashed Debian 10 image from micro SD and then I did everything described in topic of this theme, - KiwiSDR start normal.
On the second BB-AI (more older) I'm upgraded from Debian 9 to Debian 10 with edit "/etc/apt/sources.list" file without any problem.
I am trying to build a system on a new BBAI with buster installed.
when I run the make I see
Makefile:1016: warning: overriding recipe for target 'install_kiwi_device_tree'
Makefile:1000: warning: ignoring old recipe for target 'install_kiwi_device_tree
and although the build completes, when I try to run it I see kiwid appear in the process listing a few times, but the server never runs....
What did I miss?
Oh god, have they switched to shipping Debian 10 on BBAI's now? What's the output of the
dog
command?I am so done with this stuff..
John.... I'll back up a rev. if needed!
My misery may be self-imposed. I upgraded to Buster to get the rest of Linux current for that non-kiwi stuff I am going to trying to run on the same BBAI
dog output:
Debian 10.11
BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06
Linux beaglebone 4.14.108-ti-r131 #1buster SMP PREEMPT Tue Mar 24 19:18:36 UTC 2020 armv7l GNU/Linux
Debian GNU/Linux 10 (buster)
I put it back to 9.9 and all built and works fine. Not sure what @rz3dvp did to get 10 going
@WA2ZKD I think I just got lucky, tried it on the current Debian version and got the same problem.
I don't know if this is the right place to post an issue/question, but today I hit a glitch while prepping a new BBAI for my KiwiSDR.
After updating Debian (https://beagleboard.org/upgrade, minus the sections on TI deep learning tools, WiFi, USB and Cloud9), I attempted to start the install of KiwiSDR software:
root@beaglebone:~# git clone https://github.com/jks-prv/Beagle_SDR_GPS.git
Cloning into 'Beagle_SDR_GPS'...fatal: unable to access 'https://github.com/jks-prv/Beagle_SDR_GPS.git/': Failed to connect to github.com port 443: No route to host
The prior updates seemed to go normally, so I assume the ethernet connectivity is ok. Something else I'm missing?
What happens when you
ping github.com
orping google.com
from that BBAI?If it fails, what does
cat /etc/resolv.conf
show?Also check the IP range for Github is not in the blocklist, I managed to do that somehow.
Thanks for the suggestions.
On the BBAI, pinging github.com or any other external server produces "Destination Host Unreachable" errors:
debian@beaglebone:~$ ping github.com
PING github.com (192.30.255.113) 56(84) bytes of data.
From 192.168.7.2 (192.168.7.2) icmp_seq=1 Destination Host Unreachable
From 192.168.7.2 (192.168.7.2) icmp_seq=2 Destination Host Unreachable
Although the BBAI apparently obtains github.com's numeric IP address correctly as shown in the first output line, the external site is then shown as 192.168.7.2. This shows the same regardless of whatever external site I pick.
The content of /etc/resolv.conf is:
# Generated by Connection Manager
search example.com example.com
nameserver 192.168.1.1
nameserver xxxx:xxxx:xxxx:xxxx::1
nameserver xxxx:xxxx:xxxx:xxxx::1
The entries "xxxx:..." are actually what I gather is a hexidecimal MAC address, which I've obscured in the (unlikely?) event that it might not be a good idea to post for any reason. Those last two lines in the file are identical to each other.
On the same LAN, I have a BBG + Kiwi which is operating normally, and which will successfully ping github.com or other servers. Although the BBG is on Debian 8.5 and the BBAI shows as 9.13 -- and probably deal with resolv.conf differently -- I thought I'd copy the BBG's resolv.conf to the BBAI for the heck of it. The content of this file is:
domain lan
search lan
nameserver 192.168.1.1
On the BBAI, /etc resolv.conf is actually a link to /run/connman/resolv.conf. When I place a copy of the BBG's resolv.conf file there and reboot the BBAI, it dynamically overwrites the file with the same content shown above. Apparently Debian 9.x uses something called Connection Manager. Maybe my problem is that there's some Connection Manager config I need to do manually?
If not, at this point I'm thinking about re-flashing the BBAI with a Beagle Debian 9 factory image and redoing the update. Although the network issue might be solvable on its own, the fact that it's occurring on my LAN (which is a pretty plain-vanilla home network) reduces my confidence that the copy of Debian 9 on the BBAI is healthy.
P.S. When posting on this forum, is there text formatting that can be selected for code snippets? Looked around a little but didn't see anything on this.
One other note. I did the Debian 9 update on the BBAI with the KiwiSDR installed, in case this makes any difference.
We have seen a missing gateway before.
"route" I think works across all versions to show that
look for the gateway, it might just show as "_gateway" in which case you could try "ping _gateway" to see if it resolves and is contactable.
If no default gateway listed
"route add default gw 192.168.1.1 eth0"
Assuming your router is 192.168.1.1
As the AI does indeed use "connman" that search term will find a few references, just ignore the ones with me moaning about it, others seem to have fared OK but it does seem to need occasional resets.
Thanks for the suggestions. The "route add default gw ..." command let me get to github. However, a bunch of errors occurred during the Kiwi install, and it didn't complete.
So I re-flashed the BBAI with the Debian 9 factory image, redid the update and installed the Kiwi software. It all went very smoothly, and after the final reboot the Kiwi server is now running. The temperature is around 47 C with a makeshift fan -- I'll have to watch it when increasing the clock speed and/or number of receivers.
Only minor issue now is that username debian and password temppwd no longer work to log in. Did the install change that?
I'd try the Kiwi serial number, the root password is reset on the basic version like that, as part of the upgrade path but I can't honestly remember on the AI.
Thanks! That worked.
Now on to working out a more permanent cooling approach.
they sell a cape that go between the boards and has a fan.
Haven't seen anything about that yet. Is there a link?
"https://www.newark.com/element14/6100310/beaglebone-ai-fan-cape/dp/50AH3704"
Thanks. Actually I'd seen this discussion:
"https://forum.kiwisdr.com/index.php?p=/discussion/comment/10329#Comment_10329"
Is the cape adequate? Or can mods make it so?
There is really no need to boost the CPU speed.... I'm not sure how Clint had everything together
Now that you mention it, I haven't seen much about the benefit of boosting cpu speed. In theory would it enable more or better decodes?
it has no tangible benefit that I have found on either of my 2 BBAI based wspr RX
A small test:
I'd been running the BBAI + Kiwi with a 92mm 5v fan a couple of inches away pointed at an angle toward the BBAI cpu. With the room's ambient temperature around 73 F, BBAI cpu freq set to 1.0 GHz, and 12 of the Kiwi's 14 receivers in use by wsprdaemon, the cpu temp was steady at 45 C today.
The fan cape then arrived from Newark, so I installed it and removed the 92mm fan. After a few minutes running, the cpu temp started to edge up, finally reaching 50 C.
I placed the 92mm fan nearby with the fan cape still operating, and the cpu temp is now around 43 C. Not sure if multiple fans are overkill or not, but that's what produces the lowest temp.
Interesting BBAI & Debian 10 works good with 1.539 KiwiSDR version but generate panic error with modern version KiwiSDR.
@jks Maybe have any way to fix this problem?
v. 1.547
v. 1.539
I have 2 BBAI systems running latest code without issue.... FWIW
Jim, but running Debian 9 or 10?
If D10, does your log say
### using SPI_DEV /dev/spidev0.0
or/dev/spidev1.0
?