[PATCH] commands: md: don't leak heap memory with unaligned accesses

Doing unaligned near file end returns bogus results: barebox@Sandbox:/ md -s /dev/stickypage 4095 0fff: 959ff8ff . That 0x959ff8 is heap memory next to the buffer md had allocated. Fix this by adding some zeroed padding after the

[PATCH] test: self: add tests for progress notifier

We don't yet have any boards upstream that make use of the progress notifier, but at least have some tests, so we know it's working. Signed-off-by: Ahmad Fatoum --- lib/Kconfig | 2 +- test/kconfig/base.cfg | 1 + test/kconfig/full.cfg | 1 +

[PATCH v2 03/29] RISC-V: extend multi-image to support both S- and M-Mode

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

[PATCH v2 25/29] hw_random: add driver for RNG on StarFive SoC

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 --- drivers/hw_random/Kconfig| 7 + drivers/hw_random/Makefile | 1 +

[PATCH v2 14/29] soc: sifive: l2_cache: enable maximum available cache ways

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 ---

[PATCH v2 21/29] mci: dw_mmc: match against StarFive MMC compatibles

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

[PATCH v2 20/29] mci: dw_mmc: add optional reset line

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

[PATCH v2 04/29] RISC-V: cpuinfo: return some output for non-SBI systems as well

If barebox managed to actually execute the cpuinfo command, it probably means that it's assumption which instructon set is being used and whether it runs in machine or supervisor mode is correct. Add that output to cpuinfo, so it shows at least something for non-SBI configurations.

[PATCH v2 10/29] RISC-V: add exception support

Add S- and M-Mode support for dumping registers when catching unexpected CPU exceptions. Load access faults when data_abort_mask is active will be skipped over. This allows outputting xxx when doing md /dev/mem for non-accessible space. Signed-off-by: Ahmad Fatoum --- arch/riscv/Kconfig

[PATCH v2 23/29] reset: add StarFive reset controller driver

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

[PATCH v2 27/29] gpio: add support for StarFive GPIO controller

This imports support for the StarFive GPIO controller from the vendor's kernel tree. Signed-off-by: Ahmad Fatoum --- drivers/gpio/Kconfig | 8 ++ drivers/gpio/Makefile| 1 + drivers/gpio/gpio-starfive-vic.c | 177 +++

[PATCH v2 17/29] mci: allocate DMA-able memory

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 --- drivers/mci/mci-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH v2 08/29] nvmem: add StarFive OTP support

The OTP holds the ethernet MAC address. Add a driver, so barebox can read it out. Signed-off-by: Ahmad Fatoum --- drivers/nvmem/Kconfig| 8 ++ drivers/nvmem/Makefile | 2 + drivers/nvmem/starfive-otp.c | 201 +++ 3 files changed, 211

[PATCH v2 07/29] RISC-V: socs: add Kconfig entry for StarFive JH7100

The JH7100 is the StarFive SoC with SiFive CPUs in the pre-production BeagleV. Th JH7110 in later boards will be cache-coherent, but the JH7100 will need some workarounds. Add Kconfig symbols, so newly introduced symbols can depend on them. Signed-off-by: Ahmad Fatoum ---

[PATCH v2 16/29] net: designware: add support for IP integrated into StarFive SoC

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 --- drivers/net/Kconfig | 8 +++ drivers/net/Makefile | 1 + drivers/net/designware.c

[PATCH v2 24/29] watchdog: add StarFive watchdog driver

Signed-off-by: Ahmad Fatoum --- drivers/watchdog/Kconfig| 7 +++ drivers/watchdog/Makefile | 1 + drivers/watchdog/starfive_wdt.c | 106 3 files changed, 114 insertions(+) create mode 100644 drivers/watchdog/starfive_wdt.c diff --git

[PATCH v2 28/29] misc: add power sequencing driver for initializing StarFive peripherals

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

[PATCH v2 29/29] RISC-V: StarFive: add board support for BeagleV Starlight

With the different drivers now in place, we have everything to start a barebox image. Signed-off-by: Ahmad Fatoum --- Documentation/boards/riscv.rst| 37 + arch/riscv/Kconfig.socs | 18 + arch/riscv/boards/Makefile| 1 +

[PATCH v2 13/29] soc: starfive: add support for JH7100 incoherent interconnect

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

[PATCH v2 05/29] RISC-V: S-Mode: propagate Hart ID

Unlike other architectures we support, Linux must apparently be booted on all cores by the bootloader. To achieve this, the bootloaders running on the multiple cores synchronize via IPIs. We will get there eventually, but for now, let's restrict barebox to boot Linux on a single core. S-Mode

[PATCH v2 22/29] clk: add initial StarFive clock support

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

[PATCH v2 02/29] RISC-V: virt: select only one timer

S-Mode should use the riscv timer, so no need to select CLINT timer for virt. Signed-off-by: Ahmad Fatoum --- arch/riscv/Kconfig.socs | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs index c6875738d05c..fd36745755e0 100644 ---

[PATCH v2 15/29] net: designware: fix non-1:1 mapped 64-bit systems

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

[PATCH v2 26/29] reset: add device_reset_all helper

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 ---

[PATCH v2 19/29] dma: allocate 32-byte aligned buffers by default

If dma_alloc() is really used for streaming-dma between cache-incoherent masters, it should return cache-line aligned buffers, so we don't risk invalidating shared cache lines. Bump up the default alignment to 32-bytes. This doesn't affect ARM, as it defines its own implementation with 64-byte

[PATCH v2 11/29] RISC-V: support incoherent I-Cache

SiFive SoCs have separate I-Caches that require self-modifying code like barebox' relocation and PBL extraction code to do cache maintenance. Implement sync_caches_for_execution and use it where appropriate. The underlying fence.i primitive is part of the Zifencei (load/store fence) ISA

[PATCH v2 09/29] RISC-V: dma: support multiple dma_alloc_coherent backends

StarFive JH7100 is incoherent between CPU and dma masters like GMAC. It has an uncached alias though similar to what we have on MIPS. StarFive JH7110 will fix this and be cache coherent like other SiFive SoCs. Support both by allowing driver to define their own dma_alloc_coherent implementations.

[PATCH v2 12/29] drivers: soc: sifive: add basic L2 cache controller driver

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

[PATCH v2 06/29] RISC-V: erizo: make it easier to reuse ns16550 debug_ll

Incoming StarFive support also uses ns16550 compatibles as UART IP. Make reuse easier by making the two most likely parameters to change SoC-specific (base address and baud clock frequency) and move the rest behind the new CONFIG_DEBUG_LL_NS16550. Signed-off-by: Ahmad Fatoum ---

[PATCH v2 00/29] RISC-V: add BeagleV Beta board support

The changes allow barebox to run second stage (after ddrinit and second boot) on the BeagleV beta board. It does everything necessary to support Ethernet, MMC, GPIO, pinmux, pinconf, clock, reset, watchdog, HWRNG and DMA between CPU and the cache-incoherent DMA masters. The current vendor kernel

[PATCH v2 01/29] clocksource: RISC-V: demote probe success messages to debug level

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

[PATCH v2 18/29] mci: allocate sector_buf on demand

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

[PATCH 13/13] sandbox: ship sample environment

The idea of the stickypage was to have a 4K memory region persistent over resets. This region was implemented as mmap of a temporary hostfile, which was created on first barebox start and maintained over resets. Usability was a bit lacking however: - The temporary files weren't deleted -

[PATCH 05/13] sandbox: use nvmem on top of stickypage for reset reason

Watchdog and system reset driver use a byte in the sticky page to persist reset reason over reexec. So far, this was a byte outside partitioned space. With the new nvmem-cells binding, a partition can be dedicated to holding nvmem cells. Use that instead. Signed-off-by: Ahmad Fatoum ---

[PATCH 03/13] nvmem: add support for new read-only memory (rmem) binding

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

[PATCH 04/13] nvmem: add support for nvmem-cells binding

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.

[PATCH 08/13] sandbox: dts: fix unit-address for state partition

Signed-off-by: Ahmad Fatoum --- arch/sandbox/dts/sandbox.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts index fa9348d71f62..595a1e8eae73 100644 --- a/arch/sandbox/dts/sandbox.dts +++

[PATCH 02/13] nvmem: treat devices without nvmem_bus::write as read only

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 --- drivers/nvmem/core.c | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH 06/13] power: reset: port Linux generic NVMEM reboot mode driver

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.

[PATCH 09/13] nvmem: add command to list nvmem devices

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 --- commands/Kconfig | 7 +++

[PATCH 11/13] of: of_net: sync of_get_mac_address with Linux for NVMEM support

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

[PATCH 10/13] sandbox: hostfile: move initcall to earlier postcore level

Follow-up changes will have the hostfile provide nvmem cells to other drivers, which run at coredevice_ and device_ initcall levels. These drivers can't defer probe though, because access to the NVMEM cell is optional. Move the hostfile initcall earlier to allow for this. Once deep probe support

[PATCH 12/13] net: consult device tree for ethernet address in NVMEM as fall-back

While barebox fixes up the mac-address into the device tree, it doesn't care much for extracting a mac address _from_ the device tree, whether it be from local-mac-address property or from a mac-address nvmem cell. Fix the latter by calling of_get_mac_addr_nvmem for each Ethernet adapter. We do

[PATCH 00/13] nvmem: misc enhancements

Series implements some of the new NVMEM bindings: - New providers: - nvmem-cells (for MTD partitions) - nvmem-rmem (memory regions passed by previous boot stages) - New consumers: - Network devices: Unlike Linux, we do that for all drivers in generic code. This is done postenvironment,

[PATCH 07/13] sandbox: use nvmem-reboot-mode instead of syscon-reboot-mode

We have some syscon-reboot-mode users in tree, but no nvmem-reboot-mode yet. Use the new nvmem-cells binding to remedy this. Added benefit is that we no longer access unpartitioned space; The reboot mode is now clearly described in the device tree. Signed-off-by: Ahmad Fatoum ---

[PATCH 01/13] nvmem: bsec: remove unused, left-over, struct member

With the move to the nvmem_regmap_register, the config member in the bsec driver became unused. Drop it. Signed-off-by: Ahmad Fatoum --- drivers/nvmem/bsec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c index 509a5fa872f7..d9b38c8414fb 100644

[PATCH master 1/2] nvmem: regmap: fix use of uninitialized space with nvmem_regmap_register

Looking through all instances of struct nvmem_config in the tree shows that only the new nvmem_regmap_register failed to initialize all members, e.g. config::read_only was uninitialized. Fix this up. Signed-off-by: Ahmad Fatoum --- drivers/nvmem/regmap.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH master 2/2] nvmem: fix mismatch between extern and inline stub prototypes

Building with nvmem cell support disabled shows a mismatch in the stub prototype. Fix it up. Signed-off-by: Ahmad Fatoum --- include/linux/nvmem-consumer.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h index

[PATCH 1/2] string: implement strchrnul

We have at least two places opencoding strchrnul, one of them needlessly iterating twice instead of once over the string. Replace both by calling a single pass implementation. Signed-off-by: Ahmad Fatoum --- commands/hwclock.c | 8 drivers/of/base.c | 5 +

[PATCH 2/2] console: respect baudrate specified in device-tree stdout-path

stdout-path in the device tree can have a suffix indicating line settings. The baud rate contained within was so far ignored by barebox. Change this so barebox first consults the stdout-path alias before falling back to CONFIG_BAUDRATE. Signed-off-by: Ahmad Fatoum --- This applies on top of the

Re: Compiled in boot environment and dtbo files

> You could add a bootspec file with > > devicetree-overlay BB-UART1-00A0.dtbo BB-UART4-00A0.dtbo > > If you want the overlay application to happen in the bootloader, but > decide the overlay selection policy in userspace. Thanks for the information, I will definitely check this out! Kind

Re: Compiled in boot environment and dtbo files

> In the end it goes down to putting an entry like this into > loader/entries/foo.conf into your rootfs: I will investigate this definitely carefully since this has nice advantages controlling the boot from userspace, especially in order to gain a proper failover environment. Meanwhile I

Re: Compiled in boot environment and dtbo files

> While I have not yet used overlays in barebox, and don't know what is > wrong here, the order of loading is not what you think. I think I got your point. Setting those parameters are not really loading stuff. So the setting order has nothing to do with load order, the booting itself loads the

[PATCH 2/2] common: bbu: add pr_fmt

This makes it easier to identify where messages are coming from. Signed-off-by: Rouven Czerwinski --- common/bbu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/bbu.c b/common/bbu.c index a66be553e9..deb6a007c9 100644 --- a/common/bbu.c +++ b/common/bbu.c @@ -4,6 +4,9 @@ * *

[PATCH 1/2] common: bbu: only add available handlers

A board may have multiple handlers registered: registered update handlers: SD -> /dev/mmc0.barebox * eMMC-> /dev/mmc1 However when using the usbgadget with the -b command line argument, fastboot will stat all devicefiles listed in the handlers and will fail if i.e. the

Re: [PATCH 2/2] firmware: socfpga: set APPLYCFG after loading bitstream

On 18.06.21 10:09, Steffen Trumtrar wrote: > To make changes to the SDRAM controller effective, the APPLYCFG bit must > be set after programming the bitstream to the FPGA. This has to be done > without any SDRAM usage. Therefore copy the function to execute to the > OCRAM and execute it from

Re: [PATCH v4 07/10] of: of_firmware: add support for fpga bridges

Steffen Trumtrar writes: > diff --git a/include/of.h b/include/of.h > index 645f429bdeed..3c922bdb1414 100644 > --- a/include/of.h > +++ b/include/of.h > +int of_firmware_load_overlay(struct device_node *overlay, const char *path); > +#else > +static inline int of_firmware_load_overlay(const

[PATCH 2/2] firmware: socfpga: set APPLYCFG after loading bitstream

To make changes to the SDRAM controller effective, the APPLYCFG bit must be set after programming the bitstream to the FPGA. This has to be done without any SDRAM usage. Therefore copy the function to execute to the OCRAM and execute it from there. Signed-off-by: Steffen Trumtrar ---

[PATCH 1/2] ARM: mmu: inherit pte flags from pmd

From: Sascha Hauer When creating a 2nd level page table from a section inherit the flags from the section rather than assuming the section was mapped cached previously. This fixes creating a 2nd level pagetable when the section was mapped differently than we expected. Signed-off-by: Sascha

Re: Compiled in boot environment and dtbo files

Hello Konstantin, On 16.06.21 10:10, Konstantin Kletschke wrote: > Dear community, > > actually I wonder how to prepare a reset/boot up default boot environment > compiled in. > > Is it correct, that my 1st task to achieve this is to add a new file in > defaultenv/defaultenv-2-base/boot >