Re: [PATCH] tools: k3_gen_x509_cert: Allow selecting early JTAG debug value

2020-04-23 Thread Lokesh Vutla



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

2020-04-23 Thread AKASHI Takahiro
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

2020-04-23 Thread AKASHI Takahiro
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

2020-04-23 Thread Peter Geis
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

2020-04-23 Thread Tom Rini
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

2020-04-23 Thread Tom Rini
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

2020-04-23 Thread Wolfgang Denk
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

2020-04-23 Thread Wolfgang Denk
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

2020-04-23 Thread Eugeniy Paltsev
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

2020-04-23 Thread Jack Mitchell
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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck



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

2020-04-23 Thread Daniel Schwierzeck
+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

2020-04-23 Thread Pali Rohár
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Madalin Bucur
> -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

2020-04-23 Thread Yash Shah
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

2020-04-23 Thread Yash Shah
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

2020-04-23 Thread Yash Shah
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

2020-04-23 Thread Patrice Chotard
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

2020-04-23 Thread Alison Wang
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

2020-04-23 Thread Alison Wang
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Joel Johnson

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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Madalin Bucur
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

2020-04-23 Thread Andrew F. Davis
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

2020-04-23 Thread Tom Rini
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

2020-04-23 Thread Tom Rini
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Jagan Teki
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

2020-04-23 Thread Stefano Babic
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

2020-04-23 Thread Harald Seiler
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

2020-04-23 Thread Harald Seiler
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

2020-04-23 Thread Harald Seiler
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()

2020-04-23 Thread Harald Seiler
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"

2020-04-23 Thread Harald Seiler
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()

2020-04-23 Thread Harald Seiler
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"

2020-04-23 Thread Harald Seiler
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

2020-04-23 Thread Deepak Das
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Priyanka Jain
>-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

2020-04-23 Thread Priyanka Jain
>-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)

2020-04-23 Thread Bin Meng
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)

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Chen-Yu Tsai
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

2020-04-23 Thread Bin Meng
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()

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Schrempf Frieder
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"

2020-04-23 Thread Major A

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

2020-04-23 Thread Rick Chen
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

2020-04-23 Thread uboot
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Patrick DELAUNAY
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

2020-04-23 Thread Heinrich Schuchardt
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

2020-04-23 Thread Patrick DELAUNAY
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

2020-04-23 Thread Patrick Delaunay
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

2020-04-23 Thread Bin Meng
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

2020-04-23 Thread Heinrich Schuchardt
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

2020-04-23 Thread Pali Rohár
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

2020-04-23 Thread Heinrich Schuchardt
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

2020-04-23 Thread Lokesh Vutla



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
>  }
>  
>