Various cleanups to the x86 early serial driver, mostly with the goal
of simplifying its deployment during board bringup (which is really
the only reason it exists in the first place):
+ Configure it =y by default. While there are surely constrained
environments that will want to disable it, this is a TINY driver,
and it serves a very important role for niche tasks. It should be
built always to make sure it works everywhere.
+ Decouple from devicetree as much as possible. This code HAS to work
during board bringup, often with configurations cribbed from other
machines, before proper configuration gets written. Experimentally,
devicetree errors tend to be easy to make, and without a working
console impossible to diagnose. Specify the device via integer
constants in soc.h (in the case of IOPORT access, we already had
such a symbol) so that the path from what the developer intends to
what the code executes is as short and obvious as possible.
Unfortunately I'm not allowed to remove devicetree entirely here,
but at least a developer adding a new platform will be able to
override it in an obvious way instead of banging blindly on the
other side of a DTS compiler.
+ Don't try to probe the PCI device by ID to "verify". While this
sounds like a good idea, in practice it's just an extra thing to get
wrong. If we bail on our early console because someone (yes, that's
me) got the bus/device/function right but typoed the VID/DID
numbers, we're doing no one any favors.
+ Remove the word-sized-I/O feature. This is a x86 driver for a PCI
device. No known PC hardware requires that UART register access be
done in dword units (in fact doing so would be a violation of the
PCI specifciation as I understand it). It looks to have been cut
and pasted from the ns16550 driver, remove.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
PCI devices on 64 bit systems can be mapped anywhere, not just in the
lower 4G of memory. Remove pointer size assumptions.
Also this removes the use of a struct uart_device_config to store the
(runtime) BAR address. That struct has other stuff in it, and the
only thing we need is the single MMIO address. It's also REALLY
confusing to have two "devconf" fields in the device storing values of
the same struct type, some fields of which are used from one of them
but some from the other!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The PCI API was originally limited to 32 bit addresses. Even though
it had code to skip over the high word in 64 bit BAR entries, it
refused to use it and returned a 32 bit value. Some devices in the
wild have default mappings from the firmware for devices above 4G.
Also remove the "iobar" API. It's dead code, we don't call it and we
don't test it. IO space BAR entries are a legacy feature from way,
way back in PCI history (I genuinely have never heard of a real device
that uses them!). And there's no difference in format between one of
these and a 32 bit "memory" BAR anyway, someone who actually had this
requirement could just use the existing API without worry.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The mm_reg_t type used to represent a MMIO address (e.g. in the
sys_write*() APIs) was defined to a uint32_t, which is obviously wrong
on 64 bit systems where devices can be mapped anywhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The default page table (the architecturally required one used for
entrance to long mode, before the OS page tables get assembled) was
mapping the first 4G of memory.
Extend this to 512G by fully populating the second level page table.
We have devices now (up_squared) which have real RAM mapped above 4G.
There's really no good reason not to do this, the page is present
always anyway.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When checking the absolute value of cycles set to the comparator
use the MAX_CYCLES instead of MAX_TICKS.
The commit changes function names and comments to make it clear
where ticks (system ticks) and where RTC cycles are used.
Fixes#26701
Signed-off-by: Pawel Dunaj <pawel.dunaj@nordicsemi.no>
Several peripherals are non-functional in the ENG_A revision
of nRF5340 (Application MCU) so we delete the corresponding
DTS nodes in the device description.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When building for nRF5340 Application MCU we need to properly
select which are the default GPIO port/pins for UARTE on the
Network MCU (so we allocate them to Network MCU). These depend
on the actual version of the board we are using (PDK or DK) so
this commit implements the corresponding conditional logic.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When building for nRF5340 PDK board, enable Kconfig option
for Erratum 19. Do not enable when building on nRF5340 DK.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We rename the nRF5340 board directory to
nrf5340dk_nrf5340 since this will be now
containing board definitions for both the
nRF5340 PDK and DK.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Refactor the common Kconfig and build files of nRF5340
board definition to enable building for either nRF5340
PDK or DK.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We do not need to have the nrf5340pdk_ prefix in the
partition configuration and sram planning files for
nrf5340 platforms because these files may be common
for any nrf5340 board variant. Also, we do not need
it in the common .dts header for the Application MCU.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Rename the nRF5340 QKAA variant .dtsi headers (Application
MCU) by adding an Engineering A (Eng A) suffix. This is done
to indicate that the headers should be explicitly used when
building for a board that contains the Engineeering A nrf5340
SoC variant.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We need to use CPUAPP and CPUNET instead of CPU0 and CPU1
terminology, because those terms are the ones used
throughout the DeviceTree definitions for nRF5340 SoC.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Move the definition of the number of MPU regions
(num-mpu-regions) in a SoC variant-specific header
instead of the common .dtsi for nRF5340 Application
MCU. This allows us to define different SoC variants
with different number of MPU regions available.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit renames the nrf5340_cpuapp_common.dtsi header
to nrf5340_cpuapp_peripherals.dtsi. This name is more
appropriate, as the header contains DT definitions for
peripherals, accessible from either Secure or Non-secure
execution environment (i.e. not accessible exclusively
by Secure or Non-Secure).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We do not need to list the SoC compatibles in the
PDK node definition, this was accidentally left out.
Removing it in this commit.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Reverse the order of these checks because invalid PDU type will
never be expected. If PDU type is invalid we should respond with
error 0x0002 - Invalid format.
Signed-off-by: Michał Narajowski <michal.narajowski@codecoup.pl>
Since Python 2 is already EOL, Linux distributions are starting
to drop support for Python 2. For example, on Ubuntu 20.04,
"python" is no longer available. This breaks the bootstrap
and autogen.sh as they are both default to executing "python".
Fix this by setting the PYTHON environment variable before
building so both scripts will use python3 instead.
Also update git checkout to grab the official 2.04 release.
Fixes#25398
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Security documentation contains a code guideline section that is more
about security principles than code guidelines itself. Just removing
the mention do code guideline to avoid possible confusions with
upcoming project code guideline based on MISRA-C.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Configuration file was left unchanged after development
of USB Audio class. Deleted configs should never be present.
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
Recent changes to struct _timeout changed the declaration order to
avoid alignment padding. While this has no effect to C99 code C++
requires that designated initializes appear in declaration order.
Update the initializer macro so it can be used in C++ code.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Deal with qemu crashes and do not register pass status as the default.
In case we do not have a status, report unknown.
This now captures different states from qemu that were not captured
before.
Fixes#26679
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
With native_posix, a flash.bin file is created when running the tests.
If the tests are re-run, they fail since the flash is no-longer erased.
Before running the tests, erase the flash so that the 'read' test can
work regardless of the previous state.
Fixes: 25171
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple test for this command to check that the output is as
expected.
This requires a larger output buffer in shell_dummy, so update that
too.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is annoying to read just a single word at a time. Update this
command to print any amount of data. This uses byte format at present.
We could perhaps support something like:
flash read.8
flash read.16
flash read.32
to chose the size.
Example output (with line breaks to keep within git-style limit):
$ flash read FLASH_CTRL 0 20
00000000: 20 25 00 20 1d 26 00 08 69 68 00 08 45 26 00 08
| %. .&.. ih..E&..|
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|........ ........|
Signed-off-by: Simon Glass <sjg@chromium.org>
Recent ST boards embed the new ST-Link probe V3.
It is advertised as "STLINK-V3", update sanitylmib to take it
into account.
In handle function, it is proposed to treat it separately as current
"STM32 STLink" as processing might differ in next future (hla_serial
deprecation).
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
This driver blocks on a semaphore to receive notification when an
operation is complete, so requires CONFIG_MULTITHREADING=y.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
There is following error when compiling applications using http_client:
/zephyr/include/net/http_client.h:157:24: error: field 'work' has \
incomplete type
157 | struct k_delayed_work work;
| ^~~~
/zephyr/include/net/http_client.h:177:2: error: unknown type name \
'k_timeout_t'
177 | k_timeout_t timeout;
| ^~~~~~~~~~~
Fix that by adding missing kernel.h include statement in http_client.h.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Extends the github labeling action to automatically add the nxp label to
nxp-related boards, drivers, and socs.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
This test was written to assume that the only IPI handled would be the
one generated by the test, but the scheduler also generates an IPI any
time a thread becomes runnable, and there's no way to lock that out in
an SMP system where the other CPU is going to be doing its own thing
(we can't use "1cpu" because that locks interrupts on the other CPU
and obviously this is a test of an interrupt).
Change the logic to detect that "at least one IPI was received", which
is fine for coverage. Really a better place for a test like this
would have been tests/kernel/mp, which is a test of the lower level
APIs and runs the other CPU deterministically (i.e. not under the
control of the Zephyr scheduler).
Also some misc fixes:
* Don't busy wait at the start, that's needless.
* Sleep instead of busywaiting after sending the IPI, spinning isn't
needed here and acts to increase CI load needlessly.
* Declare the cross thread signal variable volatile for correctness
(though this error seems to have been benign in practice).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A last minute "cleanup" to the EFI startup path (on a system where I
had SMP disabled) moved the load of the x86_cpuboot[0] entry into RBP
into the main startup code, which is wrong because on auxiliary CPUs
that's already set up by the 16/32 bit entry code to point to the
OTHER entries.
Put it back where it belongs.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
* The stack pointer (SP) register points to the lowest-used address of
a downward-growing stack, so memory address [sp] is used, we can't
modify it.
* In firq_no_switch case, we need to pop sp, which pushed before
_isr_demux function in firq_nest function.
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
nsim is slow, if the MEMSZ is too targe, the test will
run a long time and make sanitycheck timeout.
There are two possible fixes to pass the sanitycheck test
* filter out nsim, not to block the sanitcheck test
* use a small MEMSZ for nsim to reduce the execution time.
Considering there are potential improvements for nsim (because
some qemu targets can pass), we use the 1st fix to pass the
sanitycheck temporarily.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Since commit 5963ebaf33
("drivers: spi: CS configuration through devicetree")
the SPI GPIO CS flags are obtained from DT,
but the patch series has missed the necessary changes
in the device trees for displays and link_board_eth.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Since commit 5963ebaf33
("drivers: spi: CS configuration through devicetree")
the SPI GPIO CS flags are obtained from DT,
but the patch series has missed the necessary changes
for the ieee802154_dw1000 driver and decawave_dwm1001_dev board.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Add and mark PCIe highmem outbound memory as nGnRnE device memory
in Viper SoC MMU configuration.
Increase VA/PA bits to 36-bits to support the same.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
K_FOREVER/INT_MAX number of ticks needs delay cycles value of
maximum order and exceeds 'int32' range.
The typecast to 'int32' results in wrongly evaluating the value
as less than 'MIN_DELAY' and chooses 'MIN_DELAY' over the actual
delay cycles.
Cap the 'MAX_TICKS' to INT32_MAX.
fixes: #26632
Signed-off-by: Sandeep Tripathy <sandeep.tripathy@broadcom.com>
Due to a long standing difference of requirements enabling deep sleep
will by default cause any application that delays for an unbounded
period to power down. On Nordic doing so turns the system off. Show
how to prevent this from happening while still allowing deep sleep
states to be available for the application's controlled use.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Make sure to retry at least once after the timeout elapses. Sample the
current time before starting the i2c transaction, and only give up if
the polling occurred after the timeout.
The timeout exists to allow the eeprom time to complete a write, during
which time it will nack transactions (at24) or the status register will
report busy (at25). If a transaction fails legitimately, but the 1ms
sleep overshoots the timeout expiration, we will not try again, which
fails to give the part the full grace period before declaring failure.
This is likely to happen in the last 1ms interval but also possible if
the eeprom thread is preempted. It is possible to only try once and give
up if the sleep lasts longer than the timeout, which fails to give the
part an adequate period to complete the write.
Waiting until the current time is after (not equal to) the timeout is
also important because we don't want to round up partial milliseconds if
the start time was sampled near the end of a millisecond boundary. The
timeouts of eeproms can be ~5ms.
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
