The gpp_setup routine mitigated the need for trust-uname-m.patch,
so it has been deleted in favor of using --processorname when
generating the node. Rather than generating the node on first
boot, however, we've switched to using redhawk-native to build
the node during bitbake. If the user does not want to use that
node however, they would have to remember to add the
processor_name property to their definition and patch it to the
PACKAGE_ARCH. Rather than do that, we are now patching the PRF
similar to how the REDHAWK core framework does on installation.
The gpp_setup routine mitigated the need for trust-uname-m.patch, so it has been deleted in favor of using --processorname when generating the node. Rather than generating the node on first boot, however, we've switched to using redhawk-native to build the node during bitbake. If the user does not want to use that node however, they would have to remember to add the processor_name property to their definition and patch it to the PACKAGE_ARCH. Rather than do that, we are now patching the PRF similar to how the REDHAWK core framework does on installation.
This addresses #46 for rocko.
Signed-off-by: Thomas Goodwin btgoodwin@geontech.com