It looks like you're new here. If you want to get involved, click one of these buttons!
distribution of binaries rather than local builds has been mentioned and would solve a lot
By "bricked it" I meant that it didn't reboot. I'm sure that it'll come back when I write a new image on a flash card. I already backed up my kiwi.config directory so I'm covered there. It's just a lot more work than it should be. Sigh.
Still, this is linux, and mainstream Debian Linux has gotten very good at simplifying even major updates and upgrades. For my regular (non-embedded) Debian systems, I can just edit the /etc/apt/sources.list file to reflect a new release name, then do "apt update" and "apt dist-upgrade" followed by a lot of waiting as the new packages are installed one by one.
This is the only Beagle Board I have, so maybe there's something unique to Linux on this platform. All my other Debian Linux systems are Raspberry Pis and x86s, and I've gotten pretty comfortable with updates on them.
@ka9q It's possible for BBG/BBB too and I successfully upgrade 5 my KiwiSDR, but you need more much time and always have risk of trouble for remote update, - file system error, power problem and etc. Before start upgrade you must be ready for this problems, create SCP backup and it's only your responsibility.
I got my unit working again by simply loading the new image from the micro SD card. I saved and restored the kiwi.config directory by using rsync to stash it on a local machine, then copying it back when I had the new image running. That was a lot faster and easier than storing it on another SD card.
Admittedly it was quicker to update the system image from a SD card than doing apt-get (as well as more successful), but I wanted to see if the update could be done entirely over the network. I'm sure at least some kiwisdrs are in places that are not easily accessed by their owners to physically insert and remove SD cards.
(edit:- false alarm. See end.)
I'm in the process of updating my pair of genuine KiwiSDRs from Jessie to Buster, following rz3dvp's method. As a Linux admin, I wanted to try the upgrade in place before I do the SD-card method. I know I can always nuke and pave as appropriate if this particular method fails, just waiting on delivery of some 8Gb SD cards as I have none spare.
I see one problem at the moment. After the update, I'm not seeing the Kiwi serial (4542) in the logs. Now, I'm not sure if this is my fault in breaking something during the udpate or something inherently related to the OS update itself.
This is also an FYI to John in case he sees a raft of KiwiSDRs attempting registration post-update and looking like the Chinese knock-offs - if the issue here is not caused by somethign I missed,
(I also have an issue with both of the beaglebones being unable to access the FPGA on one of the capes, but I'll start a new thread for that one, once I have the second KiwiSDR updated and back on the network. Suspecting hardware for that one)
Thu Feb 14 10:12:22 00:00:00.217 L KiwiSDR v1.516 --------------------------------------------------------------------
Thu Feb 14 10:12:22 00:00:00.220 L compiled: May 2 2022 20:57:50 on kiwisdr1
Thu Feb 14 10:12:22 00:00:00.220 L -debian 10
Thu Feb 14 10:12:22 00:00:00.222 L /etc/debian_version 10.12
Thu Feb 14 10:12:22 00:00:00.227 L background mode: delaying start 30 secs...
Tue May 3 08:07:15 00:00:30.230 TASK MAX_TASKS 217(198|17|2), stack memory 17.6 MB, stack size 8|32|64 k so(u64_t)
Tue May 3 08:07:15 00:00:30.300 L reading configuration from file /root/kiwi.config/kiwi.json: 1721 tokens (20.8k bytes)
Tue May 3 08:07:15 00:00:30.307 L reading configuration from file /root/kiwi.config/admin.json: 127 tokens (3.0k bytes)
Tue May 3 08:07:15 00:00:30.308 L EEPROM check: open /sys/bus/i2c/devices/2-0054/eeprom No such file or directory
Tue May 3 08:07:15 00:00:30.309 L can't read serial number from EEPROM and no configuration override
Tue May 3 08:07:15 00:00:30.309 L reading configuration from file /root/kiwi.config/dx.json
Tue May 3 08:07:15 00:00:30.335 L DX: 1382 label entries
Tue May 3 08:07:15 00:00:30.339 ADC_CLOCK: 66.665900 MHz
Tue May 3 08:07:15 00:00:30.339 ........ L firmware: SDR_RX8_WF2
Tue May 3 08:07:15 00:00:30.341 ........ L firmware: rx_chans=8 wf_chans=2
Tue May 3 08:07:15 00:00:30.343 ........ L firmware: RX bufs=8 samps=85 loop=85 rem=0 intr_usec=7083
Tue May 3 08:07:15 00:00:30.345 ........ L firmware: WF xfer=9 samps=911 rpt=50 loop=18 rem=11
Tue May 3 08:07:15 00:00:30.346 ........ L webserver: listening on port 8073/8073 for HTTP connections
Tue May 3 08:07:15 00:00:30.360 ........ L webserver: OK, port [::]:8073
Tue May 3 08:07:15 00:00:30.363 ........ checking SPI pmux settings..
Tue May 3 08:07:16 00:00:30.593 ........ SPI: CPU_AM3359 SPI_SHMEM_DISABLE
Tue May 3 08:07:16 00:00:30.593 ........ L ### using SPI_DEV /dev/spidev0.0
Tue May 3 08:07:16 00:00:30.595 ........ SPIDEV: max_speed 48000000 bpw 32
Tue May 3 08:07:17 00:00:31.441 ........ ping..
Tue May 3 08:07:17 00:00:31.441 ........ ping2..
Tue May 3 08:07:17 00:00:31.443 ........ L FPGA version 1
Tue May 3 08:07:17 00:00:31.447 ........ L EEPROM check: open /sys/bus/i2c/devices/2-0054/eeprom No such file or directory
Tue May 3 08:07:17 00:00:31.449 ........ eeprom_update: BAD serno
Tue May 3 08:07:17 00:00:31.544 ........ device DNA 11468416|24242e7f
Tue May 3 08:07:17 00:00:31.545 ........ RX N_CONNS 136 conns 0.084 MB
Tue May 3 08:07:17 00:00:31.545 ........ L using DC_offsets: I -0.020000 Q -0.020000
root@kiwisdr1:~# uname -a
Linux kiwisdr1 4.19.94-ti-r73 #1buster SMP PREEMPT Fri Apr 15 21:38:30 UTC 2022 armv7l GNU/Linux
root@kiwisdr1:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Entirely possible I missed something specific to the Beaglebone/cape scenario during the update, my experience is mostly x86 and amd64 servers, not the embedded side of the house.
May 3 08:41:03 kiwisdr1 kiwid: 00:00:30.759 serial number from EEPROM: 4542
May 3 08:41:03 kiwisdr1 kiwid: 00:00:30.761 reading configuration from file /root/kiwi.config/dx.json
A power cycle brought the reading of the eeprom back into play. Weird, but it is what it is.
As you were! :)
I just received my KiwiSDR from the UK and ready to start playing.
Is it OK to load the buster firmware before I do anything else or should I configure it under jessie and then upgrade to buster?
The factory installs v1.2 (one point two) of the software. When you get the Kiwi power it up while connected to a network with Internet access. Let it auto update to the latest software version (v1.518 as of today). That process takes about an hour.
After the update use the my.kiwisdr.com site to find the Kiwi's local ip address. Or try kiwisdr.local:8073/ Then you can follow the instructions at the beginning of this thread for upgrading from Jesse to Buster.
Don't take any shortcuts.
@jks Thank you for providing the OS update.
I spent the rainy afternoon with upgrading my kiwis, which went without surprises.
My WiFi dongles seem to be supported now without having to install additional software, which is great.
After the first reboot, I could not login by ssh, neither with user "debian" nor "root". I changed the passwords using the admin console and then I could log in via ssh with the user "debian". However by default, ssh login with root is disabled. /etc/ssh/sshd_config needs an entry "PermitRootLogin yes" for that.
Otherwise everything went smooth.
Hi! Just writing to let everyone know that I did this upgrade today and it went pretty smoothly. I have only one complaint - the line that says:
should instead read:
Aside from that things went really well. I did have one point of confusion because I had booted my Kiwi with the MicroSD card inserted, which caused mmcblk0 and mmcblk1 to be swapped, which led to a lot of confusion when I mounted mmcblk1p1 and tried to restore the configuration files and it complained that the files were the same:
root@kiwisdr:/media/sd_boot/root/kiwi.config# cp admin.json kiwi.json dx.json ~/kiwi.config
cp: 'admin.json' and '/root/kiwi.config/admin.json' are the same file
cp: 'kiwi.json' and '/root/kiwi.config/kiwi.json' are the same file
cp: 'dx.json' and '/root/kiwi.config/dx.json' are the same file
But eventually I figured out what I had to do - use the mosd0 command instead of mosd1! That was my fault for not following the directions exactly, though.
Now to try setting up a wifi dongle...
UPDATE: Turns out Debian 10 seems to always make mmcblk0 the external SD slot, populated or not, and assigns the internal storage to mmcblk1.
I fixed .config => kiwi.config in the instructions.
Also swapped mmc0/mmc1 in the Debian 10 section. Not sure how I missed that or why no one mentioned it until now. I see that Debian 9 (BBAI) also has it reversed compared to Debian 8.
The mmc0/mmc1 thing might have just been the result of a kernel update or something. It was definitely the other way around when I was running Debian 8.
After trying several wifi dongles unsuccessfully with debian 10, I found an older TL_WN 722N and it showed up right away with the correct id and without need to find specific drivers. After that I only needed to use connman which is already built-in to Buster to configure for the local network and voila, both wifi and ethernet access are now available.
Just in time since I can not bring my BBAI back to life. These TPLink dongles are still sold online for about 20 usd so perhaps something you can give a try as well.
Thanks for the tip! I've got several dongles that work fine with 2.4 GHz wifi, but I'm hoping for 5.8 GHz with external antenna jacks. Those are rare, but I have a Panda Wireless PAU09 N600 that fits the bill and has worked for me without custom-compiled drivers on Raspbian 10, at least. Since that's basically Debian 10 I'm hoping it'll work here, too.
My Kiwi is out in a shed away from the house because the RFI is horrific in my house. I have a Wellbrook loop on the shed roof and I'm hoping to get a stable wifi connection from a Ubiquiti bridge into my home network. Now I just need some time to try this out and get it set up.