Re: Compiled in boot environment and dtbo files

2021-06-16 Thread Trent Piepho
On Wed, Jun 16, 2021 at 8:59 AM Konstantin Kletschke wrote: > global.bootm.image=/boot/uImage > global.bootm.oftree=/boot/am335x-boneblack.dtb > > Is the order of loading (of_overlay before loading devicetree) messing things > up? If not, what does? > Is it reasonable for me to learn the

Re: Compiled in boot environment and dtbo files

2021-06-16 Thread Konstantin Kletschke
> defaultenv/defaultenv-2-base/boot is the generic place used for all > boards. As you are using the beaglebone you should rather manipulate > arch/arm/boards/beaglebone/defaultenv-beaglebone/. This directory is > added with defaultenv_append_directory(defaultenv_beaglebone) to the > environment

Re: Compiled in boot environment and dtbo files

2021-06-16 Thread Sascha Hauer
Hey Konsti, On Wed, Jun 16, 2021 at 10:10:55AM +0200, 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 >

v2021.06.0

2021-06-16 Thread Sascha Hauer
Hi All, Here comes barebox-2021.06.0. With this release the barebox RISC-V support continues to evolve. We now have sifive HiFive board support along with GPIO, UART and clock support. And for those who want to barebox can now even start kernels on RISC-V ;) Other than that see below for a full

Re: [PATCH] clk: bail out early when rate is already desired one

2021-06-16 Thread Sascha Hauer
On Mon, Jun 07, 2021 at 05:46:12PM +0200, Ahmad Fatoum wrote: > > > On 07.06.21 16:12, Sascha Hauer wrote: > > Return successfully from clk_set_rate() when the rate is already the > > desired one. This prevents a failure in clk_set_rate() when the current > > clock doesn't have a set_rate hook.

Re: [PATCH] drivers: base: Check all compatible strings for modalias match

2021-06-16 Thread Sascha Hauer
On Mon, May 31, 2021 at 07:54:14AM -0700, Trent Piepho wrote: > When attempting a modalias match in device_match_of_modalias(), only the > first string in the compatible property, which is a list of strings, was > used. > > A modalias (which is a bit of a misnomer in Barebox) match is used when >

Re: [PATCH v1 2/2] devinfo: print only devices with errors

2021-06-16 Thread Oleksij Rempel
On Wed, Jun 16, 2021 at 09:59:03AM +0200, Sascha Hauer wrote: > Hi Oleksij, > > On Sun, Jun 06, 2021 at 02:24:00PM +0200, Oleksij Rempel wrote: > > Make use of device state flags and print only devices with errors. > > The result will look like this: > > barebox@RIoTboard i.MX6S:/ devinfo -e > >

Compiled in boot environment and dtbo files

2021-06-16 Thread Konstantin Kletschke
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 like “insidem2m” for example? I managed to modify the existing “sd” entry to be able

Re: [PATCH v1 2/2] devinfo: print only devices with errors

2021-06-16 Thread Sascha Hauer
Hi Oleksij, On Sun, Jun 06, 2021 at 02:24:00PM +0200, Oleksij Rempel wrote: > Make use of device state flags and print only devices with errors. > The result will look like this: > barebox@RIoTboard i.MX6S:/ devinfo -e > `-- 2188000.ether...@2188000.of <-- (error!) >`-- miibus0 > `--

Re: [PATCH 0/5] Cleanup and fix arasan-sdhci

2021-06-16 Thread Sascha Hauer
On Wed, Jun 16, 2021 at 09:39:52AM +0200, Michael Tretter wrote: > Hi, > > These are a few misc patches for the arasan sd controller. Nothing particular > stands out and each patch is useful on its own. I put them into a single > series, because all of them affect the arasan driver. > > Michael

Re: [PATCH 2/2] ARM: i.MX: xload: consider ECC strength when reading page

2021-06-16 Thread Andrej Picej
Ok, I understand that second patch fixes really specific problem, which is not likely to happen. And if this patch would be applied it would break other specific problem that Trent pointed out. Nevertheless, I think first patch doesn't break anything and only fixes bad block marker swapping.

[PATCH 2/5] mci: arasan: fix most checkpatch warnings

2021-06-16 Thread Michael Tretter
checkpatch reports many warnings for the arasan driver. Fix most of the warnings. I didn't fix the long lines in the wait_on_timeout() calls, because trying to fix them actually makes things worse by introducing either unreadable code or multiple additional helper functions, which I don't

[PATCH 0/5] Cleanup and fix arasan-sdhci

2021-06-16 Thread Michael Tretter
Hi, These are a few misc patches for the arasan sd controller. Nothing particular stands out and each patch is useful on its own. I put them into a single series, because all of them affect the arasan driver. Michael Michael Tretter (5): mci: mci-core: respect disable-wp property mci:

[PATCH 5/5] ARM: zynqmp: defconfig: enable MCI_ARASAN

2021-06-16 Thread Michael Tretter
The ZynqMP has an arasan SD controller. Enable it in the respective defconfig. Signed-off-by: Michael Tretter --- arch/arm/configs/zynqmp_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/zynqmp_defconfig b/arch/arm/configs/zynqmp_defconfig index

[PATCH 3/5] mci: arasan: remove duplicate stop clock

2021-06-16 Thread Michael Tretter
The clock is already stopped in sdhci_set_clock(). Stopping the clock in the arasan driver is not necessary. Signed-off-by: Michael Tretter --- drivers/mci/arasan-sdhci.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/mci/arasan-sdhci.c b/drivers/mci/arasan-sdhci.c index

[PATCH 1/5] mci: mci-core: respect disable-wp property

2021-06-16 Thread Michael Tretter
Systems without write-protect pin should ignore the write protect logic and assume that an SD card is always read-write. This is expressed by the disable-wp dt property. Respect the disable-wp property and don't call the write protection check in these cases. Signed-off-by: Michael Tretter ---

[PATCH 4/5] mci: arasan: wait for XFER_COMPLETE for busy response

2021-06-16 Thread Michael Tretter
I observed errors on the ZynqMP during reading the EXT_CSD registers using CMD8. The Zynq UltraScale+ Device TRM UG1085 (v2.2) p. 777 states that the driver shall wait 2 ms after sending CMD6 for setting a EXT_CSD register. The JEDEC Standard No. 84-A43 p. 35 does not specify the delay but states

Re: [PATCH] net/eth: read default mac-address default from dts

2021-06-16 Thread Sascha Hauer
On Tue, Jun 15, 2021 at 07:17:33PM +0200, Michael Grzeschik wrote: > Since we have the function of_get_mac_address we can > use it to set the default mac address vom the dts. A default MAC address means all devices come up with the same MAC address. That's not a good default behaviour. Sascha

[PATCH v4 02/10] drivers: add fpga bridge framework

2021-06-16 Thread Steffen Trumtrar
Import the fpga bridge framework from linux v4.10-rc2. Description from the initial commit adding this to linux: 21aeda950c5f84a8351b862816d832120b217a9b fpga: add fpga bridge framework This framework adds API functions for enabling/ disabling FPGA bridges under kernel control.

[PATCH v4 03/10] drivers: fpga: add socfpga bridges

2021-06-16 Thread Steffen Trumtrar
Import the SoCFPGA bridges drivers from linux v4.10-rc2. Description from the original commit: e5f8efa5c8bf86c1fa698551d54db8f6aee221fd ARM: socfpga: fpga bridge driver support Supports Altera SOCFPGA bridges: * fpga2sdram * fpga2hps * hps2fpga * lwhps2fpga

[PATCH v4 04/10] firmware: socfpga: change function prefixes

2021-06-16 Thread Steffen Trumtrar
Since there is now a fpgamgr framework in barebox, the function names are misleading. Change that to be SoCFPGA specific. Signed-off-by: Steffen Trumtrar --- drivers/firmware/socfpga.c | 58 +++--- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git

[PATCH v4 05/10] firmware: import fpga-mgr.h from linux

2021-06-16 Thread Steffen Trumtrar
Instead of defining the fpga-mgr structure in the socfpga driver, import the fpga-mgr.h file from linux v4.13. Signed-off-by: Steffen Trumtrar --- drivers/firmware/socfpga.c | 9 +--- include/firmware.h | 1 + include/fpga-mgr.h | 102 + 3

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

2021-06-16 Thread Steffen Trumtrar
Add support for potentially defined FPGA-bridges in the overlay. While at it also add support for loading the firmware directly via a path instead of 'needing' an overlay for that. The direct loading will be done with the existent firmwareload command. Signed-off-by: Steffen Trumtrar ---

[PATCH v4 10/10] firmware: add support for compressed images

2021-06-16 Thread Steffen Trumtrar
At least bitstreams for FPGAs can consist of a lot of zeros depending on device utilization. These bitstreams can be compressed very effectively. Let the firmware code accept these images and decompress them before handing it to the firmware-manager in question. Signed-off-by: Steffen Trumtrar

[PATCH v4 01/10] reset: add of_reset_control_get to header

2021-06-16 Thread Steffen Trumtrar
Signed-off-by: Steffen Trumtrar --- drivers/reset/core.c | 2 +- include/linux/reset.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/reset/core.c b/drivers/reset/core.c index 26a54f21dff0..1c9eeaec5491 100644 --- a/drivers/reset/core.c +++ b/drivers/reset/core.c

[PATCH v4 09/10] drivers: firmware: socfpga: remove bridges shutdown

2021-06-16 Thread Steffen Trumtrar
The bridges are now handled via the bridges driver. There is no need to hardcode the memory writes anymore. Signed-off-by: Steffen Trumtrar --- drivers/firmware/socfpga.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/firmware/socfpga.c b/drivers/firmware/socfpga.c index

[PATCH v4 06/10] of: kconfig: of_overlay uses firmwaremgr_load_file

2021-06-16 Thread Steffen Trumtrar
From: Steffen Trumtrar As of_firmware.c uses the firmwaremgr_load_file function, it depends on FIRMWARE. Signed-off-by: Steffen Trumtrar --- drivers/of/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 23be25d85d09..e58fe50f7090 100644

[PATCH v4 08/10] commands: firmwareload: allow loading firmware from dt

2021-06-16 Thread Steffen Trumtrar
firmwareload can only load a bitstream into an FPGA without any knowledge of possible additional needs (e.g. FPGA bridges). These are defined in the fpga-region nodes in the devicetree. The fpga-region describes the layout of the FPGA and the bridges it needs en/disabled. Add an option to let