Hi Tom,
Please pull from u-boot-imx, thanks.
The following changes since commit e4013bcb10f604ec1dfe955634d57e1fc336b15f:
Merge branch 'master-porter' of
https://source.denx.de/u-boot/custodians/u-boot-sh (2024-02-17 18:37:07 -0500)
are available in the Git repository at:
https
Hi Nishanth
On 16/02/24 21:28, Nishanth Menon wrote:
On 14:33-20240215, Neha Malcom Francis wrote:
[...]
if the templates are abstract enough, the additional code will be so
minimal that we wont need a board-binman.dtsi - just u-boot.dtsi and
r5.dtsi can include the relevant templates.
Hope
On Sun, Feb 18, 2024 at 12:34:49AM +0100, Marek Vasut wrote:
> The following changes since commit 9e00b6993f724da9699ef12573307afea8c19284:
>
> Merge tag 'u-boot-dfu-20240215' of
> https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-15 10:26:24
> -0500)
>
> are
The following changes since commit 9e00b6993f724da9699ef12573307afea8c19284:
Merge tag 'u-boot-dfu-20240215' of
https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-15 10:26:24 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-sh.git
100644
--- a/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
@@ -1,9 +1,3 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include "rk3328-nanopi-r2c-u-boot.dtsi"
-
-/ {
- chosen {
- u-boot,spl-boot-orde
On 14:33-20240215, Neha Malcom Francis wrote:
[...]
> > if the templates are abstract enough, the additional code will be so
> > minimal that we wont need a board-binman.dtsi - just u-boot.dtsi and
> > r5.dtsi can include the relevant templates.
> >
> > Hope this helps.
>
>
> So I took a stab
On Thu, Feb 15, 2024 at 03:40:33PM +0100, Mattijs Korpershoek wrote:
> Hi Tom,
>
> Here are some developments for master including:
>
> - Fix avb_verify command with SD cards
> - Add u-boot-dfu maintainer tree for AB/AVB
> - Avb: report verified boot state based on lo
Hi Tom,
Here are some developments for master including:
- Fix avb_verify command with SD cards
- Add u-boot-dfu maintainer tree for AB/AVB
- Avb: report verified boot state based on lock state
- Misc avb refactors improve code quality
The CI job is at
https://source.denx.de/u-boot/custodians
.
But when I try to integrate this with u-boot, the boot.img is not being
parsed and I see below errors
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
I tried to manually load it using:
fatload mmc 0:1 ${kernel_addr_r
Hi Nishanth
On 24-Jan-24 2:22 AM, Nishanth Menon wrote:
On 20:28-20240123, Apurva Nandan wrote:
[...]
in j784s4-binman.dtsi:
{
j784s4_tiboot3_hs_fs_template: template-9 {
and then in sk.dtsi:
sk.dtsi means sk-uboot.dtsi or sk-binman.dtsi?
you wont need an sk-binman.dtsi
Hey all,
I'm a day late as I missed my calendar reminder, but here's -rc2 now. I
am hopeful really just about everything that needs to come in, is now
in, but I also know I have at least one more series to grab for TI
platforms. And I'll grab the series I posted today that should fix the
current
it Garg wrote:
> > >
> > > > Changes in v5:
> > > > --
> > > > - Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41)
> > > > - Created v5_dt branch for testing purposes:
> > > > https://github.com/b49020/u-boot/tree/v5
On Mon, Feb 12, 2024 at 08:01:59AM -0300, Fabio Estevam wrote:
> Hi Tom,
>
> Please pull from u-boot-imx, thanks.
>
> The following changes since commit d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8:
>
> Merge tag 'u-boot-dfu-20240209' of
> https://source.denx.de/u-bo
Hi Tom,
Please pull from u-boot-imx, thanks.
The following changes since commit d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8:
Merge tag 'u-boot-dfu-20240209' of
https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-09 09:00:42 -0500)
are available in the Git repository at:
https
Hi Quentin,
On 2024-02-09 10:50, Quentin Schulz wrote:
> From: Quentin Schulz
>
> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
> pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
> bind the device before relocation.
&
On Sun, Feb 11, 2024 at 06:31:59PM +0100, Marek Vasut wrote:
> The following changes since commit d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8:
>
> Merge tag 'u-boot-dfu-20240209' of
> https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-09 09:00:42
> -0500)
>
> are
The following changes since commit d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8:
Merge tag 'u-boot-dfu-20240209' of
https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-09 09:00:42 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-sh.git
he CI job is at
> https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/19573
>
> Thanks,
> Mattijs
>
> The following changes since commit a4650bf65e4b7d3ef04c90ba8031374428e4a682:
>
> ti: keystone2: Move common Kconfig selections to under ARCH_KEYSTONE
> (2024-
Hi Tom,
Here are some developments for master including:
- sparse error checking fix when using raw chunks
- 2 new additions (AVB, AB) of myself to the MAINTAINERS file
The CI job is at
https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/19573
Thanks,
Mattijs
The following
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's a lookup
for devic
On Thu, Feb 08, 2024 at 11:36:33AM -0300, Fabio Estevam wrote:
> Hi Tom,
>
> Please pull from u-boot-imx, thanks
>
> The following changes since commit 0101a2ffe125911ebf89172b495f5ff14f2fd058:
>
> Merge branch '2024-02-06-assorted-fixes' (2024-02-07 09:47:47 -050
Hi Tom,
Please pull from u-boot-imx, thanks
The following changes since commit 0101a2ffe125911ebf89172b495f5ff14f2fd058:
Merge branch '2024-02-06-assorted-fixes' (2024-02-07 09:47:47 -0500)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
On Fri, Feb 2, 2024 at 1:04 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> U-Boot binary has grown in such a way that it goes beyond the reserved
> area for the environment variables.
>
> Running "saveenv" and rebooting the board causes U-Boot to hang bec
Hello,
I performed a bisection and was able to fix that issue by reverting
three commits on v2024.04-rc1:
0585c28fda1007e4a90dea5f70723cff0b63dd98
eed8294b75a5908a486945ff6655d4dc9aae5fed
ee23d7466c77d01ee63efb76db2c5fd3b7cdd6f7
It is still unclear to me how those FEAT_HAFDBS related commits
dts sync from linux v6.8-rc1 for rk356x, rk3588, rv1126;
> - Enable eMMC HS200 mode by default for rk3568 and rk3588;
>
> CI:
> https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/19556
>
> Thanks,
> - Kever
>
> The following changes since commit 819abd0
and rk3588;
CI:
https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/19556
Thanks,
- Kever
The following changes since commit 819abd0a1eaff9a921f5b917e152b85dab302e33:
Merge tag 'smbios-2024-04-rc2' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2024-02-03 09:11:25
index f8adb9e5e1ff..1dc3c022c504 100644
--- a/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
@@ -1,9 +1,3 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include "rk3328-nanopi-r2c-u-boot.dtsi"
-
-/ {
- chosen {
- u-boo
ch/arm/dts/rk3328-nanopi-r2c-plus-u-boot.dtsi
@@ -1,9 +1,3 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include "rk3328-nanopi-r2c-u-boot.dtsi"
-
-/ {
- chosen {
- u-boot,spl-boot-order = "same-as-spl", ,
- };
-};
diff --git a/arch/arm/dts/rk3328
Hello,
I am using the imx93-var-som_defconfig configuration on commit
v2024.04-rc1. When producing signed or unsigned images on an unclosed
board everything works fine.
However, once the board is closed (ahab_close command is issued), u-boot
hangs this way:
--8<---cut h
> > > - Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41)
> > > - Created v5_dt branch for testing purposes:
> > > https://github.com/b49020/u-boot/tree/v5_dt
> > > - Patch #6: Added support to cherry-pick fixes in subtree update script.
> > > Also, u
for testing purposes:
> > https://github.com/b49020/u-boot/tree/v5_dt
> > - Patch #6: Added support to cherry-pick fixes in subtree update script.
> > Also, used https:// instead of git://.
> > - Patch #7: Fixed inappropriate documentation update.
> > - Patch #8: Docume
On Fri, Feb 2, 2024 at 9:34 PM Igor Opaniuk wrote:
>
> On Fri, Feb 2, 2024 at 5:04 PM Fabio Estevam wrote:
> >
> > From: Fabio Estevam
> >
> > U-Boot binary has grown in such a way that it goes beyond the reserved
> > area for the environment variables.
>
On Fri, Feb 2, 2024 at 5:04 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> U-Boot binary has grown in such a way that it goes beyond the reserved
> area for the environment variables.
>
> Running "saveenv" and rebooting the board causes U-Boot to hang bec
On Fri, Feb 02, 2024 at 06:35:23PM +0530, Sumit Garg wrote:
> Changes in v5:
> --
> - Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41)
> - Created v5_dt branch for testing purposes:
> https://github.com/b49020/u-boot/tree/v5_dt
> - Patch
On Fri, Feb 02, 2024 at 01:04:03PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> U-Boot binary has grown in such a way that it goes beyond the reserved
> area for the environment variables.
>
> Running "saveenv" and rebooting the board c
From: Fabio Estevam
U-Boot binary has grown in such a way that it goes beyond the reserved
area for the environment variables.
Running "saveenv" and rebooting the board causes U-Boot to hang because
of this overlap.
Fix this problem by selecting CONFIG_LTO so that the U-B
On Thu, Feb 01, 2024 at 10:48:48PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> U-Boot binary has grown in such a way that it goes beyond the reserved
> area for the environment variables.
>
> Running "saveenv" and rebooting the board c
Changes in v5:
--
- Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41)
- Created v5_dt branch for testing purposes:
https://github.com/b49020/u-boot/tree/v5_dt
- Patch #6: Added support to cherry-pick fixes in subtree update script.
Also, used https:// instead
From: Fabio Estevam
U-Boot binary has grown in such a way that it goes beyond the reserved
area for the environment variables.
Running "saveenv" and rebooting the board causes U-Boot to hang because
of this overlap.
Fix this problem by increasing the CONFIG_ENV_OFFSET.
Dear U-Boot Community,
I am working on porting mainline U-Boot to a standard MT7620A wireless router,
specifically the ZBT WE826-T2 (https://openwrt.org/toh/zbtlink/we-826). After
building and flashing the mainline U-Boot, I'm encountering an issue where
there is no output over UART.
So far
v2024.04-rc1 (2024-01-29 20:53:19 -0500)
>
> are available in the Git repository at:
>
> https://source.denx.de/u-boot/custodians/u-boot-amlogic.git
> tags/u-boot-amlogic-fixes-20240201
>
> for you to fetch changes up to 076529725f16f07a5cb2d5feba25d62b5f5a5872:
>
&
On Thu, Feb 01, 2024 at 11:50:43AM +0100, Stefan Roese wrote:
> Hi Tom,
>
> please pull the following watchdog related last minute fixes:
>
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Hi Tom,
Please pull this simple fix avoiding printing the board model twice.
Thanks,
Neil
The following changes since commit 6faba41927bdc8973b59678649ef83c564cc421e:
Prepare v2024.04-rc1 (2024-01-29 20:53:19 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot
Hi,
I just found out that u-boot has some support for RT117x, this is great! I
could not find a better forum to ask, I will appreciate a redirect.
I need u-boot to boot from the SPI NOR flash, I have the EVKB evaluation
board. The SPL that is generated is not ELF and no instructions of how
://dev.azure.com/sr0718/u-boot/_build/results?buildId=339=results
Thanks,
Stefan
The following changes since commit b6d8969bcb94321dfed1399f2eaa8768ba42caaa:
Merge tag 'u-boot-at91-2024.04-a' of
https://source.denx.de/u-boot/custodians/u-boot-at91 (2024-01-31
10:44:33 -0500)
are available
On 2024/1/27 06:14, Jonas Karlman wrote:
Add a default u-boot,spl-boot-order prop to rk3588s-u-boot.dtsi and
remove the prop from board u-boot.dtsi files using the default value.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3588-nanopc-t6-u
bootph-pre-ram doesn't make
U-Boot proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's
a lookup
for devices by code running before the relocation. Such is the
case of
env_init() which calls env_driver_lookup() which calls
env_get_locati
Schulz wrote:
Hi Kever,
On 1/24/24 11:35, Kever Yang wrote:
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram
node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot
pr
On Wed, Jan 31, 2024 at 05:43:49PM +0200, Eugen Hristev wrote:
> Hello Tom,
>
> Please pull tag u-boot-at91-2024.04-a , the first set of at91 features
> for 2024.04 cycle.
>
> This set includes some DT alignments and solves a compile issue for custom
> nand
> defconfi
Hello Tom,
Please pull tag u-boot-at91-2024.04-a , the first set of at91 features
for 2024.04 cycle.
This set includes some DT alignments and solves a compile issue for custom nand
defconfigs.
Thanks,
Eugen
The following changes since commit 3c04fcf3137d5f694d52b8f355373e4baabe5f78:
Merge
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. Add a U-Boot specific dtsi snippet so that this supply will
get enabled when initialising USB.
Signed-off-by: Caleb Connolly
---
arch/arm
On Wed, Jan 31, 2024 at 06:21:34PM +0800, Leo Liang wrote:
> Hi Tom,
>
> The following changes since commit 28760ce8640ff6266bd1c1c568a4a231576f3919:
>
> Merge tag 'clk-2024.04-rc2' of
> https://source.denx.de/u-boot/custodians/u-boot-clk (2024-01-30 07:54:28
> -050
On Wed, Jan 31, 2024 at 03:33:45PM +0200, Roger Quadros wrote:
> Hi,
>
> MUX driver should autoprobe if the device tree has "idle-states"
> property. Drop using the custom "u-boot,mux-autoprobe" property
> in TI device trees.
Thanks for doing this.
--
T
On Wed, Jan 31, 2024 at 06:26:54PM +0530, Sumit Garg wrote:
[snip]
> So I did a demo experiment for this here [1] where cherry picking DT
> fixes into subtree just worked fine with the next uprev. Steps
> followed:
>
> $ cd /
> $ git remote add dt-rebasing
>
MUX driver should autoprobe if the device tree has "idle-states"
property. Drop using the custom "u-boot,mux-autoprobe" property.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi| 4
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
As it is present for USB and USB won't work without the MUX
initialized correctly, add "bootph-all" property to MUX nodes.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi| 4
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8
Hi,
MUX driver should autoprobe if the device tree has "idle-states"
property. Drop using the custom "u-boot,mux-autoprobe" property
in TI device trees.
cheers,
-roger
Roger Quadros (3):
mux: autoprobe if "idle-states" present in device tree
arm: dts: k3-u-b
;>>>
> >>>> The reason why rgmii-txid worked because the rx delay was not
> >>>> disabled by
> >>>> the driver so essentially we ended up with rgmii-id PHY mode.
> >>>>
> >>>> Signed-off-by: Peter Ujfal
Hi Tom,
The following changes since commit 28760ce8640ff6266bd1c1c568a4a231576f3919:
Merge tag 'clk-2024.04-rc2' of
https://source.denx.de/u-boot/custodians/u-boot-clk (2024-01-30 07:54:28 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot
On 1/30/24 00:55, Tom Rini wrote:
Here's the latest report.
-- Forwarded message -
From:
Date: Mon, Jan 29, 2024 at 6:51 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To:
Hi,
Please find the latest report on new defect(s) introduced to Das
U-Boot found
Hey all,
It's release day and here is -rc1. Looking at my own queue, I think
things are largely set. There's some cleanups, but they can likely wait
until -next to open after -rc3. There's also some PRs I would still like
to see come in.
In terms of a changelog,
git log --merges
Here's the latest report.
-- Forwarded message -
From:
Date: Mon, Jan 29, 2024 at 6:51 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To:
Hi,
Please find the latest report on new defect(s) introduced to Das
U-Boot found with Coverity Scan.
1 new defect(s
On Mon, Jan 29, 2024 at 11:23:25PM +0530, Jagan Teki wrote:
> Hi Tom,
>
> Please pull this PR.
>
> Summary:
> - Support Infineon S28HS02GT (Takahiro)
>
> CI:
> - https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/19467
>
> thanks,
> Jagan.
>
esting for all 167 sunxi boards, and Linux
> boot testing on some selected boards.
>
> Please pull!
>
> Cheers,
> Andre
>
> ==
> The following changes since commit 526a865fe4fea59fb2638726c26e39557eb97fdd:
>
> Merge branch 'master-cleanup' of
> ht
Hi Tom,
Please pull this PR.
Summary:
- Support Infineon S28HS02GT (Takahiro)
CI:
- https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/19467
thanks,
Jagan.
The following changes since commit 526a865fe4fea59fb2638726c26e39557eb97fdd:
Merge branch 'master-cleanup' of
https
On Mon, 29 Jan 2024 12:34:18 -0500
Tom Rini wrote:
Hi Tom,
> On Mon, Jan 29, 2024 at 05:24:49PM +, Andre Przywara wrote:
> > On Mon, 29 Jan 2024 15:55:43 +
> > Andre Przywara wrote:
> >
> > Hi Tom,
> >
> > > please pull the sunxi/master branch, containing the first part of the
>
On Mon, Jan 29, 2024 at 05:24:49PM +, Andre Przywara wrote:
> On Mon, 29 Jan 2024 15:55:43 +
> Andre Przywara wrote:
>
> Hi Tom,
>
> > please pull the sunxi/master branch, containing the first part of the
>
> I just saw that the CI pipeline failed on missing maintainer entries for
>
> Please pull!
>
> Cheers,
> Andre
>
> ==
> The following changes since commit 526a865fe4fea59fb2638726c26e39557eb97fdd:
>
> Merge branch 'master-cleanup' of
> https://source.denx.de/u-boot/custodians/u-boot-sh (2024-01-27 20:43:20 -0500)
>
> are availa
fdd:
Merge branch 'master-cleanup' of
https://source.denx.de/u-boot/custodians/u-boot-sh (2024-01-27 20:43:20 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
for you to fetch changes up to 539612e27690a8df7f197cd1e9f4c2cf6ee1ac64
, Kever Yang wrote:
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram
node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot
proper
bind the device before relocation.
While this
y at:
>
> https://source.denx.de/u-boot/custodians/u-boot-sh.git master-cleanup
>
> for you to fetch changes up to 8a725c610675846b380d865ad68c2295cf15782e:
>
> ARM: renesas: whitehawk: Drop extra leading space (2024-01-27 20:17:04
> +0100)
>
Applied to u-boot/master, th
for Das U-Boot
To:
Hi,
Please find the latest report on new defect(s) introduced to Das
U-Boot found with Coverity Scan.
1 new defect(s) introduced to Das U-Boot found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 479279:(TAINTED_SCALAR
The following changes since commit fea3efb757f7a9c6831c023cb456f9fa5fd0278e:
Kconfig: boot: Imply BOOTSTD_DEFAULT when BOOTSTD_FULL=y (2024-01-19 18:30:08
-0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-sh.git master-cleanup
for you to fetch
Am 27. Januar 2024 16:40:18 MEZ schrieb Tom Rini :
>Hey, I'll just pass this on directly rather than to the list.
>
>-- Forwarded message -
>From:
>Date: Sat, Jan 27, 2024 at 10:36 AM
>Subject: New Defects reported by Coverity Scan for Das U-Boot
>To:
&g
On 1/27/24 00:14, Jonas Karlman wrote:
> Add a default u-boot,spl-boot-order prop to rk3588s-u-boot.dtsi and
> remove the prop from board u-boot.dtsi files using the default value.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Eugen Hristev
> ---
> arch/arm/dts/rk3588-nan
Add a default u-boot,spl-boot-order prop to rk3588s-u-boot.dtsi and
remove the prop from board u-boot.dtsi files using the default value.
Signed-off-by: Jonas Karlman
---
arch/arm/dts/rk3588-nanopc-t6-u-boot.dtsi | 6 --
arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi | 6 --
arch
Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram
node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot
proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's
commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram
node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot
proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's a
lookup
for devices by code running before the
/sram
node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's a lookup
for devices by code running before the relocation. Such is the case of
env_init() which calls env_dri
;), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's a lookup
for devices by code running before the relocation. Such is the case of
env_init() which calls env_driver_lookup() which calls
env_get_locati
every SoC (or really, board) has to opt-in to OF_UPSTREAM
to start with. With that, I see switching to OF_UPSTREAM meaning that
there's a commitment to keeping up with dts change in upstream dts that
might lead to issues within U-Boot. Do you still feel it would be better
to have the re-sync _also_ be per
F_UPSTREAM
to start with. With that, I see switching to OF_UPSTREAM meaning that
there's a commitment to keeping up with dts change in upstream dts that
might lead to issues within U-Boot. Do you still feel it would be better
to have the re-sync _also_ be per custodian tree? That might be a
dation to use
> synced DTs. Eventually things will stabilize and vendors will start
> switching over.
To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM
to start with. With that, I see switching to OF_UPSTREAM meaning that
there's a commitment to keeping up with dts change in upstream dts that
might lead to issues within U-Boot. Do you still feel it would be better
to have the re-sync _also_ be per custodian tree? That might be a bit
harder to handle.
--
Tom
signature.asc
Description: PGP signature
On 1/25/24 16:04, Tom Rini wrote:
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
But at this point we have to move away from apprehensions about DT ABI
breakages and provide real examples of the DT ABI breakages in the
past. Are you aware of any DT ABI breaking change
On Wed, Jan 17, 2024 at 12:55:46PM +0200, Svyatoslav Ryhel wrote:
> It seems that the U-Boot console entry of the bootmenu has lost
> its original meaning. Now, even if it is chosen, the probability
> that you will enter the actual U-Boot console is quite low.
> Boot env, bootflow,
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote:
[snip]
> But at this point we have to move away from apprehensions about DT ABI
> breakages and provide real examples of the DT ABI breakages in the
> past. Are you aware of any DT ABI breaking change backported to Linux
> stable
For some time I have been trying to understand how to build an embedded
Linux to my terasic de10-standard board, without success.
After booting the provided Linux image that is available for download
from the terasic website, I was able to check the following information:
U-Boot: 2013.01.01
>>>> has some defect that is fixed in 6.6.1, how will that fix get into
> >>>> U-Boot DTs ?
> >>>
> >>> This fix would also be in the latest Linux tags, so I think it would
> >>> find its way here - as I understand it patches aren'
On 1/24/24 09:16, Sumit Garg wrote:
Hi,
How do you propose to handle fixes to DTs which are applied to
linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which
has some defect that is fixed in 6.6.1, how will that fix get into
U-Boot DTs ?
This fix would also be in the latest
Add support for driver model where EEPROM data are read in draco board.
Reviewed-by: Alexander Sverdlin
Signed-off-by: Enrico Leto
---
configs/draco-etamin_defconfig | 4 +++-
configs/draco-rastaban_defconfig | 4 +++-
configs/draco-thuban_defconfig | 4 +++-
3 files changed, 9
Hi Kever,
On 1/24/24 11:35, Kever Yang wrote:
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the dev
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.
While this is usuall
however have one comment about the upcoming sync process:
> > > >
> > > > > ...
> > > > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather
> > > > > use devicetree-rebasing repo [3] which is a forked copy from Linux
&g
) ships a DT which
> >> has some defect that is fixed in 6.6.1, how will that fix get into
> >> U-Boot DTs ?
> >
> > This fix would also be in the latest Linux tags, so I think it would
> > find its way here - as I understand it patches aren't accepted into
> > Li
gt; > something which would be problematic for specific U-Boot platform (e.g.
> > > i.MX) or would require a lot of work to sort out, will there be a way to
> > > temporarily pin DTs for specific platform to older DT version until that
> > > is resolved (e.g. pin to 6.n) ?
&
ree-rebasing git repo to be added as a
> > subtree to the main U-Boot repo via:
> >
> > $ git subtree add --prefix dts/upstream \
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > \
>
> Please use https
On 20:28-20240123, Apurva Nandan wrote:
>
[...]
> > in j784s4-binman.dtsi:
> >
> >
> >{
> > j784s4_tiboot3_hs_fs_template: template-9 {
> >
> > and then in sk.dtsi:
> sk.dtsi means sk-uboot.dtsi or sk-binman.dtsi?
you wont need an sk-binman.dtsi with template. sk-u-boot.dtsi and
on the block
device number associated with the MMC device the SPL used to load U-Boot
proper from. It is NOT related to the mmc alias in the Device Tree.
For SPI flashes, all SPI flashes will return BOOT_DEVICE_SPI so there's
currently no way to know from which one the SPL loaded U-Boot proper
from
Garg wrote:
> > >
> > > Hi,
> > >
> > > I certainly welcome this more automatic synchronisation of the DTs,
> > > however have one comment about the upcoming sync process:
> > >
> > > > ...
> > > > However, Linux kernel DT
t3-j784s4-hs-evm.bin {
+ filename = "tiboot3-j784s4-hs-evm.bin";
+
https://lore.kernel.org/u-boot/20240103174756.xa4rzbn4klk5gv2x@aware/
You haven't responded on thread why
"Prefer #1 - j784s4 binman template" is not feasible or not desirable.
501 - 600 of 354836 matches
Mail list logo
