| commit | 7f2ff837da30adc0abdc9bf423e11b56f1800b4b | [log] [tgz] |
|---|---|---|
| author | Jan Kundrát <jan.kundrat@cesnet.cz> | Tue Jan 23 19:21:56 2018 +0100 |
| committer | Jan Kundrát <jan.kundrat@cesnet.cz> | Tue Jan 23 19:21:56 2018 +0100 |
| tree | d71b55d1e0f158a02f4fa3f4ae59d22668388324 | |
| parent | 23b16293588f3262cb5b77457abe2516134558bc [diff] |
clearfog: Add a SW bit-bang I2C bus for PMBus Unfortunately, we do not have a standalone I2C bus on this board; the I2C0 is not present on any accessible pins (and cannot be easily muxed), and I2C1 goes directly to the SFP slot which uses 0x50/0x51 addresses that conflicts with out PSUs. Because PMBus might want to use hard-coded addresses every now and then, even solutions with some ad-hoc address translators such as LTC4316 might not fully help (think ARA or PEC). Let's use a software bitbang to add another I2C bus. What remains is a choice of proper GPIO pins. We could use some which belong to MAX14830, I've tested it and it's fast enough to run at 20kHz. When we reuse the SoC's own GPIO pins, though, the effective SCL frequency is about 67kHz. I tried timing the following operations: 1) `time echo pmbus 0x25 > /sys/bus/i2c/devices/i2c-2/new_device` for device initialization, 2) `time cat /sys/class/hwmon/hwmon4/*_input > /dev/null` for reading all values the first time, 3) the same command as 2), but after a few seconds to re-read this stuff. The results are as follows: | | device init | first read | second read | |---------------|-------------|------------|-------------| | native I2C | 1.39s | 0.48s | 0.28s | | SoC GPIO | 1.82s | 0.65s | 0.35s | | MAX14830 GPIO | 5.12s | 1.96s | 1.10s | Given that we have "enough UARTs", let's reuse ua1's pins for SW I2C. Change-Id: I1ea5eb421d6029ec5b5e544b94207922bae65222
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.
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.
TODO: Automate this via the CI system. I want to get the .img files for testing of each change, eventually.
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 for targets which use a pre-generated Linaro toolchain (clearfog, beaglebone). Other targets take longer because one has to build a toolchain first. When the build finishes, the generated image to be dd-ed to an SD card is at images/sdcard.img.
WARNING: Buildroot is fragile. It is not safe to perform incremental builds after changing an "important" setting. Please check their manual for details.
A significant amount of time is wasted in configure steps which are not parallelized :( as of November 2017. This can be hacked by patching Buildroot's top-level Makefile, but note that one cannot easily debug stuff afterwards.
diff --git a/Makefile b/Makefile index 79db7fe..905099a 100644 --- a/Makefile +++ b/Makefile @@ -114,7 +114,7 @@ endif # this top-level Makefile in parallel comment the ".NOTPARALLEL" line and # use the -j<jobs> option when building, e.g: # make -j$((`getconf _NPROCESSORS_ONLN`+1)) -.NOTPARALLEL: # absolute path TOPDIR := $(CURDIR)
Also, we are building two different root filesystem instances (an EXT4 image and a tarball for RAUC). This is also currently broken, but we can work around that reasonably easily:
make -j32 target-finalize && make
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 wget http://somewhere.example.org/update.raucb -O /tmp/update.raucb rauc install /tmp/update.raucb reboot