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.
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.)
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.
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.
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.
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
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.
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.
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.
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.
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
If you need to extend them; add a custom file
to override the default.
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:
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:Example config for the common ISC DHCP server: