fdtdec_get_addr_size_no_parent is not an optimized version if parent
node is already available with the caller.
Use fdtdec_get_addr_size_auto_parent to read the "reg" property
Signed-off-by: Atish Patra
---
arch/riscv/lib/fdt_fixup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This series has few small assorted fixes related to reserved memory support
in RISC-V and EFI.
The series is rebased on top of the following series
http://patchwork.ozlabs.org/project/uboot/patch/1591767391-2669-2-git-send-email-bmeng...@gmail.com/
Changes from v1->v2:
1. Rebased on top of the
fdtdec_get_addr_size reads the uses a fixed value for address & size
cell properties which may not be correct always.
Use the auto variant of the function which automatically reads
#address-cells & #size-cells from parent and uses to read the "reg"
property.
Signed-off-by: Atish Patra
---
Not all errors are fatal. If a reserved memory node already exists in the
destination device tree, we can continue to boot without failing.
Signed-off-by: Atish Patra
---
arch/riscv/lib/fdt_fixup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/lib/fdt_fixup.c
As per kernel commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode)
the correct phy-mode should be "rgmii-id", so fix it accordingly
to fix the Ethernet regression.
This problem has been exposed by commit:
commit 13114f38e2ccea9386726d8b9831dfc310589548
Author: Vladimir Oltean
Date:
Sync the device tree with 5.8-rc1.
It basically contains the following extra kernel commit:
commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09
Author: Russell King
Date: Wed Apr 15 16:44:17 2020 +0100
ARM: dts: imx6-sr-som: add ethernet PHY configuration
Add ethernet PHY configuration
As we move towards driver model, it is required to let the FEC driver
know how to properly deal with an Ethernet PHY subnode in the device tree.
For example:
{
pinctrl-names = "default";
pinctrl-0 = <_microsom_enet_ar8035>;
phy-handle = <>;
phy-mode =
Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
Driver Model.
This also brings the benefit of restoring Ethernet functionality.
Reported-by: Tom Rini
Signed-off-by: Fabio Estevam
Tested-by: Tom Rini
---
Changes since v2:
- Removed extra Signed-off-by
The clock ouput frequency is calculated incorrectly for AR8035 due to
wrong masking of priv->clk_25m_reg and priv->clk_25m_mask.
This same issue has been already fixed in the kernel by:
commit b1f4c209d84057b6d40b939b6e4404854271d797
Author: Oleksij Rempel
Date: Wed Apr 1 11:57:32 2020 +0200
On Fri, Jun 19, 2020 at 12:02:17AM +0200, Simon Guinot wrote:
> On Thu, Jun 18, 2020 at 11:15:14PM +0530, Jagan Teki wrote:
> Hi Jagan,
>
> > This board has not been converted to CONFIG_DM by the deadline.
>
> Is that possible to negociate a new deadline ?
Well, when will you be able to spend
On Thu, Jun 18, 2020 at 11:15:14PM +0530, Jagan Teki wrote:
Hi Jagan,
> This board has not been converted to CONFIG_DM by the deadline.
Is that possible to negociate a new deadline ?
Thanks in advance.
Simon
>
> Remove it.
>
> Cc: Simon Guinot
> Signed-off-by: Jagan Teki
> ---
> Changes
On Thu, Jun 18, 2020 at 4:51 PM Marek Vasut wrote:
>
> On 6/18/20 11:14 PM, Adam Ford wrote:
> > Add R8A774A1 PFC tables based on Renesas' repo based on 2018.09.
>
> It seems linux/next uses the same file for 7796 and 774a1 , can we do
> the same for U-Boot ?
That looks encouraging. I'll try
On 6/18/20 11:14 PM, Adam Ford wrote:
> Add R8A774A1 PFC tables based on Renesas' repo based on 2018.09.
It seems linux/next uses the same file for 7796 and 774a1 , can we do
the same for U-Boot ?
On 6/18/20 11:46 PM, Adam Ford wrote:
[...]
>>> regulator 0 [ + ] fixed regulator |-- regulator0
>>> regulator 1 [ + ] fixed regulator |-- regulator1
>>> regulator 2 [ ] fixed regulator |-- regulator_audio
>>> regulator 3 [ ] fixed regulator
On 18.06.20 23:25, Fabio Estevam wrote:
> On Thu, Jun 18, 2020 at 6:16 PM Fabio Estevam wrote:
>>
>> Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
>> Driver Model.
>>
>> This also brings the benefit of restoring Ethernet functionality.
>>
>> Reported-by: Tom Rini
>>
On Thu, Jun 18, 2020 at 4:33 PM Marek Vasut wrote:
>
> On 6/18/20 11:20 PM, Adam Ford wrote:
>
> Hi,
>
> [...]
>
> >> Can you provide 'dm tree' output ?
> >
> > => dm tree
> > Class Index Probed DriverName
> > ---
> >
On 6/18/20 11:20 PM, Adam Ford wrote:
Hi,
[...]
>> Can you provide 'dm tree' output ?
>
> => dm tree
> Class Index Probed DriverName
> ---
> root 0 [ + ] root_driver root_driver
> clk
On Thu, Jun 18, 2020 at 4:20 PM Adam Ford wrote:
>
> On Thu, Jun 18, 2020 at 4:00 PM Marek Vasut wrote:
> >
> > On 6/18/20 10:33 PM, Adam Ford wrote:
> > > I am trying to port U-Boot to a new product based on a Renesas RZ/G2M
> > > (rcar-gen3). We're have this working with Renesas' version from
On Thu, Jun 18, 2020 at 6:16 PM Fabio Estevam wrote:
>
> Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
> Driver Model.
>
> This also brings the benefit of restoring Ethernet functionality.
>
> Reported-by: Tom Rini
> Signed-off-by: Fabio Estevam
>
> Signed-off-by: Fabio
On Thu, Jun 18, 2020 at 4:00 PM Marek Vasut wrote:
>
> On 6/18/20 10:33 PM, Adam Ford wrote:
> > I am trying to port U-Boot to a new product based on a Renesas RZ/G2M
> > (rcar-gen3). We're have this working with Renesas' version from
> > 2018.09, but I am trying to integrate it with U-Boot
The clock ouput frequency is calculated incorrectly for AR8035 due to
wrong masking of priv->clk_25m_reg and priv->clk_25m_mask.
This same issue has been already fixed in the kernel by:
commit b1f4c209d84057b6d40b939b6e4404854271d797
Author: Oleksij Rempel
Date: Wed Apr 1 11:57:32 2020 +0200
Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
Driver Model.
This also brings the benefit of restoring Ethernet functionality.
Reported-by: Tom Rini
Signed-off-by: Fabio Estevam
Signed-off-by: Fabio Estevam
Tested-by: Tom Rini
---
Changes since v1:
- Remove header -
Sync the device tree with 5.8-rc1.
It basically contains the following extra kernel commit:
commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09
Author: Russell King
Date: Wed Apr 15 16:44:17 2020 +0100
ARM: dts: imx6-sr-som: add ethernet PHY configuration
Add ethernet PHY configuration
As we move towards driver model, it is required to let the FEC driver
know how to properly deal with an Ethernet PHY subnode in the device tree.
For example:
{
pinctrl-names = "default";
pinctrl-0 = <_microsom_enet_ar8035>;
phy-handle = <>;
phy-mode =
This patch imports the device tree and required bindings to permit
the device tree to build for the R8Z774A1 (RZ/G2M).
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/r8a774a1.dtsi b/arch/arm/dts/r8a774a1.dtsi
new file mode 100644
index 00..a603d94797
--- /dev/null
+++
In order to build boards based on the R8A774A1, there needs to
be a config option from which to enable other drivers and/or flags
for this SoC.
Signed-off-by: Adam Ford
diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index c8f93c68bb..bfd513a361 100644
---
The renesas-shdi controller can drive the r8a774a1 and shares its
quirks with R8A7796. This patch adds the compatibilty flag, to
support the SDHI controller.
Signed-off-by: Adam Ford
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index d6ea99d2ce..8b8e300caf 100644
---
This sync's the clock tables with the official release from
Renesas' repo based on U-Boot 2018.09 and modified to build into
the latest version of U-Boot.
Signed-off-by: Adam Ford
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index e78817829b..284e2138b3 100644
---
The R8A774A1 (RZ/G2M) a commercial SoC based off the automotive
R8A7796 SoC.
This series will start the foundation to support this SoC by importing
porting the device tree and bindings from Linux 5.8-rc1, then porting
the clock driver, pinctrl driver, and sdhi drivers from Renesas'
RZG2M repo
Hi Tom,
please pull some fixes for v2020.07-rc4. Thanks!
gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3720
The following changes since commit 9cb895203a46654f7ee6dd95be5c8ab05e4dfbd3:
Merge tag 'u-boot-stm32-20200616' of
Hi Anatolij,
On Wed, Jun 10, 2020 at 6:53 AM Ye Li wrote:
>
> Update video bmp codes to support 8 bits BMP to 32 bits conversion
> so that we can display 8 bits logo on 24 bits or 32 bits display
>
> Signed-off-by: Ye Li
I haven't had a chance to test this yet, but it seems to solve an
On Thu, 2020-06-18 at 21:34 +0200, Michael Nazzareno Trimarchi wrote:
> > Looks like the pinctrl driver. This *ought* to work (with the caveat
> > that I really ought to make two pinctrl setups and change between them
> > according to the voltage, like the Linux DT and mtk-sd driver do).
> >
> >
On 6/18/20 10:33 PM, Adam Ford wrote:
> I am trying to port U-Boot to a new product based on a Renesas RZ/G2M
> (rcar-gen3). We're have this working with Renesas' version from
> 2018.09, but I am trying to integrate it with U-Boot 2020.07-rc4
>
> What's happening is that it seems like all GPIO
- Add guestfstools, efitools
- Latest Ubuntu/bionic snapshot
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 2 +-
.gitlab-ci.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 636500d6cead..28387ce17cae 100644
Hi Tom,
please pull first video updates for -next. Thanks!
gitlab CI:
https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3716
The following changes since commit 7a81989b7b04bd87d1e684f2bafdc92a9c16fecc:
common: hash: Remove a debug printf statement (2020-06-16 11:36:30 -0400)
I am trying to port U-Boot to a new product based on a Renesas RZ/G2M
(rcar-gen3). We're have this working with Renesas' version from
2018.09, but I am trying to integrate it with U-Boot 2020.07-rc4
What's happening is that it seems like all GPIO are failing to be
requested, so things like
Hi David
On Thu, Jun 18, 2020 at 9:21 PM David Woodhouse wrote:
>
> On Thu, 2020-06-18 at 16:52 +0100, David Woodhouse wrote:
> > So... whose bug is that? :)
>
> Looks like the pinctrl driver. This *ought* to work (with the caveat
> that I really ought to make two pinctrl setups and change
Thanks Peng,
Could we update the state of this patch set in the patchwork DB as done? It
still at state “New”.
> On Jun 17, 2020, at 3:14 PM, Peng Fan wrote:
>
> It has been applied, could you check tom's master tree?
>
>> -Original Message-
>> From: Alex Nemirovsky
Hi Fabio,
On Thu, 18 Jun 2020 at 22:07, Fabio Estevam wrote:
>
> Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
> Driver Model.
>
> This also brings the benefit of restoring Ethernet functionality.
>
> Reported-by: Tom Rini
> Signed-off-by: Fabio Estevam
> ---
>
On Thu, Jun 18, 2020 at 04:05:22PM -0300, Fabio Estevam wrote:
> As we move towards driver model, it is required to let the FEC driver
> know how to properly deal with an Ethernet PHY subnode in the device tree.
>
> For example:
>
> {
> pinctrl-names = "default";
> pinctrl-0 =
On Thu, Jun 18, 2020 at 04:05:24PM -0300, Fabio Estevam wrote:
> Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
> Driver Model.
>
> This also brings the benefit of restoring Ethernet functionality.
>
> Reported-by: Tom Rini
> Signed-off-by: Fabio Estevam
Tested-by: Tom
On Thu, Jun 18, 2020 at 04:05:23PM -0300, Fabio Estevam wrote:
> Sync the device tree with 5.8-rc1.
>
> It basically contains the following extra kernel commit:
>
> commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09
> Author: Russell King
> Date: Wed Apr 15 16:44:17 2020 +0100
>
> ARM:
On Thu, Jun 18, 2020 at 04:05:21PM -0300, Fabio Estevam wrote:
> The clock ouput frequency is calculated incorrectly for AR8035 due to
> wrong masking of priv->clk_25m_reg and priv->clk_25m_mask.
>
> This same issue has been already fixed in the kernel by:
>
> commit
On Tue, Jun 16, 2020 at 09:40:40AM +0200, Patrick Delaunay wrote:
> Add the absolute path to the default value of
> CONFIG_ENV_EXT4_FILE = "/uboot.env".
>
> This patch avoid the error :
> Saving Environment to EXT4... File System is consistent
> Please supply Absolute path
>
>
Hi Fabio,
Thanks for your debug and fix. Small nits below.
On Thu, Jun 18 2020, Fabio Estevam wrote:
> Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
> Driver Model.
>
> This also brings the benefit of restoring Ethernet functionality.
>
> Reported-by: Tom Rini
>
On Tue, Jun 16, 2020 at 09:40:41AM +0200, Patrick Delaunay wrote:
> Add a missing initialization of gd->env_valid in env_ext4_load
> as it is already done in some other env device.
>
> Set gd->env_valid = ENV_VALID in env_ext4_save() and env_ext4_load().
>
> This patch allows to have a correct
On Thu, 2020-06-18 at 16:52 +0100, David Woodhouse wrote:
> So... whose bug is that? :)
Looks like the pinctrl driver. This *ought* to work (with the caveat
that I really ought to make two pinctrl setups and change between them
according to the voltage, like the Linux DT and mtk-sd driver do).
On Tue, Jun 16, 2020 at 09:40:44AM +0200, Patrick Delaunay wrote:
> Add support of environment location with a new sandbox command
> 'env_loc'.
>
> When the user change the environment location with the command
> 'env_loc ' the env is reinitialized and saved;
> the GD_FLG_ENV_DEFAULT flag is
On Tue, Jun 16, 2020 at 09:40:42AM +0200, Patrick Delaunay wrote:
> Don't return error with ret=-ENOENT when the optional ops drv->init
> is absent but only if env_driver_lookup doesn't found driver.
>
> This patch correct an issue for the code
> if (!env_init())
> env_load()
> When only
Sync the device tree with 5.8-rc1.
It basically contains the following extra kernel commit:
commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09
Author: Russell King
Date: Wed Apr 15 16:44:17 2020 +0100
ARM: dts: imx6-sr-som: add ethernet PHY configuration
Add ethernet PHY configuration
As we move towards driver model, it is required to let the FEC driver
know how to properly deal with an Ethernet PHY subnode in the device tree.
For example:
{
pinctrl-names = "default";
pinctrl-0 = <_microsom_enet_ar8035>;
phy-handle = <>;
phy-mode =
Migration to DM_ETH is mandatory, so convert mx6cuboxi to Ethernet
Driver Model.
This also brings the benefit of restoring Ethernet functionality.
Reported-by: Tom Rini
Signed-off-by: Fabio Estevam
---
board/solidrun/mx6cuboxi/mx6cuboxi.c | 123 ---
The clock ouput frequency is calculated incorrectly for AR8035 due to
wrong masking of priv->clk_25m_reg and priv->clk_25m_mask.
This same issue has been already fixed in the kernel by:
commit b1f4c209d84057b6d40b939b6e4404854271d797
Author: Oleksij Rempel
Date: Wed Apr 1 11:57:32 2020 +0200
The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
unsupported, reinstate the old cd-gpios behavior until this handling
is fully implemented. This permits the DHSOM to boot from SD again,
without this patch the card detect fails.
Signed-off-by: Marek Vasut
Cc: Patrick Delaunay
On Wed, Jun 17, 2020 at 12:44:08AM +0900, Daniel Palmer wrote:
> Hi all,
>
> I'm attempting to get initial support for MStar/Sigmastar's family of
> ARMv7 chips into Linux
> and I thought I should probably at least attempt to mainling the
> u-boot support while I'm at it.
>
> I did some
On Thu, Jun 18, 2020 at 12:19 AM Bin Meng wrote:
>
> Hi Atish,
>
> On Thu, Jun 18, 2020 at 3:04 PM Atish Patra wrote:
> >
> > On Wed, Jun 17, 2020 at 5:46 PM Bin Meng wrote:
> > >
> > > Hi Atish,
> > >
> > > On Thu, Jun 18, 2020 at 7:51 AM Atish Patra wrote:
> > > >
> > > >
On Thu, Jun 18, 2020 at 07:25:43PM +0530, Lokesh Vutla wrote:
> Hi Tom,
> Please find the pull request for v2020.10 next containing TI specific
> changes.
>
> Travis-CI build:
> https://travis-ci.org/github/lokeshvutla/u-boot/builds/698883325
>
> The following changes since commit
t:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git
> tags/u-boot-amlogic-20200618
>
> for you to fetch changes up to 9c55f5d11260c5aa0f91d8cb32aa0ad00910659d:
>
> board: amlogic: add board doc files to MAINTAINERS (2020-06-18 10:24:13
> +0200)
>
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Enable DM_SPI, DM_SPI_FLASH for db-88f6281-bp-nand board.
Cc: Chris Packham
Signed-off-by: Jagan Teki
---
Changes for v3:
- new patch
configs/db-88f6281-bp-nand_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/db-88f6281-bp-nand_defconfig
This board has not been converted to CONFIG_DM by the deadline.
Remove it.
Patch-cc: Simon Guinot
Signed-off-by: Jagan Teki
---
Changes for v3:
- new patch
arch/arm/mach-kirkwood/Kconfig| 4 -
board/LaCie/netspace_v2/Kconfig | 12 --
This board has not been converted to CONFIG_DM by the deadline.
Remove it.
Cc: Simon Guinot
Signed-off-by: Jagan Teki
---
Changes for v3:
- new patch
arch/arm/mach-kirkwood/Kconfig | 4 -
board/LaCie/net2big_v2/Kconfig | 12 --
board/LaCie/net2big_v2/MAINTAINERS | 7 -
Series of kirkwood boards to switch DM_SPI and drop
which are not DM enabled still.
Any inputs?
Jagan.
Bhargav Shah (1):
spi: kirkwood: Drop nondm code
Jagan Teki (3):
arm: Remove d2net_v2 board
db-88f6281-bp-nand: Enable DM_SPI/SPI_FLASH
arm: Remove netspace_v2 board
From: Bhargav Shah
Drop the nondm code from kirkwood_spi.c since there
is no board or any other code using for it.
Signed-off-by: Bhargav Shah
Signed-off-by: Jagan Teki
---
Changes for v3:
- updated commit message
- updated config_whitelist.txt
drivers/spi/Kconfig | 12 ++--
Hi
On Thu, Jun 18, 2020 at 6:07 PM Jagan Teki wrote:
>
> On Thu, Jun 18, 2020 at 12:54 PM Maxime Ripard wrote:
> >
> > On Thu, Jun 18, 2020 at 01:54:37AM +0530, Jagan Teki wrote:
> > > DM_VIDEO migration deadline is already expired, but around
> > > 80 Allwinner boards are still using video in
On Thu, Jun 18, 2020 at 09:41:22PM +0530, Lokesh Vutla wrote:
>
>
> On 18/06/20 9:15 pm, Tom Rini wrote:
> > On Thu, Jun 18, 2020 at 07:25:43PM +0530, Lokesh Vutla wrote:
> >
> >> Hi Tom,
> >>Please find the pull request for v2020.10 next containing TI specific
> >> changes.
> >>
> >>
On Thu, Jun 18, 2020 at 04:19:51PM +, Tom Warren wrote:
> No worries, I can fix it when I add them to u-boot-tegra. I have some other
> patches to add & generate a PR, I'll get it out by EOW. TomR - do you want
> me to take this patch as well as the ARM: tegra: patch in my PR, or do you
>
On Mon, Jun 15, 2020 at 12:07 AM Yegor Yefremov
wrote:
>
> On Sat, Jun 13, 2020 at 8:01 PM Jagan Teki wrote:
> >
> > On Wed, May 27, 2020 at 6:26 PM Jagan Teki
> > wrote:
> > >
> > > Enable DM_SPI for am355x baltos board.
> > >
> > > Build is fine, but not tested.
> > >
> > > Cc: Yegor
No worries, I can fix it when I add them to u-boot-tegra. I have some other
patches to add & generate a PR, I'll get it out by EOW. TomR - do you want me
to take this patch as well as the ARM: tegra: patch in my PR, or do you want
Jon's first patch to go thru a different repo?
Tom
--
nvpublic
On Sat, Jun 13, 2020 at 5:51 PM Jagan Teki wrote:
>
> This is rebased v2 for previous version spi dm-conversion
> series[1] on fsl_espi boards.
>
> All these patches dropped the boards which are not converted
> spi dm and also the maintainer is accepted to remove the
> same.
> Rest of the patches
Rock Pi N8 is a Rockchip RK3288 based SBC, which has
- VMARC RK3288 SOM (as per SMARC standard) from Vamrs.
- Compatible carrier board from Radxa.
VAMRC RK3288 SOM need to mount on top of radxa dalang
carrier board for making Rock Pi N8 SBC.
So, add initial support for Rock Pi N8 by including
VMARC RK3288 SOM is a standard SMARC SOM design with
Rockchip RK3288 SoC, which is designed by Vamrs.
Specification:
- Rockchip RK3288
- PMIC: RK808
- SD slot, 16GiB eMMC
- 2xUSB-2.0, 1xUSB3.0
- USB-C for power supply
- Ethernet, PCIe
- HDMI, MIPI-DSI/CSI, eDP
Add initial support for VMARC
Radxa dalang carrier boards are used to mount vmarc SoM's
of rk3399pro and rk3288 to make complete SBC.
Among these combinations, card detection gpio, max-frequency
properties are used with rk3399pro SoM but not required for
rk3288 SoM based on the hardware schematics.
So, let's move these sdmmc
Rock Pi N8 is a Rockchip RK3288 based SBC, which has
- VMARC RK3288 SOM (as per SMARC standard) from Vamrs.
- Compatible carrier board from Radxa.
VMARC RK3288 SOM need to mount on top of dalang carrier
board for making Rock PI N8 SBC.
All these respective dts patches are in Linux mainling list.
On 18/06/20 9:15 pm, Tom Rini wrote:
> On Thu, Jun 18, 2020 at 07:25:43PM +0530, Lokesh Vutla wrote:
>
>> Hi Tom,
>> Please find the pull request for v2020.10 next containing TI specific
>> changes.
>>
>> Travis-CI build:
>>
roc-rk3399-pc has some specific requirements to support LEDS,
environment. board detection and etc prior to U-Boot proper.
So as of now SPL would be a better stage for these custom board
requirements to support unlike TPL. Adding few of these custom
requirements like LEDS in TPL would require
spl_board_init is a proper location and common practice
option to have a custom board initialization code after
relocation in SPL.
This patch add the feasibility to add the custom SPL board
initzlaization throughout rockchip platforms and adjust
existing the spl board code on respective boards.
ROC-RK3399-PC has specific set of configurations for
on-board led setup.
Due to easiness for user to know the state of the board
roc-rk339-pc board code will setup the low power led
on/off, and waiting for user to press power key and then
glow full power led.
All this needs to happen only during
reset cause is a generic functionality based on the soc
cru registers in rockchip. This can be used for printing
the cause of reset in cpuinfo or some other place where
reset cause is needed.
Other than cpuinfo, reset cause can also be using during
bootcount for checking the specific reset cause
Usually printing the SPL banner varies between architecture
or board codes.
- Some would print before relocation at the end board_init_f
for making sure all initialization prior to this would happen
properly. if at all there is a requirement for serial init,
that happens properly since it
On Thu, Jun 18, 2020 at 12:54 PM Maxime Ripard wrote:
>
> On Thu, Jun 18, 2020 at 01:54:37AM +0530, Jagan Teki wrote:
> > DM_VIDEO migration deadline is already expired, but around
> > 80 Allwinner boards are still using video in a legacy way.
> >
> > = WARNING
This series supports custom initialization code required for
roc-rk3399-pc board on SPL stage.
Here is the previous v3 this series[1].
Now this series is well mature code handling to add custom
spl_board_init code parts.
roc-rk3399-pc would require custom leds initialization based
on user
Hi Tom,
On Thu, Jun 18, 2020 at 10:38 AM Tom Rini wrote:
> What else do I need with this to test it myself? This alone doesn't do
> it (but I'm not surprised) and adding the 2 DM_ETH patches you sent to
> convert the platform still gives the "Could not get PHY for FEC0: addr
> 0" error
On Tue, 2020-06-16 at 22:12 +0100, David Woodhouse wrote:
> On Tue, 2020-06-16 at 21:38 +0200, Michael Nazzareno Trimarchi wrote:
> > Have you already tried to dump the pinmux using the cmd? in both
> > situation?
>
> U-Boot> pinmux status -a
On 18/06/2020 12:54, Jon Hunter wrote:
> When CONFIG_OF_LIVE is enabled, dev_of_offset() cannot be used and
> if used returns an invalid offset. This causes the call to
> fdt_stringlist_get() in the psci_probe() to fail to read the 'method'
> property from the PSCI node for the device and hence
On Thu, Jun 18, 2020 at 07:25:43PM +0530, Lokesh Vutla wrote:
> Hi Tom,
> Please find the pull request for v2020.10 next containing TI specific
> changes.
>
> Travis-CI build:
> https://travis-ci.org/github/lokeshvutla/u-boot/builds/698883325
>
> The following changes since commit
On Thu, Jun 18, 2020 at 12:55 PM Jon Hunter wrote:
>
> When CONFIG_OF_LIVE is enabled, dev_of_offset() cannot be used and
> if used returns an invalid offset. This causes the call to
> fdt_stringlist_get() in the psci_probe() to fail to read the 'method'
> property from the PSCI node for the
On Thu, Jun 18, 2020 at 12:56 PM Jon Hunter wrote:
>
> The PSCI nodes are currently not populated for the Tegra210 and Tegra186
> devices. This prevents the PSCI driver from being able to identify the
> PSCI method used by these devices and causes the probe of the PSCI
> driver to fail.
>
> Since
On 05.06.2020 11:43, Gregory CLEMENT wrote:
> Hello,
>
> a few months ago I submitted a small series allowing to run SPL with
> DTB append. Indeed according to the linker BSS section was all the
> time separated for SPL but the symbol SPL_SEPARATE_BSS was only
> enabled on some boards.
>
> In
On 05.06.2020 09:51, Eugen Hristev wrote:
> arch/arm/dts/at91-sama5d4ek.dtb: Warning (graph_endpoint):
> /ahb/gadget@0040/endpoint@10: graph node unit address error, expected "a"
> arch/arm/dts/at91-sama5d4ek.dtb: Warning (graph_endpoint):
> /ahb/gadget@0040/endpoint@11: graph node unit
From: Pascal Vizeli
Add a proper Odroid-N2 board support to handle the Ethernet MAC
address stored in the in-SoC eFuses.
Signed-off-by: Pascal Vizeli
Signed-off-by: Neil Armstrong
---
board/amlogic/odroid-n2/MAINTAINERS | 7 +
board/amlogic/odroid-n2/Makefile| 6
From: Heiko Stuebner
n, rr and rrtmp are used for internal calculations, but in the end
the results are copied into separately allocated elements of the
actual key_prop, so the n, rr and rrtmp elements are not used anymore
when returning from the function and should of course be freed.
From: Heiko Stuebner
Verifying FIT images obviously needs the rsa parts of crypto
support and while main uboot always compiles crypto support,
it's optional for SPL and we should thus select the necessary
option to not end up in compile errors like:
u-boot/lib/rsa/rsa-verify.c:328:
From: Heiko Stuebner
padding_pss_verify only works with the default pss salt setting of -2
(length to be automatically determined based on the PSS block structure)
not -1 (salt length set to the maximum permissible value), which makes
verifications of signatures with that saltlen fail.
Until
From: Heiko Stuebner
When calculating rrtmp/rr rsa_gen_key_prop() tries to make
(((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and
(((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[]
with rlen being num_bits * 2
On a 4096bit key this comes down to to 257 uint32_t elements
in rr and
From: Heiko Stuebner
rsa-checsum needs support for hash functions or else will run into
compile errors like:
u-boot/lib/rsa/rsa-checksum.c:28: undefined reference to
`hash_progressive_lookup_algo'
So similar to the main FIT_SIGNATURE entry selects HASH,
select SPL_HASH_SUPPORT for
From: Heiko Stuebner
Right now in multiple places there are only checks for the full
CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants.
This breaks when the rsa functions get enabled for SPL, for example to
verify u-boot proper from spl.
So fix this by using the existing
From: Heiko Stuebner
The exponent field of struct key_prop gets allocated an uint64_t,
and the contents are positioned from the back, so an exponent of
"0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1"
Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len
to the size
From: Heiko Stuebner
While the SPL may want to do signature checking this won't be
the case for TPL in all cases, as TPL is mostly used when the
amount of initial memory is not enough for a full SPL.
So on a system where SPL uses DM but TPL does not we currently
end up with a TPL compile error
Adjust the ENV offset, size to fit into all images
on 16MB flash.
Signed-off-by: Jagan Teki
---
Changes for v2:
- rebase on master
configs/rock-pi-4-rk3399_defconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/configs/rock-pi-4-rk3399_defconfig
Enable DWC3 core, gadget for roc-rk3399-pc board.
This would help to use fastboot by default.
Signed-off-by: Jagan Teki
---
Changes for v2:
- rebase on master
configs/rock-pi-4-rk3399_defconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/configs/rock-pi-4-rk3399_defconfig
1 - 100 of 135 matches
Mail list logo
