AM65x SoC has two USB subsystems and their corresponding device tree nodes
have the same name but different path. While allocating sequence numbers
for these device tree nodes using alias, phandles can be used to
distinguish them.
Enable config for phandle check while getting sequence number to
Hi Adam,
Thanks for the reply.
> -Original Message-
> Subject: Re: [PATCH] spi: renesas_rpc_spi: Fix fallback compatibility
> string
>
> On Tue, Jan 5, 2021 at 6:08 AM Biju Das
> wrote:
> >
> > Hi Adam,
> >
> > Thanks for the patch.
> >
> > > -Original Message-
> > > From: Adam
On 12/22/20 6:58 PM, Sean Anderson wrote:
This series depends on
https://patchwork.ozlabs.org/project/uboot/list/?series=200642
Changes in v5:
- Rebase on u-boot/master
Changes in v4:
- Fix build error without CONFIG_CLK
Changes in v3:
- Note dependency on "time: Fix get_ticks being
Hi Tom,
Please pull some riscv updates:
- Update qemu-riscv.rst build instructions.
- Add support for SPI on Kendryte K210.
- Add Microchip PolarFire SoC Icicle Kit support.
Thanks
Rick
CI: passed
https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/5853
The following changes
On Tue, Jan 12, 2021 at 03:30:53PM +0900, Jaehoon Chung wrote:
> Remove board_mmc_init function.
> It will be probed with driver-model.
>
> Signed-off-by: Jaehoon Chung
> ---
> arch/arm/mach-exynos/include/mach/dwmmc.h | 2 --
> board/samsung/arndale/arndale.c | 13 -
> 2
Hi Simon,,
On Wed, Jan 13, 2021 at 11:39 AM Simon Glass wrote:
>
> Hi,
>
> (This has been discussed for a while now so I thought I would just try it)
>
> As an experiment I'd like to set up a regular 30-minute U-Boot call
> for people to discuss features, bugs, patches, etc.
>
> The meeting
Hi,
(This has been discussed for a while now so I thought I would just try it)
As an experiment I'd like to set up a regular 30-minute U-Boot call
for people to discuss features, bugs, patches, etc.
The meeting notes and details are here[1].
Please feel free to send this to others. I cc'd a
Hi Peng,
On Wed, Jan 13, 2021 at 12:05 AM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> Drop CONFIG_SYS_[I,D]CACHE_OFF, it is safe to run with caches enabled on
> these platforms.
>
> Signed-off-by: Peng Fan
Reviewed-by: Fabio Estevam
> Subject: Re: [PATCH] imx: imx8mn/p: drop CONFIG_SYS_[I,D]CACHE_OFF in
> SPL stage
>
> Hi Peng,
>
> On Tue, Jan 12, 2021 at 11:29 PM Peng Fan (OSS)
> wrote:
> >
> > From: Peng Fan
> >
> > Drop CONFIG_SYS_[I,D]CACHE_OFF in SPL stage
>
> These options do not apply to SPL. The
Hi Peng,
On Tue, Jan 12, 2021 at 11:29 PM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> Drop CONFIG_SYS_[I,D]CACHE_OFF in SPL stage
These options do not apply to SPL. The CONFIG_SPL_SYS_ICACHE_OFF and
CONFIG_SPL_SYS_DCACHE_OFF do.
I agree with the change, but I think you need:
- Remove SPL
Hi,
It seems both U-Boot and Linux kernel spi-nor drivers have the same
assumption on dummy cycles required in a fast read command.
In U-Boot spi_nor_read_data(), there is a logic to calculate the dummy
bytes needed for fast read command:
/* convert the dummy cycles to the number of bytes
fit_check_format() must check that the buffer contains a flattened device
tree before calling any device tree library functions.
Failure to do may cause segmentation faults.
Signed-off-by: Heinrich Schuchardt
---
common/image-fit.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
> Subject: [PATCH 2/2] mmc: exynos_dw_mmc: remove unused function
>
> Remove unused function in exynos_dw_mmc.c.
>
> Signed-off-by: Jaehoon Chung
Reviewed-by: Peng Fan
> ---
> drivers/mmc/exynos_dw_mmc.c | 56 -
> 1 file changed, 56 deletions(-)
>
> diff
> Subject: [PATCH 1/2] samsung: arndale: remove board_mmc_init function
>
> Remove board_mmc_init function.
> It will be probed with driver-model.
>
> Signed-off-by: Jaehoon Chung
Reviewed-by: Peng Fan
> ---
> arch/arm/mach-exynos/include/mach/dwmmc.h | 2 --
>
> Subject: [PATCH V2] imx: Add support for i.MX8MN Beacon EmbeddedWorks
> devkit.
>
> Beacon EmbeddedWorks is releasing a devkit based on the i.MX8M
> Nano SoC consisting of baseboard + SOM.
>
> The kit is based on the same design as the Beacon dev kit with
> the i.MX8M Mini.
>
> Signed-off-by:
Update the RZ/G2H dtsi from Renesas repo destined to become 5.12-rc1.
Signed-off-by: Adam Ford
---
arch/arm/dts/r8a774e1.dtsi | 1374 +++-
1 file changed, 1347 insertions(+), 27 deletions(-)
diff --git a/arch/arm/dts/r8a774e1.dtsi b/arch/arm/dts/r8a774e1.dtsi
The Beacon EmbeddedWorks kit is based on the R8A774E1 SoC also
known as the RZ/G2H.
The kit consists of a SOM + Baseboard and supports microSD,
eMMC, Ethernet, a couple celular radios, two CAN interfaces,
Bluetooth and WiFi. It shares much of the same design as
the RZ/G2M and RZ/G2N dev kits.
The Beacon EmbeddedWorks kit is based on the R8A774B1 SoC also
known as the RZ/G2N.
The kit consists of a SOM + Baseboard and supports microSD,
eMMC, Ethernet, a couple celular radios, two CAN interfaces,
Bluetooth and WiFi. It shares much of the same design as
the RZ/G2M dev kit.
Update the RZ/G2N dtsi from Renesas repo destined to become 5.12-rc1.
Signed-off-by: Adam Ford
---
arch/arm/dts/r8a774b1.dtsi | 76 +-
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/r8a774b1.dtsi b/arch/arm/dts/r8a774b1.dtsi
index
Update the RZ/G2M dtsi and r8a774a1-beacon-rzg2m-kit kit
from Renesas repo destined to become 5.12-rc1.
Signed-off-by: Adam Ford
---
arch/arm/dts/beacon-renesom-baseboard.dtsi | 359 -
arch/arm/dts/beacon-renesom-som.dtsi | 57 +++-
When reading a file using the load command from a FAT file system this
works fine irrespective of the alignment.
When reading from an EXT4 partition raw sectors are read to unaligned
addresses which leads to a failure to load the file
=> echo $kernel_addr_r
0x4008
=> load mmc 0:3
On Fri, Dec 11, 2020 at 6:02 AM Adam Ford wrote:
>
> Beacon EmbeddedWorks is releasing a devkit based on the i.MX8M
> Nano SoC consisting of baseboard + SOM.
>
> The kit is based on the same design as the Beacon dev kit with
> the i.MX8M Mini.
>
> Signed-off-by: Adam Ford
Gentle ping on this.
On Tue, Jan 5, 2021 at 6:08 AM Biju Das wrote:
>
> Hi Adam,
>
> Thanks for the patch.
>
> > -Original Message-
> > From: Adam Ford
> > Sent: 04 January 2021 17:38
> > To: u-boot@lists.denx.de
> > Cc: ja...@amarulasolutions.com; Biju Das ;
> > Adam Ford
> > Subject: [PATCH] spi:
On Tue, Jan 12, 2021 at 02:21:11PM +0530, Lokesh Vutla wrote:
> Hi Tom,
> Please find the PR for master branch targeted for v2021.04-rc1 release.
> Details about the PR are updated in the tag message.
>
> Gitlab build report:
>
On Tue, Jan 12, 2021 at 07:28:07AM +, eugen.hris...@microchip.com wrote:
> Hello Tom,
>
> Please pull tag u-boot-atmel-2021.04-a , the first set of new features
> for the 2021.04 cycle.
>
> This feature set includes the new board SAMA7G5 EK, the new evaluation
> kit for Microchip AT91
In efi_mem_sort() adjacent memory regions of same type are coalesced.
Remove the remark "Merging of adjacent free regions is missing".
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_memory.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c
We do not want to use typedefs in U-Boot.
Do not use efi_string_t in the EFI_TEXT_OUTPUT_PROTOCOL.
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h| 4 ++--
lib/efi_loader/efi_console.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
Move efi_intn_t and efi_uintn_t to include/efi.h to allow usage without
efi_api.h
Signed-off-by: Heinrich Schuchardt
---
include/efi.h | 5 +
include/efi_api.h | 2 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index
On 12.01.21 17:51, Joel Peshkin wrote:> Cc: Simon Glass
> Cc: Heinrich Schuchardt >
Signed-off-by: Joel Peshkin
These lines should be below the commit message body.
>
> Add support for stack protector for UBOOT, SPL, and TPL
> as well as new pytest for stackprotector
>
The following lines
Up to now the bootefi command used the last file loaded to determine the
boot partition. This has led to errors when the fdt had been loaded from
another partition after the EFI binary.
Before setting the boot device from a loaded file check if it is a PE-COFF
image or a FIT image.
For a PE-COFF
Carve out a function to check that a buffer contains a PE-COFF image.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 2 +
lib/efi_loader/efi_image_loader.c | 80 ++-
2 files changed, 48 insertions(+), 34 deletions(-)
diff --git
Let helloworld.efi print the device path of the boot device and the file
path as provided by the loaded image protocol.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/helloworld.c | 167 +---
1 file changed, 137 insertions(+), 30 deletions(-)
diff --git
Up to now the bootefi command uses the last file loaded to determine the
boot partition. This has led to user irritation when the fdt has been
loaded from another partition after the EFI binary.
Before setting the boot device from a loaded file check if it is a PE-COFF
image.
The first patch
On 1/12/21 12:18 PM, Philippe Reynes wrote:
Hi Philippe,
In the function rsa_verify_hash, if the "main" key doesn't
work, u-boot try others keys. But it searches those keys
in the FIT image instead of the u-boot device tree.
Signed-off-by: Philippe Reynes
---
lib/rsa/rsa-verify.c | 4 ++--
In the function rsa_verify_hash, if the "main" key doesn't
work, u-boot try others keys. But it searches those keys
in the FIT image instead of the u-boot device tree.
Signed-off-by: Philippe Reynes
---
lib/rsa/rsa-verify.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Martin,
Thanks for the report. Adding Anatolij.
On Tue, Jan 12, 2021 at 1:11 PM Fuzzey, Martin
wrote:
>
> Hi all,
>
> After updating from u-boot 2018.11 to 2020.10 on an i.MX6 based board
> I notice the colours when displaying bitmaps are wrong.
> The reason is that, in both cases the
Cc: Simon Glass
Cc: Heinrich Schuchardt
Signed-off-by: Joel Peshkin
Add support for stack protector for UBOOT, SPL, and TPL
as well as new pytest for stackprotector
Changes for v6:
- Fix commit message
Changes for v5:
- Rebase
Changes for v4:
- Exclude EFI from stackprotector
-
Currently when executing 'bootefi hello' we copy helloworld.efi to the
address identified by environment variable loadaddr. This is unexected
behavior for a user. There is no need to copy helloworld.efi before
executing it after relocation.
Remove the copy action.
Signed-off-by: Heinrich
: Disable CONFIG_SPL_OF_PLATDATA_PARENT on XEA (imx28) (2021-01-08
08:42:08 -0500)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git
tags/u-boot-amlogic-20210112
for you to fetch changes up to 6bfa331a6e22507ae839fb8474ce1b3fd58808df:
board
Hi all,
After updating from u-boot 2018.11 to 2020.10 on an i.MX6 based board
I notice the colours when displaying bitmaps are wrong.
The reason is that, in both cases the framebuffer format (not
necessarily the physical output format) is hardcoded as RGB565 in the
IPU driver but the
bmp command
On 12.01.21 16:21, Fabio Estevam wrote:
> Hi Stefano,
>
> On Tue, Jan 12, 2021 at 12:03 PM Stefano Babic wrote:
>>
>> Hi Peng, Fabio,
>>
>> I accidental saw this code:
>>
>> arch/arm/mach-imx/imx8m/soc.c:#if defined(CONFIG_IMX_HAB)
>>
>> but then arch/arm/mach-imx/Kconfig :
>>
>> config IMX_HAB
On 11.01.21 23:49, Joel Peshkin wrote:
Somehow the commit message got lost.
> Cc: Simon Glass
> Cc: Bin Meng
> Cc: Jagan Teki
> Cc: Kever Yang
> Cc: Heinrich Schuchardt
> Cc: AKASHI Takahiro
> Cc: Usama Arif
> Cc: Sam Protsenko
> Cc: Masahiro Yamada
> Cc: Philippe Reynes
> Cc: Eugeniu
Hi Stefano,
On Tue, Jan 12, 2021 at 12:03 PM Stefano Babic wrote:
>
> Hi Peng, Fabio,
>
> I accidental saw this code:
>
> arch/arm/mach-imx/imx8m/soc.c:#if defined(CONFIG_IMX_HAB)
>
> but then arch/arm/mach-imx/Kconfig :
>
> config IMX_HAB
> bool "Support i.MX HAB features"
>
Hi Peng, Fabio,
I accidental saw this code:
arch/arm/mach-imx/imx8m/soc.c:#if defined(CONFIG_IMX_HAB)
but then arch/arm/mach-imx/Kconfig :
config IMX_HAB
bool "Support i.MX HAB features"
depends on ARCH_MX7 || ARCH_MX6 || ARCH_MX5
this does not match. As I understand from
On Tue, Jan 12, 2021 at 12:42:23AM +, Andre Przywara wrote:
> Hi Tom,
>
> please pull the master branch from u-boot-sunxi, containing the first
> bunch of patches for the 2021.04 merge window:
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
When A-050382 errata is enabled, ECAM and EDMA have
conflicting stream id 40. This patch fixes the same.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Artem,
On 12/01/2021 12:42, Artem Lapkin wrote:
> Fix reading built-in ethernet MAC address from efuse
>
> NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
>
> if mac from efuse not valid we use meson_generate_serial_ethaddr
>
> NOTE: remake odroid-n2.c from Neil
On 11/01/2021 00:07, André Przywara wrote:
On 10/01/2021 19:29, Jernej Skrabec wrote:
This series introduces OrangePi 3 support.
Previous cover letter:
This is just refreshed v4 from here:
https://patchwork.ozlabs.org/project/uboot/list/?series=156657=*
Patches are only rebased, DT updated
The 'brcm,bcm2711-hdmi0' compatible string is used on RPi4 instead of
'brcm,bcm2835-hdmi' since the IP core was upgraded (now called VC6
instead of VC4). This has no functional change as far as u-boot driver
is concerned. So simply add the compatible string.
Signed-off-by: Nicolas Saenz Julienne
The DM_DMA option is needed in order to translate physical address into
bus addresses on a per-device basis.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Simon Glass
Tested-by: Peter Robinson
---
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
So far we've been content with passing physical addresses when
configuring memory addresses into XHCI controllers, but not all
platforms have buses with transparent mappings. Specifically the
Raspberry Pi 4 might introduce an offset to memory accesses incoming
from its PCIe port.
Introduce
This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
when relevant.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Simon Glass
Tested-by: Peter Robinson
---
drivers/mmc/sdhci.c | 12 +++-
include/mmc.h | 6 ++
2 files changed, 13 insertions(+), 5
By reusing DT nodes already available in sandbox's test DT introduce a
test to validate dev_phys_to_bus()/dev_bus_to_phys().
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Simon Glass
Tested-by: Peter Robinson
---
test/dm/Makefile | 1 +
test/dm/phys2bus.c | 37
These functions, instead of relying on hard-coded platform-specific
address translations, make use of the DMA constraints provided by the DM
core. This allows for per-device translations.
We can't yet get rid of the legacy phys_to_bus()/bus_to_phys()
implementations as some of its users are not
Add test to validate dev->dma_offset is properly set on devices.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Simon Glass
Tested-by: Peter Robinson
---
arch/sandbox/dts/test.dts | 4
configs/sandbox64_defconfig| 1 +
configs/sandbox_defconfig | 1 +
Add the following functions to get a specific device's DMA ranges:
- dev_get_dma_range()
- ofnode_get_dma_range()
- of_get_dma_range()
- fdt_get_dma_range()
They are specially useful in oder to be able validate a physical address
space range into a bus's and to convert addresses from and to
Calculating the DMA offset between a bus address space and CPU's every
time we call phys_to_bus() and bus_to_phys() isn't ideal performance
wise, as it implies traversing the device tree from the device's node up
to the root. Since this information is static and available before the
device's
Introduce some new nodes in sandbox's test device-tree and dm tests in
order to validate dev_get_dma_range().
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Simon Glass
Tested-by: Peter Robinson
---
arch/sandbox/dts/test.dts | 17 ++
test/dm/Makefile | 1 +
So far we've assumed a fixed configuration for inbound windows as we had
a single user for this controller. But the controller's DMA constraints
were improved starting with BCM2711's B1 revision of the SoC, notably
available in CM4 and Pi400. They allow for wider inbound windows. We can
now cover
The Raspberry Pi Foundation released the new Compute Module 4 which we
want to detect, so we can enable Ethernet on it and know the correct
device tree file name.
Note that this sets the Ethernet option to true since the official CM4
IO board has an Ethernet port. But that might not be the case
This series could be split into at least two or even three parts, but I
kept it as is for now as it contains all the changes needed in order to
have u-boot working on the new Raspberry Pi 400 and Raspberry Pi Compute
Module 4.
There are core changes, specifically with regard to cpu to bus address
The Raspberry Pi Foundation released the new RPi400 which we want to
detect, so we can enable Ethernet on it and know the correct device tree
file name.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
---
board/raspberrypi/rpi/rpi.c | 5 +
1
Hi Artem,
On 12.01.2021 06:03, Artem Lapkin wrote:
> Fix reading built-in ethernet MAC address from efuse
>
> NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
>
> if mac from efuse not valid we use meson_generate_serial_ethaddr
>
> NOTE: remake odroid-n2.c variant from Neil
Hi Peter, sorry for the late reply, but I was on holidays.
On Mon, 2021-01-04 at 13:13 +, Peter Robinson wrote:
> On Sun, Jan 3, 2021 at 5:36 PM Nicolas Saenz Julienne
> wrote:
> >
> > Hi Peter, thanks for taking the time to test this, I'll send a new hopefully
> > definitive version soon.
Fix reading built-in ethernet MAC address from efuse
NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
if mac from efuse not valid we use meson_generate_serial_ethaddr
NOTE: remake odroid-n2.c from Neil Armstrong
Signed-off-by: Artem Lapkin
---
board/amlogic/vim3/vim3.c
From: Wasim Khan
use 'select' to enable IRQ as it does not have architecture
specific dependency.
Signed-off-by: Wasim Khan
---
arch/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 3aa99e08fc..362b220948 100644
--- a/arch/Kconfig
From: Wasim Khan
Enable IRQ using select for sandbox architecture.
Signed-off-by: Wasim Khan
---
arch/Kconfig | 1 +
configs/sandbox64_defconfig| 1 -
configs/sandbox_defconfig | 1 -
configs/sandbox_flattree_defconfig | 1 -
From: Wasim Khan
GIC_V3_ITS uses UCLASS_IRQ driver. Update Kconfig to select
IRQ when GIC_V3_ITS is enabled.
Signed-off-by: Wasim Khan
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fbe90875ae..f8b4d422d9 100644
---
From: Wasim Khan
UCLASS_IRQ driver is not Intel specific. Make CONFIG_IRQ
selectable for all platfroms.
Signed-off-by: Wasim Khan
---
drivers/misc/Kconfig | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index
Fix reading built-in ethernet MAC address from efuse
NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
if mac from efuse not valid we use meson_generate_serial_ethaddr
NOTE: remake odroid-n2.c variant from Neil Armstrong
Signed-off-by: Artem Lapkin
---
Add device tree for Microchip PolarFire SoC Icicle Kit.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
Reviewed-by: Bin Meng
---
arch/riscv/dts/Makefile | 1 +
.../dts/microchip-mpfs-icicle-kit-u-boot.dtsi | 14 +
arch/riscv/dts/microchip-mpfs-icicle-kit.dts
This patch adds Microchip MPFS Icicle Kit support. For now, only
NS16550 Serial, Microchip clock, Cadence eMMC and MACB drivers are
enabled. The Microchip MPFS Icicle defconfig by default builds
U-Boot for S-Mode because U-Boot on Microchip PolarFire SoC will run
in S-Mode as payload of HSS +
This doc describes the procedure to build, flash and
boot Linux using U-boot on Microchip MPFS Icicle Kit.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
Reviewed-by: Bin Meng
---
doc/board/index.rst | 1 +
doc/board/microchip/index.rst | 9 +
Add clock driver code for the Microchip PolarFire SoC. This driver
handles reset and clock control of the Microchip PolarFire SoC device.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
Tested-by: Bin Meng
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile
Enable 32-bit or 64-bit DMA in the macb driver based on the macb
hardware compatibility and it is configured with structure macb_config
in the driver.
The Microchip PolarFire SoC Memory Protection Unit(MPU) gives the 64-bit
DMA access with the GEM, the MPU transactions on the AXI bus is 64-bit
This patch set adds Microchip PolarFire SoC Icicle Kit support
to RISC-V U-Boot.
The patches are based upon latest U-Boot tree
(https://gitlab.denx.de/u-boot/u-boot.git) at commit id
d71be1990218957b9f05dbf13a72859a2abe06d7
All drivers namely: NS16550 Serial, Microchip clock,
Cadence eMMC and
dma_addr_t holds any valid DMA address. If the DMA API only uses 32/64-bit
addresses, dma_addr_t need only be 32/64 bits wide.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
Reviewed-by: Bin Meng
Reviewed-by: Rick Chen
---
arch/riscv/Kconfig | 4
Read phy address from device tree and use it to find the phy device
if not found then search in the range of 0 to 31.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
drivers/net/macb.c | 13 +
1 file changed, 13 insertions(+)
Hello Tom,
Please pull tag u-boot-atmel-2021.04-a , the first set of new features
for the 2021.04 cycle.
This feature set includes the new board SAMA7G5 EK, the new evaluation
kit for Microchip AT91 SAMA7G5 SoC . The current board support includes
two configurations for booting from eMMC
On 1/12/21 2:03 PM, Artem Lapkin wrote:
> Fix reading built-in ethernet MAC address from efuse
>
> NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
>
> if mac from efuse not valid we use meson_generate_serial_ethaddr
>
> NOTE: remake odroid-n2.c variant from Neil Armstrong
This patch completely removes CONFIG_PCI_ENUM_ONLY from the PCI code as
it is not configured for any board (any more). With this removal, some
PCI related files get cleaned up a bit.
Additional, dm_pciauto_setup_device() is now static, as it's not
referenced from any code outside of this C file.
Hello!
On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:
> Hi Pali,
>
> On 11/01/2021 11:51, Pali Rohár wrote:
> > Hello Stefan and Andre!
> >
> > Could you please look at this patch series and tell me what do you think
> > about it? If it is fine or needs to take different approach?
>
>
Hi Tom,
Please find the PR for master branch targeted for v2021.04-rc1 release.
Details about the PR are updated in the tag message.
Gitlab build report:
https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/5827
Changes since v1:
- Rebased on top of latest master
- Dropped
From: Igor Opaniuk
Extend existing DM tee tests adding test coverage for reverse RPC calls.
Currently this commit only adds tests for I2C requests from TEE driver
to TEE supplicant, for instance reading/writing data to emulated i2c
eeprom defines in standard sandbox test device tree
From: Igor Opaniuk
Add pygit2 and pyelftools to the list of packages for virtualenv
needed to run all sets of pytests.This fixes warnings like:
binman.elf_test.TestElf.testDecodeElf (subunit.RemotedTestCase):
Python elftools not available
Signed-off-by: Igor Opaniuk
---
From: Igor Opaniuk
This adds support for RPC test trusted application emulation, which
permits to test reverse RPC calls to TEE supplicant. Currently it covers
requests to the I2C bus from TEE.
Signed-off-by: Igor Opaniuk
---
drivers/tee/Makefile| 2 +
drivers/tee/optee/Kconfig
This commit gives the secure world access to the I2C bus so it can
communicate with I2C slaves (typically those would be secure elements
like the NXP SE050).
A similar service implementation has been merged in linux:
c05210ab ("drivers: optee: allow op-tee to access devices on the i2c
bus")
This patchset allows OP-TEE to communicate with I2C devices; a typical
use case would be servicing U-Boot requests that require underlying
cryptographic operations implemented by an I2C chip.
On a board fitted with the NXP SE050 I2C secure element, OP-TEE can
route some of the cryptographic
On 12/01/2021 09:18, Andre Heider wrote:
...
Maybe the first step can be solved with ENV_FLAGS_VAR, a new immutable
flag, and boards just making use of CONFIG_ENV_FLAGS_LIST_DEFAULT to
declare those. But I fail to find an example in-tree.
Found one, see ENV_FLAGS_LIST_STATIC. That even has
Hi Pali,
On 11/01/2021 11:51, Pali Rohár wrote:
Hello Stefan and Andre!
Could you please look at this patch series and tell me what do you think
about it? If it is fine or needs to take different approach?
I like the idea very much, and I bet there're quite some boards which
could make good
90 matches
Mail list logo
