| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 56ca2c197e71 ("mci: sdhci: Get rid of many register ops")
the core checks whether there is an explicit write function for the
host. If the struct is not zero initialized, a bogus value is taken as
the function, resulting in an unbootable board. Zero initialize the
structs properly to let the PBL correctly load images. Fixes booting on
the i.MX8M* board, tested on i.MX8MP EVK.
Fixes: 56ca2c197e71 ("mci: sdhci: Get rid of many register ops")
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210805082607.1698733-1-r.czerwinski@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With deep probe, drivers referencing nvmem-cells should make sure their
providing nvmem device is already probed. The nvmem cell already takes
care to find out the device node providing the cell. The real provider
that should be probed is then either:
- If the node is in a nvmem-cells partition, the provider is the
parent node (skipping a possible fixed-partitions node in-between)
- Otherwise, the provider is the parent node of the cell
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210628064517.28636-6-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The device tree nodes for both barebox environment and state can have
phandles that reference partitions. Environment runs at late_initcall
level, so deep probe will have populated the device by the time the
probe is called. barebox-state however is probed at device_initcall
level and thus must take care itself to ensure the partition provider is
probed. Add a new of_partition_ensure_probed that does this. It can
handle both legacy and new style (fixed) partitions.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210628064517.28636-4-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The pmu fw manages the permissions who can enable/disable the clocks.
There are a few clocks (TOPSW_LSBUS and LSBUS) which are exposed to
Barebox and Barebox assumes that is has to enable the clocks. However,
the pmu fw considers the clocks under its control and returns a
permission denied for the clock enable request.
Assume that clocks that are already enabled don't need to be enable by
Barebox to avoid the permission denied errors.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Link: https://lore.barebox.org/20210624150054.1205422-3-m.tretter@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When bthread were first merged, they could be scheduled in any context
and bthread_stop could just keep rescheduling until the bthread in
question exits after which it would return the exit code.
Now that bthreads are only scheduled in command context, bthread_stop
also can only be scheduled in command context, making it much less
useful and easier to shoot yourself in the foot with.
Avoid this by introducing a bthread_cancel function instead that will
asynchronously terminate the thread. For most purposes that should be
fine, because bthread_stop is used to synchronize cleanup and we can
move the cleanup into the thread instead.
The only exception is the bthread command, which relies on being able to
wait on bthreads to complete. For these __bthread_stop remains available,
but should not be used in new code.
This fixes a hang that is encountered when the usb mass storage gadget
unbind is called from a poller leading barebox to wait indefinitely.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210628070732.16812-2-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Follow-up commit will replace blocking bthread_stop with non-blocking
bthread_cancel. Prepare for this by dropping exit codes. This is not
much of a loss, because most users of bthreads will only call
bthread_stop at cleanup time. bthread command is an exception, so have
it take manual care of passing around exit codes.
As we touch the bthread_stop prototype anyway, rename it to
__bthread_stop. This will make it clearer in the future, that it's not
meant for driver use.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210628070732.16812-1-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This driver is based on the f_mass_storage drivers in Linux v5.11 and
U-Boot v2021.01.
Unlike the U-Boot version, it runs asynchronously without blocking the
bootloader from doing other tasks, like exporting other USB gadgets at
the same time or enabling shell access.
With pollers and workqueues, enabling this would need a large rework
of the code to be completely callback based, whenever the original
Linux code sleeps waiting for events. With the new bthread support,
we can actually sleep and handover control to other bthreads until
there is actual work to do.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210622082617.18011-9-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With the upcoming move of bthreads to be scheduled only in command
context, long running tasks (i.e. bareDOOM) may no longer process
VirtIO input in a timely manner. Move the input polling into a poller,
so input can once again be processed between frames.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210622082617.18011-2-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
buffer_dma is not really used unitialized, but the compiler doesn't
realize this. Initialize it explicitly.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210617142545.7375-1-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead of printing a "Using index %d for the new disk" without any
context, use dev_info() to print the device context and also "disk%d"
which is the name of the new device.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210617141452.3117-1-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit adds support for the Successive Approximation Register (SAR)
ADCs that can be found in Rockchip SoCs, such as the RK3568.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Link: https://lore.barebox.org/20210624160915.21897-2-michael.riesch@wolfvision.net
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The gpio device nodes are subnodes of the pinctrl device node, so we can
register a regular driver for it. With this deep-probe support finds a
driver for the gpio device nodes and of_device_ensure_probed() can
correctly work on the gpio nodes.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210625140524.1584-1-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
On both ARM and ARM64 we map DMA coherent memory the same as IO memory.
This has the effect that unaligned accesses are not possible on DMA
coherent memory. The dwc3 gadget driver uses memset() and memcpy() on
that memory which may generate unaligned accesses and result in data
aborts. Use memcpy_fromio() and memset_io() instead which are desgined
to work on IO space and thus do not generate unaligned accesses.
The alternative would be to map DMA coherent memory as MT_NORMAL_NC
instead of MT_DEVICE_nGnRnE, but that require us to add memory
barriers to drivers which we currently do not have. SO instead of
risking regressions in drivers we take the easy way out and avoid
unaligned accesses in the dwc3 driver.
In this concrete case the dwc3 driver generated unaligned accesses
on a Rockchip RK3568 ARM64 system. The driver copies data out of the
receive queue. In my case first 4 bytes were copied, both source and
target were aligned. The second access then copied more data beginning
at the place where the first memcpy stopped. On this 4byte aligned
address memcpy generated an 8byte read access which resulted in a data
abort. On an ARM32 system this might not be a problem as that place,
while not 8byte aligned, is still 4byte aligned, enough for a 32bit
system.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210622074545.17059-1-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds driver for the PCIe/USB3.0/SATA phy found on Rockchip RK3568
SoCs. The driver has been taken from the Rockchip downstream Kernel
repository.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210622064711.14058-3-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds a driver for the Rockchip usb2phy. The driver has been taken
from U-Boot which has the same codebase as the Kernel driver, but is
easier to port over. Some features like clk provider support have been
added from the kernel then.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210622064711.14058-2-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The generic ehci binding also describes clocks and a phy. Add support
for these properties to the driver.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210622064711.14058-1-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Register softrst handler to allow resetting the board.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This initializes the rk3568 clocks in the way U-Boot initializes them as
well.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210615141641.31577-3-s.hauer@pengutronix.de
Link: https://lore.barebox.org/20210621092802.27275-3-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At some places a clk name may be known without having a struct clk *
directly. Add some convenience functions to handle this situation and
use them in the clk commands.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.barebox.org/20210615141641.31577-2-s.hauer@pengutronix.de
Link: https://lore.barebox.org/20210621092802.27275-2-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There will likely not be a use case for having neural network
accelerator driver support within barebox. Still the driver requires a
reset sequence, which is not yet supported by vendor kernel's or known
forks. Until Linux can take care of this itself, add a simple driver
that gets some of the peripherals out of reset.
There also enables unconditionally some of the clocks that the vendor
kernel may depend on. Hopefully, in future, the whole driver can be
dropped when the kernel starts to do clock and reset control itself.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-29-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This imports support for the StarFive GPIO controller from the vendor's
kernel tree.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-28-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some StarFive peripherals have 5 resets that need to be triggered in
order. Add a helper to simplify this. The Linux way of doing this would
be to import the reset_control_array API, but device_reset_all as
implemented here saves us from this boilerplate.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-27-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Straight port from the vendor kernel with the difference that we
take the device out of reset. This allows to load older kernels that
don't yet do reset and clock handling.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-26-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-25-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The StarFive SoC has a single reset controller, which seems to control
reset of all clocks and peripherals. It differs from the ones supported
by the Linux reset-simple driver in that it has a dedicated status
registers that needs to be polled to verify the reset has completed.
Also special is that most resets (> 70) are synchronous. As the reset
status poll would just time out without the clock, have the reset
controller enable the clock as part of the reset. OS can decide later,
which clocks to disable again.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-24-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
All clocks seem to share a common format:
struct starfive_clk {
u32 divisor : 24; /* LSB */
u32 mux : 6;
u32 invert : 1;
u32 enable : 1; /* MSB */
};
There is no documentation, what the acceptable divisor values are, but
we could already register gates and muxes, do so for now until
documentation is available.
The bulk of this code has been machine-generated by parsing the macros
in the vendor U-Boot <asm/arch-vic7100/clkgen_ctrl_macro.h>.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-23-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Linux driver in v5.13 doesn't determine min and max frequency from
clk_ciu, instead it consults the clock-frequency property in the device
tree. We will want to follow the Linux way for the StarFive, especially
because clk_get_rate returns bogus results for the JH7100, because the
clock tree doesn't yet describe enough information to calculate rates.
Add a compatible that does the necessary things as well as a generic
snps,dw-mshc compatible, like what the vendor device tree uses. The hope
is, that with complete clock tree described, we can drop the
starfive,jh7100-dw-mshc compatible check in future and use the generic
compatible instead.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-22-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The bindings describe a reset line for the MMC controller and we have
boards with device tree that contain a reset line that barebox has so
far never acted upon. For the StarFive, we need the reset, so have the
driver toggle it optionally if specified. This change wasn't tested
on existing users of the driver, like the SoCFPGA or the Rockchip
rk2928 and rk3288.
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-21-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The MCI core uses a common bounce buffer for unaligned block
reads/writes as well as sd_change_freq. This buffer is allocated at
device initcall level, same as the MMC drivers themselves.
For CONFIG_MCI_STARTUP=y configurations this seems to imply that
sd_change_freq could attempt writing the NULL page. Avoid this
by just allocating the buffer when the first MMC device is registered.
This doesn't solve all issues; so add a comment noting that.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-19-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Doesn't yet make a difference, but in a future commit, RISC-V will use a
64-bit alignment for the sector buffers by defining a custom dma_alloc.
Prepare for this.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-18-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Designware MAC on the StarFive jh7100 needs some special speed
configuration. Match against a new starfive,stmmac compatible that
describes that.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-17-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
drivers/net/designware.c handles the older Designware < 4.x MAC IPs,
which do not support DMA beyond 32-bit. They are still being integrated
into SoCs with 64-bit CPUs like the StarFive JH7100, which additionally
needs a non 1:1 mapping for coherent DMA.
Fix the driver to support such usage. The driver still has the assumption
that barebox core will only pass it 32-bit pointers. This is now made
explicit by returning error codes when the DMA mask is violated.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-16-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previous boot stages may not enable all cache ways, e.g. because they
are running from L2 cache. By the time barebox proper is running,
execution should be from main SDRAM, so it's ok now to enable the
maximum available count of cache ways.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-15-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The preproduction JH7100 used in the BeagleV beta does not ensure cache
coherence between CPU and some DMA masters like the Ethernet MAC.
Fix this for streaming DMA mappings by implementing cache cleaning and
discarding. The Flush64 primitive can be used for both as it will
invalidate after flushing and not write-back clean lines.
Coherent DMA mapping will be implemented using allocation from uncached
SRAM in a follow-up commit.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-14-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
SiFive SoCs are cache coherent with respect to other DMA masters,
so there is no need to explicitly flush cache lines.
Incoming StarFive SoC uses SiFive CPU and L2 cache controller,
but is cache-incoherent and thus needs the maintenance for DMA.
Add a basic driver that exports the cache flush function for
SoC-specific drivers to use.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-13-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The OTP holds the ethernet MAC address. Add a driver, so barebox can
read it out.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-9-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We can't currently mix S-Mode and M-Mode images in the same build
and there's no straight-forward way to determine which mode we are in.
Move the decision on which mode barebox is targeted at out of Kconfig
and into the PBL. PBL code can call either barebox_riscv_supervisor_entry
or barebox_riscv_machine_entry to signal to barebox proper which mode
it's running in. Currently the only user of this information is the
RISC-V timer clocksource driver.
Any new code that does IS_ENABLED(CONFIG_RISCV_SBI) or
IS_ENABLED(CONFIG_RISCV_M_MODE) should also be adapted to use riscv_mode().
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-4-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There's always some clocksource driver loaded, so reporting it probed
successfully doesn't add much value. timebase-frequency can be read
from the device tree if needed and which drivers were probed successfully
can be seen in drvinfo output, so demote both riscv and clint timer
messages to debug level.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619045055.779-2-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't use of_get_mac_address anywhere, but it can come in handy as a
last resort before barebox generates a random MAC address. With the
existing implementation, that MAC address is written literally into the
DT, so it's mainly useful when barebox is booted with an external device
tree. The kernel implementation adds support for parsing the MAC address
out of a revered mac-address nvmem cell, which is much more prevalent.
Sync the implementation with Linux v5.13 in preparation for using it.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619034516.6737-12-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When doing development around nvmem devices, it can be useful to list
which ones exist. Add a command to facilitate this. It can be extended
in future as the need arises (e.g.export cells into the environment?).
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619034516.6737-10-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Not all systems can realize their reboot mode protocol via the syscon
driver:
- There might be no registers available for use that survive a warm
reset
- There might be no warm resets and every reset resets is a cold one
For these systems, the reboot mode can instead be stored in NVMEM.
Port over the Linux nvmem-reboot-mode driver to make this possible.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619034516.6737-7-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Recently, nvmem cell and MTD partition bindings were made to coexist:
Partitions can now be compatible = "nvmem-cells"; which registers a
NVMEM provider and interprets its child nodes as cells. Teach barebox
about this. This allows fetching NVMEM cells from MTD partitions and
hostfiles.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619034516.6737-5-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Only upstream user of this binding is the raspberry pi 4 DT, where it's
used to pass along bootloader-provided info to Linux. We have instances
in barebox, where a previous stage bootloader passes along a memory
region with info for barebox to interpret. This could in future be
modelled as nvmem-rmem nodes. The binding is also quite handy for
debugging.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619034516.6737-4-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
nvmem_bus::write is dereferenced unconditionally when doing write
operations. Align behavior with Linux, which allows drivers to omit
the reg_write callback when the device is known to be read-only.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20210619034516.6737-3-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
