blue-systems / neon-pinebook-remix

Todos for Neon Pinebook Remix
3 stars 0 forks source link

Build up toolchain for embedded development #51

Open subdiff opened 6 years ago

subdiff commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.