Commit graph

18 commits

Author SHA1 Message Date
Michael LeMay 6557194fc5 galileo: Revise include flags for LLVM Clang
This patch revises the compiler flags when LLVM Clang is in use to
cause Clang to automatically use its built-in header files rather than
those for GCC.
2016-01-25 14:01:16 -08:00
Michael LeMay 38206e3980 galileo: Add Ethernet support
This patch adds support for Ethernet to the Intel Galileo port.  It
uses the Intel Quark X1000 Ethernet driver.  It initializes the first
Ethernet interface and starts some common network services.  By
default, it uses the following addresses:
 - Host: 192.0.2.2
 - Netmask: 255.255.255.0
 - Default gateway: 192.0.2.1
 - DNS server: (same as default gateway)
These settings can be changed by editing eth-conf.c.
2015-12-21 08:06:14 -02:00
Ricardo de Almeida Gonzaga 93c7988069 x86: Add Galileo pinmux support
This patch adds the galileo-pinmux.c and galileo-pinmux.h files,
which support access to pinmux configuration through a function
interface.

This is not 100% supported yet due to some pinmux paths
need Quark X1000 GPIO (legacy and non-legacy) configurations.

After we finish to implement Quark X1000 GPIO driver we'll add
support for this.
2015-12-21 08:06:14 -02:00
Ricardo de Almeida Gonzaga 781375f1d1 x86: Add PCA9685 support
This patch adds pwm-pca9685.c and pwm-pca9685.h files,
which support access to I2C-based PCA9685 PWM controller
configuration register through a function interface.

The PCA9685 is an I2C-bus controlled 16-channel LED controller
optimized for Red/Green/Blue/Amber (RGBA) color backlighting
applications. Each LED output has its own 12-bit resolution
(4096 steps) fixed frequency individual PWM controller that
operates at a programmable frequency from a typical of 24 Hz to
1526 Hz with a duty cycle that is adjustable from 0 % to 100 %
to allow the LED to be set to a specific brightness value.
More about PCA9685 can be found in its datasheet[1].

This driver is needed in order to configure Galileo pinmux.

[1] - http://www.nxp.com/documents/data_sheet/PCA9685.pdf
2015-12-21 08:06:14 -02:00
Ricardo de Almeida Gonzaga 495dcd659a x86: Add PCAL9535A support
This patch adds gpio-pcal9535a.c and gpio-pcal9535a.h files,
which support access to I2C-based PCAL9535A GPIO controller
configuration register through a function interface.

The PCAL9535A is a low-voltage 16-bit GPIO expander with interrupt
and reset for I2C-bus/SMBus applications. It contains the PCA9535
register set of four pairs of 8-bit Configuration, Input, Output,
and Polarity Inversion registers, and additionally, the PCAL9535A has
Agile I/O, which are additional features specifically designed to
enhance the I/O. More about PCAL9535A can be found in its datasheet[1].

This driver is needed in order to configure Galileo pinmux.

[1] - http://www.nxp.com/documents/data_sheet/PCAL9535A.pdf
2015-12-21 08:06:14 -02:00
Michael LeMay 17b855aac9 galileo: Replace non-halting core implementation of assert with the halting one from newlib
This patch modifies the include order to include headers from newlib
ahead of those from the core of Contiki.  The only header file names
that are common between Contiki and newlib are assert.h and config.h,
but the config.h files in Contiki are only located in ports for other
CPUs so they are irrelevant to this patch.  The motivation for this
patch is to cause files that include assert.h to include the one from
newlib that halts when an assertion fails.  The assert implementation
in the core of Contiki does not halt when an assertion fails.

This patch also adds newlib syscall stubs that are required by the
newlib assert implementation and the _exit syscall function that halts
the system.

Finally, this patch updates some other newlib syscall stubs to
properly indicate their status as unsupported syscalls.
2015-12-21 08:06:14 -02:00
Andre Guedes e41bed319f galileo: Revise stdlib static linking
This patch does some refactoring so we are able to statically link
against standard libraries in a more usual way.
2015-12-21 08:06:14 -02:00
Andre Guedes 7043aa41b3 galileo: Fix newlib-syscalls issue in Makefile
This patch removes 'newlib-syscalls.c' from CONTIKI_SOURCEFILES variable
and appends it to PROJECT_SOURCEFILES. This way the buildsystem will
automatically consider the newlib-syscalls object code during linking
time.
2015-12-21 08:06:14 -02:00
Michael LeMay 9b6b5ce5b0 galileo: Instruct developer to build C library prior to building Contiki
This patch enhances build_newlib.sh to create Makefile.libc so that
the main Galileo makefile can attempt to include Makefile.libc and
instruct the developer to run build_newlib.sh first if the definition
within Makefile.libc is not detected.
2015-12-21 08:06:14 -02:00
Andre Guedes 96e50ec2c4 galileo: Fix Makefile.galileo
This patch moves the compiler and linking options related to QuarkX1000
SoC to Makefile.x86_quarkX1000 since it is more suitable. For instance,
'-m32' should be used in any platform based on QuarkX1000, not only
Galileo. The same rationale applies for the others options (e.g. -march,
mtune).
2015-12-21 08:06:14 -02:00
Michael LeMay 2b5efdfbe7 galileo: Revise C compiler flags for consistency.
The CFLAGS setting used for the newlib build process includes
"-mtune=i586" as does the ASFLAGS setting used for the Contiki build
process.  However, the CFLAGS setting used for the Contiki build
process did not include that flag.  This patch adds it for
consistency.
2015-12-21 08:06:14 -02:00
Michael LeMay b79fcaa7d8 galileo: Override Ubuntu's default GCC flags to avoid link errors
Ubuntu enables GCC's stack protector by default (see
https://wiki.ubuntu.com/Security/Features).  This causes link errors
like the following:

 ...undefined reference to `__stack_chk_fail'

To avoid these errors, this patch adds the "-fno-stack-protector" flag
to both the CFLAGS used by the Contiki build process and the CFLAGS
used by the newlib build process.
2015-12-21 08:06:14 -02:00
Andre Guedes a8849b2909 x86: Move bootstrap code and linker script to cpu/x86
This is a refactoring patch, no functionality is changed. It moves
loader.S and galileo.ld from platform/galileo/ to cpu/x86/ directory
since they seem to be more SoC-specific than platform-specific.

It also renames galileo.ld to quarkX1000.ld since it can be used by
any platform based on Quark X1000 SoC, not only Galileo.

Furthermore, this patch also renames loader.S to bootstrap_quarkX1000.S
since it is pretty much a bootstrap code to any platform based on Quark
X1000 SoC.
2015-12-21 08:06:14 -02:00
Jesus Sanchez-Palencia b2fa72bb98 x86: Break Makefile.x86 into common and pc specific ones
Now the cpu/x86/ provides a Makefile.x86_common and a
Makefile.x86_pc. The former includes the common Makefile
and adds legacy pc specific implementations (currently,
drivers only) into the building context, while the latter
has everything that defines the bootstrap of a x86 CPU.

This commit also fixes platform/galileo/ so it includes the
correct makefile - Makefile.x86_quarkX1000. Galileo uses
a Quark X1000 SoC which is not an IBM Generic PC-like CPU,
but it does provide most of a PCs peripherals through
its "Legacy Bridge". Thus, it makes sense that QuarkX1000's
Makefile includes code from the legacy_pc x86 cpu.
2015-12-21 08:06:14 -02:00
Jesus Sanchez-Palencia 9d3b9cadc4 galileo: Concentrate core implementations in platform/galileo/core/
Currently, it is common to see Contiki's core/ interfaces implementations
spread in both cpu/ and platform/. We here take one step further starting
an effort to centralize all of these in platform's code instead.

This commit starts this by adding platform/galileo/core/ and its sys/
subfolder, adding a stubbed mtarch.h and moving clock and rtimer
implementations to this new folder. From now on we should concentrate
implementation from Contiki's core/ interfaces into the appropriate
subfolder in platform/galileo/core/.

Note that this is not the current fashion followed on other platforms
and cpus folders, as most of them add the core interface implementation
into its subfolder directly. For instance, on CC2538DK,
core/dev/button-sensor.h is implemented in platform/cc2538dk/dev/
directly, while on Galileo it would sit at platform/galileo/core/dev/.
We believe ours is a better approach to organize and escalate a
platform's code base.

We also remove previous x86 mtarch.h and mtarch.c since they weren't used
at all - both native and cooja platforms have their own mtarch
implementations.
2015-12-21 08:06:14 -02:00
Andre Guedes e4ff61ff6c galileo: Support for rtimer library
This patch adds support for rtimer library on Galileo's platform.

We use the PIT to implement the rtimer platform dependent
functionalities. We chose the PIT for mainly two reason: I) its
configuration is very simple II) it has a high frequency which
provides us a good clock resolution (requirement from rtimer
library).

Since we keep track of the number of ticks in software, we define
rtimer_clock_t type as uint64_t. This gives us a good amount of time
til the variable overflows. For instance, a 32-bit type would overflow
in about one hour for high clock resolution (~ 1us).

The rtimer clock frequency (RTIMER_ARCH_SECOND) is setup to 1 kHz.
There is no technical matter regarding this value. It is just an
initial guess.

Just for the record, we might want to use HPET in future to
implement the rtimer library since it seems to be more appropriate.
The reason why we don't use it at this moment is that, in order to
configure it, we need support for ACPI 2.0 which we don't. Once we
have use-cases for the rtimer library we'll probably replace PIT
by HPET or any other timer more suitable for the job.
2015-12-21 08:06:14 -02:00
Jesus Sanchez-Palencia eafcba5e7a galileo: Add support for Clock module
This patch adds support for Contiki's clock module. All functions from
core/sys/clock.h are implemented, except clock_set_seconds() and clock_
delay_usec(). The CLOCK_CONF_SECOND macro is set to 128. This value
seems to be good enough since several platforms used it. Finally, we
use the RTC driver to track the number of ticks from the system clock.
2015-12-21 08:06:14 -02:00
Jesus Sanchez-Palencia f14f9aba41 galileo: Initial support for Intel Galileo Platform
This patch adds the initial support for Intel Galileo Platform. It
contains the minimum set of code required to boot a dummy Contiki
image.

For Galileo initial support, we implemented a linker script, a minimal
bootstrap code, a set of stubbed functions required by newlib, and a
very simple main() function. Moreover, we also define some header files
and macros required by Contiki.

To build applications for this platform you should first build newlib
(in case it wasn't already built). To build newlib you can run the
following command:
$ platform/galileo/bsp/libc/build_newlib.sh

Once newlib is built, you can build applications. To build applications
for Galileo platform you should set TARGET variable to 'galileo'. For
instance, building the hello-world application should look like this:
$ cd examples/hello-world/ && make TARGET=galileo

This will generate the 'hello-world.galileo' file which is a multiboot-
compliant [1] ELF image. This image can be booted by any multiboot-
complaint bootloader such as Grub.

Finally, this patch should be used as a guideline to add the initial
support for others platforms based on x86 SoCs.

[1] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
2015-12-21 08:06:14 -02:00