Build up toolchain for embedded development

[subdiff]

For an agile and efficient development process an embedded Linux developer needs a functional toolchain, such that:

1. the coding and compiling can be done on the developer's x86 main development machine (MDM),
2. altered kernel images and userland libs can quickly be deployed to the embedded device,
3. early boot process can be analyzed via terminal from MDM.

ad 1.: this problem is solved for some of the software that is relevant to us, but not for all of it.

Cross-compiling our kernel for ARM64 is already possible but other software is more difficult to cross-compile, in particular our KDE software. I'm currently looking into this, but could need some help.

If this does not work having the source on the Pinebook directly can be made bearable atleast a bit by sharing it via SSH with the MDM and doing the coding then there again, but the compiling on the Pinebook.

At some point we should also look into Buildroot, which is a very nice build script to build a complete root filesystem for an embedded device. But since we get currently most of userland from Neon build servers and while Buildroot has a package for Qt it does not have one for our KDE software, where it currently mostly fails for us, we should postpone trying it out.

ad 2.: there are multiple options, that I have to look into more:

• The option to boot down, remove the MicroSD, write to it on MDM, put it back in and then boot up again is a no-go.

• A simple solution is to create a NFS or SSH share and move the files this way. The connection must be reestablished after every reboot, but this might be automated via script (something like while true; do; sshfs -o nonempty,ServerAliveInterval=100 root@<pinebook ip>:/ /path/on/MDM/to/pinebook_root; sleep 1; done) and by using a USB to Ethernet adapter or just by wireless.

• A more involed solution is a NFS export of some directory on the MDM with the whole root filesystem of the Pinebook inside it and boot the Pinebook via network from that (Tutorial for A10/A20).

  To try this out I bought an USB to Ethernet adapter. U-Boot docs say it can handle "supported" USB Ethernet adapters, but I didn't find any information about the supported ones, so I just need some luck with the one I bought.

  To setup this solution there might be an UART connection necessary once (see 3.).

• Another option for such a boot from MDM disk space is FEL, which is a special dev mode inside an Allwinner BootROM. In theory by this a full boot with bootloader and kernel saved on MDM and just a connected USB cable (USB-A to USB-A!) should be possible.

  On the MDM the sunxi-tools are needed. I tried the FEL mode out with a Pine64, because it is there more easy to activate the mode (just don't insert a MicroSD) and the sunxi-tools dicovered the device successfully. If booting via this connection is also possible, is another story though. I haven't yet tested this.

  As a side note ayufan also has a repo about FEL. Also in this context something not fully clear to me right now is how U-Boot is build into our image and if our image already uses some stuff from ayufan's repo. I need to ask @shadeslayer about this.

ad 3.: currently this is not of high priority, because our kernel boots far enough to get network working and our current problems are not related to early system boot. For the future or maybe the last mentioned solution of 2. it might still be necessary. The to-go solution here is a TTY via UART.

For that I bought an adapter to Mini(!)-USB.

In the case of Pine64 this can easily be connected with female DuPont cables to its pins.

In case of the Pinebook you need to sacrifice a 3.5mm audio cable, because UART runs apparently via its headphone jack.

But I have to confirm this first on both devices. My adapter should arrive in the next few days. In any way if you try it yourself, you need to set its jumper to 3.3V!

[aleixpol]

Why don't you want to use docker+qemu to cross-compile the KDE bits?
https://www.proli.net/2017/12/18/docker-as-an-sdk-for-arm-distributions/

[subdiff]

Why don't you want to use docker+qemu to cross-compile the KDE bits?
https://www.proli.net/2017/12/18/docker-as-an-sdk-for-arm-distributions/

No worries, I didn't forget about the post you made! :) I installed qemu some days ago to get used to it. I tried to create an ARM64 image, but something failed when I booted it. But I'll definitely explore this possibility further.

Ignoring this, with your solution by integrating with Docker can the host access the files, which got compiled in the container? Because in the end the files need to be sent by the host somehow to the Pinebook. Is the use of volumes like explained here the canonical solution?

[aleixpol]

Ignoring this, with your solution by integrating with Docker can the host access the files, which got compiled in the container? Because in the end the files need to be sent by the host somehow to the Pinebook. Is the use of volumes like explained here the canonical solution?

Yes, there's several ways to access the files. Volumes are the most conventional way indeed.

[sebasje]

For embedded development, I often ended up writing a simple script to build packages (back in the day on OBS) and then rsync them to the device and install them via an ssh command locally. That worked pretty well and was mostly automated for hack/deploy/test cycles.