Re: [U-Boot] [PATCH v1] MAINTAINERS: Add info for bcm283x
On Wed, Nov 27, 2019 at 05:41:06PM +0100, matthias@kernel.org wrote: > From: Matthias Brugger > > The bcm283x has grown in files, which was not reflected in the > MAINTAINERS file. Fix this by adding the missing entries. > > Signed-off-by: Matthias Brugger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 1/2] Convert CONFIG_PHY_CORTINA to Kconfig
On Tue, Nov 26, 2019 at 05:32:42PM -0500, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_PHY_CORTINA > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> Am 03.12.2019 um 19:31 schrieb Ang, Chee Hong: > >> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong > >> > >> wrote: > >>> > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong > > wrote: > > > >> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > wrote: > > > >> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > >> > >> wrote: > >>> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > wrote: > > > >> On Mon, Dec 2, 2019 at 11:25 AM > wrote: > >>> > >>> From: "Ang, Chee Hong" > >>> > >>> New U-boot flow with ARM Trusted Firmware (ATF) support: > >>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> > >>> Linux > >>> (EL1) > >> > >> Adding support for ATF means that using U-Boot on > >> Stratix10 and Agilex without ATF keeps working, right? > > ATF is needed in order for Stratix10 and Agilex's U-Boot to > > work. > > Is there a technical requirement for that? > >>> Yes. We are using ATF to provide PSCI services such as > >>> system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in > >>> Linux) and other secure services such as mailbox > >>> communications with Secure Device Manager and accessing the > >>> System Manager registers which are > secure. > >>> Without PSCI services, we are able to boot until U-Boot > >>> proper > >> only. > >>> Currently, our U-Boot in mainline doesn't boot to Linux due > >>> to these missing > >> PSCI services. > >>> Another reason is we have another boot flow which is using > >>> ATF + > UEFI. > >>> So now we are re-using the PSCI services from ATF so that > >>> now U-Boot and UEFI share the same ATF-BL31 image so that we > >>> don't have to > >> reimplement another sets of PSCI services for U-Boot again. > >>> This will greatly reduce our engineering efforts. > >> > >> Hmm, thanks for the explanation. > >> > >> I don't really think I can review this, given the lack of > >> knowledge about that PSCI stuff. > > I believe you can review it. > > Have you briefly gone through the patches ? It has nothing to > > do with the PSCI > stuff. > > It just call the invoke_smc() function to call the ATF's PSCI > > functions. Those PSCI functions in ATF will do the rest. > > No, not yet. But see below. > > >> > >> I must say it seems strange to me that U-Boot would have to > >> rely on ATF > though. > >> How do other platforms implement this? Shouldn't PSCI be > >> generic or is it really platform specific? If it's generic, > >> isn't that a dupliation of code if you implement e.g. a reset > >> driver for > >> Stratix10 but call > into PSCI? > > It's not strange at all. A lot of U-Boot users already using > > this boot flow (ATF + > U-Boot). > > Just because other boards do this doesn't mean it's not strange. > Wasn't there some kind of discussion around that PSCI stuff to > make it > >> available from U-Boot? > What's wrong with that way? > >>> Our downstream U-Boot branch is already implemented the PSCI > >>> stuffs in U- > >> Boot. > >>> I tried to upstream my PSCI code: > >>> https://lists.denx.de/pipermail/u-boot/2019-May/368822.html > >>> > >>> Marek pointed me to this thread: > >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.ht > >>> ml > >>> > >>> He had a point. He suggested maybe we can implement the PSCI > >>> stuffs in SPL/TPL. I took a look at the U-Boot code and found > >>> out ATF is already well > >> supported. Why don't we just use the PSCI code from ATF rather > >> than > >> re- implementing the PSCI code again in SPL/TPL. > >>> It will save our effort to maintain two PSCI code in U-Boot and > >>> ATF while we > >> already have the ATF PSCI implementation to support UEFI. > >> > >> It seems to me we do have working code in U-Boot, what's missing > >> is "only" to turn it ino PSCI? > > Existing PSCI framework in U-Boot provide a way for us to turn the > > code into a PSCI handler by just adding a '__secure' keyword > > before the > function name. See: > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-soc > > fpga > > /mailbox_s10.c > > > > Below is one of the functions that has 2 versions. One 'live' in a > > normal code
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> Am 02.12.2019 um 11:25 schrieb chee.hong@intel.com: > > From: "Ang, Chee Hong" > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) > > > > SPL loads the u-boot.itb which consist of: > > 1) u-boot-nodtb.bin (U-Boot Proper image) > > 2) u-boot.dtb (U-Boot Proper DTB) > > 3) bl31.bin (ATF-BL31 image) > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes > > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager > > register accesses and mailbox communications with Secure Device > > Manager (SDM). > > > > Steps to build the U-Boot with ATF support: > > 1) Build U-Boot > > 2) Build ATF BL31 > > 3) Copy ATF BL31 binary image into U-Boot's root folder > > 4) "make u-boot.itb" to generate u-boot.itb > > > > These patchsets have dependency on: > > [U-Boot,v8,00/19] Add Intel Agilex SoC support: > > https://patchwork.ozlabs.org/cover/1201373/ > > BTW, does this series supersede these wo: > https://patchwork.ozlabs.org/user/todo/uboot/?series=106463 > https://patchwork.ozlabs.org/user/todo/uboot/?series=106465 Yes. These 2 patches are quite dated as they are using "__secure" section method for PSCI code. > > I'm just updating my patchwork todo list... > > Regards, > Simon > > > > > Chee Hong Ang (19): > >arm: socfpga: add fit source file for pack itb with ATF > >arm: socfpga: Add function for checking description from FIT image > >arm: socfpga: Load FIT image with ATF support > >arm: socfpga: Override 'lowlevel_init' to support ATF > >configs: socfpga: Enable FIT image loading with ATF support > >arm: socfpga: Disable "spin-table" method for booting Linux > >arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) > >arm: socfpga: Define SMC function identifiers for PSCI SiP services > >arm: socfpga: Add secure register access helper functions for SoC > > 64bits > >arm: socfpga: Secure register access for clock manager (SoC 64bits) > >arm: socfpga: Secure register access in PHY mode setup > >arm: socfpga: Secure register access for reading PLL frequency > >mmc: dwmmc: socfpga: Secure register access in MMC driver > >net: designware: socfpga: Secure register access in MAC driver > >arm: socfpga: Secure register access in Reset Manager driver > >arm: socfpga: stratix10: Initialize timer in SPL > >arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF > >arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config > > status > >sysreset: socfpga: Invoke PSCI call for COLD reset > > > > Dalon Westergreen (1): > >configs: stratix10: Remove CONFIG_OF_EMBED > > > > arch/arm/mach-socfpga/Kconfig | 2 - > > arch/arm/mach-socfpga/Makefile | 4 + > > arch/arm/mach-socfpga/board.c | 10 + > > arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- > > arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- > > arch/arm/mach-socfpga/include/mach/misc.h | 3 + > > .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ > > arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ > > arch/arm/mach-socfpga/misc_s10.c | 47 ++- > > arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- > > arch/arm/mach-socfpga/secure_reg_helper.c | 67 > > arch/arm/mach-socfpga/timer_s10.c | 3 +- > > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- > > board/altera/soc64/its/fit_spl_atf.its | 51 +++ > > configs/socfpga_agilex_defconfig | 8 +- > > configs/socfpga_stratix10_defconfig| 9 +- > > drivers/fpga/stratix10.c | 261 -- > > drivers/mmc/socfpga_dw_mmc.c | 7 +- > > drivers/net/dwmac_socfpga.c| 5 +- > > drivers/sysreset/sysreset_socfpga_s10.c| 4 +- > > include/configs/socfpga_soc64_common.h | 2 +- > > include/linux/intel-smc.h | 374 > > + > > 22 files changed, 732 insertions(+), 243 deletions(-) > > create mode 100644 arch/arm/mach- > socfpga/include/mach/secure_reg_helper.h > > create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S > > create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c > > create mode 100644 board/altera/soc64/its/fit_spl_atf.its > > create mode 100644 include/linux/intel-smc.h > >
Re: [U-Boot] [EXT] Re: [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode
On Wed, Dec 4, 2019 at 4:23 AM Xiaowei Bao wrote: > > > > > -Original Message- > > From: Ramon Fried > > Sent: 2019年12月4日 4:01 > > To: Xiaowei Bao > > Cc: Ramon Fried ; Hongbo Wang > > ; u-boot@lists.denx.de; York Sun > > ; Z.q. Hou ; Mingkai Hu > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCHv2 1/2] PCI: layerscape: Add Support > > for ls2088 PCIe EP mode > > > > On Tue, Dec 3, 2019 at 4:32 AM Xiaowei Bao wrote: > > > > > > Hi Ramon, > > > > > > Do you have any comments about this? Thanks a lot. > > > > > > Best regards > > > Xiaowei > > > > > > From: Xiaowei Bao > > > Sent: 2019年11月26日 10:52 > > > To: Ramon Fried > > > Cc: Bin Meng ; Simon Glass ; > > > M.h. Lian ; Z.q. Hou ; > > > Mingkai Hu ; Hongbo Wang > > ; > > > York Sun ; u-boot@lists.denx.de > > > Subject: RE: [EXT] Re: [U-Boot] [PATCHv2 1/2] PCI: layerscape: Add > > > Support for ls2088 PCIe EP mode > > > > > > H Ramon, > > > > > > Thanks for your comments. > > > If we reimplement the PCIe EP driver base on PCIe UCLASS, we must test it > > in u-boot, but I have no idea how to test the actual device, do I need to > > implement our own test case, how to verify the cadence-ep actual device? > > > > > I'm not sure I understand what you're trying to achieve and why you're > > referring to the cadence. > > You're developing a driver, just test it against a client (IE. a real PCIe > > root-complex). > > The cadence is irrelevant, it's just another implementation of endpoint > > driver. > > Thanks for your comments, do you mean that we can use the 'pci' and 'md' > command > of u-boot to test the EP device when the controller which work as a EP device > connect > to a RC port, we can access the BAR base on the "pci header" command, yes? > but if I want > to test memory access from EP to RC, what should I do, because there is not a > command > which similar to 'pci' to test. > No, I don't mean that. Currently there's no cmd line interface for PCIe endpoint (patches welcome). You should test the driver against a *real* setup, where you configure the endpoint using some init function in the board startup sequence. > Another issue is that, due to the history reason of Layerscape PCIe > controller driver, the > EP and RC codes are combined, if I separate the EP and RC code, there will > have many > duplicate code. So create a common.c file for both of them. > > Thanks > Xiaowei > > > > > Thanks, > > Ramon. > > > Best regards > > > Xiaowei > > > U-Boot@lists.denx.de > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > > > > s.denx.de%2Flistinfo%2Fu-bootdata=02%7C01%7Cxiaowei.bao%40nxp > > .com > > > %7Cad7a366db91f4e40273308d7782b7fc8%7C686ea1d3bc2b4c6fa92cd99 > > c5c301635 > > > %7C0%7C0%7C63711532938430sdata=T0D3QR5RzdFv96syOlG > > VK7OEBQyNdl > > > 8M9pfd%2F4vxOIg%3Dreserved=0
[PATCH v2 1/1] efi_loader: pass address to efi_install_fdt()
As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string.
If the address is EFI_FDT_USE_INTERNAL (= 0), the internal device tree
is used.
Signed-off-by: Heinrich Schuchardt
---
v2
provide constant EFI_FDT_USE_INTERNAL
---
cmd/bootefi.c| 32 ++--
include/efi_loader.h | 3 +++
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f613cce7e2..2b190a3edd 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -196,40 +196,39 @@ static void *get_config_table(const efi_guid_t *guid)
#endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */
/**
- * efi_install_fdt() - install fdt passed by a command argument
+ * efi_install_fdt() - install device tree
*
- * If fdt_opt is available, the device tree located at that memory address will
+ * If fdt_addr is available, the device tree located at that memory address
will
* will be installed as configuration table, otherwise the device tree located
* at the address indicated by environment variable fdtcontroladdr will be
used.
*
- * On architectures (x86) using ACPI tables device trees shall not be installed
- * as configuration table.
+ * On architectures using ACPI tables device trees shall not be installed as
+ * configuration table.
*
- * @fdt_opt: pointer to argument
+ * @fdt_addr: address of device tree or EFI_FDT_USE_INTERNAL to use the
+ * internal device tree as indicated by environment variable
+ * fdtcontroladdr
* Return: status code
*/
-static efi_status_t efi_install_fdt(const char *fdt_opt)
+static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
{
/*
* The EBBR spec requires that we have either an FDT or an ACPI table
* but not both.
*/
#if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
- if (fdt_opt) {
+ if (fdt_addr) {
printf("ERROR: can't have ACPI table and device tree.\n");
return EFI_LOAD_ERROR;
}
#else
- unsigned long fdt_addr;
void *fdt;
bootm_headers_t img = { 0 };
efi_status_t ret;
- if (fdt_opt) {
- fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
- if (!fdt_addr)
- return EFI_INVALID_PARAMETER;
- } else {
+ if (fdt_addr == EFI_FDT_USE_INTERNAL) {
+ const char *fdt_opt;
+
/* Look for device tree that is already installed */
if (get_config_table(_guid_fdt))
return EFI_SUCCESS;
@@ -556,6 +555,7 @@ static int do_efi_selftest(void)
static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
efi_status_t ret;
+ uintptr_t fdt_addr;
if (argc < 2)
return CMD_RET_USAGE;
@@ -568,7 +568,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
return CMD_RET_FAILURE;
}
- ret = efi_install_fdt(argc > 2 ? argv[2] : NULL);
+ if (argc > 2)
+ fdt_addr = simple_strtoul(argv[2], NULL, 16);
+ else
+ fdt_addr = EFI_FDT_USE_INTERNAL;
+ ret = efi_install_fdt(fdt_addr);
if (ret == EFI_INVALID_PARAMETER)
return CMD_RET_USAGE;
else if (ret != EFI_SUCCESS)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 16a1b258b1..3a22089329 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -34,6 +34,9 @@ static inline int guidcmp(const void *g1, const void *g2)
EFI_GUID(0xbbe4e671, 0x5773, 0x4ea1, \
0x9a, 0xab, 0x3a, 0x7d, 0xbf, 0x40, 0xc4, 0x82)
+/* Use internal device tree when starting UEFI application */
+#define EFI_FDT_USE_INTERNAL 0UL
+
/* Root node */
extern efi_handle_t efi_root;
--
2.24.0
Re: [PATCH v2 00/16] efi_loader: add secure boot support
On 12/4/19 3:43 AM, AKASHI Takahiro wrote: Tom, Simon, Heinrich, I have submitted three major patch sets for UEFI secure boot: * x509/pkcs7 parser * RSA library extension * UEFI secure boot I have no technical issues to fix now and have seen only a few minor comments on them (if I confirm that you have no more comments, I can submit new version almost immediately). Considering those, can I expect that those patches be merged in v2020.01? If not, do you need to have more time for your reviewing? What else do you expect from my side to accelerate the upstream? We are reaching the end of the release cycle. So do not expect any of these patch series to be merged in v2020.01. cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle To my understanding the UEFI secure boot series depends on the other two so it must be merged last. Best regards Heinrich
RE: [PATCH v3 3/6] test: dm: add a simple unit test for DSA class
>-Original Message-
>From: U-Boot On Behalf Of Alex Marginean
>Sent: Tuesday, December 3, 2019 8:27 PM
>To: u-boot@lists.denx.de
>Cc: Joe Hershberger ; Claudiu Manoil
>; Vladimir Oltean
>Subject: [PATCH v3 3/6] test: dm: add a simple unit test for DSA class
>
>The test pings the local IP address though different ports of a sandbox DSA
>device. Port traffic is filtered and the test verifies that ping works only on
>enabled ports.
>The additional interfaces require MAC addresses, these have been added to
>sandbox default environment.
>
>Signed-off-by: Alex Marginean
>---
> arch/Kconfig | 1 +
> arch/sandbox/dts/test.dts | 49 +
>include/configs/sandbox.h | 4 +++
> test/dm/Makefile | 1 +
> test/dm/dsa.c | 58 +++
> test/dm/test-fdt.c| 2 +-
> 6 files changed, 114 insertions(+), 1 deletion(-) create mode 100644
>test/dm/dsa.c
>
>diff --git a/arch/Kconfig b/arch/Kconfig index 141e48bc43..70907d69a1 100644
>--- a/arch/Kconfig
>+++ b/arch/Kconfig
>@@ -133,6 +133,7 @@ config SANDBOX
> imply PHYLIB
> imply DM_MDIO
> imply DM_MDIO_MUX
>+ imply DM_DSA
>
> config SH
> bool "SuperH architecture"
>diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index
>fdb08f2111..0f565f066a 100644
>--- a/arch/sandbox/dts/test.dts
>+++ b/arch/sandbox/dts/test.dts
>@@ -40,6 +40,10 @@
> usb2 = _2;
> axi0 =
> osd0 = "/osd";
>+ eth8 = _0;
>+ eth9 = _1;
>+ eth10 = _2;
>+ eth11 = _eth0;
> };
>
> audio: audio-codec {
>@@ -889,6 +893,51 @@
> mdio: mdio-test {
> compatible = "sandbox,mdio";
> };
>+
>+ dsa_eth0: dsa-test-eth {
>+ compatible = "sandbox,dsa-eth";
>+ };
>+
>+ dsa-test {
>+ compatible = "sandbox,dsa";
>+
>+ ports {
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+ swp_0: port@0 {
>+ reg = <0>;
>+ label = "lan0";
>+ };
>+
>+ swp_1: port@1 {
>+ reg = <1>;
>+ label = "lan1";
>+ phy-mode = "rgmii-txid";
>+ fixed-link {
>+ speed = <1000>;
>+ full-duplex;
>+ };
>+ };
>+
>+ swp_2: port@2 {
>+ reg = <2>;
>+ label = "lan2";
>+ fixed-link {
>+ speed = <100>;
>+ full-duplex;
>+ };
>+ };
>+
>+ port@3 {
>+ reg = <3>;
>+ ethernet = <_eth0>;
>+ fixed-link {
>+ speed = <100>;
>+ full-duplex;
>+ };
>+ };
>+ };
>+ };
> };
>
> #include "sandbox_pmic.dtsi"
>diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index
>1c13055cdc..35a5676eb9 100644
>--- a/include/configs/sandbox.h
>+++ b/include/configs/sandbox.h
>@@ -100,6 +100,10 @@
> "eth1addr=00:00:11:22:33:45\0" \
> "eth3addr=00:00:11:22:33:46\0" \
> "eth5addr=00:00:11:22:33:47\0" \
>+ "eth8addr=00:00:11:22:33:48\0" \
>+ "eth9addr=00:00:11:22:33:49\0" \
>+ "eth10addr=00:00:11:22:33:4a\0" \
>+ "eth11addr=00:00:11:22:33:4b\0" \
> "ipaddr=1.2.3.4\0"
>
> #define MEM_LAYOUT_ENV_SETTINGS \
>diff --git a/test/dm/Makefile b/test/dm/Makefile index 0c2fd5cb5e..69e9feed91
>100644
>--- a/test/dm/Makefile
>+++ b/test/dm/Makefile
>@@ -65,4 +65,5 @@ obj-$(CONFIG_VIRTIO_SANDBOX) += virtio.o
> obj-$(CONFIG_DMA) += dma.o
> obj-$(CONFIG_DM_MDIO) += mdio.o
> obj-$(CONFIG_DM_MDIO_MUX) += mdio_mux.o
>+obj-$(CONFIG_DM_DSA) += dsa.o
> endif
>diff --git a/test/dm/dsa.c b/test/dm/dsa.c new file mode 100644 index
>00..5aa3847fe5
>--- /dev/null
>+++ b/test/dm/dsa.c
>@@ -0,0 +1,58 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * Copyright (c) 2019 NXP
Please use Copyright 2019 NXP
>+ */
>+
>+#include
>+#include
>+#include
>+
>+extern int dsa_sandbox_port_mask;
>+
>+/* this test sends ping requests with the local address through each
>+DSA port
>+ * via the dummy DSA master Eth.
>+ * The
RE: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
> -Original Message- > From: Schrempf Frieder > Sent: Tuesday, December 3, 2019 6:17 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; ja...@amarulasolutions.com; > s...@denx.de; Ashish Kumar ; Ye Li > Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > On 03.12.19 11:56, Kuldeep Singh wrote: > > Hi Frieder, > > > >> -Original Message- > >> From: Schrempf Frieder > >> Sent: Tuesday, December 3, 2019 2:27 PM > >> To: Kuldeep Singh ; u-boot@lists.denx.de > >> Cc: Priyanka Jain ; > >> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >> ; Ye Li > >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >> spi-mem framework > >> > >> Caution: EXT Email > >> > >> On 03.12.19 07:30, Kuldeep Singh wrote: > >>> Hi Frieder, > >>> > -Original Message- > From: Schrempf Frieder > Sent: Monday, December 2, 2019 5:35 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; > ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > > Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > spi-mem framework > > Caution: EXT Email > > + Ashish > > Hi Kuldeep, > > On 29.11.19 06:54, Kuldeep Singh wrote: > > This entire patch series migrate freescale qspi driver to spi-mem > >> framework. > > First, thanks for working on this. I have this on my list for quite > a long time, but struggled to find enough time to actually get it done. > > > > > Patch 1 removes the old fsl qspi driver > > You shouldn't remove the old driver before the new one is in place, > as this breaks the build in between the two patches. > >>> > >>> I first merged the patch1 and patch2 and found that the diff output > >>> was very > >> much less readable. > >>> That's why I split them into 2 patches so as to make new driver > >>> changes > >> legible. > >>> Please let me know how shall I proceed. Shall I merge the two patches? > >> > >> Yes, the merged patch will not be very good to read, but as far as I > >> know there is no other option. We must not break the build to keep > bisectability. > > > > Alright I will merge the two patches. > > > >> > >>> > > > > > Patch 2 adds new qspi driver incorporating spi-mem framework which > > is ported version of linux qspi driver. Initial port was done by > > Frieder. > > Now, no more direct access to spi-nor memory is possible. Few > > changes were introduced to prevent uboot crash such as to add > > complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on > > chip select number instead of 1k. Immediate effect was observed on > > pfe while using 1k size as it access spi-nor memory directly. > > Using complete flash size resolves > the crash but data read will not be valid. > > Can you provide more information about the problem/crash you > experience and the platform you are working on? > >>> > >>> I observed crash on LS1012. Also, any access to flash direct memory > >>> above > >> 1k will crash without this change. > >> > >> As I already told Ashish in the conversation referenced in my last mail: > >> I can't see any good reason why the direct memory access is something > >> that we need or should support. We should always use the APIs > >> provided by U-Boot to access the flash and that is mtd. > >> > >>> By adding this, crash will be resolved but data is invalid as > >>> mentioned in > >> patch-set. > >> > >> So what's the purpose of your changes at all, if they do not solve > >> the problem you're trying to solve? > > > > I observed booting crash on all ls1012 platforms. Control does not reach > even end of uboot prompt. > > I dig in deeper, and found that "pfe (packet forwarding engine)" was using > spi-nor memory directly. > > With this change, booting crash was resolved. Now, at least other network > interfaces can be used. > > Without this changes, I have to disable pfe on adhoc basis so as to get > > uboot > prompt. > > This is to make sure all intended qspi targets are booting. > > Ok, thanks for pointing out the PFE driver. I didn't know about such a > peripheral. So this seems to be the actual problem here. > > I don't really understand, why Ashish didn't mention this when we were talking > about this issue some weeks ago. > > > > >> Why don't you just use sf/mtd to access the flash? > > > > Pfe framework have to bring in changes to access flash using sf in uboot. > > Yes and that's something that should be done first instead of hacking the QSPI > controller driver. It shouldn't be too hard to modify the PFE driver so that > it > uses the serial flash API (spi_flash_read()) to access the SPI NOR. > Can you try to come up with a patch for the PFE driver? Okay, I will start working on it. --Kuldeep > > > > > Thanks > > Kuldeep > > > >> > >>> >
Re: [U-Boot] [PATCH 1/3] Makefile: don't try to construct CLEAN_FILES based on config
On Sun, Nov 10, 2019 at 08:25:08AM -0800, Thomas Hebb wrote: > All of the clean targets (clean, dist-clean, mrproper) are run without > loading a configuration. That means that any conditional modification of > CLEAN_FILES will either always apply or never apply and so shouldn't be > in a conditional in the first place. > > Since CLEAN_FILES is allowed to list nonexistent files, just add > everything to it unconditionally to fix the issue. > > Signed-off-by: Thomas Hebb Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 1/3] Kconfig: disambiguate config names for tiny printf
On Sun, Nov 10, 2019 at 08:23:53AM -0800, Thomas Hebb wrote:
> 27084c03d36a ("spl: Allow tiny printf() to be controlled in SPL and
> TPL") split this option in two for TPL and SPL, but didn't change the
> Kconfig names, making them hard to set quickly.
>
> Signed-off-by: Thomas Hebb
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH] configs: Enable SPL_FSL_PBL for some LayerScape platforms
In commit , SPL_FSL_PBL is removed from the configs of some LayerScape platforms. Actually, SPL_FSL_PBL is needed for SD/NAND boot on LS1021A/LS1043A/LS1046A to create boot binary having SPL binary in PBI format concatenated with u-boot binary. SPL_FRAMEWORK is used on these platforms too. Signed-off-by: Alison Wang --- common/spl/Kconfig | 8 ++-- configs/ls1021aiot_sdcard_defconfig | 1 + configs/ls1021aqds_nand_defconfig | 1 + configs/ls1021aqds_sdcard_ifc_defconfig | 1 + configs/ls1021aqds_sdcard_qspi_defconfig| 1 + configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_sdcard_ifc_defconfig | 1 + configs/ls1021atwr_sdcard_qspi_defconfig| 1 + configs/ls1043aqds_nand_defconfig | 1 + configs/ls1043aqds_sdcard_ifc_defconfig | 1 + configs/ls1043aqds_sdcard_qspi_defconfig| 1 + configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 1 + configs/ls1043ardb_nand_defconfig | 1 + configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 1 + configs/ls1043ardb_sdcard_defconfig | 1 + configs/ls1046aqds_nand_defconfig | 1 + configs/ls1046aqds_sdcard_ifc_defconfig | 1 + configs/ls1046aqds_sdcard_qspi_defconfig| 1 + configs/ls1046ardb_emmc_defconfig | 1 + configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 1 + configs/ls1046ardb_sdcard_defconfig | 1 + 21 files changed, 26 insertions(+), 2 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 1f12283..43f1a9c 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -91,20 +91,24 @@ config SPL_SYS_REPORT_STACK_F_USAGE occurrence of non 0xaa bytes. This default implementation works for stacks growing down only. -menu "PowerPC SPL Boot options" - depends on PPC && (SUPPORT_SPL && !SPL_FRAMEWORK) +menu "PowerPC and LayerScape SPL Boot options" config SPL_NAND_BOOT bool "Load SPL from NAND flash" + depends on PPC && (SUPPORT_SPL && !SPL_FRAMEWORK) config SPL_MMC_BOOT bool "Load SPL from SD Card / eMMC" + depends on PPC && (SUPPORT_SPL && !SPL_FRAMEWORK) config SPL_SPI_BOOT bool "Load SPL from SPI flash" + depends on PPC && (SUPPORT_SPL && !SPL_FRAMEWORK) config SPL_FSL_PBL bool "Create SPL in Freescale PBI format" + depends on (PPC || ARCH_LS1021A || ARCH_LS1043A || ARCH_LS1046A) && \ + SUPPORT_SPL help Create boot binary having SPL binary in PBI format concatenated with u-boot binary. diff --git a/configs/ls1021aiot_sdcard_defconfig b/configs/ls1021aiot_sdcard_defconfig index 55a17f0..0b10e11 100644 --- a/configs/ls1021aiot_sdcard_defconfig +++ b/configs/ls1021aiot_sdcard_defconfig @@ -7,6 +7,7 @@ CONFIG_ENV_OFFSET=0x10 CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_AHCI=y +CONFIG_SPL_FSL_PBL=y CONFIG_SPL_TEXT_BASE=0x1000 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SD_BOOT,SD_BOOT_QSPI" CONFIG_MISC_INIT_R=y diff --git a/configs/ls1021aqds_nand_defconfig b/configs/ls1021aqds_nand_defconfig index a7f3fd1..767f4fd 100644 --- a/configs/ls1021aqds_nand_defconfig +++ b/configs/ls1021aqds_nand_defconfig @@ -10,6 +10,7 @@ CONFIG_ENV_OFFSET=0x14 CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_AHCI=y +CONFIG_SPL_FSL_PBL=y CONFIG_SPL_TEXT_BASE=0x1000 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y diff --git a/configs/ls1021aqds_sdcard_ifc_defconfig b/configs/ls1021aqds_sdcard_ifc_defconfig index b005aff..5071dd5 100644 --- a/configs/ls1021aqds_sdcard_ifc_defconfig +++ b/configs/ls1021aqds_sdcard_ifc_defconfig @@ -11,6 +11,7 @@ CONFIG_ENV_OFFSET=0x30 CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_AHCI=y +CONFIG_SPL_FSL_PBL=y CONFIG_SPL_TEXT_BASE=0x1000 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig b/configs/ls1021aqds_sdcard_qspi_defconfig index 811694f..9469c1c 100644 --- a/configs/ls1021aqds_sdcard_qspi_defconfig +++ b/configs/ls1021aqds_sdcard_qspi_defconfig @@ -11,6 +11,7 @@ CONFIG_ENV_OFFSET=0x30 CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_AHCI=y +CONFIG_SPL_FSL_PBL=y CONFIG_SPL_TEXT_BASE=0x1000 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y diff --git a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig index 2098a7f..3f03424 100644 --- a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig +++ b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig @@ -10,6 +10,7 @@ CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_ENV_SIZE=0x2 CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y +CONFIG_SPL_FSL_PBL=y CONFIG_SPL_TEXT_BASE=0x1000 CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y diff --git a/configs/ls1021atwr_sdcard_ifc_defconfig b/configs/ls1021atwr_sdcard_ifc_defconfig index 18ff9fa..b96123d 100644 ---
Re: [U-Boot] [PATCH] ARM: omapl138_lcdk: Allow early init to start instruction cache
On Sun, Nov 10, 2019 at 10:17:58AM -0600, Adam Ford wrote: > Currently the omapl138_lcdk has SKIP_LOWLEVEL_INIT set. > The README states there is a variation of this for the ARM926EJ-S > which allows the board to just skip the call to lowlevel_init() > and do the normal CP15 init which enables the instruction cache. > > On the da850evm, this was shown to improve startup time. > > This patch switches SKIP_LOWLEVEL_INIT to SKIP_LOWLEVEL_INIT_ONLY > thus, enabling the cache. > > Signed-off-by: Adam Ford > Tested-by: Bartosz Golaszewski > Reviewed-by: Bartosz Golaszewski > > diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h > index 1c41e7e97a..3b5c085a24 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v3 5/5] ARM: MediaTek: add basic support for MT8518 boards
On Thu, Nov 07, 2019 at 07:28:44PM +0800, mingming lee wrote: > This adds a general board file based on MT8518 SoCs from MediaTek. > > Apart from the generic parts (cpu) we add some low level init codes > and initialize the early clocks. > > This commit is adding the basic boot support for the MT8518 eMMC board. > > Signed-off-by: mingming lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 1/4] mmc: davinci: drop support for ti, dm6441-mmc
On Thu, Nov 14, 2019 at 04:10:28PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The DM family of DaVinci SoCs is no longer supported. Drop the > irrelevant code from the driver. > > Signed-off-by: Bartosz Golaszewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH] tbs2910: Disable VxWorks image booting support
On Wed, Nov 27, 2019 at 09:23:05AM -0500, Tom Rini wrote: > There are currently no known users of this functionality on this > platform, disable it to prepare for additional VxWorks functionality > that would cause this platform to fail to link. > > Cc: Soeren Moch > Signed-off-by: Tom Rini > Acked-by: Soeren Moch Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH 5/5] arch: armv8: fsl-layerscape: export serdes config to environment
>-Original Message-
>From: Alex Marginean
>Sent: Tuesday, December 3, 2019 4:16 PM
>To: u-boot@lists.denx.de
>Cc: Priyanka Jain ; Pankaj Bansal
>; Andy Tang ; Vladimir
>Oltean ; Claudiu Manoil
>; Florin Laurentiu Chiculita
>; Razvan Ionut Cirjan
>; Madalin Bucur ;
>Alexandru Marginean
>Subject: [PATCH 5/5] arch: armv8: fsl-layerscape: export serdes config to
>environment
>
>Exports the serdes configuration as an environment variable for LS gen 3
>SoCs, so it can be used in u-boot command line. It should particularly be
>useful for applying Linux DT overlays for the given serdes configuration.
>This code is called from arch_misc_init and not from the existing serdes_init
>function because it depends on U-Boot environment being set up.
>
>Signed-off-by: Alex Marginean
>---
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 1 +
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 14 ++
> .../armv8/fsl-layerscape/fsl_lsch3_serdes.c | 43 +++
> 3 files changed, 58 insertions(+)
>
>diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>index f1578b10bc..40cbea0e12 100644
>--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>@@ -241,6 +241,7 @@ config FSL_LSCH2
> select SYS_FSL_SEC_BE
>
> config FSL_LSCH3
>+ select ARCH_MISC_INIT
> bool
>
> config NXP_LSCH3_2
>diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>index c6490556e6..ddbc07037f 100644
>--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>@@ -1627,3 +1627,17 @@ __weak int dram_init(void)
>
> return 0;
> }
>+
>+#ifdef CONFIG_ARCH_MISC_INIT
>+__weak int serdes_misc_init(void)
>+{
>+ return 0;
>+}
>+
>+int arch_misc_init(void)
>+{
>+ serdes_misc_init();
>+
>+ return 0;
>+}
>+#endif
>diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
>b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
>index 1a747a9e3d..8b9f5a4e29 100644
>--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
>+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
>@@ -600,3 +600,46 @@ void fsl_serdes_init(void)
> serdes3_prtcl_map);
> #endif
> }
>+
>+int serdes_set_env(int sd, int rcwsr, int sd_prctl_mask, int
>+sd_prctl_shift) {
>+ struct ccsr_gur __iomem *gur = (void
>*)(CONFIG_SYS_FSL_GUTS_ADDR);
>+ char scfg[16], snum[16];
>+ int i, cfgr = 0;
>+ u32 cfg;
>+
>+ cfg = gur_in32(>rcwsr[rcwsr - 1]) & sd_prctl_mask;
>+ cfg >>= sd_prctl_shift;
>+ cfg = serdes_get_number(sd, cfg);
>+
>+ /* reverse lanes, lane 0 should be printed first */
>+ for (i = 0; i < SRDS_MAX_LANES; i++)
>+ cfgr |= (cfg >> (i * 4) & 0xf) << (SRDS_MAX_LANES - i - 1) * 4;
>+
>+ snprintf(snum, 16, "serdes%d", sd);
>+ snprintf(scfg, 16, "%x", cfgr);
>+ env_set(snum, scfg);
>+
>+ return 0;
>+}
>+
>+int serdes_misc_init(void)
>+{
>+#ifdef CONFIG_SYS_FSL_SRDS_1
>+ serdes_set_env(FSL_SRDS_1, FSL_CHASSIS3_SRDS1_REGSR,
>+ FSL_CHASSIS3_SRDS1_PRTCL_MASK,
>+ FSL_CHASSIS3_SRDS1_PRTCL_SHIFT); #endif #ifdef
Need new lines in between
>+CONFIG_SYS_FSL_SRDS_2
>+ serdes_set_env(FSL_SRDS_2, FSL_CHASSIS3_SRDS2_REGSR,
>+ FSL_CHASSIS3_SRDS2_PRTCL_MASK,
>+ FSL_CHASSIS3_SRDS2_PRTCL_SHIFT); #endif #ifdef
Same as above
>+CONFIG_SYS_NXP_SRDS_3
>+ serdes_set_env(NXP_SRDS_3, FSL_CHASSIS3_SRDS3_REGSR,
>+ FSL_CHASSIS3_SRDS3_PRTCL_MASK,
>+ FSL_CHASSIS3_SRDS3_PRTCL_SHIFT); #endif
Same as above
>+
>+ return 0;
>+}
>--
>2.17.1
Priyanka
Re: [U-Boot] [PATCH 2/2] mtd: mtdcore: Drop unused mtd_table
On Tue, Nov 26, 2019 at 08:41:00PM -0500, Tom Rini wrote: > The array 'mtd_table' is unused in the code. Remove this as gcc doesn't > always discard unused global variables. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH] spl: ymodem: Fix loading of fit image
On Thu, Nov 14, 2019 at 06:33:30PM +0530, Lokesh Vutla wrote: > spl ymodem driver always assumes that 1 BUF_SIZE is read in one stream. > This might not be true when image is not padded to BUF_SIZE and the last > sector that gets loaded will be < BUF_SIZE. Drop this assumption and use > the actual size that is loaded. > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v1 1/1] cmd: pxe: Fix bootm argument count
On Mon, Nov 18, 2019 at 04:41:49PM -0800, Vladimir Olovyannikov wrote: > From: Abhishek Shah > > pxe command parses the init ramfs address(through initrd lable in > pxe config file), but is not passing it to bootm command as argument > as bootm_argc count is not increased. > > Signed-off-by: Abhishek Shah > Signed-off-by: Vladimir Olovyannikov > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 2/4] mmc: davinci: drop struct davinci_mmc_plat
On Thu, Nov 14, 2019 at 04:10:29PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > struct mmc_config & struct mmc don't need to be exported over platform > data, but can instead be private in the driver. > > Remove struct davinci_mmc_plat. > > Signed-off-by: Bartosz Golaszewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 2/3] Makefile: consolidate hardcoded lists of files to clean
On Sun, Nov 10, 2019 at 08:25:09AM -0800, Thomas Hebb wrote:
> Currently, we have two places where we list files that should always be
> cleaned if they exist. One, the CLEAN_FILES variable, is from the Linux
> build system and is the proper place to list files.
>
> The other, a set of extra arguments passed in the xargs template used to
> remove files with certain extensions, was introduced by 8f06f0cee3d3
> ("Makefile: clean image.map") and is clearly wrong: by extending the
> xargs template, we attempt to remove the files once for each batch of
> arguments that xargs produces and we reduce the number of files from
> stdin that xargs can include in each of its rm commands.
>
> To fix this, put all hardcoded files into CLEAN_FILES.
>
> Signed-off-by: Thomas Hebb
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [U-Boot] [PATCH 3/3] Makefile: add Rockchip idbloader.img to CLEAN_FILES
On Sun, Nov 10, 2019 at 08:25:10AM -0800, Thomas Hebb wrote: > This file is generated in the root during Rockchip builds and so should > be cleaned up. > > Signed-off-by: Thomas Hebb > Reviewed-by: Michael Trimarchi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 3/3] ARM: omapl138_lcdk: Enable SPL_DM_SEQ_ALIAS and SPL_OF_TRANSLATE
On Sun, Nov 10, 2019 at 08:01:33AM -0600, Adam Ford wrote: > In order to further prepare for full device tree support in SPL, > this patch enables both SPL_DM_SEQ_ALIAS and SPL_OF_TRANSLATE. > Both of these are already enabled in U-Boot, so SPL will have > the same functionality > > Signed-off-by: Adam Ford > Tested-by: Bartosz Golaszewski > Reviewed-by: Bartosz Golaszewski > > diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig > index 376bb9f953..c95d06b551 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 1/2] pci: Only link pci_rom.o in some cases
On Tue, Nov 26, 2019 at 08:40:59PM -0500, Tom Rini wrote: > The content of pci_rom.c is only used in a few cases. Only build and > link in these cases to avoid a global variable as gcc doesn't always > discard those when they are unused. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH] bootm: vxworks: Support Linux compatible standard DTB for ARM and PPC
On Fri, Nov 15, 2019 at 12:21:17AM -0800, Bin Meng wrote: > From: Lihua Zhao > > Enhance do_bootm_vxworks() to support Linux compatible standard DTB > for ARM and PPC, when the least significant bit of flags in VxWorks > bootargs is set. Otherwise it falls back to the existing bootm flow > which is now legacy. > > Signed-off-by: Lihua Zhao > Signed-off-by: Bin Meng > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v3 3/5] mmc: mtk-sd: Adjust the mmc tuning flow
On Thu, Nov 07, 2019 at 07:28:42PM +0800, mingming lee wrote: > 1.Support cmd response and data tuning together. > 2.Support hs400 cmd responese tuning. > > Signed-off-by: mingming lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 2/3] ARM: omapl138_lcdk: Increase malloc pool before relocation
On Sun, Nov 10, 2019 at 08:01:32AM -0600, Adam Ford wrote: > Driver model requires a malloc pool to allocate memory before > relocations to operate serial and some other devices. This patch > increases the pool size to 2K. > > Signed-off-by: Adam Ford > Tested-by: Bartosz Golaszewski > Reviewed-by: Bartosz Golaszewski > > diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig > index cceb0c408e..376bb9f953 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 3/4] board: omapl138_lcdk: add the mmc device to SPL
On Thu, Nov 14, 2019 at 04:10:30PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > We don't have full device-tree support in SPL yet - add an appropriate > U_BOOT_DEVICE() to the board file. > > Signed-off-by: Bartosz Golaszewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-dm
On Tue, Dec 03, 2019 at 09:52:28AM -0700, Simon Glass wrote: > Hi Tom, > > Build here: > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1506 > > The following changes since commit dd38416d6b354acb5d12e2bd1fd45e7e63b8a605: > > Merge git://git.denx.de/u-boot-socfpga (2019-11-28 07:34:41 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-3dec19 > > for you to fetch changes up to 151f275e0562a0dcb7b6745131753f968e12b9f0: > > dm: serial: Handle "stdout-path" with ":options" correctly (2019-12-02 > 16:18:05 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for UEFI sub-system for efi-2020-01-rc5
On Tue, Dec 03, 2019 at 08:57:47PM +0100, Heinrich Schuchardt wrote: > The following changes since commit 1297989804d66c8db92efbf9fa2e6cc76965a943: > > Prepare v2020.01-rc4 (2019-12-02 22:09:27 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-01-rc5 > > for you to fetch changes up to 0bffb8c46b109dcd8766e78c357147c07333f6b6: > > cmd: efidebug: fix a build error in show_efi_boot_opt() (2019-12-03 > 20:54:05 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCHv2] blk: Make use of CONFIG_HAVE_BLOCK_DEVICE more
On Mon, Dec 02, 2019 at 10:52:31AM -0500, Tom Rini wrote: > When we do not have CONFIG_BLK (or SPL/TPL) enabled there are very few > cases where we need the blk_legacy code linked in. To catch these, build > when we have CONFIG_HAVE_BLOCK_DEVICE set. In addition, we only need > cmd/blk_common.o to be linked in when we have CONFIG_HAVE_BLOCK_DEVICE > set, so make use of that directly. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v2] armv7m: cache: add invalidate_icache_all() stub
On Tue, Nov 26, 2019 at 12:19:27PM +0100, Giulio Benetti wrote: > This commit: > https://gitlab.denx.de/u-boot/u-boot/commit/d409c962169bd293e39386d0ddfa64d5222a3be4 > causes build failure with ICACHE enabled. This is due to missing > invalidate_icache_all() stub. Let's add empty invalidate_icache_all() in > the case where ICACHE is not enabled. > > Signed-off-by: Giulio Benetti Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 2/2] Convert CONFIG_SYS_CORTINA_FW_IN_MMC et al to Kconfig
On Tue, Nov 26, 2019 at 05:32:43PM -0500, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_CORTINA_FW_IN_MMC >CONFIG_SYS_CORTINA_FW_IN_NAND >CONFIG_SYS_CORTINA_FW_IN_NOR >CONFIG_SYS_CORTINA_FW_IN_REMOTE >CONFIG_SYS_CORTINA_FW_IN_SPIFLASH > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 4/4] mmc: davinci: fix mmc boot in SPL
On Thu, Nov 14, 2019 at 04:10:31PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The MMC boot is currently broken on omapl138-lcdk after enabling the > driver model in SPL. The main problem is the driver's bind callback not > being called after probe in SPL (even with the DM_FLAG_PRE_RELOC flag > specified). > > While a proper fix is still being worked on, this hacky changeset at > least fixes the MMC boot on this platform by calling mmc_bind() > manually from probe(). > > Signed-off-by: Bartosz Golaszewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v2] cosmetic: Fix spelling and whitespace errors
On Wed, Nov 13, 2019 at 06:18:03PM -0800, Thomas Hebb wrote: > Signed-off-by: Thomas Hebb Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH] regmap: Fix potential memory leaks
On Mon, Nov 11, 2019 at 03:29:05PM +0530, Faiz Abbas wrote: > Free allocated memory in case of an error in regmap_init_mem() and > regmap_init_mem_index(). > > Signed-off-by: Faiz Abbas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 3/3] Kconfig: make TPL_DM_SERIAL depend on TPL_DM
On Sun, Nov 10, 2019 at 08:23:55AM -0800, Thomas Hebb wrote: > This missing dependency seems like an oversight, since all other > TPL_DM_* options have it. > > Signed-off-by: Thomas Hebb Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH 1/3] ARM: omapl138_lcdk: Separate BSS in SPL
On Sun, Nov 10, 2019 at 08:01:31AM -0600, Adam Ford wrote: > In preparation to use full device tree support, SPL can separate > BSS from text region. > > This patch enables SPL_SEPARATE_BSS. > > Signed-off-by: Adam Ford > Tested-by: Bartosz Golaszewski > Reviewed-by: Bartosz Golaszewski > > diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig > index 16287a4ac2..cceb0c408e 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v3 4/5] pinctrl: add driver for MT8518
On Thu, Nov 07, 2019 at 07:28:43PM +0800, mingming lee wrote: > Add Pinctrl driver for MediaTek MT8518 SoC. > > Signed-off-by: mingming lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v3 2/5] clk: mediatek: add driver for MT8518
On Thu, Nov 07, 2019 at 07:28:41PM +0800, mingming lee wrote: > Add clock driver for MediaTek MT8518 SoC. > > Signed-off-by: mingming lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH v3 1/5] ARM: MediaTek: Add support for MediaTek MT8518 SoC
On Thu, Nov 07, 2019 at 07:28:40PM +0800, mingming lee wrote: > Add support for MediaTek MT8518 SoC. This include the file > that will initialize the SoC after boot and its device tree. > > Signed-off-by: mingming lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Load Debian/Fedora via EFI
On Tue, Dec 03, 2019 at 08:51:09PM +0100, Heinrich Schuchardt wrote:
> On 12/2/19 3:21 PM, Michal Simek wrote:
> > On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
> >> On 11/29/19 11:16 AM, Michal Simek wrote:
> >>> Hi,
> >>>
> >>> I tried to boot latest debian and fedora rootfs via distro boot and
> >>> getting errors.
> >>> I have tried to run just one command and it is failing.
> >>>
> >>> ZynqMP> bootefi bootmgr ${fdtcontroladdr}
> >>> BootOrder not defined
> >>> EFI boot manager: Cannot load any image
> >>>
> >>> How to define BootOrder?
> >>>
> >>> Thanks,
> >>> Michal
> >>
> >> # Booting via boot manager
> >>
> >> U-Boot currently has no runtime support for variables. But Linaro is
> >> working on it. So update-grub cannot set the variables for you.
> >
> > Who from Linaro is working on it? Akashi?
>
> I was in contact with Ilias Apalodimas but do not know who is doing the
> actual work.
>
> See https://youtu.be/SEMJGOzjrHY @ 14:00
This is still under discussion for us. We'll either support runtime variables as
defined in the UEFI spec or present a cached copy on Linux. You can then build a
capsule and update the variables on next boot.
In any case capsule updates are not supported yet, so any path we choose
requires some development.
I'll try to keep both of you updated on the development process.
Cheers
/Ilias
Re: [PATCH v2 00/16] efi_loader: add secure boot support
Tom, Simon, Heinrich, I have submitted three major patch sets for UEFI secure boot: * x509/pkcs7 parser * RSA library extension * UEFI secure boot I have no technical issues to fix now and have seen only a few minor comments on them (if I confirm that you have no more comments, I can submit new version almost immediately). Considering those, can I expect that those patches be merged in v2020.01? If not, do you need to have more time for your reviewing? What else do you expect from my side to accelerate the upstream? Please let me know your review status and your expectation. (I'm not pushing you, but just asking.) Thanks, -Takahiro Akashi On Tue, Nov 26, 2019 at 09:51:04AM +0900, AKASHI Takahiro wrote: > One of major missing features in current UEFI implementation is "secure boot." > The ultimate goal of my attempt is to implement image authentication based > on signature and provide UEFI secure boot support which would be fully > compliant with UEFI specification, section 32[1]. > (The code was originally developed by Patrick Wildt.) > > While this patch/RFC is still rough-edged, the aim here is to get early > feedbacks from the community as the patch is quite huge (in total) and also > as it's a security enhancement. > > Please note, however, this patch doesn't work on its own; there are > a couple of functional dependencies[2] and [3], that I have submitted > before. For complete workable patch set, see my repository[4], > which also contains exeperimental timestamp-based revocation suuport. > > My "non-volatile" support[5], which is under discussion, is not mandatory > and so not included here, but this inevitably implies that, for example, > signature database variables, like db and dbx, won't be persistent unless you > explicitly run "env save" command and that UEFI variables are not separated > from U-Boot environment. Anyhow, Linaro is also working on implementing > real "secure storage" solution based on TF-A and OP-TEE. > > > Supported features: > * image authentication based on db and dbx > * supported signature types are > EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images) > EFI_CERT_X509_GUID (x509 certificate for signed images) > * SecureBoot/SignatureSupport variables > * SetupMode and user mode > * variable authentication based on PK and KEK > EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS > * basic pytest test cases > > Unsupported features: (marked as TODO in most cases in the source code, > and won't be included in this series) > * hash algorithms other than SHA256 > * dbt: timestamp(RFC6131)-based certificate revocation > * dbr: OS recovery > * xxxDefault: default values for signature stores > * transition to AuditMode and DeployedMode > * recording rejected images in EFI_IMAGE_EXECUTION_INFO_TABLE > * verification "policy", in particular, check against signature's owner > * private authenticated variables > * variable authentication with EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS > * real secure storage support, including hardware-specific PK (Platform Key) > installation > > TODO's other than "Unsupported features": (won't be included in this series) > * struct efi_image_regions cannot have arbitrary number of regions > * fail recovery, in particular, in modifying authenticated variables > * support read-only attributes of well-defined global variables > in particular, "SignatureSupport" > * Extensive test suite (or more test cases) to confirm compatibility > with EDK2 > => I requested EDK SCT community to add tests[6]. > > Test: > * my pytest, included in this patch set, passed. > * efi_selftest passed. (At least no reguression.) > * Travis CI tests, except the following two, have passed: > - test/py sandbox > test/py/tests/test_fs/test_unlink.py test_unlink2 > - test/py sandbox with clang > cmd/efidebug.c:703:15: error: result of comparison of constant > 9223372036854775822 with expression of type 'int' is always false > [-Werror,-Wtautological-constant-out-of-range-compare] > But as you can see, those have nothing to do with my UEFI secure boot > patch and are existing bugs. > > Known issues: > * efitools is used in pytest, and its version must be v1.5.2 or later. > (Solution: You can define EFITOOLS_PATH in defs.py for your own efitools.) > * Pytest depends on standalone "helloworld" app for sandbox > (Solution: You can define HELLO_PATH in defs.py or Heinrich's [7].) > * Travis CI errors mentioned above > => I will send *separate* bug-fix patches once fixed. > > > Hints about how to use: > (Please see other documents, or my pytest scripts, for details.) > * You can create your own certificates with openssl. > * You can sign your application with sbsign (on Ubuntu). > * You can create raw data for signature database with efitools, and > install/manage authenticated variables with "env -set -e" command > or efitools' "UpdateVars.efi" application. > > > [1]
RE: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
> Subject: Re: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
>
> On 12/3/2019 5:07 PM, Peng Fan wrote:
> >
> >
> >> -Original Message-
> >> From: Troy Kisky
> >> Sent: 2019年12月4日 6:54
> >> To: Peng Fan ; Stefano Babic ;
> >> u-boot@lists.denx.de
> >> Subject: re: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
> >>
> >> |+ gpio1: gpio@3020 {
> >> |+ compatible = "fsl,imx8mn-gpio",
> >> |"fsl,imx35-gpio";
> >> |+ reg = <0x3020 0x1>;
> >>
> >> Should these be 64 bit addresses ?
> >
> > This is imported from Linux Kernel.
> > No. address-size, cell-size is 1.
> >
> > Regards,
> > Peng.
> >
> >>
> >> tkisky@OS2:~/u-boot$ make imx8mn_ddr4_evk_defconfig # #
> configuration
> >> written to .config # tkisky@OS2:~/u-boot$ grep PHYS_64BIT .config
> >> CONFIG_PHYS_64BIT=y
> >>
> >>
> >> Thanks
> >> Troy
>
> So, is this code buggy ?
Yes, please use devfdt_get_addr_size_index
Regards,
Peng.
>
> /lib/fdtdec.c
> _
> fdt_addr_t fdtdec_get_addr_size(const void *blob, int node,
> const char *prop_name, fdt_size_t *sizep) {
> int ns = sizep ? (sizeof(fdt_size_t) / sizeof(fdt32_t)) : 0;
>
> return fdtdec_get_addr_size_fixed(blob, node, prop_name, 0,
> sizeof(fdt_addr_t) / sizeof(fdt32_t),
> ns, sizep, false);
> }
> _
>
>
> It is using "sizeof(fdt_addr_t) / sizeof(fdt32_t)" instead of "address-cells"
>
>
> Thanks
> Troy
RE: [U-Boot] [EXT] Re: [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode
> -Original Message- > From: Ramon Fried > Sent: 2019年12月4日 4:01 > To: Xiaowei Bao > Cc: Ramon Fried ; Hongbo Wang > ; u-boot@lists.denx.de; York Sun > ; Z.q. Hou ; Mingkai Hu > > Subject: Re: [U-Boot] [EXT] Re: [PATCHv2 1/2] PCI: layerscape: Add Support > for ls2088 PCIe EP mode > > On Tue, Dec 3, 2019 at 4:32 AM Xiaowei Bao wrote: > > > > Hi Ramon, > > > > Do you have any comments about this? Thanks a lot. > > > > Best regards > > Xiaowei > > > > From: Xiaowei Bao > > Sent: 2019年11月26日 10:52 > > To: Ramon Fried > > Cc: Bin Meng ; Simon Glass ; > > M.h. Lian ; Z.q. Hou ; > > Mingkai Hu ; Hongbo Wang > ; > > York Sun ; u-boot@lists.denx.de > > Subject: RE: [EXT] Re: [U-Boot] [PATCHv2 1/2] PCI: layerscape: Add > > Support for ls2088 PCIe EP mode > > > > H Ramon, > > > > Thanks for your comments. > > If we reimplement the PCIe EP driver base on PCIe UCLASS, we must test it > in u-boot, but I have no idea how to test the actual device, do I need to > implement our own test case, how to verify the cadence-ep actual device? > > > I'm not sure I understand what you're trying to achieve and why you're > referring to the cadence. > You're developing a driver, just test it against a client (IE. a real PCIe > root-complex). > The cadence is irrelevant, it's just another implementation of endpoint > driver. Thanks for your comments, do you mean that we can use the 'pci' and 'md' command of u-boot to test the EP device when the controller which work as a EP device connect to a RC port, we can access the BAR base on the "pci header" command, yes? but if I want to test memory access from EP to RC, what should I do, because there is not a command which similar to 'pci' to test. Another issue is that, due to the history reason of Layerscape PCIe controller driver, the EP and RC codes are combined, if I separate the EP and RC code, there will have many duplicate code. Thanks Xiaowei > Thanks, > Ramon. > > Best regards > > Xiaowei > > U-Boot@lists.denx.de > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > > s.denx.de%2Flistinfo%2Fu-bootdata=02%7C01%7Cxiaowei.bao%40nxp > .com > > %7Cad7a366db91f4e40273308d7782b7fc8%7C686ea1d3bc2b4c6fa92cd99 > c5c301635 > > %7C0%7C0%7C63711532938430sdata=T0D3QR5RzdFv96syOlG > VK7OEBQyNdl > > 8M9pfd%2F4vxOIg%3Dreserved=0
Re: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
On 12/3/2019 5:07 PM, Peng Fan wrote:
>
>
>> -Original Message-
>> From: Troy Kisky
>> Sent: 2019年12月4日 6:54
>> To: Peng Fan ; Stefano Babic ;
>> u-boot@lists.denx.de
>> Subject: re: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
>>
>> |+ gpio1: gpio@3020 {
>> |+ compatible = "fsl,imx8mn-gpio",
>> |"fsl,imx35-gpio";
>> |+ reg = <0x3020 0x1>;
>>
>> Should these be 64 bit addresses ?
>
> This is imported from Linux Kernel.
> No. address-size, cell-size is 1.
>
> Regards,
> Peng.
>
>>
>> tkisky@OS2:~/u-boot$ make imx8mn_ddr4_evk_defconfig # # configuration
>> written to .config # tkisky@OS2:~/u-boot$ grep PHYS_64BIT .config
>> CONFIG_PHYS_64BIT=y
>>
>>
>> Thanks
>> Troy
So, is this code buggy ?
/lib/fdtdec.c
_
fdt_addr_t fdtdec_get_addr_size(const void *blob, int node,
const char *prop_name, fdt_size_t *sizep)
{
int ns = sizep ? (sizeof(fdt_size_t) / sizeof(fdt32_t)) : 0;
return fdtdec_get_addr_size_fixed(blob, node, prop_name, 0,
sizeof(fdt_addr_t) / sizeof(fdt32_t),
ns, sizep, false);
}
_
It is using "sizeof(fdt_addr_t) / sizeof(fdt32_t)" instead of "address-cells"
Thanks
Troy
RE: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
> -Original Message-
> From: Troy Kisky
> Sent: 2019年12月4日 6:54
> To: Peng Fan ; Stefano Babic ;
> u-boot@lists.denx.de
> Subject: re: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
>
> |+ gpio1: gpio@3020 {
> |+ compatible = "fsl,imx8mn-gpio",
> |"fsl,imx35-gpio";
> |+ reg = <0x3020 0x1>;
>
> Should these be 64 bit addresses ?
This is imported from Linux Kernel.
No. address-size, cell-size is 1.
Regards,
Peng.
>
> tkisky@OS2:~/u-boot$ make imx8mn_ddr4_evk_defconfig # # configuration
> written to .config # tkisky@OS2:~/u-boot$ grep PHYS_64BIT .config
> CONFIG_PHYS_64BIT=y
>
>
> Thanks
> Troy
[PATCH 1/2] rockchip: misc: Only assign serial# variable if unset
The serial# environment variable is a read-only special variable, that
can only be set once. As a result, if the environment was saved to a
persistent storage location, attempting to set it again in
rockchip_cpuid_set will fail and halt the boot with the following error:
Solve this by checking whether the variable is already set before.
Signed-off-by: Paul Kocialkowski
---
arch/arm/mach-rockchip/misc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index bed4317f7ece..a0c6a1c0b266 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -108,12 +108,16 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32
cpuid_length)
high[i] = cpuid[i << 1];
}
- serialno = crc32_no_comp(0, low, 8);
- serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
- snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
-
env_set("cpuid#", cpuid_str);
- env_set("serial#", serialno_str);
+
+ if (!env_get("serial#")) {
+ serialno = crc32_no_comp(0, low, 8);
+ serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
+ snprintf(serialno_str, sizeof(serialno_str), "%016llx",
+serialno);
+
+ env_set("serial#", serialno_str);
+ }
return 0;
}
--
2.24.0
Re: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Tue, Dec 03, 2019 at 09:09:48PM +0100, Simon Goldschmidt wrote: > Am 03.12.2019 um 15:59 schrieb Dalon L Westergreen: > > > > > > On Tue, 2019-12-03 at 14:45 +, Ang, Chee Hong wrote: > > > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong < > > > > chee.hong@intel.com > > > > > > > > > wrote: > > > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > > > > > > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > > > > > > < > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > > > > > > < > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > > > > > > > > < > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM < > > > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > From: "Ang, Chee Hong" < > > > > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) > > > > > > > > > > > > > > > support: > > > > > > > > > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper > > > > > > > > > > > > > > > (EL2) -> > > > > > > > > > > > > > > > Linux > > > > > > > > > > > > > > > (EL1) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Adding support for ATF means that using U-Boot on > > > > > > > > > > > > > > Stratix10 > > > > > > > > > > > > > > and Agilex without ATF keeps working, right? > > > > > > > > > > > > > > > > > > > > > > > > > > ATF is needed in order for Stratix10 and Agilex's > > > > > > > > > > > > > U-Boot > > > > > > > > > > > > > to work. > > > > > > > > > > > > > > > > > > > > > > > > Is there a technical requirement for that? > > > > > > > > > > > > > > > > > > > > > > Yes. We are using ATF to provide PSCI services such as > > > > > > > > > > > system > > > > > > > > > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) > > > > > > > > > > > and > > > > > > > > > > > other secure services such as mailbox communications with > > > > > > > > > > > Secure Device Manager and accessing the System Manager > > > > > > > > > > > registers which are > > > > > > > > > > > > > > > > secure. > > > > > > > > > > > Without PSCI services, we are able to boot until U-Boot > > > > > > > > > > > proper > > > > > > > > > > > only. > > > > > > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux > > > > > > > > > > > due to > > > > > > > > > > > these missing > > > > > > > > > > > > > > > > > > > > PSCI services. > > > > > > > > > > > Another reason is we have another boot flow which is > > > > > > > > > > > using ATF > > > > > > > > > > > + > > > > > > > > UEFI. > > > > > > > > > > > So now we are re-using the PSCI services from ATF so that > > > > > > > > > > > now > > > > > > > > > > > U-Boot and UEFI share the same ATF-BL31 image so that we > > > > > > > > > > > don't > > > > > > > > > > > have to > > > > > > > > > > > > > > > > > > > > reimplement another sets of PSCI services for U-Boot again. > > > > > > > > > > > This will greatly reduce our engineering efforts. > > > > > > > > > > > > > > > > > > > > Hmm, thanks for the explanation. > > > > > > > > > > > > > > > > > > > > I don't really think I can review this, given the lack of > > > > > > > > > > knowledge about that PSCI stuff. > > > > > > > > > > > > > > > > > > I believe you can review it. > > > > > > > > > Have you briefly gone through the patches ? It has nothing to > > > > > > > > > do > > > > > > > > > with the PSCI > > > > > > > > > > > > > > > > stuff. > > > > > > > > > It just call the invoke_smc() function to call the ATF's PSCI > > > > > > > > > functions. Those PSCI functions in ATF will do the rest. > > > > > > > > > > > > > > > > No, not yet. But see below. > > > > > > > > > > > > > > > > > > I must say it seems strange to me that U-Boot would have to > > > > > > > > > > rely on ATF > > > > > > > > > > > > > > > > though. > > > > > > > > > > How do other platforms implement this? Shouldn't PSCI be > > > > > > > > > > generic or is it really platform specific? If it's generic, > > > > > > > > > > isn't that a dupliation of code if you implement e.g. a > > > > > > > > > > reset > > > > > > > > > > driver for > > > > > > > > > > Stratix10 but call > > > > > > > > > > > > > > > > into PSCI? > > > > > > > > > It's not strange at all. A lot of U-Boot users already using > > > > > > > > > this boot flow (ATF + > > > > > > > > > > > > > > > > U-Boot). > > > > > > > > > > > > > > > > Just because other boards do this doesn't mean it's not strange. > > > > > > > > Wasn't there some kind of discussion around that PSCI
[PATCH 1/4] spl: opensbi: specify main hart as preferred boot hart
OpenSBI uses a relocation lottery to determine the hart to relocate
OpenSBI to its link address. In the U-Boot SPL boot flow, the main hart
schedules the secondary harts to enter OpenSBI before doing so itself.
One of the secondary harts will therefore always be the winner of the
relocation lottery. This is problematic if the link address ranges of
OpenSBI and U-Boot SPL overlap. OpenSBI will be relocated and therefore
overwrite U-Boot SPL while some harts may still run it, leading to code
corruption.
Avoid this problem by specifying the main hart as the preferred boot
hart to perform the OpenSBI relocation. The main hart will be the last
hart to enter OpenSBI, relocation can therefore occur safely.
The boot hart field was added to version 2 of the OpenSBI FW_DYNAMIC
info structure. The header file include/opensbi.h is synchronized with
include/sbi/fw_dynamic.h from the OpenSBI project to update the info
structure. The header file is recent as of commit
7a13beb21326 ("firmware: Add preferred boot HART field in struct
fw_dynamic_info").
Reported-by: Rick Chen
Suggested-by: Anup Patel
Signed-off-by: Lukas Auer
---
common/spl/spl_opensbi.c | 1 +
include/opensbi.h| 18 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index a6b4480ed2..79ee7edcf9 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -69,6 +69,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
opensbi_info.next_addr = uboot_entry;
opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
opensbi_info.options = SBI_SCRATCH_NO_BOOT_PRINTS;
+ opensbi_info.boot_hart = gd->arch.boot_hart;
opensbi_entry = (void (*)(ulong, ulong, ulong))spl_image->entry_point;
invalidate_icache_all();
diff --git a/include/opensbi.h b/include/opensbi.h
index 9f1d62e7dd..d812cc8ccd 100644
--- a/include/opensbi.h
+++ b/include/opensbi.h
@@ -11,7 +11,7 @@
#define FW_DYNAMIC_INFO_MAGIC_VALUE0x4942534f
/** Maximum supported info version */
-#define FW_DYNAMIC_INFO_VERSION0x1
+#define FW_DYNAMIC_INFO_VERSION0x2
/** Possible next mode values */
#define FW_DYNAMIC_INFO_NEXT_MODE_U0x0
@@ -35,6 +35,22 @@ struct fw_dynamic_info {
unsigned long next_mode;
/** Options for OpenSBI library */
unsigned long options;
+ /**
+* Preferred boot HART id
+*
+* It is possible that the previous booting stage uses same link
+* address as the FW_DYNAMIC firmware. In this case, the relocation
+* lottery mechanism can potentially overwrite the previous booting
+* stage while other HARTs are still running in the previous booting
+* stage leading to boot-time crash. To avoid this boot-time crash,
+* the previous booting stage can specify last HART that will jump
+* to the FW_DYNAMIC firmware as the preferred boot HART.
+*
+* To avoid specifying a preferred boot HART, the previous booting
+* stage can set it to -1UL which will force the FW_DYNAMIC firmware
+* to use the relocation lottery mechanism.
+*/
+ unsigned long boot_hart;
} __packed;
#endif
--
2.21.0
Re: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Tue, 2019-12-03 at 14:45 +, Ang, Chee Hong wrote: > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong < > > chee.hong@intel.com > > > > > wrote: > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > > > > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > > > > < > > > > > > chee.hong@intel.com > > > > > > > > > > > > > wrote: > > > > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > > > > < > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > > > > > > < > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM < > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > From: "Ang, Chee Hong" < > > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) > > > > > > > > > > > > > support: > > > > > > > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> > > > > > > > > > > > > > Linux > > > > > > > > > > > > > (EL1) > > > > > > > > > > > > > > > > > > > > > > > > Adding support for ATF means that using U-Boot on > > > > > > > > > > > > Stratix10 > > > > > > > > > > > > and Agilex without ATF keeps working, right? > > > > > > > > > > > > > > > > > > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot > > > > > > > > > > > to work. > > > > > > > > > > > > > > > > > > > > Is there a technical requirement for that? > > > > > > > > > > > > > > > > > > Yes. We are using ATF to provide PSCI services such as system > > > > > > > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and > > > > > > > > > other secure services such as mailbox communications with > > > > > > > > > Secure Device Manager and accessing the System Manager > > > > > > > > > registers which are > > > > > > > > > > > > secure. > > > > > > > > > Without PSCI services, we are able to boot until U-Boot proper > > > > > > > > > only. > > > > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux due to > > > > > > > > > these missing > > > > > > > > > > > > > > > > PSCI services. > > > > > > > > > Another reason is we have another boot flow which is using ATF > > > > > > > > > + > > > > UEFI. > > > > > > > > > So now we are re-using the PSCI services from ATF so that now > > > > > > > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't > > > > > > > > > have to > > > > > > > > > > > > > > > > reimplement another sets of PSCI services for U-Boot again. > > > > > > > > > This will greatly reduce our engineering efforts. > > > > > > > > > > > > > > > > Hmm, thanks for the explanation. > > > > > > > > > > > > > > > > I don't really think I can review this, given the lack of > > > > > > > > knowledge about that PSCI stuff. > > > > > > > > > > > > > > I believe you can review it. > > > > > > > Have you briefly gone through the patches ? It has nothing to do > > > > > > > with the PSCI > > > > > > > > > > > > stuff. > > > > > > > It just call the invoke_smc() function to call the ATF's PSCI > > > > > > > functions. Those PSCI functions in ATF will do the rest. > > > > > > > > > > > > No, not yet. But see below. > > > > > > > > > > > > > > I must say it seems strange to me that U-Boot would have to > > > > > > > > rely on ATF > > > > > > > > > > > > though. > > > > > > > > How do other platforms implement this? Shouldn't PSCI be > > > > > > > > generic or is it really platform specific? If it's generic, > > > > > > > > isn't that a dupliation of code if you implement e.g. a reset > > > > > > > > driver for > > > > > > > > Stratix10 but call > > > > > > > > > > > > into PSCI? > > > > > > > It's not strange at all. A lot of U-Boot users already using > > > > > > > this boot flow (ATF + > > > > > > > > > > > > U-Boot). > > > > > > > > > > > > Just because other boards do this doesn't mean it's not strange. > > > > > > Wasn't there some kind of discussion around that PSCI stuff to > > > > > > make it > > > > > > > > available from U-Boot? > > > > > > What's wrong with that way? > > > > > > > > > > Our downstream U-Boot branch is already implemented the PSCI > > > > > stuffs in U- > > > > > > > > Boot. > > > > > I tried to upstream my PSCI code: > > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html > > > > > > > > > > > > > > > Marek pointed me to this thread: > > > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html > > > > > > > > > > > > > > > He had a point. He suggested maybe we can implement the PSCI > > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out > > > > > ATF is already well > > > > > > > > supported. Why don't we just use the PSCI code from ATF rather than > > > > re- implementing
re: [U-Boot] [PATCH 16/17] imx: add dtsi for i.MX8MN
|+ gpio1: gpio@3020 {
|+ compatible = "fsl,imx8mn-gpio",
|"fsl,imx35-gpio";
|+ reg = <0x3020 0x1>;
Should these be 64 bit addresses ?
tkisky@OS2:~/u-boot$ make imx8mn_ddr4_evk_defconfig
#
# configuration written to .config
#
tkisky@OS2:~/u-boot$ grep PHYS_64BIT .config
CONFIG_PHYS_64BIT=y
Thanks
Troy
[PATCH] spl: fit: enable hash control even without signature
The function "fit_image_verify_with_data" that performs the integrity
protection of FIT images is already able to correctly manage the device
tree nodes that require signature and/or hash control.
Tests with device tree with or without hash nodes but certainly not
signed have given positive results. Furthermore, the hash calculation
is performed only if the hash property has been detected, without
adding unnecessary calculations.
It is therefore useless and limiting to enable hash control only in
the case of a signed image.
Signed-off-by: Dario Binacchi
---
common/spl/spl_fit.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index cbc00a4e7c..58ba40cb2f 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -242,14 +242,12 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
src = (void *)data;
}
-#ifdef CONFIG_SPL_FIT_SIGNATURE
printf("## Checking hash(es) for Image %s ... ",
fit_get_name(fit, node, NULL));
if (!fit_image_verify_with_data(fit, node,
src, length))
return -EPERM;
puts("OK\n");
-#endif
#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
board_fit_image_post_process(, );
--
2.24.0
Re: [U-Boot] [ANNOUNCEMENT] Expect ML downtime at 2019-12-03 11:00 CET
Hi Claudius, On 12/3/2019 1:28 PM, Claudius Heine wrote: On 03/12/2019 11.25, Claudius Heine wrote: On 03/12/2019 10.05, Claudius Heine wrote: On 03/12/2019 08.44, Claudius Heine wrote: Hi everyone, because we are moving the mailing list to a different server, we have to take it down for hopefully only a few minutes. The DNS entries need to be updated, so it might take a while until those will stabilize. An update: We will also start sending mail over TLS only. That means that your smtp server needs to accept TLS connections. We will accept incoming unencrypted smtpd connections for now, but might disable that at some point as well. If you received this mail, then the migration to the new server was successful. If you encounter any issues then please message me and I will try to sort them out. The mailing will also no longer add the prefix to the subject line or the footer at the end of each message. This change should also now prevent invalidating the DKIM signature of messages. regards, Claudius I've sent 6 patches plus cover about one hour ago and so far patchwork picked up 4 of the patches and I've received 2 in my gmail account. I don't think this is caused by the smtp server I'm using to send, it the new mailing list server running OK? Thank you! Alex
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
On Tue, Dec 03, 2019 at 02:56:38PM -0600, Joe Hershberger wrote: > Hey Tom, > > On Tue, Dec 3, 2019 at 11:05 AM Tom Rini wrote: > > > > On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote: > > > Hi Tom, > > > > > > On Mon, Dec 2, 2019 at 9:11 PM Tom Rini wrote: > > > > > > > > Hey all, > > > > > > > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > > > > fixing all of the issues that pop up as I get the MTD clean-up series > > > > ready to go. In fact, what I need to do at this point is grab the > > > > handful of size reduction patches that this has shown are worthwhile, > > > > then I can do the MTD series. Then we're down to just fixing up > > > > misconversions where things got turned off. > > > > > > > > Once again, for a changelog, > > > > git log --merges v2020.01-rc3..v2020.01-rc4 > > > > and as always, I ask for more details in the PRs people send me so I can > > > > put them in the merge commit. > > > > > > > > I'm planning on doing -rc5 on December 23rd with the release scheduled > > > > on January 6th. Thanks all! > > > > > > I have a -net PR just about ready, but there are a few boards failing > > > for size. When can I expect the size reduction to drop? > > > > How much are they failing? You can rebase on top of > > WIP/2019-12-03-master-imports and see if that's enough. But also if > > arm: + tbs2910 > +u-boot.imx exceeds file size limit: > 1356+ limit: 0x5fc00 bytes > 1357+ actual: 0x60c00 bytes > 1358+ excess: 0x1000 bytes Might be fine now, we're clearing out a few bytes. >arm: + am335x_boneblack_vboot > 922+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will > not fit in region `.sram' > 923+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 392 bytes > 924+make[2]: *** [spl/u-boot-spl] Error 1 > 925+make[1]: *** [spl/u-boot-spl] Error 2 > 926+make: *** [sub-make] Error 2 > 927 arm: + am335x_evm > 928+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will > not fit in region `.sram' > 929+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 664 bytes > 930+make[2]: *** [spl/u-boot-spl] Error 1 > 931+make[1]: *** [spl/u-boot-spl] Error 2 > 932+make: *** [sub-make] Error 2 SPL is unchanged in all cases. What's causing this growth anyhow? Thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/4] riscv: add functions for reading the IPI status
Add the function riscv_get_ipi() for reading the pending status of IPIs.
The supported controllers are Andes' Platform Level Interrupt Controller
(PLIC), the Supervisor Binary Interface (SBI), and SiFive's Core Local
Interruptor (CLINT).
Signed-off-by: Lukas Auer
---
I do not have access to the datasheet of the Andes PLIC. The
riscv_clear_ipi() implementation seems to read the IPI status from the
claim register before writing back the results to clear them. Based on
this, I also used the claim register. Rick, please let me know if that
is ok or if I should use the pending register instead.
arch/riscv/lib/andes_plic.c | 9 +
arch/riscv/lib/sbi_ipi.c | 11 +++
arch/riscv/lib/sifive_clint.c | 9 +
arch/riscv/lib/smp.c | 12
4 files changed, 41 insertions(+)
diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
index 28568e4e2b..731ac3a148 100644
--- a/arch/riscv/lib/andes_plic.c
+++ b/arch/riscv/lib/andes_plic.c
@@ -114,6 +114,15 @@ int riscv_clear_ipi(int hart)
return 0;
}
+int riscv_get_ipi(int hart, int *pending)
+{
+ PLIC_BASE_GET();
+
+ *pending = !!readl((void __iomem *)CLAIM_REG(gd->arch.plic, hart));
+
+ return 0;
+}
+
static const struct udevice_id andes_plic_ids[] = {
{ .compatible = "riscv,plic1", .data = RISCV_SYSCON_PLIC },
{ }
diff --git a/arch/riscv/lib/sbi_ipi.c b/arch/riscv/lib/sbi_ipi.c
index 170346da68..9a698ce74e 100644
--- a/arch/riscv/lib/sbi_ipi.c
+++ b/arch/riscv/lib/sbi_ipi.c
@@ -23,3 +23,14 @@ int riscv_clear_ipi(int hart)
return 0;
}
+
+int riscv_get_ipi(int hart, int *pending)
+{
+ /*
+* The SBI does not support reading the IPI status. We always return 0
+* to indicate that no IPI is pending.
+*/
+ *pending = 0;
+
+ return 0;
+}
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index d24e0d585b..d7899d16d7 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -71,6 +71,15 @@ int riscv_clear_ipi(int hart)
return 0;
}
+int riscv_get_ipi(int hart, int *pending)
+{
+ CLINT_BASE_GET();
+
+ *pending = readl((void __iomem *)MSIP_REG(gd->arch.clint, hart));
+
+ return 0;
+}
+
static const struct udevice_id sifive_clint_ids[] = {
{ .compatible = "riscv,clint0", .data = RISCV_SYSCON_CLINT },
{ }
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
index cc66f15567..6ff0de4b74 100644
--- a/arch/riscv/lib/smp.c
+++ b/arch/riscv/lib/smp.c
@@ -31,6 +31,18 @@ extern int riscv_send_ipi(int hart);
*/
extern int riscv_clear_ipi(int hart);
+/**
+ * riscv_get_ipi() - Get status of inter-processor interrupt (IPI)
+ *
+ * Platform code must provide this function.
+ *
+ * @hart: Hart ID of hart to be checked
+ * @pending: Pointer to variable with result of the check,
+ * 1 if IPI is pending, 0 otherwise
+ * @return 0 if OK, -ve on error
+ */
+extern int riscv_get_ipi(int hart, int *pending);
+
static int send_ipi_many(struct ipi_data *ipi)
{
ofnode node, cpus;
--
2.21.0
Re: [PATCH v2 1/2] common: fdt_support: add support for setting usable memory
On Tue, 2019-12-03 at 14:04 +0200, Igor Opaniuk wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > From: Igor Opaniuk > > Add support for setting linux,usable-memory property in the memory > node of device tree for the kernel [1]. Isn't this same/similar to fdt_add_mem_rsv() ? Jocke
[PATCH 0/4] Fixes for RISC-V U-Boot SPL / OpenSBI boot flow
Rick's recent patch series, which adds support for U-Boot SPL to the Andes platform, brought several problems of the current U-Boot SPL boot flow on RISC-V to light. Discussion on the relevant parts starts at [1]. The problem showed itself in the form of code corruption. At start, OpenSBI relocates itself to its link address. This allows it to be loaded independently of the link address. In the case that the link address ranges of U-Boot SPL and OpenSBI overlap, code corruption occurs if the relocation starts while some harts are still running U-Boot SPL. This series prevents this problem by specifying the hart that performs the relocation and then making sure that it is the last hart to enter OpenSBI, allowing relocation to be completed safely. A recent version of OpenSBI is required for the changes to work. This patch series resolves the problems associated with the use case of overlapping link address ranges. However, it is still recommended to select non-overlapping ranges for U-Boot SPL and OpenSBI. [1]: https://lists.denx.de/pipermail/u-boot/2019-November/389385.html Lukas Auer (4): spl: opensbi: specify main hart as preferred boot hart riscv: add functions for reading the IPI status riscv: add option to wait for ack from secondary harts in smp functions spl: opensbi: wait for ack from secondary harts before entering OpenSBI arch/riscv/cpu/start.S| 2 ++ arch/riscv/include/asm/smp.h | 3 ++- arch/riscv/lib/andes_plic.c | 9 arch/riscv/lib/bootm.c| 2 +- arch/riscv/lib/sbi_ipi.c | 11 + arch/riscv/lib/sifive_clint.c | 9 arch/riscv/lib/smp.c | 43 +++ arch/riscv/lib/spl.c | 2 +- common/spl/spl_opensbi.c | 13 ++- include/opensbi.h | 18 ++- 10 files changed, 98 insertions(+), 14 deletions(-) -- 2.21.0
Re: [PATCH] arm: imx: Default to SYS_THUMB_BUILD for i.MX6/7
On Tue, Dec 03, 2019 at 01:34:25PM -0300, Fabio Estevam wrote: > Hi Tom, > > On Tue, Dec 3, 2019 at 11:28 AM Tom Rini wrote: > > > > In the case of i.MX6 and i.MX7 family SoCs it is safe (from an errata > > point of view) to use thumb2 by default to save space. > > > > Cc: Stefano Babic > > Cc: Fabio Estevam > > Signed-off-by: Tom Rini > > I think it is safer to apply this after 2020.01 is released: Agreed. Posted before it slips my mind :) -- Tom signature.asc Description: PGP signature
[PATCH 4/4] spl: opensbi: wait for ack from secondary harts before entering OpenSBI
At the start, OpenSBI relocates itself to its link address. If the link address ranges of U-Boot SPL and OpenSBI overlap, the relocation can lead to code corruption if a hart is still running U-Boot SPL during relocation. To avoid this problem, the main hart is specified as the preferred boot hart to perform the relocation. This fixes the code corruption problems based on the assumption that since the main hart schedules the secondary harts to enter OpenSBI, it will be the last to enter OpenSBI. However it was reported that this assumption is not always correct. To make sure the assumption always holds true, wait for all secondary harts to acknowledge the call-function request before entering OpenSBI on the main hart. Reported-by: Rick Chen Signed-off-by: Lukas Auer --- common/spl/spl_opensbi.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c index 91a411a3db..5ea59d423f 100644 --- a/common/spl/spl_opensbi.c +++ b/common/spl/spl_opensbi.c @@ -75,9 +75,19 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image) invalidate_icache_all(); #ifdef CONFIG_SMP + /* +* Start OpenSBI on all secondary harts and wait for acknowledgment. +* +* OpenSBI first relocates itself to its link address. This is done by +* the main hart. To make sure no hart is still running U-Boot SPL +* during relocation, we wait for all secondary harts to acknowledge +* the call-function request before entering OpenSBI on the main hart. +* Otherwise, code corruption can occur if the link address ranges of +* U-Boot SPL and OpenSBI overlap. +*/ ret = smp_call_function((ulong)spl_image->entry_point, (ulong)spl_image->fdt_addr, - (ulong)_info, 0); + (ulong)_info, 1); if (ret) hang(); #endif -- 2.21.0
[PATCH 3/4] riscv: add option to wait for ack from secondary harts in smp functions
Add a wait option to smp_call_function() to wait for the secondary harts
to acknowledge the call-function request. The request is considered to
be acknowledged once each secondary hart has cleared the corresponding
IPI.
As part of the call-function request, the secondary harts invalidate the
instruction cache after clearing the IPI. This adds a delay between
acknowledgment (clear IPI) and fulfillment (call function) of the
request. We want to use the acknowledgment to be able to judge when the
request has been completed. Remove the delay by clearing the IPI after
cache invalidation and just before calling the function from the
request.
Signed-off-by: Lukas Auer
---
arch/riscv/cpu/start.S | 2 ++
arch/riscv/include/asm/smp.h | 3 ++-
arch/riscv/lib/bootm.c | 2 +-
arch/riscv/lib/smp.c | 31 ++-
arch/riscv/lib/spl.c | 2 +-
common/spl/spl_opensbi.c | 2 +-
6 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 0a2ce6d691..60631638dd 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -197,6 +197,7 @@ spl_secondary_hart_stack_gd_setup:
la a0, secondary_hart_relocate
mv a1, s0
mv a2, s0
+ mv a3, zero
jal smp_call_function
/* hang if relocation of secondary harts has failed */
@@ -337,6 +338,7 @@ relocate_secondary_harts:
mv a1, s2
mv a2, s3
+ mv a3, zero
jal smp_call_function
/* hang if relocation of secondary harts has failed */
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index bc863fdbaf..74de92ed13 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -46,8 +46,9 @@ void handle_ipi(ulong hart);
* @addr: Address of function
* @arg0: First argument of function
* @arg1: Second argument of function
+ * @wait: Wait for harts to acknowledge request
* @return 0 if OK, -ve on error
*/
-int smp_call_function(ulong addr, ulong arg0, ulong arg1);
+int smp_call_function(ulong addr, ulong arg0, ulong arg1, int wait);
#endif
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index efbd3e23e7..e96137a50c 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -99,7 +99,7 @@ static void boot_jump_linux(bootm_headers_t *images, int flag)
if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
#ifdef CONFIG_SMP
ret = smp_call_function(images->ep,
- (ulong)images->ft_addr, 0);
+ (ulong)images->ft_addr, 0, 0);
if (ret)
hang();
#endif
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
index 6ff0de4b74..d575e904c2 100644
--- a/arch/riscv/lib/smp.c
+++ b/arch/riscv/lib/smp.c
@@ -43,11 +43,11 @@ extern int riscv_clear_ipi(int hart);
*/
extern int riscv_get_ipi(int hart, int *pending);
-static int send_ipi_many(struct ipi_data *ipi)
+static int send_ipi_many(struct ipi_data *ipi, int wait)
{
ofnode node, cpus;
u32 reg;
- int ret;
+ int ret, pending;
cpus = ofnode_path("/cpus");
if (!ofnode_valid(cpus)) {
@@ -90,6 +90,15 @@ static int send_ipi_many(struct ipi_data *ipi)
pr_err("Cannot send IPI to hart %d\n", reg);
return ret;
}
+
+ if (wait) {
+ pending = 1;
+ while (pending) {
+ ret = riscv_get_ipi(reg, );
+ if (ret)
+ return ret;
+ }
+ }
}
return 0;
@@ -103,21 +112,25 @@ void handle_ipi(ulong hart)
if (hart >= CONFIG_NR_CPUS)
return;
+ __smp_mb();
+
+ smp_function = (void (*)(ulong, ulong, ulong))gd->arch.ipi[hart].addr;
+ invalidate_icache_all();
+
+ /*
+* Clear the IPI to acknowledge the request before jumping to the
+* requested function.
+*/
ret = riscv_clear_ipi(hart);
if (ret) {
pr_err("Cannot clear IPI of hart %ld\n", hart);
return;
}
- __smp_mb();
-
- smp_function = (void (*)(ulong, ulong, ulong))gd->arch.ipi[hart].addr;
- invalidate_icache_all();
-
smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1);
}
-int smp_call_function(ulong addr, ulong arg0, ulong arg1)
+int smp_call_function(ulong addr, ulong arg0, ulong arg1, int wait)
{
int ret = 0;
struct ipi_data ipi;
@@ -126,7 +139,7 @@ int smp_call_function(ulong addr, ulong arg0, ulong arg1)
ipi.arg0 = arg0;
ipi.arg1 = arg1;
- ret = send_ipi_many();
+ ret = send_ipi_many(, wait);
Re: [PATCH 1/2] rockchip: misc: Only assign serial# variable if unset
Hi Paul,
On 03.12.19 16:46, Paul Kocialkowski wrote:
The serial# environment variable is a read-only special variable, that
can only be set once. As a result, if the environment was saved to a
persistent storage location, attempting to set it again in
rockchip_cpuid_set will fail and halt the boot with the following error:
Solve this by checking whether the variable is already set before.
Signed-off-by: Paul Kocialkowski
it looks like we're fixing the same problems a lot. Yesterday I
also got a patch from Miquel about the px30 iommu clocks ;-) .
Here it's the same as "rockchip: misc: protect serial# from getting
overwritten"
from november 29 ;-)
Heiko
---
arch/arm/mach-rockchip/misc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index bed4317f7ece..a0c6a1c0b266 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -108,12 +108,16 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32
cpuid_length)
high[i] = cpuid[i << 1];
}
- serialno = crc32_no_comp(0, low, 8);
- serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
- snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
-
env_set("cpuid#", cpuid_str);
- env_set("serial#", serialno_str);
+
+ if (!env_get("serial#")) {
+ serialno = crc32_no_comp(0, low, 8);
+ serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
+ snprintf(serialno_str, sizeof(serialno_str), "%016llx",
+serialno);
+
+ env_set("serial#", serialno_str);
+ }
return 0;
}
[PATCH] arm: omap: fix MPU DPLL divisor for 800MHz clock
In locked condition CLKOUT = CLKINP * [M / (N + 1)].
Signed-off-by: Dario Binacchi
---
arch/arm/mach-omap2/am33xx/clock_am33xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
index 32cdf63e3d..f2cd496607 100644
--- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
+++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
@@ -77,7 +77,7 @@ const struct dpll_params
dpll_mpu_opp[NUM_CRYSTAL_FREQ][NUM_OPPS] = {
{-1, -1, -1, -1, -1, -1, -1}, /* OPP RESERVED */
{25, 0, 1, -1, -1, -1, -1}, /* OPP 100 */
{30, 0, 1, -1, -1, -1, -1}, /* OPP 120 */
- {100, 3, 1, -1, -1, -1, -1},/* OPP TB */
+ {100, 2, 1, -1, -1, -1, -1},/* OPP TB */
{125, 2, 1, -1, -1, -1, -1} /* OPP NT */
},
{ /* 25 MHz */
--
2.24.0
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
Hey Tom, On Tue, Dec 3, 2019 at 11:05 AM Tom Rini wrote: > > On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote: > > Hi Tom, > > > > On Mon, Dec 2, 2019 at 9:11 PM Tom Rini wrote: > > > > > > Hey all, > > > > > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > > > fixing all of the issues that pop up as I get the MTD clean-up series > > > ready to go. In fact, what I need to do at this point is grab the > > > handful of size reduction patches that this has shown are worthwhile, > > > then I can do the MTD series. Then we're down to just fixing up > > > misconversions where things got turned off. > > > > > > Once again, for a changelog, > > > git log --merges v2020.01-rc3..v2020.01-rc4 > > > and as always, I ask for more details in the PRs people send me so I can > > > put them in the merge commit. > > > > > > I'm planning on doing -rc5 on December 23rd with the release scheduled > > > on January 6th. Thanks all! > > > > I have a -net PR just about ready, but there are a few boards failing > > for size. When can I expect the size reduction to drop? > > How much are they failing? You can rebase on top of > WIP/2019-12-03-master-imports and see if that's enough. But also if arm: + tbs2910 +u-boot.imx exceeds file size limit: 1356+ limit: 0x5fc00 bytes 1357+ actual: 0x60c00 bytes 1358+ excess: 0x1000 bytes arm: + am335x_boneblack_vboot 922+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' 923+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 392 bytes 924+make[2]: *** [spl/u-boot-spl] Error 1 925+make[1]: *** [spl/u-boot-spl] Error 2 926+make: *** [sub-make] Error 2 927 arm: + am335x_evm 928+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' 929+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 664 bytes 930+make[2]: *** [spl/u-boot-spl] Error 1 931+make[1]: *** [spl/u-boot-spl] Error 2 932+make: *** [sub-make] Error 2 > it's for packed member things, I'm not sure if that's the right approach > vs disabling the warning like the Linux kernel does (and we do today, > for clang). > > -- > Tom
Re: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
Am 02.12.2019 um 11:25 schrieb chee.hong@intel.com: From: "Ang, Chee Hong" New U-boot flow with ARM Trusted Firmware (ATF) support: SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1) SPL loads the u-boot.itb which consist of: 1) u-boot-nodtb.bin (U-Boot Proper image) 2) u-boot.dtb (U-Boot Proper DTB) 3) bl31.bin (ATF-BL31 image) Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex) Now, U-Boot Proper is running in non-secure mode (EL2), it invokes SMC/PSCI calls provided by ATF to perform COLD reset, System Manager register accesses and mailbox communications with Secure Device Manager (SDM). Steps to build the U-Boot with ATF support: 1) Build U-Boot 2) Build ATF BL31 3) Copy ATF BL31 binary image into U-Boot's root folder 4) "make u-boot.itb" to generate u-boot.itb These patchsets have dependency on: [U-Boot,v8,00/19] Add Intel Agilex SoC support: https://patchwork.ozlabs.org/cover/1201373/ BTW, does this series supersede these wo: https://patchwork.ozlabs.org/user/todo/uboot/?series=106463 https://patchwork.ozlabs.org/user/todo/uboot/?series=106465 I'm just updating my patchwork todo list... Regards, Simon Chee Hong Ang (19): arm: socfpga: add fit source file for pack itb with ATF arm: socfpga: Add function for checking description from FIT image arm: socfpga: Load FIT image with ATF support arm: socfpga: Override 'lowlevel_init' to support ATF configs: socfpga: Enable FIT image loading with ATF support arm: socfpga: Disable "spin-table" method for booting Linux arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits) arm: socfpga: Define SMC function identifiers for PSCI SiP services arm: socfpga: Add secure register access helper functions for SoC 64bits arm: socfpga: Secure register access for clock manager (SoC 64bits) arm: socfpga: Secure register access in PHY mode setup arm: socfpga: Secure register access for reading PLL frequency mmc: dwmmc: socfpga: Secure register access in MMC driver net: designware: socfpga: Secure register access in MAC driver arm: socfpga: Secure register access in Reset Manager driver arm: socfpga: stratix10: Initialize timer in SPL arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config status sysreset: socfpga: Invoke PSCI call for COLD reset Dalon Westergreen (1): configs: stratix10: Remove CONFIG_OF_EMBED arch/arm/mach-socfpga/Kconfig | 2 - arch/arm/mach-socfpga/Makefile | 4 + arch/arm/mach-socfpga/board.c | 10 + arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +- arch/arm/mach-socfpga/clock_manager_s10.c | 5 +- arch/arm/mach-socfpga/include/mach/misc.h | 3 + .../mach-socfpga/include/mach/secure_reg_helper.h | 20 ++ arch/arm/mach-socfpga/lowlevel_init.S | 48 +++ arch/arm/mach-socfpga/misc_s10.c | 47 ++- arch/arm/mach-socfpga/reset_manager_s10.c | 31 +- arch/arm/mach-socfpga/secure_reg_helper.c | 67 arch/arm/mach-socfpga/timer_s10.c | 3 +- arch/arm/mach-socfpga/wrap_pll_config_s10.c| 9 +- board/altera/soc64/its/fit_spl_atf.its | 51 +++ configs/socfpga_agilex_defconfig | 8 +- configs/socfpga_stratix10_defconfig| 9 +- drivers/fpga/stratix10.c | 261 -- drivers/mmc/socfpga_dw_mmc.c | 7 +- drivers/net/dwmac_socfpga.c| 5 +- drivers/sysreset/sysreset_socfpga_s10.c| 4 +- include/configs/socfpga_soc64_common.h | 2 +- include/linux/intel-smc.h | 374 + 22 files changed, 732 insertions(+), 243 deletions(-) create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c create mode 100644 board/altera/soc64/its/fit_spl_atf.its create mode 100644 include/linux/intel-smc.h
Pull request for UEFI sub-system for efi-2020-01-rc5
The following changes since commit 1297989804d66c8db92efbf9fa2e6cc76965a943: Prepare v2020.01-rc4 (2019-12-02 22:09:27 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2020-01-rc5 for you to fetch changes up to 0bffb8c46b109dcd8766e78c357147c07333f6b6: cmd: efidebug: fix a build error in show_efi_boot_opt() (2019-12-03 20:54:05 +0100) Pull request for UEFI sub-system for efi-2020-01-rc5 A type error in the implementation of the efidebug command is fixed. AKASHI Takahiro (1): cmd: efidebug: fix a build error in show_efi_boot_opt() cmd/efidebug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
Am 03.12.2019 um 19:31 schrieb Ang, Chee Hong:
On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong
wrote:
On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong
wrote:
Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
wrote:
On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
wrote:
On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
wrote:
On Mon, Dec 2, 2019 at 11:25 AM
wrote:
From: "Ang, Chee Hong"
New U-boot flow with ARM Trusted Firmware (ATF) support:
SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
Linux
(EL1)
Adding support for ATF means that using U-Boot on
Stratix10 and Agilex without ATF keeps working, right?
ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
Is there a technical requirement for that?
Yes. We are using ATF to provide PSCI services such as
system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in
Linux) and other secure services such as mailbox
communications with Secure Device Manager and accessing
the System Manager registers which are
secure.
Without PSCI services, we are able to boot until U-Boot proper
only.
Currently, our U-Boot in mainline doesn't boot to Linux
due to these missing
PSCI services.
Another reason is we have another boot flow which is using
ATF +
UEFI.
So now we are re-using the PSCI services from ATF so that
now U-Boot and UEFI share the same ATF-BL31 image so that
we don't have to
reimplement another sets of PSCI services for U-Boot again.
This will greatly reduce our engineering efforts.
Hmm, thanks for the explanation.
I don't really think I can review this, given the lack of
knowledge about that PSCI stuff.
I believe you can review it.
Have you briefly gone through the patches ? It has nothing
to do with the PSCI
stuff.
It just call the invoke_smc() function to call the ATF's
PSCI functions. Those PSCI functions in ATF will do the rest.
No, not yet. But see below.
I must say it seems strange to me that U-Boot would have to
rely on ATF
though.
How do other platforms implement this? Shouldn't PSCI be
generic or is it really platform specific? If it's generic,
isn't that a dupliation of code if you implement e.g. a
reset driver for
Stratix10 but call
into PSCI?
It's not strange at all. A lot of U-Boot users already
using this boot flow (ATF +
U-Boot).
Just because other boards do this doesn't mean it's not strange.
Wasn't there some kind of discussion around that PSCI stuff
to make it
available from U-Boot?
What's wrong with that way?
Our downstream U-Boot branch is already implemented the PSCI
stuffs in U-
Boot.
I tried to upstream my PSCI code:
https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
Marek pointed me to this thread:
https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.ht
ml
He had a point. He suggested maybe we can implement the PSCI
stuffs in SPL/TPL. I took a look at the U-Boot code and found
out ATF is already well
supported. Why don't we just use the PSCI code from ATF rather
than
re- implementing the PSCI code again in SPL/TPL.
It will save our effort to maintain two PSCI code in U-Boot
and ATF while we
already have the ATF PSCI implementation to support UEFI.
It seems to me we do have working code in U-Boot, what's missing
is "only" to turn it ino PSCI?
Existing PSCI framework in U-Boot provide a way for us to turn the
code into a PSCI handler by just adding a '__secure' keyword
before the
function name. See:
https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-soc
fpga
/mailbox_s10.c
Below is one of the functions that has 2 versions. One 'live' in a
normal code section and another one will be relocated to "__secure"
section (for PSCI). You can see that 2 same functions are
duplicated for normal
code section and PSCI section.
int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
resp_buf_len, resp_buf); }
int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
u32 *arg, u8 urgent, u32 *resp_buf_len,
u32 *resp_buf) {
return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
resp_buf_len, resp_buf); }
Those functions that are needed by PSCI runtime need to be
duplicated for
"__secure" section.
U-Boot Proper will copy and relocate the PSCI code in "__secure"
section to a location before booting Linux whereby they can be
called by Linux. Using the PSCI framework, U-Boot proper is not
able to call any PSCI
functions because PSCI code is not available until U-Boot proper
ready to boot Linux.
So that's the reason we need to have 2 sets of code in U-Boot. One
for SPL/U-Boot and another one for PSCI section which is used by Linux.
Currently we have 2 implementations for FPGA
Re: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
Am 03.12.2019 um 15:59 schrieb Dalon L Westergreen:
On Tue, 2019-12-03 at 14:45 +, Ang, Chee Hong wrote:
On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <
chee.hong@intel.com
wrote:
Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
<
chee.hong@intel.com
wrote:
On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
<
chee.hong@intel.com
wrote:
On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
<
chee.hong@intel.com
wrote:
On Mon, Dec 2, 2019 at 11:25 AM <
chee.hong@intel.com
wrote:
From: "Ang, Chee Hong" <
chee.hong@intel.com
New U-boot flow with ARM Trusted Firmware (ATF)
support:
SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
Linux
(EL1)
Adding support for ATF means that using U-Boot on
Stratix10
and Agilex without ATF keeps working, right?
ATF is needed in order for Stratix10 and Agilex's U-Boot
to work.
Is there a technical requirement for that?
Yes. We are using ATF to provide PSCI services such as system
reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
other secure services such as mailbox communications with
Secure Device Manager and accessing the System Manager
registers which are
secure.
Without PSCI services, we are able to boot until U-Boot proper
only.
Currently, our U-Boot in mainline doesn't boot to Linux due to
these missing
PSCI services.
Another reason is we have another boot flow which is using ATF
+
UEFI.
So now we are re-using the PSCI services from ATF so that now
U-Boot and UEFI share the same ATF-BL31 image so that we don't
have to
reimplement another sets of PSCI services for U-Boot again.
This will greatly reduce our engineering efforts.
Hmm, thanks for the explanation.
I don't really think I can review this, given the lack of
knowledge about that PSCI stuff.
I believe you can review it.
Have you briefly gone through the patches ? It has nothing to do
with the PSCI
stuff.
It just call the invoke_smc() function to call the ATF's PSCI
functions. Those PSCI functions in ATF will do the rest.
No, not yet. But see below.
I must say it seems strange to me that U-Boot would have to
rely on ATF
though.
How do other platforms implement this? Shouldn't PSCI be
generic or is it really platform specific? If it's generic,
isn't that a dupliation of code if you implement e.g. a reset
driver for
Stratix10 but call
into PSCI?
It's not strange at all. A lot of U-Boot users already using
this boot flow (ATF +
U-Boot).
Just because other boards do this doesn't mean it's not strange.
Wasn't there some kind of discussion around that PSCI stuff to
make it
available from U-Boot?
What's wrong with that way?
Our downstream U-Boot branch is already implemented the PSCI
stuffs in U-
Boot.
I tried to upstream my PSCI code:
https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
Marek pointed me to this thread:
https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html
He had a point. He suggested maybe we can implement the PSCI
stuffs in SPL/TPL. I took a look at the U-Boot code and found out
ATF is already well
supported. Why don't we just use the PSCI code from ATF rather than
re- implementing the PSCI code again in SPL/TPL.
It will save our effort to maintain two PSCI code in U-Boot and
ATF while we
already have the ATF PSCI implementation to support UEFI.
It seems to me we do have working code in U-Boot, what's missing is
"only" to turn it ino PSCI?
Existing PSCI framework in U-Boot provide a way for us to turn the
code into a PSCI handler by just adding a '__secure' keyword before the
function name. See:
https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga
/mailbox_s10.c
Below is one of the functions that has 2 versions. One 'live' in a
normal code section and another one will be relocated to "__secure"
section (for PSCI). You can see that 2 same functions are duplicated for
normal
code section and PSCI section.
int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
urgent,
resp_buf_len, resp_buf); }
int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
u32 *arg, u8 urgent, u32 *resp_buf_len,
u32 *resp_buf) {
return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
urgent,
resp_buf_len, resp_buf); }
Those functions that are needed by PSCI runtime need to be duplicated for
"__secure" section.
U-Boot Proper will copy and relocate the PSCI code in "__secure"
section to a location before booting Linux whereby they can be called
by Linux. Using the PSCI framework, U-Boot proper is not able to call any
PSCI
functions because PSCI code is not available until U-Boot proper ready to
boot
Linux.
So
Re: [U-Boot] [PATCH v2 1/3] mach-imx: bootaux: print stack pointer and reset vector
On Thu, Nov 28, 2019 at 3:56 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> 1. Change information printed about loaded M4 binary, print the stack
> pointer and reset vector addressed.
> 2. Add sanity check for the address provided as param.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/mach-imx/imx_bootaux.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
> index 3d9422d5a2..ee786f7d06 100644
> --- a/arch/arm/mach-imx/imx_bootaux.c
> +++ b/arch/arm/mach-imx/imx_bootaux.c
> @@ -20,6 +20,9 @@ int arch_auxiliary_core_up(u32 core_id, ulong
> boot_private_data)
> stack = *(u32 *)boot_private_data;
> pc = *(u32 *)(boot_private_data + 4);
>
> + printf("## Starting auxiliary core stack = 0x%08lX, pc =
> 0x%08lX...\n",
> + stack, pc);
> +
> /* Set the stack and pc to M4 bootROM */
> writel(stack, M4_BOOTROM_BASE_ADDR);
> writel(pc, M4_BOOTROM_BASE_ADDR + 4);
> @@ -80,7 +83,8 @@ static int do_bootaux(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
>
> addr = simple_strtoul(argv[1], NULL, 16);
>
> - printf("## Starting auxiliary core at 0x%08lX ...\n", addr);
> + if (!addr)
> + return CMD_RET_FAILURE;
>
> ret = arch_auxiliary_core_up(0, addr);
> if (ret)
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards
Oleksandr Suvorov
Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
4800 (main line)
Re: Raspberry Pi Compute Module 1 mini-UART
I've done a little more work on this. I've been able to swap the UART pins around to a certain extent, but it's still being stubborn. I've been able to move the console output from the main UART from GPIO14 to GPIO32. I've somehow also managed to get the main UART to output to both GPIO32 and GPIO14 simultaneously (although it wouldn't RX anything when that was happening)! However I still can't get it to simply move the console over to using the mini-UART. I've worked out that the serial port seems to be selected by the status of the pin multiplexers. It checks to see whether GPIO15 is multiplexed to the main port. If not, it checks to see whether GPIO15 is multiplexed to the alternate port. I tried forcing it to think that the secondary UART was multiplexed by forcing a return value in the is_serial_muxed() functions to be false for the main UART and true for the mini-UART, however it just gives me a rainbow splash screen of death. Can I have some pointers as to how I debug what's causing the Pi to fail to boot when I try forcing the mini-UART? Clearly something is wrong and causing it to fail. Will it output anything over the early debug UART and, if so, what values do I need to put into the config for that to work? I tried adding the register addresses I found in the datasheet, however I couldn't get anything out of it. Kindest regards, Ed -- Sent from: http://u-boot.10912.n7.nabble.com/
Re: [PATCH 2/2] rockchip: misc: Don't fail if ethaddr is already set
On 03.12.19 16:46, Paul Kocialkowski wrote:
rockchip_setup_macaddr will return -1 if ethaddr is already set, which
gets propagated to misc_init_r and eventually halts the boot process.
While checking that the variable is not already set before attempting to
setit is legitimate (it's a set-once variable), this is no good reason
to halt the boot process.
Return the success return code if the variable is already set instead.
Signed-off-by: Paul Kocialkowski
Same as "rockchip: misc: don't fail if eth_addr already set" from
november 29 ;-)
---
arch/arm/mach-rockchip/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index a0c6a1c0b266..bce10bb04f8f 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -29,7 +29,7 @@ int rockchip_setup_macaddr(void)
/* Only generate a MAC address, if none is set in the environment */
if (env_get("ethaddr"))
- return -1;
+ return 0;
if (!cpuid) {
debug("%s: could not retrieve 'cpuid#'\n", __func__);
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
On Tue, Dec 03, 2019 at 06:00:11PM +0100, Marek Vasut wrote: > On 12/3/19 5:52 PM, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 2 Dec 2019 at 20:11, Tom Rini wrote: > >> > >> Hey all, > >> > >> It's release day and here is v2020.01-rc4. Yes, I'm still working on > >> fixing all of the issues that pop up as I get the MTD clean-up series > >> ready to go. In fact, what I need to do at this point is grab the > >> handful of size reduction patches that this has shown are worthwhile, > >> then I can do the MTD series. Then we're down to just fixing up > >> misconversions where things got turned off. > >> > >> Once again, for a changelog, > >> git log --merges v2020.01-rc3..v2020.01-rc4 > >> and as always, I ask for more details in the PRs people send me so I can > >> put them in the merge commit. > >> > >> I'm planning on doing -rc5 on December 23rd with the release scheduled > >> on January 6th. Thanks all! > > > > Speaking of next year, what is the plan for the release. Is there any > > chance we might move back to a release every two months? The > > three-month process is very slow... > > I am very happy with this 3-month release cycle, it's less stressful and > I think the quality of the releases is higher too. I thought I said this a release or so ago, sorry. I believe we'll be sticking with the 3-month cycle and I hope to find time to more actively use a -next branch myself to help with some of the delay, or at least slower feedback cycle. -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [EXT] Re: [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode
On Tue, Dec 3, 2019 at 4:32 AM Xiaowei Bao wrote: > > Hi Ramon, > > Do you have any comments about this? Thanks a lot. > > Best regards > Xiaowei > > From: Xiaowei Bao > Sent: 2019年11月26日 10:52 > To: Ramon Fried > Cc: Bin Meng ; Simon Glass ; M.h. Lian > ; Z.q. Hou ; Mingkai Hu > ; Hongbo Wang ; York Sun > ; u-boot@lists.denx.de > Subject: RE: [EXT] Re: [U-Boot] [PATCHv2 1/2] PCI: layerscape: Add Support > for ls2088 PCIe EP mode > > H Ramon, > > Thanks for your comments. > If we reimplement the PCIe EP driver base on PCIe UCLASS, we must test it in > u-boot, but I have no idea how to test the actual device, do I need to > implement our own test case, how to verify the cadence-ep actual device? > I'm not sure I understand what you're trying to achieve and why you're referring to the cadence. You're developing a driver, just test it against a client (IE. a real PCIe root-complex). The cadence is irrelevant, it's just another implementation of endpoint driver. Thanks, Ramon. > Best regards > Xiaowei > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] mach-imx: bootaux: elf firmware support
On Thu, Nov 28, 2019 at 3:57 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Currently imx-specific bootaux command doesn't support ELF format
> firmware for Cortex-M4 core.
>
> This patches introduces a PoC implementation of handling elf firmware
> (load_elf_image_phdr() was copy-pasted from elf.c just for PoC).
>
> This has the advantage that the user does not need to know to which
> address the binary has been linked to. However, in order to handle
> and load the elf sections to the right address, we need to translate the
> Cortex-M4 core memory addresses to primary/host CPU memory
> addresses (Cortex A7/A9 cores).
>
> This allows to boot firmwares from any location with just using
> bootaux, e.g.:
> > tftp ${loadaddr} hello_world.elf && bootaux ${loadaddr}
>
> Similar translation table can be found in the Linux remoteproc
> driver [1].
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/imx_rproc.c
>
> Signed-off-by: Igor Opaniuk
> Signed-off-by: Stefan Agner
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/include/asm/mach-imx/sys_proto.h | 7 ++
> arch/arm/mach-imx/imx_bootaux.c | 84 +--
> arch/arm/mach-imx/mx7/soc.c | 28
> 3 files changed, 115 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 1e627c8fc3..ed5d9a1667 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -104,6 +104,13 @@ void gpr_init(void);
>
> #endif /* CONFIG_MX6 */
>
> +/* address translation table */
> +struct rproc_att {
> + u32 da; /* device address (From Cortex M4 view) */
> + u32 sa; /* system bus address */
> + u32 size; /* size of reg range */
> +};
> +
> u32 get_nr_cpus(void);
> u32 get_cpu_rev(void);
> u32 get_cpu_speed_grade_hz(void);
> diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
> index c750cee60c..871169e771 100644
> --- a/arch/arm/mach-imx/imx_bootaux.c
> +++ b/arch/arm/mach-imx/imx_bootaux.c
> @@ -7,18 +7,94 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> -int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data)
> +const __weak struct rproc_att hostmap[] = { };
> +
> +static const struct rproc_att *get_host_mapping(unsigned long auxcore)
> +{
> + const struct rproc_att *mmap = hostmap;
> +
> + while (mmap && mmap->size) {
> + if (mmap->da <= auxcore &&
> + mmap->da + mmap->size > auxcore)
> + return mmap;
> + mmap++;
> + }
> +
> + return NULL;
> +}
> +
> +/*
> + * A very simple elf loader, assumes the image is valid, returns the
> + * entry point address.
> + */
> +static unsigned long load_elf_image_phdr(unsigned long addr)
> +{
> + Elf32_Ehdr *ehdr; /* ELF header structure pointer */
> + Elf32_Phdr *phdr; /* Program header structure pointer */
> + int i;
> +
> + ehdr = (Elf32_Ehdr *)addr;
> + phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
> +
> + /* Load each program header */
> + for (i = 0; i < ehdr->e_phnum; ++i, ++phdr) {
> + const struct rproc_att *mmap =
> get_host_mapping(phdr->p_paddr);
> + void *dst, *src;
> +
> + if (phdr->p_type != PT_LOAD)
> + continue;
> +
> + if (!mmap) {
> + printf("Invalid aux core address: %08x",
> + phdr->p_paddr);
> + return 0;
> + }
> +
> + dst = (void *)(phdr->p_paddr - mmap->da) + mmap->sa;
> + src = (void *)addr + phdr->p_offset;
> +
> + debug("Loading phdr %i to 0x%p (%i bytes)\n",
> + i, dst, phdr->p_filesz);
> +
> + if (phdr->p_filesz)
> + memcpy(dst, src, phdr->p_filesz);
> + if (phdr->p_filesz != phdr->p_memsz)
> + memset(dst + phdr->p_filesz, 0x00,
> + phdr->p_memsz - phdr->p_filesz);
> + flush_cache((unsigned long)dst &
> + ~(CONFIG_SYS_CACHELINE_SIZE - 1),
> + ALIGN(phdr->p_filesz, CONFIG_SYS_CACHELINE_SIZE));
> + }
> +
> + return ehdr->e_entry;
> +}
> +
> +int arch_auxiliary_core_up(u32 core_id, ulong addr)
> {
> ulong stack, pc;
>
> - if (!boot_private_data)
> + if (!addr)
> return -EINVAL;
>
> - stack = *(u32 *)boot_private_data;
> - pc = *(u32 *)(boot_private_data + 4);
> + if (valid_elf_image(addr)) {
> + stack = 0x0;
> + pc = load_elf_image_phdr(addr);
> + if (!pc)
> + return CMD_RET_FAILURE;
> +
> + } else {
> + /*
> +* Assume binary file
Re: Load Debian/Fedora via EFI
On 12/2/19 3:21 PM, Michal Simek wrote:
> On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
>> On 11/29/19 11:16 AM, Michal Simek wrote:
>>> Hi,
>>>
>>> I tried to boot latest debian and fedora rootfs via distro boot and
>>> getting errors.
>>> I have tried to run just one command and it is failing.
>>>
>>> ZynqMP> bootefi bootmgr ${fdtcontroladdr}
>>> BootOrder not defined
>>> EFI boot manager: Cannot load any image
>>>
>>> How to define BootOrder?
>>>
>>> Thanks,
>>> Michal
>>
>> # Booting via boot manager
>>
>> U-Boot currently has no runtime support for variables. But Linaro is
>> working on it. So update-grub cannot set the variables for you.
>
> Who from Linaro is working on it? Akashi?
I was in contact with Ilias Apalodimas but do not know who is doing the
actual work.
See https://youtu.be/SEMJGOzjrHY @ 14:00
>
>>
>> You can use the efidebug command to prepare for booting via the boot
>> manager:
>>
>> => efidebug boot add 0001 Debian mmc 0:1 \
>> efi/debian/grubarm.efi console=${console}
>>
>> There seems to be a bug with communication lines in U-Boot. So you
>> actually have to put this into a single line.
>>
>> => efidebug boot order 0001
>>
>> Use saveenv if you want to save the settings.
>>
>> If you do not want to use the internal device tree load the proper
>> device tree, e.g.
>>
>> => load mmc 0:2 $fdt_addr_r dtb
>>
>> Now you are ready to boot via the boot manager:
>>
>> => bootefi bootmgr $fdt_addr_r
>>
>> # Booting via distro defaults
>>
>> DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the
>> UEFI binary from efi/boot/bootaa64.efi on ARM64. See
>> ./include/config_distro_bootcmd.h.
>>
>> OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does
>> not.
>
> Fedora is the same case.
> I got it working based on your guidance but would be IMHO better to
> extend distroboot to cover one of the major distribution even through
> workaround till variable support is done.
I don't like the idea of distribution specific stuff getting into U-Boot.
We would end up with a plethora of possible UEFI binaries to search for:
shim, GRUB, iPXE, any Linux kernel. All of these are binaries could be
used for booting Fedora, Debian, or any other Linux distribution via
bootefi. And which one should we take if there is more than one of these?
I especially dislike any claim that one distribution is "major" and
another is not. Should we kick out CentOS and Fedora because they are
less popular than Ubuntu and Android?
So let's leave it to the distribution to create boot.scr or provide a
binary following the naming convention given in the UEFI specification
(chapter 3.5.1.1 Removable Media Boot Behavior).
>
>>
>> # Booting via boot script.
>>
>> On Debian I use package flash-kernel to keep /boot/dtb in sync with the
>> kernel and have a u-boot.scr.uimg script with something like the
>> following lines:
>>
>> setenv bootargs console=${console}
>> load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi
>> load mmc 2:2 ${fdt_addr_r} dtb
>> bootefi ${kernel_addr_r} ${fdt_addr_r}
>
>
> flash-kernel is interesting. It generates u-boot script but if extX
> partition has no bootable flag u-boot distroboot ignores it completely.
> What's your default partition setup?
I have separate partitions:
/boot of type 83 (Linux, ext2) and marked as bootable and with boot.scr
on it.
/boot/efi of type ef (EFI, vfat) and not marked as bootable
The sequence on the block device does not matter.
When booting via iSCSI with iPXE I put boot.scr and snp.efi on an EFI
partition marked as bootable.
Best regards
Heinrich
>
>>
>> Alternatively you could use package flash-kernel and implement the
>> /etc/flash-kernel/preboot.d/
>> hook to start GRUB, cf.
>> /etc/flash-kernel/bootscript/bootscr.uboot-generic
>>
>> I currently have no Fedora system in use.
>>
>
> you can take a look.
> https://alt.fedoraproject.org/alt/
>
> Thanks,
> Michal
>
Re: [U-Boot] [PATCH v1 1/6] ARM: dts: imx6_colibri: introduce fec node
On Mon, Nov 4, 2019 at 12:13 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Sync DTS with the mainline Linux and introduce fec node.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/dts/imx6-colibri.dts | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/dts/imx6-colibri.dts b/arch/arm/dts/imx6-colibri.dts
> index 5c9f1f0d2b..387d6d5ca7 100644
> --- a/arch/arm/dts/imx6-colibri.dts
> +++ b/arch/arm/dts/imx6-colibri.dts
> @@ -21,6 +21,7 @@
> mmc0 =
> mmc1 =
> usb0 = /* required for ums */
> + ethernet0 =
> };
>
> chosen {
> @@ -46,6 +47,25 @@
> };
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_enet>;
> + phy-mode = "rmii";
> + phy-handle = <>;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy: ethernet-phy@0 {
> + reg = <0>;
> + micrel,led-mode = <0>;
> + status = "okay";
> + };
> + };
> +};
> +
> /*
> * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
> * touch screen controller
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards
Oleksandr Suvorov
Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
4800 (main line)
[PATCH v3 3/6] test: dm: add a simple unit test for DSA class
The test pings the local IP address though different ports of a sandbox
DSA device. Port traffic is filtered and the test verifies that ping
works only on enabled ports.
The additional interfaces require MAC addresses, these have been added
to sandbox default environment.
Signed-off-by: Alex Marginean
---
arch/Kconfig | 1 +
arch/sandbox/dts/test.dts | 49 +
include/configs/sandbox.h | 4 +++
test/dm/Makefile | 1 +
test/dm/dsa.c | 58 +++
test/dm/test-fdt.c| 2 +-
6 files changed, 114 insertions(+), 1 deletion(-)
create mode 100644 test/dm/dsa.c
diff --git a/arch/Kconfig b/arch/Kconfig
index 141e48bc43..70907d69a1 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -133,6 +133,7 @@ config SANDBOX
imply PHYLIB
imply DM_MDIO
imply DM_MDIO_MUX
+ imply DM_DSA
config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index fdb08f2111..0f565f066a 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -40,6 +40,10 @@
usb2 = _2;
axi0 =
osd0 = "/osd";
+ eth8 = _0;
+ eth9 = _1;
+ eth10 = _2;
+ eth11 = _eth0;
};
audio: audio-codec {
@@ -889,6 +893,51 @@
mdio: mdio-test {
compatible = "sandbox,mdio";
};
+
+ dsa_eth0: dsa-test-eth {
+ compatible = "sandbox,dsa-eth";
+ };
+
+ dsa-test {
+ compatible = "sandbox,dsa";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ swp_0: port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ swp_1: port@1 {
+ reg = <1>;
+ label = "lan1";
+ phy-mode = "rgmii-txid";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ swp_2: port@2 {
+ reg = <2>;
+ label = "lan2";
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ ethernet = <_eth0>;
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+ };
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 1c13055cdc..35a5676eb9 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -100,6 +100,10 @@
"eth1addr=00:00:11:22:33:45\0" \
"eth3addr=00:00:11:22:33:46\0" \
"eth5addr=00:00:11:22:33:47\0" \
+ "eth8addr=00:00:11:22:33:48\0" \
+ "eth9addr=00:00:11:22:33:49\0" \
+ "eth10addr=00:00:11:22:33:4a\0" \
+ "eth11addr=00:00:11:22:33:4b\0" \
"ipaddr=1.2.3.4\0"
#define MEM_LAYOUT_ENV_SETTINGS \
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 0c2fd5cb5e..69e9feed91 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -65,4 +65,5 @@ obj-$(CONFIG_VIRTIO_SANDBOX) += virtio.o
obj-$(CONFIG_DMA) += dma.o
obj-$(CONFIG_DM_MDIO) += mdio.o
obj-$(CONFIG_DM_MDIO_MUX) += mdio_mux.o
+obj-$(CONFIG_DM_DSA) += dsa.o
endif
diff --git a/test/dm/dsa.c b/test/dm/dsa.c
new file mode 100644
index 00..5aa3847fe5
--- /dev/null
+++ b/test/dm/dsa.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 NXP
+ */
+
+#include
+#include
+#include
+
+extern int dsa_sandbox_port_mask;
+
+/* this test sends ping requests with the local address through each DSA port
+ * via the dummy DSA master Eth.
+ * The dummy Eth filters traffic based on DSA port used to Tx and the port
+ * mask set here, so we can check that port information gets trough correctly.
+ */
+static int dm_test_dsa(struct unit_test_state *uts)
+{
+ dsa_sandbox_port_mask = 0x5;
+
+ env_set("ethrotate", "no");
+ net_ping_ip = string_to_ip("1.2.3.4");
+
+ env_set("ethact", "dsa-test-eth");
Re: [U-Boot] [PATCH v2 1/8] image: android: Add functions for handling dtb field
Hi, On Tue, Dec 3, 2019 at 3:59 PM Eugeniu Rosca wrote: > > Hi Sam, > > On Mon, Dec 02, 2019 at 07:19:53PM +0200, Sam Protsenko wrote: > > On Tue, Oct 29, 2019 at 3:49 AM Eugeniu Rosca wrote: > > > On Wed, Oct 23, 2019 at 05:34:20PM +0300, Sam Protsenko wrote: > > > > Android Boot Image v2 adds "DTB" payload (and corresponding field in the > > > > image header). Provide functions for its handling: > > > > > > I believe this totally new degree of freedom brought by "Android Boot > > > Image v2" might unintentionally make some users more unhappy [0], since > > > it enables yet another way of passing a DTB to the Android kernel. > > > > > > It looks to me that there are at least three valid design choices for > > > DTB storage/passing which platform maintainers have to consider: > > > A. Android Image second area [1-2] > > > B. Dedicated DTB/DTBO partitions on a block device > > > C. DTB area in Android Image v2 > > > > > > While there are some major disadvantages for [A][1-2], [B] and [C] look > > > more or less equivalent and will most likely only differ in the tooling > > > used to generate and extract the useful/relevant artifacts. > > > > > > Not to mention that hybrids [B+C] are also possible. > > > Which solution should we pick as a long-term one? > > > > My opinion is next: we should provide means (commands) to achieve any > > of [A,B,C] options. Then user (I mean, U-Boot developer who implements > > boot for each particular board) should decide which approach to use. > > Fine. Thanks. But I hope you also keep in mind that the more design > choices you make available to the users (especially if redundant): > - the more test coverage you will have to accomplish, which translates >to more requests from Simon for test development and maintenance > - the greater the attack surface/vector, i.e. increased likelihood for >CVEs and the like > > > Also [D] FIT image can be used instead of Android Boot Image. But we > > should remember that Google requires *mandatory* for all *new* devices > > (starting with Android 10) to stick with [C] approach only. Option [B] > > might be harder to handle from AVB verification point of view. > > That's useful feedback. Thanks. > > > Btw, > > when we come to "boot_android" command, I think we'll need to > > implement only officially recommended boot method. Maybe provide a > > param to choose whether to do Android-9 or Android-10 boot scheme. > > > > Anyway, the short answer is: we should provide a bunch of isolated > > commands to allow the user to implement any boot method. > > Agreed with the above warnings. > > [..] > > > > - I would try to avoid wiring the same compilation unit to Kbuild > > >(e.g. image-android-dt.o) via multiple Kconfig symbols > > >(CONFIG_ANDROID_BOOT_IMAGE and CONFIG_CMD_DTIMG) since this makes > > >the relationship between the CONFIG symbols unclear. As a user, I > > >would like to see a simple mapping between compiled objects and > > >Kconfig symbols, eventually reflecting a hierarchy/dependency: > > > > > >config ANDROID_BOOT_IMAGE > > > select ANDROID_BOOT_IMAGE_DT > > > > > >config DTIMG > > > select ANDROID_BOOT_IMAGE_DT > > > > > > > I thought about that 4 months ago when implementing this patch, even > > experimented with that. But decided to just add image-android-dt.o in > > Makefile instead, don't remember for what reason exactly. Frankly, > > don't really want to go there again and spend too much time (at least > > not in the context of this patch series). > > > > So here is what I suggest: can we approach this one-step-at-a-time? > > This patch-set is a major step as it is, and it takes a lot of time to > > get it merged. What you suggest makes sense but might have some > > implications (even architectural) when trying to implement that. Can > > we do that in another series? > > I totally agree with the following: > - This series is a major step forward. Many thanks for this effort. > - Bikeshedding and minor findings can be postponed. > > However, for the sake of a non-chaotic git history and the right degree > of intuitiveness in the usage of all newly developed commands, I see > below review points as _major_ and better be fixed before merging: > - The name of the "bootimg" command intrudes too much into the U-Boot >global namespace. This has been flagged by Simon [*] >with no reply from you yet. Do you plan to provide feedback? Already renamed to 'abootimg' and replied to Simon. Will send v3 soon. > - Kconfig wiring and naming. IMHO the right decisions have to be made >whenever new files are added to Kbuild. It is like placing the right >pipe infrastructure into the basement of the building. Why would you >want to make it twice? Renaming/deleting/relocating Kconfig symbols >makes comparing [**] the configurations of distinct U-Boot/Linux >versions pretty painful later on. Ok, will look into that tomorrow. And either will improve that, or at
Re: [U-Boot] [PATCH v2 3/8] cmd: bootimg: Add bootimg command
Hi Sam,
Cc: Aleksandr, Roman
As expressed in the attached e-mail, to minimize the headaches extending
the argument list of "bootimg" in future, can we please agree on below?
On Wed, Oct 23, 2019 at 05:34:22PM +0300, Sam Protsenko wrote:
> +U_BOOT_CMD(
> + bootimg, CONFIG_SYS_MAXARGS, 0, do_bootimg,
> + "manipulate Android Boot Image",
> + "set_addr \n"
> + "- set the address in RAM where boot image is located\n"
> + " ($loadaddr is used by default)\n"
> + "bootimg ver \n"
Can we make optional, with the background provided in [1]?
> + "- get header version\n"
> + "bootimg get_dtbo [size_var]\n"
How about converting to an optional argument too?
> + "- get address and size (hex) of recovery DTBO area in the image\n"
> + " : variable name to contain DTBO area address\n"
> + " [size_var]: variable name to contain DTBO area size\n"
> + "bootimg dtb_dump\n"
> + "- print info for all files in DTB area\n"
> + "bootimg dtb_load_addr \n"
Same as above w.r.t. .
> + "- get load address (hex) of DTB\n"
> + "bootimg get_dtb_file [size_var]\n"
How about converting to an optional argument too?
How do you foresee getting a blob entry based on id= and/or
rev=? Which of below is your favorite option?
- get_dtb_file [--id=] [--rev=] [addr_var] [size_var]
where: - in case and/or are provided, tells the
command to pick the N's entry in the selection filtered by
and
- in case neither nor is provided,
behaves like in the current patch (selects a blob entry
found at absolute index value ${index} in the image)
- get_dtb_file [|[--id=|--rev=]] [addr_var] [size_var]
To make it clear, some example commands would be:
- get_dtb_file
=> current behavior
- get_dtb_file --id=
=> get _first_ blob entry matching id value
- get_dtb_file --rev=
=> get _first_ blob entry matching rev value
- get_dtb_file --id= --rev=
=> get _first_ blob entry matching id _and_ rev=
- get_dtb_file --id=
- get_dtb_file --rev=
=> Wrong usage
- get_dtb_file anything else?
I think it is crucial to agree on the above, since the very first
revision of "bootimg"/"abootimg" may impose strict limitations on how
the command can be extended in future.
[just noticed your reply shedding more light on a subset of these
questions, but still sending this out; please skip if already answered]
> + "- get address and size (hex) of DTB file in the image\n"
> + " : index of desired DTB file in DTB area\n"
> + " : variable name to contain DTB file address\n"
> + " [size_var]: variable name to contain DTB file size\n"
> +);
[1] https://patchwork.ozlabs.org/patch/1202579/
("cmd: dtimg: Make an optional argument")
--
Best Regards,
Eugeniu
From: Eugeniu Rosca
Date: Tue, 3 Dec 2019 14:59:46 +0100
To: Sam Protsenko
CC: Eugeniu Rosca , U-Boot Mailing List
, Alistair Strachan , Alex
Deymo
, Eugeniu Rosca , Praneeth
Bajjuri
, Mykhailo Sopiha
Subject: Re: [U-Boot] [PATCH v2 1/8] image: android: Add functions for
handling dtb field
Message-ID: <20191203135946.GA29671@x230>
Content-Type: text/plain; charset="us-ascii"
In-Reply-To:
User-Agent: Mutt/1.10.1 (2018-07-13)
MIME-Version: 1.0
Hi Sam,
On Mon, Dec 02, 2019 at 07:19:53PM +0200, Sam Protsenko wrote:
> On Tue, Oct 29, 2019 at 3:49 AM Eugeniu Rosca wrote:
> > On Wed, Oct 23, 2019 at 05:34:20PM +0300, Sam Protsenko wrote:
> > > Android Boot Image v2 adds "DTB" payload (and corresponding field in the
> > > image header). Provide functions for its handling:
> >
> > I believe this totally new degree of freedom brought by "Android Boot
> > Image v2" might unintentionally make some users more unhappy [0], since
> > it enables yet another way of passing a DTB to the Android kernel.
> >
> > It looks to me that there are at least three valid design choices for
> > DTB storage/passing which platform maintainers have to consider:
> > A. Android Image second area [1-2]
> > B. Dedicated DTB/DTBO partitions on a block device
> > C. DTB area in Android Image v2
> >
> > While there are some major disadvantages for [A][1-2], [B] and [C] look
> > more or less equivalent and will most likely only differ in the tooling
> > used to generate and extract the useful/relevant artifacts.
> >
> > Not to mention that hybrids [B+C] are also possible.
> > Which solution should we pick as a long-term one?
>
> My opinion is next: we should provide means (commands) to achieve any
> of [A,B,C] options. Then user (I mean, U-Boot developer who implements
> boot for each particular board) should decide which approach to use.
Fine. Thanks. But I hope you also keep in mind that the more design
choices you make available to the users (especially if redundant):
- the more test coverage you will have to accomplish, which translates
to more requests from
Re: [PATCH v3] warp7: Fix U-Boot corruption after saving the environment
Hello Fabio, Am 03.12.2019 um 12:56 schrieb Fabio Estevam: Hi Tom, On Tue, Dec 3, 2019 at 12:10 AM Tom Rini wrote: Thanks for the rework. Can you please look at what other i.MX boards are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have thumb2 related errata that might make it a bad idea to use thumb by default ? It looks like i.MX51 and i.MX53 have the thumb related erratum: https://www.nxp.com/docs/en/errata/IMX53CE.pdf i.MX6 series should work fine in thumb without issues and we could try to enable thumb by default for the next cycle. I just enabled thumb build [1] for the DM/DTS rework for the imx6 based aristainetos board ... and as I can say, U-Boot works fine on it. bye, Heiko [1] http://patchwork.ozlabs.org/patch/1202811/ -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v3 0/6] Introduce DSA Ethernet switch class and Felix driver
DSA stands for Distributed Switch Architecture and it is a subsystem introduced in the Linux kernel to support switches that: - have an Ethernet link up to the CPU - use some form of tagging to identify the source/destination port for Rx/Tx - may be cascaded in tree-like structures. DSA is described in depth here: https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt >From the doc: Summarized, this is basically how DSA looks like from a network device perspective: |--- | CPU network device (eth0)| | | || | Switch driver | || |||| || |---| |---| |---| | sw0p0 | | sw0p1 | | sw0p2 | |---| |---| |---| This patch set introduces a DSA class in U-Boot to support drivers of such switches. DSA drivers have to implement the following ops: - enable/disable of switch ports, - insert a tag in frames being transmitted, used by the switch to select the egress port, - parse a tag in frames being received, used for Rx traffic. DSA class code deals with presentation of switch ports as Ethernet interfaces, deals with the master Ethernet device for I/O and helps with parsing of the DT assuming the structure follows the DSA kernel binding. Support for switch cascading is not included yet. This patch set also introduces a driver for the Ethernet switch integrated into NXP LS1028A, called Felix. The switch has 4 front panel ports, I/O to/fom it is done though an ENETC Ethernet interface and meta-data is carried between the switch and the driver though an additional header pre-pended to the original frame. Network commands like tftp can be used on these front panel ports. The ports are disabled unless used so they do not cause issues on network topologies that include loops. Felix as seen on LS1028A RDB: => dm tree Class Index Probed DriverName --- .. dsa 0 [ + ] felix-switch | |-- felix-switch eth 4 [ + ] dsa-port | | |-- swp0 eth 5 [ + ] dsa-port | | |-- swp1 eth 6 [ + ] dsa-port | | |-- swp2 eth 7 [ + ] dsa-port | | `-- swp3 => mdio list .. 10 - Vitesse VSC8514 <--> swp0 11 - Vitesse VSC8514 <--> swp1 12 - Vitesse VSC8514 <--> swp2 13 - Vitesse VSC8514 <--> swp3 => tftp 8000 test Using swp2 device TFTP from server 192.168.100.1; our IP address is 192.168.100.100 Filename 'test'. Load address: 0x8000 Loading: # # 6.8 MiB/s done Bytes transferred = 949880 (e7e78 hex) Changes in v3: - fix Felix platdata size - move include/dsa.h to include/net/dsa.h - updated TODO in dsa.h - other minor fixes Changes in v2: - Don't use NULL PHY in Felix driver - guard dsa.h with #ifndef __DSA__H__, somehow I missed that in v1 - added a TODO for setting master Eth in promiscuous mode - Minor fixes in patch descriptions, API comments - Added address/size-cells to LS1028A DT ports node This patch set replaces v2: https://patchwork.ozlabs.org/project/uboot/list/?series=144912 and depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=144907 https://patchwork.ozlabs.org/project/uboot/list/?series=142879 Alex Marginean (6): net: introduce DSA class for Ethernet switches drivers: net: add a DSA sandbox driver test: dm: add a simple unit test for DSA class drivers: net: add Felix DSA switch driver arm: dts: ls1028a: adds Ethernet switch node and its dependencies configs: ls1028a: enable the Ethernet switch driver in defconfig arch/Kconfig | 1 + arch/arm/dts/fsl-ls1028a-rdb.dts | 36 ++ arch/arm/dts/fsl-ls1028a.dtsi| 44 +- arch/sandbox/dts/test.dts| 49 ++ configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 3 +- configs/ls1028aqds_tfa_defconfig | 3 +- configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 3 +- configs/ls1028ardb_tfa_defconfig | 3 +- drivers/net/Kconfig | 21 + drivers/net/Makefile | 1 + drivers/net/dsa_sandbox.c| 272 +++ drivers/net/fsl_enetc.h | 5 + drivers/net/mscc_eswitch/Kconfig | 8 + drivers/net/mscc_eswitch/Makefile| 1 +
Re: [U-Boot] [PATCH v1 3/6] ARM: dts: imx6_apalis: introduce fec node
On Mon, Nov 4, 2019 at 12:16 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Sync DTS with the mainline Linux and introduce fec node.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/dts/imx6-apalis.dts | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm/dts/imx6-apalis.dts b/arch/arm/dts/imx6-apalis.dts
> index b2fdfa1af4..72f7439aed 100644
> --- a/arch/arm/dts/imx6-apalis.dts
> +++ b/arch/arm/dts/imx6-apalis.dts
> @@ -22,6 +22,7 @@
> mmc1 =
> mmc2 =
> usb0 = /* required for ums */
> + ethernet0 =
> };
>
> chosen {
> @@ -197,6 +198,27 @@
> status = "okay";
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_enet>;
> + phy-mode = "rgmii";
> + phy-handle = <>;
> + phy-reset-duration = <10>;
> + phy-reset-gpios = < 25 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy: ethernet-phy@7 {
> + interrupt-parent = <>;
> + interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
> + reg = <7>;
> + };
> + };
> +};
> +
> /* Apalis Serial ATA */
> {
> status = "okay";
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards
Oleksandr Suvorov
Toradex AG
Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
4800 (main line)
[PATCH v3 2/6] drivers: net: add a DSA sandbox driver
The DSA sandbox driver is used for DSA unit testing. It implements a
simple 4 port switch that uses a very simple tag to identify the ports.
The DSA driver comes paired with an Ethernet driver that loops packets
back and can selectively filter traffic on DSA switch ports.
Signed-off-by: Alex Marginean
---
drivers/net/Kconfig | 8 ++
drivers/net/Makefile | 1 +
drivers/net/dsa_sandbox.c | 272 ++
3 files changed, 281 insertions(+)
create mode 100644 drivers/net/dsa_sandbox.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a4157cb122..ac420cb474 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -70,6 +70,14 @@ config MDIO_MUX_SANDBOX
This driver is used for testing in test/dm/mdio.c
+config DSA_SANDBOX
+ depends on DM_DSA && SANDBOX
+ default y
+ bool "Sandbox: Mocked DSA driver"
+ help
+ This driver implements a dummy switch and a dummy Ethernet device used
+ to test DSA class code.
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 30991834ec..8be49f6335 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -82,3 +82,4 @@ obj-y += mscc_eswitch/
obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
+obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
diff --git a/drivers/net/dsa_sandbox.c b/drivers/net/dsa_sandbox.c
new file mode 100644
index 00..66882ed7de
--- /dev/null
+++ b/drivers/net/dsa_sandbox.c
@@ -0,0 +1,272 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 NXP
+ */
+
+#include
+
+#define DSA_SANDBOX_MAGIC 0x00415344
+#define DSA_SANDBOX_TAG_LENsizeof(struct dsa_sandbox_tag)
+/*
+ * This global flag is used to enable DSA just for DSA test so it doesn't
affect
+ * the existing eth unit test.
+ */
+int dsa_sandbox_port_mask;
+
+struct dsa_sandbox_priv {
+ int enabled;
+ int port_enabled;
+};
+
+struct dsa_sandbox_tag {
+ u32 magic;
+ u32 port;
+};
+
+static int dsa_sandbox_port_enable(struct udevice *dev, int port,
+ struct phy_device *phy)
+{
+ struct dsa_sandbox_priv *priv = dev->priv;
+
+ if (!priv->enabled)
+ return -EFAULT;
+
+ priv->port_enabled |= BIT(port);
+
+ return 0;
+}
+
+static void dsa_sandbox_port_disable(struct udevice *dev, int port,
+struct phy_device *phy)
+{
+ struct dsa_sandbox_priv *priv = dev->priv;
+
+ if (!priv->enabled)
+ return;
+
+ priv->port_enabled &= ~BIT(port);
+}
+
+static int dsa_sandbox_xmit(struct udevice *dev, int port, void *packet,
+ int length)
+{
+ struct dsa_sandbox_priv *priv = dev->priv;
+ struct dsa_sandbox_tag *tag = packet;
+
+ if (!priv->enabled)
+ return -EFAULT;
+
+ if (!(priv->port_enabled & BIT(port)))
+ return -EFAULT;
+
+ tag->magic = DSA_SANDBOX_MAGIC;
+ tag->port = port;
+
+ return 0;
+}
+
+static int dsa_sandbox_rcv(struct udevice *dev, int *port, void *packet,
+ int length)
+{
+ struct dsa_sandbox_priv *priv = dev->priv;
+ struct dsa_sandbox_tag *tag = packet;
+
+ if (!priv->enabled)
+ return -EFAULT;
+
+ if (tag->magic != DSA_SANDBOX_MAGIC)
+ return -EFAULT;
+
+ *port = tag->port;
+ if (!(priv->port_enabled & BIT(*port)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static const struct dsa_ops dsa_sandbox_ops = {
+ .port_enable = dsa_sandbox_port_enable,
+ .port_disable = dsa_sandbox_port_disable,
+ .xmit = dsa_sandbox_xmit,
+ .rcv = dsa_sandbox_rcv,
+};
+
+static int dsa_sandbox_bind(struct udevice *dev)
+{
+ struct dsa_perdev_platdata *pdata = dev->platdata;
+
+ /* must be at least 4 to match sandbox test DT */
+ pdata->num_ports = 4;
+ pdata->headroom = DSA_SANDBOX_TAG_LEN;
+
+ return 0;
+}
+
+static int dsa_sandbox_probe(struct udevice *dev)
+{
+ struct dsa_sandbox_priv *priv = dev_get_priv(dev);
+
+ /*
+* return error if DSA is not being tested so we don't break existing
+* eth test.
+*/
+ if (!dsa_sandbox_port_mask)
+ return -EINVAL;
+
+ priv->enabled = 1;
+
+ return 0;
+}
+
+static int dsa_sandbox_remove(struct udevice *dev)
+{
+ struct dsa_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->enabled = 0;
+
+ return 0;
+}
+
+static const struct udevice_id dsa_sandbox_ids[] = {
+ { .compatible = "sandbox,dsa" },
+ { }
+};
+
+U_BOOT_DRIVER(dsa_sandbox) = {
+ .name = "dsa_sandbox",
+ .id = UCLASS_DSA,
+ .of_match = dsa_sandbox_ids,
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong > wrote: > > > > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong > > > > > > wrote: > > > > > > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > > > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > > > >> > > > > > >> wrote: > > > > > >>> > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > > > > > > wrote: > > > > > > > > > > > >> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > >> > > > > > >> wrote: > > > > > >>> > > > > > On Mon, Dec 2, 2019 at 11:25 AM > > > > > > > > > > >> wrote: > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support: > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> > > > > > > Linux > > > > > > (EL1) > > > > > > > > > > Adding support for ATF means that using U-Boot on > > > > > Stratix10 and Agilex without ATF keeps working, right? > > > > > >>> ATF is needed in order for Stratix10 and Agilex's U-Boot to > > > > > >>> work. > > > > > >> > > > > > >> Is there a technical requirement for that? > > > > > > Yes. We are using ATF to provide PSCI services such as > > > > > > system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in > > > > > > Linux) and other secure services such as mailbox > > > > > > communications with Secure Device Manager and accessing > > > > > > the System Manager registers which are > > > > > >> secure. > > > > > > Without PSCI services, we are able to boot until U-Boot proper > only. > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux > > > > > > due to these missing > > > > > PSCI services. > > > > > > Another reason is we have another boot flow which is using > > > > > > ATF + > > > UEFI. > > > > > > So now we are re-using the PSCI services from ATF so that > > > > > > now U-Boot and UEFI share the same ATF-BL31 image so that > > > > > > we don't have to > > > > > reimplement another sets of PSCI services for U-Boot again. > > > > > > This will greatly reduce our engineering efforts. > > > > > > > > > > Hmm, thanks for the explanation. > > > > > > > > > > I don't really think I can review this, given the lack of > > > > > knowledge about that PSCI stuff. > > > > > >>> I believe you can review it. > > > > > >>> Have you briefly gone through the patches ? It has nothing > > > > > >>> to do with the PSCI > > > > > >> stuff. > > > > > >>> It just call the invoke_smc() function to call the ATF's > > > > > >>> PSCI functions. Those PSCI functions in ATF will do the rest. > > > > > >> > > > > > >> No, not yet. But see below. > > > > > >> > > > > > > > > > > I must say it seems strange to me that U-Boot would have to > > > > > rely on ATF > > > > > >> though. > > > > > How do other platforms implement this? Shouldn't PSCI be > > > > > generic or is it really platform specific? If it's generic, > > > > > isn't that a dupliation of code if you implement e.g. a > > > > > reset driver for > > > > > Stratix10 but call > > > > > >> into PSCI? > > > > > >>> It's not strange at all. A lot of U-Boot users already > > > > > >>> using this boot flow (ATF + > > > > > >> U-Boot). > > > > > >> > > > > > >> Just because other boards do this doesn't mean it's not strange. > > > > > >> Wasn't there some kind of discussion around that PSCI stuff > > > > > >> to make it > > > > > available from U-Boot? > > > > > >> What's wrong with that way? > > > > > > Our downstream U-Boot branch is already implemented the PSCI > > > > > > stuffs in U- > > > > > Boot. > > > > > > I tried to upstream my PSCI code: > > > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html > > > > > > > > > > > > Marek pointed me to this thread: > > > > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.ht > > > > > > ml > > > > > > > > > > > > He had a point. He suggested maybe we can implement the PSCI > > > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found > > > > > > out ATF is already well > > > > > supported. Why don't we just use the PSCI code from ATF rather > > > > > than > > > > > re- implementing the PSCI code again in SPL/TPL. > > > > > > It will save our effort to maintain two PSCI code in U-Boot > > > > > > and ATF while we > > > > > already have the ATF PSCI implementation to support UEFI. > > > > > > > > > > It seems to me we do have working code in U-Boot, what's missing > > > > > is "only" to turn it ino PSCI? > > > > Existing PSCI framework in U-Boot provide a way for us to turn the > > > > code into a PSCI handler by just adding a '__secure' keyword > > > > before the > > > function name. See: > > > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-soc > > > > fpga >
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
Hi Tom, On Mon, Dec 2, 2019 at 9:11 PM Tom Rini wrote: > > Hey all, > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > fixing all of the issues that pop up as I get the MTD clean-up series > ready to go. In fact, what I need to do at this point is grab the > handful of size reduction patches that this has shown are worthwhile, > then I can do the MTD series. Then we're down to just fixing up > misconversions where things got turned off. > > Once again, for a changelog, > git log --merges v2020.01-rc3..v2020.01-rc4 > and as always, I ask for more details in the PRs people send me so I can > put them in the merge commit. > > I'm planning on doing -rc5 on December 23rd with the release scheduled > on January 6th. Thanks all! I have a -net PR just about ready, but there are a few boards failing for size. When can I expect the size reduction to drop? Thanks, -Joe
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
On Tue, Dec 03, 2019 at 10:20:51AM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 3 Dec 2019 at 10:07, Tom Rini wrote: > > > > On Tue, Dec 03, 2019 at 06:00:11PM +0100, Marek Vasut wrote: > > > On 12/3/19 5:52 PM, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 2 Dec 2019 at 20:11, Tom Rini wrote: > > > >> > > > >> Hey all, > > > >> > > > >> It's release day and here is v2020.01-rc4. Yes, I'm still working on > > > >> fixing all of the issues that pop up as I get the MTD clean-up series > > > >> ready to go. In fact, what I need to do at this point is grab the > > > >> handful of size reduction patches that this has shown are worthwhile, > > > >> then I can do the MTD series. Then we're down to just fixing up > > > >> misconversions where things got turned off. > > > >> > > > >> Once again, for a changelog, > > > >> git log --merges v2020.01-rc3..v2020.01-rc4 > > > >> and as always, I ask for more details in the PRs people send me so I > > > >> can > > > >> put them in the merge commit. > > > >> > > > >> I'm planning on doing -rc5 on December 23rd with the release scheduled > > > >> on January 6th. Thanks all! > > > > > > > > Speaking of next year, what is the plan for the release. Is there any > > > > chance we might move back to a release every two months? The > > > > three-month process is very slow... > > > > > > I am very happy with this 3-month release cycle, it's less stressful and > > > I think the quality of the releases is higher too. > > > > I thought I said this a release or so ago, sorry. I believe we'll be > > sticking with the 3-month cycle and I hope to find time to more actively > > use a -next branch myself to help with some of the delay, or at least > > slower feedback cycle. > > That would certainly help, but it hasn't proved possible so far. Let's > see how it goes with the next release. Well, it's also about custodian stress and time levels. The longer cycle seems to be better for that. > Do you think if we can improve the testing (e.g. with more mini-labs > attached to gitlab) we might resolve these stability problems? Ah right, I needed to reply to that thread, sorry. I get the feeling that the answer overall is that folks that have spent time with LAVA need to chime in, or barring that, I need to play with LAVA as that's how a lot of the "how do you reserve boards" and so forth problems are handled, and would also make an easier case for vendors to get more U-Boot testing done (as that gets you to kernelci too, or if you already have kernelci going, you can add U-Boot with just a few more steps). -- Tom signature.asc Description: PGP signature
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
On 12/3/19 5:52 PM, Simon Glass wrote: > Hi Tom, > > On Mon, 2 Dec 2019 at 20:11, Tom Rini wrote: >> >> Hey all, >> >> It's release day and here is v2020.01-rc4. Yes, I'm still working on >> fixing all of the issues that pop up as I get the MTD clean-up series >> ready to go. In fact, what I need to do at this point is grab the >> handful of size reduction patches that this has shown are worthwhile, >> then I can do the MTD series. Then we're down to just fixing up >> misconversions where things got turned off. >> >> Once again, for a changelog, >> git log --merges v2020.01-rc3..v2020.01-rc4 >> and as always, I ask for more details in the PRs people send me so I can >> put them in the merge commit. >> >> I'm planning on doing -rc5 on December 23rd with the release scheduled >> on January 6th. Thanks all! > > Speaking of next year, what is the plan for the release. Is there any > chance we might move back to a release every two months? The > three-month process is very slow... I am very happy with this 3-month release cycle, it's less stressful and I think the quality of the releases is higher too.
Re: [PATCH v3] warp7: Fix U-Boot corruption after saving the environment
On Tue, Dec 03, 2019 at 06:07:57PM +0100, Heiko Schocher wrote: > Hello Fabio, > > Am 03.12.2019 um 12:56 schrieb Fabio Estevam: > > Hi Tom, > > > > On Tue, Dec 3, 2019 at 12:10 AM Tom Rini wrote: > > > > > Thanks for the rework. Can you please look at what other i.MX boards > > > are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have > > > thumb2 related errata that might make it a bad idea to use thumb by > > > default ? > > > > It looks like i.MX51 and i.MX53 have the thumb related erratum: > > https://www.nxp.com/docs/en/errata/IMX53CE.pdf > > > > i.MX6 series should work fine in thumb without issues and we could try > > to enable thumb by default for the next cycle. > > I just enabled thumb build [1] for the DM/DTS rework for the imx6 based > aristainetos board ... and as I can say, U-Boot works fine on it. There's a number of other SoCs using it too :) It really just isn't default due to the problems of early-generation ARMv7 platforms and in turn my not wanting to break them by accident. But with that in mind, a deeper dive in to a few different vendor SoCs should tell us which ones need to default to off and what can be on, and we could get better size defaults all around (but not force, let people decide if thumb2-but-smaller is quicker boot than full-but-larger). -- Tom signature.asc Description: PGP signature
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
Hi Tom, On Tue, 3 Dec 2019 at 10:07, Tom Rini wrote: > > On Tue, Dec 03, 2019 at 06:00:11PM +0100, Marek Vasut wrote: > > On 12/3/19 5:52 PM, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 2 Dec 2019 at 20:11, Tom Rini wrote: > > >> > > >> Hey all, > > >> > > >> It's release day and here is v2020.01-rc4. Yes, I'm still working on > > >> fixing all of the issues that pop up as I get the MTD clean-up series > > >> ready to go. In fact, what I need to do at this point is grab the > > >> handful of size reduction patches that this has shown are worthwhile, > > >> then I can do the MTD series. Then we're down to just fixing up > > >> misconversions where things got turned off. > > >> > > >> Once again, for a changelog, > > >> git log --merges v2020.01-rc3..v2020.01-rc4 > > >> and as always, I ask for more details in the PRs people send me so I can > > >> put them in the merge commit. > > >> > > >> I'm planning on doing -rc5 on December 23rd with the release scheduled > > >> on January 6th. Thanks all! > > > > > > Speaking of next year, what is the plan for the release. Is there any > > > chance we might move back to a release every two months? The > > > three-month process is very slow... > > > > I am very happy with this 3-month release cycle, it's less stressful and > > I think the quality of the releases is higher too. > > I thought I said this a release or so ago, sorry. I believe we'll be > sticking with the 3-month cycle and I hope to find time to more actively > use a -next branch myself to help with some of the delay, or at least > slower feedback cycle. That would certainly help, but it hasn't proved possible so far. Let's see how it goes with the next release. Do you think if we can improve the testing (e.g. with more mini-labs attached to gitlab) we might resolve these stability problems? Regards, Simon
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote: > Hi Tom, > > On Mon, Dec 2, 2019 at 9:11 PM Tom Rini wrote: > > > > Hey all, > > > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > > fixing all of the issues that pop up as I get the MTD clean-up series > > ready to go. In fact, what I need to do at this point is grab the > > handful of size reduction patches that this has shown are worthwhile, > > then I can do the MTD series. Then we're down to just fixing up > > misconversions where things got turned off. > > > > Once again, for a changelog, > > git log --merges v2020.01-rc3..v2020.01-rc4 > > and as always, I ask for more details in the PRs people send me so I can > > put them in the merge commit. > > > > I'm planning on doing -rc5 on December 23rd with the release scheduled > > on January 6th. Thanks all! > > I have a -net PR just about ready, but there are a few boards failing > for size. When can I expect the size reduction to drop? How much are they failing? You can rebase on top of WIP/2019-12-03-master-imports and see if that's enough. But also if it's for packed member things, I'm not sure if that's the right approach vs disabling the warning like the Linux kernel does (and we do today, for clang). -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools/imximage: fix reported DCD information for MX7ULP
Hi Jorge, On Tue, Dec 3, 2019 at 11:07 AM Jorge Ramirez-Ortiz, Foundries wrote: > sure that would work. given that the default 0x0091 is valid on > most of the cases - well all but the mx7ulp - we could apply this default and > only change to the > Kconfig value if defined. > > should we go for that? Yes, that would be fine.
Repeating of unknown commands
Hi, I have a question regarding the command repeat feature when you press return without additional input. The current behavior is, that unknown commands are repeated like regular commands: => foobar Unknown command 'foobar' - try 'help' => Unknown command 'foobar' - try 'help' This wasn't the case in older versions like 2011.12, which I have running on a board. I believe this was changed in 9d12d5d41d "Add cmd_process() to process commands in one place" but I couldn't find a mention of this change in behavior. Was this intentional or not? Thanks, Martin
Re: [PATCH] test.py: Make search for autoconf.mk more permission
Hi Stephen, On Mon, 2 Dec 2019 at 09:04, Stephen Warren wrote: > > On 12/1/19 7:34 PM, Simon Glass wrote: > > Buildman doesn't store this file in the same directory as a normal build. > > Update the conftest code to handle both cases. > > Shouldn't we just fix buildman so that it puts the files in the standard > locations? That way, we don't have to separately update every tool that > might want to find/interpret this file or archive the build results, but > instead just update one tool (buildman). Well we could, but IMO it is better to separate the build process from the output process. With buildman the outputs end up all in the same directory (including spl, for example). I think it becomes confusing if we just leave files where the build system happens to leave them, even worse if we wanted to keep files in include/generated. Also, those locations might change in future. It is certainly good to have pytests run on a build without preprocessing, though. Regards, Simon
Please pull u-boot-dm
Hi Tom, Build here: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1506 The following changes since commit dd38416d6b354acb5d12e2bd1fd45e7e63b8a605: Merge git://git.denx.de/u-boot-socfpga (2019-11-28 07:34:41 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-3dec19 for you to fetch changes up to 151f275e0562a0dcb7b6745131753f968e12b9f0: dm: serial: Handle "stdout-path" with ":options" correctly (2019-12-02 16:18:05 -0700) Fix stdout-path handling Bin Meng (1): dm: serial: Handle "stdout-path" with ":options" correctly drivers/serial/serial-uclass.c | 36 +++- 1 file changed, 19 insertions(+), 17 deletions(-) Regards, Simon
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
Hi Tom, On Mon, 2 Dec 2019 at 20:11, Tom Rini wrote: > > Hey all, > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > fixing all of the issues that pop up as I get the MTD clean-up series > ready to go. In fact, what I need to do at this point is grab the > handful of size reduction patches that this has shown are worthwhile, > then I can do the MTD series. Then we're down to just fixing up > misconversions where things got turned off. > > Once again, for a changelog, > git log --merges v2020.01-rc3..v2020.01-rc4 > and as always, I ask for more details in the PRs people send me so I can > put them in the merge commit. > > I'm planning on doing -rc5 on December 23rd with the release scheduled > on January 6th. Thanks all! Speaking of next year, what is the plan for the release. Is there any chance we might move back to a release every two months? The three-month process is very slow... Regards, Simon
Re: [PATCH] arm: imx: Default to SYS_THUMB_BUILD for i.MX6/7
Hi Tom, On Tue, Dec 3, 2019 at 11:28 AM Tom Rini wrote: > > In the case of i.MX6 and i.MX7 family SoCs it is safe (from an errata > point of view) to use thumb2 by default to save space. > > Cc: Stefano Babic > Cc: Fabio Estevam > Signed-off-by: Tom Rini I think it is safer to apply this after 2020.01 is released: Reviewed-by: Fabio Estevam
[PATCH 2/2] rockchip: misc: Don't fail if ethaddr is already set
rockchip_setup_macaddr will return -1 if ethaddr is already set, which
gets propagated to misc_init_r and eventually halts the boot process.
While checking that the variable is not already set before attempting to
setit is legitimate (it's a set-once variable), this is no good reason
to halt the boot process.
Return the success return code if the variable is already set instead.
Signed-off-by: Paul Kocialkowski
---
arch/arm/mach-rockchip/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index a0c6a1c0b266..bce10bb04f8f 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -29,7 +29,7 @@ int rockchip_setup_macaddr(void)
/* Only generate a MAC address, if none is set in the environment */
if (env_get("ethaddr"))
- return -1;
+ return 0;
if (!cpuid) {
debug("%s: could not retrieve 'cpuid#'\n", __func__);
--
2.24.0
[PATCH v2] arm64: zynqmp: Do not assing MIO34 that early on zcu100
MIO34 is connected to POWER_KILL signal. When MIO configuration is done in
psu_init() and this pin is assigned to PMU but PMU configuration is not
loaded yet. PMU gpio output is high that means board is powered off
immediately.
The patch is fixing this sequence that MIO34 stays assing to ps gpio IP.
PMU config is loaded in SPL and then pin assigned to PMU through
psu_post_config_data().
Signed-off-by: Michal Simek
---
Changes in v2:
- add missing declaration in header
arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h | 1 +
arch/arm/mach-zynqmp/psu_spl_init.c | 9 +
arch/arm/mach-zynqmp/spl.c| 1 +
board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c | 7 ++-
4 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
b/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
index 15e54c049387..e37acda2f89e 100644
--- a/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
+++ b/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
@@ -21,5 +21,6 @@ void prog_reg(unsigned long addr, unsigned long mask,
unsigned long shift, unsigned long value);
int psu_init(void);
+unsigned long psu_post_config_data(void);
#endif /* _PSU_INIT_GPL_H_ */
diff --git a/arch/arm/mach-zynqmp/psu_spl_init.c
b/arch/arm/mach-zynqmp/psu_spl_init.c
index b357de32358c..b6abdfd608ee 100644
--- a/arch/arm/mach-zynqmp/psu_spl_init.c
+++ b/arch/arm/mach-zynqmp/psu_spl_init.c
@@ -77,3 +77,12 @@ __weak int psu_init(void)
*/
return -1;
}
+
+__weak unsigned long psu_post_config_data(void)
+{
+ /*
+* This function is overridden by the one in
+* board/xilinx/zynqmp/(platform)/psu_init_gpl.c, if it exists.
+*/
+ return 0;
+}
diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index 6ba42bb42f62..6551b33f42d0 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -60,6 +60,7 @@ void spl_board_init(void)
preloader_console_init();
ps_mode_reset(MODE_RESET);
board_init();
+ psu_post_config_data();
}
#endif
diff --git a/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
index e1fdabaeb9d1..585b3afc218a 100644
--- a/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
+++ b/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
@@ -409,7 +409,6 @@ static unsigned long psu_mio_init_data(void)
psu_mask_write(0xFF18007C, 0x00FEU, 0xU);
psu_mask_write(0xFF180080, 0x00FEU, 0x0008U);
psu_mask_write(0xFF180084, 0x00FEU, 0x0008U);
- psu_mask_write(0xFF180088, 0x00FEU, 0x0008U);
psu_mask_write(0xFF18008C, 0x00FEU, 0xU);
psu_mask_write(0xFF180090, 0x00FEU, 0xU);
psu_mask_write(0xFF180094, 0x00FEU, 0xU);
@@ -990,3 +989,9 @@ int psu_init(void)
return 1;
return 0;
}
+
+unsigned long psu_post_config_data(void)
+{
+ psu_mask_write(0xFF180088, 0x00FEU, 0x0008U);
+ return 0;
+}
--
2.24.0
[PATCH v3 4/6] drivers: net: add Felix DSA switch driver
This driver is used for the Ethernet switch integrated into LS1028A NXP.
Felix on LS1028A has 4 front panel ports and two internal ports, I/O
to/from the switch is done through an ENETC Ethernet interface.
The 4 front panel ports are available as Ethernet interfaces and can be
used with the typical network commands like tftp.
Signed-off-by: Alex Marginean
Tested-by: Michael Walle
---
drivers/net/fsl_enetc.h | 5 +
drivers/net/mscc_eswitch/Kconfig| 8 +
drivers/net/mscc_eswitch/Makefile | 1 +
drivers/net/mscc_eswitch/felix_switch.c | 454
4 files changed, 468 insertions(+)
create mode 100644 drivers/net/mscc_eswitch/felix_switch.c
diff --git a/drivers/net/fsl_enetc.h b/drivers/net/fsl_enetc.h
index 9a36cdad80..29e7781b5e 100644
--- a/drivers/net/fsl_enetc.h
+++ b/drivers/net/fsl_enetc.h
@@ -200,6 +200,11 @@ struct enetc_priv {
/* PCS replicator block for USXGMII */
#define ENETC_PCS_DEVAD_REPL 0x1f
+#define ENETC_PCS_REPL_LINK_TIMER_10x12
+#define ENETC_PCS_REPL_LINK_TIMER_1_DEF 0x0003
+#define ENETC_PCS_REPL_LINK_TIMER_20x13
+#define ENETC_PCS_REPL_LINK_TIMER_2_DEF 0x06a0
+
/* ENETC external MDIO registers */
#define ENETC_MDIO_BASE0x1c00
#define ENETC_MDIO_CFG 0x00
diff --git a/drivers/net/mscc_eswitch/Kconfig b/drivers/net/mscc_eswitch/Kconfig
index 80dd22f98b..11fb08edaa 100644
--- a/drivers/net/mscc_eswitch/Kconfig
+++ b/drivers/net/mscc_eswitch/Kconfig
@@ -36,3 +36,11 @@ config MSCC_SERVAL_SWITCH
select PHYLIB
help
This driver supports the Serval network switch device.
+
+config MSCC_FELIX_SWITCH
+ bool "Felix switch driver"
+ depends on DM_DSA && DM_PCI
+ select FSL_ENETC
+ help
+ This driver supports the Ethernet switch integrated in LS1028A NXP
+ SoC.
diff --git a/drivers/net/mscc_eswitch/Makefile
b/drivers/net/mscc_eswitch/Makefile
index d583fe9fc4..22342ed114 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o
mscc_mac_table.o m
obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o mscc_miim.o
obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o mscc_miim.o
obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o
mscc_mac_table.o mscc_miim.o
+obj-$(CONFIG_MSCC_FELIX_SWITCH) += felix_switch.o
diff --git a/drivers/net/mscc_eswitch/felix_switch.c
b/drivers/net/mscc_eswitch/felix_switch.c
new file mode 100644
index 00..3723aad4b4
--- /dev/null
+++ b/drivers/net/mscc_eswitch/felix_switch.c
@@ -0,0 +1,454 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Felix Ethernet switch driver
+ * Copyright 2018-2019 NXP
+ */
+
+/*
+ * This driver is used for the Ethernet switch integrated into LS1028A NXP.
+ * Felix switch is derived from Microsemi Ocelot but there are several NXP
+ * adaptations that makes the two U-Boot drivers largely incompatible.
+ *
+ * Felix on LS1028A has 4 front panel ports and two internal ports, connected
+ * to ENETC interfaces. We're using one of the ENETC interfaces to push
traffic
+ * into the switch. Injection/extraction headers are used to identify
+ * egress/ingress ports in the switch for Tx/Rx.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* defines especially around PCS are reused from enetc */
+#include "../fsl_enetc.h"
+
+#define PCI_DEVICE_ID_FELIX_ETHSW 0xEEF0
+
+/* Felix has in fact 6 ports, but we don't use the last internal one */
+#define FELIX_PORT_COUNT 5
+/* Front panel port mask */
+#define FELIX_FP_PORT_MASK 0xf
+
+/* Register map for BAR4 */
+#define FELIX_SYS 0x01
+#define FELIX_ES0 0x04
+#define FELIX_IS1 0x05
+#define FELIX_IS2 0x06
+#define FELIX_GMII(port) (0x10 + (port) * 0x1)
+#define FELIX_QSYS 0x20
+
+#define FELIX_SYS_SYSTEM (FELIX_SYS + 0x0E00)
+#define FELIX_SYS_SYSTEM_EN BIT(0)
+#define FELIX_SYS_RAM_CTRL (FELIX_SYS + 0x0F24)
+#define FELIX_SYS_RAM_CTRL_INIT BIT(1)
+#define FELIX_SYS_SYSTEM_PORT_MODE(a) (FELIX_SYS_SYSTEM + 0xC + (a) * 4)
+#define FELIX_SYS_SYSTEM_PORT_MODE_CPU0x001e
+
+#define FELIX_ES0_TCAM_CTRL(FELIX_ES0 + 0x03C0)
+#define FELIX_ES0_TCAM_CTRL_ENBIT(0)
+#define FELIX_IS1_TCAM_CTRL(FELIX_IS1 + 0x03C0)
+#define FELIX_IS1_TCAM_CTRL_ENBIT(0)
+#define FELIX_IS2_TCAM_CTRL(FELIX_IS2 + 0x03C0)
+#define FELIX_IS2_TCAM_CTRL_ENBIT(0)
+
+#define FELIX_GMII_CLOCK_CFG(port) (FELIX_GMII(port) + 0x)
+#define FELIX_GMII_CLOCK_CFG_LINK_1G 1
+#define FELIX_GMII_CLOCK_CFG_LINK_100M2
+#define FELIX_GMII_CLOCK_CFG_LINK_10M 3
