Under certain high load conditions in OpenWrt, using dual-core Laguna products, Ethernet ping latencies could grow to an unacceptable value. After investigation, Gateworks found an SMP race condition as the cause in the CNS3xxx Ethernet driver in Gateworks’ 13-06 and trunk OpenWrt BSPs. Note that the 12-10 OpenWrt BSP is not affected. Gateworks has resolved the issue with upstream patches to OpenWrt:
These fixes have been committed in both the Gateworks 13-06 branch and trunk. Additionally, the prebuilt 13-06 binary firmware images have been updated and they are located here: Laguna Binary Images.
Gateworks recommends all customers using dual-core Laguna products update their firmware.
From time to time we get questions about floating point math on ARM
CPU’s. As it turns out this is a rather advanced topic that deserves
some discussion, so we recently put all of our notes and experiences into
a Wiki article that we felt was worth blogging about.
To make a long story short, many users get confused about the various
GNU Compiler (gcc) options for floating point. The most common
misconception is that ‘-mfloat-abi=softfp’ means that you are using
software floatingpoint math when in fact that produces binaries that
use hard float acceleration (as specified by the -mfp) agument but
with a function calling convention compatible with software floating
point. This allows the mixing of binaries and libraries that were
built for soft float vs hard float and is very useful if you are
trying to build a OS distribution that runs on a wide variety of
CPU’s. However, if you really want to squeeze the most out of your
ARM CPU that has hardware floating point support you can
achieve performance boosts (under most circumstances) by compiling
with -‘mfloat-abi=hard’ (which also means you will not be compatible
with binaries built with soft float). Also, keep in mind that your
Linux kernel must have VFP support if using hard float.
To see all the intricate details please visit our floating point wiki page