This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Supports both master and slave mode, standard and fast modes,
configurable timeouts, and a few other tunable settings.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The ESP-WROOM-32 board exits the bootloader at 40 MHz, not 160 MHz as
suggested by documentation. The CCOUNT special register works as
advertised, but not at the expected rate. This was verified by
timestamping (at the host) the output of a dependency-free loop that
looks like:
int key = irq_lock();
while(1) {
u32_t i, count;
volatile int dummy;
for(i = 0; i < 5000000; i++) {
dummy++;
}
__asm__ volatile ("rsr.ccount %0" : "=a"(count));
printk("%d\n", count);
}
The SoC has a fairly robust set of possible CPU clocking modes, but we
don't have a driver for that yet. Until we do, set the single
configured CPU frequency to the one we get at runtime.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The Xtensa port was the only one remaining to be converted to the new
way of connecting interrupts in Zephyr. Some things are still
unconverted, mainly the exception table, and this will be performed
another time.
Of note: _irq_priority_set() isn't called on _ARCH_IRQ_CONNECT(), since
IRQs can't change priority on Xtensa: while the architecture has the
concept of interrupt priority levels, each line has a fixed level and
can't be changed.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The random number generator from ESP32 uses noise from Wi-Fi and
Bluetooth radios. If these are off, a pseudo-random number is
generated instead; this is currently the case, but even though it's a
black box, it's arguably better than returning a timestamp as a
pseudo-random number generator.
According to the ESP32 Technical Reference manual, the RNG passed the
Dieharder Random Number Test suite (version 3.31.1)[1], but nothing has
been said about the quality of the PRNG.
The RNG register is read directly; no effort is made to use its
contents to feed an entropy pool in a way that's similar to /dev/random
on POSIX systems, as no such subsystem exists on Zephyr at the moment.
[1] http://webhome.phy.duke.edu/~rgb/General/dieharder.php
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This provides basic GPIO support, with interrupts, and the ability to
read and write to ports on a pin-by-pin basis.
Jira: ZEP-2286
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This implements a driver for the pin multiplexer as present in the ESP32
SoCs.
All APIs are supported.
Jira: ZEP-2297
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The first stage bootloader, part of the ESP32 ROM, already sets up
a stack that's sufficient to execute C programs. So, instead of
implementing __stack() in assembly, do it in C to simplify things
slightly.
This ESP32-specific initialization will perform the following:
- Disable the watchdog timer that's enabled by the bootloader
- Move exception handlers to IRAM
- Disable normal interrupts
- Disable the second CPU
- Zero out the BSS segment
Things that might be performed in the future include setting up the
CPU frequency, memory protection regions, and enabling the flash
cache.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This is a minimal driver enabling console output during the port
bringup. While the driver works, only one of the three UART devices
are supported, and there isn't any way to change any parameters or
use interrupts. This will most likely be superceded by a proper
driver after the port has matured.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
