Re: [PATCH] tools: k3_gen_x509_cert: Allow selecting early JTAG debug value
On 23/04/20 6:12 PM, Andrew F. Davis wrote: > On 4/23/20 2:38 AM, Lokesh Vutla wrote: >> >> >> On 22/04/20 10:39 PM, Andrew F. Davis wrote: >>> When authenticating the initial boot binary the ROM will check a debug >>> type value in the certificate and based on that open JTAG access to that >>> core. >>> >>> The default is currently full access, on HS this is useful for early >>> developers, but should not be the default as to prevent end system >>> integrators from unintentionally leaving this open. >> >> Won't JTAG access is useful for early developers. UART as well not available >> at >> this point. What we offer out of the box is not a production ready secure >> system. I would prefer to have it enabled by default. >> > > > Who are these early developers? Pre-SYSFW on HS is a harsh environment, > firewalls and other pitfalls limit one to only what is needed to get > SYSFW loaded. Only a handful of folks will ever touch the source this > early, and they will be using a GP device for that development, in which > case debug is enabled, even with this change. > > I'd guess I'm the only developer touching code this early on HS, I say For how long you are guaranteeing that? This cannot be an assumption for making default options. > this as so far I'm the only one who has noticed that there is a ROM > issue that makes early debug on HS almost unusable. > > Accidentally leaving this open completely defeats the chain of trust, I > guarantee some production system will do this if we leave JTAG open by > default, it happens all the time. Did you audit all other default options? > > So debug doesn't work here anyway, no one uses it and those who do can > flip this bit with the command line flag, and leaving it on will lead to > a huge security issue for one of our customers. Then please split this change into two patches. 1- adding a command line option. 2- changing the default options with reasons clearly mentioned in the commit description. Thanks and regards, Lokesh
Re: [PATCH] lib/crypto, efi_loader: avoid multiple inclusions of header files
Heinrich, On Thu, Apr 23, 2020 at 09:34:37AM +0200, Heinrich Schuchardt wrote: > On 23.04.20 02:28, AKASHI Takahiro wrote: > > Heinrich, > > > > On Tue, Apr 21, 2020 at 12:23:13PM +0200, Heinrich Schuchardt wrote: > >> On 4/21/20 2:37 AM, AKASHI Takahiro wrote: > >>> By adding extra symbols, we can now avoid including x509_parser and > >>> pkcs7_parser.h files multiple times. > >>> > >>> Signed-off-by: AKASHI Takahiro > >>> Suggested-by: Heinrich Schuchardt > >>> --- > >>> lib/crypto/pkcs7_parser.h | 4 > >>> lib/crypto/x509_parser.h | 4 > >>> lib/efi_loader/efi_image_loader.c | 1 + > >>> lib/efi_loader/efi_signature.c| 1 + > >>> 4 files changed, 10 insertions(+) > >>> > >>> diff --git a/lib/crypto/pkcs7_parser.h b/lib/crypto/pkcs7_parser.h > >>> index 6565fdc2d4ca..b8234da45a6a 100644 > >>> --- a/lib/crypto/pkcs7_parser.h > >>> +++ b/lib/crypto/pkcs7_parser.h > >>> @@ -5,6 +5,9 @@ > >>> * Written by David Howells (dhowe...@redhat.com) > >>> */ > >>> > >>> +#ifndef _PKCS7_PARSER_H > >>> +#define _PKCS7_PARSER_H > >>> + > >>> #include > >>> #include > >>> #include "x509_parser.h" > >>> @@ -63,3 +66,4 @@ struct pkcs7_message { > >>> size_t data_hdrlen;/* Length of Data ASN.1 header */ > >>> const void *data; /* Content Data (or 0) */ > >>> }; > >>> +#endif /* _PKCS7_PARSER_H */ > >>> diff --git a/lib/crypto/x509_parser.h b/lib/crypto/x509_parser.h > >>> index c233f136fb35..4cbdc1d6612d 100644 > >>> --- a/lib/crypto/x509_parser.h > >>> +++ b/lib/crypto/x509_parser.h > >>> @@ -5,6 +5,9 @@ > >>> * Written by David Howells (dhowe...@redhat.com) > >>> */ > >>> > >>> +#ifndef _X509_PARSER_H > >>> +#define _X509_PARSER_H > >>> + > >>> #include > >>> #include > >>> #include > >>> @@ -55,3 +58,4 @@ extern int x509_decode_time(time64_t *_t, size_t > >>> hdrlen, > >>> */ > >>> extern int x509_get_sig_params(struct x509_certificate *cert); > >>> extern int x509_check_for_self_signed(struct x509_certificate *cert); > >>> +#endif /* _X509_PARSER_H */ > >>> diff --git a/lib/efi_loader/efi_image_loader.c > >>> b/lib/efi_loader/efi_image_loader.c > >>> index 6c270ce94f44..899adf8493d0 100644 > >>> --- a/lib/efi_loader/efi_image_loader.c > >>> +++ b/lib/efi_loader/efi_image_loader.c > >>> @@ -14,6 +14,7 @@ > >>> #include > >>> #include > >>> #include "../lib/crypto/pkcs7_parser.h" > >>> +#include "../lib/crypto/x509_parser.h" > >> > >> As pkcs7_parser.h includes x509_parser.h there is no reason to include > >> it again. > > > > No, I don't think so. > > > > My style of coding is that, if a symbol is used in a C file and it is > > defined in a header file, the header file should be *directly* included > > in the C file. > > I believe that it is the common way so that we can avoid any "implicit" > > dependencies among header files. > > We want U-Boot to build as fast as possible. So we should not include > anything twice. When looking through the rest of the U-Boot code you > will have noticed that we do not include malloc.h and stdio.h everywhere > because it is included via common.h. The same comment here. -Takahiro Akashi > As an example of a patch removing other unnecessary includes see for > instance: > > cmd: fat: remove unused includes > fd0e30b43b6b2401e68dc32c357869c617d4fdd1 > > Best regards > > Heinrich > > > > > Thanks, > > -Takahiro Akashi > > > > > >>> > >>> const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID; > >>> const efi_guid_t efi_guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID; > >>> diff --git a/lib/efi_loader/efi_signature.c > >>> b/lib/efi_loader/efi_signature.c > >>> index 658e3547da37..6ad09e4acbd7 100644 > >>> --- a/lib/efi_loader/efi_signature.c > >>> +++ b/lib/efi_loader/efi_signature.c > >>> @@ -15,6 +15,7 @@ > >>> #include > >>> #include > >>> #include "../lib/crypto/pkcs7_parser.h" > >>> +#include "../lib/crypto/x509_parser.h" > >> > >> Same here. > >> > >> The rest is correct and should be merged. > >> > >> Best regards > >> > >> Heinrich > >> > >>> > >>> const efi_guid_t efi_guid_image_security_database = > >>> EFI_IMAGE_SECURITY_DATABASE_GUID; > >>> > >> >
Re: [PATCH] lib/crypto, efi_loader: move some headers to include/crypto
Heinrich, On Thu, Apr 23, 2020 at 09:33:37AM +0200, Heinrich Schuchardt wrote: > On 23.04.20 02:31, AKASHI Takahiro wrote: > > Heinrich, > > > > On Tue, Apr 21, 2020 at 12:26:08PM +0200, Heinrich Schuchardt wrote: > >> On 4/21/20 2:38 AM, AKASHI Takahiro wrote: > >>> Pkcs7_parse.h and x509_parser.h are used in UEFI subsystem, in particular, > >>> secure boot. So move them to include/crypto to avoid relative paths. > >>> > >>> Signed-off-by: AKASHI Takahiro > >>> Suggested-by: Heinrich Schuchardt > >>> --- > >>> {lib => include}/crypto/pkcs7_parser.h | 0 > >>> {lib => include}/crypto/x509_parser.h | 0 > >>> lib/crypto/pkcs7_parser.c | 4 > >>> lib/crypto/x509_cert_parser.c | 4 > >>> lib/crypto/x509_public_key.c | 6 -- > >>> lib/efi_loader/efi_image_loader.c | 4 ++-- > >>> lib/efi_loader/efi_signature.c | 4 ++-- > >>> lib/efi_loader/efi_variable.c | 2 +- > >>> test/lib/asn1.c| 4 ++-- > >>> 9 files changed, 19 insertions(+), 9 deletions(-) > >>> rename {lib => include}/crypto/pkcs7_parser.h (100%) > >>> rename {lib => include}/crypto/x509_parser.h (100%) > >>> > >>> diff --git a/lib/crypto/pkcs7_parser.h b/include/crypto/pkcs7_parser.h > >>> similarity index 100% > >>> rename from lib/crypto/pkcs7_parser.h > >>> rename to include/crypto/pkcs7_parser.h > >>> diff --git a/lib/crypto/x509_parser.h b/include/crypto/x509_parser.h > >>> similarity index 100% > >>> rename from lib/crypto/x509_parser.h > >>> rename to include/crypto/x509_parser.h > >>> diff --git a/lib/crypto/pkcs7_parser.c b/lib/crypto/pkcs7_parser.c > >>> index f5dda1179f8a..0ee207b6b1c8 100644 > >>> --- a/lib/crypto/pkcs7_parser.c > >>> +++ b/lib/crypto/pkcs7_parser.c > >>> @@ -20,7 +20,11 @@ > >>> #include > >>> #include > >>> #include > >>> +#ifdef __UBOOT__ > >>> +#include > >>> +#else > >>> #include "pkcs7_parser.h" > >>> +#endif > >>> #include "pkcs7.asn1.h" > >>> > >>> MODULE_DESCRIPTION("PKCS#7 parser"); > >>> diff --git a/lib/crypto/x509_cert_parser.c b/lib/crypto/x509_cert_parser.c > >>> index 4e41cffd2301..18f5407a076c 100644 > >>> --- a/lib/crypto/x509_cert_parser.c > >>> +++ b/lib/crypto/x509_cert_parser.c > >>> @@ -18,7 +18,11 @@ > >>> #include > >>> #endif > >>> #include > >>> +#ifdef __UBOOT__ > >>> +#include > >>> +#else > >>> #include "x509_parser.h" > >>> +#endif > >>> #include "x509.asn1.h" > >>> #include "x509_akid.asn1.h" > >>> > >>> diff --git a/lib/crypto/x509_public_key.c b/lib/crypto/x509_public_key.c > >>> index 676c0df17410..571af9a0adf9 100644 > >>> --- a/lib/crypto/x509_public_key.c > >>> +++ b/lib/crypto/x509_public_key.c > >>> @@ -16,15 +16,17 @@ > >>> #include > >>> #endif > >>> #include > >>> -#ifndef __UBOOT__ > >>> +#ifdef __UBOOT__ > >>> +#include > >>> +#else > >>> #include > >>> #include > >>> #include > >>> #include > >>> #include > >>> #include "asymmetric_keys.h" > >>> -#endif > >>> #include "x509_parser.h" > >>> +#endif > >>> > >>> /* > >>> * Set up the signature parameters in an X.509 certificate. This > >>> involves > >>> diff --git a/lib/efi_loader/efi_image_loader.c > >>> b/lib/efi_loader/efi_image_loader.c > >>> index 899adf8493d0..f59b9a01140e 100644 > >>> --- a/lib/efi_loader/efi_image_loader.c > >>> +++ b/lib/efi_loader/efi_image_loader.c > >>> @@ -13,8 +13,8 @@ > >>> #include > >>> #include > >>> #include > >>> -#include "../lib/crypto/pkcs7_parser.h" > >>> -#include "../lib/crypto/x509_parser.h" > >>> +#include "crypto/pkcs7_parser.h" > >>> +#include "crypto/x509_parser.h" > >> > >> Thanks for fixing this. > >> > >> x509_parser.h is included in pkcs7_parser.h. Please, remove the > >> superfluous line. > > > > See my comment in [1] > > > > [1] https://lists.denx.de/pipermail/u-boot/2020-April/408160.html > > We want U-Boot to build as fast as possible. So we should not include > anything twice. When looking through the rest of the U-Boot code you > will have noticed that we do not include malloc.h and stdio.h everywhere > because it is included via common.h. I can't agree with you. "common.h" is not a good example; its purpose is to aggregate some some useful header files so that people don't get bothered with finding out an exact set of header files needed. "common.h" is even a *bad* example if you say, "We want U-Boot to build as fast as possible." because "common.h" may contain a lot of header files that may never be used in a given C file. So I won't change my patch. -Takahiro Akashi > As an example of a patch removing other unnecessary includes see for > instance: > > cmd: fat: remove unused includes > fd0e30b43b6b2401e68dc32c357869c617d4fdd1 > > Best regards > > Heinrich > > > > > -Takahiro Akashi > > > > > >>> > >>> const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID; > >>> const efi_guid_t efi_guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID; > >>> diff --git a/lib/efi_loader/efi_signature.c > >>>
Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
On Thu, Apr 23, 2020 at 5:24 AM Chen-Yu Tsai wrote: > > Hi, > > On Tue, Apr 21, 2020 at 1:35 AM Peter Geis wrote: > > > > On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder wrote: > > > > > > Hi Chen, > > > > > > I tested your patches and all work pretty well. I just had issues with > > > USB2 that doesn't recognize any of my USB keys (it's OK on USB3). > > > > > > I also had these issues with XHCI driver: > > > => usb reset > > > resetting USB... > > > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()! > > > BUG! > > > �esetting ... > > > > > > => usb stop > > > stopping USB.. > > > Host not halted after 16000 microseconds. > > > XHCI: failed to set VBus supply > > > device_remove: Device 'usb@ff60' failed to remove, but children are > > > gone > > > > > > But for the whole series: Tested-by: Loic Devulder > > > > > > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote: > > > > From: Chen-Yu Tsai > > > > > > > > Hi everyone, > > > > > > > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly > > > > dropping the custom board target, and dealing with the pinmuxing > > > > through proper use of DM regulators / GPIO / pinctrl in SPL. > > > > > > > > This series adds proper support for Firefly / Libre Computer ROC- > > > > RK3328-CC > > > > single board computer. > > > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit > > > > card size development board based on the Rockchip RK3328 SoC, with: > > > > > > > > - 1/2/4 GB DDR4 DRAM > > > > - eMMC connector for optional module > > > > - micro SD card slot > > > > - 1 x USB 3.0 host port > > > > - 2 x USB 2.0 host port > > > > - 1 x USB 2.0 OTG port > > > > - HDMI video output > > > > - TRRS connector with audio and composite video output > > > > - gigabit Ethernet > > > > - consumer IR receiver > > > > - debug UART pins > > > > > > > > Originally I started with Loic's patches, and syncing the device tree > > > > files from Linux. That didn't get very far, with SPL failing to > > > > detect > > > > the SD card. Examining the schematics and internal state of GRF and > > > > GPIOs, I realized that the logic for the SD card power enable switch > > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin > > > > would use. Instead, directly using the GPIO is required. > > > > > > > > To deal with this, DM regulator and GPIO are enabled in SPL, and > > > > various device nodes are marked with u-boot,dm-spl to have them work. > > > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN > > > > pin muxed over to GPIO. > > > > > > > > Along the way, there are some clean-ups of existing dts files, moving > > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync > > > > from Linux. Only boards already existing in U-boot are synced. DT > > > > binding header files are synced separately as there is already one > > > > patch floating around. The DT sync also includes clean-up changes > > > > only > > > > recently posted, and likely won't make it in for at least a few > > > > weeks. > > > > > > > > Please have a look, and test if possible. I cc-ed a couple people > > > > that > > > > showed interest in this board on mailing lists recently. > > > > > > > > Regards > > > > ChenYu > > > > > > > > > > > > Chen-Yu Tsai (6): > > > > rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u- > > > > boot.dtsi > > > > rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u- > > > > boot.dtsi > > > > dt-bindings: clock: rk3328: sync from upstream Linux kernel > > > > dt-bindings: power: rk3328-power: sync from upstream Linux kernel > > > > rockchip: dts: rk3328: Sync device tree files from Linux > > > > rockchip: rk3328: Add support for ROC-RK3328-CC board > > > > > > > > arch/arm/dts/Makefile |1 + > > > > arch/arm/dts/rk3328-evb-u-boot.dtsi | 39 + > > > > arch/arm/dts/rk3328-evb.dts | 220 +-- > > > > arch/arm/dts/rk3328-roc-cc-u-boot.dtsi| 38 + > > > > .../{rk3328-rock64.dts => rk3328-roc-cc.dts} | 135 +- > > > > arch/arm/dts/rk3328-rock64.dts| 132 +- > > > > arch/arm/dts/rk3328.dtsi | 1420 +++-- > > > > > > > > board/rockchip/evb_rk3328/MAINTAINERS |7 + > > > > configs/roc-cc-rk3328_defconfig | 103 ++ > > > > doc/README.rockchip |4 +- > > > > include/dt-bindings/clock/rk3328-cru.h| 212 +-- > > > > include/dt-bindings/power/rk3328-power.h | 19 + > > > > 12 files changed, 1578 insertions(+), 752 deletions(-) > > > > create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi > > > > copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%) > > > > create mode 100644 configs/roc-cc-rk3328_defconfig > > > > create mode 100644 include/dt-bindings/power/rk3328-power.h > > > > > > > -- > > > Loic Devulder | ldevulder@irc > > >
Re: [PATCH] dm: pinctrl: Use right device pointer for configuring pinctrl
On Thu, Apr 23, 2020 at 07:49:36AM +, Patrick DELAUNAY wrote: > Hi, > > > From: Lokesh Vutla > > Sent: mercredi 22 avril 2020 19:26 > > > > commit 719cab6d2e2bf ("dm: pinctrl: convert pinctrl-single to livetree") > > converted > > pinctrl driver to livetree. In this conversion, the call to read > > pinctrl-single,pins/bits > > property is provided with pinctrl device pointer instead of pinctrl config > > pointer. > > Because of this none of the pins gets configured. Fix it by passing the > > right > > udevice pointer. > > > > Fixes: 719cab6d2e2bf ("dm: pinctrl: convert pinctrl-single to livetree") > > Reported-by: Tom Rini > > Signed-off-by: Lokesh Vutla > > --- > > drivers/pinctrl/pinctrl-single.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Sorry for regression... > > Reviewed-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] Pull request: u-boot-riscv/master
On Thu, Apr 23, 2020 at 04:25:55PM +0800, ub...@andestech.com wrote: > Hi Tom, > > Please pull some riscv updates: > > - Adds few DT related fixes required for Linux EFI stub to work on RISC-V. > - Makes SBI v0.2 the default SBI version to work with OpenSBI v0.7. > - Revert "riscv: qemu: clear kernel-start/-end in device tree as workaround > for BBL" > - Remove unnecessary CONFIG_IS_ENABLED(). > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678432471 > > Thanks > Rick > > > The following changes since commit caad316b3165615f1a4848901811a4a08c9d: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-04-22 > 13:00:21 -0400) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 177c53fe6c64d8656f5a647116a97047202c5455: > > riscv: Move all fdt fixups together (2020-04-23 10:14:16 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/7] examples: rename __start to _start on MIPS
Dear Daniel, In message you wrote: > > But I'm not sure if the original intention was to use the default linker > script or the one provided by U-Boot and if examples/api/ should use the > same compiler and linker flags as example/standalone/. Some archs have > used a custom linker script. Maybe Wolfgang knows more? Sorry, I can't remember resp. I think I never knew. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quantum particles: The dreams that stuff is made of.
Re: [PATCH 06/16] arm: stm32mp: spl: display error in board_init_f
Dear Patrick, In message <8970fb86c1374d1999ff656c2a327...@sfhdag6node3.st.com> you wrote: > > > > - ret = uclass_get_device(UCLASS_CLK, 0, ); > > > - if (ret) { > > > - debug("Clock init failed: %d\n", ret); > > > - return; > > > - } > > > + clk = uclass_get_device(UCLASS_CLK, 0, ); > > > + if (clk) > > > + debug("%s: Clock init failed: %d\n", __func__, clk); > > > > > > - ret = uclass_get_device(UCLASS_RESET, 0, ); > > > - if (ret) { > > > - debug("Reset init failed: %d\n", ret); > > > - return; > > > - } > > > + reset = uclass_get_device(UCLASS_RESET, 0, ); > > > + if (reset) > > > + debug("%s: Reset init failed: %d\n", __func__, reset); > > > > > > - ret = uclass_get_device(UCLASS_PINCTRL, 0, ); > > > - if (ret) { > > > - debug("%s: Cannot find pinctrl device\n", __func__); > > > - return; > > > - } > > > + pinctrl = uclass_get_device(UCLASS_PINCTRL, 0, ); > > > + if (pinctrl) > > > + debug("%s: Cannot find pinctrl device: %d\n", > > > + __func__, pinctrl); > > > > > > /* enable console uart printing */ > > > preloader_console_init(); > > > > > > + if (clk || reset || pinctrl) > > > + printf("%s: probe failed clk=%d reset=%d pinctrl=%d\n", > > > +__func__, clk, reset, pinctrl); > > > + > > > > This change makes little sense to me/ If you want error messages, then > > just turn > > above debug() into printf(), and be done with it. > > As an additional benefit so see at once which step failed. > > In this patch, I try to display error as soon as console is available > (after preloader_console_init) , if after one driver initialization > (clk, reset, pincontrol) failing. > > Change debug to printf only works only if CONFIG_DEBUG_UART > is activated (not by default) and board_debug_uart_init() exist to configure > the needed UART TX pins. Maybe you can remember an error code so you can tell the user which of the steps failed? That would be more useful, then. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I know engineers. They love to change things. - Dr. McCoy
[PATCH] ARC: AXS10x: cleanup kconfig
As we've dropped NAND support for AXS101 and AXS103 see commit 4f5e552d95bb ("ARC: AXS10x: drop NAND support") we don't need bounce buffer anymore. Signed-off-by: Eugeniy Paltsev --- arch/arc/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index ea875711e70..6ff201fa816 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -164,11 +164,9 @@ config TARGET_NSIM config TARGET_AXS101 bool "Support Synopsys Designware SDP board AXS101" - select BOUNCE_BUFFER if CMD_NAND config TARGET_AXS103 bool "Support Synopsys Designware SDP board AXS103" - select BOUNCE_BUFFER if CMD_NAND config TARGET_EMSDP bool "Synopsys EM Software Development Platform" -- 2.21.1
Re: rk3399 single channel lpddr4 setup
On 23/04/2020 12:38, Jagan Teki wrote: > On Tue, Apr 21, 2020 at 7:54 PM Jack Mitchell wrote: >> >> Has anyone worked with an rk3399 based board with a single channel RAM >> setup? I've looked at the current code and made some changes for only >> setting up a single channel which basically consists of altering the >> loops down to one channel, however u-boot is hanging while checking for >> a successful frequency change here: >> >>>/* change freq */ >>>writel0x3 << 4) | (1 << 2) | 1) << 16) | >>> (fn << 4) | (1 << 2) | 1, >cic->cic_ctrl0); >>>while (!(readl(>cic->cic_status0) & (1 << 2))) >>>; >>> >> >> I believe this is due to waiting for both channels to switch frequency >> which will never happen as there is only a single channel setup. >> >> Has anyone worked with a similar setup, or have any further >> documentation as the TRM only has a fairly basic register listing. > > I have tried single-channel with DDR3 which is present on NOE4, I > believe the existing code does handle single channel for LPDDR4, can > you enable debugs and check on existing code. Usually the code cannot > go and try channel 1. > > Jagan. > Hi Jagen, So I've managed to confirm it working in single channel with DDR4 on a Khadas Edge-V by shorting the reset line to RAM chip on the second channel, u-boot successfully comes up while only detecting a single chip. We've compared our board design with the NEO4 and the biggest notable difference we can see is that they power the second channel even though it's unused, while in our design we don't, leaving it completely disconnected. I believe this is what's causing our difficulties. Are you aware of any workaround which instructs the SoC to completely ignore the second channel? Regards, Jack.
Re: [PATCH 20/26 v7] spl: spl_nor: Remove unused variable 'ret' warning
Am 21.04.20 um 09:28 schrieb Stefan Roese: > With the if statement now for the legacy image handling, the compiler > now generates this compile time warning: > > common/spl/spl_nor.c:27:6: warning: unused variable 'ret' [-Wunused-variable] > > This patch removes this warning by changing the 'ret' variable handling. > > Signed-off-by: Stefan Roese > Cc: Daniel Schwierzeck > Cc: Weijie Gao > Cc: Simon Goldschmidt > --- > Changes in v7: > - New patch > > common/spl/spl_nor.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH 19/26 v7] spl: spl_nor: Move legacy image loading into spl_legacy.c
Am 21.04.20 um 09:28 schrieb Stefan Roese: > Move the legacy image loading into spl_legacy.c. This makes it easier > to extend the legacy image handling with new features that other > SPL loaders might use (e.g. spl_spi.c etc). > > No functional change intended. > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Daniel Schwierzeck > Cc: Simon Goldschmidt > --- > Changes in v7: > - Don't include "ret" usage cleanup in this patch > > Changes in v6: > - New patch > > common/spl/spl_legacy.c | 20 > common/spl/spl_nor.c| 15 +++ > include/spl.h | 13 + > 3 files changed, 40 insertions(+), 8 deletions(-) > Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH 18/26 v7] spl: spl_legacy: Use IS_ENABLED() to remove #ifdef
Am 21.04.20 um 09:28 schrieb Stefan Roese: > Use IS_ENABLED() instead of #ifdef CONFIG_ to remove one #ifdef. > > No functional change intended. > > Signed-off-by: Stefan Roese > Cc: Daniel Schwierzeck > Cc: Weijie Gao > Cc: Simon Goldschmidt > --- > Changes in v7: > - None > > Changes in v6: > - New patch > > common/spl/spl_legacy.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH 17/26 v7] spl: Extract legacy image handling into separate file
Am 21.04.20 um 09:28 schrieb Stefan Roese: > This patch moves the legacy image handling into a separate file, which > will be extended with other legacy image features later. > > No function change intended. > > Signed-off-by: Stefan Roese > Cc: Daniel Schwierzeck > Cc: Weijie Gao > Cc: Simon Goldschmidt > --- > Changes in v7: > - None > > Changes in v6: > - New patch > > common/spl/Makefile | 1 + > common/spl/spl.c| 56 + > common/spl/spl_legacy.c | 54 +++ > 3 files changed, 67 insertions(+), 44 deletions(-) > create mode 100644 common/spl/spl_legacy.c > Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH 22/26 v7] mips: spl: Flush cache before jumping to U-Boot proper
Am 21.04.20 um 09:28 schrieb Stefan Roese: > This patch adds a MIPS specific jump_to_image_no_args() implementation, > which flushes the U-Boot proper image loaded from the boot device in > SPL before jumping to it. > > It has been noticed on MT76x8, that this cache flush is needed. Other > MIPS platforms might need it as well. > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Daniel Schwierzeck > Cc: Simon Goldschmidt > --- > Changes in v7: > - Moved to MIPS specific file as suggested by Daniel > > Changes in v6: > - New patch > > arch/mips/lib/Makefile | 1 + > arch/mips/lib/spl.c| 21 + > 2 files changed, 22 insertions(+) > create mode 100644 arch/mips/lib/spl.c > Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH] bmips: allow disabling usb support
Am 04.04.20 um 16:01 schrieb Álvaro Fernández Rojas: > Currently, if usb is disabled the following error is produced: > CC drivers/usb/host/ohci-hcd.o > drivers/usb/host/ohci-hcd.c: In function ‘usb_lowlevel_init’: > drivers/usb/host/ohci-hcd.c:2057:35: error: ‘CONFIG_SYS_USB_OHCI_REGS_BASE’ > undeclared (first use in this function); did you mean > ‘CONFIG_SYS_MONITOR_BASE’? > gohci.regs = (struct ohci_regs *)CONFIG_SYS_USB_OHCI_REGS_BASE; >^ >CONFIG_SYS_MONITOR_BASE > drivers/usb/host/ohci-hcd.c:2057:35: note: each undeclared identifier is > reported only once for each function it appears in > drivers/usb/host/ohci-hcd.c:2061:20: error: ‘CONFIG_SYS_USB_OHCI_SLOT_NAME’ > undeclared (first use in this function); did you mean > ‘CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS’? > gohci.slot_name = CONFIG_SYS_USB_OHCI_SLOT_NAME; > ^ > CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS > > Signed-off-by: Álvaro Fernández Rojas > --- > include/configs/bmips_bcm6318.h | 2 ++ > include/configs/bmips_bcm63268.h | 2 ++ > include/configs/bmips_bcm6328.h | 2 ++ > include/configs/bmips_bcm6348.h | 2 ++ > include/configs/bmips_bcm6358.h | 2 ++ > include/configs/bmips_bcm6362.h | 2 ++ > include/configs/bmips_bcm6368.h | 2 ++ > 7 files changed, 14 insertions(+) > applied to u-boot-mips, thanks. -- - Daniel
Re: [PATCH] nand: brcmnand: return without disabling clock
Am 02.04.20 um 10:37 schrieb Álvaro Fernández Rojas: > Linux Broadcom NAND driver only disabled clock if no childs are initialized. > This section of the code seems to have been accidentally dropped when it was > imported in U-Boot. > > Signed-off-by: Álvaro Fernández Rojas > --- > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > applied to u-boot-mips, thanks. -- - Daniel
Re: [PATCH 1/2] bootcount: add bootcount flash driver
Am 22.04.20 um 12:46 schrieb Arnaud Ferraris: > In order to save the bootcounter on raw flash device, this commit > introduces a new bootcount driver, enabled using the > CONFIG_BOOTCOUNT_FLASH option. > > The bootcounter is stored at address CONFIG_SYS_BOOTCOUNT_FLASH_ADDR > (absolute address, can also be computed from > CONFIG_SYS_BOOTCOUNT_FLASH_OFFSET), and it uses a data structure > providing several useful enhancements: > - a `flags` field, used to check whether the bootcounter should be >written to flash (similar to the `upgrade_available` environment >variable) > - a `crc` field to ensure integrity of the structure, which will be >used later on when adding redundancy support > - a `data` field, which can be used to store and pass user data >between u-boot and the OS (e.g boot partition selection) > > Signed-off-by: Arnaud Ferraris > --- > > drivers/bootcount/Kconfig | 14 ++ > drivers/bootcount/Makefile | 1 + > drivers/bootcount/bootcount_flash.c | 78 + > include/bootcount.h | 12 + > scripts/config_whitelist.txt| 2 + > 5 files changed, 107 insertions(+) > create mode 100644 drivers/bootcount/bootcount_flash.c > > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig > index 0e506c9ea2..94de3f5ef8 100644 > --- a/drivers/bootcount/Kconfig > +++ b/drivers/bootcount/Kconfig > @@ -66,6 +66,20 @@ config BOOTCOUNT_I2C > CONFIG_SYS_BOOTCOUNT_ADDR = i2c addr which is used for > the bootcounter. > > +config BOOTCOUNT_FLASH > + bool "Boot counter on flash device" > + help > + Store the bootcounter on raw flash. The bootcounter will be stored > + as a structure using one flash sector, and will only be written when > + a specific flag is set in the structure. Additionnally, this driver > + relies on one of the following to be defined: > + > + CONFIG_SYS_BOOTCOUNT_FLASH_ADDR = address used for storing the > + bootcounter on flash. > + or > + CONFIG_SYS_BOOTCOUNT_FLASH_OFFSET = bootcounter offset on flash > + (relative to SYS_FLASH_BASE). > + > config BOOTCOUNT_AT91 > bool "Boot counter for Atmel AT91SAM9XE" > depends on AT91SAM9XE > diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile > index 73ccfb5a08..bddcd136f3 100644 > --- a/drivers/bootcount/Makefile > +++ b/drivers/bootcount/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_BOOTCOUNT_RAM) += bootcount_ram.o > obj-$(CONFIG_BOOTCOUNT_ENV) += bootcount_env.o > obj-$(CONFIG_BOOTCOUNT_I2C) += bootcount_i2c.o > obj-$(CONFIG_BOOTCOUNT_EXT) += bootcount_ext.o > +obj-$(CONFIG_BOOTCOUNT_FLASH)+= bootcount_flash.o > > obj-$(CONFIG_DM_BOOTCOUNT) += bootcount-uclass.o > obj-$(CONFIG_DM_BOOTCOUNT_RTC) += rtc.o > diff --git a/drivers/bootcount/bootcount_flash.c > b/drivers/bootcount/bootcount_flash.c > new file mode 100644 > index 00..1222bb4ae0 > --- /dev/null > +++ b/drivers/bootcount/bootcount_flash.c > @@ -0,0 +1,78 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (c) 2020 Collabora Ltd. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#ifndef CONFIG_SYS_BOOTCOUNT_FLASH_ADDR > +# ifdef CONFIG_SYS_BOOTCOUNT_FLASH_OFFSET > +#define CONFIG_SYS_BOOTCOUNT_FLASH_ADDR \ > + (CONFIG_SYS_FLASH_BASE + CONFIG_SYS_BOOTCOUNT_FLASH_OFFSET) > +# else > +#error "Either CONFIG_SYS_BOOTCOUNT_FLASH_ADDR or " \ > +"CONFIG_SYS_BOOTCOUNT_FLASH_OFFSET should be defined!" > +# endif > +#endif > + > +#define BOOTCOUNT_CRC_SIZE (sizeof(*bootcount) - sizeof(bootcount->crc)) > + > +static struct bootcount *bootcount = (void *)CONFIG_SYS_BOOTCOUNT_ADDR; > +static ulong bc_flash = CONFIG_SYS_BOOTCOUNT_FLASH_ADDR; > +static ulong bc_flash_end = > + CONFIG_SYS_BOOTCOUNT_FLASH_ADDR + CONFIG_SYS_FLASH_SECT_SIZE - 1; > + > +static void bootcount_write(void) > +{ > + if (flash_sect_protect(0, bc_flash, bc_flash_end)) > + return; > + > + puts("Erasing Flash...\n"); > + if (flash_sect_erase(bc_flash, bc_flash_end)) > + return; > + > + puts("Writing bootcount to Flash...\n"); > + if (flash_write((char *)bootcount, bc_flash, sizeof(*bootcount))) > + return; > + > + flash_sect_protect(1, bc_flash, bc_flash_end); Why don't you build this on top of the MTD layer to make it compatible with all flash media types? Nowadays no one uses parallel NOR flash devices anymore ;) Also why don't you continously write new entries until the sector is full? Erasing the sector on every boot kills the flash sector early. > +} > + > +static void bootcount_init(void) > +{ > + memset(bootcount, 0, sizeof(*bootcount)); > + bootcount->magic = CONFIG_SYS_BOOTCOUNT_MAGIC; > + bootcount->crc =
Re: [PATCH 2/7] examples: rename __start to _start on MIPS
+cc Wolfgang, Tom Am 21.04.20 um 00:34 schrieb mho...@freebsd.org: > From: Mitchell Horne > > On MIPS, __start marks the entry point to the CONFIG_API demo program. > Change the name to _start, to be consistent with all other > architectures. > > Signed-off-by: Mitchell Horne > --- > examples/api/crt0.S | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/examples/api/crt0.S b/examples/api/crt0.S > index 57bba9d851..2f75f5a036 100644 > --- a/examples/api/crt0.S > +++ b/examples/api/crt0.S > @@ -42,12 +42,12 @@ syscall: > #elif defined(CONFIG_MIPS) > #include > .text > - .globl __start > - .ent __start > -__start: > + .globl _start > + .ent _start > +_start: > PTR_S $sp, search_hint > b main > - .end __start > + .end _start > > .globl syscall > .ent syscall > __start is used by the default binutils linker script for MIPS. For a test you could simply do a "make malta_defconfig", enable CONFIG_API via menuconfig and build. Without this patch you'll get: $ /opt/gcc-9.2.0-nolibc/mips-linux/bin/mips-linux-readelf -s examples/api/demo | grep __start 64: 8020070016 FUNCGLOBAL DEFAULT1 __start But with this patch __start will now an unresolved symbol: $ /opt/gcc-9.2.0-nolibc/mips-linux/bin/mips-linux-readelf -s examples/api/demo | grep __start 19: 0 NOTYPE GLOBAL DEFAULT UND __start But I'm not sure if the original intention was to use the default linker script or the one provided by U-Boot and if examples/api/ should use the same compiler and linker flags as example/standalone/. Some archs have used a custom linker script. Maybe Wolfgang knows more? -- - Daniel
Re: [PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu
On Thursday 23 April 2020 08:24:05 Tom Rini wrote: > On Thu, Apr 23, 2020 at 09:34:26AM +0200, Pali Rohár wrote: > > On Tuesday 21 April 2020 19:24:57 Tom Rini wrote: > > > On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Rohár wrote: > > > > Ok, so is something needed to do with this patch? > > > > > > Yes, re-order where the .travis.yml hunk is and add a similar part to > > > .gitlab-ci.yml and .azure-ci.yml. > > > > Hello Tom! I have looked at .travis.yml again, but I do not understand > > what do you mean by re-order. I really have no idea where you want to > > move that rx51_test.sh hunk. Could you describe it? > > This should go around where we check tools-only/envtools. Thanks! Thank you, now I figured out. I will send V2 of this one patch.
Re: [PATCH 3/3] spi: sifive: Fix format register proto field
Hi Sagar and Bin, On Tue, Apr 21, 2020 at 9:17 PM Sagar Kadam wrote: > > Hi Bin, Jagan, > > Thanks Jagan for posting the patches to enable QUAD SPI-NOR on HiFive > Unleashed > along with other sequels. > > > -Original Message- > > From: Bin Meng > > Sent: Tuesday, April 21, 2020 4:44 AM > > To: Jagan Teki > > Cc: Vignesh R ; U-Boot Mailing List > b...@lists.denx.de>; Suneel Garapati ; Sagar > > Kadam ; Bhargav Shah > > ; Simon Glass ; Tom > > Rini ; linux-amarula > amar...@amarulasolutions.com> > > Subject: Re: [PATCH 3/3] spi: sifive: Fix format register proto field > > > > [External Email] Do not click links or attachments unless you recognize the > > sender and know the content is safe > > > > On Mon, Apr 20, 2020 at 8:09 PM Jagan Teki > > wrote: > > > > > > SiFive SPI controller has a proto bit field in frame format register > > > which would be used to configure the SPI I/O protocol lines used on > > > specific transfer. > > > > > > Right now the driver is configuring this proto using slave->mode which > > > is used for data transfer and opcode, address vary depending on the > > > particular transfer at runtime. > > > > > > Now the SPI framework supports per transfer I/O protocol lines, so use > > > spi->proto instead of slave-mode. > > > > > > Signed-off-by: Jagan Teki > > > --- > > > drivers/spi/spi-sifive.c | 11 --- > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > > > > > This patch does not apply on top of u-boot/master. > > > > Please rebase and resend. > > I guess Bin, you will also have to add following two patch series [1] and [2] > before this set. > I tested this and other series with following dependency chain over > u-boot/master(e4837da7828293ea49abc579f939c0f5c4b127c3) > > 1> 1-2-mtd-spi-nor-Enable-QE-bit-for-ISSI-flash.patch > 2> spi-sifive-Tidy-up-dm_spi_slave_platdata-variable.patch > 3> spi: Support SPI I/O protocol lines > 4> riscv: sifive/fu540: Enable SPI-NOR support > > I could verify flash erase/read/write operations along with mmc spi. Send the v4 w/o any dependencies, but on top of u-boot-spi/master tree. I/O protocol changes are now handled in spi-sifive via spi-mem exec_op for now since the actual generic code patch[3] will take some time to be in ML as it affects all platforms. Please have a test at earliest. [3] https://patchwork.ozlabs.org/project/uboot/patch/20200420120921.12840-2-ja...@amarulasolutions.com/ Jagan.
[PATCH v4 5/5] sifive: fu540: Enable spi-nor flash support
HiFive Unleashed A00 support is25wp256 spi-nor flash, So enable the same and add test result log for future reference. Tested on SiFive FU540 board. Signed-off-by: Jagan Teki Reviewed-by: Bin Meng --- Changes for v4: - none arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 1 + board/sifive/fu540/Kconfig | 3 +++ 2 files changed, 4 insertions(+) diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi index 8a784b5661..2aebfab646 100644 --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi @@ -5,6 +5,7 @@ / { aliases { + spi0 = spi2 = }; }; diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index 5ca21474de..75661f35f8 100644 --- a/board/sifive/fu540/Kconfig +++ b/board/sifive/fu540/Kconfig @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply CMD_FS_GENERIC imply CMD_NET imply CMD_PING + imply CMD_SF imply CLK_SIFIVE imply CLK_SIFIVE_FU540_PRCI imply DOS_PARTITION @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply SIFIVE_SERIAL imply SPI imply SPI_SIFIVE + imply SPI_FLASH + imply SPI_FLASH_ISSI imply MMC imply MMC_SPI imply MMC_BROKEN_CD -- 2.17.1
[PATCH v4 3/5] spi: sifive: Fix QPP transfer
The guessed reason is that the existing logic of filling tx fifo with data, rx fifo with NULL for tx transfer and filling rx fifo with data, tx fifo with NULL for rx transfer is not clear enough to support the Quad Page Program. SiFive SPI controllers have specific sets of watermark registers and SPI I/O directions bits in order to program SPI controllers clear enough to support all sets of operating modes. Here is the exact programing sequence that would follow on this patch and tested via SPI-NOR and MMC_SPI. - set the frame format proto, endian - set the frame format dir, set it for tx and clear it for rx - TX transfer: fill tx fifo with data. wait for TX watermark bit to clear. - RX transfer: fill tx fifo with 0xff. write nbytes to rx watermark register wait for rx watermark bit to clear. read the rx fifo data. So, this patch adopts this program sequence and fixes the existing I/O direction bit. Cc: Vignesh R Signed-off-by: Jagan Teki --- Changes for v4: - update commit message drivers/spi/spi-sifive.c | 57 ++-- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c index 0ea4930a0a..4cab0391f7 100644 --- a/drivers/spi/spi-sifive.c +++ b/drivers/spi/spi-sifive.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -134,8 +135,8 @@ static void sifive_spi_clear_cs(struct sifive_spi *spi) } static void sifive_spi_prep_transfer(struct sifive_spi *spi, -bool is_rx_xfer, -struct dm_spi_slave_platdata *slave_plat) +struct dm_spi_slave_platdata *slave_plat, +u8 *rx_ptr) { u32 cr; @@ -167,7 +168,7 @@ static void sifive_spi_prep_transfer(struct sifive_spi *spi, /* SPI direction in/out ? */ cr &= ~SIFIVE_SPI_FMT_DIR; - if (!is_rx_xfer) + if (!rx_ptr) cr |= SIFIVE_SPI_FMT_DIR; writel(cr, spi->regs + SIFIVE_SPI_REG_FMT); @@ -198,13 +199,19 @@ static void sifive_spi_tx(struct sifive_spi *spi, const u8 *tx_ptr) writel(tx_data, spi->regs + SIFIVE_SPI_REG_TXDATA); } +static int sifive_spi_wait(struct sifive_spi *spi, u32 bit) +{ + return wait_for_bit_le32(spi->regs + SIFIVE_SPI_REG_IP, +bit, true, 100, false); +} + static int sifive_spi_xfer(struct udevice *dev, unsigned int bitlen, const void *dout, void *din, unsigned long flags) { struct udevice *bus = dev->parent; struct sifive_spi *spi = dev_get_priv(bus); struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev); - const unsigned char *tx_ptr = dout; + const u8 *tx_ptr = dout; u8 *rx_ptr = din; u32 remaining_len; int ret; @@ -217,31 +224,37 @@ static int sifive_spi_xfer(struct udevice *dev, unsigned int bitlen, return ret; } - sifive_spi_prep_transfer(spi, true, slave_plat); + sifive_spi_prep_transfer(spi, slave_plat, rx_ptr); remaining_len = bitlen / 8; while (remaining_len) { - int n_words, tx_words, rx_words; - - n_words = min(remaining_len, spi->fifo_depth); + unsigned int n_words = min(remaining_len, spi->fifo_depth); + unsigned int tx_words, rx_words; /* Enqueue n_words for transmission */ - if (tx_ptr) { - for (tx_words = 0; tx_words < n_words; ++tx_words) { - sifive_spi_tx(spi, tx_ptr); - sifive_spi_rx(spi, NULL); - tx_ptr++; - } + for (tx_words = 0; tx_words < n_words; tx_words++) { + if (!tx_ptr) + sifive_spi_tx(spi, NULL); + else + sifive_spi_tx(spi, tx_ptr++); } - /* Read out all the data from the RX FIFO */ if (rx_ptr) { - for (rx_words = 0; rx_words < n_words; ++rx_words) { - sifive_spi_tx(spi, NULL); - sifive_spi_rx(spi, rx_ptr); - rx_ptr++; - } + /* Wait for transmission + reception to complete */ + writel(n_words - 1, spi->regs + SIFIVE_SPI_REG_RXMARK); + ret = sifive_spi_wait(spi, SIFIVE_SPI_IP_RXWM); + if (ret) + return ret; + + /* Read out all the data from the RX FIFO */ + for (rx_words = 0; rx_words < n_words; rx_words++) + sifive_spi_rx(spi,
[PATCH v4 2/5] spi: sifive: Fix format register proto field
SiFive SPI controller has a proto bit field in frame format register which would be used to configure the SPI I/O protocol lines used on specific transfer. Right now the driver is configuring this proto using slave->mode, for all types of transctions. This makes the driver unable to function since the proto needs to configure dynamically for each and every transaction separately at runtime. Now, the controller driver supports per transfer via spi-mem exec_opo, so add the fmt_proto flag and fill the per transfer buswidth so that the controller configures the proto bit at runtime. This patch fixes the SPI controller works with SPI NOR flash on quad read with page program. Cc: Vignesh R Signed-off-by: Jagan Teki --- Changes for v4: - new patch drivers/spi/spi-sifive.c | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c index 5e612edcff..0ea4930a0a 100644 --- a/drivers/spi/spi-sifive.c +++ b/drivers/spi/spi-sifive.c @@ -86,6 +86,11 @@ #define SIFIVE_SPI_IP_TXWM BIT(0) #define SIFIVE_SPI_IP_RXWM BIT(1) +/* format protocol */ +#define SIFIVE_SPI_PROTO_QUAD 4 /* 4 lines I/O protocol transfer */ +#define SIFIVE_SPI_PROTO_DUAL 2 /* 2 lines I/O protocol transfer */ +#define SIFIVE_SPI_PROTO_SINGLE1 /* 1 line I/O protocol transfer */ + struct sifive_spi { void*regs; /* base address of the registers */ u32 fifo_depth; @@ -93,6 +98,7 @@ struct sifive_spi { u32 cs_inactive;/* Level of the CS pins when inactive*/ u32 freq; u32 num_cs; + u8 fmt_proto; }; static void sifive_spi_prep_device(struct sifive_spi *spi, @@ -147,12 +153,17 @@ static void sifive_spi_prep_transfer(struct sifive_spi *spi, /* Number of wires ? */ cr &= ~SIFIVE_SPI_FMT_PROTO_MASK; - if ((slave_plat->mode & SPI_TX_QUAD) || (slave_plat->mode & SPI_RX_QUAD)) + switch (spi->fmt_proto) { + case SIFIVE_SPI_PROTO_QUAD: cr |= SIFIVE_SPI_FMT_PROTO_QUAD; - else if ((slave_plat->mode & SPI_TX_DUAL) || (slave_plat->mode & SPI_RX_DUAL)) + break; + case SIFIVE_SPI_PROTO_DUAL: cr |= SIFIVE_SPI_FMT_PROTO_DUAL; - else + break; + default: cr |= SIFIVE_SPI_FMT_PROTO_SINGLE; + break; + } /* SPI direction in/out ? */ cr &= ~SIFIVE_SPI_FMT_DIR; @@ -246,6 +257,7 @@ static int sifive_spi_exec_op(struct spi_slave *slave, const struct spi_mem_op *op) { struct udevice *dev = slave->dev; + struct sifive_spi *spi = dev_get_priv(dev->parent); unsigned long flags = SPI_XFER_BEGIN; u8 opcode = op->cmd.opcode; unsigned int pos = 0; @@ -257,6 +269,8 @@ static int sifive_spi_exec_op(struct spi_slave *slave, if (!op->addr.nbytes && !op->dummy.nbytes && !op->data.nbytes) flags |= SPI_XFER_END; + spi->fmt_proto = op->cmd.buswidth; + /* send the opcode */ ret = sifive_spi_xfer(dev, 8, (void *), NULL, flags); if (ret < 0) { @@ -284,6 +298,8 @@ static int sifive_spi_exec_op(struct spi_slave *slave, if (!op->data.nbytes) flags |= SPI_XFER_END; + spi->fmt_proto = op->addr.buswidth; + ret = sifive_spi_xfer(dev, op_len * 8, op_buf, NULL, flags); if (ret < 0) { dev_err(dev, "failed to xfer addr + dummy\n"); @@ -298,6 +314,8 @@ static int sifive_spi_exec_op(struct spi_slave *slave, else tx_buf = op->data.buf.out; + spi->fmt_proto = op->data.buswidth; + ret = sifive_spi_xfer(dev, op->data.nbytes * 8, tx_buf, rx_buf, SPI_XFER_END); if (ret) { -- 2.17.1
[PATCH v4 4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi
Add U-Boot specific dts file for hifive-unleashed-a00, this would help to add u-boot specific properties and other node changes without touching the base dts(i) files which are easy to sync from Linux. Added spi2 alias for qspi2 as an initial u-boot specific property change. spi probing in current dm model is very much rely on aliases numbering. Even though the qspi2 can't come under any associated spi nor flash it would require to specify the same to make proper binding happen for other spi slaves. Signed-off-by: Jagan Teki Reviewed-by: Bin Meng --- Changes for v4: - update licence arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi new file mode 100644 index 00..8a784b5661 --- /dev/null +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi @@ -0,0 +1,10 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2019 Jagan Teki + */ + +/ { + aliases { + spi2 = + }; +}; -- 2.17.1
[PATCH v4 1/5] spi: sifive: Add spi-mem exec op
SiFive SPI controller is responsible to handle the slave devices like mmc spi and spi nor flash. The controller is designed such a way that it would handle the slave transactions based on the I/O protocol numbers, example if spi nor slave send quad write opcode it has to send alone with I/O protocol number of 4 and if it try to send data it has to send I/O protocol number along with 4 line data. But the current spi-xfer code from spi-mem is combining the opcode and address in a single transaction, so the SPI controller will be unable to identify the I/O protocol number of opcode vs address. So, add the spi-mem exec_op with spi-xfer of opcode, address and data as a separate transaction. This doesn't remove the .xfer of dm_spi_ops since mmc spi will make use of it. Note: This code might have moved to the spi-mem core area once we have done the dedicated tests on other controllers and have real reason to move. Cc: Vignesh R Signed-off-by: Jagan Teki --- Changes for v4: - new patch drivers/spi/spi-sifive.c | 75 +++- 1 file changed, 74 insertions(+), 1 deletion(-) diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c index 8f5efb51a3..5e612edcff 100644 --- a/drivers/spi/spi-sifive.c +++ b/drivers/spi/spi-sifive.c @@ -8,8 +8,9 @@ #include #include +#include #include -#include +#include #include #include #include @@ -241,6 +242,73 @@ static int sifive_spi_xfer(struct udevice *dev, unsigned int bitlen, return 0; } +static int sifive_spi_exec_op(struct spi_slave *slave, + const struct spi_mem_op *op) +{ + struct udevice *dev = slave->dev; + unsigned long flags = SPI_XFER_BEGIN; + u8 opcode = op->cmd.opcode; + unsigned int pos = 0; + const void *tx_buf = NULL; + void *rx_buf = NULL; + int op_len, i; + int ret; + + if (!op->addr.nbytes && !op->dummy.nbytes && !op->data.nbytes) + flags |= SPI_XFER_END; + + /* send the opcode */ + ret = sifive_spi_xfer(dev, 8, (void *), NULL, flags); + if (ret < 0) { + dev_err(dev, "failed to xfer opcode\n"); + return ret; + } + + op_len = op->addr.nbytes + op->dummy.nbytes; + u8 op_buf[op_len]; + + /* send the addr + dummy */ + if (op->addr.nbytes) { + /* fill address */ + for (i = 0; i < op->addr.nbytes; i++) + op_buf[pos + i] = op->addr.val >> + (8 * (op->addr.nbytes - i - 1)); + + pos += op->addr.nbytes; + + /* fill dummy */ + if (op->dummy.nbytes) + memset(op_buf + pos, 0xff, op->dummy.nbytes); + + /* make sure to set end flag, if no data bytes */ + if (!op->data.nbytes) + flags |= SPI_XFER_END; + + ret = sifive_spi_xfer(dev, op_len * 8, op_buf, NULL, flags); + if (ret < 0) { + dev_err(dev, "failed to xfer addr + dummy\n"); + return ret; + } + } + + /* send/received the data */ + if (op->data.nbytes) { + if (op->data.dir == SPI_MEM_DATA_IN) + rx_buf = op->data.buf.in; + else + tx_buf = op->data.buf.out; + + ret = sifive_spi_xfer(dev, op->data.nbytes * 8, + tx_buf, rx_buf, SPI_XFER_END); + if (ret) { + dev_err(dev, "failed to xfer data\n"); + return ret; + } + } + + return 0; +} + static int sifive_spi_set_speed(struct udevice *bus, uint speed) { struct sifive_spi *spi = dev_get_priv(bus); @@ -348,11 +416,16 @@ static int sifive_spi_probe(struct udevice *bus) return 0; } +static const struct spi_controller_mem_ops sifive_spi_mem_ops = { + .exec_op= sifive_spi_exec_op, +}; + static const struct dm_spi_ops sifive_spi_ops = { .xfer = sifive_spi_xfer, .set_speed = sifive_spi_set_speed, .set_mode = sifive_spi_set_mode, .cs_info= sifive_spi_cs_info, + .mem_ops= _spi_mem_ops, }; static const struct udevice_id sifive_spi_ids[] = { -- 2.17.1
[PATCH v4 0/5] riscv: sifive/fu540: Enable SPI-NOR support
This is series v4 for SPI-NOR support on SiFive FU540 platform with HiFive Unleashed board. Here is the previous version changes[1]. All patches on top of u-boot-spi/master. Changes for v4: - add spi-mem exec_op - rebase on master Changes for v3: - fixed QPP support - dropped sf commands log [1] https://patchwork.ozlabs.org/project/uboot/cover/20200420125238.9610-1-ja...@amarulasolutions.com/ Any inputs? Jagan. Jagan Teki (5): spi: sifive: Add spi-mem exec op spi: sifive: Fix format register proto field spi: sifive: Fix QPP transfer riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi sifive: fu540: Enable spi-nor flash support .../dts/hifive-unleashed-a00-u-boot.dtsi | 11 ++ board/sifive/fu540/Kconfig| 3 + drivers/spi/spi-sifive.c | 156 +++--- 3 files changed, 146 insertions(+), 24 deletions(-) create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi -- 2.17.1
RE: [PATCH] arm64: dts: ls1046ardb: Set aqr106 phy mode to usxgmii
> -Original Message- > From: Sascha Hauer > Sent: Thursday, April 23, 2020 1:22 PM > To: linux-arm-ker...@lists.infradead.org > Cc: Madalin Bucur ; Shawn Guo > ; Leo Li ; Sascha Hauer > > Subject: [PATCH] arm64: dts: ls1046ardb: Set aqr106 phy mode to usxgmii > > The AQR107 family of phy devices do not support xgmii, but usxgmii > instead. Since ce64c1f77a9d ("net: phy: aquantia: add USXGMII support > and warn if XGMII mode is set") the kernel warns about xgmii being > used. Change device tree to usxgmii. > > Signed-off-by: Sascha Hauer > --- > arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts > b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts > index d53ccc56bb63..02fbef92b96a 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts > @@ -151,7 +151,7 @@ ethernet@ea000 { > > ethernet@f { /* 10GEC1 */ > phy-handle = <_phy>; > - phy-connection-type = "xgmii"; > + phy-connection-type = "usxgmii"; > }; > > ethernet@f2000 { /* 10GEC2 */ > -- > 2.26.1 Hi Sascha, thank you for trying to correct this problem. Unfortunately "usxgmii" here is incorrect too, as that mode is not supported by the LS1046A SoC. The connection mode used, as documented by the SoC and PHY datasheets, is XFI. Unfortunately there was resistance against including this connection type in the list supported by the kernel (please note the distinction between connection type and connection mode). At a certain moment the two were aliased and the kernel uses connection mode, not connection type. While we should describe here the hardware, the board connection type (XFI), in the kernel the connection mode was lately preferred (10G-BaseR). So, today we cannot use "xfi" here, as the hardware description property should read. The closest thing we can use is "10gbase-r". Unfortunately, in u-boot support for "xfi" is already in place [1] and the device tree should be different for the two for this reason - this goes against the spirit of the device tree that should not depend on the software using it... I had on my agenda to fix this problem, had to stop when "xfi" was rejected, at the time not even "10gbase-r" was an option. Also worth noting here is that, while we change "xgmii" to a correct/better value, we should also tolerate the old variant, as there are users in the wild unable/unwilling to update the device tree and backwards compatibility should be ensured, further complicating the matter. Regards, Madalin [1] I mention u-boot here because it's the default boot loader used by LS1046ARDB and there are some interdependences with it, making things even more complicated than they seem: u-boot currently performs a fix-up for this device tree field, based on RCW (reset configuration word), resulting in an override of the value provided to the booting kernel. Some relevant u-boot commits: https://github.com/u-boot/u-boot/commit/17285fc2833e0db04a2bd3d411cdf1a3e387de83 https://github.com/u-boot/u-boot/commit/8a141d6e9cc1841082e4c996703eafb037ec63ad
[PATCH v2 2/2] pwm: Add PWM driver for SiFive SoC
Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC This driver is simple port of Linux pwm sifive driver from Linux v5.6 commit: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Signed-off-by: Yash Shah --- drivers/pwm/Kconfig | 6 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 172 +++ 3 files changed, 179 insertions(+) create mode 100644 drivers/pwm/pwm-sifive.c diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 1f36fc7..d6ea9ee 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -40,6 +40,12 @@ config PWM_SANDBOX useful. The PWM can be enabled but is not connected to any outputs so this is not very useful. +config PWM_SIFIVE + bool "Enable support for SiFive PWM" + depends on DM_PWM + help + This PWM is found SiFive's FU540 and other SoCs. + config PWM_TEGRA bool "Enable support for the Tegra PWM" depends on DM_PWM diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile index a837c35..c2c7fce 100644 --- a/drivers/pwm/Makefile +++ b/drivers/pwm/Makefile @@ -14,5 +14,6 @@ obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o obj-$(CONFIG_PWM_SANDBOX) += sandbox_pwm.o +obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o obj-$(CONFIG_PWM_TEGRA)+= tegra_pwm.o obj-$(CONFIG_PWM_SUNXI)+= sunxi_pwm.o diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c new file mode 100644 index 000..77bc659 --- /dev/null +++ b/drivers/pwm/pwm-sifive.c @@ -0,0 +1,172 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 SiFive, Inc + * For SiFive's PWM IP block documentation please refer Chapter 14 of + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf + * + * Limitations: + * - When changing both duty cycle and period, we cannot prevent in + * software that the output might produce a period with mixed + * settings (new period length and old duty cycle). + * - The hardware cannot generate a 100% duty cycle. + * - The hardware generates only inverted output. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* PWMCFG fields */ +#define PWM_SIFIVE_PWMCFG_SCALE GENMASK(3, 0) +#define PWM_SIFIVE_PWMCFG_STICKYBIT(8) +#define PWM_SIFIVE_PWMCFG_ZERO_CMP BIT(9) +#define PWM_SIFIVE_PWMCFG_DEGLITCH BIT(10) +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS BIT(12) +#define PWM_SIFIVE_PWMCFG_EN_ONCE BIT(13) +#define PWM_SIFIVE_PWMCFG_CENTERBIT(16) +#define PWM_SIFIVE_PWMCFG_GANG BIT(24) +#define PWM_SIFIVE_PWMCFG_IPBIT(28) + +/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */ +#define PWM_SIFIVE_SIZE_PWMCMP 4 +#define PWM_SIFIVE_CMPWIDTH 16 + +DECLARE_GLOBAL_DATA_PTR; + +struct pwm_sifive_regs { + unsigned long cfg; + unsigned long cnt; + unsigned long pwms; + unsigned long cmp0; +}; + +struct pwm_sifive_data { + struct pwm_sifive_regs regs; +}; + +struct pwm_sifive_priv { + void __iomem *base; + ulong freq; + const struct pwm_sifive_data *data; +}; + +static int pwm_sifive_set_config(struct udevice *dev, uint channel, +uint period_ns, uint duty_ns) +{ + struct pwm_sifive_priv *priv = dev_get_priv(dev); + const struct pwm_sifive_regs *regs = >data->regs; + unsigned long scale_pow; + unsigned long long num; + u32 scale, val = 0, frac; + + debug("%s: period_ns=%u, duty_ns=%u\n", __func__, period_ns, duty_ns); + + /* +* The PWM unit is used with pwmzerocmp=0, so the only way to modify the +* period length is using pwmscale which provides the number of bits the +* counter is shifted before being feed to the comparators. A period +* lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks. +* (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period +*/ + scale_pow = lldiv((uint64_t)priv->freq * period_ns, 10); + scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf); + val |= FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale); + + /* +* The problem of output producing mixed setting as mentioned at top, +* occurs here. To minimize the window for this problem, we are +* calculating the register values first and then writing them +* consecutively +*/ + num = (u64)duty_ns * (1U << PWM_SIFIVE_CMPWIDTH); + frac = DIV_ROUND_CLOSEST_ULL(num, period_ns); + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); + + writel(val, priv->base + regs->cfg); + writel(frac, priv->base + regs->cmp0 + channel * + PWM_SIFIVE_SIZE_PWMCMP); + + return 0;
[PATCH v2 1/2] pwm: Add DT documentation for SiFive PWM Controller
DT documentation for PWM controller added from Linux v5.6 commit: daa78cc3408e ("pwm: sifive: Add DT documentation for SiFive PWM Controller") Signed-off-by: Yash Shah --- doc/device-tree-bindings/pwm/pwm-sifive.txt | 31 + 1 file changed, 31 insertions(+) create mode 100644 doc/device-tree-bindings/pwm/pwm-sifive.txt diff --git a/doc/device-tree-bindings/pwm/pwm-sifive.txt b/doc/device-tree-bindings/pwm/pwm-sifive.txt new file mode 100644 index 000..9a98837 --- /dev/null +++ b/doc/device-tree-bindings/pwm/pwm-sifive.txt @@ -0,0 +1,31 @@ +SiFive PWM controller + +Unlike most other PWM controllers, the SiFive PWM controller currently only +supports one period for all channels in the PWM. All PWMs need to run at +the same period. The period also has significant restrictions on the values +it can achieve, which the driver rounds to the nearest achievable period. +PWM RTL that corresponds to the IP block version numbers can be found +here: + +https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm + +Required properties: +- compatible: Should be "sifive,-pwm" and "sifive,pwm". + Supported compatible strings are: "sifive,fu540-c000-pwm" for the SiFive + PWM v0 as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the + SiFive PWM v0 IP block with no chip integration tweaks. +- reg: physical base address and length of the controller's registers +- clocks: Should contain a clock identifier for the PWM's parent clock. +- #pwm-cells: Should be 3. +- interrupts: one interrupt per PWM channel + +Examples: + +pwm: pwm@1002 { + compatible = "sifive,fu540-c000-pwm", "sifive,pwm0"; + reg = <0x0 0x1002 0x0 0x1000>; + clocks = <>; + interrupt-parent = <>; + interrupts = <42 43 44 45>; + #pwm-cells = <3>; +}; -- 2.7.4
[PATCH v2 0/2] Add support for PWM SiFive
The patch series adds support for PWM controller in SiFive SoCs Changes in v2: - Introduce a new patch to add the DT documentation - Change commit message to include reference of Linux ver and commit - Remove unnecessary function "pwm_sifive_set_invert" - Use "dev_read_addr_ptr" instead of "dev_read_addr" to avoid cast on each readl/writel call Yash Shah (2): pwm: Add DT documentation for SiFive PWM Controller pwm: Add PWM driver for SiFive SoC doc/device-tree-bindings/pwm/pwm-sifive.txt | 31 + drivers/pwm/Kconfig | 6 + drivers/pwm/Makefile| 1 + drivers/pwm/pwm-sifive.c| 172 4 files changed, 210 insertions(+) create mode 100644 doc/device-tree-bindings/pwm/pwm-sifive.txt create mode 100644 drivers/pwm/pwm-sifive.c -- 2.7.4
[PATCH] cmd: cache: Fix non-cached memory cachability
If dcache is switched OFF to ON state and if non-cached memory is used, this non-cached memory must be re-declared as uncached to mmu each time dcache is set ON. Issue found on STM32MP1 platform using dwc_eth_qos ethernet driver, when going from dcache OFF to dcache ON state, ethernet driver issued TX timeout errors when performing dhcp or ping. It can be reproduced with the following sequence: dhcp while true ; do ping 192.168.1.300 ; dcache off ; ping 192.168.1.300 ; dcache on ; done Signed-off-by: Patrice Chotard Cc: Marek Vasut Cc: Joe Hershberger Cc: Ramon Fried Cc: Stephen Warren --- arch/arm/include/asm/system.h | 1 + arch/arm/lib/cache.c | 13 ++--- cmd/cache.c | 3 +++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h index 81ccead112..06fb458301 100644 --- a/arch/arm/include/asm/system.h +++ b/arch/arm/include/asm/system.h @@ -584,6 +584,7 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size, #ifdef CONFIG_SYS_NONCACHED_MEMORY void noncached_init(void); +void noncached_set_region(void); phys_addr_t noncached_alloc(size_t size, size_t align); #endif /* CONFIG_SYS_NONCACHED_MEMORY */ diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c index 007d4ebc49..7f3cfb407c 100644 --- a/arch/arm/lib/cache.c +++ b/arch/arm/lib/cache.c @@ -73,6 +73,15 @@ static unsigned long noncached_start; static unsigned long noncached_end; static unsigned long noncached_next; +void noncached_set_region(void) +{ +#if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) + mmu_set_region_dcache_behaviour(noncached_start, + noncached_end - noncached_start, + DCACHE_OFF); +#endif +} + void noncached_init(void) { phys_addr_t start, end; @@ -89,9 +98,7 @@ void noncached_init(void) noncached_end = end; noncached_next = start; -#if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) - mmu_set_region_dcache_behaviour(noncached_start, size, DCACHE_OFF); -#endif + noncached_set_region(); } phys_addr_t noncached_alloc(size_t size, size_t align) diff --git a/cmd/cache.c b/cmd/cache.c index 27dcec0931..86fbaf8dd6 100644 --- a/cmd/cache.c +++ b/cmd/cache.c @@ -64,6 +64,9 @@ static int do_dcache(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) break; case 1: dcache_enable(); +#ifdef CONFIG_SYS_NONCACHED_MEMORY + noncached_set_region(); +#endif break; case 2: flush_dcache_all(); -- 2.17.1
RE: [PATCH] configs: ls1021a: Append CMA configuration to bootargs
Hi, Priyanka, > -Original Message- > From: Priyanka Jain > Sent: Thursday, April 23, 2020 6:32 PM > To: Alison Wang ; u-boot@lists.denx.de; Jagdish > Gediya > Cc: Shengzhou Liu > Subject: RE: [PATCH] configs: ls1021a: Append CMA configuration to bootargs > > >-Original Message- > >From: Alison Wang > >Sent: Thursday, April 23, 2020 6:12 AM > >To: u-boot@lists.denx.de; Priyanka Jain ; > >Jagdish Gediya > >Cc: Shengzhou Liu > >Subject: [PATCH] configs: ls1021a: Append CMA configuration to bootargs > > > >According to commit , this patch appends CMA > >configuration to bootargs for LS1021ATWR. > > > Please mention what this patch is doing (as a fresh patch). > No need to mention relation with previous commit. [Alison] Update the comment in v2. Best Regards, Alison Wang
[PATCH v2] configs: ls1021a: Append CMA configuration to bootargs
The default reserved memory for CMA is high memory. If LPAE is enabled, highmem pages are non-remapped and can not be used with dma_alloc_coherent. Reserving low memory for CMA is needed for LS1021A. This patch appends the related CMA configuration to bootargs. Signed-off-by: Shengzhou Liu Signed-off-by: Alison Wang --- Change in v2: - Update the comment. include/configs/ls1021atwr.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index a6289850ca..45ce460dca 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -297,7 +297,8 @@ #ifdef CONFIG_LPUART #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootargs=root=/dev/ram0 rw console=ttyLP0,115200 $othbootargs\0" \ + "bootargs=root=/dev/ram0 rw console=ttyLP0,115200 " \ + "cma=64M@0x0-0xb000\0" \ "initrd_high=0x\0" \ "fdt_addr=0x64f0\0" \ "kernel_addr=0x6500\0" \ @@ -353,7 +354,8 @@ "$kernel_size && bootm $load_addr#$board\0" #else #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootargs=root=/dev/ram0 rw console=ttyS0,115200 $othbootargs\0" \ + "bootargs=root=/dev/ram0 rw console=ttyS0,115200 " \ + "cma=64M@0x0-0xb000\0" \ "initrd_high=0x\0" \ "fdt_addr=0x64f0\0" \ "kernel_addr=0x6100\0" \ -- 2.17.1
Re: [PATCH 7/7] api: enumerate virtio-blk devices
On Tue, Apr 21, 2020 at 7:29 AM wrote: > > From: Mitchell Horne > > API clients can make a syscall requesting the enumeration of network and > storage devices. However, this does not check for virtio-blk storage > devices, which API consumers may wish to use. Add the support to > enumerate these devices as well. > > Signed-off-by: Mitchell Horne > --- > api/api_storage.c| 14 +- > include/api_public.h | 1 + > 2 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/api/api_storage.c b/api/api_storage.c > index 7ae03ac230..866c82d7ec 100644 > --- a/api/api_storage.c > +++ b/api/api_storage.c > @@ -30,7 +30,8 @@ > #define ENUM_SCSI 2 > #define ENUM_MMC 3 > #define ENUM_SATA 4 > -#define ENUM_MAX 5 > +#define ENUM_VIRTIO5 > +#define ENUM_MAX 6 > > struct stor_spec { > int max_dev; > @@ -46,6 +47,10 @@ static struct stor_spec specs[ENUM_MAX] = { { 0, 0, 0, 0, > NULL }, }; > #define CONFIG_SYS_MMC_MAX_DEVICE 1 > #endif > > +#ifndef CONFIG_SYS_VIRTIO_BLK_MAX_DEVICE > +#define CONFIG_SYS_VIRTIO_BLK_MAX_DEVICE 1 At some time we need turn all these macros to Kconfig options in this file. > +#endif > + > void dev_stor_init(void) > { > #if defined(CONFIG_IDE) > @@ -83,6 +88,13 @@ void dev_stor_init(void) > specs[ENUM_USB].type = DEV_TYP_STOR | DT_STOR_USB; > specs[ENUM_USB].name = "usb"; > #endif > +#if defined(CONFIG_VIRTIO_BLK) > + specs[ENUM_VIRTIO].max_dev = CONFIG_SYS_VIRTIO_BLK_MAX_DEVICE; > + specs[ENUM_VIRTIO].enum_started = 0; > + specs[ENUM_VIRTIO].enum_ended = 0; > + specs[ENUM_VIRTIO].type = DEV_TYP_STOR | DT_STOR_VIRTIO; > + specs[ENUM_VIRTIO].name = "virtio"; > +#endif > } > > /* > diff --git a/include/api_public.h b/include/api_public.h > index def103ce22..1f9ff49b0b 100644 > --- a/include/api_public.h > +++ b/include/api_public.h > @@ -87,6 +87,7 @@ typedef unsigned long lbastart_t; > #define DT_STOR_USB0x0040 > #define DT_STOR_MMC0x0080 > #define DT_STOR_SATA 0x0100 > +#define DT_STOR_VIRTIO 0x0200 > > #define DEV_STA_CLOSED 0x /* invalid, closed */ > #define DEV_STA_OPEN 0x0001 /* open i.e. active */ Reviewed-by: Bin Meng
Re: [PATCH 6/7] riscv: add CONFIG_API support
On Tue, Apr 21, 2020 at 6:35 AM wrote: > > From: Mitchell Horne > > Add the necessary changes to allow building the CONFIG_API option on the > RISC-V architecture. The downstream consumer of this API is the u-boot > version of FreeBSD's loader(8). This enables the loader to be ported to Could you please include a URL for FreeBSD's loader(8)? > RISC-V. > > Signed-off-by: Mitchell Horne > Cc: r...@andestech.com > Cc: bmeng...@gmail.com > Cc: atish.pa...@wdc.com > --- > api/Makefile | 1 + > api/api_platform-riscv.c | 33 + > examples/api/Makefile| 3 +++ > examples/api/crt0.S | 15 +++ > 4 files changed, 52 insertions(+) > create mode 100644 api/api_platform-riscv.c > > diff --git a/api/Makefile b/api/Makefile > index bd2d035fcd..737854e2c6 100644 > --- a/api/Makefile > +++ b/api/Makefile > @@ -6,3 +6,4 @@ obj-y += api.o api_display.o api_net.o api_storage.o > obj-$(CONFIG_ARM) += api_platform-arm.o > obj-$(CONFIG_PPC) += api_platform-powerpc.o > obj-$(CONFIG_MIPS) += api_platform-mips.o > +obj-$(CONFIG_RISCV) += api_platform-riscv.o > diff --git a/api/api_platform-riscv.c b/api/api_platform-riscv.c > new file mode 100644 > index 00..33a56535f3 > --- /dev/null > +++ b/api/api_platform-riscv.c > @@ -0,0 +1,33 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * (C) Copyright 2007 Stanislav Galabov > + * > + * This file contains routines that fetch data from bd_info sources > + */ > + > +#include > +#include > +#include > + > +#include > +#include > + > +#include "api_private.h" > + > +DECLARE_GLOBAL_DATA_PTR; > + > +/* > + * Important notice: handling of individual fields MUST be kept in sync with > + * include/asm-generic/u-boot.h, so any changes > + * need to reflect their current state and layout of structures involved! > + */ > +int platform_sys_info(struct sys_info *si) > +{ > + int i; > + > + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) > + platform_set_mr(si, gd->bd->bi_dram[i].start, > + gd->bd->bi_dram[i].size, MR_ATTR_DRAM); > + > + return 1; > +} > diff --git a/examples/api/Makefile b/examples/api/Makefile > index 8fa9c04118..0f9d0e013f 100644 > --- a/examples/api/Makefile > +++ b/examples/api/Makefile > @@ -18,6 +18,9 @@ else > LOAD_ADDR = 0x8020 > endif > endif > +ifeq ($(ARCH),riscv) > +LOAD_ADDR = 0x8400 > +endif > > # Resulting ELF and binary exectuables will be named demo and demo.bin > extra-y = demo demo.bin > diff --git a/examples/api/crt0.S b/examples/api/crt0.S > index 658bc59a82..2ba23331df 100644 > --- a/examples/api/crt0.S > +++ b/examples/api/crt0.S > @@ -65,6 +65,21 @@ return_addr: > .data > .align 8 > .long 0 > + > +#elif defined(CONFIG_RISCV) > +#include > + .text > + .globl _start > +_start: > + lla t0, search_hint Looks lla is only supported in newer assemblers? > + REG_S sp, 0(t0) > + tailmain > + > + .globl syscall > +syscall: > + lla t0, syscall_ptr > + REG_L t2, 0(t0) > + jr t2 > #else > #error No support for this arch! > #endif > -- Regards, Bin
Re: [PATCH 4/7] examples: fix the type of search_hint
On Tue, Apr 21, 2020 at 7:28 AM wrote: > > From: Mitchell Horne > > search_hint is defined in assembly as a .long, and is intended to hold > the initial stack pointer as a hint to the api_search_sig() routine. > Convert this to a uintptr_t, to avoid possible truncation on 64-bit > systems. > > Signed-off-by: Mitchell Horne > --- > examples/api/glue.c | 6 +++--- > examples/api/glue.h | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH 3/7] examples: add a linker script for the API demo
On Tue, Apr 21, 2020 at 7:28 AM wrote: > > From: Mitchell Horne > > When compiling the API demo program, the first object file in the linker > arguments is crt0.o, which contains the _start routine. This is done > with the hope that it will appear first in the .text section, but the > linker doesn't guarantee this behaviour. > > Add a simple linker script that ensures this ordering. This fixes > execution of the API demo binary for cases where _start was placed > elsewhere in the .text section. > > Signed-off-by: Mitchell Horne > --- > examples/api/Makefile | 4 +++- > examples/api/crt0.S | 2 ++ > examples/api/demo.lds | 14 ++ > 3 files changed, 19 insertions(+), 1 deletion(-) > create mode 100644 examples/api/demo.lds > > diff --git a/examples/api/Makefile b/examples/api/Makefile > index 9ff793206f..8fa9c04118 100644 > --- a/examples/api/Makefile > +++ b/examples/api/Makefile > @@ -48,10 +48,12 @@ OBJS := $(OBJ-y) $(notdir $(EXT_COBJ-y) $(EXT_SOBJ-y)) > targets += $(OBJS) > OBJS := $(addprefix $(obj)/,$(OBJS)) > > +LDS = $(obj)/demo.lds > # > > quiet_cmd_link_demo = LD $@ > -cmd_link_demo = $(LD) --gc-sections -Ttext $(LOAD_ADDR) -o $@ $(filter-out > $(PHONY), $^) $(PLATFORM_LIBS) > +cmd_link_demo = $(LD) --gc-sections -Ttext $(LOAD_ADDR) -T $(LDS) \ > + -o $@ $(filter-out $(PHONY), $^) $(PLATFORM_LIBS) > > $(obj)/demo: $(OBJS) FORCE > $(call if_changed,link_demo) > diff --git a/examples/api/crt0.S b/examples/api/crt0.S > index 2f75f5a036..658bc59a82 100644 > --- a/examples/api/crt0.S > +++ b/examples/api/crt0.S > @@ -62,12 +62,14 @@ syscall: > .end syscall > > return_addr: > + .data I think we need put .data before return_addr: to make it clearer. > .align 8 > .long 0 > #else > #error No support for this arch! > #endif > > + .data And changing these symbols should be a separate patch. > .globl syscall_ptr > syscall_ptr: > .align 8 Regards, Bin
Re: [PATCH 5/7] examples: fix incompatible type casts
On Tue, Apr 21, 2020 at 7:28 AM wrote: > > From: Mitchell Horne > > Some printf statements in the API demo assume pointers to be 32-bits > long, presumably since it was originally developed for 32-bit arm. This > generates a number of warnings when compiling for 64-bit architectures, > and may result in truncation of these values. Fix this by avoiding casts > where possible or casting to a more appropriate type. > > Signed-off-by: Mitchell Horne > --- > examples/api/demo.c | 21 +++-- > 1 file changed, 11 insertions(+), 10 deletions(-) > > diff --git a/examples/api/demo.c b/examples/api/demo.c > index e7523786b4..f81466c5cf 100644 > --- a/examples/api/demo.c > +++ b/examples/api/demo.c > @@ -43,12 +43,12 @@ int main(int argc, char * const argv[]) > if (sig->version > API_SIG_VERSION) > return -3; > > - printf("API signature found @%x\n", (unsigned int)sig); > + printf("API signature found @%lx\n", (uintptr_t)sig); > test_dump_sig(sig); > > printf("\n*** Consumer API test ***\n"); > - printf("syscall ptr 0x%08x@%08x\n", (unsigned int)syscall_ptr, > - (unsigned int)_ptr); > + printf("syscall ptr 0x%08lx@%08lx\n", (uintptr_t)syscall_ptr, > + (uintptr_t)_ptr); > > /* console activities */ > ub_putc('B'); > @@ -203,7 +203,7 @@ void test_dump_sig(struct api_signature *sig) > printf("signature:\n"); > printf(" version\t= %d\n", sig->version); > printf(" checksum\t= 0x%08x\n", sig->checksum); > - printf(" sc entry\t= 0x%08x\n", (unsigned int)sig->syscall); > + printf(" sc entry\t= 0x%08lx\n", (uintptr_t)sig->syscall); > } > > void test_dump_si(struct sys_info *si) > @@ -211,9 +211,9 @@ void test_dump_si(struct sys_info *si) > int i; > > printf("sys info:\n"); > - printf(" clkbus\t= 0x%08x\n", (unsigned int)si->clk_bus); > - printf(" clkcpu\t= 0x%08x\n", (unsigned int)si->clk_cpu); > - printf(" bar\t\t= 0x%08x\n", (unsigned int)si->bar); > + printf(" clkbus\t= 0x%08lx\n", si->clk_bus); > + printf(" clkcpu\t= 0x%08lx\n", si->clk_cpu); > + printf(" bar\t\t= 0x%08lx\n", si->bar); > > printf("---\n"); > for (i = 0; i < si->mr_no; i++) { > @@ -296,7 +296,7 @@ void test_dump_di(int handle) > struct device_info *di = ub_dev_get(handle); > > printf("device info (%d):\n", handle); > - printf(" cookie\t= 0x%08x\n", (uint32_t)di->cookie); > + printf(" cookie\t= 0x%08lx\n", (uintptr_t)di->cookie); > printf(" type\t\t= 0x%08x\n", di->type); > > if (di->type == DEV_TYP_NET) { > @@ -308,7 +308,8 @@ void test_dump_di(int handle) > > } else if (di->type & DEV_TYP_STOR) { > printf(" type\t\t= %s\n", test_stor_typ(di->type)); > - printf(" blk size\t\t= %d\n", (unsigned > int)di->di_stor.block_size); > - printf(" blk count\t\t= %d\n", (unsigned > int)di->di_stor.block_count); > + printf(" blk size\t\t= %lu\n", di->di_stor.block_size); > + printf(" blk count\t\t= %llu\n", Use LBAF from include/blk.h ? Also I am not sure why CONFIG_SYS_64BIT_LBA is undefined in include/api_public.h ? > + (uint64_t)di->di_stor.block_count); > } > } Regards, Bin
Re: [PATCH 1/7] examples: generate demo.bin
On Tue, Apr 21, 2020 at 7:27 AM wrote: > > From: Mitchell Horne > > The CONFIG_API option builds the example program, examples/api/demo, as > an ELF file. The make logic exists to create a binary as well, so add > the target to do so. > > Signed-off-by: Mitchell Horne > --- > examples/api/Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH 2/7] examples: rename __start to _start on MIPS
On Tue, Apr 21, 2020 at 7:28 AM wrote: > > From: Mitchell Horne > > On MIPS, __start marks the entry point to the CONFIG_API demo program. > Change the name to _start, to be consistent with all other > architectures. > > Signed-off-by: Mitchell Horne > --- > examples/api/crt0.S | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: Please pull u-boot-marvell/master
On 2020-04-22 23:04, Stefan Roese wrote: On 22.04.20 20:34, Tom Rini wrote: On Wed, Apr 22, 2020 at 04:48:33PM +0200, Stefan Roese wrote: Hi Tom, please pull the 2nd batch of MVEBU related patches in this merge window. The major changes are: Applied to u-boot/master, thanks! But the following checkpatch should be fixed in a follow up sometime: WARNING: quoted string split across lines #28: FILE: cmd/mvebu/bubt.c:734: + printf("Error: A38x image meant to be " + "booted from \"%s\", not \"%s\"!\n", (There's another but I think the split is fine for how humans would grep for it). Joel, will you please take care of this. Thanks, Stefan Yep, I'll get it updated today. Joel
Re: [RESEND PATCH v3 5/7] board: Add a gd flag for chain loading
Hi Simon, On Thu, Apr 23, 2020 at 7:03 PM Bin Meng wrote: > > Hi Simon, > > On Thu, Apr 9, 2020 at 2:58 AM Simon Glass wrote: > > > > When U-Boot is run from another boot loader, much of the low-level init > > needs to be skipped. > > > > Add a flag for this and adjust ll_boot_init() to use it. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Add a new patch with a gd flag for chain loading > > > > Changes in v2: None > > > > include/asm-generic/global_data.h | 1 + > > include/init.h| 2 +- > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/include/asm-generic/global_data.h > > b/include/asm-generic/global_data.h > > index 5d027329fe0..3dc51e49ef7 100644 > > --- a/include/asm-generic/global_data.h > > +++ b/include/asm-generic/global_data.h > > @@ -166,5 +166,6 @@ typedef struct global_data { > > #define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done > > */ > > #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use > > */ > > #define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use > > */ > > +#define GD_FLG_NO_LL_INIT 0x2 /* Don't perform low-level init > > */ > > How about GD_FLG_SKIP_LL_INIT ? Just noticed that there is an ad-hoc config macro (not converted to Kconfig yet) CONFIG_SKIP_LOWLEVEL_INIT. I suspect we can do some clean up and consolidation here ? > > > > > #endif /* __ASM_GENERIC_GBL_DATA_H */ > > diff --git a/include/init.h b/include/init.h > > index 2a33a3fd1e4..64fdf124916 100644 > > --- a/include/init.h > > +++ b/include/init.h > > @@ -20,7 +20,7 @@ struct global_data; > > #ifdef CONFIG_EFI_STUB > > #define ll_boot_init() false > > #else > > -#define ll_boot_init() true > > +#define ll_boot_init() (!(gd->flags & GD_FLG_NO_LL_INIT)) > > #endif Regards, Bin
[PATCH 09/12] driver: net: fm: add DM ETH support
Probe the FMan MACs based on the device tree while retaining the legacy code/functionality. One notable change introduced here is that, for DM_ETH, the name of the interfaces is corrected to the fmX-macY format, that avoids the referral to the MAC block names which were incorrect for FMan v3 devices (i.e. DTSEC, TGEC) and had weird formatting (i.e. FM1@DTSEC6, FM1@TGEC1). The legacy code is left unchanged in this respect. Signed-off-by: Madalin Bucur --- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 + board/freescale/ls1043ardb/ls1043ardb.c | 2 + board/freescale/ls1046afrwy/ls1046afrwy.c | 2 + board/freescale/ls1046aqds/ls1046aqds.c | 2 + board/freescale/ls1046ardb/ls1046ardb.c | 2 + drivers/net/fm/eth.c | 351 +- drivers/net/fm/fm.c | 80 +++ drivers/net/fm/fm.h | 23 ++ drivers/net/fm/init.c | 2 + drivers/net/fm/memac.c| 1 + include/fsl_mdio.h| 1 + 11 files changed, 458 insertions(+), 10 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index b443894..e0f8a50 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -1156,8 +1156,10 @@ int arch_early_init_r(void) fsl_rgmii_init(); #endif #ifdef CONFIG_FMAN_ENET +#ifndef CONFIG_DM_ETH fman_enet_init(); #endif +#endif #ifdef CONFIG_SYS_DPAA_QBMAN setup_qbman_portals(); #endif diff --git a/board/freescale/ls1043ardb/ls1043ardb.c b/board/freescale/ls1043ardb/ls1043ardb.c index 9bc78d6..26a1929 100644 --- a/board/freescale/ls1043ardb/ls1043ardb.c +++ b/board/freescale/ls1043ardb/ls1043ardb.c @@ -285,8 +285,10 @@ int ft_board_setup(void *blob, bd_t *bd) ft_cpu_setup(blob, bd); #ifdef CONFIG_SYS_DPAA_FMAN +#ifndef CONFIG_DM_ETH fdt_fixup_fman_ethernet(blob); #endif +#endif fdt_fixup_icid(blob); diff --git a/board/freescale/ls1046afrwy/ls1046afrwy.c b/board/freescale/ls1046afrwy/ls1046afrwy.c index 8c0abb6..71ace19 100644 --- a/board/freescale/ls1046afrwy/ls1046afrwy.c +++ b/board/freescale/ls1046afrwy/ls1046afrwy.c @@ -232,8 +232,10 @@ int ft_board_setup(void *blob, bd_t *bd) ft_cpu_setup(blob, bd); #ifdef CONFIG_SYS_DPAA_FMAN +#ifndef CONFIG_DM_ETH fdt_fixup_fman_ethernet(blob); #endif +#endif fdt_fixup_icid(blob); diff --git a/board/freescale/ls1046aqds/ls1046aqds.c b/board/freescale/ls1046aqds/ls1046aqds.c index cabd7ee..e6648e9 100644 --- a/board/freescale/ls1046aqds/ls1046aqds.c +++ b/board/freescale/ls1046aqds/ls1046aqds.c @@ -462,7 +462,9 @@ int ft_board_setup(void *blob, bd_t *bd) ft_cpu_setup(blob, bd); #ifdef CONFIG_SYS_DPAA_FMAN +#ifndef CONFIG_DM_ETH fdt_fixup_fman_ethernet(blob); +#endif fdt_fixup_board_enet(blob); #endif diff --git a/board/freescale/ls1046ardb/ls1046ardb.c b/board/freescale/ls1046ardb/ls1046ardb.c index cc6bd88..5308cb2 100644 --- a/board/freescale/ls1046ardb/ls1046ardb.c +++ b/board/freescale/ls1046ardb/ls1046ardb.c @@ -172,8 +172,10 @@ int ft_board_setup(void *blob, bd_t *bd) ft_cpu_setup(blob, bd); #ifdef CONFIG_SYS_DPAA_FMAN +#ifndef CONFIG_DM_ETH fdt_fixup_fman_ethernet(blob); #endif +#endif fdt_fixup_icid(blob); diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index 7d13736..5f1a023 100644 --- a/drivers/net/fm/eth.c +++ b/drivers/net/fm/eth.c @@ -1,10 +1,17 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright 2009-2012 Freescale Semiconductor, Inc. + * Copyright 2020 NXP * Dave Liu */ #include #include +#ifdef CONFIG_DM_ETH +#include +#include +#include +#include +#endif #include #include #include @@ -18,8 +25,10 @@ #include "fm.h" +#ifndef CONFIG_DM_ETH static struct eth_device *devlist[NUM_FM_PORTS]; static int num_controllers; +#endif #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) && !defined(BITBANGMII) @@ -37,10 +46,18 @@ static void dtsec_configure_serdes(struct fm_eth *priv) #ifdef CONFIG_SYS_FMAN_V3 u32 value; struct mii_dev bus; - bus.priv = priv->mac->phyregs; bool sgmii_2500 = (priv->enet_if == PHY_INTERFACE_MODE_SGMII_2500) ? true : false; - int i = 0; + int i = 0, j; + +#ifndef CONFIG_DM_ETH + bus.priv = priv->mac->phyregs; +#else + bus.priv = priv->pcs_mdio; +#endif + bus.read = memac_mdio_read; + bus.write = memac_mdio_write; + bus.reset = memac_mdio_reset; qsgmii_loop: /* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */ @@ -51,6 +68,10 @@ qsgmii_loop: else value = PHY_SGMII_IF_MODE_SGMII | PHY_SGMII_IF_MODE_AN; + for (j = 0; j <= 3; j++) + debug("dump PCS reg %#x: %#x\n", j, + memac_mdio_read(, i, MDIO_DEVAD_NONE, j)); +
[PATCH 11/12] configs: enable DM_ETH support for LS1043ARDB
Enable DM_ETH on all the defconfigs for the LS1043ARDB board. Signed-off-by: Madalin Bucur --- configs/ls1043ardb_SECURE_BOOT_defconfig| 3 +++ configs/ls1043ardb_defconfig| 3 +++ configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 3 +++ configs/ls1043ardb_nand_defconfig | 3 +++ configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 3 +++ configs/ls1043ardb_sdcard_defconfig | 3 +++ configs/ls1043ardb_tfa_SECURE_BOOT_defconfig| 3 +++ configs/ls1043ardb_tfa_defconfig| 3 +++ 8 files changed, 24 insertions(+) diff --git a/configs/ls1043ardb_SECURE_BOOT_defconfig b/configs/ls1043ardb_SECURE_BOOT_defconfig index 153a628..b06cbd8 100644 --- a/configs/ls1043ardb_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_SECURE_BOOT_defconfig @@ -13,6 +13,7 @@ CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 mtdparts=6000.nor:2m@0x10(nor_bank0_uboot),40m@0x110(nor_bank0_fit),7m(nor_bank0_user),2m@0x410(nor_bank4_uboot),40m@0x510(nor_bank4_fit),-(nor_bank4_user);7e80.flash:1m(nand_uboot),1m(nand_uboot_env),20m(nand_fit);spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(file_system)" CONFIG_MISC_INIT_R=y CONFIG_CMD_IMLS=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -36,6 +37,8 @@ CONFIG_MTD_RAW_NAND=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_PHYLIB=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1043ardb_defconfig b/configs/ls1043ardb_defconfig index d1e5343..82bd693 100644 --- a/configs/ls1043ardb_defconfig +++ b/configs/ls1043ardb_defconfig @@ -13,6 +13,7 @@ CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 mtdparts=6000.nor:2m@0x10(nor_bank0_uboot),40m@0x110(nor_bank0_fit),7m(nor_bank0_user),2m@0x410(nor_bank4_uboot),40m@0x510(nor_bank4_fit),-(nor_bank4_user);7e80.flash:1m(nand_uboot),1m(nand_uboot_env),20m(nand_fit);spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(file_system)" CONFIG_MISC_INIT_R=y CONFIG_CMD_IMLS=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -40,6 +41,8 @@ CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig index 252c7c8..e708fbc 100644 --- a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig @@ -31,6 +31,7 @@ CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_IMLS=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -57,6 +58,8 @@ CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1043ardb_nand_defconfig b/configs/ls1043ardb_nand_defconfig index de18aaa..6b9b306 100644 --- a/configs/ls1043ardb_nand_defconfig +++ b/configs/ls1043ardb_nand_defconfig @@ -31,6 +31,7 @@ CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_IMLS=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -58,6 +59,8 @@ CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig index 149b25f..c59caf1 100644 --- a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_IMLS=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -55,6 +56,8 @@ CONFIG_MTD_RAW_NAND=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_PHYLIB=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1043ardb_sdcard_defconfig b/configs/ls1043ardb_sdcard_defconfig index b386fc6..b39a907 100644 --- a/configs/ls1043ardb_sdcard_defconfig +++ b/configs/ls1043ardb_sdcard_defconfig @@ -29,6 +29,7 @@ CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_IMLS=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -57,6 +58,8 @@ CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig index
[PATCH 05/12] ARM: dts: add QorIQ DPAA 1 FMan v3 to LS1046ARDB
Introduce the QorIQ DPAA 1 Frame Manager nodes in the LS1046ARDB device tree. The device tree fragments are copied over with little modification from the Linux kernel source code. Signed-off-by: Madalin Bucur --- arch/arm/dts/fsl-ls1046a-rdb.dts | 67 arch/arm/dts/fsl-ls1046a.dtsi| 2 +- 2 files changed, 68 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/fsl-ls1046a-rdb.dts b/arch/arm/dts/fsl-ls1046a-rdb.dts index 83e34ab..cac65a7 100644 --- a/arch/arm/dts/fsl-ls1046a-rdb.dts +++ b/arch/arm/dts/fsl-ls1046a-rdb.dts @@ -3,6 +3,7 @@ * Device Tree Include file for Freescale Layerscape-1046A family SoC. * * Copyright 2016, Freescale Semiconductor + * Copyright 2020 NXP * * Mingkai Hu */ @@ -51,3 +52,69 @@ { status = "okay"; }; + +#include "fsl-ls1046-post.dtsi" + + { + ethernet@e4000 { + phy-handle = <_phy1>; + phy-connection-type = "rgmii-id"; + status = "okay"; + }; + + ethernet@e6000 { + phy-handle = <_phy2>; + phy-connection-type = "rgmii-id"; + status = "okay"; + }; + + ethernet@e8000 { + phy-handle = <_phy1>; + phy-connection-type = "sgmii"; + status = "okay"; + }; + + ethernet@ea000 { + phy-handle = <_phy2>; + phy-connection-type = "sgmii"; + status = "okay"; + }; + + ethernet@f { /* 10GEC1 */ + phy-handle = <_phy>; + phy-connection-type = "xgmii"; + status = "okay"; + }; + + ethernet@f2000 { /* 10GEC2 */ + fixed-link = <0 1 1000 0 0>; + phy-connection-type = "xgmii"; + status = "okay"; + }; + + mdio@fc000 { + rgmii_phy1: ethernet-phy@1 { + reg = <0x1>; + }; + + rgmii_phy2: ethernet-phy@2 { + reg = <0x2>; + }; + + sgmii_phy1: ethernet-phy@3 { + reg = <0x3>; + }; + + sgmii_phy2: ethernet-phy@4 { + reg = <0x4>; + }; + }; + + mdio@fd000 { + aqr106_phy: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c45"; + interrupts = <0 131 4>; + reg = <0x0>; + }; + }; +}; diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi index fdf93fd..4e91d5c 100644 --- a/arch/arm/dts/fsl-ls1046a.dtsi +++ b/arch/arm/dts/fsl-ls1046a.dtsi @@ -31,7 +31,7 @@ interrupts = <1 9 0xf08>; }; - soc { + soc: soc { compatible = "simple-bus"; #address-cells = <2>; #size-cells = <2>; -- 2.1.0
[PATCH 10/12] net: fm: fix compilation issue
The NAND related code needs to be guarded with #ifdef CONFIG_NAND_BOOT to avoid a compilation error when this configuration is not enabled. Signed-off-by: Madalin Bucur --- drivers/net/fm/fm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c index bf8d3d0..b39bdda 100644 --- a/drivers/net/fm/fm.c +++ b/drivers/net/fm/fm.c @@ -364,6 +364,7 @@ int fm_init_common(int index, struct ccsr_fman *reg) addr = (void *)(CONFIG_SYS_FMAN_FW_ADDR + CONFIG_SYS_FSL_IFC_BASE); } else if (src == BOOT_SOURCE_IFC_NAND) { +#ifdef CONFIG_NAND_BOOT size_t fw_length = CONFIG_SYS_QE_FMAN_FW_LENGTH; addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH); @@ -375,6 +376,7 @@ int fm_init_common(int index, struct ccsr_fman *reg) printf("NAND read of FMAN firmware at offset 0x%x failed %d\n", CONFIG_SYS_FMAN_FW_ADDR, rc); } +#endif } else if (src == BOOT_SOURCE_QSPI_NOR) { struct spi_flash *ucode_flash; -- 2.1.0
[PATCH 12/12] configs: enable DM_ETH support for LS1046ARDB
Enable DM_ETH on all the defconfigs for the LS1046ARDB board. Signed-off-by: Madalin Bucur --- configs/ls1046ardb_emmc_defconfig | 3 +++ configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 3 +++ configs/ls1046ardb_qspi_defconfig | 3 +++ configs/ls1046ardb_qspi_spl_defconfig | 3 +++ configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 3 +++ configs/ls1046ardb_sdcard_defconfig | 3 +++ configs/ls1046ardb_tfa_SECURE_BOOT_defconfig| 3 +++ configs/ls1046ardb_tfa_defconfig| 3 +++ 8 files changed, 24 insertions(+) diff --git a/configs/ls1046ardb_emmc_defconfig b/configs/ls1046ardb_emmc_defconfig index bbb352d..777f818 100644 --- a/configs/ls1046ardb_emmc_defconfig +++ b/configs/ls1046ardb_emmc_defconfig @@ -31,6 +31,7 @@ CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -56,6 +57,8 @@ CONFIG_MTD_RAW_NAND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig index b9c8a88..450c2d0 100644 --- a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig @@ -15,6 +15,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 mtdparts=155.spi-0:1m(rcw),15m(u-boot),48m(kernel.itb);7e80.flash:16m(nand_uboot),48m(nand_kernel),448m(nand_free)" CONFIG_MISC_INIT_R=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -37,6 +38,8 @@ CONFIG_MTD_RAW_NAND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1046ardb_qspi_defconfig b/configs/ls1046ardb_qspi_defconfig index 51edada..25665ba 100644 --- a/configs/ls1046ardb_qspi_defconfig +++ b/configs/ls1046ardb_qspi_defconfig @@ -16,6 +16,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 mtdparts=155.spi-0:1m(rcw),15m(u-boot),48m(kernel.itb);7e80.flash:16m(nand_uboot),48m(nand_kernel),448m(nand_free)" CONFIG_MISC_INIT_R=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -40,6 +41,8 @@ CONFIG_MTD_RAW_NAND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1046ardb_qspi_spl_defconfig b/configs/ls1046ardb_qspi_spl_defconfig index 84e0596..e33b641 100644 --- a/configs/ls1046ardb_qspi_spl_defconfig +++ b/configs/ls1046ardb_qspi_spl_defconfig @@ -33,6 +33,7 @@ CONFIG_SPL_OS_BOOT=y CONFIG_SYS_OS_BASE=0x4098 CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_CMD_SPL=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -58,6 +59,8 @@ CONFIG_MTD_RAW_NAND=y # CONFIG_SPI_FLASH_BAR is not set # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_FMAN_ENET=y diff --git a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig index 9954e89..b7e4d8e 100644 --- a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -52,6 +53,8 @@ CONFIG_MTD_RAW_NAND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1046ardb_sdcard_defconfig b/configs/ls1046ardb_sdcard_defconfig index 3502809..2861acb 100644 --- a/configs/ls1046ardb_sdcard_defconfig +++ b/configs/ls1046ardb_sdcard_defconfig @@ -30,6 +30,7 @@ CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y @@ -55,6 +56,8 @@ CONFIG_MTD_RAW_NAND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHYLIB=y CONFIG_PHY_AQUANTIA=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y CONFIG_E1000=y CONFIG_FMAN_ENET=y CONFIG_PCI=y diff --git a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig index 9e3042b..159cd71 100644 --- a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig @@ -16,6 +16,7 @@ CONFIG_BOOTDELAY=10
[PATCH 08/12] driver: net: fm: add DM MDIO support
Allow the MDIO devices to be probed based on the device tree. Signed-off-by: Madalin Bucur --- drivers/net/fm/memac_phy.c | 139 - 1 file changed, 137 insertions(+), 2 deletions(-) diff --git a/drivers/net/fm/memac_phy.c b/drivers/net/fm/memac_phy.c index c2ef1b4..4cbfbc7 100644 --- a/drivers/net/fm/memac_phy.c +++ b/drivers/net/fm/memac_phy.c @@ -22,6 +22,12 @@ #define memac_setbits_32(a, v) setbits_be32(a, v) #endif +#ifdef CONFIG_DM_ETH +struct fm_mdio_priv { + struct memac_mdio_controller *regs; +}; +#endif + static u32 memac_in_32(u32 *reg) { #ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN @@ -39,10 +45,23 @@ static u32 memac_in_32(u32 *reg) int memac_mdio_write(struct mii_dev *bus, int port_addr, int dev_addr, int regnum, u16 value) { + struct memac_mdio_controller *regs; u32 mdio_ctl; - struct memac_mdio_controller *regs = bus->priv; u32 c45 = 1; /* Default to 10G interface */ +#ifndef CONFIG_DM_ETH + regs = bus->priv; +#else + struct fm_mdio_priv *priv; + + if (!bus->priv) + return -EINVAL; + priv = dev_get_priv(bus->priv); + regs = priv->regs; + debug("memac_mdio_write(regs %p, port %d, dev %d, reg %d, val %#x)\n", + regs, port_addr, dev_addr, regnum, value); +#endif + if (dev_addr == MDIO_DEVAD_NONE) { c45 = 0; /* clause 22 */ dev_addr = regnum & 0x1f; @@ -84,13 +103,26 @@ int memac_mdio_write(struct mii_dev *bus, int port_addr, int dev_addr, int memac_mdio_read(struct mii_dev *bus, int port_addr, int dev_addr, int regnum) { + struct memac_mdio_controller *regs; u32 mdio_ctl; - struct memac_mdio_controller *regs = bus->priv; u32 c45 = 1; +#ifndef CONFIG_DM_ETH + regs = bus->priv; +#else + struct fm_mdio_priv *priv; + + if (!bus->priv) + return -EINVAL; + priv = dev_get_priv(bus->priv); + regs = priv->regs; +#endif + if (dev_addr == MDIO_DEVAD_NONE) { +#ifndef CONFIG_DM_ETH if (!strcmp(bus->name, DEFAULT_FM_TGEC_MDIO_NAME)) return 0x; +#endif c45 = 0; /* clause 22 */ dev_addr = regnum & 0x1f; memac_clrbits_32(>mdio_stat, MDIO_STAT_ENC); @@ -133,6 +165,7 @@ int memac_mdio_reset(struct mii_dev *bus) return 0; } +#ifndef CONFIG_DM_ETH int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info *info) { struct mii_dev *bus = mdio_alloc(); @@ -167,3 +200,105 @@ int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info *info) return mdio_register(bus); } + +#else /* CONFIG_DM_ETH */ +#if defined(CONFIG_PHYLIB) && defined(CONFIG_DM_MDIO) +static int fm_mdio_read(struct udevice *dev, int addr, int devad, int reg) +{ + struct mdio_perdev_priv *pdata = (dev) ? dev_get_uclass_priv(dev) : +NULL; + + if (pdata && pdata->mii_bus) + return memac_mdio_read(pdata->mii_bus, addr, devad, reg); + + return -1; +} + +static int fm_mdio_write(struct udevice *dev, int addr, int devad, int reg, +u16 val) +{ + struct mdio_perdev_priv *pdata = (dev) ? dev_get_uclass_priv(dev) : +NULL; + + if (pdata && pdata->mii_bus) + return memac_mdio_write(pdata->mii_bus, addr, devad, reg, val); + + return -1; +} + +static int fm_mdio_reset(struct udevice *dev) +{ + struct mdio_perdev_priv *pdata = (dev) ? dev_get_uclass_priv(dev) : +NULL; + + if (pdata && pdata->mii_bus) + return memac_mdio_reset(pdata->mii_bus); + + return -1; +} + +static const struct mdio_ops fm_mdio_ops = { + .read = fm_mdio_read, + .write = fm_mdio_write, + .reset = fm_mdio_reset, +}; + +static const struct udevice_id fm_mdio_ids[] = { + { .compatible = "fsl,fman-memac-mdio" }, + {} +}; + +static int fm_mdio_probe(struct udevice *dev) +{ + struct fm_mdio_priv *priv = (dev) ? dev_get_priv(dev) : NULL; + struct mdio_perdev_priv *pdata = (dev) ? dev_get_uclass_priv(dev) : +NULL; + + if (!dev) { + printf("%s dev = NULL\n", __func__); + return -1; + } + if (!priv) { + printf("dev_get_priv(dev %p) = NULL\n", dev); + return -1; + } + priv->regs = (void *)(uintptr_t)dev_read_addr(dev); + debug("%s priv %p @ regs %p, pdata %p\n", __func__, + priv, priv->regs, pdata); + + /* +* On some platforms like B4860, default value of MDIO_CLK_DIV bits +* in mdio_stat(mdio_cfg) register generates MDIO clock too high +* (much higher than 2.5MHz), violating the IEEE specs. +
[PATCH 01/12] ARM: dts: add QorIQ DPAA 1 FMan v3 device tree nodes
Add the QorIQ DPAA Frame Manager v3 device tree nodes description. The device tree fragments are copied over with little modification from the Linux kernel source code. Signed-off-by: Madalin Bucur --- arch/arm/dts/qoriq-fman3-0-10g-0.dtsi | 44 +++ arch/arm/dts/qoriq-fman3-0-10g-1.dtsi | 44 +++ arch/arm/dts/qoriq-fman3-0-1g-0.dtsi | 43 ++ arch/arm/dts/qoriq-fman3-0-1g-1.dtsi | 43 ++ arch/arm/dts/qoriq-fman3-0-1g-2.dtsi | 43 ++ arch/arm/dts/qoriq-fman3-0-1g-3.dtsi | 43 ++ arch/arm/dts/qoriq-fman3-0-1g-4.dtsi | 43 ++ arch/arm/dts/qoriq-fman3-0-1g-5.dtsi | 43 ++ arch/arm/dts/qoriq-fman3-0.dtsi | 82 +++ 9 files changed, 428 insertions(+) create mode 100644 arch/arm/dts/qoriq-fman3-0-10g-0.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-10g-1.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-0.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-1.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-2.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-3.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-4.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-5.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0.dtsi diff --git a/arch/arm/dts/qoriq-fman3-0-10g-0.dtsi b/arch/arm/dts/qoriq-fman3-0-10g-0.dtsi new file mode 100644 index 000..8f4776e --- /dev/null +++ b/arch/arm/dts/qoriq-fman3-0-10g-0.dtsi @@ -0,0 +1,44 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) +/* + * QorIQ FMan v3 10g port #0 device tree + * + * Copyright 2012-2015 Freescale Semiconductor Inc. + * Copyright 2020 NXP + * + */ + +fman@1a0 { + fman0_rx_0x10: port@9 { + cell-index = <0x10>; + compatible = "fsl,fman-v3-port-rx"; + reg = <0x9 0x1000>; + fsl,fman-10g-port; + }; + + fman0_tx_0x30: port@b { + cell-index = <0x30>; + compatible = "fsl,fman-v3-port-tx"; + reg = <0xb 0x1000>; + fsl,fman-10g-port; + }; + + ethernet@f { + cell-index = <0x8>; + compatible = "fsl,fman-memac"; + reg = <0xf 0x1000>; + fsl,fman-ports = <_rx_0x10 _tx_0x30>; + pcsphy-handle = <>; + status = "disabled"; + }; + + mdio@f1000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio"; + reg = <0xf1000 0x1000>; + + pcsphy6: ethernet-phy@0 { + reg = <0x0>; + }; + }; +}; diff --git a/arch/arm/dts/qoriq-fman3-0-10g-1.dtsi b/arch/arm/dts/qoriq-fman3-0-10g-1.dtsi new file mode 100644 index 000..b5eb22f --- /dev/null +++ b/arch/arm/dts/qoriq-fman3-0-10g-1.dtsi @@ -0,0 +1,44 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) +/* + * QorIQ FMan v3 10g port #1 device tree + * + * Copyright 2012-2015 Freescale Semiconductor Inc. + * Copyright 2020 NXP + * + */ + +fman@1a0 { + fman0_rx_0x11: port@91000 { + cell-index = <0x11>; + compatible = "fsl,fman-v3-port-rx"; + reg = <0x91000 0x1000>; + fsl,fman-10g-port; + }; + + fman0_tx_0x31: port@b1000 { + cell-index = <0x31>; + compatible = "fsl,fman-v3-port-tx"; + reg = <0xb1000 0x1000>; + fsl,fman-10g-port; + }; + + ethernet@f2000 { + cell-index = <0x9>; + compatible = "fsl,fman-memac"; + reg = <0xf2000 0x1000>; + fsl,fman-ports = <_rx_0x11 _tx_0x31>; + pcsphy-handle = <>; + status = "disabled"; + }; + + mdio@f3000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio"; + reg = <0xf3000 0x1000>; + + pcsphy7: ethernet-phy@0 { + reg = <0x0>; + }; + }; +}; diff --git a/arch/arm/dts/qoriq-fman3-0-1g-0.dtsi b/arch/arm/dts/qoriq-fman3-0-1g-0.dtsi new file mode 100644 index 000..4264d47 --- /dev/null +++ b/arch/arm/dts/qoriq-fman3-0-1g-0.dtsi @@ -0,0 +1,43 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) +/* + * QorIQ FMan v3 1g port #0 device tree + * + * Copyright 2012-2015 Freescale Semiconductor Inc. + * Copyright 2020 NXP + * + */ + +fman@1a0 { + fman0_rx_0x08: port@88000 { + cell-index = <0x8>; + compatible = "fsl,fman-v3-port-rx"; + reg = <0x88000 0x1000>; + }; + + fman0_tx_0x28: port@a8000 { + cell-index = <0x28>; + compatible = "fsl,fman-v3-port-tx"; + reg = <0xa8000
[PATCH 02/12] ARM: dts: add QorIQ DPAA 1 FMan v3 for LS1043A
Add the QorIQ DPAA 1 Frame Manager v3 device tree nodes for the LS1043A SoC. The device tree fragments are copied over with little modification from the Linux kernel source code. Signed-off-by: Madalin Bucur --- arch/arm/dts/fsl-ls1043-post.dtsi | 48 +++ 1 file changed, 48 insertions(+) create mode 100644 arch/arm/dts/fsl-ls1043-post.dtsi diff --git a/arch/arm/dts/fsl-ls1043-post.dtsi b/arch/arm/dts/fsl-ls1043-post.dtsi new file mode 100644 index 000..e4eab9e --- /dev/null +++ b/arch/arm/dts/fsl-ls1043-post.dtsi @@ -0,0 +1,48 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) +/* + * QorIQ FMan v3 device tree nodes for ls1043 + * + * Copyright 2015-2016 Freescale Semiconductor Inc. + * Copyright 2020 NXP + * + */ + + { + +/* include used FMan blocks */ +#include "qoriq-fman3-0.dtsi" +#include "qoriq-fman3-0-1g-0.dtsi" +#include "qoriq-fman3-0-1g-1.dtsi" +#include "qoriq-fman3-0-1g-2.dtsi" +#include "qoriq-fman3-0-1g-3.dtsi" +#include "qoriq-fman3-0-1g-4.dtsi" +#include "qoriq-fman3-0-1g-5.dtsi" +#include "qoriq-fman3-0-10g-0.dtsi" + +}; + + { + fsl,erratum-a050385; + + /* these aliases provide the FMan ports mapping */ + enet0: ethernet@e { + }; + + enet1: ethernet@e2000 { + }; + + enet2: ethernet@e4000 { + }; + + enet3: ethernet@e6000 { + }; + + enet4: ethernet@e8000 { + }; + + enet5: ethernet@ea000 { + }; + + enet6: ethernet@f { + }; +}; -- 2.1.0
[PATCH 04/12] ARM: dts: add QorIQ DPAA 1 FMan v3 for LS1046A
Add the QorIQ DPAA 1 Frame Manager v3 device tree nodes for the LS1046A SoC. The device tree fragments are copied over with little modification from the Linux kernel source code. Signed-off-by: Madalin Bucur --- arch/arm/dts/fsl-ls1046-post.dtsi | 49 +++ 1 file changed, 49 insertions(+) create mode 100644 arch/arm/dts/fsl-ls1046-post.dtsi diff --git a/arch/arm/dts/fsl-ls1046-post.dtsi b/arch/arm/dts/fsl-ls1046-post.dtsi new file mode 100644 index 000..2dac6a0 --- /dev/null +++ b/arch/arm/dts/fsl-ls1046-post.dtsi @@ -0,0 +1,49 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) +/* + * QorIQ FMan v3 device tree nodes for ls1046 + * + * Copyright 2015-2016 Freescale Semiconductor Inc. + * Copyright 2020 NXP + * + */ + + { + +/* include used FMan blocks */ +#include "qoriq-fman3-0.dtsi" +#include "qoriq-fman3-0-1g-0.dtsi" +#include "qoriq-fman3-0-1g-1.dtsi" +#include "qoriq-fman3-0-1g-2.dtsi" +#include "qoriq-fman3-0-1g-3.dtsi" +#include "qoriq-fman3-0-1g-4.dtsi" +#include "qoriq-fman3-0-1g-5.dtsi" +#include "qoriq-fman3-0-10g-0.dtsi" +#include "qoriq-fman3-0-10g-1.dtsi" +}; + + { + /* these aliases provide the FMan ports mapping */ + enet0: ethernet@e { + }; + + enet1: ethernet@e2000 { + }; + + enet2: ethernet@e4000 { + }; + + enet3: ethernet@e6000 { + }; + + enet4: ethernet@e8000 { + }; + + enet5: ethernet@ea000 { + }; + + enet6: ethernet@f { + }; + + enet7: ethernet@f2000 { + }; +}; -- 2.1.0
[PATCH 06/12] driver: net: fm: change init_phy() param
Change the init_phy() parameter to simplify the code. Signed-off-by: Madalin Bucur --- drivers/net/fm/eth.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index 88019c9..57db2e9 100644 --- a/drivers/net/fm/eth.c +++ b/drivers/net/fm/eth.c @@ -98,9 +98,8 @@ qsgmii_loop: #endif } -static void dtsec_init_phy(struct eth_device *dev) +static void dtsec_init_phy(struct fm_eth *fm_eth) { - struct fm_eth *fm_eth = dev->priv; #ifndef CONFIG_SYS_FMAN_V3 struct dtsec *regs = (struct dtsec *)CONFIG_SYS_FSL_FM1_DTSEC1_ADDR; @@ -115,9 +114,8 @@ static void dtsec_init_phy(struct eth_device *dev) } #ifdef CONFIG_PHYLIB -static int tgec_is_fibre(struct eth_device *dev) +static int tgec_is_fibre(struct fm_eth *fm) { - struct fm_eth *fm = dev->priv; char phyopt[20]; sprintf(phyopt, "fsl_fm%d_xaui_phy", fm->fm_index + 1); @@ -679,21 +677,20 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct ccsr_fman *reg) return 0; } -static int init_phy(struct eth_device *dev) +static int init_phy(struct fm_eth *fm_eth) { - struct fm_eth *fm_eth = dev->priv; #ifdef CONFIG_PHYLIB struct phy_device *phydev = NULL; u32 supported; #endif if (fm_eth->type == FM_ETH_1G_E) - dtsec_init_phy(dev); + dtsec_init_phy(fm_eth); #ifdef CONFIG_PHYLIB if (fm_eth->bus) { - phydev = phy_connect(fm_eth->bus, fm_eth->phyaddr, dev, - fm_eth->enet_if); + phydev = phy_connect(fm_eth->bus, fm_eth->phyaddr, fm_eth->dev, +fm_eth->enet_if); if (!phydev) { printf("Failed to connect\n"); return -1; @@ -711,7 +708,7 @@ static int init_phy(struct eth_device *dev) } else { supported = SUPPORTED_1baseT_Full; - if (tgec_is_fibre(dev)) + if (tgec_is_fibre(fm_eth)) phydev->port = PORT_FIBRE; } @@ -784,7 +781,7 @@ int fm_eth_initialize(struct ccsr_fman *reg, struct fm_eth_info *info) if (ret) return ret; - init_phy(dev); + init_phy(fm_eth); /* clear the ethernet address */ for (i = 0; i < 6; i++) -- 2.1.0
[PATCH 07/12] driver: net: fm: separate receive buffer free code
Move the receive buffer free code in a separate function. Signed-off-by: Madalin Bucur --- drivers/net/fm/eth.c | 63 ++-- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index 57db2e9..7d13736 100644 --- a/drivers/net/fm/eth.c +++ b/drivers/net/fm/eth.c @@ -567,20 +567,46 @@ static int fm_eth_send(struct eth_device *dev, void *buf, int len) return 1; } -static int fm_eth_recv(struct eth_device *dev) +static struct fm_port_bd *fm_eth_free_one(struct fm_eth *fm_eth, + struct fm_port_bd *rxbd) { - struct fm_eth *fm_eth; struct fm_port_global_pram *pram; - struct fm_port_bd *rxbd, *rxbd_base; - u16 status, len; - u32 buf_lo, buf_hi; - u8 *data; + struct fm_port_bd *rxbd_base; u16 offset_out; - int ret = 1; - fm_eth = (struct fm_eth *)dev->priv; pram = fm_eth->rx_pram; - rxbd = fm_eth->cur_rxbd; + + /* clear the RxBDs */ + muram_writew(>status, RxBD_EMPTY); + muram_writew(>len, 0); + sync(); + + /* advance RxBD */ + rxbd++; + rxbd_base = (struct fm_port_bd *)fm_eth->rx_bd_ring; + if (rxbd >= (rxbd_base + RX_BD_RING_SIZE)) + rxbd = rxbd_base; + + /* update RxQD */ + offset_out = muram_readw(>rxqd.offset_out); + offset_out += sizeof(struct fm_port_bd); + if (offset_out >= muram_readw(>rxqd.bd_ring_size)) + offset_out = 0; + muram_writew(>rxqd.offset_out, offset_out); + sync(); + + return rxbd; +} + +static int fm_eth_recv(struct eth_device *dev) +{ + struct fm_eth *fm_eth = (struct fm_eth *)dev->priv; + struct fm_port_bd *rxbd = fm_eth->cur_rxbd; + u32 buf_lo, buf_hi; + u16 status, len; + int ret = -1; + u8 *data; + status = muram_readw(>status); while (!(status & RxBD_EMPTY)) { @@ -595,26 +621,11 @@ static int fm_eth_recv(struct eth_device *dev) ret = 0; } - /* clear the RxBDs */ - muram_writew(>status, RxBD_EMPTY); - muram_writew(>len, 0); - sync(); + /* free current bd, advance to next one */ + rxbd = fm_eth_free_one(fm_eth, rxbd); - /* advance RxBD */ - rxbd++; - rxbd_base = (struct fm_port_bd *)fm_eth->rx_bd_ring; - if (rxbd >= (rxbd_base + RX_BD_RING_SIZE)) - rxbd = rxbd_base; /* read next status */ status = muram_readw(>status); - - /* update RxQD */ - offset_out = muram_readw(>rxqd.offset_out); - offset_out += sizeof(struct fm_port_bd); - if (offset_out >= muram_readw(>rxqd.bd_ring_size)) - offset_out = 0; - muram_writew(>rxqd.offset_out, offset_out); - sync(); } fm_eth->cur_rxbd = (void *)rxbd; -- 2.1.0
[PATCH 00/12] Enable DM_ETH on the DPAA1 ARM platforms
This patch set enables DM_ETH on the DPAA1 ARM platforms. The required changes are added to the LS104x device trees and LS104xARDB device trees. Changes to the fm driver introduce DM ETH and DM MDIO support while still preserving the legacy functionality. A compilation error related to CONFIG_NAND_BOOT revealed during validation of the changes is also addressed. Madalin Bucur (12): ARM: dts: add QorIQ DPAA 1 FMan v3 device tree nodes ARM: dts: add QorIQ DPAA 1 FMan v3 for LS1043A ARM: dts: add QorIQ DPAA 1 FMan v3 to LS1043ARDB ARM: dts: add QorIQ DPAA 1 FMan v3 for LS1046A ARM: dts: add QorIQ DPAA 1 FMan v3 to LS1046ARDB driver: net: fm: change init_phy() param driver: net: fm: separate receive buffer free code driver: net: fm: add DM MDIO support driver: net: fm: add DM ETH support net: fm: fix compilation issue configs: enable DM_ETH support for LS1043ARDB configs: enable DM_ETH support for LS1046ARDB arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 + arch/arm/dts/fsl-ls1043-post.dtsi | 48 +++ arch/arm/dts/fsl-ls1043a-rdb.dts| 81 + arch/arm/dts/fsl-ls1043a.dtsi | 2 +- arch/arm/dts/fsl-ls1046-post.dtsi | 49 +++ arch/arm/dts/fsl-ls1046a-rdb.dts| 67 arch/arm/dts/fsl-ls1046a.dtsi | 2 +- arch/arm/dts/qoriq-fman3-0-10g-0.dtsi | 44 +++ arch/arm/dts/qoriq-fman3-0-10g-1.dtsi | 44 +++ arch/arm/dts/qoriq-fman3-0-1g-0.dtsi| 43 +++ arch/arm/dts/qoriq-fman3-0-1g-1.dtsi| 43 +++ arch/arm/dts/qoriq-fman3-0-1g-2.dtsi| 43 +++ arch/arm/dts/qoriq-fman3-0-1g-3.dtsi| 43 +++ arch/arm/dts/qoriq-fman3-0-1g-4.dtsi| 43 +++ arch/arm/dts/qoriq-fman3-0-1g-5.dtsi| 43 +++ arch/arm/dts/qoriq-fman3-0.dtsi | 82 + board/freescale/ls1043ardb/ls1043ardb.c | 2 + board/freescale/ls1046afrwy/ls1046afrwy.c | 2 + board/freescale/ls1046aqds/ls1046aqds.c | 2 + board/freescale/ls1046ardb/ls1046ardb.c | 2 + configs/ls1043ardb_SECURE_BOOT_defconfig| 3 + configs/ls1043ardb_defconfig| 3 + configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 3 + configs/ls1043ardb_nand_defconfig | 3 + configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 3 + configs/ls1043ardb_sdcard_defconfig | 3 + configs/ls1043ardb_tfa_SECURE_BOOT_defconfig| 3 + configs/ls1043ardb_tfa_defconfig| 3 + configs/ls1046ardb_emmc_defconfig | 3 + configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 3 + configs/ls1046ardb_qspi_defconfig | 3 + configs/ls1046ardb_qspi_spl_defconfig | 3 + configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 3 + configs/ls1046ardb_sdcard_defconfig | 3 + configs/ls1046ardb_tfa_SECURE_BOOT_defconfig| 3 + configs/ls1046ardb_tfa_defconfig| 3 + drivers/net/fm/eth.c| 433 +--- drivers/net/fm/fm.c | 82 + drivers/net/fm/fm.h | 23 ++ drivers/net/fm/init.c | 2 + drivers/net/fm/memac.c | 1 + drivers/net/fm/memac_phy.c | 139 +++- include/fsl_mdio.h | 1 + 43 files changed, 1365 insertions(+), 51 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1043-post.dtsi create mode 100644 arch/arm/dts/fsl-ls1046-post.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-10g-0.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-10g-1.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-0.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-1.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-2.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-3.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-4.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0-1g-5.dtsi create mode 100644 arch/arm/dts/qoriq-fman3-0.dtsi -- 2.1.0
[PATCH 03/12] ARM: dts: add QorIQ DPAA 1 FMan v3 to LS1043ARDB
Introduce the QorIQ DPAA 1 Frame Manager nodes in the LS1043ARDB device tree. The device tree fragments are copied over with little modification from the Linux kernel source code. Signed-off-by: Madalin Bucur --- arch/arm/dts/fsl-ls1043a-rdb.dts | 81 arch/arm/dts/fsl-ls1043a.dtsi| 2 +- 2 files changed, 82 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/fsl-ls1043a-rdb.dts b/arch/arm/dts/fsl-ls1043a-rdb.dts index 721b158..6e4ea5b 100644 --- a/arch/arm/dts/fsl-ls1043a-rdb.dts +++ b/arch/arm/dts/fsl-ls1043a-rdb.dts @@ -3,6 +3,7 @@ * Device Tree Include file for Freescale Layerscape-1043A family SoC. * * Copyright (C) 2015, Freescale Semiconductor + * Copyright 2020 NXP * * Mingkai Hu */ @@ -98,3 +99,83 @@ { status = "okay"; }; + +#include "fsl-ls1043-post.dtsi" + + { + ethernet@e { + phy-handle = <_phy1>; + phy-connection-type = "qsgmii"; + status = "okay"; + }; + + ethernet@e2000 { + phy-handle = <_phy2>; + phy-connection-type = "qsgmii"; + status = "okay"; + }; + + ethernet@e4000 { + phy-handle = <_phy1>; + phy-connection-type = "rgmii-txid"; + status = "okay"; + }; + + ethernet@e6000 { + phy-handle = <_phy2>; + phy-connection-type = "rgmii-txid"; + status = "okay"; + }; + + ethernet@e8000 { + phy-handle = <_phy3>; + phy-connection-type = "qsgmii"; + status = "okay"; + }; + + ethernet@ea000 { + phy-handle = <_phy4>; + phy-connection-type = "qsgmii"; + status = "okay"; + }; + + ethernet@f { /* 10GEC1 */ + phy-handle = <_phy>; + phy-connection-type = "xgmii"; + status = "okay"; + }; + + mdio@fc000 { + rgmii_phy1: ethernet-phy@1 { + reg = <0x1>; + }; + + rgmii_phy2: ethernet-phy@2 { + reg = <0x2>; + }; + + qsgmii_phy1: ethernet-phy@4 { + reg = <0x4>; + }; + + qsgmii_phy2: ethernet-phy@5 { + reg = <0x5>; + }; + + qsgmii_phy3: ethernet-phy@6 { + reg = <0x6>; + }; + + qsgmii_phy4: ethernet-phy@7 { + reg = <0x7>; + }; + }; + + mdio@fd000 { + aqr105_phy: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c45"; + interrupts = <0 132 4>; + reg = <0x1>; + }; + }; +}; diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi index b159c3c..0a959f0 100644 --- a/arch/arm/dts/fsl-ls1043a.dtsi +++ b/arch/arm/dts/fsl-ls1043a.dtsi @@ -31,7 +31,7 @@ interrupts = <1 9 0xf08>; }; - soc { + soc: soc { compatible = "simple-bus"; #address-cells = <2>; #size-cells = <2>; -- 2.1.0
Re: [PATCH] tools: k3_gen_x509_cert: Allow selecting early JTAG debug value
On 4/23/20 2:38 AM, Lokesh Vutla wrote: > > > On 22/04/20 10:39 PM, Andrew F. Davis wrote: >> When authenticating the initial boot binary the ROM will check a debug >> type value in the certificate and based on that open JTAG access to that >> core. >> >> The default is currently full access, on HS this is useful for early >> developers, but should not be the default as to prevent end system >> integrators from unintentionally leaving this open. > > Won't JTAG access is useful for early developers. UART as well not available > at > this point. What we offer out of the box is not a production ready secure > system. I would prefer to have it enabled by default. > Who are these early developers? Pre-SYSFW on HS is a harsh environment, firewalls and other pitfalls limit one to only what is needed to get SYSFW loaded. Only a handful of folks will ever touch the source this early, and they will be using a GP device for that development, in which case debug is enabled, even with this change. I'd guess I'm the only developer touching code this early on HS, I say this as so far I'm the only one who has noticed that there is a ROM issue that makes early debug on HS almost unusable. Accidentally leaving this open completely defeats the chain of trust, I guarantee some production system will do this if we leave JTAG open by default, it happens all the time. So debug doesn't work here anyway, no one uses it and those who do can flip this bit with the command line flag, and leaving it on will lead to a huge security issue for one of our customers. Andrew > Thanks and regards, > Lokesh > >> >> On non-HS devices JTAG is left open anyway so this does not change >> behavior on those devices. Change the default to off and allow it to be >> switched back on by command line flag if needed. >> >> Signed-off-by: Andrew F. Davis >> --- >> tools/k3_gen_x509_cert.sh | 14 +++--- >> 1 file changed, 11 insertions(+), 3 deletions(-) >> >> diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh >> index b6d055f6f5..298cec1313 100755 >> --- a/tools/k3_gen_x509_cert.sh >> +++ b/tools/k3_gen_x509_cert.sh >> @@ -12,6 +12,7 @@ RAND_KEY=eckey.pem >> LOADADDR=0x41c0 >> BOOTCORE_OPTS=0 >> BOOTCORE=16 >> +DEBUG_TYPE=0 >> >> gen_degen_template() { >> cat << 'EOF' > degen-template.txt >> @@ -79,7 +80,7 @@ cat << 'EOF' > x509-template.txt >> >> [ debug ] >> debugUID = >> FORMAT:HEX,OCT: >> - debugType = INTEGER:4 >> + debugType = INTEGER:TEST_DEBUG_TYPE >> coreDbgEn = INTEGER:0 >> coreDbgSecEn = INTEGER:0 >> EOF >> @@ -151,8 +152,9 @@ options_help[k]="key_file:file with key inside it. If >> not provided script genera >> options_help[o]="output_file:Name of the final output file. default to >> $OUTPUT" >> options_help[c]="core_id:target core id on which the image would be >> running. Default to $BOOTCORE" >> options_help[l]="loadaddr: Target load address of the binary in hex. >> Default to $LOADADDR" >> +options_help[d]="debug_type: Debug type, set to 4 to enable early JTAG. >> Default to $DEBUG_TYPE" >> >> -while getopts "b:k:o:c:l:h" opt >> +while getopts "b:k:o:c:l:d:h" opt >> do >> case $opt in >> b) >> @@ -170,6 +172,9 @@ do >> c) >> BOOTCORE=$OPTARG >> ;; >> +d) >> +DEBUG_TYPE=$OPTARG >> +;; >> h) >> usage >> exit 0 >> @@ -224,12 +229,15 @@ gen_cert() { >> #echo " LOADADDR = 0x$ADDR" >> #echo " IMAGE_SIZE = $BIN_SIZE" >> #echo " CERT_TYPE = $CERTTYPE" >> +#echo " DEBUG_TYPE = $DEBUG_TYPE" >> sed -e "s/TEST_IMAGE_LENGTH/$BIN_SIZE/" \ >> -e "s/TEST_IMAGE_SHA_VAL/$SHA_VAL/" \ >> -e "s/TEST_CERT_TYPE/$CERTTYPE/" \ >> -e "s/TEST_BOOT_CORE_OPTS/$BOOTCORE_OPTS/" \ >> -e "s/TEST_BOOT_CORE/$BOOTCORE/" \ >> --e "s/TEST_BOOT_ADDR/$ADDR/" x509-template.txt > $TEMP_X509 >> +-e "s/TEST_BOOT_ADDR/$ADDR/" \ >> +-e "s/TEST_DEBUG_TYPE/$DEBUG_TYPE/" \ >> +x509-template.txt > $TEMP_X509 >> openssl req -new -x509 -key $KEY -nodes -outform DER -out $CERT -config >> $TEMP_X509 -sha512 >> } >> >>
Re: [PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu
On Thu, Apr 23, 2020 at 09:34:26AM +0200, Pali Rohár wrote: > On Tuesday 21 April 2020 19:24:57 Tom Rini wrote: > > On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Rohár wrote: > > > Ok, so is something needed to do with this patch? > > > > Yes, re-order where the .travis.yml hunk is and add a similar part to > > .gitlab-ci.yml and .azure-ci.yml. > > Hello Tom! I have looked at .travis.yml again, but I do not understand > what do you mean by re-order. I really have no idea where you want to > move that rx51_test.sh hunk. Could you describe it? This should go around where we check tools-only/envtools. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support
On Wed, Apr 22, 2020 at 10:03:41PM -0400, Sean Anderson wrote: > On 4/22/20 9:51 PM, Rick Chen wrote: > > Hi Sean > > > >> Hi Sean > >> > >>> This patch series adds support for Sipeed Maix boards and the Kendryte > >>> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other > >>> models are similar. > >>> > >>> Known Bugs/Limitations: > >>> - Accessing the AI ram hangs, limiting available ram to 6M > >>> - Trying to boot an image with bootm fails with > >>> ERROR: Failed to allocate 0x7d60 bytes below 0x8000. > >>> > >>> To flash u-boot to a maix bit, run > >>> kflash -tp /dev/ -B bit_mic u-boot-dtb.bin > >>> > >>> Boot output should look like the following: > >>> > >>> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500) > >>> > >>> DRAM: 8 MiB > >>> In:serial@3800 > >>> Out: serial@3800 > >>> Err: serial@3800 > >>> => > >>> > >>> Changes for v8: > >>> - Removed dependency on the patch "clk: Add functions to register CCF > >>> clock > >>> structs". Hopefully this will make reviewing easier. > >> > >> I have applied this patch series to u-boot-riscv/master except [PATCH > >> v8 14/21] riscv: Clean up IPI initialization code. > >> Because it will cause some warnings as below: > >> > >> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi': > >> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes > >> integer from pointer without a cast [-Wint-conversion] > >> int ret = syscon_get_first_range(RISCV_SYSCON_PLIC); > >> ^~ > >> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of > >> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion] > >> if (IS_ERR(ret)) > >> ^~~ > >> In file included from arch/riscv/lib/andes_plic.c:20:0: > >> include/linux/err.h:34:20: note: expected 'const void *' but argument > >> is of type 'int' > >> static inline long IS_ERR(const void *ptr) > >> ^~ > >> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of > >> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion] > >>return PTR_ERR(ret); > >> ^~~ > >> In file included from arch/riscv/lib/andes_plic.c:20:0: > >> include/linux/err.h:29:20: note: expected 'const void *' but argument > >> is of type 'int' > >> static inline long PTR_ERR(const void *ptr) > >> ^~~ > >> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer > >> from integer without a cast [-Wint-conversion] > >> gd->arch.plic = ret; > >> > > > > after running CI yesterday, it failed in many cases: > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975 > > > > and I trace at least two cases belong to your patch > > 49.59 > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035 > > > > arning, treated as error: > > /home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error > > in "code-block" directive: > > 1 argument(s) required, 0 supplied. > > .. code-block:: > > { > > assigned-clocks = < K210_CLK_PLL0>; > > assigned-clock-rates = <8>; > > }; > > doc/Makefile:69: recipe for target 'htmldocs' failed > > make[1]: *** [htmldocs] Error 1 > > I used to have > > .. code-block:: dts > > but it warned that "dts" was not a valid language, so I dropped it. > > > 49.66 > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042 > > > > ./tools/patman/patman --test && ./tools/buildman/buildman -t && > > ./tools/dtoc/dtoc -t && make testconfig; fi; fi > > cp: cannot create regular file > > '/home/travis/build/rickchen36/sandbox/': Not a directory > > cp: cannot create regular file > > '/home/travis/build/rickchen36/sandbox/': Not a directory > > WARNING: no status info for 'sipeed_maix_bitm' > > WARNING: no maintainers for 'sipeed_maix_bitm' > > I'm not sure what the issue here is. Which specific files are lacking a > MAINTAINERS entry? configs/sipeed_maix_bitm_defconfig isn't listed in any MAINTAINERS file. [snip] > These "errors" seem rather minor. I will fix the PLIC ones in the next > revision, but I don't think the sort found in this email are > particularly erroneous. They aren't minor. Not having the defconfig have a listed MAINTAINER means I don't know who to contact later on when something needs to be migrated, etc. Not having the documentation be generated cleanly is a problem because we're trying to improve our documentation as that's helpful for end users. Thanks! > > --Sean > -- Tom signature.asc Description: PGP signature
Re: rk3399 single channel lpddr4 setup
On Tue, Apr 21, 2020 at 7:54 PM Jack Mitchell wrote: > > Has anyone worked with an rk3399 based board with a single channel RAM > setup? I've looked at the current code and made some changes for only > setting up a single channel which basically consists of altering the > loops down to one channel, however u-boot is hanging while checking for > a successful frequency change here: > > >/* change freq */ > >writel0x3 << 4) | (1 << 2) | 1) << 16) | > > (fn << 4) | (1 << 2) | 1, >cic->cic_ctrl0); > >while (!(readl(>cic->cic_status0) & (1 << 2))) > >; > > > > I believe this is due to waiting for both channels to switch frequency > which will never happen as there is only a single channel setup. > > Has anyone worked with a similar setup, or have any further > documentation as the TRM only has a fairly basic register listing. I have tried single-channel with DDR3 which is present on NOE4, I believe the existing code does handle single channel for LPDDR4, can you enable debugs and check on existing code. Usually the code cannot go and try channel 1. Jagan.
Re: support of rockchip nanopiM4 2GB board
On Thu, Apr 23, 2020 at 4:37 PM Deepak Das wrote: > > Hi Jagan, > > upstream uboot has the support for nanopi M4 board with 4GB LPDDR3 RAM. > I have a nanopi M4 board with 2GB DDR3 RAM and able to boot this board > by using ddr3 configuration. > > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2019 Jagan Teki > + */ > + > +#include "rk3399-nanopi4-u-boot.dtsi" > +#include "rk3399-sdram-ddr3-1866.dtsi" > + > +/* #include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi" */ > > how to handle this situation? do we need to treat this as a new board > support? Possible approach is to check the chip type and vendor during probe and source the respective .dtsi YouMin and Kever, any ideas? Jagan.
Re: [PATCH 0/3] ARM: Fix reset in SPL if SYSRESET is not used
On 23.04.20 13:18, Harald Seiler wrote: > Hello, > > On Wed, 2020-03-04 at 15:23 +0100, Harald Seiler wrote: >> Hello, >> >> continuing on the discussion around Claudius' patch for fixing reset in SPL >> [1] >> we have taken a closer look at the issue. To quickly summarize the >> situation: >> >> The original patch was to enable the generic ARM implementation of >> `do_reset` if CONFIG_SYSRESET is not enabled in SPL. This would break >> compilation for some boards which define their own `do_reset` in >> `board/*/spl.c`. >> >> To be more specific, the following 4 boards have this custom `do_reset`: >> >> - toradex/verdin-imx8mm >> - freescale/imx8mn_evk >> - freescale/imx8mm_evk >> - freescale/imx8mp_evk >> >> I hope we can all agree that `do_reset` is not at all meant to be implemented >> in board files. From looking at the related code for imx8m, it feels like >> this >> was just a workaround hack to archieve the same thing which Claudius has >> fixed. >> So this patch series reverts the addition of `do_reset` implementations in >> imx8m board files and instead switches to using the proper fix provided by >> Claudius. >> >> >> Additionally, the custom do_reset implementations were passing an address >> (WDOG1_BASE_ADDR) to `reset_cpu()` instead of 0. This is the only place in >> the >> entire U-Boot tree where this happens. Instead, all other implementations >> simply ignore the parameter and 0 is passed by callers. It looks a lot like >> this is a legacy left-over which makes me think that using it for a >> (hard-coded) >> watchdog address is not a good idea as it breaks convention with the rest of >> U-Boot. >> >> [1]: https://patchwork.ozlabs.org/patch/1201959 >> >> Claudius Heine (3): >> ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for >> them >> imx: imx8m*: Remove do_reset from board files >> imx: imx8m: Don't use the addr parameter of reset_cpu >> >> arch/arm/lib/Makefile | 2 +- >> arch/arm/mach-imx/imx8m/soc.c | 5 + >> board/freescale/imx8mm_evk/spl.c | 9 - >> board/freescale/imx8mn_evk/spl.c | 9 - >> board/freescale/imx8mp_evk/spl.c | 9 - >> board/toradex/verdin-imx8mm/spl.c | 9 - >> 6 files changed, 2 insertions(+), 41 deletions(-) >> > > Quick question, what is the situation with this series? Is there anything > which needs to be addressed? Patches are fine IMHO - I will merge them soon. Stefano > > Without it, CONFIG_SPL_USB_SDP_SUPPORT is broken on the imx6q hardware > I am working with and I guess the same issue might exist on many other > boards as well (The USB stack needs a do_reset() implementation in SPL). > > Regards, > -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH 0/3] ARM: Fix reset in SPL if SYSRESET is not used
Hello, On Wed, 2020-03-04 at 15:23 +0100, Harald Seiler wrote: > Hello, > > continuing on the discussion around Claudius' patch for fixing reset in SPL > [1] > we have taken a closer look at the issue. To quickly summarize the situation: > > The original patch was to enable the generic ARM implementation of > `do_reset` if CONFIG_SYSRESET is not enabled in SPL. This would break > compilation for some boards which define their own `do_reset` in > `board/*/spl.c`. > > To be more specific, the following 4 boards have this custom `do_reset`: > > - toradex/verdin-imx8mm > - freescale/imx8mn_evk > - freescale/imx8mm_evk > - freescale/imx8mp_evk > > I hope we can all agree that `do_reset` is not at all meant to be implemented > in board files. From looking at the related code for imx8m, it feels like > this > was just a workaround hack to archieve the same thing which Claudius has > fixed. > So this patch series reverts the addition of `do_reset` implementations in > imx8m board files and instead switches to using the proper fix provided by > Claudius. > > > Additionally, the custom do_reset implementations were passing an address > (WDOG1_BASE_ADDR) to `reset_cpu()` instead of 0. This is the only place in > the > entire U-Boot tree where this happens. Instead, all other implementations > simply ignore the parameter and 0 is passed by callers. It looks a lot like > this is a legacy left-over which makes me think that using it for a > (hard-coded) > watchdog address is not a good idea as it breaks convention with the rest of > U-Boot. > > [1]: https://patchwork.ozlabs.org/patch/1201959 > > Claudius Heine (3): > ARM: reset: use do_reset in SPL/TPL if SYSRESET was not enabled for > them > imx: imx8m*: Remove do_reset from board files > imx: imx8m: Don't use the addr parameter of reset_cpu > > arch/arm/lib/Makefile | 2 +- > arch/arm/mach-imx/imx8m/soc.c | 5 + > board/freescale/imx8mm_evk/spl.c | 9 - > board/freescale/imx8mn_evk/spl.c | 9 - > board/freescale/imx8mp_evk/spl.c | 9 - > board/toradex/verdin-imx8mm/spl.c | 9 - > 6 files changed, 2 insertions(+), 41 deletions(-) > Quick question, what is the situation with this series? Is there anything which needs to be addressed? Without it, CONFIG_SPL_USB_SDP_SUPPORT is broken on the imx6q hardware I am working with and I guess the same issue might exist on many other boards as well (The USB stack needs a do_reset() implementation in SPL). Regards, -- Harald
[PATCH 5/5] imx: spl: Fix use of removed SPL_FAT_SUPPORT config
CONFIG_SPL_FAT_SUPPORT was removed in commit 0c3a9ed409a5 ("spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT"). Fixup a leftover use of the symbol. Fixes: 9d86dbd9cf9d ("imx: spl: implement spl_boot_mode for i.MX7/8/8M") Signed-off-by: Harald Seiler --- arch/arm/mach-imx/spl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 32d78b799c36..fd3fa046002a 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -197,14 +197,14 @@ u32 spl_mmc_boot_mode(const u32 boot_device) case SD1_BOOT: case SD2_BOOT: case SD3_BOOT: - if (IS_ENABLED(CONFIG_SPL_FAT_SUPPORT)) + if (IS_ENABLED(CONFIG_SPL_FS_FAT)) return MMCSD_MODE_FS; else return MMCSD_MODE_RAW; case MMC1_BOOT: case MMC2_BOOT: case MMC3_BOOT: - if (IS_ENABLED(CONFIG_SPL_FAT_SUPPORT)) + if (IS_ENABLED(CONFIG_SPL_FS_FAT)) return MMCSD_MODE_FS; else if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) return MMCSD_MODE_EMMCBOOT; -- 2.26.1
[PATCH 0/5] Fix spl_mmc_boot_mode() implementation for IMX
The spl_mmc_boot_mode() (formerly spl_boot_mode()) implementation for IMX has grown quite big over time [1]. It has also started to steer away from what it is meant to do in its current form and breaks some use-cases of the SPL. Namely, the issue is that nowadays SPL can attempt loading U-Boot from multiple MMC devices and this function needs to return the correct mode for each one which it currently does not. There have been multiple attempts to fix this in the past, starting with a (rejected) patch from Anatolij [2]. Most recently, a patch from Lukasz [3] was merged which introduces a config option CONFIG_SPL_FORCE_MMC_BOOT. I think this is going in the wrong direction when the real solution lies in cutting the function back down as much as possible. IMX currently has the biggest implementation in the tree and I don't really see a reason why all that complexity is necessary. I have spend some time to find out the full story here and have summarized that in a previous mail [4]. To cut it as short as possible: I believe CONFIG_SPL_FORCE_MMC_BOOT is superfluous as enabling it is the only correct behavior and CONFIG_SPL_FORCE_MMC_BOOT=n is faulty and will lead to problems when customizing the SPL boot sequence e.g. using board_boot_order(). Thus, this series contains Anatolij's original patch, reverts the introduction of CONFIG_SPL_FORCE_MMC_BOOT and cleans up the implementation a bit. One thing which is left out, which still needs to happen in the future is getting rid of the big #if for IMX{7,8,8M}. I don't have hardware to test IMX7 or 8 right now and haven't looked too deep into what needs to be done here. I'm pretty certain this series should not break any use-case and if it does anyway, a breakage caused by it indicates the need to fix SPL configuration for that board. I'm happy to help with that if the need arises. [1]: https://gitlab.denx.de/u-boot/u-boot/-/blob/v2020.04/arch/arm/mach-imx/spl.c#L192-251 [2]: https://patchwork.ozlabs.org/patch/796237/ [3]: https://gitlab.denx.de/u-boot/u-boot/-/commit/772b55723bcbe8ebe84f579d9cdc831d8e18579d [4]: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html Anatolij Gustschin (1): imx: spl: return boot mode for asked MMC device in spl_mmc_boot_mode() Harald Seiler (4): Revert "imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode" Revert "imx: defconfig: Enable CONFIG_SPL_FORCE_MMC_BOOT" imx: spl: Remove ifdefs in spl_mmc_boot_mode() imx: spl: Fix use of removed SPL_FAT_SUPPORT config arch/arm/mach-imx/spl.c | 49 - common/spl/Kconfig | 9 --- configs/display5_defconfig | 1 - configs/imx28_xea_defconfig | 1 - 4 files changed, 16 insertions(+), 44 deletions(-) -- 2.26.1
[PATCH 1/5] imx: spl: return boot mode for asked MMC device in spl_mmc_boot_mode()
From: Anatolij Gustschin Boards may extend or re-define the boot list in their board_boot_order() function by modifying spl_boot_list. E.g. a board might boot SPL from a slow SPI NOR flash and then load the U-Boot from an eMMC or SD-card. Or it might use additional MMC boot device in spl_boot_list for cases when the image in SPI NOR flash is not found, so it could fall back to eMMC, SD-card or another boot device. Getting the MMC boot mode in spl_mmc will fail when we are trying to boot from an MMC device in the spl_boot_list and the original board boot mode (as returned by spl_boot_device()) is not an MMC boot mode. Fix it by checking the asked MMC boot device from the spl_mmc_boot_mode() argument. Signed-off-by: Anatolij Gustschin --- arch/arm/mach-imx/spl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 49bb3b928da1..e5835150a06d 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -229,7 +229,7 @@ u32 spl_mmc_boot_mode(const u32 boot_device) #ifdef CONFIG_SPL_FORCE_MMC_BOOT switch (boot_device) { #else - switch (spl_boot_device()) { + switch (boot_device) { #endif /* for MMC return either RAW or FAT mode */ case BOOT_DEVICE_MMC1: -- 2.26.1
[PATCH 3/5] Revert "imx: defconfig: Enable CONFIG_SPL_FORCE_MMC_BOOT"
CONFIG_SPL_FORCE_MMC_BOOT was removed in a previous patch as its behavior is the correct one in all cases. Remove all uses of it from defconfigs. This reverts commit 3201e5b444ae3a13aa31e8b5101ad38d7ff0640d and removes CONFIG_SPL_FORCE_MMC_BOOT from the imx28_xea defconfig. Signed-off-by: Harald Seiler --- configs/display5_defconfig | 1 - configs/imx28_xea_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/configs/display5_defconfig b/configs/display5_defconfig index 9026c17f3fb5..f982191f7f53 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -38,7 +38,6 @@ CONFIG_SPL_DMA=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_SAVEENV=y CONFIG_SPL_I2C_SUPPORT=y -CONFIG_SPL_FORCE_MMC_BOOT=y CONFIG_SPL_OS_BOOT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x2 diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig index 2d49b664deae..79fa08bbab2b 100644 --- a/configs/imx28_xea_defconfig +++ b/configs/imx28_xea_defconfig @@ -28,7 +28,6 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0 CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG=y CONFIG_SPL_DMA=y -CONFIG_SPL_FORCE_MMC_BOOT=y CONFIG_SPL_MMC_TINY=y CONFIG_SPL_OS_BOOT=y CONFIG_SPL_PAYLOAD="u-boot.img" -- 2.26.1
[PATCH 4/5] imx: spl: Remove ifdefs in spl_mmc_boot_mode()
It is hard to read code which contains nested ifdef blocks. Replace them with normal if-blocks and the IS_ENABLED() macro. This is not only more readable but also helps as both arms are validated by the compiler in all cases. Signed-off-by: Harald Seiler --- arch/arm/mach-imx/spl.c | 38 -- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index e3f51e45edf2..32d78b799c36 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -197,23 +197,19 @@ u32 spl_mmc_boot_mode(const u32 boot_device) case SD1_BOOT: case SD2_BOOT: case SD3_BOOT: -#if defined(CONFIG_SPL_FAT_SUPPORT) - return MMCSD_MODE_FS; -#else - return MMCSD_MODE_RAW; -#endif - break; + if (IS_ENABLED(CONFIG_SPL_FAT_SUPPORT)) + return MMCSD_MODE_FS; + else + return MMCSD_MODE_RAW; case MMC1_BOOT: case MMC2_BOOT: case MMC3_BOOT: -#if defined(CONFIG_SPL_FAT_SUPPORT) - return MMCSD_MODE_FS; -#elif defined(CONFIG_SUPPORT_EMMC_BOOT) - return MMCSD_MODE_EMMCBOOT; -#else - return MMCSD_MODE_RAW; -#endif - break; + if (IS_ENABLED(CONFIG_SPL_FAT_SUPPORT)) + return MMCSD_MODE_FS; + else if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) + return MMCSD_MODE_EMMCBOOT; + else + return MMCSD_MODE_RAW; default: puts("spl: ERROR: unsupported device\n"); hang(); @@ -224,14 +220,12 @@ u32 spl_mmc_boot_mode(const u32 boot_device) case BOOT_DEVICE_MMC1: case BOOT_DEVICE_MMC2: case BOOT_DEVICE_MMC2_2: -#if defined(CONFIG_SPL_FS_FAT) - return MMCSD_MODE_FS; -#elif defined(CONFIG_SUPPORT_EMMC_BOOT) - return MMCSD_MODE_EMMCBOOT; -#else - return MMCSD_MODE_RAW; -#endif - break; + if (IS_ENABLED(CONFIG_SPL_FS_FAT)) + return MMCSD_MODE_FS; + else if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) + return MMCSD_MODE_EMMCBOOT; + else + return MMCSD_MODE_RAW; default: puts("spl: ERROR: unsupported device\n"); hang(); -- 2.26.1
[PATCH 2/5] Revert "imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode"
The CONFIG_SPL_FORCE_MMC_BOOT config flag is not needed as its behavior is the correct one in all cases; using spl_boot_device() instead of the boot_device parameter will lead to inconsistency issues, for example, when a board_boot_order() is defined. In fact, this is the reason the parameter was introduced in the first place, in commit 2b1cdafa9fdd ("common: Pass the boot device into spl_boot_mode()"). This reverts commit 772b55723bcbe8ebe84f579d9cdc831d8e18579d. Link: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html Signed-off-by: Harald Seiler --- arch/arm/mach-imx/spl.c | 11 --- common/spl/Kconfig | 9 - 2 files changed, 20 deletions(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index e5835150a06d..e3f51e45edf2 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -219,18 +219,7 @@ u32 spl_mmc_boot_mode(const u32 boot_device) hang(); } #else -/* - * When CONFIG_SPL_FORCE_MMC_BOOT is defined the 'boot_device' is used - * unconditionally to decide about device to use for booting. - * This is crucial for falcon boot mode, when board boots up (i.e. ROM - * loads SPL) from slow SPI-NOR memory and afterwards the SPL's 'falcon' boot - * mode is used to load Linux OS from eMMC partition. - */ -#ifdef CONFIG_SPL_FORCE_MMC_BOOT switch (boot_device) { -#else - switch (boot_device) { -#endif /* for MMC return either RAW or FAT mode */ case BOOT_DEVICE_MMC1: case BOOT_DEVICE_MMC2: diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 9d52b75cb434..344fb8003f63 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -669,15 +669,6 @@ config SPL_MMC_SUPPORT this option to build the drivers in drivers/mmc as part of an SPL build. -config SPL_FORCE_MMC_BOOT - bool "Force SPL booting from MMC" - depends on SPL_MMC_SUPPORT - default n - help - Force SPL to use MMC device for Linux kernel booting even when the - SoC ROM recognized boot medium is not eMMC/SD. This is crucial for - factory or 'falcon mode' booting. - config SPL_MMC_TINY bool "Tiny MMC framework in SPL" depends on SPL_MMC_SUPPORT -- 2.26.1
support of rockchip nanopiM4 2GB board
Hi Jagan, upstream uboot has the support for nanopi M4 board with 4GB LPDDR3 RAM. I have a nanopi M4 board with 2GB DDR3 RAM and able to boot this board by using ddr3 configuration. +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019 Jagan Teki + */ + +#include "rk3399-nanopi4-u-boot.dtsi" +#include "rk3399-sdram-ddr3-1866.dtsi" + +/* #include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi" */ how to handle this situation? do we need to treat this as a new board support? regards, Deepak
Re: [RESEND PATCH v3 0/7] x86: Improve support for chain-loading U-Boot
Hi Simon, On Thu, Apr 9, 2020 at 2:58 AM Simon Glass wrote: > > This little series adds a few checks into the code to allow better > operation when booting a build from a previous-state loader such as > coreboot. > > At present we have a 'coreboot' target but this runs very different code > from the bare-metal targets, such as coral. There is very little in common > between them. > > It is useful to be able to boot the same U-Boot on a device, with or > without a first-stage bootloader. For example, with chromebook_coral, it > is helpful for testing to be able to boot the same U-Boot (complete with > FSP) on bare metal and from coreboot. It allows checking of things like > CPU speed, comparing registers, ACPI tables and the like. > > This series allows U-Boot to detect that it ran from coreboot and > automatically do the right thing. > > This series makes the most important changes to allow the same u-boot.bin > for coral to boot after coreboot (by itself) or bare metal (via TPL->SPL). > > Changes in v3: > - Add a new patch with a gd flag for chain loading > - Add new patch to detect running from coreboot Sorry it took me some time to have a look at this series. I have some comments against 5 & 6. Could you please update doc/arch/x86.rst for the purpose and usage of the chain loading? Regards, Bin
Re: [RESEND PATCH v3 6/7] x86: Add a way to detect running from coreboot
Hi Simon, On Thu, Apr 9, 2020 at 2:58 AM Simon Glass wrote: > > If U-Boot is running from coreboot we need to skip low-level init. Add > an way to detect this and to set the gd flag. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Add new patch to detect running from coreboot > > Changes in v2: None > > arch/x86/cpu/i386/cpu.c | 15 +++ > arch/x86/include/asm/u-boot-x86.h | 7 +++ > 2 files changed, 22 insertions(+) > > diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c > index c8da7f10e9b..e43444c090b 100644 > --- a/arch/x86/cpu/i386/cpu.c > +++ b/arch/x86/cpu/i386/cpu.c > @@ -447,10 +447,25 @@ int x86_cpu_init_f(void) > return 0; > } > > +bool x86_detect_coreboot(void) > +{ > + u32 *ptr, *end; > + > + /* We look for LBIO in the first 4K of RAM */ > + for (ptr = NULL, end = ptr + 0x400; ptr < end; ptr += 4) { The logic here is not exactly the same as cb_parse_header(). I believe we should be consistent. > + if (*ptr == 0x4f49424c) /* "LBIO" */ > + return true; > + } > + > + return false; > +} > + > int x86_cpu_reinit_f(void) > { > setup_identity(); > setup_pci_ram_top(); > + if (x86_detect_coreboot()) > + gd->flags |= GD_FLG_NO_LL_INIT; > > return 0; > } > diff --git a/arch/x86/include/asm/u-boot-x86.h > b/arch/x86/include/asm/u-boot-x86.h > index 3e5d56d0757..654880f91cb 100644 > --- a/arch/x86/include/asm/u-boot-x86.h > +++ b/arch/x86/include/asm/u-boot-x86.h > @@ -43,6 +43,13 @@ int x86_cpu_reinit_f(void); > */ > int x86_cpu_init_tpl(void); > > +/** > + * x86_detect_coreboot() - See if U-Boot is being started from coreboot > + * > + * @return true if coreboot is running, false if U-Boot is running > 'bare-metal' > + */ > +bool x86_detect_coreboot(void); > + > int cpu_init_f(void); > void setup_gdt(struct global_data *id, u64 *gdt_addr); > /* > -- Regards, Bin
Re: [RESEND PATCH v3 5/7] board: Add a gd flag for chain loading
Hi Simon, On Thu, Apr 9, 2020 at 2:58 AM Simon Glass wrote: > > When U-Boot is run from another boot loader, much of the low-level init > needs to be skipped. > > Add a flag for this and adjust ll_boot_init() to use it. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Add a new patch with a gd flag for chain loading > > Changes in v2: None > > include/asm-generic/global_data.h | 1 + > include/init.h| 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/asm-generic/global_data.h > b/include/asm-generic/global_data.h > index 5d027329fe0..3dc51e49ef7 100644 > --- a/include/asm-generic/global_data.h > +++ b/include/asm-generic/global_data.h > @@ -166,5 +166,6 @@ typedef struct global_data { > #define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done */ > #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */ > #define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */ > +#define GD_FLG_NO_LL_INIT 0x2 /* Don't perform low-level init*/ How about GD_FLG_SKIP_LL_INIT ? > > #endif /* __ASM_GENERIC_GBL_DATA_H */ > diff --git a/include/init.h b/include/init.h > index 2a33a3fd1e4..64fdf124916 100644 > --- a/include/init.h > +++ b/include/init.h > @@ -20,7 +20,7 @@ struct global_data; > #ifdef CONFIG_EFI_STUB > #define ll_boot_init() false > #else > -#define ll_boot_init() true > +#define ll_boot_init() (!(gd->flags & GD_FLG_NO_LL_INIT)) > #endif Regards, Bin
Re: [PATCH] riscv: Move all SMP related SBI calls to SBI_v01
On Wed, Apr 22, 2020 at 5:52 AM Atish Patra wrote: > > SMP support for S-mode U-Boot is enabled only if SBI_V01 is enabled. > There is no point in supporting SMP related (IPI and fences) SBI calls > when SBI_V02 is enabled. > > Modify all the SMP related SBI calls to be defined only for SBI_V01. > > Signed-off-by: Atish Patra > --- > arch/riscv/include/asm/sbi.h | 5 ++--- > arch/riscv/lib/sbi.c | 37 ++-- > 2 files changed, 20 insertions(+), 22 deletions(-) > Reviewed-by: Bin Meng
RE: [PATCH] configs: ls1021a: Append CMA configuration to bootargs
>-Original Message- >From: Alison Wang >Sent: Thursday, April 23, 2020 6:12 AM >To: u-boot@lists.denx.de; Priyanka Jain ; Jagdish >Gediya >Cc: Shengzhou Liu >Subject: [PATCH] configs: ls1021a: Append CMA configuration to bootargs > >According to commit , this patch appends CMA configuration >to bootargs for LS1021ATWR. > Please mention what this patch is doing (as a fresh patch). No need to mention relation with previous commit. Regards Priyanka
RE: [v3] include/configs: ls1012afrwy: support dhcp boot
>-Original Message- >From: Biwen Li >Sent: Wednesday, April 22, 2020 3:37 PM >To: Jagdish Gediya ; Priyanka Jain >; Pramod Kumar >Cc: Alison Wang ; u-boot@lists.denx.de; Jiafei Pan >; Biwen Li >Subject: [v3] include/configs: ls1012afrwy: support dhcp boot > >From: Biwen Li > >Add support of dhcp boot for ls1012afrwy > >Signed-off-by: Biwen Li >--- >Change in v3: > - update description > >Change in v2: > - update subject > - recover original macro > - add dhcp boot > > include/configs/ls1012afrwy.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h >index 6143e9731e..de686891a9 100644 >--- a/include/configs/ls1012afrwy.h >+++ b/include/configs/ls1012afrwy.h >@@ -33,7 +33,8 @@ > #undef BOOT_TARGET_DEVICES > #define BOOT_TARGET_DEVICES(func) \ > func(MMC, mmc, 0) \ >- func(USB, usb, 0) >+ func(USB, usb, 0) \ >+ func(DHCP, dhcp, na) > #endif > > #undef FSL_QSPI_FLASH_SIZE >-- >2.17.1 Reviewed-by: Priyanka Jain
Re: [PATCH v7 0/9] dm: Add programmatic generation of ACPI tables (part A)
Hi Simon, On Thu, Apr 23, 2020 at 5:46 PM Bin Meng wrote: > > Hi Simon, > > On Wed, Apr 22, 2020 at 5:37 AM Simon Glass wrote: > > > > Hi Andy, > > > > On Tue, 21 Apr 2020 at 11:43, Andy Shevchenko > > wrote: > > > > > > On Sun, Apr 19, 2020 at 02:36:48PM -0600, Simon Glass wrote: > > > > This is split from the original series in an attempt to get things > > > > applied > > > > in chunks. > > > > > > > > v7 is just a rebase as requested > > > > > > So, overall I have no concerns, except that compatible string in ACPI > > > seems > > > half-baked solution and, due to PRP0001 awareness (my understanding that > > > it > > > should not be part of production devices), seems not needed right now. > > > It means we should require to have _HID and/or _CID. > > > > OK I am really not sure what to say about this. Let's deal with it > > when we see the use of it later. > > > > > > > > Code looks fine to me, though. > > > > > > > OK good. I will send part B soon. > > > > v7 has been applied to u-boot-x86, thanks! > Unfortunately this series breaks sandbox_spl, please take a look. https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/81615 Regards, Bin
Re: [PATCH v7 0/9] dm: Add programmatic generation of ACPI tables (part A)
Hi Simon, On Wed, Apr 22, 2020 at 5:37 AM Simon Glass wrote: > > Hi Andy, > > On Tue, 21 Apr 2020 at 11:43, Andy Shevchenko > wrote: > > > > On Sun, Apr 19, 2020 at 02:36:48PM -0600, Simon Glass wrote: > > > This is split from the original series in an attempt to get things applied > > > in chunks. > > > > > > v7 is just a rebase as requested > > > > So, overall I have no concerns, except that compatible string in ACPI seems > > half-baked solution and, due to PRP0001 awareness (my understanding that it > > should not be part of production devices), seems not needed right now. > > It means we should require to have _HID and/or _CID. > > OK I am really not sure what to say about this. Let's deal with it > when we see the use of it later. > > > > > Code looks fine to me, though. > > > > OK good. I will send part B soon. > v7 has been applied to u-boot-x86, thanks! Regards, Bin
Re: [PATCH v7 7/9] acpi: Put table-setup code in its own function
Hi Simon, Wolfgang, On Mon, Apr 20, 2020 at 4:37 AM Simon Glass wrote: > > We always write three basic tables to ACPI at the start. Move this into > its own function, along with acpi_fill_header(), so we can write a test > for this code. > > Signed-off-by: Simon Glass I see Wolfgang gave a RB tag to the v5 patch, so I am going to add that tag here since no changes between v5 and v7 Reviewed-by: Wolfgang Wallner But I wonder why this new series is tagged as v7. Do I miss v6? > --- > > Changes in v7: None > Changes in v5: None > Changes in v4: > - Put back cast on table_compute_checksum() > > Changes in v3: > - Fix 'XDST' typo > - Move acpi_align_large() out of dm_test_acpi_setup_base_tables() > - Beef up the comment explaining how the unaligned address is used > > Changes in v2: None > > arch/x86/lib/acpi_table.c | 72 +--- > include/acpi/acpi_table.h | 10 + > lib/acpi/acpi_table.c | 77 +++ > test/dm/acpi.c| 58 - > 4 files changed, 144 insertions(+), 73 deletions(-) > Regards, Bin
Re: [PATCH 4/6] x86: cbfs: Drop unwanted declaration
On Thu, Apr 23, 2020 at 5:19 PM Bin Meng wrote: > > On Mon, Apr 6, 2020 at 7:22 AM Simon Glass wrote: > > > > The intention here is add a forward declaration, not actually declare a > > variable. Fix it. > > > > Signed-off-by: Simon Glass > > --- > > > > include/cbfs.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng This patch is irrelevant to 64-bit coreboot payload support. applied to u-boot-x86, thanks!
Re: [PATCH 6/6] x86: Add a 64-bit coreboot build
Hi Simon, On Mon, Apr 6, 2020 at 7:22 AM Simon Glass wrote: > > Add a build for running 64-bit U-Boot from coreboot (which is 32-bit). > This uses binman to create an image with a 32-bit SPL and a 64-bit U-Boot. > > Coreboot boots into SPL and then SPL boots into U-Boot. > > This allows running 64-bit EFI images on x86. > Signed-off-by: Simon Glass > --- > > board/coreboot/coreboot/MAINTAINERS | 7 + > configs/coreboot64_defconfig| 48 + > doc/board/coreboot/coreboot.rst | 10 ++ > 3 files changed, 65 insertions(+) > create mode 100644 configs/coreboot64_defconfig > > diff --git a/board/coreboot/coreboot/MAINTAINERS > b/board/coreboot/coreboot/MAINTAINERS > index 188906b0803..a05673bb0be 100644 > --- a/board/coreboot/coreboot/MAINTAINERS > +++ b/board/coreboot/coreboot/MAINTAINERS > @@ -4,3 +4,10 @@ S: Maintained > F: board/coreboot/coreboot/ > F: include/configs/chromebook_link.h > F: configs/coreboot_defconfig > + > +COREBOOT64 BOARD > +M: Simon Glass > +S: Maintained > +F: board/coreboot/coreboot/ > +F: include/configs/chromebook_link.h > +F: configs/coreboot64_defconfig > diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig > new file mode 100644 > index 000..80353b8eb36 > --- /dev/null > +++ b/configs/coreboot64_defconfig > @@ -0,0 +1,48 @@ > +CONFIG_X86=y > +CONFIG_SYS_TEXT_BASE=0x112 > +CONFIG_ENV_SIZE=0x1000 > +CONFIG_NR_DRAM_BANKS=8 > +CONFIG_PRE_CON_BUF_ADDR=0x10 > +CONFIG_X86_RUN_64BIT=y > +CONFIG_VENDOR_COREBOOT=y > +CONFIG_TARGET_COREBOOT=y > +CONFIG_SPL_TEXT_BASE=0x111 > +CONFIG_FIT=y > +CONFIG_FIT_SIGNATURE=y > +CONFIG_SHOW_BOOT_PROGRESS=y > +CONFIG_USE_BOOTARGS=y > +CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" > +CONFIG_PRE_CONSOLE_BUFFER=y > +CONFIG_SYS_CONSOLE_INFO_QUIET=y > +CONFIG_DISPLAY_BOARDINFO_LATE=y > +CONFIG_LAST_STAGE_INIT=y > +CONFIG_HUSH_PARSER=y > +CONFIG_CMD_IDE=y > +CONFIG_CMD_MMC=y > +CONFIG_CMD_PART=y > +CONFIG_CMD_USB=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_CMD_DHCP=y > +# CONFIG_CMD_NFS is not set > +CONFIG_CMD_PING=y > +CONFIG_CMD_TIME=y > +CONFIG_CMD_SOUND=y > +CONFIG_CMD_EXT2=y > +CONFIG_CMD_EXT4=y > +CONFIG_CMD_EXT4_WRITE=y > +CONFIG_CMD_FAT=y > +CONFIG_CMD_FS_GENERIC=y > +CONFIG_MAC_PARTITION=y > +# CONFIG_SPL_MAC_PARTITION is not set > +# CONFIG_SPL_DOS_PARTITION is not set > +CONFIG_ISO_PARTITION=y > +CONFIG_EFI_PARTITION=y > +# CONFIG_SPL_EFI_PARTITION is not set > +CONFIG_DEFAULT_DEVICE_TREE="coreboot" > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_REGMAP=y > +CONFIG_SYSCON=y > +# CONFIG_PCI_PNP is not set > +CONFIG_SOUND=y > +CONFIG_SOUND_I8254=y > +CONFIG_CONSOLE_SCROLL_LINES=5 > diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst > index fd974229eb4..9c44c025a48 100644 > --- a/doc/board/coreboot/coreboot.rst > +++ b/doc/board/coreboot/coreboot.rst > @@ -40,3 +40,13 @@ To enable video you must enable these options in coreboot: > At present it seems that for Minnowboard Max, coreboot does not pass through > the video information correctly (it always says the resolution is 0x0). This > works correctly for link though. > + > +64-bit U-Boot > +- > + > +In addition to the 32-bit 'coreboot' build there is a 'coreboot64' build. > This > +produces an image which can be booted from coreboot (32-bit). Internally it > +works by using a 32-bit SPL binary to switch to 64-bit for running U-Boot. It > +can be useful for running UEFI applications, for example. > + > +This has only been lightly tested. > -- I tested this with QEMU, but it reboots at U-Boot proper: $ qemu-system-x86_64 -nographic -m 2G -bios coreboot.rom Jumping to boot code at 0111(7ffd5000) U-Boot SPL 2020.04-00376-g785560e (Apr 23 2020 - 15:50:17 +0800) CPU: x86_64, vendor AMD, device 663h Trying to boot from SPI Jumping to 64-bit U-Boot: Note many features are missing U-Boot 2020.04-00376-g785560e (Apr 23 2020 - 15:50:17 +0800) CPU: x86_64, vendor , device 0h DRAM: 2 GiB coreboot-4.8.1-dirty Wed May 16 19:00:17 UTC 2018 romstage starting... CBMEM: Regards, Bin Regards, Bin
Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
Hi, On Tue, Apr 21, 2020 at 1:35 AM Peter Geis wrote: > > On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder wrote: > > > > Hi Chen, > > > > I tested your patches and all work pretty well. I just had issues with > > USB2 that doesn't recognize any of my USB keys (it's OK on USB3). > > > > I also had these issues with XHCI driver: > > => usb reset > > resetting USB... > > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()! > > BUG! > > �esetting ... > > > > => usb stop > > stopping USB.. > > Host not halted after 16000 microseconds. > > XHCI: failed to set VBus supply > > device_remove: Device 'usb@ff60' failed to remove, but children are > > gone > > > > But for the whole series: Tested-by: Loic Devulder > > > > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote: > > > From: Chen-Yu Tsai > > > > > > Hi everyone, > > > > > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly > > > dropping the custom board target, and dealing with the pinmuxing > > > through proper use of DM regulators / GPIO / pinctrl in SPL. > > > > > > This series adds proper support for Firefly / Libre Computer ROC- > > > RK3328-CC > > > single board computer. > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit > > > card size development board based on the Rockchip RK3328 SoC, with: > > > > > > - 1/2/4 GB DDR4 DRAM > > > - eMMC connector for optional module > > > - micro SD card slot > > > - 1 x USB 3.0 host port > > > - 2 x USB 2.0 host port > > > - 1 x USB 2.0 OTG port > > > - HDMI video output > > > - TRRS connector with audio and composite video output > > > - gigabit Ethernet > > > - consumer IR receiver > > > - debug UART pins > > > > > > Originally I started with Loic's patches, and syncing the device tree > > > files from Linux. That didn't get very far, with SPL failing to > > > detect > > > the SD card. Examining the schematics and internal state of GRF and > > > GPIOs, I realized that the logic for the SD card power enable switch > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin > > > would use. Instead, directly using the GPIO is required. > > > > > > To deal with this, DM regulator and GPIO are enabled in SPL, and > > > various device nodes are marked with u-boot,dm-spl to have them work. > > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN > > > pin muxed over to GPIO. > > > > > > Along the way, there are some clean-ups of existing dts files, moving > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync > > > from Linux. Only boards already existing in U-boot are synced. DT > > > binding header files are synced separately as there is already one > > > patch floating around. The DT sync also includes clean-up changes > > > only > > > recently posted, and likely won't make it in for at least a few > > > weeks. > > > > > > Please have a look, and test if possible. I cc-ed a couple people > > > that > > > showed interest in this board on mailing lists recently. > > > > > > Regards > > > ChenYu > > > > > > > > > Chen-Yu Tsai (6): > > > rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u- > > > boot.dtsi > > > rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u- > > > boot.dtsi > > > dt-bindings: clock: rk3328: sync from upstream Linux kernel > > > dt-bindings: power: rk3328-power: sync from upstream Linux kernel > > > rockchip: dts: rk3328: Sync device tree files from Linux > > > rockchip: rk3328: Add support for ROC-RK3328-CC board > > > > > > arch/arm/dts/Makefile |1 + > > > arch/arm/dts/rk3328-evb-u-boot.dtsi | 39 + > > > arch/arm/dts/rk3328-evb.dts | 220 +-- > > > arch/arm/dts/rk3328-roc-cc-u-boot.dtsi| 38 + > > > .../{rk3328-rock64.dts => rk3328-roc-cc.dts} | 135 +- > > > arch/arm/dts/rk3328-rock64.dts| 132 +- > > > arch/arm/dts/rk3328.dtsi | 1420 +++-- > > > > > > board/rockchip/evb_rk3328/MAINTAINERS |7 + > > > configs/roc-cc-rk3328_defconfig | 103 ++ > > > doc/README.rockchip |4 +- > > > include/dt-bindings/clock/rk3328-cru.h| 212 +-- > > > include/dt-bindings/power/rk3328-power.h | 19 + > > > 12 files changed, 1578 insertions(+), 752 deletions(-) > > > create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi > > > copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%) > > > create mode 100644 configs/roc-cc-rk3328_defconfig > > > create mode 100644 include/dt-bindings/power/rk3328-power.h > > > > > -- > > Loic Devulder | ldevulder@irc > > 0x175A963893C85F55 | D220 DEF5 56A3 DE00 9DAA 78BA 175A 9638 93C8 5F55 > > Senior QA Engineer | Container & Storage Solutions Quality Assurance > > team (qa-css) > > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB, 21284 (AG > >
Re: [PATCH 4/6] x86: cbfs: Drop unwanted declaration
On Mon, Apr 6, 2020 at 7:22 AM Simon Glass wrote: > > The intention here is add a forward declaration, not actually declare a > variable. Fix it. > > Signed-off-by: Simon Glass > --- > > include/cbfs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH 2/6] x86: Move work-around out of cpu_jump_to_64bit_uboot()
Hi Simon, On Mon, Apr 6, 2020 at 7:22 AM Simon Glass wrote: > > At present this function copies U-Boot from the last 1MB of ROM. This is > not the right way to do it. Instead, the binman symbol should provide the > location. > > But in any case the code should live in the caller, > spl_board_load_image(), so that the 64-bit jump function can be used > elsewhere. Move it. > > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/i386/cpu.c | 10 -- > arch/x86/lib/spl.c | 13 + > 2 files changed, 13 insertions(+), 10 deletions(-) > > diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c > index c8da7f10e9b..45416a9be5b 100644 > --- a/arch/x86/cpu/i386/cpu.c > +++ b/arch/x86/cpu/i386/cpu.c > @@ -611,16 +611,6 @@ int cpu_jump_to_64bit_uboot(ulong target) > > func = (func_t)ptr; > > - /* > -* Copy U-Boot from ROM > -* TODO(s...@chromium.org): Figure out a way to get the text base > -* correctly here, and in the device-tree binman definition. > -* > -* Also consider using FIT so we get the correct image length and > -* parameters. > -*/ > - memcpy((char *)target, (char *)0xfff0, 0x10); > - > /* Jump to U-Boot */ > func((ulong)pgtable, 0, (ulong)target); > > diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c > index 90baec2a175..95a89c072d5 100644 > --- a/arch/x86/lib/spl.c > +++ b/arch/x86/lib/spl.c > @@ -207,6 +207,19 @@ static int spl_board_load_image(struct spl_image_info > *spl_image, > spl_image->os = IH_OS_U_BOOT; > spl_image->name = "U-Boot"; > > + if (!IS_ENABLED(CONFIG_SYS_COREBOOT)) { For the coreboot case, where does it load the image then? > + /* > +* Copy U-Boot from ROM > +* TODO(s...@chromium.org): Figure out a way to get the text > base > +* correctly here, and in the device-tree binman definition. > +* > +* Also consider using FIT so we get the correct image length > +* and parameters. > +*/ > + memcpy((char *)spl_image->load_addr, (char *)0xfff0, > + 0x10); > + } > + > debug("Loading to %lx\n", spl_image->load_addr); > > return 0; > -- Regards, Bin
Re: [PATCH 1/6] x86: Allow building an SPL image for coreboot
Hi Simon, On Mon, Apr 6, 2020 at 7:22 AM Simon Glass wrote: > > Coreboot runs in 32-bit mode and cannot run a 64-bit U-Boot. To get around > this we can build a combined image with 32-bit SPL and 64-bit U-Boot. Add > a build rule and binman definition for this. > > Signed-off-by: Simon Glass > --- > > Makefile | 6 ++ > arch/x86/cpu/coreboot/Kconfig | 1 + > arch/x86/dts/coreboot-u-boot.dtsi | 18 ++ > 3 files changed, 25 insertions(+) > create mode 100644 arch/x86/dts/coreboot-u-boot.dtsi > Can we reuse the arch/x86/dts/u-boot.dtsi to do the same thing? I feel creating a new rule in /Makefile is not good. Regards, Bin
Re: [PATCH] spl: Kconfig: de-dup SPL_DM_GPIO definition
On 17.04.20 17:42, Joel Johnson wrote: > Two nearly concurrent commits (d4d65e112 and bcee8d676) added a > SPL_DM_GPIO symbol. Resolve the duplication in favor of the version > in drivers/gpio/Kconfig. > > Signed-off-by: Joel Johnson Reviewed-by: Frieder Schrempf > > --- > > common/spl/Kconfig | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 9d52b75cb4..ef5bf66696 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -508,12 +508,6 @@ config SPL_DMA > the CPU moving the data. Enable this option to build the drivers > in drivers/dma as part of an SPL build. > > -config SPL_DM_GPIO > - bool "Support Driver Model GPIO drivers" > - depends on SPL_GPIO_SUPPORT && DM_GPIO > - help > - Enable support for Driver Model based GPIO drivers in SPL. > - > config SPL_DRIVERS_MISC_SUPPORT > bool "Support misc drivers" > help >
Re: ZynqMP boot: no messages from SPL other than "Debug uart enabled"
Hi Michal, I've had to take a break because, as it turned out, my ZCU102 was defective. Now that I have a working one, I can go on with my frustrating quest for a bootable image. So now that the patches to u-boot for the ZCU102 Rev. 1.1 are in git master, I started again from scratch, building ATF, PMUFW with patch and config object, and u-boot. Once the builds finish, I place the files spl/boot.bin and u-boot.itb on the SD card and try to boot. Sadly, as before, the only result I get on the first UART channel is a line Debug uart enabled sometimes followed by ### ERROR ### Please RESET the board ### but nothing else. My suspicion is that the PMUFW or its configuration object isn't right. I use Luca's code from here to build both: https://github.com/lucaceresoli/zynqmp-pmufw-builder.git I also found an issue here: https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/Booting-ZCU-102-from-SD-Card/td-p/926649 It appears that there are at least two incompatible subrevisions of the board, both labeled Rev. 1.1. Could it be that the current PMUFW (or whatever) just won't work with the current revision? How do I figure out what the h*** is going on? Cheers, András On 12/03/2020 16:22, Michal Simek wrote: hi, On 12. 03. 20 15:19, Major A wrote: Hi Michal, ATF is not the part of boot.bin. PMUFW is the part of boot.bin. I'm confused. U-boot requires bl31.bin while building but not PMUFW (unless a non-default configuration option is set). Just to confirm that I'm thinking straight: ATF must be supplied in the form of a file bl31.bin in the SD card root directory in order for SPL to load it? SD boot flow boot.bin which contains u-boot SPL and PMUFW. SPL looks for u-boot.itb on fat partition which is U-Boot fit image which contains u-boot-nodtb, ATF(bl31.bin) and dtbs. It means flow is PMUFW on PMU, SPL -> ATF -> U-Boot proper. bl31.bin is only required for u-boot.itb generation. If you don't pass it it won't be included in u-boot.itb. I haven't tested SPL-> U-Boot in EL3 but it doesn't make too much sense anyway. Thanks, Michal
Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support
Hi Sean > > Hi Sean > > > On 4/22/20 9:51 PM, Rick Chen wrote: > > > Hi Sean > > > > > >> Hi Sean > > >> > > >>> This patch series adds support for Sipeed Maix boards and the Kendryte > > >>> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other > > >>> models are similar. > > >>> > > >>> Known Bugs/Limitations: > > >>> - Accessing the AI ram hangs, limiting available ram to 6M > > >>> - Trying to boot an image with bootm fails with > > >>> ERROR: Failed to allocate 0x7d60 bytes below 0x8000. > > >>> > > >>> To flash u-boot to a maix bit, run > > >>> kflash -tp /dev/ -B bit_mic u-boot-dtb.bin > > >>> > > >>> Boot output should look like the following: > > >>> > > >>> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 > > >>> -0500) > > >>> > > >>> DRAM: 8 MiB > > >>> In:serial@3800 > > >>> Out: serial@3800 > > >>> Err: serial@3800 > > >>> => > > >>> > > >>> Changes for v8: > > >>> - Removed dependency on the patch "clk: Add functions to register CCF > > >>> clock > > >>> structs". Hopefully this will make reviewing easier. > > >> > > >> I have applied this patch series to u-boot-riscv/master except [PATCH > > >> v8 14/21] riscv: Clean up IPI initialization code. > > >> Because it will cause some warnings as below: > > >> > > >> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi': > > >> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes > > >> integer from pointer without a cast [-Wint-conversion] > > >> int ret = syscon_get_first_range(RISCV_SYSCON_PLIC); > > >> ^~ > > >> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of > > >> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion] > > >> if (IS_ERR(ret)) > > >> ^~~ > > >> In file included from arch/riscv/lib/andes_plic.c:20:0: > > >> include/linux/err.h:34:20: note: expected 'const void *' but argument > > >> is of type 'int' > > >> static inline long IS_ERR(const void *ptr) > > >> ^~ > > >> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of > > >> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion] > > >>return PTR_ERR(ret); > > >> ^~~ > > >> In file included from arch/riscv/lib/andes_plic.c:20:0: > > >> include/linux/err.h:29:20: note: expected 'const void *' but argument > > >> is of type 'int' > > >> static inline long PTR_ERR(const void *ptr) > > >> ^~~ > > >> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer > > >> from integer without a cast [-Wint-conversion] > > >> gd->arch.plic = ret; > > >> > > > > > > after running CI yesterday, it failed in many cases: > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975 > > > > > > and I trace at least two cases belong to your patch > > > 49.59 > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035 > > > > > > arning, treated as error: > > > /home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error > > > in "code-block" directive: > > > 1 argument(s) required, 0 supplied. > > > .. code-block:: > > > { > > > assigned-clocks = < K210_CLK_PLL0>; > > > assigned-clock-rates = <8>; > > > }; > > > doc/Makefile:69: recipe for target 'htmldocs' failed > > > make[1]: *** [htmldocs] Error 1 > > > > I used to have > > > > .. code-block:: dts > > > > but it warned that "dts" was not a valid language, so I dropped it. > > > > > 49.66 > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042 > > > > > > ./tools/patman/patman --test && ./tools/buildman/buildman -t && > > > ./tools/dtoc/dtoc -t && make testconfig; fi; fi > > > cp: cannot create regular file > > > '/home/travis/build/rickchen36/sandbox/': Not a directory > > > cp: cannot create regular file > > > '/home/travis/build/rickchen36/sandbox/': Not a directory > > > WARNING: no status info for 'sipeed_maix_bitm' > > > WARNING: no maintainers for 'sipeed_maix_bitm' > > > > I'm not sure what the issue here is. Which specific files are lacking a > > MAINTAINERS entry? > > > > > > > > So I will drop your patchs and run CI again today. > > > And hope you can fix them in next version and pass CI verification. > > > > > > > > > > > > Thanks, > > > Rick > > > > > > > These "errors" seem rather minor. I will fix the PLIC ones in the next > > revision, but I don't think the sort found in this email are > > particularly erroneous. > > > Can you run and pass Travis CI after you fix your patchs > It help us to maintain the quality about patch works. > The Travis CI verification is pass without your v8 patchs. https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678432471 I have send a PR excluding your v9 patchs, because I am not sure if your v9 can pass the CI. After the PR being excepted by Tom and if your v9 patchs can pass the CI. I will send another PR later for
[U-Boot] Pull request: u-boot-riscv/master
Hi Tom, Please pull some riscv updates: - Adds few DT related fixes required for Linux EFI stub to work on RISC-V. - Makes SBI v0.2 the default SBI version to work with OpenSBI v0.7. - Revert "riscv: qemu: clear kernel-start/-end in device tree as workaround for BBL" - Remove unnecessary CONFIG_IS_ENABLED(). https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678432471 Thanks Rick The following changes since commit caad316b3165615f1a4848901811a4a08c9d: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-04-22 13:00:21 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git for you to fetch changes up to 177c53fe6c64d8656f5a647116a97047202c5455: riscv: Move all fdt fixups together (2020-04-23 10:14:16 +0800) Atish Patra (6): riscv: Add boot hartid to device tree fdtdec: Fix boundary check riscv: Provide a mechanism to fix DT for reserved memory riscv: Setup reserved-memory node for FU540 riscv: Copy the reserved-memory nodes to final DT riscv: Move all fdt fixups together Bin Meng (6): riscv: qemu: Remove the simple-bus driver for the SoC node riscv: Merge unnecessary SMP ifdefs in start.S riscv: Introduce SPL_SMP Kconfig option for U-Boot SPL riscv: Add SMP Kconfig option dependency for U-Boot proper riscv: Add Kconfig option for SBI v0.2 riscv: Make SBI v0.2 the default SBI version Lukas Auer (1): Revert "riscv: qemu: clear kernel-start/-end in device tree as workaround for BBL" Pragnesh Patel (1): riscv: ax25: cache: Remove SPL_RISCV_MMODE config check arch/riscv/Kconfig | 34 +++-- arch/riscv/cpu/ax25/cache.c | 16 ++-- arch/riscv/cpu/generic/cpu.c| 14 --- arch/riscv/cpu/start.S | 19 ++ arch/riscv/include/asm/global_data.h| 3 ++- arch/riscv/include/asm/u-boot-riscv.h | 2 ++ arch/riscv/lib/Makefile | 3 ++- arch/riscv/lib/asm-offsets.c| 1 + arch/riscv/lib/bootm.c | 5 arch/riscv/lib/fdt_fixup.c | 150 + arch/riscv/lib/spl.c| 2 +- board/emulation/qemu-riscv/Kconfig | 1 - board/emulation/qemu-riscv/qemu-riscv.c | 39 - common/spl/spl_opensbi.c| 2 +- configs/sifive_fu540_defconfig | 1 + doc/board/emulation/qemu-riscv.rst | 2 +- lib/fdtdec.c| 3 ++- 17 files changed, 211 insertions(+), 86 deletions(-) create mode 100644 arch/riscv/lib/fdt_fixup.c
Re: [PATCH 0/6] x86: efi: Add a 64-bit coreboot payload
Hi Simon, On Mon, Apr 6, 2020 at 7:22 AM Simon Glass wrote: > > This series creates a new 64-bit 'coreboot64' build which can be launched > from coreboot. It uses SPL to effect the jump to 64-bit mode. Adding 64-bit U-Boot as a coreboot payload is nice. > > This was done in an attempt to get the Ubuntu FirmwareTestSuite[1] Yet I fail to understand why adding 64-bit U-Boot as the coreboot payload could help running the Ubuntu Firmware Test Suite. Does 32-bit U-Boot as the coreboot payload not work in this case? > working. Unfortunately the latest version shows a splash screen and hangs, > perhaps due to some missing EFI support. > > [1] https://wiki.ubuntu.com/FirmwareTestSuite > > Regards, Bin
RE: [PATCH] dm: pinctrl: Use right device pointer for configuring pinctrl
Hi, > From: Lokesh Vutla > Sent: mercredi 22 avril 2020 19:26 > > commit 719cab6d2e2bf ("dm: pinctrl: convert pinctrl-single to livetree") > converted > pinctrl driver to livetree. In this conversion, the call to read > pinctrl-single,pins/bits > property is provided with pinctrl device pointer instead of pinctrl config > pointer. > Because of this none of the pins gets configured. Fix it by passing the right > udevice pointer. > > Fixes: 719cab6d2e2bf ("dm: pinctrl: convert pinctrl-single to livetree") > Reported-by: Tom Rini > Signed-off-by: Lokesh Vutla > --- > drivers/pinctrl/pinctrl-single.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Sorry for regression... Reviewed-by: Patrick Delaunay And thanks for the fixe Patrick
Re: [PATCH 2/2] test/py: fix test_efi_secboot/conftest.py
On 23.04.20 02:15, AKASHI Takahiro wrote: > Heinrich, > > On Wed, Apr 22, 2020 at 05:52:55PM +0200, Heinrich Schuchardt wrote: >> If udisksctl is present >> test/py/tests/test_efi_secboot/conftest.py >> fails because the disk image is never mounted. >> >> Normal users can only mount fuse file systems. Unfortunately fusefat is >> still in an experimental state and seems not to work here correctly. > > I haven't confirmed that fuse/fat is not stable, but > >> So as we have to be root or use the sudo command anyway delete all coding >> referring to udisksctl. > > I don't mind non-root path being deleted as it was used when Travis CI > didn't work with "sudo". > >> -- >> >> We should not use mount point /mnt as this directory or one of its >> sub-directories might already be in use as active mount points. Instead >> create a new directory in the build root as mount point. >> >> -- >> >> Remove debug print statements that have been commented out. print without >> parentheses is anyway invalid in Python 3. And pytest anyway filters out >> the output if there is no exception reported. > > 'printing a mount point' was mostly useful for debugging > non-root path. The code in your comments was invalid: We are using Python 3. In Python 3 print() is a function. > >> Signed-off-by: Heinrich Schuchardt >> --- >> test/py/tests/test_efi_secboot/conftest.py | 30 +- >> 1 file changed, 6 insertions(+), 24 deletions(-) >> >> diff --git a/test/py/tests/test_efi_secboot/conftest.py >> b/test/py/tests/test_efi_secboot/conftest.py >> index 40cdf15bf2..93d308cf0d 100644 >> --- a/test/py/tests/test_efi_secboot/conftest.py >> +++ b/test/py/tests/test_efi_secboot/conftest.py >> @@ -43,7 +43,8 @@ def efi_boot_env(request, u_boot_config): >> HELLO_PATH = u_boot_config.build_dir + >> '/lib/efi_loader/helloworld.efi' >> >> try: >> -non_root = tool_is_in_path('udisksctl') >> +mnt_point = u_boot_config.persistent_data_dir + '/mnt_efisecure' >> +check_call('mkdir -p {}'.format(mnt_point), shell=True) > > For consistency, it would be better to use "%" formatting as elsewhere > in the file. https://docs.python.org/release/3.0/library/stdtypes.html#old-string-formatting-operations explicitly says: "The formatting operations described here are obsolete and may go away in future versions of Python. Use the new String Formatting in new code." As using % was deprecated 12 years ago it would be great if you could rework your code to use current Python 3. Best regards Heinrich > > Thanks, > -Takahiro Akashi > >> >> # create a disk/partition >> check_call('dd if=/dev/zero of=%s bs=1MiB count=%d' >> @@ -57,25 +58,11 @@ def efi_boot_env(request, u_boot_config): >> check_call('dd if=%s.tmp of=%s bs=1MiB seek=1 count=%d conv=notrunc' >> % (image_path, image_path, 1), shell=True) >> check_call('rm %s.tmp' % image_path, shell=True) >> -if non_root: >> -out_data = check_output('udisksctl loop-setup -f %s -o %d' >> -% (image_path, 1048576), >> shell=True).decode() >> -m = re.search('(?<= as )(.*)\.', out_data) >> -loop_dev = m.group(1) >> -# print 'loop device is: %s' % loop_dev >> -out_data = check_output('udisksctl info -b %s' >> -% loop_dev, shell=True).decode() >> -m = re.search('MountPoints:[ \t]+(.*)', out_data) >> -mnt_point = m.group(1) >> -else: >> -loop_dev = check_output('sudo losetup -o 1MiB --sizelimit %dMiB >> --show -f %s | tr -d "\n"' >> +loop_dev = check_output('sudo losetup -o 1MiB --sizelimit %dMiB >> --show -f %s | tr -d "\n"' >> % (part_size, image_path), >> shell=True).decode() >> -mnt_point = '/mnt' >> -check_output('sudo mount -t %s -o umask=000 %s %s' >> +check_output('sudo mount -t %s -o umask=000 %s %s' >> % (fs_type, loop_dev, mnt_point), >> shell=True) >> >> -# print 'mount point is: %s' % mnt_point >> - >> # suffix >> # *.key: RSA private key in PEM >> # *.crt: X509 certificate (self-signed) in PEM >> @@ -134,13 +121,8 @@ def efi_boot_env(request, u_boot_config): >> % (mnt_point, EFITOOLS_PATH, EFITOOLS_PATH), >> shell=True) >> >> -if non_root: >> -check_call('udisksctl unmount -b %s' % loop_dev, shell=True) >> -# not needed >> -# check_call('udisksctl loop-delete -b %s' % loop_dev, >> shell=True) >> -else: >> -check_call('sudo umount %s' % loop_dev, shell=True) >> -check_call('sudo losetup -d %s' % loop_dev, shell=True) >> +check_call('sudo umount %s' % loop_dev, shell=True) >> +check_call('sudo losetup -d %s' % loop_dev,
RE: [PATCH V3 3/6] ARM: stm32: Implement board coding on AV96
Dear Marek, > From: Marek Vasut > Sent: mercredi 22 avril 2020 17:19 > > On 4/22/20 5:04 PM, Patrick DELAUNAY wrote: > > Hi Marek, > > Hi, > > >> From: Marek Vasut > >> Sent: mercredi 22 avril 2020 13:18 > >> > >> The AV96 board does exist in multiple variants. To cater for all of > >> them, implement board code handling. There are two GPIOs which code > >> the type of the board, read them out and use the value to pick the correct > device tree from an fitImage. > >> > >> Reviewed-by: Patrick Delaunay > >> Signed-off-by: Marek Vasut > >> Cc: Manivannan Sadhasivam > >> Cc: Patrick Delaunay > >> Cc: Patrice Chotard > >> --- > >> V2: No change > >> V3: Drop dm-pre-reloc and gpio-cells from config node > >> --- > >> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi| 1 + > >> .../stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 1 + > >> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi| 7 +++ > >> board/dhelectronics/dh_stm32mp1/Kconfig | 2 +- > >> board/dhelectronics/dh_stm32mp1/board.c | 61 +++ > >> .../dh_stm32mp1/u-boot-dhcom.its | 39 > >> .../dh_stm32mp1/u-boot-dhcor.its | 39 > >> configs/stm32mp15_dhcom_basic_defconfig | 3 + > >> configs/stm32mp15_dhcor_basic_defconfig | 3 + > >> include/configs/dh_stm32mp1.h | 15 + > >> 10 files changed, 170 insertions(+), 1 deletion(-) create mode > >> 100644 board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its > >> create mode 100644 board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its > >> create mode 100644 include/configs/dh_stm32mp1.h > >> > > > > I have 2 compilation issue on this patch with buildman > > [...] > > > > And you are the first user of CONFIG_SPL_FIT_SOURCE... > > Most certainly not the first, this was used before. > At least the last one checked by grep. > > I want to propose to copy the file with: > > > > --- Makefile [] > > But then you need to update the patch in .its files > > > > => remove no more necessary "../../../" > > Cam you send this patch, so I can rebase on top of it ? Done in : [PATCH] Makefile: copy SPL_FIT_SOURCE in build directory http://patchwork.ozlabs.org/project/uboot/patch/20200423093845.1.Idf086bdb530238139f0066b3fecc01529d7c0b7d@changeid/ Regards Patrick
[PATCH] Makefile: copy SPL_FIT_SOURCE in build directory
Copy the .its source file selected by CONFIG_SPL_FIT_SOURCE in builddir and in a file named "u-boot.its". This patch avoid compilation issue when CONFIG_SPL_FIT_SOURCE is used and KBUILD_OUTPUT is defined, in buildman for example. Signed-off-by: Patrick Delaunay --- Hi, Problem detected with path proposal: [V3,3/6] ARM: stm32: Implement board coding on AV96 http://patchwork.ozlabs.org/project/uboot/patch/20200422111814.121060-3-ma...@denx.de/ Issue see with: tools/buildman/buildman -v -V stm32mp15_dhcom_basic stm32mp15_dhcor_basic Building current source for 2 boards (2 threads, 6 jobs per thread) arm: + stm32mp15_dhcor_basic +FATAL ERROR: Couldn't open "board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its": No such file or directory +./tools/mkimage: Can't open u-boot.itb.tmp: No such file or directory +make[2]: *** [spl/u-boot-spl] Error 1 +make[1]: *** [spl/u-boot-spl] Error 2 +make: *** [sub-make] Error 2 arm: + stm32mp15_dhcom_basic +FATAL ERROR: Couldn't open "board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its": No such file or directory +./tools/mkimage: Can't open u-boot.itb.tmp: No such file or directory +make[2]: *** [spl/u-boot-spl] Error 1 +make[1]: *** [spl/u-boot-spl] Error 2 +make: *** [sub-make] Error 2 002 /2 stm32mp15_dhcom_basic This error doesn't occur for a local compilation, as the 2 files exist in source directory: "board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its" "board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its" But they can't found by buildman in build directory and the issue is reproduced with "KBUILD_OUTPUT=../build". With the proposed path the issue is solved. Regards Patrick Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 26307fd4a6..d574f8a181 100644 --- a/Makefile +++ b/Makefile @@ -1320,7 +1320,9 @@ endif # Boards with more complex image requirements can provide an .its source file # or a generator script ifneq ($(CONFIG_SPL_FIT_SOURCE),"") -U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) +U_BOOT_ITS := u-boot.its +$(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) + $(call if_changed,copy) else ifneq ($(CONFIG_SPL_FIT_GENERATOR),"") U_BOOT_ITS := u-boot.its -- 2.17.1
Re: [PATCH] x86: spi: Only use the fast SPI peripheral when support
Hi Simon, On Tue, Mar 24, 2020 at 9:45 PM Simon Glass wrote: > > At present we query the memory map on boards which don't support it. Fix > this by only doing it on Apollo Lake. > > This fixes booting on chromebook_link. > > Signed-off-by: Simon Glass > Fixes: 92842147c31 ("spi: ich: Add support for get_mmap() method") > --- > > drivers/spi/ich.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c > index a9d7715a55..9f8af45242 100644 > --- a/drivers/spi/ich.c > +++ b/drivers/spi/ich.c > @@ -637,7 +637,10 @@ static int ich_get_mmap(struct udevice *dev, ulong > *map_basep, uint *map_sizep, > uint *offsetp) > { > struct udevice *bus = dev_get_parent(dev); > + struct ich_spi_platdata *plat = dev_get_platdata(bus); > > + if (plat->ich_version != ICHV_APL) > + return -ENOENT; > return ich_get_mmap_bus(bus, map_basep, map_sizep, offsetp); > } Although the check added here is correct, it is still an incomplete fix. I don't understand why chromebook_link boot failure is caused by this because as I mentioned before in mrccache_get_region() the call to uclass_find_first_device(UCLASS_SPI_FLASH, ) already returns hence there is no chance to execute dm_spi_get_mmap() on link. Regards, Bin
Re: [PATCH] lib/crypto, efi_loader: avoid multiple inclusions of header files
On 23.04.20 02:28, AKASHI Takahiro wrote: > Heinrich, > > On Tue, Apr 21, 2020 at 12:23:13PM +0200, Heinrich Schuchardt wrote: >> On 4/21/20 2:37 AM, AKASHI Takahiro wrote: >>> By adding extra symbols, we can now avoid including x509_parser and >>> pkcs7_parser.h files multiple times. >>> >>> Signed-off-by: AKASHI Takahiro >>> Suggested-by: Heinrich Schuchardt >>> --- >>> lib/crypto/pkcs7_parser.h | 4 >>> lib/crypto/x509_parser.h | 4 >>> lib/efi_loader/efi_image_loader.c | 1 + >>> lib/efi_loader/efi_signature.c| 1 + >>> 4 files changed, 10 insertions(+) >>> >>> diff --git a/lib/crypto/pkcs7_parser.h b/lib/crypto/pkcs7_parser.h >>> index 6565fdc2d4ca..b8234da45a6a 100644 >>> --- a/lib/crypto/pkcs7_parser.h >>> +++ b/lib/crypto/pkcs7_parser.h >>> @@ -5,6 +5,9 @@ >>> * Written by David Howells (dhowe...@redhat.com) >>> */ >>> >>> +#ifndef _PKCS7_PARSER_H >>> +#define _PKCS7_PARSER_H >>> + >>> #include >>> #include >>> #include "x509_parser.h" >>> @@ -63,3 +66,4 @@ struct pkcs7_message { >>> size_t data_hdrlen;/* Length of Data ASN.1 header */ >>> const void *data; /* Content Data (or 0) */ >>> }; >>> +#endif /* _PKCS7_PARSER_H */ >>> diff --git a/lib/crypto/x509_parser.h b/lib/crypto/x509_parser.h >>> index c233f136fb35..4cbdc1d6612d 100644 >>> --- a/lib/crypto/x509_parser.h >>> +++ b/lib/crypto/x509_parser.h >>> @@ -5,6 +5,9 @@ >>> * Written by David Howells (dhowe...@redhat.com) >>> */ >>> >>> +#ifndef _X509_PARSER_H >>> +#define _X509_PARSER_H >>> + >>> #include >>> #include >>> #include >>> @@ -55,3 +58,4 @@ extern int x509_decode_time(time64_t *_t, size_t hdrlen, >>> */ >>> extern int x509_get_sig_params(struct x509_certificate *cert); >>> extern int x509_check_for_self_signed(struct x509_certificate *cert); >>> +#endif /* _X509_PARSER_H */ >>> diff --git a/lib/efi_loader/efi_image_loader.c >>> b/lib/efi_loader/efi_image_loader.c >>> index 6c270ce94f44..899adf8493d0 100644 >>> --- a/lib/efi_loader/efi_image_loader.c >>> +++ b/lib/efi_loader/efi_image_loader.c >>> @@ -14,6 +14,7 @@ >>> #include >>> #include >>> #include "../lib/crypto/pkcs7_parser.h" >>> +#include "../lib/crypto/x509_parser.h" >> >> As pkcs7_parser.h includes x509_parser.h there is no reason to include >> it again. > > No, I don't think so. > > My style of coding is that, if a symbol is used in a C file and it is > defined in a header file, the header file should be *directly* included > in the C file. > I believe that it is the common way so that we can avoid any "implicit" > dependencies among header files. We want U-Boot to build as fast as possible. So we should not include anything twice. When looking through the rest of the U-Boot code you will have noticed that we do not include malloc.h and stdio.h everywhere because it is included via common.h. As an example of a patch removing other unnecessary includes see for instance: cmd: fat: remove unused includes fd0e30b43b6b2401e68dc32c357869c617d4fdd1 Best regards Heinrich > > Thanks, > -Takahiro Akashi > > >>> >>> const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID; >>> const efi_guid_t efi_guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID; >>> diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c >>> index 658e3547da37..6ad09e4acbd7 100644 >>> --- a/lib/efi_loader/efi_signature.c >>> +++ b/lib/efi_loader/efi_signature.c >>> @@ -15,6 +15,7 @@ >>> #include >>> #include >>> #include "../lib/crypto/pkcs7_parser.h" >>> +#include "../lib/crypto/x509_parser.h" >> >> Same here. >> >> The rest is correct and should be merged. >> >> Best regards >> >> Heinrich >> >>> >>> const efi_guid_t efi_guid_image_security_database = >>> EFI_IMAGE_SECURITY_DATABASE_GUID; >>> >>
Re: [PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu
On Tuesday 21 April 2020 19:24:57 Tom Rini wrote: > On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Rohár wrote: > > Ok, so is something needed to do with this patch? > > Yes, re-order where the .travis.yml hunk is and add a similar part to > .gitlab-ci.yml and .azure-ci.yml. Hello Tom! I have looked at .travis.yml again, but I do not understand what do you mean by re-order. I really have no idea where you want to move that rx51_test.sh hunk. Could you describe it?
Re: [PATCH] lib/crypto, efi_loader: move some headers to include/crypto
On 23.04.20 02:31, AKASHI Takahiro wrote: > Heinrich, > > On Tue, Apr 21, 2020 at 12:26:08PM +0200, Heinrich Schuchardt wrote: >> On 4/21/20 2:38 AM, AKASHI Takahiro wrote: >>> Pkcs7_parse.h and x509_parser.h are used in UEFI subsystem, in particular, >>> secure boot. So move them to include/crypto to avoid relative paths. >>> >>> Signed-off-by: AKASHI Takahiro >>> Suggested-by: Heinrich Schuchardt >>> --- >>> {lib => include}/crypto/pkcs7_parser.h | 0 >>> {lib => include}/crypto/x509_parser.h | 0 >>> lib/crypto/pkcs7_parser.c | 4 >>> lib/crypto/x509_cert_parser.c | 4 >>> lib/crypto/x509_public_key.c | 6 -- >>> lib/efi_loader/efi_image_loader.c | 4 ++-- >>> lib/efi_loader/efi_signature.c | 4 ++-- >>> lib/efi_loader/efi_variable.c | 2 +- >>> test/lib/asn1.c| 4 ++-- >>> 9 files changed, 19 insertions(+), 9 deletions(-) >>> rename {lib => include}/crypto/pkcs7_parser.h (100%) >>> rename {lib => include}/crypto/x509_parser.h (100%) >>> >>> diff --git a/lib/crypto/pkcs7_parser.h b/include/crypto/pkcs7_parser.h >>> similarity index 100% >>> rename from lib/crypto/pkcs7_parser.h >>> rename to include/crypto/pkcs7_parser.h >>> diff --git a/lib/crypto/x509_parser.h b/include/crypto/x509_parser.h >>> similarity index 100% >>> rename from lib/crypto/x509_parser.h >>> rename to include/crypto/x509_parser.h >>> diff --git a/lib/crypto/pkcs7_parser.c b/lib/crypto/pkcs7_parser.c >>> index f5dda1179f8a..0ee207b6b1c8 100644 >>> --- a/lib/crypto/pkcs7_parser.c >>> +++ b/lib/crypto/pkcs7_parser.c >>> @@ -20,7 +20,11 @@ >>> #include >>> #include >>> #include >>> +#ifdef __UBOOT__ >>> +#include >>> +#else >>> #include "pkcs7_parser.h" >>> +#endif >>> #include "pkcs7.asn1.h" >>> >>> MODULE_DESCRIPTION("PKCS#7 parser"); >>> diff --git a/lib/crypto/x509_cert_parser.c b/lib/crypto/x509_cert_parser.c >>> index 4e41cffd2301..18f5407a076c 100644 >>> --- a/lib/crypto/x509_cert_parser.c >>> +++ b/lib/crypto/x509_cert_parser.c >>> @@ -18,7 +18,11 @@ >>> #include >>> #endif >>> #include >>> +#ifdef __UBOOT__ >>> +#include >>> +#else >>> #include "x509_parser.h" >>> +#endif >>> #include "x509.asn1.h" >>> #include "x509_akid.asn1.h" >>> >>> diff --git a/lib/crypto/x509_public_key.c b/lib/crypto/x509_public_key.c >>> index 676c0df17410..571af9a0adf9 100644 >>> --- a/lib/crypto/x509_public_key.c >>> +++ b/lib/crypto/x509_public_key.c >>> @@ -16,15 +16,17 @@ >>> #include >>> #endif >>> #include >>> -#ifndef __UBOOT__ >>> +#ifdef __UBOOT__ >>> +#include >>> +#else >>> #include >>> #include >>> #include >>> #include >>> #include >>> #include "asymmetric_keys.h" >>> -#endif >>> #include "x509_parser.h" >>> +#endif >>> >>> /* >>> * Set up the signature parameters in an X.509 certificate. This involves >>> diff --git a/lib/efi_loader/efi_image_loader.c >>> b/lib/efi_loader/efi_image_loader.c >>> index 899adf8493d0..f59b9a01140e 100644 >>> --- a/lib/efi_loader/efi_image_loader.c >>> +++ b/lib/efi_loader/efi_image_loader.c >>> @@ -13,8 +13,8 @@ >>> #include >>> #include >>> #include >>> -#include "../lib/crypto/pkcs7_parser.h" >>> -#include "../lib/crypto/x509_parser.h" >>> +#include "crypto/pkcs7_parser.h" >>> +#include "crypto/x509_parser.h" >> >> Thanks for fixing this. >> >> x509_parser.h is included in pkcs7_parser.h. Please, remove the >> superfluous line. > > See my comment in [1] > > [1] https://lists.denx.de/pipermail/u-boot/2020-April/408160.html We want U-Boot to build as fast as possible. So we should not include anything twice. When looking through the rest of the U-Boot code you will have noticed that we do not include malloc.h and stdio.h everywhere because it is included via common.h. As an example of a patch removing other unnecessary includes see for instance: cmd: fat: remove unused includes fd0e30b43b6b2401e68dc32c357869c617d4fdd1 Best regards Heinrich > > -Takahiro Akashi > > >>> >>> const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID; >>> const efi_guid_t efi_guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID; >>> diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c >>> index 6ad09e4acbd7..0ead10203aeb 100644 >>> --- a/lib/efi_loader/efi_signature.c >>> +++ b/lib/efi_loader/efi_signature.c >>> @@ -10,12 +10,12 @@ >>> #include >>> #include >>> #include >>> +#include >>> +#include >> >> Same here. >> >> Best regards >> >> Heinrich >> >>> #include >>> #include >>> #include >>> #include >>> -#include "../lib/crypto/pkcs7_parser.h" >>> -#include "../lib/crypto/x509_parser.h" >>> >>> const efi_guid_t efi_guid_image_security_database = >>> EFI_IMAGE_SECURITY_DATABASE_GUID; >>> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c >>> index 7df881a74b44..0c6d1deb58eb 100644 >>> --- a/lib/efi_loader/efi_variable.c >>> +++ b/lib/efi_loader/efi_variable.c >>> @@ -12,9 +12,9 @@ >>> #include
Re: [PATCH] tools: k3_gen_x509_cert: Allow selecting early JTAG debug value
On 22/04/20 10:39 PM, Andrew F. Davis wrote: > When authenticating the initial boot binary the ROM will check a debug > type value in the certificate and based on that open JTAG access to that > core. > > The default is currently full access, on HS this is useful for early > developers, but should not be the default as to prevent end system > integrators from unintentionally leaving this open. Won't JTAG access is useful for early developers. UART as well not available at this point. What we offer out of the box is not a production ready secure system. I would prefer to have it enabled by default. Thanks and regards, Lokesh > > On non-HS devices JTAG is left open anyway so this does not change > behavior on those devices. Change the default to off and allow it to be > switched back on by command line flag if needed. > > Signed-off-by: Andrew F. Davis > --- > tools/k3_gen_x509_cert.sh | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh > index b6d055f6f5..298cec1313 100755 > --- a/tools/k3_gen_x509_cert.sh > +++ b/tools/k3_gen_x509_cert.sh > @@ -12,6 +12,7 @@ RAND_KEY=eckey.pem > LOADADDR=0x41c0 > BOOTCORE_OPTS=0 > BOOTCORE=16 > +DEBUG_TYPE=0 > > gen_degen_template() { > cat << 'EOF' > degen-template.txt > @@ -79,7 +80,7 @@ cat << 'EOF' > x509-template.txt > > [ debug ] > debugUID = > FORMAT:HEX,OCT: > - debugType = INTEGER:4 > + debugType = INTEGER:TEST_DEBUG_TYPE > coreDbgEn = INTEGER:0 > coreDbgSecEn = INTEGER:0 > EOF > @@ -151,8 +152,9 @@ options_help[k]="key_file:file with key inside it. If not > provided script genera > options_help[o]="output_file:Name of the final output file. default to > $OUTPUT" > options_help[c]="core_id:target core id on which the image would be running. > Default to $BOOTCORE" > options_help[l]="loadaddr: Target load address of the binary in hex. Default > to $LOADADDR" > +options_help[d]="debug_type: Debug type, set to 4 to enable early JTAG. > Default to $DEBUG_TYPE" > > -while getopts "b:k:o:c:l:h" opt > +while getopts "b:k:o:c:l:d:h" opt > do > case $opt in > b) > @@ -170,6 +172,9 @@ do > c) > BOOTCORE=$OPTARG > ;; > + d) > + DEBUG_TYPE=$OPTARG > + ;; > h) > usage > exit 0 > @@ -224,12 +229,15 @@ gen_cert() { > #echo " LOADADDR = 0x$ADDR" > #echo " IMAGE_SIZE = $BIN_SIZE" > #echo " CERT_TYPE = $CERTTYPE" > + #echo " DEBUG_TYPE = $DEBUG_TYPE" > sed -e "s/TEST_IMAGE_LENGTH/$BIN_SIZE/" \ > -e "s/TEST_IMAGE_SHA_VAL/$SHA_VAL/" \ > -e "s/TEST_CERT_TYPE/$CERTTYPE/" \ > -e "s/TEST_BOOT_CORE_OPTS/$BOOTCORE_OPTS/" \ > -e "s/TEST_BOOT_CORE/$BOOTCORE/" \ > - -e "s/TEST_BOOT_ADDR/$ADDR/" x509-template.txt > $TEMP_X509 > + -e "s/TEST_BOOT_ADDR/$ADDR/" \ > + -e "s/TEST_DEBUG_TYPE/$DEBUG_TYPE/" \ > + x509-template.txt > $TEMP_X509 > openssl req -new -x509 -key $KEY -nodes -outform DER -out $CERT -config > $TEMP_X509 -sha512 > } > >