On 26.10.20 14:42, Daniel Schwierzeck wrote:
Am Freitag, den 16.10.2020, 15:08 +0200 schrieb Stefan Roese:
Octeon has a specific boot header, when booted via SPI NOR, NAND or MMC.
Here the only 2 instructions are allowed in the first few bytes of the
image. And these instructions need to be one
Display the bias information for input gpios or AF configuration,
and not only for output pin, as described in Reference manual
(Table 81. Port bit configuration table).
Fixes: da7a0bb1f279 ("pinctrl: stm32: add information on pin configuration")
Signed-off-by: Patrick Delaunay
---
Use the bias configuration for all the GPIO configurations and not
only for input GPIO, as indicated in Reference manual
(Table 81. Port bit configuration table).
Fixes: 43efbb6a3ebf0223f9eab8d45916f602d876319f ("gpio: stm32: add ops
get_dir_flags")
Fixes:
From: Max Krummenacher
The I2C address is 0x25, not 0x35. This according to the datasheet and
tests with a PCA9450A.
Signed-off-by: Max Krummenacher
---
drivers/power/pmic/pca9450.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pca9450.c
From: Max Krummenacher
The used PMIC has been changed from RHOM BD71837 to NXP PCA9450A.
Adjust the device tree accordingly.
Remove the old ADC node as the ADC has been changed and has no longer
a separate power rail.
Signed-off-by: Max Krummenacher
Signed-off-by: Igor Opaniuk
---
From: Marcel Ziswiler
Add new i.MX 8M Mini/Plus SKUs to ConfigBlock handling:
0058: Verdin iMX8M Plus Quad 4GB Wi-Fi / BT IT
0059: Verdin iMX8M Mini Quad 2GB IT
0060: Verdin iMX8M Mini DualLite 1GB WB IT
0061: Verdin iMX8M Plus Quad 2GB
Rename existing SKU (use correct one):
Verdin iMX8M
From: Marcel Ziswiler
Now with them first Verdin iMX8M Mini DualLite modules in for bring-up
we got clarity how is_cpu_type() actually behaves.
Signed-off-by: Marcel Ziswiler
---
board/toradex/common/tdx-cfg-block.c | 26 +-
1 file changed, 9 insertions(+), 17
From: Marcel Ziswiler
Implement board_phys_sdram_size() to automatically detect Verdin iMX8M
Mini DualLite 1GB vs. Verdin iMX8M Mini Quad 2GB.
Note: This only works if we keep using similar RAM chips!
Signed-off-by: Marcel Ziswiler
---
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 10
From: Igor Opaniuk
Add SPL_DM_PMIC_PCA9450 symbol to Kconfig.
Signed-off-by: Igor Opaniuk
---
drivers/power/pmic/Kconfig | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index a62aa38054..7d51510d1b 100644
---
From: Max Krummenacher
V1.1A HW switched the PMIC from BD71837 to PCA9450.
- Disable combined DVS in PCA9450_BUCK123_DVS.
- Increase DDR Voltage to 0.95V as we use a 1.5GHz RAM.
- Configure WDOG_B behaviour.
Signed-off-by: Max Krummenacher
Signed-off-by: Igor Opaniuk
---
From: Max Krummenacher
And select the correct devicetree accordingly by setting the variant
environment variable.
Signed-off-by: Igor Opaniuk
Signed-off-by: Max Krummenacher
---
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 71 +
1 file changed, 71 insertions(+)
diff
From: Max Krummenacher
Enable PCA9450 i2c level translator, as this is used for the
on module ADC.
Signed-off-by: Max Krummenacher
---
board/toradex/verdin-imx8mm/spl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/toradex/verdin-imx8mm/spl.c
This patch series adds pin control support for RZ/G2[HN] SoC's.
Also added pinctrl optimization for RZ/G2[HMN] SoC's.
This patches are based on u-boot-sh/next.
+ Geert
The last 3 patches in this series are RFC, which aims to optimize pinctrl
size for RCar SoC 's( The u-boot size is reduced
Renesas RZ/G2H (r8a774e1) is pin compatible with R-Car H3 (r8a77951),
however it doesn't have several automotive specific peripherals. Add
a r8a77951 specific pin groups/functions along with common pin
groups/functions for supporting both r8a77951 and r8a774e1 SoC.
PFC changes are synced from
This driver supports both RZ/G2M and R-Car M3-W/W+ SoCs.
Optimize pinctrl image size for RZ/G2M, when support for R-Car M3-W/W+
(R8A7796[01]) is not enabled.
Based on the similar patch on Linux.
Signed-off-by: Biju Das
---
drivers/pinctrl/renesas/pfc-r8a7796.c | 12
1 file
Renesas RZ/G2N (r8a774b1) is pin compatible with R-Car M3-N (r8a77965),
however it doesn't have several automotive specific peripherals. Add
a r8a77965 specific pin groups/functions along with common pin
groups/functions for supporting both r8a77965 and r8a774b1 SoC.
PFC changes are synced from
Optimize pinctrl image size by disabling pins which are not used
by u-boot (ie, not enabled in board dts file)
Signed-off-by: Biju Das
---
drivers/pinctrl/renesas/Kconfig | 6
drivers/pinctrl/renesas/pfc-r8a7796.c | 44 +--
2 files changed, 40 insertions(+),
This driver supports both RZ/G2N and R-Car M3-N SoCs.
Optimize pinctrl image size for RZ/G2N, when support for R-Car M3-N
(R8A77965) is not enabled.
Based on the simialr patch on Linux.
Signed-off-by: Biju Das
---
drivers/pinctrl/renesas/pfc-r8a77965.c | 12
1 file changed, 12
Optimize pinctrl image size by disabling pins which are not used
by u-boot(ie, not enabled in board dts file).
Signed-off-by: Biju Das
---
drivers/pinctrl/renesas/pfc-r8a7795.c | 52 +++
1 file changed, 38 insertions(+), 14 deletions(-)
diff --git
Optimize pinctrl image size by disabling pins which are not used
by u-boot (ie, not enabled in board dts file).
Signed-off-by: Biju Das
---
drivers/pinctrl/renesas/pfc-r8a77965.c | 48 +++---
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git
This driver supports both RZ/G2H and R-Car H3 SoCs.
Optimize pinctrl image size for RZ/G2H, when support for R-Car H3
(R8A7795) is not enabled
Based on the similar patch on Linux.
Signed-off-by: Biju Das
---
drivers/pinctrl/renesas/pfc-r8a7795.c | 14 --
1 file changed, 12
Hi,
> From: Ard Biesheuvel
> Sent: mardi 27 octobre 2020 22:05
>
> On Tue, 27 Oct 2020 at 18:25, Tom Rini wrote:
> >
> > On Fri, Oct 09, 2020 at 05:00:44PM +, Patrick DELAUNAY wrote:
> > > Hi Ard,
> > >
> > > > From: Ard Biesheuvel
> > > > Sent: mercredi 7 octobre 2020 15:16
> > > >
> > >
On Wednesday 28 October 2020 06:42:39 Heiko Schocher wrote:
> Am 26.10.2020 um 22:48 schrieb Pali Rohár:
> > On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
> > > Am 26.04.2020 um 01:54 schrieb Pali Rohár:
> > > > On Saturday 25 April 2020 14:11:32 Pali Rohár wrote:
> > > > > On Saturday 25
Update pin name to avoid duplicated name with SOC GPIO
gpio0...gpio15 / agpio0agpio7: add a stmfx prefix.
This pin name can be used in pinmux command.
Signed-off-by: Patrick Delaunay
---
drivers/pinctrl/pinctrl-stmfx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
The device name is used in pinmux command and in log trace
so it is better to use the parent parent name ("stmfx@42" for
example) than a generic name ("pinctrl" or "stmfx-gpio")
to identify the device instance.
Signed-off-by: Patrick Delaunay
---
drivers/pinctrl/pinctrl-stmfx.c | 5 -
1
Allow pin name parameter for pimux staus command,
as gpio command to get status of one pin.
The possible usage of the command is:
> pinmux dev pinctrl
> pinmux status
> pinmux status -a
> pinmux status
Signed-off-by: Patrick Delaunay
---
cmd/pinmux.c | 41
Update the result of do_status and alway returns a CMD_RET_ value
(-ENOSYS was a possible result of show_pinmux).
This patch also adds pincontrol name in error messages (dev->name)
and treats correctly the status sub command when pin-controller device is
not selected.
Signed-off-by: Patrick
Hi Marek,
> Subject: RE: [PATCH v2 3/5] pinctrl: renesas: r8a77965: Add R8A774B1 PFC
> support
>
> Hi Marek,
>
> > Subject: Re: [PATCH v2 3/5] pinctrl: renesas: r8a77965: Add R8A774B1
> > PFC support
> >
> > On 10/14/20 1:29 PM, Biju Das wrote:
> >
> > Hi,
> >
> > [...]
> >
> > Check with
>-Original Message-
>From: Tom Rini
>Sent: Wednesday, October 28, 2020 3:58 AM
>To: Michael Walle
>Cc: u-boot@lists.denx.de; Priyanka Jain ; Kuldeep
>Singh ; Heiko Thiery
>Subject: Re: [PATCH v9 0/2] Basic Kontron SMARC-sAL28 board support
>
>On Tue, Oct 27, 2020 at 11:23:23PM +0100,
On 18.10.20 14:56, Baruch Siach wrote:
The kfree() call is unreachable, and is not needed. Remove this call and
the fail_disable_clk label.
Signed-off-by: Baruch Siach
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 12 +++-
1 file changed, 3
On 18.10.20 14:56, Baruch Siach wrote:
From: Shmuel Hazan
Based on Linux kernel commit fc256f5789cb ("mtd: nand: pxa3xx: enable
NAND controller if the SoC needs it"). This commit adds support for the
Armada 8040 nand controller.
The kernel commit says this:
Marvell recent SoCs like
On 18.10.20 14:56, Baruch Siach wrote:
From: Shmuel Hazan
Please add at least a minimal commit text here.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
---
drivers/mtd/nand/raw/Kconfig | 2 +
drivers/mtd/nand/raw/pxa3xx_nand.c | 117 +
2
The following changes since commit 986c980c8250849d9394fdf377a3de75edb11888:
nokia_rx51: re-enable CONSOLE_MUX and SYS_CONSOLE_IS_IN_ENV
(2020-10-27 10:48:08 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2021-01-rc2
for you
Hi Simon,
> From: Simon Glass
> Sent: lundi 26 octobre 2020 20:23
>
> Hi Patrick,
>
> On Thu, 15 Oct 2020 at 09:59, Patrick DELAUNAY
> wrote:
> >
> > Hi Simon,
> >
> > > From: Simon Glass
> > > Sent: jeudi 15 octobre 2020 17:06
> > >
> > > Hi Patrick,
> > >
> > > On Wed, 14 Oct 2020 at
On 18.10.20 14:56, Baruch Siach wrote:
From: Shmuel Hazan
Align node properties to kernel dts node.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Signed-off-by: Shmuel Hazan
Signed-off-by: Baruch Siach
Reviewed-by: Stefan Roese
Thanks,
On 18.10.20 14:56, Baruch Siach wrote:
Align node properties to kernel dts node.
The change of compatible property does not affect any currently
supported board.
Keep U-Boot specific nand-enable-arbiter, and num-cs for compatibility
with the current driver.
Signed-off-by: Baruch Siach
Hi Marek,
> From: Patrick DELAUNAY
> Sent: mercredi 28 octobre 2020 10:49
>
> Use the bias configuration for all the GPIO configurations and not only for
> input
> GPIO, as indicated in Reference manual (Table 81. Port bit configuration
> table).
>
> Fixes:
Hi Marek,
> From: Marek Vasut
> Sent: vendredi 23 octobre 2020 17:04
>
> On 10/23/20 4:39 PM, Patrick DELAUNAY wrote:
>
> Hi,
>
> [...]
>
> From: Marek Vasut
> Sent: lundi 19 octobre 2020 23:38
>
> The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
>
USB clocks were completely forgotten as driver would always return 0 even if
clock ID was unknown.
This behaviour changed with "IPQ40xx: clk: dont always return 0" and this will
now causes the USB-s to fail probing as clock enable will return -EINVAL.
So to fix that lets add all of the USB
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
PX30.Core needs to mount on top of Engicam baseboards for creating
complete platform boards.
Possible baseboards are,
- EDIMM2.2 Starter Kit
- C.TOUCH 2.0
Note: dts patches are in Linux mailing-list.
Changes for v4:
- rebase on
Currently the driver will go through the clock ID-s and set/enable them as
needed.
But if the ID is unknown it will fall through the switch case to the default
case which will always return 0.
This is not correct and default cases should return a error code since clock ID
is unknown.
So lets
Lets convert the driver to use dev_read_addr() instead of the devfdt_get_addr().
While we are here, lets also alphabetise the includes.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
arch/arm/mach-ipq40xx/clock-ipq4019.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
There is no point in having break statements in the switch case as there is
already a return before break.
So lets drop them from the driver.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
arch/arm/mach-ipq40xx/clock-ipq4019.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
On Fri, Oct 2, 2020 at 12:10 AM Heiko Stuebner wrote:
>
> From: Heiko Stuebner
>
> The SRAM on the PX30 is not big enough to hold multiple DDR configs
> so it needs to be selected during build.
>
> So far simply the DDR3 config was always selected and getting DDR4
> or LPDDR2/3 initialized would
Add a tool to update or insert an Octeon specific header into the U-Boot
image. This is needed e.g. for booting via SPI NOR, eMMC and NAND.
While working on this, move enum cvmx_board_types_enum and
cvmx_board_type_to_string() to cvmx-bootloader.h and remove the
unreferenced (unsupported) board
Octeon has a specific boot header, when booted via SPI NOR, NAND or MMC.
Here the only 2 instructions are allowed in the first few bytes of the
image. And these instructions need to be one branch and a nop. This
patch adds the necessary nop after the nop, to that the common MIPS
image is
With this patch, gd->ram_size now holds to full RAM size detected by the
DDR init code. It introduces the get_effective_memsize() function to
report the maximum usable RAM size in U-Boot to the system instead.
Signed-off-by: Stefan Roese
Cc: Aaron Williams
Cc: Chandrakala Chavva
Cc: Daniel
Using ram_get_info() is complicated and does not work after relocation.
Now that gd->ram_size holds the full RAM size, let's use it instead and
remove the ram_get_size logic completely.
Signed-off-by: Stefan Roese
Cc: Aaron Williams
Cc: Chandrakala Chavva
Cc: Daniel Schwierzeck
---
v2:
- No
Don't use "platdata_auto_alloc_size" but "priv_auto_alloc_size" instead
to auto allocate the private data struct, which is referenced via
dev_get_priv() in this driver. This fixes an ugly bug detected while
trying to boot via SPI NOR.
Signed-off-by: Stefan Roese
Cc: Aaron Williams
Cc:
From: Michael Trimarchi
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
General features:
- Rockchip PX30
- Up to 2GB DDR4
- eMMC 4 GB expandible
- rest of PX30 features
PX30.Core needs to mount on top of Engicam baseboards for creating
complete platform boards.
Possible
TARGET_EVB_PX30 can be possible to use other px30 boards.
Add the help text for existing EVB, so-that the new boards
which are resuing this config option can mention their board
help text.
This would help to track which boards are using EVB_PX30 config.
Signed-off-by: Jagan Teki
Reviewed-by:
Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
Evaluation Board.
Genaral features:
- LCD 7" C.Touch
- microSD slot
- Ethernet 1Gb
- Wifi/BT
- 2x LVDS Full HD interfaces
- 3x USB 2.0
- 1x USB 3.0
- HDMI Out
- Mini PCIe
- MIPI CSI
- 2x CAN
- Audio Out
SOM's like PX30.Core
The existing common code for Engicam boards uses i.MX6,
so attach that into i.MX6 Engicam boards so-that adding
new SoC variants of Engicam boards become meaningful.
Add support for it.
Cc: Stefano Babic
Signed-off-by: Jagan Teki
---
Changes for v4:
- none
board/engicam/common/Kconfig | 8
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
Evaluation Board from Engicam.
PX30.Core needs to mount on top of this Evaluation board for
creating complete PX30.Core EDIMM2.2 Starter Kit.
Add support for it.
Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose
carrier board with capacitive touch interface.
Genaral features:
- TFT 10.1" industrial, 1280x800 LVDS display
- Ethernet 10/100
- Wifi/BT
- USB Type A/OTG
- Audio Out
- CAN
- LVDS panel connector
SOM's like PX30.Core needs to mount on
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
C.TOUCH 2.0 is a general purpose carrier board with capacitive
touch interface support.
PX30.Core needs to mount on top of this Carrier board for creating
complete PX30.Core C.TOUCH 2.0 board.
Add support for it.
Signed-off-by:
This would be useful and recommended boot flow for new boards
which has doesn't have the DDR support yet in mainline.
Sometimes it is very useful for debugging mainline DDR support.
Documen it for px30 boot flow.
Signed-off-by: Jagan Teki
---
Changes for v4:
- none
Dear GlovePuppet,
In message <1603813411162-0.p...@n7.nabble.com> you wrote:
> Required by TPM2 Extended Auth, cloned from sha1.c
>
> Signed-off-by: GlovePuppet
NAK.
The Submitting Patches rules require using your real name (sorry, no
pseudonyms or anonymous contributions.)
See [1] for
Dear GlovePuppet,
In message <1603813495996-0.p...@n7.nabble.com> you wrote:
> Unseals a loaded object, identified by handle, and returns
> data at a memory location or in an environment variable
>
> Caveats
>
> -The PolicyPCR command only supports one PCR
> -The auth request code only supports
Use the full name of firmware self extracting file to make it run.
Also, don't use sudo when not needed.
Signed-off-by: Baruch Siach
---
This time add the u-boot list to Cc.
---
board/freescale/imx8mp_evk/README | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Hi Daniel,
On 26.10.20 14:31, Daniel Schwierzeck wrote:
diff --git a/tools/update_octeon_header.c b/tools/update_octeon_header.c
new file mode 100644
index 00..964036216d
--- /dev/null
+++ b/tools/update_octeon_header.c
@@ -0,0 +1,450 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
On Wed, Oct 28, 2020 at 12:43:43PM +0100, Heinrich Schuchardt wrote:
> The following changes since commit 986c980c8250849d9394fdf377a3de75edb11888:
>
> nokia_rx51: re-enable CONSOLE_MUX and SYS_CONSOLE_IS_IN_ENV
> (2020-10-27 10:48:08 -0400)
>
> are available in the Git repository at:
>
>
On Sat, Oct 17, 2020 at 02:31:57PM +0200, Heinrich Schuchardt wrote:
> Replace the static variable processing_msg by a field in the global data.
> Make the field bool at it can only be true or false.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
Applied to u-boot/master,
On Sat, Oct 17, 2020 at 02:31:58PM +0200, Heinrich Schuchardt wrote:
> Some drivers use macro pr_cont() for continuing a message sent via printk.
> Hence if we want to convert printk messaging to using the logging system,
> we must support continuation of log messages too.
>
> As pr_cont() does
Dear maintainers,
Any thoughts on this? It seems that "sf probe" behaviour should either
get fixed, or we should remove the "hz" and "mode" arguments entirely,
since they don't work anymore.
Regards,
Ralph
On Thu, Oct 15, 2020 at 12:25:41PM -0400, Ralph Siemsen wrote:
Hi,
The "sf probe"
On Fri, Oct 23, 2020 at 01:00:01PM +0200, Heinrich Schuchardt wrote:
> The log command has led to NULL dereferences if an unknown category name
> name was used due to missing entries in the list of category names.
>
> Add compile time checks for the array sizes of log_cat_name and
> log_lvl_name
On Sat, Oct 17, 2020 at 02:31:59PM +0200, Heinrich Schuchardt wrote:
> Provide a unit test checking that a continuation message will use the same
> log level and log category as the previous message.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
Applied to u-boot/master,
The uSD slot card-detect GPIO is connected to PG1, fix it.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
arch/arm/dts/stm32mp15xx-dhcom.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
The QSPI CS2 is not used on DHCOM, remove the pinmux and flash@1.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
arch/arm/dts/stm32mp15xx-dhcom.dtsi | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
On 10/28/20 11:20 AM, Patrick DELAUNAY wrote:
> Hi Marek,
Hello Patrick,
[...]
>>> But after investigation the internall pull-up is not configurated in
>>> stm32 pinctrol (cheked with pinmux command) even it is requested in device-
>> tree of EV1/DK2.
>>>
>>> It is clearly a bug (I isolate the
This feature is incompatble with of-platdata since it uses the
U_BOOT_DEVICE() macro. With of-platdata the only devices permitted are
those created by dtoc.
Drop this option for now, until the driver can be corrected.
Signed-off-by: Simon Glass
---
include/configs/mx6cuboxi.h | 2 --
1 file
Dear Neil
I have a question about vim3 board.
When i have build with mainline u-boot, i have faced on below problem.
(I have referred to doc/board/amlogic/khadas-vim3.rst)
Do you know why failed like below?
$fip/aml_encrypt_g12b --bl2sig --input fip/bl2_new.bin --output
fip/bl2.n.bin.sig
This is a utility mainly for test purpose.
mkeficapsule -f: create a test capsule file for FIT image firmware
Having said that, you will be able to customize the code to fit
your specific requirements for your platform.
Signed-off-by: AKASHI Takahiro
---
tools/Makefile | 2 +
On Thu, Oct 29, 2020 at 09:25:11AM +0900, AKASHI Takahiro wrote:
> #
> # This is a reminder. Nothing changed, but rebasing.
> #
Wasn't one of the outstanding requests to make the DFU related changes
less intrusive and thus easier to review by someone (me) who is not the
primary author of the DFU
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a raw image capsule,
CONFIG_EFI_CAPSULE_RAW.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on
Maxime mentioned that he feels not having the time to be an Allwinner
maintainer anymore. Take over from him.
Maxime, many thanks for your great work in the past! I hope I can still
relay the occasional technical question to you in the future.
Cc: Maxime Ripard
Signed-off-by: Andre Przywara
The range of an addressable pointer can go beyond 'integer'.
So change the argument type to a void pointer.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Heinrich Schuchardt
---
common/update.c | 3 ++-
drivers/dfu/dfu_alt.c | 6 +++---
include/dfu.h | 4 ++--
3 files changed, 7
The main purpose of this patch is to separate a generic interface for
updating firmware using DFU drivers from "auto-update" via tftp.
This function will also be used in implementing UEFI capsule update
in a later commit.
Signed-off-by: AKASHI Takahiro
---
common/Kconfig | 15 ++
This function is essentially independent from tftp, and will also be
utilised in implementing UEFI capsule update in a later commit.
So just give it a more generic name.
In addition, a new configuration option, CONFIG_DFU_ALT, was introduced
so that the file will be compiled with different
On Thu, Oct 29, 2020 at 09:59:12AM +0900, AKASHI Takahiro wrote:
> Tom,
>
> On Wed, Oct 28, 2020 at 08:30:49PM -0400, Tom Rini wrote:
> > On Thu, Oct 29, 2020 at 09:25:11AM +0900, AKASHI Takahiro wrote:
> >
> > > #
> > > # This is a reminder. Nothing changed, but rebasing.
> > > #
> >
> >
Tom,
On Wed, Oct 28, 2020 at 11:22:29PM -0400, Tom Rini wrote:
> On Thu, Oct 29, 2020 at 09:59:12AM +0900, AKASHI Takahiro wrote:
> > Tom,
> >
> > On Wed, Oct 28, 2020 at 08:30:49PM -0400, Tom Rini wrote:
> > > On Thu, Oct 29, 2020 at 09:25:11AM +0900, AKASHI Takahiro wrote:
> > >
> > > > #
> >
Tom,
On Wed, Oct 28, 2020 at 08:30:49PM -0400, Tom Rini wrote:
> On Thu, Oct 29, 2020 at 09:25:11AM +0900, AKASHI Takahiro wrote:
>
> > #
> > # This is a reminder. Nothing changed, but rebasing.
> > #
>
> Wasn't one of the outstanding requests to make the DFU related changes
> less intrusive
I found why failed. Discard this mail.
Best Regards,
Jaehoon Chung
On 10/29/20 9:11 AM, Jaehoon Chung wrote:
> Dear Neil
>
> I have a question about vim3 board.
> When i have build with mainline u-boot, i have faced on below problem.
> (I have referred to doc/board/amlogic/khadas-vim3.rst)
>
On Wed, Oct 28, 2020 at 11:22:29PM -0400, Tom Rini wrote:
> On Thu, Oct 29, 2020 at 09:59:12AM +0900, AKASHI Takahiro wrote:
> > Tom,
> >
> > On Wed, Oct 28, 2020 at 08:30:49PM -0400, Tom Rini wrote:
> > > On Thu, Oct 29, 2020 at 09:25:11AM +0900, AKASHI Takahiro wrote:
> > >
> > > > #
> > > > #
Hi Simon,
Adding Walter to Cc.
On Thu, Oct 29 2020, Simon Glass wrote:
> This feature is incompatble with of-platdata since it uses the
> U_BOOT_DEVICE() macro. With of-platdata the only devices permitted are
> those created by dtoc.
>
> Drop this option for now, until the driver can be
In this commit, a very simple firmware management protocol driver
is implemented. It will take a common FIT image firmware in a capsule
file and apply the data using dfu backend storage drivers via
update_fit() interface.
So "dfu_alt_info" variable should be properly set to specify a device
and
A capsule tagged with the guid, EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID,
is handled as a firmware update object.
What efi_update_capsule() basically does is to load any firmware management
protocol (or fmp) drivers contained in a capsule, find out an appropriate
fmp driver and then invoke its
Memory range capsule gives us a way to notify that some memory regions
should be left untouched across the next reset.
See UEFI specification, section 8.5.3.
Since how we should handle this kind of capsule is totally up to
the system, no implementation will be added in this commit.
In this commit, a very simple firmware management protocol driver
is implemented. It will take a binary image in a capsule file and
apply the data using dfu backend storage drivers via dfu_write_by_alt()
interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location
"efidebug capsule" is more or less a debugging utility.
efidebug capsule update: invoke UpdateCapsule against data on memory
efidebug capsule show: show a capsule header
efidebug capsule result: dump a capsule result variable
Signed-off-by: AKASHI Takahiro
---
cmd/efidebug.c | 235
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a FIT image capsule,
CONFIG_EFI_CAPSULE_FIT.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on
This is a utility mainly for test purpose.
mkeficapsule -f: create a test capsule file for FIT image firmware
Having said that, you will be able to customize the code to fit
your specific requirements for your platform.
Signed-off-by: AKASHI Takahiro
---
tools/Makefile | 2 +
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a raw image capsule,
CONFIG_EFI_CAPSULE_RAW.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on
This function is a variant of dfu_write_by_name() and takes a DFU alt
setting number for dfu configuration.
It will be utilised to implement UEFI capsule management protocol for
raw image in a later commit.
Signed-off-by: AKASHI Takahiro
---
drivers/dfu/dfu_alt.c | 47
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.
In this commit, we will support capsule on disk mechanism.
In this commit, skeleton functions for capsule-related API's are
added under CONFIG_EFI_UPDATE_CAPSULE configuration.
Detailed implementation for a specific capsule type will be added
in the succeeding patches.
Signed-off-by: AKASHI Takahiro
---
include/efi_api.h| 12 +++
This variable will be utilized to enumerate all dfu entities
for UEFI capsule firmware update in a later commit.
Signed-off-by: AKASHI Takahiro
---
drivers/dfu/dfu.c | 2 +-
include/dfu.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dfu/dfu.c
This function will be used from several places in UEFI subsystem
to generate some specific form of utf-16 variable name.
For example, L"Capsule0001"
Signed-off-by: AKASHI Takahiro
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_setup.c | 30 ++
2 files
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.
In this commit, we will support capsule on disk mechanism.
In this commit, skeleton functions for capsule-related API's are
added under CONFIG_EFI_UPDATE_CAPSULE configuration.
Detailed implementation for a specific capsule type will be added
in the succeeding patches.
Signed-off-by: AKASHI Takahiro
---
include/efi_api.h| 12 +++
1 - 100 of 130 matches
Mail list logo
