I sent the PR. But who knows if
Marvell will have some people assigned to merge the PR.
Since U-Boot prints its own version, people can easily reproduce the
code for a given binary from U-Boot version string.
Marek
On Mon, 15 Apr 2024 15:20:49 -0700
Tony Dinh wrote:
> Hi Marek,
>
> I'
160908.508974-1-...@ti.com.
I was not aware of that one. thank you for pointing it out. That seems
indeed a better solution.
>
>>
>> On the TI vendor tree, there is a similar patch with a commit message:
>> https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.
On Mon, Apr 15, 2024 at 09:33:40AM -0300, Fabio Estevam wrote:
> Hi Tom,
>
> Please pull from u-boot-imx/master, thanks.
>
> The following changes since commit b03b49046af5dfca599d2ce8f0aafed89b97aa91:
>
> Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2
On Mon, Apr 15, 2024 at 06:52:30PM +0900, Jaehoon Chung wrote:
> Dear Tom,
>
> Please pull u-boot-mmc master into u-boot master branch.
> If there is any problem, let me know, plz.
>
> BTW, I'm checking other pending patches in more detail.
> After checking, I will apply
On Mon, Apr 15, 2024 at 07:34:20AM +, Chee, Tien Fong wrote:
> Dear Tom,
>
> Please pull the SoCFPGA changes for next from u-boot-socfpga, containing:
>
> 1. Add option to reprogram FPGA every reboot, enable this as default in
> chameleonv3 defconfig.
>
import old DDR3 training code and make some changes so
> that it works with U-Boot. The reason why this is being done is
> explained in patch 6
> - patch 9 glues the old DDR3 training code to current U-Boot
> - patch 10 allows for dynamic selection of old DDR3 training code on
&
Support old DDR3 training code on Turris Omnia, selectable by U-Boot
enviroment variable.
Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting
dr/marvell/a38x/old/glue_symbol_renames.h
b/drivers/ddr/marvell/a38x/old/glue_symbol_renames.h
new file mode 100644
index 00..9bdfecd2d6
--- /dev/null
+++ b/drivers/ddr/marvell/a38x/old/glue_symbol_renames.h
@@ -0,0 +1,247 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Glu
Backport the option to compile with immutable debug settings also to
the old implementation of the DDR3 training code.
The original PR for mv-ddr-marvell can be seen at
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/45/
Signed-off-by: Marek Behún
---
Fix some compilation warning in the old DDR training code.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/old/ddr3_a38x.c | 1 +
drivers/ddr/marvell/a38x/old/ddr3_init.h | 2 ++
drivers/ddr/marvell/a38x/old/ddr3_training.c | 1 +
Save 10 KiB in Turris Omnia's SPL binary by enabling immutable debug
settings for DDR3 training code.
Signed-off-by: Marek Behún
---
configs/turris_omnia_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index
Allow compiling with immutable debug settings:
- DEBUG_LEVEL is always set to DEBUG_LEVEL_ERROR
- register dumps are disabled
This can save around 10 KiB of space in the resulting binary, which is a
lot in U-Boot SPL.
Signed-off-by: Marek Behún
---
arch/arm/mach-mvebu/Kconfig | 10
The variables is_validate_window_per_if, is_validate_window_per_pup,
sweep_cnt and is_run_leveling_sweep_tests are only used if
DDR_VIEWER_TOOL macro is defined, so define them only in that case.
Make them static since they are only used in ddr3_debug.c.
Signed-off-by: Marek Behún
---
Return from ddr3_tip_print_log() early if we won't print anything
anyway.
This way the compiler can optimize away the VALIDATE_IF_ACTIVE() calls
in the for-loop, so if the SILENT_LIB macro is defined, no code is
generated for the rest of the function, which saves some space.
Signed-off-by: Marek
The variables is_default_centralization, is_tune_result and
is_bist_reset_bit are never used.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_debug.c | 3 ---
drivers/ddr/marvell/a38x/ddr3_init.h | 1 -
2 files changed, 4 deletions(-)
diff --git
/45/
but I am told that Armada team has left Marvell, so who knows if this
will ever be merged there
- patch 5 enables this reduction for Turris Omnia
- patches 6-8 import old DDR3 training code and make some changes so
that it works with U-Boot. The reason why this is being done
Hi Tom,
Please pull from u-boot-imx/master, thanks.
The following changes since commit b03b49046af5dfca599d2ce8f0aafed89b97aa91:
Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2024-04-14
15:58:31 -0600)
are available in the Git repository at:
https://gitlab.denx.de/u-boot
Dear Tom,
Please pull u-boot-mmc master into u-boot master branch.
If there is any problem, let me know, plz.
BTW, I'm checking other pending patches in more detail.
After checking, I will apply them into u-boot-mmc. Sorry for too late.
Best Regards,
Jaehoon Chung
CI: https://source.denx.de/u
Dear Tom,
Please pull the SoCFPGA changes for next from u-boot-socfpga, containing:
1. Add option to reprogram FPGA every reboot, enable this as default in
chameleonv3 defconfig.
2. Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG, so
the driver can be built when
On Sun, Apr 14, 2024 at 08:45:17PM +0200, Marek Vasut wrote:
> The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
>
> Merge tag 'u-boot-dfu-next-20240402' of
> https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-04-02 22:37:23
> -0400)
>
On Sun, Apr 14, 2024 at 08:16:13PM +0200, Dario Binacchi wrote:
> Hello Tom,
>
> The following changes since commit 266603d8c39cf4d194e2cfe8d86d870590e150e0:
>
> Merge tag 'efi-2024-07-rc1-2' of
> https://source.denx.de/u-boot/custodians/u-boot-efi (2024-04-1
The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
Merge tag 'u-boot-dfu-next-20240402' of
https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-04-02 22:37:23 -0400)
are available in the Git repository at:
git://source.denx.de/u-boot-usb.git master
for you
Hello Tom,
The following changes since commit 266603d8c39cf4d194e2cfe8d86d870590e150e0:
Merge tag 'efi-2024-07-rc1-2' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2024-04-13
10:18:38 -0600)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot
On Sun, 31 Mar 2024 23:03:18 +0300, Eugene Uriev wrote:
> There was no "mcheck" for U-Boot before.
>
> Since U-Boot has only 1 thread, and normally makes 4000+ - 6000+
> mallocs, it's better to use havier canaries to protect heap-chunks.
> My variant uses 2x
Hi Jonas,
thank You, i tried my best to follow your hints as good as possible. This is
what i did:
- git clone https://github.com/rockchip-linux/rkbin
- git clone https://github.com/u-boot/u-boot
- modified the following files:
```
diff --git a/arch/arm/dts/rk3568-generic.dts b/arch/arm/dts
Hi Sjoerd!
On Fri, 2024-01-12 at 09:52 +0100, Sjoerd Simons wrote:
> Enable usb0 in all boot phases for use with DFU
>
> Signed-off-by: Sjoerd Simons
Reviewed-by: Alexander Sverdlin
> ---
>
> Changes in v4:
> - Don't force usb0 into peripheral mode
>
> Changes in v3:
> - Enable usb nodes
Dear Mr. Jaehoon Chung, Hello!
I am learning to write an mmc driver, I saw this driver code you wrote in 2012
in U-boot source code, I can't download the documentation of DesignWare MMC
controller, so I can't work on my driver development.
I hope you can provide some help! Have a nice life!
version of this series will drop this patch as Andrew has
submitted another patch removing the need for this one. See
https://lore.kernel.org/r/20240402160908.508974-1-...@ti.com.
>
> On the TI vendor tree, there is a similar patch with a commit message:
> https://git.ti.com/cgit/ti-u-
Hi Jonathan,
Thank you for the patch.
On lun., avril 08, 2024 at 17:31, Jonathan Humphreys wrote:
> Signed-off-by: Jonathan Humphreys
Please consider adding a commit message body.
On the TI vendor tree, there is a similar patch with a commit message:
https://git.ti.com/cgit/ti-u-boot/t
? I suppose
this kind of DT modifications would push us away from upstream DT
compatibility.
Yes, I plan to switch to that eventually with these patches (which I'll
try and send soon). I just didn't want to leave this broken in the meantime.
https://git.codelinaro.org/linaro/qcomlt/u-boot
Hi Caleb,
On Tue, 9 Apr 2024 at 23:33, Caleb Connolly wrote:
>
> Remove the reference to the xo clock which is on the unsupported rpmhcc
> clock controller. It isn't needed for MMC functionality.
Can it rather be handled via a NOP clock driver for rpmhcc? I suppose
this kind of DT modifications
On Tue, Apr 09, 2024 at 04:25:36PM +0800, Leo Liang wrote:
> Hi Tom,
>
> The following changes since commit 069d07396e30aa9be396c1dd3fc158ac199e6843:
>
> Merge tag 'efi-2024-07-rc1' of
> https://source.denx.de/u-boot/custodians/u-boot-efi (2024-04-08 14:33:59
> -060
Remove the reference to the xo clock which is on the unsupported rpmhcc
clock controller. It isn't needed for MMC functionality.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/sdm845-db845c-u-boot.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in
+3,7 @@
* Copyright : STMicroelectronics 2022
*/
+#include
#include "stm32mp15-scmi-u-boot.dtsi"
/ {
@@ -14,8 +15,22 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = &q
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to
+#include
#include "stm32mp15-u-boot.dtsi"
#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
@@ -16,8 +17,6 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = "f
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to
stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
@@ -18,8 +19,6 @@
u-boot,error-led = "error";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.
Signed-off-by: Patrice Chotard
de "stm32mp15-scmi-u-boot.dtsi"
/ {
@@ -16,8 +17,22 @@
u-boot,error-led = "error";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
- st,fastboot-gpios = < 13 (GPIO
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion
Remove "color" property from led-red node which is not supported
by U-Boot.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.
-boot,mmc-env-partition = "u-boot-env";
};
+ gpio-keys {
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ }
led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this,
Hi Tom,
The following changes since commit 069d07396e30aa9be396c1dd3fc158ac199e6843:
Merge tag 'efi-2024-07-rc1' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2024-04-08 14:33:59 -0600)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot
Signed-off-by: Jonathan Humphreys
---
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index fa778b0ff4c..35bfeae75a0 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
Signed-off-by: Jonathan Humphreys
---
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index fa778b0ff4c..35bfeae75a0 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
Hi Z,
On 2024-04-08 09:40, Mizsei Zoltán wrote:
> Hi,
>
> I'm trying to get a mainline U-Boot running on the Geniatech XPI-3566-ZERO
> RK3566 based SBC [1], but all my attempts have failed so far.
>
> The SBC doesn't have any SD-Card slot, please keep this in mind!
>
Is u-boot capable of selecting the correct DTB in a UKI during boot?
I saw "doc/README.multi-dtb-fit", which at least somewhat addresses
what I'm looking for I think, but I'm not sure if that will relate
directly with executing a UKI that has multiple DTBs...
For my one board, I w
Hi,
I'm trying to get a mainline U-Boot running on the Geniatech XPI-3566-ZERO
RK3566 based SBC [1], but all my attempts have failed so far.
The SBC doesn't have any SD-Card slot, please keep this in mind!
I can build U-Boot, but when I write the resulting binary to the eMMC using
On Fri, Apr 05, 2024 at 01:46:05PM -0300, Fabio Estevam wrote:
> Hi Tom,
>
> Please pull this material for from u-boot-imx/master, thanks.
>
> The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
>
> Merge tag 'u-boot-dfu-next-20240402' of
>
l
>
> The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
>
> Merge tag 'u-boot-dfu-next-20240402' of
> https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-04-02 22:37:23
> -0400)
>
> are available in the Git repository at:
>
> h
On Thu, Apr 04, 2024 at 02:08:15PM +0200, Stefan Roese wrote:
> Hi Tom,
>
> please pull the first batch of mostly Marvell related patches:
>
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
g...@source.denx.de:u-boot/custodians/u-boot-samsung.git master
>
> for you to fetch changes up to 1751ba9a3b79ea5083ff5c4de58fe3bd9588f32a:
>
> clk: exynos: Add CMU_CORE and CMU_HSI for Exynos850 (2024-03-26 18:56:55
> +0900)
>
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Hi Tom,
Please pull this material for from u-boot-imx/master, thanks.
The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
Merge tag 'u-boot-dfu-next-20240402' of
https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-04-02 22:37:23 -0400)
are available in the Git
0x00 0x4843 0x00 0x004000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "cfg", "tchan", "rchan", "rflow";
Is this needed? Do we still not have the correct regs in
upstream kernel?
I miss
= "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "cfg", "tchan", "rchan", "rflow";
Is this needed? Do we still not have the correct regs in
upstream kernel?
I missed this change when I was going through j722s
Hi Tom,
Please pull this migration to OF_UPSTREAM for all Amlogic SoCs family
except the newer A1 family.
In Addition, there's a few fixes & updates for the jethubj100 board.
Thanks,
Neil
The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
Merge tag 'u-boot-dfu-
On 4/4/24 4:00 AM, Jayesh Choudhary wrote:
Include the uboot device tree files needed to boot the board.
Co-developed-by: Vaishnav Achath
Signed-off-by: Vaishnav Achath
Signed-off-by: Jayesh Choudhary
---
arch/arm/dts/Makefile |2 +
)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=343=results
Thanks,
Stefan
The following changes since commit cdfcc37428e06f4730ab9a17cc084eeb7676ea1a:
Merge tag 'u-boot-dfu-next-20240402' of
https://source.denx.de
create mode 100644 drivers/misc/turris_omnia_mcu.c
create mode 100644 include/turris-omnia-mcu-interface.h
Applied to u-boot-marvell/master
Thanks,
Stefan
t;0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c7a800>;
+ };
+
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+
+ ti_fs_enc_fs: ti-fs-enc
Hello there,
This series add the U-Boot support for our new platform of K3-SOC
family - J722S-EVM which is a superset of AM62P. It shares the same
memory map and thus the nodes are being reused from AM62P includes
instead of duplicating the definitions.
Some highlights of J722S SoC (in addition
Dear Tom,
The following changes since commit dde373bde392c38649c8c4420e0c98ef8d38d9dc:
Prepare v2024.04-rc5 (2024-03-25 21:56:50 -0400)
are available in the git repository at:
g...@source.denx.de:u-boot/custodians/u-boot-samsung.git master
for you to fetch changes up
Now that Turris Omnia has a rng driver provided in the MCU driver,
enable the rng command in defconfig.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
configs/turris_omnia_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/turris_omnia_defconfig
Add support for true random number generator provided by the MCU on
Turris Omnia. The MCU firmware supports TRNG if the FEAT_TRNG bit is set
in features. In that case we bind the rng driver.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
configs/turris_omnia_defconfig | 1 +
In the rng command, print
Abort
instead of
Reading RNG failed
if the error number is -EINTR, which can happen if the user pressed
CTRL-C.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
cmd/rng.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/cmd/rng.c
Enable support for the poweroff command via sysreset for Turris Omnia.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
configs/turris_omnia_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index
Add support for system power off via UCLASS_SYSRESET. Newer versions of
Turris Omnia MCU firmware can power off the board (MCU will disable
almost all voltage regulators and go into low power mode).
Move the MCU driver into drivers/misc and register it under UCLASS_MISC.
The sysreset and gpio
Update firmware features reading to try reading 32 bits of features and
fallback to reading 16 bits.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
drivers/gpio/turris_omnia_mcu.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git
Use byteorder conversion function instead of manually assembling data
from/to MCU.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
drivers/gpio/turris_omnia_mcu.c | 80 +++--
1 file changed, 46 insertions(+), 34 deletions(-)
diff --git
Add driver model support for sysreset via mvebu system controller. This is
currently only available for U-Boot proper.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
arch/arm/mach-mvebu/Kconfig | 18 +-
arch/arm/mach-mvebu/Makefile| 2 +-
arch/arm/mach
The mvebu-reset driver is only needed by the mvebu PCIe driver, but
currently it is automatically selected if DM_RESET is enabled. Add the
condition of PCI_MVEBU also being enabled for mvebu-reset to be
selected.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
The system-controller driver for 32-bit Armada is currently registered
as UCLASS_RESET, since it only provides enabling/disabling PCIe ports.
Rework it as UCLASS_SYSCON and bind mvebu-reset as a child device.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
arch/arm/mach-mvebu/Kconfig
Commit 35e29e89a386 ("arm: mvebu: Implement simple mvebu-reset driver
for enabling/disabling PCIe ports") made it so that the mvebu reset
driver for enabling/disabling PCIe ports is build if CONFIG_DM_RESET is
enabled. This is because PCI_MVEBU depends on DM_RESET.
But the driver should not be
If the FEAT_CRYPTO feature bit is present in MCU features, the board
crypto is implemented by MCU and the Atmel SHA chip is not present.
Disable Atmel SHA device-tree node in that case.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 23
If MCU supports the FEAT_CRYPTO feature, read board ECDSA public key
from MCU and print it.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
Implement reading board serial number, first MAC address and board
version from MCU. MCU supports board information if the FEAT_BOARD_INFO
feature bit is set in MCU features.
Prefer getting board information from MCU if supported, fallback to
Atmel SHA chip.
Signed-off-by: Marek Behún
strcat(result, " (with peripheral resets)");
- }
+ if (omnia_mcu_has_feature(FEAT_PERIPH_MCU))
+ strcat(result, " (with peripheral resets)");
return result;
}
@@ -660,9 +710,6 @@ int board_early_init_f(void)
void spl_board_init(void)
Since commit 8cd4bf7dc9ba ("turris: Use checkboard() instead of
show_board_info()") the model is show two times during boot:
Model: Turris Omnia
Model: Turris Omnia
This is because the common function show_board_info() shows it, and
Turris' checkboard() also does.
Remove the second print.
= BIT(5),
-};
-
/*
* Those values and defines are taken from the Marvell U-Boot version
* "u-boot-2013.01-2014_T3.0"
@@ -219,7 +180,7 @@ static bool disable_mcu_watchdog(void)
puts("Disabling MCU watchdog... ");
- ret = omnia_mcu_write(CMD_WATCHDOG_STATE, &qu
U-Boot builds for Turris Omnia are approaching the limit of 0xf
bytes, which is the size of the U-Boot partition on Omnia.
Enable LTO to get more size optimized binaries.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
configs/turris_omnia_defconfig | 1 +
1 file changed, 1
changes since v3:
- added missing files turris_common.c and turris_common.h to patch 05/18
- added comment to patch 11/18 before while (1); as discussed in v3
v1, v2 and v3 at:
https://patchwork.ozlabs.org/project/uboot/cover/20240304152148.3847-1-ka...@kernel.org/
/turris_omnia/../turris_atsha_otp.o] Error 1
> board/CZ.NIC/turris_omnia/turris_omnia.c:36:10: fatal error:
> ../turris_common.h: No such file or directory
> 36 | #include "../turris_common.h"
>| ^~~~
> compilation terminated.
>
> Available here:
otp.o] Error 1
board/CZ.NIC/turris_omnia/turris_omnia.c:36:10: fatal error:
../turris_common.h: No such file or directory
36 | #include "../turris_common.h"
| ^~~~
compilation terminated.
Available here:
https://source.denx.de/u-boot/custodians/u-boot-mar
The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
This is incorrectly modelled in Linux where only the PCIe dependency is
expressed. The correct way to handle this will be through a
usb-connector node, but for now we'll just mark the regulator as
always-on so that it will be
ode from dwc3 to prepare better interrupt support
> - Bugfix for for qcom-smmu when compiling with -DDEBUG
>
> The CI job is at
> https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20143
>
> Thanks,
> Mattijs
>
> Note: sorry for the noise,
On Tue, Apr 02, 2024 at 11:36:36AM +0200, Mattijs Korpershoek wrote:
> Hi Tom,
>
> Here are some fixes for master including:
>
> - Fix #if logic in android_ab command
> - Fix ANDROID_AB_BACKUP_OFFSET in android_ab
>
> The CI job is at
> https://source.denx.de/u
Hey all,
It's Tuesday, and for once I'm not late and it's release day and so here
is v2024.04. Once again I want to thank everyone that's contributed to
this release, not just in terms of code, but documentation, testing and
otherwise ensuring things go as smoothly as they can.
In terms of a
Hi Tom,
Here are some fixes for master including:
- Fix #if logic in android_ab command
- Fix ANDROID_AB_BACKUP_OFFSET in android_ab
The CI job is at
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20142
Thanks,
Mattijs
The following changes since commit
The CI job is at
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20143
Thanks,
Mattijs
Note: sorry for the noise, I forgot to include u-boot list in the first email.
The following changes since commit e50cb36cb5e772d5bbd30d070faedf7323406364:
Merge branch '2024-03-19-assorted
On 28/03/2024 18:59, Caleb Connolly wrote:
The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
This is incorrectly modelled in Linux where only the PCIe dependency is
expressed. The correct way to handle this will be through a
usb-connector node, but for now we'll just mark
201 - 300 of 354836 matches
Mail list logo
