Advanced Use

Root file system template

The skeleton inheritance chain:
    skeleton → raspi_b_revx → raspi_x_revx → default
       (1)   →      (3)     →      (5)     →   (6)  

Lets expand skeleton (1) and raspi_b_revx (3):

We can see skeleton (1) is almost empty. A small recipe Rules.mk (2) is all what's in there. Going to next inheritance level raspi_b_revx (3) we find another recipe and a "fs-template" (4) directory. It's a template of the final target root file system. Every product and board in the inheritance chain may optionally contain one and they all contribute to the end result as a whole. The raspi_b_revx (3) filesystem template is very small. The single file will end up as /etc/rc.raspi_b_revx in the final target file system. Expanding next inheritance level raspi_x_revx (5):

This tree is a lot bigger. First is a number of *.config files. They contain the settings for a number of applications in the final product. (Inheritance may override a .config deeper down the chain.) Everything in raspi_x_revx/fs-template/etc will end up "as is" in the final product /etc file system.

Remote start

Easily run commands remotely in the target during development. Here is an example of starting the Hello World application in a specific target, given by its Ethernet MAC address. (The target must be connected to the same local subnet as your PC.)

Autostart at boot

When you have created a custom application you probably want it to always start up automatically when the system boots. The simplest method is to add a shell script in /etc having a name identical to the product name. Example:

The script nard/platform/my_product/fs-template/etc/rc.my_product will be executed at boot. Additionally there is a "autostart at network" as well; programs in /etc/network/if-up.d/ are started when a network interface becomes ready.

Scheduled start

Some automated work are often needed once a day. Cron is setup to execute all programs in /etc/cron.daily/ every night. For example, if you create backups, here is the place to initialize them.

The cross compiler

An ARM cross compiler tuned for the Raspberry Pi processor is included in Nard. Generally one need to add the path to it though in Makefiles. When you write new Makefiles, add something like CC="$(PATH_CROSS_CC)gcc" as and argument to make.

When you need to manually invoke other parts of the toolchain, for instance GDB or objdump, they are conveniently located in nard/util/bin. You may add at path to it.

Debugging

If your program behaves badly it can be debugged remotely with the bundled GDB/Insight debugger. Nard has debugsymbols enabled pretty much everywhere to ease troubleshooting, not just inside of your application but anywhere in userspace. We shall verify it's working by launching the Hello World program in a debug session. GDB/Insight will run in your local PC and communicate with the target (via network) where the program is executing.

There is a "command" file (gdbinit) in the Hello World source directory we tell GDB to execute and it contains all the settings necessary to configure GDB for a Raspberry target.

The bundled Insight graphical debugger


The bundled classic GDB

Kernel configuration

If the standard kernel configuration doesn't fit your needs here is a simple way to modify it (prior experience is assumed).

Your custom kernel .config end up in
platform/skeleton/linux-rpi-3.10.y.config where it will override the default.

BusyBox configuration

If the standard BusyBox configuration doesn't fit your needs it to can be customized as the kernel above.

Your custom BusyBox .config end up in
platform/skeleton/busybox-1.22.1.config where it will override the default.

The serial port

Does your project involve a sidekick microcontroller such as Arduino, PIC or AVR? Then you might need to dedicate the built in serial port (UART) for IPC RS-485 communication. Usually the serial port is a Linux console where one can monitor boot messages and login with a password, but embedded systems often has other uses for it. There is an example product available which has all the necessary modifications done to free up the serial port. The consoleserver product turns the Raspberry Pi into a classic terminal/console server where the serial port can be reached via TCP/IP. Run telnet from your PC (to the Pi) and start read/write the port.

There are many guides on the net for how to free up the serial port, but most of them lacks the information that the kernel needs a patch as well. The consoleserver recipe has a reference to such a patch so ensure not to miss it if copying the product. The port becomes /dev/ttyAMA0 and there is a good HOWTO for how to program it.

USB memory stick

Do you need large storage or frequent writes to a database? Then use of a USB disk is recommended alongside the SD card. Nard automatically mounts the first USB disk at /mnt/usbdisk/ on access and later unmounts is when it becomes unused.

Firewall

Nard has a decent network security firewall (iptables), but it's disabled by default for ease of use during development. Enable it by adding this line to your product recipe:

The policy rules are in
nard/platform/raspi_x_revx/fs-template/etc/network/if-pre-up.d/firewall
If you need to extend them; add a custom file
nard/platform/my_product/fs-template/etc/network/if-pre-up.d/firewall
to override the default.

Password

The default credentials should always be replaced. The proper way to do this is by overriding /etc/passwd via inheritance in your custom product. Generate the override file by first logging in to the target, set a new password with standard tools and finally copy the modified password store back to your build PC like this:

Network boot

Get rid of the SD card entirely by PXE network booting! Thanks to Nard by design run entirely from RAM, it's a perfect fit for network booting. Unlike competing distros, not even NFS-root is required. Thus a glitch in the network, which normally create hiccups in NFS-rooted devices, has no impact on Nard. The Pi model 3B+ offers the best net boot experience, with out-of-the-box support.

Nard deprecates NFS

There are two prerequisites. A DHCP server which informs the Pi of where to download binarys from and a TFTP server to hand out those binarys. The Raspberry Pi foundation has a tutorial for setting this up with Dnsmasq. Below however alternatives are used: