| commit | 2f100fcc61769cd3a8d00809fd1593218bf71704 | [log] [tgz] |
|---|---|---|
| author | Jan Kundrát <kundrat@cesnet.cz> | Mon Nov 02 22:10:16 2020 +0100 |
| committer | Jan Kundrát <kundrat@cesnet.cz> | Tue Nov 03 14:37:13 2020 +0100 |
| tree | d957546a41f6835bf1eee7e8c69b5a618ab02302 | |
| parent | 269d70f1fe5efc618efb02411d8a01714f1aec4e [diff] |
Use new, daemon-less sysrepo for YANG management Updating all dependencies so that we're using the new sysrepo. The easiest way there was via bringing in the new buildroot as well, which meant: - new RAUC, hence no patch needed anymore, - newer systemd, hence an updated patch, - New spdlog and fmt, which means that the version we ship in submodules/dependencies no longer works. Fix that by just relying on systemwide spdlog. - uboot-tools needed a patch because there's no /var/lock, - OpenSSH was previously started autmagically, now we're explicitly adding that to the list of packages (I really like SSH, don't you?). New sysrepo means that there's no `sysrepod` anymore, which required changing a bunch of other units so that they are not marked as `PartOf=sysrepod.service` anymore. Also, the command-line options for `sysrepocfg` and `sysrepoctl` changed. I had to patch buildroot so that it doesn't create SSH keys for the NETCONF server at build time, and that all required modules are actually installed. It turns out that new sysrepo doesn't really install anything, and the fun only starts with Netopeer2. Their install scripts a wee bit picky, but hey, we have bash, we can make it work. On the other hand, installation of *our* YANG modules is a bit hairy. There's just too much parallel activities going on, and therefore I have no idea how robust our callout to `sysrepoctl --apply` really is. As a cherry on top, `sysrepocfg` is particularly inconsistent when it comes to how the **** one is supposed to provision the initial config, etc etc. In the end, I ended up with a big hammer. Installation of all non-netopeer2 YANG modules now happens from just a single script, the previous way was very fragile and failed quite often -- probably because that "wonderful" new way of installing a module and possibly enabling a feature and also importing some data which might or might not be the required initial data, so *THAT* thing, depended on whether there already was or was not another SW connection. Wonderful. If only there was a oneliner for that, then we could have avoided all this stupid boilerplate. Oh well. On the other hand, the `cla-sysrepod` is now properly signalling its "up-and-running" status to systemd, *and* this up-and-running state is only reached once the configuration has been propagated to the optical HW. As a result, the HW watchdog will recover from an upload of a broken FW (or, alternatively, it will keep rebooting if the optical HW is FUBAR -- pick your poison, sir). Change-Id: I4b65a8fb345bfe7907a331d0de16294af1c36a78
This repository contains CzechLight-specific bits for Buildroot. Buildroot is a tool which produces system images for flashing to embedded devices. They have a nice documentation which explains everything that one might need.
The system architecture is described in another document. This is a quick build HOWTO.
Everything is in Gerrit. One should not need to clone anything from anywhere else. The build will download source tarballs of various open source components, though.
By default, each change of this repo uploaded to Gerrit causes the CI system to produce a firmware update. On Gerrit, the change will get a comment from Zuul with a link to the CI log server. Next to the logs, a file named artifacts/update.raucb can be used for updating devices.
Behind the scenes, the system uses Zuul with a configuration tracked in git.
Here's how to reproduce the build on a developer's workstation:
git clone ssh://$YOUR_LOGIN@cesnet.cz@gerrit.cesnet.cz:29418/CzechLight/br2-external czechlight pushd czechlight git submodule update --init --recursive popd mkdir build-clearfog cd build-clearfog ../czechlight/dev-setup-git.sh make czechlight_clearfog_defconfig make
A full rebuild takes between 30 and 45 minutes on a T460s laptop.
WARNING: Buildroot is fragile. It is not safe to perform incremental builds after changing an "important" setting. Please check their manual for details.
Apart from the traditional way of re-flashing the SD card or the eMMC from scratch, it's also possible to use RAUC to update. This method preserves the U-Boot version and the U-Boot's environment. Apart from that, everything starting with the kernel and the DTB file and including the root FS is updated. Configuration stored in /cfg is brought along and preserved as well.
To install an update:
# build node make rsync -avP images/update.raucb somewhere.example.org:path/to/web/root # target, perhaps via an USB console or over SSH rauc install http://somewhere.example.org/update.raucb reboot
On a regular Clearfog Base with an eMMC, one has to bootstrap the device first. If recovering a totally bricked board, one can use the kwboot command to upload the initial U-Boot via the console. Ensure that the jumpers are set to 0 1 0 0 1 (default for eMMC boot is 0 0 1 1 1), and then use U-Boot's kwboot tool:
./tools/kwboot -b ./u-boot-spl.kwb -t -p /dev/ttyUSB0
Once in U-Boot (a stock factory image is OK as well), plug a USB flash disk which contains images/usb-flash.img and execute:
usb start; fatload usb 0:1 00800000 boot.scr; source 00800000
The system will boot and flash the eMMC from the USB drive. Once the status LED starts blinking in yellow, data are being transferred to the eMMC. The light changes to solid yellow in later phases of the flashing process. Once everything is done, the status LED shows a solid white light and the system reboots automatically.
Turn off power, remove the USB flash, re-jumper the board (0 0 1 1 1), power-cycle, and configure MAC addresses and system type at the U-Boot prompt. The MAC addresses are found on the label at the front panel.
=> setenv eth1addr 00:11:17:01:XX:XX => setenv eth2addr 00:11:17:01:XX:YY => setenv eth3addr 00:11:17:01:XX:ZZ => setenv czechlight sdn-roadm-line => saveenv Saving Environment to MMC... Writing to redundant MMC(0)... OK => boot
Once the system boots (which currently requires a reboot for some unknown reason -- fsck, perhaps?), configure hostname, plug in the network cable, and update SW:
# hostnamectl set-hostname line-XYZSERIALNO # cp /etc/hostname /cfg/etc/ # rauc install http://somewhere.example.org/update.raucb # reboot
Obtain a reasonable Linux distro image for BBB and flash it to a µSD card. Unlock eMMC boot partitions (echo 0 > /sys/class/block/mmcblk1boot0/force_ro; echo 0 > /sys/class/block/mmcblk1boot1/force_ro). Clean the eMMC data (blkdiscard /dev/mmcblk1). Flash the content of images/emmc.img to device's /dev/mmcblk1. Flash what fits into /dev/mmcblk1boot0 and /dev/mmcblk1boot1. Fetching the image over web (python3 -m http.server and wget http://...:8000/emmc.img -O - | dd of=/dev/mmcblk1 conv=sparse) works well.