Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
the linux tree:
$ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
0
$ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
633
In u-boot device trees both prefixes are used. Until recently the only
user of the ethernet alias was the sandbox test device tree. This
changed with commit fc054d563b ("net: Introduce DSA class for Ethernet
switches"). There, the MAC addresses are inherited based on the devices
sequence IDs which is in turn given by the device tree.
Before there are more users in u-boot and both worlds will differ even
more, rename the alias prefix to "ethernet" to match the linux ones.
Also adapt the test cases and rename any old aliases in the u-boot
device trees.
Cc: David Wu <david.wu@rock-chips.com>
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Check that a variable defined in /config/environment is found in the
run-time environment, and that clearing fdt_env_path from within that
node works.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
[trini: Conditionalize the test being linked in]
Signed-off-by: Tom Rini <trini@konsulko.com>
With this extended test, we get the following failure :
=> ut dm reset_base
Test: dm_test_reset_base: reset.c
test/dm/reset.c:52, dm_test_reset_base(): reset_method3.id == reset_method3_1.id: Expected 0x14 (20), got 0x2 (2)
Test: dm_test_reset_base: reset.c (flat tree)
test/dm/reset.c:52, dm_test_reset_base(): reset_method3.id == reset_method3_1.id: Expected 0x14 (20), got 0x2 (2)
Failures: 2
A fix is needed in reset_get_by_index_nodev() when introduced in [1].
[1] ea9dc35aab ("reset: Get the RESET by index without device")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This adds a test case to test the new ofnode_phy_is_fixed_link() API.
Both the new and old DT bindings are covered.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The DSA sandbox driver is used for unit testing the DSA class code.
It implements a simple 2 port switch plus 1 CPU port, and uses a
very simple tag to identify the ports.
The DSA sandbox device is connected via CPU port to a regular Ethernet
sandbox device, called 'dsa-test-eth, managed by the existing eth
sandbox driver. The 'dsa-test-eth' is not intended for testing the
eth class code however, but it is used to emulate traffic through the
'lan0' and 'lan1' front pannel switch ports. To achieve this the dsa
sandbox driver registers a tx handler for the 'dsa-test-eth' device.
The switch ports, labeled as 'lan0' and 'lan1', are also registered
as eth devices by the dsa class code this time. So pinging through
these switch ports is as easy as:
=> setenv ethact lan0
=> ping 1.2.3.5
Unit tests for the dsa class code were also added. The 'dsa_probe'
test exercises most API functions from dsa.h. The 'dsa' unit test
simply exercises ARP/ICMP traffic through the two switch ports,
including tag injection and extraction, with the help of the dsa
sandbox driver.
I took care to minimize the impact on the existing eth unit tests,
though some adjustments needed to be made with the addition of
extra eth interfaces used by the dsa unit tests. The additional eth
interfaces also require MAC addresses, these have been added to the
sandbox default environment.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20210216224804.3355044-5-olteanv@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Implement sandbox regulator devices for SCMI voltage domains
and test them in DM scmi tests.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The test adds two pinmux nodes to the device tree, one to test when a
register changes only one pin's mux (pinctrl-single,pins), and the other
to test when more than one pin's mux is changed (pinctrl-single,bits).
This required replacing the controller's register access functions when
the driver is used on sandbox.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some of these do not follow the rules. Make sure the driver name matches
the compatible string in all cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently keyboard input fails in the GUI window opened by
./u-boot -T -l
Add the missing include to test.dts.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add test to validate dev->dma_offset is properly set on devices.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Introduce some new nodes in sandbox's test device-tree and dm tests in
order to validate dev_get_dma_range().
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Add adc-keys device to the sandbox/test.dts and connect it to the channel
#3 of the sandbox_adc driver. The default values sampled by sandbox_adc
driver determines that button3 and button4 are released and button5 is
pressed.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
At present this function uses the old format for reading hashes. Add
support for the current format.
Add a test while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The patch adds a function to get display timings from the device tree
node attached to the device.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Simon Glass <sjg@chromium.org>
The __of_translate_address routine translates an address from the
device tree into a CPU physical address. A note in the description of
the routine explains that the crossing of any level with
since inherited from IBM. This does not happen for Texas Instruments, or
at least for the beaglebone device tree. Without this patch, in fact,
the translation into physical addresses of the registers contained in the
am33xx-clocks.dtsi nodes would not be possible. They all have a parent
with #size-cells = <0>.
The CONFIG_OF_TRANSLATE_ZERO_SIZE_CELLS symbol makes translation
possible even in the case of crossing levels with #size-cells = <0>.
The patch acts conservatively on address translation, except for
removing a check within the of_translate_one function in the
drivers/core/of_addr.c file:
+
ranges = of_get_property(parent, rprop, &rlen);
- if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
- debug("no ranges; cannot translate\n");
- return 1;
- }
if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 4);
debug("empty ranges; 1:1 translation\n");
There are two reasons:
1 The function of_empty_ranges_quirk always returns false, invalidating
the following if statement in case of null ranges. Therefore one of
the two checks is useless.
2 The implementation of the of_translate_one function found in the
common/fdt_support.c file has removed this check while keeping the one
about the 1:1 translation.
The patch adds a test and modifies a check for the correctness of an
address in the case of enabling translation also for zero size cells.
The added test checks translations of addresses generated by nodes of
a device tree similar to those you can find in the files am33xx.dtsi
and am33xx-clocks.dtsi for which the patch was created.
The patch was also tested on a beaglebone black board. The addresses
generated for the registers of the loaded drivers are those specified
by the AM335x reference manual.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Tested-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Simon Glass <sjg@chromium.org>
Place a second spi slave on the sandbox_spi bus, to be used by the
spi_claim_bus() testcase we are about to introduce. We need to make sure
that jumping between slaves calling spi_claim_bus() sets the bus speed and
mode appropriately. Use different max-hz and mode properties for this new
slave.
Also, update sandbox_spi cs_info call to allow activity on CS0/CS1 and
adapt dm_test_spi_find() testcase for this new setup.
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Check that this flag operates as expected. This patch is not earlier in
this series since is uses the new behaviour of dev_seq().
Signed-off-by: Simon Glass <sjg@chromium.org>
This uclass is intended to provide a way to obtain information about a
U-Boot board. But the concept of a U-Boot 'board' is the whole system,
not just one circuit board, meaning that 'board' is something of a
misnomer for this uclass.
In addition, the name 'board' is a bit overused in U-Boot and we want to
use the same uclass to provide SMBIOS information.
The obvious name is 'system' but that is so vague as to be meaningless.
Use 'sysinfo' instead, since this uclass is aimed at providing information
on the system.
Rename everything accordingly.
Note: Due to the patch delta caused by the symbol renames, this patch
shows some renamed files as being deleted in one place and created in
another.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Provide tests to check the behavior of the multiplexer framework.
Two sets of tests are added. One is using an emulated multiplexer driver
that can be used to test basic functionality like select, deselect, etc.
The other is using the mmio mux which adds tests specific to it.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Using different strings for the device tree node labels and the label
property of buttons sharpens the button label unit test.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
This modifies the existing led test to check for default led naming as
added in the previous patch.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This extends the pinctrl-sandbox driver to support pin muxing, and adds a
test for that behaviour. The test is done in C and not python (like the
existing tests for the pinctrl uclass) because it needs to call
pinctrl_select_state. Another option could be to add a command that
invokes pinctrl_select_state and then test everything in
test/py/tests/test_pinmux.py.
The pinctrl-sandbox driver now mimics the way that many pinmux devices
work. There are two groups of pins which are muxed together, as well as
four pins which are muxed individually. I have tried to test all normal
paths. However, very few error cases are explicitly checked for.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add tests for SCMI reset controllers. A test device driver
sandbox-scmi_devices.c is used to get reset resources, allowing further
resets manipulation.
Change sandbox-smci_agent to emulate 1 reset controller exposed through
an agent. Add DM test scmi_resets to test this reset controller.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c
is used to get clock resources, allowing further clock manipulation.
Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents.
Add DM test scmi_clocks to test these 3 clocks.
Update DM test sandbox_scmi_agent with load/remove test sequences
factorized by {load|remove}_sandbox_scmi_test_devices() helper functions.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This change introduces SCMI agent uclass to interact with a firmware
using the SCMI protocols [1].
SCMI agent uclass currently supports a single method to request
processing of the SCMI message by an identified server. A SCMI message
is made of a byte payload associated to a protocol ID and a message ID,
all defined by the SCMI specification [1]. On return from process_msg()
method, the caller gets the service response.
SCMI agent uclass defines a post bind generic sequence for all devices.
The sequence binds all the SCMI protocols listed in the FDT for that
SCMI agent device. Currently none, but later change will introduce
protocols.
This change implements a simple sandbox device for the SCMI agent uclass.
The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages.
To prepare for further test support, the sandbox exposes a architecture
function for test application to read the sandbox emulated devices state.
Currently supports 2 SCMI agents, identified by an ID in the FDT device
name. The simplistic DM test does nothing yet.
SCMI agent uclass is designed for platforms that embed a SCMI server in
a firmware hosted somewhere, for example in a companion co-processor or
in the secure world of the executing processor. SCMI protocols allow an
SCMI agent to discover and access external resources as clock, reset
controllers and more. SCMI agent and server communicate following the
SCMI specification [1]. This SCMI agent implementation complies with
the DT bindings defined in the Linux kernel source tree regarding
SCMI agent description since v5.8.
Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The tests rely on a dummy driver to allocate and initialize the regmaps
and the regmap fields using the managed API. The first test checks if
the regmap config fields like width, reg_offset_shift, range specifiers,
etc work. The second test checks if regmap fields behave properly (mask
and shift are ok) by peeking into the regmap.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a test to verify that GPIOs can be acquired/released using the managed
API. Also check that the GPIOs are released when the consumer device is
removed.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
To test this function, sandbox CPU must set cpu_platdata.timebase_freq on
bind. It also needs to expose a method to set the current cpu. I also make
some most members of cpu_sandbox_ops static.
On the timer side, the device tree property
sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe
falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable PCI memory regions in ranges property to be of multiple entry.
This helps to add support for SoC's like OcteonTX/TX2 where every
peripheral is on PCI bus.
Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Usage of lists_bind_fdt() in bind command imposes to add
a compatible string for bind-test node.
Others impacts are:
- bind-test node is binded at sandbox start, so no need to bind it
in test_bind_unbind_with_node() test.
- As explained just above, after sandbox start, now a phy exist.
In test/dm/phy.c, it was verified that a third phy didn't exist,
now we must verified that a fourth phy doesn't exist.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Remove adhoc dt binding for fixed-partition definition for i2c eeprom.
fixed-partition are using reg property instead of offset/size pair.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 9ba84329dc ("sandbox, test: add test for GPIO_HOG
function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts.
But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0
and 1. As hog always request his gpios, the led command on both
led is broken:
=> led sandbox:red
LED 'sandbox:red' not found (err=-16)
The gpio is already requested by hog, so it can't be enabled
for led 'sandbox:red'.
This commit change the gpio used by hog to 10, 11, 12 and 13,
so the led command could be used again with 'sandbox:red' and
'sandbox:green'.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add a sandbox SOC driver, and some tests for the SOC uclass.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add a sandbox SOC driver, and some tests for the SOC uclass.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
For many device types it is possible to figure out the name just by
looking at its uclass or parent. Add a function to handle this, since it
allows us to cover the vast majority of cases automatically.
However it is sometimes impossible to figure out an ACPI name for a device
just by looking at its uclass. For example a touch device may have a
vendor-specific name. Add a new "acpi,name" property to allow a custom
name to be created.
With this new feature we can drop the get_name() methods in the sandbox
I2C and SPI drivers. They were only added for testing purposes. Update the
tests to use the new values.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some devices need to inject extra code into the Differentiated System
Descriptor Table (DSDT). Add a method to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: correct one typo in inject_dsdt() comments]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Add a /chosen property to control the order in which the data appears
in the SSDT. This allows matching up U-Boot's output from a dump of the
known-good data obtained from within Linux.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some devices need to generate code for the Secondary System Descriptor
Table (SSDT). Add a method to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some drivers in Linux support both device tree and ACPI. U-Boot itself
uses Linux device-tree bindings for its own configuration but does not use
ACPI.
It is convenient to copy these values over to the ACPI DP table for
passing to linux. Add some convenience functions to help with this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a function to build up the ACPI path for a device and another for its
scope.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
currently gpio hog function is not tested with "ut dm gpio"
so add some basic tests for gpio hog functionality.
For this enable GPIO_HOG in sandbox_defconfig, add
in DTS some gpio hog entries, and add testcase in
"ut dm gpio" command.
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Michael Walle