The i.MX8MM is capable of HS400. Enable it in both
U-Boot and SPL for faster throughput.
Signed-off-by: Adam Ford
diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
index c5d331f617..49d5453078 100644
--- a/configs/imx8mm_beacon_defconfig
+++ b/configs/imx8mm_beacon_
On Tue, Dec 1, 2020 at 7:32 AM Andrey Zhizhikin
wrote:
>
> i.MX8M series provide support for high speed grades in their
> usdhc controllers, which has eMMC and SDHC connected to them.
>
> Enable this support across the entire i.MX8M family by providing quirks
> to usdhc controllers designated by s
There have been some updates to the device trees, so re-sync.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
b/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
index baa5f997d0..d6b9dedd16 100644
--- a/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
+++ b/arch/arm/dts/imx8mm
There have been some updates to the device tree since 5.6.
This also includes some clocks, and makes it easier to keep
board device tree files in sync with Linux
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
index 1e5e11592f..05ee062548 100644
--- a/ar
Import clock bindings header file from Linux 5.10-rc6
Signed-off-by: Adam Ford
diff --git a/include/dt-bindings/clock/imx8mm-clock.h
b/include/dt-bindings/clock/imx8mm-clock.h
index 07e6c686f3..e63a5530ae 100644
--- a/include/dt-bindings/clock/imx8mm-clock.h
+++ b/include/dt-bindings/clock/imx8
Tom,
Please pull u-boot-tegra/master into U-Boot/master. Thanks.
All Tegra builds are OK on my system, and Stephen's test frame reports that
all tests pass.
The following changes since commit ee1e04558ff8c8ed812b986939447f129bb0b0bb:
Merge branch '2020-12-02-master-imports' (2020-12-03 09:43
Hi Peng
I have a design with imx6ull that is running properly according to the
manufacturer with the old REFTOP_VBGA set
BM_ANADIG_ANA_MISC0_REFTOP_VBGADJ,. With this commit, the TJunction of
the CPU is around 8 degree more than without. The commit message does
not provide any info
According to t
On Thu, Dec 03, 2020 at 10:19:59PM +0100, Heinrich Schuchardt wrote:
> Dear Tom,
>
> The following changes since commit a2c832471115d382d6dd60697be5bc74d2636eea:
>
> Merge branch '2020-12-01-next-imports' into next (2020-12-02 11:35:02
> -0500)
>
> are available in the Git repository at:
>
>
When issuing 'i2c probe', the driver was crashing, because at probe
there is a request with zero length buffer to write to i2c bus.
The xfer_msg function assumes the buffer is always there, and never
checks for the buffer length.
=> i2c dev 0
Setting bus to 0
=> i2c probe
Valid chip addresses:
dat
Fix typo which would cause a build error.
Fixes: 3eaac6307df ("net: introduce packet capture support")
Signed-off-by: Jorge Ramirez-Ortiz
---
net/eth_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/eth_legacy.c b/net/eth_legacy.c
index 6e0c058761..6870afb505 100
Hi Heinrich,
Heinrich Schuchardt writes:
> On 11/30/20 7:22 PM, Paulo Alcantara wrote:
>> Heinrich Schuchardt writes:
>>
>>> On 11/30/20 3:58 PM, Paulo Alcantara wrote:
Introduce a new config option CONFIG_EFI_SECURE_BOOT_VAR_DISABLE to
allow disabling EFI secure boot when the platfor
Hello,
I've realized that this patch contains wrong bindings, "u-boot," prefix should
be dropped.
Also, configuration values to enable high speed modes in eSDHC are missing from
defconfigs - those has to be added as well.
Would sent a V3 for this series, please hold the review of this one.
So
Fixed wrong PHY Interface Mode
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 13114f38e2ccea9386726d8b
Hello Julius,
I agree with you. Using an existing standard is better than inventing a new one
in this case. I think using the coreboot logging is a good idea as there is
indeed a lot of support already available and it is lightweight and simple.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstr
On 03.12.2020 23:45, Jaehoon Chung wrote:
> Hi,
>
> On 12/3/20 8:20 PM, eugen.hris...@microchip.com wrote:
>> On 03.12.2020 13:11, Jaehoon Chung wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>>> content is safe
>>>
>>> On 12/3/20 7:47 PM, eugen.hris...@micr
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targe
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng.
This is the baseline support for the SIMATIC IOT2050 devices.
Allows to boot mainline 5.10 kernels, but not the original BSP-derived
kernel we currently ship as reference. This is due to the TI sysfw ABI
breakages between 2.x and 3.x. We will soon provide a transitional
kernel that allows booting
18 matches
Mail list logo